From nobody Thu Feb 1 00:05:37 2018 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 619DC13161C for ; Thu, 1 Feb 2018 00:05:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 u7T8D6W3yCrd for ; Thu, 1 Feb 2018 00:05:30 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 36FB9131612 for ; Thu, 1 Feb 2018 00:05:17 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id EDCEBA8BF0B7C for ; Thu, 1 Feb 2018 08:05:13 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 1 Feb 2018 08:05:14 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0361.001; Thu, 1 Feb 2018 16:04:55 +0800 From: "Roni Even (A)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Martin Thomson CC: Brian Trammell , Eric Rescorla , QUIC WG , Christian Huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmdoQOHIMr4j8BEGT08HQjsZCKqOMWPCAgAAIFQCAAHdygIAAPGIAgAIc81A= Date: Thu, 1 Feb 2018 08:04:55 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD861418@DGGEMM506-MBX.china.huawei.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.244] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected 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 Feb 2018 08:05:34 -0000 KzENCkkgdGhpbmsgdGhhdCB0aGlzIGlzIHdoZXJlIHdlIG5lZWQgdG8gZXZhbHVhdGUgdGhlIHNl Y3VyaXR5IHZlcnN1cyBtYW5hZ2VhYmlsaXR5LiBJdCBpcyBub3QgYWJvdXQgdGhlIGNvbXBsZXhp dHkgb2YgdGhlIHNvbHV0aW9uLCB0aGUgcHJvcG9zZWQgZW5jcnlwdGlvbiBpcyBub3QgcGVyZmVj dCBzbyB3ZSBzaG91bGQgZGVjaWRlIHdoYXQgaXMgZ29vZCBlbm91Z2ggc29sdXRpb24gdGhhdCB3 aWxsIGFkZHJlc3Mgc2VjdXJpdHkgY29uY2VybnMgYW5kIGFsbG93IGZvciBuZXR3b3JrIG1hbmFn ZWFiaWxpdHkuDQpSb25pDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlD IFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWlyamEgS8O8aGxl d2luZA0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDMxLCAyMDE4IDk6NDUgQU0NClRvOiBNYXJ0 aW4gVGhvbXNvbg0KQ2M6IEJyaWFuIFRyYW1tZWxsOyBFcmljIFJlc2NvcmxhOyBRVUlDIFdHOyBD aHJpc3RpYW4gSHVpdGVtYQ0KU3ViamVjdDogUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0K DQoNCg0KPiBBbSAzMS4wMS4yMDE4IHVtIDA0OjA4IHNjaHJpZWIgTWFydGluIFRob21zb24gPG1h cnRpbi50aG9tc29uQGdtYWlsLmNvbT46DQo+IA0KPiBPbiBXZWQsIEphbiAzMSwgMjAxOCBhdCA4 OjAwIEFNLCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4gd3JvdGU6DQo+ Pj4gKDEpIEFuIHVucHJpdmlsZWdlZCBvbi1wYXRoIGRldmljZSB0aGF0IHNlZXMgYSBwYWNrZXQg ZnJvbSBhIGZsb3cgDQo+Pj4gdGhhdCBpcyBtaWdyYXRlZCBvbiBwdXJwb3NlIGJ5IGFuIGVuZHBv aW50IChpLmUuLCBkdWUgdG8gY29ubmVjdGlvbiANCj4+PiBtaWdyYXRpb24gb3INCj4+PiBtdWx0 aXBhdGgpIHNob3VsZCBub3QgYmUgYWJsZSB0byBhc3NvY2lhdGUgdGhhdCBwYWNrZXQgdG8gdGhl IHByaW9yIGZsb3cuDQo+PiANCj4+IFllcy4NCj4gDQo+IEFncmVlZC4gIFRoaXMgcmVtYWlucyB0 aGUgcHJpbWFyeSB0YXJnZXQuICBJIGRvbid0IHRoaW5rIHRoYXQgdGhlcmUgDQo+IGFyZSBhbnkg bmVnYXRpdmVzIHdpdGggdGhpcyBkZXNpZ24gd2l0aCByZXNwZWN0IHRvIHRoaXMgdXNlIGNhc2Ug KG9yIA0KPiBhdCBsZWFzdCBJIGZvdW5kIG5vdGhpbmcgaW4gQnJpYW4ncyBlbWFpbCBvbiB0aGlz IHBvaW50KS4NCg0KSWYgdGhhdCBpcyB0aGUgZ29hbCwgSSB0aGluayB0aGUgY29tcGxleGl0eSBv ZiB0aGUgcHJvcG9zZWQgc29sdXRpb24gaXMgbm90IGp1c3RpZmllZC4gSnVzdCBzZWxlY3QgYSBu ZXcgcmFuZG9tIG9mZnNldCB3aGVuIHlvdSBtaWdyYXRlIGJ1dCBpbmNyZWFzZSB0aGUgcGFja2V0 IG51bWJlciBtb25vdG9ub3VzbHkgb3RoZXJ3aXNlIHRvIHN1cHBvcnQgbWFuYWdlYWJpbGl0eS4N Cg0KSeKAmW0gcmVhbGx5IGNvbmNlcm5lZCBhYm91dCBjb21wbGV4aXR5IGhlcmUuIEV2ZW4gdGhv dWdoIHRoaXMgc2NoZW1lIGlzIG5vdCB2ZXJ5IGNvbXBsZXgsIGFueSBjb21wbGV4aXR5IGlzIGEg cG90ZW50aWFsIHNvdXJjZSBmb3IgZnV0dXJlIGltcGxlbWVudGF0aW9uIGVycm9ycyB3aGljaCBj YW4gYWxzbyBsZWQgdG8gcmVzdHJpY3Rpb25zIGluIHdoYXQgY2hhbmdlcyBjYW4gYmUgZGVwbG95 IHdpdGggZnV0dXJlIHZlcnNpb25zLiBNYWtpbmcgYSBwcm90b2NvbCBhcyBzaW1wbGUgYXMgcG9z c2libGUgYW5kIHRoZXJlYnkgdGhlIHNwZWMgYXMgZWFzeSB1bmRlcnN0YW5kYWJsZSBhcyBwb3Nz aWJsZSBpcyBhbHNvIGtleSBmb3IgZGVwbG95bWVudC4gSWYgd2UgYWRkIGNvbXBsZXhpdHkgaGVy ZSB3aXRob3V0IG1ha2luZyBpdCBjbGVhciB3aGF0IHRoZSBnb2FsIG9yIGFkZGl0aW9uYWwgYmVu ZWZpdCBpcyBvZiB0aGUgY29tcGxleGl0eSwgSSB0aGluayB0aGF0IGlzIGp1c3Qgd3JvbmcuDQoN Ck15IDJjLg0KTWlyamENCg0K From nobody Thu Feb 1 00:09:09 2018 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 4CBB41314F1 for ; Thu, 1 Feb 2018 00:09:08 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 I1BsMpA2NFGG for ; Thu, 1 Feb 2018 00:08:59 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80828131654 for ; Thu, 1 Feb 2018 00:08:14 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2A5C9340C6F; Thu, 1 Feb 2018 09:08:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.29588); Thu, 1 Feb 2018 09:08:11 +0100 (CET) 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; Thu, 1 Feb 2018 09:08:11 +0100 (CET) Received: from [213.55.211.8] (account ietf@trammell.ch HELO [172.20.10.4]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 43986049; Thu, 01 Feb 2018 09:08:11 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0487C45B-A3B5-4C43-9F93-6E3109805017"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Thu, 1 Feb 2018 09:08:08 +0100 In-Reply-To: Cc: Martin Thomson , Roberto Peon , Ted Hardie , Eric Rescorla , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , QUIC WG To: Jana Iyengar References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> 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, 01 Feb 2018 08:09:08 -0000 --Apple-Mail=_0487C45B-A3B5-4C43-9F93-6E3109805017 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, all, > On 1 Feb 2018, at 03:46, Jana Iyengar wrote: >=20 > I like this proposal for the ossification reason that Roberto = described, but I also like it because it really simplifies things from = an implementation perspective. There seems to be a largely unquestioned assumption that packet number = encryption has utility for ossification prevention. I am not convinced = of this. Our experience with TLS greasing shows that placing random values in = fields that would otherwise largely be static over the lifetime of the = protocol improves the ability to use those fields later. Packet number = encryption is greasing only by analogy. "Field X has value Y" is a = fundamentally different observation than "The values of field X over = time are governed by function F", and I'm not sure that intuition in the = simpler case applies directly to the more complicated one. Specifically, for packet number encryption, the assumption appears to be = that in-network devices will deploy during the operational lifetime of = QUIC v1 that will make use of the observation that packet numbers = monotonically increase, in a way that will impair the deployment of QUIC = vN > 1 that does not have packet numbers that monotonically increase, or = packet numbers that appear at a different location in the header. In = other words, these devices will fail on this new version of QUIC in such = a way that it will impair service to endpoints using QUIC vN. Analogies to the TCP sequence number here are a bit flawed. The most = important difference is that the open nature of TCP's wire image means = that usage of the sequence number isn't limited to observation: on-path = devices can change it, and forge or delay ACKs based on it. The only = thing an on-path device can do with a QUIC packet with a packet number = it doesn't like is to drop it. This function might have some utility as = part of an in-network QUIC garbage filter, as part of an anti-DDoS = system, but any such device would need to track the version number as = well (indeed, tracking version negotiation and handshaking would be a = useful primitive here in its own right), and would therefore have enough = information to not break on new versions it knows about. (Note we specifically don't care about the case where devices making use = of this observation stop working in a way that the end-to-end properties = of QUIC vN are preserved: the invariants as of a given version are the = public wire-image interface to the protocol, anything else is = at-your-own-risk, no-user-servicable-parts-inside). I suspect that similar arguments can be had about all but the simplest = proposed applications of greasing to functions more complex than "the = value of field X is always Y or Z". The example of packet number = tracking points to an anti-ossification approach that I have much more = confidence in, though: The vigorous and meaningful exercise of the version negotiation and = version coexistence systems built into QUIC would force agility on = on-path devices. The earlier we do this, the more effective it would be. = I've already said this in other contexts, but I'll explicitly suggest it = here: let's do QUIC 2, and soon (say, July 2019?), and use version = negotiation *itself* as a method to "grease" the version negotiation = mechanism along with the rest of the header. > We currently have packet number gaps to be used with new CIDs, but = these are the same packet numbers on the wire as within the transport. = So, when used with connection migration or after quiescence, the sender = and receiver of ACKs has to deal with potentially large gaps... this is = encodable on the wire, sure, but these gaps are unnecessary within the = transport. >=20 > Encrypting packet numbers reduces complexity in that you get a packet = number gap on the wire without having to explicitly model it inside the = transport. The transport machinery starts packet numbers at 0, = increments it by 1 irrespective of migration or quiescence, and the ACK = frames similarly carry the plaintext packet number. Separating what's = used within the transport and what's visible on the wire allows you to = do things like use multiple CIDs within the same 5-tuple. This is a more convincing argument for packet number encryption -- it = does seem hard to get this elegance in the transport while having a = non-trivially-linkable wire image without it. > I see it as a clean separation of concerns, with consequent = simplification in implementation and an additional degree of freedom. >=20 > I'm not convinced of the value of packet number in measuring = reordering degree, since this can be trivially done by looking at the IP = ID field for packets on the same 5-tuple. For IPv4 packets, on implementations where IPID is not randomized, yes. = I don't have numbers on how prevalent these are; in any case, where it = isn't randomized, that's arguably a bug that should be fixed. Should the = guidance in the manageability draft, then, be "use IPv4 if you care = about loss and reordering detection"? I am not optimistic about the = chances of that getting past the IESG. ;) Cheers, Brian > On Wed, Jan 31, 2018 at 6:00 PM, Martin Thomson = wrote: > With some light editing for quoting purposes... >=20 > On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon wrote: > >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for = the same > >> communicating peers Alice'sPhone and Bob'sBankServer93? > > > > The latter assuming we allow the server to specify it. >=20 > I find "assuming we allow the server to specify *it*" to be strangely = cryptic. >=20 > To be clear, my operating assumption is while that servers can provide > multiple connection IDs, those connection IDs need to be usable on any > 5-tuple. Are you suggesting that a server might need to signal where > a connection is usable? (I can see how that might make sense, but it > isn't possible with the protocol as specified.) Or are you suggesting > that there might need to be some signal that allows clients to > distinguish between connection IDs that are for concurrent use? That > is, as opposed to what you might assume to be sequential use based on > the current specification. >=20 > FWIW, it should be possible to remove the sequencing field from > NEW_CONNECTION_ID after making this change. The only reason left for > sequential connection ID use is to give the server the ability to know > when certain connection IDs no longer need to be available. A server > might then be able to clean up associated state and even reuse them. >=20 > Of course, that likely only makes sense if the server is creating > explicit mappings for each, which - as discussed at the interim - > isn't super practical in many deployments. Right now, I think that > the assumption is an assumption only, and that relying on strictly > linear use of connection IDs would be unwise. >=20 >=20 --Apple-Mail=_0487C45B-A3B5-4C43-9F93-6E3109805017 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlpyyugACgkQihK3vwvq RqN1Rg/+M1BnzNe/Rtd/rtrBhivCnkZCkv3q5jv7mBHsUtCaj634U4dHi3Sk5jYR 6a/HcCpwI43q/y+jt0ZLOBlxXWZQRqb3/5aQ1cPFE1G3lD/mE3Gjz9HcABGP05sK AvTDMFCN+tt/nFDYNwmJ9TVp6ux1PNHvA3My+oZTwTbua70gB5XuKI3wsFTMRGR2 h25Br8SOthx3yQODJWUVe6OHpmzJybmtNNgOKQ6oL+3exSieIsmPgRnssSC5MToH du+SbPomn82mjtNhMdiQTH/OcjM0Ztpxx0ctns3UXmxx3/DJFBc5zdYJsaluYx6W 7Ells01U5R3AnKY+POPdLCKJ6t7+kwRYTZ9AUXlgwVrgGThA5A26Ep3B5JAnzw0w /H9T1Dz+0f3oKzW/zp9Z8UaV/63hTRHH+WYrax79MXs7DhtYNRBQ8YcyV9vwfymN Bg5ramkW3E4qt87gmwyFkv0ltlOV20dr9L06fE7M3C7VpeThz6c+tQukuuqRHB56 kNTlNG9trLzxTs171BfBHoL8EYqM95u5QMWvCfnwcopqDPsumCMQTFAzKRNBYPoy awq0NkIlBhMzcNCY+E+MKwyiuj7V64xSFtpNUXlSd/FQGxpgwhWo/5tbeD6FDu78 WMQ2QnUBBmzcp2p32Al1DlnUdsBJEo3GNrWSPl/r258enlmlPMA= =Nhrb -----END PGP SIGNATURE----- --Apple-Mail=_0487C45B-A3B5-4C43-9F93-6E3109805017-- From nobody Thu Feb 1 00:38:41 2018 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 ED9A2131607 for ; Thu, 1 Feb 2018 00:38:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, 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=fb.com header.b=KiA/XdbE; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Av34Grn9 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 Ha2qoy6vRAKA for ; Thu, 1 Feb 2018 00:38:37 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 6783B131614 for ; Thu, 1 Feb 2018 00:38:37 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w118Y1rd022631; Thu, 1 Feb 2018 00:38:29 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=oVmPUjXUCt28gZ7XKWS9iAR0pAvQA5p23xkt9YSrjBA=; b=KiA/XdbEFemq3fovrEY53V/BzhWv8er5c2hwAjikqwujq/f7EREEyqFmcpF7xbDmanma 0FtDI6YeatVngcpulQUkCKdDoIQuhEAkg8cz1ndStlX8DL4iSFAEuRC5u+mUTt1jAxmD WgeLOqABAE1dHG9MVoDn5E5m0X/KA5x3OPQ= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2fuv7s99pp-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 01 Feb 2018 00:38:29 -0800 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 1 Feb 2018 03:38:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oVmPUjXUCt28gZ7XKWS9iAR0pAvQA5p23xkt9YSrjBA=; b=Av34Grn9SLuDLXoji8U+wIAw7YJ4ecJpYVNwgiwFyRMezVF58uSmFyOniufQMWG47S6UAml5fxFOYm110l0Gfs33qLliphab0vE9miYEORvwpV24pYiIcq53MI551lpR6uznmG3KlLAJJOqxniWy8pqEhhzjRrNRe4huaP7sibg= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0216.namprd15.prod.outlook.com (10.163.64.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Thu, 1 Feb 2018 08:38:26 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0444.016; Thu, 1 Feb 2018 08:38:25 +0000 From: Roberto Peon To: Martin Thomson CC: Ted Hardie , =?iso-8859-1?Q?Mirja_K=FChlewind?= , Brian Trammell , "Eric Rescorla" , QUIC WG , Christian Huitema Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW3+HjM5RmHWDkij9J5s6UBSSaOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAAIDjAIAAlG6A//+GjQCAAJZkAIAAbyKp Date: Thu, 1 Feb 2018 08:38:25 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.234.190.115] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0216; 20:PKmthJmlN/KZnIpJeipfPD1DrH004Xhg/K1bXPDZaVMsjPf4fH88bMGH3J/43Xr+C3E2x1F0bfTYEL9+oHiy8/aUdJVX1JflH/kO6OBWX8K1kC7dxMjVvqHZNiKEPFcSu8I3DR1xRxcFfbOSJgK37u5VRbsJN/tTUirRvJ+P9F4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2204dd99-da1b-4180-b899-08d5694f294f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0216; x-ms-traffictypediagnostic: BY2PR15MB0216: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158)(67672495146484); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(11241501184)(2400082)(944501161)(3002001)(93006095)(93001095)(10201501046)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR15MB0216; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0216; x-forefront-prvs: 0570F1F193 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(39380400002)(376002)(366004)(51444003)(189003)(199004)(9686003)(81166006)(316002)(6916009)(7736002)(76176011)(33656002)(4326008)(3480700004)(93886005)(7696005)(14454004)(3280700002)(6246003)(74316002)(478600001)(3660700001)(26005)(81156014)(97736004)(6506007)(77096007)(8676002)(53546011)(105586002)(39060400002)(102836004)(106356001)(54906003)(5660300001)(6436002)(2950100002)(8936002)(68736007)(6116002)(53936002)(54896002)(2900100001)(7116003)(186003)(2906002)(99286004)(55016002)(86362001)(3846002)(25786009)(229853002)(66066001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0216; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: fLP+754SFrfbdOf2WkLt6lQo84zpuhrr3sKQRUamX7A/Okw0rxpjcf/JMBkdLhmdnb2ENJVF71xg5tmZySrKoQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR15MB0775DF393AD42427FDE3B21BCDFA0BY2PR15MB0775namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2204dd99-da1b-4180-b899-08d5694f294f X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 08:38:25.7497 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0216 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-01_03:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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 Feb 2018 08:38:40 -0000 --_000_BY2PR15MB0775DF393AD42427FDE3B21BCDFA0BY2PR15MB0775namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm assuming a server smart enough to encrypt routing info (i.e. l7 instanc= e to which the l4 should forward) with sufficient random salt that the CID = looks completely random to someone else (other than l4 or l7). I was assuming for now that a CID so given was valid on any path. It would= , however, be perfectly reasonable (though not yet spec'd) for "real" multi= path to specify CID on a per dst tuple basis (so per day tuple or for any d= st tuple could be different CIDs), in which case the server would need a pr= otocol mechanism. Ideally such a mechanism would allow an automatic change = of CID when the client is participating in the new 5-tuple/path, potentiall= y allowing detection of explicit client action (client explicitly binds to = new 5-tuple) vs nat rebinding (oh, I have a new address,oops/how curious!),= etc. I was also thinking about l4/l7 shared key material. In particular, to deal= with key rotation for the shared key material used to encrypt the CID with= out making a new connection, a server must both be able to provide CIDs, an= d be able revoke them. It must revoke (or equivalent) so that a client will= have a finite lifetime with the old CID, presumably using the old key mate= rial. -=3DR Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- From: Martin Thomson Date: 1/31/18 6:01 PM (GMT-08:00) To: Roberto Peon Cc: Ted Hardie , Mirja K=FChlewind , Brian Trammell , Eric Rescorla , QUIC WG , Christian Huitema Subject: Re: Packet number encryption With some light editing for quoting purposes... On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon wrote: >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for the = same >> communicating peers Alice'sPhone and Bob'sBankServer93? > > The latter assuming we allow the server to specify it. I find "assuming we allow the server to specify *it*" to be strangely crypt= ic. To be clear, my operating assumption is while that servers can provide multiple connection IDs, those connection IDs need to be usable on any 5-tuple. Are you suggesting that a server might need to signal where a connection is usable? (I can see how that might make sense, but it isn't possible with the protocol as specified.) Or are you suggesting that there might need to be some signal that allows clients to distinguish between connection IDs that are for concurrent use? That is, as opposed to what you might assume to be sequential use based on the current specification. FWIW, it should be possible to remove the sequencing field from NEW_CONNECTION_ID after making this change. The only reason left for sequential connection ID use is to give the server the ability to know when certain connection IDs no longer need to be available. A server might then be able to clean up associated state and even reuse them. Of course, that likely only makes sense if the server is creating explicit mappings for each, which - as discussed at the interim - isn't super practical in many deployments. Right now, I think that the assumption is an assumption only, and that relying on strictly linear use of connection IDs would be unwise. --_000_BY2PR15MB0775DF393AD42427FDE3B21BCDFA0BY2PR15MB0775namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm assuming a server smart enough to encrypt routing info (i.e. l7 in= stance to which the l4 should forward) with sufficient random salt that the= CID looks completely random to someone else (other than l4 or l7).

I was assuming for now that a CID so given was valid on any path. = ; It would, however, be perfectly reasonable (though not yet spec'd) for &q= uot;real" multipath to specify CID on a per dst tuple basis (so per da= y tuple or for any dst tuple could be different CIDs), in which case the server would need a protocol mechanism. Ideally s= uch a mechanism would allow an automatic change of CID when the client is p= articipating in the new 5-tuple/path, potentially allowing detection of exp= licit client action (client explicitly binds to new 5-tuple) vs nat rebinding (oh, I have a new address,oops/how = curious!), etc.

I was also thinking about l4/l7 shared key material. In particular, to= deal with key rotation for the shared key material used to encrypt the CID= without making a new connection, a server must both be able to provide CID= s, and be able revoke them. It must revoke (or equivalent) so that a client will have a finite lifetime with t= he old CID, presumably using the old key material.

-=3DR

Sent via the Samsu= ng Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: Martin Thomson <martin.thomson@gmail.com>
Date: 1/31/18 6:01 PM (GMT-08:00)
To: Roberto Peon <fenix@fb.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, Mirja K=FChlewind <mirja= .kuehlewind@tik.ee.ethz.ch>, Brian Trammell <ietf@trammell.ch>, Er= ic Rescorla <ekr@rtfm.com>, QUIC WG <quic@ietf.org>, Christian = Huitema <huitema@huitema.net>
Subject: Re: Packet number encryption

With some light editing for quoting purposes...
On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon <fenix@fb.com> wrote: >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, fo= r the same
>> communicating peers  Alice'sPhone and Bob'sBankServer93?
>
> The latter assuming we allow the server to specify it.

I find "assuming we allow the server to specify *it*" to be stran= gely cryptic.

To be clear, my operating assumption is while that servers can provide
multiple connection IDs, those connection IDs need to be usable on any
5-tuple.  Are you suggesting that a server might need to signal where<= br> a connection is usable?  (I can see how that might make sense, but it<= br> isn't possible with the protocol as specified.)  Or are you suggesting=
that there might need to be some signal that allows clients to
distinguish between connection IDs that are for concurrent use? That
is, as opposed to what you might assume to be sequential use based on
the current specification.

FWIW, it should be possible to remove the sequencing field from
NEW_CONNECTION_ID after making this change.  The only reason left for<= br> sequential connection ID use is to give the server the ability to know
when certain connection IDs no longer need to be available.  A server<= br> might then be able to clean up associated state and even reuse them.

Of course, that likely only makes sense if the server is creating
explicit mappings for each, which - as discussed at the interim -
isn't super practical in many deployments.  Right now, I think that the assumption is an assumption only, and that relying on strictly
linear use of connection IDs would be unwise.
 --_000_BY2PR15MB0775DF393AD42427FDE3B21BCDFA0BY2PR15MB0775namp_-- From nobody Thu Feb 1 00:50:59 2018 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 191C61315F0 for ; Thu, 1 Feb 2018 00:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, 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=fb.com header.b=kWSFUWou; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Uj1R/VFn 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 cvg0AOXrQMye for ; Thu, 1 Feb 2018 00:50:53 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 885E2131685 for ; Thu, 1 Feb 2018 00:50:50 -0800 (PST) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w118nL3j016330; Thu, 1 Feb 2018 00:50:42 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=facebook; bh=diJOkN1rFX/DVdhIvfDMwciboFfL5VHggt37w5/AsdE=; b=kWSFUWouUKbimhB/FrAn55MWXXj7BjazVOlJHee+cN4Sr5gIF6Yu31z0QLV2luI7vHKe jDYGVUgJXeUGS+e3YLluuiYxHVjIr97/lgB5ZhEySgFqQNfBZyZYeWATaZUezzrBVXMV lW00vMJmfWYBBnP1KH8SspDY798nzjWTmTI= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fuvnxs4g8-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 01 Feb 2018 00:50:42 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.20) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 1 Feb 2018 00:50:40 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=diJOkN1rFX/DVdhIvfDMwciboFfL5VHggt37w5/AsdE=; b=Uj1R/VFn3+PB8bKoP/sxls6FTMPFgBYsetk690bD4dIO8gwQueBGneK1pAlRbeouxFXdbB30rXj0I/qnXmBO5NmewWJqLEJnbLbizGpc8gnbwU5eO/IqdCiVlCN6i4NCJ+kD6sptUPX6a6YG0ljMg15iSeCGs9t1X4MRduhElqA= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0197.namprd15.prod.outlook.com (10.163.64.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.444.14; Thu, 1 Feb 2018 08:50:38 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0444.016; Thu, 1 Feb 2018 08:50:38 +0000 From: Roberto Peon To: "Brian Trammell (IETF)" , Jana Iyengar CC: Martin Thomson , Ted Hardie , Eric Rescorla , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Christian Huitema , QUIC WG Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmzm7HjM5RmHWDkij9J5s6UBSSQ== Date: Thu, 1 Feb 2018 08:50:38 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.234.190.115] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0197; 7:5cDDjw4UEthdIYpncGVPyYNhqMqRUv2aXysjbokNIxlBbstXWxEm9WCQMAxnlOjwI9JvYkVNLChROeCPilGOj5yk6Es/k2Lsx5xLRijuda7fJugmskmJzP1IB62vxqCZw1acJr/OcYkKO/Z0nvg5ErDfwmmxJcboNodMj0FzAK2McDxo/Y/TkLU7ikcYYDueITnM1CufDAwPjaliHSr7IaSD9ffjb+Krt1ueQ7PxwOuOeMCMQzoJq+CIE58VdByP; 20:L6J6DlYUIQWcJo2L+1jSxKWMoX/4eLmaMrcmlgknaj6NNY0YpKQjUykulWcdyN/JBQ1uWsujjP8HLbNwsSj/ecaJfa8iHnDR9xHyR2J9oDnT5pGbviNvu2P5Y67vnlnDdXZLMblzqAe/wmeCFHneuQxQAjZK5b53j9/+oXPDnyE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 82d8ee60-bbcd-4026-7359-08d56950dde8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0197; x-ms-traffictypediagnostic: BY2PR15MB0197: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(85827821059158)(67672495146484)(211936372134217)(153496737603132)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(11241501184)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BY2PR15MB0197; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0197; x-forefront-prvs: 0570F1F193 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(346002)(396003)(366004)(39860400002)(199004)(189003)(51444003)(77096007)(74316002)(2900100001)(53546011)(54896002)(2906002)(97736004)(7736002)(66066001)(59450400001)(2690700001)(102836004)(14454004)(86362001)(8676002)(3846002)(7696005)(6506007)(106356001)(4326008)(561944003)(25786009)(6116002)(99286004)(110136005)(39060400002)(81166006)(33656002)(6246003)(81156014)(316002)(105586002)(5660300001)(478600001)(7116003)(53936002)(3660700001)(3280700002)(8936002)(229853002)(55016002)(186003)(9686003)(3480700004)(26005)(54906003)(68736007)(6436002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0197; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: nKsYmjbQtFDvPi+jaQp8T2OOL+ui8RcrrSWLtUblEGRlf1eNfVoY8douW29oWXGEcxapy/SPUcksJNlgytAtNQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR15MB07756D4F528DE909A5B0057FCDFA0BY2PR15MB0775namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 82d8ee60-bbcd-4026-7359-08d56950dde8 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 08:50:38.2998 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0197 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-01_03:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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 Feb 2018 08:50:57 -0000 --_000_BY2PR15MB07756D4F528DE909A5B0057FCDFA0BY2PR15MB0775namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90ZSB0aGF0IHRoZSBzaXplIG9mIHRoZSBDSUQgaXMgYWxzbyBub3Qga25vd24gdG8gdGhlIG5l dHdvcmsgYXNzdW1pbmcgd2UgYXJlIGVuY3J5cHRpbmcgYW5kIGRvaW5nIHZhcmlhYmxlLCBpbXBs aWNpdCBsZW5ndGggQ0lEIGZvciBzaG9ydCBoZWFkZXJzICh3aGljaCBpcyB3aGF0IEkgdW5kZXJz dGFuZCB0byBiZSB0aGUgcHJvcG9zYWwpIGNob3NlbiBieSB0aGUgc2VydmVyLg0KDQpUaGUgbDcg bWF5IGVuY29kZSB0aGUgbGVuZ3RoIHdpdGhpbiB0aGUgQ0lELCB3aGljaCBvbmUgY291bGQgaW1h Z2luZSBtaWdodCBiZSBjb21tb24sIGhvd2V2ZXIgdGhlIG5ldHdvcmsgd291bGQgaGF2ZSBhIGhp Z2hlciBiYXIgdG8gZGV0ZXJtaW5pbmcgaXQuDQoNClVubGVzcyB3ZSBwcmV2ZW50IGl0LCBhc3N1 bWluZyB0aGUgc2VydmVyIGNhbiBjYXVzZSB0aGUgY2xpZW50IHRvIHVzZSBtdWx0aXBsZSBDSURz LCB0aGUgbGVuZ3RoIG9mIHRoZSBDSUQgY291bGQgdmFyeSBldmVuIHdpdGhpbiB0aGUgcGFja2V0 cyBvbiBhIHNpbmdsZSBmbG93LzUtdHVwbGUuDQoNCi09Ug0KDQpTZW50IHZpYSB0aGUgU2Ftc3Vu ZyBHYWxheHkgUzcsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUNCg0KLS0tLS0tLS0gT3JpZ2lu YWwgbWVzc2FnZSAtLS0tLS0tLQ0KRnJvbTogIkJyaWFuIFRyYW1tZWxsIChJRVRGKSIgPGlldGZA dHJhbW1lbGwuY2g+DQpEYXRlOiAyLzEvMTggMTI6MDggQU0gKEdNVC0wODowMCkNClRvOiBKYW5h IEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPg0KQ2M6IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20+LCBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT4sIFRlZCBIYXJkaWUg PHRlZC5pZXRmQGdtYWlsLmNvbT4sIEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4sIE1pcmph IEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+LCBDaHJpc3RpYW4g SHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4sIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCmhpIEphbmEsIGFsbCwNCg0K PiBPbiAxIEZlYiAyMDE4LCBhdCAwMzo0NiwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT4g d3JvdGU6DQo+DQo+IEkgbGlrZSB0aGlzIHByb3Bvc2FsIGZvciB0aGUgb3NzaWZpY2F0aW9uIHJl YXNvbiB0aGF0IFJvYmVydG8gZGVzY3JpYmVkLCBidXQgSSBhbHNvIGxpa2UgaXQgYmVjYXVzZSBp dCByZWFsbHkgc2ltcGxpZmllcyB0aGluZ3MgZnJvbSBhbiBpbXBsZW1lbnRhdGlvbiBwZXJzcGVj dGl2ZS4NCg0KVGhlcmUgc2VlbXMgdG8gYmUgYSBsYXJnZWx5IHVucXVlc3Rpb25lZCBhc3N1bXB0 aW9uIHRoYXQgcGFja2V0IG51bWJlciBlbmNyeXB0aW9uIGhhcyB1dGlsaXR5IGZvciBvc3NpZmlj YXRpb24gcHJldmVudGlvbi4gSSBhbSBub3QgY29udmluY2VkIG9mIHRoaXMuDQoNCk91ciBleHBl cmllbmNlIHdpdGggVExTIGdyZWFzaW5nIHNob3dzIHRoYXQgcGxhY2luZyByYW5kb20gdmFsdWVz IGluIGZpZWxkcyB0aGF0IHdvdWxkIG90aGVyd2lzZSBsYXJnZWx5IGJlIHN0YXRpYyBvdmVyIHRo ZSBsaWZldGltZSBvZiB0aGUgcHJvdG9jb2wgaW1wcm92ZXMgdGhlIGFiaWxpdHkgdG8gdXNlIHRo b3NlIGZpZWxkcyBsYXRlci4gUGFja2V0IG51bWJlciBlbmNyeXB0aW9uIGlzIGdyZWFzaW5nIG9u bHkgYnkgYW5hbG9neS4gIkZpZWxkIFggaGFzIHZhbHVlIFkiIGlzIGEgZnVuZGFtZW50YWxseSBk aWZmZXJlbnQgb2JzZXJ2YXRpb24gdGhhbiAiVGhlIHZhbHVlcyBvZiBmaWVsZCBYIG92ZXIgdGlt ZSBhcmUgZ292ZXJuZWQgYnkgZnVuY3Rpb24gRiIsIGFuZCBJJ20gbm90IHN1cmUgdGhhdCBpbnR1 aXRpb24gaW4gdGhlIHNpbXBsZXIgY2FzZSBhcHBsaWVzIGRpcmVjdGx5IHRvIHRoZSBtb3JlIGNv bXBsaWNhdGVkIG9uZS4NCg0KU3BlY2lmaWNhbGx5LCBmb3IgcGFja2V0IG51bWJlciBlbmNyeXB0 aW9uLCB0aGUgYXNzdW1wdGlvbiBhcHBlYXJzIHRvIGJlIHRoYXQgaW4tbmV0d29yayBkZXZpY2Vz IHdpbGwgZGVwbG95IGR1cmluZyB0aGUgb3BlcmF0aW9uYWwgbGlmZXRpbWUgb2YgUVVJQyB2MSB0 aGF0IHdpbGwgbWFrZSB1c2Ugb2YgdGhlIG9ic2VydmF0aW9uIHRoYXQgcGFja2V0IG51bWJlcnMg bW9ub3RvbmljYWxseSBpbmNyZWFzZSwgaW4gYSB3YXkgdGhhdCB3aWxsIGltcGFpciB0aGUgZGVw bG95bWVudCBvZiBRVUlDIHZOID4gMSB0aGF0IGRvZXMgbm90IGhhdmUgcGFja2V0IG51bWJlcnMg dGhhdCBtb25vdG9uaWNhbGx5IGluY3JlYXNlLCBvciBwYWNrZXQgbnVtYmVycyB0aGF0IGFwcGVh ciBhdCBhIGRpZmZlcmVudCBsb2NhdGlvbiBpbiB0aGUgaGVhZGVyLiBJbiBvdGhlciB3b3Jkcywg dGhlc2UgZGV2aWNlcyB3aWxsIGZhaWwgb24gdGhpcyBuZXcgdmVyc2lvbiBvZiBRVUlDIGluIHN1 Y2ggYSB3YXkgdGhhdCBpdCB3aWxsIGltcGFpciBzZXJ2aWNlIHRvIGVuZHBvaW50cyB1c2luZyBR VUlDIHZOLg0KDQpBbmFsb2dpZXMgdG8gdGhlIFRDUCBzZXF1ZW5jZSBudW1iZXIgaGVyZSBhcmUg YSBiaXQgZmxhd2VkLiBUaGUgbW9zdCBpbXBvcnRhbnQgZGlmZmVyZW5jZSBpcyB0aGF0IHRoZSBv cGVuIG5hdHVyZSBvZiBUQ1AncyB3aXJlIGltYWdlIG1lYW5zIHRoYXQgdXNhZ2Ugb2YgdGhlIHNl cXVlbmNlIG51bWJlciBpc24ndCBsaW1pdGVkIHRvIG9ic2VydmF0aW9uOiBvbi1wYXRoIGRldmlj ZXMgY2FuIGNoYW5nZSBpdCwgYW5kIGZvcmdlIG9yIGRlbGF5IEFDS3MgYmFzZWQgb24gaXQuIFRo ZSBvbmx5IHRoaW5nIGFuIG9uLXBhdGggZGV2aWNlIGNhbiBkbyB3aXRoIGEgUVVJQyBwYWNrZXQg d2l0aCBhIHBhY2tldCBudW1iZXIgaXQgZG9lc24ndCBsaWtlIGlzIHRvIGRyb3AgaXQuIFRoaXMg ZnVuY3Rpb24gbWlnaHQgaGF2ZSBzb21lIHV0aWxpdHkgYXMgcGFydCBvZiBhbiBpbi1uZXR3b3Jr IFFVSUMgZ2FyYmFnZSBmaWx0ZXIsIGFzIHBhcnQgb2YgYW4gYW50aS1ERG9TIHN5c3RlbSwgYnV0 IGFueSBzdWNoIGRldmljZSB3b3VsZCBuZWVkIHRvIHRyYWNrIHRoZSB2ZXJzaW9uIG51bWJlciBh cyB3ZWxsIChpbmRlZWQsIHRyYWNraW5nIHZlcnNpb24gbmVnb3RpYXRpb24gYW5kIGhhbmRzaGFr aW5nIHdvdWxkIGJlIGEgdXNlZnVsIHByaW1pdGl2ZSBoZXJlIGluIGl0cyBvd24gcmlnaHQpLCBh bmQgd291bGQgdGhlcmVmb3JlIGhhdmUgZW5vdWdoIGluZm9ybWF0aW9uIHRvIG5vdCBicmVhayBv biBuZXcgdmVyc2lvbnMgaXQga25vd3MgYWJvdXQuDQoNCihOb3RlIHdlIHNwZWNpZmljYWxseSBk b24ndCBjYXJlIGFib3V0IHRoZSBjYXNlIHdoZXJlIGRldmljZXMgbWFraW5nIHVzZSBvZiB0aGlz IG9ic2VydmF0aW9uIHN0b3Agd29ya2luZyBpbiBhIHdheSB0aGF0IHRoZSBlbmQtdG8tZW5kIHBy b3BlcnRpZXMgb2YgUVVJQyB2TiBhcmUgcHJlc2VydmVkOiB0aGUgaW52YXJpYW50cyBhcyBvZiBh IGdpdmVuIHZlcnNpb24gYXJlIHRoZSBwdWJsaWMgd2lyZS1pbWFnZSBpbnRlcmZhY2UgdG8gdGhl IHByb3RvY29sLCBhbnl0aGluZyBlbHNlIGlzIGF0LXlvdXItb3duLXJpc2ssIG5vLXVzZXItc2Vy dmljYWJsZS1wYXJ0cy1pbnNpZGUpLg0KDQpJIHN1c3BlY3QgdGhhdCBzaW1pbGFyIGFyZ3VtZW50 cyBjYW4gYmUgaGFkIGFib3V0IGFsbCBidXQgdGhlIHNpbXBsZXN0IHByb3Bvc2VkIGFwcGxpY2F0 aW9ucyBvZiBncmVhc2luZyB0byBmdW5jdGlvbnMgbW9yZSBjb21wbGV4IHRoYW4gInRoZSB2YWx1 ZSBvZiBmaWVsZCBYIGlzIGFsd2F5cyBZIG9yIFoiLiBUaGUgZXhhbXBsZSBvZiBwYWNrZXQgbnVt YmVyIHRyYWNraW5nIHBvaW50cyB0byBhbiBhbnRpLW9zc2lmaWNhdGlvbiBhcHByb2FjaCB0aGF0 IEkgaGF2ZSBtdWNoIG1vcmUgY29uZmlkZW5jZSBpbiwgdGhvdWdoOg0KDQpUaGUgdmlnb3JvdXMg YW5kIG1lYW5pbmdmdWwgZXhlcmNpc2Ugb2YgdGhlIHZlcnNpb24gbmVnb3RpYXRpb24gYW5kIHZl cnNpb24gY29leGlzdGVuY2Ugc3lzdGVtcyBidWlsdCBpbnRvIFFVSUMgd291bGQgZm9yY2UgYWdp bGl0eSBvbiBvbi1wYXRoIGRldmljZXMuIFRoZSBlYXJsaWVyIHdlIGRvIHRoaXMsIHRoZSBtb3Jl IGVmZmVjdGl2ZSBpdCB3b3VsZCBiZS4gSSd2ZSBhbHJlYWR5IHNhaWQgdGhpcyBpbiBvdGhlciBj b250ZXh0cywgYnV0IEknbGwgZXhwbGljaXRseSBzdWdnZXN0IGl0IGhlcmU6IGxldCdzIGRvIFFV SUMgMiwgYW5kIHNvb24gKHNheSwgSnVseSAyMDE5PyksIGFuZCB1c2UgdmVyc2lvbiBuZWdvdGlh dGlvbiAqaXRzZWxmKiBhcyBhIG1ldGhvZCB0byAiZ3JlYXNlIiB0aGUgdmVyc2lvbiBuZWdvdGlh dGlvbiBtZWNoYW5pc20gYWxvbmcgd2l0aCB0aGUgcmVzdCBvZiB0aGUgaGVhZGVyLg0KDQo+IFdl IGN1cnJlbnRseSBoYXZlIHBhY2tldCBudW1iZXIgZ2FwcyB0byBiZSB1c2VkIHdpdGggbmV3IENJ RHMsIGJ1dCB0aGVzZSBhcmUgdGhlIHNhbWUgcGFja2V0IG51bWJlcnMgb24gdGhlIHdpcmUgYXMg d2l0aGluIHRoZSB0cmFuc3BvcnQuIFNvLCB3aGVuIHVzZWQgd2l0aCBjb25uZWN0aW9uIG1pZ3Jh dGlvbiBvciBhZnRlciBxdWllc2NlbmNlLCB0aGUgc2VuZGVyIGFuZCByZWNlaXZlciBvZiBBQ0tz IGhhcyB0byBkZWFsIHdpdGggcG90ZW50aWFsbHkgbGFyZ2UgZ2Fwcy4uLiB0aGlzIGlzIGVuY29k YWJsZSBvbiB0aGUgd2lyZSwgc3VyZSwgYnV0IHRoZXNlIGdhcHMgYXJlIHVubmVjZXNzYXJ5IHdp dGhpbiB0aGUgdHJhbnNwb3J0Lg0KPg0KPiBFbmNyeXB0aW5nIHBhY2tldCBudW1iZXJzIHJlZHVj ZXMgY29tcGxleGl0eSBpbiB0aGF0IHlvdSBnZXQgYSBwYWNrZXQgbnVtYmVyIGdhcCBvbiB0aGUg d2lyZSB3aXRob3V0IGhhdmluZyB0byBleHBsaWNpdGx5IG1vZGVsIGl0IGluc2lkZSB0aGUgdHJh bnNwb3J0LiBUaGUgdHJhbnNwb3J0IG1hY2hpbmVyeSBzdGFydHMgcGFja2V0IG51bWJlcnMgYXQg MCwgaW5jcmVtZW50cyBpdCBieSAxIGlycmVzcGVjdGl2ZSBvZiBtaWdyYXRpb24gb3IgcXVpZXNj ZW5jZSwgYW5kIHRoZSBBQ0sgZnJhbWVzIHNpbWlsYXJseSBjYXJyeSB0aGUgcGxhaW50ZXh0IHBh Y2tldCBudW1iZXIuIFNlcGFyYXRpbmcgd2hhdCdzIHVzZWQgd2l0aGluIHRoZSB0cmFuc3BvcnQg YW5kIHdoYXQncyB2aXNpYmxlIG9uIHRoZSB3aXJlIGFsbG93cyB5b3UgdG8gZG8gdGhpbmdzIGxp a2UgdXNlIG11bHRpcGxlIENJRHMgd2l0aGluIHRoZSBzYW1lIDUtdHVwbGUuDQoNClRoaXMgaXMg YSBtb3JlIGNvbnZpbmNpbmcgYXJndW1lbnQgZm9yIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbiAt LSBpdCBkb2VzIHNlZW0gaGFyZCB0byBnZXQgdGhpcyBlbGVnYW5jZSBpbiB0aGUgdHJhbnNwb3J0 IHdoaWxlIGhhdmluZyBhIG5vbi10cml2aWFsbHktbGlua2FibGUgd2lyZSBpbWFnZSB3aXRob3V0 IGl0Lg0KDQo+IEkgc2VlIGl0IGFzIGEgY2xlYW4gc2VwYXJhdGlvbiBvZiBjb25jZXJucywgd2l0 aCBjb25zZXF1ZW50IHNpbXBsaWZpY2F0aW9uIGluIGltcGxlbWVudGF0aW9uIGFuZCBhbiBhZGRp dGlvbmFsIGRlZ3JlZSBvZiBmcmVlZG9tLg0KPg0KPiBJJ20gbm90IGNvbnZpbmNlZCBvZiB0aGUg dmFsdWUgb2YgcGFja2V0IG51bWJlciBpbiBtZWFzdXJpbmcgcmVvcmRlcmluZyBkZWdyZWUsIHNp bmNlIHRoaXMgY2FuIGJlIHRyaXZpYWxseSBkb25lIGJ5IGxvb2tpbmcgYXQgdGhlIElQIElEIGZp ZWxkIGZvciBwYWNrZXRzIG9uIHRoZSBzYW1lIDUtdHVwbGUuDQoNCkZvciBJUHY0IHBhY2tldHMs IG9uIGltcGxlbWVudGF0aW9ucyB3aGVyZSBJUElEIGlzIG5vdCByYW5kb21pemVkLCB5ZXMuIEkg ZG9uJ3QgaGF2ZSBudW1iZXJzIG9uIGhvdyBwcmV2YWxlbnQgdGhlc2UgYXJlOyBpbiBhbnkgY2Fz ZSwgd2hlcmUgaXQgaXNuJ3QgcmFuZG9taXplZCwgdGhhdCdzIGFyZ3VhYmx5IGEgYnVnIHRoYXQg c2hvdWxkIGJlIGZpeGVkLiBTaG91bGQgdGhlIGd1aWRhbmNlIGluIHRoZSBtYW5hZ2VhYmlsaXR5 IGRyYWZ0LCB0aGVuLCBiZSAidXNlIElQdjQgaWYgeW91IGNhcmUgYWJvdXQgbG9zcyBhbmQgcmVv cmRlcmluZyBkZXRlY3Rpb24iPyBJIGFtIG5vdCBvcHRpbWlzdGljIGFib3V0IHRoZSBjaGFuY2Vz IG9mIHRoYXQgZ2V0dGluZyBwYXN0IHRoZSBJRVNHLiA7KQ0KDQpDaGVlcnMsDQoNCkJyaWFuDQoN Cj4gT24gV2VkLCBKYW4gMzEsIDIwMTggYXQgNjowMCBQTSwgTWFydGluIFRob21zb24gPG1hcnRp bi50aG9tc29uQGdtYWlsLmNvbT4gd3JvdGU6DQo+IFdpdGggc29tZSBsaWdodCBlZGl0aW5nIGZv ciBxdW90aW5nIHB1cnBvc2VzLi4uDQo+DQo+IE9uIFRodSwgRmViIDEsIDIwMTggYXQgMTI6MDIg UE0sIFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPiB3cm90ZToNCj4gPj4gT3IgZG8geW91IG1l YW4gQ0lEcyAxLTMgbWF5IGJlIHVzZWQgb24gYW55IG9mIHRoZSA1LXR1cGxlcyBBLUMsIGZvciB0 aGUgc2FtZQ0KPiA+PiBjb21tdW5pY2F0aW5nIHBlZXJzICBBbGljZSdzUGhvbmUgYW5kIEJvYidz QmFua1NlcnZlcjkzPw0KPiA+DQo+ID4gVGhlIGxhdHRlciBhc3N1bWluZyB3ZSBhbGxvdyB0aGUg c2VydmVyIHRvIHNwZWNpZnkgaXQuDQo+DQo+IEkgZmluZCAiYXNzdW1pbmcgd2UgYWxsb3cgdGhl IHNlcnZlciB0byBzcGVjaWZ5ICppdCoiIHRvIGJlIHN0cmFuZ2VseSBjcnlwdGljLg0KPg0KPiBU byBiZSBjbGVhciwgbXkgb3BlcmF0aW5nIGFzc3VtcHRpb24gaXMgd2hpbGUgdGhhdCBzZXJ2ZXJz IGNhbiBwcm92aWRlDQo+IG11bHRpcGxlIGNvbm5lY3Rpb24gSURzLCB0aG9zZSBjb25uZWN0aW9u IElEcyBuZWVkIHRvIGJlIHVzYWJsZSBvbiBhbnkNCj4gNS10dXBsZS4gIEFyZSB5b3Ugc3VnZ2Vz dGluZyB0aGF0IGEgc2VydmVyIG1pZ2h0IG5lZWQgdG8gc2lnbmFsIHdoZXJlDQo+IGEgY29ubmVj dGlvbiBpcyB1c2FibGU/ICAoSSBjYW4gc2VlIGhvdyB0aGF0IG1pZ2h0IG1ha2Ugc2Vuc2UsIGJ1 dCBpdA0KPiBpc24ndCBwb3NzaWJsZSB3aXRoIHRoZSBwcm90b2NvbCBhcyBzcGVjaWZpZWQuKSAg T3IgYXJlIHlvdSBzdWdnZXN0aW5nDQo+IHRoYXQgdGhlcmUgbWlnaHQgbmVlZCB0byBiZSBzb21l IHNpZ25hbCB0aGF0IGFsbG93cyBjbGllbnRzIHRvDQo+IGRpc3Rpbmd1aXNoIGJldHdlZW4gY29u bmVjdGlvbiBJRHMgdGhhdCBhcmUgZm9yIGNvbmN1cnJlbnQgdXNlPyBUaGF0DQo+IGlzLCBhcyBv cHBvc2VkIHRvIHdoYXQgeW91IG1pZ2h0IGFzc3VtZSB0byBiZSBzZXF1ZW50aWFsIHVzZSBiYXNl ZCBvbg0KPiB0aGUgY3VycmVudCBzcGVjaWZpY2F0aW9uLg0KPg0KPiBGV0lXLCBpdCBzaG91bGQg YmUgcG9zc2libGUgdG8gcmVtb3ZlIHRoZSBzZXF1ZW5jaW5nIGZpZWxkIGZyb20NCj4gTkVXX0NP Tk5FQ1RJT05fSUQgYWZ0ZXIgbWFraW5nIHRoaXMgY2hhbmdlLiAgVGhlIG9ubHkgcmVhc29uIGxl ZnQgZm9yDQo+IHNlcXVlbnRpYWwgY29ubmVjdGlvbiBJRCB1c2UgaXMgdG8gZ2l2ZSB0aGUgc2Vy dmVyIHRoZSBhYmlsaXR5IHRvIGtub3cNCj4gd2hlbiBjZXJ0YWluIGNvbm5lY3Rpb24gSURzIG5v IGxvbmdlciBuZWVkIHRvIGJlIGF2YWlsYWJsZS4gIEEgc2VydmVyDQo+IG1pZ2h0IHRoZW4gYmUg YWJsZSB0byBjbGVhbiB1cCBhc3NvY2lhdGVkIHN0YXRlIGFuZCBldmVuIHJldXNlIHRoZW0uDQo+ DQo+IE9mIGNvdXJzZSwgdGhhdCBsaWtlbHkgb25seSBtYWtlcyBzZW5zZSBpZiB0aGUgc2VydmVy IGlzIGNyZWF0aW5nDQo+IGV4cGxpY2l0IG1hcHBpbmdzIGZvciBlYWNoLCB3aGljaCAtIGFzIGRp c2N1c3NlZCBhdCB0aGUgaW50ZXJpbSAtDQo+IGlzbid0IHN1cGVyIHByYWN0aWNhbCBpbiBtYW55 IGRlcGxveW1lbnRzLiAgUmlnaHQgbm93LCBJIHRoaW5rIHRoYXQNCj4gdGhlIGFzc3VtcHRpb24g aXMgYW4gYXNzdW1wdGlvbiBvbmx5LCBhbmQgdGhhdCByZWx5aW5nIG9uIHN0cmljdGx5DQo+IGxp bmVhciB1c2Ugb2YgY29ubmVjdGlvbiBJRHMgd291bGQgYmUgdW53aXNlLg0KPg0KPg0KDQo= --_000_BY2PR15MB07756D4F528DE909A5B0057FCDFA0BY2PR15MB0775namp_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdj5Ob3RlIHRo YXQgdGhlIHNpemUgb2YgdGhlIENJRCBpcyBhbHNvIG5vdCBrbm93biB0byB0aGUgbmV0d29yayBh c3N1bWluZyB3ZSBhcmUgZW5jcnlwdGluZyBhbmQgZG9pbmcgdmFyaWFibGUsIGltcGxpY2l0IGxl bmd0aCBDSUQgZm9yIHNob3J0IGhlYWRlcnMgKHdoaWNoIGlzIHdoYXQgSSB1bmRlcnN0YW5kIHRv IGJlIHRoZSBwcm9wb3NhbCkgY2hvc2VuIGJ5IHRoZSBzZXJ2ZXIuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaGUgbDcgbWF5IGVuY29kZSB0aGUgbGVuZ3RoIHdpdGhpbiB0aGUgQ0lE LCB3aGljaCBvbmUgY291bGQgaW1hZ2luZSBtaWdodCBiZSBjb21tb24sIGhvd2V2ZXIgdGhlIG5l dHdvcmsgd291bGQgaGF2ZSBhIGhpZ2hlciBiYXIgdG8gZGV0ZXJtaW5pbmcgaXQuJm5ic3A7PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Vbmxlc3Mgd2UgcHJldmVudCBpdCwgYXNzdW1p bmcgdGhlIHNlcnZlciBjYW4gY2F1c2UgdGhlIGNsaWVudCB0byB1c2UgbXVsdGlwbGUgQ0lEcywg dGhlIGxlbmd0aCBvZiB0aGUgQ0lEIGNvdWxkIHZhcnkgZXZlbiB3aXRoaW4gdGhlIHBhY2tldHMg b24gYSBzaW5nbGUgZmxvdy81LXR1cGxlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ LT1SPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdiBpZD0iY29tcG9zZXJfc2lnbmF0dXJl Ij4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo4NSU7Y29sb3I6IzU3NTc1NyIgZGlyPSJhdXRvIj5T ZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgUzcsIGFuIEFUJmFtcDtUIDRHIExURSBzbWFydHBo b25lPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJmb250LXNp emU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT4NCjxkaXY+LS0t LS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2Pg0KPGRpdj5Gcm9tOiAmcXVvdDtC cmlhbiBUcmFtbWVsbCAoSUVURikmcXVvdDsgJmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7IDwvZGl2 Pg0KPGRpdj5EYXRlOiAyLzEvMTggMTI6MDggQU0gKEdNVC0wODowMCkgPC9kaXY+DQo8ZGl2PlRv OiBKYW5hIEl5ZW5nYXIgJmx0O2pyaUBnb29nbGUuY29tJmd0OyA8L2Rpdj4NCjxkaXY+Q2M6IE1h cnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7LCBSb2JlcnRvIFBl b24gJmx0O2Zlbml4QGZiLmNvbSZndDssIFRlZCBIYXJkaWUgJmx0O3RlZC5pZXRmQGdtYWlsLmNv bSZndDssIEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDssIE1pcmphIEvDvGhsZXdp bmQgJmx0O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7LCBDaHJpc3RpYW4gSHVp dGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDssIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5v cmcmZ3Q7DQo8L2Rpdj4NCjxkaXY+U3ViamVjdDogUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlv biA8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCmhpIEphbmEsIGFsbCw8YnI+DQo8 YnI+DQomZ3Q7IE9uIDEgRmViIDIwMTgsIGF0IDAzOjQ2LCBKYW5hIEl5ZW5nYXIgJmx0O2pyaUBn b29nbGUuY29tJmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBsaWtlIHRoaXMgcHJv cG9zYWwgZm9yIHRoZSBvc3NpZmljYXRpb24gcmVhc29uIHRoYXQgUm9iZXJ0byBkZXNjcmliZWQs IGJ1dCBJIGFsc28gbGlrZSBpdCBiZWNhdXNlIGl0IHJlYWxseSBzaW1wbGlmaWVzIHRoaW5ncyBm cm9tIGFuIGltcGxlbWVudGF0aW9uIHBlcnNwZWN0aXZlLjxicj4NCjxicj4NClRoZXJlIHNlZW1z IHRvIGJlIGEgbGFyZ2VseSB1bnF1ZXN0aW9uZWQgYXNzdW1wdGlvbiB0aGF0IHBhY2tldCBudW1i ZXIgZW5jcnlwdGlvbiBoYXMgdXRpbGl0eSBmb3Igb3NzaWZpY2F0aW9uIHByZXZlbnRpb24uIEkg YW0gbm90IGNvbnZpbmNlZCBvZiB0aGlzLjxicj4NCjxicj4NCk91ciBleHBlcmllbmNlIHdpdGgg VExTIGdyZWFzaW5nIHNob3dzIHRoYXQgcGxhY2luZyByYW5kb20gdmFsdWVzIGluIGZpZWxkcyB0 aGF0IHdvdWxkIG90aGVyd2lzZSBsYXJnZWx5IGJlIHN0YXRpYyBvdmVyIHRoZSBsaWZldGltZSBv ZiB0aGUgcHJvdG9jb2wgaW1wcm92ZXMgdGhlIGFiaWxpdHkgdG8gdXNlIHRob3NlIGZpZWxkcyBs YXRlci4gUGFja2V0IG51bWJlciBlbmNyeXB0aW9uIGlzIGdyZWFzaW5nIG9ubHkgYnkgYW5hbG9n eS4gJnF1b3Q7RmllbGQNCiBYIGhhcyB2YWx1ZSBZJnF1b3Q7IGlzIGEgZnVuZGFtZW50YWxseSBk aWZmZXJlbnQgb2JzZXJ2YXRpb24gdGhhbiAmcXVvdDtUaGUgdmFsdWVzIG9mIGZpZWxkIFggb3Zl ciB0aW1lIGFyZSBnb3Zlcm5lZCBieSBmdW5jdGlvbiBGJnF1b3Q7LCBhbmQgSSdtIG5vdCBzdXJl IHRoYXQgaW50dWl0aW9uIGluIHRoZSBzaW1wbGVyIGNhc2UgYXBwbGllcyBkaXJlY3RseSB0byB0 aGUgbW9yZSBjb21wbGljYXRlZCBvbmUuPGJyPg0KPGJyPg0KU3BlY2lmaWNhbGx5LCBmb3IgcGFj a2V0IG51bWJlciBlbmNyeXB0aW9uLCB0aGUgYXNzdW1wdGlvbiBhcHBlYXJzIHRvIGJlIHRoYXQg aW4tbmV0d29yayBkZXZpY2VzIHdpbGwgZGVwbG95IGR1cmluZyB0aGUgb3BlcmF0aW9uYWwgbGlm ZXRpbWUgb2YgUVVJQyB2MSB0aGF0IHdpbGwgbWFrZSB1c2Ugb2YgdGhlIG9ic2VydmF0aW9uIHRo YXQgcGFja2V0IG51bWJlcnMgbW9ub3RvbmljYWxseSBpbmNyZWFzZSwgaW4gYSB3YXkgdGhhdCB3 aWxsIGltcGFpcg0KIHRoZSBkZXBsb3ltZW50IG9mIFFVSUMgdk4gJmd0OyAxIHRoYXQgZG9lcyBu b3QgaGF2ZSBwYWNrZXQgbnVtYmVycyB0aGF0IG1vbm90b25pY2FsbHkgaW5jcmVhc2UsIG9yIHBh Y2tldCBudW1iZXJzIHRoYXQgYXBwZWFyIGF0IGEgZGlmZmVyZW50IGxvY2F0aW9uIGluIHRoZSBo ZWFkZXIuIEluIG90aGVyIHdvcmRzLCB0aGVzZSBkZXZpY2VzIHdpbGwgZmFpbCBvbiB0aGlzIG5l dyB2ZXJzaW9uIG9mIFFVSUMgaW4gc3VjaCBhIHdheSB0aGF0IGl0IHdpbGwNCiBpbXBhaXIgc2Vy dmljZSB0byBlbmRwb2ludHMgdXNpbmcgUVVJQyB2Ti48YnI+DQo8YnI+DQpBbmFsb2dpZXMgdG8g dGhlIFRDUCBzZXF1ZW5jZSBudW1iZXIgaGVyZSBhcmUgYSBiaXQgZmxhd2VkLiBUaGUgbW9zdCBp bXBvcnRhbnQgZGlmZmVyZW5jZSBpcyB0aGF0IHRoZSBvcGVuIG5hdHVyZSBvZiBUQ1AncyB3aXJl IGltYWdlIG1lYW5zIHRoYXQgdXNhZ2Ugb2YgdGhlIHNlcXVlbmNlIG51bWJlciBpc24ndCBsaW1p dGVkIHRvIG9ic2VydmF0aW9uOiBvbi1wYXRoIGRldmljZXMgY2FuIGNoYW5nZSBpdCwgYW5kIGZv cmdlIG9yIGRlbGF5IEFDS3MNCiBiYXNlZCBvbiBpdC4gVGhlIG9ubHkgdGhpbmcgYW4gb24tcGF0 aCBkZXZpY2UgY2FuIGRvIHdpdGggYSBRVUlDIHBhY2tldCB3aXRoIGEgcGFja2V0IG51bWJlciBp dCBkb2Vzbid0IGxpa2UgaXMgdG8gZHJvcCBpdC4gVGhpcyBmdW5jdGlvbiBtaWdodCBoYXZlIHNv bWUgdXRpbGl0eSBhcyBwYXJ0IG9mIGFuIGluLW5ldHdvcmsgUVVJQyBnYXJiYWdlIGZpbHRlciwg YXMgcGFydCBvZiBhbiBhbnRpLUREb1Mgc3lzdGVtLCBidXQgYW55IHN1Y2ggZGV2aWNlDQogd291 bGQgbmVlZCB0byB0cmFjayB0aGUgdmVyc2lvbiBudW1iZXIgYXMgd2VsbCAoaW5kZWVkLCB0cmFj a2luZyB2ZXJzaW9uIG5lZ290aWF0aW9uIGFuZCBoYW5kc2hha2luZyB3b3VsZCBiZSBhIHVzZWZ1 bCBwcmltaXRpdmUgaGVyZSBpbiBpdHMgb3duIHJpZ2h0KSwgYW5kIHdvdWxkIHRoZXJlZm9yZSBo YXZlIGVub3VnaCBpbmZvcm1hdGlvbiB0byBub3QgYnJlYWsgb24gbmV3IHZlcnNpb25zIGl0IGtu b3dzIGFib3V0Ljxicj4NCjxicj4NCihOb3RlIHdlIHNwZWNpZmljYWxseSBkb24ndCBjYXJlIGFi b3V0IHRoZSBjYXNlIHdoZXJlIGRldmljZXMgbWFraW5nIHVzZSBvZiB0aGlzIG9ic2VydmF0aW9u IHN0b3Agd29ya2luZyBpbiBhIHdheSB0aGF0IHRoZSBlbmQtdG8tZW5kIHByb3BlcnRpZXMgb2Yg UVVJQyB2TiBhcmUgcHJlc2VydmVkOiB0aGUgaW52YXJpYW50cyBhcyBvZiBhIGdpdmVuIHZlcnNp b24gYXJlIHRoZSBwdWJsaWMgd2lyZS1pbWFnZSBpbnRlcmZhY2UgdG8gdGhlIHByb3RvY29sLA0K IGFueXRoaW5nIGVsc2UgaXMgYXQteW91ci1vd24tcmlzaywgbm8tdXNlci1zZXJ2aWNhYmxlLXBh cnRzLWluc2lkZSkuPGJyPg0KPGJyPg0KSSBzdXNwZWN0IHRoYXQgc2ltaWxhciBhcmd1bWVudHMg Y2FuIGJlIGhhZCBhYm91dCBhbGwgYnV0IHRoZSBzaW1wbGVzdCBwcm9wb3NlZCBhcHBsaWNhdGlv bnMgb2YgZ3JlYXNpbmcgdG8gZnVuY3Rpb25zIG1vcmUgY29tcGxleCB0aGFuICZxdW90O3RoZSB2 YWx1ZSBvZiBmaWVsZCBYIGlzIGFsd2F5cyBZIG9yIFomcXVvdDsuIFRoZSBleGFtcGxlIG9mIHBh Y2tldCBudW1iZXIgdHJhY2tpbmcgcG9pbnRzIHRvIGFuIGFudGktb3NzaWZpY2F0aW9uIGFwcHJv YWNoIHRoYXQNCiBJIGhhdmUgbXVjaCBtb3JlIGNvbmZpZGVuY2UgaW4sIHRob3VnaDo8YnI+DQo8 YnI+DQpUaGUgdmlnb3JvdXMgYW5kIG1lYW5pbmdmdWwgZXhlcmNpc2Ugb2YgdGhlIHZlcnNpb24g bmVnb3RpYXRpb24gYW5kIHZlcnNpb24gY29leGlzdGVuY2Ugc3lzdGVtcyBidWlsdCBpbnRvIFFV SUMgd291bGQgZm9yY2UgYWdpbGl0eSBvbiBvbi1wYXRoIGRldmljZXMuIFRoZSBlYXJsaWVyIHdl IGRvIHRoaXMsIHRoZSBtb3JlIGVmZmVjdGl2ZSBpdCB3b3VsZCBiZS4gSSd2ZSBhbHJlYWR5IHNh aWQgdGhpcyBpbiBvdGhlciBjb250ZXh0cywgYnV0IEknbGwNCiBleHBsaWNpdGx5IHN1Z2dlc3Qg aXQgaGVyZTogbGV0J3MgZG8gUVVJQyAyLCBhbmQgc29vbiAoc2F5LCBKdWx5IDIwMTk/KSwgYW5k IHVzZSB2ZXJzaW9uIG5lZ290aWF0aW9uICppdHNlbGYqIGFzIGEgbWV0aG9kIHRvICZxdW90O2dy ZWFzZSZxdW90OyB0aGUgdmVyc2lvbiBuZWdvdGlhdGlvbiBtZWNoYW5pc20gYWxvbmcgd2l0aCB0 aGUgcmVzdCBvZiB0aGUgaGVhZGVyLjxicj4NCjxicj4NCiZndDsgV2UgY3VycmVudGx5IGhhdmUg cGFja2V0IG51bWJlciBnYXBzIHRvIGJlIHVzZWQgd2l0aCBuZXcgQ0lEcywgYnV0IHRoZXNlIGFy ZSB0aGUgc2FtZSBwYWNrZXQgbnVtYmVycyBvbiB0aGUgd2lyZSBhcyB3aXRoaW4gdGhlIHRyYW5z cG9ydC4gU28sIHdoZW4gdXNlZCB3aXRoIGNvbm5lY3Rpb24gbWlncmF0aW9uIG9yIGFmdGVyIHF1 aWVzY2VuY2UsIHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyIG9mIEFDS3MgaGFzIHRvIGRlYWwgd2l0 aCBwb3RlbnRpYWxseQ0KIGxhcmdlIGdhcHMuLi4gdGhpcyBpcyBlbmNvZGFibGUgb24gdGhlIHdp cmUsIHN1cmUsIGJ1dCB0aGVzZSBnYXBzIGFyZSB1bm5lY2Vzc2FyeSB3aXRoaW4gdGhlIHRyYW5z cG9ydC48YnI+DQomZ3Q7IDxicj4NCiZndDsgRW5jcnlwdGluZyBwYWNrZXQgbnVtYmVycyByZWR1 Y2VzIGNvbXBsZXhpdHkgaW4gdGhhdCB5b3UgZ2V0IGEgcGFja2V0IG51bWJlciBnYXAgb24gdGhl IHdpcmUgd2l0aG91dCBoYXZpbmcgdG8gZXhwbGljaXRseSBtb2RlbCBpdCBpbnNpZGUgdGhlIHRy YW5zcG9ydC4gVGhlIHRyYW5zcG9ydCBtYWNoaW5lcnkgc3RhcnRzIHBhY2tldCBudW1iZXJzIGF0 IDAsIGluY3JlbWVudHMgaXQgYnkgMSBpcnJlc3BlY3RpdmUgb2YgbWlncmF0aW9uIG9yIHF1aWVz Y2VuY2UsDQogYW5kIHRoZSBBQ0sgZnJhbWVzIHNpbWlsYXJseSBjYXJyeSB0aGUgcGxhaW50ZXh0 IHBhY2tldCBudW1iZXIuIFNlcGFyYXRpbmcgd2hhdCdzIHVzZWQgd2l0aGluIHRoZSB0cmFuc3Bv cnQgYW5kIHdoYXQncyB2aXNpYmxlIG9uIHRoZSB3aXJlIGFsbG93cyB5b3UgdG8gZG8gdGhpbmdz IGxpa2UgdXNlIG11bHRpcGxlIENJRHMgd2l0aGluIHRoZSBzYW1lIDUtdHVwbGUuPGJyPg0KPGJy Pg0KVGhpcyBpcyBhIG1vcmUgY29udmluY2luZyBhcmd1bWVudCBmb3IgcGFja2V0IG51bWJlciBl bmNyeXB0aW9uIC0tIGl0IGRvZXMgc2VlbSBoYXJkIHRvIGdldCB0aGlzIGVsZWdhbmNlIGluIHRo ZSB0cmFuc3BvcnQgd2hpbGUgaGF2aW5nIGEgbm9uLXRyaXZpYWxseS1saW5rYWJsZSB3aXJlIGlt YWdlIHdpdGhvdXQgaXQuPGJyPg0KPGJyPg0KJmd0OyBJIHNlZSBpdCBhcyBhIGNsZWFuIHNlcGFy YXRpb24gb2YgY29uY2VybnMsIHdpdGggY29uc2VxdWVudCBzaW1wbGlmaWNhdGlvbiBpbiBpbXBs ZW1lbnRhdGlvbiBhbmQgYW4gYWRkaXRpb25hbCBkZWdyZWUgb2YgZnJlZWRvbS48YnI+DQomZ3Q7 IDxicj4NCiZndDsgSSdtIG5vdCBjb252aW5jZWQgb2YgdGhlIHZhbHVlIG9mIHBhY2tldCBudW1i ZXIgaW4gbWVhc3VyaW5nIHJlb3JkZXJpbmcgZGVncmVlLCBzaW5jZSB0aGlzIGNhbiBiZSB0cml2 aWFsbHkgZG9uZSBieSBsb29raW5nIGF0IHRoZSBJUCBJRCBmaWVsZCBmb3IgcGFja2V0cyBvbiB0 aGUgc2FtZSA1LXR1cGxlLjxicj4NCjxicj4NCkZvciBJUHY0IHBhY2tldHMsIG9uIGltcGxlbWVu dGF0aW9ucyB3aGVyZSBJUElEIGlzIG5vdCByYW5kb21pemVkLCB5ZXMuIEkgZG9uJ3QgaGF2ZSBu dW1iZXJzIG9uIGhvdyBwcmV2YWxlbnQgdGhlc2UgYXJlOyBpbiBhbnkgY2FzZSwgd2hlcmUgaXQg aXNuJ3QgcmFuZG9taXplZCwgdGhhdCdzIGFyZ3VhYmx5IGEgYnVnIHRoYXQgc2hvdWxkIGJlIGZp eGVkLiBTaG91bGQgdGhlIGd1aWRhbmNlIGluIHRoZSBtYW5hZ2VhYmlsaXR5IGRyYWZ0LCB0aGVu LA0KIGJlICZxdW90O3VzZSBJUHY0IGlmIHlvdSBjYXJlIGFib3V0IGxvc3MgYW5kIHJlb3JkZXJp bmcgZGV0ZWN0aW9uJnF1b3Q7PyBJIGFtIG5vdCBvcHRpbWlzdGljIGFib3V0IHRoZSBjaGFuY2Vz IG9mIHRoYXQgZ2V0dGluZyBwYXN0IHRoZSBJRVNHLiA7KTxicj4NCjxicj4NCkNoZWVycyw8YnI+ DQo8YnI+DQpCcmlhbjxicj4NCjxicj4NCiZndDsgT24gV2VkLCBKYW4gMzEsIDIwMTggYXQgNjow MCBQTSwgTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDsgd3Jv dGU6PGJyPg0KJmd0OyBXaXRoIHNvbWUgbGlnaHQgZWRpdGluZyBmb3IgcXVvdGluZyBwdXJwb3Nl cy4uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBPbiBUaHUsIEZlYiAxLCAyMDE4IGF0IDEyOjAyIFBN LCBSb2JlcnRvIFBlb24gJmx0O2Zlbml4QGZiLmNvbSZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBPciBkbyB5b3UgbWVhbiBDSURzIDEtMyBtYXkgYmUgdXNlZCBvbiBhbnkgb2YgdGhlIDUt dHVwbGVzIEEtQywgZm9yIHRoZSBzYW1lPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBjb21tdW5pY2F0aW5n IHBlZXJzJm5ic3A7IEFsaWNlJ3NQaG9uZSBhbmQgQm9iJ3NCYW5rU2VydmVyOTM/PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoZSBsYXR0ZXIgYXNzdW1pbmcgd2UgYWxsb3cgdGhlIHNl cnZlciB0byBzcGVjaWZ5IGl0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGZpbmQgJnF1b3Q7YXNz dW1pbmcgd2UgYWxsb3cgdGhlIHNlcnZlciB0byBzcGVjaWZ5ICppdComcXVvdDsgdG8gYmUgc3Ry YW5nZWx5IGNyeXB0aWMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRvIGJlIGNsZWFyLCBteSBvcGVy YXRpbmcgYXNzdW1wdGlvbiBpcyB3aGlsZSB0aGF0IHNlcnZlcnMgY2FuIHByb3ZpZGU8YnI+DQom Z3Q7IG11bHRpcGxlIGNvbm5lY3Rpb24gSURzLCB0aG9zZSBjb25uZWN0aW9uIElEcyBuZWVkIHRv IGJlIHVzYWJsZSBvbiBhbnk8YnI+DQomZ3Q7IDUtdHVwbGUuJm5ic3A7IEFyZSB5b3Ugc3VnZ2Vz dGluZyB0aGF0IGEgc2VydmVyIG1pZ2h0IG5lZWQgdG8gc2lnbmFsIHdoZXJlPGJyPg0KJmd0OyBh IGNvbm5lY3Rpb24gaXMgdXNhYmxlPyZuYnNwOyAoSSBjYW4gc2VlIGhvdyB0aGF0IG1pZ2h0IG1h a2Ugc2Vuc2UsIGJ1dCBpdDxicj4NCiZndDsgaXNuJ3QgcG9zc2libGUgd2l0aCB0aGUgcHJvdG9j b2wgYXMgc3BlY2lmaWVkLikmbmJzcDsgT3IgYXJlIHlvdSBzdWdnZXN0aW5nPGJyPg0KJmd0OyB0 aGF0IHRoZXJlIG1pZ2h0IG5lZWQgdG8gYmUgc29tZSBzaWduYWwgdGhhdCBhbGxvd3MgY2xpZW50 cyB0bzxicj4NCiZndDsgZGlzdGluZ3Vpc2ggYmV0d2VlbiBjb25uZWN0aW9uIElEcyB0aGF0IGFy ZSBmb3IgY29uY3VycmVudCB1c2U/IFRoYXQ8YnI+DQomZ3Q7IGlzLCBhcyBvcHBvc2VkIHRvIHdo YXQgeW91IG1pZ2h0IGFzc3VtZSB0byBiZSBzZXF1ZW50aWFsIHVzZSBiYXNlZCBvbjxicj4NCiZn dDsgdGhlIGN1cnJlbnQgc3BlY2lmaWNhdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgRldJVywg aXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIHJlbW92ZSB0aGUgc2VxdWVuY2luZyBmaWVsZCBmcm9t PGJyPg0KJmd0OyBORVdfQ09OTkVDVElPTl9JRCBhZnRlciBtYWtpbmcgdGhpcyBjaGFuZ2UuJm5i c3A7IFRoZSBvbmx5IHJlYXNvbiBsZWZ0IGZvcjxicj4NCiZndDsgc2VxdWVudGlhbCBjb25uZWN0 aW9uIElEIHVzZSBpcyB0byBnaXZlIHRoZSBzZXJ2ZXIgdGhlIGFiaWxpdHkgdG8ga25vdzxicj4N CiZndDsgd2hlbiBjZXJ0YWluIGNvbm5lY3Rpb24gSURzIG5vIGxvbmdlciBuZWVkIHRvIGJlIGF2 YWlsYWJsZS4mbmJzcDsgQSBzZXJ2ZXI8YnI+DQomZ3Q7IG1pZ2h0IHRoZW4gYmUgYWJsZSB0byBj bGVhbiB1cCBhc3NvY2lhdGVkIHN0YXRlIGFuZCBldmVuIHJldXNlIHRoZW0uPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IE9mIGNvdXJzZSwgdGhhdCBsaWtlbHkgb25seSBtYWtlcyBzZW5zZSBpZiB0aGUg c2VydmVyIGlzIGNyZWF0aW5nPGJyPg0KJmd0OyBleHBsaWNpdCBtYXBwaW5ncyBmb3IgZWFjaCwg d2hpY2ggLSBhcyBkaXNjdXNzZWQgYXQgdGhlIGludGVyaW0gLTxicj4NCiZndDsgaXNuJ3Qgc3Vw ZXIgcHJhY3RpY2FsIGluIG1hbnkgZGVwbG95bWVudHMuJm5ic3A7IFJpZ2h0IG5vdywgSSB0aGlu ayB0aGF0PGJyPg0KJmd0OyB0aGUgYXNzdW1wdGlvbiBpcyBhbiBhc3N1bXB0aW9uIG9ubHksIGFu ZCB0aGF0IHJlbHlpbmcgb24gc3RyaWN0bHk8YnI+DQomZ3Q7IGxpbmVhciB1c2Ugb2YgY29ubmVj dGlvbiBJRHMgd291bGQgYmUgdW53aXNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQo8YnI+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BY2PR15MB07756D4F528DE909A5B0057FCDFA0BY2PR15MB0775namp_-- From nobody Thu Feb 1 03:07:26 2018 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 C44A1129C6E for ; Thu, 1 Feb 2018 03:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.309 X-Spam-Level: X-Spam-Status: No, score=-4.309 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Txbkn8wT; dkim=pass (1024-bit key) header.d=ericsson.com header.b=VsqCJ5xH 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 r4Gir5C61YLt for ; Thu, 1 Feb 2018 03:07:23 -0800 (PST) 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 77C8C1318FB for ; Thu, 1 Feb 2018 03:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517483226; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8jhHMrSOLoaEiDQWn5LqnfP0GBn0JF7v0Psyi1Qqm2k=; b=Txbkn8wTyJQ994SKngnuJTUZmFnj8PLHwFmP7XydDB4BMSJ8kTuUAk8HpVqrSlTS 6e/0F4LzvyR7jCCZGbkMkFUCdK3I5lLDwP7knSLQGbMa3KHSwFEWlS8KfmRKxVmz CMdjkax6UWwEspS2N1KOUNAFcYXmTFpTT59Evn+B57s=; X-AuditID: c1b4fb2d-b35ff70000007932-55-5a72f4dadc50 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id E5.EA.31026.AD4F27A5; Thu, 1 Feb 2018 12:07:06 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 1 Feb 2018 12:07:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5GAp+yl5U0FzQSI5LInMaJD22jNbkEaGc1FaBLRHKTI=; b=VsqCJ5xHNVfeKs+aCtodJFRNmSLXuPOPoVCYIdCt3Jgw5ON7KUcFMjgWrqdWCz1n8N1F/gFXU5W8oax1KQe39oeqb48bAatXFQf4DYuW7HDbu7EYqDRHjEo6GqqyFl24xa5u3J628BkoffUNMhnSOUF9+XcER5RfFHHq53Q6ahI= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3788.eurprd07.prod.outlook.com (52.133.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Thu, 1 Feb 2018 11:07:04 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::7d7f:f386:c50f:28d0]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::7d7f:f386:c50f:28d0%13]) with mapi id 15.20.0464.012; Thu, 1 Feb 2018 11:07:04 +0000 From: Ingemar Johansson S To: QUIC WG CC: Christian Huitema , Ian Swett , "Lubashev, Igor" , "De Schepper, Koen (Nokia - BE/Antwerp)" , Ingemar Johansson S Subject: ECN in QUIC connection migration Thread-Topic: ECN in QUIC connection migration Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25A== Date: Thu, 1 Feb 2018 11:07:04 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3788; 7:oO9QPetyR58u8xF3bVxWSA9k8QlsJwqWUsTYPHeoeC514RJ2GViHgPwRI+1oQEuJEib8D+R7gOaitcnFUlK4ihGaro1SiXnWylFYNfQEhf3TXsYhkHCqpuOj3Tbkw0ss7frt0qka+pc2GN58Sk3r4+6h7i96LOP4YSxYGnFak7U+UDO/ZPgRNwhThTdLxS3gEnFZmSTtt7lFygRqrLw9boMJxajyxebyxezfsfUbuWSFdZExg/acQKnJIV7LtnZ3 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(346002)(39860400002)(39380400002)(199004)(189003)(19609705001)(86362001)(97736004)(33656002)(2906002)(7696005)(316002)(102836004)(4743002)(606006)(6506007)(3846002)(790700001)(6116002)(26005)(106356001)(99286004)(3280700002)(4326008)(5250100002)(54906003)(3660700001)(107886003)(9326002)(66066001)(14454004)(55016002)(236005)(6306002)(9686003)(81156014)(81166006)(966005)(6916009)(8676002)(8936002)(2900100001)(54896002)(68736007)(478600001)(186003)(25786009)(6436002)(7736002)(74316002)(105586002)(53936002)(5660300001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3788; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: cdc5b7e6-328c-48b3-d015-08d56963ed10 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3788; x-ms-traffictypediagnostic: HE1PR0702MB3788: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(166708455590820)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231101)(2400082)(944501161)(3002001)(93006095)(93001095)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0702MB3788; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3788; x-forefront-prvs: 0570F1F193 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: GBHxPeUgrz0p80lJ4F6b6Gl/5lyLo2yYnnDGrl1ZaMigrueJIl7eMvDOkPdE6scg0q0l7o3gN7IzQ0lXoIuW+Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB36252D61A7A51B848B5DA9E7C2FA0HE1PR0702MB3625_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cdc5b7e6-328c-48b3-d015-08d56963ed10 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2018 11:07:04.1836 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3788 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTURjHOe9le50tjkvzoVJshZHOmRm2wiwLYn1IgiJKqFz6okOn433V NPowE4vMSNMsu+BMXV7ywrTSMKEp2iyw/OANMfMWpdkFK4YmuR0Dv/3O/8J5zsPhaEUnu4HT J6fyQrIuSSmRMSWnnocHDc8L0Tu+LoRoCrPuSzWO0VZWc9lURWu6fldSmjyz+wFWW9hpprVm a5p2+G4Po62ocFDay78fSY6x0bLwOD5Jn84LwRExsoSpoU5kzN+XYS43mlDL7lzEcYB3wVKl fy6ScQrcgaCprpElh24E86U5rgODf1JgymtncpHbsnObgheWE4SnEZRNpztZgsOh2vYHOdkT bwTrkx8SZ5nG2RR8aSihnMY6HAAdg80SEgoG67v3FGE1XB274yozeCs0jRS7dDmOgdqH8648 wj7w4c+oawgae8PwZKkrAxhDRVsvTdgLPk8ssSQfCz+HbrBE94PFvnEJYR/oK72OnMMBfkbB wC2rlBihkJvftlKYY6FoMoLwUeitz5aSQg+Cytc1iBgqcAw1rHAKDMzXM4QvwdM3BSwpPKDh 2i/LytWb4K/lGyK74+FxXQ7KR6p7q15EOAXs/UXSe64NeIC9ZJIhuhoGbxdJCAeCpWyGJhwE d5dszGrdjKQ1yEvkRdEQvzNUzQv6WFFMSVYn86lWtPy3XjUvBLWg2plIG8IcUq6RD30SohWs Ll3MNNgQcLTSUz7bvizJ43SZF3kh5ZyQlsSLNrSRY5TecvsRebQCx+tS+USeN/LCf5fi3DaY UJT7x0rD+GZ3dV/DHsbrrayt2/dgz0T/3q/UbJkiCuJCak9emTtenbiwdv/fsCJWO+WnMmw7 2K8P2+Jhyjo83mrxddzfdDbiZcb5vMX0wPKCm9vHPvtwb88EdmJ/yZR9vWziY/UMb1s0Hurr uhCptU9WpVGnyzPLDVmNI6rvkcVKRkzQhQTQgqj7B31DrzxXAwAA 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 Feb 2018 11:07:25 -0000 --_000_HE1PR0702MB36252D61A7A51B848B5DA9E7C2FA0HE1PR0702MB3625_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I have written up different aspects of connection migration and how it play= s with ECN. https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-conn= ection-migration A caveat.. I am a bit unsure about the definition of connection migration .= My interpretation is that a client moves to a new IP address due to e.g. a= NAT rebind or switch from WiFi to cellular, right ?. Is a new connection i= nstantiated at a connection migration ? /Ingemar =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 Research Network Protocols & E2E Performance 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 You can't start a fire Worrying 'bout your little world falling apart Bruce Springsteen =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_HE1PR0702MB36252D61A7A51B848B5DA9E7C2FA0HE1PR0702MB3625_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

I have written up different aspects of connection mi= gration and how it plays with ECN.

https://github.com/quic= wg/base-drafts/wiki/ECN-in-QUIC#transport-draft-connection-migration

 

A caveat.. I am a bit unsure about the definition of= connection migration . My interpretation is that a client moves to a new I= P address due to e.g. a NAT rebind or switch from WiFi to cellular, right ?= . Is a new connection instantiated at a connection migration ?

 

/Ingemar

 

=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 Research<= /o:p>

Network Protocols &= E2E Performance

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.joh= ansson@ericsson.com

www.ericsson.com

 

 =             &nb= sp;   You can't start a fire
  Worrying 'bout your little world fa= lling apart

 =             &nb= sp; Bruce Springsteen
=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_HE1PR0702MB36252D61A7A51B848B5DA9E7C2FA0HE1PR0702MB3625_-- From nobody Thu Feb 1 15:01:41 2018 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 B2A4312F280 for ; Thu, 1 Feb 2018 15:01:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 EwvpE3jZwfi0 for ; Thu, 1 Feb 2018 15:01:36 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 76D2D12DA29 for ; Thu, 1 Feb 2018 15:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1517526096; x=2381439696; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=zN4SVZX1G1GdGY+GU3HSZAG/e3O4eR3rDZarsua5R5M=; b=cs3EuMq1VuThGBaJhRBbJvWb3iW7FFb/BiQKRDKWIxAHGe9q0gjhCjxl88pCq1u5 4+mhf+rMVa96cp51xxZ08iF2bgyzT0pkQ+9UgTx5wcO2AUgYT6xIIEo9OGK9Btos 2j15UPzSJt4YhJFTveUEqG4d9ScE13j3gV4wDlPSvB3+m3H+0trouODsLajNs/nE DhABAkrrh2iUq3Vc0ZRCChcIIGZQ+LD074SbhpB2RpKaIw5H9pcGPmj+HAoKQw/u MGHEUMi2atDCvOi5E+ybisFqUjqfK/l0TyYSSXDiU1aMgAUsm0oOG9a/atv34r2m ClAsZvetC5fL5T1g1agudg==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id D9.13.14264.05C937A5; Thu, 1 Feb 2018 15:01:36 -0800 (PST) X-AuditID: 11973e13-066cc9e0000037b8-2d-5a739c50a730 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay5.apple.com (Apple SCV relay) with SMTP id F0.91.18983.F4C937A5; Thu, 1 Feb 2018 15:01:36 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_P1qNjudSPDzUqiVs46MXRQ)" Received: from [17.114.153.214] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180122 64bit (built Jan 22 2018)) with ESMTPSA id <0P3H00BUEUMNJJ40@nwk-mmpp-sz09.apple.com>; Thu, 01 Feb 2018 15:01:35 -0800 (PST) Sender: ekinnear@apple.com From: Eric Kinnear Message-id: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> Subject: Re: ECN in QUIC connection migration Date: Thu, 01 Feb 2018 15:01:34 -0800 In-reply-to: Cc: QUIC WG , Ian Swett , "Lubashev, Igor" , Christian Huitema , "De Schepper, Koen (Nokia - BE/Antwerp)" To: Ingemar Johansson S References: X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrKLMWRmVeSWpSXmKPExsUi2FAYoRswpzjK4MlMfovJjbPZLX7e28lq 0dSwgtli5uttLBbHvi1lsuhZwO3A5jH5yAJmj19fr7J5LNhU6nFrxikWjyVLfjJ5NH1bxBbA FsVlk5Kak1mWWqRvl8CVcbm/l7HgZW3F3Ynr2RsY1+d2MXJySAiYSPxbMZuli5GLQ0hgNZPE tp2TWGESjz58YYZIHGSUuN+znxkkwSsgKPFj8j2gDg4OZoEwienHykHCQgLfGCXe7KgEsYUF pCROb7zABGKzCahL/Hm4lh2i1UZi4dObLBA1uhLzfv4Hi7MIqEp8PLGcDWQkp0CyxN4pDiBr mQWeMEq8fbOWGSQuImAl8fayIogpJJAk8XxWEsSVShLTv99mAymXEFjELnHraB/TBEahWUgO nYVwKISpLjFlSi5IBbOAtsSTdxdYIWw1iYW/FzEhiy9gZFvFKJSbmJmjm5lnqpdYUJCTqpec n7uJERRP0+2EdzCeXmV1iFGAg1GJh5dDujhKiDWxrLgy9xCjNAeLkjiveXVRlJBAemJJanZq akFqUXxRaU5q8SFGJg5OqQZGr92iOXuX93wJmnHz3KLArj+ue1dNVw6cdrI782vRZKk7DN0W 9mtuOjMafZjznI2jUuyGyLQv+w60ZyqWK4UZxeYvPSDu9UHhisTdhoRn8yPvVelUf9cXT/j8 7rlydQrLnAq1og1H5r7f3FZ70DFr3YQlFfZJzLyXq7WY+s5dcJNt/1/RXGavxFKckWioxVxU nAgA11psYogCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUi2FAcoBswpzjKoHUdl8XkxtnsFj/v7WS1 aGpYwWwx8/U2Fotj35YyWfQs4HZg85h8ZAGzx6+vV9k8Fmwq9bg14xSLx5IlP5k8mr4tYgtg izK0ScsvKk8sSlEoSi4osVUqzkhMyS+PtzQ2MnVILCjISdVLzs9V0rezSUnNySxLLdK3SzDM uNzfy1jwsrbi7sT17A2M63O7GDk5JARMJB59+MLcxcjFISRwkFHifs9+ZpAEr4CgxI/J91i6 GDk4mAXCJKYfKwcJCwl8Y5R4s6MSxBYWkJI4vfECE4jNJqAu8efhWnaIVhuJhU9vskDU6ErM +/kfLM4ioCrx8cRyNpCRnALJEnunOICsZRZ4wijx9s1aZpC4iICVxNvLiiCmkECSxPNZSRBX KklM/36bbQIj/ywkt81CuA3CVJeYMiUXpIJZQFviybsLrBC2msTC34uYkMUXMLKtYhQoSs1J rDTVgwfYJkZwNBVG7GD8v8zqEKMAB6MSDy+HdHGUEGtiWXFl7iFGCQ5mJRHeK91AId6UxMqq 1KL8+KLSnNTiQ4w+QA9OZJYSTc4HRnpeSbyhsYWxpYmFgYGJpZkJDmElcd4jSkVRQgLpiSWp 2ampBalFMOOYODilGhjVUrXNVBXza97ps+snfeSfdHjRptfpR/6q33K7ztrw0N6B16AtmEFK wdrrivKOFL2jGddMJk8KrTJOfKjH7xTLfEnPUDlZagVzk3S8Ld+F1SLHZmf2KJ5sy3jCrj9v +tZ3TsuvLF7lLDSpyGPZxmmnjmZldjEtUOkK8JPz/MGVukTd+lAspxILMGkZajEXFScCAE1C PWLTAgAA 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 Feb 2018 23:01:39 -0000 --Boundary_(ID_P1qNjudSPDzUqiVs46MXRQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Hi Ingemar,=20 This generally looks good to me! A few questions and observations:=20 > There are two unique cases: >=20 > =E2=80=A2 ECN capability check successful at initial connection = setup > =E2=80=A2 ECN capability check failed at initial connection = setup Are these actually any different in terms of action taken by an = endpoint? It seems like on the new network path the endpoint would go through the = same process of: (a) verify ECN capability and if successful to whatever = degree then (b) run the rest of the ECN machinery as appropriate. In other words, as long as you allow people to start using ECN upon = migration (in other words, to allow starting it after the initial = connection establishment), then the specifics for ECN with migration is = essentially one statement, which is =E2=80=9Cdo the ECN process on each = new network path that you use=E2=80=9D.=20 > Connection migration has impact on the number of reported CE marked = packets. A new connection state with new congestion control state and = ECN counters is instantiated at the sender and receiver. The ECN = counters MUST start from zero again. This seems fine to me, it=E2=80=99s inline with the rest of the = congestion control/loss recovery state that also needs to be reset for = the new path.=20 Given that each migration requires at least one exchange of packets at = the beginning (at the very least for address validation from the side of = the endpoint that didn=E2=80=99t migrate), it seems like that=E2=80=99s = an excellent moment to mark the packets and perform the ECN capability = detection. Those packets are also likely padded, etc. similar to initial = packets since they=E2=80=99re on a previously unused network path.=20 I think the current proposed requirement of just using the =E2=80=9Cfirst=E2= =80=9D packets and marking those is sufficient (and good to avoid any = requirement as to which frames are contained in those packets), since we = are always exchanging packets in both directions immediately after = migration.=20 This has the added benefit such that any endpoint =E2=80=9Cprobing=E2=80=9D= possible network paths could include the bits necessary to detect ECN = capability on the path being probed, so it could even know before = migrating whether or not it would be able to use ECN on that new path.=20= Thanks, Eric > On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S = wrote: >=20 > Hi > I have written up different aspects of connection migration and how it = plays with ECN. > = https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-con= nection-migration = > =20 > A caveat.. I am a bit unsure about the definition of connection = migration . My interpretation is that a client moves to a new IP address = due to e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is a = new connection instantiated at a connection migration ?=20 > =20 > /Ingemar > =20 > =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 > =20 > Ericsson Research > Network Protocols & E2E Performance > Labratoriegr=C3=A4nd 11 > 971 28, Lule=C3=A5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com = > www.ericsson.com > =20 > You can't start a fire > Worrying 'bout your little world falling apart > Bruce Springsteen > =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 --Boundary_(ID_P1qNjudSPDzUqiVs46MXRQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable Hi = Ingemar, 

This = generally looks good to me!
A few questions and = observations: 

There are two unique = cases:

=E2=80=A2 = ECN capability check successful at initial connection setup
=E2=80=A2 ECN capability check = failed at initial connection setup

Are these actually any different in = terms of action taken by an endpoint?
It seems like = on the new network path the endpoint would go through the same process = of: (a) verify ECN capability and if successful to whatever degree then = (b) run the rest of the ECN machinery as appropriate.

In other words, as long = as you allow people to start using ECN upon migration (in other words, = to allow starting it after the initial connection establishment), then = the specifics for ECN with migration is essentially one statement, which = is =E2=80=9Cdo the ECN process on each new network path that you = use=E2=80=9D. 

Connection migration has = impact on the number of reported CE marked packets. A new connection = state with new congestion control state and ECN counters is = instantiated at the sender and receiver. The ECN counters MUST start = from zero again.

This seems fine to me, it=E2=80=99s inline with the = rest of the congestion control/loss recovery state that also needs to be = reset for the new path. 

Given that each migration requires at = least one exchange of packets at the beginning (at the very least for = address validation from the side of the endpoint that didn=E2=80=99t = migrate), it seems like that=E2=80=99s an excellent moment to mark the = packets and perform the ECN capability detection. Those packets are also = likely padded, etc. similar to initial packets since they=E2=80=99re on = a previously unused network path. 

I think the current proposed = requirement of just using the =E2=80=9Cfirst=E2=80=9D packets and = marking those is sufficient (and good to avoid any requirement as to = which frames are contained in those packets), since we are always = exchanging packets in both directions immediately after = migration. 

This has the added benefit such that any endpoint = =E2=80=9Cprobing=E2=80=9D possible network paths could include the bits = necessary to detect ECN capability on the path being probed, so it could = even know before migrating whether or not it would be able to use ECN on = that new path. 

Thanks,
Eric



On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi
I= have written up different aspects of connection migration and how it = plays with ECN.
 
A caveat.. I am a bit unsure about the = definition of connection migration . My interpretation is that a client = moves to a new IP address due to e.g. a NAT rebind or switch from WiFi = to cellular, right ?. Is a new connection instantiated at a connection = migration ? 
 
/Ingemar
 
=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 Research
Network Protocols & E2E Performance
Labratoriegr=C3=A4nd 11
971 28, Lule=C3=A5, = Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
ingemar.s.johansson@ericsson.com
www.ericsson.com
 
          &nb= sp;      You can't start a fire
  = Worrying 'bout your little world falling apart
          &nb= sp;    Bruce Springsteen
=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

= --Boundary_(ID_P1qNjudSPDzUqiVs46MXRQ)-- From nobody Thu Feb 1 16:47:24 2018 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 A9475126E3A for ; Thu, 1 Feb 2018 16:47:22 -0800 (PST) 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 gU3TOviPS1ok for ; Thu, 1 Feb 2018 16:47:20 -0800 (PST) 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 84508126DED for ; Thu, 1 Feb 2018 16:47:19 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id 141so9113744wme.3 for ; Thu, 01 Feb 2018 16:47:19 -0800 (PST) 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=KgkwxcQSqb7sTUGCxGjHt3Pg7/MhTqlyw7qHX1C3itA=; b=Jal2nZRE2f3Vt88SyBq3kiTJfz8/8Tj+yPYRmxdYQZQA5RqTNJoAv3OUu+oqR8tgWr e0aJkC4z2rzr9k0+NLoDrgOWNqQzLa0uHpFH9uKTPfnJBHjaKdB+nkG568WxQVEeB3fM Ms1xo8qcMSnfSqGc4Hpeci6rAIM3CcwMJPx5vW8o40kI/VjC+QSx3hASrpnEd/qdGf05 pe+p2ar6GTJu8DvP8KoGEWywiMc5hV+iN1HouipUSp9alOEYXL1+1is6CqDiTO3QjJRe negTcti3LT9c7KqYiBBpJVT945V74LSGi2N1BYC/z0ZPpVr/5d0B5cVxbsCboPpmO/r+ Icww== 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=KgkwxcQSqb7sTUGCxGjHt3Pg7/MhTqlyw7qHX1C3itA=; b=TUJMKYsEUCA9fIzDbbeWzOe9z8fcizpZS3gqjC1qKvusuGOZaTHn0OOyPl0k+91uog GDvex9EpfVw4sq1TtR3HIqRhRfBG5YTMn3kYaVDjyUyO4AJT/U+wu2dAiQRlGnbxHdBK 7tjWX7YnAoq5CDv3rQauvL4UZxLXt6+7QyZ8YTeTtGDXqH7fIVMqD9Jut1MY63+20dd0 CVYfV8m+YzhSv3wr1mlodaqxcJl8dj3/VNkQTkfGlWBzuQJUdx28+S6xS4JgTJtT2QAN ttLye68ZDtu6xdv4sbLkEwqr/Mz2X3+W1OCc/5kYft5FxArqaxdnu/3cX8tDtY7jRe1Y OkqQ== X-Gm-Message-State: AKwxytfoMsNLmAlXZk4tZnV25sPgVNVop5lJOuQRgD2hk5eNvYkwnA3Q v3RxfPPSTx/+RAZEhIatnx/u/JssEF4S5upx9VQ= X-Google-Smtp-Source: AH8x227spuDpe8vD+FoGTbqX3yjLuhZXMQ9M+avCmDHxviIR/9R2viFaUOsQw+h1OPU3Vch8l8RAJn7hMdKUSiwOSuo= X-Received: by 10.28.150.86 with SMTP id y83mr21336400wmd.42.1517532438038; Thu, 01 Feb 2018 16:47:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.208.130 with HTTP; Thu, 1 Feb 2018 16:47:17 -0800 (PST) Received: by 10.223.208.130 with HTTP; Thu, 1 Feb 2018 16:47:17 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> From: Martin Duke Date: Thu, 1 Feb 2018 16:47:17 -0800 Message-ID: Subject: Re: Packet number encryption To: Brian Trammell Cc: Jana Iyengar , Ted Hardie , Roberto Peon , Christian Huitema , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Eric Rescorla , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="001a114b33e4e790530564300df2" 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, 02 Feb 2018 00:47:23 -0000 --001a114b33e4e790530564300df2 Content-Type: text/plain; charset="UTF-8" Brian, I can come up with a middlebox design that is trying to be "helpful" but ends up causing PN ossification, but as you suggest this requires the box to be dumb about versions. So, meh. The other benefit of this scheme is that acks can go back to 1 byte PNs in ack frames for many connections, as the true packet number will start at 0 (boo!) or 1 (yay!). On Feb 1, 2018 12:09 AM, "Brian Trammell (IETF)" wrote: hi Jana, all, > On 1 Feb 2018, at 03:46, Jana Iyengar wrote: > > I like this proposal for the ossification reason that Roberto described, but I also like it because it really simplifies things from an implementation perspective. There seems to be a largely unquestioned assumption that packet number encryption has utility for ossification prevention. I am not convinced of this. Our experience with TLS greasing shows that placing random values in fields that would otherwise largely be static over the lifetime of the protocol improves the ability to use those fields later. Packet number encryption is greasing only by analogy. "Field X has value Y" is a fundamentally different observation than "The values of field X over time are governed by function F", and I'm not sure that intuition in the simpler case applies directly to the more complicated one. Specifically, for packet number encryption, the assumption appears to be that in-network devices will deploy during the operational lifetime of QUIC v1 that will make use of the observation that packet numbers monotonically increase, in a way that will impair the deployment of QUIC vN > 1 that does not have packet numbers that monotonically increase, or packet numbers that appear at a different location in the header. In other words, these devices will fail on this new version of QUIC in such a way that it will impair service to endpoints using QUIC vN. Analogies to the TCP sequence number here are a bit flawed. The most important difference is that the open nature of TCP's wire image means that usage of the sequence number isn't limited to observation: on-path devices can change it, and forge or delay ACKs based on it. The only thing an on-path device can do with a QUIC packet with a packet number it doesn't like is to drop it. This function might have some utility as part of an in-network QUIC garbage filter, as part of an anti-DDoS system, but any such device would need to track the version number as well (indeed, tracking version negotiation and handshaking would be a useful primitive here in its own right), and would therefore have enough information to not break on new versions it knows about. (Note we specifically don't care about the case where devices making use of this observation stop working in a way that the end-to-end properties of QUIC vN are preserved: the invariants as of a given version are the public wire-image interface to the protocol, anything else is at-your-own-risk, no-user-servicable-parts-inside). I suspect that similar arguments can be had about all but the simplest proposed applications of greasing to functions more complex than "the value of field X is always Y or Z". The example of packet number tracking points to an anti-ossification approach that I have much more confidence in, though: The vigorous and meaningful exercise of the version negotiation and version coexistence systems built into QUIC would force agility on on-path devices. The earlier we do this, the more effective it would be. I've already said this in other contexts, but I'll explicitly suggest it here: let's do QUIC 2, and soon (say, July 2019?), and use version negotiation *itself* as a method to "grease" the version negotiation mechanism along with the rest of the header. > We currently have packet number gaps to be used with new CIDs, but these are the same packet numbers on the wire as within the transport. So, when used with connection migration or after quiescence, the sender and receiver of ACKs has to deal with potentially large gaps... this is encodable on the wire, sure, but these gaps are unnecessary within the transport. > > Encrypting packet numbers reduces complexity in that you get a packet number gap on the wire without having to explicitly model it inside the transport. The transport machinery starts packet numbers at 0, increments it by 1 irrespective of migration or quiescence, and the ACK frames similarly carry the plaintext packet number. Separating what's used within the transport and what's visible on the wire allows you to do things like use multiple CIDs within the same 5-tuple. This is a more convincing argument for packet number encryption -- it does seem hard to get this elegance in the transport while having a non-trivially-linkable wire image without it. > I see it as a clean separation of concerns, with consequent simplification in implementation and an additional degree of freedom. > > I'm not convinced of the value of packet number in measuring reordering degree, since this can be trivially done by looking at the IP ID field for packets on the same 5-tuple. For IPv4 packets, on implementations where IPID is not randomized, yes. I don't have numbers on how prevalent these are; in any case, where it isn't randomized, that's arguably a bug that should be fixed. Should the guidance in the manageability draft, then, be "use IPv4 if you care about loss and reordering detection"? I am not optimistic about the chances of that getting past the IESG. ;) Cheers, Brian > On Wed, Jan 31, 2018 at 6:00 PM, Martin Thomson wrote: > With some light editing for quoting purposes... > > On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon wrote: > >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for the same > >> communicating peers Alice'sPhone and Bob'sBankServer93? > > > > The latter assuming we allow the server to specify it. > > I find "assuming we allow the server to specify *it*" to be strangely cryptic. > > To be clear, my operating assumption is while that servers can provide > multiple connection IDs, those connection IDs need to be usable on any > 5-tuple. Are you suggesting that a server might need to signal where > a connection is usable? (I can see how that might make sense, but it > isn't possible with the protocol as specified.) Or are you suggesting > that there might need to be some signal that allows clients to > distinguish between connection IDs that are for concurrent use? That > is, as opposed to what you might assume to be sequential use based on > the current specification. > > FWIW, it should be possible to remove the sequencing field from > NEW_CONNECTION_ID after making this change. The only reason left for > sequential connection ID use is to give the server the ability to know > when certain connection IDs no longer need to be available. A server > might then be able to clean up associated state and even reuse them. > > Of course, that likely only makes sense if the server is creating > explicit mappings for each, which - as discussed at the interim - > isn't super practical in many deployments. Right now, I think that > the assumption is an assumption only, and that relying on strictly > linear use of connection IDs would be unwise. > > --001a114b33e4e790530564300df2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Brian, I can come up with a middlebox design that is tryi= ng to be "helpful" but ends up causing PN ossification, but as yo= u suggest this requires the box to be dumb about versions. So, meh.

The other benefit of this scheme is t= hat acks can go back to 1 byte PNs in ack frames for many connections, as t= he true packet number will start at 0 (boo!) or 1 (yay!).

On Feb 1, 2018 12:09 AM= , "Brian Trammell (IETF)" <ietf@trammell.ch> wrote:
hi Jana, all,

> On 1 Feb 2018, at 03:46, Jana Iyengar <jri@google.com> wrote:
>
> I like this proposal for the ossification reason that Roberto describe= d, but I also like it because it really simplifies things from an implement= ation perspective.

There seems to be a largely unquestioned assumption that packet numbe= r encryption has utility for ossification prevention. I am not convinced of= this.

Our experience with TLS greasing shows that placing random values in fields= that would otherwise largely be static over the lifetime of the protocol i= mproves the ability to use those fields later. Packet number encryption is = greasing only by analogy. "Field X has value Y" is a fundamentall= y different observation than "The values of field X over time are gove= rned by function F", and I'm not sure that intuition in the simple= r case applies directly to the more complicated one.

Specifically, for packet number encryption, the assumption appears to be th= at in-network devices will deploy during the operational lifetime of QUIC v= 1 that will make use of the observation that packet numbers monotonically i= ncrease, in a way that will impair the deployment of QUIC vN > 1 that do= es not have packet numbers that monotonically increase, or packet numbers t= hat appear at a different location in the header. In other words, these dev= ices will fail on this new version of QUIC in such a way that it will impai= r service to endpoints using QUIC vN.

Analogies to the TCP sequence number here are a bit flawed. The most import= ant difference is that the open nature of TCP's wire image means that u= sage of the sequence number isn't limited to observation: on-path devic= es can change it, and forge or delay ACKs based on it. The only thing an on= -path device can do with a QUIC packet with a packet number it doesn't = like is to drop it. This function might have some utility as part of an in-= network QUIC garbage filter, as part of an anti-DDoS system, but any such d= evice would need to track the version number as well (indeed, tracking vers= ion negotiation and handshaking would be a useful primitive here in its own= right), and would therefore have enough information to not break on new ve= rsions it knows about.

(Note we specifically don't care about the case where devices making us= e of this observation stop working in a way that the end-to-end properties = of QUIC vN are preserved: the invariants as of a given version are the publ= ic wire-image interface to the protocol, anything else is at-your-own-risk,= no-user-servicable-parts-inside).

I suspect that similar arguments can be had about all but the simplest prop= osed applications of greasing to functions more complex than "the valu= e of field X is always Y or Z". The example of packet number tracking = points to an anti-ossification approach that I have much more confidence in= , though:

The vigorous and meaningful exercise of the version negotiation and version= coexistence systems built into QUIC would force agility on on-path devices= . The earlier we do this, the more effective it would be. I've already = said this in other contexts, but I'll explicitly suggest it here: let&#= 39;s do QUIC 2, and soon (say, July 2019?), and use version negotiation *it= self* as a method to "grease" the version negotiation mechanism a= long with the rest of the header.

> We currently have packet number gaps to be used with new CIDs, but the= se are the same packet numbers on the wire as within the transport. So, whe= n used with connection migration or after quiescence, the sender and receiv= er of ACKs has to deal with potentially large gaps... this is encodable on = the wire, sure, but these gaps are unnecessary within the transport.
>
> Encrypting packet numbers reduces complexity in that you get a packet = number gap on the wire without having to explicitly model it inside the tra= nsport. The transport machinery starts packet numbers at 0, increments it b= y 1 irrespective of migration or quiescence, and the ACK frames similarly c= arry the plaintext packet number. Separating what's used within the tra= nsport and what's visible on the wire allows you to do things like use = multiple CIDs within the same 5-tuple.

This is a more convincing argument for packet number encryption -- it= does seem hard to get this elegance in the transport while having a non-tr= ivially-linkable wire image without it.

> I see it as a clean separation of concerns, with consequent simplifica= tion in implementation and an additional degree of freedom.
>
> I'm not convinced of the value of packet number in measuring reord= ering degree, since this can be trivially done by looking at the IP ID fiel= d for packets on the same 5-tuple.

For IPv4 packets, on implementations where IPID is not randomized, ye= s. I don't have numbers on how prevalent these are; in any case, where = it isn't randomized, that's arguably a bug that should be fixed. Sh= ould the guidance in the manageability draft, then, be "use IPv4 if yo= u care about loss and reordering detection"? I am not optimistic about= the chances of that getting past the IESG. ;)

Cheers,

Brian

> On Wed, Jan 31, 2018 at 6:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> With some light editing for quoting purposes...
>
> On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon <fenix@fb.com> wrote:
> >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-= C, for the same
> >> communicating peers=C2=A0 Alice'sPhone and Bob'sBankS= erver93?
> >
> > The latter assuming we allow the server to specify it.
>
> I find "assuming we allow the server to specify *it*" to be = strangely cryptic.
>
> To be clear, my operating assumption is while that servers can provide=
> multiple connection IDs, those connection IDs need to be usable on any=
> 5-tuple.=C2=A0 Are you suggesting that a server might need to signal w= here
> a connection is usable?=C2=A0 (I can see how that might make sense, bu= t it
> isn't possible with the protocol as specified.)=C2=A0 Or are you s= uggesting
> that there might need to be some signal that allows clients to
> distinguish between connection IDs that are for concurrent use? That > is, as opposed to what you might assume to be sequential use based on<= br> > the current specification.
>
> FWIW, it should be possible to remove the sequencing field from
> NEW_CONNECTION_ID after making this change.=C2=A0 The only reason left= for
> sequential connection ID use is to give the server the ability to know=
> when certain connection IDs no longer need to be available.=C2=A0 A se= rver
> might then be able to clean up associated state and even reuse them. >
> Of course, that likely only makes sense if the server is creating
> explicit mappings for each, which - as discussed at the interim -
> isn't super practical in many deployments.=C2=A0 Right now, I thin= k that
> the assumption is an assumption only, and that relying on strictly
> linear use of connection IDs would be unwise.
>
>


--001a114b33e4e790530564300df2-- From nobody Thu Feb 1 16:56:11 2018 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 3468012DA3D for ; Thu, 1 Feb 2018 16:56:10 -0800 (PST) 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 ToWk97K5nmcG for ; Thu, 1 Feb 2018 16:56:08 -0800 (PST) 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 835FE126DED for ; Thu, 1 Feb 2018 16:56:08 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id a88so16379073pfe.12 for ; Thu, 01 Feb 2018 16:56:08 -0800 (PST) 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=Kyb1n5XOOIIuOy4EPBx/LBkaO6afUWLITkmU5wymnAg=; b=VyHmkKNYQdAqD3b+mPYDWqFAqeKY5GgRBr5KLqVq7nmfJD+GWql1TC+5hOsA1LknZG j1lkJ/dH52EF3EYZQuDDKSccJ0TYj4pKd8qunlFUvmZQwgwpgCdSfNsqed5ZDdOafLNz Gi3CneVy2EPVVyPnZuUYSW3e404cm4eaxS7sJPTpFPWchi59FTAkmDBB2+XHFHw2/4S4 th99tFdwBOWHt1C7TSllANEEmxiLm03r9C734HaarcdlvIEALWCRQSb9W5Xqz6XqBrxb Cyg89pY/vXyod4B6S/gfjsokToAssPA28H9JOCOjlts728+iLjSVayf77CWFpD6fFHro cBcA== 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=Kyb1n5XOOIIuOy4EPBx/LBkaO6afUWLITkmU5wymnAg=; b=pXMlcFrkP6Z/vySwT7mbdsE85OKDR9ozdvHPXFuEaAit774e7LYZcifMwgkOjpSzxQ tKCN2hJzz/wSpEtXRDOhFXKIk4lLir0hqOaY9E2YX2DjmBoQNSGJ2eksXWgRbL2GaJ1i 2Z6AixmXXkNNxxRTb0iHTWZx9TZz3KJ3rf3AXpunRYgOb/f6TljNu9r4KYuxMYQATheR m6PDAKK8cUaeAjxwY9rhx4MIYDI8I52Wa4Zva+CNMPpUmRwY+p2hJYHBJQjC4driHzNo uqXAgBeshAr1pSY7WaFqjQhqLarIwksOrrZQUraH61qaPAYdo7cuo3dGWS+hz5C/RNrM P3oA== X-Gm-Message-State: AKwxytdF0aCl+76kcybWrcbtGbDpYpTNgHE25vAmz5f1+C69tCWvDgIK 2TVvktL52VXrIWuJVFDXS+jSsEj8FCBfQuUkHAueqw== X-Google-Smtp-Source: AH8x226xPyjmWXEBYQUCZH5yWXUw1Dc0jCuqlF7L+PjwKIAcjPdh7czE9j0yDyer7sdyIL4hfFFU+Jt25k3TvKHYFLI= X-Received: by 10.99.123.78 with SMTP id k14mr135969pgn.173.1517532967921; Thu, 01 Feb 2018 16:56:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Thu, 1 Feb 2018 16:56:07 -0800 (PST) In-Reply-To: <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> From: Kazuho Oku Date: Fri, 2 Feb 2018 09:56:07 +0900 Message-ID: Subject: Re: Packet number encryption To: "Eggert, Lars" Cc: Gorry Fairhust , Eric Rescorla , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , Brian Trammell , QUIC WG , Martin Thomson 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, 02 Feb 2018 00:56:10 -0000 2018-01-31 19:00 GMT+09:00 Eggert, Lars : > On 2018-1-31, at 10:52, Gorry Fairhurst wrote: >> +1 - Simply: This *is* complicated and seems to add little. > > So as an implementor (chair hat off), this adds very little to the overall complexity of the protocol. +1 The algorithm defined in the PR is easy to implement. When using OpenSSL what you need to do is: * when switching to a new pn_key, call EVP_EncryptInit_ex to setup a CTR cipher (e.g., EVP_aes_128_ctr, EVP_chacha20) along with the pn_key passed as the argument. * for each packet, call EVP_EncryptInit_ex to set the IV to the 16 bytes of the AEAD ciphertext, then call EVP_EncryptUpdate to obtain the encrypted packet number Decryption is exactly the same as encryption, since it is CTR mode. To me it seems that using packet number encryption actually simplifies the implementation, since we no longer need to care about randomizing the initial packet number or implement special measures to avoid linkability when switching to a new CID. > Lars -- Kazuho Oku From nobody Thu Feb 1 18:49:26 2018 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 2EC5A12EBCB for ; Thu, 1 Feb 2018 18:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNwQ5oTHQA4R for ; Thu, 1 Feb 2018 18:49:22 -0800 (PST) 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 D6AA712EB91 for ; Thu, 1 Feb 2018 18:49:21 -0800 (PST) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx15.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ehRPh-0003gT-UI for quic@ietf.org; Fri, 02 Feb 2018 03:49:19 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ehRPb-000814-Dg for quic@ietf.org; Thu, 01 Feb 2018 21:49:15 -0500 Received: (qmail 14316 invoked from network); 2 Feb 2018 02:49:09 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 2 Feb 2018 02:49:08 -0000 To: Kazuho Oku , "Eggert, Lars" References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> Cc: Gorry Fairhust , Eric Rescorla , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Brian Trammell , QUIC WG , Martin Thomson From: Christian Huitema Message-ID: Date: Thu, 1 Feb 2018 16:49:08 -1000 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: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: Packet number encryption X-Originating-IP: 168.144.250.234 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.07) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jpcmxYcSIkO6d0SRLt7mL0Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fvdNbTVhHPV9J4dajz1aY/nB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYdTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS+C+me6dA6yBk+me OMe0W22n/kFi61SvDQh5XsjlapMvoZNAifNUgo2DcM4YtKVx9MMCOkgYBX58rqmjkeHDbS4kHaox hC4vjXqQZhHVp33bdA4PSvr8BodmIS11My0yWMx0Hcdm1lHSqdVK8QtbVazR2PDNKbWhLn7g2aSz CwEE5YE5enyccp7RH4WQio3uGTAwyjhRzXq9E3eaUXDCvLdWBb39uS1TjWG2Inx+Ts2Q6HPPLuOV zXiNlBYhGfdaOhRAKfWK48mqxd1pWN6R4o2HeieqAXh0r0nzc7RP95mM7ZWatoIKNF2f2G/5/Amz e6+9leQc+iFUvWoHPKlvO6wHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFNWyKkmH5fSq8aOwg6myHV8ibYT4C2qF2lnc18bVJn66R tTJ2QXCFHiUb4d5gX2qGZlKV//LDlCDTFxiJUKFQqDwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTlW6glWwcZMx8scB+2xXkSFjI1dRH6f16eQCtvwPkeoyZ+pdPqFUnGuNg304AKeRgl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L 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: Fri, 02 Feb 2018 02:49:24 -0000 On 2/1/2018 2:56 PM, Kazuho Oku wrote: > 2018-01-31 19:00 GMT+09:00 Eggert, Lars : >> On 2018-1-31, at 10:52, Gorry Fairhurst wrote: >>> +1 - Simply: This *is* complicated and seems to add little. >> So as an implementor (chair hat off), this adds very little to the overall complexity of the protocol. > +1 > > The algorithm defined in the PR is easy to implement. > > When using OpenSSL what you need to do is: > > * when switching to a new pn_key, call EVP_EncryptInit_ex to setup a > CTR cipher (e.g., EVP_aes_128_ctr, EVP_chacha20) along with the pn_key > passed as the argument. > > * for each packet, call EVP_EncryptInit_ex to set the IV to the 16 > bytes of the AEAD ciphertext, then call EVP_EncryptUpdate to obtain > the encrypted packet number > > Decryption is exactly the same as encryption, since it is CTR mode. > > To me it seems that using packet number encryption actually simplifies > the implementation, since we no longer need to care about randomizing > the initial packet number or implement special measures to avoid > linkability when switching to a new CID. +1. By the way, I wrote a small test vector for the PN encryption using AES, at https://github.com/quicwg/base-drafts/wiki/Test-vector-for-AES-packet-number-encryption. -- Christian Huitema From nobody Fri Feb 2 01:35:54 2018 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 E488212FA97 for ; Fri, 2 Feb 2018 01:35:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 379jvZ78VF7L for ; Fri, 2 Feb 2018 01:35:48 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AE612FA90 for ; Fri, 2 Feb 2018 01:35:47 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 937BF3409AD; Fri, 2 Feb 2018 10:35:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.5220); Fri, 2 Feb 2018 10:35:44 +0100 (CET) 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; Fri, 2 Feb 2018 10:35:44 +0100 (CET) Received: from [213.55.211.42] (account ietf@trammell.ch HELO [100.99.15.73]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44127957; Fri, 02 Feb 2018 10:35:43 +0100 Content-Type: multipart/alternative; boundary=Apple-Mail-72F30DF4-7A3A-4B58-9DB5-10816DDC44EB Mime-Version: 1.0 (1.0) Subject: Re: Packet number encryption From: "Brian Trammell (IETF)" X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Fri, 2 Feb 2018 10:35:41 +0100 Cc: Jana Iyengar , Ted Hardie , Roberto Peon , Christian Huitema , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Eric Rescorla , QUIC WG , Martin Thomson Content-Transfer-Encoding: 7bit Message-Id: <26AC90FF-EDC0-431A-86D7-8F78555B5DB9@trammell.ch> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> To: Martin Duke 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, 02 Feb 2018 09:35:52 -0000 --Apple-Mail-72F30DF4-7A3A-4B58-9DB5-10816DDC44EB Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On 2 Feb 2018, at 01:47, Martin Duke wrote: >=20 > Brian, I can come up with a middlebox design that is trying to be "helpful= " but ends up causing PN ossification, but as you suggest this requires the b= ox to be dumb about versions. So, meh. The insight hiding in my proposal about rapid versioning is exactly this: we= should have a goal to minimize the deployability of boxes that are dumb abo= ut versions. Grease the version negotiation mechanism here is fake: it prote= cts the codepoints but not the whole mechanism. As long as there is only one= version you=E2=80=99ll get boxes that don=E2=80=99t need to care about trac= king VN to know what=E2=80=99s going on. If version 2 follows on the heels o= f (or deploys simultaneously with) version 1, there will be fewer (none) of t= hose boxes deployed. > The other benefit of this scheme is that acks can go back to 1 byte PNs in= ack frames for many connections,=20 You get that with the random offset proposal as well. As far as I can see the benefits of this proposal are (1) it lets us presupp= ose a single-sequence-number design for multipath in version 2, which has so= me nice properties; and (2) it lets us dispense with all the messiness of PN= jumps on intentional migration. The first of these seems meh, the second is= a little more convincing: packet number jumping is not pretty. > as the true packet number will start at 0 (boo!) or 1 (yay!). I actually have strong opinions on both sides of this argument, so I think I= =E2=80=99ll go off in the corner and have a pointless fight with myself on t= his one. Cheers, Brian > On Feb 1, 2018 12:09 AM, "Brian Trammell (IETF)" wrote:= > hi Jana, all, >=20 > > On 1 Feb 2018, at 03:46, Jana Iyengar wrote: > > > > I like this proposal for the ossification reason that Roberto described,= but I also like it because it really simplifies things from an implementati= on perspective. >=20 > There seems to be a largely unquestioned assumption that packet number enc= ryption has utility for ossification prevention. I am not convinced of this.= >=20 > Our experience with TLS greasing shows that placing random values in field= s that would otherwise largely be static over the lifetime of the protocol i= mproves the ability to use those fields later. Packet number encryption is g= reasing only by analogy. "Field X has value Y" is a fundamentally different o= bservation than "The values of field X over time are governed by function F"= , and I'm not sure that intuition in the simpler case applies directly to th= e more complicated one. >=20 > Specifically, for packet number encryption, the assumption appears to be t= hat in-network devices will deploy during the operational lifetime of QUIC v= 1 that will make use of the observation that packet numbers monotonically in= crease, in a way that will impair the deployment of QUIC vN > 1 that does no= t have packet numbers that monotonically increase, or packet numbers that ap= pear at a different location in the header. In other words, these devices wi= ll fail on this new version of QUIC in such a way that it will impair servic= e to endpoints using QUIC vN. >=20 > Analogies to the TCP sequence number here are a bit flawed. The most impor= tant difference is that the open nature of TCP's wire image means that usage= of the sequence number isn't limited to observation: on-path devices can ch= ange it, and forge or delay ACKs based on it. The only thing an on-path devi= ce can do with a QUIC packet with a packet number it doesn't like is to drop= it. This function might have some utility as part of an in-network QUIC gar= bage filter, as part of an anti-DDoS system, but any such device would need t= o track the version number as well (indeed, tracking version negotiation and= handshaking would be a useful primitive here in its own right), and would t= herefore have enough information to not break on new versions it knows about= . >=20 > (Note we specifically don't care about the case where devices making use o= f this observation stop working in a way that the end-to-end properties of Q= UIC vN are preserved: the invariants as of a given version are the public wi= re-image interface to the protocol, anything else is at-your-own-risk, no-us= er-servicable-parts-inside). >=20 > I suspect that similar arguments can be had about all but the simplest pro= posed applications of greasing to functions more complex than "the value of f= ield X is always Y or Z". The example of packet number tracking points to an= anti-ossification approach that I have much more confidence in, though: >=20 > The vigorous and meaningful exercise of the version negotiation and versio= n coexistence systems built into QUIC would force agility on on-path devices= . The earlier we do this, the more effective it would be. I've already said t= his in other contexts, but I'll explicitly suggest it here: let's do QUIC 2,= and soon (say, July 2019?), and use version negotiation *itself* as a metho= d to "grease" the version negotiation mechanism along with the rest of the h= eader. >=20 > > We currently have packet number gaps to be used with new CIDs, but these= are the same packet numbers on the wire as within the transport. So, when u= sed with connection migration or after quiescence, the sender and receiver o= f ACKs has to deal with potentially large gaps... this is encodable on the w= ire, sure, but these gaps are unnecessary within the transport. > > > > Encrypting packet numbers reduces complexity in that you get a packet nu= mber gap on the wire without having to explicitly model it inside the transp= ort. The transport machinery starts packet numbers at 0, increments it by 1 i= rrespective of migration or quiescence, and the ACK frames similarly carry t= he plaintext packet number. Separating what's used within the transport and w= hat's visible on the wire allows you to do things like use multiple CIDs wit= hin the same 5-tuple. >=20 > This is a more convincing argument for packet number encryption -- it does= seem hard to get this elegance in the transport while having a non-triviall= y-linkable wire image without it. >=20 > > I see it as a clean separation of concerns, with consequent simplificati= on in implementation and an additional degree of freedom. > > > > I'm not convinced of the value of packet number in measuring reordering d= egree, since this can be trivially done by looking at the IP ID field for pa= ckets on the same 5-tuple. >=20 > For IPv4 packets, on implementations where IPID is not randomized, yes. I d= on't have numbers on how prevalent these are; in any case, where it isn't ra= ndomized, that's arguably a bug that should be fixed. Should the guidance in= the manageability draft, then, be "use IPv4 if you care about loss and reor= dering detection"? I am not optimistic about the chances of that getting pas= t the IESG. ;) >=20 > Cheers, >=20 > Brian >=20 > > On Wed, Jan 31, 2018 at 6:00 PM, Martin Thomson wrote: > > With some light editing for quoting purposes... > > > > On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon wrote: > > >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for t= he same > > >> communicating peers Alice'sPhone and Bob'sBankServer93? > > > > > > The latter assuming we allow the server to specify it. > > > > I find "assuming we allow the server to specify *it*" to be strangely cr= yptic. > > > > To be clear, my operating assumption is while that servers can provide > > multiple connection IDs, those connection IDs need to be usable on any > > 5-tuple. Are you suggesting that a server might need to signal where > > a connection is usable? (I can see how that might make sense, but it > > isn't possible with the protocol as specified.) Or are you suggesting > > that there might need to be some signal that allows clients to > > distinguish between connection IDs that are for concurrent use? That > > is, as opposed to what you might assume to be sequential use based on > > the current specification. > > > > FWIW, it should be possible to remove the sequencing field from > > NEW_CONNECTION_ID after making this change. The only reason left for > > sequential connection ID use is to give the server the ability to know > > when certain connection IDs no longer need to be available. A server > > might then be able to clean up associated state and even reuse them. > > > > Of course, that likely only makes sense if the server is creating > > explicit mappings for each, which - as discussed at the interim - > > isn't super practical in many deployments. Right now, I think that > > the assumption is an assumption only, and that relying on strictly > > linear use of connection IDs would be unwise. > > > > >=20 >=20 --Apple-Mail-72F30DF4-7A3A-4B58-9DB5-10816DDC44EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent= from my iPhone

On 2 Feb 2018, at 01:47, Martin Duke <martin.h.duke@gmail.com> wrote:=

Brian, I can c= ome up with a middlebox design that is trying to be "helpful" but ends up ca= using PN ossification, but as you suggest this requires the box to be dumb a= bout versions. So, meh.

The insi= ght hiding in my proposal about rapid versioning is exactly this: we should h= ave a goal to minimize the deployability of boxes that are dumb about versio= ns. Grease the version negotiation mechanism here is fake: it protects the c= odepoints but not the whole mechanism. As long as there is only one version y= ou=E2=80=99ll get boxes that don=E2=80=99t need to care about tracking VN to= know what=E2=80=99s going on. If version 2 follows on the heels of (or depl= oys simultaneously with) version 1, there will be fewer (none) of those boxe= s deployed.

The other benefit of this scheme is that acks can go back to 1 b= yte PNs in ack frames for many connections, 

You get that with the random offset proposal as well= .

As far as I can see the benefits of this proposal= are (1) it lets us presuppose a single-sequence-number design for multipath= in version 2, which has some nice properties; and (2) it lets us dispense w= ith all the messiness of PN jumps on intentional migration. The first of the= se seems meh, the second is a little more convincing: packet number jumping i= s not pretty.

as the true packet number will start at 0 (boo!) o= r 1 (yay!).

I actu= ally have strong opinions on both sides of this argument, so I think I=E2=80= =99ll go off in the corner and have a pointless fight with myself on this on= e.

Cheers,

Brian

=
On Feb 1, 2018 12:09 AM, "Brian Trammell (IETF)" <ietf@trammell.ch> wrote:
hi Jana, all,

> On 1 Feb 2018, at 03:46, Jana Iyengar <jri@google.com> wrote:
>
> I like this proposal for the ossification reason that Roberto described= , but I also like it because it really simplifies things from an implementat= ion perspective.

There seems to be a largely unquestioned assumption that packet number= encryption has utility for ossification prevention. I am not convinced of t= his.

Our experience with TLS greasing shows that placing random values in fields t= hat would otherwise largely be static over the lifetime of the protocol impr= oves the ability to use those fields later. Packet number encryption is grea= sing only by analogy. "Field X has value Y" is a fundamentally different obs= ervation than "The values of field X over time are governed by function F", a= nd I'm not sure that intuition in the simpler case applies directly to the m= ore complicated one.

Specifically, for packet number encryption, the assumption appears to be tha= t in-network devices will deploy during the operational lifetime of QUIC v1 t= hat will make use of the observation that packet numbers monotonically incre= ase, in a way that will impair the deployment of QUIC vN > 1 that does no= t have packet numbers that monotonically increase, or packet numbers that ap= pear at a different location in the header. In other words, these devices wi= ll fail on this new version of QUIC in such a way that it will impair servic= e to endpoints using QUIC vN.

Analogies to the TCP sequence number here are a bit flawed. The most importa= nt difference is that the open nature of TCP's wire image means that usage o= f the sequence number isn't limited to observation: on-path devices can chan= ge it, and forge or delay ACKs based on it. The only thing an on-path device= can do with a QUIC packet with a packet number it doesn't like is to drop i= t. This function might have some utility as part of an in-network QUIC garba= ge filter, as part of an anti-DDoS system, but any such device would need to= track the version number as well (indeed, tracking version negotiation and h= andshaking would be a useful primitive here in its own right), and would the= refore have enough information to not break on new versions it knows about.<= br>
(Note we specifically don't care about the case where devices making use of t= his observation stop working in a way that the end-to-end properties of QUIC= vN are preserved: the invariants as of a given version are the public wire-= image interface to the protocol, anything else is at-your-own-risk, no-user-= servicable-parts-inside).

I suspect that similar arguments can be had about all but the simplest propo= sed applications of greasing to functions more complex than "the value of fi= eld X is always Y or Z". The example of packet number tracking points to an a= nti-ossification approach that I have much more confidence in, though:

The vigorous and meaningful exercise of the version negotiation and version c= oexistence systems built into QUIC would force agility on on-path devices. T= he earlier we do this, the more effective it would be. I've already said thi= s in other contexts, but I'll explicitly suggest it here: let's do QUIC 2, a= nd soon (say, July 2019?), and use version negotiation *itself* as a method t= o "grease" the version negotiation mechanism along with the rest of the head= er.

> We currently have packet number gaps to be used with new CIDs, but thes= e are the same packet numbers on the wire as within the transport. So, when u= sed with connection migration or after quiescence, the sender and receiver o= f ACKs has to deal with potentially large gaps... this is encodable on the w= ire, sure, but these gaps are unnecessary within the transport.
>
> Encrypting packet numbers reduces complexity in that you get a packet n= umber gap on the wire without having to explicitly model it inside the trans= port. The transport machinery starts packet numbers at 0, increments it by 1= irrespective of migration or quiescence, and the ACK frames similarly carry= the plaintext packet number. Separating what's used within the transport an= d what's visible on the wire allows you to do things like use multiple CIDs w= ithin the same 5-tuple.

This is a more convincing argument for packet number encryption -- it d= oes seem hard to get this elegance in the transport while having a non-trivi= ally-linkable wire image without it.

> I see it as a clean separation of concerns, with consequent simplificat= ion in implementation and an additional degree of freedom.
>
> I'm not convinced of the value of packet number in measuring reordering= degree, since this can be trivially done by looking at the IP ID field for p= ackets on the same 5-tuple.

For IPv4 packets, on implementations where IPID is not randomized, yes= . I don't have numbers on how prevalent these are; in any case, where it isn= 't randomized, that's arguably a bug that should be fixed. Should the guidan= ce in the manageability draft, then, be "use IPv4 if you care about loss and= reordering detection"? I am not optimistic about the chances of that gettin= g past the IESG. ;)

Cheers,

Brian

> On Wed, Jan 31, 2018 at 6:00 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> With some light editing for quoting purposes...
>
> On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon <fenix@fb.com> wrote:
> >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C= , for the same
> >> communicating peers  Alice'sPhone and Bob'sBankServer93?<= br> > >
> > The latter assuming we allow the server to specify it.
>
> I find "assuming we allow the server to specify *it*" to be strangely c= ryptic.
>
> To be clear, my operating assumption is while that servers can provide<= br> > multiple connection IDs, those connection IDs need to be usable on any<= br> > 5-tuple.  Are you suggesting that a server might need to signal wh= ere
> a connection is usable?  (I can see how that might make sense, but= it
> isn't possible with the protocol as specified.)  Or are you sugges= ting
> that there might need to be some signal that allows clients to
> distinguish between connection IDs that are for concurrent use? That > is, as opposed to what you might assume to be sequential use based on > the current specification.
>
> FWIW, it should be possible to remove the sequencing field from
> NEW_CONNECTION_ID after making this change.  The only reason left f= or
> sequential connection ID use is to give the server the ability to know<= br> > when certain connection IDs no longer need to be available.  A ser= ver
> might then be able to clean up associated state and even reuse them. >
> Of course, that likely only makes sense if the server is creating
> explicit mappings for each, which - as discussed at the interim -
> isn't super practical in many deployments.  Right now, I think tha= t
> the assumption is an assumption only, and that relying on strictly
> linear use of connection IDs would be unwise.
>
>


= --Apple-Mail-72F30DF4-7A3A-4B58-9DB5-10816DDC44EB-- From nobody Fri Feb 2 02:54:05 2018 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 3BAF712EB38 for ; Fri, 2 Feb 2018 02:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 xHi8tsbY4gVA for ; Fri, 2 Feb 2018 02:54:02 -0800 (PST) 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 009D812EAC0 for ; Fri, 2 Feb 2018 02:54:01 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id n206so7464635itg.1 for ; Fri, 02 Feb 2018 02:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=3xUF4fnex4WsOSYcTVVA0gJH/yVPBjGBtll0DVo0hC8=; b=loSB2rWfzVx8+bTrVayeb4BxnmMKNYHn+AhfSaIFI4hZjWel3uafWSPtADTudrmXfC VDmNT+HNdQybytYByqeTX3tP7maSVMiQtzeWCo4Hiq1N/nWM6wwLojUQCzrPcrm1eAS2 9RpCMwAIzLhqd/NYkpWSQjgviU3dcIsmx6VrIWoMniE5Ur0GFNV3JsHIPyxRMcPqxBao ezKJ96w5I6sIqOak0SWS7OX4L2c4dElQclR62tIJPUOrPVf3sEDBCUngOX+DPm2Zec7y wjdCQyMcipAGURuHfpRvfpdVmCXqbYnevWBPagLBkyYrV91kRXA4hBOD4l51aYiwQTzQ cxeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=3xUF4fnex4WsOSYcTVVA0gJH/yVPBjGBtll0DVo0hC8=; b=KDMxE2q/Su2vFgvD3PtGLu6E3woeB2q9lXqD4yz5CixV3ETjksj6uZlNU9Bu38xhue rWLwJJOaNeMBijC4BLFd55xX8/68UfogU52wvOIS45zDnisveWHkrSRuAbjVIjxTJYxU A+GX1s+6CCTjXKlvfRLqs0JRrA4xBuNcK33istQhv/edLY3AOYmv9dmBCGMCETPCrnxR T9B0YLfLhEi4scxdKT/JoR6lCV6/BrBfUvMvxs9cj4mdj8RBPU7tcPz6CbC/nRRiRzOY po9HjpF8w69iwk7ffCMS9L4CVtfEeX1httNJ/7o9UJWmPA9W/QsbAbxL71PqJ5RRoPXR U/+A== X-Gm-Message-State: AKwxytcrvLgkZCtdR3cN2a6dFPxX0bYV4W+TcrzXqVyyYtj2RoI0CuEK PZzR3GjEHwDlWhVsUtIbZPL4VSOweWH9vzcv43o= X-Google-Smtp-Source: AH8x2252kmgMdfRbAj/3d6v7lPs/NXQN0gVO3XSdw+YH+GI+BvRDJTh9U7m9FP933dhx8K2vKwmjdQzpngKHC+DqWFs= X-Received: by 10.36.178.26 with SMTP id u26mr25379465ite.4.1517568841384; Fri, 02 Feb 2018 02:54:01 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 2 Feb 2018 02:54:00 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <26AC90FF-EDC0-431A-86D7-8F78555B5DB9@trammell.ch> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> <26AC90FF-EDC0-431A-86D7-8F78555B5DB9@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 2 Feb 2018 02:54:00 -0800 Message-ID: Subject: Re: Packet number encryption To: "Brian Trammell (IETF)" , Martin Duke Cc: QUIC WG , Jana Iyengar , Ted Hardie , Martin Thomson , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , Eric Rescorla , Roberto Peon Content-Type: multipart/alternative; boundary="f403045d914cb6890b05643887ef" 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, 02 Feb 2018 10:54:04 -0000 --f403045d914cb6890b05643887ef Content-Type: text/plain; charset="UTF-8" and (2) it lets us dispense with all the messiness of PN jumps on intentional migration. The first of these seems meh, the second is a little more convincing: packet number jumping is not pretty. I have proposed a defence against optimistic ACK attack the avoids the use of packet number gaps and which makes it mandatory for implementations to support: https://github.com/quicwg/base-drafts/issues/1092 --f403045d914cb6890b05643887ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
=C2=A0and (2) it lets us dispense with all the messiness of PN jumps on intentional migration. The first of these seems meh, the second is a little more convincing: packet number jumping is not pretty.


I have propose= d a defence against optimistic ACK attack the avoids the use of packet numb= er gaps and which makes it mandatory for implementations to support:
<= div>https://g= ithub.com/quicwg/base-drafts/issues/1092

--f403045d914cb6890b05643887ef-- From nobody Fri Feb 2 04:24:24 2018 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 D4EEB12D7E4 for ; Fri, 2 Feb 2018 04:24:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 XZ-a8YfX_kRl for ; Fri, 2 Feb 2018 04:24:20 -0800 (PST) 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 98F43129C6B for ; Fri, 2 Feb 2018 04:24:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zXx4K2tGrz15N3y; Fri, 2 Feb 2018 13:24:17 +0100 (CET) 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 YnAzGJLl8zRn; Fri, 2 Feb 2018 13:24:16 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (i577BCE83.versanet.de [87.123.206.131]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 2 Feb 2018 13:24:15 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Packet number encryption From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 2 Feb 2018 13:24:14 +0100 Cc: "Eggert, Lars" , Gorry Fairhust , Eric Rescorla , Christian Huitema , Brian Trammell , QUIC WG , Martin Thomson Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> To: Kazuho Oku X-Mailer: Apple Mail (2.3445.5.20) 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, 02 Feb 2018 12:24:23 -0000 Please see below. > Am 02.02.2018 um 01:56 schrieb Kazuho Oku : >=20 > 2018-01-31 19:00 GMT+09:00 Eggert, Lars : >> On 2018-1-31, at 10:52, Gorry Fairhurst wrote: >>> +1 - Simply: This *is* complicated and seems to add little. >>=20 >> So as an implementor (chair hat off), this adds very little to the = overall complexity of the protocol. >=20 > +1 >=20 > The algorithm defined in the PR is easy to implement. I didn=E2=80=99t say that it is too complex (I actually explicitly said = in my original mail it is not very complex) but it adds additional = complexity to a protocol that is already complex and doesn=E2=80=99t = provide much benefit from my point of view but can be an additional = source for errors. After all it must also be possible to implement QUIC = if you just read the final specs and have not participated in the wg = design discussion or can easy ask a clarifying question on the list. >=20 > When using OpenSSL what you need to do is: If you don=E2=80=99t want to use OpenSSL or are in an environment where = you can use such a library, it is definitely more complex than this. >=20 > * when switching to a new pn_key, call EVP_EncryptInit_ex to setup a > CTR cipher (e.g., EVP_aes_128_ctr, EVP_chacha20) along with the pn_key > passed as the argument. >=20 > * for each packet, call EVP_EncryptInit_ex to set the IV to the 16 > bytes of the AEAD ciphertext, then call EVP_EncryptUpdate to obtain > the encrypted packet number >=20 > Decryption is exactly the same as encryption, since it is CTR mode. >=20 > To me it seems that using packet number encryption actually simplifies > the implementation, since we no longer need to care about randomizing > the initial packet number or implement special measures to avoid > linkability when switching to a new CID. Choosing a random number is definitely less complex than encrypting = something. It might simply your current code because you are using a = library that implements the complexity already. And special measures = when switch to a new path are needed anyway for the CID. Mirja >=20 >> Lars >=20 >=20 >=20 > --=20 > Kazuho Oku From nobody Fri Feb 2 04:27:40 2018 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 9D9A0129C6B for ; Fri, 2 Feb 2018 04:27:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 lUrnybBqLdVK for ; Fri, 2 Feb 2018 04:27:36 -0800 (PST) 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 ADB2112D7E4 for ; Fri, 2 Feb 2018 04:27:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zXx8735F1z15N44; Fri, 2 Feb 2018 13:27:35 +0100 (CET) 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 rPiADAyikPwm; Fri, 2 Feb 2018 13:27:34 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (i577BCE83.versanet.de [87.123.206.131]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 2 Feb 2018 13:27:34 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Packet number encryption From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 2 Feb 2018 13:27:33 +0100 Cc: Martin Thomson , Roberto Peon , Ted Hardie , Eric Rescorla , Christian Huitema , Brian Trammell , QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <5DB817B8-3B9B-43B8-8949-1ABF8F9A1BF8@tik.ee.ethz.ch> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3445.5.20) 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, 02 Feb 2018 12:27:38 -0000 Hi Jana, one point below, just to clarify this explicitly. > Am 01.02.2018 um 03:46 schrieb Jana Iyengar : >=20 > I like this proposal for the ossification reason that Roberto = described, but I also like it because it really simplifies things from = an implementation perspective. >=20 > We currently have packet number gaps to be used with new CIDs, but = these are the same packet numbers on the wire as within the transport. = So, when used with connection migration or after quiescence, the sender = and receiver of ACKs has to deal with potentially large gaps... this is = encodable on the wire, sure, but these gaps are unnecessary within the = transport. >=20 > Encrypting packet numbers reduces complexity in that you get a packet = number gap on the wire without having to explicitly model it inside the = transport. The transport machinery starts packet numbers at 0, = increments it by 1 irrespective of migration or quiescence, and the ACK = frames similarly carry the plaintext packet number. Separating what's = used within the transport and what's visible on the wire allows you to = do things like use multiple CIDs within the same 5-tuple.=20 >=20 > I see it as a clean separation of concerns, with consequent = simplification in implementation and an additional degree of freedom. You also have this with an random offset. You internally start with 0 or = 1 and just add or remove the offset from the PN in the wire image. Done. = I like this separation a lot and think that is a great change as it = does make implementation easier and reduces overhead. However, these are = two different things. There is no need to encrypt the PM just for that. Mirja >=20 > I'm not convinced of the value of packet number in measuring = reordering degree, since this can be trivially done by looking at the IP = ID field for packets on the same 5-tuple. >=20 > On Wed, Jan 31, 2018 at 6:00 PM, Martin Thomson = wrote: > With some light editing for quoting purposes... >=20 > On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon wrote: > >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for = the same > >> communicating peers Alice'sPhone and Bob'sBankServer93? > > > > The latter assuming we allow the server to specify it. >=20 > I find "assuming we allow the server to specify *it*" to be strangely = cryptic. >=20 > To be clear, my operating assumption is while that servers can provide > multiple connection IDs, those connection IDs need to be usable on any > 5-tuple. Are you suggesting that a server might need to signal where > a connection is usable? (I can see how that might make sense, but it > isn't possible with the protocol as specified.) Or are you suggesting > that there might need to be some signal that allows clients to > distinguish between connection IDs that are for concurrent use? That > is, as opposed to what you might assume to be sequential use based on > the current specification. >=20 > FWIW, it should be possible to remove the sequencing field from > NEW_CONNECTION_ID after making this change. The only reason left for > sequential connection ID use is to give the server the ability to know > when certain connection IDs no longer need to be available. A server > might then be able to clean up associated state and even reuse them. >=20 > Of course, that likely only makes sense if the server is creating > explicit mappings for each, which - as discussed at the interim - > isn't super practical in many deployments. Right now, I think that > the assumption is an assumption only, and that relying on strictly > linear use of connection IDs would be unwise. >=20 >=20 From nobody Fri Feb 2 05:13:54 2018 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 F1C4912422F for ; Fri, 2 Feb 2018 05:13:51 -0800 (PST) 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 iiERvrONVztT for ; Fri, 2 Feb 2018 05:13:49 -0800 (PST) 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 64C31120713 for ; Fri, 2 Feb 2018 05:13:49 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id o13so14053294pgs.2 for ; Fri, 02 Feb 2018 05:13:49 -0800 (PST) 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=ivkoDLZifOflvdKaFG4MGQJFD17nnQkOGCz6PYWFth0=; b=EvTi9IXMedY/2Frx5ySEipVqd/9FexGiIMxqkojVF3zj7dJTcR9XQTQ8axxwWHJlAK WyWCry/qLQCVq8IJRt1sW2KiNtxaUwJVA/DenDmh05LcW8JpK3UXT4UPodh5NfEJgBLZ YjPhaBZcuXNtstzj+qeqM7lsTsjcv6PswUoF4AY/S3mNjftep+aKYk1Otezyy9OB3tXg h5yxpG8Wqkk+VZsDdlqFZ7k1G0i40iXk/MA9OnRgJaQBAfe70MMp3dk1y91D7ICbS331 WcB/oUU6XqYJLFhugK9WKaqnJYDJ58GDXxmAUgomXJPuhrlTQkUi1zKIOEvAWDSqptyV OouA== 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=ivkoDLZifOflvdKaFG4MGQJFD17nnQkOGCz6PYWFth0=; b=TH80gnWq40bl/cwUbXr6djsvimvZztS0s651s8pNcpuFhlw+qAt2bjzMKo5UyheEhE 7FT0g4yZiGaK6hER7UdWUGVAIT6RmDuohbMantdQyMfS8WVrDVR9cQ2YxvKKYeOauUlZ VyRneYd0o24GgsE032N+NGMmF28zssItzyilXVWfT+TVWkVQr+vQPSqj2m/22EpNWfsG SL+hp8eixlSuWYSCWGN/ut98LqucotNhTapK8Jk5XEt54iXVA9/0AFpyY15Mum5/qmrC jIDj7BFfIv3iV/5n4KJRRs+MepdDqGcmWfXEW2Puk2TvlOZfp6qfUIYZVwVgGGiKjDSi vOiA== X-Gm-Message-State: AKwxytd6jBCAd122r/1aexa7ozho8pyIxaTh6MWHThR/8MZYDPoHZzuM /gdWW39EAlTUw214hKvk9x9gBw99y94j1E//1+c= X-Google-Smtp-Source: AH8x226JKQgUITLw6yQPchp5JsOGPEyunRtsxlR0IUaOCLUJDmkP5OlDxiS/fTNb2pV4aAYOwW5eNVTpHfl6NLMNg5w= X-Received: by 10.99.123.78 with SMTP id k14mr1469061pgn.173.1517577228720; Fri, 02 Feb 2018 05:13:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Fri, 2 Feb 2018 05:13:47 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> From: Kazuho Oku Date: Fri, 2 Feb 2018 22:13:47 +0900 Message-ID: Subject: Re: Packet number encryption To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: "Eggert, Lars" , Gorry Fairhust , Eric Rescorla , Christian Huitema , Brian Trammell , QUIC WG , Martin Thomson 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, 02 Feb 2018 13:13:52 -0000 2018-02-02 21:24 GMT+09:00 Mirja K=C3=BChlewind : > Please see below. > >> Am 02.02.2018 um 01:56 schrieb Kazuho Oku : >> >> 2018-01-31 19:00 GMT+09:00 Eggert, Lars : >>> On 2018-1-31, at 10:52, Gorry Fairhurst wrote: >>>> +1 - Simply: This *is* complicated and seems to add little. >>> >>> So as an implementor (chair hat off), this adds very little to the over= all complexity of the protocol. >> >> +1 >> >> The algorithm defined in the PR is easy to implement. > > I didn=E2=80=99t say that it is too complex (I actually explicitly said i= n my original mail it is not very complex) but it adds additional complexi= ty to a protocol that is already complex and doesn=E2=80=99t provide much b= enefit from my point of view but can be an additional source for errors. Regarding CID migration, I would argue that the current draft is already complex due to the use of HKDF based on a derived key to calculate the gap. But it still has issues (please refer to https://github.com/quicwg/base-drafts/issues/1034). Switching to packet number encryption resolves those issues. You no longer need to do special calculation of the packet number upon CID migration. Having a consistent logic to handle packet numbers is IMO a better choice than requiring complex operations in a corner case. > After all it must also be possible to implement QUIC if you just read the= final specs and have not participated in the wg design discussion or can e= asy ask a clarifying question on the list. > >> >> When using OpenSSL what you need to do is: > > If you don=E2=80=99t want to use OpenSSL or are in an environment where y= ou can use such a library, it is definitely more complex than this. I agree that the mileage may vary depending on the crypto library you use. However, I would also argue that it would be fairly natural to assume that you have access to the underlying cipher of an AEAD cipher that you would be using (e.g. AES-ECB (or AES-CTR) for AES-GCM, Chacha20 for Chacha20-Poly1305). Then, it is easy to construct the proposed logic, though you might need to write code specific to each cipher. > >> >> * when switching to a new pn_key, call EVP_EncryptInit_ex to setup a >> CTR cipher (e.g., EVP_aes_128_ctr, EVP_chacha20) along with the pn_key >> passed as the argument. >> >> * for each packet, call EVP_EncryptInit_ex to set the IV to the 16 >> bytes of the AEAD ciphertext, then call EVP_EncryptUpdate to obtain >> the encrypted packet number >> >> Decryption is exactly the same as encryption, since it is CTR mode. >> >> To me it seems that using packet number encryption actually simplifies >> the implementation, since we no longer need to care about randomizing >> the initial packet number or implement special measures to avoid >> linkability when switching to a new CID. > > Choosing a random number is definitely less complex than encrypting somet= hing. It might simply your current code because you are using a library tha= t implements the complexity already. And special measures when switch to a = new path are needed anyway for the CID. I agree that calculating a random number is not a big deal. Regarding the amount of the special measures in relation to CID migration, please refer to my comment above. > > Mirja > > > > >> >>> Lars >> >> >> >> -- >> Kazuho Oku > --=20 Kazuho Oku From nobody Fri Feb 2 06:41:00 2018 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 ADA5012D84F for ; Fri, 2 Feb 2018 06:40:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ericsson.com header.b=McDcnP5/; dkim=pass (1024-bit key) header.d=ericsson.com header.b=KSxbzsn2 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 rZaAgBaCPLzN for ; Fri, 2 Feb 2018 06:40:54 -0800 (PST) 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 1F0B812D881 for ; Fri, 2 Feb 2018 06:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1517582452; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=2Y/S6f4sa7Is5rfHhv87A9FA0IZanSOtycNTBjsiMcs=; b=McDcnP5/t1NNRa6EtojQu/z+kKHda4WLtRx3LAb/lKzPMESF+SiRQ6sYGBwSQr+Q /PIfeEW2EIscGewXjdDcWtibl36ggws6DaPayJlTHWiuW2BRYiGABoHxvuVW1R9y NoHWZb4j+E1iKL2tGuqfk1IZIrLsfepkwZYBjavae1c=; X-AuditID: c1b4fb2d-b35ff70000007932-1e-5a7478739b97 Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.183.51]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BF.F8.31026.378747A5; Fri, 2 Feb 2018 15:40:52 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 2 Feb 2018 15:40:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2Y/S6f4sa7Is5rfHhv87A9FA0IZanSOtycNTBjsiMcs=; b=KSxbzsn2VfIHzNGjWRabGLOExVSi4PzdLEJO1e8Kc5DR931VrJ42T03ANTXKjetQk6MWaYGkGlM4PSu6y++eUib0DEl0N+sT0zQst4rsxCNZcawWmfN98YjDNy45hjWN4PXWbp54xe7aSkKrSWRuBQdDJ8Uqkgbu4sggVkjw8/0= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3771.eurprd07.prod.outlook.com (52.133.7.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Fri, 2 Feb 2018 14:40:49 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::7d7f:f386:c50f:28d0]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::7d7f:f386:c50f:28d0%13]) with mapi id 15.20.0464.012; Fri, 2 Feb 2018 14:40:49 +0000 From: Ingemar Johansson S To: "ekinnear@apple.com" CC: QUIC WG , Ian Swett , "Lubashev, Igor" , Christian Huitema , "De Schepper, Koen (Nokia - BE/Antwerp)" Subject: RE: ECN in QUIC connection migration Thread-Topic: ECN in QUIC connection migration Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25AAZWcAAACCgj4A= Date: Fri, 2 Feb 2018 14:40:49 +0000 Message-ID: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> In-Reply-To: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3771; 7:QU2yfq9dhtitQ0aOgSk/AJ1B7hmv8fR8VRaIhi24OD+dgUNauEP+aCmTXivW7azLeDj/PDqystlP7btIaB5FFchhHT1vVQ9lgM2iTDwRTO3Id/CciZ68CTM/F8ydkArGWm7aG6BBqA3olY43lfLfdExrq8lrbIDBGVR/dGfANEL1oODMXhiVMkGLHWZvPUZ3FZVdIJOYuZD1KZ8l7z1fxcFBHLxRMypxMlFL52XrzLrwt+gJylZkiJX9vAEyJ3/T x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 19e0e02a-3482-4a7d-fdcf-08d56a4af3f2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3771; x-ms-traffictypediagnostic: HE1PR0702MB3771: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(166708455590820)(211936372134217)(202460600054446)(153496737603132)(21748063052155)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231101)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0702MB3771; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3771; x-forefront-prvs: 05715BE7FD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(39860400002)(39380400002)(346002)(199004)(189003)(51914003)(9686003)(6306002)(8936002)(55016002)(790700001)(186003)(6116002)(74316002)(53936002)(606006)(3846002)(236005)(97736004)(8666007)(2906002)(2900100001)(7736002)(229853002)(86362001)(59450400001)(5660300001)(68736007)(14454004)(478600001)(6246003)(5640700003)(99286004)(4326008)(966005)(54896002)(6436002)(66066001)(5250100002)(3280700002)(76176011)(19609705001)(54906003)(316002)(105586002)(25786009)(5630700001)(106356001)(2501003)(6506007)(7696005)(53546011)(6916009)(8676002)(26005)(9326002)(33656002)(1730700003)(102836004)(2351001)(3660700001)(2950100002)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3771; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: lNQF+lS4iQcEPegq3N96ffSE/YZ7r1bGEXpgaiS4ipbetHXo+e3FLQOG0PAG2CRyRsnMQy5MvbtM/a44b3/Cug== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB3625B28D967738A0EE8A2BABC2F90HE1PR0702MB3625_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 19e0e02a-3482-4a7d-fdcf-08d56a4af3f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2018 14:40:49.4299 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3771 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85OzvOjpyW4pNllxHdyGXZh1Ea9akJ2YWIYh+ykQeVthk7 UzSIbFaITjJMTae1SstbWTLNruQqa5q1DK1EXU7TRgZdl5ZW294Ffvv9///ned/neXkZUuoQ RTCpOgOv16k1MlpCle29GRNlyDSoop3llML0ZYui6JhZrJgcvCVSGLNrSEW7p5pQmCzBm2hl 0SMLqWy2T9BKS1O6su9sB6WsqpoklEbPRXoHrZLEJvGa1Axev3rjfknKo7pz9CHXdZSZW++g slFuA8pDQQxw66DNZaLzkISRcg8RvPtyl8TiCYLevwWET1DcVwKq+yfEOCkmwF3rEWExiuBJ Tpf/MJqLhVrbTz+HclFgHnyNfEUk50IwXT1K+oI53qDZ2EniIjm4TcdFmNeD63ijnyluCThP NhE+Zrn9MGHuDdxWhKDr3CDlC4K4OChsqPQz4iLB+RP7JBcOfSPnCbweB1V3X5CYw8A9/EeE 6w/A17cFIuwvgqluF405ErrP5/unBq6FgA5HCYUDOTSf/hR4swS4UvZQjLkDwdjzfZhXwase V8BPg/5nxYHeawg6TVp8aAUJvZ5W70SMV8yH/PHoQiQvnzF3uTchve1nemLL/fvPBnvZCIXt FdB4ezWuXgxn8ofEmJfDiYpK8UzfgsR1KEzgBUGbvDZGzutTDwhCmk6u4w1NyPvP2qy/o1pR /cfNNsQxSDaLzTEYVFKROkPI0toQMKQslG1J8FpskjrrMK9PS9Sna3jBhuYxlCyctcezKimX rDbwB3n+EK//nxJMUEQ2WkB8kpXmFNwngqemzVnDkrkbQubZg921jn2Pa+IvPGj/YX5qtS22 HCmc86bf+Ov91d1j4vptxeaFKcu2G63LJldppJV3dg2x7frLR/O2J9778HnBy51dW0MyYuKc S0vN+Y0D/Pe6G+OXuscf74lgNcsL558YOFWjbf2x49udg3+tKSUySkhRr1lJ6gX1PzZF0p5j AwAA 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, 02 Feb 2018 14:40:58 -0000 --_000_HE1PR0702MB3625B28D967738A0EE8A2BABC2F90HE1PR0702MB3625_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLg0KWW91IGFyZSByaWdodCwgZXZlbnR1YWxseSB0 aGUgc3BlY2lmaWNzIGFyb3VuZCBFQ04gY2FwYWJpbGl0eSBhdCBjb25uZWN0aW9uIG1pZ3JhdGlv biBzaG91bGQgYmUgdmVyeSBzaW1wbGUuIEkgY2hvc2UgdG8gb3ZlcnNwZWNpZnkgdGhlIHRleHQs IGhvcGVmdWxseSB0byBtYWtlIGl0IHN1ZmZpY2llbnRseSBjbGVhciB0aGF0IGJ5dGUgY291bnRl cnMgc2hvdWxkIGRvIHRoZSBqb2IganVzdCBmaW5lLg0KDQovSW5nZW1hcg0KDQpGcm9tOiBla2lu bmVhckBhcHBsZS5jb20gW21haWx0bzpla2lubmVhckBhcHBsZS5jb21dDQpTZW50OiBkZW4gMiBm ZWJydWFyaSAyMDE4IDAwOjAyDQpUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb20+DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IElhbiBT d2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2Ft YWkuY29tPjsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBEZSBTY2hl cHBlciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8a29lbi5kZV9zY2hlcHBlckBub2tpYS1i ZWxsLWxhYnMuY29tPg0KU3ViamVjdDogUmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0 aW9uDQoNCkhpIEluZ2VtYXIsDQoNClRoaXMgZ2VuZXJhbGx5IGxvb2tzIGdvb2QgdG8gbWUhDQpB IGZldyBxdWVzdGlvbnMgYW5kIG9ic2VydmF0aW9uczoNCg0KVGhlcmUgYXJlIHR3byB1bmlxdWUg Y2FzZXM6DQogICAgICAgICAgICAgIOKAoiBFQ04gY2FwYWJpbGl0eSBjaGVjayBzdWNjZXNzZnVs IGF0IGluaXRpYWwgY29ubmVjdGlvbiBzZXR1cA0KICAgICAgICAgICAgICDigKIgRUNOIGNhcGFi aWxpdHkgY2hlY2sgZmFpbGVkIGF0IGluaXRpYWwgY29ubmVjdGlvbiBzZXR1cA0KDQpBcmUgdGhl c2UgYWN0dWFsbHkgYW55IGRpZmZlcmVudCBpbiB0ZXJtcyBvZiBhY3Rpb24gdGFrZW4gYnkgYW4g ZW5kcG9pbnQ/DQpJdCBzZWVtcyBsaWtlIG9uIHRoZSBuZXcgbmV0d29yayBwYXRoIHRoZSBlbmRw b2ludCB3b3VsZCBnbyB0aHJvdWdoIHRoZSBzYW1lIHByb2Nlc3Mgb2Y6IChhKSB2ZXJpZnkgRUNO IGNhcGFiaWxpdHkgYW5kIGlmIHN1Y2Nlc3NmdWwgdG8gd2hhdGV2ZXIgZGVncmVlIHRoZW4gKGIp IHJ1biB0aGUgcmVzdCBvZiB0aGUgRUNOIG1hY2hpbmVyeSBhcyBhcHByb3ByaWF0ZS4NCg0KSW4g b3RoZXIgd29yZHMsIGFzIGxvbmcgYXMgeW91IGFsbG93IHBlb3BsZSB0byBzdGFydCB1c2luZyBF Q04gdXBvbiBtaWdyYXRpb24gKGluIG90aGVyIHdvcmRzLCB0byBhbGxvdyBzdGFydGluZyBpdCBh ZnRlciB0aGUgaW5pdGlhbCBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQpLCB0aGVuIHRoZSBzcGVj aWZpY3MgZm9yIEVDTiB3aXRoIG1pZ3JhdGlvbiBpcyBlc3NlbnRpYWxseSBvbmUgc3RhdGVtZW50 LCB3aGljaCBpcyDigJxkbyB0aGUgRUNOIHByb2Nlc3Mgb24gZWFjaCBuZXcgbmV0d29yayBwYXRo IHRoYXQgeW91IHVzZeKAnS4NCg0KQ29ubmVjdGlvbiBtaWdyYXRpb24gaGFzIGltcGFjdCBvbiB0 aGUgbnVtYmVyIG9mIHJlcG9ydGVkIENFIG1hcmtlZCBwYWNrZXRzLiBBIG5ldyBjb25uZWN0aW9u IHN0YXRlIHdpdGggbmV3IGNvbmdlc3Rpb24gY29udHJvbCBzdGF0ZSBhbmQgRUNOIGNvdW50ZXJz IGlzIGluc3RhbnRpYXRlZCBhdCB0aGUgc2VuZGVyIGFuZCByZWNlaXZlci4gVGhlIEVDTiBjb3Vu dGVycyBNVVNUIHN0YXJ0IGZyb20gemVybyBhZ2Fpbi4NCg0KVGhpcyBzZWVtcyBmaW5lIHRvIG1l LCBpdOKAmXMgaW5saW5lIHdpdGggdGhlIHJlc3Qgb2YgdGhlIGNvbmdlc3Rpb24gY29udHJvbC9s b3NzIHJlY292ZXJ5IHN0YXRlIHRoYXQgYWxzbyBuZWVkcyB0byBiZSByZXNldCBmb3IgdGhlIG5l dyBwYXRoLg0KDQpHaXZlbiB0aGF0IGVhY2ggbWlncmF0aW9uIHJlcXVpcmVzIGF0IGxlYXN0IG9u ZSBleGNoYW5nZSBvZiBwYWNrZXRzIGF0IHRoZSBiZWdpbm5pbmcgKGF0IHRoZSB2ZXJ5IGxlYXN0 IGZvciBhZGRyZXNzIHZhbGlkYXRpb24gZnJvbSB0aGUgc2lkZSBvZiB0aGUgZW5kcG9pbnQgdGhh dCBkaWRu4oCZdCBtaWdyYXRlKSwgaXQgc2VlbXMgbGlrZSB0aGF04oCZcyBhbiBleGNlbGxlbnQg bW9tZW50IHRvIG1hcmsgdGhlIHBhY2tldHMgYW5kIHBlcmZvcm0gdGhlIEVDTiBjYXBhYmlsaXR5 IGRldGVjdGlvbi4gVGhvc2UgcGFja2V0cyBhcmUgYWxzbyBsaWtlbHkgcGFkZGVkLCBldGMuIHNp bWlsYXIgdG8gaW5pdGlhbCBwYWNrZXRzIHNpbmNlIHRoZXnigJlyZSBvbiBhIHByZXZpb3VzbHkg dW51c2VkIG5ldHdvcmsgcGF0aC4NCg0KSSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NlZCByZXF1 aXJlbWVudCBvZiBqdXN0IHVzaW5nIHRoZSDigJxmaXJzdOKAnSBwYWNrZXRzIGFuZCBtYXJraW5n IHRob3NlIGlzIHN1ZmZpY2llbnQgKGFuZCBnb29kIHRvIGF2b2lkIGFueSByZXF1aXJlbWVudCBh cyB0byB3aGljaCBmcmFtZXMgYXJlIGNvbnRhaW5lZCBpbiB0aG9zZSBwYWNrZXRzKSwgc2luY2Ug d2UgYXJlIGFsd2F5cyBleGNoYW5naW5nIHBhY2tldHMgaW4gYm90aCBkaXJlY3Rpb25zIGltbWVk aWF0ZWx5IGFmdGVyIG1pZ3JhdGlvbi4NCg0KVGhpcyBoYXMgdGhlIGFkZGVkIGJlbmVmaXQgc3Vj aCB0aGF0IGFueSBlbmRwb2ludCDigJxwcm9iaW5n4oCdIHBvc3NpYmxlIG5ldHdvcmsgcGF0aHMg Y291bGQgaW5jbHVkZSB0aGUgYml0cyBuZWNlc3NhcnkgdG8gZGV0ZWN0IEVDTiBjYXBhYmlsaXR5 IG9uIHRoZSBwYXRoIGJlaW5nIHByb2JlZCwgc28gaXQgY291bGQgZXZlbiBrbm93IGJlZm9yZSBt aWdyYXRpbmcgd2hldGhlciBvciBub3QgaXQgd291bGQgYmUgYWJsZSB0byB1c2UgRUNOIG9uIHRo YXQgbmV3IHBhdGguDQoNClRoYW5rcywNCkVyaWMNCg0KDQoNCg0KT24gRmViIDEsIDIwMTgsIGF0 IDM6MDcgQU0sIEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nz b24uY29tPG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0K DQpIaQ0KSSBoYXZlIHdyaXR0ZW4gdXAgZGlmZmVyZW50IGFzcGVjdHMgb2YgY29ubmVjdGlvbiBt aWdyYXRpb24gYW5kIGhvdyBpdCBwbGF5cyB3aXRoIEVDTi4NCmh0dHBzOi8vZ2l0aHViLmNvbS9x dWljd2cvYmFzZS1kcmFmdHMvd2lraS9FQ04taW4tUVVJQyN0cmFuc3BvcnQtZHJhZnQtY29ubmVj dGlvbi1taWdyYXRpb24NCg0KQSBjYXZlYXQuLiBJIGFtIGEgYml0IHVuc3VyZSBhYm91dCB0aGUg ZGVmaW5pdGlvbiBvZiBjb25uZWN0aW9uIG1pZ3JhdGlvbiAuIE15IGludGVycHJldGF0aW9uIGlz IHRoYXQgYSBjbGllbnQgbW92ZXMgdG8gYSBuZXcgSVAgYWRkcmVzcyBkdWUgdG8gZS5nLiBhIE5B VCByZWJpbmQgb3Igc3dpdGNoIGZyb20gV2lGaSB0byBjZWxsdWxhciwgcmlnaHQgPy4gSXMgYSBu ZXcgY29ubmVjdGlvbiBpbnN0YW50aWF0ZWQgYXQgYSBjb25uZWN0aW9uIG1pZ3JhdGlvbiA/DQoN Ci9JbmdlbWFyDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCkluZ2VtYXIg Sm9oYW5zc29uICBNLlNjLg0KTWFzdGVyIFJlc2VhcmNoZXINCg0KRXJpY3Nzb24gUmVzZWFyY2gN Ck5ldHdvcmsgUHJvdG9jb2xzICYgRTJFIFBlcmZvcm1hbmNlDQpMYWJyYXRvcmllZ3LDpG5kIDEx DQo5NzEgMjgsIEx1bGXDpSwgU3dlZGVuDQpQaG9uZSArNDYtMTA3MSA0MzA0Mg0KU01TL01NUyAr NDYtNzMgMDc4IDMyODkNCmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPG1haWx0bzpp bmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCnd3dy5lcmljc3Nvbi5jb208eC1tc2c6 Ly8zMTYvd3d3LmVyaWNzc29uLmNvbT4NCg0KICAgICAgICAgICAgICAgICBZb3UgY2FuJ3Qgc3Rh cnQgYSBmaXJlDQogIFdvcnJ5aW5nICdib3V0IHlvdXIgbGl0dGxlIHdvcmxkIGZhbGxpbmcgYXBh cnQNCiAgICAgICAgICAgICAgIEJydWNlIFNwcmluZ3N0ZWVuDQo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQoNCg== --_000_HE1PR0702MB3625B28D967738A0EE8A2BABC2F90HE1PR0702MB3625_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQg NzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSBjb21t ZW50cy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgYXJlIHJpZ2h0 LCBldmVudHVhbGx5IHRoZSBzcGVjaWZpY3MgYXJvdW5kIEVDTiBjYXBhYmlsaXR5IGF0IGNvbm5l Y3Rpb24gbWlncmF0aW9uIHNob3VsZCBiZSB2ZXJ5IHNpbXBsZS4gSSBjaG9zZSB0byBvdmVyc3Bl Y2lmeSB0aGUgdGV4dCwgaG9wZWZ1bGx5IHRvIG1ha2UgaXQgc3VmZmljaWVudGx5IGNsZWFyIHRo YXQgYnl0ZSBjb3VudGVycyBzaG91bGQgZG8gdGhlIGpvYiBqdXN0IGZpbmUuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IGVraW5uZWFyQGFwcGxlLmNvbSBbbWFpbHRvOmVraW5uZWFyQGFwcGxlLmNvbV0gPGJyPg0K PGI+U2VudDo8L2I+IGRlbiAyIGZlYnJ1YXJpIDIwMTggMDA6MDI8YnI+DQo8Yj5Ubzo8L2I+IElu Z2VtYXIgSm9oYW5zc29uIFMgJmx0O2luZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0 Ozxicj4NCjxiPkNjOjwvYj4gUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IElhbiBTd2V0 dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNo ZUBha2FtYWkuY29tJmd0OzsgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5u ZXQmZ3Q7OyBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJwKSAmbHQ7a29lbi5k ZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogRUNOIGluIFFVSUMgY29ubmVjdGlvbiBtaWdyYXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpIEluZ2VtYXIsJm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGdlbmVyYWxseSBsb29rcyBnb29kIHRvIG1l ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QSBm ZXcgcXVlc3Rpb25zIGFuZCBvYnNlcnZhdGlvbnM6Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij5UaGVyZSBhcmUgdHdvIHVuaXF1ZSBjYXNlczo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+4oCiIEVDTiBjYXBhYmlsaXR5IGNoZWNrIHN1Y2Nlc3Nm dWwgYXQgaW5pdGlhbCBjb25uZWN0aW9uIHNldHVwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+4oCiIEVDTiBjYXBhYmlsaXR5IGNoZWNrIGZhaWxl ZCBhdCBpbml0aWFsIGNvbm5lY3Rpb24gc2V0dXA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgdGhlc2UgYWN0dWFsbHkgYW55 IGRpZmZlcmVudCBpbiB0ZXJtcyBvZiBhY3Rpb24gdGFrZW4gYnkgYW4gZW5kcG9pbnQ/PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyBs aWtlIG9uIHRoZSBuZXcgbmV0d29yayBwYXRoIHRoZSBlbmRwb2ludCB3b3VsZCBnbyB0aHJvdWdo IHRoZSBzYW1lIHByb2Nlc3Mgb2Y6IChhKSB2ZXJpZnkgRUNOIGNhcGFiaWxpdHkgYW5kIGlmIHN1 Y2Nlc3NmdWwgdG8gd2hhdGV2ZXIgZGVncmVlIHRoZW4gKGIpIHJ1biB0aGUgcmVzdCBvZiB0aGUg RUNOIG1hY2hpbmVyeSBhcyBhcHByb3ByaWF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gb3RoZXIgd29yZHMsIGFzIGxvbmcgYXMgeW91 IGFsbG93IHBlb3BsZSB0byBzdGFydCB1c2luZyBFQ04gdXBvbiBtaWdyYXRpb24gKGluIG90aGVy IHdvcmRzLCB0byBhbGxvdyBzdGFydGluZyBpdCBhZnRlciB0aGUgaW5pdGlhbCBjb25uZWN0aW9u IGVzdGFibGlzaG1lbnQpLCB0aGVuIHRoZSBzcGVjaWZpY3MgZm9yIEVDTiB3aXRoIG1pZ3JhdGlv biBpcyBlc3NlbnRpYWxseSBvbmUgc3RhdGVtZW50LCB3aGljaA0KIGlzIOKAnGRvIHRoZSBFQ04g cHJvY2VzcyBvbiBlYWNoIG5ldyBuZXR3b3JrIHBhdGggdGhhdCB5b3UgdXNl4oCdLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNv bm5lY3Rpb24gbWlncmF0aW9uIGhhcyBpbXBhY3Qgb24gdGhlIG51bWJlciBvZiByZXBvcnRlZCBD RSBtYXJrZWQgcGFja2V0cy4gQSBuZXcgY29ubmVjdGlvbiBzdGF0ZSB3aXRoIG5ldyBjb25nZXN0 aW9uJm5ic3A7Y29udHJvbCBzdGF0ZSBhbmQgRUNOIGNvdW50ZXJzIGlzIGluc3RhbnRpYXRlZCBh dCB0aGUgc2VuZGVyIGFuZCByZWNlaXZlci4gVGhlIEVDTiBjb3VudGVycyBNVVNUIHN0YXJ0IGZy b20gemVybyBhZ2Fpbi48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyBzZWVtcyBmaW5lIHRvIG1lLCBpdOKAmXMgaW5saW5lIHdpdGggdGhl IHJlc3Qgb2YgdGhlIGNvbmdlc3Rpb24gY29udHJvbC9sb3NzIHJlY292ZXJ5IHN0YXRlIHRoYXQg YWxzbyBuZWVkcyB0byBiZSByZXNldCBmb3IgdGhlIG5ldyBwYXRoLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiB0aGF0IGVh Y2ggbWlncmF0aW9uIHJlcXVpcmVzIGF0IGxlYXN0IG9uZSBleGNoYW5nZSBvZiBwYWNrZXRzIGF0 IHRoZSBiZWdpbm5pbmcgKGF0IHRoZSB2ZXJ5IGxlYXN0IGZvciBhZGRyZXNzIHZhbGlkYXRpb24g ZnJvbSB0aGUgc2lkZSBvZiB0aGUgZW5kcG9pbnQgdGhhdCBkaWRu4oCZdCBtaWdyYXRlKSwgaXQg c2VlbXMgbGlrZSB0aGF04oCZcyBhbiBleGNlbGxlbnQgbW9tZW50IHRvIG1hcmsgdGhlIHBhY2tl dHMNCiBhbmQgcGVyZm9ybSB0aGUgRUNOIGNhcGFiaWxpdHkgZGV0ZWN0aW9uLiBUaG9zZSBwYWNr ZXRzIGFyZSBhbHNvIGxpa2VseSBwYWRkZWQsIGV0Yy4gc2ltaWxhciB0byBpbml0aWFsIHBhY2tl dHMgc2luY2UgdGhleeKAmXJlIG9uIGEgcHJldmlvdXNseSB1bnVzZWQgbmV0d29yayBwYXRoLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIHRoaW5rIHRoZSBjdXJyZW50IHByb3Bvc2VkIHJlcXVpcmVtZW50IG9mIGp1c3QgdXNpbmcg dGhlIOKAnGZpcnN04oCdIHBhY2tldHMgYW5kIG1hcmtpbmcgdGhvc2UgaXMgc3VmZmljaWVudCAo YW5kIGdvb2QgdG8gYXZvaWQgYW55IHJlcXVpcmVtZW50IGFzIHRvIHdoaWNoIGZyYW1lcyBhcmUg Y29udGFpbmVkIGluIHRob3NlIHBhY2tldHMpLCBzaW5jZSB3ZSBhcmUgYWx3YXlzIGV4Y2hhbmdp bmcgcGFja2V0cyBpbg0KIGJvdGggZGlyZWN0aW9ucyBpbW1lZGlhdGVseSBhZnRlciBtaWdyYXRp b24uJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoaXMgaGFzIHRoZSBhZGRlZCBiZW5lZml0IHN1Y2ggdGhhdCBhbnkgZW5kcG9pbnQg 4oCccHJvYmluZ+KAnSBwb3NzaWJsZSBuZXR3b3JrIHBhdGhzIGNvdWxkIGluY2x1ZGUgdGhlIGJp dHMgbmVjZXNzYXJ5IHRvIGRldGVjdCBFQ04gY2FwYWJpbGl0eSBvbiB0aGUgcGF0aCBiZWluZyBw cm9iZWQsIHNvIGl0IGNvdWxkIGV2ZW4ga25vdyBiZWZvcmUgbWlncmF0aW5nIHdoZXRoZXIgb3Ig bm90IGl0IHdvdWxkIGJlIGFibGUNCiB0byB1c2UgRUNOIG9uIHRoYXQgbmV3IHBhdGguJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo YW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkVyaWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBGZWIgMSwgMjAxOCwgYXQgMzowNyBBTSwgSW5nZW1hciBKb2hhbnNz b24gUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29t Ij5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSB3cml0dGVuIHVwIGRp ZmZlcmVudCBhc3BlY3RzIG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uIGFuZCBob3cgaXQgcGxheXMg d2l0aCBFQ04uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kv RUNOLWluLVFVSUMjdHJhbnNwb3J0LWRyYWZ0LWNvbm5lY3Rpb24tbWlncmF0aW9uIj48c3BhbiBz dHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRz L3dpa2kvRUNOLWluLVFVSUMjdHJhbnNwb3J0LWRyYWZ0LWNvbm5lY3Rpb24tbWlncmF0aW9uPC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QSBjYXZlYXQuLiBJIGFtIGEgYml0IHVuc3VyZSBhYm91dCB0aGUgZGVmaW5pdGlvbiBv ZiBjb25uZWN0aW9uIG1pZ3JhdGlvbiAuIE15IGludGVycHJldGF0aW9uIGlzIHRoYXQgYSBjbGll bnQgbW92ZXMgdG8gYSBuZXcgSVAgYWRkcmVzcyBkdWUgdG8gZS5nLiBhIE5BVCByZWJpbmQgb3Ig c3dpdGNoIGZyb20gV2lGaSB0byBjZWxsdWxhciwgcmlnaHQgPy4gSXMgYSBuZXcgY29ubmVjdGlv biBpbnN0YW50aWF0ZWQNCiBhdCBhIGNvbm5lY3Rpb24gbWlncmF0aW9uID88c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+L0luZ2VtYXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5JbmdlbWFyIEpv aGFuc3NvbiZuYnNwOyBNLlNjLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk1hc3RlciBSZXNlYXJjaGVyPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+RXJpY3Nzb24gUmVzZWFyY2g8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5OZXR3b3JrIFByb3RvY29scyAmYW1wOyBFMkUgUGVyZm9ybWFuY2U8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5MYWJyYXRvcmllZ3LDpG5kIDExPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+OTcx IDI4LCBMdWxlw6UsIFN3ZWRlbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlBob25lICYjNDM7NDYtMTA3MSA0 MzA0Mjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlNNUy9NTVMgJiM0Mzs0Ni03MyAwNzggMzI4OTwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNv bSI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPmluZ2VtYXIucy5qb2hhbnNzb25AZXJp Y3Nzb24uY29tPC9zcGFuPjwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJ4LW1zZzovLzMx Ni93d3cuZXJpY3Nzb24uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+d3d3LmVy aWNzc29uLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOiNDQ0NDREQi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlvdSBjYW4ndCBzdGFydCBhIGZpcmU8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyBX b3JyeWluZyAnYm91dCB5b3VyIGxpdHRsZSB3b3JsZCBmYWxsaW5nIGFwYXJ0PC9zcGFuPjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7YmFja2dyb3VuZDp3aGl0ZSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEJydWNlIFNwcmluZ3N0ZWVuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_HE1PR0702MB3625B28D967738A0EE8A2BABC2F90HE1PR0702MB3625_-- From nobody Fri Feb 2 06:44:32 2018 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 42EB912D87A for ; Fri, 2 Feb 2018 06:44:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=nokia.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 lEGNHUqxy0UU for ; Fri, 2 Feb 2018 06:44:27 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50097.outbound.protection.outlook.com [40.107.5.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEAFD12D84F for ; Fri, 2 Feb 2018 06:44:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zjHqvG1RbMzvTFmpZwY+cCTDHR8NvhC9We24bSaqY4A=; b=PM0VjpJCBe8T5cyrsZFvDxkzu5F6DGlAR+oML1Y+32PHRNvG3vOYojPBzXIfy+gtM/jl9CLQjMvRzzw2TEwrkKUL/FLk4LfNdGu/UdKmp2r+447+Q2NPcwz0QG4A8t2F36yHfvHZCS/GeTAqr2VCDFExafNh27O/zbO9SrlQs7k= Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com (10.169.137.7) by VI1PR0701MB2944.eurprd07.prod.outlook.com (10.173.72.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Fri, 2 Feb 2018 14:44:24 +0000 Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::a16e:3b1a:be89:10fa]) by VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::a16e:3b1a:be89:10fa%15]) with mapi id 15.20.0464.008; Fri, 2 Feb 2018 14:44:24 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: "ekinnear@apple.com" , Ingemar Johansson S CC: QUIC WG , Ian Swett , "Lubashev, Igor" , Christian Huitema Subject: RE: ECN in QUIC connection migration Thread-Topic: ECN in QUIC connection migration Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25AAZWcAAAB/s3/A= Date: Fri, 2 Feb 2018 14:44:24 +0000 Message-ID: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> In-Reply-To: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=koen.de_schepper@nokia-bell-labs.com; x-originating-ip: [213.49.86.189] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB2944; 7:A2XDjstxbMC+Taw5c+8odOJGU4u8fGfjiHtZw4va44LbSjzcL1jK1ALJtJsW1HO/oZXa376qJSLtNMM08I7pvcBREqyl79ihZaQ0jxOaGGHYeQiqZpslzS8Pe+uHhOyIOxb0j/mSZBcBbrv64qTOa/lbJjPHZfF8sXhwld3StW9AcFs5kQwDYYYyZt1Var5qoSoWhuYuBWgL81+F39eoQmQIW3mqN491IZixYEzzlHhbtGSKJvukrP7dZmnRrOGR x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8eff7e94-a552-423b-c441-08d56a4b73f2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:VI1PR0701MB2944; x-ms-traffictypediagnostic: VI1PR0701MB2944: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(166708455590820)(211936372134217)(202460600054446)(153496737603132)(21748063052155)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231101)(11241501184)(2400082)(944501161)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:VI1PR0701MB2944; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB2944; x-forefront-prvs: 05715BE7FD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39380400002)(39860400002)(376002)(396003)(199004)(189003)(229853002)(6306002)(25786009)(966005)(4326008)(7696005)(478600001)(14454004)(66066001)(2906002)(6246003)(53936002)(97736004)(110136005)(2900100001)(86362001)(19609705001)(99286004)(68736007)(54906003)(2501003)(5250100002)(186003)(105586002)(3660700001)(76176011)(6506007)(5660300001)(3280700002)(6116002)(790700001)(2950100002)(9326002)(3846002)(102836004)(106356001)(59450400001)(606006)(8936002)(33656002)(53546011)(74316002)(6436002)(8666007)(55016002)(236005)(9686003)(81156014)(81166006)(7736002)(26005)(8676002)(54896002)(316002)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB2944; H:VI1PR0701MB2126.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: DgUbgblz9XmVDcwSdp3/kXnRTN8fjrF93aAWHof8xUI+hOASMLe9/zevGwbXwU0pmkKdCBEf5cKDq5B3KzRDQA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB2126E79A17DB715F6C91EA05B9F90VI1PR0701MB2126_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8eff7e94-a552-423b-c441-08d56a4b73f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2018 14:44:24.2393 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2944 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, 02 Feb 2018 14:44:30 -0000 --_000_VI1PR0701MB2126E79A17DB715F6C91EA05B9F90VI1PR0701MB2126_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSW5nZW1hciwNCg0KSSBhbHNvIHJlYWQgYWdhaW4gdGhyb3VnaCB0aGUgZG9jdW1lbnQsIGFu ZCBoYWQgZm9sbG93aW5nIGNvbW1lbnRzOg0KDQpJIHJlcGxhY2VkOg0K4oCcVGhlIEFDS19FQ04g ZnJhbWUgaXMgdXNlZCB0byBjb252ZXkgQUNLcyB3aGVuIHRoZSBFQ04gY2FwYWJpbGl0eSBleGNo YW5nZSBjb25jbHVkZXMgdGhhdCBFQ04gc2hvdWxkIGJlIHVzZWQgZm9yIHRoZSBnaXZlbiBjb25u ZWN0aW9uLuKAnQ0KT3JpZ2luYWxseSBpdCBzb3VuZHMgYXMgaWYgdGhlIGNvdW50ZXJzIGFyZSBu b3QgZWNob2VkIGFueW1vcmUgaWYgdGhlIEVDTiBjYXBhYmlsaXR5IGNoZWNrIGZhaWxzLiBJIGFz c3VtZSB0aGlzIHdhcyBub3QgdGhlIGludGVudGlvbiwgYnV0IGlmIGl0IGlzOiBGaXJzdCwgd2Ug ZG9u4oCZdCBoYXZlIGEgcHJvdG9jb2wgb3IgZGVjaXNpb24gcG9pbnQgZGVmaW5lZCB3aGVuIHRo YXQgY29uZGl0aW9uIGlzIG1ldCAoc2VuZGVyIHNob3VsZCBsZXQgdGhlIHJlY2VpdmVyIGtub3cg aW4gdGhlIG5leHQgcGFja2V0KSwgYW5kIHNlY29uZCwgSSB3b3VsZCBhbHdheXMgc2VuZCB0aGUg ZWNobywgYXMgd2UgbWlnaHQg4oCcdHJ5IGFnYWluIGxhdGVyICh3aXRoIGFub3RoZXIgRUNUPyni gJ0sIG9yIG1pZ2h0IGRlY2lkZSB0byB1c2UgdGhlIEVDTiBiaXRzIGRpZmZlcmVudGx5IGxhdGVy Lg0KDQpJIGFsc28gY2hhbmdlZCB0aGUgdGV4dCBhcm91bmQgdGhlIGNvbm5lY3Rpb24gbWlncmF0 aW9uLCBJIHRoaW5rIGJlZm9yZSBFcmljIHJldmlld2VkIGl0LiBJIG1hZGUgaXQgc3VjaCB0aGF0 IGV2ZXJ5IG5ldyBwYXRoIGNyZWF0ZXMgYSBuZXcgY29ubmVjdGlvbiBzdGF0ZSB3aXRoIGFuIGlu aXRpYWxpemVkIGNvbmdlc3Rpb24gY29udHJvbCBzdGF0ZSBhbmQgRUNOIGNvdW50ZXJzIChhdCBs ZWFzdCBFQ04gY291bnRlcnMgcmVzZXQgdG8gMHMpLiBOb3Qgc3VyZSBpZiB0aGlzIG1hdGNoZXMg d2l0aCB0aGUgb3RoZXIgc2VjdGlvbnMgaW4gdGhlIFFVSUMgZHJhZnQuDQoNCkkgYWxzbyBoYWQg dGhlIHRob3VnaHQgd2hldGhlciBpdCB3YXMgcmVhbGx5IG5lZWRlZCB0byBoYXZlIHRoZSAyIGNh c2VzLiBJIGFncmVlIHdlIHNob3VsZCBzaW1wbGlmeSwgYnkganVzdCBzdGFydGluZyBvdmVyIGFu ZCBkb2luZyB0aGUgY2hlY2sgdW5jb25kaXRpb25hbGx5IHdoZXRoZXIgaXQgd2FzIHN1Y2Nlc3Nm dWwgb3Igbm90IGluIGEgcHJldmlvdXMgcGF0aC4NCg0KUmVnYXJkcywNCktvZW4uDQoNCkZyb206 IGVraW5uZWFyQGFwcGxlLmNvbSBbbWFpbHRvOmVraW5uZWFyQGFwcGxlLmNvbV0NClNlbnQ6IEZy aWRheSwgRmVicnVhcnkgMiwgMjAxOCAxMjowMiBBTQ0KVG86IEluZ2VtYXIgSm9oYW5zc29uIFMg PGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBMdWJhc2hldiwgSWdvciA8 aWx1YmFzaGVAYWthbWFpLmNvbT47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEu bmV0PjsgRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCkgPGtvZW4uZGVfc2No ZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbT4NClN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQyBjb25u ZWN0aW9uIG1pZ3JhdGlvbg0KDQpIaSBJbmdlbWFyLA0KDQpUaGlzIGdlbmVyYWxseSBsb29rcyBn b29kIHRvIG1lIQ0KQSBmZXcgcXVlc3Rpb25zIGFuZCBvYnNlcnZhdGlvbnM6DQoNClRoZXJlIGFy ZSB0d28gdW5pcXVlIGNhc2VzOg0KICAgICAgICAgICAgICAgIOKAoiBFQ04gY2FwYWJpbGl0eSBj aGVjayBzdWNjZXNzZnVsIGF0IGluaXRpYWwgY29ubmVjdGlvbiBzZXR1cA0KICAgICAgICAgICAg ICAgIOKAoiBFQ04gY2FwYWJpbGl0eSBjaGVjayBmYWlsZWQgYXQgaW5pdGlhbCBjb25uZWN0aW9u IHNldHVwDQoNCkFyZSB0aGVzZSBhY3R1YWxseSBhbnkgZGlmZmVyZW50IGluIHRlcm1zIG9mIGFj dGlvbiB0YWtlbiBieSBhbiBlbmRwb2ludD8NCkl0IHNlZW1zIGxpa2Ugb24gdGhlIG5ldyBuZXR3 b3JrIHBhdGggdGhlIGVuZHBvaW50IHdvdWxkIGdvIHRocm91Z2ggdGhlIHNhbWUgcHJvY2VzcyBv ZjogKGEpIHZlcmlmeSBFQ04gY2FwYWJpbGl0eSBhbmQgaWYgc3VjY2Vzc2Z1bCB0byB3aGF0ZXZl ciBkZWdyZWUgdGhlbiAoYikgcnVuIHRoZSByZXN0IG9mIHRoZSBFQ04gbWFjaGluZXJ5IGFzIGFw cHJvcHJpYXRlLg0KDQpJbiBvdGhlciB3b3JkcywgYXMgbG9uZyBhcyB5b3UgYWxsb3cgcGVvcGxl IHRvIHN0YXJ0IHVzaW5nIEVDTiB1cG9uIG1pZ3JhdGlvbiAoaW4gb3RoZXIgd29yZHMsIHRvIGFs bG93IHN0YXJ0aW5nIGl0IGFmdGVyIHRoZSBpbml0aWFsIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVu dCksIHRoZW4gdGhlIHNwZWNpZmljcyBmb3IgRUNOIHdpdGggbWlncmF0aW9uIGlzIGVzc2VudGlh bGx5IG9uZSBzdGF0ZW1lbnQsIHdoaWNoIGlzIOKAnGRvIHRoZSBFQ04gcHJvY2VzcyBvbiBlYWNo IG5ldyBuZXR3b3JrIHBhdGggdGhhdCB5b3UgdXNl4oCdLg0KDQpDb25uZWN0aW9uIG1pZ3JhdGlv biBoYXMgaW1wYWN0IG9uIHRoZSBudW1iZXIgb2YgcmVwb3J0ZWQgQ0UgbWFya2VkIHBhY2tldHMu IEEgbmV3IGNvbm5lY3Rpb24gc3RhdGUgd2l0aCBuZXcgY29uZ2VzdGlvbiBjb250cm9sIHN0YXRl IGFuZCBFQ04gY291bnRlcnMgaXMgaW5zdGFudGlhdGVkIGF0IHRoZSBzZW5kZXIgYW5kIHJlY2Vp dmVyLiBUaGUgRUNOIGNvdW50ZXJzIE1VU1Qgc3RhcnQgZnJvbSB6ZXJvIGFnYWluLg0KDQpUaGlz IHNlZW1zIGZpbmUgdG8gbWUsIGl04oCZcyBpbmxpbmUgd2l0aCB0aGUgcmVzdCBvZiB0aGUgY29u Z2VzdGlvbiBjb250cm9sL2xvc3MgcmVjb3Zlcnkgc3RhdGUgdGhhdCBhbHNvIG5lZWRzIHRvIGJl IHJlc2V0IGZvciB0aGUgbmV3IHBhdGguDQoNCkdpdmVuIHRoYXQgZWFjaCBtaWdyYXRpb24gcmVx dWlyZXMgYXQgbGVhc3Qgb25lIGV4Y2hhbmdlIG9mIHBhY2tldHMgYXQgdGhlIGJlZ2lubmluZyAo YXQgdGhlIHZlcnkgbGVhc3QgZm9yIGFkZHJlc3MgdmFsaWRhdGlvbiBmcm9tIHRoZSBzaWRlIG9m IHRoZSBlbmRwb2ludCB0aGF0IGRpZG7igJl0IG1pZ3JhdGUpLCBpdCBzZWVtcyBsaWtlIHRoYXTi gJlzIGFuIGV4Y2VsbGVudCBtb21lbnQgdG8gbWFyayB0aGUgcGFja2V0cyBhbmQgcGVyZm9ybSB0 aGUgRUNOIGNhcGFiaWxpdHkgZGV0ZWN0aW9uLiBUaG9zZSBwYWNrZXRzIGFyZSBhbHNvIGxpa2Vs eSBwYWRkZWQsIGV0Yy4gc2ltaWxhciB0byBpbml0aWFsIHBhY2tldHMgc2luY2UgdGhleeKAmXJl IG9uIGEgcHJldmlvdXNseSB1bnVzZWQgbmV0d29yayBwYXRoLg0KDQpJIHRoaW5rIHRoZSBjdXJy ZW50IHByb3Bvc2VkIHJlcXVpcmVtZW50IG9mIGp1c3QgdXNpbmcgdGhlIOKAnGZpcnN04oCdIHBh Y2tldHMgYW5kIG1hcmtpbmcgdGhvc2UgaXMgc3VmZmljaWVudCAoYW5kIGdvb2QgdG8gYXZvaWQg YW55IHJlcXVpcmVtZW50IGFzIHRvIHdoaWNoIGZyYW1lcyBhcmUgY29udGFpbmVkIGluIHRob3Nl IHBhY2tldHMpLCBzaW5jZSB3ZSBhcmUgYWx3YXlzIGV4Y2hhbmdpbmcgcGFja2V0cyBpbiBib3Ro IGRpcmVjdGlvbnMgaW1tZWRpYXRlbHkgYWZ0ZXIgbWlncmF0aW9uLg0KDQpUaGlzIGhhcyB0aGUg YWRkZWQgYmVuZWZpdCBzdWNoIHRoYXQgYW55IGVuZHBvaW50IOKAnHByb2JpbmfigJ0gcG9zc2li bGUgbmV0d29yayBwYXRocyBjb3VsZCBpbmNsdWRlIHRoZSBiaXRzIG5lY2Vzc2FyeSB0byBkZXRl Y3QgRUNOIGNhcGFiaWxpdHkgb24gdGhlIHBhdGggYmVpbmcgcHJvYmVkLCBzbyBpdCBjb3VsZCBl dmVuIGtub3cgYmVmb3JlIG1pZ3JhdGluZyB3aGV0aGVyIG9yIG5vdCBpdCB3b3VsZCBiZSBhYmxl IHRvIHVzZSBFQ04gb24gdGhhdCBuZXcgcGF0aC4NCg0KVGhhbmtzLA0KRXJpYw0KDQoNCg0KDQpP biBGZWIgMSwgMjAxOCwgYXQgMzowNyBBTSwgSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5z LmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nz b24uY29tPj4gd3JvdGU6DQoNCkhpDQpJIGhhdmUgd3JpdHRlbiB1cCBkaWZmZXJlbnQgYXNwZWN0 cyBvZiBjb25uZWN0aW9uIG1pZ3JhdGlvbiBhbmQgaG93IGl0IHBsYXlzIHdpdGggRUNOLg0KaHR0 cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1RVUlDI3RyYW5z cG9ydC1kcmFmdC1jb25uZWN0aW9uLW1pZ3JhdGlvbg0KDQpBIGNhdmVhdC4uIEkgYW0gYSBiaXQg dW5zdXJlIGFib3V0IHRoZSBkZWZpbml0aW9uIG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uIC4gTXkg aW50ZXJwcmV0YXRpb24gaXMgdGhhdCBhIGNsaWVudCBtb3ZlcyB0byBhIG5ldyBJUCBhZGRyZXNz IGR1ZSB0byBlLmcuIGEgTkFUIHJlYmluZCBvciBzd2l0Y2ggZnJvbSBXaUZpIHRvIGNlbGx1bGFy LCByaWdodCA/LiBJcyBhIG5ldyBjb25uZWN0aW9uIGluc3RhbnRpYXRlZCBhdCBhIGNvbm5lY3Rp b24gbWlncmF0aW9uID8NCg0KL0luZ2VtYXINCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KSW5nZW1hciBKb2hhbnNzb24gIE0uU2MuDQpNYXN0ZXIgUmVzZWFyY2hlcg0KDQpF cmljc3NvbiBSZXNlYXJjaA0KTmV0d29yayBQcm90b2NvbHMgJiBFMkUgUGVyZm9ybWFuY2UNCkxh YnJhdG9yaWVncsOkbmQgMTENCjk3MSAyOCwgTHVsZcOlLCBTd2VkZW4NClBob25lICs0Ni0xMDcx IDQzMDQyDQpTTVMvTU1TICs0Ni03MyAwNzggMzI4OQ0KaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0Kd3d3LmVy aWNzc29uLmNvbTx4LW1zZzovLzMxNi93d3cuZXJpY3Nzb24uY29tPg0KDQogICAgICAgICAgICAg ICAgIFlvdSBjYW4ndCBzdGFydCBhIGZpcmUNCiAgV29ycnlpbmcgJ2JvdXQgeW91ciBsaXR0bGUg d29ybGQgZmFsbGluZyBhcGFydA0KICAgICAgICAgICAgICAgQnJ1Y2UgU3ByaW5nc3RlZW4NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K --_000_VI1PR0701MB2126E79A17DB715F6C91EA05B9F90VI1PR0701MB2126_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBJbmdlbWFyLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gcmVhZCBhZ2FpbiB0 aHJvdWdoIHRoZSBkb2N1bWVudCwgYW5kIGhhZCBmb2xsb3dpbmcgY29tbWVudHM6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgcmVwbGFjZWQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj7igJxUaGUgQUNLX0VDTiBmcmFtZSBpcyB1c2VkIHRvIGNvbnZleSBBQ0tzIHdoZW4g dGhlIEVDTiBjYXBhYmlsaXR5IGV4Y2hhbmdlIGNvbmNsdWRlcyB0aGF0IEVDTiBzaG91bGQgYmUg dXNlZCBmb3IgdGhlIGdpdmVuIGNvbm5lY3Rpb24u4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PcmlnaW5hbGx5IGl0IHNvdW5kcyBhcyBpZiB0aGUgY291bnRlcnMgYXJl IG5vdCBlY2hvZWQgYW55bW9yZSBpZiB0aGUgRUNOIGNhcGFiaWxpdHkgY2hlY2sgZmFpbHMuIEkg YXNzdW1lIHRoaXMgd2FzIG5vdCB0aGUgaW50ZW50aW9uLCBidXQgaWYgaXQgaXM6IEZpcnN0LCB3 ZSBkb27igJl0IGhhdmUgYSBwcm90b2NvbCBvciBkZWNpc2lvbiBwb2ludCBkZWZpbmVkIHdoZW4g dGhhdCBjb25kaXRpb24gaXMgbWV0IChzZW5kZXINCiBzaG91bGQgbGV0IHRoZSByZWNlaXZlciBr bm93IGluIHRoZSBuZXh0IHBhY2tldCksIGFuZCBzZWNvbmQsIEkgd291bGQgYWx3YXlzIHNlbmQg dGhlIGVjaG8sIGFzIHdlIG1pZ2h0IOKAnHRyeSBhZ2FpbiBsYXRlciAod2l0aCBhbm90aGVyIEVD VD8p4oCdLCBvciBtaWdodCBkZWNpZGUgdG8gdXNlIHRoZSBFQ04gYml0cyBkaWZmZXJlbnRseSBs YXRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbHNvIGNoYW5nZWQgdGhlIHRleHQgYXJv dW5kIHRoZSBjb25uZWN0aW9uIG1pZ3JhdGlvbiwgSSB0aGluayBiZWZvcmUgRXJpYyByZXZpZXdl ZCBpdC4gSSBtYWRlIGl0IHN1Y2ggdGhhdCBldmVyeSBuZXcgcGF0aCBjcmVhdGVzIGEgbmV3IGNv bm5lY3Rpb24gc3RhdGUgd2l0aCBhbiBpbml0aWFsaXplZCBjb25nZXN0aW9uIGNvbnRyb2wgc3Rh dGUgYW5kIEVDTiBjb3VudGVycyAoYXQgbGVhc3QgRUNOIGNvdW50ZXJzDQogcmVzZXQgdG8gMHMp LiBOb3Qgc3VyZSBpZiB0aGlzIG1hdGNoZXMgd2l0aCB0aGUgb3RoZXIgc2VjdGlvbnMgaW4gdGhl IFFVSUMgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBoYWQgdGhlIHRob3Vn aHQgd2hldGhlciBpdCB3YXMgcmVhbGx5IG5lZWRlZCB0byBoYXZlIHRoZSAyIGNhc2VzLiBJIGFn cmVlIHdlIHNob3VsZCBzaW1wbGlmeSwgYnkganVzdCBzdGFydGluZyBvdmVyIGFuZCBkb2luZyB0 aGUgY2hlY2sgdW5jb25kaXRpb25hbGx5IHdoZXRoZXIgaXQgd2FzIHN1Y2Nlc3NmdWwgb3Igbm90 IGluIGEgcHJldmlvdXMgcGF0aC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktvZW4uPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gZWtp bm5lYXJAYXBwbGUuY29tIFttYWlsdG86ZWtpbm5lYXJAYXBwbGUuY29tXSA8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAyLCAyMDE4IDEyOjAyIEFNPGJyPg0KPGI+VG86PC9iPiBJ bmdlbWFyIEpvaGFuc3NvbiBTICZsdDtpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBJYW4gU3dl dHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7OyBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFz aGVAYWthbWFpLmNvbSZndDs7IENocmlzdGlhbiBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEu bmV0Jmd0OzsgRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCkgJmx0O2tvZW4u ZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBJbmdlbWFyLCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBnZW5lcmFsbHkgbG9va3MgZ29vZCB0byBt ZSE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEg ZmV3IHF1ZXN0aW9ucyBhbmQgb2JzZXJ2YXRpb25zOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+VGhlcmUgYXJlIHR3byB1bmlxdWUgY2FzZXM6PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPuKAoiBFQ04gY2FwYWJpbGl0eSBj aGVjayBzdWNjZXNzZnVsIGF0IGluaXRpYWwgY29ubmVjdGlvbiBzZXR1cDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxl LXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPuKAoiBF Q04gY2FwYWJpbGl0eSBjaGVjayBmYWlsZWQgYXQgaW5pdGlhbCBjb25uZWN0aW9uIHNldHVwPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXJlIHRoZXNlIGFjdHVhbGx5IGFueSBkaWZmZXJlbnQgaW4gdGVybXMgb2YgYWN0aW9uIHRh a2VuIGJ5IGFuIGVuZHBvaW50PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SXQgc2VlbXMgbGlrZSBvbiB0aGUgbmV3IG5ldHdvcmsgcGF0aCB0aGUg ZW5kcG9pbnQgd291bGQgZ28gdGhyb3VnaCB0aGUgc2FtZSBwcm9jZXNzIG9mOiAoYSkgdmVyaWZ5 IEVDTiBjYXBhYmlsaXR5IGFuZCBpZiBzdWNjZXNzZnVsIHRvIHdoYXRldmVyIGRlZ3JlZSB0aGVu IChiKSBydW4gdGhlIHJlc3Qgb2YgdGhlIEVDTiBtYWNoaW5lcnkgYXMgYXBwcm9wcmlhdGUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG90 aGVyIHdvcmRzLCBhcyBsb25nIGFzIHlvdSBhbGxvdyBwZW9wbGUgdG8gc3RhcnQgdXNpbmcgRUNO IHVwb24gbWlncmF0aW9uIChpbiBvdGhlciB3b3JkcywgdG8gYWxsb3cgc3RhcnRpbmcgaXQgYWZ0 ZXIgdGhlIGluaXRpYWwgY29ubmVjdGlvbiBlc3RhYmxpc2htZW50KSwgdGhlbiB0aGUgc3BlY2lm aWNzIGZvciBFQ04gd2l0aCBtaWdyYXRpb24gaXMgZXNzZW50aWFsbHkgb25lIHN0YXRlbWVudCwg d2hpY2gNCiBpcyDigJxkbyB0aGUgRUNOIHByb2Nlc3Mgb24gZWFjaCBuZXcgbmV0d29yayBwYXRo IHRoYXQgeW91IHVzZeKAnS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25uZWN0aW9uIG1pZ3JhdGlvbiBoYXMgaW1wYWN0IG9u IHRoZSBudW1iZXIgb2YgcmVwb3J0ZWQgQ0UgbWFya2VkIHBhY2tldHMuIEEgbmV3IGNvbm5lY3Rp b24gc3RhdGUgd2l0aCBuZXcgY29uZ2VzdGlvbiZuYnNwO2NvbnRyb2wgc3RhdGUgYW5kIEVDTiBj b3VudGVycyBpcyBpbnN0YW50aWF0ZWQgYXQgdGhlIHNlbmRlciBhbmQgcmVjZWl2ZXIuIFRoZSBF Q04gY291bnRlcnMgTVVTVCBzdGFydCBmcm9tIHplcm8gYWdhaW4uPG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc2VlbXMgZmluZSB0byBt ZSwgaXTigJlzIGlubGluZSB3aXRoIHRoZSByZXN0IG9mIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wv bG9zcyByZWNvdmVyeSBzdGF0ZSB0aGF0IGFsc28gbmVlZHMgdG8gYmUgcmVzZXQgZm9yIHRoZSBu ZXcgcGF0aC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+R2l2ZW4gdGhhdCBlYWNoIG1pZ3JhdGlvbiByZXF1aXJlcyBhdCBsZWFzdCBv bmUgZXhjaGFuZ2Ugb2YgcGFja2V0cyBhdCB0aGUgYmVnaW5uaW5nIChhdCB0aGUgdmVyeSBsZWFz dCBmb3IgYWRkcmVzcyB2YWxpZGF0aW9uIGZyb20gdGhlIHNpZGUgb2YgdGhlIGVuZHBvaW50IHRo YXQgZGlkbuKAmXQgbWlncmF0ZSksIGl0IHNlZW1zIGxpa2UgdGhhdOKAmXMgYW4gZXhjZWxsZW50 IG1vbWVudCB0byBtYXJrIHRoZSBwYWNrZXRzDQogYW5kIHBlcmZvcm0gdGhlIEVDTiBjYXBhYmls aXR5IGRldGVjdGlvbi4gVGhvc2UgcGFja2V0cyBhcmUgYWxzbyBsaWtlbHkgcGFkZGVkLCBldGMu IHNpbWlsYXIgdG8gaW5pdGlhbCBwYWNrZXRzIHNpbmNlIHRoZXnigJlyZSBvbiBhIHByZXZpb3Vz bHkgdW51c2VkIG5ldHdvcmsgcGF0aC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NlZCBy ZXF1aXJlbWVudCBvZiBqdXN0IHVzaW5nIHRoZSDigJxmaXJzdOKAnSBwYWNrZXRzIGFuZCBtYXJr aW5nIHRob3NlIGlzIHN1ZmZpY2llbnQgKGFuZCBnb29kIHRvIGF2b2lkIGFueSByZXF1aXJlbWVu dCBhcyB0byB3aGljaCBmcmFtZXMgYXJlIGNvbnRhaW5lZCBpbiB0aG9zZSBwYWNrZXRzKSwgc2lu Y2Ugd2UgYXJlIGFsd2F5cyBleGNoYW5naW5nIHBhY2tldHMgaW4NCiBib3RoIGRpcmVjdGlvbnMg aW1tZWRpYXRlbHkgYWZ0ZXIgbWlncmF0aW9uLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGhhcyB0aGUgYWRkZWQgYmVuZWZp dCBzdWNoIHRoYXQgYW55IGVuZHBvaW50IOKAnHByb2JpbmfigJ0gcG9zc2libGUgbmV0d29yayBw YXRocyBjb3VsZCBpbmNsdWRlIHRoZSBiaXRzIG5lY2Vzc2FyeSB0byBkZXRlY3QgRUNOIGNhcGFi aWxpdHkgb24gdGhlIHBhdGggYmVpbmcgcHJvYmVkLCBzbyBpdCBjb3VsZCBldmVuIGtub3cgYmVm b3JlIG1pZ3JhdGluZyB3aGV0aGVyIG9yIG5vdCBpdCB3b3VsZCBiZSBhYmxlDQogdG8gdXNlIEVD TiBvbiB0aGF0IG5ldyBwYXRoLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FcmljPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRmViIDEsIDIwMTgsIGF0 IDM6MDcgQU0sIEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0OzxhIGhyZWY9Im1haWx0bzppbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGhhdmUgd3JpdHRlbiB1cCBkaWZmZXJlbnQgYXNwZWN0cyBvZiBjb25uZWN0aW9uIG1p Z3JhdGlvbiBhbmQgaG93IGl0IHBsYXlzIHdpdGggRUNOLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29t L3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1RVUlDI3RyYW5zcG9ydC1kcmFmdC1jb25u ZWN0aW9uLW1pZ3JhdGlvbiI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9naXRo dWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1RVUlDI3RyYW5zcG9ydC1kcmFm dC1jb25uZWN0aW9uLW1pZ3JhdGlvbjwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgY2F2ZWF0Li4gSSBhbSBhIGJpdCB1bnN1 cmUgYWJvdXQgdGhlIGRlZmluaXRpb24gb2YgY29ubmVjdGlvbiBtaWdyYXRpb24gLiBNeSBpbnRl cnByZXRhdGlvbiBpcyB0aGF0IGEgY2xpZW50IG1vdmVzIHRvIGEgbmV3IElQIGFkZHJlc3MgZHVl IHRvIGUuZy4gYSBOQVQgcmViaW5kIG9yIHN3aXRjaCBmcm9tIFdpRmkgdG8gY2VsbHVsYXIsIHJp Z2h0ID8uIElzIGEgbmV3IGNvbm5lY3Rpb24gaW5zdGFudGlhdGVkDQogYXQgYSBjb25uZWN0aW9u IG1pZ3JhdGlvbiA/PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi9JbmdlbWFyPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+SW5nZW1hciBKb2hhbnNzb24mbmJzcDsgTS5TYy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5NYXN0ZXIgUmVzZWFyY2hlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPkVyaWNzc29uIFJlc2VhcmNoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TmV0d29yayBQcm90b2Nv bHMgJmFtcDsgRTJFIFBlcmZvcm1hbmNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TGFicmF0b3JpZWdyw6Ru ZCAxMTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjk3MSAyOCwgTHVsZcOlLCBTd2VkZW48L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj5QaG9uZSAmIzQzOzQ2LTEwNzEgNDMwNDI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5TTVMvTU1TICYj NDM7NDYtNzMgMDc4IDMyODk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBl cmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb208L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0ieC1tc2c6Ly8zMTYvd3d3LmVyaWNz c29uLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0Ij53d3cuZXJpY3Nzb24uY29t PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7YmFja2dyb3VuZDojQ0NDQ0REIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2JhY2tncm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBZb3UgY2FuJ3Qgc3RhcnQgYSBmaXJlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4N CjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj4mbmJzcDsgV29ycnlpbmcgJ2JvdXQgeW91 ciBsaXR0bGUgd29ybGQgZmFsbGluZyBhcGFydDwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2JhY2tn cm91bmQ6d2hpdGUiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBCcnVjZSBTcHJpbmdzdGVl bjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_VI1PR0701MB2126E79A17DB715F6C91EA05B9F90VI1PR0701MB2126_-- From nobody Fri Feb 2 07:08:23 2018 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 DA41112D88D for ; Fri, 2 Feb 2018 07:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 w45LGUkP6_tX for ; Fri, 2 Feb 2018 07:08:19 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 5EEDC12783A for ; Fri, 2 Feb 2018 07:08:19 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id s39so31229716qth.7 for ; Fri, 02 Feb 2018 07:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=Xk+XPKggg0To4SGQi5u5UMA+ZdmN3uM+bflr2ifaitQ=; b=OFP7aVl0WomBx8iwzN5YVFVuIMyaENJI/d0gM0X7nvcBUsLAKkLAmmmY09m70Ev2db v1VFvYSwUgp92H7Edi6yxSjJE7rhXF0xVAhzqajQLxT4BSNEwO9pbUeGFsOnwX5kREdN P5o4eDuiU9ytnvq8f8mnZE+0umayUXAzNFQiJnKC4n3TM0ObzrINklypX7GUAqqyUP4Y 3Y6GxYOq5UcOTh2hHjEEANYOO+kvMZmzh7thkl3Ai8DMmFvDOkuvq4PSjXKGY29zPc95 nYTjUWy7w2ysxwSXGxsSGxowAksLHI519SUcPhj4kgYG7bJzbY9hKd8tXakYzSX0W6hY lsAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Xk+XPKggg0To4SGQi5u5UMA+ZdmN3uM+bflr2ifaitQ=; b=mqaTPtd5StL1ESQDszvF5psBw4gUc66tdMd3mAQL5lOwym/m80wPBOvuzNMQRjK5nq mXJGFFB1ZkXLCD3gnPWnhVOcYOWy7RYm4GYsDSrFXbVc2+wRFy89gjvlaR+0WFzhVeec 4pxJ+iZ4ixkenrkfFG6SaM3Wczxexy2Em1+EYHMQc5jhqw9sDGXSPJiaHLBql8dAmLZw 6zT75p/REnvaqGaLpCwIb37as7JQBQvNvXTetXuP9OUTfhXEkxj9Uy844hgMANE0wDpA nvLIheEzL9FwjXDsPgTEci6hVtkAR3QJTDkR8q7T8fseuIdZ9aZlnyczZ+5LyJgFgxmu ZX6Q== X-Gm-Message-State: AKwxytdYRU9YjHthbUV6kecM26Jh1PFha7mPlJLoXqgH/9k4nFAWSonn kXmyiBRWKIfOucWx1XGsd3tuBQ== X-Google-Smtp-Source: AH8x2244dK+FkzdAsug45Pj+ntRgTGu7XSqa6lsTcL/gRuExcM/F/EXI75LqC2WoPphC7NMlsnqmtg== X-Received: by 10.237.33.98 with SMTP id 89mr41503480qtc.21.1517584098495; Fri, 02 Feb 2018 07:08:18 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id w33sm1529350qtj.10.2018.02.02.07.08.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Feb 2018 07:08:18 -0800 (PST) Date: Fri, 2 Feb 2018 10:08:13 -0500 From: Dmitri Tikhonov To: "Brian Trammell (IETF)" Cc: Martin Duke , Ted Hardie , Roberto Peon , Mirja =?iso-8859-1?Q?K=FChlewind?= , Christian Huitema , Jana Iyengar , Eric Rescorla , QUIC WG , Martin Thomson Subject: Re: Packet number encryption Message-ID: <20180202150812.GA12313@ubuntu-dmitri> Mail-Followup-To: "Brian Trammell (IETF)" , Martin Duke , Ted Hardie , Roberto Peon , Mirja =?iso-8859-1?Q?K=FChlewind?= , Christian Huitema , Jana Iyengar , Eric Rescorla , QUIC WG , Martin Thomson References: <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> <26AC90FF-EDC0-431A-86D7-8F78555B5DB9@trammell.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <26AC90FF-EDC0-431A-86D7-8F78555B5DB9@trammell.ch> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 02 Feb 2018 15:08:21 -0000 On Fri, Feb 02, 2018 at 10:35:41AM +0100, Brian Trammell (IETF) wrote: > > On 2 Feb 2018, at 01:47, Martin Duke wrote: > > as the true packet number will start at 0 (boo!) or 1 (yay!). > > I actually have strong opinions on both sides of this argument, so > I think I’ll go off in the corner and have a pointless fight with > myself on this one. How strong is the preference for starting off the packet sequence with zero? Zero is such a convenient (and efficient) special value, programming-wise. - Dmitri. From nobody Fri Feb 2 07:14:03 2018 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 6FB9912D944 for ; Fri, 2 Feb 2018 07:14:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 fwMB1QKuj1M3 for ; Fri, 2 Feb 2018 07:13:59 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145FE12783A for ; Fri, 2 Feb 2018 07:13:59 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 5C14A340552; Fri, 2 Feb 2018 16:13:57 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.10403); Fri, 2 Feb 2018 16:13:55 +0100 (CET) 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; Fri, 2 Feb 2018 16:13:55 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44171450; Fri, 02 Feb 2018 16:13:55 +0100 From: "Brian Trammell (IETF)" Message-Id: <919299EA-77FB-49B4-BCDD-F505AAA5E71B@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_0EAA3A67-BD4C-4AC3-9B62-B682C5AAABCE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Fri, 2 Feb 2018 16:13:54 +0100 In-Reply-To: <20180202150812.GA12313@ubuntu-dmitri> Cc: Ted Hardie , Roberto Peon , Christian Huitema , Jana Iyengar , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Eric Rescorla , QUIC WG , Martin Thomson , Martin Duke To: Dmitri Tikhonov References: <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> <26AC90FF-EDC0-431A-86D7-8F78555B5DB9@trammell.ch> <20180202150812.GA12313@ubuntu-dmitri> 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: Fri, 02 Feb 2018 15:14:01 -0000 --Apple-Mail=_0EAA3A67-BD4C-4AC3-9B62-B682C5AAABCE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 2 Feb 2018, at 16:08, Dmitri Tikhonov = wrote: >=20 > On Fri, Feb 02, 2018 at 10:35:41AM +0100, Brian Trammell (IETF) wrote: >>> On 2 Feb 2018, at 01:47, Martin Duke = wrote: >>> as the true packet number will start at 0 (boo!) or 1 (yay!). >>=20 >> I actually have strong opinions on both sides of this argument, so >> I think I=E2=80=99ll go off in the corner and have a pointless fight = with >> myself on this one. >=20 > How strong is the preference for starting off the packet sequence with > zero? Zero is such a convenient (and efficient) special value, > programming-wise. Yeah, in this case, starting at one is far preferable so as to use 0 as = the special value, but counting from one in general just feels dirty to = people who grew up with C. (This bikeshed has been painted so often that it's made of paint, = though, so I apologize for even referring to it in passing.) --Apple-Mail=_0EAA3A67-BD4C-4AC3-9B62-B682C5AAABCE 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp0gDIACgkQihK3vwvq RqOv8g/+OHnhzAapxoyvrsxwlc9efSOUViYsUwliuHMQEJMmjN0Ho6C12x2bPJJR 7xh2m3j7yjzcLqgdgqkym2x144RBXuJNKDDearq+DP0kd9hrSYpVPuIMZMxpftsv 8LB70jA6ad6/czYNXBMgATdc0I1cueNqFDrrVgHW3gPPr2jPDBF0sHPHHAEQMqia UbQd0gUgyvkUcWVhU+Khymfz4kYOw3sWOYurxlrgK6iy5y1CbaIaVUJVxN3n74Zc eQx14EaS8RvfgnYchwy5HE9WcL1Z/wD285GSVoXTzDl+6SBLCrrD21JeloBbYPWA rt9iEiauC+Bm5aUUKsFv/5tgbC+FFoAnoN1Ko3juAVGlkqiAZFax+E3IUTL4ATxm bgsKRyEG4fi7sbLTiA4UM+yvm2QCvYf8OrKFZCyUPxrE6SLERuu/LrK5DiuLrVgB MnIK5DNShzXuTjCF9Pqbqk/s+j/1rPhQbNU6yvoBncLqIJSjyGCum44A9WJYv8M1 RnQmI/IQ/lSJVuj4jw6QF0XDHxLcX73lfiNGjDZomh9+JmhrzypIH50bm37E2SkP bhGBUtF2QldSycHosMrXPAh9+Ar16IjeFsYflTBTSLHPieqKHUnbp2iJbLBXZe51 xhcjwJ3sS0EzvfNIeWH7+f9p5HtumJd9UlYLNyHGTSMwW0axfbo= =qkt/ -----END PGP SIGNATURE----- --Apple-Mail=_0EAA3A67-BD4C-4AC3-9B62-B682C5AAABCE-- From nobody Fri Feb 2 07:32:58 2018 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 3573A12783A for ; Fri, 2 Feb 2018 07:32:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 03g8EXMtWx9W for ; Fri, 2 Feb 2018 07:32:55 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe05::708]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B541267BB for ; Fri, 2 Feb 2018 07:32:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eUk7uKhXvBFdLi9/ZsASzMv2gejVPMQkJVj56eoJWtY=; b=iLB5THBK2kPB6g2Dj33yXncAaS6pzSbwAHAHkns6GqE+wkH3B4IACyLnjvuyQm2d5Q4GjRaWgSUxIfk0H6BeniLfwYi672nB2FUTqevx/O1PUPZt2dAw4U5xql2yLOmWr4Re+LvIOwJLPbWJQu4hTRlGad50dAdAlWPHIxrHopE= Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB0700.eurprd07.prod.outlook.com (10.160.51.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Fri, 2 Feb 2018 15:32:50 +0000 Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf%13]) with mapi id 15.20.0464.012; Fri, 2 Feb 2018 15:32:49 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: "Eggert, Lars" , Gorry Fairhust CC: Eric Rescorla , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Christian Huitema , Brian Trammell , QUIC WG , Martin Thomson , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31fyIlPY67nUiLThH52NyNBqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBlQA= Date: Fri, 2 Feb 2018 15:32:49 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> In-Reply-To: <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.111.115.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0700; 7:NZy6SmE/MhZ4Bc3v98xz3RR3Ur74r0wVwTtVuUQ0xukj1QmUUASVflIi/Fz1SGoqpW2ayLRFYH79ZwXVs0BlyTIvaG0LFudjKCyf18HuzaiPY39uiZ2r8+czAZEE71XBC+RijKYnqgL69Kce1s1zS8/WAtjf3iJzmmdMfTTA5tPLinPn6sZcX40WucER0k8RaN52ZZYUv02DLRRytQsqr1hyRHWMVh1pbxfAu66erVmfhkFNgKHi1mtpGtUVJip1 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(396003)(376002)(366004)(39860400002)(346002)(39380400002)(377424004)(189003)(11905935001)(199004)(8936002)(102836004)(33656002)(26005)(36756003)(39060400002)(316002)(82746002)(6436002)(6116002)(966005)(6506007)(3480700004)(25786009)(68736007)(76176011)(86362001)(2900100001)(14454004)(54906003)(83716003)(8676002)(106356001)(81166006)(93886005)(83506002)(53546011)(2906002)(81156014)(3846002)(105586002)(6246003)(3660700001)(478600001)(4326008)(58126008)(305945005)(5250100002)(4001150100001)(110136005)(7736002)(186003)(7116003)(2950100002)(99286004)(107886003)(5660300001)(66066001)(229853002)(6306002)(3280700002)(97736004)(6486002)(6512007)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0700; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6b758c97-e0f3-42f5-73a6-08d56a5237c7 x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DB3PR07MB0700; x-ms-traffictypediagnostic: DB3PR07MB0700: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(130329453890623); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231101)(11241501184)(806099)(2400082)(944501161)(3002001)(6055026)(6041288)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DB3PR07MB0700; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0700; x-forefront-prvs: 05715BE7FD received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1o6K0guBuzhdk4/OMZuXfo5QhbeW/clNBthzySLiPHZ4hW7i2SGHhjLLZZDdg885pOY8dOQ90NSliOu0KNgQUROYyLoAp/D8WxQhiHyE1yxWrey2fdRaNs866oXn3pJo spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6b758c97-e0f3-42f5-73a6-08d56a5237c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2018 15:32:49.6444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0700 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, 02 Feb 2018 15:32:57 -0000 T24gMzEvMDEvMjAxOCwgMTA6MDYsICJRVUlDIG9uIGJlaGFsZiBvZiBFZ2dlcnQsIExhcnMiIDxx dWljLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxhcnNAbmV0YXBwLmNvbT4gd3JvdGU6 DQo+IE9uIDIwMTgtMS0zMSwgYXQgMTA6NTIsIEdvcnJ5IEZhaXJodXJzdCA8Z29ycnlAZXJnLmFi ZG4uYWMudWs+IHdyb3RlOg0KPiA+ICsxIC0gU2ltcGx5OiBUaGlzICppcyogY29tcGxpY2F0ZWQg YW5kIHNlZW1zIHRvIGFkZCBsaXR0bGUuDQo+IA0KPiBTbyBhcyBhbiBpbXBsZW1lbnRvciAoY2hh aXIgaGF0IG9mZiksIHRoaXMgYWRkcyB2ZXJ5IGxpdHRsZSB0byB0aGUNCj4gb3ZlcmFsbCBjb21w bGV4aXR5IG9mIHRoZSBwcm90b2NvbC4NCg0KVGhpcyBkb2Vzbid0IHNvdW5kIGdyZWF0LiAgSXQn cyBhIGJpdCBsaWtlIHNheWluZyB0aGF0IGFkZGluZyB0aGUgSGlnZ3MNCm1lY2hhbmlzbSB0byB0 aGUgc3RhbmRhcmQgbW9kZWwncyBsYWdyYW5naWFuIGRvZXNuJ3QgbWFrZSBpdCBtdWNoIG1vcmUN CmNvbXBsaWNhdGUgOi0pICAoKikNCg0KTW9yZSBzZXJpb3VzbHkgdGhvdWdoLCBJJ2QgbGlrZSB0 byBwb2ludCBvdXQgdGhhdCBpdCBpcyBub3QganVzdCBhYm91dA0KaW1wbGVtZW50YXRpb24gY29t cGxleGl0eSwgaXQncyBhbHNvIHRoZSBlbmVyZ3kgY29zdCBwZXIgcGFja2V0IHRoYXQgaXMNCnF1 aXRlIGNydWNpYWwuICBJIGhhdmVuJ3QgZG9uZSB0aGUgbWF0aCBidXQgSVNUTSB0aGF0IGJyaW5n aW5nIGluDQphbm90aGVyIGJhdGNoIG9mIG5vbi1vcHRpb25hbCBjcnlwdG8gY29tcHV0YXRpb24g b24gYSBwZXIgcGFja2V0IGJhc2lzDQppcyBub3QgZ29pbmcgdG8gbW92ZSB0aGUgbmVlZGxlIGlu IHRoZSByaWdodCBkaXJlY3Rpb24gZm9yIHN0YWNrcyB0aGF0DQpydW4gb24gbG93IHBvd2VyIChJ b1QpLg0KDQpUaGlzIGlzIG5vdCBhIGNhdGFzdHJvcGhlIC0gd2UgaGF2ZSBDb0FQIGFuZCBhIChE KVRMUyBwcm9maWxlIC0gYnV0DQpuZWl0aGVyIGl0J3MgaWRlYWwsIHNpbmNlIGN1dHRpbmcgb2Zm IHRoZSBzbWFsbCB0aGluZ3MgZnJvbSB0aGUgd2lkZXINCmVjb3N5c3RlbSBjcmVhdGVzIGFuIGFy dGlmaWNpYWwgZ2FwIHdoaWNoIHRoZW4gd2lsbCBuZWVkIGEgbWlkZGxlYm94IHRvDQpicmlkZ2Uu ICAoU3VyZSwgd2UgaGF2ZSBzcGVjaWZpZWQgdGhlIGJlaGF2aW91ciBvZiBhIHNpbWlsYXIgYm94 DQphbHJlYWR5LCBidXQgaXQnZCBiZSByZWFsbHkgYmV0dGVyIGlmIHRoZSBleHRyYSB0cmFuc2xh dGlvbiBsb2dpYyBjb3VsZA0KYmUgYXZvaWRlZCBpbiB0aGUgZmlyc3QgcGxhY2UuKQ0KDQpJIGd1 ZXNzIHdoYXQgSSdtIHNheWluZyBpcyB0aGF0IFBOIGVuY3J5cHRpb24gYmVpbmcgYSBjb3JlIG1l Y2hhbmlzbQ0KdGhhdCBjYW4ndCBiZSBuZWdvdGlhdGVkIGF0IGhhbmRzaGFrZSB0aW1lIHJlZHVj ZXMgb3VyIGFiaWxpdHkgdG8gbGF0ZXINCnByb2ZpbGUgUVVJQyBmb3IgdGhlIElvVCwgd2hpY2gg d291bGQgYmUgYSBiaXQgdW5sdWNreS4NCg0KU28gdGhlIHF1ZXN0aW9uIGlzOiB3b3VsZCBpdCBi ZSBwb3NzaWJsZSB0byBtYWtlIHRoaXMgcHJvcGVydHkgYQ0KY29uZmlndXJhYmxlIGtub2IgaW5z dGVhZD8NCg0KKCopIGh0dHBzOi8vd3d3LnN5bW1ldHJ5bWFnYXppbmUub3JnL2FydGljbGUvdGhl LWRlY29uc3RydWN0ZWQtc3RhbmRhcmQtbW9kZWwtZXF1YXRpb24NCg0K From nobody Fri Feb 2 18:31:00 2018 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 BC8EA126DFB for ; Fri, 2 Feb 2018 18:30:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 LxCSPp3hjEZ0 for ; Fri, 2 Feb 2018 18:30:56 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 DAA5412420B for ; Fri, 2 Feb 2018 18:30:55 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id m84so14653811ywd.5 for ; Fri, 02 Feb 2018 18:30:55 -0800 (PST) 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=HI8ahOCansMAmQd6QzvOL2d+9rsoUOSf7h3Shey7oKg=; b=qWkSzPGcsFYdjyq7YbX6dgN/lfiwG8+lw2Z0kg9aBcwE/7pORtu66yIP0qN6hvuMkb pEqniZumAdfoAk0eUKnZSe/RymvY8kSIZCAQ2h6GRMVfE+nBeQY8YxvbDI9LDkKdz3wo ERjWD74m7+Z3zFEur6SNxGjWF7Uitr/73RQ1A0ykxXvJcOcf6dvQ0j967PRQgIBsVwOt vuGL4eHVroTXlq/X9WDk9bpvS5aS3QM+U4S3S3cI2KBGyhppZCq9gs9oOuL74bgTvu02 AezcP43GFYd9BUqXYq5zdZXdoBUUox/qWOfLrj0UOGQYJcsPOBl+qTbo/KvKwlS+tb0o 5hmA== 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=HI8ahOCansMAmQd6QzvOL2d+9rsoUOSf7h3Shey7oKg=; b=NYHSvdUvA8xhZd4PW9FH0uE+n2l6k6Vtpfcqv4otopy1MQBZnG2prdh6LClQFMj6lS /Q7sj4d5XUfA1PMkJoWHqLWZzO7owTLBIqLeG6qOGwGEacq4pBhO61DjQU3JKhPYSq0P 7bxWxpvapOOJvhOH/jOFwbf2sVBCjrSOXRtlFP3daBTBdWBHy1VeewOvWVSfz0q/Dbvb 6l117BG9elgh2AcrGhBLqjTrbxjxb/x2u25zlqlXGYiXSIPYxLcBGbkO2eiIu7S000R4 rQ/bJhnMzzoX2WCxYc5O7IkZdHKbpNiAgh+FCElU3q87XxsBupBxGh5PpBtFB5dlZXCU ZVqw== X-Gm-Message-State: AKwxytcXTa0d6MNqOablK+yYT5ynbX5HhoqIXSMGnNkKMaykipHT0NTC 43HVA/liVaCDEH8R+78w7jas5OtpU7nEWX4VtwAsDA== X-Google-Smtp-Source: AH8x225DSv+F/zr/aRl852Ow1VyNozs0JpS2RPdUAAmUcfGSdWMJJv9ZVUaiTROxHHm9klGA0L5Z4lsDTb3LU3IypvU= X-Received: by 10.37.132.78 with SMTP id r14mr3919732ybm.366.1517625054508; Fri, 02 Feb 2018 18:30:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Fri, 2 Feb 2018 18:30:53 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> From: Jana Iyengar Date: Fri, 2 Feb 2018 18:30:53 -0800 Message-ID: Subject: Re: Packet number encryption To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: "Eggert, Lars" , Gorry Fairhust , Eric Rescorla , Christian Huitema , Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="089e0826ea904779120564459ec9" 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, 03 Feb 2018 02:30:59 -0000 --089e0826ea904779120564459ec9 Content-Type: text/plain; charset="UTF-8" A few points as I catch up on this thread. First, I'll remind folks that QUIC is an encrypted transport. I say this because the cost of this operation is trivial in the context of encrypting every packet. The cost is borne at the servers and not at middleboxes, so the additional crypto cost is basically trivial. Second, this simplifies and increases robustness of implementation. Avoiding random PN jumps, as Kazuho points out, makes special-casing of code unnecessary. Special code that is exercised occasionally is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation. Third, yes, ossification is a real concern. A simple example: using increasing packet numbers as a signature for detecting QUIC. Even if you argue against this example, there are innovative ways in which ossification will happen. This is based on a true story: We had no idea how GQUIC's flags field could get ossified, the value that was being used commonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper ). There's a win here in terms of implementation complexity and several implementers have said so. There's a win in terms of ossification and our experience says so. There's a potential loss of manageability, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet numbers. On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) < thomas.fossati@nokia.com> wrote: > On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" < > quic-bounces@ietf.org on behalf of lars@netapp.com> wrote: > > On 2018-1-31, at 10:52, Gorry Fairhurst wrote: > > > +1 - Simply: This *is* complicated and seems to add little. > > > > So as an implementor (chair hat off), this adds very little to the > > overall complexity of the protocol. > > This doesn't sound great. It's a bit like saying that adding the Higgs > mechanism to the standard model's lagrangian doesn't make it much more > complicate :-) (*) > > More seriously though, I'd like to point out that it is not just about > implementation complexity, it's also the energy cost per packet that is > quite crucial. I haven't done the math but ISTM that bringing in > another batch of non-optional crypto computation on a per packet basis > is not going to move the needle in the right direction for stacks that > run on low power (IoT). > > This is not a catastrophe - we have CoAP and a (D)TLS profile - but > neither it's ideal, since cutting off the small things from the wider > ecosystem creates an artificial gap which then will need a middlebox to > bridge. (Sure, we have specified the behaviour of a similar box > already, but it'd be really better if the extra translation logic could > be avoided in the first place.) > > I guess what I'm saying is that PN encryption being a core mechanism > that can't be negotiated at handshake time reduces our ability to later > profile QUIC for the IoT, which would be a bit unlucky. > > So the question is: would it be possible to make this property a > configurable knob instead? > > (*) https://www.symmetrymagazine.org/article/the-deconstructed- > standard-model-equation > > --089e0826ea904779120564459ec9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A few points as I catch up on this thread.

<= div>First, I'll remind folks that QUIC is an encrypted transport. I say= this because the cost of this operation is trivial in the context of encry= pting every packet. The cost is borne at the servers and not at middleboxes= , so the additional crypto cost is basically trivial.

<= div>Second, this simplifies and increases robustness of implementation. Avo= iding random PN jumps, as Kazuho points out, makes special-casing of code u= nnecessary. Special code that is exercised occasionally is a strong bug att= ractor, and I would strongly argue for as few of those as possible in imple= mentation.

Third, yes, ossification is a real conc= ern. A simple example: using increasing packet numbers as a signature for d= etecting QUIC. Even if you argue against this example, there are innovative= ways in which ossification will happen. This is based on a true story:=C2= =A0We had no idea how GQUIC's flags field cou= ld get ossified, the value that was being used commonly became used as a si= gnature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper).

= There's a win here in terms of implementation complexity and several im= plementers have said so. There's a win in terms of ossification and our= experience says so. There's a potential loss of manageability, in bein= g able to detect reordering. This is the trade-off, and I am still in favor= of encrypting packet numbers.

On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (N= okia - GB/Cambridge, UK) <thomas.fossati@nokia.com> w= rote:
On 31/01/2018, 10:= 06, "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on behalf of lars@netapp.com> wrote:
> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> > +1 - Simply: This *is* complicated and seems to add little.
>
> So as an implementor (chair hat off), this adds very little to the
> overall complexity of the protocol.

This doesn't sound great.=C2=A0 It's a bit like saying that = adding the Higgs
mechanism to the standard model's lagrangian doesn't make it much m= ore
complicate :-)=C2=A0 (*)

More seriously though, I'd like to point out that it is not just about<= br> implementation complexity, it's also the energy cost per packet that is=
quite crucial.=C2=A0 I haven't done the math but ISTM that bringing in<= br> another batch of non-optional crypto computation on a per packet basis
is not going to move the needle in the right direction for stacks that
run on low power (IoT).

This is not a catastrophe - we have CoAP and a (D)TLS profile - but
neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to
bridge.=C2=A0 (Sure, we have specified the behaviour of a similar box
already, but it'd be really better if the extra translation logic could=
be avoided in the first place.)

I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later=
profile QUIC for the IoT, which would be a bit unlucky.

So the question is: would it be possible to make this property a
configurable knob instead?

(*) https://www.sy= mmetrymagazine.org/article/the-deconstructed-standard-model-equat= ion


--089e0826ea904779120564459ec9-- From nobody Fri Feb 2 18:59:58 2018 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 81CF812D7F1 for ; Fri, 2 Feb 2018 18:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 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 SDOgcvMMzYwZ for ; Fri, 2 Feb 2018 18:59:54 -0800 (PST) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6930212D7E9 for ; Fri, 2 Feb 2018 18:59:54 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0319.002; Fri, 2 Feb 2018 18:59:53 -0800 From: Piotr Galecki To: Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" CC: Gorry Fairhust , Eric Rescorla , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Christian Huitema , Brian Trammell , "Eggert, Lars" , QUIC WG , Martin Thomson Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31agylu7WfS0qRkNVQaeIhuKONB2EAgABeoICAAAgUAIAAd3OAgAA8YgCAACPDAIAAAicAgAOBlYCAALfdgP//f2bQ Date: Sat, 3 Feb 2018 02:59:52 +0000 Message-ID: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443MBX021W3CA2exch_" 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: Sat, 03 Feb 2018 02:59:57 -0000 --_000_2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443MBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBpcyB0aGUgZ3JvdXDigJlzIHByb3Bvc2FsIGZvciBhbGxvd2luZyBuZXR3b3JrIG1vbml0 b3JpbmcgdG9vbHMgdG8gZGV0ZWN0IHBhY2tldCByZXRyYW5zbWlzc2lvbiBvciBwYWNrZXQgcmVv cmRlcmluZyA/DQpUaGVzZSBtZXRyaWNzIGFyZSBwcmV0dHkgc3RyYWlnaHRmb3J3YXJkIHRvIG1l YXN1cmUgZm9yIFRDUCBmbG93cy4NClRvb2xzIGxpa2UgV2lyZXNoYXJrIGNhbiBhbmFseXplIHBh Y2tldHMgYW5kIHNwb3QgaXNzdWVzLg0KSG93IGNhbiB0aGUgbmV0d29yayB0b29scyBwZXJmb3Jt IHRoaXMga2luZCBvZiBtZWFzdXJlbWVudHMgZm9yIFFVSUMgZmxvd3MgaWYgUE4gZmllbGQgaXMg ZW5jcnlwdGVkPw0KDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDIsIDIw MTggOTozMSBQTQ0KVG86IEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVL KSA8dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPg0KQ2M6IEdvcnJ5IEZhaXJodXN0IDxnb3JyeUBl cmcuYWJkbi5hYy51az47IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT47IE1pcmphIEvDvGhs ZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+OyBDaHJpc3RpYW4gSHVpdGVt YSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IEJyaWFuIFRyYW1tZWxsIDxpZXRmQHRyYW1tZWxsLmNo PjsgRWdnZXJ0LCBMYXJzIDxsYXJzQG5ldGFwcC5jb20+OyBRVUlDIFdHIDxxdWljQGlldGYub3Jn PjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJl OiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KQSBmZXcgcG9pbnRzIGFzIEkgY2F0Y2ggdXAg b24gdGhpcyB0aHJlYWQuDQoNCkZpcnN0LCBJJ2xsIHJlbWluZCBmb2xrcyB0aGF0IFFVSUMgaXMg YW4gZW5jcnlwdGVkIHRyYW5zcG9ydC4gSSBzYXkgdGhpcyBiZWNhdXNlIHRoZSBjb3N0IG9mIHRo aXMgb3BlcmF0aW9uIGlzIHRyaXZpYWwgaW4gdGhlIGNvbnRleHQgb2YgZW5jcnlwdGluZyBldmVy eSBwYWNrZXQuIFRoZSBjb3N0IGlzIGJvcm5lIGF0IHRoZSBzZXJ2ZXJzIGFuZCBub3QgYXQgbWlk ZGxlYm94ZXMsIHNvIHRoZSBhZGRpdGlvbmFsIGNyeXB0byBjb3N0IGlzIGJhc2ljYWxseSB0cml2 aWFsLg0KDQpTZWNvbmQsIHRoaXMgc2ltcGxpZmllcyBhbmQgaW5jcmVhc2VzIHJvYnVzdG5lc3Mg b2YgaW1wbGVtZW50YXRpb24uIEF2b2lkaW5nIHJhbmRvbSBQTiBqdW1wcywgYXMgS2F6dWhvIHBv aW50cyBvdXQsIG1ha2VzIHNwZWNpYWwtY2FzaW5nIG9mIGNvZGUgdW5uZWNlc3NhcnkuIFNwZWNp YWwgY29kZSB0aGF0IGlzIGV4ZXJjaXNlZCBvY2Nhc2lvbmFsbHkgaXMgYSBzdHJvbmcgYnVnIGF0 dHJhY3RvciwgYW5kIEkgd291bGQgc3Ryb25nbHkgYXJndWUgZm9yIGFzIGZldyBvZiB0aG9zZSBh cyBwb3NzaWJsZSBpbiBpbXBsZW1lbnRhdGlvbi4NCg0KVGhpcmQsIHllcywgb3NzaWZpY2F0aW9u IGlzIGEgcmVhbCBjb25jZXJuLiBBIHNpbXBsZSBleGFtcGxlOiB1c2luZyBpbmNyZWFzaW5nIHBh Y2tldCBudW1iZXJzIGFzIGEgc2lnbmF0dXJlIGZvciBkZXRlY3RpbmcgUVVJQy4gRXZlbiBpZiB5 b3UgYXJndWUgYWdhaW5zdCB0aGlzIGV4YW1wbGUsIHRoZXJlIGFyZSBpbm5vdmF0aXZlIHdheXMg aW4gd2hpY2ggb3NzaWZpY2F0aW9uIHdpbGwgaGFwcGVuLiBUaGlzIGlzIGJhc2VkIG9uIGEgdHJ1 ZSBzdG9yeTogV2UgaGFkIG5vIGlkZWEgaG93IEdRVUlDJ3MgZmxhZ3MgZmllbGQgY291bGQgZ2V0 IG9zc2lmaWVkLCB0aGUgdmFsdWUgdGhhdCB3YXMgYmVpbmcgdXNlZCBjb21tb25seSBiZWNhbWUg dXNlZCBhcyBhIHNpZ25hdHVyZSBmb3IgUVVJQyB0cmFmZmljIChzZWUgU2VjdGlvbiA3LjUgaW4g dGhlIFNJR0NPTU0gUVVJQyBwYXBlcjxodHRwczovL3N0YXRpYy5nb29nbGV1c2VyY29udGVudC5j b20vbWVkaWEvcmVzZWFyY2guZ29vZ2xlLmNvbS9lbi9wdWJzL2FyY2hpdmUvNDY0MDMucGRmPiku DQoNClRoZXJlJ3MgYSB3aW4gaGVyZSBpbiB0ZXJtcyBvZiBpbXBsZW1lbnRhdGlvbiBjb21wbGV4 aXR5IGFuZCBzZXZlcmFsIGltcGxlbWVudGVycyBoYXZlIHNhaWQgc28uIFRoZXJlJ3MgYSB3aW4g aW4gdGVybXMgb2Ygb3NzaWZpY2F0aW9uIGFuZCBvdXIgZXhwZXJpZW5jZSBzYXlzIHNvLiBUaGVy ZSdzIGEgcG90ZW50aWFsIGxvc3Mgb2YgbWFuYWdlYWJpbGl0eSwgaW4gYmVpbmcgYWJsZSB0byBk ZXRlY3QgcmVvcmRlcmluZy4gVGhpcyBpcyB0aGUgdHJhZGUtb2ZmLCBhbmQgSSBhbSBzdGlsbCBp biBmYXZvciBvZiBlbmNyeXB0aW5nIHBhY2tldCBudW1iZXJzLg0KDQpPbiBGcmksIEZlYiAyLCAy MDE4IGF0IDc6MzIgQU0sIEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVL KSA8dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPG1haWx0bzp0aG9tYXMuZm9zc2F0aUBub2tpYS5j b20+PiB3cm90ZToNCk9uIDMxLzAxLzIwMTgsIDEwOjA2LCAiUVVJQyBvbiBiZWhhbGYgb2YgRWdn ZXJ0LCBMYXJzIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiBsYXJzQG5ldGFwcC5jb208bWFpbHRvOmxhcnNAbmV0YXBwLmNv bT4+IHdyb3RlOg0KPiBPbiAyMDE4LTEtMzEsIGF0IDEwOjUyLCBHb3JyeSBGYWlyaHVyc3QgPGdv cnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+IHdyb3RlOg0K PiA+ICsxIC0gU2ltcGx5OiBUaGlzICppcyogY29tcGxpY2F0ZWQgYW5kIHNlZW1zIHRvIGFkZCBs aXR0bGUuDQo+DQo+IFNvIGFzIGFuIGltcGxlbWVudG9yIChjaGFpciBoYXQgb2ZmKSwgdGhpcyBh ZGRzIHZlcnkgbGl0dGxlIHRvIHRoZQ0KPiBvdmVyYWxsIGNvbXBsZXhpdHkgb2YgdGhlIHByb3Rv Y29sLg0KDQpUaGlzIGRvZXNuJ3Qgc291bmQgZ3JlYXQuICBJdCdzIGEgYml0IGxpa2Ugc2F5aW5n IHRoYXQgYWRkaW5nIHRoZSBIaWdncw0KbWVjaGFuaXNtIHRvIHRoZSBzdGFuZGFyZCBtb2RlbCdz IGxhZ3JhbmdpYW4gZG9lc24ndCBtYWtlIGl0IG11Y2ggbW9yZQ0KY29tcGxpY2F0ZSA6LSkgICgq KQ0KDQpNb3JlIHNlcmlvdXNseSB0aG91Z2gsIEknZCBsaWtlIHRvIHBvaW50IG91dCB0aGF0IGl0 IGlzIG5vdCBqdXN0IGFib3V0DQppbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LCBpdCdzIGFsc28g dGhlIGVuZXJneSBjb3N0IHBlciBwYWNrZXQgdGhhdCBpcw0KcXVpdGUgY3J1Y2lhbC4gIEkgaGF2 ZW4ndCBkb25lIHRoZSBtYXRoIGJ1dCBJU1RNIHRoYXQgYnJpbmdpbmcgaW4NCmFub3RoZXIgYmF0 Y2ggb2Ygbm9uLW9wdGlvbmFsIGNyeXB0byBjb21wdXRhdGlvbiBvbiBhIHBlciBwYWNrZXQgYmFz aXMNCmlzIG5vdCBnb2luZyB0byBtb3ZlIHRoZSBuZWVkbGUgaW4gdGhlIHJpZ2h0IGRpcmVjdGlv biBmb3Igc3RhY2tzIHRoYXQNCnJ1biBvbiBsb3cgcG93ZXIgKElvVCkuDQoNClRoaXMgaXMgbm90 IGEgY2F0YXN0cm9waGUgLSB3ZSBoYXZlIENvQVAgYW5kIGEgKEQpVExTIHByb2ZpbGUgLSBidXQN Cm5laXRoZXIgaXQncyBpZGVhbCwgc2luY2UgY3V0dGluZyBvZmYgdGhlIHNtYWxsIHRoaW5ncyBm cm9tIHRoZSB3aWRlcg0KZWNvc3lzdGVtIGNyZWF0ZXMgYW4gYXJ0aWZpY2lhbCBnYXAgd2hpY2gg dGhlbiB3aWxsIG5lZWQgYSBtaWRkbGVib3ggdG8NCmJyaWRnZS4gIChTdXJlLCB3ZSBoYXZlIHNw ZWNpZmllZCB0aGUgYmVoYXZpb3VyIG9mIGEgc2ltaWxhciBib3gNCmFscmVhZHksIGJ1dCBpdCdk IGJlIHJlYWxseSBiZXR0ZXIgaWYgdGhlIGV4dHJhIHRyYW5zbGF0aW9uIGxvZ2ljIGNvdWxkDQpi ZSBhdm9pZGVkIGluIHRoZSBmaXJzdCBwbGFjZS4pDQoNCkkgZ3Vlc3Mgd2hhdCBJJ20gc2F5aW5n IGlzIHRoYXQgUE4gZW5jcnlwdGlvbiBiZWluZyBhIGNvcmUgbWVjaGFuaXNtDQp0aGF0IGNhbid0 IGJlIG5lZ290aWF0ZWQgYXQgaGFuZHNoYWtlIHRpbWUgcmVkdWNlcyBvdXIgYWJpbGl0eSB0byBs YXRlcg0KcHJvZmlsZSBRVUlDIGZvciB0aGUgSW9ULCB3aGljaCB3b3VsZCBiZSBhIGJpdCB1bmx1 Y2t5Lg0KDQpTbyB0aGUgcXVlc3Rpb24gaXM6IHdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIG1ha2Ug dGhpcyBwcm9wZXJ0eSBhDQpjb25maWd1cmFibGUga25vYiBpbnN0ZWFkPw0KDQooKikgaHR0cHM6 Ly93d3cuc3ltbWV0cnltYWdhemluZS5vcmcvYXJ0aWNsZS90aGUtZGVjb25zdHJ1Y3RlZC1zdGFu ZGFyZC1tb2RlbC1lcXVhdGlvbg0KDQo= --_000_2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443MBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aGF0IGlzIHRoZSBncm91cOKAmXMgcHJvcG9zYWwgZm9yIGFsbG93aW5nIG5ldHdvcmsgbW9uaXRv cmluZyB0b29scyB0byBkZXRlY3QgcGFja2V0IHJldHJhbnNtaXNzaW9uIG9yIHBhY2tldCByZW9y ZGVyaW5nID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXNlIG1ldHJp Y3MgYXJlIHByZXR0eSBzdHJhaWdodGZvcndhcmQgdG8gbWVhc3VyZSBmb3IgVENQIGZsb3dzLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VG9vbHMgbGlrZSBXaXJlc2hhcmsg Y2FuIGFuYWx5emUgcGFja2V0cyBhbmQgc3BvdCBpc3N1ZXMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Ib3cgY2FuIHRoZSBuZXR3b3JrIHRvb2xzIHBlcmZvcm0gdGhpcyBr aW5kIG9mIG1lYXN1cmVtZW50cyBmb3IgUVVJQyBmbG93cyBpZiBQTiBmaWVsZCBpcyBlbmNyeXB0 ZWQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPkphbmEgSXllbmdhcjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIEZlYnJ1YXJ5IDAyLCAyMDE4IDk6MzEgUE08YnI+DQo8Yj5Ubzo8L2I+IEZvc3Nh dGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSAmbHQ7dGhvbWFzLmZvc3NhdGlA bm9raWEuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gR29ycnkgRmFpcmh1c3QgJmx0O2dvcnJ5QGVy Zy5hYmRuLmFjLnVrJmd0OzsgRXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0OzsgTWly amEgS8O8aGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCZndDs7IENo cmlzdGlhbiBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OzsgQnJpYW4gVHJhbW1l bGwgJmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7OyBFZ2dlcnQsIExhcnMgJmx0O2xhcnNAbmV0YXBw LmNvbSZndDs7IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7Ow0KIE1hcnRpbiBUaG9tc29u ICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkEgZmV3IHBvaW50cyBhcyBJIGNhdGNoIHVwIG9uIHRoaXMgdGhyZWFkLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rmlyc3QsIEknbGwgcmVtaW5kIGZvbGtz IHRoYXQgUVVJQyBpcyBhbiBlbmNyeXB0ZWQgdHJhbnNwb3J0LiBJIHNheSB0aGlzIGJlY2F1c2Ug dGhlIGNvc3Qgb2YgdGhpcyBvcGVyYXRpb24gaXMgdHJpdmlhbCBpbiB0aGUgY29udGV4dCBvZiBl bmNyeXB0aW5nIGV2ZXJ5IHBhY2tldC4gVGhlIGNvc3QgaXMgYm9ybmUgYXQgdGhlIHNlcnZlcnMg YW5kIG5vdCBhdCBtaWRkbGVib3hlcywgc28gdGhlIGFkZGl0aW9uYWwNCiBjcnlwdG8gY29zdCBp cyBiYXNpY2FsbHkgdHJpdmlhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U2Vjb25kLCB0aGlzIHNpbXBsaWZpZXMgYW5kIGluY3JlYXNlcyBy b2J1c3RuZXNzIG9mIGltcGxlbWVudGF0aW9uLiBBdm9pZGluZyByYW5kb20gUE4ganVtcHMsIGFz IEthenVobyBwb2ludHMgb3V0LCBtYWtlcyBzcGVjaWFsLWNhc2luZyBvZiBjb2RlIHVubmVjZXNz YXJ5LiBTcGVjaWFsIGNvZGUgdGhhdCBpcyBleGVyY2lzZWQgb2NjYXNpb25hbGx5IGlzIGEgc3Ry b25nIGJ1ZyBhdHRyYWN0b3IsIGFuZCBJIHdvdWxkDQogc3Ryb25nbHkgYXJndWUgZm9yIGFzIGZl dyBvZiB0aG9zZSBhcyBwb3NzaWJsZSBpbiBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcmQsIHllcywgb3NzaWZp Y2F0aW9uIGlzIGEgcmVhbCBjb25jZXJuLiBBIHNpbXBsZSBleGFtcGxlOiB1c2luZyBpbmNyZWFz aW5nIHBhY2tldCBudW1iZXJzIGFzIGEgc2lnbmF0dXJlIGZvciBkZXRlY3RpbmcgUVVJQy4gRXZl biBpZiB5b3UgYXJndWUgYWdhaW5zdCB0aGlzIGV4YW1wbGUsIHRoZXJlIGFyZSBpbm5vdmF0aXZl IHdheXMgaW4gd2hpY2ggb3NzaWZpY2F0aW9uIHdpbGwgaGFwcGVuLiBUaGlzIGlzDQogYmFzZWQg b24gYSB0cnVlIHN0b3J5OiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3Jv dW5kOndoaXRlIj5XZSBoYWQgbm8gaWRlYSBob3cgR1FVSUMncyBmbGFncyBmaWVsZCBjb3VsZCBn ZXQgb3NzaWZpZWQsIHRoZSB2YWx1ZSB0aGF0IHdhcyBiZWluZyB1c2VkIGNvbW1vbmx5IGJlY2Ft ZSB1c2VkIGFzIGEgc2lnbmF0dXJlIGZvciBRVUlDIHRyYWZmaWMNCiAoc2VlIFNlY3Rpb24gNy41 IGluIHRoZSA8YSBocmVmPSJodHRwczovL3N0YXRpYy5nb29nbGV1c2VyY29udGVudC5jb20vbWVk aWEvcmVzZWFyY2guZ29vZ2xlLmNvbS9lbi9wdWJzL2FyY2hpdmUvNDY0MDMucGRmIj4NClNJR0NP TU0gUVVJQyBwYXBlcjwvYT4pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUncyBhIHdpbiBoZXJlIGluIHRlcm1zIG9mIGlt cGxlbWVudGF0aW9uIGNvbXBsZXhpdHkgYW5kIHNldmVyYWwgaW1wbGVtZW50ZXJzIGhhdmUgc2Fp ZCBzby4gVGhlcmUncyBhIHdpbiBpbiB0ZXJtcyBvZiBvc3NpZmljYXRpb24gYW5kIG91ciBleHBl cmllbmNlIHNheXMgc28uIFRoZXJlJ3MgYSBwb3RlbnRpYWwgbG9zcyBvZiBtYW5hZ2VhYmlsaXR5 LCBpbiBiZWluZyBhYmxlIHRvIGRldGVjdCByZW9yZGVyaW5nLg0KIFRoaXMgaXMgdGhlIHRyYWRl LW9mZiwgYW5kIEkgYW0gc3RpbGwgaW4gZmF2b3Igb2YgZW5jcnlwdGluZyBwYWNrZXQgbnVtYmVy cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gRnJpLCBGZWIgMiwgMjAxOCBhdCA3OjMyIEFNLCBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0g R0IvQ2FtYnJpZGdlLCBVSykgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXMuZm9zc2F0aUBub2tp YS5jb20iIHRhcmdldD0iX2JsYW5rIj50aG9tYXMuZm9zc2F0aUBub2tpYS5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIDMxLzAxLzIwMTgsIDEwOjA2LCAmcXVvdDtR VUlDIG9uIGJlaGFsZiBvZiBFZ2dlcnQsIExhcnMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxm IG9mDQo8YSBocmVmPSJtYWlsdG86bGFyc0BuZXRhcHAuY29tIj5sYXJzQG5ldGFwcC5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IE9uIDIwMTgtMS0zMSwgYXQgMTA6NTIsIEdvcnJ5IEZhaXJo dXJzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrIj5nb3JyeUBlcmcu YWJkbi5hYy51azwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyAmIzQzOzEgLSBTaW1wbHk6 IFRoaXMgKmlzKiBjb21wbGljYXRlZCBhbmQgc2VlbXMgdG8gYWRkIGxpdHRsZS48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBTbyBhcyBhbiBpbXBsZW1lbnRvciAoY2hhaXIgaGF0IG9mZiksIHRoaXMgYWRk cyB2ZXJ5IGxpdHRsZSB0byB0aGU8YnI+DQomZ3Q7IG92ZXJhbGwgY29tcGxleGl0eSBvZiB0aGUg cHJvdG9jb2wuPGJyPg0KPGJyPg0KVGhpcyBkb2Vzbid0IHNvdW5kIGdyZWF0LiZuYnNwOyBJdCdz IGEgYml0IGxpa2Ugc2F5aW5nIHRoYXQgYWRkaW5nIHRoZSBIaWdnczxicj4NCm1lY2hhbmlzbSB0 byB0aGUgc3RhbmRhcmQgbW9kZWwncyBsYWdyYW5naWFuIGRvZXNuJ3QgbWFrZSBpdCBtdWNoIG1v cmU8YnI+DQpjb21wbGljYXRlIDotKSZuYnNwOyAoKik8YnI+DQo8YnI+DQpNb3JlIHNlcmlvdXNs eSB0aG91Z2gsIEknZCBsaWtlIHRvIHBvaW50IG91dCB0aGF0IGl0IGlzIG5vdCBqdXN0IGFib3V0 PGJyPg0KaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSwgaXQncyBhbHNvIHRoZSBlbmVyZ3kgY29z dCBwZXIgcGFja2V0IHRoYXQgaXM8YnI+DQpxdWl0ZSBjcnVjaWFsLiZuYnNwOyBJIGhhdmVuJ3Qg ZG9uZSB0aGUgbWF0aCBidXQgSVNUTSB0aGF0IGJyaW5naW5nIGluPGJyPg0KYW5vdGhlciBiYXRj aCBvZiBub24tb3B0aW9uYWwgY3J5cHRvIGNvbXB1dGF0aW9uIG9uIGEgcGVyIHBhY2tldCBiYXNp czxicj4NCmlzIG5vdCBnb2luZyB0byBtb3ZlIHRoZSBuZWVkbGUgaW4gdGhlIHJpZ2h0IGRpcmVj dGlvbiBmb3Igc3RhY2tzIHRoYXQ8YnI+DQpydW4gb24gbG93IHBvd2VyIChJb1QpLjxicj4NCjxi cj4NClRoaXMgaXMgbm90IGEgY2F0YXN0cm9waGUgLSB3ZSBoYXZlIENvQVAgYW5kIGEgKEQpVExT IHByb2ZpbGUgLSBidXQ8YnI+DQpuZWl0aGVyIGl0J3MgaWRlYWwsIHNpbmNlIGN1dHRpbmcgb2Zm IHRoZSBzbWFsbCB0aGluZ3MgZnJvbSB0aGUgd2lkZXI8YnI+DQplY29zeXN0ZW0gY3JlYXRlcyBh biBhcnRpZmljaWFsIGdhcCB3aGljaCB0aGVuIHdpbGwgbmVlZCBhIG1pZGRsZWJveCB0bzxicj4N CmJyaWRnZS4mbmJzcDsgKFN1cmUsIHdlIGhhdmUgc3BlY2lmaWVkIHRoZSBiZWhhdmlvdXIgb2Yg YSBzaW1pbGFyIGJveDxicj4NCmFscmVhZHksIGJ1dCBpdCdkIGJlIHJlYWxseSBiZXR0ZXIgaWYg dGhlIGV4dHJhIHRyYW5zbGF0aW9uIGxvZ2ljIGNvdWxkPGJyPg0KYmUgYXZvaWRlZCBpbiB0aGUg Zmlyc3QgcGxhY2UuKTxicj4NCjxicj4NCkkgZ3Vlc3Mgd2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQg UE4gZW5jcnlwdGlvbiBiZWluZyBhIGNvcmUgbWVjaGFuaXNtPGJyPg0KdGhhdCBjYW4ndCBiZSBu ZWdvdGlhdGVkIGF0IGhhbmRzaGFrZSB0aW1lIHJlZHVjZXMgb3VyIGFiaWxpdHkgdG8gbGF0ZXI8 YnI+DQpwcm9maWxlIFFVSUMgZm9yIHRoZSBJb1QsIHdoaWNoIHdvdWxkIGJlIGEgYml0IHVubHVj a3kuPGJyPg0KPGJyPg0KU28gdGhlIHF1ZXN0aW9uIGlzOiB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0 byBtYWtlIHRoaXMgcHJvcGVydHkgYTxicj4NCmNvbmZpZ3VyYWJsZSBrbm9iIGluc3RlYWQ/PGJy Pg0KPGJyPg0KKCopIDxhIGhyZWY9Imh0dHBzOi8vd3d3LnN5bW1ldHJ5bWFnYXppbmUub3JnL2Fy dGljbGUvdGhlLWRlY29uc3RydWN0ZWQtc3RhbmRhcmQtbW9kZWwtZXF1YXRpb24iIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vd3d3LnN5bW1ldHJ5bWFnYXppbmUub3JnL2FydGljbGUvdGhlLWRl Y29uc3RydWN0ZWQtc3RhbmRhcmQtbW9kZWwtZXF1YXRpb248L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443MBX021W3CA2exch_-- From nobody Sat Feb 3 04:16:58 2018 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 F1EAE1242F7 for ; Sat, 3 Feb 2018 04:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 T6xMQLpTrtZh for ; Sat, 3 Feb 2018 04:16:54 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 727FE124F57 for ; Sat, 3 Feb 2018 04:16:54 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id DBA9841192 for ; Sat, 3 Feb 2018 13:16:52 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id C5BB31A007C for ; Sat, 3 Feb 2018 13:16:52 +0100 (CET) Received: from lat6466.rd.francetelecom.fr (10.168.234.6) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 3 Feb 2018 13:16:52 +0100 Message-ID: <7154_1517660212_5A75A834_7154_203_1_5A75A837.6080702@orange.com> Date: Sat, 3 Feb 2018 13:16:55 +0100 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Subject: Re: Re: Packet number encryption References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.6] 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, 03 Feb 2018 12:16:56 -0000 On -10/01/-28163 20:59, Jana Iyengar wrote: > > There's a win here in terms of implementation complexity and several > implementers have said so. There's a win in terms of ossification and our > experience says so. There's a potential loss of manageability, in being able to > detect reordering. This is the trade-off, and I am still in favor of encrypting > packet numbers. Given this, what's your position re the 4-bit subsequence number in clear proposed earlier ? Is it okay, or has it got too much potential for a signature ? -Alex _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Sat Feb 3 06:04:28 2018 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 673A612DA07 for ; Sat, 3 Feb 2018 06:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 ujtj99Ni5m34 for ; Sat, 3 Feb 2018 06:04:22 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC6112D886 for ; Sat, 3 Feb 2018 06:04:22 -0800 (PST) Received: from mail-ot0-f180.google.com (mail-ot0-f180.google.com [74.125.82.180]) by linode64.ducksong.com (Postfix) with ESMTPSA id 0F6723A092 for ; Sat, 3 Feb 2018 09:04:21 -0500 (EST) Received: by mail-ot0-f180.google.com with SMTP id r23so21515611ote.8 for ; Sat, 03 Feb 2018 06:04:21 -0800 (PST) X-Gm-Message-State: AKwxytevRsufF1TJ7PQGE4cWm4N/3/9Kabl6SQCYr+udCqszvlBtcrF3 WsjTPvkUNHhOcJUDMIWqQL00T+7p8PhPgXcwJCA= X-Google-Smtp-Source: AH8x226u2wHqE639zMk/nmV8+l7P8Ncfai4BkaHh3ysXKsV3VBYM7IVpoJGpONr0R747sNbyL+VQB8GN5ZIpBXOVBmo= X-Received: by 10.157.3.193 with SMTP id f59mr14511089otf.146.1517666660675; Sat, 03 Feb 2018 06:04:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.95.80 with HTTP; Sat, 3 Feb 2018 06:04:20 -0800 (PST) In-Reply-To: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> From: Patrick McManus Date: Sat, 3 Feb 2018 09:04:20 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Packet number encryption To: Piotr Galecki Cc: Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Gorry Fairhust , Eric Rescorla , Christian Huitema , "Eggert, Lars" , Brian Trammell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="94eb2c08ca8032778605644f4e6d" 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, 03 Feb 2018 14:04:26 -0000 --94eb2c08ca8032778605644f4e6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 2, 2018 at 9:59 PM, Piotr Galecki < piotr_galecki@affirmednetworks.com> wrote: > What is the group=E2=80=99s proposal for allowing network monitoring tool= s to > detect packet retransmission or packet reordering ? > quic retransmits data, it does not retransmit packets. I'm not trying to be pedantic - that's the answer to your question because obviously data needs keys. Cooperating parties need to cooperate to share keying material... this is something wireshark and tls have worked out in the past. > These metrics are pretty straightforward to measure for TCP flows. > > Tools like Wireshark can analyze packets and spot issues. > > How can the network tools perform this kind of measurements for QUIC flow= s > if PN field is encrypted? > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar > *Sent:* Friday, February 02, 2018 9:31 PM > *To:* Fossati, Thomas (Nokia - GB/Cambridge, UK) > > *Cc:* Gorry Fairhust ; Eric Rescorla = ; > Mirja K=C3=BChlewind ; Christian Huitema= < > huitema@huitema.net>; Brian Trammell ; Eggert, Lars < > lars@netapp.com>; QUIC WG ; Martin Thomson < > martin.thomson@gmail.com> > *Subject:* Re: Packet number encryption > > > > A few points as I catch up on this thread. > > > > First, I'll remind folks that QUIC is an encrypted transport. I say this > because the cost of this operation is trivial in the context of encryptin= g > every packet. The cost is borne at the servers and not at middleboxes, so > the additional crypto cost is basically trivial. > > > > Second, this simplifies and increases robustness of implementation. > Avoiding random PN jumps, as Kazuho points out, makes special-casing of > code unnecessary. Special code that is exercised occasionally is a strong > bug attractor, and I would strongly argue for as few of those as possible > in implementation. > > > > Third, yes, ossification is a real concern. A simple example: using > increasing packet numbers as a signature for detecting QUIC. Even if you > argue against this example, there are innovative ways in which ossificati= on > will happen. This is based on a true story: We had no idea how GQUIC's > flags field could get ossified, the value that was being used commonly > became used as a signature for QUIC traffic (see Section 7.5 in the SIGCO= MM > QUIC paper > > ). > > > > There's a win here in terms of implementation complexity and several > implementers have said so. There's a win in terms of ossification and our > experience says so. There's a potential loss of manageability, in being > able to detect reordering. This is the trade-off, and I am still in favor > of encrypting packet numbers. > > > > On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK= ) > wrote: > > On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" < > quic-bounces@ietf.org on behalf of lars@netapp.com> wrote: > > On 2018-1-31, at 10:52, Gorry Fairhurst wrote: > > > +1 - Simply: This *is* complicated and seems to add little. > > > > So as an implementor (chair hat off), this adds very little to the > > overall complexity of the protocol. > > This doesn't sound great. It's a bit like saying that adding the Higgs > mechanism to the standard model's lagrangian doesn't make it much more > complicate :-) (*) > > More seriously though, I'd like to point out that it is not just about > implementation complexity, it's also the energy cost per packet that is > quite crucial. I haven't done the math but ISTM that bringing in > another batch of non-optional crypto computation on a per packet basis > is not going to move the needle in the right direction for stacks that > run on low power (IoT). > > This is not a catastrophe - we have CoAP and a (D)TLS profile - but > neither it's ideal, since cutting off the small things from the wider > ecosystem creates an artificial gap which then will need a middlebox to > bridge. (Sure, we have specified the behaviour of a similar box > already, but it'd be really better if the extra translation logic could > be avoided in the first place.) > > I guess what I'm saying is that PN encryption being a core mechanism > that can't be negotiated at handshake time reduces our ability to later > profile QUIC for the IoT, which would be a bit unlucky. > > So the question is: would it be possible to make this property a > configurable knob instead? > > (*) https://www.symmetrymagazine.org/article/the-deconstructed- > standard-model-equation > > > --94eb2c08ca8032778605644f4e6d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 2, 2018 at 9:59 PM, Piotr Galecki <piotr_galecki@= affirmednetworks.com> wrote:

What is the group=E2=80=99s proposal for allowing ne= twork monitoring tools to detect packet retransmission or packet reordering= ?


quic retransmits data, i= t does not retransmit packets. I'm not trying to be pedantic - that'= ;s the answer to your question because obviously data needs keys. Cooperati= ng parties need to cooperate to share keying material... this is something = wireshark and tls have worked out in the past.

=C2=A0

These metrics are pretty straightforward to measure = for TCP flows.

Tools like Wireshark can analyze packets and spot is= sues.

How can the network tools perform this kind of measu= rements for QUIC flows if PN field is encrypted?

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Friday, February 02, 2018 9:31 PM
To: Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com&g= t;
Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>; Eric Rescorla <ekr@rtfm.com>; Mirja K=C3=BChlew= ind <mirja.kuehlewind@tik.ee.ethz.ch>; Christian Huitema <huitema@huitema.net= >; Brian Trammell <ietf@trammell.ch>; Eggert, Lars <lars@netapp.com>; QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Packet number encryption

=C2=A0

A few points as I catch up on this thread.=

=C2=A0

First, I'll remind folks that QUIC is an encrypt= ed transport. I say this because the cost of this operation is trivial in t= he context of encrypting every packet. The cost is borne at the servers and= not at middleboxes, so the additional crypto cost is basically trivial.

=C2=A0

Second, this simplifies and increases robustness of = implementation. Avoiding random PN jumps, as Kazuho points out, makes speci= al-casing of code unnecessary. Special code that is exercised occasionally = is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation.

=C2=A0

Third, yes, ossification is a real concern. A simple= example: using increasing packet numbers as a signature for detecting QUIC= . Even if you argue against this example, there are innovative ways in whic= h ossification will happen. This is based on a true story:=C2=A0We had no idea h= ow GQUIC's flags field could get ossified, the value that was being use= d commonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper).

=C2=A0

There's a win here in terms of implementation co= mplexity and several implementers have said so. There's a win in terms = of ossification and our experience says so. There's a potential loss of= manageability, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet number= s.

=C2=A0

On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nok= ia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:

On 31/01/2018, 10:06,= "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on behalf of lars@netapp.com>= ; wrote:
> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> > +1 - Simply: This *is* complicated and seems to add little.
>
> So as an implementor (chair hat off), this adds very little to the
> overall complexity of the protocol.

This doesn't sound great.=C2=A0 It's a bit like saying that adding = the Higgs
mechanism to the standard model's lagrangian doesn't make it much m= ore
complicate :-)=C2=A0 (*)

More seriously though, I'd like to point out that it is not just about<= br> implementation complexity, it's also the energy cost per packet that is=
quite crucial.=C2=A0 I haven't done the math but ISTM that bringing in<= br> another batch of non-optional crypto computation on a per packet basis
is not going to move the needle in the right direction for stacks that
run on low power (IoT).

This is not a catastrophe - we have CoAP and a (D)TLS profile - but
neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to
bridge.=C2=A0 (Sure, we have specified the behaviour of a similar box
already, but it'd be really better if the extra translation logic could=
be avoided in the first place.)

I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later=
profile QUIC for the IoT, which would be a bit unlucky.

So the question is: would it be possible to make this property a
configurable knob instead?

(*) https://www.symmetrymagazine.org/article/the-deconstructed-standa= rd-model-equation

=C2=A0


--94eb2c08ca8032778605644f4e6d-- From nobody Sat Feb 3 07:04:11 2018 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 A868F12D810 for ; Sat, 3 Feb 2018 07:04:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 fQmIf9ONcIkJ for ; Sat, 3 Feb 2018 07:04:06 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on070e.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1f::70e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DDF912D870 for ; Sat, 3 Feb 2018 07:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U0fvLfaA2AKJo3ok/cddkaV3Banl5ZJNQN3aSRSszuA=; b=s66Rp8fYX+oREVD+FSGXDYqeoFKJb3tYNXAkCwzwEFqUP/Q/x49QCcfYo+H8FAs80HrM1nuxeBHSwyc9DkG4/L/ZcxQW8d0jXZPDdacTTS9VRJP3dwOb0jVi/RJOAwgI57Qrwvj2plIOKu2qjfQqddk7uGAXqyWHzKPz1n6egp0= Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB092.eurprd07.prod.outlook.com (10.242.147.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Sat, 3 Feb 2018 15:04:01 +0000 Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf%13]) with mapi id 15.20.0464.012; Sat, 3 Feb 2018 15:04:00 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: Jana Iyengar CC: "Eggert, Lars" , Gorry Fairhust , Eric Rescorla , Christian Huitema , "Brian Trammell" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , QUIC WG , Martin Thomson , "Fossati, Thomas (Nokia - GB/Cambridge)" Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31fyIlPY67nUiLThH52NyNBqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBlQCAALfegIAA0mqA Date: Sat, 3 Feb 2018 15:04:00 +0000 Message-ID: <6670AEA8-081F-4523-8F1C-DF5B26AF5A0F@nokia.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-originating-ip: [88.111.115.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB092; 7:aBhh7iYi+5EoiM+gpe04MABItQ9SzBdiXJQ6tYpPrph20DdwQ5mBDzPiLATidZZczkNhI+qHSsQb4Br8lZnSSNp6e/XQxbO9ta7t7GBhKtKFEs35TUmi+tcuVQjY8lPuRWiJhHbzn3jScjvFlwD3vJbSy5TyUck0eAu9ZsFiLhxbODsY5mxRtYIS2YUUMWWSY7S+eljh7S0tHw8Vdoj/zsB1a0s/Lu42zln6jFd2K55qlQ4bpMXN6LVRaqxh3Bmk x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(396003)(39860400002)(39380400002)(189003)(199004)(6246003)(81156014)(102836004)(81166006)(2900100001)(8676002)(59450400001)(25786009)(97736004)(6436002)(3280700002)(36756003)(105586002)(6506007)(7736002)(6512007)(76176011)(82746002)(53936002)(305945005)(83716003)(14454004)(4326008)(53546011)(3660700001)(7116003)(39060400002)(83506002)(6916009)(2950100002)(316002)(106356001)(5250100002)(86362001)(5660300001)(6346003)(3480700004)(2906002)(93886005)(66066001)(186003)(54906003)(6486002)(8936002)(68736007)(26005)(99286004)(3846002)(58126008)(478600001)(107886003)(6116002)(33656002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB092; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7b4e3bfd-a921-4683-0198-08d56b175b67 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DB3PR07MB092; x-ms-traffictypediagnostic: DB3PR07MB092: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(11241501184)(806099)(2400082)(944501161)(10201501046)(3002001)(6055026)(6041288)(20161123560045)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB3PR07MB092; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB092; x-forefront-prvs: 05724A8921 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-microsoft-antispam-message-info: 3BCtsBqybKKZ6foWmMjxDboSW7et1Afd+6ucq2da3FC+Bb7UPQRpSdjqhAZuh9cRPtlJEhMEy8TJnvUNRuoa3x970DckCLOiwVtNgHVEjxm4jSJPs5oWkei6Dd/kAVk7 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7b4e3bfd-a921-4683-0198-08d56b175b67 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2018 15:04:00.3909 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB092 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, 03 Feb 2018 15:04:09 -0000 T24gMDMvMDIvMjAxOCwgMDI6MzEsICJKYW5hIEl5ZW5nYXIiIDxqcmlAZ29vZ2xlLmNvbT4gd3Jv dGU6DQo+IEEgZmV3IHBvaW50cyBhcyBJIGNhdGNoIHVwIG9uIHRoaXMgdGhyZWFkLiANCj4gDQo+ IEZpcnN0LCBJJ2xsIHJlbWluZCBmb2xrcyB0aGF0IFFVSUMgaXMgYW4gZW5jcnlwdGVkIHRyYW5z cG9ydC4gSSBzYXkNCj4gdGhpcyBiZWNhdXNlIHRoZSBjb3N0IG9mIHRoaXMgb3BlcmF0aW9uIGlz IHRyaXZpYWwgaW4gdGhlIGNvbnRleHQgb2YNCj4gZW5jcnlwdGluZyBldmVyeSBwYWNrZXQuIFRo ZSBjb3N0IGlzIGJvcm5lIGF0IHRoZSBzZXJ2ZXJzIGFuZCBub3QgYXQNCj4gbWlkZGxlYm94ZXMs IHNvIHRoZSBhZGRpdGlvbmFsIGNyeXB0byBjb3N0IGlzIGJhc2ljYWxseSB0cml2aWFsLg0KDQoi UVVJQyBpcyBhbiBlbmNyeXB0ZWQgdHJhbnNwb3J0IiBpcyBiaXQgdmFndWUgYSBkZWZpbml0aW9u LiAgQW5kIGl0IGlzDQpleGFjdGx5IHRoYXQgdmFndWVuZXNzIHRoYXQgd2UgYXJlIGRpc2N1c3Np bmcgaGVyZSwgSSB0aGluaywgdGhhdCBpczoNCmRlY2lkaW5nIHdoZW4gZ3JleSBiZWNvbWVzIG9u ZSBvZiB3aGl0ZSBvciBibGFjay4NCg0KR29pbmcgYmFjayBmb3IgYSBzZWNvbmQgdG8gSW9UOiBp bWFnaW5lIHVzaW5nIHNob3J0IGhlYWRlciB3aXRoIG5vIENJRCAmDQp0aW55IHBheWxvYWRzIC0g ZS5nLiwgdGhlIHR5cGljYWwgMi00IGJ5dGVzIHBlcmlvZGljIHNlbnNvciByZWFkaW5nLiAgSW4N CnRoaXMgY2FzZSwgUE4gZW5jcnlwdGlvbiB3b3VsZCBpbmNyZWFzZSB0aGUgY3J5cHRvIGNvbXB1 dGUgcGVyIHBhY2tldCBieQ0Kc29tZXRoaW5nIGFyb3VuZCA1MCUsIHdoaWNoIGNhbiBtYWtlIGEg c3Vic3RhbnRpYWwgZGlmZmVyZW5jZSBvbg0KbG93LXBvd2VyLCBiYXR0ZXJ5IG9wZXJhdGVkIGRl dmljZXMuDQoNClRoaXMgaXMgYSByYXRoZXIgZXh0cmVtZSBjYXNlLCBidXQgaXQgc2VydmVzIHRv IGlsbHVzdHJhdGUgdGhlIHBvaW50DQp0aGF0IHdoZW4gbW92aW5nIGluIHRoYXQgZ3JleWlzaCBz cGFjZSwgaXQgbWFrZXMgc2Vuc2UgdG8gbWF5YmUgYWxsb3cNCnJ1bi10aW1lIGNob2ljZXMgaW5z dGVhZCBvZiBmb3JjaW5nIGEgc3BlY2lmaWMgcG9saWN5LCB3aGljaCBoYXMgdGhlDQpwb3RlbnRp YWwgdG8gYWxpZW5hdGUgYW4gZW50aXJlIGNsYXNzIG9mIHVzZSBjYXNlcywgYXQgZGVzaWduIHRp bWUuDQoNCkxldCBlbmRwb2ludHMgbmVnb3RpYXRlIHRoZSBncmV5IGZlYXR1cmUgYW5kIG1ha2Ug aXQgYmxhY2sgb3Igd2hpdGUNCmRlcGVuZGluZyBvbiB0aGVpciBjb3N0LWJlbmVmaXQganVkZ2Vt ZW50Lg0KDQpJbiBwYXJ0aWN1bGFyLCBmcm9tIGEgc2VjdXJpdHkvcHJpdmFjeSBwZXJzcGVjdGl2 ZSwgUE4gZW5jcnlwdGlvbiBsb29rcw0KZW50aXJlbHkgbGlrZSBhIGNsaWVudCBkZWNpc2lvbi4N Cg0KQW5kIHRoZW4gdGhlcmUgaXMgdGhlIG1hbmFnZWFiaWxpdHkgaXNzdWUgdGhhdCBSb25pIGFu ZCBQaW90ciBoYXZlDQpyYWlzZWQsIHdoaWNoIGlzIHZlcnkgaW1wb3J0YW50LCBhbmQgc2hvdWxk IGJlIHdlaWdodGVkIGluIHRoZSBmZWF0dXJlDQpzZWxlY3Rpb24gcHJvY2VzcyBjYXJlZnVsbHku ICBJdCdzIG5vdCBncmVhdCBmb3IgcGVvcGxlIHNpdHRpbmcgaW4gTk9DDQpyb29tcyB0byBoYXZl IHRoZWlyIHRvb2xib3hlcyBhbmQgZXhwZXJ0aXNlIGFubmloaWxhdGVkIGJ5IGEgbWFqb3INCnJv bGxvdXQgYXQgc29tZSBiaWcgY29udGVudCBwcm92aWRlci4NCg0KUmU6IHRoZSBvc3NpZmljYXRp b24gY29uY2Vybi4gIEknbSBhbSB1bmFibGUgdG8gYXNzZXNzIHRoZSBhZHZhbnRhZ2UgUE4NCmVu Y3J5cHRpb24gd291bGQgYnJpbmcgY29tcGFyZWQgdG8gQnJpYW4ncyBhcHByb2FjaCBvZiBjaGFu Z2luZyB0aGUgd2lyZQ0KaW1hZ2UgZnJlcXVlbnRseSBhbmQgaGF2ZSBjby1leGlzdGluZyBpbmNv bXBhdGlibGUgdmVyc2lvbnMgLSBtYWlubHkNCmJlY2F1c2UgaXQncyBwcmV0dHkgZGlmZmljdWx0 IHRvIHRlbGwgbm93IGF0IHdoYXQgcmF0ZSBuZXcgUVVJQyB2ZXJzaW9ucw0Kd2lsbCBiZSByb2xs ZWQgb3V0Lg0KDQpDaGVlcnMhDQoNCg== From nobody Sat Feb 3 07:33:50 2018 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 9409312D87F for ; Sat, 3 Feb 2018 07:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 lR4EzDl3v7Sl for ; Sat, 3 Feb 2018 07:33:47 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE9112D87E for ; Sat, 3 Feb 2018 07:33:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EA4D8BE5B; Sat, 3 Feb 2018 15:33:44 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CpJSkDsmm07d; Sat, 3 Feb 2018 15:33:43 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8109DBE51; Sat, 3 Feb 2018 15:33:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1517672023; bh=7Q+TNslmjCfduow/dftrbc6qO/aHCDScIzNooTrh3vY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=IDLFIFEr2xWqLT5tovnHXv+FZHknX1ZpuFcA1N/TNohGKa8LNKZyILgQkvvjhxpmu Sp+ioZQZI+uJPAsF0Zhny0qCNU2AiI85WU5MnGHJqg+2oYu9ft/qpEuq8RrEruFxeK GP0cuMxprExive2eH60YFRk4YJa/jQRKZp1107+Y= Subject: Re: Packet number encryption To: "Fossati, Thomas (Nokia - GB/Cambridge)" , Jana Iyengar Cc: Gorry Fairhust , Eric Rescorla , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Christian Huitema , Brian Trammell , "Eggert, Lars" , QUIC WG , Martin Thomson References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <6670AEA8-081F-4523-8F1C-DF5B26AF5A0F@nokia.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <2fe4293f-1634-a27c-835b-33c8b24c23c5@cs.tcd.ie> Date: Sat, 3 Feb 2018 15:33:42 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <6670AEA8-081F-4523-8F1C-DF5B26AF5A0F@nokia.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hQvxxl17ihP3PSpt1w3eLcYnC8JumFXLW" 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, 03 Feb 2018 15:33:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hQvxxl17ihP3PSpt1w3eLcYnC8JumFXLW Content-Type: multipart/mixed; boundary="CMQ2Lwy8x2tet6ajTZDgEA4Kbu2WRVCsE"; protected-headers="v1" From: Stephen Farrell To: "Fossati, Thomas (Nokia - GB/Cambridge)" , Jana Iyengar Cc: Gorry Fairhust , Eric Rescorla , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , Christian Huitema , Brian Trammell , "Eggert, Lars" , QUIC WG , Martin Thomson Message-ID: <2fe4293f-1634-a27c-835b-33c8b24c23c5@cs.tcd.ie> Subject: Re: Packet number encryption References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <6670AEA8-081F-4523-8F1C-DF5B26AF5A0F@nokia.com> In-Reply-To: <6670AEA8-081F-4523-8F1C-DF5B26AF5A0F@nokia.com> --CMQ2Lwy8x2tet6ajTZDgEA4Kbu2WRVCsE Content-Type: multipart/mixed; boundary="------------0B2A398859E823C7C72E0B5B" Content-Language: en-GB This is a multi-part message in MIME format. --------------0B2A398859E823C7C72E0B5B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 03/02/18 15:04, Fossati, Thomas (Nokia - GB/Cambridge) wrote: > Going back for a second to IoT: imagine using short header with no CID = & > tiny payloads - e.g., the typical 2-4 bytes periodic sensor reading. I= n > this case, PN encryption would increase the crypto compute per packet b= y > something around 50%, which can make a substantial difference on > low-power, battery operated devices. Sorry - isn't the duration for which the radio is turned on a far more important factor for power consumption in such cases? I don't recall a real case being described where the kind of crypto being described here would make a significant difference but maybe you can describe one? Ta, S. --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------0B2A398859E823C7C72E0B5B Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------0B2A398859E823C7C72E0B5B-- --CMQ2Lwy8x2tet6ajTZDgEA4Kbu2WRVCsE-- --hQvxxl17ihP3PSpt1w3eLcYnC8JumFXLW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaddZXAAoJEFqy+vF7FyvqjLgP/RdRcO5lMkrVnbXwbeR/oF0x WG0WsMhvKqxgL/c4IHaL1elwDi9F6S94mXO7hgCF9a9m/YjeU6nRhXk3SrNpND6n bUm2mxCrxMNpx1bIPzQlGSCf4O/QTtq9i8DuHt522oV0sa1pQAFr22MRJhY+67yf rx9oo5m/7exY7wYzGIuGwsiFL3J753Yfzpg3YymUAxd54yOkG/r3QbC818TShd/g wm4uKrgEDD3JNkmV+o9bDtnkUsWQleZi2DHGchc5RQleuw8PlMPWVTqFN8ujPEQi fEJ7CXCGTCauBBMNyQb6GC/+QH38PpG+GNKeGmP+Wlu8juMOnjHHuzB2R/gbkfLV WjDmAD8foCEhE23/c1MR6fyDULe/Hy8+0a8suPDY1Pb1Jc2y5kLKxBZ/r3zfzyCe smIh40yaJ9UKJptbs+YdPttNS1izzP5/fMuMrbIvKTiX1udyVN75/KIVfpjePGjf kiUx5bZhdydE5mZU3+E0G7CTQWEH5VDHbymDtmrTevivz6+Ho2EgBOUb8C+srS23 6O1iFWJrQIlZrlkvGnWa7x/mpjbcDPusVksCiNTkV0nboPm/3SluUlmeChhfBK9o Ie27yLFnDr5Sp9fOtNV/Mbf1ZNWsUfEessvaAmSV/vpIVFLY+9yaXL0lniHsprUk qhkeI7WsomVSoPd10Z2n =8H+W -----END PGP SIGNATURE----- --hQvxxl17ihP3PSpt1w3eLcYnC8JumFXLW-- From nobody Sat Feb 3 10:39:10 2018 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 178CC12DA00 for ; Sat, 3 Feb 2018 10:39:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, 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=fb.com header.b=pgDM1utr; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Bc+99CMn 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 VLzOZ1EIRl5o for ; Sat, 3 Feb 2018 10:39:06 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 F074012D890 for ; Sat, 3 Feb 2018 10:39:05 -0800 (PST) Received: from pps.filterd (m0044008.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w13IXqfg012012; Sat, 3 Feb 2018 10:38:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=sChxcuKdCa+3hmG4aSv+//StloN4ShtPhsFSSzSeS74=; b=pgDM1utr/Erw6OgODrojpZPlHQP8sLDszLVaUlnFRd29hJ1osIbAepdU+qnnNVGTuuPu pMSlOxFgRFn36fDqIzf+vzCsOLUp79sZyKukeecCD/4V6uKzclLIk5lD6RTL7oDhvLnr skLzCHeLIK5I85hO22yT+SrjdWvoiPhHgcw= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fw9972gpt-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 03 Feb 2018 10:38:18 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 3 Feb 2018 13:38:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sChxcuKdCa+3hmG4aSv+//StloN4ShtPhsFSSzSeS74=; b=Bc+99CMnr7PZ+kA7owXn0YvRd1ELJz10pfpjc3AL8klFtcJugFru48RVzRRYnFFZBJDC1ka1aq7idRbUx9EqKVRvo2BJjiUT7lbWxLXbMpFmLpboNu28gpMoEIPxK1T3IYLyd6TFLQuc9PNZJ9OKLF/HJpJVBxf06MkPWnMZP9c= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0486.namprd15.prod.outlook.com (10.163.110.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Sat, 3 Feb 2018 18:37:57 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0464.012; Sat, 3 Feb 2018 18:37:57 +0000 From: Roberto Peon To: Piotr Galecki , Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" CC: Gorry Fairhust , Eric Rescorla , Christian Huitema , "Eggert, Lars" , Brian Trammell , =?Windows-1252?Q?Mirja_K=FChlewind?= , QUIC WG , Martin Thomson Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW3+HjM5RmHWDkij9J5s6UBSSaOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGB4= Date: Sat, 3 Feb 2018 18:37:56 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> , <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.234.190.115] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0486; 20:q46ccVwZOBYlYZhDw+q9rPUjhd72ySR3NYFV1T/CPULDirJJ+WctTrDDIyEfem3d652LoWEqEznhW+lAUbqkAbrEaGBGZAJckg5sSFZMADZa5mSFqxacsMviDUKKT3BYqQs7L3t8VZklbVjEv3uSrGVYPp4nEN4nWonB7o3y3M0= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c22a8ab4-49b1-4d0f-ce7d-08d56b353ed2 x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0486; x-ms-traffictypediagnostic: BY2PR15MB0486: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(72170088055959)(82608151540597)(85827821059158)(211936372134217)(179696456005106)(153496737603132)(130329453890623); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231101)(11241501184)(2400082)(944501161)(3002001)(93006095)(93001095)(6041288)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR15MB0486; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0486; x-forefront-prvs: 05724A8921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39380400002)(39860400002)(366004)(396003)(11905935001)(377424004)(199004)(189003)(2900100001)(105586002)(4326008)(5660300001)(7116003)(4001150100001)(3846002)(39060400002)(77096007)(6116002)(6506007)(53546011)(102836004)(26005)(25786009)(55016002)(3280700002)(6436002)(99286004)(9686003)(68736007)(2950100002)(236005)(97736004)(229853002)(53936002)(66066001)(86362001)(3660700001)(6306002)(54896002)(74316002)(7736002)(478600001)(6246003)(7416002)(14454004)(2906002)(3480700004)(93886005)(8936002)(8656006)(81156014)(966005)(8676002)(81166006)(7696005)(76176011)(316002)(59450400001)(186003)(54906003)(106356001)(110136005)(33656002)(561944003)(606006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0486; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Ry1cjhvXkpUbIx1wTGDcQsAG8Jq7VBucFzuTRECBG9kS3HV9980TcVBPui4UyofFSMCGE4nmf4zJ1gbdmNSaRQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR15MB07757473DB9788558B902EB5CDF80BY2PR15MB0775namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c22a8ab4-49b1-4d0f-ce7d-08d56b353ed2 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2018 18:37:56.8297 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0486 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-03_05:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 03 Feb 2018 18:39:08 -0000 --_000_BY2PR15MB07757473DB9788558B902EB5CDF80BY2PR15MB0775namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Ossification: In the past tcp middleboxes expected in-order, monotonically increasing off= sets and tried to fix reordering before forwarding. This middlebox behavior= , predicated on observable flows, prevented deployment of things which woul= d have made tcp more efficient. This is the kind of non-theoretical ossification that drove the creation o= f QUIC in the first place. Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. Debugging: Debugging of flows can still happen for flows that wish to be debugged-- th= e QUIC connection's key material(s) can be shared manually and used by the = debugging tool. This is how one debugs http2, https, etc. already today. -=3DR -------- Original message -------- From: Piotr Galecki Date: 2/2/18 7:00 PM (GMT-08:00) To: Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, = UK)" Cc: Gorry Fairhust , Eric Rescorla , Ch= ristian Huitema , "Eggert, Lars" , Br= ian Trammell , Mirja K=FChlewind , QUIC WG , Martin Thomson Subject: RE: Packet number encryption What is the group=92s proposal for allowing network monitoring tools to det= ect packet retransmission or packet reordering ? These metrics are pretty straightforward to measure for TCP flows. Tools like Wireshark can analyze packets and spot issues. How can the network tools perform this kind of measurements for QUIC flows = if PN field is encrypted? From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar Sent: Friday, February 02, 2018 9:31 PM To: Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust ; Eric Rescorla ; Mi= rja K=FChlewind ; Christian Huitema ; Brian Trammell ; Eggert, Lars ; QUIC WG ; Martin Thomson Subject: Re: Packet number encryption A few points as I catch up on this thread. First, I'll remind folks that QUIC is an encrypted transport. I say this be= cause the cost of this operation is trivial in the context of encrypting ev= ery packet. The cost is borne at the servers and not at middleboxes, so the= additional crypto cost is basically trivial. Second, this simplifies and increases robustness of implementation. Avoidin= g random PN jumps, as Kazuho points out, makes special-casing of code unnec= essary. Special code that is exercised occasionally is a strong bug attract= or, and I would strongly argue for as few of those as possible in implement= ation. Third, yes, ossification is a real concern. A simple example: using increas= ing packet numbers as a signature for detecting QUIC. Even if you argue aga= inst this example, there are innovative ways in which ossification will hap= pen. This is based on a true story: We had no idea how GQUIC's flags field = could get ossified, the value that was being used commonly became used as a= signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper). There's a win here in terms of implementation complexity and several implem= enters have said so. There's a win in terms of ossification and our experie= nce says so. There's a potential loss of manageability, in being able to de= tect reordering. This is the trade-off, and I am still in favor of encrypti= ng packet numbers. On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) = > wrote: On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" on behalf of lars@netapp.com> wrote: > On 2018-1-31, at 10:52, Gorry Fairhurst > wrote: > > +1 - Simply: This *is* complicated and seems to add little. > > So as an implementor (chair hat off), this adds very little to the > overall complexity of the protocol. This doesn't sound great. It's a bit like saying that adding the Higgs mechanism to the standard model's lagrangian doesn't make it much more complicate :-) (*) More seriously though, I'd like to point out that it is not just about implementation complexity, it's also the energy cost per packet that is quite crucial. I haven't done the math but ISTM that bringing in another batch of non-optional crypto computation on a per packet basis is not going to move the needle in the right direction for stacks that run on low power (IoT). This is not a catastrophe - we have CoAP and a (D)TLS profile - but neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to bridge. (Sure, we have specified the behaviour of a similar box already, but it'd be really better if the extra translation logic could be avoided in the first place.) I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later profile QUIC for the IoT, which would be a bit unlucky. So the question is: would it be possible to make this property a configurable knob instead? (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-mod= el-equation --_000_BY2PR15MB07757473DB9788558B902EB5CDF80BY2PR15MB0775namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Ossification:
In the past tcp middleboxes expected in-order, monotonically increasin= g offsets and tried to fix reordering before forwarding. This middlebox beh= avior, predicated on observable flows, prevented deployment of things which= would have made tcp more efficient.

 This is the kind of non-theoretical ossification that drove the = creation of QUIC in the first place.

Network monitoring:
Networks may always wrap the packet(s) they have received with whateve= r data they wish, and unwrap before forwarding. This can allow any network = to understand ordering,  loss, etc within its boundaries.

Debugging:
Debugging of flows can still happen for flows that wish to be debugged= -- the QUIC connection's key material(s) can be shared manually and used by= the debugging tool. This is how one debugs http2, https, etc. already toda= y.

-=3DR



-------- Original message --------
From: Piotr Galecki <piotr_galecki@affirmednetworks.com>
Date: 2/2/18 7:00 PM (GMT-08:00)
To: Jana Iyengar <jri@google.com>, "Fossati, Thomas (Nokia = - GB/Cambridge, UK)" <thomas.fossati@nokia.com>
Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla <ekr= @rtfm.com>, Christian Huitema <huitema@huitema.net>, "Eggert,= Lars" <lars@netapp.com>, Brian Trammell <ietf@trammell.ch>= ;, Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>, QUIC WG <q= uic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Subject: RE: Packet number encryption

What is the group=92s proposal for allowing network = monitoring tools to detect packet retransmission or packet reordering ?

These metrics are pretty straightforward to measure = for TCP flows.

Tools like Wireshark can analyze packets and spot is= sues.

How can the network tools perform this kind of measu= rements for QUIC flows if PN field is encrypted?

 

 

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of Jana Iyengar
Sent: Friday, February 02, 2018 9:31 PM
To: Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@no= kia.com>
Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>; Eric Rescorla <e= kr@rtfm.com>; Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>;= Christian Huitema <huitema@huitema.net>; Brian Trammell <ietf@tra= mmell.ch>; Eggert, Lars <lars@netapp.com>; QUIC WG <quic@ietf.o= rg>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Packet number encryption

 

A few points as I catch up on this thread.

 

First, I'll remind folks that QUIC is an encrypted t= ransport. I say this because the cost of this operation is trivial in the c= ontext of encrypting every packet. The cost is borne at the servers and not= at middleboxes, so the additional crypto cost is basically trivial.

 

Second, this simplifies and increases robustness of = implementation. Avoiding random PN jumps, as Kazuho points out, makes speci= al-casing of code unnecessary. Special code that is exercised occasionally = is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation.

 

Third, yes, ossification is a real concern. A simple= example: using increasing packet numbers as a signature for detecting QUIC= . Even if you argue against this example, there are innovative ways in whic= h ossification will happen. This is based on a true story: We had no ide= a how GQUIC's flags field could get ossified, the value that was being used= commonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper).

 

There's a win here in terms of implementation comple= xity and several implementers have said so. There's a win in terms of ossif= ication and our experience says so. There's a potential loss of manageabili= ty, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet number= s.

 

On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nok= ia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:

On 31/01/2018, 10:06,= "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on behalf of lars@netapp.com> wrote:
> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> > +1 - Simply: This *is* complicated and seems to add little. >
> So as an implementor (chair hat off), this adds very little to the
> overall complexity of the protocol.

This doesn't sound great.  It's a bit like saying that adding the Higg= s
mechanism to the standard model's lagrangian doesn't make it much more
complicate :-)  (*)

More seriously though, I'd like to point out that it is not just about
implementation complexity, it's also the energy cost per packet that is
quite crucial.  I haven't done the math but ISTM that bringing in
another batch of non-optional crypto computation on a per packet basis
is not going to move the needle in the right direction for stacks that
run on low power (IoT).

This is not a catastrophe - we have CoAP and a (D)TLS profile - but
neither it's ideal, since cutting off the small things from the wider
ecosystem creates an artificial gap which then will need a middlebox to
bridge.  (Sure, we have specified the behaviour of a similar box
already, but it'd be really better if the extra translation logic could
be avoided in the first place.)

I guess what I'm saying is that PN encryption being a core mechanism
that can't be negotiated at handshake time reduces our ability to later
profile QUIC for the IoT, which would be a bit unlucky.

So the question is: would it be possible to make this property a
configurable knob instead?

(*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-e= quation

 

--_000_BY2PR15MB07757473DB9788558B902EB5CDF80BY2PR15MB0775namp_-- From nobody Sat Feb 3 11:23:40 2018 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 0404F12D955 for ; Sat, 3 Feb 2018 11:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 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 K2cuoCphYY7P for ; Sat, 3 Feb 2018 11:23:34 -0800 (PST) Received: from hub021-ca-5.exch021.serverdata.net (hub021-ca-5.exch021.serverdata.net [64.78.56.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 951BD127871 for ; Sat, 3 Feb 2018 11:23:34 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-5.exch021.domain.local ([10.254.4.89]) with mapi id 14.03.0319.002; Sat, 3 Feb 2018 11:23:33 -0800 From: Piotr Galecki To: Patrick McManus CC: Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Gorry Fairhust , "Eric Rescorla" , Christian Huitema , "Eggert, Lars" , Brian Trammell , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "QUIC WG" , Martin Thomson Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31agylu7WfS0qRkNVQaeIhuKONB2EAgABeoICAAAgUAIAAd3OAgAA8YgCAACPDAIAAAicAgAOBlYCAALfdgP//f2bQgAFCWQD//82ssA== Date: Sat, 3 Feb 2018 19:23:33 +0000 Message-ID: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1F9F@MBX021-W3-CA-2.exch021.domain.local> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] Content-Type: multipart/alternative; boundary="_000_2C515BE8694C6F4B9B6A578BCAC32E2F83BA1F9FMBX021W3CA2exch_" 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: Sat, 03 Feb 2018 19:23:38 -0000 --_000_2C515BE8694C6F4B9B6A578BCAC32E2F83BA1F9FMBX021W3CA2exch_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaXMgdmVyeSB1bmxpa2VseSB0aGF0IGNvbnRlbnQgcHJvdmlkZXIgd291bGQgc2hhcmUga2V5 aW5nIG1hdGVyaWFsIHdpdGggYSBuZXR3b3JrIG9wZXJhdG9yLg0KSWYgYSBzdWJzY3JpYmVyIG1h a2VzIGEgY2FsbCB0byBhIG5ldHdvcmsgb3BlcmF0b3IgdGhhdCBpdCBpcyBnZXR0aW5nIHBvb3Ig dmlkZW8gcXVhbGl0eQ0KdGhlIG5ldHdvcmsgb3BlcmF0b3IgcGVyc29ubmVsIHdvdWxkIGRlYnVn IHBhY2tldCBzdHJlYW0gZGVsaXZlcnkgaXNzdWVzLg0KV2l0aCBUQ1AgdGhlIHN0cmVhbSBjYW4g YmUgY2FwdHVyZWQgYW5kIHRvb2xzIGNhbiBiZSB1c2VkIHRvIG1lYXN1cmUgcGFja2V0L2RhdGEg bG9zcywgbGV2ZWwgb2YgcmV0cmFuc21pc3Npb25zIG9yIG1pc29yZGVyaW5nLg0KVGhpcyBjYW4g YmUgZG9uZSBpbiBkaWZmZXJlbnQgcG9pbnRzIGluIHRoZSBuZXR3b3JrLg0KV2l0aCBRVUlDIGl0 IHNvdW5kcyBsaWtlIG5ldHdvcmsgdHJvdWJsZXNob290aW5nIHdpbGwgYmUgbXVjaCBtb3JlIGRp ZmZpY3VsdC4NCg0KDQpGcm9tOiBQYXRyaWNrIE1jTWFudXMgW21haWx0bzpwbWNtYW51c0Btb3pp bGxhLmNvbV0NClNlbnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAwMywgMjAxOCA5OjA0IEFNDQpUbzog UGlvdHIgR2FsZWNraSA8cGlvdHJfZ2FsZWNraUBhZmZpcm1lZG5ldHdvcmtzLmNvbT4NCkNjOiBK YW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPjsgRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtIEdC L0NhbWJyaWRnZSwgVUspIDx0aG9tYXMuZm9zc2F0aUBub2tpYS5jb20+OyBHb3JyeSBGYWlyaHVz dCA8Z29ycnlAZXJnLmFiZG4uYWMudWs+OyBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBD aHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IEVnZ2VydCwgTGFycyA8bGFy c0BuZXRhcHAuY29tPjsgQnJpYW4gVHJhbW1lbGwgPGlldGZAdHJhbW1lbGwuY2g+OyBNaXJqYSBL w7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPjsgUVVJQyBXRyA8cXVp Y0BpZXRmLm9yZz47IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpT dWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCk9uIEZyaSwgRmViIDIsIDIw MTggYXQgOTo1OSBQTSwgUGlvdHIgR2FsZWNraSA8cGlvdHJfZ2FsZWNraUBhZmZpcm1lZG5ldHdv cmtzLmNvbTxtYWlsdG86cGlvdHJfZ2FsZWNraUBhZmZpcm1lZG5ldHdvcmtzLmNvbT4+IHdyb3Rl Og0KV2hhdCBpcyB0aGUgZ3JvdXDigJlzIHByb3Bvc2FsIGZvciBhbGxvd2luZyBuZXR3b3JrIG1v bml0b3JpbmcgdG9vbHMgdG8gZGV0ZWN0IHBhY2tldCByZXRyYW5zbWlzc2lvbiBvciBwYWNrZXQg cmVvcmRlcmluZyA/DQoNCnF1aWMgcmV0cmFuc21pdHMgZGF0YSwgaXQgZG9lcyBub3QgcmV0cmFu c21pdCBwYWNrZXRzLiBJJ20gbm90IHRyeWluZyB0byBiZSBwZWRhbnRpYyAtIHRoYXQncyB0aGUg YW5zd2VyIHRvIHlvdXIgcXVlc3Rpb24gYmVjYXVzZSBvYnZpb3VzbHkgZGF0YSBuZWVkcyBrZXlz LiBDb29wZXJhdGluZyBwYXJ0aWVzIG5lZWQgdG8gY29vcGVyYXRlIHRvIHNoYXJlIGtleWluZyBt YXRlcmlhbC4uLiB0aGlzIGlzIHNvbWV0aGluZyB3aXJlc2hhcmsgYW5kIHRscyBoYXZlIHdvcmtl ZCBvdXQgaW4gdGhlIHBhc3QuDQoNCg0KVGhlc2UgbWV0cmljcyBhcmUgcHJldHR5IHN0cmFpZ2h0 Zm9yd2FyZCB0byBtZWFzdXJlIGZvciBUQ1AgZmxvd3MuDQpUb29scyBsaWtlIFdpcmVzaGFyayBj YW4gYW5hbHl6ZSBwYWNrZXRzIGFuZCBzcG90IGlzc3Vlcy4NCkhvdyBjYW4gdGhlIG5ldHdvcmsg dG9vbHMgcGVyZm9ybSB0aGlzIGtpbmQgb2YgbWVhc3VyZW1lbnRzIGZvciBRVUlDIGZsb3dzIGlm IFBOIGZpZWxkIGlzIGVuY3J5cHRlZD8NCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yg SmFuYSBJeWVuZ2FyDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDAyLCAyMDE4IDk6MzEgUE0NClRv OiBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBVSykgPHRob21hcy5mb3Nz YXRpQG5va2lhLmNvbTxtYWlsdG86dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPj4NCkNjOiBHb3Jy eSBGYWlyaHVzdCA8Z29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFj LnVrPj47IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj47 IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8bWFpbHRv Om1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+PjsgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1 aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PjsgQnJpYW4gVHJh bW1lbGwgPGlldGZAdHJhbW1lbGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PjsgRWdnZXJ0 LCBMYXJzIDxsYXJzQG5ldGFwcC5jb208bWFpbHRvOmxhcnNAbmV0YXBwLmNvbT4+OyBRVUlDIFdH IDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47IE1hcnRpbiBUaG9tc29uIDxt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+ DQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCkEgZmV3IHBvaW50cyBh cyBJIGNhdGNoIHVwIG9uIHRoaXMgdGhyZWFkLg0KDQpGaXJzdCwgSSdsbCByZW1pbmQgZm9sa3Mg dGhhdCBRVUlDIGlzIGFuIGVuY3J5cHRlZCB0cmFuc3BvcnQuIEkgc2F5IHRoaXMgYmVjYXVzZSB0 aGUgY29zdCBvZiB0aGlzIG9wZXJhdGlvbiBpcyB0cml2aWFsIGluIHRoZSBjb250ZXh0IG9mIGVu Y3J5cHRpbmcgZXZlcnkgcGFja2V0LiBUaGUgY29zdCBpcyBib3JuZSBhdCB0aGUgc2VydmVycyBh bmQgbm90IGF0IG1pZGRsZWJveGVzLCBzbyB0aGUgYWRkaXRpb25hbCBjcnlwdG8gY29zdCBpcyBi YXNpY2FsbHkgdHJpdmlhbC4NCg0KU2Vjb25kLCB0aGlzIHNpbXBsaWZpZXMgYW5kIGluY3JlYXNl cyByb2J1c3RuZXNzIG9mIGltcGxlbWVudGF0aW9uLiBBdm9pZGluZyByYW5kb20gUE4ganVtcHMs IGFzIEthenVobyBwb2ludHMgb3V0LCBtYWtlcyBzcGVjaWFsLWNhc2luZyBvZiBjb2RlIHVubmVj ZXNzYXJ5LiBTcGVjaWFsIGNvZGUgdGhhdCBpcyBleGVyY2lzZWQgb2NjYXNpb25hbGx5IGlzIGEg c3Ryb25nIGJ1ZyBhdHRyYWN0b3IsIGFuZCBJIHdvdWxkIHN0cm9uZ2x5IGFyZ3VlIGZvciBhcyBm ZXcgb2YgdGhvc2UgYXMgcG9zc2libGUgaW4gaW1wbGVtZW50YXRpb24uDQoNClRoaXJkLCB5ZXMs IG9zc2lmaWNhdGlvbiBpcyBhIHJlYWwgY29uY2Vybi4gQSBzaW1wbGUgZXhhbXBsZTogdXNpbmcg aW5jcmVhc2luZyBwYWNrZXQgbnVtYmVycyBhcyBhIHNpZ25hdHVyZSBmb3IgZGV0ZWN0aW5nIFFV SUMuIEV2ZW4gaWYgeW91IGFyZ3VlIGFnYWluc3QgdGhpcyBleGFtcGxlLCB0aGVyZSBhcmUgaW5u b3ZhdGl2ZSB3YXlzIGluIHdoaWNoIG9zc2lmaWNhdGlvbiB3aWxsIGhhcHBlbi4gVGhpcyBpcyBi YXNlZCBvbiBhIHRydWUgc3Rvcnk6IFdlIGhhZCBubyBpZGVhIGhvdyBHUVVJQydzIGZsYWdzIGZp ZWxkIGNvdWxkIGdldCBvc3NpZmllZCwgdGhlIHZhbHVlIHRoYXQgd2FzIGJlaW5nIHVzZWQgY29t bW9ubHkgYmVjYW1lIHVzZWQgYXMgYSBzaWduYXR1cmUgZm9yIFFVSUMgdHJhZmZpYyAoc2VlIFNl Y3Rpb24gNy41IGluIHRoZSBTSUdDT01NIFFVSUMgcGFwZXI8aHR0cHM6Ly9zdGF0aWMuZ29vZ2xl dXNlcmNvbnRlbnQuY29tL21lZGlhL3Jlc2VhcmNoLmdvb2dsZS5jb20vZW4vcHVicy9hcmNoaXZl LzQ2NDAzLnBkZj4pLg0KDQpUaGVyZSdzIGEgd2luIGhlcmUgaW4gdGVybXMgb2YgaW1wbGVtZW50 YXRpb24gY29tcGxleGl0eSBhbmQgc2V2ZXJhbCBpbXBsZW1lbnRlcnMgaGF2ZSBzYWlkIHNvLiBU aGVyZSdzIGEgd2luIGluIHRlcm1zIG9mIG9zc2lmaWNhdGlvbiBhbmQgb3VyIGV4cGVyaWVuY2Ug c2F5cyBzby4gVGhlcmUncyBhIHBvdGVudGlhbCBsb3NzIG9mIG1hbmFnZWFiaWxpdHksIGluIGJl aW5nIGFibGUgdG8gZGV0ZWN0IHJlb3JkZXJpbmcuIFRoaXMgaXMgdGhlIHRyYWRlLW9mZiwgYW5k IEkgYW0gc3RpbGwgaW4gZmF2b3Igb2YgZW5jcnlwdGluZyBwYWNrZXQgbnVtYmVycy4NCg0KT24g RnJpLCBGZWIgMiwgMjAxOCBhdCA3OjMyIEFNLCBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0Iv Q2FtYnJpZGdlLCBVSykgPHRob21hcy5mb3NzYXRpQG5va2lhLmNvbTxtYWlsdG86dGhvbWFzLmZv c3NhdGlAbm9raWEuY29tPj4gd3JvdGU6DQpPbiAzMS8wMS8yMDE4LCAxMDowNiwgIlFVSUMgb24g YmVoYWxmIG9mIEVnZ2VydCwgTGFycyIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgbGFyc0BuZXRhcHAuY29tPG1haWx0bzps YXJzQG5ldGFwcC5jb20+PiB3cm90ZToNCj4gT24gMjAxOC0xLTMxLCBhdCAxMDo1MiwgR29ycnkg RmFpcmh1cnN0IDxnb3JyeUBlcmcuYWJkbi5hYy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMu dWs+PiB3cm90ZToNCj4gPiArMSAtIFNpbXBseTogVGhpcyAqaXMqIGNvbXBsaWNhdGVkIGFuZCBz ZWVtcyB0byBhZGQgbGl0dGxlLg0KPg0KPiBTbyBhcyBhbiBpbXBsZW1lbnRvciAoY2hhaXIgaGF0 IG9mZiksIHRoaXMgYWRkcyB2ZXJ5IGxpdHRsZSB0byB0aGUNCj4gb3ZlcmFsbCBjb21wbGV4aXR5 IG9mIHRoZSBwcm90b2NvbC4NCg0KVGhpcyBkb2Vzbid0IHNvdW5kIGdyZWF0LiAgSXQncyBhIGJp dCBsaWtlIHNheWluZyB0aGF0IGFkZGluZyB0aGUgSGlnZ3MNCm1lY2hhbmlzbSB0byB0aGUgc3Rh bmRhcmQgbW9kZWwncyBsYWdyYW5naWFuIGRvZXNuJ3QgbWFrZSBpdCBtdWNoIG1vcmUNCmNvbXBs aWNhdGUgOi0pICAoKikNCg0KTW9yZSBzZXJpb3VzbHkgdGhvdWdoLCBJJ2QgbGlrZSB0byBwb2lu dCBvdXQgdGhhdCBpdCBpcyBub3QganVzdCBhYm91dA0KaW1wbGVtZW50YXRpb24gY29tcGxleGl0 eSwgaXQncyBhbHNvIHRoZSBlbmVyZ3kgY29zdCBwZXIgcGFja2V0IHRoYXQgaXMNCnF1aXRlIGNy dWNpYWwuICBJIGhhdmVuJ3QgZG9uZSB0aGUgbWF0aCBidXQgSVNUTSB0aGF0IGJyaW5naW5nIGlu DQphbm90aGVyIGJhdGNoIG9mIG5vbi1vcHRpb25hbCBjcnlwdG8gY29tcHV0YXRpb24gb24gYSBw ZXIgcGFja2V0IGJhc2lzDQppcyBub3QgZ29pbmcgdG8gbW92ZSB0aGUgbmVlZGxlIGluIHRoZSBy aWdodCBkaXJlY3Rpb24gZm9yIHN0YWNrcyB0aGF0DQpydW4gb24gbG93IHBvd2VyIChJb1QpLg0K DQpUaGlzIGlzIG5vdCBhIGNhdGFzdHJvcGhlIC0gd2UgaGF2ZSBDb0FQIGFuZCBhIChEKVRMUyBw cm9maWxlIC0gYnV0DQpuZWl0aGVyIGl0J3MgaWRlYWwsIHNpbmNlIGN1dHRpbmcgb2ZmIHRoZSBz bWFsbCB0aGluZ3MgZnJvbSB0aGUgd2lkZXINCmVjb3N5c3RlbSBjcmVhdGVzIGFuIGFydGlmaWNp YWwgZ2FwIHdoaWNoIHRoZW4gd2lsbCBuZWVkIGEgbWlkZGxlYm94IHRvDQpicmlkZ2UuICAoU3Vy ZSwgd2UgaGF2ZSBzcGVjaWZpZWQgdGhlIGJlaGF2aW91ciBvZiBhIHNpbWlsYXIgYm94DQphbHJl YWR5LCBidXQgaXQnZCBiZSByZWFsbHkgYmV0dGVyIGlmIHRoZSBleHRyYSB0cmFuc2xhdGlvbiBs b2dpYyBjb3VsZA0KYmUgYXZvaWRlZCBpbiB0aGUgZmlyc3QgcGxhY2UuKQ0KDQpJIGd1ZXNzIHdo YXQgSSdtIHNheWluZyBpcyB0aGF0IFBOIGVuY3J5cHRpb24gYmVpbmcgYSBjb3JlIG1lY2hhbmlz bQ0KdGhhdCBjYW4ndCBiZSBuZWdvdGlhdGVkIGF0IGhhbmRzaGFrZSB0aW1lIHJlZHVjZXMgb3Vy IGFiaWxpdHkgdG8gbGF0ZXINCnByb2ZpbGUgUVVJQyBmb3IgdGhlIElvVCwgd2hpY2ggd291bGQg YmUgYSBiaXQgdW5sdWNreS4NCg0KU28gdGhlIHF1ZXN0aW9uIGlzOiB3b3VsZCBpdCBiZSBwb3Nz aWJsZSB0byBtYWtlIHRoaXMgcHJvcGVydHkgYQ0KY29uZmlndXJhYmxlIGtub2IgaW5zdGVhZD8N Cg0KKCopIGh0dHBzOi8vd3d3LnN5bW1ldHJ5bWFnYXppbmUub3JnL2FydGljbGUvdGhlLWRlY29u c3RydWN0ZWQtc3RhbmRhcmQtbW9kZWwtZXF1YXRpb24NCg0KDQo= --_000_2C515BE8694C6F4B9B6A578BCAC32E2F83BA1F9FMBX021W3CA2exch_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J dCBpcyB2ZXJ5IHVubGlrZWx5IHRoYXQgY29udGVudCBwcm92aWRlciB3b3VsZCBzaGFyZSBrZXlp bmcgbWF0ZXJpYWwgd2l0aCBhIG5ldHdvcmsgb3BlcmF0b3IuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JZiBhIHN1YnNjcmliZXIgbWFrZXMgYSBjYWxsIHRvIGEgbmV0d29y ayBvcGVyYXRvciB0aGF0IGl0IGlzIGdldHRpbmcgcG9vciB2aWRlbyBxdWFsaXR5PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgbmV0d29yayBvcGVyYXRvciBwZXJzb25u ZWwgd291bGQgZGVidWcgcGFja2V0IHN0cmVhbSBkZWxpdmVyeSBpc3N1ZXMuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIFRDUCB0aGUgc3RyZWFtIGNhbiBiZSBjYXB0 dXJlZCBhbmQgdG9vbHMgY2FuIGJlIHVzZWQgdG8gbWVhc3VyZSBwYWNrZXQvZGF0YSBsb3NzLCBs ZXZlbCBvZiByZXRyYW5zbWlzc2lvbnMgb3IgbWlzb3JkZXJpbmcuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGNhbiBiZSBkb25lIGluIGRpZmZlcmVudCBwb2ludHMg aW4gdGhlIG5ldHdvcmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRo IFFVSUMgaXQgc291bmRzIGxpa2UgbmV0d29yayB0cm91Ymxlc2hvb3Rpbmcgd2lsbCBiZSBtdWNo IG1vcmUgZGlmZmljdWx0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBQYXRyaWNrIE1jTWFudXMg W21haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVyZGF5 LCBGZWJydWFyeSAwMywgMjAxOCA5OjA0IEFNPGJyPg0KPGI+VG86PC9iPiBQaW90ciBHYWxlY2tp ICZsdDtwaW90cl9nYWxlY2tpQGFmZmlybWVkbmV0d29ya3MuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gSmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZndDs7IEZvc3NhdGksIFRob21hcyAo Tm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSAmbHQ7dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tJmd0 OzsgR29ycnkgRmFpcmh1c3QgJmx0O2dvcnJ5QGVyZy5hYmRuLmFjLnVrJmd0OzsgRXJpYyBSZXNj b3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0OzsgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFA aHVpdGVtYS5uZXQmZ3Q7OyBFZ2dlcnQsIExhcnMgJmx0O2xhcnNAbmV0YXBwLmNvbSZndDs7IEJy aWFuDQogVHJhbW1lbGwgJmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7OyBNaXJqYSBLw7xobGV3aW5k ICZsdDttaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoJmd0OzsgUVVJQyBXRyAmbHQ7cXVp Y0BpZXRmLm9yZyZndDs7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFpbC5j b20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBGZWIg MiwgMjAxOCBhdCA5OjU5IFBNLCBQaW90ciBHYWxlY2tpICZsdDs8YSBocmVmPSJtYWlsdG86cGlv dHJfZ2FsZWNraUBhZmZpcm1lZG5ldHdvcmtzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBpb3RyX2dh bGVja2lAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hhdCBp cyB0aGUgZ3JvdXDigJlzIHByb3Bvc2FsIGZvciBhbGxvd2luZyBuZXR3b3JrIG1vbml0b3Jpbmcg dG9vbHMgdG8gZGV0ZWN0IHBhY2tldCByZXRyYW5zbWlzc2lvbiBvciBwYWNrZXQgcmVvcmRlcmlu ZyA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cXVpYyByZXRyYW5zbWl0cyBkYXRhLCBpdCBkb2VzIG5v dCByZXRyYW5zbWl0IHBhY2tldHMuIEknbSBub3QgdHJ5aW5nIHRvIGJlIHBlZGFudGljIC0gdGhh dCdzIHRoZSBhbnN3ZXIgdG8geW91ciBxdWVzdGlvbiBiZWNhdXNlIG9idmlvdXNseSBkYXRhIG5l ZWRzIGtleXMuIENvb3BlcmF0aW5nIHBhcnRpZXMgbmVlZCB0byBjb29wZXJhdGUgdG8gc2hhcmUg a2V5aW5nIG1hdGVyaWFsLi4uIHRoaXMgaXMgc29tZXRoaW5nDQogd2lyZXNoYXJrIGFuZCB0bHMg aGF2ZSB3b3JrZWQgb3V0IGluIHRoZSBwYXN0LiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlc2Ug bWV0cmljcyBhcmUgcHJldHR5IHN0cmFpZ2h0Zm9yd2FyZCB0byBtZWFzdXJlIGZvciBUQ1AgZmxv d3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRvb2xzIGxpa2UgV2ly ZXNoYXJrIGNhbiBhbmFseXplIHBhY2tldHMgYW5kIHNwb3QgaXNzdWVzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ib3cgY2FuIHRoZSBuZXR3b3JrIHRvb2xzIHBlcmZv cm0gdGhpcyBraW5kIG9mIG1lYXN1cmVtZW50cyBmb3IgUVVJQyBmbG93cyBpZiBQTiBmaWVsZCBp cyBlbmNyeXB0ZWQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVp Yy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFuYSBJeWVuZ2Fy PGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMDIsIDIwMTggOTozMSBQTTxicj4N CjxiPlRvOjwvYj4gRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSwgVUspICZs dDs8YSBocmVmPSJtYWlsdG86dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEdvcnJ5 IEZhaXJodXN0ICZsdDs8YSBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiIHRhcmdl dD0iX2JsYW5rIj5nb3JyeUBlcmcuYWJkbi5hYy51azwvYT4mZ3Q7OyBFcmljIFJlc2NvcmxhICZs dDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0u Y29tPC9hPiZndDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJqYS5r dWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIiB0YXJnZXQ9Il9ibGFuayI+bWlyamEua3VlaGxld2lu ZEB0aWsuZWUuZXRoei5jaDwvYT4mZ3Q7Ow0KIENocmlzdGlhbiBIdWl0ZW1hICZsdDs8YSBocmVm PSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh1aXRlbWFAaHVp dGVtYS5uZXQ8L2E+Jmd0OzsgQnJpYW4gVHJhbW1lbGwgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRm QHRyYW1tZWxsLmNoIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkB0cmFtbWVsbC5jaDwvYT4mZ3Q7OyBF Z2dlcnQsIExhcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpsYXJzQG5ldGFwcC5jb20iIHRhcmdldD0i X2JsYW5rIj5sYXJzQG5ldGFwcC5jb208L2E+Jmd0OzsNCiBRVUlDIFdHICZsdDs8YSBocmVmPSJt YWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0 OzsgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QSBmZXcgcG9pbnRzIGFzIEkgY2F0Y2ggdXAgb24g dGhpcyB0aHJlYWQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5GaXJzdCwgSSdsbCByZW1pbmQgZm9sa3MgdGhhdCBRVUlDIGlz IGFuIGVuY3J5cHRlZCB0cmFuc3BvcnQuIEkgc2F5IHRoaXMgYmVjYXVzZSB0aGUgY29zdCBvZiB0 aGlzIG9wZXJhdGlvbiBpcyB0cml2aWFsIGluIHRoZSBjb250ZXh0IG9mIGVuY3J5cHRpbmcgZXZl cnkgcGFja2V0LiBUaGUgY29zdCBpcyBib3JuZQ0KIGF0IHRoZSBzZXJ2ZXJzIGFuZCBub3QgYXQg bWlkZGxlYm94ZXMsIHNvIHRoZSBhZGRpdGlvbmFsIGNyeXB0byBjb3N0IGlzIGJhc2ljYWxseSB0 cml2aWFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+U2Vjb25kLCB0aGlzIHNpbXBsaWZpZXMgYW5kIGluY3JlYXNlcyByb2J1c3RuZXNz IG9mIGltcGxlbWVudGF0aW9uLiBBdm9pZGluZyByYW5kb20gUE4ganVtcHMsIGFzIEthenVobyBw b2ludHMgb3V0LCBtYWtlcyBzcGVjaWFsLWNhc2luZyBvZiBjb2RlIHVubmVjZXNzYXJ5LiBTcGVj aWFsIGNvZGUgdGhhdCBpcw0KIGV4ZXJjaXNlZCBvY2Nhc2lvbmFsbHkgaXMgYSBzdHJvbmcgYnVn IGF0dHJhY3RvciwgYW5kIEkgd291bGQgc3Ryb25nbHkgYXJndWUgZm9yIGFzIGZldyBvZiB0aG9z ZSBhcyBwb3NzaWJsZSBpbiBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoaXJkLCB5ZXMsIG9zc2lmaWNhdGlv biBpcyBhIHJlYWwgY29uY2Vybi4gQSBzaW1wbGUgZXhhbXBsZTogdXNpbmcgaW5jcmVhc2luZyBw YWNrZXQgbnVtYmVycyBhcyBhIHNpZ25hdHVyZSBmb3IgZGV0ZWN0aW5nIFFVSUMuIEV2ZW4gaWYg eW91IGFyZ3VlIGFnYWluc3QgdGhpcyBleGFtcGxlLCB0aGVyZSBhcmUNCiBpbm5vdmF0aXZlIHdh eXMgaW4gd2hpY2ggb3NzaWZpY2F0aW9uIHdpbGwgaGFwcGVuLiBUaGlzIGlzIGJhc2VkIG9uIGEg dHJ1ZSBzdG9yeTombmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3 aGl0ZSI+V2UgaGFkIG5vIGlkZWEgaG93IEdRVUlDJ3MgZmxhZ3MgZmllbGQgY291bGQgZ2V0IG9z c2lmaWVkLCB0aGUgdmFsdWUgdGhhdCB3YXMgYmVpbmcNCiB1c2VkIGNvbW1vbmx5IGJlY2FtZSB1 c2VkIGFzIGEgc2lnbmF0dXJlIGZvciBRVUlDIHRyYWZmaWMgKHNlZSBTZWN0aW9uIDcuNSBpbiB0 aGUNCjxhIGhyZWY9Imh0dHBzOi8vc3RhdGljLmdvb2dsZXVzZXJjb250ZW50LmNvbS9tZWRpYS9y ZXNlYXJjaC5nb29nbGUuY29tL2VuL3B1YnMvYXJjaGl2ZS80NjQwMy5wZGYiIHRhcmdldD0iX2Js YW5rIj4NClNJR0NPTU0gUVVJQyBwYXBlcjwvYT4pLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZXJlJ3MgYSB3aW4gaGVy ZSBpbiB0ZXJtcyBvZiBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5IGFuZCBzZXZlcmFsIGltcGxl bWVudGVycyBoYXZlIHNhaWQgc28uIFRoZXJlJ3MgYSB3aW4gaW4gdGVybXMgb2Ygb3NzaWZpY2F0 aW9uIGFuZCBvdXIgZXhwZXJpZW5jZSBzYXlzIHNvLiBUaGVyZSdzIGEgcG90ZW50aWFsDQogbG9z cyBvZiBtYW5hZ2VhYmlsaXR5LCBpbiBiZWluZyBhYmxlIHRvIGRldGVjdCByZW9yZGVyaW5nLiBU aGlzIGlzIHRoZSB0cmFkZS1vZmYsIGFuZCBJIGFtIHN0aWxsIGluIGZhdm9yIG9mIGVuY3J5cHRp bmcgcGFja2V0IG51bWJlcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmks IEZlYiAyLCAyMDE4IGF0IDc6MzIgQU0sIEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1i cmlkZ2UsIFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5mb3NzYXRpQG5va2lhLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnRob21hcy5mb3NzYXRpQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIDMxLzAxLzIwMTgsIDEwOjA2LCAmcXVvdDtRVUlD IG9uIGJlaGFsZiBvZiBFZ2dlcnQsIExhcnMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmxhcnNAbmV0YXBwLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmxhcnNAbmV0YXBwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgT24gMjAx OC0xLTMxLCBhdCAxMDo1MiwgR29ycnkgRmFpcmh1cnN0ICZsdDs8YSBocmVmPSJtYWlsdG86Z29y cnlAZXJnLmFiZG4uYWMudWsiIHRhcmdldD0iX2JsYW5rIj5nb3JyeUBlcmcuYWJkbi5hYy51azwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyAmIzQzOzEgLSBTaW1wbHk6IFRoaXMgKmlzKiBj b21wbGljYXRlZCBhbmQgc2VlbXMgdG8gYWRkIGxpdHRsZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBT byBhcyBhbiBpbXBsZW1lbnRvciAoY2hhaXIgaGF0IG9mZiksIHRoaXMgYWRkcyB2ZXJ5IGxpdHRs ZSB0byB0aGU8YnI+DQomZ3Q7IG92ZXJhbGwgY29tcGxleGl0eSBvZiB0aGUgcHJvdG9jb2wuPGJy Pg0KPGJyPg0KVGhpcyBkb2Vzbid0IHNvdW5kIGdyZWF0LiZuYnNwOyBJdCdzIGEgYml0IGxpa2Ug c2F5aW5nIHRoYXQgYWRkaW5nIHRoZSBIaWdnczxicj4NCm1lY2hhbmlzbSB0byB0aGUgc3RhbmRh cmQgbW9kZWwncyBsYWdyYW5naWFuIGRvZXNuJ3QgbWFrZSBpdCBtdWNoIG1vcmU8YnI+DQpjb21w bGljYXRlIDotKSZuYnNwOyAoKik8YnI+DQo8YnI+DQpNb3JlIHNlcmlvdXNseSB0aG91Z2gsIEkn ZCBsaWtlIHRvIHBvaW50IG91dCB0aGF0IGl0IGlzIG5vdCBqdXN0IGFib3V0PGJyPg0KaW1wbGVt ZW50YXRpb24gY29tcGxleGl0eSwgaXQncyBhbHNvIHRoZSBlbmVyZ3kgY29zdCBwZXIgcGFja2V0 IHRoYXQgaXM8YnI+DQpxdWl0ZSBjcnVjaWFsLiZuYnNwOyBJIGhhdmVuJ3QgZG9uZSB0aGUgbWF0 aCBidXQgSVNUTSB0aGF0IGJyaW5naW5nIGluPGJyPg0KYW5vdGhlciBiYXRjaCBvZiBub24tb3B0 aW9uYWwgY3J5cHRvIGNvbXB1dGF0aW9uIG9uIGEgcGVyIHBhY2tldCBiYXNpczxicj4NCmlzIG5v dCBnb2luZyB0byBtb3ZlIHRoZSBuZWVkbGUgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBmb3Igc3Rh Y2tzIHRoYXQ8YnI+DQpydW4gb24gbG93IHBvd2VyIChJb1QpLjxicj4NCjxicj4NClRoaXMgaXMg bm90IGEgY2F0YXN0cm9waGUgLSB3ZSBoYXZlIENvQVAgYW5kIGEgKEQpVExTIHByb2ZpbGUgLSBi dXQ8YnI+DQpuZWl0aGVyIGl0J3MgaWRlYWwsIHNpbmNlIGN1dHRpbmcgb2ZmIHRoZSBzbWFsbCB0 aGluZ3MgZnJvbSB0aGUgd2lkZXI8YnI+DQplY29zeXN0ZW0gY3JlYXRlcyBhbiBhcnRpZmljaWFs IGdhcCB3aGljaCB0aGVuIHdpbGwgbmVlZCBhIG1pZGRsZWJveCB0bzxicj4NCmJyaWRnZS4mbmJz cDsgKFN1cmUsIHdlIGhhdmUgc3BlY2lmaWVkIHRoZSBiZWhhdmlvdXIgb2YgYSBzaW1pbGFyIGJv eDxicj4NCmFscmVhZHksIGJ1dCBpdCdkIGJlIHJlYWxseSBiZXR0ZXIgaWYgdGhlIGV4dHJhIHRy YW5zbGF0aW9uIGxvZ2ljIGNvdWxkPGJyPg0KYmUgYXZvaWRlZCBpbiB0aGUgZmlyc3QgcGxhY2Uu KTxicj4NCjxicj4NCkkgZ3Vlc3Mgd2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgUE4gZW5jcnlwdGlv biBiZWluZyBhIGNvcmUgbWVjaGFuaXNtPGJyPg0KdGhhdCBjYW4ndCBiZSBuZWdvdGlhdGVkIGF0 IGhhbmRzaGFrZSB0aW1lIHJlZHVjZXMgb3VyIGFiaWxpdHkgdG8gbGF0ZXI8YnI+DQpwcm9maWxl IFFVSUMgZm9yIHRoZSBJb1QsIHdoaWNoIHdvdWxkIGJlIGEgYml0IHVubHVja3kuPGJyPg0KPGJy Pg0KU28gdGhlIHF1ZXN0aW9uIGlzOiB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBtYWtlIHRoaXMg cHJvcGVydHkgYTxicj4NCmNvbmZpZ3VyYWJsZSBrbm9iIGluc3RlYWQ/PGJyPg0KPGJyPg0KKCop IDxhIGhyZWY9Imh0dHBzOi8vd3d3LnN5bW1ldHJ5bWFnYXppbmUub3JnL2FydGljbGUvdGhlLWRl Y29uc3RydWN0ZWQtc3RhbmRhcmQtbW9kZWwtZXF1YXRpb24iIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vd3d3LnN5bW1ldHJ5bWFnYXppbmUub3JnL2FydGljbGUvdGhlLWRlY29uc3RydWN0ZWQt c3RhbmRhcmQtbW9kZWwtZXF1YXRpb248L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2C515BE8694C6F4B9B6A578BCAC32E2F83BA1F9FMBX021W3CA2exch_-- From nobody Sat Feb 3 16:45:31 2018 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 DC745126C83 for ; Sat, 3 Feb 2018 16:45:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, 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 (2048-bit key) header.d=mnot.net header.b=AZmOvzfa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EXPcVB5v 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 Kv8h_4ILx3KB for ; Sat, 3 Feb 2018 16:45:25 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A17A0124319 for ; Sat, 3 Feb 2018 16:45:25 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 364F021319 for ; Sat, 3 Feb 2018 19:45:23 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Sat, 03 Feb 2018 19:45:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=r7CGc2Y5/lW5RyQ+R fb4gKZeK6ffsq4qGjwPtReshtg=; b=AZmOvzfa8SNe7xhuO4Mo2QMM1EZAPlO4h s1pbZJDIiropNJl/siKR+pH9mA4KL+L3q0dz4VuFBbCc8mXR0QHgqJfkxZZsuB67 2YRLZudJrmykpcRusFn7NZyTS/wYOAo1SxX4sbINpCRX2mx+Hvmvgkg8CJnqcuDK qTD+7hrpwSTQ0Cs5cA+3IZTT2GVQ6L/WIBprFpKffoSO6pTyE0N76R3Z0h7I8AdV lG0MED2wHZ2HKCqzq6HJBI/GQi6BuH9V/xcjjE1BHIhMtTx1/+GkgMcfm9Tz84A1 RLB4vaHmH1ZY1fUIDJnsBpSO0xIr9BjyKl0NSRWUpiezKF6rZqhTw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=r7CGc2Y5/lW5RyQ+Rfb4gKZeK6ffsq4qGjwPtReshtg=; b=EXPcVB5v KqAWQ1LSz0iZ6STP7PaoibN9nGsu9tIcRWf8hywe/flhMMlqVLoypjlID6OQ8xtO nddmUB/MTvhp0uBcp3fwEEVkh5rvASAAdeGWbcPXnvByKqLZKyY63RmGB+oJngIc o93nuAiYpPyUfChfzjw6iQyLuw10HjfJZ8F6ME8KYoULkXE7MDUqPEhhSBeRXleb qWuNN4AOXn/bEBfMmEE5grOpIVLX2SRFbgdNCMMvcyyaKsKOAYN0NxQT2YJmayob oLsAFJ1aXz4Di7MxC3CwIHFh24DSj5oDjzKULg9vTLGLsSXFO1TYFvs4u5k+EzHq 0q/qey+/IMAK4w== X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 7B79F7E3D5 for ; Sat, 3 Feb 2018 19:45:22 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id E056AD2B48 for ; Sun, 4 Feb 2018 00:45:19 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============1630453884764046321==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180204004519.E056AD2B48@cloud.mnot.net> Date: Sun, 4 Feb 2018 00:45:19 +0000 (UTC) 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, 04 Feb 2018 00:45:29 -0000 --===============1630453884764046321== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+5/-4/=F0=9F=92=AC41) 5 issues created: - hq Alt-Svc quic parameter and structured headers (by LPardue) https://github.com/quicwg/base-drafts/issues/1093 - Gapless Optimitisk ACK Attack Mitigation (by mikkelfj) https://github.com/quicwg/base-drafts/issues/1092 - Don't overload PING frame semantics (by janaiyengar) https://github.com/quicwg/base-drafts/issues/1091 - Assymetric connection ID (by mikkelfj) https://github.com/quicwg/base-drafts/issues/1089 - Recommend simulating migration after quiescence (by martinthomson) https://github.com/quicwg/base-drafts/issues/1087 11 issues received 41 new comments: - #1092 Gapless Optimitisk ACK Attack Mitigation (13 by kazuho, marten-se= emann, mikkelfj, ianswett, huitema, MikeBishop) https://github.com/quicwg/base-drafts/issues/1092 - #834 Connection ID is not a number (5 by kazuho, ianswett, janaiyengar,= MikeBishop, mikkelfj) https://github.com/quicwg/base-drafts/issues/834 - #1063 Remove *BLOCKED frames (4 by janaiyengar, grmocg, larseggert, ian= swett) https://github.com/quicwg/base-drafts/issues/1063 - #1085 Handshake failure with Retry and multiple Initial packets (4 by m= artinthomson, MikeBishop) https://github.com/quicwg/base-drafts/issues/1085 - #1087 Recommend simulating migration after quiescence (4 by martinthoms= on, janaiyengar, huitema) https://github.com/quicwg/base-drafts/issues/1087 - #1089 Asymmetric connection ID (3 by martinthomson, ianswett, mikkelfj) https://github.com/quicwg/base-drafts/issues/1089 - #38 First flight size restriction (3 by martinthomson, janaiyengar) https://github.com/quicwg/base-drafts/issues/38 - #1093 hq Alt-Svc quic parameter and structured headers (2 by MikeBishop) https://github.com/quicwg/base-drafts/issues/1093 - #835 How does QPACK delete horizon interact with pushed streams? (1 by = MikeBishop) https://github.com/quicwg/base-drafts/issues/835 - #725 Server might be unable to complete handshake due to MAX_STREAM_DAT= A (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/725 - #1081 Avoid tracking bits in Alt-Svc quic=3D parameter (1 by martinthom= son) https://github.com/quicwg/base-drafts/issues/1081 4 issues closed: - How does QPACK delete horizon interact with pushed streams? https://git= hub.com/quicwg/base-drafts/issues/835 - Stream 0 exemption from flow control https://github.com/quicwg/base-dra= fts/issues/1074 - First flight size restriction https://github.com/quicwg/base-drafts/iss= ues/38 - SNI requirement for HTTP/QUIC https://github.com/quicwg/base-drafts/iss= ues/794 Pull requests ------------- * quicwg/base-drafts (+3/-7/=F0=9F=92=AC28) 3 pull requests submitted: - Mitigate amplification attacks during handshake (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1090 - Introduce PATH_CHALLENGE and PATH_RESPONSE frames (by janaiyengar) https://github.com/quicwg/base-drafts/pull/1086 - Clarify flow control issues on stream 0 (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1082 7 pull requests received 28 new comments: - #1088 A 17 octet connection ID (7 by britram, mcmanus, ekr, martinthoms= on, mikkelfj) https://github.com/quicwg/base-drafts/pull/1088 - #1024 Expand connection management text (5 by martinthomson, mikkelfj,= LPardue, MikeBishop) https://github.com/quicwg/base-drafts/pull/1024 - #348 Define "httpq" (5 by LPardue, MikeBishop) https://github.com/quicwg/base-drafts/pull/348 - #1082 Clarify flow control issues on stream 0 (4 by martinthomson, Mike= Bishop) https://github.com/quicwg/base-drafts/pull/1082 - #1086 Introduces PATH_CHALLENGE and PATH_RESPONSE frames (4 by nibanks,= janaiyengar, mikkelfj) https://github.com/quicwg/base-drafts/pull/1086 - #1079 Packet number encryption (2 by martinthomson, britram) https://github.com/quicwg/base-drafts/pull/1079 - #1083 Rationalize stream 0 flow control (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1083 7 pull requests merged: - Clarify flow control issues on stream 0 https://github.com/quicwg/base-drafts/pull/1082 - Mitigate amplification attacks during handshake https://github.com/quicwg/base-drafts/pull/1090 - Introduces PATH_CHALLENGE and PATH_RESPONSE frames https://github.com/quicwg/base-drafts/pull/1086 - Include max_ack_delay https://github.com/quicwg/base-drafts/pull/1060 - Remove mandatory in-order delivery https://github.com/quicwg/base-drafts/pull/1070 - Version Negotiation doesn't have a packet number https://github.com/quicwg/base-drafts/pull/1078 - Remove misleading changelog entry https://github.com/quicwg/base-drafts/pull/1084 Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============1630453884764046321== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday February 04, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+5/-4/=F0=9F=92=AC41)

5 issues created:

11 issues received 41 new comments:

4 issues closed:

Pull requests

quicwg/base-drafts (+3/-7/=F0=9F=92=AC28)

3 pull requests submitted:

7 pull requests received 28 new comments:

7 pull requests merged:

Repositories tracked by this digest:

--===============1630453884764046321==-- From nobody Sat Feb 3 23:47:43 2018 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 3A90E126CC4 for ; Sat, 3 Feb 2018 23:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.241 X-Spam-Level: X-Spam-Status: No, score=-2.241 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 TIOawmV91_z0 for ; Sat, 3 Feb 2018 23:47:37 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 071BC126BF7 for ; Sat, 3 Feb 2018 23:47:37 -0800 (PST) Received: from LHREML714-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3B34746DF9D90 for ; Sun, 4 Feb 2018 07:47:13 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 4 Feb 2018 07:47:14 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Sun, 4 Feb 2018 15:47:06 +0800 From: "Roni Even (A)" To: Roberto Peon , Piotr Galecki , Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" CC: Gorry Fairhust , Eric Rescorla , =?iso-8859-1?Q?Mirja_K=FChlewind?= , "Eggert, Lars" , Brian Trammell , Christian Huitema , QUIC WG , "Martin Thomson" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31OHIMr4j8BEGT08HQjsZCKqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBlQCAADHCgIAACBkAgAEGFwCAAWG+cA== Date: Sun, 4 Feb 2018 07:47:06 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> , <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.244] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD861B7FDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 04 Feb 2018 07:47:41 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD861B7FDGGEMM506MBXchina_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. RE- so you are saying that we can for example leverage RTP and define RTP= payload for QUIC that will carry QUIC packets, we will just need to resolv= e the MTU size. Roni From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon Sent: Saturday, February 03, 2018 8:38 PM To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; Brian T= rammell; Christian Huitema; QUIC WG; Martin Thomson Subject: Re: Packet number encryption Ossification: In the past tcp middleboxes expected in-order, monotonically increasing off= sets and tried to fix reordering before forwarding. This middlebox behavior= , predicated on observable flows, prevented deployment of things which woul= d have made tcp more efficient. This is the kind of non-theoretical ossification that drove the creation o= f QUIC in the first place. Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. Debugging: Debugging of flows can still happen for flows that wish to be debugged-- th= e QUIC connection's key material(s) can be shared manually and used by the = debugging tool. This is how one debugs http2, https, etc. already today. -=3DR -------- Original message -------- From: Piotr Galecki > Date: 2/2/18 7:00 PM (GMT-08:00) To: Jana Iyengar >, "Fossati, Thomas = (Nokia - GB/Cambridge, UK)" > Cc: Gorry Fairhust >, Eri= c Rescorla >, Christian Huitema >, "Eggert, Lars" >, Brian Trammell >, Mirja K=FChlewind >, QUIC WG >, = Martin Thomson > Subject: RE: Packet number encryption What is the group's proposal for allowing network monitoring tools to detec= t packet retransmission or packet reordering ? These metrics are pretty straightforward to measure for TCP flows. Tools like Wireshark can analyze packets and spot issues. How can the network tools perform this kind of measurements for QUIC flows = if PN field is encrypted? From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar Sent: Friday, February 02, 2018 9:31 PM To: Fossati, Thomas (Nokia - GB/Cambridge, UK) > Cc: Gorry Fairhust >; Eri= c Rescorla >; Mirja K=FChlewind >; Christian= Huitema >; Brian Trammell = >; Eggert, Lars >; QUIC WG >; Ma= rtin Thomson > Subject: Re: Packet number encryption A few points as I catch up on this thread. First, I'll remind folks that QUIC is an encrypted transport. I say this be= cause the cost of this operation is trivial in the context of encrypting ev= ery packet. The cost is borne at the servers and not at middleboxes, so the= additional crypto cost is basically trivial. Second, this simplifies and increases robustness of implementation. Avoidin= g random PN jumps, as Kazuho points out, makes special-casing of code unnec= essary. Special code that is exercised occasionally is a strong bug attract= or, and I would strongly argue for as few of those as possible in implement= ation. Third, yes, ossification is a real concern. A simple example: using increas= ing packet numbers as a signature for detecting QUIC. Even if you argue aga= inst this example, there are innovative ways in which ossification will hap= pen. This is based on a true story: We had no idea how GQUIC's flags field = could get ossified, the value that was being used commonly became used as a= signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper). There's a win here in terms of implementation complexity and several implem= enters have said so. There's a win in terms of ossification and our experie= nce says so. There's a potential loss of manageability, in being able to de= tect reordering. This is the trade-off, and I am still in favor of encrypti= ng packet numbers. On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) = > wrote: On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" on behalf of lars@netapp.com> wrote: > On 2018-1-31, at 10:52, Gorry Fairhurst > wrote: > > +1 - Simply: This *is* complicated and seems to add little. > > So as an implementor (chair hat off), this adds very little to the > overall complexity of the protocol. This doesn't sound great. It's a bit like saying that adding the Higgs mechanism to the standard model's lagrangian doesn't make it much more complicate :-) (*) More seriously though, I'd like to point out that it is not just about implementation complexity, it's also the energy cost per packet that is quite crucial. I haven't done the math but ISTM that bringing in another batch of non-optional crypto computation on a per packet basis is not going to move the needle in the right direction for stacks that run on low power (IoT). This is not a catastrophe - we have CoAP and a (D)TLS profile - but neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to bridge. (Sure, we have specified the behaviour of a similar box already, but it'd be really better if the extra translation logic could be avoided in the first place.) I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later profile QUIC for the IoT, which would be a bit unlucky. So the question is: would it be possible to make this property a configurable knob instead? (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-mod= el-equation --_000_6E58094ECC8D8344914996DAD28F1CCD861B7FDGGEMM506MBXchina_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

Network monitoring:

Networks may always wrap the packet(= s) they have received with whatever data they wish, and unwrap before forwa= rding. This can allow any network to understand ordering,  loss, etc within its boundaries.

 

RE- so you are saying that we can fo= r example  leverage  RTP and define RTP payload for QUIC that wil= l carry QUIC packets, we will just need to resolve the MTU size.=

Roni

 

 

From: QUIC [ma= ilto:quic-bounces@ietf.org] On Behalf Of Roberto Peon
Sent: Saturday, February 03, 2018 8:38 PM
To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambrid= ge, UK)
Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; = Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson
Subject: Re: Packet number encryption

 

Ossification:

In the past tcp middleboxes expected= in-order, monotonically increasing offsets and tried to fix reordering bef= ore forwarding. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp more effic= ient.

 

 This is the kind of non-theore= tical ossification that drove the creation of QUIC in the first place.=

 

Network monitoring:

Networks may always wrap the packet(= s) they have received with whatever data they wish, and unwrap before forwa= rding. This can allow any network to understand ordering,  loss, etc within its boundaries.

 

Debugging:

Debugging of flows can still happen = for flows that wish to be debugged-- the QUIC connection's key material(s) = can be shared manually and used by the debugging tool. This is how one debugs http2, https, etc. already today.

 

-=3DR

 

 

 

-------- Original message --------

From: Piotr Galecki <piotr_galecki@affirmednetworks.co= m>

Date: 2/2/18 7:00 PM (GMT-08:00)

To: Jana Iyengar <jri@google.com>, "Fossati, Thomas (Nokia - G= B/Cambridge, UK)" <thom= as.fossati@nokia.com>

Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla <= ekr@rtfm.com>, Christian Huitema <huitema@huitema.net>, &q= uot;Eggert, Lars" <lars@netapp.c= om>, Brian Trammell <ietf@tra= mmell.ch>, Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>, QUIC WG <quic@ietf.org>, Martin= Thomson <martin.thomson@gma= il.com>

Subject: RE: Packet number encryptio= n

 

What is the group’s proposal for allowing netw= ork monitoring tools to detect packet retransmission or packet reordering ?=

These metrics are pretty straightforward to measure = for TCP flows.

Tools like Wireshark can analyze packets and spot is= sues.

How can the network tools perform this kind of measu= rements for QUIC flows if PN field is encrypted?

 

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Friday, February 02, 2018 9:31 PM
To: Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>
Cc: Gorry Fairhust <gorry= @erg.abdn.ac.uk>; Eric Rescorla <= ekr@rtfm.com>; Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Christian Huitema <huitema@huite= ma.net>; Brian Trammell <ietf= @trammell.ch>; Eggert, Lars <l= ars@netapp.com>; QUIC WG <quic@i= etf.org>; Martin Thomson <martin.thom= son@gmail.com>
Subject: Re: Packet number encryption

 

A few points as I catch up on this thread.

 

First, I'll remind folks that QUIC is an encrypted t= ransport. I say this because the cost of this operation is trivial in the c= ontext of encrypting every packet. The cost is borne at the servers and not= at middleboxes, so the additional crypto cost is basically trivial.

 

Second, this simplifies and increases robustness of = implementation. Avoiding random PN jumps, as Kazuho points out, makes speci= al-casing of code unnecessary. Special code that is exercised occasionally = is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation.

 

Third, yes, ossification is a real concern. A simple= example: using increasing packet numbers as a signature for detecting QUIC= . Even if you argue against this example, there are innovative ways in whic= h ossification will happen. This is based on a true story: We h= ad no idea how GQUIC's flags field could get ossified, the value that was b= eing used commonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper).

 

There's a win here in terms of implementation comple= xity and several implementers have said so. There's a win in terms of ossif= ication and our experience says so. There's a potential loss of manageabili= ty, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet number= s.

 

On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nok= ia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:

On 31/01/2018, 10:06,= "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on behalf of lars@netapp.com> wrote:
> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> > +1 - Simply: This *is* complicated and seems to add little. >
> So as an implementor (chair hat off), this adds very little to the
> overall complexity of the protocol.

This doesn't sound great.  It's a bit like saying that adding the Higg= s
mechanism to the standard model's lagrangian doesn't make it much more
complicate :-)  (*)

More seriously though, I'd like to point out that it is not just about
implementation complexity, it's also the energy cost per packet that is
quite crucial.  I haven't done the math but ISTM that bringing in
another batch of non-optional crypto computation on a per packet basis
is not going to move the needle in the right direction for stacks that
run on low power (IoT).

This is not a catastrophe - we have CoAP and a (D)TLS profile - but
neither it's ideal, since cutting off the small things from the wider
ecosystem creates an artificial gap which then will need a middlebox to
bridge.  (Sure, we have specified the behaviour of a similar box
already, but it'd be really better if the extra translation logic could
be avoided in the first place.)

I guess what I'm saying is that PN encryption being a core mechanism
that can't be negotiated at handshake time reduces our ability to later
profile QUIC for the IoT, which would be a bit unlucky.

So the question is: would it be possible to make this property a
configurable knob instead?

(*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-e= quation

 

--_000_6E58094ECC8D8344914996DAD28F1CCD861B7FDGGEMM506MBXchina_-- From nobody Sun Feb 4 09:19:13 2018 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 7F6B3126C25 for ; Sun, 4 Feb 2018 09:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, 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=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 CFW07V40R6tJ for ; Sun, 4 Feb 2018 09:19:09 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 27EE1120713 for ; Sun, 4 Feb 2018 09:19:09 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w14HHHVC005654; Sun, 4 Feb 2018 17:18:17 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=X7iz+jddYBefSl0yLWDtLaA14ZXAQOaVmdqoPkwumX8=; b=CQDHTNItavwAKcKLyTmuV1aAo3cJasScNmjONKwpsD12Uj5MSPDBkJX1nY8qsZLmB/GF fo6UkEz8rVI+ciKL/TjLRJRzsyil+ZK1LC6a5OHpmoR4omnswyUFxfZb7XO0xpNtnyWu q/Z/iARdL9GXWm8DRXcEuVzUCd9+yflJabSrbRC43phraiGV+/tYxrbRcOV59SxkmdiR YPHUETDj/tgRO5N+3PzUFi0ZyNM8MMcT330+UBeAgSJirAsGTkrGQHc7yky7PzAjVrtu 1OkqAyOYYDc8tYT/RMtmb7TgcYEmymc+C3HZmdBmaYcHKYH3MeIX5iF+PX6yYC6FHbSH CQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2fw5g64tc2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Feb 2018 17:18:16 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w14HFtCj015703; Sun, 4 Feb 2018 12:18:15 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fw9ae39v5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 04 Feb 2018 12:18:15 -0500 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; Sun, 4 Feb 2018 12:18:14 -0500 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; Sun, 4 Feb 2018 12:18:14 -0500 From: "Lubashev, Igor" To: "Roni Even (A)" , Roberto Peon , "Piotr Galecki" , Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" CC: Gorry Fairhust , Eric Rescorla , Christian Huitema , "Eggert, Lars" , Brian Trammell , =?iso-8859-1?Q?Mirja_K=FChlewind?= , QUIC WG , Martin Thomson Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31yPXsGERjf0mXrDq/23iDfaOM1RYAgABeoICAAAgVAIAAd3KAgAA8YgCAACPDAIAAAicAgAOBloCAALfcgIAACBoAgAEGFwCAANx+AIAARbYg Date: Sun, 4 Feb 2018 17:18:13 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> , <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.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.43.20] Content-Type: multipart/alternative; boundary="_000_e529144067624fcba636fc8c24ee3ff4usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802040231 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_03:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802040231 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, 04 Feb 2018 17:19:11 -0000 --_000_e529144067624fcba636fc8c24ee3ff4usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The need to troubleshoot networks (at a minimum, to detect packet loss and = reordering) is real. I would assume that every network would need to have = an ability to do so. Ability to quickly troubleshoot and fix networks is n= ot only "nice" for the networks themselves, but it is also very beneficial = to QUIC users. Having networks wrap and unwrap packets at their boundaries is a possibilit= y, though it has real costs and downsides. First, while networks could set= up such wrapping for UDP port 443 traffic, what about QUIC traffic using ot= her ports? Would networks need to wrap all UDP traffic? Second, this does= reduce MTU for end users, reducing available bandwidth. Third, this would= allow networks to only answer questions like: "Is my network the culprit o= f the problem?" instead of "Is the problem in my network, upstream from me,= or downstream from me?". Would it be considered outrageous to suggest that packet number encryption = be an option negotiated during connection handshake? An end user client in= "Privacy-Enhanced" mode would negotiate this, while end users not particul= arly concerned with connection migration linkability issues would leave thi= s off? - Igor From: Roni Even (A) [mailto:roni.even@huawei.com] Sent: Sunday, February 04, 2018 2:47 AM To: Roberto Peon ; Piotr Galecki ; Jana Iyengar ; Fossati, Thomas (Nokia - GB/Cambri= dge, UK) Cc: Gorry Fairhust ; Eric Rescorla ; Ch= ristian Huitema ; Eggert, Lars ; Bria= n Trammell ; Mirja K=FChlewind ; QUIC WG ; Martin Thomson Subject: RE: Packet number encryption Hi, Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. RE- so you are saying that we can for example leverage RTP and define RTP= payload for QUIC that will carry QUIC packets, we will just need to resolv= e the MTU size. Roni From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon Sent: Saturday, February 03, 2018 8:38 PM To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; Brian T= rammell; Christian Huitema; QUIC WG; Martin Thomson Subject: Re: Packet number encryption Ossification: In the past tcp middleboxes expected in-order, monotonically increasing off= sets and tried to fix reordering before forwarding. This middlebox behavior= , predicated on observable flows, prevented deployment of things which woul= d have made tcp more efficient. This is the kind of non-theoretical ossification that drove the creation o= f QUIC in the first place. Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. Debugging: Debugging of flows can still happen for flows that wish to be debugged-- th= e QUIC connection's key material(s) can be shared manually and used by the = debugging tool. This is how one debugs http2, https, etc. already today. -=3DR -------- Original message -------- From: Piotr Galecki > Date: 2/2/18 7:00 PM (GMT-08:00) To: Jana Iyengar >, "Fossati, Thomas = (Nokia - GB/Cambridge, UK)" > Cc: Gorry Fairhust >, Eri= c Rescorla >, Christian Huitema >, "Eggert, Lars" >, Brian Trammell >, Mirja K=FChlewind >, QUIC WG >, = Martin Thomson > Subject: RE: Packet number encryption What is the group's proposal for allowing network monitoring tools to detec= t packet retransmission or packet reordering ? These metrics are pretty straightforward to measure for TCP flows. Tools like Wireshark can analyze packets and spot issues. How can the network tools perform this kind of measurements for QUIC flows = if PN field is encrypted? From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar Sent: Friday, February 02, 2018 9:31 PM To: Fossati, Thomas (Nokia - GB/Cambridge, UK) > Cc: Gorry Fairhust >; Eri= c Rescorla >; Mirja K=FChlewind >; Christian= Huitema >; Brian Trammell = >; Eggert, Lars >; QUIC WG >; Ma= rtin Thomson > Subject: Re: Packet number encryption A few points as I catch up on this thread. First, I'll remind folks that QUIC is an encrypted transport. I say this be= cause the cost of this operation is trivial in the context of encrypting ev= ery packet. The cost is borne at the servers and not at middleboxes, so the= additional crypto cost is basically trivial. Second, this simplifies and increases robustness of implementation. Avoidin= g random PN jumps, as Kazuho points out, makes special-casing of code unnec= essary. Special code that is exercised occasionally is a strong bug attract= or, and I would strongly argue for as few of those as possible in implement= ation. Third, yes, ossification is a real concern. A simple example: using increas= ing packet numbers as a signature for detecting QUIC. Even if you argue aga= inst this example, there are innovative ways in which ossification will hap= pen. This is based on a true story: We had no idea how GQUIC's flags field = could get ossified, the value that was being used commonly became used as a= signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper). There's a win here in terms of implementation complexity and several implem= enters have said so. There's a win in terms of ossification and our experie= nce says so. There's a potential loss of manageability, in being able to de= tect reordering. This is the trade-off, and I am still in favor of encrypti= ng packet numbers. On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) = > wrote: On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" on behalf of lars@netapp.com> wrote: > On 2018-1-31, at 10:52, Gorry Fairhurst > wrote: > > +1 - Simply: This *is* complicated and seems to add little. > > So as an implementor (chair hat off), this adds very little to the > overall complexity of the protocol. This doesn't sound great. It's a bit like saying that adding the Higgs mechanism to the standard model's lagrangian doesn't make it much more complicate :-) (*) More seriously though, I'd like to point out that it is not just about implementation complexity, it's also the energy cost per packet that is quite crucial. I haven't done the math but ISTM that bringing in another batch of non-optional crypto computation on a per packet basis is not going to move the needle in the right direction for stacks that run on low power (IoT). This is not a catastrophe - we have CoAP and a (D)TLS profile - but neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to bridge. (Sure, we have specified the behaviour of a similar box already, but it'd be really better if the extra translation logic could be avoided in the first place.) I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later profile QUIC for the IoT, which would be a bit unlucky. So the question is: would it be possible to make this property a configurable knob instead? (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-mod= el-equation --_000_e529144067624fcba636fc8c24ee3ff4usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The need to troubleshoot networks (at a minimum, to = detect packet loss and reordering) is real.  I would assume that every= network would need to have an ability to do so.  Ability to quickly t= roubleshoot and fix networks is not only “nice” for the networks themselves, but it is also very beneficial to QUIC users.=

 

Having networks wrap and unwrap packets at their bou= ndaries is a possibility, though it has real costs and downsides.  Fir= st, while networks could setup such wrapping for UDP port 443 traffic, what= about QUIC traffic using other ports?  Would networks need to wrap all UDP traffic?  Second, this does reduc= e MTU for end users, reducing available bandwidth.  Third, this would = allow networks to only answer questions like: “Is my network the culp= rit of the problem?” instead of “Is the problem in my network, upstream from me, or downstream from me?”.=

 

Would it be considered outrageous to suggest that pa= cket number encryption be an option negotiated during connection handshake?=   An end user client in “Privacy-Enhanced” mode would nego= tiate this, while end users not particularly concerned with connection migration linkability issues would leave this off?

 

- Igor

 

 

From: Roni Even (A) [mailto:roni.even@huawei.= com]
Sent: Sunday, February 04, 2018 2:47 AM
To: Roberto Peon <fenix@fb.com>; Piotr Galecki <piotr_galec= ki@affirmednetworks.com>; Jana Iyengar <jri@google.com>; Fossati, = Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>
Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>; Eric Rescorla <e= kr@rtfm.com>; Christian Huitema <huitema@huitema.net>; Eggert, Lar= s <lars@netapp.com>; Brian Trammell <ietf@trammell.ch>; Mirja K= =FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; QUIC WG <quic@ietf.o= rg>; Martin Thomson <martin.thomson@gmail.com>
Subject: RE: Packet number encryption

 

Hi,

Network monitoring:

Networks may always wrap the packet(s) they have= received with whatever data they wish, and unwrap before forwarding. This = can allow any network to understand ordering,  loss, etc within its boundaries.

 

RE- so you are saying that we can for example &n= bsp;leverage  RTP and define RTP payload for QUIC that will carry QUIC= packets, we will just need to resolve the MTU size.

Roni

 

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon
Sent: Saturday, February 03, 2018 8:38 PM
To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambrid= ge, UK)
Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; = Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson
Subject: Re: Packet number encryption

 

Ossification:

In the past tcp middleboxes expected in-order, m= onotonically increasing offsets and tried to fix reordering before forwardi= ng. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp more effic= ient.

 

 This is the kind of non-theoretical ossifi= cation that drove the creation of QUIC in the first place.

 

Network monitoring:

Networks may always wrap the packet(s) they have= received with whatever data they wish, and unwrap before forwarding. This = can allow any network to understand ordering,  loss, etc within its boundaries.

 

Debugging:

Debugging of flows can still happen for flows th= at wish to be debugged-- the QUIC connection's key material(s) can be share= d manually and used by the debugging tool. This is how one debugs http2, https, etc. already today.

 

-=3DR

 

 

 

-------- Original message --------

From: Piotr Galecki <piotr_galecki@affirmednetworks.com>

Date: 2/2/18 7:00 PM (GMT-08:00)

To: Jana Iyengar <jri@google.com>, "Fossati, Thomas (Nokia - GB/Cambridge,= UK)" <thomas.fossati@n= okia.com>

Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla <ekr@rtfm.com>, Christian Huitema <huitema@huitema.net>, "Eggert, Lars" <lars@netap= p.com>, Brian Trammell <ietf@= trammell.ch>, Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>, QUIC WG <quic@ietf.org>, Martin Thomson= <martin.thomson@gmail.com>

Subject: RE: Packet number encryption

 

What is the group’s proposal for allowing netw= ork monitoring tools to detect packet retransmission or packet reordering ?=

These metrics are pretty straightforward to measure = for TCP flows.

Tools like Wireshark can analyze packets and spot is= sues.

How can the network tools perform this kind of measu= rements for QUIC flows if PN field is encrypted?

 

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Friday, February 02, 2018 9:31 PM
To: Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>
Cc: Gorry Fairhust <gorry= @erg.abdn.ac.uk>; Eric Rescorla <= ekr@rtfm.com>; Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Christian Huitema <huitema@huite= ma.net>; Brian Trammell <ietf= @trammell.ch>; Eggert, Lars <l= ars@netapp.com>; QUIC WG <quic@i= etf.org>; Martin Thomson <martin.thom= son@gmail.com>
Subject: Re: Packet number encryption

 

A few points as I catch up on this thread.

 

First, I'll remind folks that QUIC is an encrypted t= ransport. I say this because the cost of this operation is trivial in the c= ontext of encrypting every packet. The cost is borne at the servers and not= at middleboxes, so the additional crypto cost is basically trivial.

 

Second, this simplifies and increases robustness of = implementation. Avoiding random PN jumps, as Kazuho points out, makes speci= al-casing of code unnecessary. Special code that is exercised occasionally = is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation.

 

Third, yes, ossification is a real concern. A simple= example: using increasing packet numbers as a signature for detecting QUIC= . Even if you argue against this example, there are innovative ways in whic= h ossification will happen. This is based on a true story: We had no idea h= ow GQUIC's flags field could get ossified, the value that was being used co= mmonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper).

 

There's a win here in terms of implementation comple= xity and several implementers have said so. There's a win in terms of ossif= ication and our experience says so. There's a potential loss of manageabili= ty, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet number= s.

 

On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nok= ia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:

On 31/01/2018, 10:06,= "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on behalf of lars@netapp.com> wrote:
> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> > +1 - Simply: This *is* complicated and seems to add little. >
> So as an implementor (chair hat off), this adds very little to the
> overall complexity of the protocol.

This doesn't sound great.  It's a bit like saying that adding the Higg= s
mechanism to the standard model's lagrangian doesn't make it much more
complicate :-)  (*)

More seriously though, I'd like to point out that it is not just about
implementation complexity, it's also the energy cost per packet that is
quite crucial.  I haven't done the math but ISTM that bringing in
another batch of non-optional crypto computation on a per packet basis
is not going to move the needle in the right direction for stacks that
run on low power (IoT).

This is not a catastrophe - we have CoAP and a (D)TLS profile - but
neither it's ideal, since cutting off the small things from the wider
ecosystem creates an artificial gap which then will need a middlebox to
bridge.  (Sure, we have specified the behaviour of a similar box
already, but it'd be really better if the extra translation logic could
be avoided in the first place.)

I guess what I'm saying is that PN encryption being a core mechanism
that can't be negotiated at handshake time reduces our ability to later
profile QUIC for the IoT, which would be a bit unlucky.

So the question is: would it be possible to make this property a
configurable knob instead?

(*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-e= quation

 

--_000_e529144067624fcba636fc8c24ee3ff4usma1exdag1mb5msgcorpak_-- From nobody Sun Feb 4 09:34:30 2018 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 C6753127369 for ; Sun, 4 Feb 2018 09:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, 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=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 ihgf9D9CPfha for ; Sun, 4 Feb 2018 09:34:24 -0800 (PST) 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 1B23B1275AB for ; Sun, 4 Feb 2018 09:34:24 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w14HRSOc029911; Sun, 4 Feb 2018 17:33:27 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=C1qsveczqRAIhyi69+iiDMqCtqTiKIvwFwEyopWRzG8=; b=UxK1WjeSJ2Fi1dLPx0Gc0GE9ksGdKqFWzThMYIg5hwFgnIis/5GiWPts0D3egwh/OYQo BIAVKU6Y5oi5jZU1UpLuiGAkBalS9D7m0MDHEYcyt34YO+70DSkyD1ENFaQ8AfFcr3JL 0Huqxgc8FNlio0ZW1d0ewwbKqnksXtwpU5PhTeC2iPGNlDX6sxFQ5Sl5D+92aYOKrdrH GJO1gV5p7w8r1iXuqKtQ8Mv1dDXJOtBemmmATGfrTpiknAYSI3EPzKdr00D8M7X2Ymiz X8bJOEfDhUbGuVTUoCwT/CLvvezd9uMXTucExnafibRJYhLiBY0PdR0RtrqfEUU+7TZI Qw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2fw6cabyc6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Feb 2018 17:33:26 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w14HVVZS027739; Sun, 4 Feb 2018 12:33:25 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fw99yub8j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 04 Feb 2018 12:33:25 -0500 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; Sun, 4 Feb 2018 12:33:24 -0500 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; Sun, 4 Feb 2018 12:33:24 -0500 From: "Lubashev, Igor" To: "Roni Even (A)" , Roberto Peon , "Piotr Galecki" , Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" CC: Gorry Fairhust , Eric Rescorla , Christian Huitema , "Eggert, Lars" , Brian Trammell , =?iso-8859-1?Q?Mirja_K=FChlewind?= , QUIC WG , Martin Thomson Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31yPXsGERjf0mXrDq/23iDfaOM1RYAgABeoICAAAgVAIAAd3KAgAA8YgCAACPDAIAAAicAgAOBloCAALfcgIAACBoAgAEGFwCAANx+AIAARbYggAAHFvA= Date: Sun, 4 Feb 2018 17:33:23 +0000 Message-ID: <5d7fb8e6572448daa1ad34d8e5f0089e@usma1ex-dag1mb5.msg.corp.akamai.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> , <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.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.43.20] Content-Type: multipart/alternative; boundary="_000_5d7fb8e6572448daa1ad34d8e5f0089eusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802040234 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_03:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802040234 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, 04 Feb 2018 17:34:29 -0000 --_000_5d7fb8e6572448daa1ad34d8e5f0089eusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable * Would it be considered outrageous to suggest that packet number encry= ption be an option negotiated during connection handshake? Answering my own question, the trade-off is, of course, is that this opens = up the possibility of network operators choosing to prohibit "enhanced priv= acy" connections by breaking those connections. The dilemma may still be there - QUIC's primary goal is to ensure better en= d user performance, but would that goal be satisfied, if networks find it m= uch harder to troubleshoot QUIC traffic? Or is there no dilemma, and netwo= rks will find ways to effectively troubleshoot QUIC traffic on par with wha= t they can do with TCP? From: Lubashev, Igor Sent: Sunday, February 04, 2018 12:18 PM To: 'Roni Even (A)' ; Roberto Peon ; Pi= otr Galecki ; Jana Iyengar ; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust ; Eric Rescorla ; Ch= ristian Huitema ; Eggert, Lars ; Bria= n Trammell ; Mirja K=FChlewind ; QUIC WG ; Martin Thomson Subject: RE: Packet number encryption The need to troubleshoot networks (at a minimum, to detect packet loss and = reordering) is real. I would assume that every network would need to have = an ability to do so. Ability to quickly troubleshoot and fix networks is n= ot only "nice" for the networks themselves, but it is also very beneficial = to QUIC users. Having networks wrap and unwrap packets at their boundaries is a possibilit= y, though it has real costs and downsides. First, while networks could set= up such wrapping for UDP port 443 traffic, what about QUIC traffic using ot= her ports? Would networks need to wrap all UDP traffic? Second, this does= reduce MTU for end users, reducing available bandwidth. Third, this would= allow networks to only answer questions like: "Is my network the culprit o= f the problem?" instead of "Is the problem in my network, upstream from me,= or downstream from me?". Would it be considered outrageous to suggest that packet number encryption = be an option negotiated during connection handshake? An end user client in= "Privacy-Enhanced" mode would negotiate this, while end users not particul= arly concerned with connection migration linkability issues would leave thi= s off? - Igor From: Roni Even (A) [mailto:roni.even@huawei.com] Sent: Sunday, February 04, 2018 2:47 AM To: Roberto Peon >; Piotr Galecki >; J= ana Iyengar >; Fossati, Thomas (Nokia= - GB/Cambridge, UK) > Cc: Gorry Fairhust >; Eri= c Rescorla >; Christian Huitema >; Eggert, Lars >; Brian Trammell >; Mirja K=FChlewind >; QUIC WG >; Ma= rtin Thomson > Subject: RE: Packet number encryption Hi, Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. RE- so you are saying that we can for example leverage RTP and define RTP= payload for QUIC that will carry QUIC packets, we will just need to resolv= e the MTU size. Roni From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon Sent: Saturday, February 03, 2018 8:38 PM To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; Brian T= rammell; Christian Huitema; QUIC WG; Martin Thomson Subject: Re: Packet number encryption Ossification: In the past tcp middleboxes expected in-order, monotonically increasing off= sets and tried to fix reordering before forwarding. This middlebox behavior= , predicated on observable flows, prevented deployment of things which woul= d have made tcp more efficient. This is the kind of non-theoretical ossification that drove the creation o= f QUIC in the first place. Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. Debugging: Debugging of flows can still happen for flows that wish to be debugged-- th= e QUIC connection's key material(s) can be shared manually and used by the = debugging tool. This is how one debugs http2, https, etc. already today. -=3DR -------- Original message -------- From: Piotr Galecki > Date: 2/2/18 7:00 PM (GMT-08:00) To: Jana Iyengar >, "Fossati, Thomas = (Nokia - GB/Cambridge, UK)" > Cc: Gorry Fairhust >, Eri= c Rescorla >, Christian Huitema >, "Eggert, Lars" >, Brian Trammell >, Mirja K=FChlewind >, QUIC WG >, = Martin Thomson > Subject: RE: Packet number encryption What is the group's proposal for allowing network monitoring tools to detec= t packet retransmission or packet reordering ? These metrics are pretty straightforward to measure for TCP flows. Tools like Wireshark can analyze packets and spot issues. How can the network tools perform this kind of measurements for QUIC flows = if PN field is encrypted? From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar Sent: Friday, February 02, 2018 9:31 PM To: Fossati, Thomas (Nokia - GB/Cambridge, UK) > Cc: Gorry Fairhust >; Eri= c Rescorla >; Mirja K=FChlewind >; Christian= Huitema >; Brian Trammell = >; Eggert, Lars >; QUIC WG >; Ma= rtin Thomson > Subject: Re: Packet number encryption A few points as I catch up on this thread. First, I'll remind folks that QUIC is an encrypted transport. I say this be= cause the cost of this operation is trivial in the context of encrypting ev= ery packet. The cost is borne at the servers and not at middleboxes, so the= additional crypto cost is basically trivial. Second, this simplifies and increases robustness of implementation. Avoidin= g random PN jumps, as Kazuho points out, makes special-casing of code unnec= essary. Special code that is exercised occasionally is a strong bug attract= or, and I would strongly argue for as few of those as possible in implement= ation. Third, yes, ossification is a real concern. A simple example: using increas= ing packet numbers as a signature for detecting QUIC. Even if you argue aga= inst this example, there are innovative ways in which ossification will hap= pen. This is based on a true story: We had no idea how GQUIC's flags field = could get ossified, the value that was being used commonly became used as a= signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper). There's a win here in terms of implementation complexity and several implem= enters have said so. There's a win in terms of ossification and our experie= nce says so. There's a potential loss of manageability, in being able to de= tect reordering. This is the trade-off, and I am still in favor of encrypti= ng packet numbers. On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) = > wrote: On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" on behalf of lars@netapp.com> wrote: > On 2018-1-31, at 10:52, Gorry Fairhurst > wrote: > > +1 - Simply: This *is* complicated and seems to add little. > > So as an implementor (chair hat off), this adds very little to the > overall complexity of the protocol. This doesn't sound great. It's a bit like saying that adding the Higgs mechanism to the standard model's lagrangian doesn't make it much more complicate :-) (*) More seriously though, I'd like to point out that it is not just about implementation complexity, it's also the energy cost per packet that is quite crucial. I haven't done the math but ISTM that bringing in another batch of non-optional crypto computation on a per packet basis is not going to move the needle in the right direction for stacks that run on low power (IoT). This is not a catastrophe - we have CoAP and a (D)TLS profile - but neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to bridge. (Sure, we have specified the behaviour of a similar box already, but it'd be really better if the extra translation logic could be avoided in the first place.) I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later profile QUIC for the IoT, which would be a bit unlucky. So the question is: would it be possible to make this property a configurable knob instead? (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-mod= el-equation --_000_5d7fb8e6572448daa1ad34d8e5f0089eusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
  • Would it be considered outrageous to suggest that packet number encry= ption be an option negotiated during connection handshake?
    • <= /ul>

     

    Answering my own question, the trade-off is, of cour= se, is that this opens up the possibility of network operators choosing to = prohibit “enhanced privacy” connections by breaking those conne= ctions.

     

    The dilemma may still be there – QUIC’s = primary goal is to ensure better end user performance, but would that goal = be satisfied, if networks find it much harder to troubleshoot QUIC traffic?=   Or is there no dilemma, and networks will find ways to effectively troubleshoot QUIC traffic on par with what they can do= with TCP?

     

     

    From: Lubashev, Igor
    Sent: Sunday, February 04, 2018 12:18 PM
    To: 'Roni Even (A)' <roni.even@huawei.com>; Roberto Peon <f= enix@fb.com>; Piotr Galecki <piotr_galecki@affirmednetworks.com>; = Jana Iyengar <jri@google.com>; Fossati, Thomas (Nokia - GB/Cambridge,= UK) <thomas.fossati@nokia.com>
    Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>; Eric Rescorla <e= kr@rtfm.com>; Christian Huitema <huitema@huitema.net>; Eggert, Lar= s <lars@netapp.com>; Brian Trammell <ietf@trammell.ch>; Mirja K= =FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; QUIC WG <quic@ietf.o= rg>; Martin Thomson <martin.thomson@gmail.com>
    Subject: RE: Packet number encryption

     

    The need to troubleshoot networks (at a minimum, to = detect packet loss and reordering) is real.  I would assume that every= network would need to have an ability to do so.  Ability to quickly t= roubleshoot and fix networks is not only “nice” for the networks themselves, but it is also very beneficial to QUIC users.=

     

    Having networks wrap and unwrap packets at their bou= ndaries is a possibility, though it has real costs and downsides.  Fir= st, while networks could setup such wrapping for UDP port 443 traffic, what= about QUIC traffic using other ports?  Would networks need to wrap all UDP traffic?  Second, this does reduc= e MTU for end users, reducing available bandwidth.  Third, this would = allow networks to only answer questions like: “Is my network the culp= rit of the problem?” instead of “Is the problem in my network, upstream from me, or downstream from me?”.=

     

    Would it be considered outrageous to suggest that pa= cket number encryption be an option negotiated during connection handshake?=   An end user client in “Privacy-Enhanced” mode would nego= tiate this, while end users not particularly concerned with connection migration linkability issues would leave this off?

     

    - Igor

     

     

    From: Roni Even (A) [mailto:roni.even@huawei.com]
    Sent: Sunday, February 04, 2018 2:47 AM
    To: Roberto Peon <fenix@fb.com>; Piotr Galecki <piotr_galecki@affirmednetworks.com>; Jana Iyengar <jri@google.com>; Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>
    Cc: Gorry Fairhust <gorry= @erg.abdn.ac.uk>; Eric Rescorla <= ekr@rtfm.com>; Christian Huitema <huitema@huitema.net>; Eggert, Lars <lars@netapp.com>; Brian Trammell <ietf@trammell.ch>; Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>
    Subject: RE: Packet number encryption

     

    Hi,

    Network monitoring:

    Networks may always wrap the packet(s) they have= received with whatever data they wish, and unwrap before forwarding. This = can allow any network to understand ordering,  loss, etc within its boundaries.

     

    RE- so you are saying that we can for example &n= bsp;leverage  RTP and define RTP payload for QUIC that will carry QUIC= packets, we will just need to resolve the MTU size.

    Roni

     

     

    From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon
    Sent: Saturday, February 03, 2018 8:38 PM
    To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambrid= ge, UK)
    Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; = Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson
    Subject: Re: Packet number encryption

     

    Ossification:

    In the past tcp middleboxes expected in-order, m= onotonically increasing offsets and tried to fix reordering before forwardi= ng. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp more effic= ient.

     

     This is the kind of non-theoretical ossifi= cation that drove the creation of QUIC in the first place.

     

    Network monitoring:

    Networks may always wrap the packet(s) they have= received with whatever data they wish, and unwrap before forwarding. This = can allow any network to understand ordering,  loss, etc within its boundaries.

     

    Debugging:

    Debugging of flows can still happen for flows th= at wish to be debugged-- the QUIC connection's key material(s) can be share= d manually and used by the debugging tool. This is how one debugs http2, https, etc. already today.

     

    -=3DR

     

     

     

    -------- Original message --------

    From: Piotr Galecki <piotr_galecki@affirmednetworks.com>

    Date: 2/2/18 7:00 PM (GMT-08:00)

    To: Jana Iyengar <jri@google.com>, "Fossati, Thomas (Nokia - GB/Cambridge,= UK)" <thomas.fossati@n= okia.com>

    Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla <ekr@rtfm.com>, Christian Huitema <huitema@huitema.net>, "Eggert, Lars" <lars@netap= p.com>, Brian Trammell <ietf@= trammell.ch>, Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>, QUIC WG <quic@ietf.org>, Martin Thomson= <martin.thomson@gmail.com>

    Subject: RE: Packet number encryption

     

    What is the group’s proposal for allowing netw= ork monitoring tools to detect packet retransmission or packet reordering ?=

    These metrics are pretty straightforward to measure = for TCP flows.

    Tools like Wireshark can analyze packets and spot is= sues.

    How can the network tools perform this kind of measu= rements for QUIC flows if PN field is encrypted?

     

     

    From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
    Sent: Friday, February 02, 2018 9:31 PM
    To: Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>
    Cc: Gorry Fairhust <gorry= @erg.abdn.ac.uk>; Eric Rescorla <= ekr@rtfm.com>; Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Christian Huitema <huitema@huite= ma.net>; Brian Trammell <ietf= @trammell.ch>; Eggert, Lars <l= ars@netapp.com>; QUIC WG <quic@i= etf.org>; Martin Thomson <martin.thom= son@gmail.com>
    Subject: Re: Packet number encryption

     

    A few points as I catch up on this thread.

     

    First, I'll remind folks that QUIC is an encrypted t= ransport. I say this because the cost of this operation is trivial in the c= ontext of encrypting every packet. The cost is borne at the servers and not= at middleboxes, so the additional crypto cost is basically trivial.

     

    Second, this simplifies and increases robustness of = implementation. Avoiding random PN jumps, as Kazuho points out, makes speci= al-casing of code unnecessary. Special code that is exercised occasionally = is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation.

     

    Third, yes, ossification is a real concern. A simple= example: using increasing packet numbers as a signature for detecting QUIC= . Even if you argue against this example, there are innovative ways in whic= h ossification will happen. This is based on a true story: We had no idea h= ow GQUIC's flags field could get ossified, the value that was being used co= mmonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper).

     

    There's a win here in terms of implementation comple= xity and several implementers have said so. There's a win in terms of ossif= ication and our experience says so. There's a potential loss of manageabili= ty, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet number= s.

     

    On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nok= ia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:

    On 31/01/2018, 10:06,= "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on behalf of lars@netapp.com> wrote:
    > On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
    > > +1 - Simply: This *is* complicated and seems to add little. >
    > So as an implementor (chair hat off), this adds very little to the
    > overall complexity of the protocol.

    This doesn't sound great.  It's a bit like saying that adding the Higg= s
    mechanism to the standard model's lagrangian doesn't make it much more
    complicate :-)  (*)

    More seriously though, I'd like to point out that it is not just about
    implementation complexity, it's also the energy cost per packet that is
    quite crucial.  I haven't done the math but ISTM that bringing in
    another batch of non-optional crypto computation on a per packet basis
    is not going to move the needle in the right direction for stacks that
    run on low power (IoT).

    This is not a catastrophe - we have CoAP and a (D)TLS profile - but
    neither it's ideal, since cutting off the small things from the wider
    ecosystem creates an artificial gap which then will need a middlebox to
    bridge.  (Sure, we have specified the behaviour of a similar box
    already, but it'd be really better if the extra translation logic could
    be avoided in the first place.)

    I guess what I'm saying is that PN encryption being a core mechanism
    that can't be negotiated at handshake time reduces our ability to later
    profile QUIC for the IoT, which would be a bit unlucky.

    So the question is: would it be possible to make this property a
    configurable knob instead?

    (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-e= quation

     

--_000_5d7fb8e6572448daa1ad34d8e5f0089eusma1exdag1mb5msgcorpak_-- From nobody Sun Feb 4 09:35:57 2018 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 013591275AB for ; Sun, 4 Feb 2018 09:35:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 yQWppjkbncFY for ; Sun, 4 Feb 2018 09:35:51 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 CB92B127369 for ; Sun, 4 Feb 2018 09:35:50 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id f4so27932649ioh.8 for ; Sun, 04 Feb 2018 09:35:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=dE4Bf+gqYhFzZJf30tB3qgIJ1XJn1Fqb/NF0eWqeP2o=; b=NSddxIw013Abq4kZ0tK+/JvvEot/jU8yh2hxsDL8tlSn3KtLMFcgtBFpdbqeFIJOs3 YPlzVkaWJ/xSgmiVpC5RNFRLdN0Tzwyv5t7tLchmg7NAtUYZ/j59AJ+u0lJn7/SNG4u8 zhQxBsCV5Ud15XubAZ8rM8ZxXdtVKJR8A/Xy9+ZDZG0hWrWMk3A/WwXCaWwSI8SsHIeZ h0kaoeW9dhagPoN72WVmDSv0qFrnAEwSl+w554WCS+5MlgyrQ+9b5TLfE5lQVjTJIcYl XCAW2HrJ6zo9GRF1Nd+cThQVwZlPsEeZavYSWCQtW531h3ZlbobtG6h+29kn1aln1H4U IJUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=dE4Bf+gqYhFzZJf30tB3qgIJ1XJn1Fqb/NF0eWqeP2o=; b=KKQKIoEhamX3Ga0+jG1mNo2eCtppZskGW0keQbpzLfZH8u0+POo3KXwTLapxlygRkr RdkXHOSfreSmtBp4tHZvEimcDj2/SWWB/JcetKldjrHzG9l27/1agXYO8i2TgYUiYM9G 2pvmqvmQvaFsry4Ctp/PmU3YEgP/XezDebxyQk25GaUnDHciOpCbdbyOoLZwO/8Fr7Xl eF8RYos/PxKfP8wsZJjOlyxoYbkrm3OE+egy43FHJj56z80c5EsEwtABEFqjn6XoPRnD AFkcyYEIVFVMy9UZHktlNriJsnYOObTUbfjK3HNFwZH54BgS3hxb62RL5Wm9h5y+OUf1 g4Tw== X-Gm-Message-State: AKwxytc4OaC1wZ0ZUv6ZgMm0sht30JaYPkCuMU7eTcg2mvvV5/lXcuDc 1WoPn56lNGy2lr+s9fVyHAF/NhthipCQv/sdhj8= X-Google-Smtp-Source: AH8x225UBLXSkDCsdjLAdq+4YqBMfX0EbH1YQDpQ6qMmwQtnHkbzSC+ZYof84e809QPG4xtT/DENQsuvpeah4yd4baE= X-Received: by 10.107.140.207 with SMTP id o198mr49713243iod.175.1517765750109; Sun, 04 Feb 2018 09:35:50 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 4 Feb 2018 09:35:48 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 4 Feb 2018 09:35:48 -0800 Message-ID: Subject: RE: Packet number encryption To: "Roni Even (A)" , Jana Iyengar , Roberto Peon , "Lubashev, Igor" , Piotr Galecki , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: QUIC WG , Brian Trammell , Martin Thomson , Eric Rescorla , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , Gorry Fairhust , "Eggert, Lars" Content-Type: multipart/alternative; boundary="94eb2c05a3ec633bed05646660c5" 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, 04 Feb 2018 17:35:55 -0000 --94eb2c05a3ec633bed05646660c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If you need to troubleshoot a network, what prevents you from injecting probe packets with random content on the same route? The more opaque QUIC is, the more likely it is that probe packets would behave the same. For that matter, QUIC could define stateless probe packets that must route the same as real connections. Mikkel On 4 February 2018 at 18.19.16, Lubashev, Igor (ilubashe@akamai.com) wrote: The need to troubleshoot networks (at a minimum, to detect packet loss and reordering) is real. I would assume that every network would need to have an ability to do so. Ability to quickly troubleshoot and fix networks is not only =E2=80=9Cnice=E2=80=9D for the networks themselves, but it is also= very beneficial to QUIC users. Having networks wrap and unwrap packets at their boundaries is a possibility, though it has real costs and downsides. First, while networks could setup such wrapping for UDP port 443 traffic, what about QUIC traffic using other ports? Would networks need to wrap all UDP traffic? Second, this does reduce MTU for end users, reducing available bandwidth. Third, this would allow networks to only answer questions like: =E2=80=9CIs my net= work the culprit of the problem?=E2=80=9D instead of =E2=80=9CIs the problem in my n= etwork, upstream from me, or downstream from me?=E2=80=9D. Would it be considered outrageous to suggest that packet number encryption be an option negotiated during connection handshake? An end user client in =E2=80=9CPrivacy-Enhanced=E2=80=9D mode would negotiate this, while end use= rs not particularly concerned with connection migration linkability issues would leave this off? - Igor *From:* Roni Even (A) [mailto:roni.even@huawei.com] *Sent:* Sunday, February 04, 2018 2:47 AM *To:* Roberto Peon ; Piotr Galecki < piotr_galecki@affirmednetworks.com>; Jana Iyengar ; Fossati, Thomas (Nokia - GB/Cambridge, UK) *Cc:* Gorry Fairhust ; Eric Rescorla ; Christian Huitema ; Eggert, Lars ; Brian Trammell ; Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch>; QUIC WG ; Martin Thomson < martin.thomson@gmail.com> *Subject:* RE: Packet number encryption Hi, Network monitoring: Networks may always wrap the packet(s) they have received with whatever data they wish, and unwrap before forwarding. This can allow any network to understand ordering, loss, etc within its boundaries. RE- so you are saying that we can for example leverage RTP and define RTP payload for QUIC that will carry QUIC packets, we will just need to resolve the MTU size. Roni *From:* QUIC [mailto:quic-bounces@ietf.org ] *On Behalf Of *Roberto Peon *Sent:* Saturday, February 03, 2018 8:38 PM *To:* Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK) *Cc:* Gorry Fairhust; Eric Rescorla; Mirja K=C3=BChlewind; Eggert, Lars; Br= ian Trammell; Christian Huitema; QUIC WG; Martin Thomson *Subject:* Re: Packet number encryption Ossification: In the past tcp middleboxes expected in-order, monotonically increasing offsets and tried to fix reordering before forwarding. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp more efficient. This is the kind of non-theoretical ossification that drove the creation of QUIC in the first place. Network monitoring: Networks may always wrap the packet(s) they have received with whatever data they wish, and unwrap before forwarding. This can allow any network to understand ordering, loss, etc within its boundaries. Debugging: Debugging of flows can still happen for flows that wish to be debugged-- the QUIC connection's key material(s) can be shared manually and used by the debugging tool. This is how one debugs http2, https, etc. already today= . -=3DR -------- Original message -------- From: Piotr Galecki Date: 2/2/18 7:00 PM (GMT-08:00) To: Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: Gorry Fairhust , Eric Rescorla , Christian Huitema , "Eggert, Lars" , Brian Trammell , Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch>, QUIC WG , Martin Thomson < martin.thomson@gmail.com> Subject: RE: Packet number encryption What is the group=E2=80=99s proposal for allowing network monitoring tools = to detect packet retransmission or packet reordering ? These metrics are pretty straightforward to measure for TCP flows. Tools like Wireshark can analyze packets and spot issues. How can the network tools perform this kind of measurements for QUIC flows if PN field is encrypted? *From:* QUIC [mailto:quic-bounces@ietf.org ] *On Behalf Of *Jana Iyengar *Sent:* Friday, February 02, 2018 9:31 PM *To:* Fossati, Thomas (Nokia - GB/Cambridge, UK) *Cc:* Gorry Fairhust ; Eric Rescorla ; Mirja K=C3=BChlewind ; Christian Huitema < huitema@huitema.net>; Brian Trammell ; Eggert, Lars < lars@netapp.com>; QUIC WG ; Martin Thomson < martin.thomson@gmail.com> *Subject:* Re: Packet number encryption A few points as I catch up on this thread. First, I'll remind folks that QUIC is an encrypted transport. I say this because the cost of this operation is trivial in the context of encrypting every packet. The cost is borne at the servers and not at middleboxes, so the additional crypto cost is basically trivial. Second, this simplifies and increases robustness of implementation. Avoiding random PN jumps, as Kazuho points out, makes special-casing of code unnecessary. Special code that is exercised occasionally is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation. Third, yes, ossification is a real concern. A simple example: using increasing packet numbers as a signature for detecting QUIC. Even if you argue against this example, there are innovative ways in which ossification will happen. This is based on a true story: We had no idea how GQUIC's flags field could get ossified, the value that was being used commonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper ). There's a win here in terms of implementation complexity and several implementers have said so. There's a win in terms of ossification and our experience says so. There's a potential loss of manageability, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet numbers. On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) = < thomas.fossati@nokia.com> wrote: On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" < quic-bounces@ietf.org on behalf of lars@netapp.com> wrote: > On 2018-1-31, at 10:52, Gorry Fairhurst wrote: > > +1 - Simply: This *is* complicated and seems to add little. > > So as an implementor (chair hat off), this adds very little to the > overall complexity of the protocol. This doesn't sound great. It's a bit like saying that adding the Higgs mechanism to the standard model's lagrangian doesn't make it much more complicate :-) (*) More seriously though, I'd like to point out that it is not just about implementation complexity, it's also the energy cost per packet that is quite crucial. I haven't done the math but ISTM that bringing in another batch of non-optional crypto computation on a per packet basis is not going to move the needle in the right direction for stacks that run on low power (IoT). This is not a catastrophe - we have CoAP and a (D)TLS profile - but neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to bridge. (Sure, we have specified the behaviour of a similar box already, but it'd be really better if the extra translation logic could be avoided in the first place.) I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later profile QUIC for the IoT, which would be a bit unlucky. So the question is: would it be possible to make this property a configurable knob instead? (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-e= quation --94eb2c05a3ec633bed05646660c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = If you need to troub= leshoot a network, what prevents you from injecting probe packets with rand= om content on the same route? The more opaque QUIC is, the more likely it i= s that probe packets would behave the same.

For that matter, QUIC could define stateless probe p= ackets that must route the same as real connections.

Mikk= el


On 4 February 2018 at 18= .19.16, Lubashev, Igor (ilubashe@aka= mai.com) wrote:

=

The need to troubleshoot networks (at a minimum, to = detect packet loss and reordering) is real.=C2=A0 I would assume that every= network would need to have an ability to do so.=C2=A0 Ability to quickly t= roubleshoot and fix networks is not only =E2=80=9Cnice=E2=80=9D for the networks themselves, but it is also very beneficial to QUIC users.=

=C2=A0

Having networks wrap and unwrap packets at their bou= ndaries is a possibility, though it has real costs and downsides.=C2=A0 Fir= st, while networks could setup such wrapping for UDP port 443 traffic, what= about QUIC traffic using other ports?=C2=A0 Would networks need to wrap all UDP traffic?=C2=A0 Second, this does reduc= e MTU for end users, reducing available bandwidth.=C2=A0 Third, this would = allow networks to only answer questions like: =E2=80=9CIs my network the cu= lprit of the problem?=E2=80=9D instead of =E2=80=9CIs the problem in my network, upstream from me, or downstream from me?=E2=80=9D.

=C2=A0

Would it be considered outrageous to suggest that pa= cket number encryption be an option negotiated during connection handshake?= =C2=A0 An end user client in =E2=80=9CPrivacy-Enhanced=E2=80=9D mode would = negotiate this, while end users not particularly concerned with connection migration linkability issues would leave this off?

=C2=A0

- Igor

=C2=A0

=C2=A0

From: Roni Even (A) [mailto:roni.even@huawei.com]
Sent: Sunday, February 04, 2018 2:47 AM
To: Roberto Peon <fenix@fb.com>; Piotr Galecki <piotr_galecki@affirmednetworks.com>; Jana Iyengar <jri@google.com>; Fossati, Thomas (Nokia - GB= /Cambridge, UK) <thomas.foss= ati@nokia.com>
Cc: Gorry Fairhust <gorry= @erg.abdn.ac.uk>; Eric Rescorla <= ekr@rtfm.com>; Christian Huitema <huitema@huitema.net>; Eggert, Lars <lars@netapp.com>; Brian Trammell <ietf@trammell.ch>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.= ch>; QUIC WG <quic@ietf.org&= gt;; Martin Thomson <martin.thom= son@gmail.com>
Subject: RE: Packet number encryption

=C2=A0

Hi,

Network monitoring:

Networks may always wrap the packet(s) they have= received with whatever data they wish, and unwrap before forwarding. This = can allow any network to understand ordering,=C2=A0 loss, etc within its boundaries.

=C2=A0

RE- so you are saying that we can for example = =C2=A0leverage =C2=A0RTP and define RTP payload for QUIC that will carry QU= IC packets, we will just need to resolve the MTU size.

Roni

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon
Sent: Saturday, February 03, 2018 8:38 PM
To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambrid= ge, UK)
Cc: Gorry Fairhust; Eric Rescorla; Mirja K=C3=BChlewind; Eggert, Lar= s; Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson
Subject: Re: Packet number encryption

=C2=A0

Ossification:

In the past tcp middleboxes expected in-order, m= onotonically increasing offsets and tried to fix reordering before forwardi= ng. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp more effic= ient.

=C2=A0

=C2=A0This is the kind of non-theoretical ossifi= cation that drove the creation of QUIC in the first place.

=C2=A0

Network monitoring:

Networks may always wrap the packet(s) they have= received with whatever data they wish, and unwrap before forwarding. This = can allow any network to understand ordering,=C2=A0 loss, etc within its boundaries.

=C2=A0

Debugging:

Debugging of flows can still happen for flows th= at wish to be debugged-- the QUIC connection's key material(s) can be s= hared manually and used by the debugging tool. This is how one debugs http2, https, etc. already today.

=C2=A0

-=3DR

=C2=A0

=C2=A0

=C2=A0

-------- Original message --------

From: Piotr Galecki <piotr_galecki@affirmednetworks.com>

Date: 2/2/18 7:00 PM (GMT-08:00)

To: Jana Iyengar <jri@google.com>, "Fossati, Thomas (Nokia - GB/Cambridge,= UK)" <thomas.fossati@n= okia.com>

Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla <ekr@rtfm.com>, Christian Huitema <huitema@huitema.net>, "Eggert, Lars" <lars@netap= p.com>, Brian Trammell <ietf@= trammell.ch>, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>, QUIC WG <quic@ietf.org>, Martin Thomson= <martin.thomson@gmail.com>

Subject: RE: Packet number encryption

=C2=A0

What is the group=E2=80=99s proposal for allowing ne= twork monitoring tools to detect packet retransmission or packet reordering= ?

These metrics are pretty straightforward to measure = for TCP flows.

Tools like Wireshark can analyze packets and spot is= sues.

How can the network tools perform this kind of measu= rements for QUIC flows if PN field is encrypted?

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Friday, February 02, 2018 9:31 PM
To: Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>
Cc: Gorry Fairhust <gorry= @erg.abdn.ac.uk>; Eric Rescorla <= ekr@rtfm.com>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Christian Huitema <huitema@huite= ma.net>; Brian Trammell <ietf= @trammell.ch>; Eggert, Lars <l= ars@netapp.com>; QUIC WG <quic@i= etf.org>; Martin Thomson <martin.thom= son@gmail.com>
Subject: Re: Packet number encryption

=C2=A0

A few points as I catch up on this thread.

=C2=A0

First, I'll remind folks that QUIC is an encrypt= ed transport. I say this because the cost of this operation is trivial in t= he context of encrypting every packet. The cost is borne at the servers and= not at middleboxes, so the additional crypto cost is basically trivial.

=C2=A0

Second, this simplifies and increases robustness of = implementation. Avoiding random PN jumps, as Kazuho points out, makes speci= al-casing of code unnecessary. Special code that is exercised occasionally = is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation.

=C2=A0

Third, yes, ossification is a real concern. A simple= example: using increasing packet numbers as a signature for detecting QUIC= . Even if you argue against this example, there are innovative ways in whic= h ossification will happen. This is based on a true story:=C2=A0We had no idea h= ow GQUIC's flags field could get ossified, the value that was being use= d commonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper).

=C2=A0

There's a win here in terms of implementation co= mplexity and several implementers have said so. There's a win in terms = of ossification and our experience says so. There's a potential loss of= manageability, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet number= s.

=C2=A0

On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nok= ia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:

On 31/01/2018, 10:06,= "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on behalf of lars@netapp.com> wrote:
> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> > +1 - Simply: This *is* complicated and seems to add little.
>
> So as an implementor (chair hat off), this adds very little to the
> overall complexity of the protocol.

This doesn't sound great.=C2=A0 It's a bit like saying that adding = the Higgs
mechanism to the standard model's lagrangian doesn't make it much m= ore
complicate :-)=C2=A0 (*)

More seriously though, I'd like to point out that it is not just about<= br> implementation complexity, it's also the energy cost per packet that is=
quite crucial.=C2=A0 I haven't done the math but ISTM that bringing in<= br> another batch of non-optional crypto computation on a per packet basis
is not going to move the needle in the right direction for stacks that
run on low power (IoT).

This is not a catastrophe - we have CoAP and a (D)TLS profile - but
neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to
bridge.=C2=A0 (Sure, we have specified the behaviour of a similar box
already, but it'd be really better if the extra translation logic could=
be avoided in the first place.)

I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later=
profile QUIC for the IoT, which would be a bit unlucky.

So the question is: would it be possible to make this property a
configurable knob instead?

(*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-e= quation

=C2=A0

--94eb2c05a3ec633bed05646660c5-- From nobody Sun Feb 4 09:41:00 2018 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 6166B127369 for ; Sun, 4 Feb 2018 09:40:58 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 O1-2nMIbRIJf for ; Sun, 4 Feb 2018 09:40:56 -0800 (PST) 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 0FA5412762F for ; Sun, 4 Feb 2018 09:40:56 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eiOHd-0003iw-30 for quic@ietf.org; Sun, 04 Feb 2018 18:40:54 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eiOHX-0004ZB-Lq for quic@ietf.org; Sun, 04 Feb 2018 12:40:51 -0500 Received: (qmail 5371 invoked from network); 4 Feb 2018 17:40:45 -0000 Received: from unknown (HELO [IPv6:2607:fb90:1e1c:a493:4095:f8ed:3c34:8f58]) (Authenticated-user:_huitema@huitema.net@[172.56.44.223]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Feb 2018 17:40:44 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-C20D84AD-929F-4741-B69C-6A76C80C5490 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Sun, 4 Feb 2018 07:40:41 -1000 Cc: "Roni Even (A)" , Roberto Peon , Piotr Galecki , Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Gorry Fairhust , Eric Rescorla , "Eggert, Lars" , Brian Trammell , =?utf-8?Q?Mirja_K=C3=BChlewind?= , QUIC WG , Martin Thomson Content-Transfer-Encoding: 7bit Message-Id: <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> To: "Lubashev, Igor" Subject: Re: Packet number encryption X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.21) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ljgM0fDv5Zp2LQBW2Uj+H4Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftnrIq+0EeNob3p+6t1Lz3jB98yDTitFWvbHwz9vKZpm2Ea bzmM/1VynIZUVImbQiuZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyYW9UNFgzCqKDXesOntN1zD9IUJ5y4fZBwzmfWaECTh P89Q8W/LjlKNXhVyzk2vd23GvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATyzYT8K6rd4RA3UMT6Em/UONoJfh+XjGSeeT90H/uIHN HiwNzyXAgQj5L4vNjntJoewP9/xKfPWTTJs08V9ARWbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW/a7J4lI9dq2HBFg+iT3zKvfFcHV2tQAVqGdj/zM7G/H0fgN5y0tqqfuQuS1mj2Wr5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w 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: Sun, 04 Feb 2018 17:40:58 -0000 --Apple-Mail-C20D84AD-929F-4741-B69C-6A76C80C5490 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =20 > On Feb 4, 2018, at 7:18 AM, Lubashev, Igor wrote: > ... > =20 > Having networks wrap and unwrap packets at their boundaries is a possibili= ty, though it has real costs and downsides. First, while networks could set= up such wrapping for UDP port 443 traffic, what about QUIC traffic using oth= er ports? Would networks need to wrap all UDP traffic? Second, this does r= educe MTU for end users, reducing available bandwidth. Third, this would al= low networks to only answer questions like: =E2=80=9CIs my network the culpr= it of the problem?=E2=80=9D instead of =E2=80=9CIs the problem in my network= , upstream from me, or downstream from me?=E2=80=9D. This is exactly why I believe the proper place for things like spin bits or s= hort sequence numbers is in the IP header. That would be a really neat use o= f the IPv6 flow ID. > =20 > Would it be considered outrageous to suggest that packet number encryption= be an option negotiated during connection handshake? An end user client in= =E2=80=9CPrivacy-Enhanced=E2=80=9D mode would negotiate this, while end use= rs not particularly concerned with connection migration linkability issues w= ould leave this off? Negotiate privacy off in the name of network performance? Very slippery slop= e! For example, the connections that do require privacy would stick out. -- Christian Huitema= --Apple-Mail-C20D84AD-929F-4741-B69C-6A76C80C5490 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable  

On Feb 4, 2018, at 7:18 A= M, Lubashev, Igor <ilubashe@akamai= .com> wrote:...

 

Having networks wrap and unwrap packets at their boun= daries is a possibility, though it has real costs and downsides.  First= , while networks could setup such wrapping for UDP port 443 traffic, what ab= out QUIC traffic using other ports?  Would networks need to wrap all UDP traffic?  Second, this does reduce= MTU for end users, reducing available bandwidth.  Third, this would al= low networks to only answer questions like: =E2=80=9CIs my network the culpr= it of the problem?=E2=80=9D instead of =E2=80=9CIs the problem in my network, upstream from me, or downstream from me?=E2=80=9D.

=

This is exactly why I believe the proper pl= ace for things like spin bits or short sequence numbers is in the IP header.= That would be a really neat use of the IPv6 flow ID.

 

Would it be considered outrageous to suggest that pac= ket number encryption be an option negotiated during connection handshake?&n= bsp; An end user client in =E2=80=9CPrivacy-Enhanced=E2=80=9D mode would neg= otiate this, while end users not particularly concerned with connection migration linkability issues would leave this off?

=

Negotiate privacy off in the name of network performance? Ve= ry slippery slope! For example, the connections that do require privacy woul= d stick out.

-- Christian Huitema
= --Apple-Mail-C20D84AD-929F-4741-B69C-6A76C80C5490-- From nobody Sun Feb 4 09:49:56 2018 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 C35B9127698 for ; Sun, 4 Feb 2018 09:49:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, 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=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 lyvlKNLd4jAR for ; Sun, 4 Feb 2018 09:49:50 -0800 (PST) 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 79E721275F4 for ; Sun, 4 Feb 2018 09:49:50 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w14Hkpau029638; Sun, 4 Feb 2018 17:49:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=wYu8BvFzP9p8jsa9I2g4urYvNpa4aOz3nfS0iO1Qqco=; b=m67HYsjJZBnGaykhagUUTntTiwFILFyqucT2hjZuIt/0mDZPJ/QeIhrCLROvs0o9IzKv tKczYg17ByBJc8EBXAYATLVQk8MbMv2FvlOTVE7R8RW/PY7Q5I2QAI/uRXZXhMkv6oEG Kk+iWDrHe6Oxi7BGTVPftCmhHE68zC5zmd8xJJUPMaSvynM4qDiZQn0FqY5VdkixZBoA xHGQRPUyRy94ygiS4ymoBCyGtSThli3AxrNIs0F1fBOgtP3kktJOzJVO6rDeEmX53lgd anyRUhde6zAFy5W0LShJYPt9Zh1Mn1mVI2MWLjA/Hjv5oSj6cSu1XPRJzTCG8h5Z6Vj6 ZA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2fw5kx3uur-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Feb 2018 17:49:01 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w14Hjr1i028488; Sun, 4 Feb 2018 12:49:01 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fw9a0tmht-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 04 Feb 2018 12:49:00 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 4 Feb 2018 12:48:59 -0500 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; Sun, 4 Feb 2018 12:48:58 -0500 From: "Lubashev, Igor" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Roni Even (A)" , Jana Iyengar , Roberto Peon , Piotr Galecki , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" CC: QUIC WG , Brian Trammell , Martin Thomson , Eric Rescorla , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Christian Huitema , Gorry Fairhust , "Eggert, Lars" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31yPXsGERjf0mXrDq/23iDfaOM1RYAgABeoICAAAgVAIAAd3KAgAA8YgCAACPDAIAAAicAgAOBloCAALfcgIAACBoAgAEGFwCAANx+AIAARbYggABexQD//6xrgA== Date: Sun, 4 Feb 2018 17:48:58 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.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.43.20] Content-Type: multipart/alternative; boundary="_000_fd246634688849819fe52b87fe3b30c1usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802040238 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_03:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802040238 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, 04 Feb 2018 17:49:55 -0000 --_000_fd246634688849819fe52b87fe3b30c1usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SWYgYW4gZW5kIHVzZXIgaXMgY29tcGxhaW5pbmcgb2YgYSBwcm9ibGVtIHdhdGNoaW5nIGEgdmlk ZW8gc3RyZWFtLCBleHRyYW5lb3VzIHByb2JlIHBhY2tldHMgd291bGQgbm90IGhlbHAgdG8gaWRl bnRpZnkgd2hhdCBleGFjdGx5IGhhcHBlbmVkIHRvIHVzZXLigJlzIHBhY2tldHMuICBJbiBmYWN0 LCBqdXN0IGNhcHR1cmluZyBRVUlD4oCZcyBlbmNyeXB0ZWQgcGFja2V0cyBudW1iZXJzIG9uIHR3 byBkZXZpY2VzIHdpdGhpbiB5b3VyIG5ldHdvcmsgd291bGQgcHJvYmFibHkgYmUgZW5vdWdoIHRv IGlkZW50aWZ5IGFueSBpc3N1ZXMgYmV0d2VlbiB0aG9zZSBkZXZpY2VzLg0KDQpTbyBpdCBzaG91 bGQgYmUgcG9zc2libGUgdG8gcnVsZSBpbiBvciBydWxlIG91dCB5b3VyIG93biBuZXR3b3JrLCBi dXQgaXQgc3RpbGwgd291bGQgYmUgaW1wb3NzaWJsZSB0byBhbnN3ZXIgdGhlIHF1ZXN0aW9uOiDi gJxJZiB1c2VyIGNsYWltcyBhIHByb2JsZW0sIGFuZCBteSBuZXR3b3JrcyBzZWVtcyBvaywgaXMg dGhlIGEgcHJvYmxlbSB1cHN0cmVhbSBvciBkb3duc3RyZWFtIGZyb20gbWU/4oCdDQoNCg0KICAq ICAgSWdvcg0KDQoNCkZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtr ZWxmakBnbWFpbC5jb21dDQpTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDA0LCAyMDE4IDEyOjM2IFBN DQpUbzogUm9uaSBFdmVuIChBKSA8cm9uaS5ldmVuQGh1YXdlaS5jb20+OyBKYW5hIEl5ZW5nYXIg PGpyaUBnb29nbGUuY29tPjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+OyBMdWJhc2hldiwg SWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT47IFBpb3RyIEdhbGVja2kgPHBpb3RyX2dhbGVja2lA YWZmaXJtZWRuZXR3b3Jrcy5jb20+OyBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJp ZGdlLCBVSykgPHRob21hcy5mb3NzYXRpQG5va2lhLmNvbT4NCkNjOiBRVUlDIFdHIDxxdWljQGll dGYub3JnPjsgQnJpYW4gVHJhbW1lbGwgPGlldGZAdHJhbW1lbGwuY2g+OyBNYXJ0aW4gVGhvbXNv biA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29t PjsgTWlyamEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD47IENo cmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PjsgR29ycnkgRmFpcmh1c3QgPGdv cnJ5QGVyZy5hYmRuLmFjLnVrPjsgRWdnZXJ0LCBMYXJzIDxsYXJzQG5ldGFwcC5jb20+DQpTdWJq ZWN0OiBSRTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCklmIHlvdSBuZWVkIHRvIHRyb3Vi bGVzaG9vdCBhIG5ldHdvcmssIHdoYXQgcHJldmVudHMgeW91IGZyb20gaW5qZWN0aW5nIHByb2Jl IHBhY2tldHMgd2l0aCByYW5kb20gY29udGVudCBvbiB0aGUgc2FtZSByb3V0ZT8gVGhlIG1vcmUg b3BhcXVlIFFVSUMgaXMsIHRoZSBtb3JlIGxpa2VseSBpdCBpcyB0aGF0IHByb2JlIHBhY2tldHMg d291bGQgYmVoYXZlIHRoZSBzYW1lLg0KDQpGb3IgdGhhdCBtYXR0ZXIsIFFVSUMgY291bGQgZGVm aW5lIHN0YXRlbGVzcyBwcm9iZSBwYWNrZXRzIHRoYXQgbXVzdCByb3V0ZSB0aGUgc2FtZSBhcyBy ZWFsIGNvbm5lY3Rpb25zLg0KDQpNaWtrZWwNCg0KDQpPbiA0IEZlYnJ1YXJ5IDIwMTggYXQgMTgu MTkuMTYsIEx1YmFzaGV2LCBJZ29yIChpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNo ZUBha2FtYWkuY29tPikgd3JvdGU6DQpUaGUgbmVlZCB0byB0cm91Ymxlc2hvb3QgbmV0d29ya3Mg KGF0IGEgbWluaW11bSwgdG8gZGV0ZWN0IHBhY2tldCBsb3NzIGFuZCByZW9yZGVyaW5nKSBpcyBy ZWFsLiAgSSB3b3VsZCBhc3N1bWUgdGhhdCBldmVyeSBuZXR3b3JrIHdvdWxkIG5lZWQgdG8gaGF2 ZSBhbiBhYmlsaXR5IHRvIGRvIHNvLiAgQWJpbGl0eSB0byBxdWlja2x5IHRyb3VibGVzaG9vdCBh bmQgZml4IG5ldHdvcmtzIGlzIG5vdCBvbmx5IOKAnG5pY2XigJ0gZm9yIHRoZSBuZXR3b3JrcyB0 aGVtc2VsdmVzLCBidXQgaXQgaXMgYWxzbyB2ZXJ5IGJlbmVmaWNpYWwgdG8gUVVJQyB1c2Vycy4N Cg0KSGF2aW5nIG5ldHdvcmtzIHdyYXAgYW5kIHVud3JhcCBwYWNrZXRzIGF0IHRoZWlyIGJvdW5k YXJpZXMgaXMgYSBwb3NzaWJpbGl0eSwgdGhvdWdoIGl0IGhhcyByZWFsIGNvc3RzIGFuZCBkb3du c2lkZXMuICBGaXJzdCwgd2hpbGUgbmV0d29ya3MgY291bGQgc2V0dXAgc3VjaCB3cmFwcGluZyBm b3IgVURQIHBvcnQgNDQzIHRyYWZmaWMsIHdoYXQgYWJvdXQgUVVJQyB0cmFmZmljIHVzaW5nIG90 aGVyIHBvcnRzPyAgV291bGQgbmV0d29ya3MgbmVlZCB0byB3cmFwIGFsbCBVRFAgdHJhZmZpYz8g IFNlY29uZCwgdGhpcyBkb2VzIHJlZHVjZSBNVFUgZm9yIGVuZCB1c2VycywgcmVkdWNpbmcgYXZh aWxhYmxlIGJhbmR3aWR0aC4gIFRoaXJkLCB0aGlzIHdvdWxkIGFsbG93IG5ldHdvcmtzIHRvIG9u bHkgYW5zd2VyIHF1ZXN0aW9ucyBsaWtlOiDigJxJcyBteSBuZXR3b3JrIHRoZSBjdWxwcml0IG9m IHRoZSBwcm9ibGVtP+KAnSBpbnN0ZWFkIG9mIOKAnElzIHRoZSBwcm9ibGVtIGluIG15IG5ldHdv cmssIHVwc3RyZWFtIGZyb20gbWUsIG9yIGRvd25zdHJlYW0gZnJvbSBtZT/igJ0uDQoNCldvdWxk IGl0IGJlIGNvbnNpZGVyZWQgb3V0cmFnZW91cyB0byBzdWdnZXN0IHRoYXQgcGFja2V0IG51bWJl ciBlbmNyeXB0aW9uIGJlIGFuIG9wdGlvbiBuZWdvdGlhdGVkIGR1cmluZyBjb25uZWN0aW9uIGhh bmRzaGFrZT8gIEFuIGVuZCB1c2VyIGNsaWVudCBpbiDigJxQcml2YWN5LUVuaGFuY2Vk4oCdIG1v ZGUgd291bGQgbmVnb3RpYXRlIHRoaXMsIHdoaWxlIGVuZCB1c2VycyBub3QgcGFydGljdWxhcmx5 IGNvbmNlcm5lZCB3aXRoIGNvbm5lY3Rpb24gbWlncmF0aW9uIGxpbmthYmlsaXR5IGlzc3VlcyB3 b3VsZCBsZWF2ZSB0aGlzIG9mZj8NCg0KLSBJZ29yDQoNCg0KRnJvbTogUm9uaSBFdmVuIChBKSBb bWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tPG1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbT5d DQpTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDA0LCAyMDE4IDI6NDcgQU0NClRvOiBSb2JlcnRvIFBl b24gPGZlbml4QGZiLmNvbTxtYWlsdG86ZmVuaXhAZmIuY29tPj47IFBpb3RyIEdhbGVja2kgPHBp b3RyX2dhbGVja2lAYWZmaXJtZWRuZXR3b3Jrcy5jb208bWFpbHRvOnBpb3RyX2dhbGVja2lAYWZm aXJtZWRuZXR3b3Jrcy5jb20+PjsgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbTxtYWlsdG86 anJpQGdvb2dsZS5jb20+PjsgRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSwg VUspIDx0aG9tYXMuZm9zc2F0aUBub2tpYS5jb208bWFpbHRvOnRob21hcy5mb3NzYXRpQG5va2lh LmNvbT4+DQpDYzogR29ycnkgRmFpcmh1c3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpn b3JyeUBlcmcuYWJkbi5hYy51az4+OyBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRv OmVrckBydGZtLmNvbT4+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxt YWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+OyBFZ2dlcnQsIExhcnMgPGxhcnNAbmV0YXBwLmNv bTxtYWlsdG86bGFyc0BuZXRhcHAuY29tPj47IEJyaWFuIFRyYW1tZWxsIDxpZXRmQHRyYW1tZWxs LmNoPG1haWx0bzppZXRmQHRyYW1tZWxsLmNoPj47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1 ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0 aHouY2g+PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBN YXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20+Pg0KU3ViamVjdDogUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0K DQpIaSwNCk5ldHdvcmsgbW9uaXRvcmluZzoNCk5ldHdvcmtzIG1heSBhbHdheXMgd3JhcCB0aGUg cGFja2V0KHMpIHRoZXkgaGF2ZSByZWNlaXZlZCB3aXRoIHdoYXRldmVyIGRhdGEgdGhleSB3aXNo LCBhbmQgdW53cmFwIGJlZm9yZSBmb3J3YXJkaW5nLiBUaGlzIGNhbiBhbGxvdyBhbnkgbmV0d29y ayB0byB1bmRlcnN0YW5kIG9yZGVyaW5nLCAgbG9zcywgZXRjIHdpdGhpbiBpdHMgYm91bmRhcmll cy4NCg0KUkUtIHNvIHlvdSBhcmUgc2F5aW5nIHRoYXQgd2UgY2FuIGZvciBleGFtcGxlICBsZXZl cmFnZSAgUlRQIGFuZCBkZWZpbmUgUlRQIHBheWxvYWQgZm9yIFFVSUMgdGhhdCB3aWxsIGNhcnJ5 IFFVSUMgcGFja2V0cywgd2Ugd2lsbCBqdXN0IG5lZWQgdG8gcmVzb2x2ZSB0aGUgTVRVIHNpemUu DQpSb25pDQoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIFJvYmVydG8gUGVvbg0KU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDAzLCAyMDE4 IDg6MzggUE0NClRvOiBQaW90ciBHYWxlY2tpOyBKYW5hIEl5ZW5nYXI7IEZvc3NhdGksIFRob21h cyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKQ0KQ2M6IEdvcnJ5IEZhaXJodXN0OyBFcmljIFJl c2NvcmxhOyBNaXJqYSBLw7xobGV3aW5kOyBFZ2dlcnQsIExhcnM7IEJyaWFuIFRyYW1tZWxsOyBD aHJpc3RpYW4gSHVpdGVtYTsgUVVJQyBXRzsgTWFydGluIFRob21zb24NClN1YmplY3Q6IFJlOiBQ YWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KT3NzaWZpY2F0aW9uOg0KSW4gdGhlIHBhc3QgdGNw IG1pZGRsZWJveGVzIGV4cGVjdGVkIGluLW9yZGVyLCBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcg b2Zmc2V0cyBhbmQgdHJpZWQgdG8gZml4IHJlb3JkZXJpbmcgYmVmb3JlIGZvcndhcmRpbmcuIFRo aXMgbWlkZGxlYm94IGJlaGF2aW9yLCBwcmVkaWNhdGVkIG9uIG9ic2VydmFibGUgZmxvd3MsIHBy ZXZlbnRlZCBkZXBsb3ltZW50IG9mIHRoaW5ncyB3aGljaCB3b3VsZCBoYXZlIG1hZGUgdGNwIG1v cmUgZWZmaWNpZW50Lg0KDQogVGhpcyBpcyB0aGUga2luZCBvZiBub24tdGhlb3JldGljYWwgb3Nz aWZpY2F0aW9uIHRoYXQgZHJvdmUgdGhlIGNyZWF0aW9uIG9mIFFVSUMgaW4gdGhlIGZpcnN0IHBs YWNlLg0KDQpOZXR3b3JrIG1vbml0b3Jpbmc6DQpOZXR3b3JrcyBtYXkgYWx3YXlzIHdyYXAgdGhl IHBhY2tldChzKSB0aGV5IGhhdmUgcmVjZWl2ZWQgd2l0aCB3aGF0ZXZlciBkYXRhIHRoZXkgd2lz aCwgYW5kIHVud3JhcCBiZWZvcmUgZm9yd2FyZGluZy4gVGhpcyBjYW4gYWxsb3cgYW55IG5ldHdv cmsgdG8gdW5kZXJzdGFuZCBvcmRlcmluZywgIGxvc3MsIGV0YyB3aXRoaW4gaXRzIGJvdW5kYXJp ZXMuDQoNCkRlYnVnZ2luZzoNCkRlYnVnZ2luZyBvZiBmbG93cyBjYW4gc3RpbGwgaGFwcGVuIGZv ciBmbG93cyB0aGF0IHdpc2ggdG8gYmUgZGVidWdnZWQtLSB0aGUgUVVJQyBjb25uZWN0aW9uJ3Mg a2V5IG1hdGVyaWFsKHMpIGNhbiBiZSBzaGFyZWQgbWFudWFsbHkgYW5kIHVzZWQgYnkgdGhlIGRl YnVnZ2luZyB0b29sLiBUaGlzIGlzIGhvdyBvbmUgZGVidWdzIGh0dHAyLCBodHRwcywgZXRjLiBh bHJlYWR5IHRvZGF5Lg0KDQotPVINCg0KDQoNCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0t LS0tLS0NCkZyb206IFBpb3RyIEdhbGVja2kgPHBpb3RyX2dhbGVja2lAYWZmaXJtZWRuZXR3b3Jr cy5jb208bWFpbHRvOnBpb3RyX2dhbGVja2lAYWZmaXJtZWRuZXR3b3Jrcy5jb20+Pg0KRGF0ZTog Mi8yLzE4IDc6MDAgUE0gKEdNVC0wODowMCkNClRvOiBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUu Y29tPG1haWx0bzpqcmlAZ29vZ2xlLmNvbT4+LCAiRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtIEdC L0NhbWJyaWRnZSwgVUspIiA8dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPG1haWx0bzp0aG9tYXMu Zm9zc2F0aUBub2tpYS5jb20+Pg0KQ2M6IEdvcnJ5IEZhaXJodXN0IDxnb3JyeUBlcmcuYWJkbi5h Yy51azxtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWs+PiwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0 Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiwgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFA aHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PiwgIkVnZ2VydCwgTGFycyIg PGxhcnNAbmV0YXBwLmNvbTxtYWlsdG86bGFyc0BuZXRhcHAuY29tPj4sIEJyaWFuIFRyYW1tZWxs IDxpZXRmQHRyYW1tZWxsLmNoPG1haWx0bzppZXRmQHRyYW1tZWxsLmNoPj4sIE1pcmphIEvDvGhs ZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLmt1ZWhs ZXdpbmRAdGlrLmVlLmV0aHouY2g+PiwgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVp Y0BpZXRmLm9yZz4+LCBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1h aWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+Pg0KU3ViamVjdDogUkU6IFBhY2tldCBudW1i ZXIgZW5jcnlwdGlvbg0KDQpXaGF0IGlzIHRoZSBncm91cOKAmXMgcHJvcG9zYWwgZm9yIGFsbG93 aW5nIG5ldHdvcmsgbW9uaXRvcmluZyB0b29scyB0byBkZXRlY3QgcGFja2V0IHJldHJhbnNtaXNz aW9uIG9yIHBhY2tldCByZW9yZGVyaW5nID8NClRoZXNlIG1ldHJpY3MgYXJlIHByZXR0eSBzdHJh aWdodGZvcndhcmQgdG8gbWVhc3VyZSBmb3IgVENQIGZsb3dzLg0KVG9vbHMgbGlrZSBXaXJlc2hh cmsgY2FuIGFuYWx5emUgcGFja2V0cyBhbmQgc3BvdCBpc3N1ZXMuDQpIb3cgY2FuIHRoZSBuZXR3 b3JrIHRvb2xzIHBlcmZvcm0gdGhpcyBraW5kIG9mIG1lYXN1cmVtZW50cyBmb3IgUVVJQyBmbG93 cyBpZiBQTiBmaWVsZCBpcyBlbmNyeXB0ZWQ/DQoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbmEgSXllbmdhcg0KU2VudDogRnJpZGF5 LCBGZWJydWFyeSAwMiwgMjAxOCA5OjMxIFBNDQpUbzogRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAt IEdCL0NhbWJyaWRnZSwgVUspIDx0aG9tYXMuZm9zc2F0aUBub2tpYS5jb208bWFpbHRvOnRob21h cy5mb3NzYXRpQG5va2lhLmNvbT4+DQpDYzogR29ycnkgRmFpcmh1c3QgPGdvcnJ5QGVyZy5hYmRu LmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51az4+OyBFcmljIFJlc2NvcmxhIDxla3JA cnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+OyBNaXJqYSBLw7xobGV3aW5kIDxtaXJqYS5r dWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPG1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5l dGh6LmNoPj47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpo dWl0ZW1hQGh1aXRlbWEubmV0Pj47IEJyaWFuIFRyYW1tZWxsIDxpZXRmQHRyYW1tZWxsLmNoPG1h aWx0bzppZXRmQHRyYW1tZWxsLmNoPj47IEVnZ2VydCwgTGFycyA8bGFyc0BuZXRhcHAuY29tPG1h aWx0bzpsYXJzQG5ldGFwcC5jb20+PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVp Y0BpZXRmLm9yZz4+OyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPG1h aWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+Pg0KU3ViamVjdDogUmU6IFBhY2tldCBudW1i ZXIgZW5jcnlwdGlvbg0KDQpBIGZldyBwb2ludHMgYXMgSSBjYXRjaCB1cCBvbiB0aGlzIHRocmVh ZC4NCg0KRmlyc3QsIEknbGwgcmVtaW5kIGZvbGtzIHRoYXQgUVVJQyBpcyBhbiBlbmNyeXB0ZWQg dHJhbnNwb3J0LiBJIHNheSB0aGlzIGJlY2F1c2UgdGhlIGNvc3Qgb2YgdGhpcyBvcGVyYXRpb24g aXMgdHJpdmlhbCBpbiB0aGUgY29udGV4dCBvZiBlbmNyeXB0aW5nIGV2ZXJ5IHBhY2tldC4gVGhl IGNvc3QgaXMgYm9ybmUgYXQgdGhlIHNlcnZlcnMgYW5kIG5vdCBhdCBtaWRkbGVib3hlcywgc28g dGhlIGFkZGl0aW9uYWwgY3J5cHRvIGNvc3QgaXMgYmFzaWNhbGx5IHRyaXZpYWwuDQoNClNlY29u ZCwgdGhpcyBzaW1wbGlmaWVzIGFuZCBpbmNyZWFzZXMgcm9idXN0bmVzcyBvZiBpbXBsZW1lbnRh dGlvbi4gQXZvaWRpbmcgcmFuZG9tIFBOIGp1bXBzLCBhcyBLYXp1aG8gcG9pbnRzIG91dCwgbWFr ZXMgc3BlY2lhbC1jYXNpbmcgb2YgY29kZSB1bm5lY2Vzc2FyeS4gU3BlY2lhbCBjb2RlIHRoYXQg aXMgZXhlcmNpc2VkIG9jY2FzaW9uYWxseSBpcyBhIHN0cm9uZyBidWcgYXR0cmFjdG9yLCBhbmQg SSB3b3VsZCBzdHJvbmdseSBhcmd1ZSBmb3IgYXMgZmV3IG9mIHRob3NlIGFzIHBvc3NpYmxlIGlu IGltcGxlbWVudGF0aW9uLg0KDQpUaGlyZCwgeWVzLCBvc3NpZmljYXRpb24gaXMgYSByZWFsIGNv bmNlcm4uIEEgc2ltcGxlIGV4YW1wbGU6IHVzaW5nIGluY3JlYXNpbmcgcGFja2V0IG51bWJlcnMg YXMgYSBzaWduYXR1cmUgZm9yIGRldGVjdGluZyBRVUlDLiBFdmVuIGlmIHlvdSBhcmd1ZSBhZ2Fp bnN0IHRoaXMgZXhhbXBsZSwgdGhlcmUgYXJlIGlubm92YXRpdmUgd2F5cyBpbiB3aGljaCBvc3Np ZmljYXRpb24gd2lsbCBoYXBwZW4uIFRoaXMgaXMgYmFzZWQgb24gYSB0cnVlIHN0b3J5OiBXZSBo YWQgbm8gaWRlYSBob3cgR1FVSUMncyBmbGFncyBmaWVsZCBjb3VsZCBnZXQgb3NzaWZpZWQsIHRo ZSB2YWx1ZSB0aGF0IHdhcyBiZWluZyB1c2VkIGNvbW1vbmx5IGJlY2FtZSB1c2VkIGFzIGEgc2ln bmF0dXJlIGZvciBRVUlDIHRyYWZmaWMgKHNlZSBTZWN0aW9uIDcuNSBpbiB0aGUgU0lHQ09NTSBR VUlDIHBhcGVyPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fc3RhdGljLmdvb2dsZXVzZXJjb250ZW50LmNvbV9tZWRpYV9yZXNlYXJjaC5nb29nbGUu Y29tX2VuX3B1YnNfYXJjaGl2ZV80NjQwMy5wZGYmZD1Ed01HYVEmYz01VkQwUlR0TmxUaDN5Y2Q0 MWIzTVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZtPVNZODdJNHZfSXFUQ0dPZHMtajVOQ093 a1EwY0pjWUhHeUtkWG1NSVZuNkkmcz1VOW82ZEktZHd6S3d2WEh2dm12N1d0Vm04NHB1dnhoYVAw Y04yb2YzVnZBJmU9PikuDQoNClRoZXJlJ3MgYSB3aW4gaGVyZSBpbiB0ZXJtcyBvZiBpbXBsZW1l bnRhdGlvbiBjb21wbGV4aXR5IGFuZCBzZXZlcmFsIGltcGxlbWVudGVycyBoYXZlIHNhaWQgc28u IFRoZXJlJ3MgYSB3aW4gaW4gdGVybXMgb2Ygb3NzaWZpY2F0aW9uIGFuZCBvdXIgZXhwZXJpZW5j ZSBzYXlzIHNvLiBUaGVyZSdzIGEgcG90ZW50aWFsIGxvc3Mgb2YgbWFuYWdlYWJpbGl0eSwgaW4g YmVpbmcgYWJsZSB0byBkZXRlY3QgcmVvcmRlcmluZy4gVGhpcyBpcyB0aGUgdHJhZGUtb2ZmLCBh bmQgSSBhbSBzdGlsbCBpbiBmYXZvciBvZiBlbmNyeXB0aW5nIHBhY2tldCBudW1iZXJzLg0KDQpP biBGcmksIEZlYiAyLCAyMDE4IGF0IDc6MzIgQU0sIEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBH Qi9DYW1icmlkZ2UsIFVLKSA8dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tPG1haWx0bzp0aG9tYXMu Zm9zc2F0aUBub2tpYS5jb20+PiB3cm90ZToNCk9uIDMxLzAxLzIwMTgsIDEwOjA2LCAiUVVJQyBv biBiZWhhbGYgb2YgRWdnZXJ0LCBMYXJzIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBsYXJzQG5ldGFwcC5jb208bWFpbHRv OmxhcnNAbmV0YXBwLmNvbT4+IHdyb3RlOg0KPiBPbiAyMDE4LTEtMzEsIGF0IDEwOjUyLCBHb3Jy eSBGYWlyaHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJkbi5h Yy51az4+IHdyb3RlOg0KPiA+ICsxIC0gU2ltcGx5OiBUaGlzICppcyogY29tcGxpY2F0ZWQgYW5k IHNlZW1zIHRvIGFkZCBsaXR0bGUuDQo+DQo+IFNvIGFzIGFuIGltcGxlbWVudG9yIChjaGFpciBo YXQgb2ZmKSwgdGhpcyBhZGRzIHZlcnkgbGl0dGxlIHRvIHRoZQ0KPiBvdmVyYWxsIGNvbXBsZXhp dHkgb2YgdGhlIHByb3RvY29sLg0KDQpUaGlzIGRvZXNuJ3Qgc291bmQgZ3JlYXQuICBJdCdzIGEg Yml0IGxpa2Ugc2F5aW5nIHRoYXQgYWRkaW5nIHRoZSBIaWdncw0KbWVjaGFuaXNtIHRvIHRoZSBz dGFuZGFyZCBtb2RlbCdzIGxhZ3JhbmdpYW4gZG9lc24ndCBtYWtlIGl0IG11Y2ggbW9yZQ0KY29t cGxpY2F0ZSA6LSkgICgqKQ0KDQpNb3JlIHNlcmlvdXNseSB0aG91Z2gsIEknZCBsaWtlIHRvIHBv aW50IG91dCB0aGF0IGl0IGlzIG5vdCBqdXN0IGFib3V0DQppbXBsZW1lbnRhdGlvbiBjb21wbGV4 aXR5LCBpdCdzIGFsc28gdGhlIGVuZXJneSBjb3N0IHBlciBwYWNrZXQgdGhhdCBpcw0KcXVpdGUg Y3J1Y2lhbC4gIEkgaGF2ZW4ndCBkb25lIHRoZSBtYXRoIGJ1dCBJU1RNIHRoYXQgYnJpbmdpbmcg aW4NCmFub3RoZXIgYmF0Y2ggb2Ygbm9uLW9wdGlvbmFsIGNyeXB0byBjb21wdXRhdGlvbiBvbiBh IHBlciBwYWNrZXQgYmFzaXMNCmlzIG5vdCBnb2luZyB0byBtb3ZlIHRoZSBuZWVkbGUgaW4gdGhl IHJpZ2h0IGRpcmVjdGlvbiBmb3Igc3RhY2tzIHRoYXQNCnJ1biBvbiBsb3cgcG93ZXIgKElvVCku DQoNClRoaXMgaXMgbm90IGEgY2F0YXN0cm9waGUgLSB3ZSBoYXZlIENvQVAgYW5kIGEgKEQpVExT IHByb2ZpbGUgLSBidXQNCm5laXRoZXIgaXQncyBpZGVhbCwgc2luY2UgY3V0dGluZyBvZmYgdGhl IHNtYWxsIHRoaW5ncyBmcm9tIHRoZSB3aWRlcg0KZWNvc3lzdGVtIGNyZWF0ZXMgYW4gYXJ0aWZp Y2lhbCBnYXAgd2hpY2ggdGhlbiB3aWxsIG5lZWQgYSBtaWRkbGVib3ggdG8NCmJyaWRnZS4gIChT dXJlLCB3ZSBoYXZlIHNwZWNpZmllZCB0aGUgYmVoYXZpb3VyIG9mIGEgc2ltaWxhciBib3gNCmFs cmVhZHksIGJ1dCBpdCdkIGJlIHJlYWxseSBiZXR0ZXIgaWYgdGhlIGV4dHJhIHRyYW5zbGF0aW9u IGxvZ2ljIGNvdWxkDQpiZSBhdm9pZGVkIGluIHRoZSBmaXJzdCBwbGFjZS4pDQoNCkkgZ3Vlc3Mg d2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgUE4gZW5jcnlwdGlvbiBiZWluZyBhIGNvcmUgbWVjaGFu aXNtDQp0aGF0IGNhbid0IGJlIG5lZ290aWF0ZWQgYXQgaGFuZHNoYWtlIHRpbWUgcmVkdWNlcyBv dXIgYWJpbGl0eSB0byBsYXRlcg0KcHJvZmlsZSBRVUlDIGZvciB0aGUgSW9ULCB3aGljaCB3b3Vs ZCBiZSBhIGJpdCB1bmx1Y2t5Lg0KDQpTbyB0aGUgcXVlc3Rpb24gaXM6IHdvdWxkIGl0IGJlIHBv c3NpYmxlIHRvIG1ha2UgdGhpcyBwcm9wZXJ0eSBhDQpjb25maWd1cmFibGUga25vYiBpbnN0ZWFk Pw0KDQooKikgaHR0cHM6Ly93d3cuc3ltbWV0cnltYWdhemluZS5vcmcvYXJ0aWNsZS90aGUtZGVj b25zdHJ1Y3RlZC1zdGFuZGFyZC1tb2RlbC1lcXVhdGlvbjxodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5zeW1tZXRyeW1hZ2F6aW5lLm9yZ19h cnRpY2xlX3RoZS0yRGRlY29uc3RydWN0ZWQtMkRzdGFuZGFyZC0yRG1vZGVsLTJEZXF1YXRpb24m ZD1Ed01HYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNzZjZU QSZtPVNZODdJNHZfSXFUQ0dPZHMtajVOQ093a1EwY0pjWUhHeUtkWG1NSVZuNkkmcz1ldElPMEFV SGlKbTh6dWNzV2FUZ28tWFVMRmlzQ01vRzJpRHZ3QzY5czlRJmU9Pg0KDQo= --_000_fd246634688849819fe52b87fe3b30c1usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp bi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFy Z2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxp Lm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsN Cgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFpbG9uLCBsaS5h aXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFpbF9vbjsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY5MDkxMDg4MjsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODU1NzkzMjkyIC01ODgwNjcyIDY3Njk4 NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTY7DQoJ bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBh biBlbmQgdXNlciBpcyBjb21wbGFpbmluZyBvZiBhIHByb2JsZW0gd2F0Y2hpbmcgYSB2aWRlbyBz dHJlYW0sIGV4dHJhbmVvdXMgcHJvYmUgcGFja2V0cyB3b3VsZCBub3QgaGVscCB0byBpZGVudGlm eSB3aGF0IGV4YWN0bHkgaGFwcGVuZWQgdG8gdXNlcuKAmXMgcGFja2V0cy4mbmJzcDsgSW4gZmFj dCwganVzdCBjYXB0dXJpbmcgUVVJQ+KAmXMgZW5jcnlwdGVkIHBhY2tldHMgbnVtYmVycyBvbiB0 d28gZGV2aWNlcyB3aXRoaW4NCiB5b3VyIG5ldHdvcmsgd291bGQgcHJvYmFibHkgYmUgZW5vdWdo IHRvIGlkZW50aWZ5IGFueSBpc3N1ZXMgYmV0d2VlbiB0aG9zZSBkZXZpY2VzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5TbyBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gcnVsZSBpbiBvciBydWxl IG91dCB5b3VyIG93biBuZXR3b3JrLCBidXQgaXQgc3RpbGwgd291bGQgYmUgaW1wb3NzaWJsZSB0 byBhbnN3ZXIgdGhlIHF1ZXN0aW9uOiDigJxJZiB1c2VyIGNsYWltcyBhIHByb2JsZW0sIGFuZCBt eSBuZXR3b3JrcyBzZWVtcyBvaywgaXMgdGhlIGEgcHJvYmxlbSB1cHN0cmVhbSBvciBkb3duc3Ry ZWFtIGZyb20gbWU/4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj5JZ29yPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vu c2VuIFttYWlsdG86bWlra2VsZmpAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRh eSwgRmVicnVhcnkgMDQsIDIwMTggMTI6MzYgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvbmkgRXZlbiAo QSkgJmx0O3JvbmkuZXZlbkBodWF3ZWkuY29tJmd0OzsgSmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29v Z2xlLmNvbSZndDs7IFJvYmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29tJmd0OzsgTHViYXNoZXYs IElnb3IgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20mZ3Q7OyBQaW90ciBHYWxlY2tpICZsdDtwaW90 cl9nYWxlY2tpQGFmZmlybWVkbmV0d29ya3MuY29tJmd0OzsgRm9zc2F0aSwgVGhvbWFzIChOb2tp YSAtIEdCL0NhbWJyaWRnZSwgVUspICZsdDt0aG9tYXMuZm9zc2F0aUBub2tpYS5jb20mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgQnJpYW4gVHJhbW1l bGwgJmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRo b21zb25AZ21haWwuY29tJmd0OzsgRXJpYyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0Ozsg TWlyamEgS8O8aGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCZndDs7 IENocmlzdGlhbiBIdWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OzsgR29ycnkgRmFp cmh1c3QgJmx0O2dvcnJ5QGVyZy5hYmRuLmFjLnVrJmd0OzsNCiBFZ2dlcnQsIExhcnMgJmx0O2xh cnNAbmV0YXBwLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFBhY2tldCBudW1iZXIg ZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWYgeW91IG5lZWQgdG8g dHJvdWJsZXNob290IGEgbmV0d29yaywgd2hhdCBwcmV2ZW50cyB5b3UgZnJvbSBpbmplY3Rpbmcg cHJvYmUgcGFja2V0cyB3aXRoIHJhbmRvbSBjb250ZW50IG9uIHRoZSBzYW1lIHJvdXRlPyBUaGUg bW9yZSBvcGFxdWUgUVVJQyBpcywgdGhlIG1vcmUgbGlrZWx5IGl0IGlzDQogdGhhdCBwcm9iZSBw YWNrZXRzIHdvdWxkIGJlaGF2ZSB0aGUgc2FtZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Rm9yIHRoYXQgbWF0dGVyLCBRVUlDIGNvdWxkIGRlZmluZSBzdGF0ZWxlc3MgcHJv YmUgcGFja2V0cyB0aGF0IG11c3Qgcm91dGUgdGhlIHNhbWUgYXMgcmVhbCBjb25uZWN0aW9ucy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUxNzc2 NTU4NDE3MDQ5MDg4MCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPk1pa2tlbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9ImFpcm1haWxvbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDQgRmVi cnVhcnkgMjAxOCBhdCAxOC4xOS4xNiwgTHViYXNoZXYsIElnb3IgKDxhIGhyZWY9Im1haWx0bzpp bHViYXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPikgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgbmVlZCB0byB0cm91Ymxlc2hvb3QgbmV0d29y a3MgKGF0IGEgbWluaW11bSwgdG8gZGV0ZWN0IHBhY2tldCBsb3NzIGFuZCByZW9yZGVyaW5nKSBp cyByZWFsLiZuYnNwOyBJIHdvdWxkIGFzc3VtZQ0KIHRoYXQgZXZlcnkgbmV0d29yayB3b3VsZCBu ZWVkIHRvIGhhdmUgYW4gYWJpbGl0eSB0byBkbyBzby4mbmJzcDsgQWJpbGl0eSB0byBxdWlja2x5 IHRyb3VibGVzaG9vdCBhbmQgZml4IG5ldHdvcmtzIGlzIG5vdCBvbmx5IOKAnG5pY2XigJ0gZm9y IHRoZSBuZXR3b3JrcyB0aGVtc2VsdmVzLCBidXQgaXQgaXMgYWxzbyB2ZXJ5IGJlbmVmaWNpYWwg dG8gUVVJQyB1c2Vycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IYXZpbmcgbmV0d29ya3Mgd3Jh cCBhbmQgdW53cmFwIHBhY2tldHMgYXQgdGhlaXIgYm91bmRhcmllcyBpcyBhIHBvc3NpYmlsaXR5 LCB0aG91Z2ggaXQgaGFzIHJlYWwgY29zdHMgYW5kIGRvd25zaWRlcy4mbmJzcDsNCiBGaXJzdCwg d2hpbGUgbmV0d29ya3MgY291bGQgc2V0dXAgc3VjaCB3cmFwcGluZyBmb3IgVURQIHBvcnQgNDQz IHRyYWZmaWMsIHdoYXQgYWJvdXQgUVVJQyB0cmFmZmljIHVzaW5nIG90aGVyIHBvcnRzPyZuYnNw OyBXb3VsZCBuZXR3b3JrcyBuZWVkIHRvIHdyYXAgYWxsIFVEUCB0cmFmZmljPyZuYnNwOyBTZWNv bmQsIHRoaXMgZG9lcyByZWR1Y2UgTVRVIGZvciBlbmQgdXNlcnMsIHJlZHVjaW5nIGF2YWlsYWJs ZSBiYW5kd2lkdGguJm5ic3A7IFRoaXJkLCB0aGlzIHdvdWxkDQogYWxsb3cgbmV0d29ya3MgdG8g b25seSBhbnN3ZXIgcXVlc3Rpb25zIGxpa2U6IOKAnElzIG15IG5ldHdvcmsgdGhlIGN1bHByaXQg b2YgdGhlIHByb2JsZW0/4oCdIGluc3RlYWQgb2Yg4oCcSXMgdGhlIHByb2JsZW0gaW4gbXkgbmV0 d29yaywgdXBzdHJlYW0gZnJvbSBtZSwgb3IgZG93bnN0cmVhbSBmcm9tIG1lP+KAnS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5Xb3VsZCBpdCBiZSBjb25zaWRlcmVkIG91dHJhZ2VvdXMgdG8gc3Vn Z2VzdCB0aGF0IHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbiBiZSBhbiBvcHRpb24gbmVnb3RpYXRl ZCBkdXJpbmcgY29ubmVjdGlvbg0KIGhhbmRzaGFrZT8mbmJzcDsgQW4gZW5kIHVzZXIgY2xpZW50 IGluIOKAnFByaXZhY3ktRW5oYW5jZWTigJ0gbW9kZSB3b3VsZCBuZWdvdGlhdGUgdGhpcywgd2hp bGUgZW5kIHVzZXJzIG5vdCBwYXJ0aWN1bGFybHkgY29uY2VybmVkIHdpdGggY29ubmVjdGlvbiBt aWdyYXRpb24gbGlua2FiaWxpdHkgaXNzdWVzIHdvdWxkIGxlYXZlIHRoaXMgb2ZmPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPi0gSWdvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiBSb25pIEV2ZW4gKEEpIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv OnJvbmkuZXZlbkBodWF3ZWkuY29tIj5yb25pLmV2ZW5AaHVhd2VpLmNvbTwvYT5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gU3VuZGF5LCBGZWJydWFyeSAwNCwgMjAxOCAyOjQ3IEFNPGJyPg0KPGI+VG86 PC9iPiBSb2JlcnRvIFBlb24gJmx0OzxhIGhyZWY9Im1haWx0bzpmZW5peEBmYi5jb20iPmZlbml4 QGZiLmNvbTwvYT4mZ3Q7OyBQaW90ciBHYWxlY2tpICZsdDs8YSBocmVmPSJtYWlsdG86cGlvdHJf Z2FsZWNraUBhZmZpcm1lZG5ldHdvcmtzLmNvbSI+cGlvdHJfZ2FsZWNraUBhZmZpcm1lZG5ldHdv cmtzLmNvbTwvYT4mZ3Q7OyBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmlAZ29v Z2xlLmNvbSI+anJpQGdvb2dsZS5jb208L2E+Jmd0OzsgRm9zc2F0aSwNCiBUaG9tYXMgKE5va2lh IC0gR0IvQ2FtYnJpZGdlLCBVSykgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXMuZm9zc2F0aUBu b2tpYS5jb20iPnRob21hcy5mb3NzYXRpQG5va2lhLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBHb3JyeSBGYWlyaHVzdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVr Ij5nb3JyeUBlcmcuYWJkbi5hYy51azwvYT4mZ3Q7OyBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVm PSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0OzsgQ2hyaXN0aWFuIEh1 aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Ij5odWl0ZW1hQGh1 aXRlbWEubmV0PC9hPiZndDs7IEVnZ2VydCwgTGFycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNA bmV0YXBwLmNvbSI+bGFyc0BuZXRhcHAuY29tPC9hPiZndDs7DQogQnJpYW4gVHJhbW1lbGwgJmx0 OzxhIGhyZWY9Im1haWx0bzppZXRmQHRyYW1tZWxsLmNoIj5pZXRmQHRyYW1tZWxsLmNoPC9hPiZn dDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzptaXJqYS5rdWVobGV3aW5k QHRpay5lZS5ldGh6LmNoIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPC9hPiZndDs7 IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3Jn PC9hPiZndDs7IE1hcnRpbiBUaG9tc29uICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21z b25AZ21haWwuY29tIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSRTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5IaSw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj5OZXR3b3JrIG1vbml0b3Jpbmc6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZiI+TmV0d29ya3MgbWF5IGFsd2F5cyB3cmFwIHRoZSBwYWNrZXQocykgdGhleSBoYXZlIHJlY2Vp dmVkIHdpdGggd2hhdGV2ZXIgZGF0YSB0aGV5IHdpc2gsIGFuZCB1bndyYXAgYmVmb3JlIGZvcndh cmRpbmcuDQogVGhpcyBjYW4gYWxsb3cgYW55IG5ldHdvcmsgdG8gdW5kZXJzdGFuZCBvcmRlcmlu ZywmbmJzcDsgbG9zcywgZXRjIHdpdGhpbiBpdHMgYm91bmRhcmllcy48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj5SRS0gc28geW91IGFyZSBzYXlpbmcgdGhhdCB3ZSBjYW4gZm9yIGV4YW1wbGUgJm5ic3A7 bGV2ZXJhZ2UgJm5ic3A7UlRQIGFuZCBkZWZpbmUgUlRQIHBheWxvYWQgZm9yIFFVSUMgdGhhdCB3 aWxsIGNhcnJ5IFFVSUMNCiBwYWNrZXRzLCB3ZSB3aWxsIGp1c3QgbmVlZCB0byByZXNvbHZlIHRo ZSBNVFUgc2l6ZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Sb25pPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86 cXVpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0byBQZW9uPGJyPg0KPGI+U2VudDo8L2I+IFNhdHVy ZGF5LCBGZWJydWFyeSAwMywgMjAxOCA4OjM4IFBNPGJyPg0KPGI+VG86PC9iPiBQaW90ciBHYWxl Y2tpOyBKYW5hIEl5ZW5nYXI7IEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2Us IFVLKTxicj4NCjxiPkNjOjwvYj4gR29ycnkgRmFpcmh1c3Q7IEVyaWMgUmVzY29ybGE7IE1pcmph IEvDvGhsZXdpbmQ7IEVnZ2VydCwgTGFyczsgQnJpYW4gVHJhbW1lbGw7IENocmlzdGlhbiBIdWl0 ZW1hOyBRVUlDIFdHOyBNYXJ0aW4gVGhvbXNvbjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUGFj a2V0IG51bWJlciBlbmNyeXB0aW9uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5Pc3NpZmljYXRpb246PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+SW4gdGhlIHBhc3Qg dGNwIG1pZGRsZWJveGVzIGV4cGVjdGVkIGluLW9yZGVyLCBtb25vdG9uaWNhbGx5IGluY3JlYXNp bmcgb2Zmc2V0cyBhbmQgdHJpZWQgdG8gZml4IHJlb3JkZXJpbmcgYmVmb3JlDQogZm9yd2FyZGlu Zy4gVGhpcyBtaWRkbGVib3ggYmVoYXZpb3IsIHByZWRpY2F0ZWQgb24gb2JzZXJ2YWJsZSBmbG93 cywgcHJldmVudGVkIGRlcGxveW1lbnQgb2YgdGhpbmdzIHdoaWNoIHdvdWxkIGhhdmUgbWFkZSB0 Y3AgbW9yZSBlZmZpY2llbnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyxzZXJpZiI+Jm5ic3A7VGhpcyBpcyB0aGUga2luZCBvZiBub24tdGhlb3JldGljYWwgb3Nz aWZpY2F0aW9uIHRoYXQgZHJvdmUgdGhlIGNyZWF0aW9uIG9mIFFVSUMgaW4gdGhlIGZpcnN0IHBs YWNlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPk5l dHdvcmsgbW9uaXRvcmluZzo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj5OZXR3b3JrcyBtYXkgYWx3YXlzIHdyYXAgdGhlIHBhY2tldChzKSB0aGV5IGhh dmUgcmVjZWl2ZWQgd2l0aCB3aGF0ZXZlciBkYXRhIHRoZXkgd2lzaCwgYW5kIHVud3JhcCBiZWZv cmUgZm9yd2FyZGluZy4NCiBUaGlzIGNhbiBhbGxvdyBhbnkgbmV0d29yayB0byB1bmRlcnN0YW5k IG9yZGVyaW5nLCZuYnNwOyBsb3NzLCBldGMgd2l0aGluIGl0cyBib3VuZGFyaWVzLjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkRlYnVnZ2luZzo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5EZWJ1Z2dpbmcg b2YgZmxvd3MgY2FuIHN0aWxsIGhhcHBlbiBmb3IgZmxvd3MgdGhhdCB3aXNoIHRvIGJlIGRlYnVn Z2VkLS0gdGhlIFFVSUMgY29ubmVjdGlvbidzIGtleSBtYXRlcmlhbChzKQ0KIGNhbiBiZSBzaGFy ZWQgbWFudWFsbHkgYW5kIHVzZWQgYnkgdGhlIGRlYnVnZ2luZyB0b29sLiBUaGlzIGlzIGhvdyBv bmUgZGVidWdzIGh0dHAyLCBodHRwcywgZXRjLiBhbHJlYWR5IHRvZGF5Ljwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi09Ujwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3Nh Z2UgLS0tLS0tLS08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj5Gcm9tOiBQaW90ciBHYWxlY2tpICZsdDs8YSBocmVmPSJtYWlsdG86cGlvdHJfZ2FsZWNr aUBhZmZpcm1lZG5ldHdvcmtzLmNvbSI+cGlvdHJfZ2FsZWNraUBhZmZpcm1lZG5ldHdvcmtzLmNv bTwvYT4mZ3Q7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNl cmlmIj5EYXRlOiAyLzIvMTggNzowMCBQTSAoR01ULTA4OjAwKQ0KPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+VG86IEphbmEgSXllbmdhciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpyaUBnb29nbGUuY29tIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7LCAmcXVv dDtGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLA0KIFVLKSZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnRob21hcy5mb3NzYXRpQG5va2lhLmNvbSI+dGhvbWFzLmZvc3NhdGlA bm9raWEuY29tPC9hPiZndDsgPC9zcGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj5DYzogR29ycnkgRmFpcmh1c3QgJmx0OzxhIGhyZWY9Im1haWx0bzpnb3Jy eUBlcmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OywgRXJpYyBSZXNj b3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWtyQHJ0Zm0uY29tPC9hPiZn dDssDQogQ2hyaXN0aWFuIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRl bWEubmV0Ij5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDssICZxdW90O0VnZ2VydCwgTGFycyZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNAbmV0YXBwLmNvbSI+bGFyc0BuZXRhcHAuY29t PC9hPiZndDssIEJyaWFuIFRyYW1tZWxsICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFtbWVs bC5jaCI+aWV0ZkB0cmFtbWVsbC5jaDwvYT4mZ3Q7LCBNaXJqYSBLw7xobGV3aW5kICZsdDs8YSBo cmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCI+bWlyamEua3VlaGxl d2luZEB0aWsuZWUuZXRoei5jaDwvYT4mZ3Q7LA0KIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0 bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDssIE1hcnRpbiBUaG9tc29uICZs dDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhvbXNv bkBnbWFpbC5jb208L2E+Jmd0Ow0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+U3ViamVjdDogUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+V2hh dCBpcyB0aGUgZ3JvdXDigJlzIHByb3Bvc2FsIGZvciBhbGxvd2luZyBuZXR3b3JrIG1vbml0b3Jp bmcgdG9vbHMgdG8gZGV0ZWN0IHBhY2tldCByZXRyYW5zbWlzc2lvbiBvciBwYWNrZXQgcmVvcmRl cmluZw0KID88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5UaGVzZSBtZXRyaWNzIGFyZSBwcmV0dHkgc3RyYWlnaHRmb3J3YXJk IHRvIG1lYXN1cmUgZm9yIFRDUCBmbG93cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ub29scyBsaWtlIFdpcmVzaGFyayBj YW4gYW5hbHl6ZSBwYWNrZXRzIGFuZCBzcG90IGlzc3Vlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ib3cgY2FuIHRoZSBu ZXR3b3JrIHRvb2xzIHBlcmZvcm0gdGhpcyBraW5kIG9mIG1lYXN1cmVtZW50cyBmb3IgUVVJQyBm bG93cyBpZiBQTiBmaWVsZCBpcyBlbmNyeXB0ZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4gUVVJQyBb PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkphbmEgSXllbmdhcjxicj4NCjxi PlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDAyLCAyMDE4IDk6MzEgUE08YnI+DQo8Yj5Ubzo8 L2I+IEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRob21hcy5mb3NzYXRpQG5va2lhLmNvbSI+dGhvbWFzLmZvc3NhdGlAbm9raWEu Y29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEdvcnJ5IEZhaXJodXN0ICZsdDs8YSBocmVmPSJt YWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPiZndDs7 IEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZt LmNvbTwvYT4mZ3Q7OyBNaXJqYSBLw7xobGV3aW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWlyamEu a3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCI+bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5j aDwvYT4mZ3Q7Ow0KIENocmlzdGlhbiBIdWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVt YUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7OyBCcmlhbiBUcmFtbWVs bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlldGZAdHJhbW1lbGwuY2giPmlldGZAdHJhbW1lbGwuY2g8 L2E+Jmd0OzsgRWdnZXJ0LCBMYXJzICZsdDs8YSBocmVmPSJtYWlsdG86bGFyc0BuZXRhcHAuY29t Ij5sYXJzQG5ldGFwcC5jb208L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1 aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzsNCiBNYXJ0aW4gVGhvbXNvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+bWFydGluLnRob21zb25A Z21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tldCBudW1iZXIg ZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BIGZldyBwb2ludHMgYXMg SSBjYXRjaCB1cCBvbiB0aGlzIHRocmVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+Rmlyc3QsIEknbGwgcmVtaW5kIGZvbGtzIHRoYXQgUVVJQyBpcyBhbiBl bmNyeXB0ZWQgdHJhbnNwb3J0LiBJIHNheSB0aGlzIGJlY2F1c2UgdGhlIGNvc3Qgb2YgdGhpcyBv cGVyYXRpb24gaXMNCiB0cml2aWFsIGluIHRoZSBjb250ZXh0IG9mIGVuY3J5cHRpbmcgZXZlcnkg cGFja2V0LiBUaGUgY29zdCBpcyBib3JuZSBhdCB0aGUgc2VydmVycyBhbmQgbm90IGF0IG1pZGRs ZWJveGVzLCBzbyB0aGUgYWRkaXRpb25hbCBjcnlwdG8gY29zdCBpcyBiYXNpY2FsbHkgdHJpdmlh bC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5T ZWNvbmQsIHRoaXMgc2ltcGxpZmllcyBhbmQgaW5jcmVhc2VzIHJvYnVzdG5lc3Mgb2YgaW1wbGVt ZW50YXRpb24uIEF2b2lkaW5nIHJhbmRvbSBQTiBqdW1wcywgYXMgS2F6dWhvIHBvaW50cw0KIG91 dCwgbWFrZXMgc3BlY2lhbC1jYXNpbmcgb2YgY29kZSB1bm5lY2Vzc2FyeS4gU3BlY2lhbCBjb2Rl IHRoYXQgaXMgZXhlcmNpc2VkIG9jY2FzaW9uYWxseSBpcyBhIHN0cm9uZyBidWcgYXR0cmFjdG9y LCBhbmQgSSB3b3VsZCBzdHJvbmdseSBhcmd1ZSBmb3IgYXMgZmV3IG9mIHRob3NlIGFzIHBvc3Np YmxlIGluIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPlRoaXJkLCB5ZXMsIG9zc2lmaWNhdGlvbiBpcyBhIHJlYWwgY29u Y2Vybi4gQSBzaW1wbGUgZXhhbXBsZTogdXNpbmcgaW5jcmVhc2luZyBwYWNrZXQgbnVtYmVycyBh cyBhIHNpZ25hdHVyZSBmb3INCiBkZXRlY3RpbmcgUVVJQy4gRXZlbiBpZiB5b3UgYXJndWUgYWdh aW5zdCB0aGlzIGV4YW1wbGUsIHRoZXJlIGFyZSBpbm5vdmF0aXZlIHdheXMgaW4gd2hpY2ggb3Nz aWZpY2F0aW9uIHdpbGwgaGFwcGVuLiBUaGlzIGlzIGJhc2VkIG9uIGEgdHJ1ZSBzdG9yeTombmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPldl IGhhZCBubw0KIGlkZWEgaG93IEdRVUlDJ3MgZmxhZ3MgZmllbGQgY291bGQgZ2V0IG9zc2lmaWVk LCB0aGUgdmFsdWUgdGhhdCB3YXMgYmVpbmcgdXNlZCBjb21tb25seSBiZWNhbWUgdXNlZCBhcyBh IHNpZ25hdHVyZSBmb3IgUVVJQyB0cmFmZmljIChzZWUgU2VjdGlvbiA3LjUgaW4gdGhlDQo8YSBo cmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3N0YXRpYy5nb29nbGV1c2VyY29udGVudC5jb21fbWVkaWFfcmVzZWFyY2guZ29vZ2xlLmNvbV9l bl9wdWJzX2FyY2hpdmVfNDY0MDMucGRmJmFtcDtkPUR3TUdhUSZhbXA7Yz01VkQwUlR0TmxUaDN5 Y2Q0MWIzTVV3JmFtcDtyPUMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEEmYW1wO209U1k4N0k0dl9JcVRD R09kcy1qNU5DT3drUTBjSmNZSEd5S2RYbU1JVm42SSZhbXA7cz1VOW82ZEktZHd6S3d2WEh2dm12 N1d0Vm04NHB1dnhoYVAwY04yb2YzVnZBJmFtcDtlPSI+DQpTSUdDT01NIFFVSUMgcGFwZXI8L2E+ KS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoZXJlJ3MgYSB3aW4gaGVyZSBpbiB0ZXJtcyBvZiBp bXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5IGFuZCBzZXZlcmFsIGltcGxlbWVudGVycyBoYXZlIHNh aWQgc28uIFRoZXJlJ3MgYSB3aW4gaW4NCiB0ZXJtcyBvZiBvc3NpZmljYXRpb24gYW5kIG91ciBl eHBlcmllbmNlIHNheXMgc28uIFRoZXJlJ3MgYSBwb3RlbnRpYWwgbG9zcyBvZiBtYW5hZ2VhYmls aXR5LCBpbiBiZWluZyBhYmxlIHRvIGRldGVjdCByZW9yZGVyaW5nLiBUaGlzIGlzIHRoZSB0cmFk ZS1vZmYsIGFuZCBJIGFtIHN0aWxsIGluIGZhdm9yIG9mIGVuY3J5cHRpbmcgcGFja2V0IG51bWJl cnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ T24gRnJpLCBGZWIgMiwgMjAxOCBhdCA3OjMyIEFNLCBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0g R0IvQ2FtYnJpZGdlLCBVSykgJmx0OzxhIGhyZWY9Im1haWx0bzp0aG9tYXMuZm9zc2F0aUBub2tp YS5jb20iIHRhcmdldD0iX2JsYW5rIj50aG9tYXMuZm9zc2F0aUBub2tpYS5jb208L2E+Jmd0Ow0K IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+T24gMzEvMDEvMjAxOCwgMTA6MDYsICZxdW90O1FVSUMgb24gYmVoYWxmIG9mIEVnZ2VydCwg TGFycyZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVp Yy1ib3VuY2VzQGlldGYub3JnPC9hPg0KIG9uIGJlaGFsZiBvZiA8YSBocmVmPSJtYWlsdG86bGFy c0BuZXRhcHAuY29tIj5sYXJzQG5ldGFwcC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IE9u IDIwMTgtMS0zMSwgYXQgMTA6NTIsIEdvcnJ5IEZhaXJodXJzdCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmdvcnJ5QGVyZy5hYmRuLmFjLnVrIj5nb3JyeUBlcmcuYWJkbi5hYy51azwvYT4mZ3Q7IHdyb3Rl Ojxicj4NCiZndDsgJmd0OyAmIzQzOzEgLSBTaW1wbHk6IFRoaXMgKmlzKiBjb21wbGljYXRlZCBh bmQgc2VlbXMgdG8gYWRkIGxpdHRsZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTbyBhcyBhbiBpbXBs ZW1lbnRvciAoY2hhaXIgaGF0IG9mZiksIHRoaXMgYWRkcyB2ZXJ5IGxpdHRsZSB0byB0aGU8YnI+ DQomZ3Q7IG92ZXJhbGwgY29tcGxleGl0eSBvZiB0aGUgcHJvdG9jb2wuPGJyPg0KPGJyPg0KVGhp cyBkb2Vzbid0IHNvdW5kIGdyZWF0LiZuYnNwOyBJdCdzIGEgYml0IGxpa2Ugc2F5aW5nIHRoYXQg YWRkaW5nIHRoZSBIaWdnczxicj4NCm1lY2hhbmlzbSB0byB0aGUgc3RhbmRhcmQgbW9kZWwncyBs YWdyYW5naWFuIGRvZXNuJ3QgbWFrZSBpdCBtdWNoIG1vcmU8YnI+DQpjb21wbGljYXRlIDotKSZu YnNwOyAoKik8YnI+DQo8YnI+DQpNb3JlIHNlcmlvdXNseSB0aG91Z2gsIEknZCBsaWtlIHRvIHBv aW50IG91dCB0aGF0IGl0IGlzIG5vdCBqdXN0IGFib3V0PGJyPg0KaW1wbGVtZW50YXRpb24gY29t cGxleGl0eSwgaXQncyBhbHNvIHRoZSBlbmVyZ3kgY29zdCBwZXIgcGFja2V0IHRoYXQgaXM8YnI+ DQpxdWl0ZSBjcnVjaWFsLiZuYnNwOyBJIGhhdmVuJ3QgZG9uZSB0aGUgbWF0aCBidXQgSVNUTSB0 aGF0IGJyaW5naW5nIGluPGJyPg0KYW5vdGhlciBiYXRjaCBvZiBub24tb3B0aW9uYWwgY3J5cHRv IGNvbXB1dGF0aW9uIG9uIGEgcGVyIHBhY2tldCBiYXNpczxicj4NCmlzIG5vdCBnb2luZyB0byBt b3ZlIHRoZSBuZWVkbGUgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBmb3Igc3RhY2tzIHRoYXQ8YnI+ DQpydW4gb24gbG93IHBvd2VyIChJb1QpLjxicj4NCjxicj4NClRoaXMgaXMgbm90IGEgY2F0YXN0 cm9waGUgLSB3ZSBoYXZlIENvQVAgYW5kIGEgKEQpVExTIHByb2ZpbGUgLSBidXQ8YnI+DQpuZWl0 aGVyIGl0J3MgaWRlYWwsIHNpbmNlIGN1dHRpbmcgb2ZmIHRoZSBzbWFsbCB0aGluZ3MgZnJvbSB0 aGUgd2lkZXI8YnI+DQplY29zeXN0ZW0gY3JlYXRlcyBhbiBhcnRpZmljaWFsIGdhcCB3aGljaCB0 aGVuIHdpbGwgbmVlZCBhIG1pZGRsZWJveCB0bzxicj4NCmJyaWRnZS4mbmJzcDsgKFN1cmUsIHdl IGhhdmUgc3BlY2lmaWVkIHRoZSBiZWhhdmlvdXIgb2YgYSBzaW1pbGFyIGJveDxicj4NCmFscmVh ZHksIGJ1dCBpdCdkIGJlIHJlYWxseSBiZXR0ZXIgaWYgdGhlIGV4dHJhIHRyYW5zbGF0aW9uIGxv Z2ljIGNvdWxkPGJyPg0KYmUgYXZvaWRlZCBpbiB0aGUgZmlyc3QgcGxhY2UuKTxicj4NCjxicj4N CkkgZ3Vlc3Mgd2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgUE4gZW5jcnlwdGlvbiBiZWluZyBhIGNv cmUgbWVjaGFuaXNtPGJyPg0KdGhhdCBjYW4ndCBiZSBuZWdvdGlhdGVkIGF0IGhhbmRzaGFrZSB0 aW1lIHJlZHVjZXMgb3VyIGFiaWxpdHkgdG8gbGF0ZXI8YnI+DQpwcm9maWxlIFFVSUMgZm9yIHRo ZSBJb1QsIHdoaWNoIHdvdWxkIGJlIGEgYml0IHVubHVja3kuPGJyPg0KPGJyPg0KU28gdGhlIHF1 ZXN0aW9uIGlzOiB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBtYWtlIHRoaXMgcHJvcGVydHkgYTxi cj4NCmNvbmZpZ3VyYWJsZSBrbm9iIGluc3RlYWQ/PGJyPg0KPGJyPg0KKCopIDxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LnN5 bW1ldHJ5bWFnYXppbmUub3JnX2FydGljbGVfdGhlLTJEZGVjb25zdHJ1Y3RlZC0yRHN0YW5kYXJk LTJEbW9kZWwtMkRlcXVhdGlvbiZhbXA7ZD1Ed01HYVEmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFi M01VdyZhbXA7cj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJmFtcDttPVNZODdJNHZfSXFUQ0dPZHMt ajVOQ093a1EwY0pjWUhHeUtkWG1NSVZuNkkmYW1wO3M9ZXRJTzBBVUhpSm04enVjc1dhVGdvLVhV TEZpc0NNb0cyaUR2d0M2OXM5USZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3 LnN5bW1ldHJ5bWFnYXppbmUub3JnL2FydGljbGUvdGhlLWRlY29uc3RydWN0ZWQtc3RhbmRhcmQt bW9kZWwtZXF1YXRpb248L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_fd246634688849819fe52b87fe3b30c1usma1exdag1mb5msgcorpak_-- From nobody Sun Feb 4 10:51:40 2018 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 74B6C127978 for ; Sun, 4 Feb 2018 10:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 op6wQP4b0CzD for ; Sun, 4 Feb 2018 10:51:36 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54939127873 for ; Sun, 4 Feb 2018 10:51:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0D261BE77; Sun, 4 Feb 2018 18:51:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A33cgQNcMklh; Sun, 4 Feb 2018 18:51:30 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 90A61BE73; Sun, 4 Feb 2018 18:51:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1517770290; bh=mczpebgPhdvi0Xq1TiZciLDyl/iK6u6cUnQvsP9fFNU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BSqh6bnXzN+ysB6IXed2O8xm9H/KfJaiwTkG2rTiP0T8/BAlOdUwxsrzFpzuqC3Ue kcX1twO61ciDdSU21f5gZM3vd4azZMjeoMQxc6GHVxGR3MLTMkB6z7P+sDTUHQxllN AoE2iHWyy/S0vwDjegCxBDPnguds0+G2KbG0pcU4= Subject: Re: Packet number encryption To: "Lubashev, Igor" , "Roni Even (A)" , Roberto Peon , Piotr Galecki , Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: Gorry Fairhust , Eric Rescorla , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , "Eggert, Lars" , Brian Trammell , Christian Huitema , QUIC WG , Martin Thomson References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <91a9d1df-c3f3-127b-ba59-942c275c00e1@cs.tcd.ie> Date: Sun, 4 Feb 2018 18:51:29 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="839kDgNKePHZL6reR5Otzy29jVFBzrlYk" 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, 04 Feb 2018 18:51:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --839kDgNKePHZL6reR5Otzy29jVFBzrlYk Content-Type: multipart/mixed; boundary="bp6kr6OiAMrJX6OEXVLt0mW2XNkpKiYI1"; protected-headers="v1" From: Stephen Farrell To: "Lubashev, Igor" , "Roni Even (A)" , Roberto Peon , Piotr Galecki , Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Cc: Gorry Fairhust , Eric Rescorla , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , "Eggert, Lars" , Brian Trammell , Christian Huitema , QUIC WG , Martin Thomson Message-ID: <91a9d1df-c3f3-127b-ba59-942c275c00e1@cs.tcd.ie> Subject: Re: Packet number encryption References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> In-Reply-To: --bp6kr6OiAMrJX6OEXVLt0mW2XNkpKiYI1 Content-Type: multipart/mixed; boundary="------------CD77E3B323D85DA06D9F2B6B" Content-Language: en-GB This is a multi-part message in MIME format. --------------CD77E3B323D85DA06D9F2B6B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 04/02/18 17:18, Lubashev, Igor wrote: > Would it be considered outrageous to suggest that packet number > encryption be an option negotiated during connection handshake? An > end user client in "Privacy-Enhanced" mode would negotiate this, > while end users not particularly concerned with connection migration > linkability issues would leave this off? I agree with Christian's points. In addition, I'd like to point out a flaw in the above - the question is posed in terms of an "end user client" making decisions for "end users not particularly concerned" with a privacy enhancing feature. I don't believe that programmers can really determine such things (no matter how often someone says they "care deeply";-) so would hope the WG adopts an approach of not making such features optional for this reason, as well as for the usual "more options =3D=3D bad plan" reasons. Cheers, S. --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------CD77E3B323D85DA06D9F2B6B Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------CD77E3B323D85DA06D9F2B6B-- --bp6kr6OiAMrJX6OEXVLt0mW2XNkpKiYI1-- --839kDgNKePHZL6reR5Otzy29jVFBzrlYk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJad1YxAAoJEFqy+vF7FyvqiwIQAJhBRzkAEgq4HwOL/SWGyEl8 QdT1dmnSbYrH3AY8fNiXtgzIX/csDlwK8WQe0pqVSUi4ot8MsAwgtXpS1Txa1kZx dk9JlDZuujPowsJVb2/wVoQrbRpFTR1+U7YHz9BQZl7Lpv8QWPD5d90OGPgsEmL5 JR4p6woKgpLFH0K+bRvwXfVmFsgknzTWrs7WlNF+3QaZ6eguA4foX47dTwaI1HDj mxGttEdRV8KHii2siZMRVs5b8595wpgFGCB8Ci3kZ1z58ELzGp+4TJKNKXw84WxC KTLudCSfaBgL2VXN+JtjhmLqMzxc47xH5hZdTetAyYzBaUotCt/HXXfBGxfd/koX B0w2B5NyFhx/7KS5GbvHhjiaVC7b0ZChNrTigiImtJ8b0wLD/Cn1l00pv37mJX1h XGJ/jpnGfdOksYxW08NMC+rdJ9XVuYcpC7CrIUri+2VDeMBtXNrixdCx50yff9E0 GhCsfIt+lKPw1qLG4EmRoJ+DEq4k+q8Bm4V0CaYIswvquGsGWKNmfNBqekYNGio5 o+FI0BjyUKQkJUYsxq9d8X+I0Grm4VQ5HIzDOInrGY/gkWS/L4DFH2ETsxPMSc9l Mn29tobFjX2vpPQo8KvfMplhwnny+gd48c2QlL9orSfy2G9ODUWx1TH+BjPW94f9 o/6ILunJWZMNBQegk8jf =f8Zi -----END PGP SIGNATURE----- --839kDgNKePHZL6reR5Otzy29jVFBzrlYk-- From nobody Sun Feb 4 11:11:15 2018 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 3FE85127978 for ; Sun, 4 Feb 2018 11:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=nokia.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 2nPBRlq2lL5D for ; Sun, 4 Feb 2018 11:11:12 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10136.outbound.protection.outlook.com [40.107.1.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FBE124239 for ; Sun, 4 Feb 2018 11:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S6IQ7dXAtP2FNJ57Q3uMhMai1jayuRRZCA0f4u5kdNo=; b=lA0GeE2ggYgHLZiboxmKtWer6WanrLPy7rbLG0oimg0GPgEqYvWp2Q53yb2MFUeufXAmKExt9rOwYn1yb83FQle4eGRICoaZkLjoBeIHXIakhvT760LeB4YTaA0TQg3Bm+ijzFAP56zL5C7GzeyNpvmtmlM6HrrIi9WK7hk4CQo= Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB0537.eurprd07.prod.outlook.com (10.160.44.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Sun, 4 Feb 2018 19:11:08 +0000 Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf%13]) with mapi id 15.20.0464.015; Sun, 4 Feb 2018 19:11:07 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: Stephen Farrell , Jana Iyengar CC: Gorry Fairhust , Eric Rescorla , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Christian Huitema , Brian Trammell , "Eggert, Lars" , QUIC WG , Martin Thomson , "Fossati, Thomas (Nokia - GB/Cambridge)" Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31fyIlPY67nUiLThH52NyNBqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBlQCAALfegIAA0mqAgAAITQCAAc8TAA== Date: Sun, 4 Feb 2018 19:11:06 +0000 Message-ID: <27B28CF5-D7B5-4CAA-AD7F-BE87C0D327C1@nokia.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <6670AEA8-081F-4523-8F1C-DF5B26AF5A0F@nokia.com> <2fe4293f-1634-a27c-835b-33c8b24c23c5@cs.tcd.ie> In-Reply-To: <2fe4293f-1634-a27c-835b-33c8b24c23c5@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-originating-ip: [88.111.115.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0537; 6:HcGAUi+OJqXGQhLeN00sx5GqVZozBnkgLAxyKXc6+OxxCgwT6yMq5pKVI32Z1fyGx2+w0vajomDJHr9dG+w8xJ6GX7xBwsGJKsyCMf3CMvEwxmc7nw9O6kyRK2D3vaPAkRzgSSJwyQpLwbt6E27JWLU1VRj2BgAUwlzvrEyRly819hodGZbuJD8yFnnbHgxuz8J8SgANWnsF2mXKPoAS297GPhDBd6s9nE6XOhcPwXNrhnYKdU6GHDGns0E2BQI7Tbn/G2p32FKpuH3keuxh4ejBDhBDf1wXjepAH2VtjhKo41szNQRMJ8ennfL+XykNdIPkGohXCLCQUDBpLcK5ZAFxMuR1HXmaK66DVa30Jan3rUdrYk98vn1WV5r2aTyp; 5:4CWio4rW01i1zZ2s2kLn+N0wQ313tkGb/te/mRxVHIc+6Both6VpjR4Td+B+n+nn96COH7ZsyPFDARwFkcZ4DMugJQIbO/yoE5ZSP1U8ow99YCkIdukstBmzn326775iuAKYo7ZCrxwzHIVAEw2saGCvYsYYMMgg+IjTfOdFxPI=; 24:BynzHAYS8Yvkh4IutRrmhgTQY7HqQUBje8/2TQX+ad4u8tos8JnnnY0ByoL4q+2lkg1mVFcCcAowXK0uK1sdQyEfc7z6BhRMBkPGgNXl9xA=; 7:3yXLYg5TgCFq1s8WVd44fkb7F3wTOw7oxMmjn+Ofo4ev0Vd7S6mcNXE1REMncoxLByJ3cN4VeuvqWhJCWtmrN5tVlj1KZh+Jdy+UINnep6hqzRWBFEp57e89+BOWJ/QvQy3ZSQSwz7BTOrBnsW4QMYbngHTvwezxqcXeEZ8UXGrwf9dEgQF8kcuEhF7PGzwqel4r3iAojKKjdaQDfY4kVeFFfyHCvn/OLkCQCNJuj8KqKmq8V7B3niz6bhSSUxzG x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(346002)(396003)(366004)(376002)(189003)(199004)(4326008)(7736002)(6512007)(66066001)(26005)(316002)(305945005)(82746002)(53936002)(186003)(6116002)(6436002)(3846002)(6486002)(3280700002)(68736007)(3660700001)(6246003)(5660300001)(102836004)(93886005)(83506002)(2950100002)(6346003)(229853002)(105586002)(81156014)(7416002)(8676002)(81166006)(106356001)(97736004)(5250100002)(86362001)(59450400001)(2900100001)(76176011)(33656002)(6506007)(478600001)(2906002)(8936002)(3480700004)(83716003)(7116003)(39060400002)(99286004)(14454004)(107886003)(54906003)(110136005)(25786009)(58126008)(53546011)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0537; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 68b9aa9a-0c47-41dc-4868-08d56c030b54 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DB3PR07MB0537; x-ms-traffictypediagnostic: DB3PR07MB0537: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(11241501184)(806099)(2400082)(944501161)(93006095)(93001095)(10201501046)(3002001)(6055026)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:DB3PR07MB0537; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0537; x-forefront-prvs: 05739BA1B5 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-microsoft-antispam-message-info: PBmOTnDiJolDo8gSL1njMm33K5iyHophuDaBuOQdwCqVmOJ/juwbkf4ZKNnI+XcON4KbFe6M1d8Z345dHAHJoBNoSTeHD1FZZEkjy7QOKoMW7VbDeghgk+kwXc2JKjBW spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 68b9aa9a-0c47-41dc-4868-08d56c030b54 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2018 19:11:07.0130 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0537 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, 04 Feb 2018 19:11:14 -0000 T24gMDMvMDIvMjAxOCwgMTU6MzMsICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllPg0Kd3JvdGU6DQo+IFNvcnJ5IC0gaXNuJ3QgdGhlIGR1cmF0aW9uIGZvciB3aGlj aCB0aGUgcmFkaW8gaXMgdHVybmVkIG9uIGEgZmFyIG1vcmUNCj4gaW1wb3J0YW50IGZhY3RvciBm b3IgcG93ZXIgY29uc3VtcHRpb24gaW4gc3VjaCBjYXNlcz8NCg0KSGkgU3RlcGhlbiwgdGhhdCdz IGEgdmVyeSBnb29kIHBvaW50OyBhcHBhcmVudGx5LCBJIGNvdWxkIG5vdCBzZWUgdGhlDQp3b29k IGZvciB0aGUgdHJlZXMhDQoNCllvdSBhcmUgcmlnaHQsIHdlIGFyZSB0YWxraW5nIGFib3V0IGEg c3ltbWV0cmljIGNpcGhlciBoZXJlLCBzbyB0aGUgd29yaw0KZm9yIGV2ZW4gZG91YmxpbmcgdGhl IGFtb3VudCBvZiBDUFUgcGVyIHBhY2tldCB3aWxsIHByb2JhYmx5IGJlIGR3YXJmZWQNCmJ5IHRo ZSBlbmVyZ3kgaXQgdGFrZXMgdG8gc2VuZCB0aGUgZnJhbWUgb3V0IGluIHRoZSBhaXIgLSBhY3Rp dmF0ZSB0aGUNCnJhZGlvIHRyYW5zY2VpdmVyLCBhc3Nlc3MgdGhlIGNoYW5uZWwsIGFjdHVhbGx5 IHNlbmQgdGhlIGRhdGEsIHN3aXRjaA0KYmFjayB0byByZWNlaXZlIG1vZGUgdG8gcmVhZCB0aGUg QUNLLCBldGMuDQoNCkNoZWVycw0KDQo= From nobody Sun Feb 4 11:14:31 2018 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 6D413128D2E for ; Sun, 4 Feb 2018 11:14:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.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 oSDxpcS_E68S for ; Sun, 4 Feb 2018 11:14:28 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on072b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe1e::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C273124239 for ; Sun, 4 Feb 2018 11:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cYJ8IYUnut1QoBD/Q9yu9p19AGdMMFnsvTBnJms2sxU=; b=i6HJU2FxCfy+bf25qNdw6sOiRdVhX7jbcTTbGp/mEVC59ych1HnIFk8JhVbUIH3vwEVYIevY7KLyjXs9sh/AG2LD+CGMfvbtl2kZxTsehvqGY/nULebBFm+NhuTWstSk5Dlj0ue709uvJdh5shevsJ3PYwvb/aq+GspLiNbcCeU= Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB0537.eurprd07.prod.outlook.com (10.160.44.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Sun, 4 Feb 2018 19:14:23 +0000 Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::92d:a5e9:3083:3dbf%13]) with mapi id 15.20.0464.015; Sun, 4 Feb 2018 19:14:23 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: Stephen Farrell , "Lubashev, Igor" , "Roni Even (A)" , Roberto Peon , Piotr Galecki , "Jana Iyengar" CC: Gorry Fairhust , Eric Rescorla , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "Eggert, Lars" , Brian Trammell , Christian Huitema , QUIC WG , "Martin Thomson" , "Fossati, Thomas (Nokia - GB/Cambridge)" Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31fyIlPY67nUiLThH52NyNBqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBlQCAALfegIAACBkAgAEGGACAANx9AIAAn5KAgAAaD4CAAAZkAA== Date: Sun, 4 Feb 2018 19:14:23 +0000 Message-ID: <05116D6F-34E5-4971-A121-B80D721B9D00@nokia.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <91a9d1df-c3f3-127b-ba59-942c275c00e1@cs.tcd.ie> In-Reply-To: <91a9d1df-c3f3-127b-ba59-942c275c00e1@cs.tcd.ie> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-originating-ip: [88.111.115.17] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB0537; 7:SjBYIvECn9RKOwckhmKQZaQZg3BW/vTct8y9iluEm7wltdgBdUF48iWUCow0PCQQE770mIZgf9GUGBcUlJ4oLruXJLOjZu6P3Edm044VaVTfNWTfu5QCNPDc3zzcTrOlfI9oWQ9e8RS3c9SS+JBo+ymMHvwjAW0/+CB+mAITg5LARooHyEzCHBYph0kD703hiWGwmcAO32fD/MFjYGVbCLt7JSuG2k2EYEpZeyygQSV/EAGpt5GEMeXHQMI5AoS6 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(346002)(396003)(366004)(376002)(189003)(199004)(4326008)(7736002)(6512007)(66066001)(26005)(316002)(305945005)(82746002)(53936002)(186003)(6116002)(6436002)(3846002)(6486002)(3280700002)(68736007)(3660700001)(6246003)(5660300001)(102836004)(93886005)(83506002)(2950100002)(6346003)(229853002)(105586002)(81156014)(7416002)(8676002)(81166006)(106356001)(97736004)(5250100002)(86362001)(2900100001)(76176011)(33656002)(6506007)(478600001)(2906002)(8936002)(3480700004)(83716003)(7116003)(39060400002)(99286004)(14454004)(107886003)(54906003)(110136005)(25786009)(58126008)(53546011)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB0537; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 75707039-13c4-4fb0-6144-08d56c038018 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DB3PR07MB0537; x-ms-traffictypediagnostic: DB3PR07MB0537: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(11241501184)(806099)(2400082)(944501161)(93006095)(93001095)(10201501046)(6055026)(6041288)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DB3PR07MB0537; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB0537; x-forefront-prvs: 05739BA1B5 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-microsoft-antispam-message-info: 1+LigDj9f3Ji/jsZiQTGzSdhGoqu4c68dlb1VOSIP2kQcMD384Xz0rxwPYzkqK6BHnrIaexZH2Dl11/1U2DxjFCp2A654HysZ5kVBi7MnZSr9YHne9k0+1bK+lP0YHE+ spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <345B63A613E65C478D5BE239B2292C27@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 75707039-13c4-4fb0-6144-08d56c038018 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2018 19:14:23.1013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB0537 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, 04 Feb 2018 19:14:30 -0000 T24gMDQvMDIvMjAxOCwgMTg6NTEsICJTdGVwaGVuIEZhcnJlbGwiIDxzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllPiB3cm90ZToNCj4gSW4gYWRkaXRpb24sIEknZCBsaWtlIHRvIHBvaW50IG91dCBh IGZsYXcgaW4gdGhlIGFib3ZlIC0gdGhlIHF1ZXN0aW9uDQo+IGlzIHBvc2VkIGluIHRlcm1zIG9m IGFuICJlbmQgdXNlciBjbGllbnQiIG1ha2luZyBkZWNpc2lvbnMgZm9yICJlbmQNCj4gdXNlcnMg bm90IHBhcnRpY3VsYXJseSBjb25jZXJuZWQiIHdpdGggYSBwcml2YWN5IGVuaGFuY2luZyBmZWF0 dXJlLiBJDQo+IGRvbid0IGJlbGlldmUgdGhhdCBwcm9ncmFtbWVycyBjYW4gcmVhbGx5IGRldGVy bWluZSBzdWNoIHRoaW5ncyAobm8NCj4gbWF0dGVyIGhvdyBvZnRlbiBzb21lb25lIHNheXMgdGhl eSAiY2FyZSBkZWVwbHkiOy0pDQoNCkluIHVzZXIgYWdlbnRzIEkgZ3Vlc3MgdGhpcyB3b3VsZCBi ZSBoYW5kbGVkIGFzIGEgY29uZmlndXJhYmxlIHVzZXIncw0KcHJlZmVyZW5jZSwgbm90IGEgYXMg aGFyZC1jb2RlZCB2YWx1ZS4gIFdlIGNvdWxkIGhhdmUgaXQgTVRJIGFuZCBvbiBieQ0KZGVmYXVs dC4gIFNvZnR3YXJlIHZlbmRvcnMgd2hvIHByb2R1Y2UgdXNlciBmYWNpbmcgdGVjaG5vbG9neSBo YXZlIGENCnN0cm9uZyBpbmNlbnRpdmUgdG8gZG8gdGhpcyBraW5kIG9mIHRoaW5ncyByaWdodC4N Cg0KQ2hlZXJzIQ0KDQo= From nobody Sun Feb 4 11:23:30 2018 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 91233127698 for ; Sun, 4 Feb 2018 11:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 vAekNKK-lOTh for ; Sun, 4 Feb 2018 11:23:27 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FDDE124239 for ; Sun, 4 Feb 2018 11:23:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9A47ABE77; Sun, 4 Feb 2018 19:23:23 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8Uvmbvn6Q_E; Sun, 4 Feb 2018 19:23:22 +0000 (GMT) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0A772BE73; Sun, 4 Feb 2018 19:23:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1517772202; bh=Q2y+5b4XrIS/dqzyrSoSk2Ot+6gqgMBxOIxj4ncVBBc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HrwGr2b/YSfjH3eTV/7i6Tfuf/wtHGzrhyygK2iOotTzhxXEe0VJRsU43ocuf3gsS P7i5ylXKaQyl80oDE2pOpQZuQBIb3WWPEQV9hmxxNoMXYGRYdylGgxH/XrsCg+j5dk AdCXiz4RYnCv80GXvJPtbhKAV5SKl9JXbpqEz56k= Subject: Re: Packet number encryption To: "Fossati, Thomas (Nokia - GB/Cambridge)" , "Lubashev, Igor" , "Roni Even (A)" , Roberto Peon , Piotr Galecki , Jana Iyengar Cc: Gorry Fairhust , Eric Rescorla , Christian Huitema , "Eggert, Lars" , Brian Trammell , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , QUIC WG , Martin Thomson References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <91a9d1df-c3f3-127b-ba59-942c275c00e1@cs.tcd.ie> <05116D6F-34E5-4971-A121-B80D721B9D00@nokia.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: Date: Sun, 4 Feb 2018 19:23:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <05116D6F-34E5-4971-A121-B80D721B9D00@nokia.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7zos43X3SCmpTCIPnm7REDHCOummWMz32" 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, 04 Feb 2018 19:23:29 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7zos43X3SCmpTCIPnm7REDHCOummWMz32 Content-Type: multipart/mixed; boundary="uvU4DeVsHUSqDCHUPxoXHQNjtGA0v7i04"; protected-headers="v1" From: Stephen Farrell To: "Fossati, Thomas (Nokia - GB/Cambridge)" , "Lubashev, Igor" , "Roni Even (A)" , Roberto Peon , Piotr Galecki , Jana Iyengar Cc: Gorry Fairhust , Eric Rescorla , Christian Huitema , "Eggert, Lars" , Brian Trammell , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , QUIC WG , Martin Thomson Message-ID: Subject: Re: Packet number encryption References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <91a9d1df-c3f3-127b-ba59-942c275c00e1@cs.tcd.ie> <05116D6F-34E5-4971-A121-B80D721B9D00@nokia.com> In-Reply-To: <05116D6F-34E5-4971-A121-B80D721B9D00@nokia.com> --uvU4DeVsHUSqDCHUPxoXHQNjtGA0v7i04 Content-Type: multipart/mixed; boundary="------------980D07180CE86B58B8070EE8" Content-Language: en-GB This is a multi-part message in MIME format. --------------980D07180CE86B58B8070EE8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 04/02/18 19:14, Fossati, Thomas (Nokia - GB/Cambridge) wrote: > On 04/02/2018, 18:51, "Stephen Farrell" > wrote: >> In addition, I'd like to point out a flaw in the above - the >> question is posed in terms of an "end user client" making decisions >> for "end users not particularly concerned" with a privacy enhancing >> feature. I don't believe that programmers can really determine such >> things (no matter how often someone says they "care deeply";-) >=20 > In user agents I guess this would be handled as a configurable > user's preference, not a as hard-coded value. We could have it MTI > and on by default. Software vendors who produce user facing > technology have a strong incentive to do this kind of things right. Hmm, it's a bit of an aside, and likely not decidable, but I'm not sure you're right that implementers (whether vendors or open-source implementers or whatever) are always driven by end-user's concerns. And in this case, I'm not sure that an application-by-application approach even works - even if N-1 of the N applications I use do a great job wrt linkability, when the N-th application is careless I can lose all benefits. (And yes, combinations of TCP and DHCP can result in the same bad outcome, but that's not a reason to do less well than we can IMO.) So I still hope the WG study the trade-offs and make doing the best we can for privacy the only option. S. >=20 > Cheers! >=20 --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------980D07180CE86B58B8070EE8 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------980D07180CE86B58B8070EE8-- --uvU4DeVsHUSqDCHUPxoXHQNjtGA0v7i04-- --7zos43X3SCmpTCIPnm7REDHCOummWMz32 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJad12pAAoJEFqy+vF7FyvqvbwQAMQULYaZAwUecU3uml2nfkRC GE283ZkEZfrkKi+3SVWutf9PdTQN0NurUYeTNS0UZJ+OKPrRi6tWIESqI3+efpmd LRe1jPgZG5W+AKaB16mP7hX/T1f0XMx4Cb/AG5MJZ/tTuacIYXUm17wGIT5TK0um Bd77hbkm6o+81ucT/jMW2/etJqpEpW5jSmABQtGj4J+IujUtcDCUe0T0H353NWBM WomrXBfPRzp+ACsDdiWa1GeXwEt6SbNbRbkdVK5vhE1B5N/Bqgej1kukVqOF9D4k /7Emhp9v/SZ4OZfBsZQFg0d0zhGkNZoKR9oo0+EPsZGDCp+N/FV1J/9mWlc2/ZXd bVxt7BVocdcSA2NNIswXXxNK0Co3XRG0oUOQSlm9JUomYi7qyLYG/0GkQuN/dzTG 57VFUz+fo72LuGFFvWypnP7LrdoGnjsULq2zrBsNmP/6dpCL5Dh/sj/5sF4sKvr1 RyO542Asvbqmk/PSluk2Hr+fjWYrIy9oWRMiqO/loVf1Up+9ee0/3JMFKBGxZCPT uOvukDQS/3AzpZtIohjKrC+1LnW6Q1mdPjtae+G7l24oASZNhT3fVr2koNMpZHnY XMPxJ91uYnUh+ckM1xNFeCFW9o9flQTUKFfhQBz9jyIkxvRwA2YuwmInT/z0ybs8 vGwIKzfVfush8HubFyus =Zo2Q -----END PGP SIGNATURE----- --7zos43X3SCmpTCIPnm7REDHCOummWMz32-- From nobody Sun Feb 4 11:26:21 2018 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 0F024127698 for ; Sun, 4 Feb 2018 11:26:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 I2x7C5u2Xc52 for ; Sun, 4 Feb 2018 11:26:18 -0800 (PST) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id A7558124239 for ; Sun, 4 Feb 2018 11:26:17 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id w14IPoHP015744; Sun, 4 Feb 2018 19:25:50 +0100 Date: Sun, 4 Feb 2018 19:25:50 +0100 From: Willy Tarreau To: Christian Huitema Cc: "Lubashev, Igor" , Gorry Fairhust , Eric Rescorla , QUIC WG , Roberto Peon , Mirja =?iso-8859-1?Q?K=FChlewind?= , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , "Roni Even (A)" , "Eggert, Lars" , Jana Iyengar , Piotr Galecki , Brian Trammell , Martin Thomson Subject: Re: Packet number encryption Message-ID: <20180204182550.GA19526@1wt.eu> Reply-To: quic@ietf.org References: <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> User-Agent: Mutt/1.4.2.3i 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, 04 Feb 2018 19:26:20 -0000 On Sun, Feb 04, 2018 at 07:40:41AM -1000, Christian Huitema wrote: > Negotiate privacy off in the name of network performance? Very slippery > slope! For example, the connections that do require privacy would stick out. Well, I personally have stopped fighting on this subject. I've long been bored by the obsession of this so-called "privacy" which justifies any possible protocol degradation and loss of efficiency to hide I-don't- know-what, even sometimes destroying basic security at the same time. Today, people who want to hide their activities use VPNs. Those of us having had to help diagnose network issues on IPSEC connections know that you can't debug anything and that the only fix is to try to randomly replace elements and settings on the path, and to ultimately get rid of this protocol in favor of other solutions with less moving parts. Yes I too am a bit worried about what QUIC will become. The lack of observability may even result in the impossibility at all to build a working firewall to protect the users. Thus instead of nasty people just counting packets on the wire, they'll have an open path to remotely install malware into their victim's devices without any possibility for them to be protected, leaking all their data and history even more easily than today. The Internet infrastructure is robust and fragile at the same time, it's robust against attacks and hardware failures, but it's fragile in front of design mistakes, especially if they're deployed on each and every browser and/or web server. I think it's important to take care of it and to ensure it always remains possible to heal it and to enhance it. I'd rather see some choices offered to the end user in fact. Just like right now some decide to use a VPN, some may decide to enable some super-privacy features that possibly make their connections a bit less reliable, less performant, and prevent them from using an efficient firewall, but it will be their choice at least. And it would allow us to go even further in the privacy domain, possibly contemplating options making it even harder to fix protocol issues but protect users better (eg: the spin bit was a tradeoff to satisfy everyone, with an opt-in solution it's not even needed anymore). Having a bit indicate if the sequence number is encrypted or not could be enough : - the sender decides to use clear sequence numbers and clears the bit - the sender decides to use encrypted sequence numbers and sets the bit. - the receiver knows how to decode the sequence number based on this bit. - a middle box could not achieve anything by clearing this bit since it would mean that the resulting values would appear as almost random and would not be usable by the other end. Just my two cents, Willy From nobody Sun Feb 4 11:31:22 2018 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 91978127978 for ; Sun, 4 Feb 2018 11:31:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_H2=-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 ZvtEQRUPVqiH for ; Sun, 4 Feb 2018 11:31:17 -0800 (PST) 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 8CF49124239 for ; Sun, 4 Feb 2018 11:31:17 -0800 (PST) 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=CgbDBOt5Ab6FhSRrYUGRrrD09Tjj9p+N9pHPjozBNZY=; b=XZmNc0LmEz2TW5F7+9Q9XA6F5lL5bA57n5k2j9YIyhLv9goU82cXwWeoqICJUi+CeIyiKWhj5DOiEuYwROJYWPxJpckHgC5nXZwuBDEy273Xbm05JsG0rg8tWYJ4TYpD93MwrtD87htV+9TUTF1EtLA1NMuXzBuHW3zwFIkFk1U= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0821.namprd21.prod.outlook.com (10.173.192.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Sun, 4 Feb 2018 19:31:14 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Sun, 4 Feb 2018 19:31:14 +0000 From: Praveen Balasubramanian To: "quic@ietf.org" , huitema CC: Gorry Fairhust , Eric Rescorla , Brian Trammell , "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , "Roni Even (A)" , =?iso-8859-1?Q?Mirja_K=FChlewind?= , Jana Iyengar , "Eggert, Lars" , Martin Thomson , Piotr Galecki Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAAGR4CAAAydAIAAEZUg Date: Sun, 4 Feb 2018 19:31:14 +0000 Message-ID: References: <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> <20180204182550.GA19526@1wt.eu> In-Reply-To: <20180204182550.GA19526@1wt.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0821; 7:enW3XkOxC9cFcVRTZMJAg8SKaWTKU+w1i9G8gTqrMl2nEfOe8q2SACzRKJ00lmhXKjrWIAWd/3Wxiawf7jeAQNNtRpk2uFhjeTUMqZE2KOSmmNr6CojEDKxNh2dF64PQH77kD+drLVrcKIi2prCRq0MP9d8fP6Vi+4O2byD9nVqp8mnTHRPyYmCfaNQCqPPqCI6m8YejIzMkHVyBM1IEDuFEIWhSFbt+riaiW2sf4zg+mMo7Zf5X3zgz2wsWBTNY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 09a80f6d-d08e-450c-d844-08d56c05dac4 x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0821; x-ms-traffictypediagnostic: CY4PR21MB0821: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(131327999870524)(50582790962513)(82608151540597)(85827821059158)(788757137089)(67672495146484)(211936372134217)(153496737603132)(130329453890623); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3002001)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0821; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0821; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(39380400002)(346002)(366004)(13464003)(199004)(189003)(43544003)(33656002)(5660300001)(110136005)(2900100001)(4326008)(8936002)(2950100002)(3660700001)(9686003)(8676002)(77096007)(3280700002)(55016002)(22452003)(229853002)(7116003)(54906003)(53936002)(68736007)(8990500004)(81166006)(6436002)(81156014)(10290500003)(6506007)(25786009)(14454004)(106356001)(53546011)(93886005)(6116002)(305945005)(105586002)(478600001)(186003)(59450400001)(7736002)(2501003)(6246003)(86362001)(102836004)(6346003)(99286004)(39060400002)(86612001)(7416002)(7696005)(2906002)(8656006)(97736004)(316002)(76176011)(3480700004)(10090500001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0821; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: iawWtgtayhyfSvLg0aaUfANTvXGPf8BdU1tyGwkwwLVYl7T+SOtynxbyEBO2GdlEGEKa7HlOYfaQgd8HsAEHoA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 09a80f6d-d08e-450c-d844-08d56c05dac4 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2018 19:31:14.2682 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0821 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, 04 Feb 2018 19:31:20 -0000 >From the charter "This work will ensure that QUIC has 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)." Is the discussion mainly focused on connection migration which is not prese= nt in TCP? There seem to be bigger privacy problems due to DNS and TLS SNI = extension so in real deployments will packet number encryption add value ot= her than preventing ossification?=20 Is a cryptographically secure random initial packet number and random (forw= ard) jumps in packet number not good enough to prevent ossification? The mi= ssing packet number range due to the forward jump could be communicated in = the encrypted payload so the receiver knows they are not missing. Thanks -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Willy Tarreau Sent: Sunday, February 4, 2018 10:26 AM To: huitema Cc: Gorry Fairhust ; Eric Rescorla ; Br= ian Trammell ; Lubashev, Igor ; Robe= rto Peon ; Fossati, Thomas (Nokia - GB/Cambridge, UK) ; Roni Even (A) ; Mirja K=FChlewin= d ; Jana Iyengar ; Eggert,= Lars ; QUIC WG ; Martin Thomson ; Piotr Galecki Subject: Re: Packet number encryption On Sun, Feb 04, 2018 at 07:40:41AM -1000, Christian Huitema wrote: > Negotiate privacy off in the name of network performance? Very=20 > slippery slope! For example, the connections that do require privacy woul= d stick out. Well, I personally have stopped fighting on this subject. I've long been bo= red by the obsession of this so-called "privacy" which justifies any possib= le protocol degradation and loss of efficiency to hide I-don't- know-what, = even sometimes destroying basic security at the same time. Today, people who want to hide their activities use VPNs. Those of us havin= g had to help diagnose network issues on IPSEC connections know that you ca= n't debug anything and that the only fix is to try to randomly replace elem= ents and settings on the path, and to ultimately get rid of this protocol i= n favor of other solutions with less moving parts. Yes I too am a bit worried about what QUIC will become. The lack of observa= bility may even result in the impossibility at all to build a working firew= all to protect the users. Thus instead of nasty people just counting packet= s on the wire, they'll have an open path to remotely install malware into t= heir victim's devices without any possibility for them to be protected, lea= king all their data and history even more easily than today. The Internet infrastructure is robust and fragile at the same time, it's ro= bust against attacks and hardware failures, but it's fragile in front of de= sign mistakes, especially if they're deployed on each and every browser and= /or web server. I think it's important to take care of it and to ensure it = always remains possible to heal it and to enhance it. I'd rather see some choices offered to the end user in fact. Just like righ= t now some decide to use a VPN, some may decide to enable some super-privac= y features that possibly make their connections a bit less reliable, less p= erformant, and prevent them from using an efficient firewall, but it will b= e their choice at least. And it would allow us to go even further in the pr= ivacy domain, possibly contemplating options making it even harder to fix p= rotocol issues but protect users better (eg: the spin bit was a tradeoff to= satisfy everyone, with an opt-in solution it's not even needed anymore). Having a bit indicate if the sequence number is encrypted or not could be e= nough : - the sender decides to use clear sequence numbers and clears the bit - the sender decides to use encrypted sequence numbers and sets the bit. - the receiver knows how to decode the sequence number based on this bit. - a middle box could not achieve anything by clearing this bit since it would mean that the resulting values would appear as almost random and would not be usable by the other end. Just my two cents, Willy From nobody Sun Feb 4 11:46:30 2018 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 5868E12895E for ; Sun, 4 Feb 2018 11:46:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrpEnV-dOQxN for ; Sun, 4 Feb 2018 11:46:27 -0800 (PST) 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 B4C18127978 for ; Sun, 4 Feb 2018 11:46:27 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eiQF2-0005w9-3V for quic@ietf.org; Sun, 04 Feb 2018 20:46:26 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eiQEz-0007d8-4n for quic@ietf.org; Sun, 04 Feb 2018 14:46:17 -0500 Received: (qmail 1274 invoked from network); 4 Feb 2018 19:46:15 -0000 Received: from unknown (HELO [IPv6:2607:fb90:1e1c:a493:4095:f8ed:3c34:8f58]) (Authenticated-user:_huitema@huitema.net@[172.56.44.223]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 4 Feb 2018 19:46:15 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Sun, 4 Feb 2018 09:46:11 -1000 Cc: "quic@ietf.org" , Gorry Fairhust , Eric Rescorla , Brian Trammell , "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , "Roni Even (A)" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Jana Iyengar , "Eggert, Lars" , Martin Thomson , Piotr Galecki Content-Transfer-Encoding: quoted-printable Message-Id: <938555E5-F328-41B0-B61F-09FC02B84397@huitema.net> References: <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> <20180204182550.GA19526@1wt.eu> To: Praveen Balasubramanian Subject: Re: Packet number encryption X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.05) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5mNVKY8RVRWzdUz06lJW/7QXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsYUQAiAD1c2mPEZa/GoTCdB98yDTitFWvbHwz9vKZpm2P2 solWnqGzrvNy3o/+ni2Z3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIem31qZa26bve9pH GOCoYNRWjP649SQzhF817kql58kAx71HfxpF/K3Kf4qEIfLm3dpo8E55I3oL4X/9gaBZfvr6VL1B tSX2x7FdoqxZLLNInsq4c1pop2DuIERl592w1UzGVaY28QIxbnHhmVmUg//xFvReUB/vUq9cRUSN fRacYvJxnE2uvPYPCbpmnXes/ii2IAbWxB6xZ+NuqELn3pmRVYKU9W9tbmVXJBqdHHDm4W04ooUi IegHnDOOrq+/aMk+XoreKQ2SPH1UIIzo7c2Lo88PO9PV9fVr22BI3nCPpPSOw1Oa46WrvaYUnHi6 A+PB6cF1lL6NodQA4oU8YMAHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGF9WeUv8bG3IRc0OWQaVR4wMibYT4C2qF2lnc18bVJn659 Mgto46IUCo1JaMLHjNggBsAfMfldyTxNYtoc/RtvQjwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTzuz8IlAYdoAk3a9gKlm9yFjI1dRH6f16eQCtvwPkeoyEru6dIZF5omGgRJsyaJIil1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L 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: Sun, 04 Feb 2018 19:46:29 -0000 > On Feb 4, 2018, at 9:31 AM, Praveen Balasubramanian w= rote: >=20 > =46rom the charter "This work will ensure that QUIC has security and priva= cy properties that are at least as good as a stack composed of TLS 1.3 usin= g TCP (or MPTCP when using multipath)." >=20 > Is the discussion mainly focused on connection migration which is not pres= ent in TCP? There seem to be bigger privacy problems due to DNS and TLS SNI e= xtension so in real deployments will packet number encryption add value othe= r than preventing ossification?=20 Yes, we need to fix the SNI issue. Clear text ALPN too. But should not preve= nt us from fixing everything else. >=20 > Is a cryptographically secure random initial packet number and random (for= ward) jumps in packet number not good enough to prevent ossification? The mi= ssing packet number range due to the forward jump could be communicated in t= he encrypted payload so the receiver knows they are not missing. >=20 No, random jumps are not enough. It turns out that during migration packets a= re often sent simultaneously on both paths. The pattern of increases and hol= es is enough to correlate the two paths. In practice there are two possible designs: packet number encryption as curr= ently documented; or, independent sequence number space and encryption conte= xt for each path. Both work. The one we have is significantly easier to impl= ement. The other exposes the sequence number, which may ease network monitor= ing but also could drive ossification. Now is a good time to have this discussion. -- Christian Huitema=20= From nobody Sun Feb 4 11:55:57 2018 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 E6D8B129C59 for ; Sun, 4 Feb 2018 11:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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 vrQ_OpHqr4n2 for ; Sun, 4 Feb 2018 11:55:55 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0107.outbound.protection.outlook.com [104.47.40.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80CE129C51 for ; Sun, 4 Feb 2018 11:55:54 -0800 (PST) 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=R7Cp8lAZU/emGWL0N9u/k8A918+n/ZQUWF4mEuEHVDc=; b=fH9gDTsYOa3n82YEgWsOBiuG8kM8EZIUqMY6NohrPQTwHj7YIG5Dq+CsNsUnXvbh4XS982cASGuXqy7vLtyn8qc/GygOtUN0lmox2pxfrz6ZVT2d/KP/Iy7aA9eiQIh+qRMRyqp3Sn2tDFxjBgXFs1+pwo+W82BKK20oUanA7ks= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0821.namprd21.prod.outlook.com (10.173.192.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Sun, 4 Feb 2018 19:55:52 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Sun, 4 Feb 2018 19:55:52 +0000 From: Praveen Balasubramanian To: huitema CC: "quic@ietf.org" , Gorry Fairhust , Eric Rescorla , Brian Trammell , "Lubashev, Igor" , Roberto Peon , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , "Roni Even (A)" , =?iso-8859-1?Q?Mirja_K=FChlewind?= , Jana Iyengar , "Eggert, Lars" , Martin Thomson , Piotr Galecki Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAAGR4CAAAydAIAAEZUggAAE3oCAAABVoA== Date: Sun, 4 Feb 2018 19:55:52 +0000 Message-ID: References: <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> <20180204182550.GA19526@1wt.eu> <938555E5-F328-41B0-B61F-09FC02B84397@huitema.net> In-Reply-To: <938555E5-F328-41B0-B61F-09FC02B84397@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0821; 7:zxxUFRQLeB1lnfl+Qwfb2ZHyzuYAygMYDhxnATg/SyYFQrhqHQDu/WtFMC3rNab2fGckKqGam3WAc9X9d/tSVvgTTFIXLjzUVc6CotVVKsrFcOaRTcQhCVblXuI6vINI8a5TzbdK9BYChFU7Ab+TAfwHrs4N15xYQBVmtXt3PH/sxndWyhQ+nw1AR308jQdf54piKe/Gl5OqnX55I51aBypV22UGVjc8sRTC3TpjPHsqHGviay8WNgDjdWi1ZVLk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: af4b4228-cc10-42a8-f055-08d56c094bf8 x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0821; x-ms-traffictypediagnostic: CY4PR21MB0821: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(72170088055959)(89211679590171)(192374486261705)(50582790962513)(82608151540597)(85827821059158)(67672495146484)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3002001)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0821; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0821; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39380400002)(376002)(39860400002)(396003)(13464003)(189003)(199004)(186003)(59450400001)(105586002)(478600001)(7736002)(86362001)(6246003)(53546011)(93886005)(6116002)(305945005)(316002)(76176011)(97736004)(8656006)(10090500001)(74316002)(3480700004)(99286004)(6346003)(102836004)(39060400002)(7696005)(2906002)(86612001)(7416002)(2950100002)(8936002)(6916009)(9686003)(3660700001)(8676002)(33656002)(5660300001)(2900100001)(4326008)(77096007)(81156014)(6436002)(81166006)(14454004)(106356001)(25786009)(6506007)(10290500003)(3280700002)(55016002)(22452003)(229853002)(8990500004)(68736007)(53936002)(7116003)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0821; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: jiEOOi7amHxvJDEgq6+lxpLtMh8lo1GhlOSR86Utk03YxLIJ2GERzaXCvfipy0NmVti8M8z1kDsgGxAtXihPZg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: af4b4228-cc10-42a8-f055-08d56c094bf8 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2018 19:55:52.6663 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0821 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, 04 Feb 2018 19:55:57 -0000 Ok this answers my question that this is targeted at the migration scenario= .=20 If jumps are random and cryptographically seeded I don't understand why the= re would be a pattern. We already use this type of mechanism for TCP ISN an= d IP header Identification fields. The adversary could also use the side ch= annel timing attack of just observing the sending and receiving application= rate for correlation between the two paths (after factoring in the RTT).=20 If independent sequence space (with randomization) can work just as well I'= d rather pick that over encryption for efficiency reasons. It should solve = ossification but I am not a privacy expert. -----Original Message----- From: Christian Huitema [mailto:huitema@huitema.net]=20 Sent: Sunday, February 4, 2018 11:46 AM To: Praveen Balasubramanian Cc: quic@ietf.org; Gorry Fairhust ; Eric Rescorla ; Brian Trammell ; Lubashev, Igor ; Roberto Peon ; Fossati, Thomas (Nokia - GB/Cambrid= ge, UK) ; Roni Even (A) ; M= irja K=FChlewind ; Jana Iyengar ; Eggert, Lars ; Martin Thomson ; Piotr Galecki Subject: Re: Packet number encryption > On Feb 4, 2018, at 9:31 AM, Praveen Balasubramanian = wrote: >=20 > From the charter "This work will ensure that QUIC has security and privac= y properties that are at least as good as a stack composed of TLS 1.3 usin= g TCP (or MPTCP when using multipath)." >=20 > Is the discussion mainly focused on connection migration which is not pre= sent in TCP? There seem to be bigger privacy problems due to DNS and TLS SN= I extension so in real deployments will packet number encryption add value = other than preventing ossification?=20 Yes, we need to fix the SNI issue. Clear text ALPN too. But should not prev= ent us from fixing everything else. >=20 > Is a cryptographically secure random initial packet number and random (fo= rward) jumps in packet number not good enough to prevent ossification? The = missing packet number range due to the forward jump could be communicated i= n the encrypted payload so the receiver knows they are not missing. >=20 No, random jumps are not enough. It turns out that during migration packets= are often sent simultaneously on both paths. The pattern of increases and = holes is enough to correlate the two paths. In practice there are two possible designs: packet number encryption as cur= rently documented; or, independent sequence number space and encryption con= text for each path. Both work. The one we have is significantly easier to i= mplement. The other exposes the sequence number, which may ease network mon= itoring but also could drive ossification. Now is a good time to have this discussion. -- Christian Huitema=20 From nobody Sun Feb 4 12:32:01 2018 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 89C5212711E for ; Sun, 4 Feb 2018 12:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 X8XU5WgLXPQ8 for ; Sun, 4 Feb 2018 12:31:57 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 2C88E124239 for ; Sun, 4 Feb 2018 12:31:57 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id p139so14385268itb.1 for ; Sun, 04 Feb 2018 12:31:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=O+4Jbmq9klIaI3aLTrqeDjbLVQV3aZvM+pcM7HWWIQ4=; b=ikuD3aK7l0/x4diPvBmNzxMk9wTsAAsYCFbPu+GgKkLNnPz0MkXZ54FuBE/JfcAPVx IVwzQ6K6zy9L5+RI1uILDbLn/kLKu1fQYUQLr39vBAvC5NsvfSLBV10m2TUary1F/fJb 4hSQ5ez1wzNsWPJz20zN8Uys54uVkom5H70rGt02IcdNDhG5XBXATmOsxqhS+46FLBNk //VgaooO84/1ABtIkPpcdM/cADiJwUcaANuJ/XCb4X4D3v1XHXH8UwDXfl/Y4Ghcqx2U 3qLmwCy4OCcELj403JhcoqQU9FTZbOGYL0iQcXqLXsA3VTzuMzxF7+cUeAaet+JeXenr OpSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=O+4Jbmq9klIaI3aLTrqeDjbLVQV3aZvM+pcM7HWWIQ4=; b=tjkqnKtO3dpZEUhYaCAh5MCYMl0Y5RJ/uxLfBOjoDTKeUjJfAzx56u2oX79uyJveZd tAOooMORQ8rJY/AdfNVyeZUWIcPjcnlBycbB/bVxTUJNZej/mDQo1d6waOCRiRp8hGwE XpMavNXWyHc2Hr0rFlUs2D+28eTKMOgsdAZTQYtb0YN231iC2CTGvhMKXjVjzHc2P6z/ Xf6SsyLS4gLRD2ChmY03ToExpgLa3D2R7mqDR6oCA1VSbWHKaAlXx2bQ7cyRGEfObVVp TcHFhTG45nld3EeJAJ8H2OGgrKO2Vc66a4eUNuU2vcYRuAzrqBpCn3OZcffLcyJfOjdp JsrA== X-Gm-Message-State: AKwxytdBt9uIF7TKvJt7wbWxF2W2WUZfSNyJ5WJnNRYC7gShFSY0MN8u O7yG/f0T6PVEGbCtogQYldwEhCok9iAoQVJ+sbo= X-Google-Smtp-Source: AH8x224/c95890TR+psWSQVNc/p3ETDh8s5wB6ZOHUiiFonooDxCb7Bt+YG952WOa8PzF4JOf+P59aWe6VBWhElymVA= X-Received: by 10.36.46.23 with SMTP id i23mr10249630ita.55.1517776316557; Sun, 04 Feb 2018 12:31:56 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 4 Feb 2018 12:31:55 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> <20180204182550.GA19526@1wt.eu> <938555E5-F328-41B0-B61F-09FC02B84397@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 4 Feb 2018 12:31:55 -0800 Message-ID: Subject: RE: Packet number encryption To: huitema , Praveen Balasubramanian Cc: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Gorry Fairhust , Piotr Galecki , "quic@ietf.org" , "Eggert, Lars" , Brian Trammell , Martin Thomson , Roberto Peon , Jana Iyengar , Eric Rescorla , "Lubashev, Igor" , "Roni Even (A)" Content-Type: multipart/alternative; boundary="001a114a9d82326d05056468d631" 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, 04 Feb 2018 20:31:59 -0000 --001a114a9d82326d05056468d631 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One aspect of randomised gaps that might be overlooked is that packet numbers are only sent with the lower 4 bytes at most. This means that a randomised gap on a new connection ID is not different from a new packet number that starts at a random offset because you cannot tell if it rolled over without knowing more about the connection. However, if migration does not look like a new connection, at least a 0-RTT, it is all a mood point because the sudden appearance of data on a new connection ID combined with the silence of another ID, and probably also characteristic changes in packet delays and sizes during migration, along with GeoIP, are all fingerprinting the connection. On monitoring packets inside a network, there are probably many new unexplored possibilities to track reordering of encrypted packet numbers. For example, one could create a bloom filter to record the packet numbers seen in a block of N packets, for example syncing wherever the lower packet number bits are all 0, or something. Packet loss would show up as fewer matches when comparing filters at different nodes. Or the lower 8 bits of each packet number in a block could be concatenated to a string and compared with levenshtein edit distance - even just the lower two bits of each packet might suffice. The fact the packet numbers are random could be used pro-actively to simplify hashing. While the above has some statistical uncertainties, and they do require a bit more data and time, they also possibly look at longer sequences and thereby give an overall better quality of understanding than just looking for out of sequence numbers. After developing good hashes that somehow encode ordering relations, a neural network might be trained to identify abnormal traffic patterns efficiently. Mikkel On 4 February 2018 at 20.55.59, Praveen Balasubramanian (pravb@microsoft.co= m) wrote: Ok this answers my question that this is targeted at the migration scenario. If jumps are random and cryptographically seeded I don't understand why there would be a pattern. We already use this type of mechanism for TCP ISN and IP header Identification fields. The adversary could also use the side channel timing attack of just observing the sending and receiving application rate for correlation between the two paths (after factoring in the RTT). If independent sequence space (with randomization) can work just as well I'd rather pick that over encryption for efficiency reasons. It should solve ossification but I am not a privacy expert. -----Original Message----- From: Christian Huitema [mailto:huitema@huitema.net] Sent: Sunday, February 4, 2018 11:46 AM To: Praveen Balasubramanian Cc: quic@ietf.org; Gorry Fairhust ; Eric Rescorla < ekr@rtfm.com>; Brian Trammell ; Lubashev, Igor < ilubashe@akamai.com>; Roberto Peon ; Fossati, Thomas (Nokia - GB/Cambridge, UK) ; Roni Even (A) < roni.even@huawei.com>; Mirja K=C3=BChlewind ; Jana Iyengar ; Eggert, Lars ; Martin Thomson ; Piotr Galecki < piotr_galecki@affirmednetworks.com> Subject: Re: Packet number encryption > On Feb 4, 2018, at 9:31 AM, Praveen Balasubramanian wrote: > > From the charter "This work will ensure that QUIC has 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)." > > Is the discussion mainly focused on connection migration which is not present in TCP? There seem to be bigger privacy problems due to DNS and TLS SNI extension so in real deployments will packet number encryption add value other than preventing ossification? Yes, we need to fix the SNI issue. Clear text ALPN too. But should not prevent us from fixing everything else. > > Is a cryptographically secure random initial packet number and random (forward) jumps in packet number not good enough to prevent ossification? The missing packet number range due to the forward jump could be communicated in the encrypted payload so the receiver knows they are not missing. > No, random jumps are not enough. It turns out that during migration packets are often sent simultaneously on both paths. The pattern of increases and holes is enough to correlate the two paths. In practice there are two possible designs: packet number encryption as currently documented; or, independent sequence number space and encryption context for each path. Both work. The one we have is significantly easier to implement. The other exposes the sequence number, which may ease network monitoring but also could drive ossification. Now is a good time to have this discussion. -- Christian Huitema --001a114a9d82326d05056468d631 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = One aspect of random= ised gaps that might be overlooked is that packet numbers are only sent wit= h the lower 4 bytes at most. This means that a randomised gap on a new conn= ection ID is not different from a new packet number that starts at a random= offset because you cannot tell if it rolled over without knowing more abou= t the connection.

How= ever, if migration does not look like a new connection, at least a 0-RTT, i= t is all a mood point because the sudden appearance of data on a new connec= tion ID combined with the silence of another ID, and probably also characte= ristic changes in packet delays and sizes during migration, along with GeoI= P, are all fingerprinting the connection.

On moni= toring packets inside a network, there are probably many new unexplored pos= sibilities to track reordering of encrypted packet numbers. For example, on= e could create a bloom filter to record the packet numbers seen in a block = of N packets, for example syncing wherever the lower packet number bits are= all 0, or something. Packet loss would show up as fewer matches when compa= ring filters at different nodes. Or the lower 8 bits of each packet number = in a block could be concatenated to a string and compared with levenshtein = edit distance - even just the lower two bits of each packet might suffice. = The fact the packet numbers are random could be used pro-actively to simpli= fy hashing.

While the above has some statistical u= ncertainties, and they do require a bit more data and time, they also possi= bly look at longer sequences and thereby give an overall better quality of = understanding than just looking for out of sequence numbers. After developi= ng good hashes that somehow encode ordering relations, a neural network mig= ht be trained to identify abnormal traffic patterns efficiently.
=
Mikkel

On 4 February 2018 = at 20.55.59, Praveen Balasubramanian (pravb@microsoft.com) wrote:

Ok this answers my question that this is= targeted at the migration scenario. =20

If jumps are random and cryptographically seeded I don't understand= why there would be a pattern. We already use this type of mechanism for TC= P ISN and IP header Identification fields. The adversary could also use the= side channel timing attack of just observing the sending and receiving app= lication rate for correlation between the two paths (after factoring in the= RTT). =20

If independent sequence space (with randomization) can work just as wel= l I'd rather pick that over encryption for efficiency reasons. It shoul= d solve ossification but I am not a privacy expert.

-----Original Message-----
From: Christian Huitema [mailto:= huitema@huitema.net] =20
Sent: Sunday, February 4, 2018 11:46 AM
To: Praveen Balasubramanian <= pravb@microsoft.com>
Cc: quic@ietf.org; Gorry Fairhust = <gorry@erg.abdn.ac.uk>; E= ric Rescorla <ekr@rtfm.com>; Bria= n Trammell <ietf@trammell.ch>= ; Lubashev, Igor <ilubashe@akamai= .com>; Roberto Peon <fenix@fb.com= >; Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>; Roni Even (A) &= lt;roni.even@huawei.com>; Mi= rja K=C3=BChlewind <m= irja.kuehlewind@tik.ee.ethz.ch>; Jana Iyengar <jri@google.com>; Eggert, Lars <lars@netapp.com>; Martin Thomson <martin.thomson@gmail.com>; Piotr Galec= ki <piotr_galecki@= affirmednetworks.com>
Subject: Re: Packet number encryption



> On Feb 4, 2018, at 9:31 AM, Praveen Balasubramanian <pravb@microsoft.com> wrote:
> =20
> From the charter "This work will ensure that QUIC has securit= y and privacy properties that are at least as good as a stack composed of T= LS 1.3 using TCP (or MPTCP when using multipath)."
> =20
> Is the discussion mainly focused on connection migration which is = not present in TCP? There seem to be bigger privacy problems due to DNS and= TLS SNI extension so in real deployments will packet number encryption add= value other than preventing ossification? =20

Yes, we need to fix the SNI issue. Clear text ALPN too. But should not = prevent us from fixing everything else.

> =20
> Is a cryptographically secure random initial packet number and ran= dom (forward) jumps in packet number not good enough to prevent ossificatio= n? The missing packet number range due to the forward jump could be communi= cated in the encrypted payload so the receiver knows they are not missing.
> =20

No, random jumps are not enough. It turns out that during migration pac= kets are often sent simultaneously on both paths. The pattern of increases = and holes is enough to correlate the two paths.

In practice there are two possible designs: packet number encryption as= currently documented; or, independent sequence number space and encryption= context for each path. Both work. The one we have is significantly easier = to implement. The other exposes the sequence number, which may ease network= monitoring but also could drive ossification.

Now is a good time to have this discussion.

-- Christian Huitema =20

--001a114a9d82326d05056468d631-- From nobody Sun Feb 4 12:52:10 2018 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 AAA01127419 for ; Sun, 4 Feb 2018 12:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 8yyrPC9Vdm5H for ; Sun, 4 Feb 2018 12:52:07 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B812C120725 for ; Sun, 4 Feb 2018 12:52:06 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9DC5A34068D; Sun, 4 Feb 2018 21:52:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.24773); Sun, 4 Feb 2018 21:52:02 +0100 (CET) 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; Sun, 4 Feb 2018 21:52:02 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44291426; Sun, 04 Feb 2018 21:52:02 +0100 From: "Brian Trammell (IETF)" Message-Id: <66B2703B-1BE8-4065-A182-22A793B5998D@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_3626AFF9-1CDE-4EB8-84CC-3C361208484C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Sun, 4 Feb 2018 21:52:01 +0100 In-Reply-To: <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> Cc: "Lubashev, Igor" , "Roni Even (A)" , Roberto Peon , Piotr Galecki , Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Gorry Fairhurst , Eric Rescorla , "Eggert, Lars" , =?utf-8?Q?Mirja_K=C3=BChlewind?= , QUIC WG , Martin Thomson To: Christian Huitema References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> 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: Sun, 04 Feb 2018 20:52:10 -0000 --Apple-Mail=_3626AFF9-1CDE-4EB8-84CC-3C361208484C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Feb 2018, at 18:40, Christian Huitema = wrote: >=20 >=20 >=20 > On Feb 4, 2018, at 7:18 AM, Lubashev, Igor = wrote:... >>=20 >> Having networks wrap and unwrap packets at their boundaries is a = possibility, though it has real costs and downsides. First, while = networks could setup such wrapping for UDP port 443 traffic, what about = QUIC traffic using other ports? Would networks need to wrap all UDP = traffic? Second, this does reduce MTU for end users, reducing available = bandwidth. Third, this would allow networks to only answer questions = like: =E2=80=9CIs my network the culprit of the problem?=E2=80=9D = instead of =E2=80=9CIs the problem in my network, upstream from me, or = downstream from me?=E2=80=9D. >=20 > This is exactly why I believe the proper place for things like spin = bits or short sequence numbers is in the IP header. That would be a = really neat use of the IPv6 flow ID. Let me say this again, more directly: the IPv6 flow ID will absolutely = not work for this. It's used, when it's used, for ECMP entropy and other = end-of-the-path routing things. This is equivalent to the problems with = ECN on older hardware / configurations using TOS for ECMP entropy: = reassign these Measurement bits aren't flow identifiers. Overloading the latter to = become the former because we don't want to deal with the protocol stack = we've inherited is not a serious option. If you've got data to the contrary, please share it. But saying this = will work is an exceptional claim, and requires exceptional evidence. >>=20 >> Would it be considered outrageous to suggest that packet number = encryption be an option negotiated during connection handshake? An end = user client in =E2=80=9CPrivacy-Enhanced=E2=80=9D mode would negotiate = this, while end users not particularly concerned with connection = migration linkability issues would leave this off? >=20 > Negotiate privacy off in the name of network performance? Very = slippery slope! For example, the connections that do require privacy = would stick out. >=20 > -- Christian Huitema --Apple-Mail=_3626AFF9-1CDE-4EB8-84CC-3C361208484C 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp3cnEACgkQihK3vwvq RqN4EA/+JOqjcr7mkwPOVH3KXEX0Bomoyfu/ulAvjdudVSPxt56mRSoPhHZfAR8g I0+kd7WabhBg8wbOvVm7UM4lmaSKOP3bTMlY/TXlGf2oGLnE1GMdox/rkXdeJDIF pspkHoiKTVkHDOaPhmLvM4QPlt6nzxFDoH7vYrpjlNYBa8ZJ3djmgTRs9CsJL+Vw nVQ5C0NeVvYn+FpypHyMOwvev+4MglB2y08G4xOyN0+A1g21VMEoYikgfgLOvnKS gvSn1tdZD4bIsS23lg+xoRSNumM8ItbbxKuhaZO185K3p2iI2E5uZetylL/0JbOg V+Dkul7HKdqIV3pIRAlAXkp/5gdFWYJJA3/6e9GmMEQZpiVXnmdG8V5CDgPNEVVf slq66jrOPrloPO0jr7RnrgTzrqdGj36wGuifjAFxw+fMhDp2GkvQRUp0Zti+7uWB nqBygDzsKXt0nIfdg3tG50KIc1nCu5crVFwyT3f1YCSceWa8Dh2oHLiAKbam4Geb sZsbZecfklN3g6UNaxTyzeJNajPF6l5N7VfsUnPfzSnjoCHcwTvcB5T63m+LEdh0 1ytfRmXY5g8YMJ/0/PEysY19qyFNNxARVEjB1mBKQcfu1Taro+cVit4/81rQ1t6e Kd6Tg5vGsR/MsO3Ya1LZvfDnMOz+li36BPPXKzeazAV6JwfpsXc= =I1zh -----END PGP SIGNATURE----- --Apple-Mail=_3626AFF9-1CDE-4EB8-84CC-3C361208484C-- From nobody Sun Feb 4 12:53:34 2018 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 1C9081241F8 for ; Sun, 4 Feb 2018 12:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ILK_iBBXWLBB for ; Sun, 4 Feb 2018 12:53:31 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFA23120725 for ; Sun, 4 Feb 2018 12:53:30 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8251534047F; Sun, 4 Feb 2018 21:53:29 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.25836); Sun, 4 Feb 2018 21:53:29 +0100 (CET) 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; Sun, 4 Feb 2018 21:53:29 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44291466; Sun, 04 Feb 2018 21:53:29 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_73E64CE4-3C03-4C33-A1D1-3E8063E3EB1A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Sun, 4 Feb 2018 21:53:28 +0100 In-Reply-To: <66B2703B-1BE8-4065-A182-22A793B5998D@trammell.ch> Cc: Gorry Fairhurst , Eric Rescorla , "Lubashev, Igor" , Roberto Peon , =?utf-8?Q?Mirja_K=C3=BChlewind?= , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , "Roni Even (A)" , "Eggert, Lars" , Jana Iyengar , Piotr Galecki , QUIC WG , Martin Thomson To: Christian Huitema References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <888DE2C2-4EDA-445A-B08F-76DD016C9CA0@huitema.net> <66B2703B-1BE8-4065-A182-22A793B5998D@trammell.ch> 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: Sun, 04 Feb 2018 20:53:33 -0000 --Apple-Mail=_73E64CE4-3C03-4C33-A1D1-3E8063E3EB1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 Feb 2018, at 21:52, Brian Trammell (IETF) = wrote: >=20 >>=20 >> On 4 Feb 2018, at 18:40, Christian Huitema = wrote: >>=20 >>=20 >>=20 >> On Feb 4, 2018, at 7:18 AM, Lubashev, Igor = wrote:... >>>=20 >>> Having networks wrap and unwrap packets at their boundaries is a = possibility, though it has real costs and downsides. First, while = networks could setup such wrapping for UDP port 443 traffic, what about = QUIC traffic using other ports? Would networks need to wrap all UDP = traffic? Second, this does reduce MTU for end users, reducing available = bandwidth. Third, this would allow networks to only answer questions = like: =E2=80=9CIs my network the culprit of the problem?=E2=80=9D = instead of =E2=80=9CIs the problem in my network, upstream from me, or = downstream from me?=E2=80=9D. >>=20 >> This is exactly why I believe the proper place for things like spin = bits or short sequence numbers is in the IP header. That would be a = really neat use of the IPv6 flow ID. >=20 > Let me say this again, more directly: the IPv6 flow ID will absolutely = not work for this. It's used, when it's used, for ECMP entropy and other = end-of-the-path routing things. This is equivalent to the problems with = ECN on older hardware / configurations using TOS for ECMP entropy: = reassign these ... and things will break in unexpected and hard to debug ways. >=20 > Measurement bits aren't flow identifiers. Overloading the latter to = become the former because we don't want to deal with the protocol stack = we've inherited is not a serious option. >=20 > If you've got data to the contrary, please share it. But saying this = will work is an exceptional claim, and requires exceptional evidence. >=20 >>>=20 >>> Would it be considered outrageous to suggest that packet number = encryption be an option negotiated during connection handshake? An end = user client in =E2=80=9CPrivacy-Enhanced=E2=80=9D mode would negotiate = this, while end users not particularly concerned with connection = migration linkability issues would leave this off? >>=20 >> Negotiate privacy off in the name of network performance? Very = slippery slope! For example, the connections that do require privacy = would stick out. >>=20 >> -- Christian Huitema --Apple-Mail=_73E64CE4-3C03-4C33-A1D1-3E8063E3EB1A 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp3csgACgkQihK3vwvq RqOCDBAAkEoIn3PP501kUFApUWc5zjKzJHO5xKPJVZthn5c55bcnAoeaI0kUUmB6 5ECDDVBwASAPY9cBqDisjavo0bFTqosKUE4bekw9aX8J4FflOyEao0+nOZvkjk+0 WM6JmNbvbHMPPr8lYb/S+il36mSNHGWm6UV9vhC+u0Yn9iV5UbMQvzGsqa3AJKrV b0IYgLObakuOYbJ/fv5/E5d32Cg6Ky1QE334537WS7zeNTSY9bbmxibgxq/ujAvn uHXarF14qj2soPe1Af6s8SajtVRH8cI4u7NijeLPEpkcSYuxeQpNYSpdU599hkx+ xCcB9ICotp9NFtnJDjZVdW/Yp/yl8Q3k+spLxPeM8vPB1rQFTbxbYlPRQDMK55mR 3b29HqmEhfVEufaFGX/YvgkBGSo0s05lpI+xxfn2v/gpvcXuD8U2Q84KVKgERj9R APGKwBbjybkmi82TdMUTH9oM9aX6FW4yOZe9gRXXDuCOlklDcUlNTUzaDaIccSN5 J9gEJ+IjlP3cOPIIrX2Er9evltCWX3kDj+ryMH3TuzspE/IGugBI7X/GhLgA8IqN XhqpV354x9DDj3JCkN/J01n3353960mbsXa+7WThxumsxqlofg+4FhuqECH5zD9K XG65/wsH/vaLJoNrWkKzIB8xAsw2uqcc9Nk3sK3W3c35jK1E6Z4= =jDPW -----END PGP SIGNATURE----- --Apple-Mail=_73E64CE4-3C03-4C33-A1D1-3E8063E3EB1A-- From nobody Sun Feb 4 13:31:28 2018 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 1640F127871 for ; Sun, 4 Feb 2018 13:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Fl5LunLzPpMH for ; Sun, 4 Feb 2018 13:31:24 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50E27126DCA for ; Sun, 4 Feb 2018 13:31:22 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C60593404D5; Sun, 4 Feb 2018 22:31:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.357); Sun, 4 Feb 2018 22:31:18 +0100 (CET) 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; Sun, 4 Feb 2018 22:31:18 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44292558; Sun, 04 Feb 2018 22:31:18 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8DE5A9C0-799D-40DF-83BE-13E9FD0A34E0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Sun, 4 Feb 2018 22:31:17 +0100 In-Reply-To: Cc: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Gorry Fairhurst , Eric Rescorla , =?utf-8?Q?Mirja_K=C3=BChlewind?= , Christian Huitema , "Eggert, Lars" , QUIC WG , Martin Thomson To: Jana Iyengar References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> 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: Sun, 04 Feb 2018 21:31:27 -0000 --Apple-Mail=_8DE5A9C0-799D-40DF-83BE-13E9FD0A34E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, > On 3 Feb 2018, at 03:30, Jana Iyengar wrote: >=20 > A few points as I catch up on this thread. >=20 > First, I'll remind folks that QUIC is an encrypted transport. I say = this because the cost of this operation is trivial in the context of = encrypting every packet. The cost is borne at the servers and not at = middleboxes, so the additional crypto cost is basically trivial. After having worked my way through the PR again (and essentially = rewriting it from the receiver's point of view, which I believe would be = useful text to have in the final document, should we end up doing this), = I buy this. > Second, this simplifies and increases robustness of implementation. = Avoiding random PN jumps, as Kazuho points out, makes special-casing of = code unnecessary. Special code that is exercised occasionally is a = strong bug attractor, and I would strongly argue for as few of those as = possible in implementation. Agree completely. Packet number jumps are a bad idea, and there seems to = be a (not explicitly examined) consensus that attempting to make = linkability difficult is worth the effort. > Third, yes, ossification is a real concern. A simple example: using = increasing packet numbers as a signature for detecting QUIC. Even if you = argue against this example, there are innovative ways in which = ossification will happen. This is based on a true story: We had no idea = how GQUIC's flags field could get ossified, the value that was being = used commonly became used as a signature for QUIC traffic (see Section = 7.5 in the SIGCOMM QUIC paper). There's an overgeneralization of experience from ossification of single = static fields (as in the TLS greasing and GUIC flags cases) to functions = over the time series of these fields which has not yet been shown to be = valid IMO in the case of integrity-protected wire images -- will expand = on this in my next message, replying to Roberto. > There's a win here in terms of implementation complexity and several = implementers have said so. Compared to packet number jumps, absolutely. Compared to the state two = revs of the draft ago, it's a *little* more complex but at least it = doesn't add completely new operations at the sender or the receiver. > There's a win in terms of ossification and our experience says so. That experience is IMO overgeneralized. > There's a potential loss of manageability, in being able to detect = reordering. Well, upstream loss and upstream reordering. As Christian suggested at the start of this thread, if we simultaneously = add back a signal that would allow on-path loss and reordering = detection, that would make this a usable-information-content-neutral = change to the wire image, and everyone could leave the table happy. The = only problem with this is that the most obvious place to put this signal = -- the four bits we get back from the short header type field (assuming = we add the spin bit) aren't really enough to track the loss and = reordering patterns we care about with a naive counter. There are lots of other options in this space (e.g. decide we care about = latency more than reordering, and that we don't care about loss at all, = and use a two-bit spin to protect the latency signal from reordering, = and so on), but that seems like a third thread we should start. Cheers, Brian > This is the trade-off, and I am still in favor of encrypting packet = numbers. >=20 > On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, = UK) wrote: > On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" = wrote: > > On 2018-1-31, at 10:52, Gorry Fairhurst = wrote: > > > +1 - Simply: This *is* complicated and seems to add little. > > > > So as an implementor (chair hat off), this adds very little to the > > overall complexity of the protocol. >=20 > This doesn't sound great. It's a bit like saying that adding the = Higgs > mechanism to the standard model's lagrangian doesn't make it much more > complicate :-) (*) >=20 > More seriously though, I'd like to point out that it is not just about > implementation complexity, it's also the energy cost per packet that = is > quite crucial. I haven't done the math but ISTM that bringing in > another batch of non-optional crypto computation on a per packet basis > is not going to move the needle in the right direction for stacks that > run on low power (IoT). >=20 > This is not a catastrophe - we have CoAP and a (D)TLS profile - but > neither it's ideal, since cutting off the small things from the wider > ecosystem creates an artificial gap which then will need a middlebox = to > bridge. (Sure, we have specified the behaviour of a similar box > already, but it'd be really better if the extra translation logic = could > be avoided in the first place.) >=20 > I guess what I'm saying is that PN encryption being a core mechanism > that can't be negotiated at handshake time reduces our ability to = later > profile QUIC for the IoT, which would be a bit unlucky. >=20 > So the question is: would it be possible to make this property a > configurable knob instead? >=20 > (*) = https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-= equation >=20 >=20 --Apple-Mail=_8DE5A9C0-799D-40DF-83BE-13E9FD0A34E0 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp3e6UACgkQihK3vwvq RqM2cw/+KoIS3E4gSO3uSjkaiA+7KSXRAI230PFL/bI1OGxEWkkcw2QqIK06Tjv0 fuoBQate0fVW6S27bssxT0BdVFmzt6YB5HsUVRhBvjL8Yug+7XhmN2sdutKene3n Ji3Z8fMBYOBW01DC0/1YczzdafvlZ+PJwOjVmh8L5Z7O+/SyOU2HqEipmNUUHaRj VGQc0+SfzMnEhiSVjafGmnmUF4L9tKRPOQjdYUTzltfDypr4oqCDQlxgk3k19fDB gMK7cGp9V4PE7XgExV83oLBw/Sz+vQR3T9TJGH4a/Lr8zqlVbI8z42ZvxAOf1ghx 4xPB/DFN8Q4wDp9i/aimF1+4QihSMbgVsOLWXdufEk4jFAcaL8a0iMlxDFFQZ0xa pT4367R25frmU/2K/DU6uW8LaUpniNNTBMjKom6pcqSECjdiRMwE8c0MWSV2fA2l Qay1NXmNYmcgR4k7j1fw7Eri763ch/og0sKia021xmGTA0T+T6DFGsJQVCt2Tq42 X3HjhDhpccDXfTMW8B+/gJ/QK+bt13QfmG4CJklCNNZriUR9HhelmNLSLjLne//q 6LGM2/ZAEv4/PpWWKnkY9NXAJ0t+Ma+ls9HspcirbC7Gv8fQscF6oSKvTPYrwAc3 vBLx5K+JMr+rEZWV8sgKNVN8Pdkg+cbHjAxmTfKjJKXl7cID/Fk= =O6yf -----END PGP SIGNATURE----- --Apple-Mail=_8DE5A9C0-799D-40DF-83BE-13E9FD0A34E0-- From nobody Sun Feb 4 13:31:35 2018 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 A5B53129516 for ; Sun, 4 Feb 2018 13:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 uQRH9Z00klFV for ; Sun, 4 Feb 2018 13:31:28 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4207126DCA for ; Sun, 4 Feb 2018 13:31:27 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6DE42340552; Sun, 4 Feb 2018 22:31:26 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.29361); Sun, 4 Feb 2018 22:31:26 +0100 (CET) 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; Sun, 4 Feb 2018 22:31:26 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44292559; Sun, 04 Feb 2018 22:31:26 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D820FCF1-0160-46B5-B0F0-B1FE6731A040"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Reducing ossification through protocol design (was Re: Packet number encryption) Date: Sun, 4 Feb 2018 22:31:26 +0100 In-Reply-To: Cc: QUIC WG To: Roberto Peon References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> 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: Sun, 04 Feb 2018 21:31:30 -0000 --Apple-Mail=_D820FCF1-0160-46B5-B0F0-B1FE6731A040 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Roberto, all, (trimming CC, forking thread, since this *really* is separate from the = question of packet number encryption.) > On 3 Feb 2018, at 19:37, Roberto Peon wrote: >=20 > Ossification: > In the past tcp middleboxes expected in-order, monotonically = increasing offsets and tried to fix reordering before forwarding. This = middlebox behavior, predicated on observable flows, prevented deployment = of things which would have made tcp more efficient. >=20 > This is the kind of non-theoretical ossification that drove the = creation of QUIC in the first place. This becomes more theoretical when you apply observations about TCP to = QUIC: (1) Sequence numbering in TCP is far more broken than packet numbering = (encrypted or not) ever could be, simply because it's not end-to-end = integrity protected. The first deployed sequence number meddling boxes, = IIRC, were designed to randomize ISNs (i.e., rewrite them), since stacks = that did so were slow to deploy. PN rewriting is not only useless in = QUIC, it'll break the connection. (2) Many TCP stacks actually had (and some have) crap performance under = certain reordering patterns, such that the deployment of a middlebox = that did "fix" reordered packets would have had measurable benefits when = tested against the stacks prevalent on the networks on which they were = deployed at the time they were deployed. A QUIC PN-reordering middlebox = would not show any such benefit, and would be correspondingly difficult = to sell. (3) The time to "path interference decay" for the TCP sequence number = was years. Yes, things move more quickly now (indeed, as evidenced by = experience with GUIC), but unless we intend not to deploy QUIC version 2 = rapidly on the heels of QUIC version 1, I would submit that there's = still time to revise everything not in the invariants. (And, indeed, if = we do *not* intend to deploy QUIC version 2 rapidly on the heels of QUIC = version 1, i.e., not until the "path interference decay" time, then this = entire exercise is academic and we can all go home, because the version = negotiation mechanism will ossify, greasing or not.) I think we need to take a step back and take a more systematic view = toward ossification prevention. Greasing, in the TLS sense, refers to not allowing extensibility = codepoints to have a single value or set of values that can be used for = traffic classification and/or bad traffic rejection by a naive device on = the path. This is useful when you're trying to keep parts of the = codepoint space available for future use, but the design of QUIC is such = that the set of codepoints *in the wire image* is completely determined = by the negotiated version; i.e., adding a new packet type to the QUIC = long header would require a new version. Therefore, protecting the = version negotiation mechanism itself is necessary and sufficient to = prevent the wire image from ossifying. This points the way to an alternate approach which will free us from = having to have the ossification discussion about every single bit in the = Version 1 header. Early and meaningful exercise of the version = negotiation mechanism, with at least two versions whose wire images have = *only* our intended invariants in common, is far superior to greasing = the version codepoints as a method to protect the version negotiation = mechanism. Greasing is a way to "fake" agility when you don't have any = real agility yet -- but we're designing a protocol with real agility, = with a version negotiation mechanism based at least in its core = operation on GUIC's mechanism -- i.e., on one which we know at least one = deployer of the protocol has used successfully multiple times. Greasing is still useful for fields in the invariants that have static = values for codepoints we might want to use in the future -- but the = greasing space should cover the whole codepoint space in these cases, = since post VN we know which values are grease. (The PN encryption question is separate. The fundamental question here = is "should the path see the PN?"... before Melbourne, the answer was "it = doesn't matter because we haven't figured out a scalable way to do = that". Now the answer is "probably not the whole PN, but the bottom N = bits seem quite useful for maintaining TCP-equivalent measurability for = the protocol, with a linear linkability risk / measurement utility = tradeoff depending on N." Those N bits ossify only if Version 1 is the = only QUIC version for the foreseeable future, or if we put them at the = same observable offset in the Version 2 header.) Cheers, Brian --Apple-Mail=_D820FCF1-0160-46B5-B0F0-B1FE6731A040 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp3e64ACgkQihK3vwvq RqOj2A//QrY6lZFxN/bRSapFXX4JDtNvt/NnfyWCzssicv9Y0vdDY2MFHPnd9SnR 5+uVLYzjE78OGwAZKHZ9WgkYB56hhxk/tZYv+dif6ewQJsj0dLohXvlxFxeww06q ytuMCVpkQvYvcR4aXgErmd2M9SrTGsI8Pu3n/VhZng9cb5Mk5I9S83PugNHUOvP9 K4+g03C0NDuP2jCns5CHacI32jdZosGEZ1r3iEXfza/octhytCnfffcQ8tBmtH6b Ut32gsVFsNfjJhVEof7MIS3NU0d/v9WVD8hGKTyBv5uO+L2OkkI9jFpz6rNwIF+/ eQ/ZASesXkrjM4Y6P80Inw4u1XeMtZqYsRgWRefG/o3HvroCGjNs9ZnghtwN9ACl xp6kKaqRlrpEbKu09Ay4c5wQGdqEsABmX8oE/JwuUAU2vEIJeFm4dYXRANF1KLcL rENvGiWeVukBYa10hiNdy/ffXBE9yaDHEPy9gj4nkak98sm22x/ZwKuPfteOv50h eJa43pGMkGN+zXQGnQ93yzTLJoO1KQISfEWNTl/rMUcJEKcuHxAawwIveHNsCRwB qYm6EQc4wpmqeV4ruc48EhVsNijGF7+LDONAuNccP1mMtU/Wa+iKOlsPG53b8aZO V82FLYFvdYVgmNfqyulCwDeC7fO2K2eyFjKtylnT2BZI+eiHjHs= =bHVN -----END PGP SIGNATURE----- --Apple-Mail=_D820FCF1-0160-46B5-B0F0-B1FE6731A040-- From nobody Sun Feb 4 14:52:56 2018 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 A8109129BBF for ; Sun, 4 Feb 2018 14:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_H2=-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 3PujEFM32v5B for ; Sun, 4 Feb 2018 14:52:51 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0121.outbound.protection.outlook.com [104.47.34.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D068120725 for ; Sun, 4 Feb 2018 14:52:51 -0800 (PST) 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=/uTHnuhOZCCQ2Y9pzgVANqKUwZxiHfaCXGZmOt/M2A8=; b=mxaXmxlG+NdknbDQyFepIpW2YOUIT7+o3bPAYNvhMjonfnEREYzvUy/qKhaI/hZuq0JMLC5K8GmLW+C18nZkDcI8rRk/3OqfILDT9AH86KccaIas5cZbRVkW5/L0z7hED2L855TG9lHzgsiyXLD22EcL8xRp0SyPwaKPWAKJcmU= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0152.namprd21.prod.outlook.com (10.173.189.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.4; Sun, 4 Feb 2018 22:52:48 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Sun, 4 Feb 2018 22:52:48 +0000 From: Praveen Balasubramanian To: "Brian Trammell (IETF)" , Jana Iyengar CC: Gorry Fairhurst , Eric Rescorla , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , =?iso-8859-1?Q?Mirja_K=FChlewind?= , "Eggert, Lars" , huitema , QUIC WG , Martin Thomson Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAC0PSAgAAUMsA= Date: Sun, 4 Feb 2018 22:52:48 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0152; 7:D2TnF5GB1JI1M+eOP6NqqXEyLxuB6EsG6edwqBmfptL6xF44GSAFPJmXqPJYDNiGUcxjo6QbBCke7nyyHXn/qB2Zm00LYaeaEcrPU7oMa0PRAyYdvmgkffY5W2Y2BBR8FGBxF+OAK9Sjy/xOvTfj1oUF2NOofOXxR1jaI1ap2zw82/cIS/H+fsmeAjsMjEtRdTycHCvRVMcU7hHzQwLt8ENL9wasbUfcz7FN/GVm8TpjiJCHzJq8cLmtjRK8+fcI x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 437a3bfb-6814-4faa-87fb-08d56c22039e x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0152; x-ms-traffictypediagnostic: CY4PR21MB0152: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-exchange-antispam-report-cfa: BCL:0; PCL:0; RULEID:(3231001); SRVR:CY4PR21MB0152; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0152; x-forefront-prvs: 05739BA1B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(11905935001)(189003)(199004)(377424004)(13464003)(3480700004)(81156014)(2950100002)(8936002)(5660300001)(7116003)(966005)(6436002)(229853002)(8656006)(106356001)(99286004)(9686003)(54906003)(6306002)(105586002)(8990500004)(93886005)(110136005)(68736007)(8676002)(14454004)(55016002)(86362001)(6246003)(3660700001)(77096007)(7416002)(10090500001)(6116002)(76176011)(53546011)(4326008)(33656002)(25786009)(7736002)(6506007)(102836004)(305945005)(3280700002)(2900100001)(97736004)(74316002)(7696005)(86612001)(186003)(59450400001)(22452003)(39060400002)(10290500003)(6346003)(4001150100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0152; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: At5/qE/WCH6GO4nvqkdzPXCcEG5uAqTmcZAVnO+Fm/ryc8/gsqy840h9UaD7CYiXPrR3Aba9CWtFVBV69NTseg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 437a3bfb-6814-4faa-87fb-08d56c22039e X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2018 22:52:48.2807 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0152 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, 04 Feb 2018 22:52:54 -0000 There seems to be a 1 to 1.25% overhead due to the additional encryption/de= cryption operation based on a quick microbenchmark experiment. This number = will vary for each implementation / system config but seems to be non-negli= gible. Let's weigh this against the implementation complexities of dealing = with packet number jumps.=20 Thanks -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell (IETF= ) Sent: Sunday, February 4, 2018 1:31 PM To: Jana Iyengar Cc: Gorry Fairhurst ; Eric Rescorla ; F= ossati, Thomas (Nokia - GB/Cambridge, UK) ; Mirja= K=FChlewind ; Eggert, Lars ; huitema ; QUIC WG ; Martin Thomson= Subject: Re: Packet number encryption hi Jana, > On 3 Feb 2018, at 03:30, Jana Iyengar wrote: >=20 > A few points as I catch up on this thread. >=20 > First, I'll remind folks that QUIC is an encrypted transport. I say this = because the cost of this operation is trivial in the context of encrypting = every packet. The cost is borne at the servers and not at middleboxes, so t= he additional crypto cost is basically trivial. After having worked my way through the PR again (and essentially rewriting = it from the receiver's point of view, which I believe would be useful text = to have in the final document, should we end up doing this), I buy this. > Second, this simplifies and increases robustness of implementation. Avoid= ing random PN jumps, as Kazuho points out, makes special-casing of code unn= ecessary. Special code that is exercised occasionally is a strong bug attra= ctor, and I would strongly argue for as few of those as possible in impleme= ntation. Agree completely. Packet number jumps are a bad idea, and there seems to be= a (not explicitly examined) consensus that attempting to make linkability = difficult is worth the effort. > Third, yes, ossification is a real concern. A simple example: using incre= asing packet numbers as a signature for detecting QUIC. Even if you argue a= gainst this example, there are innovative ways in which ossification will h= appen. This is based on a true story: We had no idea how GQUIC's flags fiel= d could get ossified, the value that was being used commonly became used as= a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper). There's an overgeneralization of experience from ossification of single sta= tic fields (as in the TLS greasing and GUIC flags cases) to functions over = the time series of these fields which has not yet been shown to be valid IM= O in the case of integrity-protected wire images -- will expand on this in = my next message, replying to Roberto. > There's a win here in terms of implementation complexity and several impl= ementers have said so. Compared to packet number jumps, absolutely. Compared to the state two revs= of the draft ago, it's a *little* more complex but at least it doesn't add= completely new operations at the sender or the receiver. > There's a win in terms of ossification and our experience says so. That experience is IMO overgeneralized. > There's a potential loss of manageability, in being able to detect reorde= ring. Well, upstream loss and upstream reordering. As Christian suggested at the start of this thread, if we simultaneously ad= d back a signal that would allow on-path loss and reordering detection, tha= t would make this a usable-information-content-neutral change to the wire i= mage, and everyone could leave the table happy. The only problem with this = is that the most obvious place to put this signal -- the four bits we get b= ack from the short header type field (assuming we add the spin bit) aren't = really enough to track the loss and reordering patterns we care about with = a naive counter. There are lots of other options in this space (e.g. decide we care about la= tency more than reordering, and that we don't care about loss at all, and u= se a two-bit spin to protect the latency signal from reordering, and so on)= , but that seems like a third thread we should start. Cheers, Brian > This is the trade-off, and I am still in favor of encrypting packet numbe= rs. >=20 > On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK= ) wrote: > On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" wrote: > > On 2018-1-31, at 10:52, Gorry Fairhurst wrote: > > > +1 - Simply: This *is* complicated and seems to add little. > > > > So as an implementor (chair hat off), this adds very little to the=20 > > overall complexity of the protocol. >=20 > This doesn't sound great. It's a bit like saying that adding the=20 > Higgs mechanism to the standard model's lagrangian doesn't make it=20 > much more complicate :-) (*) >=20 > More seriously though, I'd like to point out that it is not just about=20 > implementation complexity, it's also the energy cost per packet that=20 > is quite crucial. I haven't done the math but ISTM that bringing in=20 > another batch of non-optional crypto computation on a per packet basis=20 > is not going to move the needle in the right direction for stacks that=20 > run on low power (IoT). >=20 > This is not a catastrophe - we have CoAP and a (D)TLS profile - but=20 > neither it's ideal, since cutting off the small things from the wider=20 > ecosystem creates an artificial gap which then will need a middlebox=20 > to bridge. (Sure, we have specified the behaviour of a similar box=20 > already, but it'd be really better if the extra translation logic=20 > could be avoided in the first place.) >=20 > I guess what I'm saying is that PN encryption being a core mechanism=20 > that can't be negotiated at handshake time reduces our ability to=20 > later profile QUIC for the IoT, which would be a bit unlucky. >=20 > So the question is: would it be possible to make this property a=20 > configurable knob instead? >=20 > (*)=20 > https://www.symmetrymagazine.org/article/the-deconstructed-standard-mo > del-equation >=20 >=20 From nobody Sun Feb 4 16:39:00 2018 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 96C781243F6 for ; Sun, 4 Feb 2018 16:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, 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 (1024-bit key) header.d=fb.com header.b=eEVGQK1B; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=iP9EEQzg 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 Hb8SrQTKTIsv for ; Sun, 4 Feb 2018 16:38:56 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 AAD9F120725 for ; Sun, 4 Feb 2018 16:38:56 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w150Y9lC017220; Sun, 4 Feb 2018 16:38:00 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=TwF/h4lugZkHOxT6QcTl3SO8GxkgxP/v6FnQtSK3ep8=; b=eEVGQK1BFMr0TowA5eM94Urx0h/wEr4ZLouMz/TgrJz3o9NtPVzkRsWwHQGZMB/RCKT4 Td36QuqMJAPWY4pH5CObMxVDEqwon3V1mXPCT6EnwSUo8f01kW5tBULzGxI7/fvKBODN Sz0W7Gdg3/PZtWKgvU0vLz7a+NblIQPZl7M= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2fw9f256ry-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 04 Feb 2018 16:38:00 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.23) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 4 Feb 2018 19:37:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TwF/h4lugZkHOxT6QcTl3SO8GxkgxP/v6FnQtSK3ep8=; b=iP9EEQzguIiVLumGl7JPLNXvpD/OnzBeEj5fLzef+wAxiLtq2LNRS1bnxFEz4H81OfUl1edK20MMt1L2rHEneIMPVrgxbS2t5027sdotd3vMdcBPKfZWqVyNze3mIjn45loUGd8ipY5IE5rHbvfWi4zzYTJPC0iPY/Ot48kw87A= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0232.namprd15.prod.outlook.com (10.163.64.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 00:37:53 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 00:37:53 +0000 From: Roberto Peon To: "Roni Even (A)" , Piotr Galecki , Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" CC: Gorry Fairhust , Eric Rescorla , =?Windows-1252?Q?Mirja_K=FChlewind?= , "Eggert, Lars" , Brian Trammell , Christian Huitema , QUIC WG , "Martin Thomson" Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW3+HjM5RmHWDkij9J5s6UBSSaOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGB6AANx9AIABGNFf Date: Mon, 5 Feb 2018 00:37:53 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> , <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> , <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.234.190.115] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0232; 20:Sp+NVSP7uM5n/XiA0sV9f+twqvIgMn0v6lCNM0Q/ZPCCVj12VsQEoj4uwqyJei/+J5RSax4axuX59H8Enc4Y0CbCD+esvtRmjahd3G7cQJGqYCy+pbsJqdMmNctaLv1ndvQHtRhDvNqlb7MOHvl9iB2SFtppaE/GyoCjPc2uWlc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 701844ad-f59c-4726-3d9f-08d56c30b1a5 x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0232; x-ms-traffictypediagnostic: BY2PR15MB0232: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(72170088055959)(50582790962513)(82608151540597)(85827821059158)(211936372134217)(179696456005106)(153496737603132)(130329453890623); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(11241501184)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR15MB0232; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0232; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39380400002)(346002)(39860400002)(376002)(11905935001)(199004)(189003)(377424004)(186003)(5660300001)(19627405001)(7116003)(25786009)(39060400002)(561944003)(55016002)(54906003)(66066001)(4326008)(110136005)(68736007)(33656002)(76176011)(106356001)(7696005)(3660700001)(97736004)(966005)(3280700002)(6606003)(4001150100001)(229853002)(6436002)(53936002)(478600001)(14454004)(9686003)(93886005)(6306002)(99286004)(3480700004)(2900100001)(6246003)(8676002)(81156014)(236005)(54896002)(81166006)(8936002)(8656006)(2950100002)(606006)(6506007)(77096007)(7736002)(53546011)(26005)(105586002)(7416002)(86362001)(2906002)(74316002)(102836004)(6116002)(3846002)(59450400001)(316002)(42262002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0232; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3ixtazJxgrMgPLkr7MiDso2FZEy8iNh/QxaHK72sAG/WC5OgwmCAQwnoFlXLBENb3nKG5OHwTdTS7LeOIKp6Mw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR15MB07758F932FBB87047ACB9D9ACDFE0BY2PR15MB0775namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 701844ad-f59c-4726-3d9f-08d56c30b1a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 00:37:53.5700 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0232 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 05 Feb 2018 00:39:00 -0000 --_000_BY2PR15MB07758F932FBB87047ACB9D9ACDFE0BY2PR15MB0775namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable A network could carry whatever protocol it wished to, i.e. by wrapping any/= all packets on ingress to the network, and then un-wrapping when forwarding= to another network. This would allow a network to record and track whateve= r it wanted to without placing constraints on layers which should be above = it. If the network placed a sequence number on incoming packets, it could detec= t reordering across all flows. If it do so on a 5-tuple basis, it could det= ect reordering/duplication/loss across any 5-tuple. -=3DR ________________________________ From: Roni Even (A) Sent: Saturday, February 3, 2018 11:47:06 PM To: Roberto Peon; Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/= Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; Brian T= rammell; Christian Huitema; QUIC WG; Martin Thomson Subject: RE: Packet number encryption Hi, Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. RE- so you are saying that we can for example leverage RTP and define RTP= payload for QUIC that will carry QUIC packets, we will just need to resolv= e the MTU size. Roni From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon Sent: Saturday, February 03, 2018 8:38 PM To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; Brian T= rammell; Christian Huitema; QUIC WG; Martin Thomson Subject: Re: Packet number encryption Ossification: In the past tcp middleboxes expected in-order, monotonically increasing off= sets and tried to fix reordering before forwarding. This middlebox behavior= , predicated on observable flows, prevented deployment of things which woul= d have made tcp more efficient. This is the kind of non-theoretical ossification that drove the creation o= f QUIC in the first place. Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. Debugging: Debugging of flows can still happen for flows that wish to be debugged-- th= e QUIC connection's key material(s) can be shared manually and used by the = debugging tool. This is how one debugs http2, https, etc. already today. -=3DR -------- Original message -------- From: Piotr Galecki > Date: 2/2/18 7:00 PM (GMT-08:00) To: Jana Iyengar >, "Fossati, Thomas = (Nokia - GB/Cambridge, UK)" > Cc: Gorry Fairhust >, Eri= c Rescorla >, Christian Huitema >, "Eggert, Lars" >, Brian Trammell >, Mirja K=FChlewind >, QUIC WG >, = Martin Thomson > Subject: RE: Packet number encryption What is the group=92s proposal for allowing network monitoring tools to det= ect packet retransmission or packet reordering ? These metrics are pretty straightforward to measure for TCP flows. Tools like Wireshark can analyze packets and spot issues. How can the network tools perform this kind of measurements for QUIC flows = if PN field is encrypted? From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar Sent: Friday, February 02, 2018 9:31 PM To: Fossati, Thomas (Nokia - GB/Cambridge, UK) > Cc: Gorry Fairhust >; Eri= c Rescorla >; Mirja K=FChlewind >; Christian= Huitema >; Brian Trammell = >; Eggert, Lars >; QUIC WG >; Ma= rtin Thomson > Subject: Re: Packet number encryption A few points as I catch up on this thread. First, I'll remind folks that QUIC is an encrypted transport. I say this be= cause the cost of this operation is trivial in the context of encrypting ev= ery packet. The cost is borne at the servers and not at middleboxes, so the= additional crypto cost is basically trivial. Second, this simplifies and increases robustness of implementation. Avoidin= g random PN jumps, as Kazuho points out, makes special-casing of code unnec= essary. Special code that is exercised occasionally is a strong bug attract= or, and I would strongly argue for as few of those as possible in implement= ation. Third, yes, ossification is a real concern. A simple example: using increas= ing packet numbers as a signature for detecting QUIC. Even if you argue aga= inst this example, there are innovative ways in which ossification will hap= pen. This is based on a true story: We had no idea how GQUIC's flags field = could get ossified, the value that was being used commonly became used as a= signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper). There's a win here in terms of implementation complexity and several implem= enters have said so. There's a win in terms of ossification and our experie= nce says so. There's a potential loss of manageability, in being able to de= tect reordering. This is the trade-off, and I am still in favor of encrypti= ng packet numbers. On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) = > wrote: On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" on behalf of lars@netapp.com> wrote: > On 2018-1-31, at 10:52, Gorry Fairhurst > wrote: > > +1 - Simply: This *is* complicated and seems to add little. > > So as an implementor (chair hat off), this adds very little to the > overall complexity of the protocol. This doesn't sound great. It's a bit like saying that adding the Higgs mechanism to the standard model's lagrangian doesn't make it much more complicate :-) (*) More seriously though, I'd like to point out that it is not just about implementation complexity, it's also the energy cost per packet that is quite crucial. I haven't done the math but ISTM that bringing in another batch of non-optional crypto computation on a per packet basis is not going to move the needle in the right direction for stacks that run on low power (IoT). This is not a catastrophe - we have CoAP and a (D)TLS profile - but neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to bridge. (Sure, we have specified the behaviour of a similar box already, but it'd be really better if the extra translation logic could be avoided in the first place.) I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later profile QUIC for the IoT, which would be a bit unlucky. So the question is: would it be possible to make this property a configurable knob instead? (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-mod= el-equation --_000_BY2PR15MB07758F932FBB87047ACB9D9ACDFE0BY2PR15MB0775namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

A network could carry whatever pr= otocol it wished to, i.e. by wrapping any/all packets on ingress to the net= work, and then un-wrapping when forwarding to another network. Th= is would allow a network to record and track whatever it wanted to without placing constraints on layers which should b= e above it. 


If the network placed a sequence number on incoming packets, it could detec= t reordering across all flows. If it do so on a 5-tuple basis, it could det= ect reordering/duplication/loss across any 5-tuple.


-=3DR

From: Roni Even (A) <ron= i.even@huawei.com>
Sent: Saturday, February 3, 2018 11:47:06 PM
To: Roberto Peon; Piotr Galecki; Jana Iyengar; Fossati, Thomas (Noki= a - GB/Cambridge, UK)
Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; = Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson
Subject: RE: Packet number encryption
 

Hi,

Network monitoring:

Networks may always wrap the pack= et(s) they have received with whatever data they wish, and unwrap before fo= rwarding. This can allow any network to understand ordering,  loss, etc within its boundaries.

 

RE- so you are saying that we can= for example  leverage  RTP and define RTP payload for QUIC that = will carry QUIC packets, we will just need to resolve the MTU size.<= /p>

Roni

 

 

From: QUIC= [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon
Sent: Saturday, February 03, 2018 8:38 PM
To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambrid= ge, UK)
Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; = Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson
Subject: Re: Packet number encryption

 

Ossification:

In the past tcp middleboxes expec= ted in-order, monotonically increasing offsets and tried to fix reordering = before forwarding. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp= more efficient.

 

 This is the kind of non-the= oretical ossification that drove the creation of QUIC in the first place.

 

Network monitoring:

Networks may always wrap the pack= et(s) they have received with whatever data they wish, and unwrap before fo= rwarding. This can allow any network to understand ordering,  loss, etc within its boundaries.

 

Debugging:

Debugging of flows can still happ= en for flows that wish to be debugged-- the QUIC connection's key material(= s) can be shared manually and used by the debugging tool. This is how one debugs http2, https, etc. already today.

 

-=3DR

 

 

 

-------- Original message -------= -

From: Piotr Galecki <piotr_galecki@affirmednetwor= ks.com>

Date: 2/2/18 7:00 PM (GMT-08:00)

To: Jana Iyengar <jri@google.com>, "Fossati, Thomas (Nokia = - GB/Cambridge, UK)" <t= homas.fossati@nokia.com>

Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla &= lt;ekr@rtfm.com>, Christian Huitema <huitema@huitema.net>, &q= uot;Eggert, Lars" <lars@netapp.c= om>, Brian Trammell <ietf@tra= mmell.ch>, Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>, QUIC WG <quic@ietf.org>, Martin= Thomson <martin.thomson@gma= il.com>

Subject: RE: Packet number encryp= tion

 

What is the group=92s proposal for allowing networ= k monitoring tools to detect packet retransmission or packet reordering ?

These metrics are pretty straightforward to measur= e for TCP flows.

Tools like Wireshark can analyze packets and spot = issues.

How can the network tools perform this kind of mea= surements for QUIC flows if PN field is encrypted?

 

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Friday, February 02, 2018 9:31 PM
To: Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>
Cc: Gorry Fairhust <gorry= @erg.abdn.ac.uk>; Eric Rescorla <= ekr@rtfm.com>; Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Christian Huitema <huitema@huite= ma.net>; Brian Trammell <ietf= @trammell.ch>; Eggert, Lars <l= ars@netapp.com>; QUIC WG <quic@i= etf.org>; Martin Thomson <martin.thom= son@gmail.com>
Subject: Re: Packet number encryption

 

A few points as I catch up on this thread.

 

First, I'll remind folks that QUIC is an encrypted= transport. I say this because the cost of this operation is trivial in the= context of encrypting every packet. The cost is borne at the servers and n= ot at middleboxes, so the additional crypto cost is basically trivial.

 

Second, this simplifies and increases robustness o= f implementation. Avoiding random PN jumps, as Kazuho points out, makes spe= cial-casing of code unnecessary. Special code that is exercised occasionall= y is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation.

 

Third, yes, ossification is a real concern. A simp= le example: using increasing packet numbers as a signature for detecting QU= IC. Even if you argue against this example, there are innovative ways in wh= ich ossification will happen. This is based on a true story:  SIGCOMM QUIC paper).

 

There's a win here in terms of implementation comp= lexity and several implementers have said so. There's a win in terms of oss= ification and our experience says so. There's a potential loss of manageabi= lity, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet number= s.

 

On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (N= okia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:

On 31/01/2018, 10:0= 6, "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on behalf of lars@netapp.com> wrote:
> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> > +1 - Simply: This *is* complicated and seems to add little. >
> So as an implementor (chair hat off), this adds very little to the
> overall complexity of the protocol.

This doesn't sound great.  It's a bit like saying that adding the Higg= s
mechanism to the standard model's lagrangian doesn't make it much more
complicate :-)  (*)

More seriously though, I'd like to point out that it is not just about
implementation complexity, it's also the energy cost per packet that is
quite crucial.  I haven't done the math but ISTM that bringing in
another batch of non-optional crypto computation on a per packet basis
is not going to move the needle in the right direction for stacks that
run on low power (IoT).

This is not a catastrophe - we have CoAP and a (D)TLS profile - but
neither it's ideal, since cutting off the small things from the wider
ecosystem creates an artificial gap which then will need a middlebox to
bridge.  (Sure, we have specified the behaviour of a similar box
already, but it'd be really better if the extra translation logic could
be avoided in the first place.)

I guess what I'm saying is that PN encryption being a core mechanism
that can't be negotiated at handshake time reduces our ability to later
profile QUIC for the IoT, which would be a bit unlucky.

So the question is: would it be possible to make this property a
configurable knob instead?

(*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-e= quation

 

--_000_BY2PR15MB07758F932FBB87047ACB9D9ACDFE0BY2PR15MB0775namp_-- From nobody Sun Feb 4 16:43:22 2018 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 6869A1241F3 for ; Sun, 4 Feb 2018 16:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, 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 (1024-bit key) header.d=fb.com header.b=KAtgBBi8; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=V37++NEf 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 vR3ZD1pCboop for ; Sun, 4 Feb 2018 16:43:18 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 270B9120725 for ; Sun, 4 Feb 2018 16:43:18 -0800 (PST) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w150eDV3010591; Sun, 4 Feb 2018 16:42:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=q4oZqosFIwtaXCbpuoMf0GOfLTBdFbfo/g8bd0jm3rE=; b=KAtgBBi8zmCOxk9gtE5CWHTexC4vL4+RwxSvqkH7MuVRmv7TvFgCK1R1XQpdwhhHMQT7 uwoQRPaBwU6vQUQnyKRNUFxkjtxY3Z/vQkQwPkQ92YqKBLABOl2WjKkGl00XpEBUoyO1 /dJy+cLL/zAxk0uSEYYbp/qA1dR2RaLl4Xs= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fwbnj6pdh-2 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 04 Feb 2018 16:42:32 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.25) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 4 Feb 2018 19:41:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q4oZqosFIwtaXCbpuoMf0GOfLTBdFbfo/g8bd0jm3rE=; b=V37++NEfwTmHALJ/GvKjdxOgvoXCOMfKk/qZaKVYRC8TjnK2Uuz57scxH77DI9XwlL5Edq9DjPvlSgVXtbHxWjCmKU/TGaLK+TmmWIzLUMeSZ3xci+H7QhFx3FetgQbmG2NghMTEUWEw12/LEruVe1K4X82JEY0uj3a8sHIm4Rk= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0232.namprd15.prod.outlook.com (10.163.64.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 00:41:11 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 00:41:11 +0000 From: Roberto Peon To: "Lubashev, Igor" , "Roni Even (A)" , Piotr Galecki , Jana Iyengar , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" CC: Gorry Fairhust , Eric Rescorla , Christian Huitema , "Eggert, Lars" , Brian Trammell , =?Windows-1252?Q?Mirja_K=FChlewind?= , QUIC WG , Martin Thomson Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW3+HjM5RmHWDkij9J5s6UBSSaOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGB6AANx9AIAAn5KAgAB69NE= Date: Mon, 5 Feb 2018 00:41:11 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> , <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.234.190.115] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0232; 20:HWxgV93CE8Sw9fHbiGytnIUm7b6KKa0Xxl8UHo8LneQnb/5+/sQG2ck8Aiibt6cTbBUeb4XbhpPl0bnFTHLJsCsM9cvbAg93fZepU6EM5Mvv1Z2nnm+GrAiyUcgxvlssi9p4I99bpp/qVOEvjb7MWB95g1GBmBOrb6KGVsvxEu4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 67013884-2161-433e-7bf1-08d56c312787 x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0232; x-ms-traffictypediagnostic: BY2PR15MB0232: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(72170088055959)(192374486261705)(50582790962513)(82608151540597)(85827821059158)(67672495146484)(211936372134217)(179696456005106)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(11241501184)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR15MB0232; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0232; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39380400002)(346002)(39860400002)(376002)(11905935001)(199004)(189003)(377424004)(186003)(5660300001)(19627405001)(7116003)(25786009)(39060400002)(561944003)(55016002)(54906003)(66066001)(4326008)(110136005)(68736007)(33656002)(76176011)(106356001)(7696005)(3660700001)(97736004)(966005)(3280700002)(6606003)(4001150100001)(229853002)(6436002)(53936002)(478600001)(14454004)(9686003)(93886005)(6306002)(99286004)(3480700004)(2900100001)(6246003)(8676002)(81156014)(236005)(54896002)(81166006)(8936002)(8656006)(2950100002)(606006)(6506007)(77096007)(7736002)(53546011)(26005)(105586002)(7416002)(86362001)(2906002)(74316002)(102836004)(6116002)(3846002)(59450400001)(316002)(42262002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0232; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 5SOfXPHrlgC7/z4TS+I6pJC1DuE0YkfWLdSYTLEAXkr3nkGDd4ctuPg7uzVWWHjt5Ry55d1kZm7COuBOMiq8Mg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR15MB07754D83A1721F2BD742359BCDFE0BY2PR15MB0775namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 67013884-2161-433e-7bf1-08d56c312787 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 00:41:11.3774 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0232 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 05 Feb 2018 00:43:21 -0000 --_000_BY2PR15MB07754D83A1721F2BD742359BCDFE0BY2PR15MB0775namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Placing/consuming unnecessary bits into the protocol also may reduce bandwi= dth, even on LANs/intranets. Optional security tends to devolve to non-secure. -=3DR ________________________________ From: Lubashev, Igor Sent: Sunday, February 4, 2018 9:18:13 AM To: Roni Even (A); Roberto Peon; Piotr Galecki; Jana Iyengar; Fossati, Thom= as (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Christian Huitema; Eggert, Lars; Brian T= rammell; Mirja K=FChlewind; QUIC WG; Martin Thomson Subject: RE: Packet number encryption The need to troubleshoot networks (at a minimum, to detect packet loss and = reordering) is real. I would assume that every network would need to have = an ability to do so. Ability to quickly troubleshoot and fix networks is n= ot only =93nice=94 for the networks themselves, but it is also very benefic= ial to QUIC users. Having networks wrap and unwrap packets at their boundaries is a possibilit= y, though it has real costs and downsides. First, while networks could set= up such wrapping for UDP port 443 traffic, what about QUIC traffic using ot= her ports? Would networks need to wrap all UDP traffic? Second, this does= reduce MTU for end users, reducing available bandwidth. Third, this would= allow networks to only answer questions like: =93Is my network the culprit= of the problem?=94 instead of =93Is the problem in my network, upstream fr= om me, or downstream from me?=94. Would it be considered outrageous to suggest that packet number encryption = be an option negotiated during connection handshake? An end user client in= =93Privacy-Enhanced=94 mode would negotiate this, while end users not part= icularly concerned with connection migration linkability issues would leave= this off? - Igor From: Roni Even (A) [mailto:roni.even@huawei.com] Sent: Sunday, February 04, 2018 2:47 AM To: Roberto Peon ; Piotr Galecki ; Jana Iyengar ; Fossati, Thomas (Nokia - GB/Cambri= dge, UK) Cc: Gorry Fairhust ; Eric Rescorla ; Ch= ristian Huitema ; Eggert, Lars ; Bria= n Trammell ; Mirja K=FChlewind ; QUIC WG ; Martin Thomson Subject: RE: Packet number encryption Hi, Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. RE- so you are saying that we can for example leverage RTP and define RTP= payload for QUIC that will carry QUIC packets, we will just need to resolv= e the MTU size. Roni From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon Sent: Saturday, February 03, 2018 8:38 PM To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; Brian T= rammell; Christian Huitema; QUIC WG; Martin Thomson Subject: Re: Packet number encryption Ossification: In the past tcp middleboxes expected in-order, monotonically increasing off= sets and tried to fix reordering before forwarding. This middlebox behavior= , predicated on observable flows, prevented deployment of things which woul= d have made tcp more efficient. This is the kind of non-theoretical ossification that drove the creation o= f QUIC in the first place. Network monitoring: Networks may always wrap the packet(s) they have received with whatever dat= a they wish, and unwrap before forwarding. This can allow any network to un= derstand ordering, loss, etc within its boundaries. Debugging: Debugging of flows can still happen for flows that wish to be debugged-- th= e QUIC connection's key material(s) can be shared manually and used by the = debugging tool. This is how one debugs http2, https, etc. already today. -=3DR -------- Original message -------- From: Piotr Galecki > Date: 2/2/18 7:00 PM (GMT-08:00) To: Jana Iyengar >, "Fossati, Thomas = (Nokia - GB/Cambridge, UK)" > Cc: Gorry Fairhust >, Eri= c Rescorla >, Christian Huitema >, "Eggert, Lars" >, Brian Trammell >, Mirja K=FChlewind >, QUIC WG >, = Martin Thomson > Subject: RE: Packet number encryption What is the group=92s proposal for allowing network monitoring tools to det= ect packet retransmission or packet reordering ? These metrics are pretty straightforward to measure for TCP flows. Tools like Wireshark can analyze packets and spot issues. How can the network tools perform this kind of measurements for QUIC flows = if PN field is encrypted? From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar Sent: Friday, February 02, 2018 9:31 PM To: Fossati, Thomas (Nokia - GB/Cambridge, UK) > Cc: Gorry Fairhust >; Eri= c Rescorla >; Mirja K=FChlewind >; Christian= Huitema >; Brian Trammell = >; Eggert, Lars >; QUIC WG >; Ma= rtin Thomson > Subject: Re: Packet number encryption A few points as I catch up on this thread. First, I'll remind folks that QUIC is an encrypted transport. I say this be= cause the cost of this operation is trivial in the context of encrypting ev= ery packet. The cost is borne at the servers and not at middleboxes, so the= additional crypto cost is basically trivial. Second, this simplifies and increases robustness of implementation. Avoidin= g random PN jumps, as Kazuho points out, makes special-casing of code unnec= essary. Special code that is exercised occasionally is a strong bug attract= or, and I would strongly argue for as few of those as possible in implement= ation. Third, yes, ossification is a real concern. A simple example: using increas= ing packet numbers as a signature for detecting QUIC. Even if you argue aga= inst this example, there are innovative ways in which ossification will hap= pen. This is based on a true story: We had no idea how GQUIC's flags field = could get ossified, the value that was being used commonly became used as a= signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper). There's a win here in terms of implementation complexity and several implem= enters have said so. There's a win in terms of ossification and our experie= nce says so. There's a potential loss of manageability, in being able to de= tect reordering. This is the trade-off, and I am still in favor of encrypti= ng packet numbers. On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) = > wrote: On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" on behalf of lars@netapp.com> wrote: > On 2018-1-31, at 10:52, Gorry Fairhurst > wrote: > > +1 - Simply: This *is* complicated and seems to add little. > > So as an implementor (chair hat off), this adds very little to the > overall complexity of the protocol. This doesn't sound great. It's a bit like saying that adding the Higgs mechanism to the standard model's lagrangian doesn't make it much more complicate :-) (*) More seriously though, I'd like to point out that it is not just about implementation complexity, it's also the energy cost per packet that is quite crucial. I haven't done the math but ISTM that bringing in another batch of non-optional crypto computation on a per packet basis is not going to move the needle in the right direction for stacks that run on low power (IoT). This is not a catastrophe - we have CoAP and a (D)TLS profile - but neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to bridge. (Sure, we have specified the behaviour of a similar box already, but it'd be really better if the extra translation logic could be avoided in the first place.) I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later profile QUIC for the IoT, which would be a bit unlucky. So the question is: would it be possible to make this property a configurable knob instead? (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-mod= el-equation --_000_BY2PR15MB07754D83A1721F2BD742359BCDFE0BY2PR15MB0775namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Placing/consuming unnecessary bit= s into the protocol also may reduce bandwidth, even on LANs/intra= nets.

Optional security tends to devolve to non-secure.

-=3DR

From: Lubashev, Igor <il= ubashe@akamai.com>
Sent: Sunday, February 4, 2018 9:18:13 AM
To: Roni Even (A); Roberto Peon; Piotr Galecki; Jana Iyengar; Fossat= i, Thomas (Nokia - GB/Cambridge, UK)
Cc: Gorry Fairhust; Eric Rescorla; Christian Huitema; Eggert, Lars; = Brian Trammell; Mirja K=FChlewind; QUIC WG; Martin Thomson
Subject: RE: Packet number encryption
 

The need to troubleshoot networks (at a minimum, t= o detect packet loss and reordering) is real.  I would assume that eve= ry network would need to have an ability to do so.  Ability to quickly= troubleshoot and fix networks is not only =93nice=94 for the networks themselves, but it is also very beneficial to QUIC users.=

 

Having networks wrap and unwrap packets at their b= oundaries is a possibility, though it has real costs and downsides.  F= irst, while networks could setup such wrapping for UDP port 443 traffic, wh= at about QUIC traffic using other ports?  Would networks need to wrap all UDP traffic?  Second, this does reduc= e MTU for end users, reducing available bandwidth.  Third, this would = allow networks to only answer questions like: =93Is my network the culprit = of the problem?=94 instead of =93Is the problem in my network, upstream from me, or downstream from me?=94.

 

Would it be considered outrageous to suggest that = packet number encryption be an option negotiated during connection handshak= e?  An end user client in =93Privacy-Enhanced=94 mode would negotiate = this, while end users not particularly concerned with connection migration linkability issues would leave this off?

 

- Igor

 

 

From: Roni Even (A) [mailto:roni.even@huawe= i.com]
Sent: Sunday, February 04, 2018 2:47 AM
To: Roberto Peon <fenix@fb.com>; Piotr Galecki <piotr_galec= ki@affirmednetworks.com>; Jana Iyengar <jri@google.com>; Fossati, = Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>
Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>; Eric Rescorla <e= kr@rtfm.com>; Christian Huitema <huitema@huitema.net>; Eggert, Lar= s <lars@netapp.com>; Brian Trammell <ietf@trammell.ch>; Mirja K= =FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; QUIC WG <quic@ietf.o= rg>; Martin Thomson <martin.thomson@gmail.com>
Subject: RE: Packet number encryption

 

Hi,

Network monitoring:

Networks may always wrap the packet(s) they h= ave received with whatever data they wish, and unwrap before forwarding. Th= is can allow any network to understand ordering,  loss, etc within its boundaries.

 

RE- so you are saying that we can for example=  leverage  RTP and define RTP payload for QUIC that will carry Q= UIC packets, we will just need to resolve the MTU size.

Roni

 

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon
Sent: Saturday, February 03, 2018 8:38 PM
To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambrid= ge, UK)
Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; = Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson
Subject: Re: Packet number encryption

 

Ossification:

In the past tcp middleboxes expected in-order= , monotonically increasing offsets and tried to fix reordering before forwa= rding. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp= more efficient.

 

 This is the kind of non-theoretical oss= ification that drove the creation of QUIC in the first place.

 

Network monitoring:

Networks may always wrap the packet(s) they h= ave received with whatever data they wish, and unwrap before forwarding. Th= is can allow any network to understand ordering,  loss, etc within its boundaries.

 

Debugging:

Debugging of flows can still happen for flows= that wish to be debugged-- the QUIC connection's key material(s) can be sh= ared manually and used by the debugging tool. This is how one debugs http2, https, etc. already today.

 

-=3DR

 

 

 

-------- Original message --------

From: Piotr Galecki <piotr_galecki@affirmednetworks.com>

Date: 2/2/18 7:00 PM (GMT-08:00)

To: Jana Iyengar <jri@google.com>, "Fossati, Thomas (Nokia - GB/Cambrid= ge, UK)" <thomas.fossat= i@nokia.com>

Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric Rescorla <ekr@rtfm.com>, Christian Huitema <huitema@huitema.net>, &q= uot;Eggert, Lars" <lars@netapp.c= om>, Brian Trammell <ietf@tra= mmell.ch>, Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>, QUIC WG <quic@ietf.org>, Martin= Thomson <martin.thomson@gma= il.com>

Subject: RE: Packet number encryption

 

What is the group=92s proposal for allowing networ= k monitoring tools to detect packet retransmission or packet reordering ?

These metrics are pretty straightforward to measur= e for TCP flows.

Tools like Wireshark can analyze packets and spot = issues.

How can the network tools perform this kind of mea= surements for QUIC flows if PN field is encrypted?

 

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Friday, February 02, 2018 9:31 PM
To: Fossati, Thomas (Nokia - GB/Cambridge, UK) <thomas.fossati@nokia.com>
Cc: Gorry Fairhust <gorry= @erg.abdn.ac.uk>; Eric Rescorla <= ekr@rtfm.com>; Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Christian Huitema <huitema@huite= ma.net>; Brian Trammell <ietf= @trammell.ch>; Eggert, Lars <l= ars@netapp.com>; QUIC WG <quic@i= etf.org>; Martin Thomson <martin.thom= son@gmail.com>
Subject: Re: Packet number encryption

 

A few points as I catch up on this thread.

 

First, I'll remind folks that QUIC is an encrypted= transport. I say this because the cost of this operation is trivial in the= context of encrypting every packet. The cost is borne at the servers and n= ot at middleboxes, so the additional crypto cost is basically trivial.

 

Second, this simplifies and increases robustness o= f implementation. Avoiding random PN jumps, as Kazuho points out, makes spe= cial-casing of code unnecessary. Special code that is exercised occasionall= y is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation.

 

Third, yes, ossification is a real concern. A simp= le example: using increasing packet numbers as a signature for detecting QU= IC. Even if you argue against this example, there are innovative ways in wh= ich ossification will happen. This is based on a true story: We had no = idea how GQUIC's flags field could get ossified, the value that was being u= sed commonly became used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper).

 

There's a win here in terms of implementation comp= lexity and several implementers have said so. There's a win in terms of oss= ification and our experience says so. There's a potential loss of manageabi= lity, in being able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet number= s.

 

On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (N= okia - GB/Cambridge, UK) <thomas.fossati@nokia.com> wrote:

On 31/01/2018, 10:0= 6, "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on behalf of lars@netapp.com> wrote:
> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> > +1 - Simply: This *is* complicated and seems to add little. >
> So as an implementor (chair hat off), this adds very little to the
> overall complexity of the protocol.

This doesn't sound great.  It's a bit like saying that adding the Higg= s
mechanism to the standard model's lagrangian doesn't make it much more
complicate :-)  (*)

More seriously though, I'd like to point out that it is not just about
implementation complexity, it's also the energy cost per packet that is
quite crucial.  I haven't done the math but ISTM that bringing in
another batch of non-optional crypto computation on a per packet basis
is not going to move the needle in the right direction for stacks that
run on low power (IoT).

This is not a catastrophe - we have CoAP and a (D)TLS profile - but
neither it's ideal, since cutting off the small things from the wider
ecosystem creates an artificial gap which then will need a middlebox to
bridge.  (Sure, we have specified the behaviour of a similar box
already, but it'd be really better if the extra translation logic could
be avoided in the first place.)

I guess what I'm saying is that PN encryption being a core mechanism
that can't be negotiated at handshake time reduces our ability to later
profile QUIC for the IoT, which would be a bit unlucky.

So the question is: would it be possible to make this property a
configurable knob instead?

(*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-e= quation

 

--_000_BY2PR15MB07754D83A1721F2BD742359BCDFE0BY2PR15MB0775namp_-- From nobody Sun Feb 4 19:51:31 2018 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 CEAAD126BFD for ; Sun, 4 Feb 2018 19:51:29 -0800 (PST) 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, 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 grh1ehjjZWJI for ; Sun, 4 Feb 2018 19:51:28 -0800 (PST) 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 1C8EB126B7E for ; Sun, 4 Feb 2018 19:51:27 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w153kg42010734; Mon, 5 Feb 2018 03:51:24 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=rdUYPMiaTBS5d/vJSUaHPRKvGgn10X4IOo+ifhFp0sE=; b=etl8QYxkUkW67pj0g9/JYcfoQjFWOxHjfaPvuqMxvNCSfpPxVDd2hlt+h8XgoXAIiDCB XIXVdissGBixwvQHb0sq7vpTRdC0npGnhuutB/BAm2XQItgC+kuYQ12nOeYBjW58C4PD /J1d6FG7yc5Pb//tXcaelXn/eB+eXoYA0zecSKGWcD9XKEV+00U9V33RMJEcsAJ5S0M/ vL6O9z1rK1wHDfwcJVgEnq4147IUVQ6J1k2WwfcErTJK4ZX44Ptnq2b4fl7beeRaLCq+ gg2/AFxaqP/oA+IxVrrHESZaxoBNJDTflJZI+UAsm9rsGTajePeenWl+9X8jvYF69wZI TQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2fw2tv5499-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Feb 2018 03:51:24 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w153p4da019248; Sun, 4 Feb 2018 22:51:23 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fw99yvcuc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 04 Feb 2018 22:51:23 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sun, 4 Feb 2018 22:51:22 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Sun, 4 Feb 2018 22:51:22 -0500 From: "Salz, Rich" To: Roberto Peon , "Lubashev, Igor" CC: QUIC WG Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31Be9MxlVQxEqrVhXIOG6b4KOM1RYAgABeoICAAAgVAIAAd3KAgAA8YgCAACPDAIAAAicAgAOBloCAALfcgIAACBoAgAEGFwCAANx+AIAAn5GAgAB7xICAADUigA== Date: Mon, 5 Feb 2018 03:51:21 +0000 Message-ID: <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.187] Content-Type: multipart/alternative; boundary="_000_2CD9DC43D69B43F08474DFE798850A52akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=810 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050049 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-04_07:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=759 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050049 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, 05 Feb 2018 03:51:30 -0000 --_000_2CD9DC43D69B43F08474DFE798850A52akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBPcHRpb25hbCBzZWN1cml0eSB0ZW5kcyB0byBkZXZvbHZlIHRvIG5vbi1zZWN1cmUuDQoNCg0K DQpUaGF04oCZcyBhIGdyZWF0IGFwaG9yaXNtLiAgQW5kIHNhZGx5IGFsbCB0b28gdHJ1ZS4NCg== --_000_2CD9DC43D69B43F08474DFE798850A52akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlw ZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2Vk DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAueG1zb25vcm1hbCwgbGkueG1zb25vcm1hbCwg ZGl2Lnhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6eF9tc29ub3JtYWw7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLnhtc29hY2V0YXRlLCBsaS54bXNvYWNldGF0 ZSwgZGl2Lnhtc29hY2V0YXRlDQoJe21zby1zdHlsZS1uYW1lOnhfbXNvYWNldGF0ZTsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpwLnhtc29saXN0cGFyYWdyYXBoLCBsaS54 bXNvbGlzdHBhcmFncmFwaCwgZGl2Lnhtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1l OnhfbXNvbGlzdHBhcmFncmFwaDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KcC54bXNvbm9ybWFsMCwgbGkueG1zb25vcm1hbDAsIGRpdi54bXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTp4X21zb25vcm1hbDA7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpwLnhtc29ub3JtYWwwMCwgbGkueG1zb25vcm1hbDAwLCBkaXYueG1z b25vcm1hbDAwDQoJe21zby1zdHlsZS1uYW1lOnhfbXNvbm9ybWFsMDA7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLnhtc29jaHBkZWZhdWx0LCBsaS54bXNvY2hwZGVm YXVsdCwgZGl2Lnhtc29jaHBkZWZhdWx0DQoJe21zby1zdHlsZS1uYW1lOnhfbXNvY2hwZGVmYXVs dDsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ueGJhbGxvb250 ZXh0Y2hhcg0KCXttc28tc3R5bGUtbmFtZTp4X2JhbGxvb250ZXh0Y2hhcjsNCglmb250LWZhbWls eToiVGFob21hIixzYW5zLXNlcmlmO30NCnNwYW4ueGVtYWlsc3R5bGUxOA0KCXttc28tc3R5bGUt bmFtZTp4X2VtYWlsc3R5bGUxODsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ueGVtYWlsc3R5bGUyMw0KCXttc28tc3R5bGUtbmFt ZTp4X2VtYWlsc3R5bGUyMzsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjojMUY0OTdEO30NCnNwYW4ueGVtYWlsc3R5bGUyNQ0KCXttc28tc3R5bGUtbmFtZTp4X2Vt YWlsc3R5bGUyNTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv LXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFs O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj4mZ3Q7IE9wdGlvbmFsIHNlY3VyaXR5IHRlbmRzIHRvIGRldm9sdmUgdG8gbm9uLXNl Y3VyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJ4bXNvbm9ybWFsIj5UaGF04oCZcyBhIGdyZWF0IGFwaG9yaXNtLiZuYnNwOyBBbmQgc2Fk bHkgYWxsIHRvbyB0cnVlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2CD9DC43D69B43F08474DFE798850A52akamaicom_-- From nobody Sun Feb 4 20:34:43 2018 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 B6402126DED for ; Sun, 4 Feb 2018 20:34:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 ATajxbXVZDt5 for ; Sun, 4 Feb 2018 20:34:39 -0800 (PST) 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 92D67126CD6 for ; Sun, 4 Feb 2018 20:34:39 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id v196so17511958ywc.6 for ; Sun, 04 Feb 2018 20:34:39 -0800 (PST) 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=C8dpgAAzCmeNNyjvNu9xVts1vYoXSx5sqddSagf1SWQ=; b=Nr5rNlIiOpQZks+iyGfDBD/W4WmtDfCYgVOLk+2WH8a8uKq3QLUnkTAsa2b5im/zGt 2YksNFEvoi6i/CuOC1IGGel42Fvw6Y1nhiRQ/knGGwvJB+bQ55L38hxG1hbbrvg6bcVU XdjAfGUNjduXmyitKIrPmMC4fsg+POv4+VhQSxO4r61j+PcWe9luKH/hgGu1C6q1/UIg RjIING6JGwxk0/105gLp+sTDIAmNYEsM1xw9ijWYriIALpANOOEnR9U04iZQepSAS37n iv2AA/D/MRtz91DhNPV7QREEJbOc5ZDYHnGlqdPEYfj36c3A8tBcRst5bJlsSDxKbFvY tf0w== 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=C8dpgAAzCmeNNyjvNu9xVts1vYoXSx5sqddSagf1SWQ=; b=SuUX2bRRuEbgPFaZtWMxyE3RxZHl6uldtwsMjudhYUfbdmPgKufvU3B4N4p4p0RUJM oK6hRgg2WqwA28RT3x+rd3rGfjSm6Io+t/Nwlgg7GRg91fEe++8hTVbkbL7aOKoWNlE8 26w7/6MICbanHLB+rapZHSKLjN1gOzrWgAu+Q37Hjfkk7Lrw9TTw1+GAnRsi5nasxZiK g6gmrM7abW/CfdZic1NP3gQlVxusmJMCfZUq2aJ3zvUDdn1OU4mhO73SEQ6pXC7Ro0yt SzTpHFOEh8xzkVjMlapmahfX/3GGabXPcTEgReMk7HtEc8SciqCigi3y89nCP22iXypa zctw== X-Gm-Message-State: AKwxytdw/FBrlNUCNO05mtITBR1Z2dIn6Q1/HurnmiyA9+LpWhaaOu6w o96T+kC6YF71E1RYA9Adi2THev/2+P54nxXiqi0CzQ== X-Google-Smtp-Source: AH8x227ZZxByu86DhYBU+1u57XsTzF/Qeupad4SnQ/1yAx/yHwmsUKaw33MTykX6y+iIpb6RodW7LWgrW7fimuOEZYg= X-Received: by 10.129.112.207 with SMTP id l198mr32084315ywc.139.1517805278251; Sun, 04 Feb 2018 20:34:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Sun, 4 Feb 2018 20:34:37 -0800 (PST) In-Reply-To: <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> From: Jana Iyengar Date: Sun, 4 Feb 2018 20:34:37 -0800 Message-ID: Subject: Re: Packet number encryption To: "Salz, Rich" Cc: Roberto Peon , "Lubashev, Igor" , QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0b14847361ee05646f94ea" 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, 05 Feb 2018 04:34:42 -0000 --94eb2c0b14847361ee05646f94ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Privacy-protection can't be a user choice, for the reasons others have noted on this thread. That said, my primary argument is for encryption to avoid ossification. Not that it matters now, but I'll note that much of GQUIC's original motivation for encrypting headers was to avoid ossification. I'll reiterate that fields we expose will get ossified and there are long-term ecosystem effects to this. Let me illustrate this with precisely the packet number field. Middleboxes commonly assume that a TCP flow can only handle packets in-order. This assumption comes from the fact that TCP implementations get poor performance when packets are reordered. This was definitely true for implementations of TCP, but that is TCP's problem, not the network's. However, almost all load-balancers I know of now will pin all packets within a TCP flow to one path, leading to sub-optimal performance in the network, and destroying incentives for the endpoints to deploy reordering-resilient TCP implementations (even though there are plenty of ways of doing this.) Exposing QUIC's packet number field (as any field) is likely to have similar consequences and a similar ecosystem arc. On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: > > Optional security tends to devolve to non-secure. > > > > That=E2=80=99s a great aphorism. And sadly all too true. > --94eb2c0b14847361ee05646f94ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Privacy-protection can't be a user choice, for the rea= sons others have noted on this thread.=C2=A0

That said, my primary = argument is for encryption to avoid ossification. Not that it matters now, = but I'll note that much of GQUIC's original motivation for encrypti= ng headers was to avoid ossification.

I'll rei= terate that fields we expose will get ossified and there are long-term ecos= ystem effects to this. Let me illustrate this with precisely the packet num= ber field. Middleboxes commonly assume that a TCP flow can only handle pack= ets in-order. This assumption comes from the fact that TCP implementations = get poor performance when packets are reordered. This was definitely true f= or implementations of TCP, but that is TCP's problem, not the network&#= 39;s. However, almost all load-balancers I know of now will pin all packets= within a TCP flow to one path, leading to sub-optimal performance in the n= etwork, and destroying incentives for the endpoints to deploy reordering-re= silient TCP implementations (even though there are plenty of ways of doing = this.)

Exposing QUIC's packet number field (as= any field) is likely to have similar consequences and a similar ecosystem = arc.


On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich = <rsalz@akamai.com<= /a>> wrote:

> Optional security tend= s to devolve to non-secure.

=C2=A0

That=E2=80=99s a great aphoris= m.=C2=A0 And sadly all too true.


--94eb2c0b14847361ee05646f94ea-- From nobody Sun Feb 4 20:58:31 2018 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 EDC84126CBF for ; Sun, 4 Feb 2018 20:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, HTTPS_HTTP_MISMATCH=1.989, 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 bEI3qgB8FMPZ for ; Sun, 4 Feb 2018 20:58:25 -0800 (PST) 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 EF21D1205D3 for ; Sun, 4 Feb 2018 20:58:24 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id b21so23220293wme.4 for ; Sun, 04 Feb 2018 20:58:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-language:thread-index; bh=LQQvV+kNw8Gtj0ve9EydIljRRy0mw884b0psVsX4PL8=; b=We5xv1KFKvr6ELanmRnguB/UvXUtRpWQMgXub97murgrj9218p9vqYDQEFeO0e5fNc 1J1xnoPHkMoprb5Yjro+BoEvNzAQiZivHpeocmJy+Df+5nFZT3rhkQ3kG+/4vReFsujT Ur/ltiIU9VgyWtfZbptFoR2PLnhF1c/bjG8rarWDjsi9x1T8rYdyNBY76dJnJ4gGpm8E 0AiDnYg877h3Erqi3kPQt94ZiTTW6w3zNQd4ovfUXy1o7bE+8c7T5iDiwiP+ZmaNaos6 dxebNG85q42ZppEsnZ982A8PRKuwaG0MLoW8SnjiTkkcupQfk6/VqUr4Sk9vi2584uv5 YPWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=LQQvV+kNw8Gtj0ve9EydIljRRy0mw884b0psVsX4PL8=; b=LChZEn4QW+dOSxr3vUh01kw8UzB4lfIpzIIL/225P4UeI3ztiKhhhHOuM4+91oDwBt fxfgAV7LOlK1QkSXsPW1hpOvjtiEWt/fpq8rS/S0Bvgz6yE7ejQeLDwpKrnweYmAbWFV 8dCpZL4T9Q6BNurm5kuARGL4zT2M3BneF2Q1qLrDIBcwRkcIhupRbVF9lBoYEjKtHAzM zOU1oBwgMAHILlm3wBkNgtXj7C8X+4ibkcWRDJUvY5Hf4xr2vHMV3CyVmnLQkthpYoR1 Xf2hwj4HYLJfQ2fZHWGIJsl/1JcqmEYzKgK07M0QXEAQp9qWuxpyCTFJ/qqDZVvrtXWu dPHg== X-Gm-Message-State: AKwxytfm2eg6de9N8uzccDvfg5cYwK9akGdnskNPHFDWcL2/csiHDtJR /+DdEL2Tf5JC0sXt7qSSoQc= X-Google-Smtp-Source: AH8x226gmLqsb9fbiT8b/Z8UONpwWbSrBxZPnq1Xf40ZIv2dLbNMCOpY0ihsl1B/eJ6pCRA1PabARQ== X-Received: by 10.28.32.15 with SMTP id g15mr31661275wmg.22.1517806703352; Sun, 04 Feb 2018 20:58:23 -0800 (PST) Received: from RoniPC (bzq-79-183-153-245.red.bezeqint.net. [79.183.153.245]) by smtp.gmail.com with ESMTPSA id q131sm9235234wmg.18.2018.02.04.20.58.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 04 Feb 2018 20:58:21 -0800 (PST) From: "Roni Even" To: "'Roberto Peon'" , "'Roni Even \(A\)'" , "'Piotr Galecki'" , "'Jana Iyengar'" , "'Fossati, Thomas \(Nokia - GB/Cambridge, UK\)'" Cc: "'Gorry Fairhust'" , "'Eric Rescorla'" , "'Christian Huitema'" , "'Eggert, Lars'" , "'Brian Trammell'" , =?iso-8859-1?Q?'Mirja_K=FChlewind'?= , "'QUIC WG'" , "'Martin Thomson'" References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> , <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> , <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Subject: RE: Packet number encryption Date: Mon, 5 Feb 2018 06:58:17 +0200 Message-ID: <00f301d39e3d$f15bdf40$d4139dc0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F4_01D39E4E.B4E6F930" X-Mailer: Microsoft Outlook 14.0 Content-Language: he Thread-Index: AQGQ530rNkaVCPfLZBKkq0r1tERDAQJoUcKLAOqrdnUByCTDvwIyPa6oAhcWTWcBH9bDhAGpm2h4Ai0m8V0BYzTSYQJi/trAAYuplSEAg9HiIAJKr5A5o2bQ+lA= 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, 05 Feb 2018 04:58:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F4_01D39E4E.B4E6F930 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does not it mean that the network need to identify packets that are = from the same quic connection to make such wrapping? Roni =20 From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon Sent: Monday, February 05, 2018 2:38 AM To: Roni Even (A); Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Christian Huitema; Eggert, Lars; = Brian Trammell; Mirja K=FChlewind; QUIC WG; Martin Thomson Subject: Re: Packet number encryption =20 A network could carry whatever protocol it wished to, i.e. by wrapping any/all packets on ingress to the network, and then un-wrapping when forwarding to another network. This would allow a network to record and track whatever it wanted to without placing constraints on layers which should be above it.=20 If the network placed a sequence number on incoming packets, it could = detect reordering across all flows. If it do so on a 5-tuple basis, it could = detect reordering/duplication/loss across any 5-tuple. =20 -=3DR _____ =20 From: Roni Even (A) Sent: Saturday, February 3, 2018 11:47:06 PM To: Roberto Peon; Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK) Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; = Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson Subject: RE: Packet number encryption=20 =20 Hi, Network monitoring: Networks may always wrap the packet(s) they have received with whatever = data they wish, and unwrap before forwarding. This can allow any network to understand ordering, loss, etc within its boundaries. =20 RE- so you are saying that we can for example leverage RTP and define = RTP payload for QUIC that will carry QUIC packets, we will just need to = resolve the MTU size. Roni =20 =20 From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon Sent: Saturday, February 03, 2018 8:38 PM To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, = UK) Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; = Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson Subject: Re: Packet number encryption =20 Ossification: In the past tcp middleboxes expected in-order, monotonically increasing offsets and tried to fix reordering before forwarding. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp more efficient. =20 This is the kind of non-theoretical ossification that drove the = creation of QUIC in the first place. =20 Network monitoring: Networks may always wrap the packet(s) they have received with whatever = data they wish, and unwrap before forwarding. This can allow any network to understand ordering, loss, etc within its boundaries. =20 Debugging: Debugging of flows can still happen for flows that wish to be debugged-- = the QUIC connection's key material(s) can be shared manually and used by the debugging tool. This is how one debugs http2, https, etc. already today. =20 -=3DR =20 =20 =20 -------- Original message -------- From: Piotr Galecki =20 Date: 2/2/18 7:00 PM (GMT-08:00)=20 To: Jana Iyengar , "Fossati, Thomas (Nokia - = GB/Cambridge, UK)" =20 Cc: Gorry Fairhust , Eric Rescorla , Christian Huitema , "Eggert, Lars" = , Brian Trammell , Mirja K=FChlewind , QUIC WG , Martin = Thomson =20 Subject: RE: Packet number encryption=20 =20 What is the group=92s proposal for allowing network monitoring tools to = detect packet retransmission or packet reordering ? These metrics are pretty straightforward to measure for TCP flows. Tools like Wireshark can analyze packets and spot issues. How can the network tools perform this kind of measurements for QUIC = flows if PN field is encrypted? =20 =20 From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar Sent: Friday, February 02, 2018 9:31 PM To: Fossati, Thomas (Nokia - GB/Cambridge, UK) = Cc: Gorry Fairhust ; Eric Rescorla ; Mirja K=FChlewind ; Christian Huitema ; Brian Trammell ; Eggert, Lars ; QUIC WG ; Martin Thomson Subject: Re: Packet number encryption =20 A few points as I catch up on this thread. =20 First, I'll remind folks that QUIC is an encrypted transport. I say this because the cost of this operation is trivial in the context of = encrypting every packet. The cost is borne at the servers and not at middleboxes, = so the additional crypto cost is basically trivial. =20 Second, this simplifies and increases robustness of implementation. = Avoiding random PN jumps, as Kazuho points out, makes special-casing of code unnecessary. Special code that is exercised occasionally is a strong bug attractor, and I would strongly argue for as few of those as possible in implementation. =20 Third, yes, ossification is a real concern. A simple example: using increasing packet numbers as a signature for detecting QUIC. Even if you argue against this example, there are innovative ways in which = ossification will happen. This is based on a true story: We had no idea how GQUIC's = flags field could get ossified, the value that was being used commonly became = used as a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC = paper ). =20 There's a win here in terms of implementation complexity and several implementers have said so. There's a win in terms of ossification and = our experience says so. There's a potential loss of manageability, in being = able to detect reordering. This is the trade-off, and I am still in favor of encrypting packet numbers. =20 On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, = UK) wrote: On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" wrote: > On 2018-1-31, at 10:52, Gorry Fairhurst wrote: > > +1 - Simply: This *is* complicated and seems to add little. > > So as an implementor (chair hat off), this adds very little to the > overall complexity of the protocol. This doesn't sound great. It's a bit like saying that adding the Higgs mechanism to the standard model's lagrangian doesn't make it much more complicate :-) (*) More seriously though, I'd like to point out that it is not just about implementation complexity, it's also the energy cost per packet that is quite crucial. I haven't done the math but ISTM that bringing in another batch of non-optional crypto computation on a per packet basis is not going to move the needle in the right direction for stacks that run on low power (IoT). This is not a catastrophe - we have CoAP and a (D)TLS profile - but neither it's ideal, since cutting off the small things from the wider ecosystem creates an artificial gap which then will need a middlebox to bridge. (Sure, we have specified the behaviour of a similar box already, but it'd be really better if the extra translation logic could be avoided in the first place.) I guess what I'm saying is that PN encryption being a core mechanism that can't be negotiated at handshake time reduces our ability to later profile QUIC for the IoT, which would be a bit unlucky. So the question is: would it be possible to make this property a configurable knob instead? (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-model= -eq uation =20 =20 ------=_NextPart_000_00F4_01D39E4E.B4E6F930 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Does not it mean that the network need to identify packets =A0that = are from the same quic connection to make such = wrapping?

Roni

 

From:= = QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto = Peon
Sent: Monday, February 05, 2018 2:38 AM
To: = Roni Even (A); Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - = GB/Cambridge, UK)
Cc: Gorry Fairhust; Eric Rescorla; Christian = Huitema; Eggert, Lars; Brian Trammell; Mirja K=FChlewind; QUIC WG; = Martin Thomson
Subject: Re: Packet number = encryption

 

A network could = carry whatever protocol it wished to, i.e. by wrapping any/all packets = on ingress to the network, and then un-wrapping when = forwarding to another network. This would allow a network to record and = track whatever it wanted to without placing constraints on layers which = should be above it. 


If the = network placed a sequence number on incoming packets, it could detect = reordering across all flows. If it do so on a 5-tuple basis, it could = detect reordering/duplication/loss across any = 5-tuple.

 

-=3DR=

From: Roni Even (A) <roni.even@huawei.com>
Sent: Saturday, = February 3, 2018 11:47:06 PM
To: Roberto Peon; Piotr Galecki; = Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, UK)
Cc: = Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; Eggert, Lars; Brian = Trammell; Christian Huitema; QUIC WG; Martin Thomson
Subject: = RE: Packet number encryption

 

Hi,

Network = monitoring:

Networks may always wrap the packet(s) they have = received with whatever data they wish, and unwrap before forwarding. = This can allow any network to understand ordering,  loss, etc = within its boundaries.

 

RE- so = you are saying that we can for example  leverage  RTP and = define RTP payload for QUIC that will carry QUIC packets, we will just = need to resolve the MTU size.

Roni

 

 

From:= = QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto = Peon
Sent: Saturday, February 03, 2018 8:38 PM
To: = Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - GB/Cambridge, = UK)
Cc: Gorry Fairhust; Eric Rescorla; Mirja K=FChlewind; = Eggert, Lars; Brian Trammell; Christian Huitema; QUIC WG; Martin = Thomson
Subject: Re: Packet number = encryption

 

Ossification:

In the past tcp middleboxes expected in-order, = monotonically increasing offsets and tried to fix reordering before = forwarding. This middlebox behavior, predicated on observable flows, = prevented deployment of things which would have made tcp more = efficient.

 

 This is the kind of non-theoretical = ossification that drove the creation of QUIC in the first = place.

 

Network = monitoring:

Networks may always wrap the packet(s) they have = received with whatever data they wish, and unwrap before forwarding. = This can allow any network to understand ordering,  loss, etc = within its boundaries.

 

Debugging:

Debugging of flows can still happen for flows that = wish to be debugged-- the QUIC connection's key material(s) can be = shared manually and used by the debugging tool. This is how one debugs = http2, https, etc. already today.

 

-=3DR

 

 

 

-------- Original message = --------

Date: 2/2/18 7:00 PM (GMT-08:00) =

To: = Jana Iyengar <jri@google.com>, "Fossati, = Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>=

Cc: = Gorry Fairhust <gorry@erg.abdn.ac.uk>, Eric = Rescorla <ekr@rtfm.com>, = Christian Huitema <huitema@huitema.net>, = "Eggert, Lars" <lars@netapp.com>, Brian Trammell = <ietf@trammell.ch>, Mirja = K=FChlewind <mirja.kuehlewind@tik.ee.e= thz.ch>, QUIC WG <quic@ietf.org>, Martin Thomson = <martin.thomson@gmail.com>=

Subject: RE: Packet number encryption =

 

What is the group’s proposal for allowing = network monitoring tools to detect packet retransmission or packet = reordering ?

These metrics are = pretty straightforward to measure for TCP flows.

Tools like Wireshark can analyze packets and spot = issues.

How can the network tools = perform this kind of measurements for QUIC flows if PN field is = encrypted?

 

 

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of Jana Iyengar
Sent: Friday, February 02, = 2018 9:31 PM
To: Fossati, Thomas (Nokia - GB/Cambridge, UK) = <thomas.fossati@nokia.com>=
Cc: Gorry Fairhust <gorry@erg.abdn.ac.uk>; Eric = Rescorla <ekr@rtfm.com>; Mirja = K=FChlewind <mirja.kuehlewind@tik.ee.e= thz.ch>; Christian Huitema <huitema@huitema.net>; Brian = Trammell <ietf@trammell.ch>; Eggert, Lars = <lars@netapp.com>; QUIC WG = <quic@ietf.org>; Martin = Thomson <martin.thomson@gmail.com>=
Subject: Re: Packet number encryption

 

A few = points as I catch up on this thread.

 

First, I'll remind folks that QUIC is an encrypted = transport. I say this because the cost of this operation is trivial in = the context of encrypting every packet. The cost is borne at the servers = and not at middleboxes, so the additional crypto cost is basically = trivial.

 

Second, this simplifies and increases robustness of = implementation. Avoiding random PN jumps, as Kazuho points out, makes = special-casing of code unnecessary. Special code that is exercised = occasionally is a strong bug attractor, and I would strongly argue for = as few of those as possible in = implementation.

 

Third, yes, ossification is a real concern. A simple = example: using increasing packet numbers as a signature for detecting = QUIC. Even if you argue against this example, there are innovative ways = in which ossification will happen. This is based on a true = story: We had no idea how GQUIC's flags field could get = ossified, the value that was being used commonly became used as a = signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC = paper).

 

There's a win here in terms of implementation = complexity and several implementers have said so. There's a win in terms = of ossification and our experience says so. There's a potential loss of = manageability, in being able to detect reordering. This is the = trade-off, and I am still in favor of encrypting packet = numbers.

 

On = Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, UK) = <thomas.fossati@nokia.com> = wrote:

On = 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" <quic-bounces@ietf.org on = behalf of lars@netapp.com> = wrote:
> On 2018-1-31, at 10:52, Gorry Fairhurst <gorry@erg.abdn.ac.uk> = wrote:
> > +1 - Simply: This *is* complicated and seems to add = little.
>
> So as an implementor (chair hat off), this adds = very little to the
> overall complexity of the = protocol.

This doesn't sound great.  It's a bit like saying = that adding the Higgs
mechanism to the standard model's lagrangian = doesn't make it much more
complicate :-)  (*)

More = seriously though, I'd like to point out that it is not just = about
implementation complexity, it's also the energy cost per packet = that is
quite crucial.  I haven't done the math but ISTM that = bringing in
another batch of non-optional crypto computation on a per = packet basis
is not going to move the needle in the right direction = for stacks that
run on low power (IoT).

This is not a = catastrophe - we have CoAP and a (D)TLS profile - but
neither it's = ideal, since cutting off the small things from the wider
ecosystem = creates an artificial gap which then will need a middlebox = to
bridge.  (Sure, we have specified the behaviour of a similar = box
already, but it'd be really better if the extra translation logic = could
be avoided in the first place.)

I guess what I'm saying = is that PN encryption being a core mechanism
that can't be negotiated = at handshake time reduces our ability to later
profile QUIC for the = IoT, which would be a bit unlucky.

So the question is: would it = be possible to make this property a
configurable knob = instead?

(*) https://www.symmetrymagazine.org/article/the-deconstruc= ted-standard-model-equation

 

------=_NextPart_000_00F4_01D39E4E.B4E6F930-- From nobody Sun Feb 4 22:07:56 2018 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 0ACB6126DED for ; Sun, 4 Feb 2018 22:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Xo0nM29n; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=OCoB1Fn6 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 22jkSi4W6LYB for ; Sun, 4 Feb 2018 22:07:51 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FFBE126D74 for ; Sun, 4 Feb 2018 22:07:51 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4B29320AF9; Mon, 5 Feb 2018 01:07:50 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 05 Feb 2018 01:07:50 -0500 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; s= fm1; bh=nI65yIbjQ9OZMBl0SN9fCo4600kBaLop52S3ABMBfNc=; b=Xo0nM29n 0tMDLJcxE7+fMjKiW8qkXZhejsy3WpIhNSBIiNiBLWQtpkhTW7ncB4yA3jqHa3EO D/qUCbvvzfDgDX105HruGoYxE9KQg+e0MrLwahMk9FYTAaJnjp0SySxgh779wBR6 nWMFMvBnHRechlYU6pJp58KAE85LebC/t3wOkuFF/8nA/nfP491Z0mN+IqZcQhCV r2Ko8Pj/898CA+EytcR92HfYIfBbbNx9svDiQKv6anK8zo2RPi2QKWzO0z2e4Fj5 zxQy/h2Dv/UEAEnDooWwXM8xhuHvkIu4bqq1/Exua4kHdoHhVovedHpyl2RbpuBC TWr0HecP4NOmRA== 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; s=fm1; bh=nI65yIbjQ9OZMBl0SN9fCo4600kBa Lop52S3ABMBfNc=; b=OCoB1Fn6GY2O7c6HfeJmSekXGDz3XExpKlIfaMnb0JNSp 2QC/HRMgitMJlJklI4l2ONINkEC6KYsXVSoC/3mSc9mIZQ/78F07abXl/O2E/hoI TYejE7E5zZXiDb5bbbS0trL07OM6bR3DQEFwlNWFpqFPgFFk9EVwgeaHPENSzwO8 9vmdMtXln9+atVS4koVdodM2FG9emFjQrDOohxw8bFKFaftglGmbICYb0KHZPM2n U9rAN/k2CUH3NoHS5sa2kVaKdD7kXIE47Ek6+3HtMxL36EXmRZ4tLp+wB+ctGM64 GZh+n5b6MY3zRHo6JkW23cm2qwAOqU9X4GBE0yQFA== X-ME-Sender: Received: from [192.168.1.18] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 4AA5D2415E; Mon, 5 Feb 2018 01:07:49 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Call for Adoption: Invariants Message-Id: Date: Mon, 5 Feb 2018 17:07:45 +1100 Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3445.5.20) 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, 05 Feb 2018 06:07:54 -0000 At the Melbourne meeting, there was strong support for adopting Martin's = invariants draft: https://tools.ietf.org/html/draft-thomson-quic-invariants-00 Any objections / concerns about doing so? Unless we hear otherwise, = we'll adopt at the end of the week. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Feb 4 22:08:02 2018 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 EB466126CD6 for ; Sun, 4 Feb 2018 22:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=RvsPbAYd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XTqLnVt9 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 BQJ9kcxUT_Zv for ; Sun, 4 Feb 2018 22:07:58 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A70D126D74 for ; Sun, 4 Feb 2018 22:07:58 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B9B0120B4C; Mon, 5 Feb 2018 01:07:57 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 05 Feb 2018 01:07:57 -0500 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; s= fm1; bh=U6pQRwu5nKwrqow9Nsho2qwZZJ8dupHH3oILbYiFjSY=; b=RvsPbAYd l6uEFu2/C0KPt9rA3AsQ78/vBNz/F4nLAto4yq3FZur9Z0PmqYtSe0X51wTz1yrh 1f+jI0aTQND41OLranOO2E5yTCgD8AmORS9BLTi9cBaIRaIdECnev8+Rt0tJL/LQ 3f7nROJLrkkOA4IiQuaaFdVHrizSNhbS4aXdupx96jpf0t+xuQNpBFqRJetWcBTe 73wli019LtMqm6/OOn5u6kCYolrs4/yrKvobyRBQbElJE2yZcr/0vSC9DQgXZ6Jf tjt/Dg0MALg9RbwmPGGT5UpV8aYJ81Q4i6ysm0NrEoeg6zU1WbPmplVkqSSDfWWY w5bagSNq7H51WA== 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; s=fm1; bh=U6pQRwu5nKwrqow9Nsho2qwZZJ8du pHH3oILbYiFjSY=; b=XTqLnVt9Xv2DgLuDGs8owozGa0g9vOolBRb7v1yKMSxks DARxsZj48p1Vm1CKt47HEd+68MI4H9Eh0O61tkWqwLLKPme7aZVi4PXS0ABBzijb lK0/FbaJp9jPUvJwN2TpEoHfRUOGkCVYw4OWblGGKlRm2Hk+/sIz6QXsKxmlZBeR 5Z0dBZS4FUSpwiYJBmWjbuxSEZPD/9jDHnkZV3aDrXpLU5n4QPbsdgLP9Y5WjUFK uM4mfk7I4ImoorOpqCPOgYUVMBOEutF8E75Ung4rh/+BhOycsGsHTfdtlBRefGDS l5AXqYiXMa10YpVZQ9ak0Y7AqYtlXSUSOAcYUxAQQ== X-ME-Sender: Received: from [192.168.1.18] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id C37BD241E0; Mon, 5 Feb 2018 01:07:56 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Call for Adoption: QCRAM Message-Id: <6A834DB6-F2A5-4973-83CD-8AAA82945372@mnot.net> Date: Mon, 5 Feb 2018 17:07:55 +1100 Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3445.5.20) 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, 05 Feb 2018 06:08:00 -0000 In Melbourne, there was strong support (with a small amount of pushback = which was discussed) for adopting QCRAM: https://tools.ietf.org/html/draft-krasic-quic-qcram-04 Any objections / concerns about doing so? Unless we hear otherwise, = we'll adopt at the end of the week. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sun Feb 4 22:14:39 2018 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 40230126D74 for ; Sun, 4 Feb 2018 22:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 xCkcKowUqukX for ; Sun, 4 Feb 2018 22:14:36 -0800 (PST) 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 9B364120727 for ; Sun, 4 Feb 2018 22:14:36 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx12.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1eia2u-0003hQ-W9 for quic@ietf.org; Mon, 05 Feb 2018 07:14:35 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eia2s-0000l3-Tc for quic@ietf.org; Mon, 05 Feb 2018 01:14:27 -0500 Received: (qmail 11483 invoked from network); 5 Feb 2018 06:14:24 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Feb 2018 06:14:24 -0000 To: quic@ietf.org References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <00f301d39e3d$f15bdf40$d4139dc0$@gmail.com> From: Christian Huitema Message-ID: <613d29a0-5928-a41a-c4df-628c01bd6ef6@huitema.net> Date: Sun, 4 Feb 2018 20:14:23 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <00f301d39e3d$f15bdf40$d4139dc0$@gmail.com> Content-Type: multipart/alternative; boundary="------------7DBB1BF7AD10D7D2272DE2CB" Content-Language: en-US Subject: Re: Packet number encryption X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tttBI5fAFnSZqtu0qjMbwwXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fvBajegLDcZxza81Z9Gs+T4B98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYd851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Vm3SIdO3BpR97t9bfBi5FxwJWxe4AVanuu6Qx5p47D RdBMnad1MZGQJt70BWgqpdDGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATvFVVOfJAYdBTniKgyyo60ONoJfh+XjGSeeT90H/uIHg abd/jr1Rt4J/OQ1c4GRp/cXqomqzFz0nrRO9BMxfdWbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWi2LEHF33nMCnEPdDBPtPg/fFcHV2tQAVqGdj/zM7G/G3L31QGIB1LDs8uX49JL/W5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w 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: Mon, 05 Feb 2018 06:14:38 -0000 This is a multi-part message in MIME format. --------------7DBB1BF7AD10D7D2272DE2CB Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 2/4/2018 6:58 PM, Roni Even wrote: > Does not it mean that the network need to identify packets that are > from the same quic connection to make such wrapping? > Not really. The network can take any slice of the input packets, assigned them a sequence number, and verify that the slice comes out the same way it went in. Or count losses, reordering, etc. Slicing by five tuple should work just fine. -- Christian Huitema --------------7DBB1BF7AD10D7D2272DE2CB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 2/4/2018 6:58 PM, Roni Even wrote:

Does not it mean that the network need to identify packets that are from the same quic connection to make such wrapping?


Not really. The network can take any slice of the input packets, assigned them a sequence number, and verify that the slice comes out the same way it went in. Or count losses, reordering, etc. Slicing by five tuple should work just fine.

-- Christian Huitema
--------------7DBB1BF7AD10D7D2272DE2CB-- From nobody Sun Feb 4 22:24:15 2018 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 5B453126D74 for ; Sun, 4 Feb 2018 22:24:14 -0800 (PST) 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, 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, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-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 vvKvyIPTUO9k for ; Sun, 4 Feb 2018 22:24:12 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 66AC5120727 for ; Sun, 4 Feb 2018 22:24:12 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1A3387796FF31 for ; Mon, 5 Feb 2018 06:24:09 +0000 (GMT) Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 5 Feb 2018 06:24:09 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0361.001; Mon, 5 Feb 2018 14:24:04 +0800 From: "Roni Even (A)" To: Christian Huitema , "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31OHIMr4j8BEGT08HQjsZCKqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBlQCAADHCgIAACBkAgAEGFwCAAWG+cIABeXFFgAACQ6A= Date: Mon, 5 Feb 2018 06:24:03 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD861DD5@DGGEMM506-MBX.china.huawei.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <00f301d39e3d$f15bdf40$d4139dc0$@gmail.com> <613d29a0-5928-a41a-c4df-628c01bd6ef6@huitema.net> In-Reply-To: <613d29a0-5928-a41a-c4df-628c01bd6ef6@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.244] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD861DD5DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 05 Feb 2018 06:24:14 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD861DD5DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable BTW: This will only provide information about reorder in this network segment an= d not end to end which is what the requirement is for. Roni From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema Sent: Monday, February 05, 2018 8:14 AM To: quic@ietf.org Subject: Re: Packet number encryption On 2/4/2018 6:58 PM, Roni Even wrote: Does not it mean that the network need to identify packets that are from t= he same quic connection to make such wrapping? Not really. The network can take any slice of the input packets, assigned t= hem a sequence number, and verify that the slice comes out the same way it = went in. Or count losses, reordering, etc. Slicing by five tuple should wor= k just fine. -- Christian Huitema --_000_6E58094ECC8D8344914996DAD28F1CCD861DD5DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

BTW:

This will only provide in= formation about reorder in this network segment and not end to end which is= what the requirement is for.

Roni

 <= /p>

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Monday, February 05, 2018 8:14 AM
To: quic@ietf.org
Subject: Re: Packet number encryption

 

On 2/4/2018 6:58 PM, Roni Even wrote:

Does not it mean that the network need = to identify packets  that are from the same quic connection to make such wrapping?


Not really. The network can take any slice of the input packets, assigned t= hem a sequence number, and verify that the slice comes out the same way it = went in. Or count losses, reordering, etc. Slicing by five tuple should wor= k just fine.

-- Christian Huitema

--_000_6E58094ECC8D8344914996DAD28F1CCD861DD5DGGEMM506MBXchina_-- From nobody Sun Feb 4 23:18:15 2018 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 D6B071289B0 for ; Sun, 4 Feb 2018 23:18:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, HTTPS_HTTP_MISMATCH=1.989, 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 (1024-bit key) header.d=fb.com header.b=Is9QbdXt; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=kgPOV7rl 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 C9U5PEQ46q17 for ; Sun, 4 Feb 2018 23:18:08 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 74EA1120727 for ; Sun, 4 Feb 2018 23:18:08 -0800 (PST) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w157CeoD032152; Sun, 4 Feb 2018 23:17:03 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=GTATbk2I28MafdN6jIE1qeXn8o7/0mtmI9hNVzTt7hU=; b=Is9QbdXtF6u0Pom3bpnaFVklIcAU7AduPis+SNsomAVRP3xKN0PChIHWJgQAR1oqRmWG W4F4crKcIElEyPY3yJRtIahcLMQq/cESEPpsYkGtuJ/A9IOtl5DWyQt098R2+crZnvcH gyxjwIy02VVYC7GJNHK3f8zBInE/s9r+Bt0= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fwbssdjtw-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 04 Feb 2018 23:17:03 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 5 Feb 2018 02:17:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GTATbk2I28MafdN6jIE1qeXn8o7/0mtmI9hNVzTt7hU=; b=kgPOV7rlGwcweyUIDrSCYdExxFRWOkdQZR2TK8JA8fK0yRTEBb0JJ+vBeP/4tUKzazVo2ZxQp5UAymAKlOPIz5W6fgD43mv3Ar6vfL6YTMHQS49Cetg4XuJih8ZVAFBqiTb6LZUvs+qaHTbZZtz4UcuAq2AratyUN5IF8gUJmmc= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0215.namprd15.prod.outlook.com (10.163.64.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 07:16:58 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 07:16:58 +0000 From: Roberto Peon To: Roni Even , "'Roni Even (A)'" , 'Piotr Galecki' , 'Jana Iyengar' , "'Fossati, Thomas (Nokia - GB/Cambridge, UK)'" CC: 'Gorry Fairhust' , 'Eric Rescorla' , 'Christian Huitema' , "'Eggert, Lars'" , 'Brian Trammell' , =?utf-8?B?J01pcmphIEvDvGhsZXdpbmQn?= , 'QUIC WG' , 'Martin Thomson' Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW3+HjM5RmHWDkij9J5s6UBSSaOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGB6AANx9AIABGNFfgABKWYD//6CaAA== Date: Mon, 5 Feb 2018 07:16:57 +0000 Message-ID: <2B5B329E-C539-40EA-B8E4-A96861141F52@fb.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <00f301d39e3d$f15bdf40$d4139dc0$@gmail.com> In-Reply-To: <00f301d39e3d$f15bdf40$d4139dc0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [98.234.190.115] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0215; 20:z5mxOpcdPdMMGERJ8k7rtmlclHTb3d7MdQSFFj1pQ1LiiZrfY5YbbeFtPUmKdmSw2VpVxVMbdhXR1SH3wPRRBG6tIGmvhxkaCxXCNANAO87JwCMAHFztmow278ikWBYNzsLElLMxRtqt+4Fd5u7NnbE638qHuP6XWNPusggRVXI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b9817206-2b7b-46c2-f96c-08d56c687190 x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0215; x-ms-traffictypediagnostic: BY2PR15MB0215: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(72170088055959)(50582790962513)(82608151540597)(85827821059158)(67672495146484)(211936372134217)(179696456005106)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(11241501184)(2400082)(944501161)(10201501046)(3002001)(6041288)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:BY2PR15MB0215; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0215; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(39380400002)(366004)(376002)(396003)(11905935001)(377424004)(199004)(189003)(25786009)(6512007)(26005)(106356001)(2950100002)(105586002)(86362001)(81156014)(8936002)(81166006)(7116003)(5660300001)(606006)(8676002)(66066001)(99286004)(36756003)(68736007)(2900100001)(93886005)(966005)(478600001)(8656006)(97736004)(14454004)(33656002)(110136005)(54906003)(6246003)(4326008)(3480700004)(2906002)(39060400002)(316002)(561944003)(6116002)(3660700001)(3280700002)(3846002)(76176011)(6486002)(77096007)(82746002)(6436002)(236005)(229853002)(54896002)(7416002)(53936002)(4001150100001)(6506007)(102836004)(53546011)(59450400001)(186003)(7736002)(6306002)(83716003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0215; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ya2guFWlZYzk2n+0D8X+yI2BRhBLVeG+Ck4OKRYfJ9H+Pi5A3smK29LUH3DE+OjOMoxyJ09yJTKO6whXbkV2Rg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_2B5B329EC53940EAB8E4A96861141F52fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b9817206-2b7b-46c2-f96c-08d56c687190 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 07:16:57.8955 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0215 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_01:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 05 Feb 2018 07:18:13 -0000 --_000_2B5B329EC53940EAB8E4A96861141F52fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBkZXBlbmRzLg0KQXJndWFibHksIGFsbCB0aGUgbmV0d29yayBjYW4ga25vdyAob3Igc2hv dWxkIGtub3cpIGlzIG9uIHRoZSBiYXNpcyBvZiBhIDUtdHVwbGUsIHRodXMgdGhlIG5ldHdvcmsg Y291bGQgYXNzaWduIHNlcXVlbmNlIG51bWJlcnMgYmFzZWQgb24gb3JkZXIgb2YgYXJyaXZhbCBv ZiBhIDUtdHVwbGUuDQoNCkhvd2V2ZXIsIG9uZSBjb3VsZCBkbyBtb3JlIHVzZWZ1bCBhbmQvb3Ig Z2VuZXJhbCB0aGluZ3M6IElmIHRoZSBpbnRlbmRlZCBlZ3Jlc3Mgbm9kZSBpcyBrbm93biBhdCB0 aGUgaW5ncmVzcyBwb2ludCBmb3IgYSBwYWNrZXQgdGhlbiwgd2hlbiBhcHBseWluZyB0aGUgYXBw cm9wcmlhdGUgcm91dGUsIHN0YW1wIHRoZSBwYWNrZXQgd2l0aCBhIHNlcXVlbmNlIG51bWJlciBv bi9mb3IgdGhhdCByb3V0ZS4gQXQgdGhhdCBwb2ludCB5b3XigJlyZSBhYmxlIHRvIGxvb2sgYXQg cmVvcmRlcmluZyBhY3Jvc3MgYW55L2FsbCBmbG93cyB3aXRoaW4gYSByb3V0ZS4gVGhpcyBpcyBh IHN0cm9uZ2VyIG9yZGVyaW5nIGd1YXJhbnRlZSB0aGFuIGlzIG5lY2Vzc2FyeSwgYW5kIHRodXMg aXMgc3VmZmljaWVudCBmb3IgYW55IGluZGl2aWR1YWwgZmxvdyBvbiB0aGF0IHJvdXRlLiBJbiBt eSBiZWxpZWYsIHRoaXMgd291bGQgYmUgYSBzdXBlcmlvciBtZXRyaWMgZm9yIG5ldHdvcmsgaGVh bHRoIGRldGVjdGlvbiBvdmVyYWxsLg0KDQotPVINCg0KRnJvbTogUm9uaSBFdmVuIDxyb24uZXZl bi50bHZAZ21haWwuY29tPg0KRGF0ZTogU3VuZGF5LCBGZWJydWFyeSA0LCAyMDE4IGF0IDg6NTgg UE0NClRvOiBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT4sICInUm9uaSBFdmVuIChBKSciIDxy b25pLmV2ZW5AaHVhd2VpLmNvbT4sICdQaW90ciBHYWxlY2tpJyA8cGlvdHJfZ2FsZWNraUBhZmZp cm1lZG5ldHdvcmtzLmNvbT4sICdKYW5hIEl5ZW5nYXInIDxqcmlAZ29vZ2xlLmNvbT4sICInRm9z c2F0aSwgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSwgVUspJyIgPHRob21hcy5mb3NzYXRp QG5va2lhLmNvbT4NCkNjOiAnR29ycnkgRmFpcmh1c3QnIDxnb3JyeUBlcmcuYWJkbi5hYy51az4s ICdFcmljIFJlc2NvcmxhJyA8ZWtyQHJ0Zm0uY29tPiwgJ0NocmlzdGlhbiBIdWl0ZW1hJyA8aHVp dGVtYUBodWl0ZW1hLm5ldD4sICInRWdnZXJ0LCBMYXJzJyIgPGxhcnNAbmV0YXBwLmNvbT4sICdC cmlhbiBUcmFtbWVsbCcgPGlldGZAdHJhbW1lbGwuY2g+LCAnTWlyamEgS8O8aGxld2luZCcgPG1p cmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+LCAnUVVJQyBXRycgPHF1aWNAaWV0Zi5vcmc+ LCAnTWFydGluIFRob21zb24nIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpTdWJqZWN0OiBS RTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCkRvZXMgbm90IGl0IG1lYW4gdGhhdCB0aGUg bmV0d29yayBuZWVkIHRvIGlkZW50aWZ5IHBhY2tldHMgIHRoYXQgYXJlIGZyb20gdGhlIHNhbWUg cXVpYyBjb25uZWN0aW9uIHRvIG1ha2Ugc3VjaCB3cmFwcGluZz8NClJvbmkNCg0KRnJvbTogUVVJ QyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYmVydG8gUGVv bg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAwNSwgMjAxOCAyOjM4IEFNDQpUbzogUm9uaSBFdmVu IChBKTsgUGlvdHIgR2FsZWNraTsgSmFuYSBJeWVuZ2FyOyBGb3NzYXRpLCBUaG9tYXMgKE5va2lh IC0gR0IvQ2FtYnJpZGdlLCBVSykNCkNjOiBHb3JyeSBGYWlyaHVzdDsgRXJpYyBSZXNjb3JsYTsg Q2hyaXN0aWFuIEh1aXRlbWE7IEVnZ2VydCwgTGFyczsgQnJpYW4gVHJhbW1lbGw7IE1pcmphIEvD vGhsZXdpbmQ7IFFVSUMgV0c7IE1hcnRpbiBUaG9tc29uDQpTdWJqZWN0OiBSZTogUGFja2V0IG51 bWJlciBlbmNyeXB0aW9uDQoNCg0KQSBuZXR3b3JrIGNvdWxkIGNhcnJ5IHdoYXRldmVyIHByb3Rv Y29sIGl0IHdpc2hlZCB0bywgaS5lLiBieSB3cmFwcGluZyBhbnkvYWxsIHBhY2tldHMgb24gaW5n cmVzcyB0byB0aGUgbmV0d29yaywgYW5kIHRoZW4gdW4td3JhcHBpbmcgd2hlbiBmb3J3YXJkaW5n IHRvIGFub3RoZXIgbmV0d29yay4gVGhpcyB3b3VsZCBhbGxvdyBhIG5ldHdvcmsgdG8gcmVjb3Jk IGFuZCB0cmFjayB3aGF0ZXZlciBpdCB3YW50ZWQgdG8gd2l0aG91dCBwbGFjaW5nIGNvbnN0cmFp bnRzIG9uIGxheWVycyB3aGljaCBzaG91bGQgYmUgYWJvdmUgaXQuDQoNCklmIHRoZSBuZXR3b3Jr IHBsYWNlZCBhIHNlcXVlbmNlIG51bWJlciBvbiBpbmNvbWluZyBwYWNrZXRzLCBpdCBjb3VsZCBk ZXRlY3QgcmVvcmRlcmluZyBhY3Jvc3MgYWxsIGZsb3dzLiBJZiBpdCBkbyBzbyBvbiBhIDUtdHVw bGUgYmFzaXMsIGl0IGNvdWxkIGRldGVjdCByZW9yZGVyaW5nL2R1cGxpY2F0aW9uL2xvc3MgYWNy b3NzIGFueSA1LXR1cGxlLg0KDQoNCg0KLT1SDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBSb25pIEV2ZW4gKEEpIDxyb25pLmV2ZW5AaHVhd2VpLmNvbT4NClNlbnQ6 IFNhdHVyZGF5LCBGZWJydWFyeSAzLCAyMDE4IDExOjQ3OjA2IFBNDQpUbzogUm9iZXJ0byBQZW9u OyBQaW90ciBHYWxlY2tpOyBKYW5hIEl5ZW5nYXI7IEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBH Qi9DYW1icmlkZ2UsIFVLKQ0KQ2M6IEdvcnJ5IEZhaXJodXN0OyBFcmljIFJlc2NvcmxhOyBNaXJq YSBLw7xobGV3aW5kOyBFZ2dlcnQsIExhcnM7IEJyaWFuIFRyYW1tZWxsOyBDaHJpc3RpYW4gSHVp dGVtYTsgUVVJQyBXRzsgTWFydGluIFRob21zb24NClN1YmplY3Q6IFJFOiBQYWNrZXQgbnVtYmVy IGVuY3J5cHRpb24NCg0KDQpIaSwNCg0KTmV0d29yayBtb25pdG9yaW5nOg0KDQpOZXR3b3JrcyBt YXkgYWx3YXlzIHdyYXAgdGhlIHBhY2tldChzKSB0aGV5IGhhdmUgcmVjZWl2ZWQgd2l0aCB3aGF0 ZXZlciBkYXRhIHRoZXkgd2lzaCwgYW5kIHVud3JhcCBiZWZvcmUgZm9yd2FyZGluZy4gVGhpcyBj YW4gYWxsb3cgYW55IG5ldHdvcmsgdG8gdW5kZXJzdGFuZCBvcmRlcmluZywgIGxvc3MsIGV0YyB3 aXRoaW4gaXRzIGJvdW5kYXJpZXMuDQoNCg0KDQpSRS0gc28geW91IGFyZSBzYXlpbmcgdGhhdCB3 ZSBjYW4gZm9yIGV4YW1wbGUgIGxldmVyYWdlICBSVFAgYW5kIGRlZmluZSBSVFAgcGF5bG9hZCBm b3IgUVVJQyB0aGF0IHdpbGwgY2FycnkgUVVJQyBwYWNrZXRzLCB3ZSB3aWxsIGp1c3QgbmVlZCB0 byByZXNvbHZlIHRoZSBNVFUgc2l6ZS4NCg0KUm9uaQ0KDQoNCg0KDQoNCkZyb206IFFVSUMgW21h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnRvIFBlb24NClNl bnQ6IFNhdHVyZGF5LCBGZWJydWFyeSAwMywgMjAxOCA4OjM4IFBNDQpUbzogUGlvdHIgR2FsZWNr aTsgSmFuYSBJeWVuZ2FyOyBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBV SykNCkNjOiBHb3JyeSBGYWlyaHVzdDsgRXJpYyBSZXNjb3JsYTsgTWlyamEgS8O8aGxld2luZDsg RWdnZXJ0LCBMYXJzOyBCcmlhbiBUcmFtbWVsbDsgQ2hyaXN0aWFuIEh1aXRlbWE7IFFVSUMgV0c7 IE1hcnRpbiBUaG9tc29uDQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoN Cg0KDQpPc3NpZmljYXRpb246DQoNCkluIHRoZSBwYXN0IHRjcCBtaWRkbGVib3hlcyBleHBlY3Rl ZCBpbi1vcmRlciwgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIG9mZnNldHMgYW5kIHRyaWVkIHRv IGZpeCByZW9yZGVyaW5nIGJlZm9yZSBmb3J3YXJkaW5nLiBUaGlzIG1pZGRsZWJveCBiZWhhdmlv ciwgcHJlZGljYXRlZCBvbiBvYnNlcnZhYmxlIGZsb3dzLCBwcmV2ZW50ZWQgZGVwbG95bWVudCBv ZiB0aGluZ3Mgd2hpY2ggd291bGQgaGF2ZSBtYWRlIHRjcCBtb3JlIGVmZmljaWVudC4NCg0KDQoN CiBUaGlzIGlzIHRoZSBraW5kIG9mIG5vbi10aGVvcmV0aWNhbCBvc3NpZmljYXRpb24gdGhhdCBk cm92ZSB0aGUgY3JlYXRpb24gb2YgUVVJQyBpbiB0aGUgZmlyc3QgcGxhY2UuDQoNCg0KDQpOZXR3 b3JrIG1vbml0b3Jpbmc6DQoNCk5ldHdvcmtzIG1heSBhbHdheXMgd3JhcCB0aGUgcGFja2V0KHMp IHRoZXkgaGF2ZSByZWNlaXZlZCB3aXRoIHdoYXRldmVyIGRhdGEgdGhleSB3aXNoLCBhbmQgdW53 cmFwIGJlZm9yZSBmb3J3YXJkaW5nLiBUaGlzIGNhbiBhbGxvdyBhbnkgbmV0d29yayB0byB1bmRl cnN0YW5kIG9yZGVyaW5nLCAgbG9zcywgZXRjIHdpdGhpbiBpdHMgYm91bmRhcmllcy4NCg0KDQoN CkRlYnVnZ2luZzoNCg0KRGVidWdnaW5nIG9mIGZsb3dzIGNhbiBzdGlsbCBoYXBwZW4gZm9yIGZs b3dzIHRoYXQgd2lzaCB0byBiZSBkZWJ1Z2dlZC0tIHRoZSBRVUlDIGNvbm5lY3Rpb24ncyBrZXkg bWF0ZXJpYWwocykgY2FuIGJlIHNoYXJlZCBtYW51YWxseSBhbmQgdXNlZCBieSB0aGUgZGVidWdn aW5nIHRvb2wuIFRoaXMgaXMgaG93IG9uZSBkZWJ1Z3MgaHR0cDIsIGh0dHBzLCBldGMuIGFscmVh ZHkgdG9kYXkuDQoNCg0KDQotPVINCg0KDQoNCg0KDQoNCg0KLS0tLS0tLS0gT3JpZ2luYWwgbWVz c2FnZSAtLS0tLS0tLQ0KDQpGcm9tOiBQaW90ciBHYWxlY2tpIDxwaW90cl9nYWxlY2tpQGFmZmly bWVkbmV0d29ya3MuY29tPG1haWx0bzpwaW90cl9nYWxlY2tpQGFmZmlybWVkbmV0d29ya3MuY29t Pj4NCg0KRGF0ZTogMi8yLzE4IDc6MDAgUE0gKEdNVC0wODowMCkNCg0KVG86IEphbmEgSXllbmdh ciA8anJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29tPj4sICJGb3NzYXRpLCBUaG9t YXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBVSykiIDx0aG9tYXMuZm9zc2F0aUBub2tpYS5jb208 bWFpbHRvOnRob21hcy5mb3NzYXRpQG5va2lhLmNvbT4+DQoNCkNjOiBHb3JyeSBGYWlyaHVzdCA8 Z29ycnlAZXJnLmFiZG4uYWMudWs8bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFjLnVrPj4sIEVyaWMg UmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj4sIENocmlzdGlhbiBI dWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj4s ICJFZ2dlcnQsIExhcnMiIDxsYXJzQG5ldGFwcC5jb208bWFpbHRvOmxhcnNAbmV0YXBwLmNvbT4+ LCBCcmlhbiBUcmFtbWVsbCA8aWV0ZkB0cmFtbWVsbC5jaDxtYWlsdG86aWV0ZkB0cmFtbWVsbC5j aD4+LCBNaXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPG1h aWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPj4sIFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PiwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9t c29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4NCg0KU3ViamVj dDogUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQoNCg0KV2hhdCBpcyB0aGUgZ3JvdXDi gJlzIHByb3Bvc2FsIGZvciBhbGxvd2luZyBuZXR3b3JrIG1vbml0b3JpbmcgdG9vbHMgdG8gZGV0 ZWN0IHBhY2tldCByZXRyYW5zbWlzc2lvbiBvciBwYWNrZXQgcmVvcmRlcmluZyA/DQoNClRoZXNl IG1ldHJpY3MgYXJlIHByZXR0eSBzdHJhaWdodGZvcndhcmQgdG8gbWVhc3VyZSBmb3IgVENQIGZs b3dzLg0KDQpUb29scyBsaWtlIFdpcmVzaGFyayBjYW4gYW5hbHl6ZSBwYWNrZXRzIGFuZCBzcG90 IGlzc3Vlcy4NCg0KSG93IGNhbiB0aGUgbmV0d29yayB0b29scyBwZXJmb3JtIHRoaXMga2luZCBv ZiBtZWFzdXJlbWVudHMgZm9yIFFVSUMgZmxvd3MgaWYgUE4gZmllbGQgaXMgZW5jcnlwdGVkPw0K DQoNCg0KDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDIsIDIwMTggOToz MSBQTQ0KVG86IEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSA8dGhv bWFzLmZvc3NhdGlAbm9raWEuY29tPG1haWx0bzp0aG9tYXMuZm9zc2F0aUBub2tpYS5jb20+Pg0K Q2M6IEdvcnJ5IEZhaXJodXN0IDxnb3JyeUBlcmcuYWJkbi5hYy51azxtYWlsdG86Z29ycnlAZXJn LmFiZG4uYWMudWs+PjsgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRm bS5jb20+PjsgTWlyamEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5j aDxtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4+OyBDaHJpc3RpYW4gSHVp dGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+OyBC cmlhbiBUcmFtbWVsbCA8aWV0ZkB0cmFtbWVsbC5jaDxtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaD4+ OyBFZ2dlcnQsIExhcnMgPGxhcnNAbmV0YXBwLmNvbTxtYWlsdG86bGFyc0BuZXRhcHAuY29tPj47 IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PjsgTWFydGluIFRo b21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21h aWwuY29tPj4NClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KDQoNCkEg ZmV3IHBvaW50cyBhcyBJIGNhdGNoIHVwIG9uIHRoaXMgdGhyZWFkLg0KDQoNCg0KRmlyc3QsIEkn bGwgcmVtaW5kIGZvbGtzIHRoYXQgUVVJQyBpcyBhbiBlbmNyeXB0ZWQgdHJhbnNwb3J0LiBJIHNh eSB0aGlzIGJlY2F1c2UgdGhlIGNvc3Qgb2YgdGhpcyBvcGVyYXRpb24gaXMgdHJpdmlhbCBpbiB0 aGUgY29udGV4dCBvZiBlbmNyeXB0aW5nIGV2ZXJ5IHBhY2tldC4gVGhlIGNvc3QgaXMgYm9ybmUg YXQgdGhlIHNlcnZlcnMgYW5kIG5vdCBhdCBtaWRkbGVib3hlcywgc28gdGhlIGFkZGl0aW9uYWwg Y3J5cHRvIGNvc3QgaXMgYmFzaWNhbGx5IHRyaXZpYWwuDQoNCg0KDQpTZWNvbmQsIHRoaXMgc2lt cGxpZmllcyBhbmQgaW5jcmVhc2VzIHJvYnVzdG5lc3Mgb2YgaW1wbGVtZW50YXRpb24uIEF2b2lk aW5nIHJhbmRvbSBQTiBqdW1wcywgYXMgS2F6dWhvIHBvaW50cyBvdXQsIG1ha2VzIHNwZWNpYWwt Y2FzaW5nIG9mIGNvZGUgdW5uZWNlc3NhcnkuIFNwZWNpYWwgY29kZSB0aGF0IGlzIGV4ZXJjaXNl ZCBvY2Nhc2lvbmFsbHkgaXMgYSBzdHJvbmcgYnVnIGF0dHJhY3RvciwgYW5kIEkgd291bGQgc3Ry b25nbHkgYXJndWUgZm9yIGFzIGZldyBvZiB0aG9zZSBhcyBwb3NzaWJsZSBpbiBpbXBsZW1lbnRh dGlvbi4NCg0KDQoNClRoaXJkLCB5ZXMsIG9zc2lmaWNhdGlvbiBpcyBhIHJlYWwgY29uY2Vybi4g QSBzaW1wbGUgZXhhbXBsZTogdXNpbmcgaW5jcmVhc2luZyBwYWNrZXQgbnVtYmVycyBhcyBhIHNp Z25hdHVyZSBmb3IgZGV0ZWN0aW5nIFFVSUMuIEV2ZW4gaWYgeW91IGFyZ3VlIGFnYWluc3QgdGhp cyBleGFtcGxlLCB0aGVyZSBhcmUgaW5ub3ZhdGl2ZSB3YXlzIGluIHdoaWNoIG9zc2lmaWNhdGlv biB3aWxsIGhhcHBlbi4gVGhpcyBpcyBiYXNlZCBvbiBhIHRydWUgc3Rvcnk6IFdlIGhhZCBubyBp ZGVhIGhvdyBHUVVJQydzIGZsYWdzIGZpZWxkIGNvdWxkIGdldCBvc3NpZmllZCwgdGhlIHZhbHVl IHRoYXQgd2FzIGJlaW5nIHVzZWQgY29tbW9ubHkgYmVjYW1lIHVzZWQgYXMgYSBzaWduYXR1cmUg Zm9yIFFVSUMgdHJhZmZpYyAoc2VlIFNlY3Rpb24gNy41IGluIHRoZSBTSUdDT01NIFFVSUMgcGFw ZXI8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19z dGF0aWMuZ29vZ2xldXNlcmNvbnRlbnQuY29tX21lZGlhX3Jlc2VhcmNoLmdvb2dsZS5jb21fZW5f cHVic19hcmNoaXZlXzQ2NDAzLnBkZiZkPUR3TUdhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcm cj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJm09U1k4N0k0dl9JcVRDR09kcy1qNU5DT3drUTBjSmNZ SEd5S2RYbU1JVm42SSZzPVU5bzZkSS1kd3pLd3ZYSHZ2bXY3V3RWbTg0cHV2eGhhUDBjTjJvZjNW dkEmZT0+KS4NCg0KDQoNClRoZXJlJ3MgYSB3aW4gaGVyZSBpbiB0ZXJtcyBvZiBpbXBsZW1lbnRh dGlvbiBjb21wbGV4aXR5IGFuZCBzZXZlcmFsIGltcGxlbWVudGVycyBoYXZlIHNhaWQgc28uIFRo ZXJlJ3MgYSB3aW4gaW4gdGVybXMgb2Ygb3NzaWZpY2F0aW9uIGFuZCBvdXIgZXhwZXJpZW5jZSBz YXlzIHNvLiBUaGVyZSdzIGEgcG90ZW50aWFsIGxvc3Mgb2YgbWFuYWdlYWJpbGl0eSwgaW4gYmVp bmcgYWJsZSB0byBkZXRlY3QgcmVvcmRlcmluZy4gVGhpcyBpcyB0aGUgdHJhZGUtb2ZmLCBhbmQg SSBhbSBzdGlsbCBpbiBmYXZvciBvZiBlbmNyeXB0aW5nIHBhY2tldCBudW1iZXJzLg0KDQoNCg0K T24gRnJpLCBGZWIgMiwgMjAxOCBhdCA3OjMyIEFNLCBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0g R0IvQ2FtYnJpZGdlLCBVSykgPHRob21hcy5mb3NzYXRpQG5va2lhLmNvbTxtYWlsdG86dGhvbWFz LmZvc3NhdGlAbm9raWEuY29tPj4gd3JvdGU6DQoNCk9uIDMxLzAxLzIwMTgsIDEwOjA2LCAiUVVJ QyBvbiBiZWhhbGYgb2YgRWdnZXJ0LCBMYXJzIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBsYXJzQG5ldGFwcC5jb208bWFp bHRvOmxhcnNAbmV0YXBwLmNvbT4+IHdyb3RlOg0KPiBPbiAyMDE4LTEtMzEsIGF0IDEwOjUyLCBH b3JyeSBGYWlyaHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPG1haWx0bzpnb3JyeUBlcmcuYWJk bi5hYy51az4+IHdyb3RlOg0KPiA+ICsxIC0gU2ltcGx5OiBUaGlzICppcyogY29tcGxpY2F0ZWQg YW5kIHNlZW1zIHRvIGFkZCBsaXR0bGUuDQo+DQo+IFNvIGFzIGFuIGltcGxlbWVudG9yIChjaGFp ciBoYXQgb2ZmKSwgdGhpcyBhZGRzIHZlcnkgbGl0dGxlIHRvIHRoZQ0KPiBvdmVyYWxsIGNvbXBs ZXhpdHkgb2YgdGhlIHByb3RvY29sLg0KDQpUaGlzIGRvZXNuJ3Qgc291bmQgZ3JlYXQuICBJdCdz IGEgYml0IGxpa2Ugc2F5aW5nIHRoYXQgYWRkaW5nIHRoZSBIaWdncw0KbWVjaGFuaXNtIHRvIHRo ZSBzdGFuZGFyZCBtb2RlbCdzIGxhZ3JhbmdpYW4gZG9lc24ndCBtYWtlIGl0IG11Y2ggbW9yZQ0K Y29tcGxpY2F0ZSA6LSkgICgqKQ0KDQpNb3JlIHNlcmlvdXNseSB0aG91Z2gsIEknZCBsaWtlIHRv IHBvaW50IG91dCB0aGF0IGl0IGlzIG5vdCBqdXN0IGFib3V0DQppbXBsZW1lbnRhdGlvbiBjb21w bGV4aXR5LCBpdCdzIGFsc28gdGhlIGVuZXJneSBjb3N0IHBlciBwYWNrZXQgdGhhdCBpcw0KcXVp dGUgY3J1Y2lhbC4gIEkgaGF2ZW4ndCBkb25lIHRoZSBtYXRoIGJ1dCBJU1RNIHRoYXQgYnJpbmdp bmcgaW4NCmFub3RoZXIgYmF0Y2ggb2Ygbm9uLW9wdGlvbmFsIGNyeXB0byBjb21wdXRhdGlvbiBv biBhIHBlciBwYWNrZXQgYmFzaXMNCmlzIG5vdCBnb2luZyB0byBtb3ZlIHRoZSBuZWVkbGUgaW4g dGhlIHJpZ2h0IGRpcmVjdGlvbiBmb3Igc3RhY2tzIHRoYXQNCnJ1biBvbiBsb3cgcG93ZXIgKElv VCkuDQoNClRoaXMgaXMgbm90IGEgY2F0YXN0cm9waGUgLSB3ZSBoYXZlIENvQVAgYW5kIGEgKEQp VExTIHByb2ZpbGUgLSBidXQNCm5laXRoZXIgaXQncyBpZGVhbCwgc2luY2UgY3V0dGluZyBvZmYg dGhlIHNtYWxsIHRoaW5ncyBmcm9tIHRoZSB3aWRlcg0KZWNvc3lzdGVtIGNyZWF0ZXMgYW4gYXJ0 aWZpY2lhbCBnYXAgd2hpY2ggdGhlbiB3aWxsIG5lZWQgYSBtaWRkbGVib3ggdG8NCmJyaWRnZS4g IChTdXJlLCB3ZSBoYXZlIHNwZWNpZmllZCB0aGUgYmVoYXZpb3VyIG9mIGEgc2ltaWxhciBib3gN CmFscmVhZHksIGJ1dCBpdCdkIGJlIHJlYWxseSBiZXR0ZXIgaWYgdGhlIGV4dHJhIHRyYW5zbGF0 aW9uIGxvZ2ljIGNvdWxkDQpiZSBhdm9pZGVkIGluIHRoZSBmaXJzdCBwbGFjZS4pDQoNCkkgZ3Vl c3Mgd2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgUE4gZW5jcnlwdGlvbiBiZWluZyBhIGNvcmUgbWVj aGFuaXNtDQp0aGF0IGNhbid0IGJlIG5lZ290aWF0ZWQgYXQgaGFuZHNoYWtlIHRpbWUgcmVkdWNl cyBvdXIgYWJpbGl0eSB0byBsYXRlcg0KcHJvZmlsZSBRVUlDIGZvciB0aGUgSW9ULCB3aGljaCB3 b3VsZCBiZSBhIGJpdCB1bmx1Y2t5Lg0KDQpTbyB0aGUgcXVlc3Rpb24gaXM6IHdvdWxkIGl0IGJl IHBvc3NpYmxlIHRvIG1ha2UgdGhpcyBwcm9wZXJ0eSBhDQpjb25maWd1cmFibGUga25vYiBpbnN0 ZWFkPw0KDQooKikgaHR0cHM6Ly93d3cuc3ltbWV0cnltYWdhemluZS5vcmcvYXJ0aWNsZS90aGUt ZGVjb25zdHJ1Y3RlZC1zdGFuZGFyZC1tb2RlbC1lcXVhdGlvbjxodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5zeW1tZXRyeW1hZ2F6aW5lLm9y Z19hcnRpY2xlX3RoZS0yRGRlY29uc3RydWN0ZWQtMkRzdGFuZGFyZC0yRG1vZGVsLTJEZXF1YXRp b24mZD1Ed01HYVEmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNz ZjZUQSZtPVNZODdJNHZfSXFUQ0dPZHMtajVOQ093a1EwY0pjWUhHeUtkWG1NSVZuNkkmcz1ldElP MEFVSGlKbTh6dWNzV2FUZ28tWFVMRmlzQ01vRzJpRHZ3QzY5czlRJmU9Pg0KDQoNCg== --_000_2B5B329EC53940EAB8E4A96861141F52fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptdj0iaHR0cDovL21hY1ZtbFNj aGVtYVVyaSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPGhlYWQ+ DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9 IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJN aWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8IS0tW2lmICFtc29dPjxzdHls ZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhhdmlvcjp1cmwo I2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQouc2hh cGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5kaWZdLS0+PHN0 eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAyIDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpzcGFu LkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsN Cglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnAueG1zb25vcm1hbCwgbGkueG1z b25vcm1hbCwgZGl2Lnhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6eF9tc29ub3JtYWw7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KcC54bXNvYWNldGF0ZSwgbGkueG1zb2FjZXRhdGUsIGRpdi54bXNvYWNldGF0ZQ0KCXtt c28tc3R5bGUtbmFtZTp4X21zb2FjZXRhdGU7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglm b250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnAueG1zb25vcm1hbDAsIGxpLnhtc29u b3JtYWwwLCBkaXYueG1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6eF9tc29ub3JtYWwwOw0K CW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnAueG1zb2NocGRlZmF1bHQsIGxpLnhtc29jaHBkZWZhdWx0LCBkaXYueG1zb2NocGRl ZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6eF9tc29jaHBkZWZhdWx0Ow0KCW1zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ueGVt YWlsc3R5bGUxOA0KCXttc28tc3R5bGUtbmFtZTp4X2VtYWlsc3R5bGUxODsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ueGJhbGxv b250ZXh0Y2hhcg0KCXttc28tc3R5bGUtbmFtZTp4X2JhbGxvb250ZXh0Y2hhcjsNCglmb250LWZh bWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnNwYW4ueGVtYWlsc3R5bGUyMg0KCXttc28tc3R5 bGUtbmFtZTp4X2VtYWlsc3R5bGUyMjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI3DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5 bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hp dGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRo YXQgZGVwZW5kcy48YnI+DQpBcmd1YWJseSwgYWxsIHRoZSBuZXR3b3JrIGNhbiBrbm93IChvciBz aG91bGQga25vdykgaXMgb24gdGhlIGJhc2lzIG9mIGEgNS10dXBsZSwgdGh1cyB0aGUgbmV0d29y ayBjb3VsZCBhc3NpZ24gc2VxdWVuY2UgbnVtYmVycyBiYXNlZCBvbiBvcmRlciBvZiBhcnJpdmFs IG9mIGEgNS10dXBsZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkhvd2V2ZXIsIG9uZSBjb3VsZCBkbyBtb3JlIHVzZWZ1 bCBhbmQvb3IgZ2VuZXJhbCB0aGluZ3M6IElmIHRoZSBpbnRlbmRlZCBlZ3Jlc3Mgbm9kZSBpcyBr bm93biBhdCB0aGUgaW5ncmVzcyBwb2ludCBmb3IgYSBwYWNrZXQgdGhlbiwgd2hlbiBhcHBseWlu ZyB0aGUgYXBwcm9wcmlhdGUgcm91dGUsIHN0YW1wIHRoZSBwYWNrZXQgd2l0aCBhIHNlcXVlbmNl IG51bWJlciBvbi9mb3IgdGhhdCByb3V0ZS4gQXQgdGhhdCBwb2ludCB5b3XigJlyZSBhYmxlIHRv DQogbG9vayBhdCByZW9yZGVyaW5nIGFjcm9zcyBhbnkvYWxsIGZsb3dzIHdpdGhpbiBhIHJvdXRl LiBUaGlzIGlzIGEgc3Ryb25nZXIgb3JkZXJpbmcgZ3VhcmFudGVlIHRoYW4gaXMgbmVjZXNzYXJ5 LCBhbmQgdGh1cyBpcyBzdWZmaWNpZW50IGZvciBhbnkgaW5kaXZpZHVhbCBmbG93IG9uIHRoYXQg cm91dGUuIEluIG15IGJlbGllZiwgdGhpcyB3b3VsZCBiZSBhIHN1cGVyaW9yIG1ldHJpYyBmb3Ig bmV0d29yayBoZWFsdGggZGV0ZWN0aW9uIG92ZXJhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQotPVI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJvbmkgRXZlbiAmbHQ7cm9uLmV2ZW4udGx2 QGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+U3VuZGF5LCBGZWJydWFyeSA0LCAyMDE4 IGF0IDg6NTggUE08YnI+DQo8Yj5UbzogPC9iPlJvYmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29t Jmd0OywgJnF1b3Q7J1JvbmkgRXZlbiAoQSknJnF1b3Q7ICZsdDtyb25pLmV2ZW5AaHVhd2VpLmNv bSZndDssICdQaW90ciBHYWxlY2tpJyAmbHQ7cGlvdHJfZ2FsZWNraUBhZmZpcm1lZG5ldHdvcmtz LmNvbSZndDssICdKYW5hIEl5ZW5nYXInICZsdDtqcmlAZ29vZ2xlLmNvbSZndDssICZxdW90OydG b3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBVSyknJnF1b3Q7ICZsdDt0aG9t YXMuZm9zc2F0aUBub2tpYS5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4nR29ycnkgRmFpcmh1c3Qn ICZsdDtnb3JyeUBlcmcuYWJkbi5hYy51ayZndDssICdFcmljIFJlc2NvcmxhJyAmbHQ7ZWtyQHJ0 Zm0uY29tJmd0OywgJ0NocmlzdGlhbiBIdWl0ZW1hJyAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZn dDssICZxdW90OydFZ2dlcnQsIExhcnMnJnF1b3Q7ICZsdDtsYXJzQG5ldGFwcC5jb20mZ3Q7LCAn QnJpYW4gVHJhbW1lbGwnICZsdDtpZXRmQHRyYW1tZWxsLmNoJmd0OywgJ01pcmphIEvDvGhsZXdp bmQnICZsdDttaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoJmd0OywgJ1FVSUMNCiBXRycg Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7LCAnTWFydGluIFRob21zb24nICZsdDttYXJ0aW4udGhvbXNv bkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBQYWNrZXQgbnVtYmVyIGVu Y3J5cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+RG9lcyBub3QgaXQgbWVhbiB0aGF0IHRoZSBuZXR3b3JrIG5lZWQg dG8gaWRlbnRpZnkgcGFja2V0cyAmbmJzcDt0aGF0IGFyZSBmcm9tIHRoZSBzYW1lIHF1aWMgY29u bmVjdGlvbiB0byBtYWtlIHN1Y2ggd3JhcHBpbmc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJvbmk8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmIj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Um9iZXJ0byBQZW9uPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMDUs IDIwMTggMjozOCBBTTxicj4NCjxiPlRvOjwvYj4gUm9uaSBFdmVuIChBKTsgUGlvdHIgR2FsZWNr aTsgSmFuYSBJeWVuZ2FyOyBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBV Syk8YnI+DQo8Yj5DYzo8L2I+IEdvcnJ5IEZhaXJodXN0OyBFcmljIFJlc2NvcmxhOyBDaHJpc3Rp YW4gSHVpdGVtYTsgRWdnZXJ0LCBMYXJzOyBCcmlhbiBUcmFtbWVsbDsgTWlyamEgS8O8aGxld2lu ZDsgUVVJQyBXRzsgTWFydGluIFRob21zb248YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tl dCBudW1iZXIgZW5jcnlwdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9ImRp dnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkEgbmV0d29yayBjb3VsZCBjYXJy eSB3aGF0ZXZlciBwcm90b2NvbCBpdCB3aXNoZWQgdG8sIGkuZS4gYnkgd3JhcHBpbmcgYW55L2Fs bCBwYWNrZXRzIG9uIGluZ3Jlc3MgdG8gdGhlIG5ldHdvcmssJm5ic3A7YW5kIHRoZW4mbmJzcDt1 bi13cmFwcGluZyB3aGVuIGZvcndhcmRpbmcgdG8gYW5vdGhlciBuZXR3b3JrLiBUaGlzIHdvdWxk IGFsbG93IGEgbmV0d29yaw0KIHRvIHJlY29yZCBhbmQgdHJhY2sgd2hhdGV2ZXIgaXQgd2FudGVk IHRvIHdpdGhvdXQgcGxhY2luZyBjb25zdHJhaW50cyBvbiBsYXllcnMgd2hpY2ggc2hvdWxkIGJl IGFib3ZlIGl0LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxi cj4NCklmIHRoZSBuZXR3b3JrIHBsYWNlZCBhIHNlcXVlbmNlIG51bWJlciBvbiBpbmNvbWluZyBw YWNrZXRzLCBpdCBjb3VsZCBkZXRlY3QgcmVvcmRlcmluZyBhY3Jvc3MgYWxsIGZsb3dzLiBJZiBp dCBkbyBzbyBvbiBhIDUtdHVwbGUgYmFzaXMsIGl0IGNvdWxkIGRldGVjdCByZW9yZGVyaW5nL2R1 cGxpY2F0aW9uL2xvc3MgYWNyb3NzIGFueSA1LXR1cGxlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPi09Ujwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9y bWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9 IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJkaXZScGx5 RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+IFJvbmkg RXZlbiAoQSkgJmx0O3JvbmkuZXZlbkBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBT YXR1cmRheSwgRmVicnVhcnkgMywgMjAxOCAxMTo0NzowNiBQTTxicj4NCjxiPlRvOjwvYj4gUm9i ZXJ0byBQZW9uOyBQaW90ciBHYWxlY2tpOyBKYW5hIEl5ZW5nYXI7IEZvc3NhdGksIFRob21hcyAo Tm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKTxicj4NCjxiPkNjOjwvYj4gR29ycnkgRmFpcmh1c3Q7 IEVyaWMgUmVzY29ybGE7IE1pcmphIEvDvGhsZXdpbmQ7IEVnZ2VydCwgTGFyczsgQnJpYW4gVHJh bW1lbGw7IENocmlzdGlhbiBIdWl0ZW1hOyBRVUlDIFdHOyBNYXJ0aW4gVGhvbXNvbjxicj4NCjxi PlN1YmplY3Q6PC9iPiBSRTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPC9zcGFuPiA8bzpwPjwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDssc2VyaWYiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4 bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPk5ldHdvcmsgbW9uaXRvcmluZzo8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlm Ij5OZXR3b3JrcyBtYXkgYWx3YXlzIHdyYXAgdGhlIHBhY2tldChzKSB0aGV5IGhhdmUgcmVjZWl2 ZWQgd2l0aCB3aGF0ZXZlciBkYXRhIHRoZXkgd2lzaCwgYW5kIHVud3JhcCBiZWZvcmUgZm9yd2Fy ZGluZy4gVGhpcyBjYW4gYWxsb3cgYW55IG5ldHdvcmsgdG8gdW5kZXJzdGFuZCBvcmRlcmluZywm bmJzcDsNCiBsb3NzLCBldGMgd2l0aGluIGl0cyBib3VuZGFyaWVzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiPlJFLSBzbyB5b3UgYXJlIHNheWluZyB0aGF0IHdlIGNhbiBmb3IgZXhhbXBsZSAmbmJz cDtsZXZlcmFnZSAmbmJzcDtSVFAgYW5kIGRlZmluZSBSVFAgcGF5bG9hZCBmb3IgUVVJQyB0aGF0 IHdpbGwgY2FycnkgUVVJQyBwYWNrZXRzLCB3ZSB3aWxsIGp1c3QgbmVlZCB0byByZXNvbHZlIHRo ZSBNVFUgc2l6ZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7LHNlcmlmIj5Sb25pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Inhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydG8gUGVvbjxicj4NCjxiPlNlbnQ6 PC9iPiBTYXR1cmRheSwgRmVicnVhcnkgMDMsIDIwMTggODozOCBQTTxicj4NCjxiPlRvOjwvYj4g UGlvdHIgR2FsZWNraTsgSmFuYSBJeWVuZ2FyOyBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0Iv Q2FtYnJpZGdlLCBVSyk8YnI+DQo8Yj5DYzo8L2I+IEdvcnJ5IEZhaXJodXN0OyBFcmljIFJlc2Nv cmxhOyBNaXJqYSBLw7xobGV3aW5kOyBFZ2dlcnQsIExhcnM7IEJyaWFuIFRyYW1tZWxsOyBDaHJp c3RpYW4gSHVpdGVtYTsgUVVJQyBXRzsgTWFydGluIFRob21zb248YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+T3NzaWZp Y2F0aW9uOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4 bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPkluIHRoZSBwYXN0IHRjcCBtaWRkbGVib3hl cyBleHBlY3RlZCBpbi1vcmRlciwgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nIG9mZnNldHMgYW5k IHRyaWVkIHRvIGZpeCByZW9yZGVyaW5nIGJlZm9yZSBmb3J3YXJkaW5nLiBUaGlzIG1pZGRsZWJv eCBiZWhhdmlvciwgcHJlZGljYXRlZCBvbiBvYnNlcnZhYmxlDQogZmxvd3MsIHByZXZlbnRlZCBk ZXBsb3ltZW50IG9mIHRoaW5ncyB3aGljaCB3b3VsZCBoYXZlIG1hZGUgdGNwIG1vcmUgZWZmaWNp ZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNv bm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PiZuYnNwO1RoaXMgaXMgdGhlIGtpbmQgb2Ygbm9uLXRoZW9yZXRpY2FsIG9zc2lmaWNhdGlvbiB0 aGF0IGRyb3ZlIHRoZSBjcmVhdGlvbiBvZiBRVUlDIGluIHRoZSBmaXJzdCBwbGFjZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj5OZXR3b3JrIG1v bml0b3Jpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Inhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+TmV0d29ya3MgbWF5IGFsd2F5cyB3cmFw IHRoZSBwYWNrZXQocykgdGhleSBoYXZlIHJlY2VpdmVkIHdpdGggd2hhdGV2ZXIgZGF0YSB0aGV5 IHdpc2gsIGFuZCB1bndyYXAgYmVmb3JlIGZvcndhcmRpbmcuIFRoaXMgY2FuIGFsbG93IGFueSBu ZXR3b3JrIHRvIHVuZGVyc3RhbmQgb3JkZXJpbmcsJm5ic3A7DQogbG9zcywgZXRjIHdpdGhpbiBp dHMgYm91bmRhcmllcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj5EZWJ1Z2dpbmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+RGVidWdnaW5nIG9m IGZsb3dzIGNhbiBzdGlsbCBoYXBwZW4gZm9yIGZsb3dzIHRoYXQgd2lzaCB0byBiZSBkZWJ1Z2dl ZC0tIHRoZSBRVUlDIGNvbm5lY3Rpb24ncyBrZXkgbWF0ZXJpYWwocykgY2FuIGJlIHNoYXJlZCBt YW51YWxseSBhbmQgdXNlZCBieSB0aGUgZGVidWdnaW5nIHRvb2wuIFRoaXMNCiBpcyBob3cgb25l IGRlYnVncyBodHRwMiwgaHR0cHMsIGV0Yy4gYWxyZWFkeSB0b2RheS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tPVI8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7 LHNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieG1zb25vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4tLS0tLS0tLSBPcmlnaW5h bCBtZXNzYWdlIC0tLS0tLS0tPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Inhtc29ub3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+RnJvbTogUGlvdHIgR2Fs ZWNraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBpb3RyX2dhbGVja2lAYWZmaXJtZWRuZXR3b3Jrcy5j b20iPnBpb3RyX2dhbGVja2lAYWZmaXJtZWRuZXR3b3Jrcy5jb208L2E+Jmd0Ow0KPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZiI+RGF0ZTogMi8yLzE4IDc6MDAgUE0gKEdNVC0wODowMCkNCjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDssc2VyaWYiPlRvOiBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmlA Z29vZ2xlLmNvbSI+anJpQGdvb2dsZS5jb208L2E+Jmd0OywgJnF1b3Q7Rm9zc2F0aSwgVGhvbWFz IChOb2tpYSAtIEdCL0NhbWJyaWRnZSwgVUspJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGhv bWFzLmZvc3NhdGlAbm9raWEuY29tIj50aG9tYXMuZm9zc2F0aUBub2tpYS5jb208L2E+Jmd0Ow0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Q2M6IEdvcnJ5IEZhaXJodXN0ICZsdDs8YSBocmVmPSJt YWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiPmdvcnJ5QGVyZy5hYmRuLmFjLnVrPC9hPiZndDss IEVyaWMgUmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZt LmNvbTwvYT4mZ3Q7LCBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRl bWFAaHVpdGVtYS5uZXQiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OywNCiAmcXVvdDtFZ2dl cnQsIExhcnMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsYXJzQG5ldGFwcC5jb20iPmxhcnNA bmV0YXBwLmNvbTwvYT4mZ3Q7LCBCcmlhbiBUcmFtbWVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmll dGZAdHJhbW1lbGwuY2giPmlldGZAdHJhbW1lbGwuY2g8L2E+Jmd0OywgTWlyamEgS8O8aGxld2lu ZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2giPm1p cmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+Jmd0OywgUVVJQyBXRw0KICZsdDs8YSBo cmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7LCBNYXJ0aW4g VGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSI+bWFy dGluLnRob21zb25AZ21haWwuY29tPC9hPiZndDsNCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPlN1 YmplY3Q6IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0ieG1zb25vcm1hbCI+V2hhdCBpcyB0aGUgZ3JvdXDigJlzIHByb3Bvc2FsIGZvciBh bGxvd2luZyBuZXR3b3JrIG1vbml0b3JpbmcgdG9vbHMgdG8gZGV0ZWN0IHBhY2tldCByZXRyYW5z bWlzc2lvbiBvciBwYWNrZXQgcmVvcmRlcmluZyA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i eG1zb25vcm1hbCI+VGhlc2UgbWV0cmljcyBhcmUgcHJldHR5IHN0cmFpZ2h0Zm9yd2FyZCB0byBt ZWFzdXJlIGZvciBUQ1AgZmxvd3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1h bCI+VG9vbHMgbGlrZSBXaXJlc2hhcmsgY2FuIGFuYWx5emUgcGFja2V0cyBhbmQgc3BvdCBpc3N1 ZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+SG93IGNhbiB0aGUgbmV0 d29yayB0b29scyBwZXJmb3JtIHRoaXMga2luZCBvZiBtZWFzdXJlbWVudHMgZm9yIFFVSUMgZmxv d3MgaWYgUE4gZmllbGQgaXMgZW5jcnlwdGVkPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inht c29ub3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPjxiPkZyb206PC9iPiBR VUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SmFuYSBJeWVuZ2FyPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMDIsIDIwMTggOTozMSBQTTxicj4NCjxi PlRvOjwvYj4gRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSwgVUspICZsdDs8 YSBocmVmPSJtYWlsdG86dGhvbWFzLmZvc3NhdGlAbm9raWEuY29tIj50aG9tYXMuZm9zc2F0aUBu b2tpYS5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gR29ycnkgRmFpcmh1c3QgJmx0OzxhIGhy ZWY9Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+ Jmd0OzsgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ZWty QHJ0Zm0uY29tPC9hPiZndDs7IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9Im1haWx0bzpt aXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5l dGh6LmNoPC9hPiZndDs7DQogQ2hyaXN0aWFuIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpo dWl0ZW1hQGh1aXRlbWEubmV0Ij5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDs7IEJyaWFuIFRy YW1tZWxsICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaCI+aWV0ZkB0cmFtbWVs bC5jaDwvYT4mZ3Q7OyBFZ2dlcnQsIExhcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpsYXJzQG5ldGFw cC5jb20iPmxhcnNAbmV0YXBwLmNvbTwvYT4mZ3Q7OyBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWls dG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7Ow0KIE1hcnRpbiBUaG9tc29u ICZsdDs8YSBocmVmPSJtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tIj5tYXJ0aW4udGhv bXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUGFja2V0IG51 bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwiPkEgZmV3IHBv aW50cyBhcyBJIGNhdGNoIHVwIG9uIHRoaXMgdGhyZWFkLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj5GaXJzdCwgSSdsbCByZW1pbmQgZm9sa3MgdGhhdCBR VUlDIGlzIGFuIGVuY3J5cHRlZCB0cmFuc3BvcnQuIEkgc2F5IHRoaXMgYmVjYXVzZSB0aGUgY29z dCBvZiB0aGlzIG9wZXJhdGlvbiBpcyB0cml2aWFsIGluIHRoZSBjb250ZXh0IG9mIGVuY3J5cHRp bmcgZXZlcnkgcGFja2V0LiBUaGUgY29zdCBpcyBib3JuZSBhdCB0aGUgc2VydmVycyBhbmQgbm90 IGF0IG1pZGRsZWJveGVzLCBzbyB0aGUgYWRkaXRpb25hbA0KIGNyeXB0byBjb3N0IGlzIGJhc2lj YWxseSB0cml2aWFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inht c29ub3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Inhtc29ub3JtYWwiPlNlY29uZCwgdGhpcyBzaW1wbGlmaWVzIGFuZCBpbmNyZWFzZXMgcm9idXN0 bmVzcyBvZiBpbXBsZW1lbnRhdGlvbi4gQXZvaWRpbmcgcmFuZG9tIFBOIGp1bXBzLCBhcyBLYXp1 aG8gcG9pbnRzIG91dCwgbWFrZXMgc3BlY2lhbC1jYXNpbmcgb2YgY29kZSB1bm5lY2Vzc2FyeS4g U3BlY2lhbCBjb2RlIHRoYXQgaXMgZXhlcmNpc2VkIG9jY2FzaW9uYWxseSBpcyBhIHN0cm9uZyBi dWcgYXR0cmFjdG9yLCBhbmQgSQ0KIHdvdWxkIHN0cm9uZ2x5IGFyZ3VlIGZvciBhcyBmZXcgb2Yg dGhvc2UgYXMgcG9zc2libGUgaW4gaW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+VGhpcmQsIHllcywgb3NzaWZpY2F0 aW9uIGlzIGEgcmVhbCBjb25jZXJuLiBBIHNpbXBsZSBleGFtcGxlOiB1c2luZyBpbmNyZWFzaW5n IHBhY2tldCBudW1iZXJzIGFzIGEgc2lnbmF0dXJlIGZvciBkZXRlY3RpbmcgUVVJQy4gRXZlbiBp ZiB5b3UgYXJndWUgYWdhaW5zdCB0aGlzIGV4YW1wbGUsIHRoZXJlIGFyZSBpbm5vdmF0aXZlIHdh eXMgaW4gd2hpY2ggb3NzaWZpY2F0aW9uIHdpbGwgaGFwcGVuLiBUaGlzDQogaXMgYmFzZWQgb24g YSB0cnVlIHN0b3J5OiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5k OndoaXRlIj5XZSBoYWQgbm8gaWRlYSBob3cgR1FVSUMncyBmbGFncyBmaWVsZCBjb3VsZCBnZXQg b3NzaWZpZWQsIHRoZSB2YWx1ZSB0aGF0IHdhcyBiZWluZyB1c2VkIGNvbW1vbmx5IGJlY2FtZSB1 c2VkIGFzIGEgc2lnbmF0dXJlIGZvciBRVUlDIHRyYWZmaWMNCiAoc2VlIFNlY3Rpb24gNy41IGlu IHRoZSA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3N0YXRpYy5nb29nbGV1c2VyY29udGVudC5jb21fbWVkaWFfcmVzZWFyY2guZ29v Z2xlLmNvbV9lbl9wdWJzX2FyY2hpdmVfNDY0MDMucGRmJmFtcDtkPUR3TUdhUSZhbXA7Yz01VkQw UlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPUMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEEmYW1wO209U1k4 N0k0dl9JcVRDR09kcy1qNU5DT3drUTBjSmNZSEd5S2RYbU1JVm42SSZhbXA7cz1VOW82ZEktZHd6 S3d2WEh2dm12N1d0Vm04NHB1dnhoYVAwY04yb2YzVnZBJmFtcDtlPSI+DQpTSUdDT01NIFFVSUMg cGFwZXI8L2E+KS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0ieG1zb25vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0ieG1zb25vcm1hbCI+VGhlcmUncyBhIHdpbiBoZXJlIGluIHRlcm1zIG9mIGltcGxlbWVu dGF0aW9uIGNvbXBsZXhpdHkgYW5kIHNldmVyYWwgaW1wbGVtZW50ZXJzIGhhdmUgc2FpZCBzby4g VGhlcmUncyBhIHdpbiBpbiB0ZXJtcyBvZiBvc3NpZmljYXRpb24gYW5kIG91ciBleHBlcmllbmNl IHNheXMgc28uIFRoZXJlJ3MgYSBwb3RlbnRpYWwgbG9zcyBvZiBtYW5hZ2VhYmlsaXR5LCBpbiBi ZWluZyBhYmxlIHRvIGRldGVjdCByZW9yZGVyaW5nLg0KIFRoaXMgaXMgdGhlIHRyYWRlLW9mZiwg YW5kIEkgYW0gc3RpbGwgaW4gZmF2b3Igb2YgZW5jcnlwdGluZyBwYWNrZXQgbnVtYmVycy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Inhtc29ub3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJ4bXNvbm9ybWFsIj5PbiBG cmksIEZlYiAyLCAyMDE4IGF0IDc6MzIgQU0sIEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9D YW1icmlkZ2UsIFVLKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRob21hcy5mb3NzYXRpQG5va2lhLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRob21hcy5mb3NzYXRpQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0ieG1zb25vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5PbiAzMS8wMS8yMDE4LCAxMDowNiwgJnF1b3Q7UVVJQyBvbiBiZWhhbGYgb2YgRWdnZXJ0 LCBMYXJzJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5x dWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmxh cnNAbmV0YXBwLmNvbSI+bGFyc0BuZXRhcHAuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyBP biAyMDE4LTEtMzEsIGF0IDEwOjUyLCBHb3JyeSBGYWlyaHVyc3QgJmx0OzxhIGhyZWY9Im1haWx0 bzpnb3JyeUBlcmcuYWJkbi5hYy51ayI+Z29ycnlAZXJnLmFiZG4uYWMudWs8L2E+Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7ICZndDsgJiM0MzsxIC0gU2ltcGx5OiBUaGlzICppcyogY29tcGxpY2F0ZWQg YW5kIHNlZW1zIHRvIGFkZCBsaXR0bGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgU28gYXMgYW4gaW1w bGVtZW50b3IgKGNoYWlyIGhhdCBvZmYpLCB0aGlzIGFkZHMgdmVyeSBsaXR0bGUgdG8gdGhlPGJy Pg0KJmd0OyBvdmVyYWxsIGNvbXBsZXhpdHkgb2YgdGhlIHByb3RvY29sLjxicj4NCjxicj4NClRo aXMgZG9lc24ndCBzb3VuZCBncmVhdC4mbmJzcDsgSXQncyBhIGJpdCBsaWtlIHNheWluZyB0aGF0 IGFkZGluZyB0aGUgSGlnZ3M8YnI+DQptZWNoYW5pc20gdG8gdGhlIHN0YW5kYXJkIG1vZGVsJ3Mg bGFncmFuZ2lhbiBkb2Vzbid0IG1ha2UgaXQgbXVjaCBtb3JlPGJyPg0KY29tcGxpY2F0ZSA6LSkm bmJzcDsgKCopPGJyPg0KPGJyPg0KTW9yZSBzZXJpb3VzbHkgdGhvdWdoLCBJJ2QgbGlrZSB0byBw b2ludCBvdXQgdGhhdCBpdCBpcyBub3QganVzdCBhYm91dDxicj4NCmltcGxlbWVudGF0aW9uIGNv bXBsZXhpdHksIGl0J3MgYWxzbyB0aGUgZW5lcmd5IGNvc3QgcGVyIHBhY2tldCB0aGF0IGlzPGJy Pg0KcXVpdGUgY3J1Y2lhbC4mbmJzcDsgSSBoYXZlbid0IGRvbmUgdGhlIG1hdGggYnV0IElTVE0g dGhhdCBicmluZ2luZyBpbjxicj4NCmFub3RoZXIgYmF0Y2ggb2Ygbm9uLW9wdGlvbmFsIGNyeXB0 byBjb21wdXRhdGlvbiBvbiBhIHBlciBwYWNrZXQgYmFzaXM8YnI+DQppcyBub3QgZ29pbmcgdG8g bW92ZSB0aGUgbmVlZGxlIGluIHRoZSByaWdodCBkaXJlY3Rpb24gZm9yIHN0YWNrcyB0aGF0PGJy Pg0KcnVuIG9uIGxvdyBwb3dlciAoSW9UKS48YnI+DQo8YnI+DQpUaGlzIGlzIG5vdCBhIGNhdGFz dHJvcGhlIC0gd2UgaGF2ZSBDb0FQIGFuZCBhIChEKVRMUyBwcm9maWxlIC0gYnV0PGJyPg0KbmVp dGhlciBpdCdzIGlkZWFsLCBzaW5jZSBjdXR0aW5nIG9mZiB0aGUgc21hbGwgdGhpbmdzIGZyb20g dGhlIHdpZGVyPGJyPg0KZWNvc3lzdGVtIGNyZWF0ZXMgYW4gYXJ0aWZpY2lhbCBnYXAgd2hpY2gg dGhlbiB3aWxsIG5lZWQgYSBtaWRkbGVib3ggdG88YnI+DQpicmlkZ2UuJm5ic3A7IChTdXJlLCB3 ZSBoYXZlIHNwZWNpZmllZCB0aGUgYmVoYXZpb3VyIG9mIGEgc2ltaWxhciBib3g8YnI+DQphbHJl YWR5LCBidXQgaXQnZCBiZSByZWFsbHkgYmV0dGVyIGlmIHRoZSBleHRyYSB0cmFuc2xhdGlvbiBs b2dpYyBjb3VsZDxicj4NCmJlIGF2b2lkZWQgaW4gdGhlIGZpcnN0IHBsYWNlLik8YnI+DQo8YnI+ DQpJIGd1ZXNzIHdoYXQgSSdtIHNheWluZyBpcyB0aGF0IFBOIGVuY3J5cHRpb24gYmVpbmcgYSBj b3JlIG1lY2hhbmlzbTxicj4NCnRoYXQgY2FuJ3QgYmUgbmVnb3RpYXRlZCBhdCBoYW5kc2hha2Ug dGltZSByZWR1Y2VzIG91ciBhYmlsaXR5IHRvIGxhdGVyPGJyPg0KcHJvZmlsZSBRVUlDIGZvciB0 aGUgSW9ULCB3aGljaCB3b3VsZCBiZSBhIGJpdCB1bmx1Y2t5Ljxicj4NCjxicj4NClNvIHRoZSBx dWVzdGlvbiBpczogd291bGQgaXQgYmUgcG9zc2libGUgdG8gbWFrZSB0aGlzIHByb3BlcnR5IGE8 YnI+DQpjb25maWd1cmFibGUga25vYiBpbnN0ZWFkPzxicj4NCjxicj4NCigqKSA8YSBocmVmPSJo dHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5z eW1tZXRyeW1hZ2F6aW5lLm9yZ19hcnRpY2xlX3RoZS0yRGRlY29uc3RydWN0ZWQtMkRzdGFuZGFy ZC0yRG1vZGVsLTJEZXF1YXRpb24mYW1wO2Q9RHdNR2FRJmFtcDtjPTVWRDBSVHRObFRoM3ljZDQx YjNNVXcmYW1wO3I9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZhbXA7bT1TWTg3STR2X0lxVENHT2Rz LWo1TkNPd2tRMGNKY1lIR3lLZFhtTUlWbjZJJmFtcDtzPWV0SU8wQVVIaUptOHp1Y3NXYVRnby1Y VUxGaXNDTW9HMmlEdndDNjlzOVEmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3 dy5zeW1tZXRyeW1hZ2F6aW5lLm9yZy9hcnRpY2xlL3RoZS1kZWNvbnN0cnVjdGVkLXN0YW5kYXJk LW1vZGVsLWVxdWF0aW9uPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0ieG1zb25vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_2B5B329EC53940EAB8E4A96861141F52fbcom_-- From nobody Sun Feb 4 23:51:43 2018 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 27CDE126CE8 for ; Sun, 4 Feb 2018 23:51:42 -0800 (PST) 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, 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=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 HX1b688cAuFH for ; Sun, 4 Feb 2018 23:51:40 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 89DE01241F5 for ; Sun, 4 Feb 2018 23:51:40 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id o1so3598156pgn.4 for ; Sun, 04 Feb 2018 23:51:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=qHTpiqgVLFFM/wVcfFWi4dmZEEJYOmUBZc8KCaPdGQw=; b=ccaMFth4bl80E9ai7sn+d68+n9Qt+WtuTeJ7xMVX9UUBPKaYVch/jmyzvFIosSMTgG tChoYKpmwNYtvVKIhDWhdy9FhCp+vQc1N26cHnIRVais0ZvzP96h4+PFEAoosAPbfI89 MMoW0xSi+C+WDGiM7J6qCtUHTHT8zN6wxx+NY2+KhsoVhEbF2+eK5p4UsJsGJAFdzSa6 QHYAu81O3QnMIieVZ3Cwp1OHsVGIfdffk2xJdbfUtxWdgR/o/Wef0TUt6PDq2r67mCTj EXGR2Z+DSYr7SIfL9jrMpg+CvbbwwzTzxSZbOemml3lta/mqTM+ZvU8crKc3kVsWImg3 qJfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=qHTpiqgVLFFM/wVcfFWi4dmZEEJYOmUBZc8KCaPdGQw=; b=VqREtQv/5NuBcobZwIemZP8ROYQ0uBDsEhr4ZB0pqpBtfRBsq2SqMdgK0RbmBwvS2k FXLUfRRAtG7T217MTf73A+wuAJrlpXBujAoEnMHtpPH/ccno6B2tGHGD30u4Crg2UoVH uiYqNntLpENJhOWuAAoQsKPhhthCDdTrLnlThcaFzD2GJ/uf58P66o5b1/1220mQfLaK rnddMOqMQQYICys6fdw2TnFBXZVkZcAzSa6GcTMeLj72rNmfZ6dTLgX1kfHiJQZKXuUh yKMOLOwSCDlbIGOez+87XkIfmN/Qx0RKTyBdFyp4+9vKbjebqEIWKUwnXknWtsUAqmvG KO2Q== X-Gm-Message-State: AKwxytdym276YZIbuG3owkgAy9ZufLIC7SUAaukwNyLbe6CWazdZ1zTj If6C5Q9InIovV1o9YYqpdd4= X-Google-Smtp-Source: AH8x225pqaRr6J0404LllI5C6GlwARIApR784ESqzwt3TsOn4dOES9cYEA9gxLlxxFsZUREuOF7rpQ== X-Received: by 10.99.117.87 with SMTP id f23mr8353542pgn.453.1517817100078; Sun, 04 Feb 2018 23:51:40 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id 12sm16764316pfr.147.2018.02.04.23.51.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 04 Feb 2018 23:51:39 -0800 (PST) From: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Mark Nottingham , QUIC WG CC: Lars Eggert Subject: Re: Call for Adoption: Invariants Thread-Topic: Call for Adoption: Invariants Thread-Index: AUY2OTQ2mv+s5soMjSZWGIW+IBxM+JrQOeFT X-MS-Exchange-MessageSentRepresentingType: 2 Date: Mon, 5 Feb 2018 07:51:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB17667AAB19D4A9288FD5BAF3ACFE0DB6PR10MB1766EURP_" 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: Mon, 05 Feb 2018 07:51:42 -0000 --_000_DB6PR10MB17667AAB19D4A9288FD5BAF3ACFE0DB6PR10MB1766EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Only concern is when it takes effect since it likely needs adjustments. And= perhaps a procedure to handle invariant changes since everything changes. ________________________________ From: QUIC on behalf of Mark Nottingham Sent: Monday, February 5, 2018 7:07:45 AM To: QUIC WG Cc: Lars Eggert Subject: Call for Adoption: Invariants At the Melbourne meeting, there was strong support for adopting Martin's in= variants draft: https://tools.ietf.org/html/draft-thomson-quic-invariants-00 Any objections / concerns about doing so? Unless we hear otherwise, we'll a= dopt at the end of the week. Cheers, -- Mark Nottingham https://www.mnot.net/ --_000_DB6PR10MB17667AAB19D4A9288FD5BAF3ACFE0DB6PR10MB1766EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Only concern is when it takes effect since it = likely needs adjustments. And perhaps a procedure to handle invariant chang= es since everything changes.
From: QUIC <quic-bounc= es@ietf.org> on behalf of Mark Nottingham <mnot@mnot.net>
Sent: Monday, February 5, 2018 7:07:45 AM
To: QUIC WG
Cc: Lars Eggert
Subject: Call for Adoption: Invariants
 
At the Melbourne meeting, there was strong support= for adopting Martin's invariants draft:

ht= tps://tools.ietf.org/html/draft-thomson-quic-invariants-00

Any objections / concerns about doing so? Unless we hear otherwise, we'll a= dopt at the end of the week.

Cheers,

--
Mark Nottingham   https://www.m= not.net/

 --_000_DB6PR10MB17667AAB19D4A9288FD5BAF3ACFE0DB6PR10MB1766EURP_-- From nobody Mon Feb 5 00:33:41 2018 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 7A208129516 for ; Mon, 5 Feb 2018 00:33:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ep3loHdLZAku for ; Mon, 5 Feb 2018 00:33:37 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB81112946D for ; Mon, 5 Feb 2018 00:33:35 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 1E3A2340D1D; Mon, 5 Feb 2018 09:33:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.5852); Mon, 5 Feb 2018 09:33:32 +0100 (CET) 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; Mon, 5 Feb 2018 09:33:32 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44327363; Mon, 05 Feb 2018 09:33:32 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_6E6BE53F-4301-41AD-8AE3-B08ECE5967B5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Call for Adoption: Invariants Date: Mon, 5 Feb 2018 09:33:33 +0100 In-Reply-To: Cc: Mark Nottingham , QUIC WG , Lars Eggert To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= References: 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, 05 Feb 2018 08:33:39 -0000 --Apple-Mail=_6E6BE53F-4301-41AD-8AE3-B08ECE5967B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all, I support adoption of the invariants draft. > On 5 Feb 2018, at 08:51, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: >=20 > Only concern is when it takes effect since it likely needs = adjustments. I'd presume that invariants is published simultaneously with the version = 1 spec. > And perhaps a procedure to handle invariant changes since everything = changes. Noted, though the point of declaring something an invariant is to say = "the meaning of this part of the wire image, expressed as a bit offset, = will never change". You can add constraints to the invariants, but if = you think you might remove a constraint, then it's not an invariant by = definition. Cheers, Brian > From: QUIC on behalf of Mark Nottingham = > Sent: Monday, February 5, 2018 7:07:45 AM > To: QUIC WG > Cc: Lars Eggert > Subject: Call for Adoption: Invariants >=20 > At the Melbourne meeting, there was strong support for adopting = Martin's invariants draft: >=20 > https://tools.ietf.org/html/draft-thomson-quic-invariants-00 >=20 > Any objections / concerns about doing so? Unless we hear otherwise, = we'll adopt at the end of the week. >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ --Apple-Mail=_6E6BE53F-4301-41AD-8AE3-B08ECE5967B5 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp4Ft0ACgkQihK3vwvq RqND9RAAje2IbboY6ctEcp1VyLj7JRqIrJ9B/xO7b7x11kds6ocW4TOACEudmKF0 ogIpwbvs7drx2cJvqVaxECQshnUCnYrynX+NuL7Wms1U7ymx3viAL/5bKWAUaS1g VYUHZVa7igDBaZAblnj/JKeW7ELq2lhh/Y7gOePbYt/d9z2BSGH6icOvARY4i+Lh v5ZqL4LHua+s0bwlJMuivZ7G/gTbEX1Uormn48aDfPo6p65ozYxRYRlW6r9ncswD 89eBxEUXAUVBSPlh3eFnDCdSIOWtPW/q3sRjxi1RG7mCFxmen3uIhgFC+WSP3sK5 37x9i221rPxaf14GVMmOJFjooysCCCxDEVZTNKRH/+sgH8HxGlqbGLCUV7PeaBMF kCojZUpRC6EB3S9BrqV2REeeEADbUwSLq7ib8xlnuoQHn/1AX+7r/CtNSqESW1Ur r3HhkGqyBJ7I/y6INska44Y9UUntDokqRpPPc16Gq1MyU7ZGO6o982UukhqfLgRI WpfhkMQTbnFzgX8/nJ3zev5WsKuNQPbQRMiCWfoiEYZL0Nk02A8XIkcrusGmPLDS /jY13WDygD26QiSrgDBeMb3FnCnMZfJAU25xG1gFvSXOLGCFRNODvp1IjY76BLjw hwB6bGeAKioHeu6meFPxcaoSlsOrRPCpqWX0bulEM0lX6EWewDg= =XoVn -----END PGP SIGNATURE----- --Apple-Mail=_6E6BE53F-4301-41AD-8AE3-B08ECE5967B5-- From nobody Mon Feb 5 00:37:05 2018 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 AFBEE12946D for ; Mon, 5 Feb 2018 00:37:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 1nO6nbmhCliX for ; Mon, 5 Feb 2018 00:37:02 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCA5126BF7 for ; Mon, 5 Feb 2018 00:37:02 -0800 (PST) Received: from Gs-MacBook-Pro.local (unknown [109.144.213.225]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 33F2B1B00082; Mon, 5 Feb 2018 08:36:41 +0000 (GMT) Message-ID: <5A781798.6010101@erg.abdn.ac.uk> Date: Mon, 05 Feb 2018 08:36:40 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Brian Trammell (IETF)" CC: Roberto Peon , QUIC WG Subject: Re: Reducing ossification through protocol design (was Re: Packet number encryption) References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit 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, 05 Feb 2018 08:37:05 -0000 On 04/02/2018, 21:31, Brian Trammell (IETF) wrote: > hi Roberto, all, > > (trimming CC, forking thread, since this *really* is separate from the question of packet number encryption.) > >> On 3 Feb 2018, at 19:37, Roberto Peon wrote: >> >> Ossification: >> In the past tcp middleboxes expected in-order, monotonically increasing offsets and tried to fix reordering before forwarding. This middlebox behavior, predicated on observable flows, prevented deployment of things which would have made tcp more efficient. >> >> This is the kind of non-theoretical ossification that drove the creation of QUIC in the first place. > This becomes more theoretical when you apply observations about TCP to QUIC: > > (1) Sequence numbering in TCP is far more broken than packet numbering (encrypted or not) ever could be, simply because it's not end-to-end integrity protected. The first deployed sequence number meddling boxes, IIRC, were designed to randomize ISNs (i.e., rewrite them), since stacks that did so were slow to deploy. PN rewriting is not only useless in QUIC, it'll break the connection. +1 Experience with TCP doesnt; necessarily help people understand what will happen with QUIC. Because TCP exposes all its protocol information, a middlebox can do a lot more than observe the sequence number, it can actually insert itself as a proxy for protocol mechanisms. This is not possible with QUIC. > (2) Many TCP stacks actually had (and some have) crap performance under certain reordering patterns, such that the deployment of a middlebox that did "fix" reordered packets would have had measurable benefits when tested against the stacks prevalent on the networks on which they were deployed at the time they were deployed. A QUIC PN-reordering middlebox would not show any such benefit, and would be correspondingly difficult to sell. It would not be fair to say that all boxes that observe TCP sequence numbers also interpret TCP options (or any other field used by the protocol). My point is that we shouldnt now fear everything, and then suspect that evil may come form this. > (3) The time to "path interference decay" for the TCP sequence number was years. Yes, things move more quickly now (indeed, as evidenced by experience with GUIC), but unless we intend not to deploy QUIC version 2 rapidly on the heels of QUIC version 1, I would submit that there's still time to revise everything not in the invariants. (And, indeed, if we do *not* intend to deploy QUIC version 2 rapidly on the heels of QUIC version 1, i.e., not until the "path interference decay" time, then this entire exercise is academic and we can all go home, because the version negotiation mechanism will ossify, greasing or not.) > > I think we need to take a step back and take a more systematic view toward ossification prevention. > > Greasing, in the TLS sense, refers to not allowing extensibility codepoints to have a single value or set of values that can be used for traffic classification and/or bad traffic rejection by a naive device on the path. This is useful when you're trying to keep parts of the codepoint space available for future use, but the design of QUIC is such that the set of codepoints *in the wire image* is completely determined by the negotiated version; i.e., adding a new packet type to the QUIC long header would require a new version. Therefore, protecting the version negotiation mechanism itself is necessary and sufficient to prevent the wire image from ossifying. > > This points the way to an alternate approach which will free us from having to have the ossification discussion about every single bit in the Version 1 header. Early and meaningful exercise of the version negotiation mechanism, with at least two versions whose wire images have *only* our intended invariants in common, is far superior to greasing the version codepoints as a method to protect the version negotiation mechanism. Greasing is a way to "fake" agility when you don't have any real agility yet -- but we're designing a protocol with real agility, with a version negotiation mechanism based at least in its core operation on GUIC's mechanism -- i.e., on one which we know at least one deployer of the protocol has used successfully multiple times. > > Greasing is still useful for fields in the invariants that have static values for codepoints we might want to use in the future -- but the greasing space should cover the whole codepoint space in these cases, since post VN we know which values are grease. > > (The PN encryption question is separate. The fundamental question here is "should the path see the PN?"... before Melbourne, the answer was "it doesn't matter because we haven't figured out a scalable way to do that". Now the answer is "probably not the whole PN, but the bottom N bits seem quite useful for maintaining TCP-equivalent measurability for the protocol, with a linear linkability risk / measurement utility tradeoff depending on N." Those N bits ossify only if Version 1 is the only QUIC version for the foreseeable future, or if we put them at the same observable offset in the Version 2 header.) > > Cheers, > > Brian > I think it is entirely possible that a small set of fields in the transport header may be usefully ossified to increase the deployability, manageability and flexibility across a range of use cases. Gorry From nobody Mon Feb 5 00:38:52 2018 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 85D52129C6B for ; Mon, 5 Feb 2018 00:38:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 rPWWehkZZvxv for ; Mon, 5 Feb 2018 00:38:47 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC03126BF7 for ; Mon, 5 Feb 2018 00:38:46 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 79E07340D4D; Mon, 5 Feb 2018 09:38:45 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.7756); Mon, 5 Feb 2018 09:38:45 +0100 (CET) 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; Mon, 5 Feb 2018 09:38:45 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44328255; Mon, 05 Feb 2018 09:38:44 +0100 From: Brian Trammell (IETF) Message-Id: <5F8F8C9A-4FA3-4493-AAFA-ADF0416B0BA5@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_BD474536-C8D6-4ECF-9FCD-4E3B98CFA4AF"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Mon, 5 Feb 2018 09:38:45 +0100 In-Reply-To: <2B5B329E-C539-40EA-B8E4-A96861141F52@fb.com> Cc: QUIC WG To: Roberto Peon References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <00f301d39e3d$f15bdf40$d4139dc0$@gmail.com> <2B5B329E-C539-40EA-B8E4-A96861141F52@fb.com> 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, 05 Feb 2018 08:38:51 -0000 --Apple-Mail=_BD474536-C8D6-4ECF-9FCD-4E3B98CFA4AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Roberto, all, (Trimming recipients) Briefly: this is the approach under development with the IOAM work in = the IPPM (and other) working groups; please come by if you=E2=80=98d = like to contribute there. There are two serious drawbacks of an IOAM-only approach to = measurability of encrypted transports. First, they only allow measurement on the granularity of the tunnels = carrying IOAM traffic. As you point out, sometimes that is exactly what = you want. Often it isn=E2=80=99t. Requiring an operator to tunnel = traffic differently in order to be able to get the measurement = aggregates necessary for a given measurement task runs into a Heisenberg = problem: you=E2=80=99ve changed the thing you want to measure in trying = to measure it. Second, they only measure the treatment of a traffic flow between tunnel = endpoints. This implies that they're good for intranet diagnostics (of = aggregates you generally already have) or for diagnostics for tunnel = services provided to customers (assuming you ship IOAM-capable CPE for = the customer end; this is indeed one of the reasons to standardize this = approach). They're bad for diagnosing stuff within an end network = (between the tunnel end and the endpoint) or for anything interdomain. IOAM approaches are an important part of the measurement toolkit, but = they're not a replacement for end-to-end signals for all tasks. Cheers, Brian On 5 Feb 2018, at 08:16, Roberto Peon wrote: > That depends. > Arguably, all the network can know (or should know) is on the basis of = a 5-tuple, thus the network could assign sequence numbers based on order = of arrival of a 5-tuple. >=20 > However, one could do more useful and/or general things: If the = intended egress node is known at the ingress point for a packet then, = when applying the appropriate route, stamp the packet with a sequence = number on/for that route. At that point you=E2=80=99re able to look at = reordering across any/all flows within a route. This is a stronger = ordering guarantee than is necessary, and thus is sufficient for any = individual flow on that route. In my belief, this would be a superior = metric for network health detection overall. >=20 > -=3DR >=20 > From: Roni Even > Date: Sunday, February 4, 2018 at 8:58 PM > To: Roberto Peon , "'Roni Even (A)'" = , 'Piotr Galecki' = , 'Jana Iyengar' , = "'Fossati, Thomas (Nokia - GB/Cambridge, UK)'" = > Cc: 'Gorry Fairhust' , 'Eric Rescorla' = , 'Christian Huitema' , "'Eggert, = Lars'" , 'Brian Trammell' , 'Mirja = K=C3=BChlewind' , 'QUIC WG' = , 'Martin Thomson' > Subject: RE: Packet number encryption >=20 > Does not it mean that the network need to identify packets that are = from the same quic connection to make such wrapping? > Roni >=20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon > Sent: Monday, February 05, 2018 2:38 AM > To: Roni Even (A); Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia = - GB/Cambridge, UK) > Cc: Gorry Fairhust; Eric Rescorla; Christian Huitema; Eggert, Lars; = Brian Trammell; Mirja K=C3=BChlewind; QUIC WG; Martin Thomson > Subject: Re: Packet number encryption >=20 > A network could carry whatever protocol it wished to, i.e. by wrapping = any/all packets on ingress to the network, and then un-wrapping when = forwarding to another network. This would allow a network to record and = track whatever it wanted to without placing constraints on layers which = should be above it. >=20 > If the network placed a sequence number on incoming packets, it could = detect reordering across all flows. If it do so on a 5-tuple basis, it = could detect reordering/duplication/loss across any 5-tuple. >=20 > -=3DR > From: Roni Even (A) > Sent: Saturday, February 3, 2018 11:47:06 PM > To: Roberto Peon; Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia = - GB/Cambridge, UK) > Cc: Gorry Fairhust; Eric Rescorla; Mirja K=C3=BChlewind; Eggert, Lars; = Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson > Subject: RE: Packet number encryption >=20 > Hi, > Network monitoring: > Networks may always wrap the packet(s) they have received with = whatever data they wish, and unwrap before forwarding. This can allow = any network to understand ordering, loss, etc within its boundaries. >=20 > RE- so you are saying that we can for example leverage RTP and = define RTP payload for QUIC that will carry QUIC packets, we will just = need to resolve the MTU size. > Roni >=20 >=20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roberto Peon > Sent: Saturday, February 03, 2018 8:38 PM > To: Piotr Galecki; Jana Iyengar; Fossati, Thomas (Nokia - = GB/Cambridge, UK) > Cc: Gorry Fairhust; Eric Rescorla; Mirja K=C3=BChlewind; Eggert, Lars; = Brian Trammell; Christian Huitema; QUIC WG; Martin Thomson > Subject: Re: Packet number encryption >=20 > Ossification: > In the past tcp middleboxes expected in-order, monotonically = increasing offsets and tried to fix reordering before forwarding. This = middlebox behavior, predicated on observable flows, prevented deployment = of things which would have made tcp more efficient. >=20 > This is the kind of non-theoretical ossification that drove the = creation of QUIC in the first place. >=20 > Network monitoring: > Networks may always wrap the packet(s) they have received with = whatever data they wish, and unwrap before forwarding. This can allow = any network to understand ordering, loss, etc within its boundaries. >=20 > Debugging: > Debugging of flows can still happen for flows that wish to be = debugged-- the QUIC connection's key material(s) can be shared manually = and used by the debugging tool. This is how one debugs http2, https, = etc. already today. >=20 > -=3DR >=20 >=20 >=20 > -------- Original message -------- > From: Piotr Galecki > Date: 2/2/18 7:00 PM (GMT-08:00) > To: Jana Iyengar , "Fossati, Thomas (Nokia - = GB/Cambridge, UK)" > Cc: Gorry Fairhust , Eric Rescorla = , Christian Huitema , "Eggert, Lars" = , Brian Trammell , Mirja K=C3=BChlewind= , QUIC WG , Martin = Thomson > Subject: RE: Packet number encryption >=20 > What is the group=E2=80=99s proposal for allowing network monitoring = tools to detect packet retransmission or packet reordering ? > These metrics are pretty straightforward to measure for TCP flows. > Tools like Wireshark can analyze packets and spot issues. > How can the network tools perform this kind of measurements for QUIC = flows if PN field is encrypted? >=20 >=20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar > Sent: Friday, February 02, 2018 9:31 PM > To: Fossati, Thomas (Nokia - GB/Cambridge, UK) = > Cc: Gorry Fairhust ; Eric Rescorla = ; Mirja K=C3=BChlewind ; = Christian Huitema ; Brian Trammell = ; Eggert, Lars ; QUIC WG = ; Martin Thomson > Subject: Re: Packet number encryption >=20 > A few points as I catch up on this thread. >=20 > First, I'll remind folks that QUIC is an encrypted transport. I say = this because the cost of this operation is trivial in the context of = encrypting every packet. The cost is borne at the servers and not at = middleboxes, so the additional crypto cost is basically trivial. >=20 > Second, this simplifies and increases robustness of implementation. = Avoiding random PN jumps, as Kazuho points out, makes special-casing of = code unnecessary. Special code that is exercised occasionally is a = strong bug attractor, and I would strongly argue for as few of those as = possible in implementation. >=20 > Third, yes, ossification is a real concern. A simple example: using = increasing packet numbers as a signature for detecting QUIC. Even if you = argue against this example, there are innovative ways in which = ossification will happen. This is based on a true story: We had no idea = how GQUIC's flags field could get ossified, the value that was being = used commonly became used as a signature for QUIC traffic (see Section = 7.5 in the SIGCOMM QUIC paper). >=20 > There's a win here in terms of implementation complexity and several = implementers have said so. There's a win in terms of ossification and = our experience says so. There's a potential loss of manageability, in = being able to detect reordering. This is the trade-off, and I am still = in favor of encrypting packet numbers. >=20 > On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, = UK) wrote: > On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" = wrote: > > On 2018-1-31, at 10:52, Gorry Fairhurst = wrote: > > > +1 - Simply: This *is* complicated and seems to add little. > > > > So as an implementor (chair hat off), this adds very little to the > > overall complexity of the protocol. >=20 > This doesn't sound great. It's a bit like saying that adding the = Higgs > mechanism to the standard model's lagrangian doesn't make it much more > complicate :-) (*) >=20 > More seriously though, I'd like to point out that it is not just about > implementation complexity, it's also the energy cost per packet that = is > quite crucial. I haven't done the math but ISTM that bringing in > another batch of non-optional crypto computation on a per packet basis > is not going to move the needle in the right direction for stacks that > run on low power (IoT). >=20 > This is not a catastrophe - we have CoAP and a (D)TLS profile - but > neither it's ideal, since cutting off the small things from the wider > ecosystem creates an artificial gap which then will need a middlebox = to > bridge. (Sure, we have specified the behaviour of a similar box > already, but it'd be really better if the extra translation logic = could > be avoided in the first place.) >=20 > I guess what I'm saying is that PN encryption being a core mechanism > that can't be negotiated at handshake time reduces our ability to = later > profile QUIC for the IoT, which would be a bit unlucky. >=20 > So the question is: would it be possible to make this property a > configurable knob instead? >=20 > (*) = https://www.symmetrymagazine.org/article/the-deconstructed-standard-model-= equation >=20 >=20 --Apple-Mail=_BD474536-C8D6-4ECF-9FCD-4E3B98CFA4AF 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp4GBUACgkQihK3vwvq RqOE4A/8D06k2ixuVFZtOGVacyhx1n2eitnDoEXkoH/CjuiS2TAwODRefPDdNYfY lEejGop6Zq+WbyyLff/Itu5LtDq3d2S4bJsUH2FV5Zh+0nYmvebqJ2uv2JX78lDv UizvwOWNBR1z+DUchYLL1NTu0N86259W03CkY+agUjbT4cA0OY5sAIWpCB1UhK85 qsQkmhn1TGnrTEeglaQtekMZE3YqDPHpUnXjxTJFItNaESHaI0XCSOzW0C9b8MCY QM0SrXcIum7uPoA37y1TF7CribYho9dft163hKbPPPIQx1yDQ16xoEhMQiBGayoG 2DqqcWLrDdwKhM48OobPxeQWBFoTjOu3/UhtAQpxYcWxCO70WNCBydujtdDsfwF+ S+GEmsbSySj6A/qSBP+cDsqEid6xp/dxtRSWUj6falLKoNPgxnokTcekgVkX7fil 6u6hI1nFGEqSTekYOUoAKvuCy9jgUFBtryofDY2ko7KasTgshko7pMcNlixECjLF +ktKC31ahdR4AZjovGXifz+TKOBSRrW5yjl/m2k5qNWUy34llSAfp4YotQZJnsFp 1wDUtKGfPX/OIGhju261SYnYQNBmzLkRQtFfrW7UEn5gathCqGuItQZ7tnzh0IFL XtGB6QgRh0bieiU7CcatzBuqIx38yztoE76X/rYvyoV/zHlAOTw= =T4tw -----END PGP SIGNATURE----- --Apple-Mail=_BD474536-C8D6-4ECF-9FCD-4E3B98CFA4AF-- From nobody Mon Feb 5 01:45:41 2018 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 C0307129BBF for ; Mon, 5 Feb 2018 01:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iUUcomyhU2VP for ; Mon, 5 Feb 2018 01:45:37 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16FE12946D for ; Mon, 5 Feb 2018 01:45:36 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,464,1511856000"; d="asc'?scan'208";a="239871854" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx144-out.netapp.com with ESMTP; 05 Feb 2018 01:45:35 -0800 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 5 Feb 2018 01:45:35 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Mon, 5 Feb 2018 01:45:35 -0800 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=/5aIjY7br8JMUelDBh9rqtCp6O0gsKxDPe7VIE8Yl7U=; b=NtGb1pTpI3SG3ARM1cMd80QVbG4STZEtMfRWmS0Ox3Y2+g4e5Hwq75IGs9HRc0QKY2b91Uzpec4F1FLvonFzy8OH5uP2yJWznjVYYKixydcu+3mJbzXcwiqH7+/Nqu8hMJJG7E8C+YIg4uFYug6+v1iel+A7BfSz9bPCGyN63Kc= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1857.namprd06.prod.outlook.com (10.162.225.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 09:45:33 +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.20.0464.015; Mon, 5 Feb 2018 09:45:33 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Re: Doodle poll for Feb 2018 remote interop day Thread-Topic: Doodle poll for Feb 2018 remote interop day Thread-Index: AQHTlZWamOk6nfArGUuGr+le3k3//6OIkuUAgA0OD4A= Date: Mon, 5 Feb 2018 09:45:32 +0000 Message-ID: References: <9C605165-D6F0-4ECC-9C49-41C059324603@netapp.com> <5D489CC6-2C35-4486-86DE-95CCC7A3C21D@netapp.com> In-Reply-To: <5D489CC6-2C35-4486-86DE-95CCC7A3C21D@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1857; 6:l5mDqNdrLIUhFSQBAjxvvRDXtL22q4suvIQa/knlYsq3vbLtLmt2/0mdaq7lw1FEGld5owfv9Jh5dapJDZ79I9PNqH09SzLu7adohVjUi/JDK0QqD9n7YfJTHEfQFeJqUCC01qtPS3EW1SofOqpZe8aBX72FDow7KeZsogILW6pxnj6MMwAPgEmjZK8yr7RNGjtHu/lAX538QObhA49FzEsqt3ST0br4hUz1xnNiHmIAHTTfVaNhWCZJ6n2Y5W0nF+61XpukP9VMg725BNHb8xPeU0AUGHVbYoVTw5+MpzI9osT86qvktJ46dS+vK6gHkNJSGgE6QRVqeRFCK6vEOpWu5C0qyvovHeumuxJm5Pd4LlWR0ibQ6yGAFF2eUvzM; 5:NuVYL3hkrdqoccUZrIAbC405xIxZ65EhJZuuyESf3mX0QdKmy9Np2EXs+vASQNTNf8+a5suuWPwx0NZKrrAPHR7ovnzfDx76oz3ws9ke/+MMAjNwy8CbqgI6kYfVu+aMsQsvfYDkg8MFcJxrwXZz9Zor82n5l8f2S7o6ixJeHQ8=; 24:pRIeHjR5pjCyB3+kbvCISkh/oZ8EgyDO94id4HbXCt4liecgMEPa9s6r/3FLrnZ7ke4dU3TfdIlvqBWHhghYv1w+s+2wGthaJQ3w3+YJ/fU=; 7:BLPmoKhm3Ba4tURkli9u5FA77qTtScQh9JhQcU0A7qD54MB1aJSeZMPq3Ddukj+WXD9MsuNXFvwQMJOIJjpx+hJE8mA5OhtkNP2hRgr1fz0m8BLg0ZPo+ON5fDpgW7M18yedOqxlAVkvxMzid/soIGbG9XG91xc7NykJgsa7+JhTKeiPF+OOCSHdpSrKOl7zRvLopL7Kakb9gGqm26f9IS8dxOQDIJkCizE5pWCtgfjCGIqDz74zCeFu6q4yhcRB x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 71c8e001-8711-4fbd-5988-08d56c7d334e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB1857; x-ms-traffictypediagnostic: BLUPR06MB1857: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60409825278598); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231101)(2400082)(944501161)(6055026)(6041288)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BLUPR06MB1857; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1857; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(396003)(376002)(366004)(346002)(199004)(377424004)(189003)(6486002)(6246003)(14454004)(36756003)(6506007)(57306001)(305945005)(53546011)(5660300001)(99936001)(478600001)(6116002)(6512007)(53936002)(6916009)(102836004)(6436002)(26005)(6306002)(316002)(77096007)(186003)(3846002)(8676002)(81166006)(97736004)(50226002)(4001150100001)(2900100001)(8936002)(2950100002)(86362001)(2906002)(81156014)(76176011)(966005)(3660700001)(3280700002)(82746002)(33656002)(99286004)(66066001)(105586002)(7736002)(229853002)(106356001)(83716003)(68736007)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1857; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: Q171QT1f+KVt7qdS1yphWhnUv6mmB205tgSp1qqaRK5eQUok16ZdPkkgfVpQYQKIpEzf3BS+Y/rkADybjomKLQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_21BA593F-F62F-44B8-A42A-90F9434DD8A0"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 71c8e001-8711-4fbd-5988-08d56c7d334e X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 09:45:32.4340 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1857 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: Mon, 05 Feb 2018 09:45:40 -0000 --Apple-Mail=_21BA593F-F62F-44B8-A42A-90F9434DD8A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Thu, Mar 1, is the final choice. I have started a wiki page for the 4th implementation draft. I think we = agreed in Melbourne to mostly go to QUIC -09 drafts and TLS1.3 draft-23, = and that's what's on that page. Patrick and others wanted to add some = HTTP things to the list, please do that. I'll also make a new tab in the interop spreadsheet. Lars > On 2018-1-28, at 3:23, Eggert, Lars wrote: >=20 > At the moment, it looks like Thu, Mar 1. Please respond soon, I'll = pick a date by the end of the coming week. >=20 > Lars >=20 >> On 2018-1-25, at 15:33, Eggert, Lars wrote: >>=20 >> Please indicate your availability, if you have a stack you wish to = test: https://doodle.com/poll/ee4gueyfve3azpqn >>=20 >> (This will be a remote interop day. Next physical one will be = Hackathon in London.) >>=20 >> Lars >=20 --Apple-Mail=_21BA593F-F62F-44B8-A42A-90F9434DD8A0 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlp4J7sACgkQVLXDCb9w wVfB0A//aWmOhVvW0chYNtlBT5b7ff4r1Q9C9FCqktqq+jsZrKfHQYAv1W8I6gob vIkJAJUABiVaP7sakAmHw+4YdQocznTgO+wk0HX9708oqyRcTLQRCdR8ibFsrfFe 89CEmWResEVmjCb7W49oyZUCURBXM0JIzMerPl38y4vIl07nhKkD7+Mir08POyZX ducSAoW4LDvkmDEeXy7Xd/afJvOHE7fZ/nDmFfGhZ8HD3H75R92o/yZPvwk9FSiI zHAkkNJVipxi/EnnXTWK5dFclr05aVlG+6/C982iJ0i06/WuLxUMmOsViw8wdXmk yEcxqc05kLQnvgSogOylzHH9N/9YNgoXsjAOK4BFVdDH/IX19Ibe+O3arsHxytb8 3xyAWXzYGC6bIgEV3EdXckjg9EBHLX9XJWJzQH9ih6ELJ/uZMYExhGIftNm8lI95 CLrVSiY/DN/n6J1q9Oed1PS6u8+86Ha+YZlfPfKo95xgJAYc1TUKVf5W5yAlFCqp BoHD+ZaFnDzHHkTbCJHTlMhEW7z5t+N7jl8NOZnIOZwmpI4Gza1665gq0sAeKn4O NOXU1Xnr1QOPyLiVQsJFOG7nKaXgbT7F6bniGOANM03G2UB7HTJ1QJL6T3/5Q6Y7 6tbd9vwmNfZvGAxiemu8qbcCS2x9Wlzm+dR3oj/5MMpazfaLMW8= =+jpH -----END PGP SIGNATURE----- --Apple-Mail=_21BA593F-F62F-44B8-A42A-90F9434DD8A0-- From nobody Mon Feb 5 05:35:37 2018 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 0839B12D77E for ; Mon, 5 Feb 2018 05:35:36 -0800 (PST) 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 jzVt_MTr-ixj for ; Mon, 5 Feb 2018 05:35:33 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e: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 1501A12426E for ; Mon, 5 Feb 2018 05:35:33 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id o13so18537428pgs.2 for ; Mon, 05 Feb 2018 05:35:33 -0800 (PST) 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=UENHbzDbwoHGUmkEGXnXJxhcUPghSyGl9EoJbBya2AU=; b=PwFLwE7FI+0NGLLoyc9ig0HYi4+qzx0d8VE02UuTeVQhCgYBiXrBgiy+fqoWiIxR7W O4php29quYFqPs1xMz1SarfdhmQ3xsROhSVTZISDI6LvjsZ8PywDxG1wawvcjXly7uBS ger1PZM38MKZhYY9B0I7CdheuJL4BoZgtNTnvrhsTLxMdt5TMHw9OHvxtfvY9LfXbjLH qi0K+yrNkGPbTeE2BNyxYRc60Sy6OKeTRcSTGQZxpjKev+JTplqrpbYjbqQoXFoMON71 NWtIGlxkH3tWjtlaznxHV9Y8eqDiH63Qc2SG1YkN05RDWuIOwxVGQy4kkIfvjI7YluWI Pyag== 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=UENHbzDbwoHGUmkEGXnXJxhcUPghSyGl9EoJbBya2AU=; b=kQ8C2HUGxlvqbS+65YbmyP79GpA10IMULaKXpdDclKB+7mrh5KdsZlzlCKy5Nbst67 kJnaOX3V3Bst6KVxO85qjhLS8vZTHUE8jSbzoNFKB2j3LXF4FmbUHFoU2E5oh/94Avc3 r6eE9AeB956KSctzufeh6hawF/hMmgqVRE9GjSvjGKGpJcUuZBVFdh4vahWUYwyRptVd ltH7tRZ4gC4elQoWn7fzpFbUht24JEfjKbMe+3YPqNNitALeI+oGKkw0LCCXUsNrPuz0 hsm/R8jZUP+13FQrvps8i/yqTDDZ+bVpiTNtqqF+Iw6C0mS0wGY+6zvY07ndNxUdulF6 GfPw== X-Gm-Message-State: AKwxyte6zSP3OUalZD5NYEdc35kMyQL6aP/0IpVfaT0uTURhkY4FxS2e d6NdLYMxVtwJKOkxHGi3Mt/1smQ/L6ud6cYj2iw= X-Google-Smtp-Source: AH8x224FEpqAi2KTzmgUKTLOyLtSjuwID4gCfPIxOd25Kcs7TG3tox7Xr4tkoBLaP3Ar+bQo99ygE7cnzraBhkZ0T7g= X-Received: by 10.99.100.198 with SMTP id y189mr7544201pgb.277.1517837732409; Mon, 05 Feb 2018 05:35:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Mon, 5 Feb 2018 05:35:31 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> From: Kazuho Oku Date: Mon, 5 Feb 2018 22:35:31 +0900 Message-ID: Subject: Re: Packet number encryption To: "Brian Trammell (IETF)" Cc: Jana Iyengar , Gorry Fairhurst , Eric Rescorla , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "Eggert, Lars" , Christian Huitema , QUIC WG , Martin Thomson 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: Mon, 05 Feb 2018 13:35:36 -0000 2018-02-05 6:31 GMT+09:00 Brian Trammell (IETF) : > hi Jana, > >> On 3 Feb 2018, at 03:30, Jana Iyengar wrote: >> >> A few points as I catch up on this thread. >> >> First, I'll remind folks that QUIC is an encrypted transport. I say this= because the cost of this operation is trivial in the context of encrypting= every packet. The cost is borne at the servers and not at middleboxes, so = the additional crypto cost is basically trivial. > > After having worked my way through the PR again (and essentially rewritin= g it from the receiver's point of view, which I believe would be useful tex= t to have in the final document, should we end up doing this), I buy this. > >> Second, this simplifies and increases robustness of implementation. Avoi= ding random PN jumps, as Kazuho points out, makes special-casing of code un= necessary. Special code that is exercised occasionally is a strong bug attr= actor, and I would strongly argue for as few of those as possible in implem= entation. > > Agree completely. Packet number jumps are a bad idea, and there seems to = be a (not explicitly examined) consensus that attempting to make linkabilit= y difficult is worth the effort. > >> Third, yes, ossification is a real concern. A simple example: using incr= easing packet numbers as a signature for detecting QUIC. Even if you argue = against this example, there are innovative ways in which ossification will = happen. This is based on a true story: We had no idea how GQUIC's flags fie= ld could get ossified, the value that was being used commonly became used a= s a signature for QUIC traffic (see Section 7.5 in the SIGCOMM QUIC paper). > > There's an overgeneralization of experience from ossification of single s= tatic fields (as in the TLS greasing and GUIC flags cases) to functions ove= r the time series of these fields which has not yet been shown to be valid = IMO in the case of integrity-protected wire images -- will expand on this i= n my next message, replying to Roberto. > >> There's a win here in terms of implementation complexity and several imp= lementers have said so. > > Compared to packet number jumps, absolutely. Compared to the state two re= vs of the draft ago, it's a *little* more complex but at least it doesn't a= dd completely new operations at the sender or the receiver. > >> There's a win in terms of ossification and our experience says so. > > That experience is IMO overgeneralized. > >> There's a potential loss of manageability, in being able to detect reord= ering. > > Well, upstream loss and upstream reordering. > > As Christian suggested at the start of this thread, if we simultaneously = add back a signal that would allow on-path loss and reordering detection, t= hat would make this a usable-information-content-neutral change to the wire= image, and everyone could leave the table happy. +1 There are two parties with different interests. Endpoint developers want something more straightforward to implement and also is safe from ossification. Operators want a tool for diagnosis. In TCP, both parties have used the same signal for their tasks. In QUIC, we can split the signal into two, which can be tailored for each use-case. The split would help the protocol evolve (as fit from endpoint developers' perspective). At the same time, it could also help operators, since the signal they use can become more stable or evolve in a different pace (since the changes to the encrypted part of the protocol will not affect what the operators will see, or vice-versa). Note also that even in the current unencrypted form, packet numbers of QUIC is not as easy to use compared to TCP (from operators' viewpoint) since the numbers monotonically increase and since ACKs are encrypted. So there's a chance to make the signal more useful by splitting the signals. Spin bit is a good example. > The only problem with this is that the most obvious place to put this sig= nal -- the four bits we get back from the short header type field (assuming= we add the spin bit) aren't really enough to track the loss and reordering= patterns we care about with a naive counter. > > There are lots of other options in this space (e.g. decide we care about = latency more than reordering, and that we don't care about loss at all, and= use a two-bit spin to protect the latency signal from reordering, and so o= n), but that seems like a third thread we should start. > > Cheers, > > Brian > >> This is the trade-off, and I am still in favor of encrypting packet numb= ers. >> >> On Fri, Feb 2, 2018 at 7:32 AM, Fossati, Thomas (Nokia - GB/Cambridge, U= K) wrote: >> On 31/01/2018, 10:06, "QUIC on behalf of Eggert, Lars" wrote: >> > On 2018-1-31, at 10:52, Gorry Fairhurst wrote: >> > > +1 - Simply: This *is* complicated and seems to add little. >> > >> > So as an implementor (chair hat off), this adds very little to the >> > overall complexity of the protocol. >> >> This doesn't sound great. It's a bit like saying that adding the Higgs >> mechanism to the standard model's lagrangian doesn't make it much more >> complicate :-) (*) >> >> More seriously though, I'd like to point out that it is not just about >> implementation complexity, it's also the energy cost per packet that is >> quite crucial. I haven't done the math but ISTM that bringing in >> another batch of non-optional crypto computation on a per packet basis >> is not going to move the needle in the right direction for stacks that >> run on low power (IoT). >> >> This is not a catastrophe - we have CoAP and a (D)TLS profile - but >> neither it's ideal, since cutting off the small things from the wider >> ecosystem creates an artificial gap which then will need a middlebox to >> bridge. (Sure, we have specified the behaviour of a similar box >> already, but it'd be really better if the extra translation logic could >> be avoided in the first place.) >> >> I guess what I'm saying is that PN encryption being a core mechanism >> that can't be negotiated at handshake time reduces our ability to later >> profile QUIC for the IoT, which would be a bit unlucky. >> >> So the question is: would it be possible to make this property a >> configurable knob instead? >> >> (*) https://www.symmetrymagazine.org/article/the-deconstructed-standard-= model-equation >> >> > --=20 Kazuho Oku From nobody Mon Feb 5 06:05:02 2018 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 D3FCC12D7FB for ; Mon, 5 Feb 2018 06:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 XO6kGF9JoxtM for ; Mon, 5 Feb 2018 06:04:57 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 6B1E91252BA for ; Mon, 5 Feb 2018 06:04:57 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id u62so16755850ita.2 for ; Mon, 05 Feb 2018 06:04:57 -0800 (PST) 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=LQsUQTf69iJ+0NQfwGeRjbRjaq9CWyOizkAzgeSkUGw=; b=VN4Q7o15KmSXGsS6uRkcYQTHFeM8VMD4mhx0Rt33Fap2XuoYwG0TXOvHtG3OikFYou gO5maye4PyQGoGxgG29jVb1birskHDuovthRlYyW/G+Sk/sKb+QhOTvguxGqyuLe33YD UWtmrs6BN3+etX6Wk/haz4h+x/FTRxKH/uNLj2GneDm5AY2nybvJe4okSg9IgZxjfG3g QNW02euFddObeWy+T9aff6WunYCF9RepaUVRG8P44WzYdYzexTEg3CRPwObj6mjFO2di xu1slhkAQPTe283TR9KlgZKW3Sf6iLQydA5HBcJfutvjhbLtfX431paQ/CJP2rdY19uO cQYw== 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=LQsUQTf69iJ+0NQfwGeRjbRjaq9CWyOizkAzgeSkUGw=; b=lVecaqJpusjfHbqLt7SE1jNT/4LrwEmL+fGrNm2GrG3qww/kdprld/ykryfKv/fqs6 NMInXPRRC+RMPm7C2H/ZQybU2clbW2Se87aoHaXIj+06NVRsrVVLVo0D2DB6zXtFfA/o rz00jA/HVWvKMwWOuuoqdTEYM4DeZpb3VQosQUZPCJakgvN/ug7yBB+nJm3FpEnZS9HY rMgdu3PHOWc4/MYlqRnGQTkB37W2hKUuVEIX9awh0GIlOcg8B0L90JWXR6IFQ8QL3eOf djaERLsS2YI8qdUmx5BjRn9u/z8XcmwWEUhvvdPLlGlulULqdvcTEtwugiMlq9HQnOLS 8uXA== X-Gm-Message-State: AKwxytdmX4j7p6c8awOwIaH8c9rPSVnR9vRmtvx93S4vsorDI+EQEaFj eZM10uOHMdnQjG/ycp5HbCZK+XgBoRube+2FtWo55g== X-Google-Smtp-Source: AH8x226RHtNmS5PCblAQlhiZiWlYphS5Xp/P8NJ/RF+dDM1aMRgJl+syUi9nXYHq7bquLOcFv6AkdwHJfCpXOfmaDSc= X-Received: by 10.36.73.102 with SMTP id z99mr61281125ita.72.1517839496353; Mon, 05 Feb 2018 06:04:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Mon, 5 Feb 2018 06:04:35 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Mon, 5 Feb 2018 09:04:35 -0500 Message-ID: Subject: Re: Call for Adoption: Invariants To: "Brian Trammell (IETF)" Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Lars Eggert , Mark Nottingham , QUIC WG Content-Type: multipart/alternative; boundary="001a11c14e5e0218a00564778c13" 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, 05 Feb 2018 14:05:00 -0000 --001a11c14e5e0218a00564778c13 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption of the invariants draft. On Mon, Feb 5, 2018 at 3:33 AM, Brian Trammell (IETF) wrote: > Hi, all, > > I support adoption of the invariants draft. > > > On 5 Feb 2018, at 08:51, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > > > > Only concern is when it takes effect since it likely needs adjustments. > > I'd presume that invariants is published simultaneously with the version = 1 > spec. > >From the perspective of someone intending to deploy draft versions, the invariants need to be stable, ideally at least in a last call state, sooner than the version 1 spec, otherwise there's no guarantee a server can migrate from one version to another. > > And perhaps a procedure to handle invariant changes since everything > changes. > > Noted, though the point of declaring something an invariant is to say "th= e > meaning of this part of the wire image, expressed as a bit offset, will > never change". You can add constraints to the invariants, but if you thin= k > you might remove a constraint, then it's not an invariant by definition. > > Cheers, > > Brian > > > From: QUIC on behalf of Mark Nottingham < > mnot@mnot.net> > > Sent: Monday, February 5, 2018 7:07:45 AM > > To: QUIC WG > > Cc: Lars Eggert > > Subject: Call for Adoption: Invariants > > > > At the Melbourne meeting, there was strong support for adopting Martin'= s > invariants draft: > > > > https://tools.ietf.org/html/draft-thomson-quic-invariants-00 > > > > Any objections / concerns about doing so? Unless we hear otherwise, > we'll adopt at the end of the week. > > > > Cheers, > > > > -- > > Mark Nottingham https://www.mnot.net/ > > --001a11c14e5e0218a00564778c13 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of the invariants draft.

On Mon, Feb 5, 2018 at 3:33 AM, = Brian Trammell (IETF) <ietf@trammell.ch> wrote:
Hi, all,

I support adoption of the invariants draft.

> On 5 Feb 2018, at 08:51, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
>
> Only concern is when it takes effect since it likely needs adjustments= .

I'd presume that invariants is published simultaneously with the= version 1 spec.

From the perspective o= f someone intending to deploy draft versions, the invariants need to be sta= ble, ideally at least in a last call state, sooner than the version 1 spec,= otherwise there's no guarantee a server can migrate from one version t= o another.


> And perhaps a procedure to handle invariant changes since everything c= hanges.

Noted, though the point of declaring something an invariant is to sa= y "the meaning of this part of the wire image, expressed as a bit offs= et, will never change". You can add constraints to the invariants, but= if you think you might remove a constraint, then it's not an invariant= by definition.

Cheers,

Brian

> From: QUIC <quic-bounces@i= etf.org> on behalf of Mark Nottingham <mnot@mnot.net>
> Sent: Monday, February 5, 2018 7:07:45 AM
> To: QUIC WG
> Cc: Lars Eggert
> Subject: Call for Adoption: Invariants
>
> At the Melbourne meeting, there was strong support for adopting Martin= 's invariants draft:
>
> https://tools.ietf.org/html/dr= aft-thomson-quic-invariants-00
>
> Any objections / concerns about doing so? Unless we hear otherwise, we= 'll adopt at the end of the week.
>
> Cheers,
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/


--001a11c14e5e0218a00564778c13-- From nobody Mon Feb 5 06:30:23 2018 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 53EAA127023 for ; Mon, 5 Feb 2018 06:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 hqiPmqCdymeg for ; Mon, 5 Feb 2018 06:30:18 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 4BA341242F7 for ; Mon, 5 Feb 2018 06:30:18 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id C1ED9C5878EB8 for ; Mon, 5 Feb 2018 14:30:14 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 5 Feb 2018 14:28:10 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Mon, 5 Feb 2018 22:28:04 +0800 From: "Roni Even (A)" To: "quic@ietf.org" CC: Kazuho Oku Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTnoZDs2xD/Oha40aWBKSZaocvJqOV3G8g Date: Mon, 5 Feb 2018 14:28:04 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD861F8E@DGGEMM506-MBX.china.huawei.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.244] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 05 Feb 2018 14:30:21 -0000 SGksDQoNCkkgd2FudCB0byBjb21tZW50IG9uIA0KIiBUaGVyZSBhcmUgdHdvIHBhcnRpZXMgd2l0 aCBkaWZmZXJlbnQgaW50ZXJlc3RzLiBFbmRwb2ludCBkZXZlbG9wZXJzIHdhbnQgc29tZXRoaW5n IG1vcmUgc3RyYWlnaHRmb3J3YXJkIHRvIGltcGxlbWVudCBhbmQgYWxzbyBpcyBzYWZlIGZyb20g b3NzaWZpY2F0aW9uLiBPcGVyYXRvcnMgd2FudCBhIHRvb2wgZm9yIGRpYWdub3Npcy4iDQoNCkkg YWdyZWUgdGhhdCB0aGVyZSBhcmUgdHdvIHBhcnRpZXMgYnV0IEkgaG9wZSB0aGF0IHdlIHNoYXJl IHRoZSBzYW1lIGludGVyZXN0IHdoaWNoIGlzIHRvIGhhdmUgYSBzZWN1cmUsIHJlbGlhYmxlIHBy b3RvY29sIHRoYXQgYWxzbyBzdXBwb3J0IG1hbmFnZWFiaWxpdHkgaW4gYWN0dWFsIHRyYW5zcG9y dCBuZXR3b3Jrcy4NCg0KQXMgZm9yIGhhdmluZyBwYXJhbGxlbCBtZWNoYW5pc21zLCBvbmUgb2Yg dGhlIHBvaW50cyBhYm91dCB0aGUgdXNhYmlsaXR5IG9mIHNwaW4gYml0IHdhcyB0aGF0IGl0IG5v dCBwYXJ0IG9mIHRoZSBwcm90b2NvbCBzdGF0ZSBtYWNoaW5lIGFuZCB0aGF0IG1ha2VzIGl0IGxl c3MgcmVsaWFibGUsDQoNClJvbmkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLYXp1aG8g T2t1DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDA1LCAyMDE4IDM6MzYgUE0NClRvOiBCcmlhbiBU cmFtbWVsbCAoSUVURikNCkNjOiBHb3JyeSBGYWlyaHVyc3Q7IEVyaWMgUmVzY29ybGE7IENocmlz dGlhbiBIdWl0ZW1hOyBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBVSyk7 IE1pcmphIEvDvGhsZXdpbmQ7IEVnZ2VydCwgTGFyczsgSmFuYSBJeWVuZ2FyOyBRVUlDIFdHOyBN YXJ0aW4gVGhvbXNvbg0KU3ViamVjdDogUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQoy MDE4LTAyLTA1IDY6MzEgR01UKzA5OjAwIEJyaWFuIFRyYW1tZWxsIChJRVRGKSA8aWV0ZkB0cmFt bWVsbC5jaD46DQo+IGhpIEphbmEsDQo+DQo+PiBPbiAzIEZlYiAyMDE4LCBhdCAwMzozMCwgSmFu YSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT4gd3JvdGU6DQo+Pg0KPj4gQSBmZXcgcG9pbnRzIGFz IEkgY2F0Y2ggdXAgb24gdGhpcyB0aHJlYWQuDQo+Pg0KPj4gRmlyc3QsIEknbGwgcmVtaW5kIGZv bGtzIHRoYXQgUVVJQyBpcyBhbiBlbmNyeXB0ZWQgdHJhbnNwb3J0LiBJIHNheSB0aGlzIGJlY2F1 c2UgdGhlIGNvc3Qgb2YgdGhpcyBvcGVyYXRpb24gaXMgdHJpdmlhbCBpbiB0aGUgY29udGV4dCBv ZiBlbmNyeXB0aW5nIGV2ZXJ5IHBhY2tldC4gVGhlIGNvc3QgaXMgYm9ybmUgYXQgdGhlIHNlcnZl cnMgYW5kIG5vdCBhdCBtaWRkbGVib3hlcywgc28gdGhlIGFkZGl0aW9uYWwgY3J5cHRvIGNvc3Qg aXMgYmFzaWNhbGx5IHRyaXZpYWwuDQo+DQo+IEFmdGVyIGhhdmluZyB3b3JrZWQgbXkgd2F5IHRo cm91Z2ggdGhlIFBSIGFnYWluIChhbmQgZXNzZW50aWFsbHkgcmV3cml0aW5nIGl0IGZyb20gdGhl IHJlY2VpdmVyJ3MgcG9pbnQgb2Ygdmlldywgd2hpY2ggSSBiZWxpZXZlIHdvdWxkIGJlIHVzZWZ1 bCB0ZXh0IHRvIGhhdmUgaW4gdGhlIGZpbmFsIGRvY3VtZW50LCBzaG91bGQgd2UgZW5kIHVwIGRv aW5nIHRoaXMpLCBJIGJ1eSB0aGlzLg0KPg0KPj4gU2Vjb25kLCB0aGlzIHNpbXBsaWZpZXMgYW5k IGluY3JlYXNlcyByb2J1c3RuZXNzIG9mIGltcGxlbWVudGF0aW9uLiBBdm9pZGluZyByYW5kb20g UE4ganVtcHMsIGFzIEthenVobyBwb2ludHMgb3V0LCBtYWtlcyBzcGVjaWFsLWNhc2luZyBvZiBj b2RlIHVubmVjZXNzYXJ5LiBTcGVjaWFsIGNvZGUgdGhhdCBpcyBleGVyY2lzZWQgb2NjYXNpb25h bGx5IGlzIGEgc3Ryb25nIGJ1ZyBhdHRyYWN0b3IsIGFuZCBJIHdvdWxkIHN0cm9uZ2x5IGFyZ3Vl IGZvciBhcyBmZXcgb2YgdGhvc2UgYXMgcG9zc2libGUgaW4gaW1wbGVtZW50YXRpb24uDQo+DQo+ IEFncmVlIGNvbXBsZXRlbHkuIFBhY2tldCBudW1iZXIganVtcHMgYXJlIGEgYmFkIGlkZWEsIGFu ZCB0aGVyZSBzZWVtcyB0byBiZSBhIChub3QgZXhwbGljaXRseSBleGFtaW5lZCkgY29uc2Vuc3Vz IHRoYXQgYXR0ZW1wdGluZyB0byBtYWtlIGxpbmthYmlsaXR5IGRpZmZpY3VsdCBpcyB3b3J0aCB0 aGUgZWZmb3J0Lg0KPg0KPj4gVGhpcmQsIHllcywgb3NzaWZpY2F0aW9uIGlzIGEgcmVhbCBjb25j ZXJuLiBBIHNpbXBsZSBleGFtcGxlOiB1c2luZyBpbmNyZWFzaW5nIHBhY2tldCBudW1iZXJzIGFz IGEgc2lnbmF0dXJlIGZvciBkZXRlY3RpbmcgUVVJQy4gRXZlbiBpZiB5b3UgYXJndWUgYWdhaW5z dCB0aGlzIGV4YW1wbGUsIHRoZXJlIGFyZSBpbm5vdmF0aXZlIHdheXMgaW4gd2hpY2ggb3NzaWZp Y2F0aW9uIHdpbGwgaGFwcGVuLiBUaGlzIGlzIGJhc2VkIG9uIGEgdHJ1ZSBzdG9yeTogV2UgaGFk IG5vIGlkZWEgaG93IEdRVUlDJ3MgZmxhZ3MgZmllbGQgY291bGQgZ2V0IG9zc2lmaWVkLCB0aGUg dmFsdWUgdGhhdCB3YXMgYmVpbmcgdXNlZCBjb21tb25seSBiZWNhbWUgdXNlZCBhcyBhIHNpZ25h dHVyZSBmb3IgUVVJQyB0cmFmZmljIChzZWUgU2VjdGlvbiA3LjUgaW4gdGhlIFNJR0NPTU0gUVVJ QyBwYXBlcikuDQo+DQo+IFRoZXJlJ3MgYW4gb3ZlcmdlbmVyYWxpemF0aW9uIG9mIGV4cGVyaWVu Y2UgZnJvbSBvc3NpZmljYXRpb24gb2Ygc2luZ2xlIHN0YXRpYyBmaWVsZHMgKGFzIGluIHRoZSBU TFMgZ3JlYXNpbmcgYW5kIEdVSUMgZmxhZ3MgY2FzZXMpIHRvIGZ1bmN0aW9ucyBvdmVyIHRoZSB0 aW1lIHNlcmllcyBvZiB0aGVzZSBmaWVsZHMgd2hpY2ggaGFzIG5vdCB5ZXQgYmVlbiBzaG93biB0 byBiZSB2YWxpZCBJTU8gaW4gdGhlIGNhc2Ugb2YgaW50ZWdyaXR5LXByb3RlY3RlZCB3aXJlIGlt YWdlcyAtLSB3aWxsIGV4cGFuZCBvbiB0aGlzIGluIG15IG5leHQgbWVzc2FnZSwgcmVwbHlpbmcg dG8gUm9iZXJ0by4NCj4NCj4+IFRoZXJlJ3MgYSB3aW4gaGVyZSBpbiB0ZXJtcyBvZiBpbXBsZW1l bnRhdGlvbiBjb21wbGV4aXR5IGFuZCBzZXZlcmFsIGltcGxlbWVudGVycyBoYXZlIHNhaWQgc28u DQo+DQo+IENvbXBhcmVkIHRvIHBhY2tldCBudW1iZXIganVtcHMsIGFic29sdXRlbHkuIENvbXBh cmVkIHRvIHRoZSBzdGF0ZSB0d28gcmV2cyBvZiB0aGUgZHJhZnQgYWdvLCBpdCdzIGEgKmxpdHRs ZSogbW9yZSBjb21wbGV4IGJ1dCBhdCBsZWFzdCBpdCBkb2Vzbid0IGFkZCBjb21wbGV0ZWx5IG5l dyBvcGVyYXRpb25zIGF0IHRoZSBzZW5kZXIgb3IgdGhlIHJlY2VpdmVyLg0KPg0KPj4gVGhlcmUn cyBhIHdpbiBpbiB0ZXJtcyBvZiBvc3NpZmljYXRpb24gYW5kIG91ciBleHBlcmllbmNlIHNheXMg c28uDQo+DQo+IFRoYXQgZXhwZXJpZW5jZSBpcyBJTU8gb3ZlcmdlbmVyYWxpemVkLg0KPg0KPj4g VGhlcmUncyBhIHBvdGVudGlhbCBsb3NzIG9mIG1hbmFnZWFiaWxpdHksIGluIGJlaW5nIGFibGUg dG8gZGV0ZWN0IHJlb3JkZXJpbmcuDQo+DQo+IFdlbGwsIHVwc3RyZWFtIGxvc3MgYW5kIHVwc3Ry ZWFtIHJlb3JkZXJpbmcuDQo+DQo+IEFzIENocmlzdGlhbiBzdWdnZXN0ZWQgYXQgdGhlIHN0YXJ0 IG9mIHRoaXMgdGhyZWFkLCBpZiB3ZSBzaW11bHRhbmVvdXNseSBhZGQgYmFjayBhIHNpZ25hbCB0 aGF0IHdvdWxkIGFsbG93IG9uLXBhdGggbG9zcyBhbmQgcmVvcmRlcmluZyBkZXRlY3Rpb24sIHRo YXQgd291bGQgbWFrZSB0aGlzIGEgdXNhYmxlLWluZm9ybWF0aW9uLWNvbnRlbnQtbmV1dHJhbCBj aGFuZ2UgdG8gdGhlIHdpcmUgaW1hZ2UsIGFuZCBldmVyeW9uZSBjb3VsZCBsZWF2ZSB0aGUgdGFi bGUgaGFwcHkuDQoNCisxDQoNClRoZXJlIGFyZSB0d28gcGFydGllcyB3aXRoIGRpZmZlcmVudCBp bnRlcmVzdHMuIEVuZHBvaW50IGRldmVsb3BlcnMgd2FudCBzb21ldGhpbmcgbW9yZSBzdHJhaWdo dGZvcndhcmQgdG8gaW1wbGVtZW50IGFuZCBhbHNvIGlzIHNhZmUgZnJvbSBvc3NpZmljYXRpb24u IE9wZXJhdG9ycyB3YW50IGEgdG9vbCBmb3IgZGlhZ25vc2lzLg0KDQpJbiBUQ1AsIGJvdGggcGFy dGllcyBoYXZlIHVzZWQgdGhlIHNhbWUgc2lnbmFsIGZvciB0aGVpciB0YXNrcy4NCg0KSW4gUVVJ Qywgd2UgY2FuIHNwbGl0IHRoZSBzaWduYWwgaW50byB0d28sIHdoaWNoIGNhbiBiZSB0YWlsb3Jl ZCBmb3IgZWFjaCB1c2UtY2FzZS4NCg0KVGhlIHNwbGl0IHdvdWxkIGhlbHAgdGhlIHByb3RvY29s IGV2b2x2ZSAoYXMgZml0IGZyb20gZW5kcG9pbnQgZGV2ZWxvcGVycycgcGVyc3BlY3RpdmUpLiBB dCB0aGUgc2FtZSB0aW1lLCBpdCBjb3VsZCBhbHNvIGhlbHAgb3BlcmF0b3JzLCBzaW5jZSB0aGUg c2lnbmFsIHRoZXkgdXNlIGNhbiBiZWNvbWUgbW9yZSBzdGFibGUgb3IgZXZvbHZlIGluIGEgZGlm ZmVyZW50IHBhY2UgKHNpbmNlIHRoZSBjaGFuZ2VzIHRvIHRoZSBlbmNyeXB0ZWQgcGFydCBvZiB0 aGUgcHJvdG9jb2wgd2lsbCBub3QgYWZmZWN0IHdoYXQgdGhlIG9wZXJhdG9ycyB3aWxsIHNlZSwg b3IgdmljZS12ZXJzYSkuDQoNCk5vdGUgYWxzbyB0aGF0IGV2ZW4gaW4gdGhlIGN1cnJlbnQgdW5l bmNyeXB0ZWQgZm9ybSwgcGFja2V0IG51bWJlcnMgb2YgUVVJQyBpcyBub3QgYXMgZWFzeSB0byB1 c2UgY29tcGFyZWQgdG8gVENQIChmcm9tIG9wZXJhdG9ycycgdmlld3BvaW50KSBzaW5jZSB0aGUg bnVtYmVycyBtb25vdG9uaWNhbGx5IGluY3JlYXNlIGFuZCBzaW5jZSBBQ0tzIGFyZSBlbmNyeXB0 ZWQuDQpTbyB0aGVyZSdzIGEgY2hhbmNlIHRvIG1ha2UgdGhlIHNpZ25hbCBtb3JlIHVzZWZ1bCBi eSBzcGxpdHRpbmcgdGhlIHNpZ25hbHMuIFNwaW4gYml0IGlzIGEgZ29vZCBleGFtcGxlLg0KDQo+ IFRoZSBvbmx5IHByb2JsZW0gd2l0aCB0aGlzIGlzIHRoYXQgdGhlIG1vc3Qgb2J2aW91cyBwbGFj ZSB0byBwdXQgdGhpcyBzaWduYWwgLS0gdGhlIGZvdXIgYml0cyB3ZSBnZXQgYmFjayBmcm9tIHRo ZSBzaG9ydCBoZWFkZXIgdHlwZSBmaWVsZCAoYXNzdW1pbmcgd2UgYWRkIHRoZSBzcGluIGJpdCkg YXJlbid0IHJlYWxseSBlbm91Z2ggdG8gdHJhY2sgdGhlIGxvc3MgYW5kIHJlb3JkZXJpbmcgcGF0 dGVybnMgd2UgY2FyZSBhYm91dCB3aXRoIGEgbmFpdmUgY291bnRlci4NCj4NCj4gVGhlcmUgYXJl IGxvdHMgb2Ygb3RoZXIgb3B0aW9ucyBpbiB0aGlzIHNwYWNlIChlLmcuIGRlY2lkZSB3ZSBjYXJl IGFib3V0IGxhdGVuY3kgbW9yZSB0aGFuIHJlb3JkZXJpbmcsIGFuZCB0aGF0IHdlIGRvbid0IGNh cmUgYWJvdXQgbG9zcyBhdCBhbGwsIGFuZCB1c2UgYSB0d28tYml0IHNwaW4gdG8gcHJvdGVjdCB0 aGUgbGF0ZW5jeSBzaWduYWwgZnJvbSByZW9yZGVyaW5nLCBhbmQgc28gb24pLCBidXQgdGhhdCBz ZWVtcyBsaWtlIGEgdGhpcmQgdGhyZWFkIHdlIHNob3VsZCBzdGFydC4NCj4NCj4gQ2hlZXJzLA0K Pg0KPiBCcmlhbg0KPg0KPj4gVGhpcyBpcyB0aGUgdHJhZGUtb2ZmLCBhbmQgSSBhbSBzdGlsbCBp biBmYXZvciBvZiBlbmNyeXB0aW5nIHBhY2tldCBudW1iZXJzLg0KPj4NCj4+IE9uIEZyaSwgRmVi IDIsIDIwMTggYXQgNzozMiBBTSwgRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRn ZSwgVUspIDx0aG9tYXMuZm9zc2F0aUBub2tpYS5jb20+IHdyb3RlOg0KPj4gT24gMzEvMDEvMjAx OCwgMTA6MDYsICJRVUlDIG9uIGJlaGFsZiBvZiBFZ2dlcnQsIExhcnMiIDxxdWljLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIGxhcnNAbmV0YXBwLmNvbT4gd3JvdGU6DQo+PiA+IE9uIDIw MTgtMS0zMSwgYXQgMTA6NTIsIEdvcnJ5IEZhaXJodXJzdCA8Z29ycnlAZXJnLmFiZG4uYWMudWs+ IHdyb3RlOg0KPj4gPiA+ICsxIC0gU2ltcGx5OiBUaGlzICppcyogY29tcGxpY2F0ZWQgYW5kIHNl ZW1zIHRvIGFkZCBsaXR0bGUuDQo+PiA+DQo+PiA+IFNvIGFzIGFuIGltcGxlbWVudG9yIChjaGFp ciBoYXQgb2ZmKSwgdGhpcyBhZGRzIHZlcnkgbGl0dGxlIHRvIHRoZSANCj4+ID4gb3ZlcmFsbCBj b21wbGV4aXR5IG9mIHRoZSBwcm90b2NvbC4NCj4+DQo+PiBUaGlzIGRvZXNuJ3Qgc291bmQgZ3Jl YXQuICBJdCdzIGEgYml0IGxpa2Ugc2F5aW5nIHRoYXQgYWRkaW5nIHRoZSANCj4+IEhpZ2dzIG1l Y2hhbmlzbSB0byB0aGUgc3RhbmRhcmQgbW9kZWwncyBsYWdyYW5naWFuIGRvZXNuJ3QgbWFrZSBp dCANCj4+IG11Y2ggbW9yZSBjb21wbGljYXRlIDotKSAgKCopDQo+Pg0KPj4gTW9yZSBzZXJpb3Vz bHkgdGhvdWdoLCBJJ2QgbGlrZSB0byBwb2ludCBvdXQgdGhhdCBpdCBpcyBub3QganVzdCANCj4+ IGFib3V0IGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHksIGl0J3MgYWxzbyB0aGUgZW5lcmd5IGNv c3QgcGVyIHBhY2tldCANCj4+IHRoYXQgaXMgcXVpdGUgY3J1Y2lhbC4gIEkgaGF2ZW4ndCBkb25l IHRoZSBtYXRoIGJ1dCBJU1RNIHRoYXQgDQo+PiBicmluZ2luZyBpbiBhbm90aGVyIGJhdGNoIG9m IG5vbi1vcHRpb25hbCBjcnlwdG8gY29tcHV0YXRpb24gb24gYSBwZXIgDQo+PiBwYWNrZXQgYmFz aXMgaXMgbm90IGdvaW5nIHRvIG1vdmUgdGhlIG5lZWRsZSBpbiB0aGUgcmlnaHQgZGlyZWN0aW9u IA0KPj4gZm9yIHN0YWNrcyB0aGF0IHJ1biBvbiBsb3cgcG93ZXIgKElvVCkuDQo+Pg0KPj4gVGhp cyBpcyBub3QgYSBjYXRhc3Ryb3BoZSAtIHdlIGhhdmUgQ29BUCBhbmQgYSAoRClUTFMgcHJvZmls ZSAtIGJ1dCANCj4+IG5laXRoZXIgaXQncyBpZGVhbCwgc2luY2UgY3V0dGluZyBvZmYgdGhlIHNt YWxsIHRoaW5ncyBmcm9tIHRoZSB3aWRlciANCj4+IGVjb3N5c3RlbSBjcmVhdGVzIGFuIGFydGlm aWNpYWwgZ2FwIHdoaWNoIHRoZW4gd2lsbCBuZWVkIGEgbWlkZGxlYm94IA0KPj4gdG8gYnJpZGdl LiAgKFN1cmUsIHdlIGhhdmUgc3BlY2lmaWVkIHRoZSBiZWhhdmlvdXIgb2YgYSBzaW1pbGFyIGJv eCANCj4+IGFscmVhZHksIGJ1dCBpdCdkIGJlIHJlYWxseSBiZXR0ZXIgaWYgdGhlIGV4dHJhIHRy YW5zbGF0aW9uIGxvZ2ljIA0KPj4gY291bGQgYmUgYXZvaWRlZCBpbiB0aGUgZmlyc3QgcGxhY2Uu KQ0KPj4NCj4+IEkgZ3Vlc3Mgd2hhdCBJJ20gc2F5aW5nIGlzIHRoYXQgUE4gZW5jcnlwdGlvbiBi ZWluZyBhIGNvcmUgbWVjaGFuaXNtIA0KPj4gdGhhdCBjYW4ndCBiZSBuZWdvdGlhdGVkIGF0IGhh bmRzaGFrZSB0aW1lIHJlZHVjZXMgb3VyIGFiaWxpdHkgdG8gDQo+PiBsYXRlciBwcm9maWxlIFFV SUMgZm9yIHRoZSBJb1QsIHdoaWNoIHdvdWxkIGJlIGEgYml0IHVubHVja3kuDQo+Pg0KPj4gU28g dGhlIHF1ZXN0aW9uIGlzOiB3b3VsZCBpdCBiZSBwb3NzaWJsZSB0byBtYWtlIHRoaXMgcHJvcGVy dHkgYSANCj4+IGNvbmZpZ3VyYWJsZSBrbm9iIGluc3RlYWQ/DQo+Pg0KPj4gKCopIA0KPj4gaHR0 cHM6Ly93d3cuc3ltbWV0cnltYWdhemluZS5vcmcvYXJ0aWNsZS90aGUtZGVjb25zdHJ1Y3RlZC1z dGFuZGFyZC1tDQo+PiBvZGVsLWVxdWF0aW9uDQo+Pg0KPj4NCj4NCg0KDQoNCi0tDQpLYXp1aG8g T2t1DQoNCg== From nobody Mon Feb 5 07:09:31 2018 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 3906E12D82E for ; Mon, 5 Feb 2018 07:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 gP-0yVn-rAc9 for ; Mon, 5 Feb 2018 07:09:27 -0800 (PST) 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 EE47412D80F for ; Mon, 5 Feb 2018 07:09:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zZrbT49pVz15Mqy; Mon, 5 Feb 2018 16:09:25 +0100 (CET) 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 Q1sCNC5MuEYK; Mon, 5 Feb 2018 16:09:24 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (mue-88-130-61-066.dsl.tropolys.de [88.130.61.66]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 5 Feb 2018 16:09:23 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Reducing ossification through protocol design (was Re: Packet number encryption) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <5A781798.6010101@erg.abdn.ac.uk> Date: Mon, 5 Feb 2018 16:09:22 +0100 Cc: "Brian Trammell (IETF)" , Roberto Peon , Gorry Fairhust Content-Transfer-Encoding: quoted-printable Message-Id: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <5A781798.6010101@erg.abdn.ac.uk> To: QUIC WG X-Mailer: Apple Mail (2.3445.5.20) 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, 05 Feb 2018 15:09:29 -0000 > Am 05.02.2018 um 09:36 schrieb Gorry Fairhurst : >=20 > I think it is entirely possible that a small set of fields in the = transport header may be usefully ossified to increase the deployability, = manageability and flexibility across a range of use cases. +1 if a field ossifies that is fully specified in one version and = indented to be used by the network in a certain way that can be helpful = for deployment. We really need to make sure however that middleboxes are = version-aware and basically deploying two or multiple versions at once = could be the right approach to make sure the version mechanism will be = usable in future. From nobody Mon Feb 5 08:39:41 2018 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 B13E5127201 for ; Mon, 5 Feb 2018 08:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] 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 GgXoYpJiwUHK for ; Mon, 5 Feb 2018 08:39:37 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 4A1E91270B4 for ; Mon, 5 Feb 2018 08:39:37 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w15GW2PC014018 for ; Mon, 5 Feb 2018 16:39:37 GMT 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-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=qbJbOGUt4vCHhvIR3YtP3OOXm+vueGSmHr/NorvGOds=; b=Si4NObnP1X4tT+4u/CD8WO9CitnIyEnRnFMi3UpNv5DtbPvoxfa6ry5A2XUTwg55LQ8/ wJuKNbIy+GgVy3XMO/jPUg9elFKpvkADuKBH4wMaqx7y1pWmV/kbcfszAAVcBZ3kyxsr H5tnNgr4EA4w8IhlpRUlJRhgswYwY7XjlVC9IReVfUYMrVhAo5KGyqLnNc78dRifwFJk qjSqdV+SB86PW/n1dAN80oa6mOLcYKeDVqaZ70IbVnq/2mYHeNF5fia9Mp9SRl57ural j5hBEsMDFgSC3ISyzqNrCX1Cy4U2YUidjX3c/rpDLqFc3WyefoB5iUlrPvPdRbKFp1zs fg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2fw579qgga-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 05 Feb 2018 16:39:36 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w15Ga2bR017508 for ; Mon, 5 Feb 2018 11:39:35 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fw9ae6avv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Mon, 05 Feb 2018 11:39:35 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 5 Feb 2018 11:39:34 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Mon, 5 Feb 2018 11:39:34 -0500 From: "Salz, Rich" To: QUIC WG Subject: Re: Reducing ossification through protocol design (was Re: Packet number encryption) Thread-Topic: Reducing ossification through protocol design (was Re: Packet number encryption) Thread-Index: AQHTnf+KWNUofjU1OkGT7iGhn7BVo6OV0LUAgABtuACAABkygA== Date: Mon, 5 Feb 2018 16:39:33 +0000 Message-ID: <6D4A2F58-F13A-46AB-80A3-E356DDE15A0F@akamai.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <5A781798.6010101@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.207] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=599 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050209 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_03:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=539 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050209 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, 05 Feb 2018 16:39:39 -0000 PiBJIHRoaW5rIGl0IGlzIGVudGlyZWx5IHBvc3NpYmxlIHRoYXQgYSBzbWFsbCBzZXQgb2YgZmll bGRzIGluIHRoZSB0cmFuc3BvcnQgaGVhZGVyIG1heSBiZSB1c2VmdWxseSBvc3NpZmllZCB0byBp bmNyZWFzZSB0aGUgZGVwbG95YWJpbGl0eSwgbWFuYWdlYWJpbGl0eSBhbmQgZmxleGliaWxpdHkg YWNyb3NzIGEgcmFuZ2Ugb2YgdXNlIGNhc2VzLg0KDQpUaGVuIHdlIHNob3VsZCB1c2UgYSB3b3Jk IGJlc2lkZXMgb3NzaWZpZWQsIHdoaWNoIGF0IHRoaXMgcG9pbnQgaGFzIGVudGlyZWx5IG5lZ2F0 aXZlIGNvbm5vdGF0aW9ucy4gIFBlcmhhcHMg4oCcZnJvemVu4oCdPw0KDQo= From nobody Mon Feb 5 08:42:59 2018 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 2CCD61270AE for ; Mon, 5 Feb 2018 08:42:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 7P_ElevrmGxR for ; Mon, 5 Feb 2018 08:42:56 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B04B127077 for ; Mon, 5 Feb 2018 08:42:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3zZtgL5RsNzMpt8; Mon, 5 Feb 2018 17:42:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ6Nt34ipeaJ; Mon, 5 Feb 2018 17:42:53 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (mue-88-130-61-066.dsl.tropolys.de [88.130.61.66]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 5 Feb 2018 17:42:53 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Reducing ossification through protocol design (was Re: Packet number encryption) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <6D4A2F58-F13A-46AB-80A3-E356DDE15A0F@akamai.com> Date: Mon, 5 Feb 2018 17:42:52 +0100 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <5FBE1ABB-C8CD-47BF-BEB7-792864A4BEE4@tik.ee.ethz.ch> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <5A781798.6010101@erg.abdn.ac.uk> <6D4A2F58-F13A-46AB-80A3-E356DDE15A0F@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3445.5.20) 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, 05 Feb 2018 16:42:58 -0000 If that helps I=E2=80=99m all in for that! > Am 05.02.2018 um 17:39 schrieb Salz, Rich : >=20 >> I think it is entirely possible that a small set of fields in the = transport header may be usefully ossified to increase the deployability, = manageability and flexibility across a range of use cases. >=20 > Then we should use a word besides ossified, which at this point has = entirely negative connotations. Perhaps =E2=80=9Cfrozen=E2=80=9D? >=20 From nobody Mon Feb 5 09:25:04 2018 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 9D0FD1270AB for ; Mon, 5 Feb 2018 09:25:02 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 Swq4KwzqPtSl for ; Mon, 5 Feb 2018 09:24:59 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0120.outbound.protection.outlook.com [104.47.36.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208811273B1 for ; Mon, 5 Feb 2018 09:24:58 -0800 (PST) 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=f5KNe2XamIlsYG610TEwkv7hFfMaEfvs9HjsJGIqSWY=; b=WLuQ8ymf5QmexfW9mwd9l9x8KUww2OIcWhibTWKWjGi2GMqgwTBOdUTySVV4dhzew7sNtE+dAi+osvZmbWY3UWPSXU8NJCe3q7ZPDUY//A6b5bUynC49iTnBe0lG425fLAue6x9PT1SxaUu1IHBOf+G+HALKvkf4CyyfEIUyqyE= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0503.namprd21.prod.outlook.com (10.172.122.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Mon, 5 Feb 2018 17:24:56 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Mon, 5 Feb 2018 17:24:56 +0000 From: Praveen Balasubramanian To: Jana Iyengar , "Salz, Rich" CC: "Lubashev, Igor" , Roberto Peon , QUIC WG Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaA= Date: Mon, 5 Feb 2018 17:24:56 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0503; 7:riCnB4OTEmnCzF4N9souJbnFwxuJnnZd/o17yWpza3N7noKwPN60I4kc4VgvTh9rKz5nR+OrZqDH9pp3bz+CMlB/veoa8s3hXRP/lWQ2QMXIEvaCCt6MeLvA3who+ip/wf2xxMlaDTHILC97bfNqarPjdDpy+KYzh1ZIeW3TJmy7pCI2XJTOu8HNpaVdKDWAW42wCOW1Nfp3smm1L8umZQlIcvGw/wCPz4LKJEEiYkK/O05IEnIYu9yudufej/yv x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ed057d99-7430-4eab-c5e8-08d56cbd607d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:CY4PR21MB0503; x-ms-traffictypediagnostic: CY4PR21MB0503: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(67672495146484)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0503; BCL:0; PCL:0; RULEID:(3232008); SRVR:CY4PR21MB0503; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(39380400002)(376002)(346002)(396003)(199004)(189003)(6116002)(790700001)(229853002)(186003)(59450400001)(102836004)(53546011)(6506007)(74316002)(6436002)(5660300001)(55016002)(2950100002)(77096007)(68736007)(2906002)(8990500004)(4326008)(3660700001)(10290500003)(86362001)(7116003)(3280700002)(14454004)(76176011)(6346003)(19609705001)(7736002)(7696005)(97736004)(99286004)(478600001)(25786009)(10090500001)(81156014)(8936002)(81166006)(106356001)(105586002)(54906003)(110136005)(8676002)(316002)(3480700004)(236005)(9686003)(6306002)(86612001)(53936002)(54896002)(6246003)(33656002)(22452003)(2900100001)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0503; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: yQREeLlf1gGPF8zJphWDcS+TT5l26gC5enOyJ+HdI+tcwLhLBIAF31/M6ym1OVrN4UnDoMDVfSJNHOo1t6UKYQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01334E30C7AF6AE75F58EEFDB6FE0CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ed057d99-7430-4eab-c5e8-08d56cbd607d X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 17:24:56.4736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0503 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, 05 Feb 2018 17:25:03 -0000 --_000_CY4PR21MB01334E30C7AF6AE75F58EEFDB6FE0CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gVGhpcyB3YXMgZGVmaW5pdGVseSB0cnVlIGZvciBpbXBsZW1lbnRhdGlvbnMgb2YgVENQLCBi dXQgdGhhdCBpcyBUQ1AncyBwcm9ibGVtLCBub3QgdGhlIG5ldHdvcmsncw0KRmxvdyBjbGFzc2lm aWNhdGlvbiBoYXBwZW5zIHRocm91Z2ggdGhlIG5ldHdvcmsgYW5kIGFsc28gb24gdGhlIGVuZCBo b3N0IHdpdGggUlNTIHdoZXJlIGEgZmxvdyBpcyBtYXBwZWQgdG8gYSBjb3JlLiBUaGlzIGFsbG93 cyBmb3IgYnVpbGRpbmcgaGlnaCBwZXJmb3JtYW5jZSByZWNlaXZlIHByb2Nlc3NpbmcgdGhhdCBj b3VsZCBiZSBsb2NrIGZyZWUgZm9yIHRoZSBtb3N0IHBhcnQuIFRoZSBvbmx5IGRvd25zaWRlIG9m IEVDTVAgb24gdGhlIG5ldHdvcmsgYW5kIFJTUyBvbiB0aGUgQ1BVIGlzIHRoYXQgYSBzaW5nbGUg ZmxvdyB3aWxsIG5vdCB0YWtlIG11bHRpcGxlIHBhdGhzIG9yIGdldCBwcm9jZXNzZWQgb24gbW9y ZSB0aGFuIG9uZSBjb3JlLiBXaW5kb3dzIG9uIHNlcnZlciBtYWNoaW5lcyB0b2RheSBjYW4gc2F0 dXJhdGUgMjUtMzUgR2JwcyBmb3IgYSBzaW5nbGUgVENQIGNvbm5lY3Rpb24gYmVmb3JlIGJlaW5n IENQVSBsaW1pdGVkLiBUaGlzIGlzIGEgIHJlYXNvbmFibGUgdHJhZGUgb2ZmIGJlY2F1c2UgSSBk b27igJl0IGtub3cgb2YgY2FzZXMgd2hlcmUgYSBzaW5nbGUgZmxvdyBpcyBkcml2aW5nIG1vcmUg dGhhbiB0aGF0IGFtb3VudCBvZiB0cmFmZmljLiBBc3N1bXB0aW9ucyBhYm91dCBob3cgZmxvd3Mg Z2V0IGNsYXNzaWZpZWQgaGVscCBtYWtlIGZvciBtb3JlIGVmZmljaWVudCBwcm9jZXNzaW5nLiBU aGV5IGFsc28gbGVhZCB0byBjb25zaXN0ZW50IGxhdGVuY3kuIFlvdSBkbyBub3Qgd2FudCB0aGUg dHJhZmZpYyB0byB0YWtlIGEgYmktbW9kYWwgb3IgTi1tb2RhbCBwYXRocyAob24gdGhlIG5ldHdv cmsgb3IgdGhlIGhvc3QpIHRvIGJlaW5nIHByb2Nlc3NlZCBiZWNhdXNlIHRoZSBmbHVjdHVhdGlv bnMgaW4gbGF0ZW5jeSB3aWxsIGh1cnQgdGhlIHdvcmtsb2FkLiBJIGFtIG5vdCBhcmd1aW5nIGZv ciBUQ1Agbm90IGJlaW5nIHJlc2lsaWVudCB0byByZW9yZGVyaW5nIGJ1dCBJTU8gdGhhdCBzaG91 bGQgYmUgdGhlIHVuY29tbW9uIGNhc2Ugbm90IHRoZSBjb21tb24gY2FzZS4gV2l0aCBRVUlDIGlm IHN0cmVhbXMgd2VyZSBleHBvc2VkIG9uIHRoZSBuZXR3b3JrIHlvdSBjb3VsZCB0YWtlIGFkdmFu dGFnZSBvZiBzdHJlYW0gbGV2ZWwgRUNNUCBhbmQgUlNTIHRvIHNjYWxlIGJldHRlciB0aGFuIFRD UCBidXQgd2UgaGF2ZSBjaG9zZW4gdG8ga2VlcCB0aGUgNC10dXBsZSAob3IgdGhlIDUtdHVwbGUp IGFzIHRoZSBmbG93IGNsYXNzaWZpZXIgb24gdGhlIG5ldHdvcmsgd2hpY2ggaXMgb2sgYnkgbWUg c2luY2UgaXQgbGVhZHMgdG8gVENQIHBhcml0eS4NCg0KVGhhbmtzDQoNCkZyb206IFFVSUMgW21h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYW5hIEl5ZW5nYXINClNl bnQ6IFN1bmRheSwgRmVicnVhcnkgNCwgMjAxOCA4OjM1IFBNDQpUbzogU2FseiwgUmljaCA8cnNh bHpAYWthbWFpLmNvbT4NCkNjOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT47 IFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KUHJpdmFjeS1wcm90ZWN0aW9u IGNhbid0IGJlIGEgdXNlciBjaG9pY2UsIGZvciB0aGUgcmVhc29ucyBvdGhlcnMgaGF2ZSBub3Rl ZCBvbiB0aGlzIHRocmVhZC4NCg0KVGhhdCBzYWlkLCBteSBwcmltYXJ5IGFyZ3VtZW50IGlzIGZv ciBlbmNyeXB0aW9uIHRvIGF2b2lkIG9zc2lmaWNhdGlvbi4gTm90IHRoYXQgaXQgbWF0dGVycyBu b3csIGJ1dCBJJ2xsIG5vdGUgdGhhdCBtdWNoIG9mIEdRVUlDJ3Mgb3JpZ2luYWwgbW90aXZhdGlv biBmb3IgZW5jcnlwdGluZyBoZWFkZXJzIHdhcyB0byBhdm9pZCBvc3NpZmljYXRpb24uDQoNCkkn bGwgcmVpdGVyYXRlIHRoYXQgZmllbGRzIHdlIGV4cG9zZSB3aWxsIGdldCBvc3NpZmllZCBhbmQg dGhlcmUgYXJlIGxvbmctdGVybSBlY29zeXN0ZW0gZWZmZWN0cyB0byB0aGlzLiBMZXQgbWUgaWxs dXN0cmF0ZSB0aGlzIHdpdGggcHJlY2lzZWx5IHRoZSBwYWNrZXQgbnVtYmVyIGZpZWxkLiBNaWRk bGVib3hlcyBjb21tb25seSBhc3N1bWUgdGhhdCBhIFRDUCBmbG93IGNhbiBvbmx5IGhhbmRsZSBw YWNrZXRzIGluLW9yZGVyLiBUaGlzIGFzc3VtcHRpb24gY29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0 IFRDUCBpbXBsZW1lbnRhdGlvbnMgZ2V0IHBvb3IgcGVyZm9ybWFuY2Ugd2hlbiBwYWNrZXRzIGFy ZSByZW9yZGVyZWQuIFRoaXMgd2FzIGRlZmluaXRlbHkgdHJ1ZSBmb3IgaW1wbGVtZW50YXRpb25z IG9mIFRDUCwgYnV0IHRoYXQgaXMgVENQJ3MgcHJvYmxlbSwgbm90IHRoZSBuZXR3b3JrJ3MuIEhv d2V2ZXIsIGFsbW9zdCBhbGwgbG9hZC1iYWxhbmNlcnMgSSBrbm93IG9mIG5vdyB3aWxsIHBpbiBh bGwgcGFja2V0cyB3aXRoaW4gYSBUQ1AgZmxvdyB0byBvbmUgcGF0aCwgbGVhZGluZyB0byBzdWIt b3B0aW1hbCBwZXJmb3JtYW5jZSBpbiB0aGUgbmV0d29yaywgYW5kIGRlc3Ryb3lpbmcgaW5jZW50 aXZlcyBmb3IgdGhlIGVuZHBvaW50cyB0byBkZXBsb3kgcmVvcmRlcmluZy1yZXNpbGllbnQgVENQ IGltcGxlbWVudGF0aW9ucyAoZXZlbiB0aG91Z2ggdGhlcmUgYXJlIHBsZW50eSBvZiB3YXlzIG9m IGRvaW5nIHRoaXMuKQ0KDQpFeHBvc2luZyBRVUlDJ3MgcGFja2V0IG51bWJlciBmaWVsZCAoYXMg YW55IGZpZWxkKSBpcyBsaWtlbHkgdG8gaGF2ZSBzaW1pbGFyIGNvbnNlcXVlbmNlcyBhbmQgYSBz aW1pbGFyIGVjb3N5c3RlbSBhcmMuDQoNCg0KT24gU3VuLCBGZWIgNCwgMjAxOCBhdCA3OjUxIFBN LCBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpyc2FsekBha2FtYWkuY29tPj4g d3JvdGU6DQoNCj4gT3B0aW9uYWwgc2VjdXJpdHkgdGVuZHMgdG8gZGV2b2x2ZSB0byBub24tc2Vj dXJlLg0KDQoNCg0KVGhhdOKAmXMgYSBncmVhdCBhcGhvcmlzbS4gIEFuZCBzYWRseSBhbGwgdG9v IHRydWUuDQoNCg== --_000_CY4PR21MB01334E30C7AF6AE75F58EEFDB6FE0CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubS03OTE0ODc2MDgyNDI1Nzg1MDR4 bXNvbm9ybWFsLCBsaS5tLTc5MTQ4NzYwODI0MjU3ODUwNHhtc29ub3JtYWwsIGRpdi5tLTc5MTQ4 NzYwODI0MjU3ODUwNHhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6bV8tNzkxNDg3NjA4MjQy NTc4NTA0eG1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBUaGlzIHdhcyBkZWZpbml0ZWx5IHRydWUg Zm9yIGltcGxlbWVudGF0aW9ucyBvZiBUQ1AsIGJ1dCB0aGF0IGlzIFRDUCdzIHByb2JsZW0sIG5v dCB0aGUgbmV0d29yaydzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GbG93 IGNsYXNzaWZpY2F0aW9uIGhhcHBlbnMgdGhyb3VnaCB0aGUgbmV0d29yayBhbmQgYWxzbyBvbiB0 aGUgZW5kIGhvc3Qgd2l0aCBSU1Mgd2hlcmUgYSBmbG93IGlzIG1hcHBlZCB0byBhIGNvcmUuIFRo aXMgYWxsb3dzIGZvciBidWlsZGluZyBoaWdoIHBlcmZvcm1hbmNlIHJlY2VpdmUgcHJvY2Vzc2lu ZyB0aGF0IGNvdWxkIGJlIGxvY2sgZnJlZSBmb3IgdGhlIG1vc3QgcGFydC4gVGhlIG9ubHkgZG93 bnNpZGUNCiBvZiBFQ01QIG9uIHRoZSBuZXR3b3JrIGFuZCBSU1Mgb24gdGhlIENQVSBpcyB0aGF0 IGEgc2luZ2xlIGZsb3cgd2lsbCBub3QgdGFrZSBtdWx0aXBsZSBwYXRocyBvciBnZXQgcHJvY2Vz c2VkIG9uIG1vcmUgdGhhbiBvbmUgY29yZS4gV2luZG93cyBvbiBzZXJ2ZXIgbWFjaGluZXMgdG9k YXkgY2FuIHNhdHVyYXRlIDI1LTM1IEdicHMgZm9yIGEgc2luZ2xlIFRDUCBjb25uZWN0aW9uIGJl Zm9yZSBiZWluZyBDUFUgbGltaXRlZC4gVGhpcyBpcyBhICZuYnNwO3JlYXNvbmFibGUNCiB0cmFk ZSBvZmYgYmVjYXVzZSBJIGRvbuKAmXQga25vdyBvZiBjYXNlcyB3aGVyZSBhIHNpbmdsZSBmbG93 IGlzIGRyaXZpbmcgbW9yZSB0aGFuIHRoYXQgYW1vdW50IG9mIHRyYWZmaWMuIEFzc3VtcHRpb25z IGFib3V0IGhvdyBmbG93cyBnZXQgY2xhc3NpZmllZCBoZWxwIG1ha2UgZm9yIG1vcmUgZWZmaWNp ZW50IHByb2Nlc3NpbmcuIFRoZXkgYWxzbyBsZWFkIHRvIGNvbnNpc3RlbnQgbGF0ZW5jeS4gWW91 IGRvIG5vdCB3YW50IHRoZSB0cmFmZmljIHRvDQogdGFrZSBhIGJpLW1vZGFsIG9yIE4tbW9kYWwg cGF0aHMgKG9uIHRoZSBuZXR3b3JrIG9yIHRoZSBob3N0KSB0byBiZWluZyBwcm9jZXNzZWQgYmVj YXVzZSB0aGUgZmx1Y3R1YXRpb25zIGluIGxhdGVuY3kgd2lsbCBodXJ0IHRoZSB3b3JrbG9hZC4g SSBhbSBub3QgYXJndWluZyBmb3IgVENQIG5vdCBiZWluZyByZXNpbGllbnQgdG8gcmVvcmRlcmlu ZyBidXQgSU1PIHRoYXQgc2hvdWxkIGJlIHRoZSB1bmNvbW1vbiBjYXNlIG5vdCB0aGUgY29tbW9u DQogY2FzZS4gV2l0aCBRVUlDIGlmIHN0cmVhbXMgd2VyZSBleHBvc2VkIG9uIHRoZSBuZXR3b3Jr IHlvdSBjb3VsZCB0YWtlIGFkdmFudGFnZSBvZiBzdHJlYW0gbGV2ZWwgRUNNUCBhbmQgUlNTIHRv IHNjYWxlIGJldHRlciB0aGFuIFRDUCBidXQgd2UgaGF2ZSBjaG9zZW4gdG8ga2VlcCB0aGUgNC10 dXBsZSAob3IgdGhlIDUtdHVwbGUpIGFzIHRoZSBmbG93IGNsYXNzaWZpZXIgb24gdGhlIG5ldHdv cmsgd2hpY2ggaXMgb2sgYnkgbWUgc2luY2UgaXQgbGVhZHMNCiB0byBUQ1AgcGFyaXR5LiA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYg T2YNCjwvYj5KYW5hIEl5ZW5nYXI8YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBGZWJydWFyeSA0 LCAyMDE4IDg6MzUgUE08YnI+DQo8Yj5Ubzo8L2I+IFNhbHosIFJpY2ggJmx0O3JzYWx6QGFrYW1h aS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWth bWFpLmNvbSZndDs7IFJvYmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29tJmd0OzsgUVVJQyBXRyAm bHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tldCBudW1i ZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJpdmFjeS1wcm90 ZWN0aW9uIGNhbid0IGJlIGEgdXNlciBjaG9pY2UsIGZvciB0aGUgcmVhc29ucyBvdGhlcnMgaGF2 ZSBub3RlZCBvbiB0aGlzIHRocmVhZC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQpUaGF0IHNhaWQsIG15IHByaW1hcnkgYXJndW1lbnQgaXMg Zm9yIGVuY3J5cHRpb24gdG8gYXZvaWQgb3NzaWZpY2F0aW9uLiBOb3QgdGhhdCBpdCBtYXR0ZXJz IG5vdywgYnV0IEknbGwgbm90ZSB0aGF0IG11Y2ggb2YgR1FVSUMncyBvcmlnaW5hbCBtb3RpdmF0 aW9uIGZvciBlbmNyeXB0aW5nIGhlYWRlcnMgd2FzIHRvIGF2b2lkIG9zc2lmaWNhdGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdsbCBy ZWl0ZXJhdGUgdGhhdCBmaWVsZHMgd2UgZXhwb3NlIHdpbGwgZ2V0IG9zc2lmaWVkIGFuZCB0aGVy ZSBhcmUgbG9uZy10ZXJtIGVjb3N5c3RlbSBlZmZlY3RzIHRvIHRoaXMuIExldCBtZSBpbGx1c3Ry YXRlIHRoaXMgd2l0aCBwcmVjaXNlbHkgdGhlIHBhY2tldCBudW1iZXIgZmllbGQuIE1pZGRsZWJv eGVzIGNvbW1vbmx5IGFzc3VtZSB0aGF0IGEgVENQIGZsb3cgY2FuIG9ubHkgaGFuZGxlIHBhY2tl dHMNCiBpbi1vcmRlci4gVGhpcyBhc3N1bXB0aW9uIGNvbWVzIGZyb20gdGhlIGZhY3QgdGhhdCBU Q1AgaW1wbGVtZW50YXRpb25zIGdldCBwb29yIHBlcmZvcm1hbmNlIHdoZW4gcGFja2V0cyBhcmUg cmVvcmRlcmVkLiBUaGlzIHdhcyBkZWZpbml0ZWx5IHRydWUgZm9yIGltcGxlbWVudGF0aW9ucyBv ZiBUQ1AsIGJ1dCB0aGF0IGlzIFRDUCdzIHByb2JsZW0sIG5vdCB0aGUgbmV0d29yaydzLiBIb3dl dmVyLCBhbG1vc3QgYWxsIGxvYWQtYmFsYW5jZXJzIEkNCiBrbm93IG9mIG5vdyB3aWxsIHBpbiBh bGwgcGFja2V0cyB3aXRoaW4gYSBUQ1AgZmxvdyB0byBvbmUgcGF0aCwgbGVhZGluZyB0byBzdWIt b3B0aW1hbCBwZXJmb3JtYW5jZSBpbiB0aGUgbmV0d29yaywgYW5kIGRlc3Ryb3lpbmcgaW5jZW50 aXZlcyBmb3IgdGhlIGVuZHBvaW50cyB0byBkZXBsb3kgcmVvcmRlcmluZy1yZXNpbGllbnQgVENQ IGltcGxlbWVudGF0aW9ucyAoZXZlbiB0aG91Z2ggdGhlcmUgYXJlIHBsZW50eSBvZiB3YXlzIG9m IGRvaW5nDQogdGhpcy4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkV4cG9zaW5nIFFVSUMncyBwYWNrZXQgbnVtYmVyIGZpZWxkIChhcyBhbnkg ZmllbGQpIGlzIGxpa2VseSB0byBoYXZlIHNpbWlsYXIgY29uc2VxdWVuY2VzIGFuZCBhIHNpbWls YXIgZWNvc3lzdGVtIGFyYy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEZlYiA0LCAyMDE4IGF0IDc6NTEgUE0sIFNhbHosIFJp Y2ggJmx0OzxhIGhyZWY9Im1haWx0bzpyc2FsekBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ cnNhbHpAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPiZndDsgT3B0aW9uYWwgc2VjdXJpdHkgdGVuZHMgdG8gZGV2b2x2ZSB0byBub24tc2Vj dXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Im0tNzkxNDg3NjA4MjQyNTc4NTA0eG1zb25vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS03OTE0ODc2MDgyNDI1Nzg1MDR4bXNvbm9ybWFsIj5U aGF04oCZcyBhIGdyZWF0IGFwaG9yaXNtLiZuYnNwOyBBbmQgc2FkbHkgYWxsIHRvbyB0cnVlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_CY4PR21MB01334E30C7AF6AE75F58EEFDB6FE0CY4PR21MB0133namp_-- From nobody Mon Feb 5 10:19:52 2018 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 22B5312D892 for ; Mon, 5 Feb 2018 10:19:51 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 iv93JZ-OOOWh for ; Mon, 5 Feb 2018 10:19:49 -0800 (PST) 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 98A5A12D88E for ; Mon, 5 Feb 2018 10:19:39 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eilM5-0000Pm-ID for quic@ietf.org; Mon, 05 Feb 2018 19:19:09 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eilLg-0001gb-S3 for quic@ietf.org; Mon, 05 Feb 2018 13:18:40 -0500 Received: (qmail 14502 invoked from network); 5 Feb 2018 18:18:13 -0000 Received: from unknown (HELO [192.168.200.65]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Feb 2018 18:18:13 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-7EC7A3F8-6ED0-4673-9916-0A768309CE2A Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15C202) In-Reply-To: Date: Mon, 5 Feb 2018 08:18:10 -1000 Cc: "Brian Trammell (IETF)" , Lars Eggert , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Mark Nottingham Content-Transfer-Encoding: 7bit Message-Id: <3761ABF1-6BE5-46F6-B8BD-958365B71A6D@huitema.net> References: To: Ian Swett Subject: Re: Call for Adoption: Invariants X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5qXXpqj00edi0rmbKqIisYMXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsYay3JbAQaXjRPLmDkDLz8B98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CstDAjCNidMNTTT2l8YX9HmUTmj0QZk3SQ/TbYRr7yfbx6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGcyNBJprCgmabT8JgPqpM5kvKSvC0LDy5UGAFpFuWjTgS aara5b+hdT6nDe+yMl3p9u7OTA2dS2mw7K5brBO3Qlz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiBfcoxmrjechJW+9VrFT0uBx3h1vgDbEdmhrg3iVBpdRY15+ZZmMZUyV9HJAkRDrR5GpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj 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: Mon, 05 Feb 2018 18:19:51 -0000 --Apple-Mail-7EC7A3F8-6ED0-4673-9916-0A768309CE2A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, invariants are useful, and the draft too. Take the example of the omit CID bit in the short header. If it were version= dependent, you could not understand it without first retrieving the connect= ion context to find which version is used. But to do that you need to parse t= he CID, so you need to know whether it is present. That said, what about the 17 bytes CID PR? -- Christian Huitema=20 > On Feb 5, 2018, at 4:04 AM, Ian Swett wrote: >=20 > I support adoption of the invariants draft. >=20 >> On Mon, Feb 5, 2018 at 3:33 AM, Brian Trammell (IETF) w= rote: >> Hi, all, >>=20 >> I support adoption of the invariants draft. >>=20 >> > On 5 Feb 2018, at 08:51, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> > >> > Only concern is when it takes effect since it likely needs adjustments.= >>=20 >> I'd presume that invariants is published simultaneously with the version 1= spec. >=20 > =46rom the perspective of someone intending to deploy draft versions, the i= nvariants need to be stable, ideally at least in a last call state, sooner t= han the version 1 spec, otherwise there's no guarantee a server can migrate f= rom one version to another. >=20 >>=20 >> > And perhaps a procedure to handle invariant changes since everything ch= anges. >>=20 >> Noted, though the point of declaring something an invariant is to say "th= e meaning of this part of the wire image, expressed as a bit offset, will ne= ver change". You can add constraints to the invariants, but if you think you= might remove a constraint, then it's not an invariant by definition. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> > From: QUIC on behalf of Mark Nottingham >> > Sent: Monday, February 5, 2018 7:07:45 AM >> > To: QUIC WG >> > Cc: Lars Eggert >> > Subject: Call for Adoption: Invariants >> > >> > At the Melbourne meeting, there was strong support for adopting Martin'= s invariants draft: >> > >> > https://tools.ietf.org/html/draft-thomson-quic-invariants-00 >> > >> > Any objections / concerns about doing so? Unless we hear otherwise, we'= ll adopt at the end of the week. >> > >> > Cheers, >> > >> > -- >> > Mark Nottingham https://www.mnot.net/ >>=20 >=20 --Apple-Mail-7EC7A3F8-6ED0-4673-9916-0A768309CE2A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yes, invariants are useful, and the draft t= oo.

Take the example of the omit CID bit in the short hea= der. If it were version dependent, you could not understand it without first= retrieving the connection context to find which version is used. But to do t= hat you need to parse the CID, so you need to know whether it is present.

That said, what about the 17 bytes CID PR?

-- Christian Huitema 

On Feb 5= , 2018, at 4:04 AM, Ian Swett <ian= swett@google.com> wrote:

=
I support adoption of the invariants draft.

On Mon, Feb 5, 2018 at 3:33 AM, Br= ian Trammell (IETF) <ietf@trammell.ch> wrote:
Hi, all,

I support adoption of the invariants draft.

> On 5 Feb 2018, at 08:51, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
>
> Only concern is when it takes effect since it likely needs adjustments.=

I'd presume that invariants is published simultaneously with the vers= ion 1 spec.

=46rom the perspective of so= meone intending to deploy draft versions, the invariants need to be stable, i= deally at least in a last call state, sooner than the version 1 spec, otherw= ise there's no guarantee a server can migrate from one version to another.


> And perhaps a procedure to handle invariant changes since everything ch= anges.

Noted, though the point of declaring something an invariant is to say= "the meaning of this part of the wire image, expressed as a bit offset, wil= l never change". You can add constraints to the invariants, but if you think= you might remove a constraint, then it's not an invariant by definition.
Cheers,

Brian

> From: QUIC <quic-bounces@ie= tf.org> on behalf of Mark Nottingham <mnot@mnot.net>
> Sent: Monday, February 5, 2018 7:07:45 AM
> To: QUIC WG
> Cc: Lars Eggert
> Subject: Call for Adoption: Invariants
>
> At the Melbourne meeting, there was strong support for adopting Martin'= s invariants draft:
>
> https://tools.ietf.org/html/draf= t-thomson-quic-invariants-00
>
> Any objections / concerns about doing so? Unless we hear otherwise, we'= ll adopt at the end of the week.
>
> Cheers,
>
> --
> Mark Nottingham   https://www.mnot.net/


= --Apple-Mail-7EC7A3F8-6ED0-4673-9916-0A768309CE2A-- From nobody Mon Feb 5 10:59:18 2018 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 4D9B012D940 for ; Mon, 5 Feb 2018 10:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 n94DErRGCi2D for ; Mon, 5 Feb 2018 10:59:13 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0107.outbound.protection.outlook.com [104.47.36.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 551411275AB for ; Mon, 5 Feb 2018 10:59:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rCZvuHLHNVorIiKcQPNcPOldDzc3LfRWwDhRFfNUeOY=; b=JgX/wm/7W2f6ws4JNYWRifrpDZ3GvsPvxSY2F/S4No27SxPGUL6RRnE03kpmv28ltFGFE50QgJhbytHZ3vq/No1NFwAKPLozyr7qN8LyzvtwkcM4TLfuNUIBOJcPWY9MZRUSSxy6bmllqUis3KSBcLfjVCQJ1LzGWbFAvkLbWmw= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB3405.namprd08.prod.outlook.com (10.164.203.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 18:59:09 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 18:59:09 +0000 From: Mike Bishop To: "Roni Even (A)" , "quic@ietf.org" CC: Kazuho Oku Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW33YzpoOLX0UU2dbBSG8l3vaKOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAC0PSAgAENaICAAA6uAIAAS1MQ Date: Mon, 5 Feb 2018 18:59:09 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <6E58094ECC8D8344914996DAD28F1CCD861F8E@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD861F8E@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB3405; 7:AIr7AaynUDmSYGKz+wbcbhwtEY/GgTz14z5vg1z45DFy8nX6lyUytUVXaYSVbF0XGTv/EBO/Mgxfu1VF19vJa0FlYeaqAIZzSprkx4lBNhN1xlIAWi7iZjYwsxBdH2vCS1BaJY2rifgj/j8hwVMpKQbFtwx2xTzvZ0xiocC/g+RTe6BZFuhfg3C7lrqS9BhHLM9toJ9gyBECCfLmUSNKSqSr1b2P3AVJ4KKDv/SCWXGEB8L146KGyrCFDnoCJfE1 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ebfe5264-7a25-484c-4d1d-08d56cca89f4 x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB3405; x-ms-traffictypediagnostic: MWHPR08MB3405: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(130329453890623); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(3002001)(6041288)(20161123562045)(2016111802025)(20161123560045)(20161123564045)(20161123558120)(6043046)(6072148)(201708071742011); SRVR:MWHPR08MB3405; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB3405; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(396003)(39380400002)(346002)(39830400003)(189003)(199004)(377424004)(13464003)(11905935001)(6116002)(6246003)(39060400002)(53936002)(966005)(55016002)(9686003)(6436002)(14454004)(93886005)(229853002)(8676002)(7116003)(5660300001)(81166006)(81156014)(8936002)(3280700002)(68736007)(3846002)(316002)(3660700001)(2950100002)(6306002)(33656002)(2501003)(7696005)(2906002)(74316002)(3480700004)(102836004)(4001150100001)(106356001)(110136005)(99286004)(66066001)(97736004)(25786009)(26005)(478600001)(86362001)(77096007)(105586002)(59450400001)(2900100001)(6506007)(53546011)(4326008)(186003)(76176011)(7736002)(74482002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB3405; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: YzRxrMDqShJjRfEuj5CNUXx/7onZuzaXz6y21NOV4JMtsJ/CG4Oukv44hCJ8DBsQhcYN0BxeBx5CImcM/WfdFA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: ebfe5264-7a25-484c-4d1d-08d56cca89f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 18:59:09.4600 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB3405 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, 05 Feb 2018 18:59:16 -0000 VGhlcmUgYXJlIG92ZXJsYXBwaW5nIGludGVyZXN0cywgYnV0IHRoZXkgYXJlIGNlcnRhaW5seSBu b3QgdGhlIHNhbWUuICBXaGVuIHNvbWVvbmUgb24gdGhlIG5ldHdvcmsgc2lkZSBzYXlzICJyZWxp YWJsZSwiIGV2ZXJ5b25lIGF0IHRoZSBlbmRwb2ludHMgaGVhcnMgIm9zc2lmaWVkLCIgYmVjYXVz ZSBvbmNlIHRoZSBuZXR3b3JrIHN0YXJ0cyByZWx5aW5nIG9uIGEgYmVoYXZpb3IsIHlvdSBjYW4n dCByZWFsaXN0aWNhbGx5IGNoYW5nZSBpdC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBS b25pIEV2ZW4gKEEpDQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDUsIDIwMTggNjoyOCBBTQ0KVG86 IHF1aWNAaWV0Zi5vcmcNCkNjOiBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPg0KU3Vi amVjdDogUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpIaSwNCg0KSSB3YW50IHRvIGNv bW1lbnQgb24NCiIgVGhlcmUgYXJlIHR3byBwYXJ0aWVzIHdpdGggZGlmZmVyZW50IGludGVyZXN0 cy4gRW5kcG9pbnQgZGV2ZWxvcGVycyB3YW50IHNvbWV0aGluZyBtb3JlIHN0cmFpZ2h0Zm9yd2Fy ZCB0byBpbXBsZW1lbnQgYW5kIGFsc28gaXMgc2FmZSBmcm9tIG9zc2lmaWNhdGlvbi4gT3BlcmF0 b3JzIHdhbnQgYSB0b29sIGZvciBkaWFnbm9zaXMuIg0KDQpJIGFncmVlIHRoYXQgdGhlcmUgYXJl IHR3byBwYXJ0aWVzIGJ1dCBJIGhvcGUgdGhhdCB3ZSBzaGFyZSB0aGUgc2FtZSBpbnRlcmVzdCB3 aGljaCBpcyB0byBoYXZlIGEgc2VjdXJlLCByZWxpYWJsZSBwcm90b2NvbCB0aGF0IGFsc28gc3Vw cG9ydCBtYW5hZ2VhYmlsaXR5IGluIGFjdHVhbCB0cmFuc3BvcnQgbmV0d29ya3MuDQoNCkFzIGZv ciBoYXZpbmcgcGFyYWxsZWwgbWVjaGFuaXNtcywgb25lIG9mIHRoZSBwb2ludHMgYWJvdXQgdGhl IHVzYWJpbGl0eSBvZiBzcGluIGJpdCB3YXMgdGhhdCBpdCBub3QgcGFydCBvZiB0aGUgcHJvdG9j b2wgc3RhdGUgbWFjaGluZSBhbmQgdGhhdCBtYWtlcyBpdCBsZXNzIHJlbGlhYmxlLA0KDQpSb25p DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgS2F6dWhvIE9rdQ0KU2VudDogTW9uZGF5LCBG ZWJydWFyeSAwNSwgMjAxOCAzOjM2IFBNDQpUbzogQnJpYW4gVHJhbW1lbGwgKElFVEYpDQpDYzog R29ycnkgRmFpcmh1cnN0OyBFcmljIFJlc2NvcmxhOyBDaHJpc3RpYW4gSHVpdGVtYTsgRm9zc2F0 aSwgVGhvbWFzIChOb2tpYSAtIEdCL0NhbWJyaWRnZSwgVUspOyBNaXJqYSBLw7xobGV3aW5kOyBF Z2dlcnQsIExhcnM7IEphbmEgSXllbmdhcjsgUVVJQyBXRzsgTWFydGluIFRob21zb24NClN1Ympl Y3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KMjAxOC0wMi0wNSA2OjMxIEdNVCsw OTowMCBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+Og0KPiBoaSBKYW5h LA0KPg0KPj4gT24gMyBGZWIgMjAxOCwgYXQgMDM6MzAsIEphbmEgSXllbmdhciA8anJpQGdvb2ds ZS5jb20+IHdyb3RlOg0KPj4NCj4+IEEgZmV3IHBvaW50cyBhcyBJIGNhdGNoIHVwIG9uIHRoaXMg dGhyZWFkLg0KPj4NCj4+IEZpcnN0LCBJJ2xsIHJlbWluZCBmb2xrcyB0aGF0IFFVSUMgaXMgYW4g ZW5jcnlwdGVkIHRyYW5zcG9ydC4gSSBzYXkgdGhpcyBiZWNhdXNlIHRoZSBjb3N0IG9mIHRoaXMg b3BlcmF0aW9uIGlzIHRyaXZpYWwgaW4gdGhlIGNvbnRleHQgb2YgZW5jcnlwdGluZyBldmVyeSBw YWNrZXQuIFRoZSBjb3N0IGlzIGJvcm5lIGF0IHRoZSBzZXJ2ZXJzIGFuZCBub3QgYXQgbWlkZGxl Ym94ZXMsIHNvIHRoZSBhZGRpdGlvbmFsIGNyeXB0byBjb3N0IGlzIGJhc2ljYWxseSB0cml2aWFs Lg0KPg0KPiBBZnRlciBoYXZpbmcgd29ya2VkIG15IHdheSB0aHJvdWdoIHRoZSBQUiBhZ2FpbiAo YW5kIGVzc2VudGlhbGx5IHJld3JpdGluZyBpdCBmcm9tIHRoZSByZWNlaXZlcidzIHBvaW50IG9m IHZpZXcsIHdoaWNoIEkgYmVsaWV2ZSB3b3VsZCBiZSB1c2VmdWwgdGV4dCB0byBoYXZlIGluIHRo ZSBmaW5hbCBkb2N1bWVudCwgc2hvdWxkIHdlIGVuZCB1cCBkb2luZyB0aGlzKSwgSSBidXkgdGhp cy4NCj4NCj4+IFNlY29uZCwgdGhpcyBzaW1wbGlmaWVzIGFuZCBpbmNyZWFzZXMgcm9idXN0bmVz cyBvZiBpbXBsZW1lbnRhdGlvbi4gQXZvaWRpbmcgcmFuZG9tIFBOIGp1bXBzLCBhcyBLYXp1aG8g cG9pbnRzIG91dCwgbWFrZXMgc3BlY2lhbC1jYXNpbmcgb2YgY29kZSB1bm5lY2Vzc2FyeS4gU3Bl Y2lhbCBjb2RlIHRoYXQgaXMgZXhlcmNpc2VkIG9jY2FzaW9uYWxseSBpcyBhIHN0cm9uZyBidWcg YXR0cmFjdG9yLCBhbmQgSSB3b3VsZCBzdHJvbmdseSBhcmd1ZSBmb3IgYXMgZmV3IG9mIHRob3Nl IGFzIHBvc3NpYmxlIGluIGltcGxlbWVudGF0aW9uLg0KPg0KPiBBZ3JlZSBjb21wbGV0ZWx5LiBQ YWNrZXQgbnVtYmVyIGp1bXBzIGFyZSBhIGJhZCBpZGVhLCBhbmQgdGhlcmUgc2VlbXMgdG8gYmUg YSAobm90IGV4cGxpY2l0bHkgZXhhbWluZWQpIGNvbnNlbnN1cyB0aGF0IGF0dGVtcHRpbmcgdG8g bWFrZSBsaW5rYWJpbGl0eSBkaWZmaWN1bHQgaXMgd29ydGggdGhlIGVmZm9ydC4NCj4NCj4+IFRo aXJkLCB5ZXMsIG9zc2lmaWNhdGlvbiBpcyBhIHJlYWwgY29uY2Vybi4gQSBzaW1wbGUgZXhhbXBs ZTogdXNpbmcgaW5jcmVhc2luZyBwYWNrZXQgbnVtYmVycyBhcyBhIHNpZ25hdHVyZSBmb3IgZGV0 ZWN0aW5nIFFVSUMuIEV2ZW4gaWYgeW91IGFyZ3VlIGFnYWluc3QgdGhpcyBleGFtcGxlLCB0aGVy ZSBhcmUgaW5ub3ZhdGl2ZSB3YXlzIGluIHdoaWNoIG9zc2lmaWNhdGlvbiB3aWxsIGhhcHBlbi4g VGhpcyBpcyBiYXNlZCBvbiBhIHRydWUgc3Rvcnk6IFdlIGhhZCBubyBpZGVhIGhvdyBHUVVJQydz IGZsYWdzIGZpZWxkIGNvdWxkIGdldCBvc3NpZmllZCwgdGhlIHZhbHVlIHRoYXQgd2FzIGJlaW5n IHVzZWQgY29tbW9ubHkgYmVjYW1lIHVzZWQgYXMgYSBzaWduYXR1cmUgZm9yIFFVSUMgdHJhZmZp YyAoc2VlIFNlY3Rpb24gNy41IGluIHRoZSBTSUdDT01NIFFVSUMgcGFwZXIpLg0KPg0KPiBUaGVy ZSdzIGFuIG92ZXJnZW5lcmFsaXphdGlvbiBvZiBleHBlcmllbmNlIGZyb20gb3NzaWZpY2F0aW9u IG9mIHNpbmdsZSBzdGF0aWMgZmllbGRzIChhcyBpbiB0aGUgVExTIGdyZWFzaW5nIGFuZCBHVUlD IGZsYWdzIGNhc2VzKSB0byBmdW5jdGlvbnMgb3ZlciB0aGUgdGltZSBzZXJpZXMgb2YgdGhlc2Ug ZmllbGRzIHdoaWNoIGhhcyBub3QgeWV0IGJlZW4gc2hvd24gdG8gYmUgdmFsaWQgSU1PIGluIHRo ZSBjYXNlIG9mIGludGVncml0eS1wcm90ZWN0ZWQgd2lyZSBpbWFnZXMgLS0gd2lsbCBleHBhbmQg b24gdGhpcyBpbiBteSBuZXh0IG1lc3NhZ2UsIHJlcGx5aW5nIHRvIFJvYmVydG8uDQo+DQo+PiBU aGVyZSdzIGEgd2luIGhlcmUgaW4gdGVybXMgb2YgaW1wbGVtZW50YXRpb24gY29tcGxleGl0eSBh bmQgc2V2ZXJhbCBpbXBsZW1lbnRlcnMgaGF2ZSBzYWlkIHNvLg0KPg0KPiBDb21wYXJlZCB0byBw YWNrZXQgbnVtYmVyIGp1bXBzLCBhYnNvbHV0ZWx5LiBDb21wYXJlZCB0byB0aGUgc3RhdGUgdHdv IHJldnMgb2YgdGhlIGRyYWZ0IGFnbywgaXQncyBhICpsaXR0bGUqIG1vcmUgY29tcGxleCBidXQg YXQgbGVhc3QgaXQgZG9lc24ndCBhZGQgY29tcGxldGVseSBuZXcgb3BlcmF0aW9ucyBhdCB0aGUg c2VuZGVyIG9yIHRoZSByZWNlaXZlci4NCj4NCj4+IFRoZXJlJ3MgYSB3aW4gaW4gdGVybXMgb2Yg b3NzaWZpY2F0aW9uIGFuZCBvdXIgZXhwZXJpZW5jZSBzYXlzIHNvLg0KPg0KPiBUaGF0IGV4cGVy aWVuY2UgaXMgSU1PIG92ZXJnZW5lcmFsaXplZC4NCj4NCj4+IFRoZXJlJ3MgYSBwb3RlbnRpYWwg bG9zcyBvZiBtYW5hZ2VhYmlsaXR5LCBpbiBiZWluZyBhYmxlIHRvIGRldGVjdCByZW9yZGVyaW5n Lg0KPg0KPiBXZWxsLCB1cHN0cmVhbSBsb3NzIGFuZCB1cHN0cmVhbSByZW9yZGVyaW5nLg0KPg0K PiBBcyBDaHJpc3RpYW4gc3VnZ2VzdGVkIGF0IHRoZSBzdGFydCBvZiB0aGlzIHRocmVhZCwgaWYg d2Ugc2ltdWx0YW5lb3VzbHkgYWRkIGJhY2sgYSBzaWduYWwgdGhhdCB3b3VsZCBhbGxvdyBvbi1w YXRoIGxvc3MgYW5kIHJlb3JkZXJpbmcgZGV0ZWN0aW9uLCB0aGF0IHdvdWxkIG1ha2UgdGhpcyBh IHVzYWJsZS1pbmZvcm1hdGlvbi1jb250ZW50LW5ldXRyYWwgY2hhbmdlIHRvIHRoZSB3aXJlIGlt YWdlLCBhbmQgZXZlcnlvbmUgY291bGQgbGVhdmUgdGhlIHRhYmxlIGhhcHB5Lg0KDQorMQ0KDQpU aGVyZSBhcmUgdHdvIHBhcnRpZXMgd2l0aCBkaWZmZXJlbnQgaW50ZXJlc3RzLiBFbmRwb2ludCBk ZXZlbG9wZXJzIHdhbnQgc29tZXRoaW5nIG1vcmUgc3RyYWlnaHRmb3J3YXJkIHRvIGltcGxlbWVu dCBhbmQgYWxzbyBpcyBzYWZlIGZyb20gb3NzaWZpY2F0aW9uLiBPcGVyYXRvcnMgd2FudCBhIHRv b2wgZm9yIGRpYWdub3Npcy4NCg0KSW4gVENQLCBib3RoIHBhcnRpZXMgaGF2ZSB1c2VkIHRoZSBz YW1lIHNpZ25hbCBmb3IgdGhlaXIgdGFza3MuDQoNCkluIFFVSUMsIHdlIGNhbiBzcGxpdCB0aGUg c2lnbmFsIGludG8gdHdvLCB3aGljaCBjYW4gYmUgdGFpbG9yZWQgZm9yIGVhY2ggdXNlLWNhc2Uu DQoNClRoZSBzcGxpdCB3b3VsZCBoZWxwIHRoZSBwcm90b2NvbCBldm9sdmUgKGFzIGZpdCBmcm9t IGVuZHBvaW50IGRldmVsb3BlcnMnIHBlcnNwZWN0aXZlKS4gQXQgdGhlIHNhbWUgdGltZSwgaXQg Y291bGQgYWxzbyBoZWxwIG9wZXJhdG9ycywgc2luY2UgdGhlIHNpZ25hbCB0aGV5IHVzZSBjYW4g YmVjb21lIG1vcmUgc3RhYmxlIG9yIGV2b2x2ZSBpbiBhIGRpZmZlcmVudCBwYWNlIChzaW5jZSB0 aGUgY2hhbmdlcyB0byB0aGUgZW5jcnlwdGVkIHBhcnQgb2YgdGhlIHByb3RvY29sIHdpbGwgbm90 IGFmZmVjdCB3aGF0IHRoZSBvcGVyYXRvcnMgd2lsbCBzZWUsIG9yIHZpY2UtdmVyc2EpLg0KDQpO b3RlIGFsc28gdGhhdCBldmVuIGluIHRoZSBjdXJyZW50IHVuZW5jcnlwdGVkIGZvcm0sIHBhY2tl dCBudW1iZXJzIG9mIFFVSUMgaXMgbm90IGFzIGVhc3kgdG8gdXNlIGNvbXBhcmVkIHRvIFRDUCAo ZnJvbSBvcGVyYXRvcnMnIHZpZXdwb2ludCkgc2luY2UgdGhlIG51bWJlcnMgbW9ub3RvbmljYWxs eSBpbmNyZWFzZSBhbmQgc2luY2UgQUNLcyBhcmUgZW5jcnlwdGVkLg0KU28gdGhlcmUncyBhIGNo YW5jZSB0byBtYWtlIHRoZSBzaWduYWwgbW9yZSB1c2VmdWwgYnkgc3BsaXR0aW5nIHRoZSBzaWdu YWxzLiBTcGluIGJpdCBpcyBhIGdvb2QgZXhhbXBsZS4NCg0KPiBUaGUgb25seSBwcm9ibGVtIHdp dGggdGhpcyBpcyB0aGF0IHRoZSBtb3N0IG9idmlvdXMgcGxhY2UgdG8gcHV0IHRoaXMgc2lnbmFs IC0tIHRoZSBmb3VyIGJpdHMgd2UgZ2V0IGJhY2sgZnJvbSB0aGUgc2hvcnQgaGVhZGVyIHR5cGUg ZmllbGQgKGFzc3VtaW5nIHdlIGFkZCB0aGUgc3BpbiBiaXQpIGFyZW4ndCByZWFsbHkgZW5vdWdo IHRvIHRyYWNrIHRoZSBsb3NzIGFuZCByZW9yZGVyaW5nIHBhdHRlcm5zIHdlIGNhcmUgYWJvdXQg d2l0aCBhIG5haXZlIGNvdW50ZXIuDQo+DQo+IFRoZXJlIGFyZSBsb3RzIG9mIG90aGVyIG9wdGlv bnMgaW4gdGhpcyBzcGFjZSAoZS5nLiBkZWNpZGUgd2UgY2FyZSBhYm91dCBsYXRlbmN5IG1vcmUg dGhhbiByZW9yZGVyaW5nLCBhbmQgdGhhdCB3ZSBkb24ndCBjYXJlIGFib3V0IGxvc3MgYXQgYWxs LCBhbmQgdXNlIGEgdHdvLWJpdCBzcGluIHRvIHByb3RlY3QgdGhlIGxhdGVuY3kgc2lnbmFsIGZy b20gcmVvcmRlcmluZywgYW5kIHNvIG9uKSwgYnV0IHRoYXQgc2VlbXMgbGlrZSBhIHRoaXJkIHRo cmVhZCB3ZSBzaG91bGQgc3RhcnQuDQo+DQo+IENoZWVycywNCj4NCj4gQnJpYW4NCj4NCj4+IFRo aXMgaXMgdGhlIHRyYWRlLW9mZiwgYW5kIEkgYW0gc3RpbGwgaW4gZmF2b3Igb2YgZW5jcnlwdGlu ZyBwYWNrZXQgbnVtYmVycy4NCj4+DQo+PiBPbiBGcmksIEZlYiAyLCAyMDE4IGF0IDc6MzIgQU0s IEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSA8dGhvbWFzLmZvc3Nh dGlAbm9raWEuY29tPiB3cm90ZToNCj4+IE9uIDMxLzAxLzIwMTgsIDEwOjA2LCAiUVVJQyBvbiBi ZWhhbGYgb2YgRWdnZXJ0LCBMYXJzIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBsYXJzQG5ldGFwcC5jb20+IHdyb3RlOg0KPj4gPiBPbiAyMDE4LTEtMzEsIGF0IDEwOjUyLCBH b3JyeSBGYWlyaHVyc3QgPGdvcnJ5QGVyZy5hYmRuLmFjLnVrPiB3cm90ZToNCj4+ID4gPiArMSAt IFNpbXBseTogVGhpcyAqaXMqIGNvbXBsaWNhdGVkIGFuZCBzZWVtcyB0byBhZGQgbGl0dGxlLg0K Pj4gPg0KPj4gPiBTbyBhcyBhbiBpbXBsZW1lbnRvciAoY2hhaXIgaGF0IG9mZiksIHRoaXMgYWRk cyB2ZXJ5IGxpdHRsZSB0byB0aGUgDQo+PiA+IG92ZXJhbGwgY29tcGxleGl0eSBvZiB0aGUgcHJv dG9jb2wuDQo+Pg0KPj4gVGhpcyBkb2Vzbid0IHNvdW5kIGdyZWF0LiAgSXQncyBhIGJpdCBsaWtl IHNheWluZyB0aGF0IGFkZGluZyB0aGUgDQo+PiBIaWdncyBtZWNoYW5pc20gdG8gdGhlIHN0YW5k YXJkIG1vZGVsJ3MgbGFncmFuZ2lhbiBkb2Vzbid0IG1ha2UgaXQgDQo+PiBtdWNoIG1vcmUgY29t cGxpY2F0ZSA6LSkgICgqKQ0KPj4NCj4+IE1vcmUgc2VyaW91c2x5IHRob3VnaCwgSSdkIGxpa2Ug dG8gcG9pbnQgb3V0IHRoYXQgaXQgaXMgbm90IGp1c3QgDQo+PiBhYm91dCBpbXBsZW1lbnRhdGlv biBjb21wbGV4aXR5LCBpdCdzIGFsc28gdGhlIGVuZXJneSBjb3N0IHBlciBwYWNrZXQgDQo+PiB0 aGF0IGlzIHF1aXRlIGNydWNpYWwuICBJIGhhdmVuJ3QgZG9uZSB0aGUgbWF0aCBidXQgSVNUTSB0 aGF0IA0KPj4gYnJpbmdpbmcgaW4gYW5vdGhlciBiYXRjaCBvZiBub24tb3B0aW9uYWwgY3J5cHRv IGNvbXB1dGF0aW9uIG9uIGEgcGVyIA0KPj4gcGFja2V0IGJhc2lzIGlzIG5vdCBnb2luZyB0byBt b3ZlIHRoZSBuZWVkbGUgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiANCj4+IGZvciBzdGFja3MgdGhh dCBydW4gb24gbG93IHBvd2VyIChJb1QpLg0KPj4NCj4+IFRoaXMgaXMgbm90IGEgY2F0YXN0cm9w aGUgLSB3ZSBoYXZlIENvQVAgYW5kIGEgKEQpVExTIHByb2ZpbGUgLSBidXQgDQo+PiBuZWl0aGVy IGl0J3MgaWRlYWwsIHNpbmNlIGN1dHRpbmcgb2ZmIHRoZSBzbWFsbCB0aGluZ3MgZnJvbSB0aGUg d2lkZXIgDQo+PiBlY29zeXN0ZW0gY3JlYXRlcyBhbiBhcnRpZmljaWFsIGdhcCB3aGljaCB0aGVu IHdpbGwgbmVlZCBhIG1pZGRsZWJveCANCj4+IHRvIGJyaWRnZS4gIChTdXJlLCB3ZSBoYXZlIHNw ZWNpZmllZCB0aGUgYmVoYXZpb3VyIG9mIGEgc2ltaWxhciBib3ggDQo+PiBhbHJlYWR5LCBidXQg aXQnZCBiZSByZWFsbHkgYmV0dGVyIGlmIHRoZSBleHRyYSB0cmFuc2xhdGlvbiBsb2dpYyANCj4+ IGNvdWxkIGJlIGF2b2lkZWQgaW4gdGhlIGZpcnN0IHBsYWNlLikNCj4+DQo+PiBJIGd1ZXNzIHdo YXQgSSdtIHNheWluZyBpcyB0aGF0IFBOIGVuY3J5cHRpb24gYmVpbmcgYSBjb3JlIG1lY2hhbmlz bSANCj4+IHRoYXQgY2FuJ3QgYmUgbmVnb3RpYXRlZCBhdCBoYW5kc2hha2UgdGltZSByZWR1Y2Vz IG91ciBhYmlsaXR5IHRvIA0KPj4gbGF0ZXIgcHJvZmlsZSBRVUlDIGZvciB0aGUgSW9ULCB3aGlj aCB3b3VsZCBiZSBhIGJpdCB1bmx1Y2t5Lg0KPj4NCj4+IFNvIHRoZSBxdWVzdGlvbiBpczogd291 bGQgaXQgYmUgcG9zc2libGUgdG8gbWFrZSB0aGlzIHByb3BlcnR5IGEgDQo+PiBjb25maWd1cmFi bGUga25vYiBpbnN0ZWFkPw0KPj4NCj4+ICgqKQ0KPj4gaHR0cHM6Ly93d3cuc3ltbWV0cnltYWdh emluZS5vcmcvYXJ0aWNsZS90aGUtZGVjb25zdHJ1Y3RlZC1zdGFuZGFyZC1tDQo+PiBvZGVsLWVx dWF0aW9uDQo+Pg0KPj4NCj4NCg0KDQoNCi0tDQpLYXp1aG8gT2t1DQoNCg== From nobody Mon Feb 5 11:00:59 2018 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 0281E12D945 for ; Mon, 5 Feb 2018 11:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=evequefou.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 Z9Fl1Xkbblbl for ; Mon, 5 Feb 2018 11:00:56 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0126.outbound.protection.outlook.com [104.47.34.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2425F12D944 for ; Mon, 5 Feb 2018 11:00:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UZ0CcwpYYdslt44/qEajzn1AS04BSQ87iDMEFXw2uZ8=; b=KxobcFEhGeia5RHBsw+xSAGSqL7eZTkR861zxeG51yVDdw0nmsgA1w8BYH26Q5L9SafKBOImbgBcMi4XvmXV6m38W0rahG+RIvxKRHZuGL5Lm6TjHI06rw5wAOLIkhRLHBQcfADjpDor4kHEKIV8vK17Os8jKuFjtUdGsNOUVIQ= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2509.namprd08.prod.outlook.com (10.173.230.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 19:00:53 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 19:00:53 +0000 From: Mike Bishop To: "Brian Trammell (IETF)" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: Lars Eggert , Mark Nottingham , QUIC WG Subject: RE: Call for Adoption: Invariants Thread-Topic: Call for Adoption: Invariants Thread-Index: AQHTnkeuZnxZRuZmRE2jEtXr4M5toqOVb7kAgAALu4CAAK8BAA== Date: Mon, 5 Feb 2018 19:00:53 +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: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2509; 7:t/bBDXDoJt27ZmtaP+Q8Xn7GComZtB+/U7KFL2vviPOIjHUuzBwQ4O/YCG/s60fXCc2fCwBiyBUcsFbS9GJygTZlcBTRrxui1frTjb6I0faRU7yjy2b/sBmjvO16k8XWMyh8RvQ6leMcQF8ugtEW3wC+qkUyQwEFkF+Bg50NDNiaV3NTgphywnYnHI2+E6mJHTl9bFjKJNIDLpx2SVsxWyqQLpxEXidPj3WHvBC6mchmOKPKLqgOF9RCqrPdAzH0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bcbcba4b-10cf-4a72-3f9b-08d56ccac7e5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2509; x-ms-traffictypediagnostic: MWHPR08MB2509: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231101)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123560045)(20161123564045)(20161123558120)(2016111802025)(20161123562045)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB2509; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2509; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(39380400002)(396003)(39830400003)(199004)(189003)(13464003)(33656002)(2900100001)(2950100002)(2906002)(81156014)(6506007)(25786009)(8676002)(53546011)(478600001)(229853002)(81166006)(102836004)(8936002)(3846002)(6116002)(5660300001)(76176011)(68736007)(74316002)(74482002)(186003)(7696005)(105586002)(54906003)(305945005)(7736002)(110136005)(77096007)(39060400002)(97736004)(26005)(14454004)(966005)(4326008)(53936002)(86362001)(55016002)(3660700001)(3280700002)(6436002)(9686003)(6306002)(99286004)(66066001)(6246003)(316002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2509; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: y51bKL64iTQgfplAGgx8AsfC6pA+cIpoLgoKBVgZcKMhxPQd5bR2q4LdFBT75I4FIi2l8Smp9lK9ltTtvJOzDw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: bcbcba4b-10cf-4a72-3f9b-08d56ccac7e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 19:00:53.3489 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2509 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, 05 Feb 2018 19:00:58 -0000 SSBzdXBwb3J0IGFkb3B0aW9uLiAgVGhlIHdheSB0byBjaGFuZ2UgdGhlIGludmFyaWFudHMgd2ls bCBiZSB0byBtaW50IGEgbmV3IHByb3RvY29sLCBhbmQgbm90IGNsYWltIHRoYXQgeW91ciBuZXcg cHJvdG9jb2wgaXMgYSB2ZXJzaW9uIG9mIFFVSUMuICBJZiBpdCBoYXBwZW5zIHRvIGJlIHN0YXJ0 bGluZ2x5IHNpbWlsYXIsIGFsbCB3ZWxsIGFuZCBnb29kLg0KDQotLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEJyaWFuIFRyYW1tZWxsIChJRVRGKQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA1LCAy MDE4IDEyOjM0IEFNDQpUbzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21h aWwuY29tPg0KQ2M6IExhcnMgRWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc+OyBNYXJrIE5vdHRpbmdo YW0gPG1ub3RAbW5vdC5uZXQ+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IENhbGwgZm9yIEFkb3B0aW9uOiBJbnZhcmlhbnRzDQoNCkhpLCBhbGwsDQoNCkkgc3VwcG9ydCBh ZG9wdGlvbiBvZiB0aGUgaW52YXJpYW50cyBkcmFmdC4NCg0KPiBPbiA1IEZlYiAyMDE4LCBhdCAw ODo1MSwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPiB3cm90 ZToNCj4gDQo+IE9ubHkgY29uY2VybiBpcyB3aGVuIGl0IHRha2VzIGVmZmVjdCBzaW5jZSBpdCBs aWtlbHkgbmVlZHMgYWRqdXN0bWVudHMuDQoNCkknZCBwcmVzdW1lIHRoYXQgaW52YXJpYW50cyBp cyBwdWJsaXNoZWQgc2ltdWx0YW5lb3VzbHkgd2l0aCB0aGUgdmVyc2lvbiAxIHNwZWMuDQoNCj4g QW5kIHBlcmhhcHMgYSBwcm9jZWR1cmUgdG8gaGFuZGxlIGludmFyaWFudCBjaGFuZ2VzIHNpbmNl IGV2ZXJ5dGhpbmcgY2hhbmdlcy4NCg0KTm90ZWQsIHRob3VnaCB0aGUgcG9pbnQgb2YgZGVjbGFy aW5nIHNvbWV0aGluZyBhbiBpbnZhcmlhbnQgaXMgdG8gc2F5ICJ0aGUgbWVhbmluZyBvZiB0aGlz IHBhcnQgb2YgdGhlIHdpcmUgaW1hZ2UsIGV4cHJlc3NlZCBhcyBhIGJpdCBvZmZzZXQsIHdpbGwg bmV2ZXIgY2hhbmdlIi4gWW91IGNhbiBhZGQgY29uc3RyYWludHMgdG8gdGhlIGludmFyaWFudHMs IGJ1dCBpZiB5b3UgdGhpbmsgeW91IG1pZ2h0IHJlbW92ZSBhIGNvbnN0cmFpbnQsIHRoZW4gaXQn cyBub3QgYW4gaW52YXJpYW50IGJ5IGRlZmluaXRpb24uDQoNCkNoZWVycywNCg0KQnJpYW4NCg0K PiBGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBNYXJrIE5v dHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+DQo+IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgNSwgMjAx OCA3OjA3OjQ1IEFNDQo+IFRvOiBRVUlDIFdHDQo+IENjOiBMYXJzIEVnZ2VydA0KPiBTdWJqZWN0 OiBDYWxsIGZvciBBZG9wdGlvbjogSW52YXJpYW50cw0KPiANCj4gQXQgdGhlIE1lbGJvdXJuZSBt ZWV0aW5nLCB0aGVyZSB3YXMgc3Ryb25nIHN1cHBvcnQgZm9yIGFkb3B0aW5nIE1hcnRpbidzIGlu dmFyaWFudHMgZHJhZnQ6DQo+IA0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dGhvbXNvbi1xdWljLWludmFyaWFudHMtMDANCj4gDQo+IEFueSBvYmplY3Rpb25zIC8gY29uY2Vy bnMgYWJvdXQgZG9pbmcgc28/IFVubGVzcyB3ZSBoZWFyIG90aGVyd2lzZSwgd2UnbGwgYWRvcHQg YXQgdGhlIGVuZCBvZiB0aGUgd2Vlay4NCj4gDQo+IENoZWVycywNCj4gDQo+IC0tDQo+IE1hcmsg Tm90dGluZ2hhbSAgIGh0dHBzOi8vd3d3Lm1ub3QubmV0Lw0KDQo= From nobody Mon Feb 5 11:02:11 2018 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 37D5D12D941 for ; Mon, 5 Feb 2018 11:02:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=evequefou.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 QcONseYoraK2 for ; Mon, 5 Feb 2018 11:02:08 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0127.outbound.protection.outlook.com [104.47.42.127]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDD81275AB for ; Mon, 5 Feb 2018 11:02:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hODz2xcZ6cKbaba3CAD126BEFnd6mEDnyNy2hjjZfog=; b=cTy0MM45tgdvitMwG44zVikef1ao6PtyP7gVV/FuwTSY1M1HiIDsw7SR1Ft7U9OrUXIAHkFfGmczGwVAlpoqRXjAWB03JecMZuqCIE/LDzKNaTFWQ4JsbmEiqwZxq3vo3sLj1bZPEpINBchJUq1bovCIO+Irb4eqnheWwzs/hZg= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2797.namprd08.prod.outlook.com (10.173.239.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 19:02:06 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 19:02:06 +0000 From: Mike Bishop To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , "Salz, Rich" CC: QUIC WG Subject: RE: Reducing ossification through protocol design (was Re: Packet number encryption) Thread-Topic: Reducing ossification through protocol design (was Re: Packet number encryption) Thread-Index: AQHTnf+NlUqsX1h6U0uiVsf3NVQgAaOVfOMAgABtuACAABkzgIAAAO0AgAAm2fA= Date: Mon, 5 Feb 2018 19:02:06 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <5A781798.6010101@erg.abdn.ac.uk> <6D4A2F58-F13A-46AB-80A3-E356DDE15A0F@akamai.com> <5FBE1ABB-C8CD-47BF-BEB7-792864A4BEE4@tik.ee.ethz.ch> In-Reply-To: <5FBE1ABB-C8CD-47BF-BEB7-792864A4BEE4@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2797; 7:ZyiLbhIoVqh7zgVMwFEuiE5cpw+lV0Za8oN1AU9I3RosXsV/Mvk6j//mxHvgkRt9z7aUPe6Y15AUijRPkCQSC5n4YrJjeyhrhcjjv9QvlNSNog/39tPOp3n7WJGSAbaAoa9H8R0tIoQe/VpdauCzjx85jUsUlQZKi772gx3m9XUGYYbo4EPH9scjTji/s0LekoIPoFQalmPVcc2IHuo8UQupVrdMQdeP3siIMYEtYkFdx6mHWMUpdPFMAKEpLYil x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 0d45d176-8c25-4996-986c-08d56ccaf33a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2797; x-ms-traffictypediagnostic: MWHPR08MB2797: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(10201501046)(3002001)(93006095)(93001095)(6041288)(20161123560045)(20161123564045)(20161123562045)(2016111802025)(20161123558120)(6043046)(6072148)(201708071742011); SRVR:MWHPR08MB2797; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2797; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39830400003)(39380400002)(346002)(396003)(13464003)(189003)(199004)(186003)(106356001)(3660700001)(81166006)(81156014)(2950100002)(4326008)(14454004)(26005)(6436002)(6116002)(3846002)(229853002)(3280700002)(25786009)(8936002)(86362001)(8676002)(99286004)(2900100001)(110136005)(77096007)(316002)(68736007)(5660300001)(6506007)(6246003)(478600001)(2906002)(53546011)(9686003)(74482002)(105586002)(33656002)(55016002)(93886005)(53936002)(102836004)(305945005)(76176011)(97736004)(7736002)(66066001)(74316002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2797; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: 6+5NLNNRUfK20ZkYcDs8bO8hLojCY3afGlopPlRvtpEOocit+6VNDO64LOeCaBY7ehlqA2Ks/8jLrupjlAxNhw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 0d45d176-8c25-4996-986c-08d56ccaf33a X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 19:02:06.0659 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2797 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, 05 Feb 2018 19:02:10 -0000 SG93IGFib3V0ICJpbnZhcmlhbnQiPyAg8J+Yig0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IE1pcmphIEvDvGhsZXdpbmQNClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgNSwgMjAxOCA4OjQzIEFN DQpUbzogU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT4NCkNjOiBRVUlDIFdHIDxxdWljQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFJlZHVjaW5nIG9zc2lmaWNhdGlvbiB0aHJvdWdoIHByb3Rv Y29sIGRlc2lnbiAod2FzIFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24pDQoNCklmIHRoYXQg aGVscHMgSeKAmW0gYWxsIGluIGZvciB0aGF0IQ0KDQo+IEFtIDA1LjAyLjIwMTggdW0gMTc6Mzkg c2NocmllYiBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPjoNCj4gDQo+PiBJIHRoaW5rIGl0 IGlzIGVudGlyZWx5IHBvc3NpYmxlIHRoYXQgYSBzbWFsbCBzZXQgb2YgZmllbGRzIGluIHRoZSB0 cmFuc3BvcnQgaGVhZGVyIG1heSBiZSB1c2VmdWxseSBvc3NpZmllZCB0byBpbmNyZWFzZSB0aGUg ZGVwbG95YWJpbGl0eSwgbWFuYWdlYWJpbGl0eSBhbmQgZmxleGliaWxpdHkgYWNyb3NzIGEgcmFu Z2Ugb2YgdXNlIGNhc2VzLg0KPiANCj4gVGhlbiB3ZSBzaG91bGQgdXNlIGEgd29yZCBiZXNpZGVz IG9zc2lmaWVkLCB3aGljaCBhdCB0aGlzIHBvaW50IGhhcyBlbnRpcmVseSBuZWdhdGl2ZSBjb25u b3RhdGlvbnMuICBQZXJoYXBzIOKAnGZyb3plbuKAnT8NCj4gDQoNCg== From nobody Mon Feb 5 11:03:27 2018 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 DC62F12D942 for ; Mon, 5 Feb 2018 11:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=evequefou.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 YOG1gD_uaeMO for ; Mon, 5 Feb 2018 11:03:24 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0128.outbound.protection.outlook.com [104.47.42.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13C7B1275AB for ; Mon, 5 Feb 2018 11:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SwkgPiurZ+chyEM9uqpViVNvGGSG/3moKpFeSk0RHKE=; b=H9g5hrwoMDe7TbAmfomXwv2Zt8GJabR7zBhBeiXnFs/lEV2ZEnJOi81Ue/plDTK7bBq9EyspNkAWA9OwZMdWkERLP4xBJMwgneiNUzDhP8n6nmHwNhN6UPSUi1iXCDiBigLbSzFNHREfVzUgsilzwIg7dEx+kE/NedhOsqm9UrQ= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2797.namprd08.prod.outlook.com (10.173.239.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 19:03:22 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 19:03:22 +0000 From: Mike Bishop To: Mark Nottingham , QUIC WG CC: Lars Eggert Subject: RE: Call for Adoption: QCRAM Thread-Topic: Call for Adoption: QCRAM Thread-Index: AQHTnkexXbjyOz6HJUu/FnyihGnxYKOWKyOw Date: Mon, 5 Feb 2018 19:03:22 +0000 Message-ID: References: <6A834DB6-F2A5-4973-83CD-8AAA82945372@mnot.net> In-Reply-To: <6A834DB6-F2A5-4973-83CD-8AAA82945372@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2797; 7:koEIqihxS5v6JrLk3sV489krU1oNdtGd+QnYoeVaqMi5O4ljabKcUgeDothKRHBtx43q/codbacWUkqV0BqocY45L9HDwSELaLSHKsuOhgSUU+PCa0MR0dSyIZzLNns3J1eHs9JYtdtqLPGfjfd0hhjyxVR+t8GmarxyYkApVLvoo8qDo+Op/zuSRnn++Z68iVK5gl/xnPCEz802QruK8pz/Xi50P09ZUHT+y7SPsWIWNqR8iEhR+qHtWSUdhALP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 315c33ee-e30e-4585-1a00-08d56ccb20e9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2797; x-ms-traffictypediagnostic: MWHPR08MB2797: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(10201501046)(3002001)(93006095)(93001095)(6041288)(20161123560045)(20161123564045)(20161123562045)(2016111802025)(20161123558120)(6043046)(6072148)(201708071742011); SRVR:MWHPR08MB2797; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2797; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39830400003)(39380400002)(346002)(396003)(13464003)(189003)(199004)(186003)(106356001)(3660700001)(81166006)(81156014)(2950100002)(4326008)(14454004)(26005)(6436002)(6116002)(3846002)(229853002)(3280700002)(25786009)(8936002)(86362001)(8676002)(99286004)(2900100001)(110136005)(77096007)(316002)(68736007)(5660300001)(6506007)(966005)(6246003)(478600001)(6306002)(2906002)(53546011)(9686003)(74482002)(105586002)(33656002)(55016002)(53936002)(102836004)(305945005)(76176011)(97736004)(7736002)(66066001)(74316002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2797; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: 7DC/rwlQWz642cS7jDbSKjx9AZhI6mrT03umjKiezkjHJHRux7Hvt/vexaGqutE2kCWXmKko8vtDEEit6M9PTA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 315c33ee-e30e-4585-1a00-08d56ccb20e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 19:03:22.7070 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2797 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, 05 Feb 2018 19:03:26 -0000 I support adoption -- it's a useful starting point from which we can discus= s what elements of other proposals are worth lifting into this model. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham Sent: Sunday, February 4, 2018 10:08 PM To: QUIC WG Cc: Lars Eggert Subject: Call for Adoption: QCRAM In Melbourne, there was strong support (with a small amount of pushback whi= ch was discussed) for adopting QCRAM: https://tools.ietf.org/html/draft-krasic-quic-qcram-04 Any objections / concerns about doing so? Unless we hear otherwise, we'll a= dopt at the end of the week. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Feb 5 11:05:26 2018 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 27E2912778E for ; Mon, 5 Feb 2018 11:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, 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 (1024-bit key) header.d=fb.com header.b=UkPMEjgy; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=fXvPAIMZ 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 fY3YCGu3bxrf for ; Mon, 5 Feb 2018 11:05:24 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 0CA1C1275AB for ; Mon, 5 Feb 2018 11:05:23 -0800 (PST) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.16.0.22/8.16.0.22) with SMTP id w15IqIm5019669; Mon, 5 Feb 2018 11:05:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=bYoEGG/+voOgSPaHwjNYJB9PKC7iGByY0yBM5duCPP8=; b=UkPMEjgylO4SVXU+2CuBFyDEyjnRN5lL8f6/55Y2zt95YjH4C/pUL6C/ntndD9bfw7GT 9Zorwi6JiF9tpBtuqU9TmMqgdg0xEGS/p6G/keZ0Th8rteVeCPzpduD06dj+SgapgHXw J4jsQdJYH4flrfQuiOYYJYYjS9B8QpA/6EU= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 2fxuwcrawe-3 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 05 Feb 2018 11:05:18 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.14) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 5 Feb 2018 11:05:17 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bYoEGG/+voOgSPaHwjNYJB9PKC7iGByY0yBM5duCPP8=; b=fXvPAIMZ3SqdREZhEKnk4fl2SxmJORwp8mBA4+kWMv2HDfL+V49LaM0UJC3UbIxZHjTMycaQaLBth4Wjyghhewhp+3K1qw2UiuOsZ8g2J0F9G/1fuxnSYX7YpgOkWd4FjAQJEcRXyqwaN/WcilkvIB8fr/AsNpp5v/osUSlkC/4= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0485.namprd15.prod.outlook.com (10.163.110.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 19:05:15 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 19:05:15 +0000 From: Roberto Peon To: Mike Bishop , "Brian Trammell (IETF)" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: Lars Eggert , Mark Nottingham , QUIC WG Subject: Re: Call for Adoption: Invariants Thread-Topic: Call for Adoption: Invariants Thread-Index: AQHTnke71VfTOLESs0C03kkd0o9QVKOVb7kAgAALu4CAAK9GgP//exsA Date: Mon, 5 Feb 2018 19:05:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::6:a15b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0485; 7:EeusO+5G3Dk4F/IpmUhjqJ69vvnR2CHbwsuEpUZWRLbhkoy4NaZwcj4N2N7J5OrBwMlurjsKMIfgubk7GZigBO3iZMlhr/MujUHorgLEjiGA04bhCDMczLMkFGnJthr6mBPaal49DgkrbT3mVWgkkcN4buAwzoODrMArOVtPAxzSktsC2raVeVRMGCiiFSvABy7KBfxWYe44wZeOB4w/o2ouE1NbOFdMKb49W/HK7sYsfs74u10Wb7Z7SO8Pq19H; 20:TLmiIYh1UJIUBUAvLO8H+IYQWZFIW1D3DroktZhhxeuOQf6zG/WEqcS1VRaRl8lbA+gRzrpCObqJzoYP2x9kgv7bRfaZ+GMQdaDIR8Ij1/JnAw6CwdlSa33TIYSMoKNtqCEWT57XsWGmcfU9tVICJgp4unXQXBXOzwOEDH/IyOI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f3f1464a-3252-4d23-daf5-08d56ccb63cc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0485; x-ms-traffictypediagnostic: BY2PR15MB0485: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231101)(11241501184)(2400082)(944501161)(6041288)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BY2PR15MB0485; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0485; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(396003)(346002)(376002)(366004)(13464003)(199004)(189003)(8676002)(7736002)(36756003)(76176011)(2950100002)(305945005)(4326008)(6436002)(83716003)(105586002)(6306002)(6116002)(97736004)(77096007)(3280700002)(102836004)(33656002)(2906002)(3660700001)(6512007)(82746002)(25786009)(99286004)(2900100001)(86362001)(966005)(575784001)(478600001)(6486002)(14454004)(53936002)(106356001)(186003)(53546011)(8936002)(110136005)(6506007)(5660300001)(39060400002)(316002)(68736007)(81166006)(81156014)(229853002)(93886005)(54906003)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0485; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZTttiGvH34z9M5oUWbSrYbpkld66S+xCKI+wcjoY0A5h+MVn5727u+q1FSMFxeNB8h1Dg++9L7zzxpgRtNRx6Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f3f1464a-3252-4d23-daf5-08d56ccb63cc X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 19:05:14.9136 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0485 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_04:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 05 Feb 2018 19:05:26 -0000 U3VwcG9ydGVkLg0KLT1SDQoNCk9uIDIvNS8xOCwgMTE6MDEgQU0sICJRVUlDIG9uIGJlaGFsZiBv ZiBNaWtlIEJpc2hvcCIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbWJpc2hv cEBldmVxdWVmb3UuYmU+IHdyb3RlOg0KDQogICAgSSBzdXBwb3J0IGFkb3B0aW9uLiAgVGhlIHdh eSB0byBjaGFuZ2UgdGhlIGludmFyaWFudHMgd2lsbCBiZSB0byBtaW50IGEgbmV3IHByb3RvY29s LCBhbmQgbm90IGNsYWltIHRoYXQgeW91ciBuZXcgcHJvdG9jb2wgaXMgYSB2ZXJzaW9uIG9mIFFV SUMuICBJZiBpdCBoYXBwZW5zIHRvIGJlIHN0YXJ0bGluZ2x5IHNpbWlsYXIsIGFsbCB3ZWxsIGFu ZCBnb29kLg0KICAgIA0KICAgIA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQogICAgDQogICAgRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEJyaWFuIFRyYW1tZWxsIChJRVRGKQ0KICAgIA0KICAgIFNlbnQ6IE1vbmRheSwg RmVicnVhcnkgNSwgMjAxOCAxMjozNCBBTQ0KICAgIA0KICAgIFRvOiBNaWtrZWwgRmFobsO4ZSBK w7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+DQogICAgDQogICAgQ2M6IExhcnMgRWdnZXJ0 IDxsYXJzQGVnZ2VydC5vcmc+OyBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+OyBRVUlD IFdHIDxxdWljQGlldGYub3JnPg0KICAgIA0KICAgIFN1YmplY3Q6IFJlOiBDYWxsIGZvciBBZG9w dGlvbjogSW52YXJpYW50cw0KICAgIA0KICAgIA0KICAgIA0KICAgIEhpLCBhbGwsDQogICAgDQog ICAgDQogICAgDQogICAgSSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoZSBpbnZhcmlhbnRzIGRyYWZ0 Lg0KICAgIA0KICAgIA0KICAgIA0KICAgID4gT24gNSBGZWIgMjAxOCwgYXQgMDg6NTEsIE1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgDQog ICAgPiANCiAgICANCiAgICA+IE9ubHkgY29uY2VybiBpcyB3aGVuIGl0IHRha2VzIGVmZmVjdCBz aW5jZSBpdCBsaWtlbHkgbmVlZHMgYWRqdXN0bWVudHMuDQogICAgDQogICAgDQogICAgDQogICAg SSdkIHByZXN1bWUgdGhhdCBpbnZhcmlhbnRzIGlzIHB1Ymxpc2hlZCBzaW11bHRhbmVvdXNseSB3 aXRoIHRoZSB2ZXJzaW9uIDEgc3BlYy4NCiAgICANCiAgICANCiAgICANCiAgICA+IEFuZCBwZXJo YXBzIGEgcHJvY2VkdXJlIHRvIGhhbmRsZSBpbnZhcmlhbnQgY2hhbmdlcyBzaW5jZSBldmVyeXRo aW5nIGNoYW5nZXMuDQogICAgDQogICAgDQogICAgDQogICAgTm90ZWQsIHRob3VnaCB0aGUgcG9p bnQgb2YgZGVjbGFyaW5nIHNvbWV0aGluZyBhbiBpbnZhcmlhbnQgaXMgdG8gc2F5ICJ0aGUgbWVh bmluZyBvZiB0aGlzIHBhcnQgb2YgdGhlIHdpcmUgaW1hZ2UsIGV4cHJlc3NlZCBhcyBhIGJpdCBv ZmZzZXQsIHdpbGwgbmV2ZXIgY2hhbmdlIi4gWW91IGNhbiBhZGQgY29uc3RyYWludHMgdG8gdGhl IGludmFyaWFudHMsIGJ1dCBpZiB5b3UgdGhpbmsgeW91IG1pZ2h0IHJlbW92ZSBhIGNvbnN0cmFp bnQsIHRoZW4gaXQncyBub3QgYW4gaW52YXJpYW50IGJ5IGRlZmluaXRpb24uDQogICAgDQogICAg DQogICAgDQogICAgQ2hlZXJzLA0KICAgIA0KICAgIA0KICAgIA0KICAgIEJyaWFuDQogICAgDQog ICAgDQogICAgDQogICAgPiBGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl aGFsZiBvZiBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+DQogICAgDQogICAgPiBTZW50 OiBNb25kYXksIEZlYnJ1YXJ5IDUsIDIwMTggNzowNzo0NSBBTQ0KICAgIA0KICAgID4gVG86IFFV SUMgV0cNCiAgICANCiAgICA+IENjOiBMYXJzIEVnZ2VydA0KICAgIA0KICAgID4gU3ViamVjdDog Q2FsbCBmb3IgQWRvcHRpb246IEludmFyaWFudHMNCiAgICANCiAgICA+IA0KICAgIA0KICAgID4g QXQgdGhlIE1lbGJvdXJuZSBtZWV0aW5nLCB0aGVyZSB3YXMgc3Ryb25nIHN1cHBvcnQgZm9yIGFk b3B0aW5nIE1hcnRpbidzIGludmFyaWFudHMgZHJhZnQ6DQogICAgDQogICAgPiANCiAgICANCiAg ICA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f dG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRHRob21zb24tMkRxdWljLTJEaW52YXJpYW50cy0y RDAwJmQ9RHdJR2FRJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPUMwc1VvLUxGTkJhWWZ5b2FD c2Y2VEEmbT1uMmxJSDd6UHd1MWZxcEJVRGNXVWpWUDk1SEFiYVk3QzA5RTBHa2RleUN3JnM9YzNH NG9icmp4cFhJb2tzUzFjSWwybGltR2JoQkhYRGt2dnYzem5GbHBIOCZlPQ0KICAgIA0KICAgID4g DQogICAgDQogICAgPiBBbnkgb2JqZWN0aW9ucyAvIGNvbmNlcm5zIGFib3V0IGRvaW5nIHNvPyBV bmxlc3Mgd2UgaGVhciBvdGhlcndpc2UsIHdlJ2xsIGFkb3B0IGF0IHRoZSBlbmQgb2YgdGhlIHdl ZWsuDQogICAgDQogICAgPiANCiAgICANCiAgICA+IENoZWVycywNCiAgICANCiAgICA+IA0KICAg IA0KICAgID4gLS0NCiAgICANCiAgICA+IE1hcmsgTm90dGluZ2hhbSAgIGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lm1ub3QubmV0XyZkPUR3 SUdhUSZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJm09 bjJsSUg3elB3dTFmcXBCVURjV1VqVlA5NUhBYmFZN0MwOUUwR2tkZXlDdyZzPWdZeE5DV1lwVnpX ZzJBNGJiOER6cTlyNE03RXRVUHBjOFFjVXBNbll5cUkmZT0NCiAgICANCiAgICANCiAgICANCiAg ICANCg0K From nobody Mon Feb 5 11:05:39 2018 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 A6D6E12D942 for ; Mon, 5 Feb 2018 11:05:30 -0800 (PST) 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, 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=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 YBibqIEF05FC for ; Mon, 5 Feb 2018 11:05:28 -0800 (PST) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::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 15A2812D946 for ; Mon, 5 Feb 2018 11:05:28 -0800 (PST) Received: by mail-pl0-x235.google.com with SMTP id f8so12395812plk.11 for ; Mon, 05 Feb 2018 11:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=MlEFBr6VwSQtYh9HFUjBRUDwsLp3FRQj7CZex5Pk9cE=; b=slTrV0+QFlIt2KSv1ZYOpHccv2knWo+QQQgTPix/Ebpegi7mb5FwyFRsAO9yO6QJKt M91XEZfRk110VUV6kdjlc4X3SpHzzEnO+ixvlJXECcPZVwyKg8st0c7xLhOK5xFerzS6 pAdQT0ONrzLcUzSueWJ8mfpbs3ovGVwK8GLyBgdykPTfmvXypWWcFYd/qX/nrYJvc+B4 tSe5M/WXi37ABiBbZttdxS1PjP5lyY/VOfuJdAkxULPcw0QeFM8B6uaCcIF7bcZ4wxVg 8ftPTl4kCR3dq42KFfC9ZkYlC3bviVVpq+m6PQEL5FGsowSU7SzlpM0fKoW0HFWw70Y0 G/mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=MlEFBr6VwSQtYh9HFUjBRUDwsLp3FRQj7CZex5Pk9cE=; b=iaKecZKusW+jRF2bQJJQkFZd7ohJW5tyeeUsY+mgwslohyCRGFuFdHmh3GLoKzm++R pW++lNRFBootrLAA1CsM3h/ccpLRsZLYszuHnlL1i7GyynPjwPyiLGxij6IOqsJOy8p9 MqQQ8+1Kcbuztd377yd/DjdNGH5rtxiewjgCbF1bH8mEnlfHAJ54vBOuqV/8XGXmn7lh PUNPpgSfCf4W2rHk6o0JQfOGvt0rNj7JgumRjZGMFR92EeIfCErVuzztSPmuIScS7/Pf PXG3aq8sDa8ByuUgEn+b47cXYtpIbzOMtnbPAXEaWzMQXX5PPlmeT/wEHSF9FaA36cCB PpPA== X-Gm-Message-State: AKwxyteBES0uSjgzWVu5dabh2OC5Y6gh99oZG2WkL6sRQQ+eQ9n22fOD GWDupD1k3NZV41XGnLo6D2728r2E91I= X-Google-Smtp-Source: AH8x2240kUf8I2HOPVQ+PeYkuof3ZduftKSDtH+5eVbCx1+LZK24D/wRtoU6IZ+koD0R+eXs7W/M7Q== X-Received: by 2002:a17:902:595d:: with SMTP id e29-v6mr45487992plj.436.1517857527659; Mon, 05 Feb 2018 11:05:27 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id y13sm23193138pfj.96.2018.02.05.11.05.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 05 Feb 2018 11:05:27 -0800 (PST) From: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Mike Bishop , "Brian Trammell (IETF)" CC: Lars Eggert , Mark Nottingham , QUIC WG Subject: Re: Call for Adoption: Invariants Thread-Topic: Call for Adoption: Invariants Thread-Index: AUY2OTQ2mv+s5soMjSZWGIW+IBxM+DBBMkIxNTE1NDgwOUNCMpYjmM27 X-MS-Exchange-MessageSentRepresentingType: 2 Date: Mon, 5 Feb 2018 19:05:22 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB176682C4EC84D225E08C5A6BACFE0DB6PR10MB1766EURP_" 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: Mon, 05 Feb 2018 19:05:31 -0000 --_000_DB6PR10MB176682C4EC84D225E08C5A6BACFE0DB6PR10MB1766EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It could be called QUID ... ________________________________ From: Mike Bishop Sent: Monday, February 5, 2018 8:00:53 PM To: Brian Trammell (IETF); Mikkel Fahn=F8e J=F8rgensen Cc: Lars Eggert; Mark Nottingham; QUIC WG Subject: RE: Call for Adoption: Invariants I support adoption. The way to change the invariants will be to mint a new= protocol, and not claim that your new protocol is a version of QUIC. If i= t happens to be startlingly similar, all well and good. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell (IETF= ) Sent: Monday, February 5, 2018 12:34 AM To: Mikkel Fahn=F8e J=F8rgensen Cc: Lars Eggert ; Mark Nottingham ; QUIC WG= Subject: Re: Call for Adoption: Invariants Hi, all, I support adoption of the invariants draft. > On 5 Feb 2018, at 08:51, Mikkel Fahn=F8e J=F8rgensen = wrote: > > Only concern is when it takes effect since it likely needs adjustments. I'd presume that invariants is published simultaneously with the version 1 = spec. > And perhaps a procedure to handle invariant changes since everything chan= ges. Noted, though the point of declaring something an invariant is to say "the = meaning of this part of the wire image, expressed as a bit offset, will nev= er change". You can add constraints to the invariants, but if you think you= might remove a constraint, then it's not an invariant by definition. Cheers, Brian > From: QUIC on behalf of Mark Nottingham > Sent: Monday, February 5, 2018 7:07:45 AM > To: QUIC WG > Cc: Lars Eggert > Subject: Call for Adoption: Invariants > > At the Melbourne meeting, there was strong support for adopting Martin's = invariants draft: > > https://tools.ietf.org/html/draft-thomson-quic-invariants-00 > > Any objections / concerns about doing so? Unless we hear otherwise, we'll= adopt at the end of the week. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ --_000_DB6PR10MB176682C4EC84D225E08C5A6BACFE0DB6PR10MB1766EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
It could be called QUID ...

From: Mike Bishop <mbi= shop@evequefou.be>
Sent: Monday, February 5, 2018 8:00:53 PM
To: Brian Trammell (IETF); Mikkel Fahn=F8e J=F8rgensen
Cc: Lars Eggert; Mark Nottingham; QUIC WG
Subject: RE: Call for Adoption: Invariants
 
I support adoption.  The way to change the in= variants will be to mint a new protocol, and not claim that your new protoc= ol is a version of QUIC.  If it happens to be startlingly similar, all= well and good.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Brian Trammell (IETF)
Sent: Monday, February 5, 2018 12:34 AM
To: Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.com>
Cc: Lars Eggert <lars@eggert.org>; Mark Nottingham <mnot@mnot.net&= gt;; QUIC WG <quic@ietf.org>
Subject: Re: Call for Adoption: Invariants

Hi, all,

I support adoption of the invariants draft.

> On 5 Feb 2018, at 08:51, Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmai= l.com> wrote:
>
> Only concern is when it takes effect since it likely needs adjustments= .

I'd presume that invariants is published simultaneously with the version 1 = spec.

> And perhaps a procedure to handle invariant changes since everything c= hanges.

Noted, though the point of declaring something an invariant is to say "= ;the meaning of this part of the wire image, expressed as a bit offset, wil= l never change". You can add constraints to the invariants, but if you= think you might remove a constraint, then it's not an invariant by definition.

Cheers,

Brian

> From: QUIC <quic-bounces@ietf.org> on behalf of Mark Nottingham = <mnot@mnot.net>
> Sent: Monday, February 5, 2018 7:07:45 AM
> To: QUIC WG
> Cc: Lars Eggert
> Subject: Call for Adoption: Invariants
>
> At the Melbourne meeting, there was strong support for adopting Martin= 's invariants draft:
>
> https://tools.ietf.org/html/draft-thomson-quic-invariants-00
>
> Any objections / concerns about doing so? Unless we hear otherwise, we= 'll adopt at the end of the week.
>
> Cheers,
>
> --
> Mark Nottingham   https://= www.mnot.net/

 --_000_DB6PR10MB176682C4EC84D225E08C5A6BACFE0DB6PR10MB1766EURP_-- From nobody Mon Feb 5 11:44:08 2018 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 09BC0128954 for ; Mon, 5 Feb 2018 11:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, 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 (1024-bit key) header.d=fb.com header.b=m7BCMJP6; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=B7o0wBWu 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 0tp_LesPV5cu for ; Mon, 5 Feb 2018 11:44:05 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 25F74127735 for ; Mon, 5 Feb 2018 11:44:05 -0800 (PST) Received: from pps.filterd (m0109333.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w15Iuush022113; Mon, 5 Feb 2018 11:05:43 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=facebook; bh=2wl/O0fQ8eQ66cykcG0y4N40XHCiNeyfoLPMdOt4fHw=; b=m7BCMJP6amr+J8+N/uxEiv0uFo8rK7lTVXWpXyDlXpl5MtDP8T41LWDz7mir7BdTu5tu VA0dzI2pAP9aTS75XiRnJNsz9oZYPtGKYtGNjHnyJIY+Fuadm62BvNGuCqoRJqW6U6sY hL7B1hVDsJTltYR6+kBhsuC5+TsfENgUOwQ= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fxu8qrm52-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 05 Feb 2018 11:05:43 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 5 Feb 2018 14:05:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2wl/O0fQ8eQ66cykcG0y4N40XHCiNeyfoLPMdOt4fHw=; b=B7o0wBWuQJ7MWPFJ7O3xLxb4LPiBbqQ/z7uS5xNnuG53k79Ah+bkxsALTZrx1jazfhVuV6pAUfX9hCs1C4/Ln42A+DUz1UvLMb2o7m70ESH3adRLJDZ4aumRgrGG0Z/8blniI5GaQ3Wuvbqg5bPAATIfW715kaqasM88HvM5HOY= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0485.namprd15.prod.outlook.com (10.163.110.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Mon, 5 Feb 2018 19:05:40 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0464.015; Mon, 5 Feb 2018 19:05:40 +0000 From: Roberto Peon To: Mike Bishop , Mark Nottingham , "QUIC WG" CC: Lars Eggert Subject: Re: Call for Adoption: QCRAM Thread-Topic: Call for Adoption: QCRAM Thread-Index: AQHTnke/h6X3M/Kn+U2HNfRw6Mm9PaOWK2wA//96h4A= Date: Mon, 5 Feb 2018 19:05:39 +0000 Message-ID: References: <6A834DB6-F2A5-4973-83CD-8AAA82945372@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::6:a15b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0485; 7:CSglVbetspzURWqDd28+LgHRGHEqXKGvkO/+cbEcDpoHxYHIwjo7Y/toerFroAG2+z1CHSHw2DHD+A46sNaRolL8x7zcN5Yb9cbXtjSWfU2AiDt9m9+3MCX0gNVMGNdsgSbAL1y6iiRxXCJRgax31PvzHPk9VYtMNdTc5nMicd1heDC8xUqhHBXiiAzximlNgbuWZ+9pyml6n4AIqtLFY0p/c73fKSN78Eponmc/Z22SsHyL5EK5TZVcWLQjaT4I; 20:SF3v63l2qbkIgutD+mvd/f3ujszjF1zXNT/p7bNFBidSgc0WPj1FpEgNSMVldKQFES50RgVBNQWMbHj65Q1C0fxKwYMQSfQ9XhOy19YLxG/WGERyzhQ60ciuH0ymEuZskSz3dn42DCAkR71asnzNeCJgrt5dhojL/dJXOP9Ptk4= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 805c72ae-aa3d-4c7d-2273-08d56ccb72aa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0485; x-ms-traffictypediagnostic: BY2PR15MB0485: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(131327999870524); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231101)(11241501184)(2400082)(944501161)(6041288)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BY2PR15MB0485; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0485; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(396003)(346002)(376002)(366004)(13464003)(199004)(189003)(8676002)(7736002)(36756003)(76176011)(2950100002)(305945005)(4326008)(6436002)(83716003)(105586002)(6306002)(6116002)(97736004)(77096007)(3280700002)(102836004)(33656002)(2906002)(3660700001)(6512007)(82746002)(25786009)(99286004)(2900100001)(86362001)(966005)(575784001)(478600001)(6486002)(14454004)(53936002)(106356001)(186003)(53546011)(8936002)(110136005)(6506007)(5660300001)(316002)(68736007)(81166006)(81156014)(229853002)(6246003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0485; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: GECNBr/aHrKRMcBVJfOzh2oKI+6IDhZNdbJd7N1DGdqBDklMawULlGTDibrx5wFh7B8jMj4BnKBdI1D5GEAFiQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <44410F14D3997840BEDEB9D84284ADB6@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 805c72ae-aa3d-4c7d-2273-08d56ccb72aa X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 19:05:39.8987 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0485 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_04:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 05 Feb 2018 19:44:07 -0000 QWdyZWVkLg0KU3VwcG9ydGVkLg0KLT1SDQoNCk9uIDIvNS8xOCwgMTE6MDQgQU0sICJRVUlDIG9u IGJlaGFsZiBvZiBNaWtlIEJpc2hvcCIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgbWJpc2hvcEBldmVxdWVmb3UuYmU+IHdyb3RlOg0KDQogICAgSSBzdXBwb3J0IGFkb3B0aW9u IC0tIGl0J3MgYSB1c2VmdWwgc3RhcnRpbmcgcG9pbnQgZnJvbSB3aGljaCB3ZSBjYW4gZGlzY3Vz cyB3aGF0IGVsZW1lbnRzIG9mIG90aGVyIHByb3Bvc2FscyBhcmUgd29ydGggbGlmdGluZyBpbnRv IHRoaXMgbW9kZWwuDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICBG cm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFy ayBOb3R0aW5naGFtDQogICAgU2VudDogU3VuZGF5LCBGZWJydWFyeSA0LCAyMDE4IDEwOjA4IFBN DQogICAgVG86IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQogICAgQ2M6IExhcnMgRWdnZXJ0IDxs YXJzQGVnZ2VydC5vcmc+DQogICAgU3ViamVjdDogQ2FsbCBmb3IgQWRvcHRpb246IFFDUkFNDQog ICAgDQogICAgSW4gTWVsYm91cm5lLCB0aGVyZSB3YXMgc3Ryb25nIHN1cHBvcnQgKHdpdGggYSBz bWFsbCBhbW91bnQgb2YgcHVzaGJhY2sgd2hpY2ggd2FzIGRpc2N1c3NlZCkgZm9yIGFkb3B0aW5n IFFDUkFNOg0KICAgIA0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGtyYXNpYy0yRHF1aWMt MkRxY3JhbS0yRDA0JmQ9RHdJRkFnJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZyPUMwc1VvLUxG TkJhWWZ5b2FDc2Y2VEEmbT05Q0wyRHpSQ3J2cFdSRVNlcVF6ZUJKV21BNUNzZ2p1X3RfbUFNOVRr cnY4JnM9WVV0LWV0ZlJVUnpKQVUzS2szTWgtNjNYc2s2RXF0Nmp0M19ObXNoTnJvMCZlPQ0KICAg IA0KICAgIEFueSBvYmplY3Rpb25zIC8gY29uY2VybnMgYWJvdXQgZG9pbmcgc28/IFVubGVzcyB3 ZSBoZWFyIG90aGVyd2lzZSwgd2UnbGwgYWRvcHQgYXQgdGhlIGVuZCBvZiB0aGUgd2Vlay4NCiAg ICANCiAgICBDaGVlcnMsDQogICAgDQogICAgLS0NCiAgICBNYXJrIE5vdHRpbmdoYW0gICBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5tbm90 Lm5ldF8mZD1Ed0lGQWcmYz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JnI9QzBzVW8tTEZOQmFZZnlv YUNzZjZUQSZtPTlDTDJEelJDcnZwV1JFU2VxUXplQkpXbUE1Q3NnanVfdF9tQU05VGtydjgmcz05 c3gxYkJoNmRkNEQ0TG1hU29XUmpRNm1sWnpsVV9OZVBibDBrbXZuWEhFJmU9DQogICAgDQogICAg DQoNCg== From nobody Mon Feb 5 12:01:33 2018 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 5D13F12D95C for ; Mon, 5 Feb 2018 12:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Vn9WrwW2yV7W for ; Mon, 5 Feb 2018 12:01:29 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002: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 44E3112D953 for ; Mon, 5 Feb 2018 12:01:14 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id u17so19264194ywg.9 for ; Mon, 05 Feb 2018 12:01:14 -0800 (PST) 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=uHhjPUDLBFETKUMoRYh+jLGSx3gOvlAVa/6hrfOLMh4=; b=rFHsHSZnz9Mv6X9EnKp36sGRI5HHtv08jBBbrKXtUQJNdOsQ1P3y7Ywr9/6t8ZNk9u 9RYCxmrodmT0bzdORlJBIvBHWJ9ReueefdGr4qffBHLINNPSbHf6tIAaVd3YWDci4aC/ LPq0lynuoHNN2JI4m7RYRcOeC4bfSV4RZM65afGlTfMi0xwgsn8T4Xm8m1j7gFLOHQkT 7cIXhdZpgDxvFGmzb/wCzWp8awmtprqGBxigNXCoO+5B1HoXCSZKqzsmbWBjnyIZfUTC W626mHbLXIjXwjIa1BeWEBZollyOcn46KSmNb1+b7t7EIC5GAmBJOtN+AHzq+IKoGxtt rAwA== 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=uHhjPUDLBFETKUMoRYh+jLGSx3gOvlAVa/6hrfOLMh4=; b=dLRxNNBkMZbTvb8R6t5/VXbIGOYKriqLpyGcYJdw3Gn6333KyPTylRVFvENOpgHNV0 zN9aXRSFgNbLtW01kBWf/JDAuUduy7rFeymSN9Dimi3syYh+YTLGgHoB/mI1mKo4vxRv SiShzlK/ybbf3nYGozvw+neMzaP8c2mSEDN2nsAWysa0eODjfxeywE9IJCYYc2+B/Q4D b92o7IhcvpSO3pIOb5axMz4k+P6y9/S1cPnNOCzkY/hVfXIujPuzUTIRpWXawgBMlGeG lx+J8FCDgNrNZrdwY1NNrpHsrVuMX9QRGmit5UvUqi08jmcA7za0wmUr9n9Bz494rpKD Tdsw== X-Gm-Message-State: AKwxytePKQxlXRinTPdxZtlARTyZs6ORgHxcYzV8AYPMoBmstB+O2qiu 7qwuaY9GJ0WkbdUwo01zvnNd54qCo9/CEdjMQ2upKg== X-Google-Smtp-Source: AH8x224AGrZzkn0oo3eUE57lTNa9uK48oHoCJpRvWeT2RJPl0eRjhMQXpxEkUqKUaIyHNl7zwc//XLj+3eBdvTUSrRI= X-Received: by 10.129.60.9 with SMTP id j9mr31781612ywa.315.1517860872566; Mon, 05 Feb 2018 12:01:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Mon, 5 Feb 2018 12:01:11 -0800 (PST) In-Reply-To: References: <6A834DB6-F2A5-4973-83CD-8AAA82945372@mnot.net> From: Jana Iyengar Date: Mon, 5 Feb 2018 12:01:11 -0800 Message-ID: Subject: Re: Call for Adoption: QCRAM To: Roberto Peon Cc: Mike Bishop , Mark Nottingham , QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="001a1142e95c21c6f005647c861e" 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, 05 Feb 2018 20:01:31 -0000 --001a1142e95c21c6f005647c861e Content-Type: text/plain; charset="UTF-8" +1 for adoption. On Mon, Feb 5, 2018 at 11:05 AM, Roberto Peon wrote: > Agreed. > Supported. > -=R > > On 2/5/18, 11:04 AM, "QUIC on behalf of Mike Bishop" < > quic-bounces@ietf.org on behalf of mbishop@evequefou.be> wrote: > > I support adoption -- it's a useful starting point from which we can > discuss what elements of other proposals are worth lifting into this model. > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham > Sent: Sunday, February 4, 2018 10:08 PM > To: QUIC WG > Cc: Lars Eggert > Subject: Call for Adoption: QCRAM > > In Melbourne, there was strong support (with a small amount of > pushback which was discussed) for adopting QCRAM: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools. > ietf.org_html_draft-2Dkrasic-2Dquic-2Dqcram-2D04&d=DwIFAg& > c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m= > 9CL2DzRCrvpWRESeqQzeBJWmA5Csgju_t_mAM9Tkrv8&s=YUt-etfRURzJAU3Kk3Mh- > 63Xsk6Eqt6jt3_NmshNro0&e= > > Any objections / concerns about doing so? Unless we hear otherwise, > we'll adopt at the end of the week. > > Cheers, > > -- > Mark Nottingham https://urldefense.proofpoint. > com/v2/url?u=https-3A__www.mnot.net_&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r= > C0sUo-LFNBaYfyoaCsf6TA&m=9CL2DzRCrvpWRESeqQzeBJWmA5Csgju_t_mAM9Tkrv8&s= > 9sx1bBh6dd4D4LmaSoWRjQ6mlZzlU_NePbl0kmvnXHE&e= > > > > --001a1142e95c21c6f005647c861e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption.

On Mon, Feb 5, 2018 at 11:05 AM, Roberto Peon <fenix@fb.c= om> wrote:
Agreed.
Supported.
-=3DR

On 2/5/18, 11:04 AM, "QUIC on behalf of Mike Bishop" <quic-bounces@ietf.org on behalf of mbishop@evequefou.be> wrote:
=C2=A0 =C2=A0 I support adoption -- it's a useful starting point from w= hich we can discuss what elements of other proposals are worth lifting into= this model.

=C2=A0 =C2=A0 -----Original Message-----
=C2=A0 =C2=A0 From: QUIC [mailto:q= uic-bounces@ietf.org] On Behalf Of Mark Nottingham
=C2=A0 =C2=A0 Sent: Sunday, February 4, 2018 10:08 PM
=C2=A0 =C2=A0 To: QUIC WG <quic@ietf.or= g>
=C2=A0 =C2=A0 Cc: Lars Eggert <lars@e= ggert.org>
=C2=A0 =C2=A0 Subject: Call for Adoption: QCRAM

=C2=A0 =C2=A0 In Melbourne, there was strong support (with a small amount o= f pushback which was discussed) for adopting QCRAM:

=C2=A0 =C2=A0 ht= tps://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.o= rg_html_draft-2Dkrasic-2Dquic-2Dqcram-2D04&d=3DDwIFAg&c= =3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA&m=3D= 9CL2DzRCrvpWRESeqQzeBJWmA5Csgju_t_mAM9Tkrv8&s=3DYUt-etfRURzJA= U3Kk3Mh-63Xsk6Eqt6jt3_NmshNro0&e=3D

=C2=A0 =C2=A0 Any objections / concerns about doing so? Unless we hear othe= rwise, we'll adopt at the end of the week.

=C2=A0 =C2=A0 Cheers,

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 Mark Nottingham=C2=A0 =C2=A0https://urldefens= e.proofpoint.com/v2/url?u=3Dhttps-3A__www.mnot.net_&d=3DDwIFA= g&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA&a= mp;m=3D9CL2DzRCrvpWRESeqQzeBJWmA5Csgju_t_mAM9Tkrv8&s=3D9= sx1bBh6dd4D4LmaSoWRjQ6mlZzlU_NePbl0kmvnXHE&e=3D




--001a1142e95c21c6f005647c861e-- From nobody Mon Feb 5 12:15:57 2018 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 539D5128954 for ; Mon, 5 Feb 2018 12:15:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 mhrS3a7k4l_6 for ; Mon, 5 Feb 2018 12:15:54 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 D566B127698 for ; Mon, 5 Feb 2018 12:15:53 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id v139so19313663ywg.4 for ; Mon, 05 Feb 2018 12:15:53 -0800 (PST) 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=BAy5MlnQSAOVFyAehuzyAWgLDuhaPjrWlcwMqNdP/fk=; b=hAn1fHV0Pn9PrtnIqkbi0/zkrlmgUKU+JDKZC9ie/AcUCZw6a1Q0nzwobNDZSuMq/L qXGu4oUafDGCDq5zYACig3yRhKZTW+B3asF0uaLZ8bw/GcdsaUncZhXgOXSJqVCvy/5a mFsiNpyVrOe2k8oLuHh6oUDh4hiUUznanZTUnXDhCXBeRDF2WpdjX/f6uJRepP2RMoDg DQ49Mn5wKll+/cEZ8w6xqOuC/O6+k5XNdyqtv/IdE1UPHsLaIHLhkjx7PJkVP6tFol5/ yZk709BKiaKmLDI5T3e3p0Eg1S/iyH7nU1nHTjB5Z0t84H7TC96nsrs0TF+xjuueyYfA pjww== 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=BAy5MlnQSAOVFyAehuzyAWgLDuhaPjrWlcwMqNdP/fk=; b=ujfTKiBB8w9AIVz4c1Iv3glanzaqV/benomYbLiSpaqdLI5zts+isk1nhl0He/5Gj1 I9dxSrKDn54+/d/J00BqfGpfvcR4RYu+EZcrhlL0XnxQdIan3uOd1rqz9GiepdRukeHz 1QgP360f+3tSNvW99Afyym49e9CVklsxkVX2tf3V1EF8G8tcw7slq58p3WPmGzOEltei vqI9Vx5QucmJzzPdHqP8vd3WKyELz2i6y7BjHLiuJ7r3BHj8WkcmBN8E+Fs9JghnOmAu HsnDz/8Y/LqTYzXHr2mqCkajy1HOwSdiNzBjkubaHyloSQvKv7/FR5Tv8IPZ9S17q8Z+ /V3w== X-Gm-Message-State: APf1xPBHJABT4JPSQqxFpqWy0u6Wfe4Cce2+iacQnKMe7HZXgV/Nai8Q KUni7us9QV+efJXUOKZlEpuk4vsVWLkHzmIkDDYXYw== X-Google-Smtp-Source: AH8x224aN5L4WX37rcUKhukonBtpIxlVV8cWqzXVp04oO4+9pEMYX6oWsQegYKwzAki8QeFxV+6LKUSOW6FioKvyAjw= X-Received: by 10.37.74.68 with SMTP id x65mr8312yba.91.1517861752601; Mon, 05 Feb 2018 12:15:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Mon, 5 Feb 2018 12:15:52 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Mon, 5 Feb 2018 12:15:52 -0800 Message-ID: Subject: Re: Call for Adoption: Invariants To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Mike Bishop , "Brian Trammell (IETF)" , Lars Eggert , Mark Nottingham , QUIC WG Content-Type: multipart/alternative; boundary="001a113e67bc95b78e05647cba5f" 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, 05 Feb 2018 20:15:56 -0000 --001a113e67bc95b78e05647cba5f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 for adoption. As Ian pointed out, once published, any changes to the invariants will be a significant uphill task for active deployments. That's the entire point of having these invariants. I would very much like to publish the invariants ahead of the rest of the documents, so that active deployment of IETF-QUIC can start, but that's a matter for a different thread, not this one. On Mon, Feb 5, 2018 at 11:05 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > It could be called QUID ... > > ------------------------------ > *From:* Mike Bishop > *Sent:* Monday, February 5, 2018 8:00:53 PM > *To:* Brian Trammell (IETF); Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Cc:* Lars Eggert; Mark Nottingham; QUIC WG > *Subject:* RE: Call for Adoption: Invariants > > I support adoption. The way to change the invariants will be to mint a > new protocol, and not claim that your new protocol is a version of QUIC. > If it happens to be startlingly similar, all well and good. > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org ] On > Behalf Of Brian Trammell (IETF) > Sent: Monday, February 5, 2018 12:34 AM > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen > Cc: Lars Eggert ; Mark Nottingham ; QUIC > WG > Subject: Re: Call for Adoption: Invariants > > Hi, all, > > I support adoption of the invariants draft. > > > On 5 Feb 2018, at 08:51, Mikkel Fahn=C3=B8e J=C3=B8rgensen > wrote: > > > > Only concern is when it takes effect since it likely needs adjustments. > > I'd presume that invariants is published simultaneously with the version = 1 > spec. > > > And perhaps a procedure to handle invariant changes since everything > changes. > > Noted, though the point of declaring something an invariant is to say "th= e > meaning of this part of the wire image, expressed as a bit offset, will > never change". You can add constraints to the invariants, but if you thin= k > you might remove a constraint, then it's not an invariant by definition. > > Cheers, > > Brian > > > From: QUIC on behalf of Mark Nottingham < > mnot@mnot.net> > > Sent: Monday, February 5, 2018 7:07:45 AM > > To: QUIC WG > > Cc: Lars Eggert > > Subject: Call for Adoption: Invariants > > > > At the Melbourne meeting, there was strong support for adopting Martin'= s > invariants draft: > > > > https://tools.ietf.org/html/draft-thomson-quic-invariants-00 > > > > Any objections / concerns about doing so? Unless we hear otherwise, > we'll adopt at the end of the week. > > > > Cheers, > > > > -- > > Mark Nottingham https://www.mnot.net/ > > --001a113e67bc95b78e05647cba5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for adoption.

As Ian pointed out, on= ce published, any changes to the invariants will be a significant uphill ta= sk for active deployments. That's the entire point of having these inva= riants. I would very much like to publish the invariants ahead of the rest = of the documents, so that active deployment of IETF-QUIC can start, but tha= t's a matter for a different thread, not this one.

On Mon, Feb 5, 2018 at 11:= 05 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
It could be called QUID ...

From: Mike Bishop <mbishop@evequefou.be>
Sent: Monday, February 5, 2018 8:00:53 PM
To: Brian Trammell (IETF); Mikkel Fahn=C3=B8e J=C3=B8rgensen
Cc: Lars Eggert; Mark Nottingham; QUIC WG
Subject: RE: Call for Adoption: Invariants
=C2=A0
I support adoption.=C2=A0 Th= e way to change the invariants will be to mint a new protocol, and not clai= m that your new protocol is a version of QUIC.=C2=A0 If it happens to be st= artlingly similar, all well and good.

-----Original Message-----
From: QUIC [mail= to:quic-bounces@ietf.org] On Behalf Of Brian Trammell (IETF)
Sent: Monday, February 5, 2018 12:34 AM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: Lars Eggert <la= rs@eggert.org>; Mark Nottingham <mnot@mnot.net>; QUIC WG <quic@ietf.org>
Subject: Re: Call for Adoption: Invariants

Hi, all,

I support adoption of the invariants draft.

> On 5 Feb 2018, at 08:51, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>= wrote:
>
> Only concern is when it takes effect since it likely needs adjustments= .

I'd presume that invariants is published simultaneously with the versio= n 1 spec.

> And perhaps a procedure to handle invariant changes since everything c= hanges.

Noted, though the point of declaring something an invariant is to say "= ;the meaning of this part of the wire image, expressed as a bit offset, wil= l never change". You can add constraints to the invariants, but if you= think you might remove a constraint, then it's not an invariant by definition.

Cheers,

Brian

> From: QUIC <quic-bounces@ietf.org> on behalf of Mark Nottingham <mnot@mnot.net>
> Sent: Monday, February 5, 2018 7:07:45 AM
> To: QUIC WG
> Cc: Lars Eggert
> Subject: Call for Adoption: Invariants
>
> At the Melbourne meeting, there was strong support for adopting Martin= 's invariants draft:
>
> https://tools.ietf.org/html/draft-thomson-quic-in= variants-00
>
> Any objections / concerns about doing so? Unless we hear otherwise, we= 'll adopt at the end of the week.
>
> Cheers,
>
> --
> Mark Nottingham=C2=A0=C2=A0 https://www.mnot.net/

--001a113e67bc95b78e05647cba5f-- From nobody Mon Feb 5 12:45:22 2018 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 EED2E12D94B for ; Mon, 5 Feb 2018 12:45:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, 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=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 xMkrvoAIZsQQ for ; Mon, 5 Feb 2018 12:45:17 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 7E62B128954 for ; Mon, 5 Feb 2018 12:45:17 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w15KgxQx002197; Mon, 5 Feb 2018 20:45:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=yAYV4l6//AjhPN9tRVCG5zWPDQAWVPd+WzkUhfg3YWk=; b=K2MNnHmIqRu8fkQvs1Vv8CeNPkHkba0PnXohBxHDXkEuzXZzmLHUrcJ3h3n3xdyGuf88 b89Y3IrctitT1iJ32xfcVHMPX4PlOYAu5dDDi58UDOoS1yIYTo7Dfkopvutr/k/LQA+O Ay4+7RI6zUBoe1x/xqF9G0R22OwDf/PAH2u3f27XphxkjRZmL9qdJdulsS8q+Av+V0Qe czn57lTa03XuhZWNS8nrF/rm7qApIMtGjzx4aFLXc7ftc/DpWQhF5zlGC5BD8sxOwbVv VrCUoHn1GsMauu8gd0/PCLxnjeYnNp1UlpQ1st8IdHjJIvYPNmsKfJG5z2IJwa5UITpC Iw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2fw579r5dp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Feb 2018 20:45:08 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w15Kf2iF020829; Mon, 5 Feb 2018 15:45:07 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fw9ae724a-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 05 Feb 2018 15:45:07 -0500 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; Mon, 5 Feb 2018 15:45:06 -0500 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; Mon, 5 Feb 2018 15:45:06 -0500 From: "Lubashev, Igor" To: Jana Iyengar , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: "Brian Trammell (IETF)" , Mark Nottingham , QUIC WG , Mike Bishop , Lars Eggert Subject: RE: Call for Adoption: Invariants Thread-Topic: Call for Adoption: Invariants Thread-Index: AQHTnketHxVqOy4ggE2WDHwxwswgXqOVw4sAgAALu4CAAK9GgIAAAUEAgAATsgD//7MF0A== Date: Mon, 5 Feb 2018 20:45:05 +0000 Message-ID: <869dbe08975540c98d0984c01f5942dc@usma1ex-dag1mb5.msg.corp.akamai.com> References: 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.34.110] Content-Type: multipart/alternative; boundary="_000_869dbe08975540c98d0984c01f5942dcusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050255 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_05:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802050255 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, 05 Feb 2018 20:45:20 -0000 --_000_869dbe08975540c98d0984c01f5942dcusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIHRoZSBhZG9wdGlvbi4NCg0KVGhlIGFkb3B0aW9uIGRvZXMgbm90IG1lYW4gdGhhdCB0 aGUgZHJhZnQgd2lsbCBiZSBwdWJsaXNoZWQgZXhhY3RseSBsaWtlIGl0IGlzIHJpZ2h0IG5vdy4g IEJ1dCwgYXMgSmFuYSBzYWlkLCBJIHJlYWxseSBob3BlIHdlIGNhbiBzZXR0bGUgdGhpcyBvbmUg YmVmb3JlIHdlIHNldHRsZSB2MSBkcmFmdHMuDQoNCkZyb206IEphbmEgSXllbmdhciBbbWFpbHRv OmpyaUBnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAwNSwgMjAxOCAzOjE2IFBN DQpUbzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPg0KQ2M6 IEJyaWFuIFRyYW1tZWxsIChJRVRGKSA8aWV0ZkB0cmFtbWVsbC5jaD47IE1hcmsgTm90dGluZ2hh bSA8bW5vdEBtbm90Lm5ldD47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNaWtlIEJpc2hvcCA8 bWJpc2hvcEBldmVxdWVmb3UuYmU+OyBMYXJzIEVnZ2VydCA8bGFyc0BlZ2dlcnQub3JnPg0KU3Vi amVjdDogUmU6IENhbGwgZm9yIEFkb3B0aW9uOiBJbnZhcmlhbnRzDQoNCisxIGZvciBhZG9wdGlv bi4NCg0KQXMgSWFuIHBvaW50ZWQgb3V0LCBvbmNlIHB1Ymxpc2hlZCwgYW55IGNoYW5nZXMgdG8g dGhlIGludmFyaWFudHMgd2lsbCBiZSBhIHNpZ25pZmljYW50IHVwaGlsbCB0YXNrIGZvciBhY3Rp dmUgZGVwbG95bWVudHMuIFRoYXQncyB0aGUgZW50aXJlIHBvaW50IG9mIGhhdmluZyB0aGVzZSBp bnZhcmlhbnRzLiBJIHdvdWxkIHZlcnkgbXVjaCBsaWtlIHRvIHB1Ymxpc2ggdGhlIGludmFyaWFu dHMgYWhlYWQgb2YgdGhlIHJlc3Qgb2YgdGhlIGRvY3VtZW50cywgc28gdGhhdCBhY3RpdmUgZGVw bG95bWVudCBvZiBJRVRGLVFVSUMgY2FuIHN0YXJ0LCBidXQgdGhhdCdzIGEgbWF0dGVyIGZvciBh IGRpZmZlcmVudCB0aHJlYWQsIG5vdCB0aGlzIG9uZS4NCg0KT24gTW9uLCBGZWIgNSwgMjAxOCBh dCAxMTowNSBBTSwgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29t PG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+PiB3cm90ZToNCkl0IGNvdWxkIGJlIGNhbGxlZCBR VUlEIC4uLg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogTWlrZSBC aXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+ DQpTZW50OiBNb25kYXksIEZlYnJ1YXJ5IDUsIDIwMTggODowMDo1MyBQTQ0KVG86IEJyaWFuIFRy YW1tZWxsIChJRVRGKTsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KQ2M6IExhcnMgRWdnZXJ0 OyBNYXJrIE5vdHRpbmdoYW07IFFVSUMgV0cNClN1YmplY3Q6IFJFOiBDYWxsIGZvciBBZG9wdGlv bjogSW52YXJpYW50cw0KDQpJIHN1cHBvcnQgYWRvcHRpb24uICBUaGUgd2F5IHRvIGNoYW5nZSB0 aGUgaW52YXJpYW50cyB3aWxsIGJlIHRvIG1pbnQgYSBuZXcgcHJvdG9jb2wsIGFuZCBub3QgY2xh aW0gdGhhdCB5b3VyIG5ldyBwcm90b2NvbCBpcyBhIHZlcnNpb24gb2YgUVVJQy4gIElmIGl0IGhh cHBlbnMgdG8gYmUgc3RhcnRsaW5nbHkgc2ltaWxhciwgYWxsIHdlbGwgYW5kIGdvb2QuDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJpYW4gVHJhbW1lbGwgKElFVEYpDQpTZW50OiBNb25k YXksIEZlYnJ1YXJ5IDUsIDIwMTggMTI6MzQgQU0NClRvOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vu c2VuIDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT4+DQpDYzog TGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZzxtYWlsdG86bGFyc0BlZ2dlcnQub3JnPj47IE1h cmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldDxtYWlsdG86bW5vdEBtbm90Lm5ldD4+OyBRVUlD IFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBD YWxsIGZvciBBZG9wdGlvbjogSW52YXJpYW50cw0KDQpIaSwgYWxsLA0KDQpJIHN1cHBvcnQgYWRv cHRpb24gb2YgdGhlIGludmFyaWFudHMgZHJhZnQuDQoNCj4gT24gNSBGZWIgMjAxOCwgYXQgMDg6 NTEsIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86 bWlra2VsZmpAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+IE9ubHkgY29uY2VybiBpcyB3aGVuIGl0 IHRha2VzIGVmZmVjdCBzaW5jZSBpdCBsaWtlbHkgbmVlZHMgYWRqdXN0bWVudHMuDQoNCkknZCBw cmVzdW1lIHRoYXQgaW52YXJpYW50cyBpcyBwdWJsaXNoZWQgc2ltdWx0YW5lb3VzbHkgd2l0aCB0 aGUgdmVyc2lvbiAxIHNwZWMuDQoNCj4gQW5kIHBlcmhhcHMgYSBwcm9jZWR1cmUgdG8gaGFuZGxl IGludmFyaWFudCBjaGFuZ2VzIHNpbmNlIGV2ZXJ5dGhpbmcgY2hhbmdlcy4NCg0KTm90ZWQsIHRo b3VnaCB0aGUgcG9pbnQgb2YgZGVjbGFyaW5nIHNvbWV0aGluZyBhbiBpbnZhcmlhbnQgaXMgdG8g c2F5ICJ0aGUgbWVhbmluZyBvZiB0aGlzIHBhcnQgb2YgdGhlIHdpcmUgaW1hZ2UsIGV4cHJlc3Nl ZCBhcyBhIGJpdCBvZmZzZXQsIHdpbGwgbmV2ZXIgY2hhbmdlIi4gWW91IGNhbiBhZGQgY29uc3Ry YWludHMgdG8gdGhlIGludmFyaWFudHMsIGJ1dCBpZiB5b3UgdGhpbmsgeW91IG1pZ2h0IHJlbW92 ZSBhIGNvbnN0cmFpbnQsIHRoZW4gaXQncyBub3QgYW4gaW52YXJpYW50IGJ5IGRlZmluaXRpb24u DQoNCkNoZWVycywNCg0KQnJpYW4NCg0KPiBGcm9tOiBRVUlDIDxxdWljLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBNYXJrIE5vdHRp bmdoYW0gPG1ub3RAbW5vdC5uZXQ8bWFpbHRvOm1ub3RAbW5vdC5uZXQ+Pg0KPiBTZW50OiBNb25k YXksIEZlYnJ1YXJ5IDUsIDIwMTggNzowNzo0NSBBTQ0KPiBUbzogUVVJQyBXRw0KPiBDYzogTGFy cyBFZ2dlcnQNCj4gU3ViamVjdDogQ2FsbCBmb3IgQWRvcHRpb246IEludmFyaWFudHMNCj4NCj4g QXQgdGhlIE1lbGJvdXJuZSBtZWV0aW5nLCB0aGVyZSB3YXMgc3Ryb25nIHN1cHBvcnQgZm9yIGFk b3B0aW5nIE1hcnRpbidzIGludmFyaWFudHMgZHJhZnQ6DQo+DQo+IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC10aG9tc29uLXF1aWMtaW52YXJpYW50cy0wMDxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0 bWxfZHJhZnQtMkR0aG9tc29uLTJEcXVpYy0yRGludmFyaWFudHMtMkQwMCZkPUR3TUZhUSZjPTk2 WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRu X201NUtQbWxvJm09S1g3el83NF9TbWZDTkNDZndidkdVcmoxNGFraG5ZV0ZhX2pZVXNKOWI0cyZz PWJ3TktuYkUwZDVuZ05uRUxWRWE2LVJBcFh4T3NBM3I5WlpKOU9GNDQ4bGsmZT0+DQo+DQo+IEFu eSBvYmplY3Rpb25zIC8gY29uY2VybnMgYWJvdXQgZG9pbmcgc28/IFVubGVzcyB3ZSBoZWFyIG90 aGVyd2lzZSwgd2UnbGwgYWRvcHQgYXQgdGhlIGVuZCBvZiB0aGUgd2Vlay4NCj4NCj4gQ2hlZXJz LA0KPg0KPiAtLQ0KPiBNYXJrIE5vdHRpbmdoYW0gICBodHRwczovL3d3dy5tbm90Lm5ldC88aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cubW5v dC5uZXRfJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1f MnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8mbT1LWDd6Xzc0X1NtZkNOQ0Nmd2J2R1VyajE0 YWtobllXRmFfallVc0o5YjRzJnM9V2FiQjFkUWNvNTJkV2toSmcyZGl4dTluU2Focl83QkpDaHBo RGdIRi1DcyZlPT4NCg0K --_000_869dbe08975540c98d0984c01f5942dcusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41 aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQov KiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo4Mzc0MjIyMDM7 DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi04ODI2MjUw OTQgMTgzMTM0MDQ0MiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mIzQzOzEgZm9yIHRoZSBhZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGFkb3B0aW9uIGRvZXMgbm90IG1lYW4gdGhhdCB0aGUgZHJhZnQgd2lsbCBiZSBw dWJsaXNoZWQgZXhhY3RseSBsaWtlIGl0IGlzIHJpZ2h0IG5vdy4mbmJzcDsgQnV0LCBhcyBKYW5h IHNhaWQsIEkgcmVhbGx5IGhvcGUgd2UgY2FuIHNldHRsZSB0aGlzIG9uZSBiZWZvcmUgd2Ugc2V0 dGxlIHYxIGRyYWZ0cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEphbmEg SXllbmdhciBbbWFpbHRvOmpyaUBnb29nbGUuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBGZWJydWFyeSAwNSwgMjAxOCAzOjE2IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtrZWwgRmFobsO4 ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBC cmlhbiBUcmFtbWVsbCAoSUVURikgJmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7OyBNYXJrIE5vdHRp bmdoYW0gJmx0O21ub3RAbW5vdC5uZXQmZ3Q7OyBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0 OzsgTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0OzsgTGFycyBFZ2dlcnQg Jmx0O2xhcnNAZWdnZXJ0Lm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IENhbGwgZm9y IEFkb3B0aW9uOiBJbnZhcmlhbnRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQz OzEgZm9yIGFkb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QXMgSWFuIHBvaW50ZWQgb3V0LCBvbmNlIHB1Ymxpc2hlZCwgYW55IGNoYW5nZXMgdG8g dGhlIGludmFyaWFudHMgd2lsbCBiZSBhIHNpZ25pZmljYW50IHVwaGlsbCB0YXNrIGZvciBhY3Rp dmUgZGVwbG95bWVudHMuIFRoYXQncyB0aGUgZW50aXJlIHBvaW50IG9mIGhhdmluZyB0aGVzZSBp bnZhcmlhbnRzLiBJIHdvdWxkIHZlcnkgbXVjaCBsaWtlIHRvIHB1Ymxpc2ggdGhlIGludmFyaWFu dHMgYWhlYWQgb2YgdGhlDQogcmVzdCBvZiB0aGUgZG9jdW1lbnRzLCBzbyB0aGF0IGFjdGl2ZSBk ZXBsb3ltZW50IG9mIElFVEYtUVVJQyBjYW4gc3RhcnQsIGJ1dCB0aGF0J3MgYSBtYXR0ZXIgZm9y IGEgZGlmZmVyZW50IHRocmVhZCwgbm90IHRoaXMgb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEZlYiA1LCAyMDE4IGF0IDEx OjA1IEFNLCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlr a2VsZmpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 IGlkPSJtXy04MzE1MzkwMjk0OTc4MjE0MzE2eF9jb21wb3NlLWNvbnRhaW5lciI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBjb3VsZCBiZSBjYWxsZWQgUVVJ RCAuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNl bnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4N CjxkaXYgaWQ9Im1fLTgzMTUzOTAyOTQ5NzgyMTQzMTZ4X2RpdlJwbHlGd2RNc2ciPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1h aWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVl Zm91LmJlPC9hPiZndDs8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4 IDg6MDA6NTMgUE08YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIFRyYW1tZWxsIChJRVRGKTsgTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbjxicj4NCjxiPkNjOjwvYj4gTGFycyBFZ2dlcnQ7IE1hcmsgTm90 dGluZ2hhbTsgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogQ2FsbCBmb3IgQWRvcHRp b246IEludmFyaWFudHM8L3NwYW4+IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5JIHN1cHBvcnQgYWRvcHRpb24uJm5ic3A7IFRoZSB3YXkgdG8gY2hhbmdl IHRoZSBpbnZhcmlhbnRzIHdpbGwgYmUgdG8gbWludCBhIG5ldyBwcm90b2NvbCwgYW5kIG5vdCBj bGFpbSB0aGF0IHlvdXIgbmV3IHByb3RvY29sIGlzIGEgdmVyc2lvbiBvZiBRVUlDLiZuYnNwOyBJ ZiBpdCBoYXBwZW5zIHRvIGJlIHN0YXJ0bGluZ2x5IHNpbWlsYXIsIGFsbCB3ZWxsIGFuZCBnb29k Ljxicj4NCjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogUVVJQyBb PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQnJpYW4gVHJhbW1l bGwgKElFVEYpPGJyPg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4IDEyOjM0IEFNPGJy Pg0KVG86IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtr ZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0 Ozxicj4NCkNjOiBMYXJzIEVnZ2VydCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNAZWdnZXJ0Lm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPmxhcnNAZWdnZXJ0Lm9yZzwvYT4mZ3Q7OyBNYXJrIE5vdHRpbmdo YW0gJmx0OzxhIGhyZWY9Im1haWx0bzptbm90QG1ub3QubmV0IiB0YXJnZXQ9Il9ibGFuayI+bW5v dEBtbm90Lm5ldDwvYT4mZ3Q7OyBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6 IFJlOiBDYWxsIGZvciBBZG9wdGlvbjogSW52YXJpYW50czxicj4NCjxicj4NCkhpLCBhbGwsPGJy Pg0KPGJyPg0KSSBzdXBwb3J0IGFkb3B0aW9uIG9mIHRoZSBpbnZhcmlhbnRzIGRyYWZ0Ljxicj4N Cjxicj4NCiZndDsgT24gNSBGZWIgMjAxOCwgYXQgMDg6NTEsIE1pa2tlbCBGYWhuw7hlIErDuHJn ZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZn dDsgT25seSBjb25jZXJuIGlzIHdoZW4gaXQgdGFrZXMgZWZmZWN0IHNpbmNlIGl0IGxpa2VseSBu ZWVkcyBhZGp1c3RtZW50cy48YnI+DQo8YnI+DQpJJ2QgcHJlc3VtZSB0aGF0IGludmFyaWFudHMg aXMgcHVibGlzaGVkIHNpbXVsdGFuZW91c2x5IHdpdGggdGhlIHZlcnNpb24gMSBzcGVjLjxicj4N Cjxicj4NCiZndDsgQW5kIHBlcmhhcHMgYSBwcm9jZWR1cmUgdG8gaGFuZGxlIGludmFyaWFudCBj aGFuZ2VzIHNpbmNlIGV2ZXJ5dGhpbmcgY2hhbmdlcy48YnI+DQo8YnI+DQpOb3RlZCwgdGhvdWdo IHRoZSBwb2ludCBvZiBkZWNsYXJpbmcgc29tZXRoaW5nIGFuIGludmFyaWFudCBpcyB0byBzYXkg JnF1b3Q7dGhlIG1lYW5pbmcgb2YgdGhpcyBwYXJ0IG9mIHRoZSB3aXJlIGltYWdlLCBleHByZXNz ZWQgYXMgYSBiaXQgb2Zmc2V0LCB3aWxsIG5ldmVyIGNoYW5nZSZxdW90Oy4gWW91IGNhbiBhZGQg Y29uc3RyYWludHMgdG8gdGhlIGludmFyaWFudHMsIGJ1dCBpZiB5b3UgdGhpbmsgeW91IG1pZ2h0 IHJlbW92ZSBhIGNvbnN0cmFpbnQsIHRoZW4NCiBpdCdzIG5vdCBhbiBpbnZhcmlhbnQgYnkgZGVm aW5pdGlvbi48YnI+DQo8YnI+DQpDaGVlcnMsPGJyPg0KPGJyPg0KQnJpYW48YnI+DQo8YnI+DQom Z3Q7IEZyb206IFFVSUMgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYg b2YgTWFyayBOb3R0aW5naGFtICZsdDs8YSBocmVmPSJtYWlsdG86bW5vdEBtbm90Lm5ldCIgdGFy Z2V0PSJfYmxhbmsiPm1ub3RAbW5vdC5uZXQ8L2E+Jmd0Ozxicj4NCiZndDsgU2VudDogTW9uZGF5 LCBGZWJydWFyeSA1LCAyMDE4IDc6MDc6NDUgQU08YnI+DQomZ3Q7IFRvOiBRVUlDIFdHPGJyPg0K Jmd0OyBDYzogTGFycyBFZ2dlcnQ8YnI+DQomZ3Q7IFN1YmplY3Q6IENhbGwgZm9yIEFkb3B0aW9u OiBJbnZhcmlhbnRzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEF0IHRoZSBNZWxib3VybmUgbWVldGlu ZywgdGhlcmUgd2FzIHN0cm9uZyBzdXBwb3J0IGZvciBhZG9wdGluZyBNYXJ0aW4ncyBpbnZhcmlh bnRzIGRyYWZ0Ojxicj4NCiZndDsgPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxf ZHJhZnQtMkR0aG9tc29uLTJEcXVpYy0yRGludmFyaWFudHMtMkQwMCZhbXA7ZD1Ed01GYVEmYW1w O2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6 Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPUtYN3pfNzRfU21mQ05DQ2Z3YnZHVXJqMTRha2huWVdG YV9qWVVzSjliNHMmYW1wO3M9YndOS25iRTBkNW5nTm5FTFZFYTYtUkFwWHhPc0EzcjlaWko5T0Y0 NDhsayZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC10aG9tc29uLXF1aWMtaW52YXJpYW50cy0wMDwvYT48YnI+DQomZ3Q7IDxicj4NCiZn dDsgQW55IG9iamVjdGlvbnMgLyBjb25jZXJucyBhYm91dCBkb2luZyBzbz8gVW5sZXNzIHdlIGhl YXIgb3RoZXJ3aXNlLCB3ZSdsbCBhZG9wdCBhdCB0aGUgZW5kIG9mIHRoZSB3ZWVrLjxicj4NCiZn dDsgPGJyPg0KJmd0OyBDaGVlcnMsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tPGJyPg0KJmd0OyBN YXJrIE5vdHRpbmdoYW0mbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cubW5vdC5uZXRfJmFtcDtkPUR3TUZh USZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPURqbjNiUTV1TkpEUE1fMnNrZkwz clcxdHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209S1g3el83NF9TbWZDTkNDZndidkdVcmoxNGFr aG5ZV0ZhX2pZVXNKOWI0cyZhbXA7cz1XYWJCMWRRY281MmRXa2hKZzJkaXh1OW5TYWhyXzdCSkNo cGhEZ0hGLUNzJmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cubW5vdC5uZXQv PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_869dbe08975540c98d0984c01f5942dcusma1exdag1mb5msgcorpak_-- From nobody Mon Feb 5 13:05:31 2018 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 E28F412D953 for ; Mon, 5 Feb 2018 13:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 5VHxhqZ8bLus for ; Mon, 5 Feb 2018 13:05:27 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0135.outbound.protection.outlook.com [104.47.36.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39138128954 for ; Mon, 5 Feb 2018 13:05:27 -0800 (PST) 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=DA86FZtILMNtQqPCWzJU3dqPevmcZJDNWR4H6rdRqF0=; b=iqPjV6pyIY3eLT9Sq/KDtjlkaM1iK5/astRdPgrD/kpjDrRx4UxzMy6W+f+/nOaywtxvURii4HjkSfbmCITvq4LZTclOAZ2AWqSheEed/TawG9RcdKkJU+mgSvdAOK10NAHew9mfcy1SqKqg+lcPqW+ctXTD7t8Eo0kUcZ5AHmQ= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0838.namprd21.prod.outlook.com (10.173.192.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.1; Mon, 5 Feb 2018 21:05:25 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Mon, 5 Feb 2018 21:05:25 +0000 From: Praveen Balasubramanian To: "Lubashev, Igor" , Jana Iyengar , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: "Brian Trammell (IETF)" , Mark Nottingham , QUIC WG , Mike Bishop , Lars Eggert Subject: RE: Call for Adoption: Invariants Thread-Topic: Call for Adoption: Invariants Thread-Index: AQHTnketpPPeU/jidk6aOHbvjAdkY6OVb7kAgAALu4CAAK9GgIAAAUEAgAATswCAAAgpgIAABZ8g Date: Mon, 5 Feb 2018 21:05:24 +0000 Message-ID: References: <869dbe08975540c98d0984c01f5942dc@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <869dbe08975540c98d0984c01f5942dc@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0838; 6:7xjJ3LxR3GDdPMDPttMjzQgiKldaonOMBSSb95/lVnF7pKHzUjO40mvguBCV5wMFcTcSjGrjsR4b2oajiG3BC1DxnXJKcFWrYuFSU6G7kdaqcWzAiHSIVJ3ZDglzzYt9nL7sHPsDFweT9ge+dlS0ufSQtTZSsJfac7pV/YxnBeBKC7QGUQJpyJVoqaKb4mnCRGGoeXaizm/J8InDmEsAoeY7ByMOJZ8cl0TXfl2ZJsy3TWfGyqXhi2NOePMrtzfXbpNMsYRaINGJoihwiEsVeo3gf/l0EOIcCluPpSOvcDwohKSe3Sedkpbi/2/pcUgRGAeIkIHv/jJi22bmTL1piBRHSUgoSgVLnZ/3/+4xb0O8fGREXGL9N6PipvlcG9IT; 5:Uk8xoVY1yZJ5g1Po1mA5zv9jLLT/a+haJXf/3471jBvhckRtZJK1gwkKsWDkWz/jnRzd3td6anDGWxHhQ8OkXuqVy/TtKU0S/YrC+HimYCJGuFjECfpP0JW/b3VUEoorJd7CZEkcVKhltqE6S/8G9GJ8WpZj7GWiZYFN+MFjmE8=; 24:x6iKFc/yZGA/8hNb1wvN7boVBO6i7/pOuo2T2z7X5VMDsuRJq4EyeNJP9oo3rfNbpuxq8QnDNHX75Xtsk08l4frFQ/adm53VtN52T3hXyUA=; 7:CJzEt7w9ZOg0IQrbGYqdtEwzQAuGZNOBW6oKqCOkjET9SFD1ZnXW2Woo0nkx/gtpXBHgwFNEESAOlKRef8rcCMdmMH5UUJoY7j3jS4h4zzq7nWcJIbu2jWNUF8MGtgEm736+qPxk/CcTAoVCNuPHqUvZLwkg+uY/xdpuy48/NicxN+EKWYAFLTZwwxSTOQgbi6LMtdnrfRREMdTrHMvFrOSebwVz39mAH7hmjPdzcfYUP7xzjhrS0uZdmoX7dRj1 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 524ce1b2-f93e-4fb3-c0ef-08d56cdc2d58 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0838; x-ms-traffictypediagnostic: CY4PR21MB0838: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(189930954265078)(85827821059158)(211936372134217)(153496737603132)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0838; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0838; x-forefront-prvs: 0574D4712B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(396003)(346002)(376002)(366004)(199004)(189003)(13464003)(316002)(86362001)(53936002)(33656002)(7736002)(6506007)(102836004)(25786009)(6246003)(478600001)(790700001)(6116002)(10090500001)(3660700001)(77096007)(4326008)(76176011)(53546011)(10290500003)(2906002)(39060400002)(6346003)(3280700002)(7696005)(2900100001)(97736004)(74316002)(186003)(86612001)(22452003)(5660300001)(229853002)(6436002)(99286004)(106356001)(81156014)(81166006)(966005)(2950100002)(8936002)(14454004)(8676002)(68736007)(55016002)(606006)(8990500004)(9686003)(105586002)(236005)(19609705001)(54906003)(6306002)(54896002)(110136005)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0838; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: OK+IEtUDtvfDVnn/Zir1gFpwM1HxjSB4H/AJLaLCtdmFOYzpz5+VxQdyYW1ReWD5NAOKJ+VbR3dpuR59KygEEw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB013319562763F0DADC138466B6FE0CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 524ce1b2-f93e-4fb3-c0ef-08d56cdc2d58 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2018 21:05:25.0397 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0838 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, 05 Feb 2018 21:05:31 -0000 --_000_CY4PR21MB013319562763F0DADC138466B6FE0CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIGFkb3B0aW9uDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBMdWJhc2hldiwgSWdvcg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA1 LCAyMDE4IDEyOjQ1IFBNDQpUbzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IE1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT4NCkNjOiBCcmlhbiBUcmFt bWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+OyBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5v dC5uZXQ+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZl cXVlZm91LmJlPjsgTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz4NClN1YmplY3Q6IFJFOiBD YWxsIGZvciBBZG9wdGlvbjogSW52YXJpYW50cw0KDQorMSBmb3IgdGhlIGFkb3B0aW9uLg0KDQpU aGUgYWRvcHRpb24gZG9lcyBub3QgbWVhbiB0aGF0IHRoZSBkcmFmdCB3aWxsIGJlIHB1Ymxpc2hl ZCBleGFjdGx5IGxpa2UgaXQgaXMgcmlnaHQgbm93LiAgQnV0LCBhcyBKYW5hIHNhaWQsIEkgcmVh bGx5IGhvcGUgd2UgY2FuIHNldHRsZSB0aGlzIG9uZSBiZWZvcmUgd2Ugc2V0dGxlIHYxIGRyYWZ0 cy4NCg0KRnJvbTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21dDQpTZW50OiBN b25kYXksIEZlYnJ1YXJ5IDA1LCAyMDE4IDM6MTYgUE0NClRvOiBNaWtrZWwgRmFobsO4ZSBKw7hy Z2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT4+DQpD YzogQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPG1haWx0bzppZXRmQHRy YW1tZWxsLmNoPj47IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldDxtYWlsdG86bW5vdEBt bm90Lm5ldD4+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47 IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVm b3UuYmU+PjsgTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZzxtYWlsdG86bGFyc0BlZ2dlcnQu b3JnPj4NClN1YmplY3Q6IFJlOiBDYWxsIGZvciBBZG9wdGlvbjogSW52YXJpYW50cw0KDQorMSBm b3IgYWRvcHRpb24uDQoNCkFzIElhbiBwb2ludGVkIG91dCwgb25jZSBwdWJsaXNoZWQsIGFueSBj aGFuZ2VzIHRvIHRoZSBpbnZhcmlhbnRzIHdpbGwgYmUgYSBzaWduaWZpY2FudCB1cGhpbGwgdGFz ayBmb3IgYWN0aXZlIGRlcGxveW1lbnRzLiBUaGF0J3MgdGhlIGVudGlyZSBwb2ludCBvZiBoYXZp bmcgdGhlc2UgaW52YXJpYW50cy4gSSB3b3VsZCB2ZXJ5IG11Y2ggbGlrZSB0byBwdWJsaXNoIHRo ZSBpbnZhcmlhbnRzIGFoZWFkIG9mIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudHMsIHNvIHRoYXQg YWN0aXZlIGRlcGxveW1lbnQgb2YgSUVURi1RVUlDIGNhbiBzdGFydCwgYnV0IHRoYXQncyBhIG1h dHRlciBmb3IgYSBkaWZmZXJlbnQgdGhyZWFkLCBub3QgdGhpcyBvbmUuDQoNCk9uIE1vbiwgRmVi IDUsIDIwMTggYXQgMTE6MDUgQU0sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZq QGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4gd3JvdGU6DQpJdCBjb3VsZCBi ZSBjYWxsZWQgUVVJRCAuLi4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZy b206IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVx dWVmb3UuYmU+Pg0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4IDg6MDA6NTMgUE0NClRv OiBCcmlhbiBUcmFtbWVsbCAoSUVURik7IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NCkNjOiBM YXJzIEVnZ2VydDsgTWFyayBOb3R0aW5naGFtOyBRVUlDIFdHDQpTdWJqZWN0OiBSRTogQ2FsbCBm b3IgQWRvcHRpb246IEludmFyaWFudHMNCg0KSSBzdXBwb3J0IGFkb3B0aW9uLiAgVGhlIHdheSB0 byBjaGFuZ2UgdGhlIGludmFyaWFudHMgd2lsbCBiZSB0byBtaW50IGEgbmV3IHByb3RvY29sLCBh bmQgbm90IGNsYWltIHRoYXQgeW91ciBuZXcgcHJvdG9jb2wgaXMgYSB2ZXJzaW9uIG9mIFFVSUMu ICBJZiBpdCBoYXBwZW5zIHRvIGJlIHN0YXJ0bGluZ2x5IHNpbWlsYXIsIGFsbCB3ZWxsIGFuZCBn b29kLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIFRyYW1tZWxsIChJRVRGKQ0K U2VudDogTW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4IDEyOjM0IEFNDQpUbzogTWlra2VsIEZhaG7D uGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5j b20+Pg0KQ2M6IExhcnMgRWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc8bWFpbHRvOmxhcnNAZWdnZXJ0 Lm9yZz4+OyBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ8bWFpbHRvOm1ub3RAbW5vdC5u ZXQ+PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogQ2FsbCBmb3IgQWRvcHRpb246IEludmFyaWFudHMNCg0KSGksIGFsbCwNCg0KSSBz dXBwb3J0IGFkb3B0aW9uIG9mIHRoZSBpbnZhcmlhbnRzIGRyYWZ0Lg0KDQo+IE9uIDUgRmViIDIw MTgsIGF0IDA4OjUxLCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5j b208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT4+IHdyb3RlOg0KPg0KPiBPbmx5IGNvbmNlcm4g aXMgd2hlbiBpdCB0YWtlcyBlZmZlY3Qgc2luY2UgaXQgbGlrZWx5IG5lZWRzIGFkanVzdG1lbnRz Lg0KDQpJJ2QgcHJlc3VtZSB0aGF0IGludmFyaWFudHMgaXMgcHVibGlzaGVkIHNpbXVsdGFuZW91 c2x5IHdpdGggdGhlIHZlcnNpb24gMSBzcGVjLg0KDQo+IEFuZCBwZXJoYXBzIGEgcHJvY2VkdXJl IHRvIGhhbmRsZSBpbnZhcmlhbnQgY2hhbmdlcyBzaW5jZSBldmVyeXRoaW5nIGNoYW5nZXMuDQoN Ck5vdGVkLCB0aG91Z2ggdGhlIHBvaW50IG9mIGRlY2xhcmluZyBzb21ldGhpbmcgYW4gaW52YXJp YW50IGlzIHRvIHNheSAidGhlIG1lYW5pbmcgb2YgdGhpcyBwYXJ0IG9mIHRoZSB3aXJlIGltYWdl LCBleHByZXNzZWQgYXMgYSBiaXQgb2Zmc2V0LCB3aWxsIG5ldmVyIGNoYW5nZSIuIFlvdSBjYW4g YWRkIGNvbnN0cmFpbnRzIHRvIHRoZSBpbnZhcmlhbnRzLCBidXQgaWYgeW91IHRoaW5rIHlvdSBt aWdodCByZW1vdmUgYSBjb25zdHJhaW50LCB0aGVuIGl0J3Mgbm90IGFuIGludmFyaWFudCBieSBk ZWZpbml0aW9uLg0KDQpDaGVlcnMsDQoNCkJyaWFuDQoNCj4gRnJvbTogUVVJQyA8cXVpYy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2Yg TWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PG1haWx0bzptbm90QG1ub3QubmV0Pj4NCj4g U2VudDogTW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4IDc6MDc6NDUgQU0NCj4gVG86IFFVSUMgV0cN Cj4gQ2M6IExhcnMgRWdnZXJ0DQo+IFN1YmplY3Q6IENhbGwgZm9yIEFkb3B0aW9uOiBJbnZhcmlh bnRzDQo+DQo+IEF0IHRoZSBNZWxib3VybmUgbWVldGluZywgdGhlcmUgd2FzIHN0cm9uZyBzdXBw b3J0IGZvciBhZG9wdGluZyBNYXJ0aW4ncyBpbnZhcmlhbnRzIGRyYWZ0Og0KPg0KPiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGhvbXNvbi1xdWljLWludmFyaWFudHMtMDA8aHR0 cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0El MkYlMkZ1cmxkZWZlbnNlLnByb29mcG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMtM0Ff X3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkR0aG9tc29uLTJEcXVpYy0yRGludmFyaWFudHMt MkQwMCUyNmQlM0REd01GYVElMjZjJTNEOTZaYlpaY2FNRjR3MEY0anBONkxaZyUyNnIlM0REam4z YlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJTI2bSUzREtYN3pfNzRfU21m Q05DQ2Z3YnZHVXJqMTRha2huWVdGYV9qWVVzSjliNHMlMjZzJTNEYndOS25iRTBkNW5nTm5FTFZF YTYtUkFwWHhPc0EzcjlaWko5T0Y0NDhsayUyNmUlM0QmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBt aWNyb3NvZnQuY29tJTdDZTk2ZjZlZDVjY2Y4NDQxMjU1ZjgwOGQ1NmNkOTYxYjglN0NlZTMzMDNk N2ZiNzM0YjBjODU4OWJjZDg0N2YxYzI3NyU3QzElN0MwJTdDNjM2NTM0NjAzMjcwMDIwNzYxJnNk YXRhPXUzdWQlMkJQTGZOTVlRQWgzYmIyYUFXS0ZiREJRbFl1WDl4RkR3SUdKSHRhdyUzRCZyZXNl cnZlZD0wPg0KPg0KPiBBbnkgb2JqZWN0aW9ucyAvIGNvbmNlcm5zIGFib3V0IGRvaW5nIHNvPyBV bmxlc3Mgd2UgaGVhciBvdGhlcndpc2UsIHdlJ2xsIGFkb3B0IGF0IHRoZSBlbmQgb2YgdGhlIHdl ZWsuDQo+DQo+IENoZWVycywNCj4NCj4gLS0NCj4gTWFyayBOb3R0aW5naGFtICAgaHR0cHM6Ly93 d3cubW5vdC5uZXQvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJs JTNGdSUzRGh0dHBzLTNBX193d3cubW5vdC5uZXRfJTI2ZCUzRER3TUZhUSUyNmMlM0Q5NlpiWlpj YU1GNHcwRjRqcE42TFpnJTI2ciUzRERqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5f bTU1S1BtbG8lMjZtJTNES1g3el83NF9TbWZDTkNDZndidkdVcmoxNGFraG5ZV0ZhX2pZVXNKOWI0 cyUyNnMlM0RXYWJCMWRRY281MmRXa2hKZzJkaXh1OW5TYWhyXzdCSkNocGhEZ0hGLUNzJTI2ZSUz RCZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NlOTZmNmVkNWNjZjg0NDEy NTVmODA4ZDU2Y2Q5NjFiOCU3Q2VlMzMwM2Q3ZmI3MzRiMGM4NTg5YmNkODQ3ZjFjMjc3JTdDMSU3 QzAlN0M2MzY1MzQ2MDMyNzAwMjA3NjEmc2RhdGE9YXRMQ1p3UGppY2F3JTJCdUhmZUpnNWZhY1lQ TEFXN2pLN2NZV3NiUkloUmEwJTNEJnJlc2VydmVkPTA+DQoNCg== --_000_CY4PR21MB013319562763F0DADC138466B6FE0CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mIzQzOzEgZm9yIGFkb3B0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+THViYXNoZXYsIEln b3I8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4IDEyOjQ1IFBNPGJy Pg0KPGI+VG86PC9iPiBKYW5hIEl5ZW5nYXIgJmx0O2pyaUBnb29nbGUuY29tJmd0OzsgTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7bWlra2VsZmpAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gQnJpYW4gVHJhbW1lbGwgKElFVEYpICZsdDtpZXRmQHRyYW1tZWxsLmNoJmd0OzsgTWFy ayBOb3R0aW5naGFtICZsdDttbm90QG1ub3QubmV0Jmd0OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRm Lm9yZyZndDs7IE1pa2UgQmlzaG9wICZsdDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZndDs7IExhcnMg RWdnZXJ0ICZsdDtsYXJzQGVnZ2VydC5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBD YWxsIGZvciBBZG9wdGlvbjogSW52YXJpYW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+JiM0MzsxIGZvciB0aGUgYWRvcHRpb24uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBhZG9wdGlvbiBkb2VzIG5vdCBtZWFuIHRoYXQgdGhlIGRyYWZ0IHdpbGwgYmUgcHVi bGlzaGVkIGV4YWN0bHkgbGlrZSBpdCBpcyByaWdodCBub3cuJm5ic3A7IEJ1dCwgYXMgSmFuYSBz YWlkLCBJIHJlYWxseSBob3BlIHdlIGNhbiBzZXR0bGUgdGhpcyBvbmUgYmVmb3JlIHdlIHNldHRs ZSB2MSBkcmFmdHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBKYW5hIEl5 ZW5nYXIgWzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+bWFpbHRvOmpyaUBnb29nbGUu Y29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDA1LCAyMDE4IDM6 MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhy ZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiBCcmlhbiBUcmFtbWVsbCAoSUVURikgJmx0OzxhIGhyZWY9Im1haWx0 bzppZXRmQHRyYW1tZWxsLmNoIj5pZXRmQHRyYW1tZWxsLmNoPC9hPiZndDs7IE1hcmsgTm90dGlu Z2hhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1ub3RAbW5vdC5uZXQiPm1ub3RAbW5vdC5uZXQ8L2E+ Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0 Zi5vcmc8L2E+Jmd0OzsgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2 ZXF1ZWZvdS5iZSI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OzsNCiBMYXJzIEVnZ2VydCAm bHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNAZWdnZXJ0Lm9yZyI+bGFyc0BlZ2dlcnQub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IENhbGwgZm9yIEFkb3B0aW9uOiBJbnZhcmlhbnRz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgZm9yIGFkb3B0aW9uLjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXMgSWFuIHBvaW50ZWQg b3V0LCBvbmNlIHB1Ymxpc2hlZCwgYW55IGNoYW5nZXMgdG8gdGhlIGludmFyaWFudHMgd2lsbCBi ZSBhIHNpZ25pZmljYW50IHVwaGlsbCB0YXNrIGZvciBhY3RpdmUgZGVwbG95bWVudHMuIFRoYXQn cyB0aGUgZW50aXJlIHBvaW50IG9mIGhhdmluZyB0aGVzZSBpbnZhcmlhbnRzLiBJIHdvdWxkIHZl cnkgbXVjaCBsaWtlIHRvIHB1Ymxpc2ggdGhlIGludmFyaWFudHMgYWhlYWQgb2YgdGhlDQogcmVz dCBvZiB0aGUgZG9jdW1lbnRzLCBzbyB0aGF0IGFjdGl2ZSBkZXBsb3ltZW50IG9mIElFVEYtUVVJ QyBjYW4gc3RhcnQsIGJ1dCB0aGF0J3MgYSBtYXR0ZXIgZm9yIGEgZGlmZmVyZW50IHRocmVhZCwg bm90IHRoaXMgb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIEZlYiA1LCAyMDE4IGF0IDExOjA1IEFNLCBNaWtrZWwgRmFobsO4 ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIiB0YXJn ZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPGRpdiBpZD0ibV8tODMxNTM5MDI5NDk3ODIxNDMxNnhfY29tcG9zZS1jb250 YWluZXIiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgY291 bGQgYmUgY2FsbGVkIFFVSUQgLi4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHls ZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJj ZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy04MzE1MzkwMjk0OTc4MjE0MzE2eF9kaXZScGx5 RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IE1pa2UgQmlzaG9w ICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5r Ij5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg RmVicnVhcnkgNSwgMjAxOCA4OjAwOjUzIFBNPGJyPg0KPGI+VG86PC9iPiBCcmlhbiBUcmFtbWVs bCAoSUVURik7IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48YnI+DQo8Yj5DYzo8L2I+IExhcnMg RWdnZXJ0OyBNYXJrIE5vdHRpbmdoYW07IFFVSUMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IENhbGwgZm9yIEFkb3B0aW9uOiBJbnZhcmlhbnRzPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBzdXBwb3J0IGFkb3B0aW9uLiZuYnNwOyBU aGUgd2F5IHRvIGNoYW5nZSB0aGUgaW52YXJpYW50cyB3aWxsIGJlIHRvIG1pbnQgYSBuZXcgcHJv dG9jb2wsIGFuZCBub3QgY2xhaW0gdGhhdCB5b3VyIG5ldyBwcm90b2NvbCBpcyBhIHZlcnNpb24g b2YgUVVJQy4mbmJzcDsgSWYgaXQgaGFwcGVucyB0byBiZSBzdGFydGxpbmdseSBzaW1pbGFyLCBh bGwgd2VsbCBhbmQgZ29vZC48YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCkZyb206IFFVSUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxm IE9mIEJyaWFuIFRyYW1tZWxsIChJRVRGKTxicj4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgNSwg MjAxOCAxMjozNCBBTTxicj4NClRvOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBo cmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpA Z21haWwuY29tPC9hPiZndDs8YnI+DQpDYzogTGFycyBFZ2dlcnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpsYXJzQGVnZ2VydC5vcmciIHRhcmdldD0iX2JsYW5rIj5sYXJzQGVnZ2VydC5vcmc8L2E+Jmd0 OzsgTWFyayBOb3R0aW5naGFtICZsdDs8YSBocmVmPSJtYWlsdG86bW5vdEBtbm90Lm5ldCIgdGFy Z2V0PSJfYmxhbmsiPm1ub3RAbW5vdC5uZXQ8L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZn dDs8YnI+DQpTdWJqZWN0OiBSZTogQ2FsbCBmb3IgQWRvcHRpb246IEludmFyaWFudHM8YnI+DQo8 YnI+DQpIaSwgYWxsLDxicj4NCjxicj4NCkkgc3VwcG9ydCBhZG9wdGlvbiBvZiB0aGUgaW52YXJp YW50cyBkcmFmdC48YnI+DQo8YnI+DQomZ3Q7IE9uIDUgRmViIDIwMTgsIGF0IDA4OjUxLCBNaWtr ZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwu Y29tIiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IE9ubHkgY29uY2VybiBpcyB3aGVuIGl0IHRha2VzIGVmZmVjdCBz aW5jZSBpdCBsaWtlbHkgbmVlZHMgYWRqdXN0bWVudHMuPGJyPg0KPGJyPg0KSSdkIHByZXN1bWUg dGhhdCBpbnZhcmlhbnRzIGlzIHB1Ymxpc2hlZCBzaW11bHRhbmVvdXNseSB3aXRoIHRoZSB2ZXJz aW9uIDEgc3BlYy48YnI+DQo8YnI+DQomZ3Q7IEFuZCBwZXJoYXBzIGEgcHJvY2VkdXJlIHRvIGhh bmRsZSBpbnZhcmlhbnQgY2hhbmdlcyBzaW5jZSBldmVyeXRoaW5nIGNoYW5nZXMuPGJyPg0KPGJy Pg0KTm90ZWQsIHRob3VnaCB0aGUgcG9pbnQgb2YgZGVjbGFyaW5nIHNvbWV0aGluZyBhbiBpbnZh cmlhbnQgaXMgdG8gc2F5ICZxdW90O3RoZSBtZWFuaW5nIG9mIHRoaXMgcGFydCBvZiB0aGUgd2ly ZSBpbWFnZSwgZXhwcmVzc2VkIGFzIGEgYml0IG9mZnNldCwgd2lsbCBuZXZlciBjaGFuZ2UmcXVv dDsuIFlvdSBjYW4gYWRkIGNvbnN0cmFpbnRzIHRvIHRoZSBpbnZhcmlhbnRzLCBidXQgaWYgeW91 IHRoaW5rIHlvdSBtaWdodCByZW1vdmUgYSBjb25zdHJhaW50LCB0aGVuDQogaXQncyBub3QgYW4g aW52YXJpYW50IGJ5IGRlZmluaXRpb24uPGJyPg0KPGJyPg0KQ2hlZXJzLDxicj4NCjxicj4NCkJy aWFuPGJyPg0KPGJyPg0KJmd0OyBGcm9tOiBRVUlDICZsdDs8YSBocmVmPSJtYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9h PiZndDsgb24gYmVoYWxmIG9mIE1hcmsgTm90dGluZ2hhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1u b3RAbW5vdC5uZXQiIHRhcmdldD0iX2JsYW5rIj5tbm90QG1ub3QubmV0PC9hPiZndDs8YnI+DQom Z3Q7IFNlbnQ6IE1vbmRheSwgRmVicnVhcnkgNSwgMjAxOCA3OjA3OjQ1IEFNPGJyPg0KJmd0OyBU bzogUVVJQyBXRzxicj4NCiZndDsgQ2M6IExhcnMgRWdnZXJ0PGJyPg0KJmd0OyBTdWJqZWN0OiBD YWxsIGZvciBBZG9wdGlvbjogSW52YXJpYW50czxicj4NCiZndDsgPGJyPg0KJmd0OyBBdCB0aGUg TWVsYm91cm5lIG1lZXRpbmcsIHRoZXJlIHdhcyBzdHJvbmcgc3VwcG9ydCBmb3IgYWRvcHRpbmcg TWFydGluJ3MgaW52YXJpYW50cyBkcmFmdDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGEgaHJlZj0i aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ1cmxkZWZlbnNlLnByb29mcG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMt M0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkR0aG9tc29uLTJEcXVpYy0yRGludmFyaWFu dHMtMkQwMCUyNmQlM0REd01GYVElMjZjJTNEOTZaYlpaY2FNRjR3MEY0anBONkxaZyUyNnIlM0RE am4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJTI2bSUzREtYN3pfNzRf U21mQ05DQ2Z3YnZHVXJqMTRha2huWVdGYV9qWVVzSjliNHMlMjZzJTNEYndOS25iRTBkNW5nTm5F TFZFYTYtUkFwWHhPc0EzcjlaWko5T0Y0NDhsayUyNmUlM0QmYW1wO2RhdGE9MDIlN0MwMSU3Q3By YXZiJTQwbWljcm9zb2Z0LmNvbSU3Q2U5NmY2ZWQ1Y2NmODQ0MTI1NWY4MDhkNTZjZDk2MWI4JTdD ZWUzMzAzZDdmYjczNGIwYzg1ODliY2Q4NDdmMWMyNzclN0MxJTdDMCU3QzYzNjUzNDYwMzI3MDAy MDc2MSZhbXA7c2RhdGE9dTN1ZCUyQlBMZk5NWVFBaDNiYjJhQVdLRmJEQlFsWXVYOXhGRHdJR0pI dGF3JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtdGhvbXNvbi1xdWljLWludmFyaWFudHMtMDA8L2E+PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEFueSBvYmplY3Rpb25zIC8gY29uY2VybnMgYWJvdXQgZG9pbmcgc28/IFVu bGVzcyB3ZSBoZWFyIG90aGVyd2lzZSwgd2UnbGwgYWRvcHQgYXQgdGhlIGVuZCBvZiB0aGUgd2Vl ay48YnI+DQomZ3Q7IDxicj4NCiZndDsgQ2hlZXJzLDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLTxi cj4NCiZndDsgTWFyayBOb3R0aW5naGFtJm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX193d3cubW5v dC5uZXRfJTI2ZCUzRER3TUZhUSUyNmMlM0Q5NlpiWlpjYU1GNHcwRjRqcE42TFpnJTI2ciUzRERq bjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8lMjZtJTNES1g3el83NF9T bWZDTkNDZndidkdVcmoxNGFraG5ZV0ZhX2pZVXNKOWI0cyUyNnMlM0RXYWJCMWRRY281MmRXa2hK ZzJkaXh1OW5TYWhyXzdCSkNocGhEZ0hGLUNzJTI2ZSUzRCZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJh dmIlNDBtaWNyb3NvZnQuY29tJTdDZTk2ZjZlZDVjY2Y4NDQxMjU1ZjgwOGQ1NmNkOTYxYjglN0Nl ZTMzMDNkN2ZiNzM0YjBjODU4OWJjZDg0N2YxYzI3NyU3QzElN0MwJTdDNjM2NTM0NjAzMjcwMDIw NzYxJmFtcDtzZGF0YT1hdExDWndQamljYXclMkJ1SGZlSmc1ZmFjWVBMQVc3aks3Y1lXc2JSSWhS YTAlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3Lm1ub3Qu bmV0LzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB013319562763F0DADC138466B6FE0CY4PR21MB0133namp_-- From nobody Mon Feb 5 13:55:14 2018 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 70FA712DA08 for ; Mon, 5 Feb 2018 13:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.33 X-Spam-Level: X-Spam-Status: No, score=-4.33 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 wH1YDaj1TokQ for ; Mon, 5 Feb 2018 13:55:11 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 47B4E127011 for ; Mon, 5 Feb 2018 13:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1517867710; x=2381781310; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OMB+VkgLdg9nu+g7OKh30JPnb9G0woc+2/bsIcL6Mx0=; b=alOpke6G67mfrUwXTcIwozIiQnXlwGRMwSL3/XNbcDJpMCnmb55Y6SDkniNtg6k+ Zag6Ol4KGgRLvf6JuI9OyUIGwiBy4Pd0Tc0b8pW+h2deL09BXGtwBFcrnQ16FGqT oPzKMxISVJrCqKWEXnbAesF6SIFk4y1McWAAwo7CiuLSsFRdRm+Y7/voZuIRZtl+ +Hh0m7LG5EAcTANrzUtMKmxp3yr/jjmtHDxBgicPQkyKUyNWz2b1VsgusV0SZYhk q5jR/SLC9Otktcx6lZpAH4VzeLx2a1lROz+xWrtsFHrOp+Xf6HDx38MQXsu3tZWJ FnUSzlyTeCT1J46zblERjQ==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 5E.84.12202.EB2D87A5; Mon, 5 Feb 2018 13:55:10 -0800 (PST) X-AuditID: 11973e11-f8a419e000002faa-d1-5a78d2be8083 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay2.apple.com (Apple SCV relay) with SMTP id 84.C2.26650.EB2D87A5; Mon, 5 Feb 2018 13:55:10 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_YJz5s3FuiJsEx+bHtaqVMQ)" Received: from ekinnear.apple.com ([17.226.40.239]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180122 64bit (built Jan 22 2018)) with ESMTPSA id <0P3P00FFJ67YTLJ1@nwk-mmpp-sz12.apple.com>; Mon, 05 Feb 2018 13:55:10 -0800 (PST) Sender: ekinnear@apple.com From: Eric Kinnear Message-id: Subject: Re: Call for Adoption: QCRAM Date: Mon, 05 Feb 2018 13:55:10 -0800 In-reply-to: Cc: Roberto Peon , Lars Eggert , Mark Nottingham , QUIC WG , Mike Bishop To: Jana Iyengar References: <6A834DB6-F2A5-4973-83CD-8AAA82945372@mnot.net> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUi2FDorLvvUkWUwc6p5hZTZvawWkw6upDF 4vWRbnaLX8+72C3Wf3rMaNGzgNuBzWNy22lWj/PHN7B6TGx+x+6xYFOpx5IlP5k8Ni7+zhrA FsVlk5Kak1mWWqRvl8CVseLVepaCVsuKqa9fsTUwvjDqYuTkkBAwkThyt4e1i5GLQ0hgNZPE /3+7mWASVz+cZ4ZIHGKUuPBzDyNIgldAUOLH5HssIDazQJjEhCXvGCGKupgkXv1vYAdJCAtI SZzeeAFsEpuAusSfh2vZIZptJGauu8MCUaMq8enmSWYQmwXI/nukH6yeUyBY4kX7R3aQocwC CxglvrX8B2sQEVCUePrzK9ggIYFWJolV+4sgTlWSmP79NhtIg4TAKnaJ6e+Osk1gFJqF5NpZ SK6FsLUkvj9qBYpzANnyEgfPy0KENSWe3fvEDmFrSzx5d4F1ASPbKkah3MTMHN3MPCO9xIKC nFS95PzcTYyg2JpuJ7iD8fgqq0OMAhyMSjy8AhkVUUKsiWXFlbmHGKU5WJTEeZVLSqOEBNIT S1KzU1MLUovii0pzUosPMTJxcEo1MF5599v0RG/lp5tRcqtbmx9zWHWdZTy9c/7t2ylrvYz2 Gb8O4L10R+3HbBVNnld9+85zOTgzZfIt4r6k4inKLy37h9X/06lS52THe/K65oszV7otat5x dp6y6z0v6+0PGs+ft3NiNp/SOPMvp/3ySwXvH1oHSGk0H2+dqzrZ5v6JC/9Ul1+u+aPEUpyR aKjFXFScCAAzCVdHjgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGIsWRmVeSWpSXmKPExsUi2FB8RnffpYoogzcvjC2mzOxhtZh0dCGL xesj3ewWv553sVus//SY0aJnAbcDm8fkttOsHuePb2D1mNj8jt1jwaZSjyVLfjJ5bFz8nTWA LcrQJi2/qDyxKEWhKLmgxFapOCMxJb883tLYyNQhsaAgJ1UvOT9XSd/OJiU1J7MstUjfLsEw Y8Wr9SwFrZYVU1+/YmtgfGHUxcjJISFgInH1w3nmLkYuDiGBQ4wSF37uYQRJ8AoISvyYfI8F xGYWCJOYsOQdI0RRF5PEq/8N7CAJYQEpidMbLzCB2GwC6hJ/Hq5lh2i2kZi57g4LRI2qxKeb J5lBbBYg+++RfrB6ToFgiRftH9lBhjILLGCU+NbyH6xBREBR4unPr2CDhARamSRW7S+COFVJ Yvr322wTGPlnITlwFpIDIWwtie+PWoHiHEC2vMTB87IQYU2JZ/c+sUPY2hJP3l1gXcDItopR oCg1J7HSSA8ebJsYwZFV6LyD8dgyq0OMAhyMSjy8ghkVUUKsiWXFlbnAUOJgVhLhdbpeHiXE m5JYWZValB9fVJqTWnyI0QfoyYnMUqLJ+cCozyuJNzS2MLY0sTAwMLE0M8EhrCTOe0SpKEpI ID2xJDU7NbUgtQhmHBMHp1QDY+2G3fKrVk72/9ARumrqvLV67B5ZRTc6G8z6LdrmBS/4LSv8 sss7fddqXSGLGbPMqjIj9ix7EbFhju7nhOmi0zYwvQx7WNA0xc8nkelfoFDY53chbNp/rayr z01Ztdt+q/3S+NJJ6cn/sv+qODH0PSjWT7GXEnwwS2itt+Q/S0tBa95MhgVflViACcxQi7mo OBEAfmYdi9kCAAA= 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, 05 Feb 2018 21:55:13 -0000 --Boundary_(ID_YJz5s3FuiJsEx+bHtaqVMQ) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT +1 for adoption, I think this is a good starting point for folding in pieces of the other proposals. Thanks, Eric > On Feb 5, 2018, at 12:01 PM, Jana Iyengar wrote: > > +1 for adoption. > > On Mon, Feb 5, 2018 at 11:05 AM, Roberto Peon > wrote: > Agreed. > Supported. > -=R > > On 2/5/18, 11:04 AM, "QUIC on behalf of Mike Bishop" on behalf of mbishop@evequefou.be > wrote: > > I support adoption -- it's a useful starting point from which we can discuss what elements of other proposals are worth lifting into this model. > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org ] On Behalf Of Mark Nottingham > Sent: Sunday, February 4, 2018 10:08 PM > To: QUIC WG > > Cc: Lars Eggert > > Subject: Call for Adoption: QCRAM > > In Melbourne, there was strong support (with a small amount of pushback which was discussed) for adopting QCRAM: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dkrasic-2Dquic-2Dqcram-2D04&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=9CL2DzRCrvpWRESeqQzeBJWmA5Csgju_t_mAM9Tkrv8&s=YUt-etfRURzJAU3Kk3Mh-63Xsk6Eqt6jt3_NmshNro0&e= > > Any objections / concerns about doing so? Unless we hear otherwise, we'll adopt at the end of the week. > > Cheers, > > -- > Mark Nottingham https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mnot.net_&d=DwIFAg&c=5VD0RTtNlTh3ycd41b3MUw&r=C0sUo-LFNBaYfyoaCsf6TA&m=9CL2DzRCrvpWRESeqQzeBJWmA5Csgju_t_mAM9Tkrv8&s=9sx1bBh6dd4D4LmaSoWRjQ6mlZzlU_NePbl0kmvnXHE&e= > > > > --Boundary_(ID_YJz5s3FuiJsEx+bHtaqVMQ) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable +1 = for adoption, I think this is a good starting point for folding in = pieces of the other proposals. 

Thanks,
Eric


On Feb 5, 2018, at 12:01 PM, Jana Iyengar <jri@google.com> = wrote:

+1 for adoption.

On Mon, = Feb 5, 2018 at 11:05 AM, Roberto Peon <fenix@fb.com> wrote:
Agreed.
Supported.
-=3DR

On 2/5/18, 11:04 AM, "QUIC on behalf of Mike Bishop" <quic-bounces@ietf.org= on behalf of mbishop@evequefou.be> wrote:

    I support adoption -- it's a useful starting point from = which we can discuss what elements of other proposals are worth lifting = into this model.

    -----Original Message-----
    From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham
    Sent: Sunday, February 4, 2018 10:08 PM
    To: QUIC WG <quic@ietf.org>
    Cc: Lars Eggert <lars@eggert.org>
    Subject: Call for Adoption: QCRAM

    In Melbourne, there was strong support (with a small = amount of pushback which was discussed) for adopting QCRAM:
=
    https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_draft-2Dkrasic-2Dquic-2Dqcram-2D04&d=3DDwIFAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA&m=3D9CL2DzRCrvpWRESeqQzeBJWmA5Csgju_t_mAM9Tkrv8&s=3DYUt-etfRURzJAU3Kk3Mh-63Xsk6Eqt6jt3_NmshNro0&e=3D

    Any objections / concerns about doing so? Unless we hear = otherwise, we'll adopt at the end of the week.

    Cheers,

    --
    Mark Nottingham   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.mnot.net_&d=3DDwIFAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3DC0sUo-LFNBaYfyoaCsf6TA&m=3D9CL2DzRCrvpWRESeqQzeBJWmA5Csgju_t_mAM9Tkrv8&s=3D9sx1bBh6dd4D4LmaSoWRjQ6mlZzlU_NePbl0kmvnXHE&e=3D





= --Boundary_(ID_YJz5s3FuiJsEx+bHtaqVMQ)-- From nobody Mon Feb 5 15:04:30 2018 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 1ABBC124BAC for ; Mon, 5 Feb 2018 15:04:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 9dn2Y-FWqijD for ; Mon, 5 Feb 2018 15:04:26 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (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 654B112025C for ; Mon, 5 Feb 2018 15:04:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1517871866; x=2381785466; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=RoQ+5fk/apblGjhJHOgJyBJaT8qp3Wf1cnU4ac9mytc=; b=rSS3LF9+RVThikB9B08WCXcc8BSFyQrl1ga5S8Dn2YZXaysLee5s4Zs/58tljENM UYfu3NxVmV3Nmj7Yo5ZkGj1xfDZpxNJwaVH/7SmHu3LicHefLw6gy3+M3gCRFNMf ILqRzNEs1Fm42bogz2bWDdS7QFndeMJjxpIskEVxVRSE7T12JVle0xGslWjIJelC PKVvxoHZKLnSfXV9t788n55pv64k90CaGYYJMN+JXZUFvsoh516dTJJG0KvO2MDw nZDnGjYWVJaY4wRB5Wad0/lW1nw+GuShikirY2Re9uWvxvkudQoY3UH7CMdxOSN8 gLSFu0vxmQpyzKHpS3HDrw==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id FB.AD.10621.AF2E87A5; Mon, 5 Feb 2018 15:04:26 -0800 (PST) X-AuditID: 11973e12-77bff7000000297d-a0-5a78e2fa0d15 Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by relay4.apple.com (Apple SCV relay) with SMTP id 6D.71.11536.9F2E87A5; Mon, 5 Feb 2018 15:04:25 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_r85CZaHkWwlmJryzE1593w)" Received: from ekinnear.apple.com ([17.226.40.239]) by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180122 64bit (built Jan 22 2018)) with ESMTPSA id <0P3P008FK9FDHVB0@nwk-mmpp-sz12.apple.com>; Mon, 05 Feb 2018 15:04:25 -0800 (PST) Sender: ekinnear@apple.com From: Eric Kinnear Message-id: <3954C408-BAC6-4534-B417-39399C5A3C30@apple.com> Subject: Re: Call for Adoption: Invariants Date: Mon, 05 Feb 2018 15:04:25 -0800 In-reply-to: Cc: "Lubashev, Igor" , Jana Iyengar , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "Brian Trammell (IETF)" , Mark Nottingham , QUIC WG , Mike Bishop , Lars Eggert To: Praveen Balasubramanian References: <869dbe08975540c98d0984c01f5942dc@usma1ex-dag1mb5.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3445.5.20) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUi2FAYrvvrUUWUwcLHLBYbW96xWTQ1rGC2 mHR0IYvF6yPd7Ba/nnexWyz+vo/ZYv2nx4wWr3uARM8CbgdOj8lHFjB7TG47zepx/vgGVo+d s+6yeyzYVOqxZMlPJo/WHX/ZPTYu/s7q8WT/TJYAzigum5TUnMyy1CJ9uwSujEn9f9gK1i5l rNjxZCdLA2PbZMYuRk4OCQETiSvfprF0MXJxCAmsZpK4eG4jO0zi7pQp7BCJQ4wS9x4sYwZJ 8AoISvyYfA+og4ODWSBMYsYBF4iaLiaJrjknwaYKC0hJnN54gQnEZhNQl/jzcC07RK+NxJyH vSwQNVoS33ousYHYLAKqEgeuPgGr4RSIl3j9cjLYRcwC+5gkpl3eCVYkImAocWX3TDaIbWdY JE4d6GCFOFVJYvr322AJCYFz7BJLzq9lmsAoNAvJtbMQroUw1SWmTMkFqWAW0JZ48u4CK4St JrHw9yImZPEFjGyrGIVyEzNzdDPzTPQSCwpyUvWS83M3MYIic7qd0A7GU6usDjEKcDAq8fAK ZFRECbEmlhVX5h5ilOZgURLnPfEQKCSQnliSmp2aWpBaFF9UmpNafIiRiYNTqoFx5WcBprV+ fJJ9Rq3PBV3Clcxn3+67e0R2/Y0/67vkXOWXiKu87b6e+3rd9voVf1fcuq9kzinMqBVrZXxy Rrju+RtH3zqutvhQGjnjaeHPvhl/Jp8zY9unnnxMOOHzuhKeQlaGL05dW9Sqv4oFFdR/XV9a 0ewRESrcyGaXxqGi+nSR6m2lFWeVWIozEg21mIuKEwEV1Hu2rQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUi2FB8Rvfno4oogzsfrCw2trxjs2hqWMFs MenoQhaL10e62S1+Pe9it1j8fR+zxfpPjxktXvcAiZ4F3A6cHpOPLGD2mNx2mtXj/PENrB47 Z91l91iwqdRjyZKfTB6tO/6ye2xc/J3V48n+mSwBnFGGNmn5ReWJRSkKRckFJbZKxRmJKfnl 8ZbGRqYOiQUFOal6yfm5Svp2NimpOZllqUX6dgmGGZP6/7AVrF3KWLHjyU6WBsa2yYxdjJwc EgImEnenTGHvYuTiEBI4xChx78EyZpAEr4CgxI/J91i6GDk4mAXCJGYccIGo6WKS6JpzEqxZ WEBK4vTGC0wgNpuAusSfh2vZIXptJOY87GWBqNGS+NZziQ3EZhFQlThw9QlYDadAvMTrl5NZ QIYyC+xjkph2eSdYkYiAocSV3TPZILadYZE4daCDFeJUJYnp32+zTWDkn4XkwFkIB0KY6hJT puSCVDALaEs8eXeBFcJWk1j4exETsvgCRrZVjAJFqTmJlSZ68HDbxAiOy8LwHYz/llkdYhTg YFTi4RXIqIgSYk0sK67MBQYSB7OSCK/T9fIoId6UxMqq1KL8+KLSnNTiQ4w+QE9OZJYSTc4H poy8knhDYwtjSxMLAwMTSzMTHMJK4rxHlIqihATSE0tSs1NTC1KLYMYxcXBKNTDK3jp52eGS zcWeamPj/3fnqHEf9kxfXZGVvFfRpfP1jptG0dPLNMs5QpZsyGW99FeL9/Gl3m6VPW35elxS 3dM1T2/l6ChriSwKuph1wCjv20kmn9BGfua1V7Lk5U5650SylKe9vrbXaU/B4hpnt+kr8jXD PG++O2F7ZpVYrsjxDfOzo5ed/q7EAkxhhlrMRcWJAPDB9er4AgAA 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, 05 Feb 2018 23:04:29 -0000 --Boundary_(ID_r85CZaHkWwlmJryzE1593w) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable +1 for adoption.=20 Thanks, Eric > On Feb 5, 2018, at 1:05 PM, Praveen Balasubramanian = wrote: >=20 > +1 for adoption > =20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Lubashev, Igor > Sent: Monday, February 5, 2018 12:45 PM > To: Jana Iyengar ; Mikkel Fahn=C3=B8e J=C3=B8rgensen = > Cc: Brian Trammell (IETF) ; Mark Nottingham = ; QUIC WG ; Mike Bishop = ; Lars Eggert > Subject: RE: Call for Adoption: Invariants > =20 > +1 for the adoption. > =20 > The adoption does not mean that the draft will be published exactly = like it is right now. But, as Jana said, I really hope we can settle = this one before we settle v1 drafts. > =20 > From: Jana Iyengar [mailto:jri@google.com ]=20 > Sent: Monday, February 05, 2018 3:16 PM > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen > > Cc: Brian Trammell (IETF) >; Mark Nottingham >; QUIC WG >; = Mike Bishop >; Lars = Eggert > > Subject: Re: Call for Adoption: Invariants > =20 > +1 for adoption. > =20 > As Ian pointed out, once published, any changes to the invariants will = be a significant uphill task for active deployments. That's the entire = point of having these invariants. I would very much like to publish the = invariants ahead of the rest of the documents, so that active deployment = of IETF-QUIC can start, but that's a matter for a different thread, not = this one. > =20 > On Mon, Feb 5, 2018 at 11:05 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen = > wrote: > It could be called QUID ... > =20 > From: Mike Bishop > > Sent: Monday, February 5, 2018 8:00:53 PM > To: Brian Trammell (IETF); Mikkel Fahn=C3=B8e J=C3=B8rgensen > Cc: Lars Eggert; Mark Nottingham; QUIC WG > Subject: RE: Call for Adoption: Invariants > =20 > I support adoption. The way to change the invariants will be to mint = a new protocol, and not claim that your new protocol is a version of = QUIC. If it happens to be startlingly similar, all well and good. >=20 > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org = ] On Behalf Of Brian Trammell (IETF) > Sent: Monday, February 5, 2018 12:34 AM > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen > > Cc: Lars Eggert >; Mark = Nottingham >; QUIC WG = > > Subject: Re: Call for Adoption: Invariants >=20 > Hi, all, >=20 > I support adoption of the invariants draft. >=20 > > On 5 Feb 2018, at 08:51, Mikkel Fahn=C3=B8e J=C3=B8rgensen = > wrote: > >=20 > > Only concern is when it takes effect since it likely needs = adjustments. >=20 > I'd presume that invariants is published simultaneously with the = version 1 spec. >=20 > > And perhaps a procedure to handle invariant changes since everything = changes. >=20 > Noted, though the point of declaring something an invariant is to say = "the meaning of this part of the wire image, expressed as a bit offset, = will never change". You can add constraints to the invariants, but if = you think you might remove a constraint, then it's not an invariant by = definition. >=20 > Cheers, >=20 > Brian >=20 > > From: QUIC > on = behalf of Mark Nottingham > > > Sent: Monday, February 5, 2018 7:07:45 AM > > To: QUIC WG > > Cc: Lars Eggert > > Subject: Call for Adoption: Invariants > >=20 > > At the Melbourne meeting, there was strong support for adopting = Martin's invariants draft: > >=20 > > https://tools.ietf.org/html/draft-thomson-quic-invariants-00 = > >=20 > > Any objections / concerns about doing so? Unless we hear otherwise, = we'll adopt at the end of the week. > >=20 > > Cheers, > >=20 > > -- > > Mark Nottingham https://www.mnot.net/ = --Boundary_(ID_r85CZaHkWwlmJryzE1593w) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable +1 = for adoption. 

Thanks,
Eric


On Feb 5, 2018, at 1:05 PM, Praveen Balasubramanian <pravb@microsoft.com>= wrote:

+1 for adoption
 
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Lubashev, = Igor
Sent: Monday, February 5, 2018 = 12:45 PM
To: Jana Iyengar <jri@google.com>; Mikkel = Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: Brian= Trammell (IETF) <ietf@trammell.ch>; Mark Nottingham <mnot@mnot.net>; QUIC WG = <quic@ietf.org>; = Mike Bishop <mbishop@evequefou.be>; Lars Eggert <lars@eggert.org>
Subject: RE: Call for Adoption: = Invariants
 
+1 for the adoption.
 
The adoption does not mean that the = draft will be published exactly like it is right now.  But, as Jana = said, I really hope we can settle this one before we settle v1 = drafts.
 
From: Jana Iyengar [mailto:jri@google.com] 
Sent: Monday, February 05, 2018 = 3:16 PM
To: Mikkel Fahn=C3=B8e = J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: Brian= Trammell (IETF) <ietf@trammell.ch>; = Mark Nottingham <mnot@mnot.net>; = QUIC WG <quic@ietf.org>; Mike = Bishop <mbishop@evequefou.be>; Lars Eggert <lars@eggert.org>
Subject: Re: Call for Adoption: = Invariants
 
+1 for adoption.
 
As Ian pointed out, once published, any = changes to the invariants will be a significant uphill task for active = deployments. That's the entire point of having these invariants. I would = very much like to publish the invariants ahead of the rest of the = documents, so that active deployment of IETF-QUIC can start, but that's = a matter for a different thread, not this one.
 
On Mon, Feb 5, 2018 at 11:05 AM, Mikkel = Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
It could be called QUID ...
 
From: Mike Bishop <mbishop@evequefou.be>
Sent: Monday, February 5, 2018 = 8:00:53 PM
To: Brian Trammell (IETF); = Mikkel Fahn=C3=B8e J=C3=B8rgensen
Cc: Lars Eggert; Mark = Nottingham; QUIC WG
Subject: RE: Call for Adoption: = Invariants
 

I support = adoption.  The way to change the invariants will be to mint a new = protocol, and not claim that your new protocol is a version of = QUIC.  If it happens to be startlingly similar, all well and = good.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell = (IETF)
Sent: Monday, February 5, 2018 12:34 AM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: Lars Eggert = <lars@eggert.org>; = Mark Nottingham <mnot@mnot.net>; QUIC WG <quic@ietf.org>
Subject: Re: Call for Adoption: Invariants

Hi, all,

I support adoption of = the invariants draft.

> On 5 Feb 2018, = at 08:51, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>= wrote:
> 
> Only = concern is when it takes effect since it likely needs adjustments.

I'd presume that invariants is published = simultaneously with the version 1 spec.

> = And perhaps a procedure to handle invariant changes since everything = changes.

Noted, though the point of = declaring something an invariant is to say "the meaning of this part of = the wire image, expressed as a bit offset, will never change". You can = add constraints to the invariants, but if you think you might remove a = constraint, then it's not an invariant by definition.

Cheers,

Brian

> From: QUIC <quic-bounces@ietf.org> on behalf of Mark Nottingham = <mnot@mnot.net>
> Sent: Monday, February 5, 2018 7:07:45 AM
> To: QUIC WG
> Cc: Lars Eggert
> Subject: Call for Adoption: Invariants
> 
> At the Melbourne meeting, there was strong support for = adopting Martin's invariants draft:
> 
> https://tools.ietf.org/html/draft-thomson-quic-invariants-00
> > Any objections / concerns about doing so? Unless we = hear otherwise, we'll adopt at the end of the week.
> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/


= --Boundary_(ID_r85CZaHkWwlmJryzE1593w)-- From nobody Mon Feb 5 15:32:34 2018 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 8E92A124E15 for ; Mon, 5 Feb 2018 15:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 PZIdjk9Fi37r for ; Mon, 5 Feb 2018 15:32:30 -0800 (PST) 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 E2DE8120721 for ; Mon, 5 Feb 2018 15:32:29 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id j128so45210ywg.7 for ; Mon, 05 Feb 2018 15:32:29 -0800 (PST) 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=mRBYje+CSvdpQ/qWA0RgG7HurCno/YkalYKq7fiIpRc=; b=QG3PMJrFb+XBXHQybDfqcRkIDUzbpdTbXRO6/YXZaEI3PGE3DI5rJxO7+1N9VgsvQp 9LPjWCPmOswO2HNfV3Lau/foc+UDtwghdNtep2b1n/JivviVFCMIexQf1z+LcztFX9i4 pR6seAd0C1VQ2kClTGObYoEzzqecDVs4eWQPTXC/e8cf5OrH2Eqm6VZa6NZCMC6N9G7z PbC16VkoSGjn4qye5R9LSE05fziLAmGoN2jj3rgGmoVmNX1NlFQHNH1HP7j76Whzxl4O vSqke06sU2uBryA8myrKHMYsdYhdLX9W//2CmxvKnf7V0HmSIUOmpqddlvKl8q02vz8F 0gCA== 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=mRBYje+CSvdpQ/qWA0RgG7HurCno/YkalYKq7fiIpRc=; b=epFo1m6cQ/6DsOruTbInbS4FpRVkmd4vVsIrVE1dv6gojy2cxtePapAhV9X/EBn5Yc mku3u2hbxEJ/pFyttVpfutoRriJcF8ecdWxT3vYSP01IfmMXy8kxDkJWOLzvpCQe72pa JlIlfBIIwyCFBGnLTVYQavI8ba6Ivgv+bRjNv4lF0/rJx0K3qR7UO9X78u5a3feQPL/4 ko8FQOQ8Bk/LVZ1wE3caST/0tqBEEErYZ/nhh3PUbEzPKPmSO/KRPmJzjYeZoZgtEMYd fk3A0s4saWrSpqFpiaN0CYh/+uiMbvWqAL0LL1LregS4h7ohMTua7u3fAHMU0jRar3k9 tPWw== X-Gm-Message-State: APf1xPDhczxQVIsg16g0p4CHIcWV04EQbmPsXAvydQ6AAZcq0x8DXsL4 ckRSvu2z/QosNK0cBtqP+wj7jA3Ks8sMwMY6mNyxAw== X-Google-Smtp-Source: AH8x2258OfNhSyxgpqD26ETQpJHkKAnN51eO5OXWgfjgWgVdJHA4UE4yjtOgZuNIfxETuOXzKUKvcKxYP86Tm81uzhI= X-Received: by 10.129.131.139 with SMTP id t133mr302795ywf.59.1517873548089; Mon, 05 Feb 2018 15:32:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Mon, 5 Feb 2018 15:32:27 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> From: Jana Iyengar Date: Mon, 5 Feb 2018 15:32:27 -0800 Message-ID: Subject: Re: Packet number encryption To: Praveen Balasubramanian Cc: "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , QUIC WG Content-Type: multipart/alternative; boundary="001a114ecd54a6a64405647f7904" 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, 05 Feb 2018 23:32:32 -0000 --001a114ecd54a6a64405647f7904 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Praveen, That was precisely my point about the ecosystem evolving. Now that we have the ability to classify flows, various things have been built around being able to tell TCP flows. This obviously has benefits as you point out, but the downside is that that I can't get good network utilization with a single flow. I understand the scaling point, but speaking of common cases, any server in the wild is usually serving a large number of connections at moderate speeds, not a single one at 25-35 Gbps... which makes that sort of scaling less exciting than in a microbenchmark. FWIW, the other downside of ECMP is that multipath transport doesn't work -- you need to hash on something else besides the 4-tuple. (We had to work around this in Google's deployment of connection migration.) I'll disagree with your point about reordering being the uncommon case. While that's true today, this is again an expectation that the network works hard to maintain, though the ecosystem and what we expect as "usual" would be quite different had we not built TCP's requirements into the network. There's nothing wrong with having n-modal latencies... we can engineer around that. Any sensible load distribution scheme within the network will give you increased variance but it should limit the worst-case latency. You'd perhaps agree that that's a net win. This was an example of how exposing packet number or not can have long term ecosystem effects. My point was about the fact that exposing can cause ossification. - jana On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian wrote: > >> This was definitely true for implementations of TCP, but that is TCP's > problem, not the network's > > Flow classification happens through the network and also on the end host > with RSS where a flow is mapped to a core. This allows for building high > performance receive processing that could be lock free for the most part. > The only downside of ECMP on the network and RSS on the CPU is that a > single flow will not take multiple paths or get processed on more than on= e > core. Windows on server machines today can saturate 25-35 Gbps for a sing= le > TCP connection before being CPU limited. This is a reasonable trade off > because I don=E2=80=99t know of cases where a single flow is driving more= than that > amount of traffic. Assumptions about how flows get classified help make f= or > more efficient processing. They also lead to consistent latency. You do n= ot > want the traffic to take a bi-modal or N-modal paths (on the network or t= he > host) to being processed because the fluctuations in latency will hurt th= e > workload. I am not arguing for TCP not being resilient to reordering but > IMO that should be the uncommon case not the common case. With QUIC if > streams were exposed on the network you could take advantage of stream > level ECMP and RSS to scale better than TCP but we have chosen to keep th= e > 4-tuple (or the 5-tuple) as the flow classifier on the network which is o= k > by me since it leads to TCP parity. > > > > Thanks > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar > *Sent:* Sunday, February 4, 2018 8:35 PM > *To:* Salz, Rich > *Cc:* Lubashev, Igor ; Roberto Peon ; > QUIC WG > *Subject:* Re: Packet number encryption > > > > Privacy-protection can't be a user choice, for the reasons others have > noted on this thread. > > > That said, my primary argument is for encryption to avoid ossification. > Not that it matters now, but I'll note that much of GQUIC's original > motivation for encrypting headers was to avoid ossification. > > > > I'll reiterate that fields we expose will get ossified and there are > long-term ecosystem effects to this. Let me illustrate this with precisel= y > the packet number field. Middleboxes commonly assume that a TCP flow can > only handle packets in-order. This assumption comes from the fact that TC= P > implementations get poor performance when packets are reordered. This was > definitely true for implementations of TCP, but that is TCP's problem, no= t > the network's. However, almost all load-balancers I know of now will pin > all packets within a TCP flow to one path, leading to sub-optimal > performance in the network, and destroying incentives for the endpoints t= o > deploy reordering-resilient TCP implementations (even though there are > plenty of ways of doing this.) > > > > Exposing QUIC's packet number field (as any field) is likely to have > similar consequences and a similar ecosystem arc. > > > > > > On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: > > > Optional security tends to devolve to non-secure. > > > > That=E2=80=99s a great aphorism. And sadly all too true. > > > --001a114ecd54a6a64405647f7904 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Praveen,

That was precisely my poi= nt about the ecosystem evolving. Now that we have the ability to classify f= lows, various things have been built around being able to tell TCP flows. T= his obviously has benefits as you point out, but the downside is that that = I can't get good network utilization with a single flow. I understand t= he scaling point, but speaking of common cases, a= ny server in the wild is usually serving a large number of connections at m= oderate speeds, not a single one at 25-35 Gbps... which makes that sort of = scaling less exciting than in a microbenchmark.

FWIW, the other = downside of ECMP is that multipath transport doesn't work -- you need t= o hash on something else besides the 4-tuple. (We had to work around this i= n Google's deployment of connection migration.)

I'll disagree with your point about reordering bei= ng the uncommon case. While that's true today, this is again an expecta= tion that the network works hard to maintain, though the ecosystem and what= we expect as "usual" would be quite different had we not built T= CP's requirements into the network. There's nothing wrong with havi= ng n-modal latencies... we can engineer around that. Any sensible load dist= ribution scheme within the network will give you increased variance but it = should limit the worst-case latency. You'd perhaps agree that that'= s a net win.

This was an example of how exposi= ng packet number or not can have long term ecosystem effects. My point was = about the fact that exposing can cause ossification.

- jana

On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian <pravb@micro= soft.com> wrote:

>> This was definitely true for implementation= s of TCP, but that is TCP's problem, not the network's

Flow classification happens through the netwo= rk and also on the end host with RSS where a flow is mapped to a core. This= allows for building high performance receive processing that could be lock= free for the most part. The only downside of ECMP on the network and RSS on the CPU is that a single flow will not t= ake multiple paths or get processed on more than one core. Windows on serve= r machines today can saturate 25-35 Gbps for a single TCP connection before= being CPU limited. This is a =C2=A0reasonable trade off because I don=E2=80=99t know of cases where a single flow is dri= ving more than that amount of traffic. Assumptions about how flows get clas= sified help make for more efficient processing. They also lead to consisten= t latency. You do not want the traffic to take a bi-modal or N-modal paths (on the network or the host) to being pro= cessed because the fluctuations in latency will hurt the workload. I am not= arguing for TCP not being resilient to reordering but IMO that should be t= he uncommon case not the common case. With QUIC if streams were exposed on the network you could take adva= ntage of stream level ECMP and RSS to scale better than TCP but we have cho= sen to keep the 4-tuple (or the 5-tuple) as the flow classifier on the netw= ork which is ok by me since it leads to TCP parity.

=C2=A0

Thanks

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Sunday, February 4, 2018 8:35 PM
To: Salz, Rich <rsalz@akamai.com>
Cc: Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon <fenix@fb.com>; QUIC WG <quic@ietf.org>
Subject: Re: Packet number encryption

=C2=A0

Privacy-protection can't be a user choice, for t= he reasons others have noted on this thread.=C2=A0


That said, my primary argument is for encryption to avoid ossification. Not= that it matters now, but I'll note that much of GQUIC's original m= otivation for encrypting headers was to avoid ossification.

=C2=A0

I'll reiterate that fields we expose will get os= sified and there are long-term ecosystem effects to this. Let me illustrate= this with precisely the packet number field. Middleboxes commonly assume t= hat a TCP flow can only handle packets in-order. This assumption comes from the fact that TCP implementations get= poor performance when packets are reordered. This was definitely true for = implementations of TCP, but that is TCP's problem, not the network'= s. However, almost all load-balancers I know of now will pin all packets within a TCP flow to one path, leading to= sub-optimal performance in the network, and destroying incentives for the = endpoints to deploy reordering-resilient TCP implementations (even though t= here are plenty of ways of doing this.)

=C2=A0

Exposing QUIC's packet number field (as any fiel= d) is likely to have similar consequences and a similar ecosystem arc.

=C2=A0

=C2=A0

On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <rsalz@akamai.com> w= rote:

> Optional security tend= s to devolve to non-secure.

=C2=A0<= /u>

That=E2=80= =99s a great aphorism.=C2=A0 And sadly all too true.

=C2=A0


--001a114ecd54a6a64405647f7904-- From nobody Mon Feb 5 16:30:53 2018 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 9488C12D860 for ; Mon, 5 Feb 2018 16:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rIqNO6mGJeoi for ; Mon, 5 Feb 2018 16:30:47 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002: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 E9BE012DA15 for ; Mon, 5 Feb 2018 16:30:46 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id v139so130508ywg.4 for ; Mon, 05 Feb 2018 16:30:46 -0800 (PST) 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=YkCkZDBVJVntgtpG52Y9/JTz4kSHOcxrAfmpeVG5sqE=; b=uLTiRH06ma1r8iahDZSvU6bFhuttWDwa+sxMlSIwZaEHO5rmroDE0baEvYu3u8kQ2a m+Z6vl0mNTcESQlNFYGwA/fx9PWUxTsDEBSFPQbw7ge+V0h7pywVpoF34ZNKlOD+riJf 8Dngz6oWujn2gYn1C2nYP3jIFZ1Gue9WE3WUzWi+rMcD67CLiLRnBq/M9t5aTdvZv3ZZ DTrRBLaymD7/z39Wg3Cc7llh/5/L/WEaUql06PvcyQGHBLImdT0QoaJvH2eBqesgnAzS 0xtwBUY+4hE0N1Iz1Idi6tRiHah9Gs9ogKjUZcij7jLXh84KVuwDpWLHdwnsN36v3ArJ 0W6w== 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=YkCkZDBVJVntgtpG52Y9/JTz4kSHOcxrAfmpeVG5sqE=; b=Hl9lMmQWvGnp3ZkZd/DAaCf19aHOpNazNd95C6s1tylblXclH7a1Q+WHfb7z6s5qXb 6RSs4BEcq1FYIGxCYFlfSYnPPY+OF75iP7ZUmf22iSea/Wc4pp+gBs6PMwf0v9lZzQII 6jEpLkQo1P+AR0ntYs8v503pw1Lt3U5dZIaLuU1LiYXHafRmctJ5AgGMmBobkyqOT5r/ wFj5wWd/vRlcDNON9r55xiiL1DXnRQ1i3cgJBowVZ/kTxlcSPw9vYt2ymEf8Qa20Ja7X LrNd04jshEGDpDoW/YaBMV9zezLsd+5xAYUxm81LJo4pDhH499j5Eu1rfa3eoO341/GP wpjA== X-Gm-Message-State: APf1xPC8utShstO/FH/UshCntj7R905RfVRKcxHjmm5qUhvqdOZckhfe WlU6+Wbwzr1pWWJHNHMoyMAuwtP5aYD7jYUF9aZIbQ== X-Google-Smtp-Source: AH8x227dT0VAVCBLZWxtJqalXb62V4Ka00AX0sJvVcy7xazEvnMtwemiNBQM9aHHLTD6FVzufO+WxI1bryjeTHbUzIs= X-Received: by 10.37.132.78 with SMTP id r14mr422503ybm.366.1517877045458; Mon, 05 Feb 2018 16:30:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Mon, 5 Feb 2018 16:30:44 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> From: Jana Iyengar Date: Mon, 5 Feb 2018 16:30:44 -0800 Message-ID: Subject: Re: Packet number encryption To: Praveen Balasubramanian Cc: "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , QUIC WG Content-Type: multipart/alternative; boundary="089e0826ea901cbc9e0564804a52" 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, 06 Feb 2018 00:30:52 -0000 --089e0826ea901cbc9e0564804a52 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think we're converging here, so I'd like to try and encourage us to move towards it. I have my opinion, but I care more about forward progress at this point. There are three designs so far: 1. Packet numbers as is, with random gaps around migration. 2. Packet numbers encrypted, as per Martin's PR. 3. Packet numbers encrypted, plus a small modulo sequence number somewhere. The concrete ones here are (1) and (2). I'm listing (3) but am not inclined to consider it seriously, since it's not concrete enough, (and I don't want more bits to be spent in the QUIC packet header if that's where this info goes.) There are opinions about ossification, privacy, and manageability. I'm not hearing bloody murder, so for what it's worth, I'd like to stipulate first that we can all live with the final design, whichever one it is. If anyone disagrees, please say so -- I think it'd be useful to hear if there are folks who think a particular design is fundamentally problematic. My opinion is still for (2) over (1), but I can live with either. On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: > Praveen, > > That was precisely my point about the ecosystem evolving. Now that we hav= e > the ability to classify flows, various things have been built around bein= g > able to tell TCP flows. This obviously has benefits as you point out, but > the downside is that that I can't get good network utilization with a > single flow. I understand the scaling point, but speaking of common > cases, any server in the wild is usually serving a large number of > connections at moderate speeds, not a single one at 25-35 Gbps... which > makes that sort of scaling less exciting than in a microbenchmark. > > FWIW, the other downside of ECMP is that multipath transport doesn't work > -- you need to hash on something else besides the 4-tuple. (We had to wor= k > around this in Google's deployment of connection migration.) > > I'll disagree with your point about reordering being the uncommon case. > While that's true today, this is again an expectation that the network > works hard to maintain, though the ecosystem and what we expect as "usual= " > would be quite different had we not built TCP's requirements into the > network. There's nothing wrong with having n-modal latencies... we can > engineer around that. Any sensible load distribution scheme within the > network will give you increased variance but it should limit the worst-ca= se > latency. You'd perhaps agree that that's a net win. > > This was an example of how exposing packet number or not can have long > term ecosystem effects. My point was about the fact that exposing can cau= se > ossification. > > - jana > > On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > >> >> This was definitely true for implementations of TCP, but that is TCP'= s >> problem, not the network's >> >> Flow classification happens through the network and also on the end host >> with RSS where a flow is mapped to a core. This allows for building high >> performance receive processing that could be lock free for the most part= . >> The only downside of ECMP on the network and RSS on the CPU is that a >> single flow will not take multiple paths or get processed on more than o= ne >> core. Windows on server machines today can saturate 25-35 Gbps for a sin= gle >> TCP connection before being CPU limited. This is a reasonable trade off >> because I don=E2=80=99t know of cases where a single flow is driving mor= e than that >> amount of traffic. Assumptions about how flows get classified help make = for >> more efficient processing. They also lead to consistent latency. You do = not >> want the traffic to take a bi-modal or N-modal paths (on the network or = the >> host) to being processed because the fluctuations in latency will hurt t= he >> workload. I am not arguing for TCP not being resilient to reordering but >> IMO that should be the uncommon case not the common case. With QUIC if >> streams were exposed on the network you could take advantage of stream >> level ECMP and RSS to scale better than TCP but we have chosen to keep t= he >> 4-tuple (or the 5-tuple) as the flow classifier on the network which is = ok >> by me since it leads to TCP parity. >> >> >> >> Thanks >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar >> *Sent:* Sunday, February 4, 2018 8:35 PM >> *To:* Salz, Rich >> *Cc:* Lubashev, Igor ; Roberto Peon ; >> QUIC WG >> *Subject:* Re: Packet number encryption >> >> >> >> Privacy-protection can't be a user choice, for the reasons others have >> noted on this thread. >> >> >> That said, my primary argument is for encryption to avoid ossification. >> Not that it matters now, but I'll note that much of GQUIC's original >> motivation for encrypting headers was to avoid ossification. >> >> >> >> I'll reiterate that fields we expose will get ossified and there are >> long-term ecosystem effects to this. Let me illustrate this with precise= ly >> the packet number field. Middleboxes commonly assume that a TCP flow can >> only handle packets in-order. This assumption comes from the fact that T= CP >> implementations get poor performance when packets are reordered. This wa= s >> definitely true for implementations of TCP, but that is TCP's problem, n= ot >> the network's. However, almost all load-balancers I know of now will pin >> all packets within a TCP flow to one path, leading to sub-optimal >> performance in the network, and destroying incentives for the endpoints = to >> deploy reordering-resilient TCP implementations (even though there are >> plenty of ways of doing this.) >> >> >> >> Exposing QUIC's packet number field (as any field) is likely to have >> similar consequences and a similar ecosystem arc. >> >> >> >> >> >> On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: >> >> > Optional security tends to devolve to non-secure. >> >> >> >> That=E2=80=99s a great aphorism. And sadly all too true. >> >> >> > > --089e0826ea901cbc9e0564804a52 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think we're converging here, so I'd li= ke to try and encourage us to move towards it. I have my opinion, but I car= e more about forward progress at this point.

There are t= hree designs so far:
1. Packet numbers as is, with random gaps ar= ound migration.
2. Packet numbers encrypted, as per Martin's = PR.
3. Packet numbers encrypted, plus a small modulo sequence num= ber somewhere.

The concrete ones here are (1) and = (2).=C2=A0=C2=A0I'm listing (3) but am not in= clined to consider it seriously, since it's not concrete enough, (and I= don't want more bits to be spent in the QUIC packet header if that'= ;s where this info goes.)

There are opinions about ossificati= on, privacy, and manageability. I'm not hearing bloody murder, so for w= hat it's worth, I'd like to stipulate first that we can all live wi= th the final design, whichever one it is.=C2=A0 If anyone disagrees, please= say so -- I think it'd be useful to hear if there are folks who think = a particular design is fundamentally problematic.

= My opinion is still for (2) over (1), but I can l= ive with either.

On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar <jri@googl= e.com> wrote:
Praveen,

That was precisely my point about the = ecosystem evolving. Now that we have the ability to classify flows, various= things have been built around being able to tell TCP flows. This obviously= has benefits as you point out, but the downside is that that I can't g= et good network utilization with a single flow. I understand the scaling po= int, but speaking of common cases, any server in = the wild is usually serving a large number of connections at moderate speed= s, not a single one at 25-35 Gbps... which makes that sort of scaling less = exciting than in a microbenchmark.

FWIW, the other downside of E= CMP is that multipath transport doesn't work -- you need to hash on som= ething else besides the 4-tuple. (We had to work around this in Google'= s deployment of connection migration.)

I'll disagree with your point about reordering being the uncomm= on case. While that's true today, this is again an expectation that the= network works hard to maintain, though the ecosystem and what we expect as= "usual" would be quite different had we not built TCP's requ= irements into the network. There's nothing wrong with having n-modal la= tencies... we can engineer around that. Any sensible load distribution sche= me within the network will give you increased variance but it should limit = the worst-case latency. You'd perhaps agree that that's a net win.<= br>

This was an example of how exposing packet num= ber or not can have long term ecosystem effects. My point was about the fac= t that exposing can cause ossification.

- jana

On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian <pravb@microsoft.com> wrote:

>> This was definitely true for implementation= s of TCP, but that is TCP's problem, not the network's

Flow classification happens through the netwo= rk and also on the end host with RSS where a flow is mapped to a core. This= allows for building high performance receive processing that could be lock= free for the most part. The only downside of ECMP on the network and RSS on the CPU is that a single flow will not t= ake multiple paths or get processed on more than one core. Windows on serve= r machines today can saturate 25-35 Gbps for a single TCP connection before= being CPU limited. This is a =C2=A0reasonable trade off because I don=E2=80=99t know of cases where a single flow is dri= ving more than that amount of traffic. Assumptions about how flows get clas= sified help make for more efficient processing. They also lead to consisten= t latency. You do not want the traffic to take a bi-modal or N-modal paths (on the network or the host) to being pro= cessed because the fluctuations in latency will hurt the workload. I am not= arguing for TCP not being resilient to reordering but IMO that should be t= he uncommon case not the common case. With QUIC if streams were exposed on the network you could take adva= ntage of stream level ECMP and RSS to scale better than TCP but we have cho= sen to keep the 4-tuple (or the 5-tuple) as the flow classifier on the netw= ork which is ok by me since it leads to TCP parity.

=C2=A0

Thanks

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Beh= alf Of Jana Iyengar
Sent: Sunday, February 4, 2018 8:35 PM
To: Salz, Rich <rsalz@akamai.com>
Cc: Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon <fenix@fb.com>; QUIC WG <quic@ietf.org>
Subject: Re: Packet number encryption

=C2=A0

Privacy-protection can't be a user choice, for t= he reasons others have noted on this thread.=C2=A0


That said, my primary argument is for encryption to avoid ossification. Not= that it matters now, but I'll note that much of GQUIC's original m= otivation for encrypting headers was to avoid ossification.

=C2=A0

I'll reiterate that fields we expose will get os= sified and there are long-term ecosystem effects to this. Let me illustrate= this with precisely the packet number field. Middleboxes commonly assume t= hat a TCP flow can only handle packets in-order. This assumption comes from the fact that TCP implementations get= poor performance when packets are reordered. This was definitely true for = implementations of TCP, but that is TCP's problem, not the network'= s. However, almost all load-balancers I know of now will pin all packets within a TCP flow to one path, leading to= sub-optimal performance in the network, and destroying incentives for the = endpoints to deploy reordering-resilient TCP implementations (even though t= here are plenty of ways of doing this.)

=C2=A0

Exposing QUIC's packet number field (as any fiel= d) is likely to have similar consequences and a similar ecosystem arc.

=C2=A0

=C2=A0

On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <rsalz@akamai.com> w= rote:

> Optional security tend= s to devolve to non-secure.

=C2=A0

That=E2=80=99s a great aphorism.=C2=A0 And sadly all too true.

=C2=A0



--089e0826ea901cbc9e0564804a52-- From nobody Mon Feb 5 16:41:16 2018 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 EFBB912DA2B for ; Mon, 5 Feb 2018 16:41:14 -0800 (PST) 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 Mip1YIJ0RvAF for ; Mon, 5 Feb 2018 16:41:12 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 C4A1412DA24 for ; Mon, 5 Feb 2018 16:41:12 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id b3so133126oib.11 for ; Mon, 05 Feb 2018 16:41:12 -0800 (PST) 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=ulVLoVxoxSVMVhkaTspLWqixZyGvxPMJKtK69u+iWMg=; b=OoTHEUiwcApGM3EnOQLKNIEhlZpGM+EeeXCiwwIuGSJrzNUGB3cHxB4UrnzjypiNec d2W23tOqoB1tKsYE5W3uow/VQHYZQK+ALawejrR4orjeq/EUVFMvrXRusXWylFwtqtyb jdaJYMOhxy6eGa/yp0/1izmAvPrRYd0NHd0ap0LovNcWDek7IDsYSrKkHmNryA6iD5z9 WyZkbgqLsoYloa8YqUIInRz3WR36d91c4SllfFOznycXLzwcL8QqVcXMVJrYH8kwHiwH cRYQaxSF0r0YgABD6xC1LqYO3DNOrGDU5FYPnrdMJvXiziMqv8PuSrbw5zTE8Cr6KyBP b9ww== 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=ulVLoVxoxSVMVhkaTspLWqixZyGvxPMJKtK69u+iWMg=; b=C2kp+jlkgEm345dzd4gDjIU4NGw1TepxzXaCh5yxqRUO7GXyymqZMvvWHDFdDZLoWh MpjD/izuPV9tLFP2Z+A6XO7B6RElDFCqRremx+WS85YV6eSINRlp7vrZEPfh2VVYfvDi 2ydPjLRzQgD63E5XSu+kwxFrhNhWKFUMICF1ZnHYQy8Z04tB0nCUGZMY/l339JdGpUy0 toYIalySBKswAYqVnUakwuJMEeffHc/rHtJkc99Api0rjcpOHNFShnFSrFeiJirFxlwF fiFjcJMIpey4gKlasaKmgYkvzCV7mXNcAQtq2+djdBGyaJw0vcv1sxMmKfe7HB9lqdSJ IoYg== X-Gm-Message-State: APf1xPBLG9RtF50KD4kxeZDaIx/hMpOYbxPUzg4OmT1FE6h6oVLtNH7Q vo8NvQQzzHpEmhFSaoaz+x7y0ITaWKEVqmjRc7E= X-Google-Smtp-Source: AH8x225szz/mq7g47UH8Zjk7S9mpipRuBb3Kic9arLRgyIjA0/6fGDPPXypIi/ldFP6ktsm7r53uys9041en+0yLY44= X-Received: by 10.202.106.12 with SMTP id f12mr408542oic.92.1517877671883; Mon, 05 Feb 2018 16:41:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Mon, 5 Feb 2018 16:41:11 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> From: Martin Thomson Date: Tue, 6 Feb 2018 11:41:11 +1100 Message-ID: Subject: Re: Packet number encryption To: Jana Iyengar Cc: Praveen Balasubramanian , "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , 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: Tue, 06 Feb 2018 00:41:15 -0000 It's possible that we could decide to add (3) later if we decided to take (2) now. I'd prefer to proceed with (2) and I'm sure that we'll collectively have more information on what it takes to add bits to the header after we conclude our discussion on spin bits in London. There's a fourth option, which involves encryption of just the high-order bits of the packet number. It still likely means that we would need gaps to break linkability, but those gaps could be relatively small and so could be made unilaterally without all of the machinery that (1) has. Of course, that has other implications, such as the need to expose the size of the packet number (unless we switch to a little-endian encoding...). On Tue, Feb 6, 2018 at 11:30 AM, Jana Iyengar wrote: > I don't think we're converging here, so I'd like to try and encourage us = to > move towards it. I have my opinion, but I care more about forward progres= s > at this point. > > There are three designs so far: > 1. Packet numbers as is, with random gaps around migration. > 2. Packet numbers encrypted, as per Martin's PR. > 3. Packet numbers encrypted, plus a small modulo sequence number somewher= e. > > The concrete ones here are (1) and (2). I'm listing (3) but am not incli= ned > to consider it seriously, since it's not concrete enough, (and I don't wa= nt > more bits to be spent in the QUIC packet header if that's where this info > goes.) > > There are opinions about ossification, privacy, and manageability. I'm no= t > hearing bloody murder, so for what it's worth, I'd like to stipulate firs= t > that we can all live with the final design, whichever one it is. If anyo= ne > disagrees, please say so -- I think it'd be useful to hear if there are > folks who think a particular design is fundamentally problematic. > > My opinion is still for (2) over (1), but I can live with either. > > On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: >> >> Praveen, >> >> That was precisely my point about the ecosystem evolving. Now that we ha= ve >> the ability to classify flows, various things have been built around bei= ng >> able to tell TCP flows. This obviously has benefits as you point out, bu= t >> the downside is that that I can't get good network utilization with a si= ngle >> flow. I understand the scaling point, but speaking of common cases, any >> server in the wild is usually serving a large number of connections at >> moderate speeds, not a single one at 25-35 Gbps... which makes that sort= of >> scaling less exciting than in a microbenchmark. >> >> FWIW, the other downside of ECMP is that multipath transport doesn't wor= k >> -- you need to hash on something else besides the 4-tuple. (We had to wo= rk >> around this in Google's deployment of connection migration.) >> >> I'll disagree with your point about reordering being the uncommon case. >> While that's true today, this is again an expectation that the network w= orks >> hard to maintain, though the ecosystem and what we expect as "usual" wou= ld >> be quite different had we not built TCP's requirements into the network. >> There's nothing wrong with having n-modal latencies... we can engineer >> around that. Any sensible load distribution scheme within the network wi= ll >> give you increased variance but it should limit the worst-case latency. >> You'd perhaps agree that that's a net win. >> >> This was an example of how exposing packet number or not can have long >> term ecosystem effects. My point was about the fact that exposing can ca= use >> ossification. >> >> - jana >> >> On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian >> wrote: >>> >>> >> This was definitely true for implementations of TCP, but that is TCP= 's >>> >> problem, not the network's >>> >>> Flow classification happens through the network and also on the end hos= t >>> with RSS where a flow is mapped to a core. This allows for building hig= h >>> performance receive processing that could be lock free for the most par= t. >>> The only downside of ECMP on the network and RSS on the CPU is that a s= ingle >>> flow will not take multiple paths or get processed on more than one cor= e. >>> Windows on server machines today can saturate 25-35 Gbps for a single T= CP >>> connection before being CPU limited. This is a reasonable trade off be= cause >>> I don=E2=80=99t know of cases where a single flow is driving more than = that amount >>> of traffic. Assumptions about how flows get classified help make for mo= re >>> efficient processing. They also lead to consistent latency. You do not = want >>> the traffic to take a bi-modal or N-modal paths (on the network or the = host) >>> to being processed because the fluctuations in latency will hurt the >>> workload. I am not arguing for TCP not being resilient to reordering bu= t IMO >>> that should be the uncommon case not the common case. With QUIC if stre= ams >>> were exposed on the network you could take advantage of stream level EC= MP >>> and RSS to scale better than TCP but we have chosen to keep the 4-tuple= (or >>> the 5-tuple) as the flow classifier on the network which is ok by me si= nce >>> it leads to TCP parity. >>> >>> >>> >>> Thanks >>> >>> >>> >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar >>> Sent: Sunday, February 4, 2018 8:35 PM >>> To: Salz, Rich >>> Cc: Lubashev, Igor ; Roberto Peon ; >>> QUIC WG >>> Subject: Re: Packet number encryption >>> >>> >>> >>> Privacy-protection can't be a user choice, for the reasons others have >>> noted on this thread. >>> >>> >>> That said, my primary argument is for encryption to avoid ossification. >>> Not that it matters now, but I'll note that much of GQUIC's original >>> motivation for encrypting headers was to avoid ossification. >>> >>> >>> >>> I'll reiterate that fields we expose will get ossified and there are >>> long-term ecosystem effects to this. Let me illustrate this with precis= ely >>> the packet number field. Middleboxes commonly assume that a TCP flow ca= n >>> only handle packets in-order. This assumption comes from the fact that = TCP >>> implementations get poor performance when packets are reordered. This w= as >>> definitely true for implementations of TCP, but that is TCP's problem, = not >>> the network's. However, almost all load-balancers I know of now will pi= n all >>> packets within a TCP flow to one path, leading to sub-optimal performan= ce in >>> the network, and destroying incentives for the endpoints to deploy >>> reordering-resilient TCP implementations (even though there are plenty = of >>> ways of doing this.) >>> >>> >>> >>> Exposing QUIC's packet number field (as any field) is likely to have >>> similar consequences and a similar ecosystem arc. >>> >>> >>> >>> >>> >>> On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: >>> >>> > Optional security tends to devolve to non-secure. >>> >>> >>> >>> That=E2=80=99s a great aphorism. And sadly all too true. >>> >>> >> >> > From nobody Mon Feb 5 16:50:22 2018 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 EFF5112DA26 for ; Mon, 5 Feb 2018 16:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 3toaUmcNOp0c for ; Mon, 5 Feb 2018 16:50:18 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 87305126C26 for ; Mon, 5 Feb 2018 16:50:18 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id a2so206194otf.2 for ; Mon, 05 Feb 2018 16:50:18 -0800 (PST) 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=AUPowOjkx29LBeAyvTS6aqrodFlc8c9xarvAEA28Y6c=; b=gpbgMW8S41oIrGEENkJH2wPxtRhy4JGzJHgpzEa0iCAECMnp5RWRxT5AH6hix6onhR 11cifqBbyiubmv841yraPrtMZL+NcRIRtoxMajMSav4s/+rwIcvk88SXFW/ZKUpxOF1S SpOfd02LbKqCXY2YddfoAaZA2gfGwzG8tUMTAo8txbUeG1xeCyrEkrmg38WOI3zeb24M 7nWV+4e4P/iU6ZBbbLtEF+kjkO8IhzW7wF6XAzK/qxVBI/xTkoeFWIRhKDaxaHrRAugw xPUF+wZGjBIBuY7F8tadv0yB01LOf7vUGD602+Yghpj5v50wD36CHuULo1X8qcaY1Ipm L7+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=AUPowOjkx29LBeAyvTS6aqrodFlc8c9xarvAEA28Y6c=; b=Vs9x/ftVGzpJZd5KxbLp1g2z5jQfNIYxQj4eGg0/EUEkdekd7wqB8BQlrBqf8Hv+AO 3OqRjNKLng73DbjOtv4i939geAY97X+NFOfq3uar5YnBi91y8iUyNOxHyqLnCu9gUm+i Z1z1KN7D6GZR18oWXCRodKr2mBEVEWr4zsdXMYbj/NpvP5OQNXAlDQxPYscYN+ELOP84 LLbHMWhWpVFdSSB8k1AFb6E3C8tn8GJdHkTaHrGq069HyVf+IeT34DjvGE3oMftAUzcB HeW1eM9+7Mms12BvW/+SOwZLenkFd6S3Xdd8yo/oiXIZMNoE4D7+z4cRHMR+k88629ti 249Q== X-Gm-Message-State: APf1xPDw5tWCLTCXj/YG5OFvLOImbOKURw9dn4jVv/PkZwRDs+wSz/lU 9O079DrnTyaN9vnMH8xzRRRkfqR2bXi/8PDgCSo= X-Google-Smtp-Source: AH8x227vV3cq9DrGzGJBcUrA13FlgvT8pgtSDFiRcqhxTL5sAxmQeawYuuE7pP92sxZIkeNkp4dPc3Kn+aTa+UCB3SQ= X-Received: by 10.157.53.5 with SMTP id o5mr435287otc.181.1517878217579; Mon, 05 Feb 2018 16:50:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.3.71 with HTTP; Mon, 5 Feb 2018 16:49:47 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> From: Ted Hardie Date: Mon, 5 Feb 2018 16:49:47 -0800 Message-ID: Subject: Re: Packet number encryption To: Jana Iyengar Cc: Praveen Balasubramanian , "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , QUIC WG Content-Type: multipart/alternative; boundary="001a11c046c4f8a3b00564808f0c" 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, 06 Feb 2018 00:50:21 -0000 --001a11c046c4f8a3b00564808f0c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 5, 2018 at 4:30 PM, Jana Iyengar wrote: > I don't think we're converging here, so I'd like to try and encourage us > to move towards it. I have my opinion, but I care more about forward > progress at this point. > > There are three designs so far: > 1. Packet numbers as is, with random gaps around migration. > 2. Packet numbers encrypted, as per Martin's PR. > 3. Packet numbers encrypted, plus a small modulo sequence number somewher= e. > > The concrete ones here are (1) and (2). I'm listing (3) but am not > inclined to consider it seriously, since it's not concrete enough, (and I > don't want more bits to be spent in the QUIC packet header if that's wher= e > this info goes.) > > If you'll forgive my saying so, evidence suggests that so many of the concrete aspects of such a proposal (where the bits would live, how many bits, etc.) would change over the lifetime of a proposal in this WG that any completely nailed down suggestion might as well be a blank sheet for all the bearing it would have on the final placement and length. The question is: do we wish to expose a small sequence number to assist in network analysis and management, yes or no? We can argue over the bike shed color after making the decision to build a shed; requiring the shed have a color before considering the question seems less productive to me than just answering the question. Just my personal opinion, of course. Ted > There are opinions about ossification, privacy, and manageability. I'm no= t > hearing bloody murder, so for what it's worth, I'd like to stipulate firs= t > that we can all live with the final design, whichever one it is. If anyo= ne > disagrees, please say so -- I think it'd be useful to hear if there are > folks who think a particular design is fundamentally problematic. > > My opinion is still for (2) over (1), but I can live with either. > > On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: > >> Praveen, >> >> That was precisely my point about the ecosystem evolving. Now that we >> have the ability to classify flows, various things have been built aroun= d >> being able to tell TCP flows. This obviously has benefits as you point o= ut, >> but the downside is that that I can't get good network utilization with = a >> single flow. I understand the scaling point, but speaking of common >> cases, any server in the wild is usually serving a large number of >> connections at moderate speeds, not a single one at 25-35 Gbps... which >> makes that sort of scaling less exciting than in a microbenchmark. >> >> FWIW, the other downside of ECMP is that multipath transport doesn't wor= k >> -- you need to hash on something else besides the 4-tuple. (We had to wo= rk >> around this in Google's deployment of connection migration.) >> >> I'll disagree with your point about reordering being the uncommon case. >> While that's true today, this is again an expectation that the network >> works hard to maintain, though the ecosystem and what we expect as "usua= l" >> would be quite different had we not built TCP's requirements into the >> network. There's nothing wrong with having n-modal latencies... we can >> engineer around that. Any sensible load distribution scheme within the >> network will give you increased variance but it should limit the worst-c= ase >> latency. You'd perhaps agree that that's a net win. >> >> This was an example of how exposing packet number or not can have long >> term ecosystem effects. My point was about the fact that exposing can ca= use >> ossification. >> >> - jana >> >> On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian < >> pravb@microsoft.com> wrote: >> >>> >> This was definitely true for implementations of TCP, but that is >>> TCP's problem, not the network's >>> >>> Flow classification happens through the network and also on the end hos= t >>> with RSS where a flow is mapped to a core. This allows for building hig= h >>> performance receive processing that could be lock free for the most par= t. >>> The only downside of ECMP on the network and RSS on the CPU is that a >>> single flow will not take multiple paths or get processed on more than = one >>> core. Windows on server machines today can saturate 25-35 Gbps for a si= ngle >>> TCP connection before being CPU limited. This is a reasonable trade of= f >>> because I don=E2=80=99t know of cases where a single flow is driving mo= re than that >>> amount of traffic. Assumptions about how flows get classified help make= for >>> more efficient processing. They also lead to consistent latency. You do= not >>> want the traffic to take a bi-modal or N-modal paths (on the network or= the >>> host) to being processed because the fluctuations in latency will hurt = the >>> workload. I am not arguing for TCP not being resilient to reordering bu= t >>> IMO that should be the uncommon case not the common case. With QUIC if >>> streams were exposed on the network you could take advantage of stream >>> level ECMP and RSS to scale better than TCP but we have chosen to keep = the >>> 4-tuple (or the 5-tuple) as the flow classifier on the network which is= ok >>> by me since it leads to TCP parity. >>> >>> >>> >>> Thanks >>> >>> >>> >>> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar >>> *Sent:* Sunday, February 4, 2018 8:35 PM >>> *To:* Salz, Rich >>> *Cc:* Lubashev, Igor ; Roberto Peon = ; >>> QUIC WG >>> *Subject:* Re: Packet number encryption >>> >>> >>> >>> Privacy-protection can't be a user choice, for the reasons others have >>> noted on this thread. >>> >>> >>> That said, my primary argument is for encryption to avoid ossification. >>> Not that it matters now, but I'll note that much of GQUIC's original >>> motivation for encrypting headers was to avoid ossification. >>> >>> >>> >>> I'll reiterate that fields we expose will get ossified and there are >>> long-term ecosystem effects to this. Let me illustrate this with precis= ely >>> the packet number field. Middleboxes commonly assume that a TCP flow ca= n >>> only handle packets in-order. This assumption comes from the fact that = TCP >>> implementations get poor performance when packets are reordered. This w= as >>> definitely true for implementations of TCP, but that is TCP's problem, = not >>> the network's. However, almost all load-balancers I know of now will pi= n >>> all packets within a TCP flow to one path, leading to sub-optimal >>> performance in the network, and destroying incentives for the endpoints= to >>> deploy reordering-resilient TCP implementations (even though there are >>> plenty of ways of doing this.) >>> >>> >>> >>> Exposing QUIC's packet number field (as any field) is likely to have >>> similar consequences and a similar ecosystem arc. >>> >>> >>> >>> >>> >>> On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: >>> >>> > Optional security tends to devolve to non-secure. >>> >>> >>> >>> That=E2=80=99s a great aphorism. And sadly all too true. >>> >>> >>> >> >> > --001a11c046c4f8a3b00564808f0c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Feb 5, 2018 at 4:30 PM, Jana Iyengar <jri@google.com= > wrote:
I don't think we&#= 39;re converging here, so I'd like to try and encourage us to move towa= rds it. I have my opinion, but I care more about forward progress at this p= oint.

There are three designs so far:
1. Packe= t numbers as is, with random gaps around migration.
2. Packet num= bers encrypted, as per Martin's PR.
3. Packet numbers encrypt= ed, plus a small modulo sequence number somewhere.

The concrete ones here are (1) and (2).=C2=A0=C2=A0I'm listing (3) but am not inclined to consider it seriously, since = it's not concrete enough, (and I don't want more bits to be spent i= n the QUIC packet header if that's where this info goes.)

If you'll forgive my sayi= ng so, evidence suggests that so many of the concrete aspects of such a pro= posal (where the bits would live, how many bits, etc.) would change over th= e lifetime of a proposal in this WG that any completely nailed down suggest= ion might as well be a blank sheet for all the bearing it would have on the= final placement and length.

The question is:=C2=A0 do we= wish to expose a small sequence number to assist in network analysis and m= anagement, yes or no?=C2=A0

We can argue over the bike shed color a= fter making the decision to build a shed; requiring the shed have a color b= efore considering the question seems less productive to me than just answer= ing the question.

Just my personal opinion, of course.
Ted

=C2=A0
There are opinions about ossification, privacy,= and manageability. I'm not hearing bloody murder, so for what it's= worth, I'd like to stipulate first that we can all live with the final= design, whichever one it is.=C2=A0 If anyone disagrees, please say so -- I= think it'd be useful to hear if there are folks who think a particular= design is fundamentally problematic.

My opinion is still for (2) over (1), but I can live with ei= ther.

On Mon, Feb 5, 2018 at 3= :32 PM, Jana Iyengar <jri@google.com> wrote:
Praveen,

That was = precisely my point about the ecosystem evolving. Now that we have the abili= ty to classify flows, various things have been built around being able to t= ell TCP flows. This obviously has benefits as you point out, but the downsi= de is that that I can't get good network utilization with a single flow= . I understand the scaling point, but speaking of= common cases, any server in the wild is usually serving a large number of = connections at moderate speeds, not a single one at 25-35 Gbps... which mak= es that sort of scaling less exciting than in a microbenchmark.

= FWIW, the other downside of ECMP is that multipath transport doesn't wo= rk -- you need to hash on something else besides the 4-tuple. (We had to wo= rk around this in Google's deployment of connection migration.)<= /div>

I'll disagree with your point abou= t reordering being the uncommon case. While that's true today, this is = again an expectation that the network works hard to maintain, though the ec= osystem and what we expect as "usual" would be quite different ha= d we not built TCP's requirements into the network. There's nothing= wrong with having n-modal latencies... we can engineer around that. Any se= nsible load distribution scheme within the network will give you increased = variance but it should limit the worst-case latency. You'd perhaps agre= e that that's a net win.

This was an examp= le of how exposing packet number or not can have long term ecosystem effect= s. My point was about the fact that exposing can cause ossification.
<= span class=3D"m_-5376313852984361260HOEnZb">
- jana

On Mon, Feb 5, 2018 at 9:24 AM, Pravee= n Balasubramanian <pravb@microsoft.com> wrote:

>> This was definitely true for implementation= s of TCP, but that is TCP's problem, not the network's

Flow classification happens through the netwo= rk and also on the end host with RSS where a flow is mapped to a core. This= allows for building high performance receive processing that could be lock= free for the most part. The only downside of ECMP on the network and RSS on the CPU is that a single flow will not t= ake multiple paths or get processed on more than one core. Windows on serve= r machines today can saturate 25-35 Gbps for a single TCP connection before= being CPU limited. This is a =C2=A0reasonable trade off because I don=E2=80=99t know of cases where a single flow is dri= ving more than that amount of traffic. Assumptions about how flows get clas= sified help make for more efficient processing. They also lead to consisten= t latency. You do not want the traffic to take a bi-modal or N-modal paths (on the network or the host) to being pro= cessed because the fluctuations in latency will hurt the workload. I am not= arguing for TCP not being resilient to reordering but IMO that should be t= he uncommon case not the common case. With QUIC if streams were exposed on the network you could take adva= ntage of stream level ECMP and RSS to scale better than TCP but we have cho= sen to keep the 4-tuple (or the 5-tuple) as the flow classifier on the netw= ork which is ok by me since it leads to TCP parity.

=C2=A0

Thanks

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Beh= alf Of Jana Iyengar
Sent: Sunday, February 4, 2018 8:35 PM
To: Salz, Rich <rsalz@akamai.com>
Cc: Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon <fenix@fb.com>; QUIC WG <quic@ietf.org>
Subject: Re: Packet number encryption

=C2=A0

Privacy-protection can't be a user choice, for t= he reasons others have noted on this thread.=C2=A0


That said, my primary argument is for encryption to avoid ossification. Not= that it matters now, but I'll note that much of GQUIC's original m= otivation for encrypting headers was to avoid ossification.

=C2=A0

I'll reiterate that fields we expose will get os= sified and there are long-term ecosystem effects to this. Let me illustrate= this with precisely the packet number field. Middleboxes commonly assume t= hat a TCP flow can only handle packets in-order. This assumption comes from the fact that TCP implementations get= poor performance when packets are reordered. This was definitely true for = implementations of TCP, but that is TCP's problem, not the network'= s. However, almost all load-balancers I know of now will pin all packets within a TCP flow to one path, leading to= sub-optimal performance in the network, and destroying incentives for the = endpoints to deploy reordering-resilient TCP implementations (even though t= here are plenty of ways of doing this.)

=C2=A0

Exposing QUIC's packet number field (as any fiel= d) is likely to have similar consequences and a similar ecosystem arc.

=C2=A0

=C2=A0

On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <rsalz@akamai.com> w= rote:

> Optional security tend= s to devolve to non-secure.

=C2=A0

That=E2=80=99s a great aphorism.=C2=A0 And= sadly all too true.

=C2=A0




--001a11c046c4f8a3b00564808f0c-- From nobody Mon Feb 5 16:52:55 2018 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 4CCE212DA15 for ; Mon, 5 Feb 2018 16:52:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, 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=fb.com header.b=rOUyf1E2; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=kUWURYWW 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 N1LfoeXwhVE5 for ; Mon, 5 Feb 2018 16:52:50 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 BBFC1126C26 for ; Mon, 5 Feb 2018 16:52:50 -0800 (PST) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w160nqaA007985; Mon, 5 Feb 2018 16:52:40 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=KFwrQ4ZxZuOCGqhHJQokwXBWGEpxp1syqRVNeQ6nxjk=; b=rOUyf1E2aFnWUkN853s6RxwEiPixOuh7Hweu4ONer9Nbpj0dM8fl2+qLO0HKQfX0bSdb kZCOSgOS/foIZbyQp+2EMVPni1wiG620vVI/FHwO07lhqlyWQcM7fEf1gDnGEJROFdi3 sGm7tDK3lrjutZaOcQCrP0QlYYNLpJkby7g= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2fy0fbgje3-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 05 Feb 2018 16:52:39 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.25) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 5 Feb 2018 19:52:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KFwrQ4ZxZuOCGqhHJQokwXBWGEpxp1syqRVNeQ6nxjk=; b=kUWURYWW/b6vXAB48VvkJRTUU/qMlwC64Cg+V3HpuPlaJGU8IroDxvQEK0eZhQOy6kpVIJUQlMWfHDeH4Mpj1D9w9dzAdZf6PbSESU14ldaaTS25WT8AmmHxH6qve/5ouHvdwnlM8okf6QzS/vpRnzV1OxMCjVa5KK/Tn1yhAFg= Received: from CY4PR15MB1927.namprd15.prod.outlook.com (10.174.54.148) by CY4PR15MB1381.namprd15.prod.outlook.com (10.172.159.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Tue, 6 Feb 2018 00:52:36 +0000 Received: from CY4PR15MB1927.namprd15.prod.outlook.com ([fe80::463:bbae:3f76:e5da]) by CY4PR15MB1927.namprd15.prod.outlook.com ([fe80::463:bbae:3f76:e5da%18]) with mapi id 15.20.0464.015; Tue, 6 Feb 2018 00:52:35 +0000 From: Alan Frindell To: Eric Kinnear , Jana Iyengar CC: Lars Eggert , Mark Nottingham , QUIC WG , Mike Bishop , Roberto Peon Subject: Re: Call for Adoption: QCRAM Thread-Topic: Call for Adoption: QCRAM Thread-Index: AQHTnke81v8V7C16KEip0BRzijbEWKOWK2wAgAAAo4CAAA+EgIAAH9kAgADp9oA= Date: Tue, 6 Feb 2018 00:52:35 +0000 Message-ID: <816D67C7-1E2F-40E3-AC64-504D06316FC1@fb.com> References: <6A834DB6-F2A5-4973-83CD-8AAA82945372@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.28.0.171108 x-originating-ip: [2620:10d:c091:180::1:faac] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR15MB1381; 7:xtFUrfIwdfWtlUWbUDYyzVz1dH0fYOGQbfqftmzjfKOImm7ZOlWeZnG+HoJ3DOl/vWKKC7807gQyJkVMhlTtTUPLWO+vPNetuNQRgST5S59GudQFiexUW8V5gF4K5yWkgJ7ByVxOlRiu1w+K0mKhAy8H4ogk8rCJDaG1wUJBIFJVJqrbdabsWnI8aOaGOHf3IrKW1zTSgyqsrrVC/OZfjEg5Q7UTjEkzuVplw4abXTiJ2BEoDqVvplSdjyWB5MFN; 20:uqsf8APLspaey0CoWYkxysAG1IEYbXzSUoQmUkxEc6ziNofqeBiEydKZvlvC6EpPnmS7LPmQr16G1aFlrxfz+fCIHJbZUx8yw3SFfWA7mrJFjW/WFqV+K53KgFXLIaMXPbpWiblq4jrveR5cdzZrslPXTy2kjMurn/eaE9krptI= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(366004)(346002)(376002)(396003)(13464003)(189003)(199004)(82746002)(606006)(8936002)(99286004)(6306002)(53936002)(3660700001)(54896002)(68736007)(8666007)(5660300001)(5250100002)(3280700002)(6246003)(83506002)(2906002)(105586002)(83716003)(2900100001)(106356001)(4326008)(966005)(478600001)(229853002)(81156014)(81166006)(33656002)(186003)(97736004)(58126008)(6436002)(6486002)(25786009)(86362001)(102836004)(575784001)(93886005)(8676002)(2950100002)(14454004)(6116002)(110136005)(36756003)(316002)(53546011)(7736002)(76176011)(6512007)(6506007)(236005)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR15MB1381; H:CY4PR15MB1927.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 8e0f2f23-bcdb-4b54-e418-08d56cfbe9c5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR15MB1381; x-ms-traffictypediagnostic: CY4PR15MB1381: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(80524489315369)(10436049006162)(131327999870524)(67672495146484)(211936372134217)(153496737603132)(21748063052155)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(11241501184)(2400082)(944501161)(10201501046)(93006095)(93001095)(3002001)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR15MB1381; BCL:0; PCL:0; RULEID:; SRVR:CY4PR15MB1381; x-forefront-prvs: 0575F81B58 received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: +aG1NXqY72HW6UiPdUr3VzohUZUpOK6dmvUxIa6/+YlHhXQmg7rGhr4309HpkFWHd1nTS4vDS3sdMJMPi//CQA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_816D67C71E2F40E3AC64504D06316FC1fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8e0f2f23-bcdb-4b54-e418-08d56cfbe9c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 00:52:35.5873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR15MB1381 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-05_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 06 Feb 2018 00:52:53 -0000 --_000_816D67C71E2F40E3AC64504D06316FC1fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIGFkb3B0aW9uDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIEVyaWMgS2lubmVhciA8ZWtpbm5lYXJAYXBwbGUuY29tPg0KRGF0ZTogTW9uZGF5 LCBGZWJydWFyeSA1LCAyMDE4IGF0IDE6NTUgUE0NClRvOiBKYW5hIEl5ZW5nYXIgPGpyaUBnb29n bGUuY29tPg0KQ2M6IExhcnMgRWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc+LCBNYXJrIE5vdHRpbmdo YW0gPG1ub3RAbW5vdC5uZXQ+LCBRVUlDIFdHIDxxdWljQGlldGYub3JnPiwgTWlrZSBCaXNob3Ag PG1iaXNob3BAZXZlcXVlZm91LmJlPiwgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+DQpTdWJq ZWN0OiBSZTogQ2FsbCBmb3IgQWRvcHRpb246IFFDUkFNDQoNCisxIGZvciBhZG9wdGlvbiwgSSB0 aGluayB0aGlzIGlzIGEgZ29vZCBzdGFydGluZyBwb2ludCBmb3IgZm9sZGluZyBpbiBwaWVjZXMg b2YgdGhlIG90aGVyIHByb3Bvc2Fscy4NCg0KVGhhbmtzLA0KRXJpYw0KDQoNCg0KT24gRmViIDUs IDIwMTgsIGF0IDEyOjAxIFBNLCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpq cmlAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KDQorMSBmb3IgYWRvcHRpb24uDQoNCk9uIE1vbiwgRmVi IDUsIDIwMTggYXQgMTE6MDUgQU0sIFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPG1haWx0bzpm ZW5peEBmYi5jb20+PiB3cm90ZToNCkFncmVlZC4NClN1cHBvcnRlZC4NCi09Ug0KDQpPbiAyLzUv MTgsIDExOjA0IEFNLCAiUVVJQyBvbiBiZWhhbGYgb2YgTWlrZSBCaXNob3AiIDxxdWljLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIG1i aXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+IHdyb3RlOg0K DQogICAgSSBzdXBwb3J0IGFkb3B0aW9uIC0tIGl0J3MgYSB1c2VmdWwgc3RhcnRpbmcgcG9pbnQg ZnJvbSB3aGljaCB3ZSBjYW4gZGlzY3VzcyB3aGF0IGVsZW1lbnRzIG9mIG90aGVyIHByb3Bvc2Fs cyBhcmUgd29ydGggbGlmdGluZyBpbnRvIHRoaXMgbW9kZWwuDQoNCiAgICAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBNYXJrIE5vdHRp bmdoYW0NCiAgICBTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDQsIDIwMTggMTA6MDggUE0NCiAgICBU bzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQogICAgQ2M6 IExhcnMgRWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc8bWFpbHRvOmxhcnNAZWdnZXJ0Lm9yZz4+DQog ICAgU3ViamVjdDogQ2FsbCBmb3IgQWRvcHRpb246IFFDUkFNDQoNCiAgICBJbiBNZWxib3VybmUs IHRoZXJlIHdhcyBzdHJvbmcgc3VwcG9ydCAod2l0aCBhIHNtYWxsIGFtb3VudCBvZiBwdXNoYmFj ayB3aGljaCB3YXMgZGlzY3Vzc2VkKSBmb3IgYWRvcHRpbmcgUUNSQU06DQoNCiAgICBodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYu b3JnX2h0bWxfZHJhZnQtMkRrcmFzaWMtMkRxdWljLTJEcWNyYW0tMkQwNCZkPUR3SUZBZyZjPTVW RDBSVHRObFRoM3ljZDQxYjNNVXcmcj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJm09OUNMMkR6UkNy dnBXUkVTZXFRemVCSldtQTVDc2dqdV90X21BTTlUa3J2OCZzPVlVdC1ldGZSVVJ6SkFVM0trM01o LTYzWHNrNkVxdDZqdDNfTm1zaE5ybzAmZT0NCg0KICAgIEFueSBvYmplY3Rpb25zIC8gY29uY2Vy bnMgYWJvdXQgZG9pbmcgc28/IFVubGVzcyB3ZSBoZWFyIG90aGVyd2lzZSwgd2UnbGwgYWRvcHQg YXQgdGhlIGVuZCBvZiB0aGUgd2Vlay4NCg0KICAgIENoZWVycywNCg0KICAgIC0tDQogICAgTWFy ayBOb3R0aW5naGFtICAgaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91 PWh0dHBzLTNBX193d3cubW5vdC5uZXRfJmQ9RHdJRkFnJmM9NVZEMFJUdE5sVGgzeWNkNDFiM01V dyZyPUMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEEmbT05Q0wyRHpSQ3J2cFdSRVNlcVF6ZUJKV21BNUNz Z2p1X3RfbUFNOVRrcnY4JnM9OXN4MWJCaDZkZDRENExtYVNvV1JqUTZtbFp6bFVfTmVQYmwwa212 blhIRSZlPQ0KDQoNCg0KDQo= --_000_816D67C71E2F40E3AC64504D06316FC1fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <5596C2B7EC8F2941953F7A455C597FDD@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgZm9yIGFkb3B0aW9uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5RVUlDICZsdDtxdWljLWJvdW5j ZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBFcmljIEtpbm5lYXIgJmx0O2VraW5uZWFyQGFw cGxlLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4IGF0 IDE6NTUgUE08YnI+DQo8Yj5UbzogPC9iPkphbmEgSXllbmdhciAmbHQ7anJpQGdvb2dsZS5jb20m Z3Q7PGJyPg0KPGI+Q2M6IDwvYj5MYXJzIEVnZ2VydCAmbHQ7bGFyc0BlZ2dlcnQub3JnJmd0Oywg TWFyayBOb3R0aW5naGFtICZsdDttbm90QG1ub3QubmV0Jmd0OywgUVVJQyBXRyAmbHQ7cXVpY0Bp ZXRmLm9yZyZndDssIE1pa2UgQmlzaG9wICZsdDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZndDssIFJv YmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog Q2FsbCBmb3IgQWRvcHRpb246IFFDUkFNPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSBmb3IgYWRvcHRpb24sIEkgdGhpbmsgdGhpcyBp cyBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgZm9yIGZvbGRpbmcgaW4gcGllY2VzIG9mIHRoZSBvdGhl ciBwcm9wb3NhbHMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkVyaWM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRmViIDUsIDIwMTgsIGF0IDEyOjAxIFBNLCBKYW5h IEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+anJpQGdvb2dsZS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiYjNDM7MSBmb3IgYWRvcHRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEZlYiA1LCAyMDE4IGF0IDExOjA1IEFNLCBSb2JlcnRv IFBlb24gJmx0OzxhIGhyZWY9Im1haWx0bzpmZW5peEBmYi5jb20iIHRhcmdldD0iX2JsYW5rIj5m ZW5peEBmYi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFncmVlZC48 YnI+DQpTdXBwb3J0ZWQuPGJyPg0KLT1SPGJyPg0KPGJyPg0KT24gMi81LzE4LCAxMTowNCBBTSwg JnF1b3Q7UVVJQyBvbiBiZWhhbGYgb2YgTWlrZSBCaXNob3AmcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24g YmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiPm1iaXNob3BA ZXZlcXVlZm91LmJlPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBJIHN1 cHBvcnQgYWRvcHRpb24gLS0gaXQncyBhIHVzZWZ1bCBzdGFydGluZyBwb2ludCBmcm9tIHdoaWNo IHdlIGNhbiBkaXNjdXNzIHdoYXQgZWxlbWVudHMgb2Ygb3RoZXIgcHJvcG9zYWxzIGFyZSB3b3J0 aCBsaWZ0aW5nIGludG8gdGhpcyBtb2RlbC48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJm5ic3A7ICZuYnNwOyBGcm9tOiBRVUlDIFttYWls dG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGll dGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1hcmsgTm90dGluZ2hhbTxicj4NCiZuYnNwOyAmbmJz cDsgU2VudDogU3VuZGF5LCBGZWJydWFyeSA0LCAyMDE4IDEwOjA4IFBNPGJyPg0KJm5ic3A7ICZu YnNwOyBUbzogUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZuYnNwOyAmbmJzcDsgQ2M6IExhcnMgRWdnZXJ0ICZsdDs8 YSBocmVmPSJtYWlsdG86bGFyc0BlZ2dlcnQub3JnIj5sYXJzQGVnZ2VydC5vcmc8L2E+Jmd0Ozxi cj4NCiZuYnNwOyAmbmJzcDsgU3ViamVjdDogQ2FsbCBmb3IgQWRvcHRpb246IFFDUkFNPGJyPg0K PGJyPg0KJm5ic3A7ICZuYnNwOyBJbiBNZWxib3VybmUsIHRoZXJlIHdhcyBzdHJvbmcgc3VwcG9y dCAod2l0aCBhIHNtYWxsIGFtb3VudCBvZiBwdXNoYmFjayB3aGljaCB3YXMgZGlzY3Vzc2VkKSBm b3IgYWRvcHRpbmcgUUNSQU06PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyA8YSBocmVmPSJodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmll dGYub3JnX2h0bWxfZHJhZnQtMkRrcmFzaWMtMkRxdWljLTJEcWNyYW0tMkQwNCZhbXA7ZD1Ed0lG QWcmYW1wO2M9NVZEMFJUdE5sVGgzeWNkNDFiM01VdyZhbXA7cj1DMHNVby1MRk5CYVlmeW9hQ3Nm NlRBJmFtcDttPTlDTDJEelJDcnZwV1JFU2VxUXplQkpXbUE1Q3NnanVfdF9tQU05VGtydjgmYW1w O3M9WVV0LWV0ZlJVUnpKQVUzS2szTWgtNjNYc2s2RXF0Nmp0M19ObXNoTnJvMCZhbXA7ZT0iIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGtyYXNpYy0yRHF1aWMtMkRx Y3JhbS0yRDA0JmFtcDtkPUR3SUZBZyZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDty PUMwc1VvLUxGTkJhWWZ5b2FDc2Y2VEEmYW1wO209OUNMMkR6UkNydnBXUkVTZXFRemVCSldtQTVD c2dqdV90X21BTTlUa3J2OCZhbXA7cz1ZVXQtZXRmUlVSekpBVTNLazNNaC02M1hzazZFcXQ2anQz X05tc2hOcm8wJmFtcDtlPTwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEFueSBvYmplY3Rp b25zIC8gY29uY2VybnMgYWJvdXQgZG9pbmcgc28/IFVubGVzcyB3ZSBoZWFyIG90aGVyd2lzZSwg d2UnbGwgYWRvcHQgYXQgdGhlIGVuZCBvZiB0aGUgd2Vlay48YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7IENoZWVycyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IC0tPGJyPg0KJm5ic3A7ICZuYnNw OyBNYXJrIE5vdHRpbmdoYW0mbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cubW5vdC5uZXRfJmFtcDtkPUR3 SUZBZyZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPUMwc1VvLUxGTkJhWWZ5b2FD c2Y2VEEmYW1wO209OUNMMkR6UkNydnBXUkVTZXFRemVCSldtQTVDc2dqdV90X21BTTlUa3J2OCZh bXA7cz05c3gxYkJoNmRkNEQ0TG1hU29XUmpRNm1sWnpsVV9OZVBibDBrbXZuWEhFJmFtcDtlPSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3Lm1ub3QubmV0XyZhbXA7ZD1Ed0lGQWcmYW1wO2M9NVZEMFJUdE5sVGgz eWNkNDFiM01VdyZhbXA7cj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJmFtcDttPTlDTDJEelJDcnZw V1JFU2VxUXplQkpXbUE1Q3NnanVfdF9tQU05VGtydjgmYW1wO3M9OXN4MWJCaDZkZDRENExtYVNv V1JqUTZtbFp6bFVfTmVQYmwwa212blhIRSZhbXA7ZT08L2E+PGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_816D67C71E2F40E3AC64504D06316FC1fbcom_-- From nobody Mon Feb 5 19:07:04 2018 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 E8D3E12DA40 for ; Mon, 5 Feb 2018 19:07:02 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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=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 nGIJ5w4T9YNW for ; Mon, 5 Feb 2018 19:06:54 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0109.outbound.protection.outlook.com [104.47.38.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BCD712DA3F for ; Mon, 5 Feb 2018 19:06:54 -0800 (PST) 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=47MR/MxLO7rMJhVwMgHWqSAtNbFoZy+xY3qUvbbjWD0=; b=nr4qQLprdDfPhJ67BiP2DPK0UCQf19m9egVN4YIT79yFd0o9uFAjnm26NOtYzwFy8f9Aops5XbHJKNodsJCjSnZzzVD7Hck3O66L/XA2zFxARSFbqU0wuNQlnR+NrKGpb0U4q3JtjxAABVIpU6US81Aiq/Y28CA0Y+sgX9anTqs= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0789.namprd21.prod.outlook.com (10.175.121.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Tue, 6 Feb 2018 03:06:51 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Tue, 6 Feb 2018 03:06:51 +0000 From: Praveen Balasubramanian To: Jana Iyengar CC: "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , QUIC WG Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAKaFw Date: Tue, 6 Feb 2018 03:06:51 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0789; 7:VgoT8qUIZ/inlM0ZTovR/M8j5ZepDNQVu2X/d1WZOQROx+0ad/rINtC7a16BnVLv+XjtUDE+c/O7Out0BP5gnJIi7DjYHRRDlF5EEP9tcpbPbrJvhw3OlfE1+RsEkxx9mMSMEZnOTRsseqG3kTZMOrgFNwt56B4pIKXyfxLNcvzPRF4CNadKYTYiNT7/bkVfZIAjkhQ2nPnm78DlGQQ+1MJ6iaZH29bBftFreU2g6DeePNqnucbpN7Fp/krrBJ7o x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6172c4b6-fae9-4657-4b07-08d56d0eab88 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:CY4PR21MB0789; x-ms-traffictypediagnostic: CY4PR21MB0789: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(192374486261705)(67672495146484)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR21MB0789; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0789; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(39850400004)(346002)(396003)(366004)(189003)(199004)(33656002)(4326008)(7736002)(316002)(86362001)(3660700001)(22452003)(3280700002)(97736004)(93886005)(7116003)(6116002)(186003)(790700001)(74316002)(2906002)(6246003)(25786009)(2900100001)(5660300001)(105586002)(2950100002)(478600001)(6306002)(102836004)(10290500003)(6346003)(6916009)(77096007)(8990500004)(14454004)(68736007)(236005)(9686003)(19609705001)(7696005)(86612001)(54896002)(99286004)(10090500001)(55016002)(54906003)(53936002)(106356001)(59450400001)(81166006)(229853002)(76176011)(6436002)(3480700004)(6506007)(53546011)(8936002)(81156014)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0789; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: xTQ7XhnI9meGJuZLVkhGhG8Td4lM3gt2TkHtzgmgyCDW8HiI2oYuTFjvGi1dVsxtfdqwSGQHV7gKELV9PQvp6g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133BD233AFD371388060D24B6FD0CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6172c4b6-fae9-4657-4b07-08d56d0eab88 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 03:06:51.5417 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0789 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, 06 Feb 2018 03:07:03 -0000 --_000_CY4PR21MB0133BD233AFD371388060D24B6FD0CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgb24gdGhlIHBvaW50IGFib3V0IG9zc2lmaWNhdGlvbiBhbmQgbG9uZyB0ZXJtIGVmZmVj dHMgb24gZWNvc3lzdGVtLiBJIHdhcyBqdXN0IHBvaW50aW5nIG91dCB0aGF0IHRoZSBjdXJyZW50 IGZsb3cgY2xhc3NpZmljYXRpb24gc2NoZW1lIGhhcyBzb21lIGJlbmVmaXRzIHRvbyBzbyB0aGVy ZSBhcmUgdHJhZGUtb2Zmcy4NCg0KPj4geW91IG5lZWQgdG8gaGFzaCBvbiBzb21ldGhpbmcgZWxz ZSBiZXNpZGVzIHRoZSA0LXR1cGxlLiAoV2UgaGFkIHRvIHdvcmsgYXJvdW5kIHRoaXMgaW4gR29v Z2xlJ3MgZGVwbG95bWVudCBvZiBjb25uZWN0aW9uIG1pZ3JhdGlvbg0KSSB3b3VsZCBsaWtlIHRv IHVuZGVyc3RhbmQgdGhlIHdvcmthcm91bmQgYmV0dGVyIGJlY2F1c2UgSSBoYXZlIGJlZW4gc3Ry dWdnbGluZyB3aXRoIGhvdyBvbmUgY2FuIGluY3JlbWVudGFsbHkgZGVwbG95IHNvbWV0aGluZyBs aWtlIGNvbm5lY3Rpb24gbWlncmF0aW9uIG9uIGN1cnJlbnQgbG9hZCBiYWxhbmNlcnMuIEJ1dCB0 aGF04oCZcyBmb3IgYSBzZXBhcmF0ZSB0aHJlYWQuDQoNCkZyb206IEphbmEgSXllbmdhciBbbWFp bHRvOmpyaUBnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4IDM6MzIg UE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCkNj OiBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPjsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hl QGFrYW1haS5jb20+OyBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT47IFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNClByYXZl ZW4sDQoNClRoYXQgd2FzIHByZWNpc2VseSBteSBwb2ludCBhYm91dCB0aGUgZWNvc3lzdGVtIGV2 b2x2aW5nLiBOb3cgdGhhdCB3ZSBoYXZlIHRoZSBhYmlsaXR5IHRvIGNsYXNzaWZ5IGZsb3dzLCB2 YXJpb3VzIHRoaW5ncyBoYXZlIGJlZW4gYnVpbHQgYXJvdW5kIGJlaW5nIGFibGUgdG8gdGVsbCBU Q1AgZmxvd3MuIFRoaXMgb2J2aW91c2x5IGhhcyBiZW5lZml0cyBhcyB5b3UgcG9pbnQgb3V0LCBi dXQgdGhlIGRvd25zaWRlIGlzIHRoYXQgdGhhdCBJIGNhbid0IGdldCBnb29kIG5ldHdvcmsgdXRp bGl6YXRpb24gd2l0aCBhIHNpbmdsZSBmbG93LiBJIHVuZGVyc3RhbmQgdGhlIHNjYWxpbmcgcG9p bnQsIGJ1dCBzcGVha2luZyBvZiBjb21tb24gY2FzZXMsIGFueSBzZXJ2ZXIgaW4gdGhlIHdpbGQg aXMgdXN1YWxseSBzZXJ2aW5nIGEgbGFyZ2UgbnVtYmVyIG9mIGNvbm5lY3Rpb25zIGF0IG1vZGVy YXRlIHNwZWVkcywgbm90IGEgc2luZ2xlIG9uZSBhdCAyNS0zNSBHYnBzLi4uIHdoaWNoIG1ha2Vz IHRoYXQgc29ydCBvZiBzY2FsaW5nIGxlc3MgZXhjaXRpbmcgdGhhbiBpbiBhIG1pY3JvYmVuY2ht YXJrLg0KDQpGV0lXLCB0aGUgb3RoZXIgZG93bnNpZGUgb2YgRUNNUCBpcyB0aGF0IG11bHRpcGF0 aCB0cmFuc3BvcnQgZG9lc24ndCB3b3JrIC0tIHlvdSBuZWVkIHRvIGhhc2ggb24gc29tZXRoaW5n IGVsc2UgYmVzaWRlcyB0aGUgNC10dXBsZS4gKFdlIGhhZCB0byB3b3JrIGFyb3VuZCB0aGlzIGlu IEdvb2dsZSdzIGRlcGxveW1lbnQgb2YgY29ubmVjdGlvbiBtaWdyYXRpb24uKQ0KDQpJJ2xsIGRp c2FncmVlIHdpdGggeW91ciBwb2ludCBhYm91dCByZW9yZGVyaW5nIGJlaW5nIHRoZSB1bmNvbW1v biBjYXNlLiBXaGlsZSB0aGF0J3MgdHJ1ZSB0b2RheSwgdGhpcyBpcyBhZ2FpbiBhbiBleHBlY3Rh dGlvbiB0aGF0IHRoZSBuZXR3b3JrIHdvcmtzIGhhcmQgdG8gbWFpbnRhaW4sIHRob3VnaCB0aGUg ZWNvc3lzdGVtIGFuZCB3aGF0IHdlIGV4cGVjdCBhcyAidXN1YWwiIHdvdWxkIGJlIHF1aXRlIGRp ZmZlcmVudCBoYWQgd2Ugbm90IGJ1aWx0IFRDUCdzIHJlcXVpcmVtZW50cyBpbnRvIHRoZSBuZXR3 b3JrLiBUaGVyZSdzIG5vdGhpbmcgd3Jvbmcgd2l0aCBoYXZpbmcgbi1tb2RhbCBsYXRlbmNpZXMu Li4gd2UgY2FuIGVuZ2luZWVyIGFyb3VuZCB0aGF0LiBBbnkgc2Vuc2libGUgbG9hZCBkaXN0cmli dXRpb24gc2NoZW1lIHdpdGhpbiB0aGUgbmV0d29yayB3aWxsIGdpdmUgeW91IGluY3JlYXNlZCB2 YXJpYW5jZSBidXQgaXQgc2hvdWxkIGxpbWl0IHRoZSB3b3JzdC1jYXNlIGxhdGVuY3kuIFlvdSdk IHBlcmhhcHMgYWdyZWUgdGhhdCB0aGF0J3MgYSBuZXQgd2luLg0KDQpUaGlzIHdhcyBhbiBleGFt cGxlIG9mIGhvdyBleHBvc2luZyBwYWNrZXQgbnVtYmVyIG9yIG5vdCBjYW4gaGF2ZSBsb25nIHRl cm0gZWNvc3lzdGVtIGVmZmVjdHMuIE15IHBvaW50IHdhcyBhYm91dCB0aGUgZmFjdCB0aGF0IGV4 cG9zaW5nIGNhbiBjYXVzZSBvc3NpZmljYXRpb24uDQoNCi0gamFuYQ0KDQpPbiBNb24sIEZlYiA1 LCAyMDE4IGF0IDk6MjQgQU0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3Nv ZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+PiBUaGlzIHdhcyBk ZWZpbml0ZWx5IHRydWUgZm9yIGltcGxlbWVudGF0aW9ucyBvZiBUQ1AsIGJ1dCB0aGF0IGlzIFRD UCdzIHByb2JsZW0sIG5vdCB0aGUgbmV0d29yaydzDQpGbG93IGNsYXNzaWZpY2F0aW9uIGhhcHBl bnMgdGhyb3VnaCB0aGUgbmV0d29yayBhbmQgYWxzbyBvbiB0aGUgZW5kIGhvc3Qgd2l0aCBSU1Mg d2hlcmUgYSBmbG93IGlzIG1hcHBlZCB0byBhIGNvcmUuIFRoaXMgYWxsb3dzIGZvciBidWlsZGlu ZyBoaWdoIHBlcmZvcm1hbmNlIHJlY2VpdmUgcHJvY2Vzc2luZyB0aGF0IGNvdWxkIGJlIGxvY2sg ZnJlZSBmb3IgdGhlIG1vc3QgcGFydC4gVGhlIG9ubHkgZG93bnNpZGUgb2YgRUNNUCBvbiB0aGUg bmV0d29yayBhbmQgUlNTIG9uIHRoZSBDUFUgaXMgdGhhdCBhIHNpbmdsZSBmbG93IHdpbGwgbm90 IHRha2UgbXVsdGlwbGUgcGF0aHMgb3IgZ2V0IHByb2Nlc3NlZCBvbiBtb3JlIHRoYW4gb25lIGNv cmUuIFdpbmRvd3Mgb24gc2VydmVyIG1hY2hpbmVzIHRvZGF5IGNhbiBzYXR1cmF0ZSAyNS0zNSBH YnBzIGZvciBhIHNpbmdsZSBUQ1AgY29ubmVjdGlvbiBiZWZvcmUgYmVpbmcgQ1BVIGxpbWl0ZWQu IFRoaXMgaXMgYSAgcmVhc29uYWJsZSB0cmFkZSBvZmYgYmVjYXVzZSBJIGRvbuKAmXQga25vdyBv ZiBjYXNlcyB3aGVyZSBhIHNpbmdsZSBmbG93IGlzIGRyaXZpbmcgbW9yZSB0aGFuIHRoYXQgYW1v dW50IG9mIHRyYWZmaWMuIEFzc3VtcHRpb25zIGFib3V0IGhvdyBmbG93cyBnZXQgY2xhc3NpZmll ZCBoZWxwIG1ha2UgZm9yIG1vcmUgZWZmaWNpZW50IHByb2Nlc3NpbmcuIFRoZXkgYWxzbyBsZWFk IHRvIGNvbnNpc3RlbnQgbGF0ZW5jeS4gWW91IGRvIG5vdCB3YW50IHRoZSB0cmFmZmljIHRvIHRh a2UgYSBiaS1tb2RhbCBvciBOLW1vZGFsIHBhdGhzIChvbiB0aGUgbmV0d29yayBvciB0aGUgaG9z dCkgdG8gYmVpbmcgcHJvY2Vzc2VkIGJlY2F1c2UgdGhlIGZsdWN0dWF0aW9ucyBpbiBsYXRlbmN5 IHdpbGwgaHVydCB0aGUgd29ya2xvYWQuIEkgYW0gbm90IGFyZ3VpbmcgZm9yIFRDUCBub3QgYmVp bmcgcmVzaWxpZW50IHRvIHJlb3JkZXJpbmcgYnV0IElNTyB0aGF0IHNob3VsZCBiZSB0aGUgdW5j b21tb24gY2FzZSBub3QgdGhlIGNvbW1vbiBjYXNlLiBXaXRoIFFVSUMgaWYgc3RyZWFtcyB3ZXJl IGV4cG9zZWQgb24gdGhlIG5ldHdvcmsgeW91IGNvdWxkIHRha2UgYWR2YW50YWdlIG9mIHN0cmVh bSBsZXZlbCBFQ01QIGFuZCBSU1MgdG8gc2NhbGUgYmV0dGVyIHRoYW4gVENQIGJ1dCB3ZSBoYXZl IGNob3NlbiB0byBrZWVwIHRoZSA0LXR1cGxlIChvciB0aGUgNS10dXBsZSkgYXMgdGhlIGZsb3cg Y2xhc3NpZmllciBvbiB0aGUgbmV0d29yayB3aGljaCBpcyBvayBieSBtZSBzaW5jZSBpdCBsZWFk cyB0byBUQ1AgcGFyaXR5Lg0KDQpUaGFua3MNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9m IEphbmEgSXllbmdhcg0KU2VudDogU3VuZGF5LCBGZWJydWFyeSA0LCAyMDE4IDg6MzUgUE0NClRv OiBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpyc2FsekBha2FtYWkuY29tPj4N CkNjOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVA YWthbWFpLmNvbT4+OyBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbTxtYWlsdG86ZmVuaXhAZmIu Y29tPj47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpQcml2YWN5LXByb3RlY3Rpb24g Y2FuJ3QgYmUgYSB1c2VyIGNob2ljZSwgZm9yIHRoZSByZWFzb25zIG90aGVycyBoYXZlIG5vdGVk IG9uIHRoaXMgdGhyZWFkLg0KDQpUaGF0IHNhaWQsIG15IHByaW1hcnkgYXJndW1lbnQgaXMgZm9y IGVuY3J5cHRpb24gdG8gYXZvaWQgb3NzaWZpY2F0aW9uLiBOb3QgdGhhdCBpdCBtYXR0ZXJzIG5v dywgYnV0IEknbGwgbm90ZSB0aGF0IG11Y2ggb2YgR1FVSUMncyBvcmlnaW5hbCBtb3RpdmF0aW9u IGZvciBlbmNyeXB0aW5nIGhlYWRlcnMgd2FzIHRvIGF2b2lkIG9zc2lmaWNhdGlvbi4NCg0KSSds bCByZWl0ZXJhdGUgdGhhdCBmaWVsZHMgd2UgZXhwb3NlIHdpbGwgZ2V0IG9zc2lmaWVkIGFuZCB0 aGVyZSBhcmUgbG9uZy10ZXJtIGVjb3N5c3RlbSBlZmZlY3RzIHRvIHRoaXMuIExldCBtZSBpbGx1 c3RyYXRlIHRoaXMgd2l0aCBwcmVjaXNlbHkgdGhlIHBhY2tldCBudW1iZXIgZmllbGQuIE1pZGRs ZWJveGVzIGNvbW1vbmx5IGFzc3VtZSB0aGF0IGEgVENQIGZsb3cgY2FuIG9ubHkgaGFuZGxlIHBh Y2tldHMgaW4tb3JkZXIuIFRoaXMgYXNzdW1wdGlvbiBjb21lcyBmcm9tIHRoZSBmYWN0IHRoYXQg VENQIGltcGxlbWVudGF0aW9ucyBnZXQgcG9vciBwZXJmb3JtYW5jZSB3aGVuIHBhY2tldHMgYXJl IHJlb3JkZXJlZC4gVGhpcyB3YXMgZGVmaW5pdGVseSB0cnVlIGZvciBpbXBsZW1lbnRhdGlvbnMg b2YgVENQLCBidXQgdGhhdCBpcyBUQ1AncyBwcm9ibGVtLCBub3QgdGhlIG5ldHdvcmsncy4gSG93 ZXZlciwgYWxtb3N0IGFsbCBsb2FkLWJhbGFuY2VycyBJIGtub3cgb2Ygbm93IHdpbGwgcGluIGFs bCBwYWNrZXRzIHdpdGhpbiBhIFRDUCBmbG93IHRvIG9uZSBwYXRoLCBsZWFkaW5nIHRvIHN1Yi1v cHRpbWFsIHBlcmZvcm1hbmNlIGluIHRoZSBuZXR3b3JrLCBhbmQgZGVzdHJveWluZyBpbmNlbnRp dmVzIGZvciB0aGUgZW5kcG9pbnRzIHRvIGRlcGxveSByZW9yZGVyaW5nLXJlc2lsaWVudCBUQ1Ag aW1wbGVtZW50YXRpb25zIChldmVuIHRob3VnaCB0aGVyZSBhcmUgcGxlbnR5IG9mIHdheXMgb2Yg ZG9pbmcgdGhpcy4pDQoNCkV4cG9zaW5nIFFVSUMncyBwYWNrZXQgbnVtYmVyIGZpZWxkIChhcyBh bnkgZmllbGQpIGlzIGxpa2VseSB0byBoYXZlIHNpbWlsYXIgY29uc2VxdWVuY2VzIGFuZCBhIHNp bWlsYXIgZWNvc3lzdGVtIGFyYy4NCg0KDQpPbiBTdW4sIEZlYiA0LCAyMDE4IGF0IDc6NTEgUE0s IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3 cm90ZToNCg0KPiBPcHRpb25hbCBzZWN1cml0eSB0ZW5kcyB0byBkZXZvbHZlIHRvIG5vbi1zZWN1 cmUuDQoNCg0KDQpUaGF04oCZcyBhIGdyZWF0IGFwaG9yaXNtLiAgQW5kIHNhZGx5IGFsbCB0b28g dHJ1ZS4NCg0KDQo= --_000_CY4PR21MB0133BD233AFD371388060D24B6FD0CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubTIwODA3NTkyNDExNzIwOTY5NzFt LTc5MTQ4NzYwODI0MjU3ODUwNHhtc29ub3JtYWwsIGxpLm0yMDgwNzU5MjQxMTcyMDk2OTcxbS03 OTE0ODc2MDgyNDI1Nzg1MDR4bXNvbm9ybWFsLCBkaXYubTIwODA3NTkyNDExNzIwOTY5NzFtLTc5 MTQ4NzYwODI0MjU3ODUwNHhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6bV8yMDgwNzU5MjQx MTcyMDk2OTcxbS03OTE0ODc2MDgyNDI1Nzg1MDR4bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ3JlZSBvbiB0aGUgcG9pbnQg YWJvdXQgb3NzaWZpY2F0aW9uIGFuZCBsb25nIHRlcm0gZWZmZWN0cyBvbiBlY29zeXN0ZW0uIEkg d2FzIGp1c3QgcG9pbnRpbmcgb3V0IHRoYXQgdGhlIGN1cnJlbnQgZmxvdyBjbGFzc2lmaWNhdGlv biBzY2hlbWUgaGFzIHNvbWUgYmVuZWZpdHMgdG9vIHNvIHRoZXJlIGFyZSB0cmFkZS1vZmZzLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmZ3Q7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIy MjIyO2JhY2tncm91bmQ6d2hpdGUiPiB5b3UgbmVlZCB0byBoYXNoIG9uIHNvbWV0aGluZyBlbHNl IGJlc2lkZXMgdGhlIDQtdHVwbGUuIChXZSBoYWQgdG8gd29yayBhcm91bmQgdGhpcyBpbiBHb29n bGUncyBkZXBsb3ltZW50IG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhl IHdvcmthcm91bmQgYmV0dGVyIGJlY2F1c2UgSSBoYXZlIGJlZW4gc3RydWdnbGluZyB3aXRoIGhv dyBvbmUgY2FuIGluY3JlbWVudGFsbHkgZGVwbG95IHNvbWV0aGluZyBsaWtlIGNvbm5lY3Rpb24g bWlncmF0aW9uIG9uIGN1cnJlbnQgbG9hZCBiYWxhbmNlcnMuIEJ1dCB0aGF04oCZcyBmb3IgYSBz ZXBhcmF0ZSB0aHJlYWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBKYW5h IEl5ZW5nYXIgW21haWx0bzpqcmlAZ29vZ2xlLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgRmVicnVhcnkgNSwgMjAxOCAzOjMyIFBNPGJyPg0KPGI+VG86PC9iPiBQcmF2ZWVuIEJhbGFz dWJyYW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFNh bHosIFJpY2ggJmx0O3JzYWx6QGFrYW1haS5jb20mZ3Q7OyBMdWJhc2hldiwgSWdvciAmbHQ7aWx1 YmFzaGVAYWthbWFpLmNvbSZndDs7IFJvYmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29tJmd0Ozsg UVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBh Y2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UHJh dmVlbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj5UaGF0IHdhcyBwcmVjaXNlbHkg bXkgcG9pbnQgYWJvdXQgdGhlIGVjb3N5c3RlbSBldm9sdmluZy4gTm93IHRoYXQgd2UgaGF2ZSB0 aGUgYWJpbGl0eSB0byBjbGFzc2lmeSBmbG93cywgdmFyaW91cyB0aGluZ3MgaGF2ZSBiZWVuIGJ1 aWx0IGFyb3VuZCBiZWluZyBhYmxlIHRvIHRlbGwNCiBUQ1AgZmxvd3MuIFRoaXMgb2J2aW91c2x5 IGhhcyBiZW5lZml0cyBhcyB5b3UgcG9pbnQgb3V0LCBidXQgdGhlIGRvd25zaWRlIGlzIHRoYXQg dGhhdCBJIGNhbid0IGdldCBnb29kIG5ldHdvcmsgdXRpbGl6YXRpb24gd2l0aCBhIHNpbmdsZSBm bG93LiBJIHVuZGVyc3RhbmQgdGhlIHNjYWxpbmcgcG9pbnQsIGJ1dCBzPHNwYW4gc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPnBlYWtpbmcgb2YgY29tbW9uIGNhc2VzLCBhbnkgc2VydmVyIGluIHRo ZSB3aWxkDQogaXMgdXN1YWxseSBzZXJ2aW5nIGEgbGFyZ2UgbnVtYmVyIG9mIGNvbm5lY3Rpb25z IGF0IG1vZGVyYXRlIHNwZWVkcywgbm90IGEgc2luZ2xlIG9uZSBhdCAyNS0zNSBHYnBzLi4uIHdo aWNoIG1ha2VzIHRoYXQgc29ydCBvZiBzY2FsaW5nIGxlc3MgZXhjaXRpbmcgdGhhbiBpbiBhIG1p Y3JvYmVuY2htYXJrLjwvc3Bhbj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5GV0lXLCB0 aGUgb3RoZXIgZG93bnNpZGUgb2YgRUNNUCBpcyB0aGF0IG11bHRpcGF0aCB0cmFuc3BvcnQgZG9l c24ndCB3b3JrIC0tIHlvdSBuZWVkIHRvIGhhc2ggb24gc29tZXRoaW5nIGVsc2UgYmVzaWRlcyB0 aGUgNC10dXBsZS4gKFdlIGhhZCB0bw0KIHdvcmsgYXJvdW5kIHRoaXMgaW4gR29vZ2xlJ3MgZGVw bG95bWVudCBvZiBjb25uZWN0aW9uIG1pZ3JhdGlvbi4pPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzIyMjIyMiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdsbCBkaXNhZ3JlZSB3aXRoIHlvdXIg cG9pbnQgYWJvdXQgcmVvcmRlcmluZyBiZWluZyB0aGUgdW5jb21tb24gY2FzZS4gV2hpbGUgdGhh dCdzIHRydWUgdG9kYXksIHRoaXMgaXMgYWdhaW4gYW4gZXhwZWN0YXRpb24gdGhhdCB0aGUgbmV0 d29yayB3b3JrcyBoYXJkIHRvIG1haW50YWluLCB0aG91Z2ggdGhlIGVjb3N5c3RlbSBhbmQgd2hh dCB3ZSBleHBlY3QgYXMgJnF1b3Q7dXN1YWwmcXVvdDsgd291bGQgYmUgcXVpdGUgZGlmZmVyZW50 DQogaGFkIHdlIG5vdCBidWlsdCBUQ1AncyByZXF1aXJlbWVudHMgaW50byB0aGUgbmV0d29yay4g VGhlcmUncyBub3RoaW5nIHdyb25nIHdpdGggaGF2aW5nIG4tbW9kYWwgbGF0ZW5jaWVzLi4uIHdl IGNhbiBlbmdpbmVlciBhcm91bmQgdGhhdC4gQW55IHNlbnNpYmxlIGxvYWQgZGlzdHJpYnV0aW9u IHNjaGVtZSB3aXRoaW4gdGhlIG5ldHdvcmsgd2lsbCBnaXZlIHlvdSBpbmNyZWFzZWQgdmFyaWFu Y2UgYnV0IGl0IHNob3VsZCBsaW1pdCB0aGUgd29yc3QtY2FzZQ0KIGxhdGVuY3kuIFlvdSdkIHBl cmhhcHMgYWdyZWUgdGhhdCB0aGF0J3MgYSBuZXQgd2luLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdhcyBhbiBleGFtcGxlIG9mIGhv dyBleHBvc2luZyBwYWNrZXQgbnVtYmVyIG9yIG5vdCBjYW4gaGF2ZSBsb25nIHRlcm0gZWNvc3lz dGVtIGVmZmVjdHMuIE15IHBvaW50IHdhcyBhYm91dCB0aGUgZmFjdCB0aGF0IGV4cG9zaW5nIGNh biBjYXVzZSBvc3NpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPi0gamFuYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEZlYiA1LCAyMDE4IGF0IDk6MjQgQU0sIFBy YXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jmd0OyZndDsgVGhpcyB3YXMgZGVmaW5pdGVseSB0cnVlIGZvciBpbXBsZW1lbnRh dGlvbnMgb2YgVENQLCBidXQgdGhhdCBpcyBUQ1AncyBwcm9ibGVtLCBub3QgdGhlIG5ldHdvcmsn czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5GbG93IGNsYXNzaWZpY2F0 aW9uIGhhcHBlbnMgdGhyb3VnaCB0aGUgbmV0d29yayBhbmQgYWxzbyBvbiB0aGUgZW5kIGhvc3Qg d2l0aCBSU1Mgd2hlcmUgYSBmbG93IGlzIG1hcHBlZCB0byBhIGNvcmUuIFRoaXMgYWxsb3dzIGZv ciBidWlsZGluZyBoaWdoIHBlcmZvcm1hbmNlIHJlY2VpdmUgcHJvY2Vzc2luZw0KIHRoYXQgY291 bGQgYmUgbG9jayBmcmVlIGZvciB0aGUgbW9zdCBwYXJ0LiBUaGUgb25seSBkb3duc2lkZSBvZiBF Q01QIG9uIHRoZSBuZXR3b3JrIGFuZCBSU1Mgb24gdGhlIENQVSBpcyB0aGF0IGEgc2luZ2xlIGZs b3cgd2lsbCBub3QgdGFrZSBtdWx0aXBsZSBwYXRocyBvciBnZXQgcHJvY2Vzc2VkIG9uIG1vcmUg dGhhbiBvbmUgY29yZS4gV2luZG93cyBvbiBzZXJ2ZXIgbWFjaGluZXMgdG9kYXkgY2FuIHNhdHVy YXRlIDI1LTM1IEdicHMgZm9yIGENCiBzaW5nbGUgVENQIGNvbm5lY3Rpb24gYmVmb3JlIGJlaW5n IENQVSBsaW1pdGVkLiBUaGlzIGlzIGEgJm5ic3A7cmVhc29uYWJsZSB0cmFkZSBvZmYgYmVjYXVz ZSBJIGRvbuKAmXQga25vdyBvZiBjYXNlcyB3aGVyZSBhIHNpbmdsZSBmbG93IGlzIGRyaXZpbmcg bW9yZSB0aGFuIHRoYXQgYW1vdW50IG9mIHRyYWZmaWMuIEFzc3VtcHRpb25zIGFib3V0IGhvdyBm bG93cyBnZXQgY2xhc3NpZmllZCBoZWxwIG1ha2UgZm9yIG1vcmUgZWZmaWNpZW50IHByb2Nlc3Np bmcuDQogVGhleSBhbHNvIGxlYWQgdG8gY29uc2lzdGVudCBsYXRlbmN5LiBZb3UgZG8gbm90IHdh bnQgdGhlIHRyYWZmaWMgdG8gdGFrZSBhIGJpLW1vZGFsIG9yIE4tbW9kYWwgcGF0aHMgKG9uIHRo ZSBuZXR3b3JrIG9yIHRoZSBob3N0KSB0byBiZWluZyBwcm9jZXNzZWQgYmVjYXVzZSB0aGUgZmx1 Y3R1YXRpb25zIGluIGxhdGVuY3kgd2lsbCBodXJ0IHRoZSB3b3JrbG9hZC4gSSBhbSBub3QgYXJn dWluZyBmb3IgVENQIG5vdCBiZWluZyByZXNpbGllbnQgdG8NCiByZW9yZGVyaW5nIGJ1dCBJTU8g dGhhdCBzaG91bGQgYmUgdGhlIHVuY29tbW9uIGNhc2Ugbm90IHRoZSBjb21tb24gY2FzZS4gV2l0 aCBRVUlDIGlmIHN0cmVhbXMgd2VyZSBleHBvc2VkIG9uIHRoZSBuZXR3b3JrIHlvdSBjb3VsZCB0 YWtlIGFkdmFudGFnZSBvZiBzdHJlYW0gbGV2ZWwgRUNNUCBhbmQgUlNTIHRvIHNjYWxlIGJldHRl ciB0aGFuIFRDUCBidXQgd2UgaGF2ZSBjaG9zZW4gdG8ga2VlcCB0aGUgNC10dXBsZSAob3IgdGhl IDUtdHVwbGUpDQogYXMgdGhlIGZsb3cgY2xhc3NpZmllciBvbiB0aGUgbmV0d29yayB3aGljaCBp cyBvayBieSBtZSBzaW5jZSBpdCBsZWFkcyB0byBUQ1AgcGFyaXR5Lg0KPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206 PC9iPiBRVUlDIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkphbmEgSXllbmdhcjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEZlYnJ1YXJ5IDQs IDIwMTggODozNSBQTTxicj4NCjxiPlRvOjwvYj4gU2FseiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFp bHRvOnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5yc2FsekBha2FtYWkuY29tPC9h PiZndDs8YnI+DQo8Yj5DYzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86 aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208 L2E+Jmd0OzsgUm9iZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29tIiB0 YXJnZXQ9Il9ibGFuayI+ZmVuaXhAZmIuY29tPC9hPiZndDs7IFFVSUMgV0cgJmx0OzxhIGhyZWY9 Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Qcml2YWN5LXByb3RlY3Rpb24gY2FuJ3Qg YmUgYSB1c2VyIGNob2ljZSwgZm9yIHRoZSByZWFzb25zIG90aGVycyBoYXZlIG5vdGVkIG9uIHRo aXMgdGhyZWFkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpUaGF0IHNhaWQsIG15IHByaW1hcnkgYXJndW1lbnQg aXMgZm9yIGVuY3J5cHRpb24gdG8gYXZvaWQgb3NzaWZpY2F0aW9uLiBOb3QgdGhhdCBpdCBtYXR0 ZXJzIG5vdywgYnV0IEknbGwgbm90ZSB0aGF0IG11Y2ggb2YgR1FVSUMncyBvcmlnaW5hbCBtb3Rp dmF0aW9uIGZvciBlbmNyeXB0aW5nIGhlYWRlcnMgd2FzIHRvIGF2b2lkIG9zc2lmaWNhdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkknbGwgcmVpdGVyYXRlIHRoYXQgZmllbGRzIHdlIGV4cG9zZSB3aWxsIGdldCBvc3NpZmllZCBh bmQgdGhlcmUgYXJlIGxvbmctdGVybSBlY29zeXN0ZW0gZWZmZWN0cyB0byB0aGlzLiBMZXQgbWUg aWxsdXN0cmF0ZSB0aGlzIHdpdGggcHJlY2lzZWx5IHRoZSBwYWNrZXQgbnVtYmVyIGZpZWxkLiBN aWRkbGVib3hlcw0KIGNvbW1vbmx5IGFzc3VtZSB0aGF0IGEgVENQIGZsb3cgY2FuIG9ubHkgaGFu ZGxlIHBhY2tldHMgaW4tb3JkZXIuIFRoaXMgYXNzdW1wdGlvbiBjb21lcyBmcm9tIHRoZSBmYWN0 IHRoYXQgVENQIGltcGxlbWVudGF0aW9ucyBnZXQgcG9vciBwZXJmb3JtYW5jZSB3aGVuIHBhY2tl dHMgYXJlIHJlb3JkZXJlZC4gVGhpcyB3YXMgZGVmaW5pdGVseSB0cnVlIGZvciBpbXBsZW1lbnRh dGlvbnMgb2YgVENQLCBidXQgdGhhdCBpcyBUQ1AncyBwcm9ibGVtLA0KIG5vdCB0aGUgbmV0d29y aydzLiBIb3dldmVyLCBhbG1vc3QgYWxsIGxvYWQtYmFsYW5jZXJzIEkga25vdyBvZiBub3cgd2ls bCBwaW4gYWxsIHBhY2tldHMgd2l0aGluIGEgVENQIGZsb3cgdG8gb25lIHBhdGgsIGxlYWRpbmcg dG8gc3ViLW9wdGltYWwgcGVyZm9ybWFuY2UgaW4gdGhlIG5ldHdvcmssIGFuZCBkZXN0cm95aW5n IGluY2VudGl2ZXMgZm9yIHRoZSBlbmRwb2ludHMgdG8gZGVwbG95IHJlb3JkZXJpbmctcmVzaWxp ZW50IFRDUCBpbXBsZW1lbnRhdGlvbnMNCiAoZXZlbiB0aG91Z2ggdGhlcmUgYXJlIHBsZW50eSBv ZiB3YXlzIG9mIGRvaW5nIHRoaXMuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RXhwb3NpbmcgUVVJQydzIHBhY2tldCBudW1iZXIgZmll bGQgKGFzIGFueSBmaWVsZCkgaXMgbGlrZWx5IHRvIGhhdmUgc2ltaWxhciBjb25zZXF1ZW5jZXMg YW5kIGEgc2ltaWxhciBlY29zeXN0ZW0gYXJjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPk9uIFN1biwgRmViIDQsIDIwMTggYXQgNzo1MSBQTSwgU2FseiwgUmljaCAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5yc2FsekBha2Ft YWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDsgT3B0aW9uYWwgc2VjdXJpdHkg dGVuZHMgdG8gZGV2b2x2ZSB0byBub24tc2VjdXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im0yMDgwNzU5MjQxMTcy MDk2OTcxbS03OTE0ODc2MDgyNDI1Nzg1MDR4bXNvbm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJtMjA4MDc1OTI0MTE3MjA5Njk3MW0tNzkxNDg3NjA4MjQyNTc4NTA0eG1z b25vcm1hbCI+VGhhdOKAmXMgYSBncmVhdCBhcGhvcmlzbS4mbmJzcDsgQW5kIHNhZGx5IGFsbCB0 b28gdHJ1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_CY4PR21MB0133BD233AFD371388060D24B6FD0CY4PR21MB0133namp_-- From nobody Mon Feb 5 19:13:23 2018 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 DB88A124319 for ; Mon, 5 Feb 2018 19:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 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_H5=-1, 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=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 XXvGdU5U-XkY for ; Mon, 5 Feb 2018 19:13:18 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0139.outbound.protection.outlook.com [104.47.40.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EE5120227 for ; Mon, 5 Feb 2018 19:13:18 -0800 (PST) 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=DuLbLRROQZgrjF2s1yMAjTwJdO8VRIR5qgCf6MGlzlU=; b=nO/f0y1d1qe7fpms2uil9u6zHvFy00Ep5+ZCdCDnnZKT0eTVFJ6GI69A+KHMlZA8gsbi3pwSgBpPyhvqtflJHpAnpTLdMAOlY0mdEtnHMPmyajWCr8GZ0bKthZzSmUuY6NShaNqam2Psnlcs07Fyii94ilyHIZ+fxwvWw391UvU= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0181.namprd21.prod.outlook.com (10.173.193.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.485.0; Tue, 6 Feb 2018 03:13:16 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Tue, 6 Feb 2018 03:13:16 +0000 From: Praveen Balasubramanian To: Jana Iyengar CC: "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , QUIC WG Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgAArugA= Date: Tue, 6 Feb 2018 03:13:16 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0181; 7:Vr+1anfvTEetHewvWiQvB+u8PQIjK1wtmFEPWZSy5iQnvzoSr9jv6QhrfRCl5pan5p40Cqo+eNoFBsB12AhQxZLnTnVozMSeqb1NmAlZmWUmKUukubhLRVDw0IYR1jzNezDGI6aP/c2G1PiI5XmfRwGuIRORkBa6GMBszNJpMCW7bLHSiod2wkhRtCQIHZcaiaZ5B7hUlNEH2zFdzFx9u1OXHY/ktz5rMvqjDjXdSroEOk6G+bBp7HCHfnTE073p x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 83128637-6701-46c6-ddca-08d56d0f90f8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:CY4PR21MB0181; x-ms-traffictypediagnostic: CY4PR21MB0181: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(192374486261705)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0181; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0181; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(366004)(396003)(346002)(39860400002)(189003)(199004)(3280700002)(102836004)(53546011)(2906002)(6506007)(76176011)(7116003)(6436002)(5660300001)(7696005)(2900100001)(229853002)(59450400001)(105586002)(54906003)(33656002)(93886005)(6916009)(2950100002)(74316002)(22452003)(19609705001)(7736002)(68736007)(790700001)(6116002)(316002)(478600001)(99286004)(106356001)(86612001)(4326008)(10290500003)(186003)(53936002)(86362001)(3480700004)(81166006)(81156014)(8676002)(14454004)(6246003)(97736004)(8990500004)(8936002)(3660700001)(236005)(6306002)(54896002)(9686003)(77096007)(55016002)(25786009)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0181; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: qw9kTDe/q0VR7Xr4fmwckdFikrQ4uVQe1SnrgWlJO+JC6rUp/t4gM3ijKVk/6kU3V5VqU9D5O5/GPk9qUEOnCQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01336FF451F8E4A3CF013E47B6FD0CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 83128637-6701-46c6-ddca-08d56d0f90f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 03:13:16.6088 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0181 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, 06 Feb 2018 03:13:22 -0000 --_000_CY4PR21MB01336FF451F8E4A3CF013E47B6FD0CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgb3BpbmlvbiBpcyBmb3IgMSBvdmVyIDIgYnV0IEkgY2FuIGxpdmUgd2l0aCBlaXRoZXIuIFRo ZSBtYWluIGNvbmNlcm4gaXMgY29zdCBvZiBhbm90aGVyIGVuY3J5cHRpb24gLyBkZWNyeXB0aW9u IHN0ZXAsIHNvIHRoZSBiZW5lZml0IG9mIDIgb3ZlciAxIHNob3VsZCBiZSBkZW1vbnN0cmFibHkg YmV0dGVyIG9uIG9uZSBvZiBvc3NpZmljYXRpb24sIHByaXZhY3ksIG9yIG1hbmFnZWFiaWxpdHku DQoNCkZyb206IEphbmEgSXllbmdhciBbbWFpbHRvOmpyaUBnb29nbGUuY29tXQ0KU2VudDogTW9u ZGF5LCBGZWJydWFyeSA1LCAyMDE4IDQ6MzEgUE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh biA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCkNjOiBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29t PjsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+OyBSb2JlcnRvIFBlb24gPGZl bml4QGZiLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUGFja2V0 IG51bWJlciBlbmNyeXB0aW9uDQoNCkkgZG9uJ3QgdGhpbmsgd2UncmUgY29udmVyZ2luZyBoZXJl LCBzbyBJJ2QgbGlrZSB0byB0cnkgYW5kIGVuY291cmFnZSB1cyB0byBtb3ZlIHRvd2FyZHMgaXQu IEkgaGF2ZSBteSBvcGluaW9uLCBidXQgSSBjYXJlIG1vcmUgYWJvdXQgZm9yd2FyZCBwcm9ncmVz cyBhdCB0aGlzIHBvaW50Lg0KDQpUaGVyZSBhcmUgdGhyZWUgZGVzaWducyBzbyBmYXI6DQoxLiBQ YWNrZXQgbnVtYmVycyBhcyBpcywgd2l0aCByYW5kb20gZ2FwcyBhcm91bmQgbWlncmF0aW9uLg0K Mi4gUGFja2V0IG51bWJlcnMgZW5jcnlwdGVkLCBhcyBwZXIgTWFydGluJ3MgUFIuDQozLiBQYWNr ZXQgbnVtYmVycyBlbmNyeXB0ZWQsIHBsdXMgYSBzbWFsbCBtb2R1bG8gc2VxdWVuY2UgbnVtYmVy IHNvbWV3aGVyZS4NCg0KVGhlIGNvbmNyZXRlIG9uZXMgaGVyZSBhcmUgKDEpIGFuZCAoMikuICBJ J20gbGlzdGluZyAoMykgYnV0IGFtIG5vdCBpbmNsaW5lZCB0byBjb25zaWRlciBpdCBzZXJpb3Vz bHksIHNpbmNlIGl0J3Mgbm90IGNvbmNyZXRlIGVub3VnaCwgKGFuZCBJIGRvbid0IHdhbnQgbW9y ZSBiaXRzIHRvIGJlIHNwZW50IGluIHRoZSBRVUlDIHBhY2tldCBoZWFkZXIgaWYgdGhhdCdzIHdo ZXJlIHRoaXMgaW5mbyBnb2VzLikNCg0KVGhlcmUgYXJlIG9waW5pb25zIGFib3V0IG9zc2lmaWNh dGlvbiwgcHJpdmFjeSwgYW5kIG1hbmFnZWFiaWxpdHkuIEknbSBub3QgaGVhcmluZyBibG9vZHkg bXVyZGVyLCBzbyBmb3Igd2hhdCBpdCdzIHdvcnRoLCBJJ2QgbGlrZSB0byBzdGlwdWxhdGUgZmly c3QgdGhhdCB3ZSBjYW4gYWxsIGxpdmUgd2l0aCB0aGUgZmluYWwgZGVzaWduLCB3aGljaGV2ZXIg b25lIGl0IGlzLiAgSWYgYW55b25lIGRpc2FncmVlcywgcGxlYXNlIHNheSBzbyAtLSBJIHRoaW5r IGl0J2QgYmUgdXNlZnVsIHRvIGhlYXIgaWYgdGhlcmUgYXJlIGZvbGtzIHdobyB0aGluayBhIHBh cnRpY3VsYXIgZGVzaWduIGlzIGZ1bmRhbWVudGFsbHkgcHJvYmxlbWF0aWMuDQoNCk15IG9waW5p b24gaXMgc3RpbGwgZm9yICgyKSBvdmVyICgxKSwgYnV0IEkgY2FuIGxpdmUgd2l0aCBlaXRoZXIu DQoNCk9uIE1vbiwgRmViIDUsIDIwMTggYXQgMzozMiBQTSwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29v Z2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+PiB3cm90ZToNClByYXZlZW4sDQoNClRoYXQg d2FzIHByZWNpc2VseSBteSBwb2ludCBhYm91dCB0aGUgZWNvc3lzdGVtIGV2b2x2aW5nLiBOb3cg dGhhdCB3ZSBoYXZlIHRoZSBhYmlsaXR5IHRvIGNsYXNzaWZ5IGZsb3dzLCB2YXJpb3VzIHRoaW5n cyBoYXZlIGJlZW4gYnVpbHQgYXJvdW5kIGJlaW5nIGFibGUgdG8gdGVsbCBUQ1AgZmxvd3MuIFRo aXMgb2J2aW91c2x5IGhhcyBiZW5lZml0cyBhcyB5b3UgcG9pbnQgb3V0LCBidXQgdGhlIGRvd25z aWRlIGlzIHRoYXQgdGhhdCBJIGNhbid0IGdldCBnb29kIG5ldHdvcmsgdXRpbGl6YXRpb24gd2l0 aCBhIHNpbmdsZSBmbG93LiBJIHVuZGVyc3RhbmQgdGhlIHNjYWxpbmcgcG9pbnQsIGJ1dCBzcGVh a2luZyBvZiBjb21tb24gY2FzZXMsIGFueSBzZXJ2ZXIgaW4gdGhlIHdpbGQgaXMgdXN1YWxseSBz ZXJ2aW5nIGEgbGFyZ2UgbnVtYmVyIG9mIGNvbm5lY3Rpb25zIGF0IG1vZGVyYXRlIHNwZWVkcywg bm90IGEgc2luZ2xlIG9uZSBhdCAyNS0zNSBHYnBzLi4uIHdoaWNoIG1ha2VzIHRoYXQgc29ydCBv ZiBzY2FsaW5nIGxlc3MgZXhjaXRpbmcgdGhhbiBpbiBhIG1pY3JvYmVuY2htYXJrLg0KDQpGV0lX LCB0aGUgb3RoZXIgZG93bnNpZGUgb2YgRUNNUCBpcyB0aGF0IG11bHRpcGF0aCB0cmFuc3BvcnQg ZG9lc24ndCB3b3JrIC0tIHlvdSBuZWVkIHRvIGhhc2ggb24gc29tZXRoaW5nIGVsc2UgYmVzaWRl cyB0aGUgNC10dXBsZS4gKFdlIGhhZCB0byB3b3JrIGFyb3VuZCB0aGlzIGluIEdvb2dsZSdzIGRl cGxveW1lbnQgb2YgY29ubmVjdGlvbiBtaWdyYXRpb24uKQ0KDQpJJ2xsIGRpc2FncmVlIHdpdGgg eW91ciBwb2ludCBhYm91dCByZW9yZGVyaW5nIGJlaW5nIHRoZSB1bmNvbW1vbiBjYXNlLiBXaGls ZSB0aGF0J3MgdHJ1ZSB0b2RheSwgdGhpcyBpcyBhZ2FpbiBhbiBleHBlY3RhdGlvbiB0aGF0IHRo ZSBuZXR3b3JrIHdvcmtzIGhhcmQgdG8gbWFpbnRhaW4sIHRob3VnaCB0aGUgZWNvc3lzdGVtIGFu ZCB3aGF0IHdlIGV4cGVjdCBhcyAidXN1YWwiIHdvdWxkIGJlIHF1aXRlIGRpZmZlcmVudCBoYWQg d2Ugbm90IGJ1aWx0IFRDUCdzIHJlcXVpcmVtZW50cyBpbnRvIHRoZSBuZXR3b3JrLiBUaGVyZSdz IG5vdGhpbmcgd3Jvbmcgd2l0aCBoYXZpbmcgbi1tb2RhbCBsYXRlbmNpZXMuLi4gd2UgY2FuIGVu Z2luZWVyIGFyb3VuZCB0aGF0LiBBbnkgc2Vuc2libGUgbG9hZCBkaXN0cmlidXRpb24gc2NoZW1l IHdpdGhpbiB0aGUgbmV0d29yayB3aWxsIGdpdmUgeW91IGluY3JlYXNlZCB2YXJpYW5jZSBidXQg aXQgc2hvdWxkIGxpbWl0IHRoZSB3b3JzdC1jYXNlIGxhdGVuY3kuIFlvdSdkIHBlcmhhcHMgYWdy ZWUgdGhhdCB0aGF0J3MgYSBuZXQgd2luLg0KDQpUaGlzIHdhcyBhbiBleGFtcGxlIG9mIGhvdyBl eHBvc2luZyBwYWNrZXQgbnVtYmVyIG9yIG5vdCBjYW4gaGF2ZSBsb25nIHRlcm0gZWNvc3lzdGVt IGVmZmVjdHMuIE15IHBvaW50IHdhcyBhYm91dCB0aGUgZmFjdCB0aGF0IGV4cG9zaW5nIGNhbiBj YXVzZSBvc3NpZmljYXRpb24uDQoNCi0gamFuYQ0KDQpPbiBNb24sIEZlYiA1LCAyMDE4IGF0IDk6 MjQgQU0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0 bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+PiBUaGlzIHdhcyBkZWZpbml0ZWx5IHRy dWUgZm9yIGltcGxlbWVudGF0aW9ucyBvZiBUQ1AsIGJ1dCB0aGF0IGlzIFRDUCdzIHByb2JsZW0s IG5vdCB0aGUgbmV0d29yaydzDQpGbG93IGNsYXNzaWZpY2F0aW9uIGhhcHBlbnMgdGhyb3VnaCB0 aGUgbmV0d29yayBhbmQgYWxzbyBvbiB0aGUgZW5kIGhvc3Qgd2l0aCBSU1Mgd2hlcmUgYSBmbG93 IGlzIG1hcHBlZCB0byBhIGNvcmUuIFRoaXMgYWxsb3dzIGZvciBidWlsZGluZyBoaWdoIHBlcmZv cm1hbmNlIHJlY2VpdmUgcHJvY2Vzc2luZyB0aGF0IGNvdWxkIGJlIGxvY2sgZnJlZSBmb3IgdGhl IG1vc3QgcGFydC4gVGhlIG9ubHkgZG93bnNpZGUgb2YgRUNNUCBvbiB0aGUgbmV0d29yayBhbmQg UlNTIG9uIHRoZSBDUFUgaXMgdGhhdCBhIHNpbmdsZSBmbG93IHdpbGwgbm90IHRha2UgbXVsdGlw bGUgcGF0aHMgb3IgZ2V0IHByb2Nlc3NlZCBvbiBtb3JlIHRoYW4gb25lIGNvcmUuIFdpbmRvd3Mg b24gc2VydmVyIG1hY2hpbmVzIHRvZGF5IGNhbiBzYXR1cmF0ZSAyNS0zNSBHYnBzIGZvciBhIHNp bmdsZSBUQ1AgY29ubmVjdGlvbiBiZWZvcmUgYmVpbmcgQ1BVIGxpbWl0ZWQuIFRoaXMgaXMgYSAg cmVhc29uYWJsZSB0cmFkZSBvZmYgYmVjYXVzZSBJIGRvbuKAmXQga25vdyBvZiBjYXNlcyB3aGVy ZSBhIHNpbmdsZSBmbG93IGlzIGRyaXZpbmcgbW9yZSB0aGFuIHRoYXQgYW1vdW50IG9mIHRyYWZm aWMuIEFzc3VtcHRpb25zIGFib3V0IGhvdyBmbG93cyBnZXQgY2xhc3NpZmllZCBoZWxwIG1ha2Ug Zm9yIG1vcmUgZWZmaWNpZW50IHByb2Nlc3NpbmcuIFRoZXkgYWxzbyBsZWFkIHRvIGNvbnNpc3Rl bnQgbGF0ZW5jeS4gWW91IGRvIG5vdCB3YW50IHRoZSB0cmFmZmljIHRvIHRha2UgYSBiaS1tb2Rh bCBvciBOLW1vZGFsIHBhdGhzIChvbiB0aGUgbmV0d29yayBvciB0aGUgaG9zdCkgdG8gYmVpbmcg cHJvY2Vzc2VkIGJlY2F1c2UgdGhlIGZsdWN0dWF0aW9ucyBpbiBsYXRlbmN5IHdpbGwgaHVydCB0 aGUgd29ya2xvYWQuIEkgYW0gbm90IGFyZ3VpbmcgZm9yIFRDUCBub3QgYmVpbmcgcmVzaWxpZW50 IHRvIHJlb3JkZXJpbmcgYnV0IElNTyB0aGF0IHNob3VsZCBiZSB0aGUgdW5jb21tb24gY2FzZSBu b3QgdGhlIGNvbW1vbiBjYXNlLiBXaXRoIFFVSUMgaWYgc3RyZWFtcyB3ZXJlIGV4cG9zZWQgb24g dGhlIG5ldHdvcmsgeW91IGNvdWxkIHRha2UgYWR2YW50YWdlIG9mIHN0cmVhbSBsZXZlbCBFQ01Q IGFuZCBSU1MgdG8gc2NhbGUgYmV0dGVyIHRoYW4gVENQIGJ1dCB3ZSBoYXZlIGNob3NlbiB0byBr ZWVwIHRoZSA0LXR1cGxlIChvciB0aGUgNS10dXBsZSkgYXMgdGhlIGZsb3cgY2xhc3NpZmllciBv biB0aGUgbmV0d29yayB3aGljaCBpcyBvayBieSBtZSBzaW5jZSBpdCBsZWFkcyB0byBUQ1AgcGFy aXR5Lg0KDQpUaGFua3MNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIEphbmEgSXllbmdh cg0KU2VudDogU3VuZGF5LCBGZWJydWFyeSA0LCAyMDE4IDg6MzUgUE0NClRvOiBTYWx6LCBSaWNo IDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpyc2FsekBha2FtYWkuY29tPj4NCkNjOiBMdWJhc2hl diwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+ OyBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbTxtYWlsdG86ZmVuaXhAZmIuY29tPj47IFFVSUMg V0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFBh Y2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpQcml2YWN5LXByb3RlY3Rpb24gY2FuJ3QgYmUgYSB1 c2VyIGNob2ljZSwgZm9yIHRoZSByZWFzb25zIG90aGVycyBoYXZlIG5vdGVkIG9uIHRoaXMgdGhy ZWFkLg0KDQpUaGF0IHNhaWQsIG15IHByaW1hcnkgYXJndW1lbnQgaXMgZm9yIGVuY3J5cHRpb24g dG8gYXZvaWQgb3NzaWZpY2F0aW9uLiBOb3QgdGhhdCBpdCBtYXR0ZXJzIG5vdywgYnV0IEknbGwg bm90ZSB0aGF0IG11Y2ggb2YgR1FVSUMncyBvcmlnaW5hbCBtb3RpdmF0aW9uIGZvciBlbmNyeXB0 aW5nIGhlYWRlcnMgd2FzIHRvIGF2b2lkIG9zc2lmaWNhdGlvbi4NCg0KSSdsbCByZWl0ZXJhdGUg dGhhdCBmaWVsZHMgd2UgZXhwb3NlIHdpbGwgZ2V0IG9zc2lmaWVkIGFuZCB0aGVyZSBhcmUgbG9u Zy10ZXJtIGVjb3N5c3RlbSBlZmZlY3RzIHRvIHRoaXMuIExldCBtZSBpbGx1c3RyYXRlIHRoaXMg d2l0aCBwcmVjaXNlbHkgdGhlIHBhY2tldCBudW1iZXIgZmllbGQuIE1pZGRsZWJveGVzIGNvbW1v bmx5IGFzc3VtZSB0aGF0IGEgVENQIGZsb3cgY2FuIG9ubHkgaGFuZGxlIHBhY2tldHMgaW4tb3Jk ZXIuIFRoaXMgYXNzdW1wdGlvbiBjb21lcyBmcm9tIHRoZSBmYWN0IHRoYXQgVENQIGltcGxlbWVu dGF0aW9ucyBnZXQgcG9vciBwZXJmb3JtYW5jZSB3aGVuIHBhY2tldHMgYXJlIHJlb3JkZXJlZC4g VGhpcyB3YXMgZGVmaW5pdGVseSB0cnVlIGZvciBpbXBsZW1lbnRhdGlvbnMgb2YgVENQLCBidXQg dGhhdCBpcyBUQ1AncyBwcm9ibGVtLCBub3QgdGhlIG5ldHdvcmsncy4gSG93ZXZlciwgYWxtb3N0 IGFsbCBsb2FkLWJhbGFuY2VycyBJIGtub3cgb2Ygbm93IHdpbGwgcGluIGFsbCBwYWNrZXRzIHdp dGhpbiBhIFRDUCBmbG93IHRvIG9uZSBwYXRoLCBsZWFkaW5nIHRvIHN1Yi1vcHRpbWFsIHBlcmZv cm1hbmNlIGluIHRoZSBuZXR3b3JrLCBhbmQgZGVzdHJveWluZyBpbmNlbnRpdmVzIGZvciB0aGUg ZW5kcG9pbnRzIHRvIGRlcGxveSByZW9yZGVyaW5nLXJlc2lsaWVudCBUQ1AgaW1wbGVtZW50YXRp b25zIChldmVuIHRob3VnaCB0aGVyZSBhcmUgcGxlbnR5IG9mIHdheXMgb2YgZG9pbmcgdGhpcy4p DQoNCkV4cG9zaW5nIFFVSUMncyBwYWNrZXQgbnVtYmVyIGZpZWxkIChhcyBhbnkgZmllbGQpIGlz IGxpa2VseSB0byBoYXZlIHNpbWlsYXIgY29uc2VxdWVuY2VzIGFuZCBhIHNpbWlsYXIgZWNvc3lz dGVtIGFyYy4NCg0KDQpPbiBTdW4sIEZlYiA0LCAyMDE4IGF0IDc6NTEgUE0sIFNhbHosIFJpY2gg PHJzYWx6QGFrYW1haS5jb208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3cm90ZToNCg0KPiBP cHRpb25hbCBzZWN1cml0eSB0ZW5kcyB0byBkZXZvbHZlIHRvIG5vbi1zZWN1cmUuDQoNCg0KDQpU aGF04oCZcyBhIGdyZWF0IGFwaG9yaXNtLiAgQW5kIHNhZGx5IGFsbCB0b28gdHJ1ZS4NCg0KDQoN Cg== --_000_CY4PR21MB01336FF451F8E4A3CF013E47B6FD0CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpwLm03MDk1Mzc0MTgyMTE2MzI0MDM0bTIwODA3NTkyNDExNzIwOTY5 NzFtLTc5MTQ4NzYwODI0MjU3ODUwNHhtc29ub3JtYWwsIGxpLm03MDk1Mzc0MTgyMTE2MzI0MDM0 bTIwODA3NTkyNDExNzIwOTY5NzFtLTc5MTQ4NzYwODI0MjU3ODUwNHhtc29ub3JtYWwsIGRpdi5t NzA5NTM3NDE4MjExNjMyNDAzNG0yMDgwNzU5MjQxMTcyMDk2OTcxbS03OTE0ODc2MDgyNDI1Nzg1 MDR4bXNvbm9ybWFsDQoJe21zby1zdHlsZS1uYW1lOm1fNzA5NTM3NDE4MjExNjMyNDAzNG1fMjA4 MDc1OTI0MTE3MjA5Njk3MW0tNzkxNDg3NjA4MjQyNTc4NTA0eG1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBp biAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBv cGluaW9uIGlzIGZvciAxIG92ZXIgMiBidXQgSSBjYW4gbGl2ZSB3aXRoIGVpdGhlci4gVGhlIG1h aW4gY29uY2VybiBpcyBjb3N0IG9mIGFub3RoZXIgZW5jcnlwdGlvbiAvIGRlY3J5cHRpb24gc3Rl cCwgc28gdGhlIGJlbmVmaXQgb2YgMiBvdmVyIDEgc2hvdWxkIGJlIGRlbW9uc3RyYWJseSBiZXR0 ZXIgb24gb25lIG9mIG9zc2lmaWNhdGlvbiwgcHJpdmFjeSwgb3IgbWFuYWdlYWJpbGl0eS4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gSmFuYSBJeWVuZ2FyIFttYWlsdG86 anJpQGdvb2dsZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDUsIDIw MTggNDozMSBQTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3By YXZiQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBTYWx6LCBSaWNoICZsdDtyc2Fs ekBha2FtYWkuY29tJmd0OzsgTHViYXNoZXYsIElnb3IgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20m Z3Q7OyBSb2JlcnRvIFBlb24gJmx0O2Zlbml4QGZiLmNvbSZndDs7IFFVSUMgV0cgJmx0O3F1aWNA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5 cHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgd2UncmUg Y29udmVyZ2luZyBoZXJlLCBzbyBJJ2QgbGlrZSB0byB0cnkgYW5kIGVuY291cmFnZSB1cyB0byBt b3ZlIHRvd2FyZHMgaXQuIEkgaGF2ZSBteSBvcGluaW9uLCBidXQgSSBjYXJlIG1vcmUgYWJvdXQg Zm9yd2FyZCBwcm9ncmVzcyBhdCB0aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIHRocmVlIGRlc2lnbnMgc28gZmFyOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gUGFja2V0 IG51bWJlcnMgYXMgaXMsIHdpdGggcmFuZG9tIGdhcHMgYXJvdW5kIG1pZ3JhdGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFBhY2tldCBu dW1iZXJzIGVuY3J5cHRlZCwgYXMgcGVyIE1hcnRpbidzIFBSLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gUGFja2V0IG51bWJlcnMgZW5jcnlw dGVkLCBwbHVzIGEgc21hbGwgbW9kdWxvIHNlcXVlbmNlIG51bWJlciBzb21ld2hlcmUuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjb25j cmV0ZSBvbmVzIGhlcmUgYXJlICgxKSBhbmQgKDIpLiZuYnNwOyZuYnNwOzxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5JJ20gbGlzdGluZyAoMykgYnV0IGFtIG5v dCBpbmNsaW5lZCB0byBjb25zaWRlciBpdCBzZXJpb3VzbHksIHNpbmNlIGl0J3Mgbm90IGNvbmNy ZXRlIGVub3VnaCwgKGFuZCBJIGRvbid0DQogd2FudCBtb3JlIGJpdHMgdG8gYmUgc3BlbnQgaW4g dGhlIFFVSUMgcGFja2V0IGhlYWRlciBpZiB0aGF0J3Mgd2hlcmUgdGhpcyBpbmZvIGdvZXMuKTwv c3Bhbj48YnI+DQo8YnI+DQpUaGVyZSBhcmUgb3BpbmlvbnMgYWJvdXQgb3NzaWZpY2F0aW9uLCBw cml2YWN5LCBhbmQgbWFuYWdlYWJpbGl0eS4gSSdtIG5vdCBoZWFyaW5nIGJsb29keSBtdXJkZXIs IHNvIGZvciB3aGF0IGl0J3Mgd29ydGgsIEknZCBsaWtlIHRvIHN0aXB1bGF0ZSBmaXJzdCB0aGF0 IHdlIGNhbiBhbGwgbGl2ZSB3aXRoIHRoZSBmaW5hbCBkZXNpZ24sIHdoaWNoZXZlciBvbmUgaXQg aXMuJm5ic3A7IElmIGFueW9uZSBkaXNhZ3JlZXMsIHBsZWFzZSBzYXkgc28gLS0gSSB0aGluaw0K IGl0J2QgYmUgdXNlZnVsIHRvIGhlYXIgaWYgdGhlcmUgYXJlIGZvbGtzIHdobyB0aGluayBhIHBh cnRpY3VsYXIgZGVzaWduIGlzIGZ1bmRhbWVudGFsbHkgcHJvYmxlbWF0aWMuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5NeSBvcGluaW9uIGlzIHN0aWxsIGZvciAo Mikgb3ZlciAoMSksIGJ1dCBJIGNhbiBsaXZlIHdpdGggZWl0aGVyLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIg NSwgMjAxOCBhdCAzOjMyIFBNLCBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmlA Z29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpyaUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlByYXZlZW4sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+VGhhdCB3YXMgcHJlY2lz ZWx5IG15IHBvaW50IGFib3V0IHRoZSBlY29zeXN0ZW0gZXZvbHZpbmcuIE5vdyB0aGF0IHdlIGhh dmUgdGhlIGFiaWxpdHkgdG8gY2xhc3NpZnkgZmxvd3MsIHZhcmlvdXMgdGhpbmdzIGhhdmUgYmVl biBidWlsdCBhcm91bmQgYmVpbmcgYWJsZSB0byB0ZWxsDQogVENQIGZsb3dzLiBUaGlzIG9idmlv dXNseSBoYXMgYmVuZWZpdHMgYXMgeW91IHBvaW50IG91dCwgYnV0IHRoZSBkb3duc2lkZSBpcyB0 aGF0IHRoYXQgSSBjYW4ndCBnZXQgZ29vZCBuZXR3b3JrIHV0aWxpemF0aW9uIHdpdGggYSBzaW5n bGUgZmxvdy4gSSB1bmRlcnN0YW5kIHRoZSBzY2FsaW5nIHBvaW50LCBidXQgczxzcGFuIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj5wZWFraW5nIG9mIGNvbW1vbiBjYXNlcywgYW55IHNlcnZlciBp biB0aGUgd2lsZA0KIGlzIHVzdWFsbHkgc2VydmluZyBhIGxhcmdlIG51bWJlciBvZiBjb25uZWN0 aW9ucyBhdCBtb2RlcmF0ZSBzcGVlZHMsIG5vdCBhIHNpbmdsZSBvbmUgYXQgMjUtMzUgR2Jwcy4u LiB3aGljaCBtYWtlcyB0aGF0IHNvcnQgb2Ygc2NhbGluZyBsZXNzIGV4Y2l0aW5nIHRoYW4gaW4g YSBtaWNyb2JlbmNobWFyay48L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIyIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFja2dyb3VuZDp3aGl0ZSI+RldJ VywgdGhlIG90aGVyIGRvd25zaWRlIG9mIEVDTVAgaXMgdGhhdCBtdWx0aXBhdGggdHJhbnNwb3J0 IGRvZXNuJ3Qgd29yayAtLSB5b3UgbmVlZCB0byBoYXNoIG9uIHNvbWV0aGluZyBlbHNlIGJlc2lk ZXMgdGhlIDQtdHVwbGUuIChXZSBoYWQgdG8NCiB3b3JrIGFyb3VuZCB0aGlzIGluIEdvb2dsZSdz IGRlcGxveW1lbnQgb2YgY29ubmVjdGlvbiBtaWdyYXRpb24uKTwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbGwgZGlzYWdyZWUgd2l0aCB5 b3VyIHBvaW50IGFib3V0IHJlb3JkZXJpbmcgYmVpbmcgdGhlIHVuY29tbW9uIGNhc2UuIFdoaWxl IHRoYXQncyB0cnVlIHRvZGF5LCB0aGlzIGlzIGFnYWluIGFuIGV4cGVjdGF0aW9uIHRoYXQgdGhl IG5ldHdvcmsgd29ya3MgaGFyZCB0byBtYWludGFpbiwgdGhvdWdoIHRoZSBlY29zeXN0ZW0gYW5k IHdoYXQgd2UgZXhwZWN0IGFzICZxdW90O3VzdWFsJnF1b3Q7IHdvdWxkIGJlIHF1aXRlIGRpZmZl cmVudA0KIGhhZCB3ZSBub3QgYnVpbHQgVENQJ3MgcmVxdWlyZW1lbnRzIGludG8gdGhlIG5ldHdv cmsuIFRoZXJlJ3Mgbm90aGluZyB3cm9uZyB3aXRoIGhhdmluZyBuLW1vZGFsIGxhdGVuY2llcy4u LiB3ZSBjYW4gZW5naW5lZXIgYXJvdW5kIHRoYXQuIEFueSBzZW5zaWJsZSBsb2FkIGRpc3RyaWJ1 dGlvbiBzY2hlbWUgd2l0aGluIHRoZSBuZXR3b3JrIHdpbGwgZ2l2ZSB5b3UgaW5jcmVhc2VkIHZh cmlhbmNlIGJ1dCBpdCBzaG91bGQgbGltaXQgdGhlIHdvcnN0LWNhc2UNCiBsYXRlbmN5LiBZb3Un ZCBwZXJoYXBzIGFncmVlIHRoYXQgdGhhdCdzIGEgbmV0IHdpbi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB3YXMgYW4gZXhhbXBsZSBv ZiBob3cgZXhwb3NpbmcgcGFja2V0IG51bWJlciBvciBub3QgY2FuIGhhdmUgbG9uZyB0ZXJtIGVj b3N5c3RlbSBlZmZlY3RzLiBNeSBwb2ludCB3YXMgYWJvdXQgdGhlIGZhY3QgdGhhdCBleHBvc2lu ZyBjYW4gY2F1c2Ugb3NzaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4tIGphbmE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g TW9uLCBGZWIgNSwgMjAxOCBhdCA5OjI0IEFNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5wcmF2 YkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsmZ3Q7IFRoaXMgd2Fz IGRlZmluaXRlbHkgdHJ1ZSBmb3IgaW1wbGVtZW50YXRpb25zIG9mIFRDUCwgYnV0IHRoYXQgaXMg VENQJ3MgcHJvYmxlbSwgbm90IHRoZSBuZXR3b3JrJ3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+RmxvdyBjbGFzc2lmaWNhdGlvbiBoYXBwZW5zIHRocm91Z2ggdGhlIG5l dHdvcmsgYW5kIGFsc28gb24gdGhlIGVuZCBob3N0IHdpdGggUlNTIHdoZXJlIGEgZmxvdyBpcyBt YXBwZWQgdG8gYSBjb3JlLiBUaGlzIGFsbG93cyBmb3IgYnVpbGRpbmcgaGlnaCBwZXJmb3JtYW5j ZSByZWNlaXZlIHByb2Nlc3NpbmcNCiB0aGF0IGNvdWxkIGJlIGxvY2sgZnJlZSBmb3IgdGhlIG1v c3QgcGFydC4gVGhlIG9ubHkgZG93bnNpZGUgb2YgRUNNUCBvbiB0aGUgbmV0d29yayBhbmQgUlNT IG9uIHRoZSBDUFUgaXMgdGhhdCBhIHNpbmdsZSBmbG93IHdpbGwgbm90IHRha2UgbXVsdGlwbGUg cGF0aHMgb3IgZ2V0IHByb2Nlc3NlZCBvbiBtb3JlIHRoYW4gb25lIGNvcmUuIFdpbmRvd3Mgb24g c2VydmVyIG1hY2hpbmVzIHRvZGF5IGNhbiBzYXR1cmF0ZSAyNS0zNSBHYnBzIGZvciBhDQogc2lu Z2xlIFRDUCBjb25uZWN0aW9uIGJlZm9yZSBiZWluZyBDUFUgbGltaXRlZC4gVGhpcyBpcyBhICZu YnNwO3JlYXNvbmFibGUgdHJhZGUgb2ZmIGJlY2F1c2UgSSBkb27igJl0IGtub3cgb2YgY2FzZXMg d2hlcmUgYSBzaW5nbGUgZmxvdyBpcyBkcml2aW5nIG1vcmUgdGhhbiB0aGF0IGFtb3VudCBvZiB0 cmFmZmljLiBBc3N1bXB0aW9ucyBhYm91dCBob3cgZmxvd3MgZ2V0IGNsYXNzaWZpZWQgaGVscCBt YWtlIGZvciBtb3JlIGVmZmljaWVudCBwcm9jZXNzaW5nLg0KIFRoZXkgYWxzbyBsZWFkIHRvIGNv bnNpc3RlbnQgbGF0ZW5jeS4gWW91IGRvIG5vdCB3YW50IHRoZSB0cmFmZmljIHRvIHRha2UgYSBi aS1tb2RhbCBvciBOLW1vZGFsIHBhdGhzIChvbiB0aGUgbmV0d29yayBvciB0aGUgaG9zdCkgdG8g YmVpbmcgcHJvY2Vzc2VkIGJlY2F1c2UgdGhlIGZsdWN0dWF0aW9ucyBpbiBsYXRlbmN5IHdpbGwg aHVydCB0aGUgd29ya2xvYWQuIEkgYW0gbm90IGFyZ3VpbmcgZm9yIFRDUCBub3QgYmVpbmcgcmVz aWxpZW50IHRvDQogcmVvcmRlcmluZyBidXQgSU1PIHRoYXQgc2hvdWxkIGJlIHRoZSB1bmNvbW1v biBjYXNlIG5vdCB0aGUgY29tbW9uIGNhc2UuIFdpdGggUVVJQyBpZiBzdHJlYW1zIHdlcmUgZXhw b3NlZCBvbiB0aGUgbmV0d29yayB5b3UgY291bGQgdGFrZSBhZHZhbnRhZ2Ugb2Ygc3RyZWFtIGxl dmVsIEVDTVAgYW5kIFJTUyB0byBzY2FsZSBiZXR0ZXIgdGhhbiBUQ1AgYnV0IHdlIGhhdmUgY2hv c2VuIHRvIGtlZXAgdGhlIDQtdHVwbGUgKG9yIHRoZSA1LXR1cGxlKQ0KIGFzIHRoZSBmbG93IGNs YXNzaWZpZXIgb24gdGhlIG5ldHdvcmsgd2hpY2ggaXMgb2sgYnkgbWUgc2luY2UgaXQgbGVhZHMg dG8gVENQIHBhcml0eS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5KYW5hIEl5ZW5nYXI8YnI+DQo8 Yj5TZW50OjwvYj4gU3VuZGF5LCBGZWJydWFyeSA0LCAyMDE4IDg6MzUgUE08YnI+DQo8Yj5Ubzo8 L2I+IFNhbHosIFJpY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpyc2FsekBha2FtYWkuY29tIiB0YXJn ZXQ9Il9ibGFuayI+cnNhbHpAYWthbWFpLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMdWJh c2hldiwgSWdvciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iIHRhcmdl dD0iX2JsYW5rIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZndDs7IFJvYmVydG8gUGVvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmZlbml4QGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZlbml4QGZiLmNv bTwvYT4mZ3Q7OyBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+UHJpdmFjeS1wcm90ZWN0aW9uIGNhbid0IGJlIGEgdXNlciBjaG9pY2UsIGZvciB0aGUg cmVhc29ucyBvdGhlcnMgaGF2ZSBub3RlZCBvbiB0aGlzIHRocmVhZC4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0K VGhhdCBzYWlkLCBteSBwcmltYXJ5IGFyZ3VtZW50IGlzIGZvciBlbmNyeXB0aW9uIHRvIGF2b2lk IG9zc2lmaWNhdGlvbi4gTm90IHRoYXQgaXQgbWF0dGVycyBub3csIGJ1dCBJJ2xsIG5vdGUgdGhh dCBtdWNoIG9mIEdRVUlDJ3Mgb3JpZ2luYWwgbW90aXZhdGlvbiBmb3IgZW5jcnlwdGluZyBoZWFk ZXJzIHdhcyB0byBhdm9pZCBvc3NpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ2xsIHJlaXRlcmF0ZSB0aGF0IGZpZWxk cyB3ZSBleHBvc2Ugd2lsbCBnZXQgb3NzaWZpZWQgYW5kIHRoZXJlIGFyZSBsb25nLXRlcm0gZWNv c3lzdGVtIGVmZmVjdHMgdG8gdGhpcy4gTGV0IG1lIGlsbHVzdHJhdGUgdGhpcyB3aXRoIHByZWNp c2VseSB0aGUgcGFja2V0IG51bWJlciBmaWVsZC4gTWlkZGxlYm94ZXMNCiBjb21tb25seSBhc3N1 bWUgdGhhdCBhIFRDUCBmbG93IGNhbiBvbmx5IGhhbmRsZSBwYWNrZXRzIGluLW9yZGVyLiBUaGlz IGFzc3VtcHRpb24gY29tZXMgZnJvbSB0aGUgZmFjdCB0aGF0IFRDUCBpbXBsZW1lbnRhdGlvbnMg Z2V0IHBvb3IgcGVyZm9ybWFuY2Ugd2hlbiBwYWNrZXRzIGFyZSByZW9yZGVyZWQuIFRoaXMgd2Fz IGRlZmluaXRlbHkgdHJ1ZSBmb3IgaW1wbGVtZW50YXRpb25zIG9mIFRDUCwgYnV0IHRoYXQgaXMg VENQJ3MgcHJvYmxlbSwNCiBub3QgdGhlIG5ldHdvcmsncy4gSG93ZXZlciwgYWxtb3N0IGFsbCBs b2FkLWJhbGFuY2VycyBJIGtub3cgb2Ygbm93IHdpbGwgcGluIGFsbCBwYWNrZXRzIHdpdGhpbiBh IFRDUCBmbG93IHRvIG9uZSBwYXRoLCBsZWFkaW5nIHRvIHN1Yi1vcHRpbWFsIHBlcmZvcm1hbmNl IGluIHRoZSBuZXR3b3JrLCBhbmQgZGVzdHJveWluZyBpbmNlbnRpdmVzIGZvciB0aGUgZW5kcG9p bnRzIHRvIGRlcGxveSByZW9yZGVyaW5nLXJlc2lsaWVudCBUQ1AgaW1wbGVtZW50YXRpb25zDQog KGV2ZW4gdGhvdWdoIHRoZXJlIGFyZSBwbGVudHkgb2Ygd2F5cyBvZiBkb2luZyB0aGlzLik8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkV4 cG9zaW5nIFFVSUMncyBwYWNrZXQgbnVtYmVyIGZpZWxkIChhcyBhbnkgZmllbGQpIGlzIGxpa2Vs eSB0byBoYXZlIHNpbWlsYXIgY29uc2VxdWVuY2VzIGFuZCBhIHNpbWlsYXIgZWNvc3lzdGVtIGFy Yy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBTdW4sIEZlYiA0LCAyMDE4 IGF0IDc6NTEgUE0sIFNhbHosIFJpY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpyc2FsekBha2FtYWku Y29tIiB0YXJnZXQ9Il9ibGFuayI+cnNhbHpAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj4mZ3Q7IE9wdGlvbmFsIHNlY3VyaXR5IHRlbmRzIHRvIGRldm9sdmUgdG8gbm9uLXNl Y3VyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJtNzA5NTM3NDE4MjExNjMyNDAzNG0yMDgwNzU5MjQxMTcyMDk2OTcx bS03OTE0ODc2MDgyNDI1Nzg1MDR4bXNvbm9ybWFsIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Im03MDk1Mzc0MTgyMTE2MzI0MDM0bTIwODA3NTkyNDExNzIwOTY5NzFtLTc5MTQ4 NzYwODI0MjU3ODUwNHhtc29ub3JtYWwiPg0KVGhhdOKAmXMgYSBncmVhdCBhcGhvcmlzbS4mbmJz cDsgQW5kIHNhZGx5IGFsbCB0b28gdHJ1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_CY4PR21MB01336FF451F8E4A3CF013E47B6FD0CY4PR21MB0133namp_-- From nobody Mon Feb 5 23:10:17 2018 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 2DC41126D74 for ; Mon, 5 Feb 2018 23:10:15 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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=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 KKEKQmvPFruE for ; Mon, 5 Feb 2018 23:10:11 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0114.outbound.protection.outlook.com [104.47.42.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 5232A126D85 for ; Mon, 5 Feb 2018 23:10:11 -0800 (PST) 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=R+7xsSHkPu0FyzwQAP/IrtFr9UVzGR6S4jXXvO3WHs0=; b=YNoSxmZiih7bCR61yeQw+icPnwJcESWCzg05AR+Gc31M8JZYzLy4euL49SFnESMqPABcHcO9cNIhmcIkKqI11bWxHt8jaP0CRcqt7BRQh2TkCCDotNBqImgsi7QdP9/FJ2Fc7c7lYOh6E7HFl+uA/CHoCP54U57I3tlUAx7Jx1M= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0744.namprd21.prod.outlook.com (10.173.189.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Tue, 6 Feb 2018 07:10:09 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Tue, 6 Feb 2018 07:10:05 +0000 From: Praveen Balasubramanian To: Praveen Balasubramanian , Jana Iyengar CC: "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , QUIC WG Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgAArugCAAEL00A== Date: Tue, 6 Feb 2018 07:10:05 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0744; 7:F5bkcrSUma3vZu1fRR+R8Mo0zelgNZYhg7J+jTsIyMF5EJmX9nPme91OpHU8rTzCbF6rvFrS0I904jDZWD5pFDFp93TbfjH2jsjZkVT62aDcOiv0FuJ2X+JltxDOzL3qyjWPImDYtQWfnVB2Rxw3jzu+QjCHuYTU0O+lKBjiZdLLuPtMygAcBfDnUwonIM78VQ/6EUFoawKjJoc84jMpz+QrOTVntAFOVaq/REOjEse9EYokB2Dxy4ByWFqQxaAp x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(376002)(396003)(366004)(39860400002)(39380400002)(346002)(199004)(189003)(2950100002)(99286004)(105586002)(86612001)(14454004)(8990500004)(10290500003)(478600001)(7116003)(5660300001)(2940100002)(229853002)(81166006)(81156014)(8676002)(6436002)(19609705001)(86362001)(1511001)(10090500001)(3660700001)(54896002)(8936002)(6306002)(53936002)(102836004)(106356001)(76176011)(77096007)(3480700004)(6346003)(316002)(6246003)(3280700002)(110136005)(54906003)(55016002)(22452003)(236005)(2900100001)(93886005)(9686003)(25786009)(68736007)(2906002)(33656002)(74316002)(7736002)(7696005)(97736004)(6506007)(53546011)(59450400001)(790700001)(6116002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0744; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 50ddf77e-0c3b-4fda-b1fc-08d56d30a616 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0744; x-ms-traffictypediagnostic: CY4PR21MB0744: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(192374486261705)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0744; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0744; x-forefront-prvs: 0575F81B58 received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: OzS3f5CEU1/3/ef4kjmDwZ1U4k8n534LrwfDcKlERiMoLQ1kAMYLxMpC+kpsLrMYO7tNYQ5BsFOAbIzm1/NYOw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133383C5FB993D3F5642A89B6FD0CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 50ddf77e-0c3b-4fda-b1fc-08d56d30a616 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 07:10:05.3785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0744 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, 06 Feb 2018 07:10:15 -0000 --_000_CY4PR21MB0133383C5FB993D3F5642A89B6FD0CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T29wcyBzb3JyeSBJIHRoaW5rIEkgbWlzcmVhZCB0aGF0IDEgcmVxdWlyZXMgcmFuZG9tIGp1bXBz IG9ubHkgYXJvdW5kIG1pZ3JhdGlvbiBhbmQgbm90IGFsd2F5cywgd2hpY2ggbWVhbnMgaXRzIGRl Y2lkZWRseSBpbmZlcmlvciB0byAyIHcuci50LiBvc3NpZmljYXRpb24uIENhbiB3ZSBpbmNsdWRl IGEgMS4xIHdoaWNoIGluY29ycG9yYXRlcyByYW5kb20ganVtcHMgZXZlbiBpbiBzdGVhZHkgc3Rh dGU/IE9yIGhhdmUgd2UgcnVsZWQgdGhhdCBvcHRpb24gb3V0Pw0KDQpGcm9tOiBRVUlDIFttYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUHJhdmVlbiBCYWxhc3VicmFt YW5pYW4NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgNSwgMjAxOCA3OjEzIFBNDQpUbzogSmFuYSBJ eWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT4NCkNjOiBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29t PjsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+OyBSb2JlcnRvIFBlb24gPGZl bml4QGZiLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogUGFja2V0 IG51bWJlciBlbmNyeXB0aW9uDQoNCk15IG9waW5pb24gaXMgZm9yIDEgb3ZlciAyIGJ1dCBJIGNh biBsaXZlIHdpdGggZWl0aGVyLiBUaGUgbWFpbiBjb25jZXJuIGlzIGNvc3Qgb2YgYW5vdGhlciBl bmNyeXB0aW9uIC8gZGVjcnlwdGlvbiBzdGVwLCBzbyB0aGUgYmVuZWZpdCBvZiAyIG92ZXIgMSBz aG91bGQgYmUgZGVtb25zdHJhYmx5IGJldHRlciBvbiBvbmUgb2Ygb3NzaWZpY2F0aW9uLCBwcml2 YWN5LCBvciBtYW5hZ2VhYmlsaXR5Lg0KDQpGcm9tOiBKYW5hIEl5ZW5nYXIgW21haWx0bzpqcmlA Z29vZ2xlLmNvbV0NClNlbnQ6IE1vbmRheSwgRmVicnVhcnkgNSwgMjAxOCA0OjMxIFBNDQpUbzog UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZi QG1pY3Jvc29mdC5jb20+Pg0KQ2M6IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb208bWFpbHRv OnJzYWx6QGFrYW1haS5jb20+PjsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208 bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb208 bWFpbHRvOmZlbml4QGZiLmNvbT4+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWlj QGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KSSBk b24ndCB0aGluayB3ZSdyZSBjb252ZXJnaW5nIGhlcmUsIHNvIEknZCBsaWtlIHRvIHRyeSBhbmQg ZW5jb3VyYWdlIHVzIHRvIG1vdmUgdG93YXJkcyBpdC4gSSBoYXZlIG15IG9waW5pb24sIGJ1dCBJ IGNhcmUgbW9yZSBhYm91dCBmb3J3YXJkIHByb2dyZXNzIGF0IHRoaXMgcG9pbnQuDQoNClRoZXJl IGFyZSB0aHJlZSBkZXNpZ25zIHNvIGZhcjoNCjEuIFBhY2tldCBudW1iZXJzIGFzIGlzLCB3aXRo IHJhbmRvbSBnYXBzIGFyb3VuZCBtaWdyYXRpb24uDQoyLiBQYWNrZXQgbnVtYmVycyBlbmNyeXB0 ZWQsIGFzIHBlciBNYXJ0aW4ncyBQUi4NCjMuIFBhY2tldCBudW1iZXJzIGVuY3J5cHRlZCwgcGx1 cyBhIHNtYWxsIG1vZHVsbyBzZXF1ZW5jZSBudW1iZXIgc29tZXdoZXJlLg0KDQpUaGUgY29uY3Jl dGUgb25lcyBoZXJlIGFyZSAoMSkgYW5kICgyKS4gIEknbSBsaXN0aW5nICgzKSBidXQgYW0gbm90 IGluY2xpbmVkIHRvIGNvbnNpZGVyIGl0IHNlcmlvdXNseSwgc2luY2UgaXQncyBub3QgY29uY3Jl dGUgZW5vdWdoLCAoYW5kIEkgZG9uJ3Qgd2FudCBtb3JlIGJpdHMgdG8gYmUgc3BlbnQgaW4gdGhl IFFVSUMgcGFja2V0IGhlYWRlciBpZiB0aGF0J3Mgd2hlcmUgdGhpcyBpbmZvIGdvZXMuKQ0KDQpU aGVyZSBhcmUgb3BpbmlvbnMgYWJvdXQgb3NzaWZpY2F0aW9uLCBwcml2YWN5LCBhbmQgbWFuYWdl YWJpbGl0eS4gSSdtIG5vdCBoZWFyaW5nIGJsb29keSBtdXJkZXIsIHNvIGZvciB3aGF0IGl0J3Mg d29ydGgsIEknZCBsaWtlIHRvIHN0aXB1bGF0ZSBmaXJzdCB0aGF0IHdlIGNhbiBhbGwgbGl2ZSB3 aXRoIHRoZSBmaW5hbCBkZXNpZ24sIHdoaWNoZXZlciBvbmUgaXQgaXMuICBJZiBhbnlvbmUgZGlz YWdyZWVzLCBwbGVhc2Ugc2F5IHNvIC0tIEkgdGhpbmsgaXQnZCBiZSB1c2VmdWwgdG8gaGVhciBp ZiB0aGVyZSBhcmUgZm9sa3Mgd2hvIHRoaW5rIGEgcGFydGljdWxhciBkZXNpZ24gaXMgZnVuZGFt ZW50YWxseSBwcm9ibGVtYXRpYy4NCg0KTXkgb3BpbmlvbiBpcyBzdGlsbCBmb3IgKDIpIG92ZXIg KDEpLCBidXQgSSBjYW4gbGl2ZSB3aXRoIGVpdGhlci4NCg0KT24gTW9uLCBGZWIgNSwgMjAxOCBh dCAzOjMyIFBNLCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlAZ29vZ2xl LmNvbT4+IHdyb3RlOg0KUHJhdmVlbiwNCg0KVGhhdCB3YXMgcHJlY2lzZWx5IG15IHBvaW50IGFi b3V0IHRoZSBlY29zeXN0ZW0gZXZvbHZpbmcuIE5vdyB0aGF0IHdlIGhhdmUgdGhlIGFiaWxpdHkg dG8gY2xhc3NpZnkgZmxvd3MsIHZhcmlvdXMgdGhpbmdzIGhhdmUgYmVlbiBidWlsdCBhcm91bmQg YmVpbmcgYWJsZSB0byB0ZWxsIFRDUCBmbG93cy4gVGhpcyBvYnZpb3VzbHkgaGFzIGJlbmVmaXRz IGFzIHlvdSBwb2ludCBvdXQsIGJ1dCB0aGUgZG93bnNpZGUgaXMgdGhhdCB0aGF0IEkgY2FuJ3Qg Z2V0IGdvb2QgbmV0d29yayB1dGlsaXphdGlvbiB3aXRoIGEgc2luZ2xlIGZsb3cuIEkgdW5kZXJz dGFuZCB0aGUgc2NhbGluZyBwb2ludCwgYnV0IHNwZWFraW5nIG9mIGNvbW1vbiBjYXNlcywgYW55 IHNlcnZlciBpbiB0aGUgd2lsZCBpcyB1c3VhbGx5IHNlcnZpbmcgYSBsYXJnZSBudW1iZXIgb2Yg Y29ubmVjdGlvbnMgYXQgbW9kZXJhdGUgc3BlZWRzLCBub3QgYSBzaW5nbGUgb25lIGF0IDI1LTM1 IEdicHMuLi4gd2hpY2ggbWFrZXMgdGhhdCBzb3J0IG9mIHNjYWxpbmcgbGVzcyBleGNpdGluZyB0 aGFuIGluIGEgbWljcm9iZW5jaG1hcmsuDQoNCkZXSVcsIHRoZSBvdGhlciBkb3duc2lkZSBvZiBF Q01QIGlzIHRoYXQgbXVsdGlwYXRoIHRyYW5zcG9ydCBkb2Vzbid0IHdvcmsgLS0geW91IG5lZWQg dG8gaGFzaCBvbiBzb21ldGhpbmcgZWxzZSBiZXNpZGVzIHRoZSA0LXR1cGxlLiAoV2UgaGFkIHRv IHdvcmsgYXJvdW5kIHRoaXMgaW4gR29vZ2xlJ3MgZGVwbG95bWVudCBvZiBjb25uZWN0aW9uIG1p Z3JhdGlvbi4pDQoNCkknbGwgZGlzYWdyZWUgd2l0aCB5b3VyIHBvaW50IGFib3V0IHJlb3JkZXJp bmcgYmVpbmcgdGhlIHVuY29tbW9uIGNhc2UuIFdoaWxlIHRoYXQncyB0cnVlIHRvZGF5LCB0aGlz IGlzIGFnYWluIGFuIGV4cGVjdGF0aW9uIHRoYXQgdGhlIG5ldHdvcmsgd29ya3MgaGFyZCB0byBt YWludGFpbiwgdGhvdWdoIHRoZSBlY29zeXN0ZW0gYW5kIHdoYXQgd2UgZXhwZWN0IGFzICJ1c3Vh bCIgd291bGQgYmUgcXVpdGUgZGlmZmVyZW50IGhhZCB3ZSBub3QgYnVpbHQgVENQJ3MgcmVxdWly ZW1lbnRzIGludG8gdGhlIG5ldHdvcmsuIFRoZXJlJ3Mgbm90aGluZyB3cm9uZyB3aXRoIGhhdmlu ZyBuLW1vZGFsIGxhdGVuY2llcy4uLiB3ZSBjYW4gZW5naW5lZXIgYXJvdW5kIHRoYXQuIEFueSBz ZW5zaWJsZSBsb2FkIGRpc3RyaWJ1dGlvbiBzY2hlbWUgd2l0aGluIHRoZSBuZXR3b3JrIHdpbGwg Z2l2ZSB5b3UgaW5jcmVhc2VkIHZhcmlhbmNlIGJ1dCBpdCBzaG91bGQgbGltaXQgdGhlIHdvcnN0 LWNhc2UgbGF0ZW5jeS4gWW91J2QgcGVyaGFwcyBhZ3JlZSB0aGF0IHRoYXQncyBhIG5ldCB3aW4u DQoNClRoaXMgd2FzIGFuIGV4YW1wbGUgb2YgaG93IGV4cG9zaW5nIHBhY2tldCBudW1iZXIgb3Ig bm90IGNhbiBoYXZlIGxvbmcgdGVybSBlY29zeXN0ZW0gZWZmZWN0cy4gTXkgcG9pbnQgd2FzIGFi b3V0IHRoZSBmYWN0IHRoYXQgZXhwb3NpbmcgY2FuIGNhdXNlIG9zc2lmaWNhdGlvbi4NCg0KLSBq YW5hDQoNCk9uIE1vbiwgRmViIDUsIDIwMTggYXQgOToyNCBBTSwgUHJhdmVlbiBCYWxhc3VicmFt YW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PiB3 cm90ZToNCj4+IFRoaXMgd2FzIGRlZmluaXRlbHkgdHJ1ZSBmb3IgaW1wbGVtZW50YXRpb25zIG9m IFRDUCwgYnV0IHRoYXQgaXMgVENQJ3MgcHJvYmxlbSwgbm90IHRoZSBuZXR3b3JrJ3MNCkZsb3cg Y2xhc3NpZmljYXRpb24gaGFwcGVucyB0aHJvdWdoIHRoZSBuZXR3b3JrIGFuZCBhbHNvIG9uIHRo ZSBlbmQgaG9zdCB3aXRoIFJTUyB3aGVyZSBhIGZsb3cgaXMgbWFwcGVkIHRvIGEgY29yZS4gVGhp cyBhbGxvd3MgZm9yIGJ1aWxkaW5nIGhpZ2ggcGVyZm9ybWFuY2UgcmVjZWl2ZSBwcm9jZXNzaW5n IHRoYXQgY291bGQgYmUgbG9jayBmcmVlIGZvciB0aGUgbW9zdCBwYXJ0LiBUaGUgb25seSBkb3du c2lkZSBvZiBFQ01QIG9uIHRoZSBuZXR3b3JrIGFuZCBSU1Mgb24gdGhlIENQVSBpcyB0aGF0IGEg c2luZ2xlIGZsb3cgd2lsbCBub3QgdGFrZSBtdWx0aXBsZSBwYXRocyBvciBnZXQgcHJvY2Vzc2Vk IG9uIG1vcmUgdGhhbiBvbmUgY29yZS4gV2luZG93cyBvbiBzZXJ2ZXIgbWFjaGluZXMgdG9kYXkg Y2FuIHNhdHVyYXRlIDI1LTM1IEdicHMgZm9yIGEgc2luZ2xlIFRDUCBjb25uZWN0aW9uIGJlZm9y ZSBiZWluZyBDUFUgbGltaXRlZC4gVGhpcyBpcyBhICByZWFzb25hYmxlIHRyYWRlIG9mZiBiZWNh dXNlIEkgZG9u4oCZdCBrbm93IG9mIGNhc2VzIHdoZXJlIGEgc2luZ2xlIGZsb3cgaXMgZHJpdmlu ZyBtb3JlIHRoYW4gdGhhdCBhbW91bnQgb2YgdHJhZmZpYy4gQXNzdW1wdGlvbnMgYWJvdXQgaG93 IGZsb3dzIGdldCBjbGFzc2lmaWVkIGhlbHAgbWFrZSBmb3IgbW9yZSBlZmZpY2llbnQgcHJvY2Vz c2luZy4gVGhleSBhbHNvIGxlYWQgdG8gY29uc2lzdGVudCBsYXRlbmN5LiBZb3UgZG8gbm90IHdh bnQgdGhlIHRyYWZmaWMgdG8gdGFrZSBhIGJpLW1vZGFsIG9yIE4tbW9kYWwgcGF0aHMgKG9uIHRo ZSBuZXR3b3JrIG9yIHRoZSBob3N0KSB0byBiZWluZyBwcm9jZXNzZWQgYmVjYXVzZSB0aGUgZmx1 Y3R1YXRpb25zIGluIGxhdGVuY3kgd2lsbCBodXJ0IHRoZSB3b3JrbG9hZC4gSSBhbSBub3QgYXJn dWluZyBmb3IgVENQIG5vdCBiZWluZyByZXNpbGllbnQgdG8gcmVvcmRlcmluZyBidXQgSU1PIHRo YXQgc2hvdWxkIGJlIHRoZSB1bmNvbW1vbiBjYXNlIG5vdCB0aGUgY29tbW9uIGNhc2UuIFdpdGgg UVVJQyBpZiBzdHJlYW1zIHdlcmUgZXhwb3NlZCBvbiB0aGUgbmV0d29yayB5b3UgY291bGQgdGFr ZSBhZHZhbnRhZ2Ugb2Ygc3RyZWFtIGxldmVsIEVDTVAgYW5kIFJTUyB0byBzY2FsZSBiZXR0ZXIg dGhhbiBUQ1AgYnV0IHdlIGhhdmUgY2hvc2VuIHRvIGtlZXAgdGhlIDQtdHVwbGUgKG9yIHRoZSA1 LXR1cGxlKSBhcyB0aGUgZmxvdyBjbGFzc2lmaWVyIG9uIHRoZSBuZXR3b3JrIHdoaWNoIGlzIG9r IGJ5IG1lIHNpbmNlIGl0IGxlYWRzIHRvIFRDUCBwYXJpdHkuDQoNClRoYW5rcw0KDQpGcm9tOiBR VUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmc+XSBPbiBCZWhhbGYgT2YgSmFuYSBJeWVuZ2FyDQpTZW50OiBTdW5kYXksIEZlYnJ1YXJ5 IDQsIDIwMTggODozNSBQTQ0KVG86IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb208bWFpbHRv OnJzYWx6QGFrYW1haS5jb20+Pg0KQ2M6IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWku Y29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29tPj47IFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIu Y29tPG1haWx0bzpmZW5peEBmYi5jb20+PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86 cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoN ClByaXZhY3ktcHJvdGVjdGlvbiBjYW4ndCBiZSBhIHVzZXIgY2hvaWNlLCBmb3IgdGhlIHJlYXNv bnMgb3RoZXJzIGhhdmUgbm90ZWQgb24gdGhpcyB0aHJlYWQuDQoNClRoYXQgc2FpZCwgbXkgcHJp bWFyeSBhcmd1bWVudCBpcyBmb3IgZW5jcnlwdGlvbiB0byBhdm9pZCBvc3NpZmljYXRpb24uIE5v dCB0aGF0IGl0IG1hdHRlcnMgbm93LCBidXQgSSdsbCBub3RlIHRoYXQgbXVjaCBvZiBHUVVJQydz IG9yaWdpbmFsIG1vdGl2YXRpb24gZm9yIGVuY3J5cHRpbmcgaGVhZGVycyB3YXMgdG8gYXZvaWQg b3NzaWZpY2F0aW9uLg0KDQpJJ2xsIHJlaXRlcmF0ZSB0aGF0IGZpZWxkcyB3ZSBleHBvc2Ugd2ls bCBnZXQgb3NzaWZpZWQgYW5kIHRoZXJlIGFyZSBsb25nLXRlcm0gZWNvc3lzdGVtIGVmZmVjdHMg dG8gdGhpcy4gTGV0IG1lIGlsbHVzdHJhdGUgdGhpcyB3aXRoIHByZWNpc2VseSB0aGUgcGFja2V0 IG51bWJlciBmaWVsZC4gTWlkZGxlYm94ZXMgY29tbW9ubHkgYXNzdW1lIHRoYXQgYSBUQ1AgZmxv dyBjYW4gb25seSBoYW5kbGUgcGFja2V0cyBpbi1vcmRlci4gVGhpcyBhc3N1bXB0aW9uIGNvbWVz IGZyb20gdGhlIGZhY3QgdGhhdCBUQ1AgaW1wbGVtZW50YXRpb25zIGdldCBwb29yIHBlcmZvcm1h bmNlIHdoZW4gcGFja2V0cyBhcmUgcmVvcmRlcmVkLiBUaGlzIHdhcyBkZWZpbml0ZWx5IHRydWUg Zm9yIGltcGxlbWVudGF0aW9ucyBvZiBUQ1AsIGJ1dCB0aGF0IGlzIFRDUCdzIHByb2JsZW0sIG5v dCB0aGUgbmV0d29yaydzLiBIb3dldmVyLCBhbG1vc3QgYWxsIGxvYWQtYmFsYW5jZXJzIEkga25v dyBvZiBub3cgd2lsbCBwaW4gYWxsIHBhY2tldHMgd2l0aGluIGEgVENQIGZsb3cgdG8gb25lIHBh dGgsIGxlYWRpbmcgdG8gc3ViLW9wdGltYWwgcGVyZm9ybWFuY2UgaW4gdGhlIG5ldHdvcmssIGFu ZCBkZXN0cm95aW5nIGluY2VudGl2ZXMgZm9yIHRoZSBlbmRwb2ludHMgdG8gZGVwbG95IHJlb3Jk ZXJpbmctcmVzaWxpZW50IFRDUCBpbXBsZW1lbnRhdGlvbnMgKGV2ZW4gdGhvdWdoIHRoZXJlIGFy ZSBwbGVudHkgb2Ygd2F5cyBvZiBkb2luZyB0aGlzLikNCg0KRXhwb3NpbmcgUVVJQydzIHBhY2tl dCBudW1iZXIgZmllbGQgKGFzIGFueSBmaWVsZCkgaXMgbGlrZWx5IHRvIGhhdmUgc2ltaWxhciBj b25zZXF1ZW5jZXMgYW5kIGEgc2ltaWxhciBlY29zeXN0ZW0gYXJjLg0KDQoNCk9uIFN1biwgRmVi IDQsIDIwMTggYXQgNzo1MSBQTSwgU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbTxtYWlsdG86 cnNhbHpAYWthbWFpLmNvbT4+IHdyb3RlOg0KDQo+IE9wdGlvbmFsIHNlY3VyaXR5IHRlbmRzIHRv IGRldm9sdmUgdG8gbm9uLXNlY3VyZS4NCg0KDQoNClRoYXTigJlzIGEgZ3JlYXQgYXBob3Jpc20u ICBBbmQgc2FkbHkgYWxsIHRvbyB0cnVlLg0KDQoNCg0K --_000_CY4PR21MB0133383C5FB993D3F5642A89B6FD0CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubTcwOTUzNzQxODIxMTYzMjQwMzRt MjA4MDc1OTI0MTE3MjA5Njk3MW0tNzkxNDg3NjA4MjQyNTc4NTA0eG1zb25vcm1hbCwgbGkubTcw OTUzNzQxODIxMTYzMjQwMzRtMjA4MDc1OTI0MTE3MjA5Njk3MW0tNzkxNDg3NjA4MjQyNTc4NTA0 eG1zb25vcm1hbCwgZGl2Lm03MDk1Mzc0MTgyMTE2MzI0MDM0bTIwODA3NTkyNDExNzIwOTY5NzFt LTc5MTQ4NzYwODI0MjU3ODUwNHhtc29ub3JtYWwNCgl7bXNvLXN0eWxlLW5hbWU6bV83MDk1Mzc0 MTgyMTE2MzI0MDM0bV8yMDgwNzU5MjQxMTcyMDk2OTcxbS03OTE0ODc2MDgyNDI1Nzg1MDR4bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5ob2Vu emINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T29wcyBzb3JyeSBJIHRoaW5rIEkgbWlzcmVhZCB0 aGF0IDEgcmVxdWlyZXMgcmFuZG9tIGp1bXBzIG9ubHkgYXJvdW5kIG1pZ3JhdGlvbiBhbmQgbm90 IGFsd2F5cywgd2hpY2ggbWVhbnMgaXRzIGRlY2lkZWRseSBpbmZlcmlvciB0byAyIHcuci50LiBv c3NpZmljYXRpb24uIENhbiB3ZSBpbmNsdWRlIGEgMS4xIHdoaWNoIGluY29ycG9yYXRlcyByYW5k b20ganVtcHMgZXZlbiBpbiBzdGVhZHkgc3RhdGU/IE9yIGhhdmUNCiB3ZSBydWxlZCB0aGF0IG9w dGlvbiBvdXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y Z10gPGI+T24gQmVoYWxmIE9mDQo8L2I+UHJhdmVlbiBCYWxhc3VicmFtYW5pYW48YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4IDc6MTMgUE08YnI+DQo8Yj5Ubzo8L2I+ IEphbmEgSXllbmdhciAmbHQ7anJpQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBTYWx6 LCBSaWNoICZsdDtyc2FsekBha2FtYWkuY29tJmd0OzsgTHViYXNoZXYsIElnb3IgJmx0O2lsdWJh c2hlQGFrYW1haS5jb20mZ3Q7OyBSb2JlcnRvIFBlb24gJmx0O2Zlbml4QGZiLmNvbSZndDs7IFFV SUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQYWNr ZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk15IG9waW5pb24gaXMgZm9yIDEgb3ZlciAyIGJ1dCBJIGNhbiBsaXZlIHdpdGggZWl0aGVy LiBUaGUgbWFpbiBjb25jZXJuIGlzIGNvc3Qgb2YgYW5vdGhlciBlbmNyeXB0aW9uIC8gZGVjcnlw dGlvbiBzdGVwLCBzbyB0aGUgYmVuZWZpdCBvZiAyIG92ZXIgMSBzaG91bGQgYmUgZGVtb25zdHJh Ymx5IGJldHRlciBvbiBvbmUgb2Ygb3NzaWZpY2F0aW9uLCBwcml2YWN5LCBvciBtYW5hZ2VhYmls aXR5Lg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBKYW5hIEl5ZW5nYXIg WzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+bWFpbHRvOmpyaUBnb29nbGUuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDUsIDIwMTggNDozMSBQTTxi cj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0 bzpwcmF2YkBtaWNyb3NvZnQuY29tIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IFNhbHosIFJpY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpyc2FsekBha2FtYWkuY29t Ij5yc2FsekBha2FtYWkuY29tPC9hPiZndDs7IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJt YWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7OyBS b2JlcnRvIFBlb24gJmx0OzxhIGhyZWY9Im1haWx0bzpmZW5peEBmYi5jb20iPmZlbml4QGZiLmNv bTwvYT4mZ3Q7OyBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVp Y0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVy IGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsg d2UncmUgY29udmVyZ2luZyBoZXJlLCBzbyBJJ2QgbGlrZSB0byB0cnkgYW5kIGVuY291cmFnZSB1 cyB0byBtb3ZlIHRvd2FyZHMgaXQuIEkgaGF2ZSBteSBvcGluaW9uLCBidXQgSSBjYXJlIG1vcmUg YWJvdXQgZm9yd2FyZCBwcm9ncmVzcyBhdCB0aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIHRocmVlIGRlc2lnbnMgc28gZmFy OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4g UGFja2V0IG51bWJlcnMgYXMgaXMsIHdpdGggcmFuZG9tIGdhcHMgYXJvdW5kIG1pZ3JhdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFBh Y2tldCBudW1iZXJzIGVuY3J5cHRlZCwgYXMgcGVyIE1hcnRpbidzIFBSLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gUGFja2V0IG51bWJlcnMg ZW5jcnlwdGVkLCBwbHVzIGEgc21hbGwgbW9kdWxvIHNlcXVlbmNlIG51bWJlciBzb21ld2hlcmUu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBjb25jcmV0ZSBvbmVzIGhlcmUgYXJlICgxKSBhbmQgKDIpLiZuYnNwOyZuYnNwOzxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5JJ20gbGlzdGluZyAoMykgYnV0 IGFtIG5vdCBpbmNsaW5lZCB0byBjb25zaWRlciBpdCBzZXJpb3VzbHksIHNpbmNlIGl0J3Mgbm90 IGNvbmNyZXRlIGVub3VnaCwgKGFuZCBJIGRvbid0DQogd2FudCBtb3JlIGJpdHMgdG8gYmUgc3Bl bnQgaW4gdGhlIFFVSUMgcGFja2V0IGhlYWRlciBpZiB0aGF0J3Mgd2hlcmUgdGhpcyBpbmZvIGdv ZXMuKTwvc3Bhbj48YnI+DQo8YnI+DQpUaGVyZSBhcmUgb3BpbmlvbnMgYWJvdXQgb3NzaWZpY2F0 aW9uLCBwcml2YWN5LCBhbmQgbWFuYWdlYWJpbGl0eS4gSSdtIG5vdCBoZWFyaW5nIGJsb29keSBt dXJkZXIsIHNvIGZvciB3aGF0IGl0J3Mgd29ydGgsIEknZCBsaWtlIHRvIHN0aXB1bGF0ZSBmaXJz dCB0aGF0IHdlIGNhbiBhbGwgbGl2ZSB3aXRoIHRoZSBmaW5hbCBkZXNpZ24sIHdoaWNoZXZlciBv bmUgaXQgaXMuJm5ic3A7IElmIGFueW9uZSBkaXNhZ3JlZXMsIHBsZWFzZSBzYXkgc28gLS0gSSB0 aGluaw0KIGl0J2QgYmUgdXNlZnVsIHRvIGhlYXIgaWYgdGhlcmUgYXJlIGZvbGtzIHdobyB0aGlu ayBhIHBhcnRpY3VsYXIgZGVzaWduIGlzIGZ1bmRhbWVudGFsbHkgcHJvYmxlbWF0aWMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj5NeSBvcGluaW9uIGlzIHN0aWxs IGZvciAoMikgb3ZlciAoMSksIGJ1dCBJIGNhbiBsaXZlIHdpdGggZWl0aGVyLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9u LCBGZWIgNSwgMjAxOCBhdCAzOjMyIFBNLCBKYW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpqcmlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpyaUBnb29nbGUuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QcmF2ZWVuLDxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjIiPlRoYXQgd2FzIHByZWNpc2VseSBteSBwb2ludCBh Ym91dCB0aGUgZWNvc3lzdGVtIGV2b2x2aW5nLiBOb3cgdGhhdCB3ZSBoYXZlIHRoZSBhYmlsaXR5 IHRvIGNsYXNzaWZ5IGZsb3dzLCB2YXJpb3VzIHRoaW5ncyBoYXZlIGJlZW4gYnVpbHQgYXJvdW5k IGJlaW5nIGFibGUgdG8gdGVsbA0KIFRDUCBmbG93cy4gVGhpcyBvYnZpb3VzbHkgaGFzIGJlbmVm aXRzIGFzIHlvdSBwb2ludCBvdXQsIGJ1dCB0aGUgZG93bnNpZGUgaXMgdGhhdCB0aGF0IEkgY2Fu J3QgZ2V0IGdvb2QgbmV0d29yayB1dGlsaXphdGlvbiB3aXRoIGEgc2luZ2xlIGZsb3cuIEkgdW5k ZXJzdGFuZCB0aGUgc2NhbGluZyBwb2ludCwgYnV0IHM8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3 aGl0ZSI+cGVha2luZyBvZiBjb21tb24gY2FzZXMsIGFueSBzZXJ2ZXIgaW4gdGhlIHdpbGQNCiBp cyB1c3VhbGx5IHNlcnZpbmcgYSBsYXJnZSBudW1iZXIgb2YgY29ubmVjdGlvbnMgYXQgbW9kZXJh dGUgc3BlZWRzLCBub3QgYSBzaW5nbGUgb25lIGF0IDI1LTM1IEdicHMuLi4gd2hpY2ggbWFrZXMg dGhhdCBzb3J0IG9mIHNjYWxpbmcgbGVzcyBleGNpdGluZyB0aGFuIGluIGEgbWljcm9iZW5jaG1h cmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMjIyMjIyO2JhY2tncm91bmQ6d2hpdGUiPkZXSVcsIHRoZSBvdGhlciBk b3duc2lkZSBvZiBFQ01QIGlzIHRoYXQgbXVsdGlwYXRoIHRyYW5zcG9ydCBkb2Vzbid0IHdvcmsg LS0geW91IG5lZWQgdG8gaGFzaCBvbiBzb21ldGhpbmcgZWxzZSBiZXNpZGVzIHRoZSA0LXR1cGxl LiAoV2UgaGFkIHRvDQogd29yayBhcm91bmQgdGhpcyBpbiBHb29nbGUncyBkZXBsb3ltZW50IG9m IGNvbm5lY3Rpb24gbWlncmF0aW9uLik8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMjIyMjIy Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ2xsIGRpc2FncmVlIHdpdGggeW91ciBwb2ludCBhYm91 dCByZW9yZGVyaW5nIGJlaW5nIHRoZSB1bmNvbW1vbiBjYXNlLiBXaGlsZSB0aGF0J3MgdHJ1ZSB0 b2RheSwgdGhpcyBpcyBhZ2FpbiBhbiBleHBlY3RhdGlvbiB0aGF0IHRoZSBuZXR3b3JrIHdvcmtz IGhhcmQgdG8gbWFpbnRhaW4sIHRob3VnaCB0aGUgZWNvc3lzdGVtIGFuZCB3aGF0IHdlIGV4cGVj dCBhcyAmcXVvdDt1c3VhbCZxdW90OyB3b3VsZCBiZSBxdWl0ZSBkaWZmZXJlbnQNCiBoYWQgd2Ug bm90IGJ1aWx0IFRDUCdzIHJlcXVpcmVtZW50cyBpbnRvIHRoZSBuZXR3b3JrLiBUaGVyZSdzIG5v dGhpbmcgd3Jvbmcgd2l0aCBoYXZpbmcgbi1tb2RhbCBsYXRlbmNpZXMuLi4gd2UgY2FuIGVuZ2lu ZWVyIGFyb3VuZCB0aGF0LiBBbnkgc2Vuc2libGUgbG9hZCBkaXN0cmlidXRpb24gc2NoZW1lIHdp dGhpbiB0aGUgbmV0d29yayB3aWxsIGdpdmUgeW91IGluY3JlYXNlZCB2YXJpYW5jZSBidXQgaXQg c2hvdWxkIGxpbWl0IHRoZSB3b3JzdC1jYXNlDQogbGF0ZW5jeS4gWW91J2QgcGVyaGFwcyBhZ3Jl ZSB0aGF0IHRoYXQncyBhIG5ldCB3aW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgd2FzIGFuIGV4YW1wbGUgb2YgaG93IGV4cG9zaW5n IHBhY2tldCBudW1iZXIgb3Igbm90IGNhbiBoYXZlIGxvbmcgdGVybSBlY29zeXN0ZW0gZWZmZWN0 cy4gTXkgcG9pbnQgd2FzIGFib3V0IHRoZSBmYWN0IHRoYXQgZXhwb3NpbmcgY2FuIGNhdXNlIG9z c2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6Izg4ODg4OCI+LSBqYW5hPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgRmViIDUsIDIw MTggYXQgOToyNCBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0 bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHJhdmJAbWljcm9zb2Z0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jmd0OyZndDsgVGhpcyB3YXMgZGVmaW5pdGVseSB0cnVlIGZvciBpbXBsZW1lbnRhdGlv bnMgb2YgVENQLCBidXQgdGhhdCBpcyBUQ1AncyBwcm9ibGVtLCBub3QgdGhlIG5ldHdvcmsnczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5GbG93IGNsYXNzaWZpY2F0aW9u IGhhcHBlbnMgdGhyb3VnaCB0aGUgbmV0d29yayBhbmQgYWxzbyBvbiB0aGUgZW5kIGhvc3Qgd2l0 aCBSU1Mgd2hlcmUgYSBmbG93IGlzIG1hcHBlZCB0byBhIGNvcmUuIFRoaXMgYWxsb3dzIGZvciBi dWlsZGluZyBoaWdoIHBlcmZvcm1hbmNlIHJlY2VpdmUgcHJvY2Vzc2luZw0KIHRoYXQgY291bGQg YmUgbG9jayBmcmVlIGZvciB0aGUgbW9zdCBwYXJ0LiBUaGUgb25seSBkb3duc2lkZSBvZiBFQ01Q IG9uIHRoZSBuZXR3b3JrIGFuZCBSU1Mgb24gdGhlIENQVSBpcyB0aGF0IGEgc2luZ2xlIGZsb3cg d2lsbCBub3QgdGFrZSBtdWx0aXBsZSBwYXRocyBvciBnZXQgcHJvY2Vzc2VkIG9uIG1vcmUgdGhh biBvbmUgY29yZS4gV2luZG93cyBvbiBzZXJ2ZXIgbWFjaGluZXMgdG9kYXkgY2FuIHNhdHVyYXRl IDI1LTM1IEdicHMgZm9yIGENCiBzaW5nbGUgVENQIGNvbm5lY3Rpb24gYmVmb3JlIGJlaW5nIENQ VSBsaW1pdGVkLiBUaGlzIGlzIGEgJm5ic3A7cmVhc29uYWJsZSB0cmFkZSBvZmYgYmVjYXVzZSBJ IGRvbuKAmXQga25vdyBvZiBjYXNlcyB3aGVyZSBhIHNpbmdsZSBmbG93IGlzIGRyaXZpbmcgbW9y ZSB0aGFuIHRoYXQgYW1vdW50IG9mIHRyYWZmaWMuIEFzc3VtcHRpb25zIGFib3V0IGhvdyBmbG93 cyBnZXQgY2xhc3NpZmllZCBoZWxwIG1ha2UgZm9yIG1vcmUgZWZmaWNpZW50IHByb2Nlc3Npbmcu DQogVGhleSBhbHNvIGxlYWQgdG8gY29uc2lzdGVudCBsYXRlbmN5LiBZb3UgZG8gbm90IHdhbnQg dGhlIHRyYWZmaWMgdG8gdGFrZSBhIGJpLW1vZGFsIG9yIE4tbW9kYWwgcGF0aHMgKG9uIHRoZSBu ZXR3b3JrIG9yIHRoZSBob3N0KSB0byBiZWluZyBwcm9jZXNzZWQgYmVjYXVzZSB0aGUgZmx1Y3R1 YXRpb25zIGluIGxhdGVuY3kgd2lsbCBodXJ0IHRoZSB3b3JrbG9hZC4gSSBhbSBub3QgYXJndWlu ZyBmb3IgVENQIG5vdCBiZWluZyByZXNpbGllbnQgdG8NCiByZW9yZGVyaW5nIGJ1dCBJTU8gdGhh dCBzaG91bGQgYmUgdGhlIHVuY29tbW9uIGNhc2Ugbm90IHRoZSBjb21tb24gY2FzZS4gV2l0aCBR VUlDIGlmIHN0cmVhbXMgd2VyZSBleHBvc2VkIG9uIHRoZSBuZXR3b3JrIHlvdSBjb3VsZCB0YWtl IGFkdmFudGFnZSBvZiBzdHJlYW0gbGV2ZWwgRUNNUCBhbmQgUlNTIHRvIHNjYWxlIGJldHRlciB0 aGFuIFRDUCBidXQgd2UgaGF2ZSBjaG9zZW4gdG8ga2VlcCB0aGUgNC10dXBsZSAob3IgdGhlIDUt dHVwbGUpDQogYXMgdGhlIGZsb3cgY2xhc3NpZmllciBvbiB0aGUgbmV0d29yayB3aGljaCBpcyBv ayBieSBtZSBzaW5jZSBpdCBsZWFkcyB0byBUQ1AgcGFyaXR5Lg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9i PiBRVUlDIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPkphbmEgSXllbmdhcjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEZlYnJ1YXJ5IDQsIDIw MTggODozNSBQTTxicj4NCjxiPlRvOjwvYj4gU2FseiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5yc2FsekBha2FtYWkuY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1 YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+ Jmd0OzsgUm9iZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZmVuaXhAZmIuY29tPC9hPiZndDs7IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1h aWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Qcml2YWN5LXByb3RlY3Rpb24gY2FuJ3QgYmUg YSB1c2VyIGNob2ljZSwgZm9yIHRoZSByZWFzb25zIG90aGVycyBoYXZlIG5vdGVkIG9uIHRoaXMg dGhyZWFkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48YnI+DQpUaGF0IHNhaWQsIG15IHByaW1hcnkgYXJndW1lbnQgaXMg Zm9yIGVuY3J5cHRpb24gdG8gYXZvaWQgb3NzaWZpY2F0aW9uLiBOb3QgdGhhdCBpdCBtYXR0ZXJz IG5vdywgYnV0IEknbGwgbm90ZSB0aGF0IG11Y2ggb2YgR1FVSUMncyBvcmlnaW5hbCBtb3RpdmF0 aW9uIGZvciBlbmNyeXB0aW5nIGhlYWRlcnMgd2FzIHRvIGF2b2lkIG9zc2lmaWNhdGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkn bGwgcmVpdGVyYXRlIHRoYXQgZmllbGRzIHdlIGV4cG9zZSB3aWxsIGdldCBvc3NpZmllZCBhbmQg dGhlcmUgYXJlIGxvbmctdGVybSBlY29zeXN0ZW0gZWZmZWN0cyB0byB0aGlzLiBMZXQgbWUgaWxs dXN0cmF0ZSB0aGlzIHdpdGggcHJlY2lzZWx5IHRoZSBwYWNrZXQgbnVtYmVyIGZpZWxkLiBNaWRk bGVib3hlcw0KIGNvbW1vbmx5IGFzc3VtZSB0aGF0IGEgVENQIGZsb3cgY2FuIG9ubHkgaGFuZGxl IHBhY2tldHMgaW4tb3JkZXIuIFRoaXMgYXNzdW1wdGlvbiBjb21lcyBmcm9tIHRoZSBmYWN0IHRo YXQgVENQIGltcGxlbWVudGF0aW9ucyBnZXQgcG9vciBwZXJmb3JtYW5jZSB3aGVuIHBhY2tldHMg YXJlIHJlb3JkZXJlZC4gVGhpcyB3YXMgZGVmaW5pdGVseSB0cnVlIGZvciBpbXBsZW1lbnRhdGlv bnMgb2YgVENQLCBidXQgdGhhdCBpcyBUQ1AncyBwcm9ibGVtLA0KIG5vdCB0aGUgbmV0d29yaydz LiBIb3dldmVyLCBhbG1vc3QgYWxsIGxvYWQtYmFsYW5jZXJzIEkga25vdyBvZiBub3cgd2lsbCBw aW4gYWxsIHBhY2tldHMgd2l0aGluIGEgVENQIGZsb3cgdG8gb25lIHBhdGgsIGxlYWRpbmcgdG8g c3ViLW9wdGltYWwgcGVyZm9ybWFuY2UgaW4gdGhlIG5ldHdvcmssIGFuZCBkZXN0cm95aW5nIGlu Y2VudGl2ZXMgZm9yIHRoZSBlbmRwb2ludHMgdG8gZGVwbG95IHJlb3JkZXJpbmctcmVzaWxpZW50 IFRDUCBpbXBsZW1lbnRhdGlvbnMNCiAoZXZlbiB0aG91Z2ggdGhlcmUgYXJlIHBsZW50eSBvZiB3 YXlzIG9mIGRvaW5nIHRoaXMuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+RXhwb3NpbmcgUVVJQydzIHBhY2tldCBudW1iZXIgZmllbGQg KGFzIGFueSBmaWVsZCkgaXMgbGlrZWx5IHRvIGhhdmUgc2ltaWxhciBjb25zZXF1ZW5jZXMgYW5k IGEgc2ltaWxhciBlY29zeXN0ZW0gYXJjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk9uIFN1biwgRmViIDQsIDIwMTggYXQgNzo1MSBQTSwgU2FseiwgUmljaCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5yc2FsekBha2FtYWku Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDsgT3B0aW9uYWwgc2VjdXJpdHkgdGVu ZHMgdG8gZGV2b2x2ZSB0byBub24tc2VjdXJlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Im03MDk1Mzc0MTgyMTE2MzI0 MDM0bTIwODA3NTkyNDExNzIwOTY5NzFtLTc5MTQ4NzYwODI0MjU3ODUwNHhtc29ub3JtYWwiPg0K Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTcwOTUzNzQxODIxMTYzMjQwMzRtMjA4 MDc1OTI0MTE3MjA5Njk3MW0tNzkxNDg3NjA4MjQyNTc4NTA0eG1zb25vcm1hbCI+DQpUaGF04oCZ cyBhIGdyZWF0IGFwaG9yaXNtLiZuYnNwOyBBbmQgc2FkbHkgYWxsIHRvbyB0cnVlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB0133383C5FB993D3F5642A89B6FD0CY4PR21MB0133namp_-- From nobody Mon Feb 5 23:30:57 2018 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 DC7CE126CF9 for ; Mon, 5 Feb 2018 23:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 WU4XFXiO8zQ5 for ; Mon, 5 Feb 2018 23:30:53 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 1021D120727 for ; Mon, 5 Feb 2018 23:30:53 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id q62so536852vkb.11 for ; Mon, 05 Feb 2018 23:30:53 -0800 (PST) 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=cFeOvNk0N47LhxUN6gX1EHiisSzP8egDVaCcwl5mrl8=; b=QX/sTSzOTd7BRSOieZojzeOGhONSAwpSKrk3DzVxJCRLbC1TQW17kuUCHYDC5obi7w bGMVdKQsG2qaCGgqmwvsO1tieyjObUQ8IEaoYzdrTpUfysmitxDmyXFhA8Ow2qB/WJX4 4ddtjQXVmJ677mqzpSRhLatn90Hvm38ymTomkywzRXzZTF9Phg1Fe1veQO4XG89ns0TS BurFb2SlRvWwefoMcbn31tu5jdacymTQTNKIOmKjoYNuDob3GVO62Ul1DNgGz8HpJJ1n QkAM/k3jr1mdIW7deWTIN4iMfDR53+6syxtxu93EL64aLR1BIP/RDMcwIUudJDfEypi0 7ySg== 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=cFeOvNk0N47LhxUN6gX1EHiisSzP8egDVaCcwl5mrl8=; b=rpneDYD7AYMMuSpMk37fmS0A9thhcF4ll/QQLR9MDn463NiJdTV6Et4OIwI1QXM1JV yvehykG6rBhvtxTZHkKZrINPgBe0ncniaOv6dVrR/GCdGcKc60Oa6u0GKu4A9HD51+dD 4c7zqJ4E1/keqLg4MxPiAjb/Ir/UDgyn0ArbZ9dizSVMV/09INCidvRX/UX5nTG2vHd+ h3qiV2QqjM8sOQ/RYK//6nGYgh3Ua2ZRLfoEj94I6McIXKIGBWp7XhF9Cb3DEbEQPFQ3 MorDv09PmL/nqsK6sra/6BSZwXw1S/AzbUGRIIid2vlHeAVxr7QY3qxnLb5H525jdvMs Yo0w== X-Gm-Message-State: APf1xPCKow6h2A2eo/qAN22LU7pYqN3FcEFEx+55l1eN4K0SlUW82vmG I/48KUPSfLmzqtJdv0Cm7JC2y9z3k8KerVEN94Q= X-Google-Smtp-Source: AH8x226w8yC/FvrRekUEQLMS8ICPJLRrWSiG8QcPfepPzCBzqVHDzPJLSehm0NY7XBH9V9KjLO3vBuFY5feWGTq+vAE= X-Received: by 10.31.153.11 with SMTP id b11mr1442391vke.119.1517902251701; Mon, 05 Feb 2018 23:30:51 -0800 (PST) MIME-Version: 1.0 References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> In-Reply-To: From: Marten Seemann Date: Tue, 06 Feb 2018 07:30:40 +0000 Message-ID: Subject: Re: Packet number encryption To: Praveen Balasubramanian Cc: Jana Iyengar , "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , QUIC WG Content-Type: multipart/alternative; boundary="001a1140fe58843f8505648628bd" 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, 06 Feb 2018 07:30:56 -0000 --001a1140fe58843f8505648628bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Option 2 is the only option that allows us to correct our decision in the future. If we were to discover that it doesn't work out as we planned (wrt encryption performance, network manageability or literally any other unforeseen problem), going back to option 1 (or coming up with another clever solution) in a future QUIC version would still be a viable option. Option 1 on the other hand, once deployed, immediately puts us at risk of ossification by middleboxes, which will prohibit us from ever switching to option 2 for a future QUIC version. On Tue, Feb 6, 2018 at 3:10 PM Praveen Balasubramanian wrote: > Oops sorry I think I misread that 1 requires random jumps only around > migration and not always, which means its decidedly inferior to 2 w.r.t. > ossification. Can we include a 1.1 which incorporates random jumps even i= n > steady state? Or have we ruled that option out? > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen > Balasubramanian > *Sent:* Monday, February 5, 2018 7:13 PM > *To:* Jana Iyengar > > > *Cc:* Salz, Rich ; Lubashev, Igor = ; > Roberto Peon ; QUIC WG > > *Subject:* RE: Packet number encryption > > > > My opinion is for 1 over 2 but I can live with either. The main concern i= s > cost of another encryption / decryption step, so the benefit of 2 over 1 > should be demonstrably better on one of ossification, privacy, or > manageability. > > > > *From:* Jana Iyengar [mailto:jri@google.com ] > *Sent:* Monday, February 5, 2018 4:31 PM > *To:* Praveen Balasubramanian > *Cc:* Salz, Rich ; Lubashev, Igor = ; > Roberto Peon ; QUIC WG > *Subject:* Re: Packet number encryption > > > > I don't think we're converging here, so I'd like to try and encourage us > to move towards it. I have my opinion, but I care more about forward > progress at this point. > > > > There are three designs so far: > > 1. Packet numbers as is, with random gaps around migration. > > 2. Packet numbers encrypted, as per Martin's PR. > > 3. Packet numbers encrypted, plus a small modulo sequence number somewher= e. > > > > The concrete ones here are (1) and (2). I'm listing (3) but am not > inclined to consider it seriously, since it's not concrete enough, (and I > don't want more bits to be spent in the QUIC packet header if that's wher= e > this info goes.) > > There are opinions about ossification, privacy, and manageability. I'm no= t > hearing bloody murder, so for what it's worth, I'd like to stipulate firs= t > that we can all live with the final design, whichever one it is. If anyo= ne > disagrees, please say so -- I think it'd be useful to hear if there are > folks who think a particular design is fundamentally problematic. > > > > My opinion is still for (2) over (1), but I can live with either. > > > > On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: > > Praveen, > > > > That was precisely my point about the ecosystem evolving. Now that we hav= e > the ability to classify flows, various things have been built around bein= g > able to tell TCP flows. This obviously has benefits as you point out, but > the downside is that that I can't get good network utilization with a > single flow. I understand the scaling point, but speaking of common > cases, any server in the wild is usually serving a large number of > connections at moderate speeds, not a single one at 25-35 Gbps... which > makes that sort of scaling less exciting than in a microbenchmark. > > > > FWIW, the other downside of ECMP is that multipath transport doesn't work > -- you need to hash on something else besides the 4-tuple. (We had to wor= k > around this in Google's deployment of connection migration.) > > > > I'll disagree with your point about reordering being the uncommon case. > While that's true today, this is again an expectation that the network > works hard to maintain, though the ecosystem and what we expect as "usual= " > would be quite different had we not built TCP's requirements into the > network. There's nothing wrong with having n-modal latencies... we can > engineer around that. Any sensible load distribution scheme within the > network will give you increased variance but it should limit the worst-ca= se > latency. You'd perhaps agree that that's a net win. > > > > This was an example of how exposing packet number or not can have long > term ecosystem effects. My point was about the fact that exposing can cau= se > ossification. > > > > - jana > > > > On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > >> This was definitely true for implementations of TCP, but that is TCP's > problem, not the network's > > Flow classification happens through the network and also on the end host > with RSS where a flow is mapped to a core. This allows for building high > performance receive processing that could be lock free for the most part. > The only downside of ECMP on the network and RSS on the CPU is that a > single flow will not take multiple paths or get processed on more than on= e > core. Windows on server machines today can saturate 25-35 Gbps for a sing= le > TCP connection before being CPU limited. This is a reasonable trade off > because I don=E2=80=99t know of cases where a single flow is driving more= than that > amount of traffic. Assumptions about how flows get classified help make f= or > more efficient processing. They also lead to consistent latency. You do n= ot > want the traffic to take a bi-modal or N-modal paths (on the network or t= he > host) to being processed because the fluctuations in latency will hurt th= e > workload. I am not arguing for TCP not being resilient to reordering but > IMO that should be the uncommon case not the common case. With QUIC if > streams were exposed on the network you could take advantage of stream > level ECMP and RSS to scale better than TCP but we have chosen to keep th= e > 4-tuple (or the 5-tuple) as the flow classifier on the network which is o= k > by me since it leads to TCP parity. > > > > Thanks > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar > *Sent:* Sunday, February 4, 2018 8:35 PM > *To:* Salz, Rich > *Cc:* Lubashev, Igor ; Roberto Peon ; > QUIC WG > *Subject:* Re: Packet number encryption > > > > Privacy-protection can't be a user choice, for the reasons others have > noted on this thread. > > > That said, my primary argument is for encryption to avoid ossification. > Not that it matters now, but I'll note that much of GQUIC's original > motivation for encrypting headers was to avoid ossification. > > > > I'll reiterate that fields we expose will get ossified and there are > long-term ecosystem effects to this. Let me illustrate this with precisel= y > the packet number field. Middleboxes commonly assume that a TCP flow can > only handle packets in-order. This assumption comes from the fact that TC= P > implementations get poor performance when packets are reordered. This was > definitely true for implementations of TCP, but that is TCP's problem, no= t > the network's. However, almost all load-balancers I know of now will pin > all packets within a TCP flow to one path, leading to sub-optimal > performance in the network, and destroying incentives for the endpoints t= o > deploy reordering-resilient TCP implementations (even though there are > plenty of ways of doing this.) > > > > Exposing QUIC's packet number field (as any field) is likely to have > similar consequences and a similar ecosystem arc. > > > > > > On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: > > > Optional security tends to devolve to non-secure. > > > > That=E2=80=99s a great aphorism. And sadly all too true. > > > > > > > --001a1140fe58843f8505648628bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Option 2 is the only option that allows us to correct our = decision in the future. If we were to discover that it doesn't work out= as we planned (wrt encryption performance, network manageability or litera= lly any other unforeseen problem), going back to option 1 (or coming up wit= h another clever solution) in a future QUIC version would still be a viable= option.
Option 1 on the other hand, once deployed, immediately puts us= at risk of ossification by middleboxes, which will prohibit us from ever s= witching to option 2 for a future QUIC version.

On Tue, Feb 6, 2018 at 3:10 PM Praveen Ba= lasubramanian <pravb@microsoft.co= m> wrote:

Oops sorry I think I misread that 1 requires random = jumps only around migration and not always, which means its decidedly infer= ior to 2 w.r.t. ossification. Can we include a 1.1 which incorporates rando= m jumps even in steady state? Or have we ruled that option out?

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Monday, February 5, 2018 7:13 PM
To: Jana Iyengar <jri@google.com>


Cc: Salz, Rich <rsalz@akamai.com>; Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon &= lt;fenix@fb.com>; = QUIC WG <quic@ietf.or= g>

Subject: RE: Packet number encryption

=C2=A0

My opinion is for 1 over 2 but I can live with eithe= r. The main concern is cost of another encryption / decryption step, so the= benefit of 2 over 1 should be demonstrably better on one of ossification, = privacy, or manageability.

=C2=A0

From: Jana Iyengar [mailto:jri@google.com]
Sent: Monday, February 5, 2018 4:31 PM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Salz, Rich <rsalz@akamai.com>; Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon &= lt;fenix@fb.com>; = QUIC WG <quic@ietf.or= g>
Subject: Re: Packet number encryption

=C2=A0

I don't think we're converging here, so I= 9;d like to try and encourage us to move towards it. I have my opinion, but= I care more about forward progress at this point.

=C2=A0

There are three designs so far:

1. Packet numbers as is, with random gaps around mig= ration.

2. Packet numbers encrypted, as per Martin's PR.=

3. Packet numbers encrypted, plus a small modulo seq= uence number somewhere.

=C2=A0

The concrete ones here are (1) and (2).=C2=A0=C2=A0<= span style=3D"font-size:12.0pt;font-family:"Arial",sans-serif;col= or:#222222;background:white">I'm listing (3) but am not inclined to con= sider it seriously, since it's not concrete enough, (and I don't want more bits to be spent in the QUIC packet header if that's where t= his info goes.)

There are opinions about ossification, privacy, and manageability. I'm = not hearing bloody murder, so for what it's worth, I'd like to stip= ulate first that we can all live with the final design, whichever one it is= .=C2=A0 If anyone disagrees, please say so -- I think it'd be useful to hear if there are folks who think a particular desig= n is fundamentally problematic.

=C2=A0

My opinion is still fo= r (2) over (1), but I can live with either.

=C2=A0

On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar <jri@google.com> wro= te:

Praveen,

=C2=A0

That was precisely my point about the e= cosystem evolving. Now that we have the ability to classify flows, various = things have been built around being able to tell TCP flows. This obviously has benefits as you point out, but the downside = is that that I can't get good network utilization with a single flow. I= understand the scaling point, but speakin= g of common cases, any server in the wild is usually serving a large number of connections at moderate speeds, not a= single one at 25-35 Gbps... which makes that sort of scaling less exciting= than in a microbenchmark.

=C2=A0

FWIW, the other downsi= de of ECMP is that multipath transport doesn't work -- you need to hash= on something else besides the 4-tuple. (We had to work around this in Google's deployment of connection migration.)

=C2=A0

I'll disagree with your point about reordering b= eing the uncommon case. While that's true today, this is again an expec= tation that the network works hard to maintain, though the ecosystem and wh= at we expect as "usual" would be quite different had we not built TCP's requirements into the network. There's noth= ing wrong with having n-modal latencies... we can engineer around that. Any= sensible load distribution scheme within the network will give you increas= ed variance but it should limit the worst-case latency. You'd perhaps agree that that's a net win.<= /p>

=C2=A0

This was an example of how exposing packet number or= not can have long term ecosystem effects. My point was about the fact that= exposing can cause ossification.

=C2=A0

- jana

=C2=A0

On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubraman= ian <pravb@micr= osoft.com> wrote:

>> This was definitely true for implementation= s of TCP, but that is TCP's problem, not the network's

Flow classification happens through the network and = also on the end host with RSS where a flow is mapped to a core. This allows= for building high performance receive processing that could be lock free for the most part. The only downside of ECMP on th= e network and RSS on the CPU is that a single flow will not take multiple p= aths or get processed on more than one core. Windows on server machines tod= ay can saturate 25-35 Gbps for a single TCP connection before being CPU limited. This is a =C2=A0reasonable= trade off because I don=E2=80=99t know of cases where a single flow is dri= ving more than that amount of traffic. Assumptions about how flows get clas= sified help make for more efficient processing. They also lead to consistent latency. You do not want the traffic to take = a bi-modal or N-modal paths (on the network or the host) to being processed= because the fluctuations in latency will hurt the workload. I am not argui= ng for TCP not being resilient to reordering but IMO that should be the uncommon case not the common case. W= ith QUIC if streams were exposed on the network you could take advantage of= stream level ECMP and RSS to scale better than TCP but we have chosen to k= eep the 4-tuple (or the 5-tuple) as the flow classifier on the network which is ok by me since it leads to = TCP parity.

=C2=A0

Thanks

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Sunday, February 4, 2018 8:35 PM
To: Salz, Rich <rsalz@akamai.com>
Cc: Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon <fenix@fb.com>; QUIC WG <quic@ietf.org>
Subject: Re: Packet number encryption

=C2=A0

Privacy-protection can't be a user choice, for t= he reasons others have noted on this thread.=C2=A0


That said, my primary argument is for encryption to avoid ossification. Not= that it matters now, but I'll note that much of GQUIC's original m= otivation for encrypting headers was to avoid ossification.

=C2=A0

I'll reiterate that fields we expose will get os= sified and there are long-term ecosystem effects to this. Let me illustrate= this with precisely the packet number field. Middleboxes commonly assume that a TCP flow can only handle packets in-order. This ass= umption comes from the fact that TCP implementations get poor performance w= hen packets are reordered. This was definitely true for implementations of = TCP, but that is TCP's problem, not the network's. However, almost all load-balancers I know of now wi= ll pin all packets within a TCP flow to one path, leading to sub-optimal pe= rformance in the network, and destroying incentives for the endpoints to de= ploy reordering-resilient TCP implementations (even though there are plenty of ways of doing this.)

=C2=A0

Exposing QUIC's packet number field (as any fiel= d) is likely to have similar consequences and a similar ecosystem arc.

=C2=A0

=C2=A0

On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <rsalz@akamai.com> w= rote:

> Optional security tend= s to devolve to non-secure.

=C2=A0

That=E2=80=99s a great aphorism.=C2=A0 And sadly all too true.

=C2=A0

=C2=A0

=C2=A0

--001a1140fe58843f8505648628bd-- From nobody Mon Feb 5 23:35:06 2018 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 620AB126CF9 for ; Mon, 5 Feb 2018 23:35:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.229 X-Spam-Level: X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_RP_MATCHES_RCVD=-0.01, 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 jkbkIiQyMuvm for ; Mon, 5 Feb 2018 23:35:00 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 45783126CD6 for ; Mon, 5 Feb 2018 23:35:00 -0800 (PST) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 2688212274EA for ; Tue, 6 Feb 2018 07:34:56 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 6 Feb 2018 07:34:57 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Tue, 6 Feb 2018 15:34:49 +0800 From: "Roni Even (A)" To: Marten Seemann , Praveen Balasubramanian CC: Jana Iyengar , "Lubashev, Igor" , Roberto Peon , QUIC WG , "Salz, Rich" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTnxxjs2xD/Oha40aWBKSZaocvJqOW+2JQ Date: Tue, 6 Feb 2018 07:34:50 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8621FA@DGGEMM506-MBX.china.huawei.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.244] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8621FADGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 06 Feb 2018 07:35:04 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8621FADGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpUaGlzIGlzIHdoYXQgdmVyc2lvbiBuZWdvdGlhdGlvbiBpcyBmb3IsIHlvdSBjYW4gY2hh bmdlIGl0IGluIGZ1dHVyZSB2ZXJzaW9uIGJhc2VkIG9uIHZlcnNpb24gbnVtYmVyLg0KUm9uaQ0K DQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg TWFydGVuIFNlZW1hbm4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE4IDk6MzEgQU0N ClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KQ2M6IEphbmEgSXllbmdhcjsgTHViYXNoZXYs IElnb3I7IFJvYmVydG8gUGVvbjsgUVVJQyBXRzsgU2FseiwgUmljaA0KU3ViamVjdDogUmU6IFBh Y2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpPcHRpb24gMiBpcyB0aGUgb25seSBvcHRpb24gdGhh dCBhbGxvd3MgdXMgdG8gY29ycmVjdCBvdXIgZGVjaXNpb24gaW4gdGhlIGZ1dHVyZS4gSWYgd2Ug d2VyZSB0byBkaXNjb3ZlciB0aGF0IGl0IGRvZXNuJ3Qgd29yayBvdXQgYXMgd2UgcGxhbm5lZCAo d3J0IGVuY3J5cHRpb24gcGVyZm9ybWFuY2UsIG5ldHdvcmsgbWFuYWdlYWJpbGl0eSBvciBsaXRl cmFsbHkgYW55IG90aGVyIHVuZm9yZXNlZW4gcHJvYmxlbSksIGdvaW5nIGJhY2sgdG8gb3B0aW9u IDEgKG9yIGNvbWluZyB1cCB3aXRoIGFub3RoZXIgY2xldmVyIHNvbHV0aW9uKSBpbiBhIGZ1dHVy ZSBRVUlDIHZlcnNpb24gd291bGQgc3RpbGwgYmUgYSB2aWFibGUgb3B0aW9uLg0KT3B0aW9uIDEg b24gdGhlIG90aGVyIGhhbmQsIG9uY2UgZGVwbG95ZWQsIGltbWVkaWF0ZWx5IHB1dHMgdXMgYXQg cmlzayBvZiBvc3NpZmljYXRpb24gYnkgbWlkZGxlYm94ZXMsIHdoaWNoIHdpbGwgcHJvaGliaXQg dXMgZnJvbSBldmVyIHN3aXRjaGluZyB0byBvcHRpb24gMiBmb3IgYSBmdXR1cmUgUVVJQyB2ZXJz aW9uLg0KDQpPbiBUdWUsIEZlYiA2LCAyMDE4IGF0IDM6MTAgUE0gUHJhdmVlbiBCYWxhc3VicmFt YW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PiB3 cm90ZToNCk9vcHMgc29ycnkgSSB0aGluayBJIG1pc3JlYWQgdGhhdCAxIHJlcXVpcmVzIHJhbmRv bSBqdW1wcyBvbmx5IGFyb3VuZCBtaWdyYXRpb24gYW5kIG5vdCBhbHdheXMsIHdoaWNoIG1lYW5z IGl0cyBkZWNpZGVkbHkgaW5mZXJpb3IgdG8gMiB3LnIudC4gb3NzaWZpY2F0aW9uLiBDYW4gd2Ug aW5jbHVkZSBhIDEuMSB3aGljaCBpbmNvcnBvcmF0ZXMgcmFuZG9tIGp1bXBzIGV2ZW4gaW4gc3Rl YWR5IHN0YXRlPyBPciBoYXZlIHdlIHJ1bGVkIHRoYXQgb3B0aW9uIG91dD8NCg0KRnJvbTogUVVJ QyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQpTZW50OiBNb25kYXks IEZlYnJ1YXJ5IDUsIDIwMTggNzoxMyBQTQ0KVG86IEphbmEgSXllbmdhciA8anJpQGdvb2dsZS5j b208bWFpbHRvOmpyaUBnb29nbGUuY29tPj4NCg0KQ2M6IFNhbHosIFJpY2ggPHJzYWx6QGFrYW1h aS5jb208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PjsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hl QGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PjsgUm9iZXJ0byBQZW9uIDxm ZW5peEBmYi5jb208bWFpbHRvOmZlbml4QGZiLmNvbT4+OyBRVUlDIFdHIDxxdWljQGlldGYub3Jn PG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5 cHRpb24NCg0KTXkgb3BpbmlvbiBpcyBmb3IgMSBvdmVyIDIgYnV0IEkgY2FuIGxpdmUgd2l0aCBl aXRoZXIuIFRoZSBtYWluIGNvbmNlcm4gaXMgY29zdCBvZiBhbm90aGVyIGVuY3J5cHRpb24gLyBk ZWNyeXB0aW9uIHN0ZXAsIHNvIHRoZSBiZW5lZml0IG9mIDIgb3ZlciAxIHNob3VsZCBiZSBkZW1v bnN0cmFibHkgYmV0dGVyIG9uIG9uZSBvZiBvc3NpZmljYXRpb24sIHByaXZhY3ksIG9yIG1hbmFn ZWFiaWxpdHkuDQoNCkZyb206IEphbmEgSXllbmdhciBbbWFpbHRvOmpyaUBnb29nbGUuY29tXQ0K U2VudDogTW9uZGF5LCBGZWJydWFyeSA1LCAyMDE4IDQ6MzEgUE0NClRvOiBQcmF2ZWVuIEJhbGFz dWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNv bT4+DQpDYzogU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFp LmNvbT4+OyBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFz aGVAYWthbWFpLmNvbT4+OyBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbTxtYWlsdG86ZmVuaXhA ZmIuY29tPj47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpJIGRvbid0IHRoaW5rIHdl J3JlIGNvbnZlcmdpbmcgaGVyZSwgc28gSSdkIGxpa2UgdG8gdHJ5IGFuZCBlbmNvdXJhZ2UgdXMg dG8gbW92ZSB0b3dhcmRzIGl0LiBJIGhhdmUgbXkgb3BpbmlvbiwgYnV0IEkgY2FyZSBtb3JlIGFi b3V0IGZvcndhcmQgcHJvZ3Jlc3MgYXQgdGhpcyBwb2ludC4NCg0KVGhlcmUgYXJlIHRocmVlIGRl c2lnbnMgc28gZmFyOg0KMS4gUGFja2V0IG51bWJlcnMgYXMgaXMsIHdpdGggcmFuZG9tIGdhcHMg YXJvdW5kIG1pZ3JhdGlvbi4NCjIuIFBhY2tldCBudW1iZXJzIGVuY3J5cHRlZCwgYXMgcGVyIE1h cnRpbidzIFBSLg0KMy4gUGFja2V0IG51bWJlcnMgZW5jcnlwdGVkLCBwbHVzIGEgc21hbGwgbW9k dWxvIHNlcXVlbmNlIG51bWJlciBzb21ld2hlcmUuDQoNClRoZSBjb25jcmV0ZSBvbmVzIGhlcmUg YXJlICgxKSBhbmQgKDIpLiAgSSdtIGxpc3RpbmcgKDMpIGJ1dCBhbSBub3QgaW5jbGluZWQgdG8g Y29uc2lkZXIgaXQgc2VyaW91c2x5LCBzaW5jZSBpdCdzIG5vdCBjb25jcmV0ZSBlbm91Z2gsIChh bmQgSSBkb24ndCB3YW50IG1vcmUgYml0cyB0byBiZSBzcGVudCBpbiB0aGUgUVVJQyBwYWNrZXQg aGVhZGVyIGlmIHRoYXQncyB3aGVyZSB0aGlzIGluZm8gZ29lcy4pDQoNClRoZXJlIGFyZSBvcGlu aW9ucyBhYm91dCBvc3NpZmljYXRpb24sIHByaXZhY3ksIGFuZCBtYW5hZ2VhYmlsaXR5LiBJJ20g bm90IGhlYXJpbmcgYmxvb2R5IG11cmRlciwgc28gZm9yIHdoYXQgaXQncyB3b3J0aCwgSSdkIGxp a2UgdG8gc3RpcHVsYXRlIGZpcnN0IHRoYXQgd2UgY2FuIGFsbCBsaXZlIHdpdGggdGhlIGZpbmFs IGRlc2lnbiwgd2hpY2hldmVyIG9uZSBpdCBpcy4gIElmIGFueW9uZSBkaXNhZ3JlZXMsIHBsZWFz ZSBzYXkgc28gLS0gSSB0aGluayBpdCdkIGJlIHVzZWZ1bCB0byBoZWFyIGlmIHRoZXJlIGFyZSBm b2xrcyB3aG8gdGhpbmsgYSBwYXJ0aWN1bGFyIGRlc2lnbiBpcyBmdW5kYW1lbnRhbGx5IHByb2Js ZW1hdGljLg0KDQpNeSBvcGluaW9uIGlzIHN0aWxsIGZvciAoMikgb3ZlciAoMSksIGJ1dCBJIGNh biBsaXZlIHdpdGggZWl0aGVyLg0KDQpPbiBNb24sIEZlYiA1LCAyMDE4IGF0IDM6MzIgUE0sIEph bmEgSXllbmdhciA8anJpQGdvb2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29tPj4gd3JvdGU6 DQpQcmF2ZWVuLA0KDQpUaGF0IHdhcyBwcmVjaXNlbHkgbXkgcG9pbnQgYWJvdXQgdGhlIGVjb3N5 c3RlbSBldm9sdmluZy4gTm93IHRoYXQgd2UgaGF2ZSB0aGUgYWJpbGl0eSB0byBjbGFzc2lmeSBm bG93cywgdmFyaW91cyB0aGluZ3MgaGF2ZSBiZWVuIGJ1aWx0IGFyb3VuZCBiZWluZyBhYmxlIHRv IHRlbGwgVENQIGZsb3dzLiBUaGlzIG9idmlvdXNseSBoYXMgYmVuZWZpdHMgYXMgeW91IHBvaW50 IG91dCwgYnV0IHRoZSBkb3duc2lkZSBpcyB0aGF0IHRoYXQgSSBjYW4ndCBnZXQgZ29vZCBuZXR3 b3JrIHV0aWxpemF0aW9uIHdpdGggYSBzaW5nbGUgZmxvdy4gSSB1bmRlcnN0YW5kIHRoZSBzY2Fs aW5nIHBvaW50LCBidXQgc3BlYWtpbmcgb2YgY29tbW9uIGNhc2VzLCBhbnkgc2VydmVyIGluIHRo ZSB3aWxkIGlzIHVzdWFsbHkgc2VydmluZyBhIGxhcmdlIG51bWJlciBvZiBjb25uZWN0aW9ucyBh dCBtb2RlcmF0ZSBzcGVlZHMsIG5vdCBhIHNpbmdsZSBvbmUgYXQgMjUtMzUgR2Jwcy4uLiB3aGlj aCBtYWtlcyB0aGF0IHNvcnQgb2Ygc2NhbGluZyBsZXNzIGV4Y2l0aW5nIHRoYW4gaW4gYSBtaWNy b2JlbmNobWFyay4NCg0KRldJVywgdGhlIG90aGVyIGRvd25zaWRlIG9mIEVDTVAgaXMgdGhhdCBt dWx0aXBhdGggdHJhbnNwb3J0IGRvZXNuJ3Qgd29yayAtLSB5b3UgbmVlZCB0byBoYXNoIG9uIHNv bWV0aGluZyBlbHNlIGJlc2lkZXMgdGhlIDQtdHVwbGUuIChXZSBoYWQgdG8gd29yayBhcm91bmQg dGhpcyBpbiBHb29nbGUncyBkZXBsb3ltZW50IG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uLikNCg0K SSdsbCBkaXNhZ3JlZSB3aXRoIHlvdXIgcG9pbnQgYWJvdXQgcmVvcmRlcmluZyBiZWluZyB0aGUg dW5jb21tb24gY2FzZS4gV2hpbGUgdGhhdCdzIHRydWUgdG9kYXksIHRoaXMgaXMgYWdhaW4gYW4g ZXhwZWN0YXRpb24gdGhhdCB0aGUgbmV0d29yayB3b3JrcyBoYXJkIHRvIG1haW50YWluLCB0aG91 Z2ggdGhlIGVjb3N5c3RlbSBhbmQgd2hhdCB3ZSBleHBlY3QgYXMgInVzdWFsIiB3b3VsZCBiZSBx dWl0ZSBkaWZmZXJlbnQgaGFkIHdlIG5vdCBidWlsdCBUQ1AncyByZXF1aXJlbWVudHMgaW50byB0 aGUgbmV0d29yay4gVGhlcmUncyBub3RoaW5nIHdyb25nIHdpdGggaGF2aW5nIG4tbW9kYWwgbGF0 ZW5jaWVzLi4uIHdlIGNhbiBlbmdpbmVlciBhcm91bmQgdGhhdC4gQW55IHNlbnNpYmxlIGxvYWQg ZGlzdHJpYnV0aW9uIHNjaGVtZSB3aXRoaW4gdGhlIG5ldHdvcmsgd2lsbCBnaXZlIHlvdSBpbmNy ZWFzZWQgdmFyaWFuY2UgYnV0IGl0IHNob3VsZCBsaW1pdCB0aGUgd29yc3QtY2FzZSBsYXRlbmN5 LiBZb3UnZCBwZXJoYXBzIGFncmVlIHRoYXQgdGhhdCdzIGEgbmV0IHdpbi4NCg0KVGhpcyB3YXMg YW4gZXhhbXBsZSBvZiBob3cgZXhwb3NpbmcgcGFja2V0IG51bWJlciBvciBub3QgY2FuIGhhdmUg bG9uZyB0ZXJtIGVjb3N5c3RlbSBlZmZlY3RzLiBNeSBwb2ludCB3YXMgYWJvdXQgdGhlIGZhY3Qg dGhhdCBleHBvc2luZyBjYW4gY2F1c2Ugb3NzaWZpY2F0aW9uLg0KDQotIGphbmENCg0KT24gTW9u LCBGZWIgNSwgMjAxOCBhdCA5OjI0IEFNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJA bWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KPj4gVGhp cyB3YXMgZGVmaW5pdGVseSB0cnVlIGZvciBpbXBsZW1lbnRhdGlvbnMgb2YgVENQLCBidXQgdGhh dCBpcyBUQ1AncyBwcm9ibGVtLCBub3QgdGhlIG5ldHdvcmsncw0KRmxvdyBjbGFzc2lmaWNhdGlv biBoYXBwZW5zIHRocm91Z2ggdGhlIG5ldHdvcmsgYW5kIGFsc28gb24gdGhlIGVuZCBob3N0IHdp dGggUlNTIHdoZXJlIGEgZmxvdyBpcyBtYXBwZWQgdG8gYSBjb3JlLiBUaGlzIGFsbG93cyBmb3Ig YnVpbGRpbmcgaGlnaCBwZXJmb3JtYW5jZSByZWNlaXZlIHByb2Nlc3NpbmcgdGhhdCBjb3VsZCBi ZSBsb2NrIGZyZWUgZm9yIHRoZSBtb3N0IHBhcnQuIFRoZSBvbmx5IGRvd25zaWRlIG9mIEVDTVAg b24gdGhlIG5ldHdvcmsgYW5kIFJTUyBvbiB0aGUgQ1BVIGlzIHRoYXQgYSBzaW5nbGUgZmxvdyB3 aWxsIG5vdCB0YWtlIG11bHRpcGxlIHBhdGhzIG9yIGdldCBwcm9jZXNzZWQgb24gbW9yZSB0aGFu IG9uZSBjb3JlLiBXaW5kb3dzIG9uIHNlcnZlciBtYWNoaW5lcyB0b2RheSBjYW4gc2F0dXJhdGUg MjUtMzUgR2JwcyBmb3IgYSBzaW5nbGUgVENQIGNvbm5lY3Rpb24gYmVmb3JlIGJlaW5nIENQVSBs aW1pdGVkLiBUaGlzIGlzIGEgIHJlYXNvbmFibGUgdHJhZGUgb2ZmIGJlY2F1c2UgSSBkb27igJl0 IGtub3cgb2YgY2FzZXMgd2hlcmUgYSBzaW5nbGUgZmxvdyBpcyBkcml2aW5nIG1vcmUgdGhhbiB0 aGF0IGFtb3VudCBvZiB0cmFmZmljLiBBc3N1bXB0aW9ucyBhYm91dCBob3cgZmxvd3MgZ2V0IGNs YXNzaWZpZWQgaGVscCBtYWtlIGZvciBtb3JlIGVmZmljaWVudCBwcm9jZXNzaW5nLiBUaGV5IGFs c28gbGVhZCB0byBjb25zaXN0ZW50IGxhdGVuY3kuIFlvdSBkbyBub3Qgd2FudCB0aGUgdHJhZmZp YyB0byB0YWtlIGEgYmktbW9kYWwgb3IgTi1tb2RhbCBwYXRocyAob24gdGhlIG5ldHdvcmsgb3Ig dGhlIGhvc3QpIHRvIGJlaW5nIHByb2Nlc3NlZCBiZWNhdXNlIHRoZSBmbHVjdHVhdGlvbnMgaW4g bGF0ZW5jeSB3aWxsIGh1cnQgdGhlIHdvcmtsb2FkLiBJIGFtIG5vdCBhcmd1aW5nIGZvciBUQ1Ag bm90IGJlaW5nIHJlc2lsaWVudCB0byByZW9yZGVyaW5nIGJ1dCBJTU8gdGhhdCBzaG91bGQgYmUg dGhlIHVuY29tbW9uIGNhc2Ugbm90IHRoZSBjb21tb24gY2FzZS4gV2l0aCBRVUlDIGlmIHN0cmVh bXMgd2VyZSBleHBvc2VkIG9uIHRoZSBuZXR3b3JrIHlvdSBjb3VsZCB0YWtlIGFkdmFudGFnZSBv ZiBzdHJlYW0gbGV2ZWwgRUNNUCBhbmQgUlNTIHRvIHNjYWxlIGJldHRlciB0aGFuIFRDUCBidXQg d2UgaGF2ZSBjaG9zZW4gdG8ga2VlcCB0aGUgNC10dXBsZSAob3IgdGhlIDUtdHVwbGUpIGFzIHRo ZSBmbG93IGNsYXNzaWZpZXIgb24gdGhlIG5ldHdvcmsgd2hpY2ggaXMgb2sgYnkgbWUgc2luY2Ug aXQgbGVhZHMgdG8gVENQIHBhcml0eS4NCg0KVGhhbmtzDQoNCkZyb206IFFVSUMgW21haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJl aGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IFN1bmRheSwgRmVicnVhcnkgNCwgMjAxOCA4OjM1 IFBNDQpUbzogU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbTxtYWlsdG86cnNhbHpAYWthbWFp LmNvbT4+DQpDYzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmls dWJhc2hlQGFrYW1haS5jb20+PjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb208bWFpbHRvOmZl bml4QGZiLmNvbT4+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3Jn Pj4NClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KUHJpdmFjeS1wcm90 ZWN0aW9uIGNhbid0IGJlIGEgdXNlciBjaG9pY2UsIGZvciB0aGUgcmVhc29ucyBvdGhlcnMgaGF2 ZSBub3RlZCBvbiB0aGlzIHRocmVhZC4NCg0KVGhhdCBzYWlkLCBteSBwcmltYXJ5IGFyZ3VtZW50 IGlzIGZvciBlbmNyeXB0aW9uIHRvIGF2b2lkIG9zc2lmaWNhdGlvbi4gTm90IHRoYXQgaXQgbWF0 dGVycyBub3csIGJ1dCBJJ2xsIG5vdGUgdGhhdCBtdWNoIG9mIEdRVUlDJ3Mgb3JpZ2luYWwgbW90 aXZhdGlvbiBmb3IgZW5jcnlwdGluZyBoZWFkZXJzIHdhcyB0byBhdm9pZCBvc3NpZmljYXRpb24u DQoNCkknbGwgcmVpdGVyYXRlIHRoYXQgZmllbGRzIHdlIGV4cG9zZSB3aWxsIGdldCBvc3NpZmll ZCBhbmQgdGhlcmUgYXJlIGxvbmctdGVybSBlY29zeXN0ZW0gZWZmZWN0cyB0byB0aGlzLiBMZXQg bWUgaWxsdXN0cmF0ZSB0aGlzIHdpdGggcHJlY2lzZWx5IHRoZSBwYWNrZXQgbnVtYmVyIGZpZWxk LiBNaWRkbGVib3hlcyBjb21tb25seSBhc3N1bWUgdGhhdCBhIFRDUCBmbG93IGNhbiBvbmx5IGhh bmRsZSBwYWNrZXRzIGluLW9yZGVyLiBUaGlzIGFzc3VtcHRpb24gY29tZXMgZnJvbSB0aGUgZmFj dCB0aGF0IFRDUCBpbXBsZW1lbnRhdGlvbnMgZ2V0IHBvb3IgcGVyZm9ybWFuY2Ugd2hlbiBwYWNr ZXRzIGFyZSByZW9yZGVyZWQuIFRoaXMgd2FzIGRlZmluaXRlbHkgdHJ1ZSBmb3IgaW1wbGVtZW50 YXRpb25zIG9mIFRDUCwgYnV0IHRoYXQgaXMgVENQJ3MgcHJvYmxlbSwgbm90IHRoZSBuZXR3b3Jr J3MuIEhvd2V2ZXIsIGFsbW9zdCBhbGwgbG9hZC1iYWxhbmNlcnMgSSBrbm93IG9mIG5vdyB3aWxs IHBpbiBhbGwgcGFja2V0cyB3aXRoaW4gYSBUQ1AgZmxvdyB0byBvbmUgcGF0aCwgbGVhZGluZyB0 byBzdWItb3B0aW1hbCBwZXJmb3JtYW5jZSBpbiB0aGUgbmV0d29yaywgYW5kIGRlc3Ryb3lpbmcg aW5jZW50aXZlcyBmb3IgdGhlIGVuZHBvaW50cyB0byBkZXBsb3kgcmVvcmRlcmluZy1yZXNpbGll bnQgVENQIGltcGxlbWVudGF0aW9ucyAoZXZlbiB0aG91Z2ggdGhlcmUgYXJlIHBsZW50eSBvZiB3 YXlzIG9mIGRvaW5nIHRoaXMuKQ0KDQpFeHBvc2luZyBRVUlDJ3MgcGFja2V0IG51bWJlciBmaWVs ZCAoYXMgYW55IGZpZWxkKSBpcyBsaWtlbHkgdG8gaGF2ZSBzaW1pbGFyIGNvbnNlcXVlbmNlcyBh bmQgYSBzaW1pbGFyIGVjb3N5c3RlbSBhcmMuDQoNCg0KT24gU3VuLCBGZWIgNCwgMjAxOCBhdCA3 OjUxIFBNLCBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpyc2FsekBha2FtYWku Y29tPj4gd3JvdGU6DQoNCj4gT3B0aW9uYWwgc2VjdXJpdHkgdGVuZHMgdG8gZGV2b2x2ZSB0byBu b24tc2VjdXJlLg0KDQoNCg0KVGhhdOKAmXMgYSBncmVhdCBhcGhvcmlzbS4gIEFuZCBzYWRseSBh bGwgdG9vIHRydWUuDQoNCg0KDQo= --_000_6E58094ECC8D8344914996DAD28F1CCD8621FADGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLm05MDYzNzQwNjg0NzA4ODkwNm03MDk1Mzc0MTgy MTE2MzI0MDM0bTIwODA3NTkyNDExNzIwOTY5NzFtLTc5MTQ4NzYwODI0MjU3ODUwNHhtc29ub3Jt YWwsIGxpLm05MDYzNzQwNjg0NzA4ODkwNm03MDk1Mzc0MTgyMTE2MzI0MDM0bTIwODA3NTkyNDEx NzIwOTY5NzFtLTc5MTQ4NzYwODI0MjU3ODUwNHhtc29ub3JtYWwsIGRpdi5tOTA2Mzc0MDY4NDcw ODg5MDZtNzA5NTM3NDE4MjExNjMyNDAzNG0yMDgwNzU5MjQxMTcyMDk2OTcxbS03OTE0ODc2MDgy NDI1Nzg1MDR4bXNvbm9ybWFsDQoJe21zby1zdHlsZS1uYW1lOm1fOTA2Mzc0MDY4NDcwODg5MDZt NzA5NTM3NDE4MjExNjMyNDAzNG0yMDgwNzU5MjQxMTcyMDk2OTcxbS03OTE0ODc2MDgyNDI1Nzg1 MDR4bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGks PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoaXMgaXMgd2hhdCB2ZXJzaW9uIG5lZ290 aWF0aW9uIGlzIGZvciwgeW91IGNhbiBjaGFuZ2UgaXQgaW4gZnV0dXJlIHZlcnNpb24gYmFzZWQg b24gdmVyc2lvbiBudW1iZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbmk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFFVSUMgW21haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hcnRlbiBTZWVtYW5uPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDA2LCAyMDE4IDk6MzEgQU08YnI+DQo8 Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuPGJyPg0KPGI+Q2M6PC9iPiBKYW5hIEl5 ZW5nYXI7IEx1YmFzaGV2LCBJZ29yOyBSb2JlcnRvIFBlb247IFFVSUMgV0c7IFNhbHosIFJpY2g8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9wdGlvbiAyIGlzIHRoZSBvbmx5IG9wdGlv biB0aGF0IGFsbG93cyB1cyB0byBjb3JyZWN0IG91ciBkZWNpc2lvbiBpbiB0aGUgZnV0dXJlLiBJ ZiB3ZSB3ZXJlIHRvIGRpc2NvdmVyIHRoYXQgaXQgZG9lc24ndCB3b3JrIG91dCBhcyB3ZSBwbGFu bmVkICh3cnQgZW5jcnlwdGlvbiBwZXJmb3JtYW5jZSwgbmV0d29yayBtYW5hZ2VhYmlsaXR5IG9y IGxpdGVyYWxseSBhbnkgb3RoZXIgdW5mb3Jlc2VlbiBwcm9ibGVtKSwNCiBnb2luZyBiYWNrIHRv IG9wdGlvbiAxIChvciBjb21pbmcgdXAgd2l0aCBhbm90aGVyIGNsZXZlciBzb2x1dGlvbikgaW4g YSBmdXR1cmUgUVVJQyB2ZXJzaW9uIHdvdWxkIHN0aWxsIGJlIGEgdmlhYmxlIG9wdGlvbi48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PcHRpb24gMSBvbiB0aGUg b3RoZXIgaGFuZCwgb25jZSBkZXBsb3llZCwgaW1tZWRpYXRlbHkgcHV0cyB1cyBhdCByaXNrIG9m IG9zc2lmaWNhdGlvbiBieSBtaWRkbGVib3hlcywgd2hpY2ggd2lsbCBwcm9oaWJpdCB1cyBmcm9t IGV2ZXIgc3dpdGNoaW5nIHRvIG9wdGlvbiAyIGZvciBhIGZ1dHVyZSBRVUlDIHZlcnNpb24uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1 ZSwgRmViIDYsIDIwMTggYXQgMzoxMCBQTSBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iPnByYXZiQG1pY3Jvc29mdC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Pb3BzIHNvcnJ5IEkgdGhpbmsgSSBtaXNyZWFk IHRoYXQgMSByZXF1aXJlcyByYW5kb20ganVtcHMgb25seSBhcm91bmQgbWlncmF0aW9uIGFuZCBu b3QgYWx3YXlzLCB3aGljaCBtZWFucyBpdHMgZGVjaWRlZGx5IGluZmVyaW9yIHRvIDIgdy5yLnQu IG9zc2lmaWNhdGlvbi4gQ2FuIHdlIGluY2x1ZGUgYSAxLjENCiB3aGljaCBpbmNvcnBvcmF0ZXMg cmFuZG9tIGp1bXBzIGV2ZW4gaW4gc3RlYWR5IHN0YXRlPyBPciBoYXZlIHdlIHJ1bGVkIHRoYXQg b3B0aW9uIG91dD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDUsIDIwMTggNzoxMyBQTTxicj4NCjxi PlRvOjwvYj4gSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+Q2M6 PC9iPiBTYWx6LCBSaWNoICZsdDs8YSBocmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnJzYWx6QGFrYW1haS5jb208L2E+Jmd0OzsgTHViYXNoZXYsIElnb3IgJmx0 OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWx1 YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7OyBSb2JlcnRvIFBlb24gJmx0OzxhIGhyZWY9Im1haWx0 bzpmZW5peEBmYi5jb20iIHRhcmdldD0iX2JsYW5rIj5mZW5peEBmYi5jb208L2E+Jmd0OzsNCiBR VUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPlN1YmplY3Q6PC9iPiBSRTogUGFja2V0IG51 bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TXkgb3BpbmlvbiBpcyBmb3IgMSBvdmVy IDIgYnV0IEkgY2FuIGxpdmUgd2l0aCBlaXRoZXIuIFRoZSBtYWluIGNvbmNlcm4gaXMgY29zdCBv ZiBhbm90aGVyIGVuY3J5cHRpb24gLyBkZWNyeXB0aW9uIHN0ZXAsIHNvIHRoZSBiZW5lZml0IG9m IDIgb3ZlciAxIHNob3VsZCBiZSBkZW1vbnN0cmFibHkgYmV0dGVyDQogb24gb25lIG9mIG9zc2lm aWNhdGlvbiwgcHJpdmFjeSwgb3IgbWFuYWdlYWJpbGl0eS4gPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj5Gcm9tOjwvYj4gSmFuYSBJeWVuZ2FyIFs8YSBocmVmPSJtYWlsdG86anJpQGdv b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86anJpQGdvb2dsZS5jb208L2E+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgNSwgMjAxOCA0OjMxIFBNPGJyPg0KPGI+ VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZi QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IFNhbHosIFJpY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpyc2FsekBh a2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+cnNhbHpAYWthbWFpLmNvbTwvYT4mZ3Q7OyBMdWJh c2hldiwgSWdvciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iIHRhcmdl dD0iX2JsYW5rIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZndDs7IFJvYmVydG8gUGVvbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmZlbml4QGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZlbml4QGZiLmNv bTwvYT4mZ3Q7Ow0KIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5JIGRvbid0IHRoaW5rIHdlJ3JlIGNvbnZlcmdpbmcgaGVyZSwgc28gSSdkIGxpa2Ug dG8gdHJ5IGFuZCBlbmNvdXJhZ2UgdXMgdG8gbW92ZSB0b3dhcmRzIGl0LiBJIGhhdmUgbXkgb3Bp bmlvbiwgYnV0IEkgY2FyZSBtb3JlIGFib3V0IGZvcndhcmQgcHJvZ3Jlc3MgYXQgdGhpcyBwb2lu dC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGVy ZSBhcmUgdGhyZWUgZGVzaWducyBzbyBmYXI6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjEuIFBhY2tldCBudW1iZXJzIGFzIGlzLCB3aXRoIHJh bmRvbSBnYXBzIGFyb3VuZCBtaWdyYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjIuIFBhY2tldCBudW1iZXJzIGVuY3J5cHRlZCwgYXMg cGVyIE1hcnRpbidzIFBSLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4zLiBQYWNrZXQgbnVtYmVycyBlbmNyeXB0ZWQsIHBsdXMgYSBzbWFsbCBt b2R1bG8gc2VxdWVuY2UgbnVtYmVyIHNvbWV3aGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBjb25jcmV0ZSBvbmVzIGhlcmUg YXJlICgxKSBhbmQgKDIpLiZuYnNwOyZuYnNwOzxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dy b3VuZDp3aGl0ZSI+SSdtIGxpc3RpbmcgKDMpIGJ1dCBhbSBub3QgaW5jbGluZWQgdG8gY29uc2lk ZXIgaXQgc2VyaW91c2x5LA0KIHNpbmNlIGl0J3Mgbm90IGNvbmNyZXRlIGVub3VnaCwgKGFuZCBJ IGRvbid0IHdhbnQgbW9yZSBiaXRzIHRvIGJlIHNwZW50IGluIHRoZSBRVUlDIHBhY2tldCBoZWFk ZXIgaWYgdGhhdCdzIHdoZXJlIHRoaXMgaW5mbyBnb2VzLik8L3NwYW4+PGJyPg0KPGJyPg0KVGhl cmUgYXJlIG9waW5pb25zIGFib3V0IG9zc2lmaWNhdGlvbiwgcHJpdmFjeSwgYW5kIG1hbmFnZWFi aWxpdHkuIEknbSBub3QgaGVhcmluZyBibG9vZHkgbXVyZGVyLCBzbyBmb3Igd2hhdCBpdCdzIHdv cnRoLCBJJ2QgbGlrZSB0byBzdGlwdWxhdGUgZmlyc3QgdGhhdCB3ZSBjYW4gYWxsIGxpdmUgd2l0 aCB0aGUgZmluYWwgZGVzaWduLCB3aGljaGV2ZXIgb25lIGl0IGlzLiZuYnNwOyBJZiBhbnlvbmUg ZGlzYWdyZWVzLCBwbGVhc2Ugc2F5IHNvIC0tIEkgdGhpbmsNCiBpdCdkIGJlIHVzZWZ1bCB0byBo ZWFyIGlmIHRoZXJlIGFyZSBmb2xrcyB3aG8gdGhpbmsgYSBwYXJ0aWN1bGFyIGRlc2lnbiBpcyBm dW5kYW1lbnRhbGx5IHByb2JsZW1hdGljLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIyMjIyMjtiYWNrZ3Jv dW5kOndoaXRlIj5NeSBvcGluaW9uIGlzIHN0aWxsIGZvciAoMikgb3ZlciAoMSksIGJ1dCBJIGNh biBsaXZlIHdpdGggZWl0aGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwgRmViIDUsIDIwMTggYXQgMzozMiBQ TSwgSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iIHRhcmdl dD0iX2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5QcmF2ZWVuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzIy MjIyMiI+VGhhdCB3YXMgcHJlY2lzZWx5IG15IHBvaW50IGFib3V0IHRoZSBlY29zeXN0ZW0gZXZv bHZpbmcuIE5vdyB0aGF0IHdlIGhhdmUgdGhlIGFiaWxpdHkgdG8gY2xhc3NpZnkgZmxvd3MsIHZh cmlvdXMgdGhpbmdzDQogaGF2ZSBiZWVuIGJ1aWx0IGFyb3VuZCBiZWluZyBhYmxlIHRvIHRlbGwg VENQIGZsb3dzLiBUaGlzIG9idmlvdXNseSBoYXMgYmVuZWZpdHMgYXMgeW91IHBvaW50IG91dCwg YnV0IHRoZSBkb3duc2lkZSBpcyB0aGF0IHRoYXQgSSBjYW4ndCBnZXQgZ29vZCBuZXR3b3JrIHV0 aWxpemF0aW9uIHdpdGggYSBzaW5nbGUgZmxvdy4gSSB1bmRlcnN0YW5kIHRoZSBzY2FsaW5nIHBv aW50LCBidXQgczxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj5wZWFraW5nDQogb2YgY29t bW9uIGNhc2VzLCBhbnkgc2VydmVyIGluIHRoZSB3aWxkIGlzIHVzdWFsbHkgc2VydmluZyBhIGxh cmdlIG51bWJlciBvZiBjb25uZWN0aW9ucyBhdCBtb2RlcmF0ZSBzcGVlZHMsIG5vdCBhIHNpbmds ZSBvbmUgYXQgMjUtMzUgR2Jwcy4uLiB3aGljaCBtYWtlcyB0aGF0IHNvcnQgb2Ygc2NhbGluZyBs ZXNzIGV4Y2l0aW5nIHRoYW4gaW4gYSBtaWNyb2JlbmNobWFyay48L3NwYW4+PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMjIyMjIyIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMyMjIyMjI7YmFja2dy b3VuZDp3aGl0ZSI+RldJVywgdGhlIG90aGVyIGRvd25zaWRlIG9mIEVDTVAgaXMgdGhhdCBtdWx0 aXBhdGggdHJhbnNwb3J0IGRvZXNuJ3Qgd29yayAtLSB5b3UgbmVlZCB0byBoYXNoIG9uIHNvbWV0 aGluZw0KIGVsc2UgYmVzaWRlcyB0aGUgNC10dXBsZS4gKFdlIGhhZCB0byB3b3JrIGFyb3VuZCB0 aGlzIGluIEdvb2dsZSdzIGRlcGxveW1lbnQgb2YgY29ubmVjdGlvbiBtaWdyYXRpb24uKTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JJ2xsIGRpc2FncmVlIHdpdGggeW91ciBwb2ludCBhYm91dCBy ZW9yZGVyaW5nIGJlaW5nIHRoZSB1bmNvbW1vbiBjYXNlLiBXaGlsZSB0aGF0J3MgdHJ1ZSB0b2Rh eSwgdGhpcyBpcyBhZ2FpbiBhbiBleHBlY3RhdGlvbiB0aGF0IHRoZSBuZXR3b3JrIHdvcmtzIGhh cmQgdG8gbWFpbnRhaW4sIHRob3VnaCB0aGUNCiBlY29zeXN0ZW0gYW5kIHdoYXQgd2UgZXhwZWN0 IGFzICZxdW90O3VzdWFsJnF1b3Q7IHdvdWxkIGJlIHF1aXRlIGRpZmZlcmVudCBoYWQgd2Ugbm90 IGJ1aWx0IFRDUCdzIHJlcXVpcmVtZW50cyBpbnRvIHRoZSBuZXR3b3JrLiBUaGVyZSdzIG5vdGhp bmcgd3Jvbmcgd2l0aCBoYXZpbmcgbi1tb2RhbCBsYXRlbmNpZXMuLi4gd2UgY2FuIGVuZ2luZWVy IGFyb3VuZCB0aGF0LiBBbnkgc2Vuc2libGUgbG9hZCBkaXN0cmlidXRpb24gc2NoZW1lIHdpdGhp biB0aGUgbmV0d29yaw0KIHdpbGwgZ2l2ZSB5b3UgaW5jcmVhc2VkIHZhcmlhbmNlIGJ1dCBpdCBz aG91bGQgbGltaXQgdGhlIHdvcnN0LWNhc2UgbGF0ZW5jeS4gWW91J2QgcGVyaGFwcyBhZ3JlZSB0 aGF0IHRoYXQncyBhIG5ldCB3aW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGlzIHdhcyBhbiBleGFtcGxlIG9mIGhvdyBleHBvc2lu ZyBwYWNrZXQgbnVtYmVyIG9yIG5vdCBjYW4gaGF2ZSBsb25nIHRlcm0gZWNvc3lzdGVtIGVmZmVj dHMuIE15IHBvaW50IHdhcyBhYm91dCB0aGUgZmFjdCB0aGF0IGV4cG9zaW5nIGNhbiBjYXVzZSBv c3NpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojODg4ODg4Ij4tIGphbmE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIE1vbiwg RmViIDUsIDIwMTggYXQgOToyNCBBTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhy ZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHJhdmJAbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jmd0OyZndDsgVGhpcyB3YXMgZGVmaW5pdGVseSB0cnVlIGZvciBpbXBs ZW1lbnRhdGlvbnMgb2YgVENQLCBidXQgdGhhdCBpcyBUQ1AncyBwcm9ibGVtLCBub3QgdGhlIG5l dHdvcmsnczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5GbG93IGNsYXNz aWZpY2F0aW9uIGhhcHBlbnMgdGhyb3VnaCB0aGUgbmV0d29yayBhbmQgYWxzbyBvbiB0aGUgZW5k IGhvc3Qgd2l0aCBSU1Mgd2hlcmUgYSBmbG93IGlzIG1hcHBlZCB0byBhIGNvcmUuIFRoaXMgYWxs b3dzIGZvciBidWlsZGluZyBoaWdoIHBlcmZvcm1hbmNlIHJlY2VpdmUgcHJvY2Vzc2luZw0KIHRo YXQgY291bGQgYmUgbG9jayBmcmVlIGZvciB0aGUgbW9zdCBwYXJ0LiBUaGUgb25seSBkb3duc2lk ZSBvZiBFQ01QIG9uIHRoZSBuZXR3b3JrIGFuZCBSU1Mgb24gdGhlIENQVSBpcyB0aGF0IGEgc2lu Z2xlIGZsb3cgd2lsbCBub3QgdGFrZSBtdWx0aXBsZSBwYXRocyBvciBnZXQgcHJvY2Vzc2VkIG9u IG1vcmUgdGhhbiBvbmUgY29yZS4gV2luZG93cyBvbiBzZXJ2ZXIgbWFjaGluZXMgdG9kYXkgY2Fu IHNhdHVyYXRlIDI1LTM1IEdicHMgZm9yIGENCiBzaW5nbGUgVENQIGNvbm5lY3Rpb24gYmVmb3Jl IGJlaW5nIENQVSBsaW1pdGVkLiBUaGlzIGlzIGEgJm5ic3A7cmVhc29uYWJsZSB0cmFkZSBvZmYg YmVjYXVzZSBJIGRvbuKAmXQga25vdyBvZiBjYXNlcyB3aGVyZSBhIHNpbmdsZSBmbG93IGlzIGRy aXZpbmcgbW9yZSB0aGFuIHRoYXQgYW1vdW50IG9mIHRyYWZmaWMuIEFzc3VtcHRpb25zIGFib3V0 IGhvdyBmbG93cyBnZXQgY2xhc3NpZmllZCBoZWxwIG1ha2UgZm9yIG1vcmUgZWZmaWNpZW50IHBy b2Nlc3NpbmcuDQogVGhleSBhbHNvIGxlYWQgdG8gY29uc2lzdGVudCBsYXRlbmN5LiBZb3UgZG8g bm90IHdhbnQgdGhlIHRyYWZmaWMgdG8gdGFrZSBhIGJpLW1vZGFsIG9yIE4tbW9kYWwgcGF0aHMg KG9uIHRoZSBuZXR3b3JrIG9yIHRoZSBob3N0KSB0byBiZWluZyBwcm9jZXNzZWQgYmVjYXVzZSB0 aGUgZmx1Y3R1YXRpb25zIGluIGxhdGVuY3kgd2lsbCBodXJ0IHRoZSB3b3JrbG9hZC4gSSBhbSBu b3QgYXJndWluZyBmb3IgVENQIG5vdCBiZWluZyByZXNpbGllbnQgdG8NCiByZW9yZGVyaW5nIGJ1 dCBJTU8gdGhhdCBzaG91bGQgYmUgdGhlIHVuY29tbW9uIGNhc2Ugbm90IHRoZSBjb21tb24gY2Fz ZS4gV2l0aCBRVUlDIGlmIHN0cmVhbXMgd2VyZSBleHBvc2VkIG9uIHRoZSBuZXR3b3JrIHlvdSBj b3VsZCB0YWtlIGFkdmFudGFnZSBvZiBzdHJlYW0gbGV2ZWwgRUNNUCBhbmQgUlNTIHRvIHNjYWxl IGJldHRlciB0aGFuIFRDUCBidXQgd2UgaGF2ZSBjaG9zZW4gdG8ga2VlcCB0aGUgNC10dXBsZSAo b3IgdGhlIDUtdHVwbGUpDQogYXMgdGhlIGZsb3cgY2xhc3NpZmllciBvbiB0aGUgbmV0d29yayB3 aGljaCBpcyBvayBieSBtZSBzaW5jZSBpdCBsZWFkcyB0byBUQ1AgcGFyaXR5Lg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PkZyb206PC9iPiBRVUlDIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPkphbmEgSXllbmdhcjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIEZlYnJ1 YXJ5IDQsIDIwMTggODozNSBQTTxicj4NCjxiPlRvOjwvYj4gU2FseiwgUmljaCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5yc2FsekBha2FtYWku Y29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJt YWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1h aS5jb208L2E+Jmd0OzsgUm9iZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIu Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZmVuaXhAZmIuY29tPC9hPiZndDs7IFFVSUMgV0cgJmx0Ozxh IGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRp b248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Qcml2YWN5LXByb3RlY3Rpb24g Y2FuJ3QgYmUgYSB1c2VyIGNob2ljZSwgZm9yIHRoZSByZWFzb25zIG90aGVycyBoYXZlIG5vdGVk IG9uIHRoaXMgdGhyZWFkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQpUaGF0IHNhaWQsIG15IHByaW1hcnkgYXJn dW1lbnQgaXMgZm9yIGVuY3J5cHRpb24gdG8gYXZvaWQgb3NzaWZpY2F0aW9uLiBOb3QgdGhhdCBp dCBtYXR0ZXJzIG5vdywgYnV0IEknbGwgbm90ZSB0aGF0IG11Y2ggb2YgR1FVSUMncyBvcmlnaW5h bCBtb3RpdmF0aW9uIGZvciBlbmNyeXB0aW5nIGhlYWRlcnMgd2FzIHRvIGF2b2lkIG9zc2lmaWNh dGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPkknbGwgcmVpdGVyYXRlIHRoYXQgZmllbGRzIHdlIGV4cG9zZSB3aWxsIGdldCBvc3Np ZmllZCBhbmQgdGhlcmUgYXJlIGxvbmctdGVybSBlY29zeXN0ZW0gZWZmZWN0cyB0byB0aGlzLiBM ZXQgbWUgaWxsdXN0cmF0ZSB0aGlzIHdpdGggcHJlY2lzZWx5IHRoZSBwYWNrZXQgbnVtYmVyIGZp ZWxkLiBNaWRkbGVib3hlcw0KIGNvbW1vbmx5IGFzc3VtZSB0aGF0IGEgVENQIGZsb3cgY2FuIG9u bHkgaGFuZGxlIHBhY2tldHMgaW4tb3JkZXIuIFRoaXMgYXNzdW1wdGlvbiBjb21lcyBmcm9tIHRo ZSBmYWN0IHRoYXQgVENQIGltcGxlbWVudGF0aW9ucyBnZXQgcG9vciBwZXJmb3JtYW5jZSB3aGVu IHBhY2tldHMgYXJlIHJlb3JkZXJlZC4gVGhpcyB3YXMgZGVmaW5pdGVseSB0cnVlIGZvciBpbXBs ZW1lbnRhdGlvbnMgb2YgVENQLCBidXQgdGhhdCBpcyBUQ1AncyBwcm9ibGVtLA0KIG5vdCB0aGUg bmV0d29yaydzLiBIb3dldmVyLCBhbG1vc3QgYWxsIGxvYWQtYmFsYW5jZXJzIEkga25vdyBvZiBu b3cgd2lsbCBwaW4gYWxsIHBhY2tldHMgd2l0aGluIGEgVENQIGZsb3cgdG8gb25lIHBhdGgsIGxl YWRpbmcgdG8gc3ViLW9wdGltYWwgcGVyZm9ybWFuY2UgaW4gdGhlIG5ldHdvcmssIGFuZCBkZXN0 cm95aW5nIGluY2VudGl2ZXMgZm9yIHRoZSBlbmRwb2ludHMgdG8gZGVwbG95IHJlb3JkZXJpbmct cmVzaWxpZW50IFRDUCBpbXBsZW1lbnRhdGlvbnMNCiAoZXZlbiB0aG91Z2ggdGhlcmUgYXJlIHBs ZW50eSBvZiB3YXlzIG9mIGRvaW5nIHRoaXMuKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RXhwb3NpbmcgUVVJQydzIHBhY2tldCBudW1i ZXIgZmllbGQgKGFzIGFueSBmaWVsZCkgaXMgbGlrZWx5IHRvIGhhdmUgc2ltaWxhciBjb25zZXF1 ZW5jZXMgYW5kIGEgc2ltaWxhciBlY29zeXN0ZW0gYXJjLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPk9uIFN1biwgRmViIDQsIDIwMTggYXQgNzo1MSBQTSwgU2FseiwgUmljaCAm bHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj5yc2Fs ekBha2FtYWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mZ3Q7IE9wdGlvbmFsIHNlY3VyaXR5IHRlbmRzIHRvIGRl dm9sdmUgdG8gbm9uLXNlY3VyZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJtOTA2Mzc0MDY4NDcwODg5MDZtNzA5NTM3 NDE4MjExNjMyNDAzNG0yMDgwNzU5MjQxMTcyMDk2OTcxbS03OTE0ODc2MDgyNDI1Nzg1MDR4bXNv bm9ybWFsIj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im05MDYzNzQwNjg0NzA4 ODkwNm03MDk1Mzc0MTgyMTE2MzI0MDM0bTIwODA3NTkyNDExNzIwOTY5NzFtLTc5MTQ4NzYwODI0 MjU3ODUwNHhtc29ub3JtYWwiPg0KVGhhdOKAmXMgYSBncmVhdCBhcGhvcmlzbS4mbmJzcDsgQW5k IHNhZGx5IGFsbCB0b28gdHJ1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD8621FADGGEMM506MBXchina_-- From nobody Mon Feb 5 23:57:59 2018 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 C320B1250B8 for ; Mon, 5 Feb 2018 23:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 zWq1mr_5QJGp for ; Mon, 5 Feb 2018 23:57:54 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 AC864120727 for ; Mon, 5 Feb 2018 23:57:53 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id g83so575032vki.4 for ; Mon, 05 Feb 2018 23:57:53 -0800 (PST) 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=R4auhoBtNpjhTMhTt4KAkP8VDGfFSWIpGlPzzhy69wg=; b=XB4uT2wNouLmrVTcWlPipEVcQhYaS4uo5GZ7CUqTUDPKPT/I3KnPrXyt40p6eP+adx +aVAZRHa1cWV47jAjrqFX2A/LI5VmUuxjuKmBe7Y5+DS39ldPRCPK9TGPFEkiqxfhm/v AjTCDO9z84+2W+IKLBVEnzXk0pegWgzdmvgsxFRq0HYL7pJpBY1r7uoofnuH/gpkBqaV uFJ2i9ztUD7uKKgRjkMQLtttTKzhlh1RzkIKuRtZzMwPHE8k6SAU4LjX9M+9KqnzXgmB GUwc9hjm4+XmNpyHMFHlTiSZpud/Xdv2TGyAl8ql/hryBWXMgBskz44kydRULAmum9b4 h8SQ== 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=R4auhoBtNpjhTMhTt4KAkP8VDGfFSWIpGlPzzhy69wg=; b=F5mBYD7SC9ovGsdhXnhCzXjHJePmZp/vx7QETxYT9x1RZn00Z8gwpXUSp6Tjl3Iutv F+2Tkfcg0clKfJI3HGwEqeCsm6B9EGwxZkUIthnHifXoxbzxd6/+puOlMQm5jR7JS35r V/AIRvuVEWr+WFl80WrcWC1DpUFGlgby5EGfsC6et7LIu19K2waKUgCmeKrPcN/iHdnr 1BiKHjP7oQzM9mar5URUfqCuQwiOM8Ck8oVJHvcUZwowo5ESkTJvnUu0o/4NWrEe6Nl0 lT9YRDd0CVjsjLTRl5IqbQ6t/lUVkYmRGClYTIqK2ORqMKBv3Wgxy9wB5oRAMzMy8+h1 q9Jw== X-Gm-Message-State: APf1xPD4eddSDjeXsguj2iAval/n0RmYaaqASEDDapigZ7+MfW0V2ZHz D05Wuz41p2yn+FWBFGypjUNG42o4IhqnKf5h/lY= X-Google-Smtp-Source: AH8x227Wm1dGs6jpmopFX0+8/fi8WL9h2aZSlRRgZKAfNy5Z97ojErcbWNsUzCd8Uidb9dpA+3n0fjBqi2VnxLWQjLs= X-Received: by 10.31.179.139 with SMTP id c133mr1439102vkf.194.1517903872484; Mon, 05 Feb 2018 23:57:52 -0800 (PST) MIME-Version: 1.0 References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <6E58094ECC8D8344914996DAD28F1CCD8621FA@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8621FA@DGGEMM506-MBX.china.huawei.com> From: Marten Seemann Date: Tue, 06 Feb 2018 07:57:41 +0000 Message-ID: Subject: Re: Packet number encryption To: "Roni Even (A)" Cc: Praveen Balasubramanian , Jana Iyengar , "Lubashev, Igor" , Roberto Peon , QUIC WG , "Salz, Rich" Content-Type: multipart/alternative; boundary="001a114354c61f6c100564868905" 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, 06 Feb 2018 07:57:58 -0000 --001a114354c61f6c100564868905 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable That's only true if you assume that the middlebox reads the version number from the Long Header packets, and then only takes action if it understands that version. Additionally, in case of a migrated connection, the middlebox has no way to learn about the QUIC version at all, and would have to refrain from taking any action at all. Furthermore, if we rotate connection IDs more frequently, as Martin suggested, the middlebox would also become ignorant of the QUIC version for that new connection ID, and would have to stop reading the packet number for that flow. These are a lot of ifs, and I'm not sure if it's a wise decision to put all our trust in the manufacturers of middleboxes, that all of them will adhere to all the assumptions outlined above. Note that there's no other way than deploying a new QUIC version to distinguish middleboxes implementing this correctly from middleboxes that don't exactly play by these rules. Since in the beginning QUIC v1 will be the only deployed QUIC version, it might be very tempting for middleboxes to not implement these rules properly. On Tue, Feb 6, 2018 at 3:34 PM Roni Even (A) wrote: > Hi, > > This is what version negotiation is for, you can change it in future > version based on version number. > > Roni > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Marten Seemann > *Sent:* Tuesday, February 06, 2018 9:31 AM > *To:* Praveen Balasubramanian > *Cc:* Jana Iyengar; Lubashev, Igor; Roberto Peon; QUIC WG; Salz, Rich > > > *Subject:* Re: Packet number encryption > > > > Option 2 is the only option that allows us to correct our decision in the > future. If we were to discover that it doesn't work out as we planned (wr= t > encryption performance, network manageability or literally any other > unforeseen problem), going back to option 1 (or coming up with another > clever solution) in a future QUIC version would still be a viable option. > > Option 1 on the other hand, once deployed, immediately puts us at risk of > ossification by middleboxes, which will prohibit us from ever switching t= o > option 2 for a future QUIC version. > > > > On Tue, Feb 6, 2018 at 3:10 PM Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > Oops sorry I think I misread that 1 requires random jumps only around > migration and not always, which means its decidedly inferior to 2 w.r.t. > ossification. Can we include a 1.1 which incorporates random jumps even i= n > steady state? Or have we ruled that option out? > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen > Balasubramanian > *Sent:* Monday, February 5, 2018 7:13 PM > *To:* Jana Iyengar > > > *Cc:* Salz, Rich ; Lubashev, Igor = ; > Roberto Peon ; QUIC WG > > *Subject:* RE: Packet number encryption > > > > My opinion is for 1 over 2 but I can live with either. The main concern i= s > cost of another encryption / decryption step, so the benefit of 2 over 1 > should be demonstrably better on one of ossification, privacy, or > manageability. > > > > *From:* Jana Iyengar [mailto:jri@google.com ] > *Sent:* Monday, February 5, 2018 4:31 PM > *To:* Praveen Balasubramanian > *Cc:* Salz, Rich ; Lubashev, Igor = ; > Roberto Peon ; QUIC WG > *Subject:* Re: Packet number encryption > > > > I don't think we're converging here, so I'd like to try and encourage us > to move towards it. I have my opinion, but I care more about forward > progress at this point. > > > > There are three designs so far: > > 1. Packet numbers as is, with random gaps around migration. > > 2. Packet numbers encrypted, as per Martin's PR. > > 3. Packet numbers encrypted, plus a small modulo sequence number somewher= e. > > > > The concrete ones here are (1) and (2). I'm listing (3) but am not > inclined to consider it seriously, since it's not concrete enough, (and I > don't want more bits to be spent in the QUIC packet header if that's wher= e > this info goes.) > > There are opinions about ossification, privacy, and manageability. I'm no= t > hearing bloody murder, so for what it's worth, I'd like to stipulate firs= t > that we can all live with the final design, whichever one it is. If anyo= ne > disagrees, please say so -- I think it'd be useful to hear if there are > folks who think a particular design is fundamentally problematic. > > > > My opinion is still for (2) over (1), but I can live with either. > > > > On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: > > Praveen, > > > > That was precisely my point about the ecosystem evolving. Now that we hav= e > the ability to classify flows, various things have been built around bein= g > able to tell TCP flows. This obviously has benefits as you point out, but > the downside is that that I can't get good network utilization with a > single flow. I understand the scaling point, but speaking of common > cases, any server in the wild is usually serving a large number of > connections at moderate speeds, not a single one at 25-35 Gbps... which > makes that sort of scaling less exciting than in a microbenchmark. > > > > FWIW, the other downside of ECMP is that multipath transport doesn't work > -- you need to hash on something else besides the 4-tuple. (We had to wor= k > around this in Google's deployment of connection migration.) > > > > I'll disagree with your point about reordering being the uncommon case. > While that's true today, this is again an expectation that the network > works hard to maintain, though the ecosystem and what we expect as "usual= " > would be quite different had we not built TCP's requirements into the > network. There's nothing wrong with having n-modal latencies... we can > engineer around that. Any sensible load distribution scheme within the > network will give you increased variance but it should limit the worst-ca= se > latency. You'd perhaps agree that that's a net win. > > > > This was an example of how exposing packet number or not can have long > term ecosystem effects. My point was about the fact that exposing can cau= se > ossification. > > > > - jana > > > > On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > >> This was definitely true for implementations of TCP, but that is TCP's > problem, not the network's > > Flow classification happens through the network and also on the end host > with RSS where a flow is mapped to a core. This allows for building high > performance receive processing that could be lock free for the most part. > The only downside of ECMP on the network and RSS on the CPU is that a > single flow will not take multiple paths or get processed on more than on= e > core. Windows on server machines today can saturate 25-35 Gbps for a sing= le > TCP connection before being CPU limited. This is a reasonable trade off > because I don=E2=80=99t know of cases where a single flow is driving more= than that > amount of traffic. Assumptions about how flows get classified help make f= or > more efficient processing. They also lead to consistent latency. You do n= ot > want the traffic to take a bi-modal or N-modal paths (on the network or t= he > host) to being processed because the fluctuations in latency will hurt th= e > workload. I am not arguing for TCP not being resilient to reordering but > IMO that should be the uncommon case not the common case. With QUIC if > streams were exposed on the network you could take advantage of stream > level ECMP and RSS to scale better than TCP but we have chosen to keep th= e > 4-tuple (or the 5-tuple) as the flow classifier on the network which is o= k > by me since it leads to TCP parity. > > > > Thanks > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar > *Sent:* Sunday, February 4, 2018 8:35 PM > *To:* Salz, Rich > *Cc:* Lubashev, Igor ; Roberto Peon ; > QUIC WG > *Subject:* Re: Packet number encryption > > > > Privacy-protection can't be a user choice, for the reasons others have > noted on this thread. > > > That said, my primary argument is for encryption to avoid ossification. > Not that it matters now, but I'll note that much of GQUIC's original > motivation for encrypting headers was to avoid ossification. > > > > I'll reiterate that fields we expose will get ossified and there are > long-term ecosystem effects to this. Let me illustrate this with precisel= y > the packet number field. Middleboxes commonly assume that a TCP flow can > only handle packets in-order. This assumption comes from the fact that TC= P > implementations get poor performance when packets are reordered. This was > definitely true for implementations of TCP, but that is TCP's problem, no= t > the network's. However, almost all load-balancers I know of now will pin > all packets within a TCP flow to one path, leading to sub-optimal > performance in the network, and destroying incentives for the endpoints t= o > deploy reordering-resilient TCP implementations (even though there are > plenty of ways of doing this.) > > > > Exposing QUIC's packet number field (as any field) is likely to have > similar consequences and a similar ecosystem arc. > > > > > > On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: > > > Optional security tends to devolve to non-secure. > > > > That=E2=80=99s a great aphorism. And sadly all too true. > > > > > > > > --001a114354c61f6c100564868905 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's only true if you assume that the middlebox read= s the version number from the Long Header packets, and then only takes acti= on if it understands that version. Additionally, in case of a migrated conn= ection, the middlebox has no way to learn about the QUIC version at all, an= d would have to refrain from taking any action at all. Furthermore, if we r= otate connection IDs more frequently, as Martin suggested, the middlebox wo= uld also become ignorant of the QUIC version for that new connection ID, an= d would have to stop reading the packet number for that flow.

These are a lot of ifs, and I'm not sure if it's a wise decis= ion to put all our trust in the manufacturers of middleboxes, that all of t= hem will adhere to all the assumptions outlined above.
Note t= hat there's no other way than deploying a new QUIC version to distingui= sh middleboxes implementing this correctly from middleboxes that don't = exactly play by these rules. Since in the beginning QUIC v1 will be the onl= y deployed QUIC version, it might be very tempting for middleboxes to not i= mplement these rules properly.

On Tue, Feb 6, 2018 at 3:34 PM Roni Even (A) <roni.even@huawei.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

Hi,<= /p>

This is what version nego= tiation is for, you can change it in future version based on version number= .

Roni=

=C2=A0

From: QUIC [ma= ilto:quic-bounce= s@ietf.org] On Behalf Of Marten Seemann
Sent: Tuesday, February 06, 2018 9:31 AM
To: Praveen Balasubramanian
Cc: Jana Iyengar; Lubashev, Igor; Roberto Peon; QUIC WG; Salz, Rich<= /span>


Subject: Re: Packet number encryption

=

=C2=A0

Option 2 is the only option that allows us to correc= t our decision in the future. If we were to discover that it doesn't wo= rk out as we planned (wrt encryption performance, network manageability or = literally any other unforeseen problem), going back to option 1 (or coming up with another clever solution) in a fu= ture QUIC version would still be a viable option.

Option 1 on the other hand, once deployed, immediate= ly puts us at risk of ossification by middleboxes, which will prohibit us f= rom ever switching to option 2 for a future QUIC version.

=C2=A0

On Tue, Feb 6, 2018 at 3:10 PM Praveen Balasubramani= an <pravb@micro= soft.com> wrote:

Oops sorry I think I misread that 1 requires random = jumps only around migration and not always, which means its decidedly infer= ior to 2 w.r.t. ossification. Can we include a 1.1 which incorporates random jumps even in steady state? Or have we ruled tha= t option out?

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Monday, February 5, 2018 7:13 PM
To: Jana Iyengar <jri@google.com>


Cc: Salz, Rich <rsalz@akamai.com>; Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon &= lt;fenix@fb.com>; QUIC WG <quic@ietf.o= rg>

Subject: RE: Packet number encryption<= u>

=C2=A0

My opinion is for 1 over 2 but I can live with eithe= r. The main concern is cost of another encryption / decryption step, so the= benefit of 2 over 1 should be demonstrably better on one of ossification, privacy, or manageability.

=C2=A0

From: Jana Iyengar [mailto:jri@google.com]
Sent: Monday, February 5, 2018 4:31 PM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Salz, Rich <rsalz@akamai.com>; Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon &= lt;fenix@fb.com>; QUIC WG <quic@ietf.o= rg>
Subject: Re: Packet number encryption

=C2=A0

I don't think we're converging here, so I= 9;d like to try and encourage us to move towards it. I have my opinion, but= I care more about forward progress at this point.

=C2=A0

There are three designs so far:

1. Packet numbers as is, with random gaps around mig= ration.

2. Packet numbers encrypted, as per Martin's PR.=

3. Packet numbers encrypted, plus a small modulo seq= uence number somewhere.

=C2=A0

The concrete ones here are (1) and (2).=C2=A0=C2=A0<= span style=3D"font-family:"Arial","sans-serif";color:#2= 22222;background:white">I'm listing (3) but am not inclined to consider= it seriously, since it's not concrete enough, (and I don't want more bits to be = spent in the QUIC packet header if that's where this info goes.)=

There are opinions about ossification, privacy, and manageability. I'm = not hearing bloody murder, so for what it's worth, I'd like to stip= ulate first that we can all live with the final design, whichever one it is= .=C2=A0 If anyone disagrees, please say so -- I think it'd be useful to hear if there are folks who think a particular desig= n is fundamentally problematic.

=C2=A0

My opinion is still for (2)= over (1), but I can live with either.

=C2=A0

On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar <jri@google.com> wro= te:

Praveen,

=C2=A0

That was precisely my point about the ecosys= tem evolving. Now that we have the ability to classify flows, various thing= s have been built around being able to tell TCP flows. This obviously has be= nefits as you point out, but the downside is that that I can't get good= network utilization with a single flow. I understand the scaling point, bu= t speaking of common cases, any server in the wild is usually serving a large number = of connections at moderate speeds, not a single one at 25-35 Gbps... which = makes that sort of scaling less exciting than in a microbenchmark.

=C2=A0

FWIW, the other downside of= ECMP is that multipath transport doesn't work -- you need to hash on s= omething else besides the 4-tuple. (We had to work around this in Google's depl= oyment of connection migration.)

=C2=A0

I'll disagree with your point about reordering b= eing the uncommon case. While that's true today, this is again an expec= tation that the network works hard to maintain, though the ecosystem and what we expect as "usual" would be quite different= had we not built TCP's requirements into the network. There's noth= ing wrong with having n-modal latencies... we can engineer around that. Any= sensible load distribution scheme within the network will give you increased variance but it should limit the worst-case latenc= y. You'd perhaps agree that that's a net win.

=C2=A0

This was an example of how exposing packet number or= not can have long term ecosystem effects. My point was about the fact that= exposing can cause ossification.

=C2=A0

- jana

=C2=A0

On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubraman= ian <pravb@micr= osoft.com> wrote:

>> This was definitely true for implementation= s of TCP, but that is TCP's problem, not the network's

Flow classification happens through the network and = also on the end host with RSS where a flow is mapped to a core. This allows= for building high performance receive processing that could be lock free for the most part. The only downside of ECMP on th= e network and RSS on the CPU is that a single flow will not take multiple p= aths or get processed on more than one core. Windows on server machines tod= ay can saturate 25-35 Gbps for a single TCP connection before being CPU limited. This is a =C2=A0reasonable= trade off because I don=E2=80=99t know of cases where a single flow is dri= ving more than that amount of traffic. Assumptions about how flows get clas= sified help make for more efficient processing. They also lead to consistent latency. You do not want the traffic to take = a bi-modal or N-modal paths (on the network or the host) to being processed= because the fluctuations in latency will hurt the workload. I am not argui= ng for TCP not being resilient to reordering but IMO that should be the uncommon case not the common case. W= ith QUIC if streams were exposed on the network you could take advantage of= stream level ECMP and RSS to scale better than TCP but we have chosen to k= eep the 4-tuple (or the 5-tuple) as the flow classifier on the network which is ok by me since it leads to = TCP parity.

=C2=A0

Thanks

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Sunday, February 4, 2018 8:35 PM
To: Salz, Rich <rsalz@akamai.com>
Cc: Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon <fenix@fb.com>; QUIC WG <quic@ietf.org>
Subject: Re: Packet number encryption

=C2=A0

Privacy-protection can't be a user choice, for t= he reasons others have noted on this thread.=C2=A0


That said, my primary argument is for encryption to avoid ossification. Not= that it matters now, but I'll note that much of GQUIC's original m= otivation for encrypting headers was to avoid ossification.

=C2=A0

I'll reiterate that fields we expose will get os= sified and there are long-term ecosystem effects to this. Let me illustrate= this with precisely the packet number field. Middleboxes commonly assume that a TCP flow can only handle packets in-order. This ass= umption comes from the fact that TCP implementations get poor performance w= hen packets are reordered. This was definitely true for implementations of = TCP, but that is TCP's problem, not the network's. However, almost all load-balancers I know of now wi= ll pin all packets within a TCP flow to one path, leading to sub-optimal pe= rformance in the network, and destroying incentives for the endpoints to de= ploy reordering-resilient TCP implementations (even though there are plenty of ways of doing this.)

=C2=A0

Exposing QUIC's packet number field (as any fiel= d) is likely to have similar consequences and a similar ecosystem arc.

=C2=A0

=C2=A0

On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <rsalz@akamai.com> w= rote:

> Optional security tends to devolve to n= on-secure.

=C2=A0

That=E2=80=99s a great aphorism.=C2=A0 And sadly all too true.

=C2=A0

=C2=A0

=C2=A0

--001a114354c61f6c100564868905-- From nobody Tue Feb 6 02:13:37 2018 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 3E30312D893 for ; Tue, 6 Feb 2018 02:13:35 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 zqMU37OY4J_G for ; Tue, 6 Feb 2018 02:13:31 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63461241F5 for ; Tue, 6 Feb 2018 02:13:30 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D84E734047F; Tue, 6 Feb 2018 11:13:28 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.13782); Tue, 6 Feb 2018 11:13:25 +0100 (CET) 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; Tue, 6 Feb 2018 11:13:25 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44482860; Tue, 06 Feb 2018 11:13:25 +0100 From: "Brian Trammell (IETF)" Message-Id: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_70AEC089-49FE-4187-845A-975A097482CB"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Tue, 6 Feb 2018 11:13:24 +0100 In-Reply-To: Cc: Praveen Balasubramanian , "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , QUIC WG To: Jana Iyengar References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> 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, 06 Feb 2018 10:13:35 -0000 --Apple-Mail=_70AEC089-49FE-4187-845A-975A097482CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 6 Feb 2018, at 01:30, Jana Iyengar wrote: >=20 > I don't think we're converging here, so I'd like to try and encourage = us to move towards it. I have my opinion, but I care more about forward = progress at this point. >=20 > There are three designs so far: > 1. Packet numbers as is, with random gaps around migration. > 2. Packet numbers encrypted, as per Martin's PR. > 3. Packet numbers encrypted, plus a small modulo sequence number = somewhere. >=20 > The concrete ones here are (1) and (2). I'm listing (3) but am not = inclined to consider it seriously, since it's not concrete enough, (and = I don't want more bits to be spent in the QUIC packet header if that's = where this info goes.) Unsurprisingly, I'm still for (3). :) If a concrete proposal would incline you to consider it seriously, I'm = happy to write one or two points in this space up, probably for the list = at first. (Indeed, I'll probably go ahead and do this anyway today). > There are opinions about ossification, privacy, and manageability. I'm = not hearing bloody murder, so for what it's worth, I'd like to stipulate = first that we can all live with the final design, whichever one it is. = If anyone disagrees, please say so -- I think it'd be useful to hear if = there are folks who think a particular design is fundamentally = problematic. >=20 > My opinion is still for (2) over (1), but I can live with either. FWIW, I prefer (2) over (1) as well, modulo a little discomfort about = the crypto: the proposed encryption scheme uses a secret derived from = the end-to-end secret to ECB-encrypt a plaintext which is completely = known to an on-path observer in a place to see all packets in the common = case that packets are neither lost nor reordered on the path -- namely = the sequence 0x00 - 0x3f, 0x4000 - 0x7fff and so on. I Am Not A = Cryptographer, but that property of this algorithm used in this way = screams "Call A Cryptographer Before Deploying" to me.) Cheers, Brian > On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: > Praveen, >=20 > That was precisely my point about the ecosystem evolving. Now that we = have the ability to classify flows, various things have been built = around being able to tell TCP flows. This obviously has benefits as you = point out, but the downside is that that I can't get good network = utilization with a single flow. I understand the scaling point, but = speaking of common cases, any server in the wild is usually serving a = large number of connections at moderate speeds, not a single one at = 25-35 Gbps... which makes that sort of scaling less exciting than in a = microbenchmark. >=20 > FWIW, the other downside of ECMP is that multipath transport doesn't = work -- you need to hash on something else besides the 4-tuple. (We had = to work around this in Google's deployment of connection migration.) >=20 > I'll disagree with your point about reordering being the uncommon = case. While that's true today, this is again an expectation that the = network works hard to maintain, though the ecosystem and what we expect = as "usual" would be quite different had we not built TCP's requirements = into the network. There's nothing wrong with having n-modal latencies... = we can engineer around that. Any sensible load distribution scheme = within the network will give you increased variance but it should limit = the worst-case latency. You'd perhaps agree that that's a net win. >=20 > This was an example of how exposing packet number or not can have long = term ecosystem effects. My point was about the fact that exposing can = cause ossification. >=20 > - jana >=20 > On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian = wrote: > >> This was definitely true for implementations of TCP, but that is = TCP's problem, not the network's >=20 > Flow classification happens through the network and also on the end = host with RSS where a flow is mapped to a core. This allows for building = high performance receive processing that could be lock free for the most = part. The only downside of ECMP on the network and RSS on the CPU is = that a single flow will not take multiple paths or get processed on more = than one core. Windows on server machines today can saturate 25-35 Gbps = for a single TCP connection before being CPU limited. This is a = reasonable trade off because I don=E2=80=99t know of cases where a = single flow is driving more than that amount of traffic. Assumptions = about how flows get classified help make for more efficient processing. = They also lead to consistent latency. You do not want the traffic to = take a bi-modal or N-modal paths (on the network or the host) to being = processed because the fluctuations in latency will hurt the workload. I = am not arguing for TCP not being resilient to reordering but IMO that = should be the uncommon case not the common case. With QUIC if streams = were exposed on the network you could take advantage of stream level = ECMP and RSS to scale better than TCP but we have chosen to keep the = 4-tuple (or the 5-tuple) as the flow classifier on the network which is = ok by me since it leads to TCP parity. >=20 >=20 >=20 > Thanks >=20 >=20 >=20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar > Sent: Sunday, February 4, 2018 8:35 PM > To: Salz, Rich > Cc: Lubashev, Igor ; Roberto Peon ; = QUIC WG > Subject: Re: Packet number encryption >=20 >=20 >=20 > Privacy-protection can't be a user choice, for the reasons others have = noted on this thread. >=20 >=20 > That said, my primary argument is for encryption to avoid = ossification. Not that it matters now, but I'll note that much of = GQUIC's original motivation for encrypting headers was to avoid = ossification. >=20 >=20 >=20 > I'll reiterate that fields we expose will get ossified and there are = long-term ecosystem effects to this. Let me illustrate this with = precisely the packet number field. Middleboxes commonly assume that a = TCP flow can only handle packets in-order. This assumption comes from = the fact that TCP implementations get poor performance when packets are = reordered. This was definitely true for implementations of TCP, but that = is TCP's problem, not the network's. However, almost all load-balancers = I know of now will pin all packets within a TCP flow to one path, = leading to sub-optimal performance in the network, and destroying = incentives for the endpoints to deploy reordering-resilient TCP = implementations (even though there are plenty of ways of doing this.) >=20 >=20 >=20 > Exposing QUIC's packet number field (as any field) is likely to have = similar consequences and a similar ecosystem arc. >=20 >=20 >=20 >=20 >=20 > On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: >=20 > > Optional security tends to devolve to non-secure. >=20 >=20 >=20 > That=E2=80=99s a great aphorism. And sadly all too true. >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_70AEC089-49FE-4187-845A-975A097482CB 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp5f8QACgkQihK3vwvq RqNvtg//YQMHglFOdzgqLafjzBYcdMo2XRF+v6LfxpEcHvkavilHBAE+ANjwC6V2 97dwEOiV+X04zv3MRlJ4wwBCn6ewPL7zrRUysTzDVzC6+FBdhBs5dKR09vq8THfA vClXLdIu6piz4r7O/gQ6f+Hoqi5jwn/k0hfXJTv8MFOaQW0rdCpL3hYRkfuQhZeI 9Pr/ojlLscoT3n0ZiJH8uGCrEcSTnN3ujCqHXGUu/GwX7CLkLvHoMPDkanB5yqDf bIlQ5Pj+ZUEUmCZLiAmTv+zwwLuvEFDMkh7LkZ2cdztIAD4M3J9Bs7WXE9AqloiT 8iGah7kPhYZ5gOK9Prced6HQWQllbcGN36HqDloMfM5DSqIwgAYhRgsdrmzClMtZ FOkUcHSnCo7U8CL6Z48v/PDJ95kLBW2oY1CIlSjxF8Og3NvvcoK/dB9eNezwyUpp 25Yt5gvAlQK4Jd42HGgQtdEPeRnVYa5YWaUXLkr1bxnJYNg+XnL/PHNLQvHh9dnz 1IA7Ie511eAIaeDMZo6QzCSQ6qMbpW7dTOKj2UWLjdYWkHYfdFUcK3FCeMk1+yrR oLGLxJl69/kDoGBxQzN6AP4IbvIphhp/DBIwwX6dEXffi5s4bC6B6rC+hZQspK9z hAIl+/N0ioJGetTR5A9741AFbZKeOdZY5Pf/2R6iWK1JNfG4eCE= =nsp8 -----END PGP SIGNATURE----- --Apple-Mail=_70AEC089-49FE-4187-845A-975A097482CB-- From nobody Tue Feb 6 04:49:11 2018 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 5DB5F12DFDB for ; Tue, 6 Feb 2018 04:49:09 -0800 (PST) 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, 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 caj8_nF5ZLud for ; Tue, 6 Feb 2018 04:49:07 -0800 (PST) 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 EFF0112DA6A for ; Tue, 6 Feb 2018 04:49:06 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id x25so1050392pge.3 for ; Tue, 06 Feb 2018 04:49:06 -0800 (PST) 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=FIs8L/9TBTzMh4hjwFSgZ7NP5QJ7eDqgW6oULQN4TPY=; b=Req+easf/5srm2iaX6OBBeFAOyjlQTo67zd4mcMUtkwXTVVAqg0ZxH1ZLsy0scmzPG IH35+UdPnYVDCQbPqzIvfcNynLG7I8kZx0P/zSIL9MCNKn9RfEnxIeAyGdKAWNU1Av06 T5f7PDNn+0b2caVQcOTyXYNqU+xyTp+uiMt190nXVXPDCop00Dlqhn8NEWB/fI0azFvE fQ2vz07mt1JHwbBt3lTvAE1spB9r90BbtSkggNKNxcZCTHeDT73qn5hb+zU84kooRmgu RCwJB2s98kk9H9y48Wm1bvR1TXu/IjdVq0/TtEaWDiyD/XCkll2XX81uQvIjVuK7mkE9 bQLQ== 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=FIs8L/9TBTzMh4hjwFSgZ7NP5QJ7eDqgW6oULQN4TPY=; b=EJIxds5n6tlNM7Yty4P7dCALdqgAW/qs7xOYPtMU6XZHU0ReRURqc0pinfjd7bo+ns qLcaebR7edfsWD820r7Rq3povyD+5pnVCrJ5deQm18mgKKNHd5X+omFiigeq4XgVi8dP PpqlQ8CAEV7UTU94DcxYM/M8Zx5x7lRVu2O4rGHTxZFJXuR9KewwyKRZNiJBLGp0AXSB VGfLxQEcRZBaJaWEe/GWYpjYYySaeIoXBOZ0QK8rnTPPECBr/Swr9fk5piZqY3pomKnH D80fyOolaJVOg5VA2P+dw78lC+ZAuCgc6IBmO1tPC8y2QUxZC/sAfLrYv5FUTwOx5XPy blXg== X-Gm-Message-State: APf1xPDgJqtW/hpErkIBEOnmM9Zkw9rmzzJYRRCAOc0Nu5Df/mGiYhrq fKo5kuxdc3DahjYuSiwnIDI8MxqO/yn2cFH/MZk= X-Google-Smtp-Source: AH8x227amrXqZunCmGeASnhyv4/tXb70mNyIrdFwlsKj4fPs8HCTWolZTJX3fqcPyTKQOuzgRECRJ7tlmA1+RMJYwMg= X-Received: by 10.99.124.66 with SMTP id l2mr1878739pgn.290.1517921346050; Tue, 06 Feb 2018 04:49:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Tue, 6 Feb 2018 04:49:05 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> From: Kazuho Oku Date: Tue, 6 Feb 2018 21:49:05 +0900 Message-ID: Subject: Re: Packet number encryption To: Jana Iyengar Cc: Praveen Balasubramanian , "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , 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: Tue, 06 Feb 2018 12:49:09 -0000 2018-02-06 9:30 GMT+09:00 Jana Iyengar : > I don't think we're converging here, so I'd like to try and encourage us = to > move towards it. I have my opinion, but I care more about forward progres= s > at this point. > > There are three designs so far: > 1. Packet numbers as is, with random gaps around migration. > 2. Packet numbers encrypted, as per Martin's PR. > 3. Packet numbers encrypted, plus a small modulo sequence number somewher= e. I wonder if we can provide opportunity to observe upstream loss / reorder rate by just reserving one bit per packet. The strawman is as follows. Sender exposes one bit per packet that can be observed by on-path devices. The bit is flipped for every 256 packets that the sender sends. Observer records the bit of each packet as they pass by. If there is no loss or reorder, the pattern an on-path device would observe is repetition of 256 zeros and 256 ones. In other words, the wavelength is 512 samples. When there is a loss, the wavelength becomes shorter. The wavelength becomes 512 * (1-loss_rate) samples. For example, if the wavelength being observed is 384, loss rate is 25%. If there is reorder, the edge (i.e. shift from zereos to ones, or vice versa) becomes unclear. Duration of the transition will reflect the extent of reordering. Theoretically, it might be possible to explain the approach as a way to let the sender emit a wave, then FFT the wave in on-path devices to observe loss / reorder. Or it could be explained as just sending one bit of the sequence number, somewhere in the middle (i.e., not LSB nor MSB). The pros of the approach is obvious; we will only spend 1 bit per packet. Privacy impact is minimum. Implementing it is easy. Another benefit is that it would be difficult (if not impossible) for on-path devices to use the bit for purposes other than observation (i.e., change the ordering of the packets "for performance"). OTOH I am not sure how hard it would be to build tools for observing upstream behavior using the proposed approach. Or I could well be missing some requirements that operators have, as I am an endpoint developer. > > The concrete ones here are (1) and (2). I'm listing (3) but am not incli= ned > to consider it seriously, since it's not concrete enough, (and I don't wa= nt > more bits to be spent in the QUIC packet header if that's where this info > goes.) > > There are opinions about ossification, privacy, and manageability. I'm no= t > hearing bloody murder, so for what it's worth, I'd like to stipulate firs= t > that we can all live with the final design, whichever one it is. If anyo= ne > disagrees, please say so -- I think it'd be useful to hear if there are > folks who think a particular design is fundamentally problematic. > > My opinion is still for (2) over (1), but I can live with either. > > On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: >> >> Praveen, >> >> That was precisely my point about the ecosystem evolving. Now that we ha= ve >> the ability to classify flows, various things have been built around bei= ng >> able to tell TCP flows. This obviously has benefits as you point out, bu= t >> the downside is that that I can't get good network utilization with a si= ngle >> flow. I understand the scaling point, but speaking of common cases, any >> server in the wild is usually serving a large number of connections at >> moderate speeds, not a single one at 25-35 Gbps... which makes that sort= of >> scaling less exciting than in a microbenchmark. >> >> FWIW, the other downside of ECMP is that multipath transport doesn't wor= k >> -- you need to hash on something else besides the 4-tuple. (We had to wo= rk >> around this in Google's deployment of connection migration.) >> >> I'll disagree with your point about reordering being the uncommon case. >> While that's true today, this is again an expectation that the network w= orks >> hard to maintain, though the ecosystem and what we expect as "usual" wou= ld >> be quite different had we not built TCP's requirements into the network. >> There's nothing wrong with having n-modal latencies... we can engineer >> around that. Any sensible load distribution scheme within the network wi= ll >> give you increased variance but it should limit the worst-case latency. >> You'd perhaps agree that that's a net win. >> >> This was an example of how exposing packet number or not can have long >> term ecosystem effects. My point was about the fact that exposing can ca= use >> ossification. >> >> - jana >> >> On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian >> wrote: >>> >>> >> This was definitely true for implementations of TCP, but that is TCP= 's >>> >> problem, not the network's >>> >>> Flow classification happens through the network and also on the end hos= t >>> with RSS where a flow is mapped to a core. This allows for building hig= h >>> performance receive processing that could be lock free for the most par= t. >>> The only downside of ECMP on the network and RSS on the CPU is that a s= ingle >>> flow will not take multiple paths or get processed on more than one cor= e. >>> Windows on server machines today can saturate 25-35 Gbps for a single T= CP >>> connection before being CPU limited. This is a reasonable trade off be= cause >>> I don=E2=80=99t know of cases where a single flow is driving more than = that amount >>> of traffic. Assumptions about how flows get classified help make for mo= re >>> efficient processing. They also lead to consistent latency. You do not = want >>> the traffic to take a bi-modal or N-modal paths (on the network or the = host) >>> to being processed because the fluctuations in latency will hurt the >>> workload. I am not arguing for TCP not being resilient to reordering bu= t IMO >>> that should be the uncommon case not the common case. With QUIC if stre= ams >>> were exposed on the network you could take advantage of stream level EC= MP >>> and RSS to scale better than TCP but we have chosen to keep the 4-tuple= (or >>> the 5-tuple) as the flow classifier on the network which is ok by me si= nce >>> it leads to TCP parity. >>> >>> >>> >>> Thanks >>> >>> >>> >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar >>> Sent: Sunday, February 4, 2018 8:35 PM >>> To: Salz, Rich >>> Cc: Lubashev, Igor ; Roberto Peon ; >>> QUIC WG >>> Subject: Re: Packet number encryption >>> >>> >>> >>> Privacy-protection can't be a user choice, for the reasons others have >>> noted on this thread. >>> >>> >>> That said, my primary argument is for encryption to avoid ossification. >>> Not that it matters now, but I'll note that much of GQUIC's original >>> motivation for encrypting headers was to avoid ossification. >>> >>> >>> >>> I'll reiterate that fields we expose will get ossified and there are >>> long-term ecosystem effects to this. Let me illustrate this with precis= ely >>> the packet number field. Middleboxes commonly assume that a TCP flow ca= n >>> only handle packets in-order. This assumption comes from the fact that = TCP >>> implementations get poor performance when packets are reordered. This w= as >>> definitely true for implementations of TCP, but that is TCP's problem, = not >>> the network's. However, almost all load-balancers I know of now will pi= n all >>> packets within a TCP flow to one path, leading to sub-optimal performan= ce in >>> the network, and destroying incentives for the endpoints to deploy >>> reordering-resilient TCP implementations (even though there are plenty = of >>> ways of doing this.) >>> >>> >>> >>> Exposing QUIC's packet number field (as any field) is likely to have >>> similar consequences and a similar ecosystem arc. >>> >>> >>> >>> >>> >>> On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: >>> >>> > Optional security tends to devolve to non-secure. >>> >>> >>> >>> That=E2=80=99s a great aphorism. And sadly all too true. >>> >>> >> >> > --=20 Kazuho Oku From nobody Tue Feb 6 05:35:21 2018 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 D6B5B12E043 for ; Tue, 6 Feb 2018 05:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, UNPARSEABLE_RELAY=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 h96TgyG80s4q for ; Tue, 6 Feb 2018 05:35:14 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 314BF12E041 for ; Tue, 6 Feb 2018 05:35:14 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id h129so2452918ita.2 for ; Tue, 06 Feb 2018 05:35:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=lWHv6VkWpbGqt46tX9om1sWxqxe4C+jpxiuhddqdeqU=; b=Z6d+QAMjcHvA1WydQnFs08oTG7ZEa7hIhHFl9hBNoZETskTKxDJ+9x1jo35AxEJnEB 0AXPV/QAtVoPbsbg0L9kN7bfSU0yuqm+d955HTir6MeQQXHb7hk+9xA7X0mJnUKlxMdn 5HaMw9O+7Qv7SIng+Whk9Kl30dAe2HbSMyoly41Fz061QL8uIT9B+m6QC/MnqZjQOk/A bz74fFMz4AJ1H/ThrfcUDw2ScnpmVO2+mtk7ScgspGpUR5ZLvrU0y0oaRlnYw7XN9Ljz i+0BFo4KCn2gNZIsPiWmerv5dabj/xdxakBpbakWTU3SJk2BBXUsfjczeBUyR/eVw+uf EDBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=lWHv6VkWpbGqt46tX9om1sWxqxe4C+jpxiuhddqdeqU=; b=N9/pBXwSZtDvIoCdudg3jEUxSGsYjRzSIqqk2TTPVipM/ezil6BM667s3dpyJMRHZO /g20GzXF3/CBsZ7T9dPx3ThugKGsYFtoLdekLl2eEaz2sHRTTeuU+KIxDdZ6W2D/Pm3L aCr6vp2Fw3ZTF1E+dkoqxgpu1SFyTloujKB6ASh8xZ6rDMMxa5Qo//ds2rtTKbGv8f7o 8PaLYUaf1F8UxMGDeOn3uxNLdcFe5Hp0h4fJlR4CHPHeYK8iBO2WccDsWvSLfeAb/eol aWbOeRaCEDvJFfBeUrOYfTNGBZu2m1waMCZdFbUZUPif2Cbf6pIgoCWWvu+UxFSM63vw Vlqw== X-Gm-Message-State: APf1xPBv7zyNbMmmElsgSjQCWgu2OEBCA6BQbHzHAFFddoQ+bhW7Sewf 2TgeElMaCIrb23vWyskAcOIJzpLMjDJN59Wf5ts= X-Google-Smtp-Source: AH8x227xNbpIxqPu1KrdrQbtj/D5vRVk4FrFqGNLt/p2pnZVXzMuh8FEm1HYiYNlFvECYPG73bDL7pBSPYVIW6+GWKA= X-Received: by 10.36.10.207 with SMTP id 198mr3030754itw.42.1517924113377; Tue, 06 Feb 2018 05:35:13 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Feb 2018 08:35:12 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 6 Feb 2018 08:35:12 -0500 Message-ID: Subject: Re: Packet number encryption To: "Brian Trammell (IETF)" , Jana Iyengar Cc: Praveen Balasubramanian , "Salz, Rich" , QUIC WG , Roberto Peon , "Lubashev, Igor" Content-Type: multipart/alternative; boundary="001a1144b82892eefa05648b3fb7" 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, 06 Feb 2018 13:35:21 -0000 --001a1144b82892eefa05648b3fb7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Some overhead considerations of packet encryption: Sensor and control devices: The power overhead on sensor networks is small compared to just listening on the radio and if not using radio, the latency is probably not critical compared to the speed of encryption. To be a bit sci-fi - low-latency encrypted control signals in robotics might be relevant. Think exo-skeleton hacked by enemy through targeted signal injection. Still, packet number encryption is likely fast enough in such cases. For servers: The overhead of packet encryption (single block AES-CTR) is probably around 100 cycles with AES-NI and possibly 160 cycles table based for one block for Intel arch. This is because parallel multi-block optimisations are not possible. AES-CTR of one block is about the same as AES-CTR of 4 blocks, and GCM auth tag adds perhaps 50% to that. Thus packet number encryption might be twice as fast as AES-GCM of a 64 byte message which is still a 50% overhead. High speed low latency applications might receive a packet concurrently on two cores, one with a fast path reacting specifically to packets containing only small stream messages, and one core handling everything else. The message handler could experience a delay of 50% compared to not encrypting packet numbers. It is not possible to significantly improve on this in hardware because the packet number must be decrypted before AEAD can be applied. That is, unless the encrypted packet number is used as the IV of AEAD in which case encryption gets a new bottleneck but decryption can be processed faster. My take is that I prefer to avoid packet number gaps because they are messy and I don=E2=80=99t believe they provide any significant privacy, but I als= o don=E2=80=99t like the crypto cost in low-latency scenarios. If the argument is for ossification and not privacy, I think the encryption is the only option as Marten has pointed out. For this reason it makes sense to apply crypto. Low-latency systems could create a QUIC variant that drops the packet encryption. Mikkel On 6 February 2018 at 11.13.40, Brian Trammell (IETF) (ietf@trammell.ch) wrote: > On 6 Feb 2018, at 01:30, Jana Iyengar wrote: > > I don't think we're converging here, so I'd like to try and encourage us to move towards it. I have my opinion, but I care more about forward progress at this point. > > There are three designs so far: > 1. Packet numbers as is, with random gaps around migration. > 2. Packet numbers encrypted, as per Martin's PR. > 3. Packet numbers encrypted, plus a small modulo sequence number somewhere. > > The concrete ones here are (1) and (2). I'm listing (3) but am not inclined to consider it seriously, since it's not concrete enough, (and I don't want more bits to be spent in the QUIC packet header if that's where this info goes.) Unsurprisingly, I'm still for (3). :) If a concrete proposal would incline you to consider it seriously, I'm happy to write one or two points in this space up, probably for the list at first. (Indeed, I'll probably go ahead and do this anyway today). > There are opinions about ossification, privacy, and manageability. I'm not hearing bloody murder, so for what it's worth, I'd like to stipulate first that we can all live with the final design, whichever one it is. If anyone disagrees, please say so -- I think it'd be useful to hear if there are folks who think a particular design is fundamentally problematic. > > My opinion is still for (2) over (1), but I can live with either. FWIW, I prefer (2) over (1) as well, modulo a little discomfort about the crypto: the proposed encryption scheme uses a secret derived from the end-to-end secret to ECB-encrypt a plaintext which is completely known to an on-path observer in a place to see all packets in the common case that packets are neither lost nor reordered on the path -- namely the sequence 0x00 - 0x3f, 0x4000 - 0x7fff and so on. I Am Not A Cryptographer, but that property of this algorithm used in this way screams "Call A Cryptographer Before Deploying" to me.) Cheers, Brian > On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: > Praveen, > > That was precisely my point about the ecosystem evolving. Now that we have the ability to classify flows, various things have been built around being able to tell TCP flows. This obviously has benefits as you point out, but the downside is that that I can't get good network utilization with a single flow. I understand the scaling point, but speaking of common cases, any server in the wild is usually serving a large number of connections at moderate speeds, not a single one at 25-35 Gbps... which makes that sort of scaling less exciting than in a microbenchmark. > > FWIW, the other downside of ECMP is that multipath transport doesn't work -- you need to hash on something else besides the 4-tuple. (We had to work around this in Google's deployment of connection migration.) > > I'll disagree with your point about reordering being the uncommon case. While that's true today, this is again an expectation that the network works hard to maintain, though the ecosystem and what we expect as "usual" would be quite different had we not built TCP's requirements into the network. There's nothing wrong with having n-modal latencies... we can engineer around that. Any sensible load distribution scheme within the network will give you increased variance but it should limit the worst-case latency. You'd perhaps agree that that's a net win. > > This was an example of how exposing packet number or not can have long term ecosystem effects. My point was about the fact that exposing can cause ossification. > > - jana > > On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian < pravb@microsoft.com> wrote: > >> This was definitely true for implementations of TCP, but that is TCP's problem, not the network's > > Flow classification happens through the network and also on the end host with RSS where a flow is mapped to a core. This allows for building high performance receive processing that could be lock free for the most part. The only downside of ECMP on the network and RSS on the CPU is that a single flow will not take multiple paths or get processed on more than one core. Windows on server machines today can saturate 25-35 Gbps for a single TCP connection before being CPU limited. This is a reasonable trade off because I don=E2=80=99t know of cases where a single flow is driving more t= han that amount of traffic. Assumptions about how flows get classified help make for more efficient processing. They also lead to consistent latency. You do not want the traffic to take a bi-modal or N-modal paths (on the network or the host) to being processed because the fluctuations in latency will hurt the workload. I am not arguing for TCP not being resilient to reordering but IMO that should be the uncommon case not the common case. With QUIC if streams were exposed on the network you could take advantage of stream level ECMP and RSS to scale better than TCP but we have chosen to keep the 4-tuple (or the 5-tuple) as the flow classifier on the network which is ok by me since it leads to TCP parity. > > > > Thanks > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar > Sent: Sunday, February 4, 2018 8:35 PM > To: Salz, Rich > Cc: Lubashev, Igor ; Roberto Peon ; QUIC WG > Subject: Re: Packet number encryption > > > > Privacy-protection can't be a user choice, for the reasons others have noted on this thread. > > > That said, my primary argument is for encryption to avoid ossification. Not that it matters now, but I'll note that much of GQUIC's original motivation for encrypting headers was to avoid ossification. > > > > I'll reiterate that fields we expose will get ossified and there are long-term ecosystem effects to this. Let me illustrate this with precisely the packet number field. Middleboxes commonly assume that a TCP flow can only handle packets in-order. This assumption comes from the fact that TCP implementations get poor performance when packets are reordered. This was definitely true for implementations of TCP, but that is TCP's problem, not the network's. However, almost all load-balancers I know of now will pin all packets within a TCP flow to one path, leading to sub-optimal performance in the network, and destroying incentives for the endpoints to deploy reordering-resilient TCP implementations (even though there are plenty of ways of doing this.) > > > > Exposing QUIC's packet number field (as any field) is likely to have similar consequences and a similar ecosystem arc. > > > > > > On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: > > > Optional security tends to devolve to non-secure. > > > > That=E2=80=99s a great aphorism. And sadly all too true. > > > > > --001a1144b82892eefa05648b3fb7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Some overhead consid= erations of packet encryption:

Sensor and control devices:

The powe= r overhead on sensor networks is small compared to just listening on the ra= dio and if not using radio, the latency is probably not critical compared t= o the speed of encryption. To be a bit sci-fi - low-latency encrypted contr= ol signals in robotics might be relevant. Think exo-skeleton hacked by enem= y through targeted signal injection. Still, packet number encryption is lik= ely fast enough in such cases.

For = servers:

<= /div>
The overhead = of packet encryption (single block AES-CTR) is probably around 100 cycles w= ith AES-NI and possibly 160 cycles table based for one block for Intel arch= . This is because parallel multi-block optimisations are not possible. AES-= CTR of one block is about the same as AES-CTR of 4 blocks, and GCM auth tag= adds perhaps 50% to that. Thus packet number encryption might be twice as = fast as AES-GCM of a 64 byte message which is still a 50% overhead.

High speed low latency appli= cations might receive a packet concurrently on two cores, one with a fast p= ath reacting specifically to packets containing only small stream messages,= and one core handling everything else. The message handler could experienc= e a delay of 50% compared to not encrypting packet numbers.

It is not possible to significantly = improve on this in hardware because the packet number must be decrypted bef= ore AEAD can be applied. That is, unless the encrypted packet number is use= d as the IV of AEAD in which case encryption gets a new bottleneck but decr= yption can be processed faster.

My take is that I prefer to avoid packet number gaps because the= y are messy and I don=E2=80=99t believe they provide any significant privac= y, but I also don=E2=80=99t like the crypto cost in low-latency scenarios.<= /div>

If the argument is fo= r ossification and not privacy, I think the encryption is the only option a= s Marten has pointed out. For this reason it makes sense to apply crypto. L= ow-latency systems could create a QUIC variant that drops the packet encryp= tion.

Mikkel

On 6 February = 2018 at 11.13.40, Brian Trammell (IETF) (ietf@trammell.ch) wrote:


> On 6 Feb 2018, at 01:30, Jana Iyengar <jri@google.com> wrote:
> =20
> I don't think we're converging here, so I'd like to tr= y and encourage us to move towards it. I have my opinion, but I care more a= bout forward progress at this point.
> =20
> There are three designs so far:
> 1. Packet numbers as is, with random gaps around migration.
> 2. Packet numbers encrypted, as per Martin's PR.
> 3. Packet numbers encrypted, plus a small modulo sequence number s= omewhere.
> =20
> The concrete ones here are (1) and (2). I'm listing (3) but a= m not inclined to consider it seriously, since it's not concrete enough= , (and I don't want more bits to be spent in the QUIC packet header if = that's where this info goes.)

Unsurprisingly, I'm still for (3). :)

If a concrete proposal would incline you to consider it seriously, I= 9;m happy to write one or two points in this space up, probably for the lis= t at first. (Indeed, I'll probably go ahead and do this anyway today).

> There are opinions about ossification, privacy, and manageability.= I'm not hearing bloody murder, so for what it's worth, I'd lik= e to stipulate first that we can all live with the final design, whichever = one it is. If anyone disagrees, please say so -- I think it'd be usefu= l to hear if there are folks who think a particular design is fundamentally= problematic.
> =20
> My opinion is still for (2) over (1), but I can live with either.

FWIW, I prefer (2) over (1) as well, modulo a little discomfort about t= he crypto: the proposed encryption scheme uses a secret derived from the en= d-to-end secret to ECB-encrypt a plaintext which is completely known to an = on-path observer in a place to see all packets in the common case that pack= ets are neither lost nor reordered on the path -- namely the sequence 0x00 = - 0x3f, 0x4000 - 0x7fff and so on. I Am Not A Cryptographer, but that prope= rty of this algorithm used in this way screams "Call A Cryptographer B= efore Deploying" to me.)

Cheers,

Brian


> On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar <jri@google.com> wrote:
> Praveen,
> =20
> That was precisely my point about the ecosystem evolving. Now that= we have the ability to classify flows, various things have been built arou= nd being able to tell TCP flows. This obviously has benefits as you point o= ut, but the downside is that that I can't get good network utilization = with a single flow. I understand the scaling point, but speaking of common = cases, any server in the wild is usually serving a large number of connecti= ons at moderate speeds, not a single one at 25-35 Gbps... which makes that = sort of scaling less exciting than in a microbenchmark.
> =20
> FWIW, the other downside of ECMP is that multipath transport doesn= 't work -- you need to hash on something else besides the 4-tuple. (We = had to work around this in Google's deployment of connection migration.= )
> =20
> I'll disagree with your point about reordering being the uncom= mon case. While that's true today, this is again an expectation that th= e network works hard to maintain, though the ecosystem and what we expect a= s "usual" would be quite different had we not built TCP's req= uirements into the network. There's nothing wrong with having n-modal l= atencies... we can engineer around that. Any sensible load distribution sch= eme within the network will give you increased variance but it should limit= the worst-case latency. You'd perhaps agree that that's a net win.
> =20
> This was an example of how exposing packet number or not can have = long term ecosystem effects. My point was about the fact that exposing can = cause ossification.
> =20
> - jana
> =20
> On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian <pravb@microsoft.com> wrote:
> >> This was definitely true for implementations of TCP, but = that is TCP's problem, not the network's
> =20
> Flow classification happens through the network and also on the en= d host with RSS where a flow is mapped to a core. This allows for building = high performance receive processing that could be lock free for the most pa= rt. The only downside of ECMP on the network and RSS on the CPU is that a s= ingle flow will not take multiple paths or get processed on more than one c= ore. Windows on server machines today can saturate 25-35 Gbps for a single = TCP connection before being CPU limited. This is a reasonable trade off be= cause I don=E2=80=99t know of cases where a single flow is driving more tha= n that amount of traffic. Assumptions about how flows get classified help m= ake for more efficient processing. They also lead to consistent latency. Yo= u do not want the traffic to take a bi-modal or N-modal paths (on the netwo= rk or the host) to being processed because the fluctuations in latency will= hurt the workload. I am not arguing for TCP not being resilient to reorder= ing but IMO that should be the uncommon case not the common case. With QUIC= if streams were exposed on the network you could take advantage of stream = level ECMP and RSS to scale better than TCP but we have chosen to keep the = 4-tuple (or the 5-tuple) as the flow classifier on the network which is ok = by me since it leads to TCP parity.
> =20
> =20
> =20
> Thanks
> =20
> =20
> =20
> From: QUIC [mailto:quic-b= ounces@ietf.org] On Behalf Of Jana Iyengar
> Sent: Sunday, February 4, 2018 8:35 PM
> To: Salz, Rich <rsalz@akama= i.com>
> Cc: Lubashev, Igor <ilub= ashe@akamai.com>; Roberto Peon <f= enix@fb.com>; QUIC WG <quic@ietf= .org>
> Subject: Re: Packet number encryption
> =20
> =20
> =20
> Privacy-protection can't be a user choice, for the reasons oth= ers have noted on this thread.
> =20
> =20
> That said, my primary argument is for encryption to avoid ossifica= tion. Not that it matters now, but I'll note that much of GQUIC's o= riginal motivation for encrypting headers was to avoid ossification.
> =20
> =20
> =20
> I'll reiterate that fields we expose will get ossified and the= re are long-term ecosystem effects to this. Let me illustrate this with pre= cisely the packet number field. Middleboxes commonly assume that a TCP flow= can only handle packets in-order. This assumption comes from the fact that= TCP implementations get poor performance when packets are reordered. This = was definitely true for implementations of TCP, but that is TCP's probl= em, not the network's. However, almost all load-balancers I know of now= will pin all packets within a TCP flow to one path, leading to sub-optimal= performance in the network, and destroying incentives for the endpoints to= deploy reordering-resilient TCP implementations (even though there are ple= nty of ways of doing this.)
> =20
> =20
> =20
> Exposing QUIC's packet number field (as any field) is likely t= o have similar consequences and a similar ecosystem arc.
> =20
> =20
> =20
> =20
> =20
> On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <rsalz@akamai.com> wrote:
> =20
> > Optional security tends to devolve to non-secure.
> =20
> =20
> =20
> That=E2=80=99s a great aphorism. And sadly all too true.
> =20
> =20
> =20
> =20
> =20

--001a1144b82892eefa05648b3fb7-- From nobody Tue Feb 6 05:43:28 2018 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 2899312D77C for ; Tue, 6 Feb 2018 05:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 O4HQrH4TkgI5 for ; Tue, 6 Feb 2018 05:43:20 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::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 ACC9312AF84 for ; Tue, 6 Feb 2018 05:43:20 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id t22so2520202ioa.7 for ; Tue, 06 Feb 2018 05:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=fWJmG7Mb0bdUmtaPKWCgYWom2ywIg00ut1HqKA9jLhM=; b=SZswL8C9Q2uO1Qd86fnyKE/9mMd4UHKGobLLOFp3dGaWTS76r4wqHZ2SRJvyfYR+tn CeFPspmbf/ucqHrp77IUhHqY0H+vmzQ3AJrB2ikRMaTzTrGJVsilAh3ilA/xeu7tfAAz qJg29fzsWKGpEp+snoxGrPp4sybyVoIj244/uIqUGus98mDeL1vhReObucK0AcHLanKN 3Ee3exT1Jo3o02NMhGfszTZn/KU8zVdyHw9Vacs5f9bFZ59kKPbDs8yjWZT4/X1mrDLa dxRRcrKz8ZKuNAsWNTosAZvmzH9JxVGftb+PVZEWlH9tqHm2JyODlXtLbNbsR0k+MVwm 6CoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=fWJmG7Mb0bdUmtaPKWCgYWom2ywIg00ut1HqKA9jLhM=; b=d3TUEbbwqSbTw/yC8dqSdj/F461BzZf22iejYrdyzyyGATzNU174TF40tbsO99unCk 8n713dvZDEgjp17F7pjuQfZ6sdbzdqFce5s+ls9KoEEquUHRG1nNcPfS+EYlCyhsBD0C etK3mjg/X5b4f8Y2IQX488sX7DQhOmrygtxBjLEVBB6OAedYPdKARfwyCEiWVj69vYms qhPTUOcWx2Xq+R5ASz+9BIdbGQ2hd2hFn1Uo9/O0iz/yYf7yFUu6O6HLRibmM/QnZ+Ke rtmMKU/8k4oLzRQLLcfn33Rl3o95IcGsm1PXgCt77MaiV3XT3w4bjk4C4XQ4vnMnl1TP GcCA== X-Gm-Message-State: APf1xPA0ARx7LsZ5p8eky0ovAdMOD+qK1+Yg2korCHh5DrQ4LI1gCNck PHKb2sEt1FRa+8MbnE9zXR8/coDzAt64eOweF5eibD/A X-Google-Smtp-Source: AH8x226cMeM1aNQwgd20wU5L5E35EeiZjP3MCBI8PoDJK9RE+QjM/0IcxJcYRDnHxual34NPMh3E8FLBzQw8eOMpu0g= X-Received: by 10.107.34.199 with SMTP id i190mr3051884ioi.297.1517924599878; Tue, 06 Feb 2018 05:43:19 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Feb 2018 05:43:19 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 6 Feb 2018 05:43:19 -0800 Message-ID: Subject: Re: Packet number encryption To: "Brian Trammell (IETF)" , Jana Iyengar Cc: Praveen Balasubramanian , "Salz, Rich" , QUIC WG , Roberto Peon , "Lubashev, Igor" Content-Type: multipart/alternative; boundary="001a1140d944925fa005648b5c06" 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, 06 Feb 2018 13:43:27 -0000 --001a1140d944925fa005648b5c06 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 6 February 2018 at 14.35.12, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: Low-latency systems could create a QUIC variant that drops the packet encryption. I meant drop the packet number encryption, not the full AEAD. --001a1140d944925fa005648b5c06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 6 February 2018 a= t 14.35.12, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:
Low-latency systems co= uld create a QUIC variant that drops the packet encryption.

I meant drop the packet number encryption, not th= e full AEAD.

--001a1140d944925fa005648b5c06-- From nobody Tue Feb 6 06:20:43 2018 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 A82D212D7E8 for ; Tue, 6 Feb 2018 06:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.207 X-Spam-Level: X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, 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 3JtBBlyx2R33 for ; Tue, 6 Feb 2018 06:20:38 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D65FC126BF3 for ; Tue, 6 Feb 2018 06:20:37 -0800 (PST) Received: from [163.117.240.106] (unknown [163.117.240.106]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 9FC081B000FD; Tue, 6 Feb 2018 14:20:35 +0000 (GMT) Content-Type: multipart/alternative; boundary=Apple-Mail-B2FBF19A-0D2C-487F-9C02-2C1D67481E5A Mime-Version: 1.0 (1.0) Subject: Re: Packet number encryption From: Gorry Fairhurst X-Mailer: iPad Mail (14F89) In-Reply-To: Date: Tue, 6 Feb 2018 15:20:34 +0100 Cc: Jana Iyengar , Praveen Balasubramanian , "Lubashev, Igor" , Roberto Peon , QUIC WG , "Salz, Rich" Content-Transfer-Encoding: 7bit Message-Id: <4821376D-3865-47D7-8518-AEA8AEC76E84@erg.abdn.ac.uk> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52 @akamai.com> To: Ted Hardie 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, 06 Feb 2018 14:20:42 -0000 --Apple-Mail-B2FBF19A-0D2C-487F-9C02-2C1D67481E5A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I'd like to agree with Ted on this one. Specifically I think we are discussing exposing some specific information in= a header to assist in measurement and operations. To me, this includes considering the possibility that these specific fields= could become ossified - but looking back at the thread, I think it is impor= tant also to note that such ossification is to the exposed info. It would NO= T ossify the QUIC recovery, CC, flow control, options negotiation, etc - bec= ause these protocol mechanisms would not be exposed. This is in contrast to w= hat happened to TCP!=20 Gorry =20 ---- > On 6 Feb 2018, at 01:49, Ted Hardie wrote: >=20 >> On Mon, Feb 5, 2018 at 4:30 PM, Jana Iyengar wrote: >> I don't think we're converging here, so I'd like to try and encourage us t= o move towards it. I have my opinion, but I care more about forward progress= at this point. >>=20 >> There are three designs so far: >> 1. Packet numbers as is, with random gaps around migration. >> 2. Packet numbers encrypted, as per Martin's PR. >> 3. Packet numbers encrypted, plus a small modulo sequence number somewher= e. >>=20 >> The concrete ones here are (1) and (2). I'm listing (3) but am not incli= ned to consider it seriously, since it's not concrete enough, (and I don't w= ant more bits to be spent in the QUIC packet header if that's where this inf= o goes.) >>=20 >=20 > If you'll forgive my saying so, evidence suggests that so many of the conc= rete aspects of such a proposal (where the bits would live, how many bits, e= tc.) would change over the lifetime of a proposal in this WG that any comple= tely nailed down suggestion might as well be a blank sheet for all the beari= ng it would have on the final placement and length. >=20 > The question is: do we wish to expose a small sequence number to assist i= n network analysis and management, yes or no? =20 >=20 > We can argue over the bike shed color after making the decision to build a= shed; requiring the shed have a color before considering the question seems= less productive to me than just answering the question. >=20 > Just my personal opinion, of course. >=20 > Ted >=20 > =20 >> There are opinions about ossification, privacy, and manageability. I'm no= t hearing bloody murder, so for what it's worth, I'd like to stipulate first= that we can all live with the final design, whichever one it is. If anyone= disagrees, please say so -- I think it'd be useful to hear if there are fol= ks who think a particular design is fundamentally problematic. >>=20 >> My opinion is still for (2) over (1), but I can live with either. >>=20 >>> On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: >>> Praveen, >>>=20 >>> That was precisely my point about the ecosystem evolving. Now that we ha= ve the ability to classify flows, various things have been built around bein= g able to tell TCP flows. This obviously has benefits as you point out, but t= he downside is that that I can't get good network utilization with a single f= low. I understand the scaling point, but speaking of common cases, any serve= r in the wild is usually serving a large number of connections at moderate s= peeds, not a single one at 25-35 Gbps... which makes that sort of scaling le= ss exciting than in a microbenchmark. >>>=20 >>> FWIW, the other downside of ECMP is that multipath transport doesn't wor= k -- you need to hash on something else besides the 4-tuple. (We had to work= around this in Google's deployment of connection migration.) >>>=20 >>> I'll disagree with your point about reordering being the uncommon case. W= hile that's true today, this is again an expectation that the network works h= ard to maintain, though the ecosystem and what we expect as "usual" would be= quite different had we not built TCP's requirements into the network. There= 's nothing wrong with having n-modal latencies... we can engineer around tha= t. Any sensible load distribution scheme within the network will give you in= creased variance but it should limit the worst-case latency. You'd perhaps a= gree that that's a net win. >>>=20 >>> This was an example of how exposing packet number or not can have long t= erm ecosystem effects. My point was about the fact that exposing can cause o= ssification. >>>=20 >>> - jana >>>=20 >>>> On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian wrote: >>>> >> This was definitely true for implementations of TCP, but that is TCP= 's problem, not the network's >>>>=20 >>>> Flow classification happens through the network and also on the end hos= t with RSS where a flow is mapped to a core. This allows for building high p= erformance receive processing that could be lock free for the most part. The= only downside of ECMP on the network and RSS on the CPU is that a single fl= ow will not take multiple paths or get processed on more than one core. Wind= ows on server machines today can saturate 25-35 Gbps for a single TCP connec= tion before being CPU limited. This is a reasonable trade off because I don= =E2=80=99t know of cases where a single flow is driving more than that amoun= t of traffic. Assumptions about how flows get classified help make for more e= fficient processing. They also lead to consistent latency. You do not want t= he traffic to take a bi-modal or N-modal paths (on the network or the host) t= o being processed because the fluctuations in latency will hurt the workload= . I am not arguing for TCP not being resilient to reordering but IMO that sh= ould be the uncommon case not the common case. With QUIC if streams were exp= osed on the network you could take advantage of stream level ECMP and RSS to= scale better than TCP but we have chosen to keep the 4-tuple (or the 5-tupl= e) as the flow classifier on the network which is ok by me since it leads to= TCP parity. >>>>=20 >>>> =20 >>>>=20 >>>> Thanks >>>>=20 >>>> =20 >>>>=20 >>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar >>>> Sent: Sunday, February 4, 2018 8:35 PM >>>> To: Salz, Rich >>>> Cc: Lubashev, Igor ; Roberto Peon ; Q= UIC WG >>>> Subject: Re: Packet number encryption >>>>=20 >>>> =20 >>>>=20 >>>> Privacy-protection can't be a user choice, for the reasons others have n= oted on this thread.=20 >>>>=20 >>>>=20 >>>> That said, my primary argument is for encryption to avoid ossification.= Not that it matters now, but I'll note that much of GQUIC's original motiva= tion for encrypting headers was to avoid ossification. >>>>=20 >>>> =20 >>>>=20 >>>> I'll reiterate that fields we expose will get ossified and there are lo= ng-term ecosystem effects to this. Let me illustrate this with precisely the= packet number field. Middleboxes commonly assume that a TCP flow can only h= andle packets in-order. This assumption comes from the fact that TCP impleme= ntations get poor performance when packets are reordered. This was definitel= y true for implementations of TCP, but that is TCP's problem, not the networ= k's. However, almost all load-balancers I know of now will pin all packets w= ithin a TCP flow to one path, leading to sub-optimal performance in the netw= ork, and destroying incentives for the endpoints to deploy reordering-resili= ent TCP implementations (even though there are plenty of ways of doing this.= ) >>>>=20 >>>> =20 >>>>=20 >>>> Exposing QUIC's packet number field (as any field) is likely to have si= milar consequences and a similar ecosystem arc. >>>>=20 >>>> =20 >>>>=20 >>>> =20 >>>>=20 >>>> On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: >>>>=20 >>>> > Optional security tends to devolve to non-secure. >>>>=20 >>>> =20 >>>>=20 >>>> That=E2=80=99s a great aphorism. And sadly all too true. >>>>=20 >>>> =20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail-B2FBF19A-0D2C-487F-9C02-2C1D67481E5A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I'd like to agree with Ted on this one= .

Specifically I think we are discussing exposing some specific information= in a header to assist in measurement and operations.

To me, this includes c= onsidering  the possibility that these specific fields could become oss= ified - but looking back at the thread, I think it is important also to note= that such ossification is to the exposed info. It would NOT ossify the QUIC= recovery, CC, flow control, options negotiation, etc - because these protoc= ol mechanisms would not be exposed. This is in contrast to what happened to TCP! 

Gorry
 
----

On 6 Feb 2018, at 01:49, Ted Har= die <ted.ietf@gmail.com> wro= te:

On Mon, Feb= 5, 2018 at 4:30 PM, Jana Iyengar <jri@google.com> wrote:
I don't think we're converging here, so I'd like to try= and encourage us to move towards it. I have my opinion, but I care more abo= ut forward progress at this point.

There are three design= s so far:
1. Packet numbers as is, with random gaps around migrati= on.
2. Packet numbers encrypted, as per Martin's PR.
3. P= acket numbers encrypted, plus a small modulo sequence number somewhere.

The concrete ones here are (1) and (2).  I'm listing (3) but am not inclined to consider it seriousl= y, since it's not concrete enough, (and I don't want more bits to be spent i= n the QUIC packet header if that's where this info goes.)


If you'll forgive my saying so, evi= dence suggests that so many of the concrete aspects of such a proposal (wher= e the bits would live, how many bits, etc.) would change over the lifetime o= f a proposal in this WG that any completely nailed down suggestion might as w= ell be a blank sheet for all the bearing it would have on the final placemen= t and length.

The question is:  do we wish to expose a= small sequence number to assist in network analysis and management, yes or n= o? 

We can argue over the bike shed color after making the deci= sion to build a shed; requiring the shed have a color before considering the= question seems less productive to me than just answering the question.
<= br>
Just my personal opinion, of course.

Ted
=

 
There are opinions about ossification, privacy, and manageability. I'm no= t hearing bloody murder, so for what it's worth, I'd like to stipulate first= that we can all live with the final design, whichever one it is.  If a= nyone disagrees, please say so -- I think it'd be useful to hear if there ar= e folks who think a particular design is fundamentally problematic.

My opinion is still for (2) over (1), b= ut I can live with either.

On Mon= , Feb 5, 2018 at 3:32 PM, Jana Iyengar <jri@google.com> wrote:
Praveen,

=
That= was precisely my point about the ecosystem evolving. Now that we have the a= bility to classify flows, various things have been built around being able t= o tell TCP flows. This obviously has benefits as you point out, but the down= side is that that I can't get good network utilization with a single flow. I= understand the scaling point, but speaking of common c= ases, any server in the wild is usually serving a large number of connection= s at moderate speeds, not a single one at 25-35 Gbps... which makes that sor= t of scaling less exciting than in a microbenchmark.

FWIW, the other downside of ECMP i= s that multipath transport doesn't work -- you need to hash on something els= e besides the 4-tuple. (We had to work around this in Google's deployment of= connection migration.)

I'll dis= agree with your point about reordering being the uncommon case. While that's= true today, this is again an expectation that the network works hard to mai= ntain, though the ecosystem and what we expect as "usual" would be quite dif= ferent had we not built TCP's requirements into the network. There's nothing= wrong with having n-modal latencies... we can engineer around that. Any sen= sible load distribution scheme within the network will give you increased va= riance but it should limit the worst-case latency. You'd perhaps agree that t= hat's a net win.

This was an example of how exp= osing packet number or not can have long term ecosystem effects. My point wa= s about the fact that exposing can cause ossification.

- j= ana

On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian <= span dir=3D"ltr"><pravb@microsoft.com> wrote:

>> This was definitely true for implementations= of TCP, but that is TCP's problem, not the network's

Flow classification happens through the networ= k and also on the end host with RSS where a flow is mapped to a core. This a= llows for building high performance receive processing that could be lock fr= ee for the most part. The only downside of ECMP on the network and RSS on the CPU is that a single flow will not ta= ke multiple paths or get processed on more than one core. Windows on server m= achines today can saturate 25-35 Gbps for a single TCP connection before bei= ng CPU limited. This is a  reasonable trade off because I don=E2=80=99t know of cases where a single flow is driv= ing more than that amount of traffic. Assumptions about how flows get classi= fied help make for more efficient processing. They also lead to consistent l= atency. You do not want the traffic to take a bi-modal or N-modal paths (on the network or the host) to being proc= essed because the fluctuations in latency will hurt the workload. I am not a= rguing for TCP not being resilient to reordering but IMO that should be the u= ncommon case not the common case. With QUIC if streams were exposed on the network you could take advan= tage of stream level ECMP and RSS to scale better than TCP but we have chose= n to keep the 4-tuple (or the 5-tuple) as the flow classifier on the network= which is ok by me since it leads to TCP parity.

 

Thanks

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behal= f Of Jana Iyengar
Sent: Sunday, February 4, 2018 8:35 PM
To: Salz, Rich <rsalz@akamai.com>
Cc: Lubashev, Igor <ilubashe@akamai.com>; Roberto Peon <fenix@fb.com>; QUIC WG <quic@ietf.org>
Subject: Re: Packet number encryption

 

Privacy-protection can't be a user choice, for the re= asons others have noted on this thread. 


That said, my primary argument is for encryption to avoid ossification. Not t= hat it matters now, but I'll note that much of GQUIC's original motivation f= or encrypting headers was to avoid ossification.

 

I'll reiterate that fields we expose will get ossifie= d and there are long-term ecosystem effects to this. Let me illustrate this w= ith precisely the packet number field. Middleboxes commonly assume that a TC= P flow can only handle packets in-order. This assumption comes from the fact that TCP implementations get p= oor performance when packets are reordered. This was definitely true for imp= lementations of TCP, but that is TCP's problem, not the network's. However, a= lmost all load-balancers I know of now will pin all packets within a TCP flow to one path, leading to s= ub-optimal performance in the network, and destroying incentives for the end= points to deploy reordering-resilient TCP implementations (even though there= are plenty of ways of doing this.)

 

Exposing QUIC's packet number field (as any field) is= likely to have similar consequences and a similar ecosystem arc.<= /u>

 

 

On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich <rsalz@akamai.com> wro= te:

> Optional security tends= to devolve to non-secure.

 

That=E2=80=99s a great aphorism.  And s= adly all too true.

 




= --Apple-Mail-B2FBF19A-0D2C-487F-9C02-2C1D67481E5A-- From nobody Tue Feb 6 06:31:01 2018 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 B3CAD12D7F0 for ; Tue, 6 Feb 2018 06:31:00 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, 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 EmVP46hgK_Sk for ; Tue, 6 Feb 2018 06:30:56 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6034912D7EA for ; Tue, 6 Feb 2018 06:30:56 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id AD61C340D5A; Tue, 6 Feb 2018 15:30:54 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.28674); Tue, 6 Feb 2018 15:30:54 +0100 (CET) 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; Tue, 6 Feb 2018 15:30:54 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44517049; Tue, 06 Feb 2018 15:30:54 +0100 From: "Brian Trammell (IETF)" Message-Id: <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_CD6F9FAC-57A8-4209-9067-2DE68EEF6404"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) Date: Tue, 6 Feb 2018 15:30:53 +0100 In-Reply-To: Cc: QUIC WG To: Kazuho Oku References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> 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, 06 Feb 2018 14:31:01 -0000 --Apple-Mail=_CD6F9FAC-57A8-4209-9067-2DE68EEF6404 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Kazuho, all, (splitting the thread, trimming recipients) We've been kicking around a few ideas like this one around the office = today, more or less as you were writing this... > On 6 Feb 2018, at 13:49, Kazuho Oku wrote: >=20 > 2018-02-06 9:30 GMT+09:00 Jana Iyengar : >> I don't think we're converging here, so I'd like to try and encourage = us to >> move towards it. I have my opinion, but I care more about forward = progress >> at this point. >>=20 >> There are three designs so far: >> 1. Packet numbers as is, with random gaps around migration. >> 2. Packet numbers encrypted, as per Martin's PR. >> 3. Packet numbers encrypted, plus a small modulo sequence number = somewhere. >=20 > I wonder if we can provide opportunity to observe upstream loss / > reorder rate by just reserving one bit per packet. >=20 > The strawman is as follows. >=20 > Sender exposes one bit per packet that can be observed by on-path > devices. The bit is flipped for every 256 packets that the sender > sends. Observer records the bit of each packet as they pass by. >=20 > If there is no loss or reorder, the pattern an on-path device would > observe is repetition of 256 zeros and 256 ones. In other words, the > wavelength is 512 samples. >=20 > When there is a loss, the wavelength becomes shorter. The wavelength > becomes 512 * (1-loss_rate) samples. For example, if the wavelength > being observed is 384, loss rate is 25%. >=20 > If there is reorder, the edge (i.e. shift from zereos to ones, or vice > versa) becomes unclear. Duration of the transition will reflect the > extent of reordering. This is a pretty cool idea, but it doesn't provide enough information to = protect the spin bit from reordering. This could be easily fixed by = moving to a two-bit spin, as Gorry (I think) suggested. Among other = things in this space, Piet's also looking into how much reordering = information could be extracted from a two-bit spin itself. There's a little complexity here -- you'd ideally like the starting = point to depend on the window size, which you actually don't know at the = starting point, and so on and so forth, but those are details. > Theoretically, it might be possible to explain the approach as a way > to let the sender emit a wave, then FFT the wave in on-path devices to > observe loss / reorder. Or it could be explained as just sending one > bit of the sequence number, somewhere in the middle (i.e., not LSB nor > MSB). >=20 > The pros of the approach is obvious; we will only spend 1 bit per > packet. Privacy impact is minimum. Implementing it is easy. Another > benefit is that it would be difficult (if not impossible) for on-path > devices to use the bit for purposes other than observation (i.e., > change the ordering of the packets "for performance"). >=20 > OTOH I am not sure how hard it would be to build tools for observing > upstream behavior using the proposed approach. Or I could well be > missing some requirements that operators have, as I am an endpoint > developer. It's generally not the computational complexity of the task at a passive = measurement point that is limiting to passive observation, it's the I/O = (i.e. the amount of data that must be analyzed to generate a useful = observation, and how far that data needs to be transmitted). Approaches = like this one that trade off additional analysis-time complexity for = ease of implementation and endpoint runtime simplicity are where we want = to look, IMO. Cheers, Brian >> The concrete ones here are (1) and (2). I'm listing (3) but am not = inclined >> to consider it seriously, since it's not concrete enough, (and I = don't want >> more bits to be spent in the QUIC packet header if that's where this = info >> goes.) >>=20 >> There are opinions about ossification, privacy, and manageability. = I'm not >> hearing bloody murder, so for what it's worth, I'd like to stipulate = first >> that we can all live with the final design, whichever one it is. If = anyone >> disagrees, please say so -- I think it'd be useful to hear if there = are >> folks who think a particular design is fundamentally problematic. >>=20 >> My opinion is still for (2) over (1), but I can live with either. >>=20 >> On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: >>>=20 >>> Praveen, >>>=20 >>> That was precisely my point about the ecosystem evolving. Now that = we have >>> the ability to classify flows, various things have been built around = being >>> able to tell TCP flows. This obviously has benefits as you point = out, but >>> the downside is that that I can't get good network utilization with = a single >>> flow. I understand the scaling point, but speaking of common cases, = any >>> server in the wild is usually serving a large number of connections = at >>> moderate speeds, not a single one at 25-35 Gbps... which makes that = sort of >>> scaling less exciting than in a microbenchmark. >>>=20 >>> FWIW, the other downside of ECMP is that multipath transport doesn't = work >>> -- you need to hash on something else besides the 4-tuple. (We had = to work >>> around this in Google's deployment of connection migration.) >>>=20 >>> I'll disagree with your point about reordering being the uncommon = case. >>> While that's true today, this is again an expectation that the = network works >>> hard to maintain, though the ecosystem and what we expect as "usual" = would >>> be quite different had we not built TCP's requirements into the = network. >>> There's nothing wrong with having n-modal latencies... we can = engineer >>> around that. Any sensible load distribution scheme within the = network will >>> give you increased variance but it should limit the worst-case = latency. >>> You'd perhaps agree that that's a net win. >>>=20 >>> This was an example of how exposing packet number or not can have = long >>> term ecosystem effects. My point was about the fact that exposing = can cause >>> ossification. >>>=20 >>> - jana >>>=20 >>> On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian >>> wrote: >>>>=20 >>>>>> This was definitely true for implementations of TCP, but that is = TCP's >>>>>> problem, not the network's >>>>=20 >>>> Flow classification happens through the network and also on the end = host >>>> with RSS where a flow is mapped to a core. This allows for building = high >>>> performance receive processing that could be lock free for the most = part. >>>> The only downside of ECMP on the network and RSS on the CPU is that = a single >>>> flow will not take multiple paths or get processed on more than one = core. >>>> Windows on server machines today can saturate 25-35 Gbps for a = single TCP >>>> connection before being CPU limited. This is a reasonable trade = off because >>>> I don=E2=80=99t know of cases where a single flow is driving more = than that amount >>>> of traffic. Assumptions about how flows get classified help make = for more >>>> efficient processing. They also lead to consistent latency. You do = not want >>>> the traffic to take a bi-modal or N-modal paths (on the network or = the host) >>>> to being processed because the fluctuations in latency will hurt = the >>>> workload. I am not arguing for TCP not being resilient to = reordering but IMO >>>> that should be the uncommon case not the common case. With QUIC if = streams >>>> were exposed on the network you could take advantage of stream = level ECMP >>>> and RSS to scale better than TCP but we have chosen to keep the = 4-tuple (or >>>> the 5-tuple) as the flow classifier on the network which is ok by = me since >>>> it leads to TCP parity. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks >>>>=20 >>>>=20 >>>>=20 >>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar >>>> Sent: Sunday, February 4, 2018 8:35 PM >>>> To: Salz, Rich >>>> Cc: Lubashev, Igor ; Roberto Peon = ; >>>> QUIC WG >>>> Subject: Re: Packet number encryption >>>>=20 >>>>=20 >>>>=20 >>>> Privacy-protection can't be a user choice, for the reasons others = have >>>> noted on this thread. >>>>=20 >>>>=20 >>>> That said, my primary argument is for encryption to avoid = ossification. >>>> Not that it matters now, but I'll note that much of GQUIC's = original >>>> motivation for encrypting headers was to avoid ossification. >>>>=20 >>>>=20 >>>>=20 >>>> I'll reiterate that fields we expose will get ossified and there = are >>>> long-term ecosystem effects to this. Let me illustrate this with = precisely >>>> the packet number field. Middleboxes commonly assume that a TCP = flow can >>>> only handle packets in-order. This assumption comes from the fact = that TCP >>>> implementations get poor performance when packets are reordered. = This was >>>> definitely true for implementations of TCP, but that is TCP's = problem, not >>>> the network's. However, almost all load-balancers I know of now = will pin all >>>> packets within a TCP flow to one path, leading to sub-optimal = performance in >>>> the network, and destroying incentives for the endpoints to deploy >>>> reordering-resilient TCP implementations (even though there are = plenty of >>>> ways of doing this.) >>>>=20 >>>>=20 >>>>=20 >>>> Exposing QUIC's packet number field (as any field) is likely to = have >>>> similar consequences and a similar ecosystem arc. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich = wrote: >>>>=20 >>>>> Optional security tends to devolve to non-secure. >>>>=20 >>>>=20 >>>>=20 >>>> That=E2=80=99s a great aphorism. And sadly all too true. >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 >=20 > -- > Kazuho Oku --Apple-Mail=_CD6F9FAC-57A8-4209-9067-2DE68EEF6404 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp5vB0ACgkQihK3vwvq RqOlqw/9FX/wuVc8V2vHsF6Am9dAOw6ukHs4mQkRlu1hm2elWETQTqHj4jGpyjAM zs6PDY5jgfL9UvLzcW5BEzeVEsrJmI6RSRBipbn5zp2L7U22NMzmWvk3bsdPB4GY 5OcInHpCngpzIOa9UfCPNLY6S4NLoH/n25JWbl8qHMFitikLVzBQcAuBc3YztqlN kOs6xBQcF2duGbMlCDvtz5IAcuVLgmt+/GVr5QPt2gBRqXDfhlDoyUr9tFTaZfMW JqZ08QOZ272qOgAwbXNaXOMfx9VT6MWEoSdnkRwZhpODVMyFeqxhXxST6lF5S5tP vm9+xlN09RLdVcSzzkYSKO0Ei7T1K30q0QS1W7bg7cDOHK1UeHmUjeZON7e6tq+z 5gYdyxL3T5eGyj1GxMD7svtx+pt4WpwpBSnmWUXTO0LJ4FJeBXtnPUJ4x+NBlhZe elp4luXYlnaD7TbIlTBtTLQ0MgnUtqHbsy6QUfZM7lFWavYQzNtPBOcPXkctghhr /a+uu8v2i3Ivzi4RVmIYI2qV0DAqr8ienq4ZY6r4Wd5g+/tUb7M0I4mZoTNOf+EZ 4WfWepWJ68wXbUpFSrvO5DHnMS0dsPtbQIa5zQsO09zSIfcMCiCJQKym6GVlMSbp AAzdJ9dj1jY4zISwlHU1R+ZE9tMnv2SXmdroNSjQlYpHcceDfbE= =jX9n -----END PGP SIGNATURE----- --Apple-Mail=_CD6F9FAC-57A8-4209-9067-2DE68EEF6404-- From nobody Tue Feb 6 06:46:42 2018 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 BCF0612E05D for ; Tue, 6 Feb 2018 06:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 i-fYRgaw_7mQ for ; Tue, 6 Feb 2018 06:46:38 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DC312E059 for ; Tue, 6 Feb 2018 06:46:38 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4BCE7340D9D; Tue, 6 Feb 2018 15:46:37 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.31642); Tue, 6 Feb 2018 15:46:37 +0100 (CET) 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; Tue, 6 Feb 2018 15:46:37 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44519603; Tue, 06 Feb 2018 15:46:37 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_85325B80-7A3F-483D-8D34-7462C5AE3365"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) Date: Tue, 6 Feb 2018 15:46:36 +0100 In-Reply-To: Cc: QUIC WG To: Ted Hardie References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> 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, 06 Feb 2018 14:46:41 -0000 --Apple-Mail=_85325B80-7A3F-483D-8D34-7462C5AE3365 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Ted, (trimming, forking, #include apologies for google/apple mail = shenanigans) > On 6 Feb 2018, at 01:49, Ted Hardie wrote: >=20 > On Mon, Feb 5, 2018 at 4:30 PM, Jana Iyengar wrote: > I don't think we're converging here, so I'd like to try and encourage = us to move towards it. I have my opinion, but I care more about forward = progress at this point. >=20 > There are three designs so far: > 1. Packet numbers as is, with random gaps around migration. > 2. Packet numbers encrypted, as per Martin's PR. > 3. Packet numbers encrypted, plus a small modulo sequence number = somewhere. >=20 > The concrete ones here are (1) and (2). I'm listing (3) but am not = inclined to consider it seriously, since it's not concrete enough, (and = I don't want more bits to be spent in the QUIC packet header if that's = where this info goes.) >=20 >=20 > If you'll forgive my saying so, evidence suggests that so many of the = concrete aspects of such a proposal (where the bits would live, how many = bits, etc.) would change over the lifetime of a proposal in this WG that = any completely nailed down suggestion might as well be a blank sheet for = all the bearing it would have on the final placement and length. Heh. Indeed. > The question is: do we wish to expose a small sequence number to = assist in network analysis and management, yes or no? A friendly amendment to refine this question, since I think it = presupposes too much about the shape and color of said blank sheet of = paper: do we wish to expose a signal that is designed to meet the = following requirements: - assist in on-path detection and measurement of upstream packet loss - assist in on-path detection and measurement or upstream packet = reordering - improve the passive measurement of RTT in the presence of reordering = (i.e., fix the spin bit to work without the packet number) We (without the encryption PR) already have a single (implicit) signal = for these three requirements, but we can without too much thought = already see a few ways to add an implicit signal back in, probably even = using only bits vacated in the short header by making encrypted packet = numbers use varint encoding. +1 to Ted: if we could at least come to consensus as a WG that these = requirements are important, then we can separate these two discussions. = Let's reserve some bits in the header, let those of us who care about = the shape of the measurement nybble go off and work on a concrete = proposal, and move on. Cheers, Brian > We can argue over the bike shed color after making the decision to = build a shed; requiring the shed have a color before considering the = question seems less productive to me than just answering the question. >=20 > Just my personal opinion, of course. >=20 > Ted >=20 --Apple-Mail=_85325B80-7A3F-483D-8D34-7462C5AE3365 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp5v8wACgkQihK3vwvq RqNklg//YmhJquDq5TBRwsn1e/cMZWI7yWO2YM5p8fCJ2HWEesjTiOn3AdHjFmCP DQG0mmpaopD6BTKmGbJAZavSukfTHar1ISlKoEfKtKnF3Wr3hM0rD5+gkY4LV785 xqK3gZMDzJ2sunXAuyAZLoa6R1bT5jFWcjn6WjdShU3RWv/YBPdwAhVH3jKyqSUC 9UMtAOsODC1K5Lny9qnrD5eapkmCMYHG3xIqBpZdtcoZIk/mrVDYu8pWb0MAxh+7 sQID9v4apYHOUmnBmaaw7v7Dk5FBNUvPW+1ga+Ylm8YnoFpHlukq+2OsGQFAEXyp KgcKWc/y1jqfrhCR9GgfggKbbg4/nFafUarZ8lB8pY2ZtKma7yD4Pt4rNoFYs+OG VqkDHRK1eTn9JgnZMQnFzZfaXFZVAjvwM3vbw/2CWRAw0XJpFiuvg4fF25CU4AS+ XMgcCKTw8Wgf10IVS1fwHUPr0coj3GT4yNutXNIW06uS42CvvLm2XO+iV1fIgKIg ssBAWsozMioWCsxPErnYapFEUGgYvomDFjaASeyLx7UrPbpJ0qmIdmwG1+Jz9wri ySxdEXC4p7KDDn+YkG0Te1+GUvvdz85zQWYFBreqGcJlL9py37JsJTZaW9XUMQuX hZwuhuRuTW7OBkqf37Gz9kqClSxsf7NnKbB6J7bwdiHxNOGtULQ= =eu/2 -----END PGP SIGNATURE----- --Apple-Mail=_85325B80-7A3F-483D-8D34-7462C5AE3365-- From nobody Tue Feb 6 06:52:32 2018 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 472A712D7EC for ; Tue, 6 Feb 2018 06:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 7j7J7WECP1eb for ; Tue, 6 Feb 2018 06:52:29 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 6414A120454 for ; Tue, 6 Feb 2018 06:52:29 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 416EA64BC1CE4 for ; Tue, 6 Feb 2018 14:52:25 +0000 (GMT) Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 6 Feb 2018 14:52:26 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0361.001; Tue, 6 Feb 2018 22:52:19 +0800 From: "Roni Even (A)" To: "Brian Trammell (IETF)" , Ted Hardie CC: QUIC WG Subject: RE: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) Thread-Topic: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) Thread-Index: AQHTn1lW9weAa8mzzUyvUmOH39MiCaOXdRyQ Date: Tue, 6 Feb 2018 14:52:18 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8623C3@DGGEMM506-MBX.china.huawei.com> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.244] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 06 Feb 2018 14:52:31 -0000 Brian, I like your proposal as for the requirements I think that we are also talki= ng about one point measurement and not two points. Roni -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell (IETF= ) Sent: Tuesday, February 06, 2018 4:47 PM To: Ted Hardie Cc: QUIC WG Subject: Explicit measurability in the QUIC wire image (was Re: Packet numb= er encryption) hi Ted, (trimming, forking, #include apologies for google/apple mail shenanigans) > On 6 Feb 2018, at 01:49, Ted Hardie wrote: >=20 > On Mon, Feb 5, 2018 at 4:30 PM, Jana Iyengar wrote: > I don't think we're converging here, so I'd like to try and encourage us = to move towards it. I have my opinion, but I care more about forward progre= ss at this point. >=20 > There are three designs so far: > 1. Packet numbers as is, with random gaps around migration. > 2. Packet numbers encrypted, as per Martin's PR. > 3. Packet numbers encrypted, plus a small modulo sequence number somewher= e. >=20 > The concrete ones here are (1) and (2). I'm listing (3) but am not incli= ned to consider it seriously, since it's not concrete enough, (and I don't = want more bits to be spent in the QUIC packet header if that's where this i= nfo goes.) >=20 >=20 > If you'll forgive my saying so, evidence suggests that so many of the con= crete aspects of such a proposal (where the bits would live, how many bits,= etc.) would change over the lifetime of a proposal in this WG that any com= pletely nailed down suggestion might as well be a blank sheet for all the b= earing it would have on the final placement and length. Heh. Indeed. > The question is: do we wish to expose a small sequence number to assist = in network analysis and management, yes or no? A friendly amendment to refine this question, since I think it presupposes = too much about the shape and color of said blank sheet of paper: do we wish= to expose a signal that is designed to meet the following requirements: - assist in on-path detection and measurement of upstream packet loss - assist in on-path detection and measurement or upstream packet reordering - improve the passive measurement of RTT in the presence of reordering (i.e= ., fix the spin bit to work without the packet number) We (without the encryption PR) already have a single (implicit) signal for = these three requirements, but we can without too much thought already see a= few ways to add an implicit signal back in, probably even using only bits = vacated in the short header by making encrypted packet numbers use varint e= ncoding. +1 to Ted: if we could at least come to consensus as a WG that these requir= ements are important, then we can separate these two discussions. Let's res= erve some bits in the header, let those of us who care about the shape of t= he measurement nybble go off and work on a concrete proposal, and move on. Cheers, Brian > We can argue over the bike shed color after making the decision to build = a shed; requiring the shed have a color before considering the question see= ms less productive to me than just answering the question. >=20 > Just my personal opinion, of course. >=20 > Ted >=20 From nobody Tue Feb 6 06:52:48 2018 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 B7AAF120454 for ; Tue, 6 Feb 2018 06:52:37 -0800 (PST) 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, 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 a7qSUNuh0cXj for ; Tue, 6 Feb 2018 06:52:34 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::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 7F04B12E05C for ; Tue, 6 Feb 2018 06:52:34 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id w17so1173635pgv.6 for ; Tue, 06 Feb 2018 06:52:34 -0800 (PST) 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=p08HaxO/BtZTj7kV/Kd+EeHXefluZegOb5UZ6H4E1C4=; b=rTFng28UHZM+6VdJ9HitHmx4vg6Ue4jRCgzqKg19oqVidFGQA4GZtDajzgJlwM0lJM 6mEu/DB9cDZqkZuJ2VWt3IYrGhkJagh11V+xbJUmcaYsmFZb2D8hkiS7Eya1fckoku2A Co6cIHqtg2uIzrVXbEjP0DtgSOdxEwSigzD4lleNOgiaEPoufKJN20EtKKWbY1fpuYFv WO57rG7q31EHO0bYCZl3Ef36z1T5bT8V3sevc/HH5O1bV2sXrpzTPkfiZy2CrLAflIpO fNt1bgb4r3fzpjpQJkalL6e7ppFchq0naeJCjP4nAZUR7ONhi05AlflYqf5BRFu+tkJV 0khA== 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=p08HaxO/BtZTj7kV/Kd+EeHXefluZegOb5UZ6H4E1C4=; b=SxkEHhpRkPgff+h6gZADo1+Ws+KXn6PYRTJzyN2AI06cc0O8U7/5dJf8rX7dWsudkF Pp+2E/jROZPRT0d9b+pR/httm/yhg5bVJjD2RTlvQdjEndO9QBHQB10NHAutC8yUbyXL US768XZgEUwO4uGfHf6gpVHJkoEw9c7PKQAcMwux++diQawgk/jNU+DpielSFGc0P5cm UsSV83Fb4p9XK7WoEA4BlyiW70sFUUOl0/QNYT2gYPPkWtgV+57nSD7rgr5XhBRjSPuK gZK3x+aB6KaJ0TswPBcTat2cyu2B6SrzP7S6CElI/NPNUd67cscWhkkYKycCdESaVfia aMAg== X-Gm-Message-State: APf1xPABFg7sujVEWruPHwNqI/xrhiF+gWewZwguVaLv0328W3mkbuRj jHFu6n3qmq7vN+ELt+V4ZQtH+7Lad+MsLhhoZXA= X-Google-Smtp-Source: AH8x225yW7NL6BgrpUo9GeXDhxpxWScJSTQewwsvFHUf6mo5XlNYYbmfZP/N2BPiNg0nqlsx9McjtMReaaqWBgWWzbA= X-Received: by 10.98.75.218 with SMTP id d87mr2716912pfj.11.1517928753835; Tue, 06 Feb 2018 06:52:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Tue, 6 Feb 2018 06:52:33 -0800 (PST) In-Reply-To: <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> From: Kazuho Oku Date: Tue, 6 Feb 2018 23:52:33 +0900 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) 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: Tue, 06 Feb 2018 14:52:38 -0000 Hi Brian, Thank you for the response. Responding in-line. 2018-02-06 23:30 GMT+09:00 Brian Trammell (IETF) : > hi Kazuho, all, > > (splitting the thread, trimming recipients) > > We've been kicking around a few ideas like this one around the office tod= ay, more or less as you were writing this... > >> On 6 Feb 2018, at 13:49, Kazuho Oku wrote: >> >> 2018-02-06 9:30 GMT+09:00 Jana Iyengar : >>> I don't think we're converging here, so I'd like to try and encourage u= s to >>> move towards it. I have my opinion, but I care more about forward progr= ess >>> at this point. >>> >>> There are three designs so far: >>> 1. Packet numbers as is, with random gaps around migration. >>> 2. Packet numbers encrypted, as per Martin's PR. >>> 3. Packet numbers encrypted, plus a small modulo sequence number somewh= ere. >> >> I wonder if we can provide opportunity to observe upstream loss / >> reorder rate by just reserving one bit per packet. >> >> The strawman is as follows. >> >> Sender exposes one bit per packet that can be observed by on-path >> devices. The bit is flipped for every 256 packets that the sender >> sends. Observer records the bit of each packet as they pass by. >> >> If there is no loss or reorder, the pattern an on-path device would >> observe is repetition of 256 zeros and 256 ones. In other words, the >> wavelength is 512 samples. >> >> When there is a loss, the wavelength becomes shorter. The wavelength >> becomes 512 * (1-loss_rate) samples. For example, if the wavelength >> being observed is 384, loss rate is 25%. >> >> If there is reorder, the edge (i.e. shift from zereos to ones, or vice >> versa) becomes unclear. Duration of the transition will reflect the >> extent of reordering. > > This is a pretty cool idea, but it doesn't provide enough information to = protect the spin bit from reordering. This could be easily fixed by moving = to a two-bit spin, as Gorry (I think) suggested. Among other things in this= space, Piet's also looking into how much reordering information could be e= xtracted from a two-bit spin itself. > > There's a little complexity here -- you'd ideally like the starting point= to depend on the window size, which you actually don't know at the startin= g point, and so on and so forth, but those are details. Actually I was thinking of having a bit that is independent from the "spin bit", which is proposed to measure the latency. We can have one bit that measures the latency, and one bit that measures packet loss / reorder. The former will be flipped every RTT. The latter will be flipped for for every N packets being sent (I used the N=3D256 example). My understanding is that we want to observe three properties: latency, loss, reordering. To me it seems that we might be able to achieve that using 2 bits. OTOH there could be other ways to achieve the three indicators using 2 bits. I think that we would have an interesting discussion. > >> Theoretically, it might be possible to explain the approach as a way >> to let the sender emit a wave, then FFT the wave in on-path devices to >> observe loss / reorder. Or it could be explained as just sending one >> bit of the sequence number, somewhere in the middle (i.e., not LSB nor >> MSB). >> >> The pros of the approach is obvious; we will only spend 1 bit per >> packet. Privacy impact is minimum. Implementing it is easy. Another >> benefit is that it would be difficult (if not impossible) for on-path >> devices to use the bit for purposes other than observation (i.e., >> change the ordering of the packets "for performance"). >> >> OTOH I am not sure how hard it would be to build tools for observing >> upstream behavior using the proposed approach. Or I could well be >> missing some requirements that operators have, as I am an endpoint >> developer. > > It's generally not the computational complexity of the task at a passive = measurement point that is limiting to passive observation, it's the I/O (i.= e. the amount of data that must be analyzed to generate a useful observatio= n, and how far that data needs to be transmitted). Approaches like this one= that trade off additional analysis-time complexity for ease of implementat= ion and endpoint runtime simplicity are where we want to look, IMO. Thank you very much for explaining that. It helps a lot. I would keep that in mind while I follow the discussion. > > Cheers, > > Brian > >>> The concrete ones here are (1) and (2). I'm listing (3) but am not inc= lined >>> to consider it seriously, since it's not concrete enough, (and I don't = want >>> more bits to be spent in the QUIC packet header if that's where this in= fo >>> goes.) >>> >>> There are opinions about ossification, privacy, and manageability. I'm = not >>> hearing bloody murder, so for what it's worth, I'd like to stipulate fi= rst >>> that we can all live with the final design, whichever one it is. If an= yone >>> disagrees, please say so -- I think it'd be useful to hear if there are >>> folks who think a particular design is fundamentally problematic. >>> >>> My opinion is still for (2) over (1), but I can live with either. >>> >>> On Mon, Feb 5, 2018 at 3:32 PM, Jana Iyengar wrote: >>>> >>>> Praveen, >>>> >>>> That was precisely my point about the ecosystem evolving. Now that we = have >>>> the ability to classify flows, various things have been built around b= eing >>>> able to tell TCP flows. This obviously has benefits as you point out, = but >>>> the downside is that that I can't get good network utilization with a = single >>>> flow. I understand the scaling point, but speaking of common cases, an= y >>>> server in the wild is usually serving a large number of connections at >>>> moderate speeds, not a single one at 25-35 Gbps... which makes that so= rt of >>>> scaling less exciting than in a microbenchmark. >>>> >>>> FWIW, the other downside of ECMP is that multipath transport doesn't w= ork >>>> -- you need to hash on something else besides the 4-tuple. (We had to = work >>>> around this in Google's deployment of connection migration.) >>>> >>>> I'll disagree with your point about reordering being the uncommon case= . >>>> While that's true today, this is again an expectation that the network= works >>>> hard to maintain, though the ecosystem and what we expect as "usual" w= ould >>>> be quite different had we not built TCP's requirements into the networ= k. >>>> There's nothing wrong with having n-modal latencies... we can engineer >>>> around that. Any sensible load distribution scheme within the network = will >>>> give you increased variance but it should limit the worst-case latency= . >>>> You'd perhaps agree that that's a net win. >>>> >>>> This was an example of how exposing packet number or not can have long >>>> term ecosystem effects. My point was about the fact that exposing can = cause >>>> ossification. >>>> >>>> - jana >>>> >>>> On Mon, Feb 5, 2018 at 9:24 AM, Praveen Balasubramanian >>>> wrote: >>>>> >>>>>>> This was definitely true for implementations of TCP, but that is TC= P's >>>>>>> problem, not the network's >>>>> >>>>> Flow classification happens through the network and also on the end h= ost >>>>> with RSS where a flow is mapped to a core. This allows for building h= igh >>>>> performance receive processing that could be lock free for the most p= art. >>>>> The only downside of ECMP on the network and RSS on the CPU is that a= single >>>>> flow will not take multiple paths or get processed on more than one c= ore. >>>>> Windows on server machines today can saturate 25-35 Gbps for a single= TCP >>>>> connection before being CPU limited. This is a reasonable trade off = because >>>>> I don=E2=80=99t know of cases where a single flow is driving more tha= n that amount >>>>> of traffic. Assumptions about how flows get classified help make for = more >>>>> efficient processing. They also lead to consistent latency. You do no= t want >>>>> the traffic to take a bi-modal or N-modal paths (on the network or th= e host) >>>>> to being processed because the fluctuations in latency will hurt the >>>>> workload. I am not arguing for TCP not being resilient to reordering = but IMO >>>>> that should be the uncommon case not the common case. With QUIC if st= reams >>>>> were exposed on the network you could take advantage of stream level = ECMP >>>>> and RSS to scale better than TCP but we have chosen to keep the 4-tup= le (or >>>>> the 5-tuple) as the flow classifier on the network which is ok by me = since >>>>> it leads to TCP parity. >>>>> >>>>> >>>>> >>>>> Thanks >>>>> >>>>> >>>>> >>>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar >>>>> Sent: Sunday, February 4, 2018 8:35 PM >>>>> To: Salz, Rich >>>>> Cc: Lubashev, Igor ; Roberto Peon = ; >>>>> QUIC WG >>>>> Subject: Re: Packet number encryption >>>>> >>>>> >>>>> >>>>> Privacy-protection can't be a user choice, for the reasons others hav= e >>>>> noted on this thread. >>>>> >>>>> >>>>> That said, my primary argument is for encryption to avoid ossificatio= n. >>>>> Not that it matters now, but I'll note that much of GQUIC's original >>>>> motivation for encrypting headers was to avoid ossification. >>>>> >>>>> >>>>> >>>>> I'll reiterate that fields we expose will get ossified and there are >>>>> long-term ecosystem effects to this. Let me illustrate this with prec= isely >>>>> the packet number field. Middleboxes commonly assume that a TCP flow = can >>>>> only handle packets in-order. This assumption comes from the fact tha= t TCP >>>>> implementations get poor performance when packets are reordered. This= was >>>>> definitely true for implementations of TCP, but that is TCP's problem= , not >>>>> the network's. However, almost all load-balancers I know of now will = pin all >>>>> packets within a TCP flow to one path, leading to sub-optimal perform= ance in >>>>> the network, and destroying incentives for the endpoints to deploy >>>>> reordering-resilient TCP implementations (even though there are plent= y of >>>>> ways of doing this.) >>>>> >>>>> >>>>> >>>>> Exposing QUIC's packet number field (as any field) is likely to have >>>>> similar consequences and a similar ecosystem arc. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, Feb 4, 2018 at 7:51 PM, Salz, Rich wrote: >>>>> >>>>>> Optional security tends to devolve to non-secure. >>>>> >>>>> >>>>> >>>>> That=E2=80=99s a great aphorism. And sadly all too true. >>>>> >>>>> >>>> >>>> >>> >> >> >> >> -- >> Kazuho Oku > --=20 Kazuho Oku From nobody Tue Feb 6 06:54:06 2018 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 5C6B712D7F2 for ; Tue, 6 Feb 2018 06:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 3rvsvXOLrIBe for ; Tue, 6 Feb 2018 06:54:03 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 B28AC120454 for ; Tue, 6 Feb 2018 06:54:03 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id n206so2735455itg.1 for ; Tue, 06 Feb 2018 06:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=tOjRN0MiG2OnY97f+WLPcRgbZc0icIGmfng7WCpSF88=; b=IrdBrTYGFCSKSHJ5y7UopbYJ0l/Gu+NIzpqLkM3NtMoYmzkkxKq9dXMVV5QINwA7J2 0iGnnrd8TT/YK4BDRkuziUFCzUuR+BjiBamXvQcneTB22UpsZQaAZEQHlwZTU8GR6oI8 arRVGFcf69utCKfn/rA2u9u+8yJb/EgyJFeaErCT92mt+kfMiqxeLECRxSDIwdN/jaqz 7bWq0rQcPLPjEB0dXGML0E7DdQAXS8JQw9CuW+2HcrybCtng9EFgz2MPxC3UiE5C7w7a Jd4uVai2EOYbyTUfLahSkq6P1TLNPU49FFfA/1zEE7FiN+ZBca1O3JP6ovrM1ZwRLJ23 ymRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=tOjRN0MiG2OnY97f+WLPcRgbZc0icIGmfng7WCpSF88=; b=nW2YPUh68UdW/hPWvsxXnZba2wtYjaUj2PxdQqJIre7SM0dqD4LMMK9dt7ev+0lChi UC5VoVsuxECXoHKonhWdc6KDppndLObAhfuoxrkFLnXRDDTJ0/d5mOwXqEANDCe6XabI i43jmipq47TAXUJWJvBNf0XKwh7O15LD0aOa/hIug74xonm4V7oD6VVqclp/E3tuRETT 0IblzugdjR87QvcLkx88bb3gozDgvLwFRf/F8FptuMv12l8LV31/qtgudoJBt+2R8QRD XXLpjSTKOQuELWDrJs6nOvkraG/5aHpeaglMkdxSuFKzUJTjxNXiw9FPH69ouGGHMKFI +0gw== X-Gm-Message-State: APf1xPBYRVgQIgWfupxaaVTnmwPo323mlAEw1/zNMyPxGHqUfwd5gSKV OzcRPZ8a2odMeqXnWUhc7u9XDQSFbimLLqBVtFhQZQbw X-Google-Smtp-Source: AH8x227gm4m3LgZDSS2+uQGtVGCdTFE03NDGRwytgQ+NP227oCwOAfencb9QbkXImIKbBQP3qYAWPd5ixQ5oDCgxR+0= X-Received: by 10.36.131.194 with SMTP id d185mr3545298ite.31.1517928843074; Tue, 06 Feb 2018 06:54:03 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Feb 2018 06:54:02 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 6 Feb 2018 06:54:02 -0800 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: "Brian Trammell (IETF)" , Kazuho Oku Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0496527c626305648c59bd" 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, 06 Feb 2018 14:54:05 -0000 --94eb2c0496527c626305648c59bd Content-Type: text/plain; charset="UTF-8" > Sender exposes one bit per packet that can be observed by on-path > devices. The bit is flipped for every 256 packets that the sender > sends. Observer records the bit of each packet as they pass by. This is a pretty cool idea, but it doesn't provide enough information to protect the spin bit from reordering. This could be easily fixed by moving to a two-bit spin, as Gorry (I think) suggested. Among other things in this space, Piet's also looking into how much reordering information could be extracted from a two-bit spin itself. This idea can be taken further: You can modulate the signal so you use multiple packets to encode a zero or a one for half the wave duration. For example 1 could be encoded as 0101 over four packets and zero could be encoded as 0011 over four packets. If there is any reordering, it would show up as an unexpected value in the pulse. --94eb2c0496527c626305648c59bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
> = Sender exposes one bit per packet that can be observed by on-path=C2=A0
> devices. The bit is flipp= ed for every 256 packets that the sender=C2=A0
> sends. Observer records the bit of each packet as = they pass by.=C2=A0



This is a pretty cool idea, but it doesn't provide eno= ugh information to protect the spin bit from reordering. This could be easi= ly fixed by moving to a two-bit spin, as Gorry (I think) suggested. Among o= ther things in this space, Piet's also looking into how much reordering= information could be extracted from a two-bit spin itself.=C2=A0


This idea can be taken further: You = can modulate the signal so you use multiple packets to encode a zero or a o= ne for half the wave duration. For example 1 could be encoded as 0101 over = four packets and zero could be encoded as 0011 over four packets.
If there is any reordering, it would show up as an unexpected value in the= pulse.
--94eb2c0496527c626305648c59bd-- From nobody Tue Feb 6 06:54:57 2018 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 061D812D7F3 for ; Tue, 6 Feb 2018 06:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 Fja_hgy5KfhA for ; Tue, 6 Feb 2018 06:54:53 -0800 (PST) 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 49F9412D7EC for ; Tue, 6 Feb 2018 06:54:53 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id v196so1472241ywc.6 for ; Tue, 06 Feb 2018 06:54:53 -0800 (PST) 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=Kln2TnWxkIX7Qldl8eu/p2FjUEBqj3bkqNqAvXR484k=; b=aRxobFcQq972UWs/3AP7MJB45QoG9PePMzsstbZKRf9Dz7F1xiJP29YSpY2TF781tX TfVrasfwxMX7cERhBEl65FsF3NHTVlW0TEsQXlP933jLLzonLotNPSdjVVxIbDmX3UJT trYphDHos06yBQcpxTOnWITAGg+trat4UD8kLjIF2SQHmofux3apIVJHZmyt/qxcRxmy OQxqNzjRl9MG0uBgzMe6vcvFd5VPtVYOAGVxw7xodIDuE7/rLcAODY/CSV48KwsAKH55 hmj24d6AivnmvSGFnisz4udUf6gdOqkIVUP0CzDhsMkfUjf0b3ZokXCxXawN8XUlzNNy f5vw== 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=Kln2TnWxkIX7Qldl8eu/p2FjUEBqj3bkqNqAvXR484k=; b=nD/QIrTySdOlgZitmJX3AF0VB7UA86T2ewTSIegtp0k2/lTKqo3h/gTvNnr53aeDzx W1aN3bn4bCijcvqWB2mZ5XRSIi7wwietx/20MwV/z3yXjqfMUurlpPFX6g91rFSWngH6 KXrGpesFDma3uTNBV/y2YWJjcgMvvRCa/miDIAqa4i8E85SBuwTGVKH+r/q5/TLhGrHw bJwMQuy0tXww2weMR2HB3iyv/BH9M/tcmN0DcD4X5bnA5oKVu4eEtL3V/nYKdBemUgRB dQ57PpODFHqFpPvnQKpOwqJv+BPi4c7tSO+C+5PxTNCMZoznYImnqkQdC95YTOx/WzQe 8+xg== X-Gm-Message-State: APf1xPDpKcvZknytwEJNXaYVGmbEU8i6nZzb5andfJW06UN1FlqUYDj9 vMXX+Xutw8K2pzl08+a6HtPpqfHHsHgcQcvfQhk= X-Google-Smtp-Source: AH8x226Jt5oU9D9F0qESgb38m66/2mPMidEV+M3Oul0OC8qAs/OA46NCh+sI8BPmzzpsSdmJK+vpAcc2awRmXIMrvJQ= X-Received: by 10.129.87.2 with SMTP id l2mr1543394ywb.454.1517928892169; Tue, 06 Feb 2018 06:54:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.21.201 with HTTP; Tue, 6 Feb 2018 06:54:51 -0800 (PST) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Tue, 6 Feb 2018 08:54:51 -0600 Message-ID: Subject: Re: Call for Adoption: Invariants To: Mike Bishop Cc: "Brian Trammell (IETF)" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Lars Eggert , Mark Nottingham , QUIC WG Content-Type: multipart/alternative; boundary="001a113a3c4e6982e605648c5c50" 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, 06 Feb 2018 14:54:55 -0000 --001a113a3c4e6982e605648c5c50 Content-Type: text/plain; charset="UTF-8" Asking with no hat, but ... On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop wrote: > I support adoption. The way to change the invariants will be to mint a > new protocol, and not claim that your new protocol is a version of QUIC. > If it happens to be startlingly similar, all well and good. If you roll a new protocol, that's not a version of QUIC, is it obvious to everyone but me whether you can run both protocols on UDP/443? I thought I remembered that UDP/443 was chosen because firewalls often pass port 443, so that aids deployment. Hence, my question. Thanks, Spencer --001a113a3c4e6982e605648c5c50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Asking with no hat, but ...

=
On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop <mbishop@evequefou.be> wrote:
I support adoption.=C2=A0 The way to change the invariants will be to mi= nt a new protocol, and not claim that your new protocol is a version of QUI= C.=C2=A0 If it happens to be startlingly similar, all well and good.

If you roll a new protocol, that's not a vers= ion of QUIC, is it obvious to everyone but me whether you can run both prot= ocols on UDP/443?=C2=A0

I thought I remembered tha= t UDP/443 was chosen because firewalls often pass port 443, so that aids de= ployment. Hence, my question.

Thanks,
Spencer
--001a113a3c4e6982e605648c5c50-- From nobody Tue Feb 6 07:09:22 2018 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 1C63912D7F8 for ; Tue, 6 Feb 2018 07:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 L94eDGRHG1j6 for ; Tue, 6 Feb 2018 07:09:18 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 4EF551243FE for ; Tue, 6 Feb 2018 07:09:18 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id 25so2794884ioj.9 for ; Tue, 06 Feb 2018 07:09:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=yEQpjHDdwhhgsnJXPMLpURwNeKfRu2PYC1V5z59hUqI=; b=eq30si0evv1EBpE7+j1BodCfdCB6CDvFYwTKG5F0dz7w+OZWhT+9EXyzav1ZtSC/8f utpVOVsouhxK1PdCgoswrjFjUXWU9J6i5KtV+/Ql/BgyPIsEvbhKD3CbtNHD5vB+f97q VZZo4IU+9BJYrf+c8x3WqYF+rQwitFNVuRUNMHduhjHN3+gjzCFk6TCUji3OqhKOeS63 +a7cWRBMU7RJ3T/4eCx4syzepwYQsKNxqvk/XBqTIXDj/ccfRybU2qh/3HTOUsHOhDJg dC/E1KwrPhegbJObjGk+ooGM3oBD4Lofro9IwdyD9lJgiNQXD2vpGiw0jD05iLzfl7Z6 5VLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=yEQpjHDdwhhgsnJXPMLpURwNeKfRu2PYC1V5z59hUqI=; b=mJNqB6rgsVANemMHbzASxOnnWbavtSmocAIDHxyFji/YejLVdke4M6tei9UFUas+Ex HP9hqUHMiwoZBqAt4QBDYGScVGBPaFAgP2wkwLZnKlOPlklWzXbIb59ZdD7BCGR53dnU oWLrrJok0SXUSWl5CEBuGj8owIKfylhfq2EUkMP6w/X06ghV07u9r+lbky7bmLh/MSm0 Hn4n/O5PLm8c2I8RzCDdi1/5cLGD0bfG5MotccFxd9Rk2g0sx3DhTqLYLdhxGQ182NaF fowpOIm1VvlU4Zvfiaz/1Q2Cw+LnbRqMUTEPiFjc9VLhfYKrjeYc+ucEPlHvJIbOblvI N35A== X-Gm-Message-State: APf1xPB/Ly0CfUE3kgzIsHIVcCtPud1Q3dicEYnv3wvyX/irl6zTRKoy PooHdeooTINbGX9bnQYByUwj2auU3RTDeTysysY= X-Google-Smtp-Source: AH8x2257xf98BsH7unQIrltZLPrNZ4cDipos6jcqb0tLBiH+Q/drg/rU/q+/d9nkUZlRjpNIU0aqfuryeXSkNWrfNm8= X-Received: by 10.107.168.25 with SMTP id r25mr3288183ioe.16.1517929757737; Tue, 06 Feb 2018 07:09:17 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Feb 2018 07:09:17 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 6 Feb 2018 07:09:17 -0800 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: "Brian Trammell (IETF)" , Kazuho Oku Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a11427bca01162c05648c90ee" 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, 06 Feb 2018 15:09:20 -0000 --001a11427bca01162c05648c90ee Content-Type: text/plain; charset="UTF-8" This idea can be taken further: You can modulate the signal so you use multiple packets to encode a zero or a one for half the wave duration. For example 1 could be encoded as 0101 over four packets and zero could be encoded as 0011 over four packets. If there is any reordering, it would show up as an unexpected value in the pulse. You can take it even further and add error correcting codes into the sequence. Or likewise, you could generate a known random sequence such as PI, or perhaps simpler, an AES generated sequence. It is easy to sync the signal by hashing bits from multiple packets and therefore easy to detect any missing bits. If there is massive loss, a binary search can be conducted to find the location of the surviving packets. It sort of breaks down if every other packet is reordered but you could still handle that with some consideration. The signal could repeat with a period significantly larger that practical RTT rather than running an infinite sequence. Technically it would also make it possible to remove the packet number entirely because the number can be estimated by end-points and trial decrypted, but that would likely not be performance optimal. --001a11427bca01162c05648c90ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
This idea can be tak= en further: You can modulate the signal so you use multiple packets to enco= de a zero or a one for half the wave duration. For example 1 could be encod= ed as 0101 over four packets and zero could be encoded as 0011 over four pa= ckets.
If there is any reordering, it would show up as an unexpec= ted value in the pulse.


<= /p>

You can take it even further and add error correcting codes into the = sequence.

Or likewise, you could generate a known random sequence suc= h as PI, or perhaps simpler, an AES generated sequence.

It is easy to= sync the signal by hashing bits from multiple packets and therefore easy t= o detect any missing bits. If there is massive loss, a binary search can be= conducted to find the location of the surviving packets. It sort of breaks= down if every other packet is reordered but you could still handle that wi= th some consideration.

The signal could repeat with a period signific= antly larger that practical RTT rather than running an infinite sequence.

Technically it would also make it possible to remove the packet number= entirely because the number can be estimated by end-points and trial decry= pted, but that would likely not be performance optimal.

--001a11427bca01162c05648c90ee-- From nobody Tue Feb 6 07:15:11 2018 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 F293B12E76A for ; Tue, 6 Feb 2018 07:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 89OAkXGWa67Y for ; Tue, 6 Feb 2018 07:15:09 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 790721243FE for ; Tue, 6 Feb 2018 07:15:09 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id m11so2837937iob.2 for ; Tue, 06 Feb 2018 07:15:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=jvAVp6lR5fMHnx17StKI8f06PsJplTYNysm/Grqy4yc=; b=srSbop893nb30HpE/LoYFc3aFRzPd4ibLIoN7SUtqbbuV80dsiDnCM6sXwFCxya/Bz kf6a2lbv6xfX7M34cvxpyYXiUJ5UYjCRD7nxS8TWxzYW6rHEvrEfwoKJxXYvZhylJs3a 7TJuH6N/zfADXvWHp6GX1cqNDWCq9vE/ja/jfTomS/Hez1ZLSgyl0WH9tWi1gyZtkDP0 AHBUTg9mnVKKWpGqcg2czWqEZHzEDy8jVFIGm1rqBKaBCSwVpE7lCCSg1oChyA3bKjFy 44lUci4BBcyhgOoV5DA+hp6sPrTDYqlsOZ/wl0neO+8FMlCQYq7pxQBiKaUiYEpx2WeP xpYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=jvAVp6lR5fMHnx17StKI8f06PsJplTYNysm/Grqy4yc=; b=M45WiuNdIgO8Xp80r8IlQPxVx9uZ8zAMNLazPF+Advq9E80yrGJ0qb4u8a6NzNic2V oifTUmcWyX6FxpdTkUWjsnLxJ5u/jT5A7UeAjdWlYMkOjjZqQyRWUDvz/5rRPFUjxOgS h/fpSMq7e118Jx+jdO4r4I5Bmg+QL+NY9TdbXXUqJ3ew3Fo1n2d1Z51iojtywtQ4+AYF YhB+L7QsfoCoHnTcao3ZL0eQy7Ih1k3+LcnrEgSd4xOnPxbdt3Z6GylOHZI+QehNP/Sp Ps66ldF6AAkgHVmdCn9FJQGD5R8fpaRTL4NZF34E/af7wI8C8STUegKn2NBOHZqk7iuo gYaA== X-Gm-Message-State: APf1xPDOAtAtCvv/5CxDMzJVuh9GTcJ5A6u55Buw/HV3Npre4RLjgEHM nKeNCDy7/cNyH4F2QCTpX+7aMC8kaSQEyDYCkDSIyVIw X-Google-Smtp-Source: AH8x227ov7lpldy4TaajibuID+ZXCasTYU9Arqo9qldgpSpQQoio/sns/fuvF6rWE4vIeLfhsge2Qlc4TFxuFzPhMqY= X-Received: by 10.107.140.207 with SMTP id o198mr3258839iod.175.1517930108975; Tue, 06 Feb 2018 07:15:08 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Feb 2018 07:15:08 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 6 Feb 2018 07:15:08 -0800 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: "Brian Trammell (IETF)" , Kazuho Oku Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c05a3ecf080b905648ca4f9" 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, 06 Feb 2018 15:15:11 -0000 --94eb2c05a3ecf080b905648ca4f9 Content-Type: text/plain; charset="UTF-8" Or likewise, you could generate a known random sequence such as PI, or perhaps simpler, an AES generated sequence. Such a signal would work against privacy unless it restarts with each new connection ID or it is keyed by connection ID. --94eb2c05a3ecf080b905648ca4f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

Or likewise, you could generate a known rando= m sequence such as PI, or perhaps simpler, an AES generated sequence.
=


Such a signal would work against pr= ivacy unless it restarts with each new connection ID or it is keyed by conn= ection ID.

--94eb2c05a3ecf080b905648ca4f9-- From nobody Tue Feb 6 07:23:43 2018 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 B32C712E3AE for ; Tue, 6 Feb 2018 07:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 SzRV2hzapJrk for ; Tue, 6 Feb 2018 07:23:39 -0800 (PST) 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 E33C51201F8 for ; Tue, 6 Feb 2018 07:23:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zbSsP1R00z15NBR; Tue, 6 Feb 2018 16:23:37 +0100 (CET) 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 OKuutTopLneA; Tue, 6 Feb 2018 16:23:36 +0100 (CET) X-MtScore: NO score=0 Received: from [82.130.103.20] (nb-10688.ethz.ch [82.130.103.20]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 6 Feb 2018 16:23:35 +0100 (CET) Subject: Re: Packet number encryption To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "Brian Trammell (IETF)" , Jana Iyengar Cc: Praveen Balasubramanian , QUIC WG , Roberto Peon , "Lubashev, Igor" , "Salz, Rich" References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> Date: Tue, 6 Feb 2018 16:23:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------F3C14726B3277BC581C87660" Content-Language: en-US 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, 06 Feb 2018 15:23:42 -0000 This is a multi-part message in MIME format. --------------F3C14726B3277BC581C87660 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi all, On 06.02.2018 14:35, Mikkel Fahnøe Jørgensen wrote: > > If the argument is for ossification and not privacy, I think the > encryption is the only option as Marten has pointed out. For this reason > it makes sense to apply crypto. Low-latency systems could create a QUIC > variant that drops the packet encryption. It's also my understanding that we do agree that packet number encryption does not help likability (and thereby privacy) a lot, or at least that the benefits we might get (or not) do not justify the additional complexity. So let's talk about ossification. I'm also not certain yet that the additional complexity (even thought it is low; and I'm not only talking about implementation complexity but also the effect for someone new to understand the protocol and the spec) is justified by the fear people have about the big evil called ossification. And my point really is here that this is driven by a fear about things that theoretical could happen in the future and less about that the experience we have. Yes, we should be really careful here; that's definitely a lesson learned. And yes, I do understand well how painful and extremely said it was to see how quickly guic ossified. But we really need to look a bit deeper into what happened and why, e.g. what does ossification really mean and what do we know about it to handle it best. In case of guic, there was a presumably fixed bit pattern at the beginning of each packet that was used to classify traffic as being guic. So I think one thing we can learn is that for a field that is not supposed to be static we should try make it not to look static (I guess the solution here are not exposing it or grease it; in general I do prefer the first option). However, the other apart of the question is why did this happen. The answer is because the network needed a way to classify guic traffic as guic. If we don't provide an easy way to identify guic traffic (where currently the only way is observing the handshake but that might be fine; we'll see), the chance that other information is misused for this purposed is high (and this information could also be a certain traffic pattern that is usually observed with quic, compared to other UDP based traffic; or a certain port number...). Alternatively, if there is no way to distinguish quic from random spam that is also based on UDP, I can actually imagine a future where the easiest way out is to block all UDP because at least for quic with its current use case it will likely fall back to TCP anyway, so no harm here, right... expect for all the other protocols that want to use UDP encapsulation eventually, but the we can still use TCP an encapsulation... or something like this... maybe. So this might be only my imagination of an alternative reality but this is a different kind of ossification that can happen in the Internet if we do the wrong thing, and I think that's the alternate reality I'd really like to avoid! So let's see what we really know about ossification so far. I think the big lesson we can learn from TCP is that we need to be selective about what we expose to the network (also for privacy reason) but the other part of the lesson is also that using TCP header information for network monitoring (that have been exposed accidentally) has been a great win. Without the tools we have today, we would know less about the Internet than we already do and it would be much more effort and potentially economically not viable anymore to manage the networks we have have build with it current complexity. I'm all in for privacy and that's also a lesson learned, but I would really be disappointed if end up designing a protocol that would not be based on the things that we know have been good about TCP and just ignore that part. Coming back to the packet number (and closer to this reality). Guic has been exposing the packet number for a long time now and this didn't cause an ossification problem. Yes, they presumingly didn't try to change it (actually I don't know that) but it is used (if at all) also in a different way than the flags field and for a different purpose. The packet number is a field that is increased on each packet. So if that is what is observed in the network and assumed to be mechanism then that's correct (different than the flags field with was assumed to be static but was not). Further network monitoring devices will likely use the packet number field for measurement but will not block the traffic if they don't find what they'll expect. So to sum up, yes we need to consider possible ossification that can happen for all information we are going to expose (and I do mean all! including traffic pattern, packet sizes and timing). However, the conclusion from the past for me is not to not expose any information. It has proven of high value if information for network monitoring are available to the network, and the spin bit has show that it is possible to expose these information without a privacy impact. I do not see any evidence that the packet number is likely to ossify in a way that would hinder future protocol deployment and it will not increase likability, therefore I do think not changing the protocol and keeping the packet number as it is, is the best and easiest solution. However, if people really think it's better to encrypt the packet number, we must provide other measures for manageability. Sorry for this long mail but I am very worried that the fear we have about this big evil word ossification is driving us into a wrong direction and we really should consider the different cases more separately and in detail. Mirja --------------F3C14726B3277BC581C87660 Content-Type: text/x-vcard; name="mirja_kuehlewind.vcf" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="mirja_kuehlewind.vcf" bnVsbA== --------------F3C14726B3277BC581C87660-- From nobody Tue Feb 6 07:25:12 2018 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 8109212E852 for ; Tue, 6 Feb 2018 07:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 GoMUIjqvuOzj for ; Tue, 6 Feb 2018 07:25:06 -0800 (PST) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::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 BE61A124BE8 for ; Tue, 6 Feb 2018 07:25:06 -0800 (PST) Received: by mail-it0-x241.google.com with SMTP id i144so2940599ita.3 for ; Tue, 06 Feb 2018 07:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=i2cmnlpNrsEKxRf8qY5OPqmM28LnM8iS29HpyRVONH4=; b=k4+YBsYxfwlTTL8V+LNTHdDF5/0aJ0k+GXpBmvjckYNRvWWYrTpGmu8PvoAuoANzVa eD+eSU2GDrVnaoZsk9ecVP1+fZoYlq6qCiBFGTVmiHynzouWrRre/q2PDRykjTIFA1z3 akrgsiV723AhEcXKzpWbsBaSxnqNCsSvN8B5X9/Hp8NLH+Kj9E7KICZA6Tr2doipQtYi bBFbciFC84diWk7wNgwLDQ7PE30J5ANm+28Moy6CP2jZHjqdKXYaegQaoaNAkSb/BPfO XU4nhAt4Z/7S7ng7RzWapQ//YZvZQZ4jnqSJJJKubnxYKPCIgoo4FYOEbvyGQh0/r2eH nv3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=i2cmnlpNrsEKxRf8qY5OPqmM28LnM8iS29HpyRVONH4=; b=Nw3JI/Jsfkl/XiswlrcJmN6nkldf1yib6Qcf0qsAcZ5mmzJdFC2dD5tFc3dhc8+knc EjjymffjrjQW3guWCmF4ht1OygSZsLDBPrfnKo8y+1M9ZDaiy49CmxRxncTV+vpm8HAv Uxs0R1Byq1P621WgGSgQ6Ncb54mnErJ4INfTwqKNMJq+WaaH6ilzzp7TNnF8q1D767qS +IE9P6oXbRlZYSLR7pvNImASKhYxsmw4R0YqhKUbr0cleOhv4WV+SlEm4iycmwMNR01u TyrYFUEcQpK4esReCjcYqNqrVX7EBDMfThVZ9hoc3Az92AQJDfyLMO8u8Wm2AD09Mhq2 1peQ== X-Gm-Message-State: APf1xPBQ2iE4tmCLuryuZdou7PUb4U+bIn1dqaQMF2HNABMIuk7uxT8U SFhiyCeG0VztsUbsCvJ+BfO+esmeQlrCfgpbo0A= X-Google-Smtp-Source: AH8x2244mhC/hZC1DB9J0rGmEJBm3o8/R66PhO1ggtVpCoRSNV+9D6hIw3aBbaxT8Wo6jyZWQZh0BU2WebV6YBAE5e8= X-Received: by 10.36.178.26 with SMTP id u26mr3443450ite.4.1517930706252; Tue, 06 Feb 2018 07:25:06 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 6 Feb 2018 10:25:05 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 6 Feb 2018 10:25:05 -0500 Message-ID: Subject: Re: Packet number encryption To: "Brian Trammell (IETF)" , Jana Iyengar Cc: Praveen Balasubramanian , "Salz, Rich" , QUIC WG , Roberto Peon , "Lubashev, Igor" Content-Type: multipart/alternative; boundary="f403045d914c8a384a05648cc86e" 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, 06 Feb 2018 15:25:08 -0000 --f403045d914c8a384a05648cc86e Content-Type: text/plain; charset="UTF-8" The overhead of packet encryption (single block AES-CTR) is probably around 100 cycles with AES-NI and possibly 160 cycles table based for one block for Intel arch. This is because parallel multi-block optimisations are not possible. AES-CTR of one block is about the same as AES-CTR of 4 blocks, and GCM auth tag adds perhaps 50% to that. Thus packet number encryption might be twice as fast as AES-GCM of a 64 byte message which is still a 50% overhead. The overhead could be reduced by generating an AES derived random byte sequence and store 8 bits from the sequence in each packet. The sequence can be efficiently precomputed for 64 packets at a time. A simple lookup table will tell the packet number with high probability, and if it fails, it is possible to extend the search. Details could be discussed, such as using 12 bits instead of 8 etc. This requires fewer header bits on the wire, is private, ossification resistant, and fast. --f403045d914c8a384a05648cc86e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
The overhead of packet encryption (single block AES-CTR) is proba= bly around 100 cycles with AES-NI and possibly 160 cycles table based for o= ne block for Intel arch. This is because parallel multi-block optimisations= are not possible. AES-CTR of one block is about the same as AES-CTR of 4 b= locks, and GCM auth tag adds perhaps 50% to that. Thus packet number encryp= tion might be twice as fast as AES-GCM of a 64 byte message which is still = a 50% overhead.


Th= e overhead could be reduced by generating an AES derived random byte sequen= ce and store 8 bits from the sequence in each packet. The sequence can be e= fficiently precomputed for 64 packets at a time. A simple lookup table will= tell the packet number with high probability, and if it fails, it is possi= ble to extend the search. Details could be discussed, such as using 12 bits= instead of 8 etc.

This requires fewer header bits on the wire, is pr= ivate, ossification resistant, and fast.

--f403045d914c8a384a05648cc86e-- From nobody Tue Feb 6 07:35:34 2018 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 64E3412D7FC for ; Tue, 6 Feb 2018 07:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 2hSpleJJmOqF for ; Tue, 6 Feb 2018 07:35:30 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F008C124BE8 for ; Tue, 6 Feb 2018 07:35:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7EE6ABEB3; Tue, 6 Feb 2018 15:35:28 +0000 (GMT) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxd5MqohjSff; Tue, 6 Feb 2018 15:35:28 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 36DC9BE80; Tue, 6 Feb 2018 15:35:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1517931328; bh=EKlnE56Eu5QOeMqGtYw4xwyy7b15lLN4kUtB7tPXZ5M=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=XVPkWF0sHOddipeWLcXrtNtg+5zRdzobdVvAtKmflcBYzv8XmJS1SBfgMALBYRD4U YKDaLgWLYcSk8dt5NW3g8eHUqXYei1BF1nO3b5MfknLxEUKqGueBBEkOB/O4i2ZiZ7 HGSQ0eRZuGWPbmwWpfzB4RjXOC9JDEm+aFsKGuFs= Subject: Re: Packet number encryption To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "Brian Trammell (IETF)" , Jana Iyengar Cc: Praveen Balasubramanian , QUIC WG , Roberto Peon , "Lubashev, Igor" , "Salz, Rich" References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Message-ID: <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> Date: Tue, 6 Feb 2018 15:35:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="qhUDrMPnlMpmfpNvsfvgKEZWoqxjhwM0P" 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, 06 Feb 2018 15:35:32 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qhUDrMPnlMpmfpNvsfvgKEZWoqxjhwM0P Content-Type: multipart/mixed; boundary="wuYr5IX8yGvgx1ZPkHQQaPVzIggrXz4aZ"; protected-headers="v1" From: Stephen Farrell To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "Brian Trammell (IETF)" , Jana Iyengar Cc: Praveen Balasubramanian , QUIC WG , Roberto Peon , "Lubashev, Igor" , "Salz, Rich" Message-ID: <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> Subject: Re: Packet number encryption References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> In-Reply-To: <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> --wuYr5IX8yGvgx1ZPkHQQaPVzIggrXz4aZ Content-Type: multipart/mixed; boundary="------------86679E1F314C22DCA298C596" Content-Language: en-GB This is a multi-part message in MIME format. --------------86679E1F314C22DCA298C596 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06/02/18 15:23, Mirja K=C3=BChlewind wrote: >=20 > It's also my understanding that we do agree that packet number > encryption does not help likability (and thereby privacy) a lot, or at > least that the benefits we might get (or not) do not justify the > additional complexity. FWIW, which isn't much, I don't (yet) agree to the above. I reckon it'll be a while before we know how linkability pans out. I do agree that packet number encryption is not a panacea for unlinkability, but it may help, or may even end up being required, to do a good job wrt linkability. I also heard people say it was less complex for them so "additional complexity" may also not be quite right. (I guess "differently complex" is correct though.) S. --=20 PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --------------86679E1F314C22DCA298C596 Content-Type: application/pgp-keys; name="0x7B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x7B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3Dg8yx -----END PGP PUBLIC KEY BLOCK----- --------------86679E1F314C22DCA298C596-- --wuYr5IX8yGvgx1ZPkHQQaPVzIggrXz4aZ-- --qhUDrMPnlMpmfpNvsfvgKEZWoqxjhwM0P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAEBCAAGBQJaecs/AAoJEFqy+vF7Fyvq/3oP/2f+4Fe5MEiEmru8Gqsb2if3 SuZQU9Jv3yDcW0UmXU6bKHk8CE7UjfgpHpUM0a8+BpIIGdpn0KyiwynnaLhgecKq /nf2itdxm6Pky8BXHjwDbk7jww5Ppz9QG2gsi9Fxc4gPdoos00GZstof1dyRIXxD JlnR+pLEQimRREAYvNJCjSYu8r9Cks1CIVuHIZicXoEkUFn9wpEV26OWqhiovH0P CnrLJL5LUr+oKszh80pL8bGrHp+eXtiUwM3OYlBK5Klv0G83gydVXaknNyAyOfad A3jAQfZCPb4crby8x43Zj6/+VN2yxFyPqPrcrgsgBNKRmmqUJamDhfMMEJ5DLtro vrRQ3AYCjhBuCBMByudiUP3H5DeQk3xtAnHFx25laWnUTDUAhs9M8GXpqTDJXOc6 bLapQEM4refKo/HnYHFBzRc7toVQhe8ye3iuzgep69yUqKQcDB/At75sMfWeLq1F hPCXiVz8+j8/BY+B98nixELLr1wn+Xu9MhTgI4kfR1v2aqQ8LZk0qb0vZ41Xr3Im 1APdPwnYn6QaHGk+SLc6HMtnu1GlcVf7ljRBSxT89zOKmy3/485cDnHVQSQWEpBP A1FGxy8QmZnHfW6/83D+yHIw8YnX3w3aQwq++lfonxfZB5/zIrMohgDYdUuR7eBC GQaJnU6kYJufRNAxwFT0 =KODH -----END PGP SIGNATURE----- --qhUDrMPnlMpmfpNvsfvgKEZWoqxjhwM0P-- From nobody Tue Feb 6 08:22:39 2018 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 3670F12E87F for ; Tue, 6 Feb 2018 08:22:38 -0800 (PST) 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 dlHuYE5s-UF5 for ; Tue, 6 Feb 2018 08:22:36 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 CD3FE12E87C for ; Tue, 6 Feb 2018 08:22:36 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id k5so816991pff.3 for ; Tue, 06 Feb 2018 08:22:36 -0800 (PST) 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=xLZyoBECwZ0XHuGZ+j3l1ejUdW8iDYO78PfeYqrq1BE=; b=o/d8x9ZCozJzDwmVpBCk8MUvRzjWXXOp32DiQ+4iCY7fLhkYCsq1cO9S+PpEa8ZsEJ 1RDcOAGaKNWya9mhFoNez3D+MT+gGyABwZiAmW9zUeM++xGHI0mPeVWPDd5FUKO8zKly FuXZrCB44oSLUweVoYlEe4QyWz4YDdt+gVcjvQU04dbU0FYU5mGuwPNwXvzJuSDbOjRy M1xJsVBtWwPAWlAjW2LsXrqfm4nw4PnV28M55y+9MzlV2Oqs01bSKXQonqzcVi7XXWiI Km5EzUOlC+MTjCDZmuZFLz/BUIkthxMKU/4e8KvZ5p7mlKTyJ5urF7FFXOqSPvHjU/kr q/Lw== 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=xLZyoBECwZ0XHuGZ+j3l1ejUdW8iDYO78PfeYqrq1BE=; b=I8r/TW33cClWOvgtMm1eBOQdqCNEIj6oTz9YcF296diIc0OdY8PEvxZuB/1BKk8RZl VIIijl0xEyPSkkAiv5qRlYd6nxLlUhaZ7yMk9apZM8nj8U6cpjm1v+AHgWRc9UpaJ5+M 6oImFhRC7wvFSnDOyIs3nWYuuXS3ZIail+wlZovXCk7WjStaR23jYlrBqbXE8sGbNOR0 TxVJJo4tcspbm2pYi14tI3xStvu83W1OJACRBnH2unerMGqsnNJ7flHiPTMFpoWJQq56 r/2rJMwAgXPUTXvLrscb5AeL3GlJbgHtkGV9cIiryO5lX+p3y4dVpOmUvXbvvFNdGyR9 s2lw== X-Gm-Message-State: APf1xPCw5A05a9oJmoGJsM/cmo/MIcvkQqOXWESZGOBtmgUoqInoS1TT fZwr/r9HwJ52RoQxbTAjXFB8fp0dsNh1x+tQCfQ= X-Google-Smtp-Source: AH8x224AxJGhqCmcE7gs7veZooKixVM7/J8b74jqZVcdeZqHBaoSyRDghGtcAbrsMJRV8La8T7KS502gzv7pv0mmzzQ= X-Received: by 10.98.19.19 with SMTP id b19mr2979772pfj.118.1517934156330; Tue, 06 Feb 2018 08:22:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Tue, 6 Feb 2018 08:22:35 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> From: Kazuho Oku Date: Wed, 7 Feb 2018 01:22:35 +0900 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: "Brian Trammell (IETF)" , 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: Tue, 06 Feb 2018 16:22:38 -0000 2018-02-06 23:54 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen : > This idea can be taken further: You can modulate the signal so you use > multiple packets to encode a zero or a one for half the wave duration. Fo= r > example 1 could be encoded as 0101 over four packets and zero could be > encoded as 0011 over four packets. > If there is any reordering, it would show up as an unexpected value in th= e > pulse. That's definitely an option. Actually, I considered using sin wave (that distributes the error among 1-bit samples) as an example instead of the square wave. The primary reason behind my preference to using a square wave is that it is easier to implement; in fact, emitting a square wave with the length of 512 packets is as easy as just taking the 9th bit (counting from LSB) of the packet number (if we forget about the gaps for a moment). --=20 Kazuho Oku From nobody Tue Feb 6 08:36:45 2018 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 63A5312D84F for ; Tue, 6 Feb 2018 08:36:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, 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 tIR5I0qYByLX for ; Tue, 6 Feb 2018 08:36:42 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 A69AD12D838 for ; Tue, 6 Feb 2018 08:36:42 -0800 (PST) Received: from MBP.local ([IPv6:2620:11a:c081:20:bd85:ba9e:7eba:e9b5]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w16GaVkx052008 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 6 Feb 2018 16:36:31 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:bd85:ba9e:7eba:e9b5] claimed to be MBP.local Subject: Re: Call for Adoption: Invariants To: Spencer Dawkins at IETF , Mike Bishop Cc: "Brian Trammell (IETF)" , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , QUIC WG , Mark Nottingham , Lars Eggert References: From: joel jaeggli Message-ID: Date: Tue, 6 Feb 2018 08:36:25 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4F159B70308CAB01AAA78B1A" Content-Language: en-US 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, 06 Feb 2018 16:36:44 -0000 This is a multi-part message in MIME format. --------------4F159B70308CAB01AAA78B1A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/6/18 6:54 AM, Spencer Dawkins at IETF wrote: > Asking with no hat, but ... > > On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop > wrote: > > I support adoption.=C2=A0 The way to change the invariants will be = to > mint a new protocol, and not claim that your new protocol is a > version of QUIC.=C2=A0 If it happens to be startlingly similar, all= > well and good. > > > If you roll a new protocol, that's not a version of QUIC, is it > obvious to everyone but me whether you can run both protocols on UDP/44= 3?=C2=A0 > > I thought I remembered that UDP/443 was chosen because firewalls often > pass port 443, so that aids deployment. Hence, my question. In my experience as a vendor of and consumer of commercial firewalls. UDP and TCP port numbers receive separate treatment. So a decision to pass TCP 80/443=C2=A0 or UDP 443 would be undertaken independently. Outgoing UDP through a stateful NAT/PAT tends to create state for a binding which will be used to map incoming packets with obverse 5-tuple to the original sender. unsolicited incoming UDP (for which no binding or rule exists) will be dropped. There is the complexity with UDP of determining when you can remove the state since connection oriented signaling may well be (is) opaque to the stateful device. if you have to fall back to a timer or some kind of LRU policy for state entries you will tend break long lived flows that don't use keep-alives. > Thanks, > > Spencer --------------4F159B70308CAB01AAA78B1A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 2/6/18 6:54 AM, Spencer Dawkins at IETF wrote:
Asking with no hat, but ...

On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop <mbishop@evequefou.be> wrote:
I support adoption.  The way to change the invariants will be to mint a new protocol, and not claim that your new protocol is a version of QUIC.  If it happens to be startlingly similar, all well and good.

If you roll a new protocol, that's not a version of QUIC, is it obvious to everyone but me whether you can run both protocols on UDP/443? 

I thought I remembered that UDP/443 was chosen because firewalls often pass port 443, so that aids deployment. Hence, my question.
In my experience as a vendor of and consumer of commercial firewalls. UDP and TCP port numbers receive separate treatment.

So a decision to pass TCP 80/443  or UDP 443 would be undertaken independently.

Outgoing UDP through a stateful NAT/PAT tends to create state for a binding which will be used to map incoming packets with obverse 5-tuple to the original sender. unsolicited incoming UDP (for which no binding or rule exists) will be dropped.

There is the complexity with UDP of determining when you can remove the state since connection oriented signaling may well be (is) opaque to the stateful device. if you have to fall back to a timer or some kind of LRU policy for state entries you will tend break long lived flows that don't use keep-alives.
Thanks,

Spencer

--------------4F159B70308CAB01AAA78B1A-- From nobody Tue Feb 6 09:56:11 2018 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 EBFF112D878 for ; Tue, 6 Feb 2018 09:56:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=evequefou.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 1vHXq3seJG39 for ; Tue, 6 Feb 2018 09:56:06 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0109.outbound.protection.outlook.com [104.47.38.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 814791271DF for ; Tue, 6 Feb 2018 09:56:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WZ9UE51kNEo/5XM6LgpbpJMwg0RdSz/poJQ2Ut71qxs=; b=poALWaWXAlg+nRRS1t/E0gEfXNJRuF9A19CHVNcQzf7N3lUjpie7Zi+pyjf/IrTwF7E42db+i07gjZQFT8NZ3jYoy/LfJonjRlcMMg/oIdNhAW20hkcisDN09osile3x7Zuqk68vQYChaBOtnwoqlllaAY5mglGnVuGIxuoqnaI= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2719.namprd08.prod.outlook.com (10.173.232.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Tue, 6 Feb 2018 17:56:00 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0464.016; Tue, 6 Feb 2018 17:56:00 +0000 From: Mike Bishop To: Stephen Farrell , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Brian Trammell (IETF)" , Jana Iyengar CC: Praveen Balasubramanian , QUIC WG , Roberto Peon , "Lubashev, Igor" , "Salz, Rich" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW33YzpoOLX0UU2dbBSG8l3vaKOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADXOQCAAGavgIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACabIA== Date: Tue, 6 Feb 2018 17:56:00 +0000 Message-ID: References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> In-Reply-To: <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2719; 7:o9jz1P3NIZO70sCegNeRwtyqKz1Qtuz9aHE6Wv30RYSDHTqs+WZMsUj1VUGCFb4vNpD0Hszru/pJYU+8Ilft94dXXNsKwrYDbLaNMkP+nIdh79p5GOCutXQS2gYlp9YBOPSu2HA6ymn2uw0kc+AzmvyeMwXYLHhrbr++7jLBfvYgA/MW0FnujtX0MHxcNbTIsWldbkSNL07JxYPTjnizmS2eW6vgyJrOvOmTWL8hfMQFIVLb7rkXnMScUue4rxle x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1b44569f-c6c8-4d81-c320-08d56d8ae1ec x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2719; x-ms-traffictypediagnostic: MWHPR08MB2719: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(67672495146484)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(3002001)(6041288)(20161123562045)(20161123560045)(2016111802025)(20161123564045)(20161123558120)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB2719; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2719; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39380400002)(376002)(39830400003)(346002)(189003)(199004)(13464003)(6246003)(8666007)(39060400002)(9686003)(2900100001)(106356001)(4326008)(229853002)(6436002)(53936002)(74482002)(55016002)(93886005)(3660700001)(186003)(99286004)(478600001)(86362001)(105586002)(3280700002)(14454004)(33656002)(2906002)(53546011)(7736002)(6116002)(6506007)(3846002)(305945005)(74316002)(7696005)(316002)(8936002)(3480700004)(26005)(81156014)(81166006)(77096007)(8676002)(68736007)(25786009)(110136005)(54906003)(66066001)(7116003)(2950100002)(5660300001)(97736004)(7416002)(76176011)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2719; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2mgsr9N6x4z/a3VU4PX69ZV5YNktjCRxnqsDkV4LKYkY8ZEpJeDxS8XhAZX4HKJhIcb9JjxR3Mq0Iv5ZOgpL+Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 1b44569f-c6c8-4d81-c320-08d56d8ae1ec X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 17:56:00.2503 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2719 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, 06 Feb 2018 17:56:10 -0000 UGFja2V0IG51bWJlciBlbmNyeXB0aW9uICpkb2VzKiBpbXByb3ZlIGxpbmthYmlsaXR5IGVxdWl2 YWxlbnRseSB0byByYW5kb20ganVtcHMsIGJ1dCB3aXRob3V0IHRoZSBmcmFnbWVudGF0aW9uIG9m IHRoZSBBQ0sgcGFja2V0IHdoaWNoIHRob3NlIGp1bXBzIG90aGVyd2lzZSBjYXVzZS4gIFNvIEkn bSB3aXRoIFN0ZXBoZW4sIHdlIGRvbid0IHlldCBoYXZlIGFncmVlbWVudCBvbiB0aGF0IGFzc2Vy dGlvbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNClNlbnQ6 IFR1ZXNkYXksIEZlYnJ1YXJ5IDYsIDIwMTggNzozNSBBTQ0KVG86IE1pcmphIEvDvGhsZXdpbmQg PG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vu c2VuIDxtaWtrZWxmakBnbWFpbC5jb20+OyBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJh bW1lbGwuY2g+OyBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPg0KQ2M6IFByYXZlZW4gQmFs YXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9y Zz47IFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPjsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hl QGFrYW1haS5jb20+OyBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPg0KU3ViamVjdDogUmU6 IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQoNCg0KT24gMDYvMDIvMTggMTU6MjMsIE1pcmph IEvDvGhsZXdpbmQgd3JvdGU6DQo+IA0KPiBJdCdzIGFsc28gbXkgdW5kZXJzdGFuZGluZyB0aGF0 IHdlIGRvIGFncmVlIHRoYXQgcGFja2V0IG51bWJlciANCj4gZW5jcnlwdGlvbiBkb2VzIG5vdCBo ZWxwIGxpa2FiaWxpdHkgKGFuZCB0aGVyZWJ5IHByaXZhY3kpIGEgbG90LCBvciBhdCANCj4gbGVh c3QgdGhhdCB0aGUgYmVuZWZpdHMgd2UgbWlnaHQgZ2V0IChvciBub3QpIGRvIG5vdCBqdXN0aWZ5 IHRoZSANCj4gYWRkaXRpb25hbCBjb21wbGV4aXR5Lg0KDQpGV0lXLCB3aGljaCBpc24ndCBtdWNo LCBJIGRvbid0ICh5ZXQpIGFncmVlIHRvIHRoZSBhYm92ZS4NCkkgcmVja29uIGl0J2xsIGJlIGEg d2hpbGUgYmVmb3JlIHdlIGtub3cgaG93IGxpbmthYmlsaXR5IHBhbnMgb3V0LiBJIGRvIGFncmVl IHRoYXQgcGFja2V0IG51bWJlciBlbmNyeXB0aW9uIGlzIG5vdCBhIHBhbmFjZWEgZm9yIHVubGlu a2FiaWxpdHksIGJ1dCBpdCBtYXkgaGVscCwgb3IgbWF5IGV2ZW4gZW5kIHVwIGJlaW5nIHJlcXVp cmVkLCB0byBkbyBhIGdvb2Qgam9iIHdydCBsaW5rYWJpbGl0eS4NCg0KSSBhbHNvIGhlYXJkIHBl b3BsZSBzYXkgaXQgd2FzIGxlc3MgY29tcGxleCBmb3IgdGhlbSBzbyAiYWRkaXRpb25hbCBjb21w bGV4aXR5IiBtYXkgYWxzbyBub3QgYmUgcXVpdGUgcmlnaHQuIChJIGd1ZXNzICJkaWZmZXJlbnRs eSBjb21wbGV4IiBpcyBjb3JyZWN0IHRob3VnaC4pDQoNClMuDQoNCi0tDQpQR1Aga2V5IGNoYW5n ZSB0aW1lIGZvciBtZS4NCk5ldy1JRCA3QjE3MkJFQTsgb2xkLUlEIDgwNUY4REEyIGV4cGlyZXMg SmFuIDI0IDIwMTguDQpOZXdXaXRoT2xkIHNpZ3MgaW4ga2V5c2VydmVycy4NClNvcnJ5IGlmIHRo YXQgbXVja3Mgc29tZXRoaW5nIHVwOy0pDQo= From nobody Tue Feb 6 10:00:05 2018 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 833841271DF for ; Tue, 6 Feb 2018 10:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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, RCVD_IN_MSPIKE_H4=-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=evequefou.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 ouSXSeCz4u7Z for ; Tue, 6 Feb 2018 09:59:53 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0119.outbound.protection.outlook.com [104.47.40.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7195412741D for ; Tue, 6 Feb 2018 09:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KUKwfPcNT3j2umJv590G0sQ5BprUlaBvYE0i5rFDgTg=; b=pVuA+8ypXEsaWgOPFUeJ13rL9Rv8p4eE6LDHdEKthFVxAu78+96Ced5GvHwwH+wQXUAHDh9eL4Noh8MrMf6bcYN5dPF2Z0B54pElYpIDmyip6LYYwKk8kjImSD6S2ymq0PfAyzlXgAqngeJ1iU8SNx5ZL/wdJf5C8dVOgkOmc4E= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2688.namprd08.prod.outlook.com (10.173.231.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Tue, 6 Feb 2018 17:59:49 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0464.016; Tue, 6 Feb 2018 17:59:49 +0000 From: Mike Bishop To: Spencer Dawkins at IETF CC: "Brian Trammell (IETF)" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Lars Eggert" , Mark Nottingham , QUIC WG Subject: RE: Call for Adoption: Invariants Thread-Topic: Call for Adoption: Invariants Thread-Index: AQHTnkeuZnxZRuZmRE2jEtXr4M5toqOVb7kAgAALu4CAAK8BAIABTdyAgAAzYWA= Date: Tue, 6 Feb 2018 17:59:49 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2688; 7:grzKvjQcHMsdmSKllTb2g0ZG5g+d276XSUrivV03f730UedWNCRVae0dfL0csqS4xbXLpK/xO+SkmRZii4rP6204SETWtr4+yzgWz/3Hx5N8f6Uk6T911SbsaD3CDNq+dTxfw9oCfIw18+GVTBnGA9uQvswWaMbmQohqIkltGiPCMuwKxlltgrRfEBcwfI0+G8VF6+x41tfzCsXskZvBx5iy9hs0BKpqhhljVI/mwOqc2soJT8EhrA8aM7JJIq1k x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c5d84352-c827-488e-0dab-08d56d8b6a34 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2688; x-ms-traffictypediagnostic: MWHPR08MB2688: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(3002001)(6041288)(20161123562045)(20161123560045)(2016111802025)(20161123564045)(20161123558120)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB2688; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2688; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39830400003)(366004)(376002)(396003)(346002)(189003)(199004)(54896002)(53936002)(105586002)(6306002)(55016002)(8676002)(81156014)(6246003)(229853002)(81166006)(6916009)(7696005)(19609705001)(97736004)(236005)(106356001)(2950100002)(9686003)(2900100001)(3846002)(5660300001)(6116002)(790700001)(99286004)(86362001)(186003)(39060400002)(74482002)(478600001)(4326008)(26005)(102836004)(3280700002)(2906002)(53546011)(316002)(66066001)(6506007)(77096007)(14454004)(76176011)(74316002)(68736007)(25786009)(6346003)(6436002)(8936002)(7736002)(3660700001)(93886005)(33656002)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2688; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-microsoft-antispam-message-info: R5ltk9BVnzwmj9OkDObEKpXD9C6gF+/8Rf25FmfwRyN8FyGjCK9UAuTM+OsPQrXHxpXbiRBfMeyCGiOz1VczeQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB24322AC02BFDEBDB2662389BDAFD0MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: c5d84352-c827-488e-0dab-08d56d8b6a34 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 17:59:49.0439 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2688 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, 06 Feb 2018 18:00:04 -0000 --_000_MWHPR08MB24322AC02BFDEBDB2662389BDAFD0MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXQgdGhhdCBwb2ludCwgeW914oCZcmUgYmFjayBpbiB0aGUg4oCcZGVtdXhpbmcgVURQIHByb3Rv Y29sc+KAnSBkaXNjdXNzaW9uLiAgSWYgdGhlcmXigJlzIGEgd2F5IHRvIGRpZmZlcmVudGlhdGUg dGhlIHR3byBwcm90b2NvbHMsIHRoZW4gYW4gZW5kcG9pbnQgY291bGQgaW1wbGVtZW50IGJvdGgg YW5kIHJvdXRlIGluY29taW5nIHBhY2tldHMgdG8gdGhlIGNvcnJlY3QgcGFyc2VyLg0KDQpGcm9t OiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiBbbWFpbHRvOnNwZW5jZXJkYXdraW5zLmlldGZAZ21h aWwuY29tXQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgNiwgMjAxOCA2OjU1IEFNDQpUbzogTWlr ZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPg0KQ2M6IEJyaWFuIFRyYW1tZWxsIChJRVRG KSA8aWV0ZkB0cmFtbWVsbC5jaD47IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZq QGdtYWlsLmNvbT47IExhcnMgRWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc+OyBNYXJrIE5vdHRpbmdo YW0gPG1ub3RAbW5vdC5uZXQ+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IENhbGwgZm9yIEFkb3B0aW9uOiBJbnZhcmlhbnRzDQoNCkFza2luZyB3aXRoIG5vIGhhdCwgYnV0 IC4uLg0KDQpPbiBNb24sIEZlYiA1LCAyMDE4IGF0IDE6MDAgUE0sIE1pa2UgQmlzaG9wIDxtYmlz aG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3cm90ZToNCkkg c3VwcG9ydCBhZG9wdGlvbi4gIFRoZSB3YXkgdG8gY2hhbmdlIHRoZSBpbnZhcmlhbnRzIHdpbGwg YmUgdG8gbWludCBhIG5ldyBwcm90b2NvbCwgYW5kIG5vdCBjbGFpbSB0aGF0IHlvdXIgbmV3IHBy b3RvY29sIGlzIGEgdmVyc2lvbiBvZiBRVUlDLiAgSWYgaXQgaGFwcGVucyB0byBiZSBzdGFydGxp bmdseSBzaW1pbGFyLCBhbGwgd2VsbCBhbmQgZ29vZC4NCg0KSWYgeW91IHJvbGwgYSBuZXcgcHJv dG9jb2wsIHRoYXQncyBub3QgYSB2ZXJzaW9uIG9mIFFVSUMsIGlzIGl0IG9idmlvdXMgdG8gZXZl cnlvbmUgYnV0IG1lIHdoZXRoZXIgeW91IGNhbiBydW4gYm90aCBwcm90b2NvbHMgb24gVURQLzQ0 Mz8NCg0KSSB0aG91Z2h0IEkgcmVtZW1iZXJlZCB0aGF0IFVEUC80NDMgd2FzIGNob3NlbiBiZWNh dXNlIGZpcmV3YWxscyBvZnRlbiBwYXNzIHBvcnQgNDQzLCBzbyB0aGF0IGFpZHMgZGVwbG95bWVu dC4gSGVuY2UsIG15IHF1ZXN0aW9uLg0KDQpUaGFua3MsDQoNClNwZW5jZXINCg== --_000_MWHPR08MB24322AC02BFDEBDB2662389BDAFD0MWHPR08MB2432namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B dCB0aGF0IHBvaW50LCB5b3XigJlyZSBiYWNrIGluIHRoZSDigJxkZW11eGluZyBVRFAgcHJvdG9j b2xz4oCdIGRpc2N1c3Npb24uJm5ic3A7IElmIHRoZXJl4oCZcyBhIHdheSB0byBkaWZmZXJlbnRp YXRlIHRoZSB0d28gcHJvdG9jb2xzLCB0aGVuIGFuIGVuZHBvaW50IGNvdWxkIGltcGxlbWVudCBi b3RoIGFuZCByb3V0ZSBpbmNvbWluZyBwYWNrZXRzIHRvIHRoZSBjb3JyZWN0IHBhcnNlci48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRG IFttYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50Ojwv Yj4gVHVlc2RheSwgRmVicnVhcnkgNiwgMjAxOCA2OjU1IEFNPGJyPg0KPGI+VG86PC9iPiBNaWtl IEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBCcmlh biBUcmFtbWVsbCAoSUVURikgJmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7OyBNaWtrZWwgRmFobsO4 ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBMYXJzIEVnZ2VydCAmbHQ7 bGFyc0BlZ2dlcnQub3JnJmd0OzsgTWFyayBOb3R0aW5naGFtICZsdDttbm90QG1ub3QubmV0Jmd0 OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IENhbGwgZm9yIEFkb3B0aW9uOiBJbnZhcmlhbnRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Bc2tpbmcgd2l0aCBubyBoYXQsIGJ1dCAuLi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBNb24sIEZlYiA1LCAyMDE4IGF0IDE6MDAgUE0sIE1pa2UgQmlzaG9w ICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5r Ij5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc3VwcG9ydCBhZG9wdGlvbi4mbmJzcDsg VGhlIHdheSB0byBjaGFuZ2UgdGhlIGludmFyaWFudHMgd2lsbCBiZSB0byBtaW50IGEgbmV3IHBy b3RvY29sLCBhbmQgbm90IGNsYWltIHRoYXQgeW91ciBuZXcgcHJvdG9jb2wgaXMgYSB2ZXJzaW9u IG9mIFFVSUMuJm5ic3A7IElmIGl0IGhhcHBlbnMgdG8gYmUgc3RhcnRsaW5nbHkgc2ltaWxhciwg YWxsIHdlbGwgYW5kIGdvb2QuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3Ugcm9sbCBhIG5ldyBwcm90b2NvbCwgdGhhdCdz IG5vdCBhIHZlcnNpb24gb2YgUVVJQywgaXMgaXQgb2J2aW91cyB0byBldmVyeW9uZSBidXQgbWUg d2hldGhlciB5b3UgY2FuIHJ1biBib3RoIHByb3RvY29scyBvbiBVRFAvNDQzPyZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRob3Vn aHQgSSByZW1lbWJlcmVkIHRoYXQgVURQLzQ0MyB3YXMgY2hvc2VuIGJlY2F1c2UgZmlyZXdhbGxz IG9mdGVuIHBhc3MgcG9ydCA0NDMsIHNvIHRoYXQgYWlkcyBkZXBsb3ltZW50LiBIZW5jZSwgbXkg cXVlc3Rpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U3BlbmNlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR08MB24322AC02BFDEBDB2662389BDAFD0MWHPR08MB2432namp_-- From nobody Tue Feb 6 10:57:38 2018 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 034B812741D for ; Tue, 6 Feb 2018 10:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, 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 u8Yx6j9FwHIP for ; Tue, 6 Feb 2018 10:57:35 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 2EBEB1267BB for ; Tue, 6 Feb 2018 10:57:35 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id j188so2128143oib.6 for ; Tue, 06 Feb 2018 10:57:35 -0800 (PST) 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=O8NR+6GDVbV62TC5igh0vo6JTEThVkv3DI87fdKSPEM=; b=njBQLmQ8GzlwfYSf39Y2xRDlKeI0oyyALXiuOCE4Al8Pv48W3i5qOGiqgVanof4+yn fkluOtm7Ejy6fPQ5KB+3ERQrLFqgW55/8LS4YVwmdoFvA0LvPq7uTKfUWiQaW18Bu0oJ 9KuhJgmdI31jjEUtCViIrZmzyWGcrgH2I0HEsq9Zp1NcrJfmiDE1Jeu79vy+q3EftrrO 0TTWAkEJ/sscaV8E8lkxzBtgPFItmbZwN+6UIWLhKuOk4kA9J7mJhYXYLC3s9TeP5lFu DjOcjCrLYVpulX++5NN6ll3J3sQ7o/A3woNg3QlqV/nhl8Z8gG1ZHYZhAwmBTqMpNwiF g9BA== 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=O8NR+6GDVbV62TC5igh0vo6JTEThVkv3DI87fdKSPEM=; b=YeJWLpu7NLIL+x629z7omKTkP4FLF9DBrlOIDuJ3Ecsk5EyYLE2n2tV/mw/BhWPaze /1a3NjpxjXIu0w6N4krlTIMl0HujTD/hoWVMnNj+Q82V36sQmgn0C+w224Do5erqqHFb e90hGVGF6rV6GZdj7vP7iDNsZoZFP2FBwv1aDSUl1qP6OBk+TIdKZEHBGef01O9wLiRA Q5FA+Kax5UkdI4aht1Po4mnErkICqZbW9Hqfprtqogs65YmNX3i8eaygIgC9Qm9TceeH 6+2jUaqc7ZV+KGwBTQlNOGosD5cOua1U10g8hGm//Ztml+aEJr4MgvkUTs437LU+LyS5 stJA== X-Gm-Message-State: APf1xPB0bdtCfBu+SXiGxaYoYIXO+9cY24v4gfGi4JSvRpwpt1tlGjm3 s1pw/1z6wVtOkVpLMi95w2rVzL7J9tlw55U3j/YqIA== X-Google-Smtp-Source: AH8x2242eFhJ2hMKh7gothA/56OG6z7+8hLblsWKd7Izx5jqTHrOgGVoWzXptbTaPwpI23YYdNAc6bUpubfFs71qRug= X-Received: by 10.202.60.196 with SMTP id j187mr2390520oia.216.1517943454366; Tue, 06 Feb 2018 10:57:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.3.71 with HTTP; Tue, 6 Feb 2018 10:57:03 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Tue, 6 Feb 2018 10:57:03 -0800 Message-ID: Subject: Re: Call for Adoption: Invariants To: Spencer Dawkins at IETF Cc: Mike Bishop , "Brian Trammell (IETF)" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Mark Nottingham , Lars Eggert Content-Type: multipart/alternative; boundary="001a113cced86307d805648fc072" 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, 06 Feb 2018 18:57:37 -0000 --001a113cced86307d805648fc072 Content-Type: text/plain; charset="UTF-8" On Tue, Feb 6, 2018 at 6:54 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > Asking with no hat, but ... > > On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop wrote: > >> I support adoption. The way to change the invariants will be to mint a >> new protocol, and not claim that your new protocol is a version of QUIC. >> If it happens to be startlingly similar, all well and good. > > > If you roll a new protocol, that's not a version of QUIC, is it obvious to > everyone but me whether you can run both protocols on UDP/443? > > Mike Bishop's PR defining httpq as a scheme ( https://github.com/quicwg/base-drafts/pull/348) defines UDP 443 as the default for httpq. I think that pretty much asserts that UDP/443 is QUIC, not a forked variant. > I thought I remembered that UDP/443 was chosen because firewalls often > pass port 443, so that aids deployment. Hence, my question. > > Yes. That may cause us to consider carefully whether UDP/443 ought to be defined for QUIC more rather than HTTP over QUIC, or even more generally. Ted > Thanks, > > Spencer > --001a113cced86307d805648fc072 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Feb 6, 2018 at 6:54 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
Asking with no hat, but ...

On Mon, Feb 5, 2= 018 at 1:00 PM, Mike Bishop <mbishop@evequefou.be> wrote:=
I support adoption.= =C2=A0 The way to change the invariants will be to mint a new protocol, and= not claim that your new protocol is a version of QUIC.=C2=A0 If it happens= to be startlingly similar, all well and good.

<= /span>
If you roll a new protocol, that's not a version of QUIC, is= it obvious to everyone but me whether you can run both protocols on UDP/44= 3?=C2=A0


= Mike Bishop's PR defining httpq as a scheme (https://github.com/quicwg/base-drafts/pull= /348) defines UDP 443 as the default for httpq.=C2=A0 I think that pret= ty much asserts that UDP/443 is QUIC, not a forked variant.=C2=A0
=C2=A0
I thought I remembered that UDP/443 was ch= osen because firewalls often pass port 443, so that aids deployment. Hence,= my question.


<= /div>
Yes.=C2=A0 That may cause us to consider carefully whether UDP/44= 3 ought to be defined for QUIC more rather than HTTP over QUIC, or even mor= e generally.

Ted

=C2=A0
Thanks,

<= /div>
Spencer

--001a113cced86307d805648fc072-- From nobody Tue Feb 6 11:10:07 2018 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 EBF6C12D872 for ; Tue, 6 Feb 2018 11:10:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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, RCVD_IN_MSPIKE_H4=-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=evequefou.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 q6cMFtO395M7 for ; Tue, 6 Feb 2018 11:10:03 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0119.outbound.protection.outlook.com [104.47.36.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AB7B120713 for ; Tue, 6 Feb 2018 11:10:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CtaR8DlFW5hgKgGZgJy/KIHaWFUpph4iQ4Kh2nwTvqQ=; b=lRLgvIWq0qSCOe5JDZxgiCuqG//B1HQ36jy69x9zasA8kG1Z4bRwPlh8u+Mp+cL56uMJ0aAjSbhCWRT/Pde2KLiYwFS4zuLK07vkFBcEbx97usGnIV8kbnUq78UPOQDamIuqSyZdzW4yQIyHdBcDFX45U8cmZQqpzRA5XKrykws= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2896.namprd08.prod.outlook.com (10.173.240.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Tue, 6 Feb 2018 19:09:59 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0464.016; Tue, 6 Feb 2018 19:09:59 +0000 From: Mike Bishop To: Ted Hardie , Spencer Dawkins at IETF CC: "Brian Trammell (IETF)" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "QUIC WG" , Mark Nottingham , Lars Eggert Subject: RE: Call for Adoption: Invariants Thread-Topic: Call for Adoption: Invariants Thread-Index: AQHTnkeuZnxZRuZmRE2jEtXr4M5toqOVb7kAgAALu4CAAK8BAIABTdyAgABDrICAAANAMA== Date: Tue, 6 Feb 2018 19:09:59 +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: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2896; 7:Hw1UdrkRbwuJO9rflL5ZhkwO1UpQRPDO7hl3/pRFUUKbv9ESHsYj+qYeevFc9+deZk/oUXKgjh8WjHSA2BWFBISoVXyjij5tWpzhfdeI2IPNL/0xTOP+QFB2/wVa1CaV9eIAbsKp3v6jqCfK2ZPcpifNJSdZQFzEkEQqYH/xQXaFx2XztuqCuX5JErPVtlIW5n8QaPpCA+wUo0M7rmYbJbYE3kEriPvhKMbskv3qyTSmNuMK0o+KEMd4UmCuQqVW x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 863a06a0-4c07-48a9-1597-08d56d95379e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2896; x-ms-traffictypediagnostic: MWHPR08MB2896: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(85827821059158)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(6041288)(20161123564045)(2016111802025)(20161123560045)(20161123562045)(20161123558120)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB2896; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2896; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(366004)(376002)(396003)(39380400002)(346002)(51444003)(189003)(199004)(76176011)(2906002)(7696005)(53546011)(186003)(74482002)(106356001)(110136005)(19609705001)(66066001)(93886005)(68736007)(3660700001)(14454004)(6116002)(790700001)(3846002)(26005)(105586002)(81166006)(86362001)(8676002)(81156014)(8936002)(102836004)(6506007)(99286004)(3280700002)(4326008)(316002)(5660300001)(478600001)(55016002)(74316002)(25786009)(77096007)(54906003)(97736004)(33656002)(39060400002)(229853002)(236005)(2900100001)(54896002)(2950100002)(6436002)(9686003)(6306002)(7736002)(6246003)(53936002)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2896; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: DBjEiuSlWr9pd0IU9VIWjFTPvMRamB6KazG/Nwd7M1HNLtjkG1KTdqPYs9bB26+vXbtzZDTTPQtzSbc/c8J96Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432E39B469653DB35C02D8EDAFD0MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 863a06a0-4c07-48a9-1597-08d56d95379e X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 19:09:59.1267 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2896 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, 06 Feb 2018 19:10:06 -0000 --_000_MWHPR08MB2432E39B469653DB35C02D8EDAFD0MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VHdvIG5vdGVzLCBvbmUgYWdhaW5zdCBpbnRlcmVzdDogIFRoYXQgUFIgaXMgb2xkIGFuZCBjdXJy ZW50bHkgcGFya2VkLCBiZWNhdXNlIHdlIGRvbuKAmXQgaGF2ZSBjb25zZW5zdXMgYW5kIGl04oCZ cyBsZXNzIHVyZ2VudC4gIEFuZCBzZWNvbmRseSwgVURQLzQ0MyBpcyBhbHJlYWR5IGFsbG9jYXRl ZCBieSBJQU5BIGZvciBIVFRQIG92ZXIgVURQLg0KDQpGcm9tOiBUZWQgSGFyZGllIFttYWlsdG86 dGVkLmlldGZAZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgNiwgMjAxOCAxMDo1 NyBBTQ0KVG86IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdt YWlsLmNvbT4NCkNjOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+OyBCcmlhbiBU cmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vu c2VuIDxtaWtrZWxmakBnbWFpbC5jb20+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWFyayBO b3R0aW5naGFtIDxtbm90QG1ub3QubmV0PjsgTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9yZz4N ClN1YmplY3Q6IFJlOiBDYWxsIGZvciBBZG9wdGlvbjogSW52YXJpYW50cw0KDQpPbiBUdWUsIEZl YiA2LCAyMDE4IGF0IDY6NTQgQU0sIFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3 a2lucy5pZXRmQGdtYWlsLmNvbTxtYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+ PiB3cm90ZToNCkFza2luZyB3aXRoIG5vIGhhdCwgYnV0IC4uLg0KDQpPbiBNb24sIEZlYiA1LCAy MDE4IGF0IDE6MDAgUE0sIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86 bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3cm90ZToNCkkgc3VwcG9ydCBhZG9wdGlvbi4gIFRoZSB3 YXkgdG8gY2hhbmdlIHRoZSBpbnZhcmlhbnRzIHdpbGwgYmUgdG8gbWludCBhIG5ldyBwcm90b2Nv bCwgYW5kIG5vdCBjbGFpbSB0aGF0IHlvdXIgbmV3IHByb3RvY29sIGlzIGEgdmVyc2lvbiBvZiBR VUlDLiAgSWYgaXQgaGFwcGVucyB0byBiZSBzdGFydGxpbmdseSBzaW1pbGFyLCBhbGwgd2VsbCBh bmQgZ29vZC4NCg0KSWYgeW91IHJvbGwgYSBuZXcgcHJvdG9jb2wsIHRoYXQncyBub3QgYSB2ZXJz aW9uIG9mIFFVSUMsIGlzIGl0IG9idmlvdXMgdG8gZXZlcnlvbmUgYnV0IG1lIHdoZXRoZXIgeW91 IGNhbiBydW4gYm90aCBwcm90b2NvbHMgb24gVURQLzQ0Mz8NCg0KDQpNaWtlIEJpc2hvcCdzIFBS IGRlZmluaW5nIGh0dHBxIGFzIGEgc2NoZW1lIChodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jh c2UtZHJhZnRzL3B1bGwvMzQ4KSBkZWZpbmVzIFVEUCA0NDMgYXMgdGhlIGRlZmF1bHQgZm9yIGh0 dHBxLiAgSSB0aGluayB0aGF0IHByZXR0eSBtdWNoIGFzc2VydHMgdGhhdCBVRFAvNDQzIGlzIFFV SUMsIG5vdCBhIGZvcmtlZCB2YXJpYW50Lg0KDQpJIHRob3VnaHQgSSByZW1lbWJlcmVkIHRoYXQg VURQLzQ0MyB3YXMgY2hvc2VuIGJlY2F1c2UgZmlyZXdhbGxzIG9mdGVuIHBhc3MgcG9ydCA0NDMs IHNvIHRoYXQgYWlkcyBkZXBsb3ltZW50LiBIZW5jZSwgbXkgcXVlc3Rpb24uDQoNCg0KWWVzLiAg VGhhdCBtYXkgY2F1c2UgdXMgdG8gY29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIgVURQLzQ0MyBv dWdodCB0byBiZSBkZWZpbmVkIGZvciBRVUlDIG1vcmUgcmF0aGVyIHRoYW4gSFRUUCBvdmVyIFFV SUMsIG9yIGV2ZW4gbW9yZSBnZW5lcmFsbHkuDQpUZWQNCg0KDQpUaGFua3MsDQoNClNwZW5jZXIN Cg0K --_000_MWHPR08MB2432E39B469653DB35C02D8EDAFD0MWHPR08MB2432namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U d28gbm90ZXMsIG9uZSBhZ2FpbnN0IGludGVyZXN0OiZuYnNwOyBUaGF0IFBSIGlzIG9sZCBhbmQg Y3VycmVudGx5IHBhcmtlZCwgYmVjYXVzZSB3ZSBkb27igJl0IGhhdmUgY29uc2Vuc3VzIGFuZCBp dOKAmXMgbGVzcyB1cmdlbnQuJm5ic3A7IEFuZCBzZWNvbmRseSwgVURQLzQ0MyBpcyBhbHJlYWR5 IGFsbG9jYXRlZCBieSBJQU5BIGZvciBIVFRQIG92ZXIgVURQLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gVGVkIEhhcmRpZSBbbWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbV0g PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDYsIDIwMTggMTA6NTcgQU08YnI+ DQo8Yj5Ubzo8L2I+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGICZsdDtzcGVuY2VyZGF3a2lucy5p ZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1pa2UgQmlzaG9wICZsdDttYmlzaG9w QGV2ZXF1ZWZvdS5iZSZndDs7IEJyaWFuIFRyYW1tZWxsIChJRVRGKSAmbHQ7aWV0ZkB0cmFtbWVs bC5jaCZndDs7IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWlsLmNv bSZndDs7IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBNYXJrIE5vdHRpbmdoYW0gJmx0 O21ub3RAbW5vdC5uZXQmZ3Q7OyBMYXJzIEVnZ2VydCAmbHQ7bGFyc0BlZ2dlcnQub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQ2FsbCBmb3IgQWRvcHRpb246IEludmFyaWFudHM8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDYsIDIwMTggYXQgNjo1NCBB TSwgU3BlbmNlciBEYXdraW5zIGF0IElFVEYgJmx0OzxhIGhyZWY9Im1haWx0bzpzcGVuY2VyZGF3 a2lucy5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNwZW5jZXJkYXdraW5zLmlldGZA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXNraW5nIHdpdGggbm8gaGF0 LCBidXQgLi4uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBG ZWIgNSwgMjAxOCBhdCAxOjAwIFBNLCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1i aXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIHN1cHBvcnQgYWRvcHRpb24uJm5ic3A7IFRoZSB3YXkgdG8gY2hhbmdlIHRoZSBp bnZhcmlhbnRzIHdpbGwgYmUgdG8gbWludCBhIG5ldyBwcm90b2NvbCwgYW5kIG5vdCBjbGFpbSB0 aGF0IHlvdXIgbmV3IHByb3RvY29sIGlzIGEgdmVyc2lvbiBvZiBRVUlDLiZuYnNwOyBJZiBpdCBo YXBwZW5zIHRvIGJlIHN0YXJ0bGluZ2x5IHNpbWlsYXIsIGFsbCB3ZWxsIGFuZCBnb29kLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgeW91IHJvbGwgYSBuZXcgcHJvdG9jb2wsIHRoYXQncyBub3QgYSB2ZXJzaW9uIG9mIFFVSUMs IGlzIGl0IG9idmlvdXMgdG8gZXZlcnlvbmUgYnV0IG1lIHdoZXRoZXIgeW91IGNhbiBydW4gYm90 aCBwcm90b2NvbHMgb24gVURQLzQ0Mz8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1pa2UgQmlzaG9wJ3MgUFIgZGVmaW5pbmcgaHR0cHEgYXMgYSBzY2hlbWUgKDxhIGhyZWY9 Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8zNDgiPmh0dHBzOi8v Z2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC8zNDg8L2E+KSBkZWZpbmVzIFVEUCA0 NDMgYXMgdGhlIGRlZmF1bHQgZm9yIGh0dHBxLiZuYnNwOyBJIHRoaW5rIHRoYXQgcHJldHR5IG11 Y2ggYXNzZXJ0cyB0aGF0IFVEUC80NDMNCiBpcyBRVUlDLCBub3QgYSBmb3JrZWQgdmFyaWFudC4m bmJzcDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aG91Z2h0IEkg cmVtZW1iZXJlZCB0aGF0IFVEUC80NDMgd2FzIGNob3NlbiBiZWNhdXNlIGZpcmV3YWxscyBvZnRl biBwYXNzIHBvcnQgNDQzLCBzbyB0aGF0IGFpZHMgZGVwbG95bWVudC4gSGVuY2UsIG15IHF1ZXN0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+WWVzLiZuYnNwOyBUaGF0IG1heSBjYXVzZSB1cyB0byBjb25zaWRlciBj YXJlZnVsbHkgd2hldGhlciBVRFAvNDQzIG91Z2h0IHRvIGJlIGRlZmluZWQgZm9yIFFVSUMgbW9y ZSByYXRoZXIgdGhhbiBIVFRQIG92ZXIgUVVJQywgb3IgZXZlbiBtb3JlIGdlbmVyYWxseS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRlZDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVuY2VyPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR08MB2432E39B469653DB35C02D8EDAFD0MWHPR08MB2432namp_-- From nobody Tue Feb 6 11:26:13 2018 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 7C45B127241 for ; Tue, 6 Feb 2018 11:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 3IC-YoVrUq77 for ; Tue, 6 Feb 2018 11:26:10 -0800 (PST) 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 C89A4124B17 for ; Tue, 6 Feb 2018 11:26:09 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id u21so2155850ywc.2 for ; Tue, 06 Feb 2018 11:26:09 -0800 (PST) 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=djOM+XhUyVt8ym/EJrpVzeA5V3ZGpKitghKwlisQZvQ=; b=SaWi0JJCeyn+90/BFnhtgIqaopNcY6CXrp5UV10LkXL0tQsBmCIrokWuQycSbUBQzK 7kjgny8IOMMUoIZbBz1vF5fkTG1YHSwtLV+V3BkgKoxj4e2mn/HPY5/oOK9U355lWOo1 7pbvLsBd+otAtueEIB5huoKs+oSkcJ3jWUeNaI+a73cad8GGjpNeyXJht3X0G2y8+A84 Kr+D7jRejwBu9i8Re5vV9fiuRKthJnrscO9kTe8i4ghxqBcrXPDZmK7KX/8yVxN8Pm+p ycM2w6Z2E+ZgAOuupWoIiIBNnkikGP4dHpsI0VXJcdQyzVMMZQ4Al4GXh9bj/jBQSw+i WAnw== 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=djOM+XhUyVt8ym/EJrpVzeA5V3ZGpKitghKwlisQZvQ=; b=TGttMLFlbodRg6DQUZ9x+dRCuPmf7UWVzIAx5Do5GiAf8TWEGqJo1/oXtgfdt4IKvg 2HnX7of1OMeNg0WqTJFbDYPC/k5swZmPScmBbcFnVyVUbmMIZPDFV3pJwz7CImquwH6P +xilJ5WV8QeiTiz/JkbIQyzS4ghOj0KFQ5/GS2fIRtFxZeCr13aA1S9BR4d4vWMUyGNl WwSRHqzFUDVCdLpuDSg+AJVf6/ILTXGJHurrVn/mDYUQfO9kIb3RNPkdP7rx3upWTG4q uOgtvgoCAYj3As4FrPsmbQ+4iCFq8gIEqow/YAqB17Kqn8Xw40UDEB/dKcD3eqtSHEiy umbw== X-Gm-Message-State: APf1xPBCpRO6UKhAdz3GUzsOPQ1yZtJfLy6m8BI8TcbaG57TSMnGUaSv r+23gkT77kuhDzWFt6tO10Nqto6xkdjrfNA/EocfFA== X-Google-Smtp-Source: AH8x226utKM86nlEWE6h2DJ5X7dgB26eFIKVCFH166XXjmyU2LUfuL+Np4FsW8ctGABdOU9W7+lQ2fcDVuviR096eMQ= X-Received: by 10.129.146.130 with SMTP id j124mr2142519ywg.256.1517945168324; Tue, 06 Feb 2018 11:26:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Tue, 6 Feb 2018 11:26:07 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 6 Feb 2018 11:26:07 -0800 Message-ID: Subject: Re: Call for Adoption: Invariants To: Mike Bishop Cc: Ted Hardie , Spencer Dawkins at IETF , "Brian Trammell (IETF)" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Mark Nottingham , Lars Eggert Content-Type: multipart/alternative; boundary="001a114c4c108ca7f50564902663" 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, 06 Feb 2018 19:26:12 -0000 --001a114c4c108ca7f50564902663 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What Mike said -- UDP/443 was allocated for HTTP over UDP, but is not required for HTTP/QUIC. The HTTP mapping document currently says (in Sectio= n 2.1 ) "Servers MAY serve HTTP/QUIC on any UDP port." We can discuss this, but let's move that discussion to where it belongs, on #495 . The QUIC transport draft specifically does not say anything about which UDP ports are to be used -- QUIC is a transport after all, and there is no reason to tie the entire transport to a port. On Tue, Feb 6, 2018 at 11:09 AM, Mike Bishop wrote: > Two notes, one against interest: That PR is old and currently parked, > because we don=E2=80=99t have consensus and it=E2=80=99s less urgent. An= d secondly, > UDP/443 is already allocated by IANA for HTTP over UDP. > > > > *From:* Ted Hardie [mailto:ted.ietf@gmail.com] > *Sent:* Tuesday, February 6, 2018 10:57 AM > *To:* Spencer Dawkins at IETF > *Cc:* Mike Bishop ; Brian Trammell (IETF) < > ietf@trammell.ch>; Mikkel Fahn=C3=B8e J=C3=B8rgensen = ; QUIC WG < > quic@ietf.org>; Mark Nottingham ; Lars Eggert < > lars@eggert.org> > *Subject:* Re: Call for Adoption: Invariants > > > > On Tue, Feb 6, 2018 at 6:54 AM, Spencer Dawkins at IETF < > spencerdawkins.ietf@gmail.com> wrote: > > Asking with no hat, but ... > > > > On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop wrote: > > I support adoption. The way to change the invariants will be to mint a > new protocol, and not claim that your new protocol is a version of QUIC. > If it happens to be startlingly similar, all well and good. > > > > If you roll a new protocol, that's not a version of QUIC, is it obvious t= o > everyone but me whether you can run both protocols on UDP/443? > > > > > > Mike Bishop's PR defining httpq as a scheme (https://github.com/quicwg/ > base-drafts/pull/348) defines UDP 443 as the default for httpq. I think > that pretty much asserts that UDP/443 is QUIC, not a forked variant. > > > > I thought I remembered that UDP/443 was chosen because firewalls often > pass port 443, so that aids deployment. Hence, my question. > > > > > > Yes. That may cause us to consider carefully whether UDP/443 ought to be > defined for QUIC more rather than HTTP over QUIC, or even more generally. > > Ted > > > > > Thanks, > > > > Spencer > > > --001a114c4c108ca7f50564902663 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What Mike said -- UDP/443 was allocated for HTTP over UDP,= but is not required for HTTP/QUIC.=C2=A0The HTTP= mapping document currently says (in=C2=A0Section 2.1) "Servers MAY serve HTTP/QUIC on any UDP port." We can = discuss this, but let's move that discussion to where it belongs, on=C2= =A0#495.

The QUIC transport draft specific= ally does not say anything about which UDP ports are to be used -- QUIC is = a transport after all, and there is no reason to tie the entire transport t= o a port.



On Tue, Feb 6, 2018 at 11:09 AM, Mike Bishop <mbishop@= evequefou.be> wrote:

Two notes, one against interest:=C2=A0 That PR is ol= d and currently parked, because we don=E2=80=99t have consensus and it=E2= =80=99s less urgent.=C2=A0 And secondly, UDP/443 is already allocated by IA= NA for HTTP over UDP.

=C2=A0

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Tuesday, February 6, 2018 10:57 AM
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Cc: Mike Bishop <mbishop@evequefou.be>; Brian Trammell (IETF) <ietf@trammell.ch>; Mi= kkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; QUIC WG <quic@ietf.org>; Mark Nottingham <= ;mnot@mnot.net>; = Lars Eggert <lars@e= ggert.org>
Subject: Re: Call for Adoption: Invariants

=C2=A0

On Tue, Feb 6, 2018 at 6:54 AM, Spencer Dawkins at I= ETF <= spencerdawkins.ietf@gmail.com> wrote:

=C2=A0

I thought I remembered that UDP/443 was chosen becau= se firewalls often pass port 443, so that aids deployment. Hence, my questi= on.

=C2=A0

=C2=A0

Yes.=C2=A0 That may c= ause us to consider carefully whether UDP/443 ought to be defined for QUIC = more rather than HTTP over QUIC, or even more generally.

Ted


=C2=A0

Thanks,

=C2=A0

Spencer

=C2=A0


--001a114c4c108ca7f50564902663-- From nobody Tue Feb 6 11:31:36 2018 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 C5BA01275AB for ; Tue, 6 Feb 2018 11:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=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 KqNygD4K06Ut for ; Tue, 6 Feb 2018 11:31:30 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0121.outbound.protection.outlook.com [104.47.42.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48550124B17 for ; Tue, 6 Feb 2018 11:31:30 -0800 (PST) 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=wnJWV7PUn4tGKbQQ6vF4ffzb4q+YkWXQpAFISJ/neuE=; b=coLKMxW4nfGXm+3mGUoE7TLSNrQU/CIf8jtQCteqN7nmjmh28Jzv2LIsTls9zMstFH+fCkz+EckZ75ef64K+m86ATAAomlCDkSQSmSwaYVhDHAUqy4q9KMc9D1MLxdEtLp4z3B2jh64o7lQgzZrtDjE+yGwpHgSzW/J+Xfbak4U= Received: from DM5PR21MB0827.namprd21.prod.outlook.com (10.173.172.9) by DM5PR21MB0507.namprd21.prod.outlook.com (10.172.91.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Tue, 6 Feb 2018 19:31:27 +0000 Received: from DM5PR21MB0827.namprd21.prod.outlook.com ([10.173.172.9]) by DM5PR21MB0827.namprd21.prod.outlook.com ([10.173.172.9]) with mapi id 15.20.0506.007; Tue, 6 Feb 2018 19:31:27 +0000 From: Gabriel Montenegro To: Alan Frindell , Eric Kinnear , Jana Iyengar CC: Lars Eggert , Mark Nottingham , QUIC WG , Mike Bishop , Roberto Peon Subject: RE: Call for Adoption: QCRAM Thread-Topic: Call for Adoption: QCRAM Thread-Index: AQHTnkewJq9krIppVEG6+MFrCUaB/qOWK2wAgAAAo4CAAA+EgIAAH9kAgAAxkoCAATh+AA== Date: Tue, 6 Feb 2018 19:31:27 +0000 Message-ID: References: <6A834DB6-F2A5-4973-83CD-8AAA82945372@mnot.net> <816D67C7-1E2F-40E3-AC64-504D06316FC1@fb.com> In-Reply-To: <816D67C7-1E2F-40E3-AC64-504D06316FC1@fb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=gmonte@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-02-06T19:31:26.4277132Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:3::299] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR21MB0507; 7:rnV3zu0al8DyCb4hFq+tIN6Xx+V0m123iE9BpvPRPDDWTOgfB5ZY5ujcPu3oY9VSceP5T9fse+epRrWgEeo7vZ0T0ndbxPaGAmA7AXEf5mCconCaJ2mK2QpJH/Mstrgi4Z9NLST6RpSeduXYx7EysQ7y0BZh3xohkm1jToZTR45iGMeGCL9hdjmOMLa4RYfF9+A+NQgk5eNSK0HckcSEBWPvADvSaa3Ha22slJ0jZFkbOtKCp17vvkXduiRFCO0V x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4bb5a770-00a3-4fbe-6b20-08d56d983794 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DM5PR21MB0507; x-ms-traffictypediagnostic: DM5PR21MB0507: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(80524489315369)(10436049006162)(189930954265078)(131327999870524)(67672495146484)(211936372134217)(153496737603132)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR21MB0507; BCL:0; PCL:0; RULEID:; SRVR:DM5PR21MB0507; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39860400002)(366004)(39380400002)(346002)(13464003)(189003)(199004)(6346003)(110136005)(105586002)(8936002)(4326008)(236005)(9686003)(33656002)(8676002)(606006)(97736004)(54906003)(72206003)(93886005)(81156014)(81166006)(7696005)(2906002)(53546011)(102836004)(6506007)(22452003)(74316002)(53936002)(790700001)(76176011)(106356001)(6116002)(5660300001)(316002)(86362001)(2950100002)(8990500004)(7736002)(68736007)(6246003)(575784001)(3280700002)(86612001)(25786009)(14454004)(8666007)(3660700001)(55016002)(186003)(2900100001)(10290500003)(10090500001)(6306002)(478600001)(99286004)(229853002)(966005)(77096007)(6436002)(54896002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR21MB0507; H:DM5PR21MB0827.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Gabriel.Montenegro@microsoft.com; x-microsoft-antispam-message-info: sul36D13sqP+PHEkEFYixXKSID3dY5h86PRY1u0r9JJ3q5rTDPGzKEVtHO0fEU3yvoV3ma7rAF1LTfVrvH4Szw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR21MB0827F647B613184ED4D34C4E95FD0DM5PR21MB0827namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4bb5a770-00a3-4fbe-6b20-08d56d983794 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 19:31:27.6342 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0507 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, 06 Feb 2018 19:31:34 -0000 --_000_DM5PR21MB0827F647B613184ED4D34C4E95FD0DM5PR21MB0827namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEsIGdvb2QgcGxhY2UgdG8gc3RhcnQNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsYW4gRnJpbmRlbGwNClNlbnQ6IDUgRmVicnVhcnks IDIwMTggMTY6NTMNClRvOiBFcmljIEtpbm5lYXIgPGVraW5uZWFyQGFwcGxlLmNvbT47IEphbmEg SXllbmdhciA8anJpQGdvb2dsZS5jb20+DQpDYzogTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9y Zz47IE1hcmsgTm90dGluZ2hhbSA8bW5vdEBtbm90Lm5ldD47IFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+OyBSb2JlcnRvIFBlb24gPGZl bml4QGZiLmNvbT4NClN1YmplY3Q6IFJlOiBDYWxsIGZvciBBZG9wdGlvbjogUUNSQU0NCg0KKzEg Zm9yIGFkb3B0aW9uDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVo YWxmIG9mIEVyaWMgS2lubmVhciA8ZWtpbm5lYXJAYXBwbGUuY29tPg0KRGF0ZTogTW9uZGF5LCBG ZWJydWFyeSA1LCAyMDE4IGF0IDE6NTUgUE0NClRvOiBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUu Y29tPg0KQ2M6IExhcnMgRWdnZXJ0IDxsYXJzQGVnZ2VydC5vcmc+LCBNYXJrIE5vdHRpbmdoYW0g PG1ub3RAbW5vdC5uZXQ+LCBRVUlDIFdHIDxxdWljQGlldGYub3JnPiwgTWlrZSBCaXNob3AgPG1i aXNob3BAZXZlcXVlZm91LmJlPiwgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+DQpTdWJqZWN0 OiBSZTogQ2FsbCBmb3IgQWRvcHRpb246IFFDUkFNDQoNCisxIGZvciBhZG9wdGlvbiwgSSB0aGlu ayB0aGlzIGlzIGEgZ29vZCBzdGFydGluZyBwb2ludCBmb3IgZm9sZGluZyBpbiBwaWVjZXMgb2Yg dGhlIG90aGVyIHByb3Bvc2Fscy4NCg0KVGhhbmtzLA0KRXJpYw0KDQoNCk9uIEZlYiA1LCAyMDE4 LCBhdCAxMjowMSBQTSwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdv b2dsZS5jb20+PiB3cm90ZToNCg0KKzEgZm9yIGFkb3B0aW9uLg0KDQpPbiBNb24sIEZlYiA1LCAy MDE4IGF0IDExOjA1IEFNLCBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbTxtYWlsdG86ZmVuaXhA ZmIuY29tPj4gd3JvdGU6DQpBZ3JlZWQuDQpTdXBwb3J0ZWQuDQotPVINCg0KT24gMi81LzE4LCAx MTowNCBBTSwgIlFVSUMgb24gYmVoYWxmIG9mIE1pa2UgQmlzaG9wIiA8cXVpYy1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBtYmlzaG9w QGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3cm90ZToNCg0KICAg IEkgc3VwcG9ydCBhZG9wdGlvbiAtLSBpdCdzIGEgdXNlZnVsIHN0YXJ0aW5nIHBvaW50IGZyb20g d2hpY2ggd2UgY2FuIGRpc2N1c3Mgd2hhdCBlbGVtZW50cyBvZiBvdGhlciBwcm9wb3NhbHMgYXJl IHdvcnRoIGxpZnRpbmcgaW50byB0aGlzIG1vZGVsLg0KDQogICAgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCiAgICBGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWFyayBOb3R0aW5naGFt DQogICAgU2VudDogU3VuZGF5LCBGZWJydWFyeSA0LCAyMDE4IDEwOjA4IFBNDQogICAgVG86IFFV SUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KICAgIENjOiBMYXJz IEVnZ2VydCA8bGFyc0BlZ2dlcnQub3JnPG1haWx0bzpsYXJzQGVnZ2VydC5vcmc+Pg0KICAgIFN1 YmplY3Q6IENhbGwgZm9yIEFkb3B0aW9uOiBRQ1JBTQ0KDQogICAgSW4gTWVsYm91cm5lLCB0aGVy ZSB3YXMgc3Ryb25nIHN1cHBvcnQgKHdpdGggYSBzbWFsbCBhbW91bnQgb2YgcHVzaGJhY2sgd2hp Y2ggd2FzIGRpc2N1c3NlZCkgZm9yIGFkb3B0aW5nIFFDUkFNOg0KDQogICAgaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19o dG1sX2RyYWZ0LTJEa3Jhc2ljLTJEcXVpYy0yRHFjcmFtLTJEMDQmZD1Ed0lGQWcmYz01VkQwUlR0 TmxUaDN5Y2Q0MWIzTVV3JnI9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZtPTlDTDJEelJDcnZwV1JF U2VxUXplQkpXbUE1Q3NnanVfdF9tQU05VGtydjgmcz1ZVXQtZXRmUlVSekpBVTNLazNNaC02M1hz azZFcXQ2anQzX05tc2hOcm8wJmU9PGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUy RnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEa3Jh c2ljLTJEcXVpYy0yRHFjcmFtLTJEMDQlMjZkJTNERHdJRkFnJTI2YyUzRDVWRDBSVHRObFRoM3lj ZDQxYjNNVXclMjZyJTNEQzBzVW8tTEZOQmFZZnlvYUNzZjZUQSUyNm0lM0Q5Q0wyRHpSQ3J2cFdS RVNlcVF6ZUJKV21BNUNzZ2p1X3RfbUFNOVRrcnY4JTI2cyUzRFlVdC1ldGZSVVJ6SkFVM0trM01o LTYzWHNrNkVxdDZqdDNfTm1zaE5ybzAlMjZlJTNEJmRhdGE9MDIlN0MwMSU3Q0dhYnJpZWwuTW9u dGVuZWdybyU0MG1pY3Jvc29mdC5jb20lN0M2MmQ2ODkyODY3NWM0NTgxZDMyNzA4ZDU2Y2ZiZjZi MCU3Q2VlMzMwM2Q3ZmI3MzRiMGM4NTg5YmNkODQ3ZjFjMjc3JTdDMSU3QzAlN0M2MzY1MzQ3NTE3 OTc0MTAzMzImc2RhdGE9TmtEMEs0SVBTN3MlMkI1Tzg1T1puT1lxQkZkSTM1ZTlnZjdPbm5PN3pY eHcwJTNEJnJlc2VydmVkPTA+DQoNCiAgICBBbnkgb2JqZWN0aW9ucyAvIGNvbmNlcm5zIGFib3V0 IGRvaW5nIHNvPyBVbmxlc3Mgd2UgaGVhciBvdGhlcndpc2UsIHdlJ2xsIGFkb3B0IGF0IHRoZSBl bmQgb2YgdGhlIHdlZWsuDQoNCiAgICBDaGVlcnMsDQoNCiAgICAtLQ0KICAgIE1hcmsgTm90dGlu Z2hhbSAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3Lm1ub3QubmV0XyZkPUR3SUZBZyZjPTVWRDBSVHRObFRoM3ljZDQxYjNNVXcmcj1DMHNV by1MRk5CYVlmeW9hQ3NmNlRBJm09OUNMMkR6UkNydnBXUkVTZXFRemVCSldtQTVDc2dqdV90X21B TTlUa3J2OCZzPTlzeDFiQmg2ZGQ0RDRMbWFTb1dSalE2bWxaemxVX05lUGJsMGttdm5YSEUmZT08 aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ1cmxkZWZlbnNlLnByb29mcG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMt M0FfX3d3dy5tbm90Lm5ldF8lMjZkJTNERHdJRkFnJTI2YyUzRDVWRDBSVHRObFRoM3ljZDQxYjNN VXclMjZyJTNEQzBzVW8tTEZOQmFZZnlvYUNzZjZUQSUyNm0lM0Q5Q0wyRHpSQ3J2cFdSRVNlcVF6 ZUJKV21BNUNzZ2p1X3RfbUFNOVRrcnY4JTI2cyUzRDlzeDFiQmg2ZGQ0RDRMbWFTb1dSalE2bWxa emxVX05lUGJsMGttdm5YSEUlMjZlJTNEJmRhdGE9MDIlN0MwMSU3Q0dhYnJpZWwuTW9udGVuZWdy byU0MG1pY3Jvc29mdC5jb20lN0M2MmQ2ODkyODY3NWM0NTgxZDMyNzA4ZDU2Y2ZiZjZiMCU3Q2Vl MzMwM2Q3ZmI3MzRiMGM4NTg5YmNkODQ3ZjFjMjc3JTdDMSU3QzAlN0M2MzY1MzQ3NTE3OTc0MTAz MzImc2RhdGE9QVF6MkclMkZRWjExUGlWMUlneHJZWHFrbkhlblJoZEpsWVRPUkE4QnA0OXNNJTNE JnJlc2VydmVkPTA+DQoNCg0KDQo= --_000_DM5PR21MB0827F647B613184ED4D34C4E95FD0DM5PR21MB0827namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJZdSBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNCAwIDAgMCAw IDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFl1IEdv dGhpYyI7DQoJcGFub3NlLTE6MiAxMSA0IDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MSwgZ29vZCBwbGFjZSB0byBzdGFydDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5BbGFuIEZyaW5kZWxsPGJyPg0KPGI+ U2VudDo8L2I+IDUgRmVicnVhcnksIDIwMTggMTY6NTM8YnI+DQo8Yj5Ubzo8L2I+IEVyaWMgS2lu bmVhciAmbHQ7ZWtpbm5lYXJAYXBwbGUuY29tJmd0OzsgSmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29v Z2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IExhcnMgRWdnZXJ0ICZsdDtsYXJzQGVnZ2VydC5v cmcmZ3Q7OyBNYXJrIE5vdHRpbmdoYW0gJmx0O21ub3RAbW5vdC5uZXQmZ3Q7OyBRVUlDIFdHICZs dDtxdWljQGlldGYub3JnJmd0OzsgTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJl Jmd0OzsgUm9iZXJ0byBQZW9uICZsdDtmZW5peEBmYi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBDYWxsIGZvciBBZG9wdGlvbjogUUNSQU08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiYjNDM7MSBmb3IgYWRvcHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlFVSUMgJmx0O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDsg b24gYmVoYWxmIG9mIEVyaWMgS2lubmVhciAmbHQ7ZWtpbm5lYXJAYXBwbGUuY29tJmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5Nb25kYXksIEZlYnJ1YXJ5IDUsIDIwMTggYXQgMTo1NSBQTTxicj4NCjxi PlRvOiA8L2I+SmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzog PC9iPkxhcnMgRWdnZXJ0ICZsdDtsYXJzQGVnZ2VydC5vcmcmZ3Q7LCBNYXJrIE5vdHRpbmdoYW0g Jmx0O21ub3RAbW5vdC5uZXQmZ3Q7LCBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OywgTWlr ZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0OywgUm9iZXJ0byBQZW9uICZsdDtm ZW5peEBmYi5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBDYWxsIGZvciBBZG9wdGlv bjogUUNSQU08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+JiM0MzsxIGZvciBhZG9wdGlvbiwgSSB0aGluayB0aGlzIGlzIGEgZ29vZCBzdGFydGlu ZyBwb2ludCBmb3IgZm9sZGluZyBpbiBwaWVjZXMgb2YgdGhlIG90aGVyIHByb3Bvc2Fscy4mbmJz cDsNCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXJp YzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiA1LCAyMDE4LCBhdCAxMjowMSBQ TSwgSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWlsdG86anJpQGdvb2dsZS5jb20iPmpyaUBn b29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mIzQzOzEgZm9yIGFkb3B0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBGZWIgNSwgMjAxOCBhdCAxMTowNSBBTSwg Um9iZXJ0byBQZW9uICZsdDs8YSBocmVmPSJtYWlsdG86ZmVuaXhAZmIuY29tIiB0YXJnZXQ9Il9i bGFuayI+ZmVuaXhAZmIuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+QWdyZWVkLjxicj4NClN1cHBvcnRl ZC48YnI+DQotPVI8YnI+DQo8YnI+DQpPbiAyLzUvMTgsIDExOjA0IEFNLCAmcXVvdDtRVUlDIG9u IGJlaGFsZiBvZiBNaWtlIEJpc2hvcCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91 bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxh IGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSI+bWJpc2hvcEBldmVxdWVmb3UuYmU8 L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEkgc3VwcG9ydCBhZG9wdGlv biAtLSBpdCdzIGEgdXNlZnVsIHN0YXJ0aW5nIHBvaW50IGZyb20gd2hpY2ggd2UgY2FuIGRpc2N1 c3Mgd2hhdCBlbGVtZW50cyBvZiBvdGhlciBwcm9wb3NhbHMgYXJlIHdvcnRoIGxpZnRpbmcgaW50 byB0aGlzIG1vZGVsLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQombmJzcDsgJm5ic3A7IEZyb206IFFVSUMgW21haWx0bzo8YSBocmVmPSJt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP biBCZWhhbGYgT2YgTWFyayBOb3R0aW5naGFtPGJyPg0KJm5ic3A7ICZuYnNwOyBTZW50OiBTdW5k YXksIEZlYnJ1YXJ5IDQsIDIwMTggMTA6MDggUE08YnI+DQombmJzcDsgJm5ic3A7IFRvOiBRVUlD IFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KJm5ic3A7ICZuYnNwOyBDYzogTGFycyBFZ2dlcnQgJmx0OzxhIGhyZWY9Im1haWx0 bzpsYXJzQGVnZ2VydC5vcmciPmxhcnNAZWdnZXJ0Lm9yZzwvYT4mZ3Q7PGJyPg0KJm5ic3A7ICZu YnNwOyBTdWJqZWN0OiBDYWxsIGZvciBBZG9wdGlvbjogUUNSQU08YnI+DQo8YnI+DQombmJzcDsg Jm5ic3A7IEluIE1lbGJvdXJuZSwgdGhlcmUgd2FzIHN0cm9uZyBzdXBwb3J0ICh3aXRoIGEgc21h bGwgYW1vdW50IG9mIHB1c2hiYWNrIHdoaWNoIHdhcyBkaXNjdXNzZWQpIGZvciBhZG9wdGluZyBR Q1JBTTo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5z ZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX190b29scy5pZXRmLm9y Z19odG1sX2RyYWZ0LTJEa3Jhc2ljLTJEcXVpYy0yRHFjcmFtLTJEMDQlMjZkJTNERHdJRkFnJTI2 YyUzRDVWRDBSVHRObFRoM3ljZDQxYjNNVXclMjZyJTNEQzBzVW8tTEZOQmFZZnlvYUNzZjZUQSUy Nm0lM0Q5Q0wyRHpSQ3J2cFdSRVNlcVF6ZUJKV21BNUNzZ2p1X3RfbUFNOVRrcnY4JTI2cyUzRFlV dC1ldGZSVVJ6SkFVM0trM01oLTYzWHNrNkVxdDZqdDNfTm1zaE5ybzAlMjZlJTNEJmFtcDtkYXRh PTAyJTdDMDElN0NHYWJyaWVsLk1vbnRlbmVncm8lNDBtaWNyb3NvZnQuY29tJTdDNjJkNjg5Mjg2 NzVjNDU4MWQzMjcwOGQ1NmNmYmY2YjAlN0NlZTMzMDNkN2ZiNzM0YjBjODU4OWJjZDg0N2YxYzI3 NyU3QzElN0MwJTdDNjM2NTM0NzUxNzk3NDEwMzMyJmFtcDtzZGF0YT1Oa0QwSzRJUFM3cyUyQjVP ODVPWm5PWXFCRmRJMzVlOWdmN09ubk83elh4dzAlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGtyYXNpYy0yRHF1aWMtMkRxY3JhbS0y RDA0JmFtcDtkPUR3SUZBZyZhbXA7Yz01VkQwUlR0TmxUaDN5Y2Q0MWIzTVV3JmFtcDtyPUMwc1Vv LUxGTkJhWWZ5b2FDc2Y2VEEmYW1wO209OUNMMkR6UkNydnBXUkVTZXFRemVCSldtQTVDc2dqdV90 X21BTTlUa3J2OCZhbXA7cz1ZVXQtZXRmUlVSekpBVTNLazNNaC02M1hzazZFcXQ2anQzX05tc2hO cm8wJmFtcDtlPTwvYT48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEFueSBvYmplY3Rpb25zIC8g Y29uY2VybnMgYWJvdXQgZG9pbmcgc28/IFVubGVzcyB3ZSBoZWFyIG90aGVyd2lzZSwgd2UnbGwg YWRvcHQgYXQgdGhlIGVuZCBvZiB0aGUgd2Vlay48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IENo ZWVycyw8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IC0tPGJyPg0KJm5ic3A7ICZuYnNwOyBNYXJr IE5vdHRpbmdoYW0mbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLnByb29m cG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMtM0FfX3d3dy5tbm90Lm5ldF8lMjZkJTNE RHdJRkFnJTI2YyUzRDVWRDBSVHRObFRoM3ljZDQxYjNNVXclMjZyJTNEQzBzVW8tTEZOQmFZZnlv YUNzZjZUQSUyNm0lM0Q5Q0wyRHpSQ3J2cFdSRVNlcVF6ZUJKV21BNUNzZ2p1X3RfbUFNOVRrcnY4 JTI2cyUzRDlzeDFiQmg2ZGQ0RDRMbWFTb1dSalE2bWxaemxVX05lUGJsMGttdm5YSEUlMjZlJTNE JmFtcDtkYXRhPTAyJTdDMDElN0NHYWJyaWVsLk1vbnRlbmVncm8lNDBtaWNyb3NvZnQuY29tJTdD NjJkNjg5Mjg2NzVjNDU4MWQzMjcwOGQ1NmNmYmY2YjAlN0NlZTMzMDNkN2ZiNzM0YjBjODU4OWJj ZDg0N2YxYzI3NyU3QzElN0MwJTdDNjM2NTM0NzUxNzk3NDEwMzMyJmFtcDtzZGF0YT1BUXoyRyUy RlFaMTFQaVYxSWd4cllYcWtuSGVuUmhkSmxZVE9SQThCcDQ5c00lM0QmYW1wO3Jlc2VydmVkPTAi IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5tbm90Lm5ldF8mYW1wO2Q9RHdJRkFnJmFtcDtjPTVWRDBSVHRObFRo M3ljZDQxYjNNVXcmYW1wO3I9QzBzVW8tTEZOQmFZZnlvYUNzZjZUQSZhbXA7bT05Q0wyRHpSQ3J2 cFdSRVNlcVF6ZUJKV21BNUNzZ2p1X3RfbUFNOVRrcnY4JmFtcDtzPTlzeDFiQmg2ZGQ0RDRMbWFT b1dSalE2bWxaemxVX05lUGJsMGttdm5YSEUmYW1wO2U9PC9hPjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM5PR21MB0827F647B613184ED4D34C4E95FD0DM5PR21MB0827namp_-- From nobody Tue Feb 6 12:48:30 2018 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 DBE3F12D945 for ; Tue, 6 Feb 2018 12:48:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, 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=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 uc6SbTQtyrtc for ; Tue, 6 Feb 2018 12:48:11 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31B9312D940 for ; Tue, 6 Feb 2018 12:48:10 -0800 (PST) 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=SwDR8zkZDJ8QkaC/GxJsdQPsY8aOh3TEzCzvDM9bo+g=; b=XB/OfLHohoC+NfbEBT8JCzGpAdKmZ8ONMOs+6jy0aXVkhq3iPwYEuSgReEXGwjQpfaDZZimOFwXfqHW4fAJmPrbrPkOG5nB9t+iXZlMh1+s+OkTAiwMR6hLp2zDg+P0xI6DSUsxjobgoUUTUr+JC+VfEsdt+6X8BOh4HSyDsLHM= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0119.namprd21.prod.outlook.com (10.173.189.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.485.2; Tue, 6 Feb 2018 20:48:08 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Tue, 6 Feb 2018 20:48:08 +0000 From: Praveen Balasubramanian To: Jana Iyengar , Mike Bishop CC: Ted Hardie , Mark Nottingham , Spencer Dawkins at IETF , Lars Eggert , "Brian Trammell (IETF)" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , QUIC WG Subject: RE: Call for Adoption: Invariants Thread-Topic: Call for Adoption: Invariants Thread-Index: AQHTnketpPPeU/jidk6aOHbvjAdkY6OVb7kAgAALu4CAAK9GgIABTZeAgABDrICAAAOdgIAABIKAgAAWxJA= Date: Tue, 6 Feb 2018 20:48:08 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0119; 7:PZ0Oa51qmok0j7P4u+RcJWVP1FutDO83ODzGEIYZGizkE9YA01wFMYcZY8T4LtgQN23ZJbPKs1bzjBzrnCi1CgVha45Jnq3etyFmX+cVN+AA3KQdrJrcuzpGNK51Gt1kKW3LoOBL9Zlm7m1G0wA73QKCIj/tKqrP6qQUnO9x9obG8+6RziV80A7UXwlVK0LOpvC3ybEaV4KwnAkkG3AahLChEp5PxU+mxv9sPMK1bEX/ApjJs2RI2LCuLZdW8OB0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ef23515c-fabd-4f50-593e-08d56da2ee11 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0119; x-ms-traffictypediagnostic: CY4PR21MB0119: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(189930954265078)(85827821059158)(100405760836317)(219752817060721)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0119; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0119; x-forefront-prvs: 0575F81B58 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(39860400002)(376002)(396003)(366004)(189003)(51444003)(199004)(74316002)(19609705001)(68736007)(236005)(7696005)(53546011)(8990500004)(7736002)(478600001)(33656002)(3280700002)(14454004)(8936002)(99286004)(10290500003)(8676002)(55016002)(5660300001)(10090500001)(2906002)(97736004)(606006)(81166006)(4326008)(81156014)(110136005)(54906003)(2950100002)(186003)(6436002)(93886005)(106356001)(76176011)(86612001)(22452003)(3660700001)(6116002)(86362001)(229853002)(105586002)(316002)(25786009)(6306002)(9686003)(39060400002)(77096007)(790700001)(54896002)(102836004)(6246003)(2900100001)(53936002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0119; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: gc+0x4BHoqWuaC3aDagBKq62R2ICnE+WOeENmFwfzp47qR2Gk+2T4J6UgtYMlJEujMsfT3+QqWOce2RAGljTCA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133BB3C3554E0096A7BBDF9B6FD0CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ef23515c-fabd-4f50-593e-08d56da2ee11 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2018 20:48:08.7445 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0119 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, 06 Feb 2018 20:48:15 -0000 --_000_CY4PR21MB0133BB3C3554E0096A7BBDF9B6FD0CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24g4oCcVGhlIFFVSUMgdHJhbnNwb3J0IGRyYWZ0IHNwZWNpZmljYWxseSBkb2VzIG5vdCBz YXkgYW55dGhpbmcgYWJvdXQgd2hpY2ggVURQIHBvcnRzIGFyZSB0byBiZSB1c2VkIC0tIFFVSUMg aXMgYSB0cmFuc3BvcnQgYWZ0ZXIgYWxsLCBhbmQgdGhlcmUgaXMgbm8gcmVhc29uIHRvIHRpZSB0 aGUgZW50aXJlIHRyYW5zcG9ydCB0byBhIHBvcnQu4oCdDQoNCkZyb206IFFVSUMgW21haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKYW5hIEl5ZW5nYXINClNlbnQ6IFR1 ZXNkYXksIEZlYnJ1YXJ5IDYsIDIwMTggMTE6MjYgQU0NClRvOiBNaWtlIEJpc2hvcCA8bWJpc2hv cEBldmVxdWVmb3UuYmU+DQpDYzogVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPjsgTWFy ayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PjsgU3BlbmNlciBEYXdraW5zIGF0IElFVEYgPHNw ZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPjsgTGFycyBFZ2dlcnQgPGxhcnNAZWdnZXJ0Lm9y Zz47IEJyaWFuIFRyYW1tZWxsIChJRVRGKSA8aWV0ZkB0cmFtbWVsbC5jaD47IE1pa2tlbCBGYWhu w7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogQ2FsbCBmb3IgQWRvcHRpb246IEludmFyaWFudHMNCg0KV2hhdCBN aWtlIHNhaWQgLS0gVURQLzQ0MyB3YXMgYWxsb2NhdGVkIGZvciBIVFRQIG92ZXIgVURQLCBidXQg aXMgbm90IHJlcXVpcmVkIGZvciBIVFRQL1FVSUMuIFRoZSBIVFRQIG1hcHBpbmcgZG9jdW1lbnQg Y3VycmVudGx5IHNheXMgKGluIFNlY3Rpb24gMi4xPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGcXVpY3dnLmdpdGh1Yi5pbyUy RmJhc2UtZHJhZnRzJTJGZHJhZnQtaWV0Zi1xdWljLWh0dHAuaHRtbCUyM3JmYy5zZWN0aW9uLjIu MSZkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MxODg4NWQ2ZWMwMTU0MDM3 NTAzMjA4ZDU2ZDk3N2RhZSU3Q2VlMzMwM2Q3ZmI3MzRiMGM4NTg5YmNkODQ3ZjFjMjc3JTdDMSU3 QzAlN0M2MzY1MzU0MTk4MDU2NzE1OTgmc2RhdGE9JTJCMGglMkIxbWVBVHM4cmNGJTJGNjZUYiUy QnZ4c2hURkZVTExmd3F3b0h4dXk2Q2IwJTNEJnJlc2VydmVkPTA+KSAiU2VydmVycyBNQVkgc2Vy dmUgSFRUUC9RVUlDIG9uIGFueSBVRFAgcG9ydC4iIFdlIGNhbiBkaXNjdXNzIHRoaXMsIGJ1dCBs ZXQncyBtb3ZlIHRoYXQgZGlzY3Vzc2lvbiB0byB3aGVyZSBpdCBiZWxvbmdzLCBvbiAjNDk1PGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGaXNzdWVzJTJGNDk1JmRh dGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzE4ODg1ZDZlYzAxNTQwMzc1MDMy MDhkNTZkOTc3ZGFlJTdDZWUzMzAzZDdmYjczNGIwYzg1ODliY2Q4NDdmMWMyNzclN0MxJTdDMCU3 QzYzNjUzNTQxOTgwNTY4MTEzMiZzZGF0YT1hbXM0Qmg1dDNybGR6aDR1b2s2WUp2R2xueDhvMFI3 RUxBb2dROGlJSzU0JTNEJnJlc2VydmVkPTA+Lg0KDQpUaGUgUVVJQyB0cmFuc3BvcnQgZHJhZnQg c3BlY2lmaWNhbGx5IGRvZXMgbm90IHNheSBhbnl0aGluZyBhYm91dCB3aGljaCBVRFAgcG9ydHMg YXJlIHRvIGJlIHVzZWQgLS0gUVVJQyBpcyBhIHRyYW5zcG9ydCBhZnRlciBhbGwsIGFuZCB0aGVy ZSBpcyBubyByZWFzb24gdG8gdGllIHRoZSBlbnRpcmUgdHJhbnNwb3J0IHRvIGEgcG9ydC4NCg0K DQpPbiBUdWUsIEZlYiA2LCAyMDE4IGF0IDExOjA5IEFNLCBNaWtlIEJpc2hvcCA8bWJpc2hvcEBl dmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj4gd3JvdGU6DQpUd28gbm90 ZXMsIG9uZSBhZ2FpbnN0IGludGVyZXN0OiAgVGhhdCBQUiBpcyBvbGQgYW5kIGN1cnJlbnRseSBw YXJrZWQsIGJlY2F1c2Ugd2UgZG9u4oCZdCBoYXZlIGNvbnNlbnN1cyBhbmQgaXTigJlzIGxlc3Mg dXJnZW50LiAgQW5kIHNlY29uZGx5LCBVRFAvNDQzIGlzIGFscmVhZHkgYWxsb2NhdGVkIGJ5IElB TkEgZm9yIEhUVFAgb3ZlciBVRFAuDQoNCkZyb206IFRlZCBIYXJkaWUgW21haWx0bzp0ZWQuaWV0 ZkBnbWFpbC5jb208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT5dDQpTZW50OiBUdWVzZGF5LCBG ZWJydWFyeSA2LCAyMDE4IDEwOjU3IEFNDQpUbzogU3BlbmNlciBEYXdraW5zIGF0IElFVEYgPHNw ZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPG1haWx0bzpzcGVuY2VyZGF3a2lucy5pZXRmQGdt YWlsLmNvbT4+DQpDYzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzpt YmlzaG9wQGV2ZXF1ZWZvdS5iZT4+OyBCcmlhbiBUcmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1l bGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+PjsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNl biA8bWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+PjsgUVVJQyBX RyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBNYXJrIE5vdHRpbmdoYW0g PG1ub3RAbW5vdC5uZXQ8bWFpbHRvOm1ub3RAbW5vdC5uZXQ+PjsgTGFycyBFZ2dlcnQgPGxhcnNA ZWdnZXJ0Lm9yZzxtYWlsdG86bGFyc0BlZ2dlcnQub3JnPj4NClN1YmplY3Q6IFJlOiBDYWxsIGZv ciBBZG9wdGlvbjogSW52YXJpYW50cw0KDQpPbiBUdWUsIEZlYiA2LCAyMDE4IGF0IDY6NTQgQU0s IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbTxt YWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNCkFza2luZyB3aXRo IG5vIGhhdCwgYnV0IC4uLg0KDQpPbiBNb24sIEZlYiA1LCAyMDE4IGF0IDE6MDAgUE0sIE1pa2Ug QmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+ PiB3cm90ZToNCkkgc3VwcG9ydCBhZG9wdGlvbi4gIFRoZSB3YXkgdG8gY2hhbmdlIHRoZSBpbnZh cmlhbnRzIHdpbGwgYmUgdG8gbWludCBhIG5ldyBwcm90b2NvbCwgYW5kIG5vdCBjbGFpbSB0aGF0 IHlvdXIgbmV3IHByb3RvY29sIGlzIGEgdmVyc2lvbiBvZiBRVUlDLiAgSWYgaXQgaGFwcGVucyB0 byBiZSBzdGFydGxpbmdseSBzaW1pbGFyLCBhbGwgd2VsbCBhbmQgZ29vZC4NCg0KSWYgeW91IHJv bGwgYSBuZXcgcHJvdG9jb2wsIHRoYXQncyBub3QgYSB2ZXJzaW9uIG9mIFFVSUMsIGlzIGl0IG9i dmlvdXMgdG8gZXZlcnlvbmUgYnV0IG1lIHdoZXRoZXIgeW91IGNhbiBydW4gYm90aCBwcm90b2Nv bHMgb24gVURQLzQ0Mz8NCg0KDQpNaWtlIEJpc2hvcCdzIFBSIGRlZmluaW5nIGh0dHBxIGFzIGEg c2NoZW1lIChodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMzQ4PGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGcHVsbCUyRjM0OCZkYXRh PTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MxODg4NWQ2ZWMwMTU0MDM3NTAzMjA4 ZDU2ZDk3N2RhZSU3Q2VlMzMwM2Q3ZmI3MzRiMGM4NTg5YmNkODQ3ZjFjMjc3JTdDMSU3QzAlN0M2 MzY1MzU0MTk4MDU2ODExMzImc2RhdGE9d1RERzVmbXVwWEpSUlNGcm9OeUJScGNidXdqUXp6NWZY cyUyQjQxRjZEaGVBJTNEJnJlc2VydmVkPTA+KSBkZWZpbmVzIFVEUCA0NDMgYXMgdGhlIGRlZmF1 bHQgZm9yIGh0dHBxLiAgSSB0aGluayB0aGF0IHByZXR0eSBtdWNoIGFzc2VydHMgdGhhdCBVRFAv NDQzIGlzIFFVSUMsIG5vdCBhIGZvcmtlZCB2YXJpYW50Lg0KDQpJIHRob3VnaHQgSSByZW1lbWJl cmVkIHRoYXQgVURQLzQ0MyB3YXMgY2hvc2VuIGJlY2F1c2UgZmlyZXdhbGxzIG9mdGVuIHBhc3Mg cG9ydCA0NDMsIHNvIHRoYXQgYWlkcyBkZXBsb3ltZW50LiBIZW5jZSwgbXkgcXVlc3Rpb24uDQoN Cg0KWWVzLiAgVGhhdCBtYXkgY2F1c2UgdXMgdG8gY29uc2lkZXIgY2FyZWZ1bGx5IHdoZXRoZXIg VURQLzQ0MyBvdWdodCB0byBiZSBkZWZpbmVkIGZvciBRVUlDIG1vcmUgcmF0aGVyIHRoYW4gSFRU UCBvdmVyIFFVSUMsIG9yIGV2ZW4gbW9yZSBnZW5lcmFsbHkuDQpUZWQNCg0KDQpUaGFua3MsDQoN ClNwZW5jZXINCg0KDQo= --_000_CY4PR21MB0133BB3C3554E0096A7BBDF9B6FD0CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m IzQzOzEgb24g4oCcVGhlIFFVSUMgdHJhbnNwb3J0IGRyYWZ0IHNwZWNpZmljYWxseSBkb2VzIG5v dCBzYXkgYW55dGhpbmcgYWJvdXQgd2hpY2ggVURQIHBvcnRzIGFyZSB0byBiZSB1c2VkIC0tIFFV SUMgaXMgYSB0cmFuc3BvcnQgYWZ0ZXIgYWxsLCBhbmQgdGhlcmUgaXMgbm8gcmVhc29uIHRvIHRp ZSB0aGUgZW50aXJlIHRyYW5zcG9ydCB0byBhIHBvcnQu4oCdPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5P biBCZWhhbGYgT2YNCjwvYj5KYW5hIEl5ZW5nYXI8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwg RmVicnVhcnkgNiwgMjAxOCAxMToyNiBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0 O21iaXNob3BAZXZlcXVlZm91LmJlJmd0Ozxicj4NCjxiPkNjOjwvYj4gVGVkIEhhcmRpZSAmbHQ7 dGVkLmlldGZAZ21haWwuY29tJmd0OzsgTWFyayBOb3R0aW5naGFtICZsdDttbm90QG1ub3QubmV0 Jmd0OzsgU3BlbmNlciBEYXdraW5zIGF0IElFVEYgJmx0O3NwZW5jZXJkYXdraW5zLmlldGZAZ21h aWwuY29tJmd0OzsgTGFycyBFZ2dlcnQgJmx0O2xhcnNAZWdnZXJ0Lm9yZyZndDs7IEJyaWFuIFRy YW1tZWxsIChJRVRGKSAmbHQ7aWV0ZkB0cmFtbWVsbC5jaCZndDs7IE1pa2tlbCBGYWhuw7hlIErD uHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZndDs7IFFVSUMNCiBXRyAmbHQ7cXVpY0Bp ZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IENhbGwgZm9yIEFkb3B0aW9uOiBJ bnZhcmlhbnRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IE1pa2Ugc2FpZCAt LSBVRFAvNDQzIHdhcyBhbGxvY2F0ZWQgZm9yIEhUVFAgb3ZlciBVRFAsIGJ1dCBpcyBub3QgcmVx dWlyZWQgZm9yIEhUVFAvUVVJQy4mbmJzcDs8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyMjIyMjI7YmFj a2dyb3VuZDp3aGl0ZSI+VGhlIEhUVFAgbWFwcGluZyBkb2N1bWVudCBjdXJyZW50bHkgc2F5cyAo aW4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZxdWljd2cuZ2l0aHViLmlvJTJGYmFzZS1k cmFmdHMlMkZkcmFmdC1pZXRmLXF1aWMtaHR0cC5odG1sJTIzcmZjLnNlY3Rpb24uMi4xJmFtcDtk YXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MxODg4NWQ2ZWMwMTU0MDM3NTAz MjA4ZDU2ZDk3N2RhZSU3Q2VlMzMwM2Q3ZmI3MzRiMGM4NTg5YmNkODQ3ZjFjMjc3JTdDMSU3QzAl N0M2MzY1MzU0MTk4MDU2NzE1OTgmYW1wO3NkYXRhPSUyQjBoJTJCMW1lQVRzOHJjRiUyRjY2VGIl MkJ2eHNoVEZGVUxMZndxd29IeHV5NkNiMCUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMTE1NUNDO2JhY2tncm91bmQ6d2hpdGUiPlNlY3Rpb24NCiAyLjE8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5kOndoaXRlIj4pICZxdW90O1Nl cnZlcnMgTUFZIHNlcnZlIEhUVFAvUVVJQyBvbiBhbnkgVURQIHBvcnQuJnF1b3Q7IFdlIGNhbiBk aXNjdXNzIHRoaXMsIGJ1dCBsZXQncyBtb3ZlIHRoYXQgZGlzY3Vzc2lvbiB0byB3aGVyZSBpdCBi ZWxvbmdzLCBvbiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJh c2UtZHJhZnRzJTJGaXNzdWVzJTJGNDk1JmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jv c29mdC5jb20lN0MxODg4NWQ2ZWMwMTU0MDM3NTAzMjA4ZDU2ZDk3N2RhZSU3Q2VlMzMwM2Q3ZmI3 MzRiMGM4NTg5YmNkODQ3ZjFjMjc3JTdDMSU3QzAlN0M2MzY1MzU0MTk4MDU2ODExMzImYW1wO3Nk YXRhPWFtczRCaDV0M3JsZHpoNHVvazZZSnZHbG54OG8wUjdFTEFvZ1E4aUlLNTQlM0QmYW1wO3Jl c2VydmVkPTAiPiM0OTU8L2E+Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+VGhlIFFVSUMgdHJh bnNwb3J0IGRyYWZ0IHNwZWNpZmljYWxseSBkb2VzIG5vdCBzYXkgYW55dGhpbmcgYWJvdXQgd2hp Y2ggVURQIHBvcnRzIGFyZSB0byBiZSB1c2VkIC0tIFFVSUMgaXMgYSB0cmFuc3BvcnQgYWZ0ZXIg YWxsLCBhbmQgdGhlcmUgaXMgbm8gcmVhc29uIHRvIHRpZSB0aGUgZW50aXJlIHRyYW5zcG9ydCB0 byBhIHBvcnQuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDYsIDIwMTggYXQgMTE6MDkgQU0sIE1pa2Ug QmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdldD0i X2JsYW5rIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ud28g bm90ZXMsIG9uZSBhZ2FpbnN0IGludGVyZXN0OiZuYnNwOyBUaGF0IFBSIGlzIG9sZCBhbmQgY3Vy cmVudGx5IHBhcmtlZCwgYmVjYXVzZSB3ZSBkb27igJl0IGhhdmUgY29uc2Vuc3VzIGFuZCBpdOKA mXMgbGVzcyB1cmdlbnQuJm5ic3A7IEFuZCBzZWNvbmRseSwgVURQLzQ0MyBpcyBhbHJlYWR5IGFs bG9jYXRlZCBieSBJQU5BDQogZm9yIEhUVFAgb3ZlciBVRFAuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj5Gcm9tOjwvYj4gVGVkIEhhcmRpZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzp0 ZWQuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj50ZWQuaWV0ZkBnbWFpbC5jb208L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDYsIDIwMTggMTA6NTcgQU08 YnI+DQo8Yj5Ubzo8L2I+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGICZsdDs8YSBocmVmPSJtYWls dG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5zcGVuY2Vy ZGF3a2lucy5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEJpc2hv cCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFu ayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OzsgQnJpYW4gVHJhbW1lbGwgKElFVEYpICZs dDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaCIgdGFyZ2V0PSJfYmxhbmsiPmlldGZA dHJhbW1lbGwuY2g8L2E+Jmd0OzsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdt YWlsLmNvbTwvYT4mZ3Q7Ow0KIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7OyBNYXJrIE5vdHRpbmdo YW0gJmx0OzxhIGhyZWY9Im1haWx0bzptbm90QG1ub3QubmV0IiB0YXJnZXQ9Il9ibGFuayI+bW5v dEBtbm90Lm5ldDwvYT4mZ3Q7OyBMYXJzIEVnZ2VydCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNA ZWdnZXJ0Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmxhcnNAZWdnZXJ0Lm9yZzwvYT4mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBDYWxsIGZvciBBZG9wdGlvbjogSW52YXJpYW50czxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFR1ZSwgRmViIDYsIDIwMTggYXQgNjo1NCBB TSwgU3BlbmNlciBEYXdraW5zIGF0IElFVEYgJmx0OzxhIGhyZWY9Im1haWx0bzpzcGVuY2VyZGF3 a2lucy5pZXRmQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnNwZW5jZXJkYXdraW5zLmlldGZA Z21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Bc2tpbmcgd2l0aCBubyBoYXQsIGJ1 dCAuLi48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24gTW9uLCBG ZWIgNSwgMjAxOCBhdCAxOjAwIFBNLCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1i aXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGlu O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHN1cHBvcnQg YWRvcHRpb24uJm5ic3A7IFRoZSB3YXkgdG8gY2hhbmdlIHRoZSBpbnZhcmlhbnRzIHdpbGwgYmUg dG8gbWludCBhIG5ldyBwcm90b2NvbCwgYW5kIG5vdCBjbGFpbSB0aGF0IHlvdXIgbmV3IHByb3Rv Y29sIGlzIGEgdmVyc2lvbiBvZiBRVUlDLiZuYnNwOyBJZiBpdCBoYXBwZW5zIHRvIGJlIHN0YXJ0 bGluZ2x5DQogc2ltaWxhciwgYWxsIHdlbGwgYW5kIGdvb2QuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgeW91IHJvbGwg YSBuZXcgcHJvdG9jb2wsIHRoYXQncyBub3QgYSB2ZXJzaW9uIG9mIFFVSUMsIGlzIGl0IG9idmlv dXMgdG8gZXZlcnlvbmUgYnV0IG1lIHdoZXRoZXIgeW91IGNhbiBydW4gYm90aCBwcm90b2NvbHMg b24gVURQLzQ0Mz8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1p a2UgQmlzaG9wJ3MgUFIgZGVmaW5pbmcgaHR0cHEgYXMgYSBzY2hlbWUgKDxhIGhyZWY9Imh0dHBz Oi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJG JTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGcHVsbCUyRjM0OCZhbXA7ZGF0 YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMTg4ODVkNmVjMDE1NDAzNzUwMzIw OGQ1NmQ5NzdkYWUlN0NlZTMzMDNkN2ZiNzM0YjBjODU4OWJjZDg0N2YxYzI3NyU3QzElN0MwJTdD NjM2NTM1NDE5ODA1NjgxMTMyJmFtcDtzZGF0YT13VERHNWZtdXBYSlJSU0Zyb055QlJwY2J1d2pR eno1ZlhzJTJCNDFGNkRoZUElM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvMzQ4PC9hPikNCiBkZWZpbmVz IFVEUCA0NDMgYXMgdGhlIGRlZmF1bHQgZm9yIGh0dHBxLiZuYnNwOyBJIHRoaW5rIHRoYXQgcHJl dHR5IG11Y2ggYXNzZXJ0cyB0aGF0IFVEUC80NDMgaXMgUVVJQywgbm90IGEgZm9ya2VkIHZhcmlh bnQuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhvdWdodCBJIHJlbWVtYmVyZWQg dGhhdCBVRFAvNDQzIHdhcyBjaG9zZW4gYmVjYXVzZSBmaXJld2FsbHMgb2Z0ZW4gcGFzcyBwb3J0 IDQ0Mywgc28gdGhhdCBhaWRzIGRlcGxveW1lbnQuIEhlbmNlLCBteSBxdWVzdGlvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5ZZXMuJm5ic3A7IFRoYXQgbWF5IGNhdXNl IHVzIHRvIGNvbnNpZGVyIGNhcmVmdWxseSB3aGV0aGVyIFVEUC80NDMgb3VnaHQgdG8gYmUgZGVm aW5lZCBmb3IgUVVJQyBtb3JlIHJhdGhlciB0aGFuIEhUVFAgb3ZlciBRVUlDLCBvciBldmVuIG1v cmUgZ2VuZXJhbGx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGJyPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U3BlbmNlcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0133BB3C3554E0096A7BBDF9B6FD0CY4PR21MB0133namp_-- From nobody Tue Feb 6 15:00:43 2018 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 7937512DA3F for ; Tue, 6 Feb 2018 15:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 sOviqQryD3Vx for ; Tue, 6 Feb 2018 15:00:34 -0800 (PST) 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 9B15712DA4C for ; Tue, 6 Feb 2018 15:00:34 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id m84so2582582ywd.5 for ; Tue, 06 Feb 2018 15:00:34 -0800 (PST) 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=/ggAHmHIBfeYljleYXXruvDHM9OkA0rKp488tUuBhTs=; b=idvqal8PurKrWuqIqJXcAPmmNbm5lAHwYEd/wRh36m0/cZkMVPqe2CAy3Vhx/Q53Lk 6XW2ZDtNmqLiHQ6oYXhbuWQ9n9Kp15FrJJFVLGoZ0rDhqy5qpL2o/jsyCKPSHPVPWuhf hyqEZWjEoUcwKsupQUpFTqjmF34EhbMp6Q1XFS4oiMXeVTjebn4U0l+yrzPMzdPbNNAB OYJWwIeYWagF+r75jCdrLywgNUJKFPIGL/7+SVMb6F7olbhKh7/qOyUPTGKVUqDnS2Eu gtQuEa/mN4hJP24b3HymJwewgB+2B3tnWbZOL05bkIEpFAovpXXLsPdTFM3cYODUP1gs aQqQ== 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=/ggAHmHIBfeYljleYXXruvDHM9OkA0rKp488tUuBhTs=; b=jL222zkc8bYuXafBlezNSS4KX3RVJIj88ZUwIjNj8zAzjg8dl7Sgz6Anz7q1AvhWwJ 7h/3v5TBCryaAFb1ToqkIAO6nmLTuyj7SjJa1Ex4RhL9rEtEWNBri6HyQAVIA2Hw8Ox1 037sIFoZ6Du+k5YhVpxJIats5ta8M2RtRerbWMH94kgRQLPJP0x3llPopQSiY3zcSTgx TPy2FV+VtOmhsSH5vEG5+VrIl94G6ZX3GGpndvUGBDcLcVG/p4A+4LD1vbkt+9Rzfs7y FBu3lzrDo9Livhsfuy7BUy8hPsvI59uznpRdenGKrvFLiU9Y3sAiJk8F3Bnfbdx69b6/ H6tw== X-Gm-Message-State: APf1xPDq+nSmV11d6WbzQK0/iwH5NiH4zyLdPQDuqknrIZlNX2VB65Gf 51sD14CXImogn/vBNHALI82OqCTsyIXEFEKOSjkyrA== X-Google-Smtp-Source: AH8x225gfHFXHg8MY0m47a6qIbY19d6KHAnrWO0M+WxGybRSyABwyGrUWsf0OGRv9JgjvzyOm//j38Kt1QMsc55nIik= X-Received: by 10.37.125.131 with SMTP id y125mr2671199ybc.186.1517958033252; Tue, 06 Feb 2018 15:00:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Tue, 6 Feb 2018 15:00:32 -0800 (PST) In-Reply-To: References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> From: Jana Iyengar Date: Tue, 6 Feb 2018 15:00:32 -0800 Message-ID: Subject: Re: Packet number encryption To: Mike Bishop Cc: Stephen Farrell , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "Brian Trammell (IETF)" , Praveen Balasubramanian , QUIC WG , Roberto Peon , "Lubashev, Igor" , "Salz, Rich" Content-Type: multipart/alternative; boundary="001a114e326e5c023005649325d2" 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, 06 Feb 2018 23:00:37 -0000 --001a114e326e5c023005649325d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm going to try a different attempt at moving towards convergence. Thinking about this some more, and picking up something that Mirja said way earlier in this thread, I think the following decomposition is useful. 1. In the transport, all packet numbers start at 0, increasing monotonically. ACK frames carry these packet numbers, and therefore do not have to span large gaps and do not have to deal with increases in the size of the largest acked. Basically, no gaps are visible within the transport processing engine. 2. Before sending a packet on the wire, and before processing the packet, QUIC transforms the packet number with some function, replacing the visible packet number with the transformed value. I think we can all agree that (1) is goodness. A sender is also free to use packet numbers from non-contiguous spaces here FWIW, but that's entirely independent of what's visible on the wire. This helps me separate transport processing complexity from the rest of it, which I think is helpful. I think we are disagreeing on the precise properties we want from the transformation in (2). If we can agree on these properties, we can then figure out whether it's possible and how to construct such a transform. Here's a union of what folks are concerned about: 1. Packet number must be unlinkable across connection ID change (for migration.) 2. Packet number must start at an arbitrary value, to avoid ossification of the first packet number. 3. Some sequencing information -- a few bits of the packet number perhaps -- should be revealed (for monitoring. Number of bits TBD.) 4. Any packet number transformation should not be compute intensive. I'm not looking for a construction, but I'd like to agree on the problem first. Does this sound like the set of properties we want? Or is there a contradiction among these properties that I'm not seeing? On Tue, Feb 6, 2018 at 9:56 AM, Mike Bishop wrote: > Packet number encryption *does* improve linkability equivalently to rando= m > jumps, but without the fragmentation of the ACK packet which those jumps > otherwise cause. So I'm with Stephen, we don't yet have agreement on tha= t > assertion. > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Tuesday, February 6, 2018 7:35 AM > To: Mirja K=C3=BChlewind ; Mikkel Fahn= =C3=B8e > J=C3=B8rgensen ; Brian Trammell (IETF) ; > Jana Iyengar > Cc: Praveen Balasubramanian ; QUIC WG ; > Roberto Peon ; Lubashev, Igor ; Salz, > Rich > Subject: Re: Packet number encryption > > > > On 06/02/18 15:23, Mirja K=C3=BChlewind wrote: > > > > It's also my understanding that we do agree that packet number > > encryption does not help likability (and thereby privacy) a lot, or at > > least that the benefits we might get (or not) do not justify the > > additional complexity. > > FWIW, which isn't much, I don't (yet) agree to the above. > I reckon it'll be a while before we know how linkability pans out. I do > agree that packet number encryption is not a panacea for unlinkability, b= ut > it may help, or may even end up being required, to do a good job wrt > linkability. > > I also heard people say it was less complex for them so "additional > complexity" may also not be quite right. (I guess "differently complex" i= s > correct though.) > > S. > > -- > PGP key change time for me. > New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > NewWithOld sigs in keyservers. > Sorry if that mucks something up;-) > --001a114e326e5c023005649325d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm going to try a different attempt at moving towards= convergence.=C2=A0Thinking about this some more, and picking up something = that Mirja said way earlier in this thread, I think the following decomposi= tion is useful.

1. In the transport, all packet numbers = start at 0, increasing monotonically. ACK frames carry these packet numbers= , and therefore do not have to span large gaps and do not have to deal with= increases in the size of the largest acked. Basically, no gaps are visible= within the transport processing engine.
2. Before sending a pack= et on the wire, and before processing the packet, QUIC transforms the packe= t number with some function, replacing the visible packet number with the t= ransformed value.

I think we can all agree tha= t (1) is goodness. A sender is also free to use packet numbers from non-con= tiguous spaces here FWIW, but that's entirely independent of what's= visible on the wire. This helps me separate transport processing complexit= y from the rest of it, which I think is helpful.

I= think we are disagreeing on the precise properties we want from the transf= ormation in (2). If we can agree on these properties, we can then figure ou= t whether it's possible and how to construct such a transform. Here'= ;s a union of what folks are concerned about:
1. Packet number mu= st be unlinkable across connection ID change (for migration.)
2. = Packet number must start at an arbitrary value, to avoid ossification of th= e first packet number.
3. Some sequencing information -- a few bi= ts of the packet number perhaps -- should be revealed (for monitoring. Numb= er of bits TBD.)
4. Any packet number transformation should not b= e compute intensive.

I'm not looking for a con= struction, but I'd like to agree on the problem first. Does this sound = like the set of properties we want? Or is there a contradiction among these= properties that I'm not seeing?
=
On Tue, Feb 6, 2018 at 9:56 AM, Mike Bishop = <mbishop@evequefou.be> wrote:
Packet number encryption *does* improve linkability equivalently to = random jumps, but without the fragmentation of the ACK packet which those j= umps otherwise cause.=C2=A0 So I'm with Stephen, we don't yet have = agreement on that assertion.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Stephen Farrell
Sent: Tuesday, February 6, 2018 7:35 AM
To: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Mikkel Fahn=C3=B8e J=C3= =B8rgensen <mikkelfj@gmail.com= >; Brian Trammell (IETF) <ietf@tr= ammell.ch>; Jana Iyengar <jri@g= oogle.com>
Cc: Praveen Balasubramanian <prav= b@microsoft.com>; QUIC WG <quic@= ietf.org>; Roberto Peon <fenix@fb= .com>; Lubashev, Igor <ilu= bashe@akamai.com>; Salz, Rich <rsalz@akamai.com>
Subject: Re: Packet number encryption



On 06/02/18 15:23, Mirja K= =C3=BChlewind wrote:
>
> It's also my understanding that we do agree that packet number
> encryption does not help likability (and thereby privacy) a lot, or at=
> least that the benefits we might get (or not) do not justify the
> additional complexity.

FWIW, which isn't much, I don't (yet) agree to the above.
I reckon it'll be a while before we know how linkability pans out. I do= agree that packet number encryption is not a panacea for unlinkability, bu= t it may help, or may even end up being required, to do a good job wrt link= ability.

I also heard people say it was less complex for them so "additional co= mplexity" may also not be quite right. (I guess "differently comp= lex" is correct though.)

S.

--
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

--001a114e326e5c023005649325d2-- From nobody Tue Feb 6 15:58:42 2018 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 13A3F124BAC for ; Tue, 6 Feb 2018 15:58:42 -0800 (PST) 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, 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=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 lxQK7oF5PUrW for ; Tue, 6 Feb 2018 15:58:39 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 88845127871 for ; Tue, 6 Feb 2018 15:58:39 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id x25so1781912pge.3 for ; Tue, 06 Feb 2018 15:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=s2DZmeWJhrDP8C6lqmxQk6SNLmOM/WoLhuSZ/UoAJsg=; b=n5gvNDeRUI0aGtKi00tGYugK4xn7vtwrhKoSTuv04ZQiiBQP/9HKnA777pa0d7/lgk nvBU3Lb0iREJKkIHjkzP8xfQmLeLdwcgNUPAA940i4fYTZM51f7X9cVCfQ2pTLmEyLW+ OwiePUcznci8Z4SMujwcs/qLKLct5DxmAMNMmfIoyMnVqt1OfydgGe+nEO+CxAhw6bzA oqDUYJoj2kKg986B1o9FlIBVNS5EFFtEHDudLHksSiL8snew79hgg+U84boUzZkcxleU pfs8NVdPuEueYGG0pnVwB+16JBXmFUN4fwGm88dlYovZai5Iy5FBKzP0eu+VEpviAIHV 8Cow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=s2DZmeWJhrDP8C6lqmxQk6SNLmOM/WoLhuSZ/UoAJsg=; b=q649Gk8LwxJT2FDobPZKnzB5nk1A2TxPC4MtbDI+G6KPW9P+tPEArLFmrIThhajrmm fhUYa1F14mx3mLAUHZMUlv8Cil8eVhROD0h3uUD8XlW4xx5MUJNaP1AdBDfw/2sDz9y0 owTnyaPcU9sgeyPOMRziqafGGjJkDvuCmvxESFx6YtPwlLudUGqE+j4W7GUGWfJ2D9U8 SE/4rQoLdb5Cc/WqH/G0zL2MDpycdwjgi2myb7voPfRxdowb/DacdYQnuGFxrH5SAkxn TeOo38bKaEbelBWSTAJUiT03PpH2wdezIS84czGIxxIALSxdBXS7rkNmfBY2L8uJb6b4 zcjw== X-Gm-Message-State: APf1xPAv2TeEvTfYFSZHOLukWkl1t6ZWxQVjB8if76wAk1Iybo0qOCgs VOOC8O2DMLTUw8AF5+r0/UI= X-Google-Smtp-Source: AH8x225x/c6b5BHqA/PGrTmpYAylKdEuhu2ZzduKWPJ/39yb815jeYBxG0q/A2LDsASA6oiDD7/KlA== X-Received: by 10.99.142.66 with SMTP id k63mr3243372pge.278.1517961519156; Tue, 06 Feb 2018 15:58:39 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id b84sm295490pfj.11.2018.02.06.15.58.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 15:58:37 -0800 (PST) From: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Kazuho Oku CC: "Brian Trammell (IETF)" , QUIC WG Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) Thread-Topic: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) Thread-Index: AQHTn1cqSR45mit5E0WzVadd6SuPAaOXdfgAgAAYvoCAAH9ldw== X-MS-Exchange-MessageSentRepresentingType: 2 Date: Tue, 6 Feb 2018 23:58:33 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB17661B9957DF90733FA28EC5ACFD0DB6PR10MB1766EURP_" 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: Tue, 06 Feb 2018 23:58:42 -0000 --_000_DB6PR10MB17661B9957DF90733FA28EC5ACFD0DB6PR10MB1766EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I actually think a static 1KB table of Pi could work quite well. A subset of samples could be indexed in a hashtable and yield loss data ear= ly with some probability. Some samples would miss due to reordering or loss= . If more exact analysis is wanted the levenshtein distance of a sample seq= uence against Pi from a synced offset would tell a lot about the data. Or D= NA sequencing. This could be hardware optimized. Yet, transmission is always just the next bit in the Pi table. Since Pi is effectively random it will ebentually detect mutations if the o= bserved sequence is long enough. Wrt privacy, the CID may be used as a start offset hash into the Pi table. There isn't any need to cover a full RTT worth of Pi bits unless it is used= for latency detection, but in that case the spin could be a pattern like 1= 0101010 and 00001111 injected into the Pi sequence. A separate spin bit wou= ld be simpler. ________________________________ From: Kazuho Oku Sent: Tuesday, February 6, 2018 5:22:35 PM To: Mikkel Fahn=F8e J=F8rgensen Cc: Brian Trammell (IETF); QUIC WG Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet = number encryption) 2018-02-06 23:54 GMT+09:00 Mikkel Fahn=F8e J=F8rgensen = : > This idea can be taken further: You can modulate the signal so you use > multiple packets to encode a zero or a one for half the wave duration. Fo= r > example 1 could be encoded as 0101 over four packets and zero could be > encoded as 0011 over four packets. > If there is any reordering, it would show up as an unexpected value in th= e > pulse. That's definitely an option. Actually, I considered using sin wave (that distributes the error among 1-bit samples) as an example instead of the square wave. The primary reason behind my preference to using a square wave is that it is easier to implement; in fact, emitting a square wave with the length of 512 packets is as easy as just taking the 9th bit (counting from LSB) of the packet number (if we forget about the gaps for a moment). -- Kazuho Oku --_000_DB6PR10MB17661B9957DF90733FA28EC5ACFD0DB6PR10MB1766EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I actually think a static 1KB table of Pi coul= d work quite well.

A subset of samples could be indexed in a hash= table and yield loss data early with some probability. Some samples would m= iss due to reordering or loss. If more exact analysis is wanted the levensh= tein distance of a sample sequence against Pi from a synced offset would tell a lot about the data. Or DNA se= quencing. This could be hardware optimized.

Yet, transmission is always just the next bit = in the Pi table.

Since Pi is effectively random it will ebentua= lly detect mutations if the observed sequence is long enough.

Wrt privacy, the CID may be used as a start of= fset hash into the Pi table.

There isn’t any need to cover a full RTT= worth of Pi bits unless it is used for latency detection, but in that case= the spin could be a pattern like 10101010 and 00001111 injected into the P= i sequence. A separate spin bit would be simpler.


From: Kazuho Oku <kazu= hooku@gmail.com>
Sent: Tuesday, February 6, 2018 5:22:35 PM
To: Mikkel Fahn=F8e J=F8rgensen
Cc: Brian Trammell (IETF); QUIC WG
Subject: Re: Explicit measurability in the QUIC wire image (was Re: = Packet number encryption)
 
2018-02-06 23:54 GMT+09:00 Mikkel Fahn=F8e J= =F8rgensen <mikkelfj@gmail.com>:
> This idea can be taken further: You can modulate the signal so you use=
> multiple packets to encode a zero or a one for half the wave duration.= For
> example 1 could be encoded as 0101 over four packets and zero could be=
> encoded as 0011 over four packets.
> If there is any reordering, it would show up as an unexpected value in= the
> pulse.

That's definitely an option.

Actually, I considered using sin wave (that distributes the error
among 1-bit samples) as an example instead of the square wave.

The primary reason behind my preference to using a square wave is that
it is easier to implement; in fact, emitting a square wave with the
length of 512 packets is as easy as just taking the 9th bit (counting
from LSB) of the packet number (if we forget about the gaps for a
moment).


--
Kazuho Oku
 --_000_DB6PR10MB17661B9957DF90733FA28EC5ACFD0DB6PR10MB1766EURP_-- From nobody Tue Feb 6 16:10:54 2018 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 9C14B12DA1A for ; Tue, 6 Feb 2018 16:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 hK_Pi-X0jgbc for ; Tue, 6 Feb 2018 16:10:49 -0800 (PST) Received: from mail-pl0-x241.google.com (mail-pl0-x241.google.com [IPv6:2607:f8b0:400e:c01::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 B2CF81242EA for ; Tue, 6 Feb 2018 16:10:49 -0800 (PST) Received: by mail-pl0-x241.google.com with SMTP id ay8so2327439plb.4 for ; Tue, 06 Feb 2018 16:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=v6Js9Hpo5MSqZzI2pDiDVglu79X2l1aUg/OQGDFJ/FM=; b=Rs3oE/IKjiJcoqnAS7EVkab/TL618FdjaqzJgnklVHencGdUnd3Unq6jmUaLOGO0h9 9+I+/Z38P+NiiKVgp2IUKqIl4nM3ZWZkpC5cEhD2sfBCxqsimc1vU+F2yLdh5iuhLWy6 T/b7Ae1R59J1BWhGIkzgIs2wFbP6NfQnU2gxmdxaFHLKYP/EzXR6/E2Lxo1jGJnRLTq9 BHUG9HSH6wEOsGGtv1lt9KzVnnaP9/XNUdVRBgFD9yUW/dpAjtlN5jDFgX3Gz2YCEjDZ +TpMzv0a8j3IW0T5akGNE1fuirZ92paY8N+raTnMVguGPhW7oDk9xL0VU/2MAxdwW8qz KFSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=v6Js9Hpo5MSqZzI2pDiDVglu79X2l1aUg/OQGDFJ/FM=; b=HtYIe0MTXPJKAeR7cBAEAEc1o3uE+tnaluSSi/9Pp5oE/ni8p52wMtjIlN9D9hBcf3 SXWN3mXZY0HX0Sty/q6r5wMgzS6pwaCIkA5J+H5FiaPCxcRti0PiDoaFj538lK3+V2pq nyk1zrp2Anj0pbU2tiVcwxeLKaY/237j4qOZeIzRTrsWGZQf08yPv+6ARrCKPT8Jzyb6 LVx8QkwHxMmejCejxotWxKyBswp+HIPk09pl++XgZ/0tZNTg9Rkhg2ptx7ljHvRAlqBW XDF8QGEZg/PhbI8/WXArPGuGph0zhZzhJQiizWqLRoxGt8eetYj9sIF7jcL2oZWIuju3 wD6w== X-Gm-Message-State: APf1xPBR34XmE2Fy/IzbHlZDJrQIVJn0FYXStQ313Vf+gK5tc/Hoq6lc nGUxzhH0zQpjXLA41QOCiZ0= X-Google-Smtp-Source: AH8x2266zAlAQp26US7dZs+pxw75IF4fUvb94gBZeYyKMp/VVApJ15d76KULr49ISnadY8OU5oniyw== X-Received: by 2002:a17:902:b104:: with SMTP id q4-v6mr4136044plr.143.1517962249394; Tue, 06 Feb 2018 16:10:49 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id y17sm307209pfk.67.2018.02.06.16.10.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 16:10:48 -0800 (PST) From: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Jana Iyengar , Mike Bishop CC: Stephen Farrell , =?iso-8859-1?Q?Mirja_K=FChlewind?= , "Brian Trammell (IETF)" , Praveen Balasubramanian , QUIC WG , Roberto Peon , "Lubashev, Igor" , "Salz, Rich" Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AWdzZj0zCJVGNsv3EmSkq0r1tERDAUJGNDQ4QW1HTGRkYmQ4Y2dGTmZTREUyNEEzMDZFMTU1MjQzNUM5NDR3M3h3RzNGQkI4MEU1MzBGQ0E5QzQ0NmYwMDUyMzAyOTc0M1FBVTBOMEVFMDBBNHJVcVE2TUdhNzRENDJnMWRGNqt9wcKAgAADUYCAACdFAIAAVRYAgAATm1Q= X-MS-Exchange-MessageSentRepresentingType: 2 Date: Wed, 7 Feb 2018 00:10:42 +0000 Message-ID: References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB1766F4CAD36D6098F9F69AA7ACFC0DB6PR10MB1766EURP_" 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, 07 Feb 2018 00:10:53 -0000 --_000_DB6PR10MB1766F4CAD36D6098F9F69AA7ACFC0DB6PR10MB1766EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sounds reasonable to me. You could add that the transformation should be sp= ace efficient. ________________________________ From: Jana Iyengar Sent: Wednesday, February 7, 2018 12:00:32 AM To: Mike Bishop Cc: Stephen Farrell; Mirja K=FChlewind; Mikkel Fahn=F8e J=F8rgensen; Brian = Trammell (IETF); Praveen Balasubramanian; QUIC WG; Roberto Peon; Lubashev, = Igor; Salz, Rich Subject: Re: Packet number encryption I'm going to try a different attempt at moving towards convergence. Thinkin= g about this some more, and picking up something that Mirja said way earlie= r in this thread, I think the following decomposition is useful. 1. In the transport, all packet numbers start at 0, increasing monotonicall= y. ACK frames carry these packet numbers, and therefore do not have to span= large gaps and do not have to deal with increases in the size of the large= st acked. Basically, no gaps are visible within the transport processing en= gine. 2. Before sending a packet on the wire, and before processing the packet, Q= UIC transforms the packet number with some function, replacing the visible = packet number with the transformed value. I think we can all agree that (1) is goodness. A sender is also free to use= packet numbers from non-contiguous spaces here FWIW, but that's entirely i= ndependent of what's visible on the wire. This helps me separate transport = processing complexity from the rest of it, which I think is helpful. I think we are disagreeing on the precise properties we want from the trans= formation in (2). If we can agree on these properties, we can then figure o= ut whether it's possible and how to construct such a transform. Here's a un= ion of what folks are concerned about: 1. Packet number must be unlinkable across connection ID change (for migrat= ion.) 2. Packet number must start at an arbitrary value, to avoid ossification of= the first packet number. 3. Some sequencing information -- a few bits of the packet number perhaps -= - should be revealed (for monitoring. Number of bits TBD.) 4. Any packet number transformation should not be compute intensive. I'm not looking for a construction, but I'd like to agree on the problem fi= rst. Does this sound like the set of properties we want? Or is there a cont= radiction among these properties that I'm not seeing? On Tue, Feb 6, 2018 at 9:56 AM, Mike Bishop > wrote: Packet number encryption *does* improve linkability equivalently to random = jumps, but without the fragmentation of the ACK packet which those jumps ot= herwise cause. So I'm with Stephen, we don't yet have agreement on that as= sertion. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On = Behalf Of Stephen Farrell Sent: Tuesday, February 6, 2018 7:35 AM To: Mirja K=FChlewind >; Mikkel Fahn=F8e J=F8rgensen >; Brian Trammell (IETF) >; Jana Iyengar > Cc: Praveen Balasubramanian >; QUIC WG >; Roberto Peon >; Lubashev, Igor >; Salz, Rich > Subject: Re: Packet number encryption On 06/02/18 15:23, Mirja K=FChlewind wrote: > > It's also my understanding that we do agree that packet number > encryption does not help likability (and thereby privacy) a lot, or at > least that the benefits we might get (or not) do not justify the > additional complexity. FWIW, which isn't much, I don't (yet) agree to the above. I reckon it'll be a while before we know how linkability pans out. I do agr= ee that packet number encryption is not a panacea for unlinkability, but it= may help, or may even end up being required, to do a good job wrt linkabil= ity. I also heard people say it was less complex for them so "additional complex= ity" may also not be quite right. (I guess "differently complex" is correct= though.) S. -- PGP key change time for me. New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. NewWithOld sigs in keyservers. Sorry if that mucks something up;-) --_000_DB6PR10MB1766F4CAD36D6098F9F69AA7ACFC0DB6PR10MB1766EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Sounds reasonable to me. You could add that th= e transformation should be space efficient.

From: Jana Iyengar <jri@= google.com>
Sent: Wednesday, February 7, 2018 12:00:32 AM
To: Mike Bishop
Cc: Stephen Farrell; Mirja K=FChlewind; Mikkel Fahn=F8e J=F8rgensen;= Brian Trammell (IETF); Praveen Balasubramanian; QUIC WG; Roberto Peon; Lub= ashev, Igor; Salz, Rich
Subject: Re: Packet number encryption
 
I'm going to try a different attempt at moving towards con= vergence. Thinking about this some more, and picking up something that= Mirja said way earlier in this thread, I think the following decomposition= is useful.

1. In the transport, all packet numbers start at 0, increasing monoton= ically. ACK frames carry these packet numbers, and therefore do not have to= span large gaps and do not have to deal with increases in the size of the = largest acked. Basically, no gaps are visible within the transport processing engine.
2. Before sending a packet on the wire, and before processing the pack= et, QUIC transforms the packet number with some function, replacing the vis= ible packet number with the transformed value.

I think we can all agree that (1) is goodness. A sender is also free t= o use packet numbers from non-contiguous spaces here FWIW, but that's entir= ely independent of what's visible on the wire. This helps me separate trans= port processing complexity from the rest of it, which I think is helpful.

I think we are disagreeing on the precise properties we want from the = transformation in (2). If we can agree on these properties, we can then fig= ure out whether it's possible and how to construct such a transform. Here's= a union of what folks are concerned about:
1. Packet number must be unlinkable across connection ID change (for m= igration.)
2. Packet number must start at an arbitrary value, to avoid ossificati= on of the first packet number.
3. Some sequencing information -- a few bits of the packet number perh= aps -- should be revealed (for monitoring. Number of bits TBD.)
4. Any packet number transformation should not be compute intensive.

I'm not looking for a construction, but I'd like to agree on the probl= em first. Does this sound like the set of properties we want? Or is there a= contradiction among these properties that I'm not seeing?

On Tue, Feb 6, 2018 at 9:56 AM, Mike Bishop <mbishop@evequ= efou.be> wrote:
Packet number encryption *does* improve linkability equivalently to random = jumps, but without the fragmentation of the ACK packet which those jumps ot= herwise cause.  So I'm with Stephen, we don't yet have agreement on th= at assertion.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Stephen Farrell
Sent: Tuesday, February 6, 2018 7:35 AM
To: Mirja K=FChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Mikkel Fahn=F8e J=F8rgensen= <mikkelfj@gmail.com>; Bria= n Trammell (IETF) <ietf@trammell.ch<= /a>>; Jana Iyengar <jri@google.com><= br> Cc: Praveen Balasubramanian <prav= b@microsoft.com>; QUIC WG <quic@= ietf.org>; Roberto Peon <fenix@fb= .com>; Lubashev, Igor <ilu= bashe@akamai.com>; Salz, Rich <rsalz@akamai.com>= ;
Subject: Re: Packet number encryption
On 06/02/18 15:23, Mirja K=FChlewind wrote:
>
> It's also my understanding that we do agree that packet number
> encryption does not help likability (and thereby privacy) a lot, or at=
> least that the benefits we might get (or not) do not justify the
> additional complexity.

FWIW, which isn't much, I don't (yet) agree to the above.
I reckon it'll be a while before we know how linkability pans out. I do agr= ee that packet number encryption is not a panacea for unlinkability, but it= may help, or may even end up being required, to do a good job wrt linkabil= ity.

I also heard people say it was less complex for them so "additional co= mplexity" may also not be quite right. (I guess "differently comp= lex" is correct though.)

S.

--
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

--_000_DB6PR10MB1766F4CAD36D6098F9F69AA7ACFC0DB6PR10MB1766EURP_-- From nobody Tue Feb 6 16:14:18 2018 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 D27AF12DA1A for ; Tue, 6 Feb 2018 16:14:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 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, URIBL_BLOCKED=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 KkmPQhs1T4jF for ; Tue, 6 Feb 2018 16:14:14 -0800 (PST) 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 0488A1242EA for ; Tue, 6 Feb 2018 16:14:14 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id v196so2689012ywc.6 for ; Tue, 06 Feb 2018 16:14:13 -0800 (PST) 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=f6jAW4CsRxQamotzpftf1KZtSYQ9ymg3qgWlcm34Ics=; b=dxm8HW8HgEwp3TaC2hEv3f3MOU3D3cGMpp3SIyaluN3B6fzgnWUXzpzhe236vS4/8x 439VuHVwMdHE1VTkgFHg2+MPkm0cKIxO/qi0qFkxkDbydpT9kDVHgiyQPBdCIR8iDLfC cKJ7zxLSKGkXe0E8U/SPs2MCZX3yni2NyOdxscxWbjWbP6pvhFrxfo8g6eb0UMn/ct40 RSCk++2gAEq4ygpAaNI0ytSv2UJqkcHVDc4zw5ULf6UBc02Gm7NN6AKzlTNmn7tkTjhO EwannDnrb+K0zZSOPJ6YZuq632zrC7fMN4tt/+aKFVptabgR3QpJY1vqMASqgEKcdOp5 xQNQ== 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=f6jAW4CsRxQamotzpftf1KZtSYQ9ymg3qgWlcm34Ics=; b=TdivS6K4Mxik5XT826XnMo9br9L2QFwStdsKt6NX30AqjwAnNMupVfEE61UAjRe2BN GVD6nBPhILY175B2PumOnfqe0ne/s5DrMVlpBKs1ev6IBBZ+ETPAtm573MhOSjMBODpF dw8zqoHmiDn3oVWB4Rs2zRDO7vOjNwUOXQFjCLk3a/8BJiosJK1zeLCcO5GoGG5hgbj7 rjGRhJBW2sFz36cO2Q59iA5j6lHtkXg44enGTNrAFAZl2N+vjSYXLKVlYUGvhta+8Gzm MY4qivCxIkWIHg1yn6WU0JUJT4EV6P3tsO6p/vP7bj1x1SvoQJeeT0oFhqqSpAs8ksst EQgg== X-Gm-Message-State: APf1xPCckh4mI3fVmUnvLV55BU3J1mxjRMuRm8CvsC8XxSbvGhOdFfPs ruywQbm17CByPzyQ6SmXpm4PMbfvryUkfU+k7cNVRw== X-Google-Smtp-Source: AH8x226IYjxYS2sau/5p0KjClHTndot4TxLzz2VIs+Ri+7HWEMF7DDhzr8gGtTPj30lOzEtEpt4YFBwl94NU99ZbDA4= X-Received: by 10.37.239.79 with SMTP id w15mr2650410ybm.293.1517962453135; Tue, 06 Feb 2018 16:14:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Tue, 6 Feb 2018 16:13:32 -0800 (PST) In-Reply-To: References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> From: Eric Rescorla Date: Tue, 6 Feb 2018 16:13:32 -0800 Message-ID: Subject: Re: Packet number encryption To: Jana Iyengar Cc: Mike Bishop , Praveen Balasubramanian , "Lubashev, Igor" , Roberto Peon , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , "Salz, Rich" , "Brian Trammell (IETF)" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Stephen Farrell Content-Type: multipart/alternative; boundary="089e0828a13ccd4c330564942cbb" 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, 07 Feb 2018 00:14:17 -0000 --089e0828a13ccd4c330564942cbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Feb 6, 2018 at 3:00 PM, Jana Iyengar wrote: > I'm going to try a different attempt at moving towards > convergence. Thinking about this some more, and picking up something that > Mirja said way earlier in this thread, I think the following decompositio= n > is useful. > > 1. In the transport, all packet numbers start at 0, increasing > monotonically. ACK frames carry these packet numbers, and therefore do no= t > have to span large gaps and do not have to deal with increases in the siz= e > of the largest acked. Basically, no gaps are visible within the transport > processing engine. > 2. Before sending a packet on the wire, and before processing the packet, > QUIC transforms the packet number with some function, replacing the visib= le > packet number with the transformed value. > > I think we can all agree that (1) is goodness. A sender is also free to > use packet numbers from non-contiguous spaces here FWIW, but that's > entirely independent of what's visible on the wire. This helps me separat= e > transport processing complexity from the rest of it, which I think is > helpful. > > I think we are disagreeing on the precise properties we want from the > transformation in (2). If we can agree on these properties, we can then > figure out whether it's possible and how to construct such a transform. > Here's a union of what folks are concerned about: > 1. Packet number must be unlinkable across connection ID change (for > migration.) > 2. Packet number must start at an arbitrary value, to avoid ossification > of the first packet number. > 3. Some sequencing information -- a few bits of the packet number perhaps > -- should be revealed (for monitoring. Number of bits TBD.) > I'm not sure I am persuaded of this point -Ekr > 4. Any packet number transformation should not be compute intensive. > > I'm not looking for a construction, but I'd like to agree on the problem > first. Does this sound like the set of properties we want? Or is there a > contradiction among these properties that I'm not seeing? > > On Tue, Feb 6, 2018 at 9:56 AM, Mike Bishop wrote: > >> Packet number encryption *does* improve linkability equivalently to >> random jumps, but without the fragmentation of the ACK packet which thos= e >> jumps otherwise cause. So I'm with Stephen, we don't yet have agreement= on >> that assertion. >> >> -----Original Message----- >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stephen Farrell >> Sent: Tuesday, February 6, 2018 7:35 AM >> To: Mirja K=C3=BChlewind ; Mikkel Fahn= =C3=B8e >> J=C3=B8rgensen ; Brian Trammell (IETF) ; >> Jana Iyengar >> Cc: Praveen Balasubramanian ; QUIC WG ; >> Roberto Peon ; Lubashev, Igor ; Salz, >> Rich >> Subject: Re: Packet number encryption >> >> >> >> On 06/02/18 15:23, Mirja K=C3=BChlewind wrote: >> > >> > It's also my understanding that we do agree that packet number >> > encryption does not help likability (and thereby privacy) a lot, or at >> > least that the benefits we might get (or not) do not justify the >> > additional complexity. >> >> FWIW, which isn't much, I don't (yet) agree to the above. >> I reckon it'll be a while before we know how linkability pans out. I do >> agree that packet number encryption is not a panacea for unlinkability, = but >> it may help, or may even end up being required, to do a good job wrt >> linkability. >> >> I also heard people say it was less complex for them so "additional >> complexity" may also not be quite right. (I guess "differently complex" = is >> correct though.) >> >> S. >> >> -- >> PGP key change time for me. >> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. >> NewWithOld sigs in keyservers. >> Sorry if that mucks something up;-) >> > > --089e0828a13ccd4c330564942cbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Feb 6, 2018 at 3:00 PM, Jana Iyengar <jri@google.com> wrote:
I'm going = to try a different attempt at moving towards convergence.=C2=A0Thinking abo= ut this some more, and picking up something that Mirja said way earlier in = this thread, I think the following decomposition is useful.

<= div>1. In the transport, all packet numbers start at 0, increasing monotoni= cally. ACK frames carry these packet numbers, and therefore do not have to = span large gaps and do not have to deal with increases in the size of the l= argest acked. Basically, no gaps are visible within the transport processin= g engine.
2. Before sending a packet on the wire, and before proc= essing the packet, QUIC transforms the packet number with some function, re= placing the visible packet number with the transformed value.

I think we can all agree that (1) is goodness. A sender is = also free to use packet numbers from non-contiguous spaces here FWIW, but t= hat's entirely independent of what's visible on the wire. This help= s me separate transport processing complexity from the rest of it, which I = think is helpful.

I think we are disagreeing on th= e precise properties we want from the transformation in (2). If we can agre= e on these properties, we can then figure out whether it's possible and= how to construct such a transform. Here's a union of what folks are co= ncerned about:
1. Packet number must be unlinkable across connect= ion ID change (for migration.)
2. Packet number must start at an = arbitrary value, to avoid ossification of the first packet number.
3. Som= e sequencing information -- a few bits of the packet number perhaps -- shou= ld be revealed (for monitoring. Number of bits TBD.)

I'm not sure I am persuaded of this point

-Ekr
=C2=A0
4. Any packet number transformation should not be co= mpute intensive.

I'm not looking for a constru= ction, but I'd like to agree on the problem first. Does this sound like= the set of properties we want? Or is there a contradiction among these pro= perties that I'm not seeing?

On Tue, = Feb 6, 2018 at 9:56 AM, Mike Bishop <mbishop@evequefou.be> wrote:
Packet number encryption *does* = improve linkability equivalently to random jumps, but without the fragmenta= tion of the ACK packet which those jumps otherwise cause.=C2=A0 So I'm = with Stephen, we don't yet have agreement on that assertion.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Tuesday, February 6, 2018 7:35 AM
To: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Mikkel= Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; Brian Trammell (IETF) <ietf@trammell.ch>; Ja= na Iyengar <jri@goog= le.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; QUIC WG <quic@ietf.org>; Roberto Peon <fenix@fb.com>; Lubashe= v, Igor <ilubas= he@akamai.com>; Salz, Rich <rsalz@akamai.com>
Subject: Re: Packet number encryption



On 06/02/18 15:23, Mirja K=C3=BChlewind wrote:
>
> It's also my understanding that we do agree that packet number
> encryption does not help likability (and thereby privacy) a lot, or at=
> least that the benefits we might get (or not) do not justify the
> additional complexity.

FWIW, which isn't much, I don't (yet) agree to the above.
I reckon it'll be a while before we know how linkability pans out. I do= agree that packet number encryption is not a panacea for unlinkability, bu= t it may help, or may even end up being required, to do a good job wrt link= ability.

I also heard people say it was less complex for them so "additional co= mplexity" may also not be quite right. (I guess "differently comp= lex" is correct though.)

S.

--
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


--089e0828a13ccd4c330564942cbb-- From nobody Tue Feb 6 16:29:24 2018 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 1368412DA1A for ; Tue, 6 Feb 2018 16:29:22 -0800 (PST) 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, 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=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 ouSA47tMN1H6 for ; Tue, 6 Feb 2018 16:29:20 -0800 (PST) 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 0860B126DFB for ; Tue, 6 Feb 2018 16:29:20 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id g2so1802735pgn.7 for ; Tue, 06 Feb 2018 16:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=UdP74149GAl+lbDMzQjabs8ZZaSxe5hU2LZraKhPNMQ=; b=KIhMoJmKbxl9ZC2E8mqcyTnNvzwIkhwLzPK6TvxR9igcRLNgjGDtyX55oNhgB7Yn13 6rR/21zbFGZkMMSPAX5Ahf5Qh46xN+pJVMOXruznCyzeOKgXTJPld6t/oCplEcyUuNPW LSIOlZfIqIAOa3k6qf47FQ0HASTafC30SlDpQJKG3MClBhclnKvnFlIucfSuc3lyOhmq HALlvHchwjOkSQlNerhjDn0aO/MJ5Coaoiosu4csgGakwIa+X9+nMepLqGN5yXri7At8 50CkkXU2Y7ZLdpiIvpDEhJVC5cb+YxPdxzDjNhKf1xpyTbdzJnv5uruKd/l3lSpy9REG 3qiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=UdP74149GAl+lbDMzQjabs8ZZaSxe5hU2LZraKhPNMQ=; b=JLzIaeHJyfuuBNyg67pCNjH3cQ4R73s2AHzjlDOr+7Vfy03axan1YCaAjCDGONBKBk Ag2qdAgFqsL/I7U1nvS5vmwXS3AHGcx/T1CxLToC3H5JoHVmhnVwueGJy4YSEesuUOiR CskRgWAyJL/b9aMEW7rXms5fn2VW+MUbOCQI1jC1yaU0nBI28cyLW96/8GDtgGlAfXUB wniu9qnBcrGx2I1ZbGmes48ng0wRk9ubXKMSsHzJia5ksgO72eVkcq3F2V8uemAF63uS NjWH8Oz8Lyrn/qRbkuru89Y2cF3pv/5wzS86ha1LebpLYomqDnLZ/a2vgafQ0Bvd0j9Y tbhA== X-Gm-Message-State: APf1xPByFAmpdH+d3Nb0LQI9/XK56ydTurJkCD3UcCAqWgF3CI7gVksd 5AbU5j7BpdhGpX3GbZqfP5o= X-Google-Smtp-Source: AH8x227LT+AXd1sAfNwo9SyUi6GLnl/Tm1QR9JsoQEOSZP7cyP+LzmmPhFhXoZZQWhPO4tYS47udwA== X-Received: by 10.98.247.25 with SMTP id h25mr4054058pfi.162.1517963359693; Tue, 06 Feb 2018 16:29:19 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id y131sm337915pfg.69.2018.02.06.16.29.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Feb 2018 16:29:18 -0800 (PST) From: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Kazuho Oku CC: "Brian Trammell (IETF)" , QUIC WG Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) Thread-Topic: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) Thread-Index: AQHTn1cqSR45mit5E0WzVadd6SuPAaOXdfgAgAAYvoCAAH9lgIAACJBJ X-MS-Exchange-MessageSentRepresentingType: 2 Date: Wed, 7 Feb 2018 00:29:12 +0000 Message-ID: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB176682C63A91007574BBEAECACFC0DB6PR10MB1766EURP_" 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, 07 Feb 2018 00:29:22 -0000 --_000_DB6PR10MB176682C63A91007574BBEAECACFC0DB6PR10MB1766EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Also note that this approach is insensitive to skipped packet numbers in op= timistic ACK attack defence. It leaks zero information when the network is = perfect and if the CID hash is random. ________________________________ From: Mikkel Fahn=F8e J=F8rgensen Sent: Wednesday, February 7, 2018 12:58:33 AM To: Kazuho Oku Cc: Brian Trammell (IETF); QUIC WG Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet = number encryption) I actually think a static 1KB table of Pi could work quite well. A subset of samples could be indexed in a hashtable and yield loss data ear= ly with some probability. Some samples would miss due to reordering or loss= . If more exact analysis is wanted the levenshtein distance of a sample seq= uence against Pi from a synced offset would tell a lot about the data. Or D= NA sequencing. This could be hardware optimized. Yet, transmission is always just the next bit in the Pi table. Since Pi is effectively random it will ebentually detect mutations if the o= bserved sequence is long enough. Wrt privacy, the CID may be used as a start offset hash into the Pi table. There isn=92t any need to cover a full RTT worth of Pi bits unless it is us= ed for latency detection, but in that case the spin could be a pattern like= 10101010 and 00001111 injected into the Pi sequence. A separate spin bit w= ould be simpler. ________________________________ From: Kazuho Oku Sent: Tuesday, February 6, 2018 5:22:35 PM To: Mikkel Fahn=F8e J=F8rgensen Cc: Brian Trammell (IETF); QUIC WG Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet = number encryption) 2018-02-06 23:54 GMT+09:00 Mikkel Fahn=F8e J=F8rgensen = : > This idea can be taken further: You can modulate the signal so you use > multiple packets to encode a zero or a one for half the wave duration. Fo= r > example 1 could be encoded as 0101 over four packets and zero could be > encoded as 0011 over four packets. > If there is any reordering, it would show up as an unexpected value in th= e > pulse. That's definitely an option. Actually, I considered using sin wave (that distributes the error among 1-bit samples) as an example instead of the square wave. The primary reason behind my preference to using a square wave is that it is easier to implement; in fact, emitting a square wave with the length of 512 packets is as easy as just taking the 9th bit (counting from LSB) of the packet number (if we forget about the gaps for a moment). -- Kazuho Oku --_000_DB6PR10MB176682C63A91007574BBEAECACFC0DB6PR10MB1766EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Also note that this approach is insensitive to= skipped packet numbers in optimistic ACK attack defence. It leaks zero inf= ormation when the network is perfect and if the CID hash is random.

From: Mikkel Fahn=F8e J=F8r= gensen <mikkelfj@gmail.com>
Sent: Wednesday, February 7, 2018 12:58:33 AM
To: Kazuho Oku
Cc: Brian Trammell (IETF); QUIC WG
Subject: Re: Explicit measurability in the QUIC wire image (was Re: = Packet number encryption)
 
I actually think a static 1KB table of Pi coul= d work quite well.

A subset of samples could be indexed in a hash= table and yield loss data early with some probability. Some samples would m= iss due to reordering or loss. If more exact analysis is wanted the levensh= tein distance of a sample sequence against Pi from a synced offset would tell a lot about the data. Or DNA se= quencing. This could be hardware optimized.

Yet, transmission is always just the next bit = in the Pi table.

Since Pi is effectively random it will ebentua= lly detect mutations if the observed sequence is long enough.

Wrt privacy, the CID may be used as a start of= fset hash into the Pi table.

There isn=92t any need to cover a full RTT wor= th of Pi bits unless it is used for latency detection, but in that case the= spin could be a pattern like 10101010 and 00001111 injected into the Pi se= quence. A separate spin bit would be simpler.


From: Kazuho Oku <kazu= hooku@gmail.com>
Sent: Tuesday, February 6, 2018 5:22:35 PM
To: Mikkel Fahn=F8e J=F8rgensen
Cc: Brian Trammell (IETF); QUIC WG
Subject: Re: Explicit measurability in the QUIC wire image (was Re: = Packet number encryption)
 
2018-02-06 23:54 GMT+09:00 Mikkel Fahn=F8e J= =F8rgensen <mikkelfj@gmail.com>:
> This idea can be taken further: You can modulate the signal so you use=
> multiple packets to encode a zero or a one for half the wave duration.= For
> example 1 could be encoded as 0101 over four packets and zero could be=
> encoded as 0011 over four packets.
> If there is any reordering, it would show up as an unexpected value in= the
> pulse.

That's definitely an option.

Actually, I considered using sin wave (that distributes the error
among 1-bit samples) as an example instead of the square wave.

The primary reason behind my preference to using a square wave is that
it is easier to implement; in fact, emitting a square wave with the
length of 512 packets is as easy as just taking the 9th bit (counting
from LSB) of the packet number (if we forget about the gaps for a
moment).


--
Kazuho Oku
--_000_DB6PR10MB176682C63A91007574BBEAECACFC0DB6PR10MB1766EURP_-- From nobody Tue Feb 6 17:05:34 2018 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 7E4971242EA for ; Tue, 6 Feb 2018 17:05:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ctlqwNBsGPM8 for ; Tue, 6 Feb 2018 17:05:28 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 6C8AF129C51 for ; Tue, 6 Feb 2018 17:05:28 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id n206so199517itg.1 for ; Tue, 06 Feb 2018 17:05:28 -0800 (PST) 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=/JNabrn2LtoVnLHih7VWgIw864hf5CYJm2dda9ga4tw=; b=kANZS1pN53McdZwZQ6z26NYkGJrxP3YJuy719i8RI5TUeqTQYG0NS0LVn+guw5p95b 5bzhUPgWwZ6uYw3j7MPYghg6qAXN+ehTve1ofw4P6b8fQ+2iydOpzKmju/I743UAoB0P pU1RIOKzhoPkzyHDUq2sE5tKLiRK5WudDnlBpmkF9VpWOnO8P/QI4LQoi7HBgNh3FiPU ZQ3EV/YmZDja1pKlmnqpEi8gqUaN9oVMfjuzBnXTVmc3laQtAZUR3Di/42aJ7dlkBM2s yjrOyTKlVK1HLaOyUwfox2EEqYgRTlxVI8WBe/wNG7sHxA8HYb9Xnbr82jZWuhFNbl0A 9G3g== 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=/JNabrn2LtoVnLHih7VWgIw864hf5CYJm2dda9ga4tw=; b=qc2pkRxleB1ZTQhnq+a+vza2fv3Axtlsa98A+VfuTTzR6R7+frSVjEFG4UY+6L/TAz K5Pn0+kTkG3yS6k20uMD43cfzMxfBdFjVdVm7RxN9VfZ3tcKkj6JJDdiVP/71Wjnneaw Hqls6v1MliOm6E4PUzWIVOyVzre7VevAXZWfLgCbzkY+KL3X0YA72u2ilAYv/6eDq8gl dhR51aRNhQB3r5hHzk6oA98ore3B4N8XEcPSA+xY9qjFyRF3cJyLxZjNBdg47LYAGG5L eO3ndq/71MZ0iyLHQgy/pdXFdZJ+r2n22Bzv0mREEqn/BgKTYG4NZCCnpPm5dQzS3UYM /wYg== X-Gm-Message-State: APf1xPA2ZoafdarP2OE3rfg4N+LwktEAPxfI6FeyZMinqLcWDpu40ZcP /mQ3p0euUu0RzayKtoW9XbPP+NLVwjKyXDsqtrrKUA== X-Google-Smtp-Source: AH8x225YtkaGpzpztFddsan0iLzE7r3yqwlPFqVdBW+XDR3Xgpg9SodXldxyanWMn4YLHZBFjSNTFJau1XlwU7jQSHA= X-Received: by 10.36.37.84 with SMTP id g81mr5758490itg.73.1517965527379; Tue, 06 Feb 2018 17:05:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Tue, 6 Feb 2018 17:05:06 -0800 (PST) In-Reply-To: References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> From: Ian Swett Date: Tue, 6 Feb 2018 20:05:06 -0500 Message-ID: Subject: Re: Packet number encryption To: Eric Rescorla Cc: Jana Iyengar , QUIC WG , Praveen Balasubramanian , "Lubashev, Igor" , Roberto Peon , Mike Bishop , "Salz, Rich" , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "Brian Trammell (IETF)" , Stephen Farrell Content-Type: multipart/alternative; boundary="001a1145bb480afc2e056494e49d" 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, 07 Feb 2018 01:05:31 -0000 --001a1145bb480afc2e056494e49d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Jana, I think this is a nice framing of the problem and discussion. On Tue, Feb 6, 2018 at 7:13 PM, Eric Rescorla wrote: > > > On Tue, Feb 6, 2018 at 3:00 PM, Jana Iyengar wrote: > >> I'm going to try a different attempt at moving towards >> convergence. Thinking about this some more, and picking up something tha= t >> Mirja said way earlier in this thread, I think the following decompositi= on >> is useful. >> >> 1. In the transport, all packet numbers start at 0, increasing >> monotonically. ACK frames carry these packet numbers, and therefore do n= ot >> have to span large gaps and do not have to deal with increases in the si= ze >> of the largest acked. Basically, no gaps are visible within the transpor= t >> processing engine. >> 2. Before sending a packet on the wire, and before processing the packet= , >> QUIC transforms the packet number with some function, replacing the visi= ble >> packet number with the transformed value. >> >> I think we can all agree that (1) is goodness. A sender is also free to >> use packet numbers from non-contiguous spaces here FWIW, but that's >> entirely independent of what's visible on the wire. This helps me separa= te >> transport processing complexity from the rest of it, which I think is >> helpful. >> >> I think we are disagreeing on the precise properties we want from the >> transformation in (2). If we can agree on these properties, we can then >> figure out whether it's possible and how to construct such a transform. >> Here's a union of what folks are concerned about: >> 1. Packet number must be unlinkable across connection ID change (for >> migration.) >> 2. Packet number must start at an arbitrary value, to avoid ossification >> of the first packet number. >> > 3. Some sequencing information -- a few bits of the packet number perhaps >> -- should be revealed (for monitoring. Number of bits TBD.) >> > > I'm not sure I am persuaded of this point > Yes, I think this seems like the largest point of contention, and #4 is the second largest concern. Given that, I think it makes sense to try to resolve #3, if that is possible. > -Ekr > > >> 4. Any packet number transformation should not be compute intensive. >> >> I'm not looking for a construction, but I'd like to agree on the problem >> first. Does this sound like the set of properties we want? Or is there a >> contradiction among these properties that I'm not seeing? >> >> On Tue, Feb 6, 2018 at 9:56 AM, Mike Bishop wrote= : >> >>> Packet number encryption *does* improve linkability equivalently to >>> random jumps, but without the fragmentation of the ACK packet which tho= se >>> jumps otherwise cause. So I'm with Stephen, we don't yet have agreemen= t on >>> that assertion. >>> >>> -----Original Message----- >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stephen Farrell >>> Sent: Tuesday, February 6, 2018 7:35 AM >>> To: Mirja K=C3=BChlewind ; Mikkel Fahn= =C3=B8e >>> J=C3=B8rgensen ; Brian Trammell (IETF) ; >>> Jana Iyengar >>> Cc: Praveen Balasubramanian ; QUIC WG < >>> quic@ietf.org>; Roberto Peon ; Lubashev, Igor < >>> ilubashe@akamai.com>; Salz, Rich >>> Subject: Re: Packet number encryption >>> >>> >>> >>> On 06/02/18 15:23, Mirja K=C3=BChlewind wrote: >>> > >>> > It's also my understanding that we do agree that packet number >>> > encryption does not help likability (and thereby privacy) a lot, or a= t >>> > least that the benefits we might get (or not) do not justify the >>> > additional complexity. >>> >>> FWIW, which isn't much, I don't (yet) agree to the above. >>> I reckon it'll be a while before we know how linkability pans out. I do >>> agree that packet number encryption is not a panacea for unlinkability,= but >>> it may help, or may even end up being required, to do a good job wrt >>> linkability. >>> >>> I also heard people say it was less complex for them so "additional >>> complexity" may also not be quite right. (I guess "differently complex"= is >>> correct though.) >>> >>> S. >>> >>> -- >>> PGP key change time for me. >>> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. >>> NewWithOld sigs in keyservers. >>> Sorry if that mucks something up;-) >>> >> >> > --001a1145bb480afc2e056494e49d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Jana, I think this is a = nice framing of the problem and discussion.

On Tue, Feb 6, 2018 at 7:13 PM, Eric Rescor= la <= ekr@rtfm.com> wrote:


On Tue, Feb 6, 2018 at 3:00 PM, Jana Iyengar <jri@google.com> wrote:
I&#= 39;m going to try a different attempt at moving towards convergence.=C2=A0T= hinking about this some more, and picking up something that Mirja said way = earlier in this thread, I think the following decomposition is useful.
=
1. In the transport, all packet numbers start at 0, increasi= ng monotonically. ACK frames carry these packet numbers, and therefore do n= ot have to span large gaps and do not have to deal with increases in the si= ze of the largest acked. Basically, no gaps are visible within the transpor= t processing engine.
2. Before sending a packet on the wire, and = before processing the packet, QUIC transforms the packet number with some f= unction, replacing the visible packet number with the transformed value.

I think we can all agree that (1) is goodness. A= sender is also free to use packet numbers from non-contiguous spaces here = FWIW, but that's entirely independent of what's visible on the wire= . This helps me separate transport processing complexity from the rest of i= t, which I think is helpful.

I think we are disagr= eeing on the precise properties we want from the transformation in (2). If = we can agree on these properties, we can then figure out whether it's p= ossible and how to construct such a transform. Here's a union of what f= olks are concerned about:
1. Packet number must be unlinkable acr= oss connection ID change (for migration.)
2. Packet number must s= tart at an arbitrary value, to avoid ossification of the first packet numbe= r.
=
3. Some sequencing information -- a few bits of the packet number perh= aps -- should be revealed (for monitoring. Number of bits TBD.)
=

I'm not sure I am persuaded of = this point



=C2=A0
4. Any packet number transformation= should not be compute intensive.

I'm not look= ing for a construction, but I'd like to agree on the problem first. Doe= s this sound like the set of properties we want? Or is there a contradictio= n among these properties that I'm not seeing?

On Tue, Feb 6, 2018 at 9= :56 AM, Mike Bishop <mbishop@evequefou.be> wrote:
Packet number encryption *does* improve linkabil= ity equivalently to random jumps, but without the fragmentation of the ACK = packet which those jumps otherwise cause.=C2=A0 So I'm with Stephen, we= don't yet have agreement on that assertion.

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stephen Farrell
Sent: Tuesday, February 6, 2018 7:35 AM
To: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>; Mikkel= Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; Brian Trammell (IETF) <ietf@trammell.ch>; Ja= na Iyengar <jri@goog= le.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; QUIC WG <quic@ietf.org>; Roberto Peon <fenix@fb.com>; Lubashe= v, Igor <ilubas= he@akamai.com>; Salz, Rich <rsalz@akamai.com>
Subject: Re: Packet number encryption



On 06/02/18 15:23, Mi= rja K=C3=BChlewind wrote:
>
> It's also my understanding that we do agree that packet number
> encryption does not help likability (and thereby privacy) a lot, or at=
> least that the benefits we might get (or not) do not justify the
> additional complexity.

FWIW, which isn't much, I don't (yet) agree to the above.
I reckon it'll be a while before we know how linkability pans out. I do= agree that packet number encryption is not a panacea for unlinkability, bu= t it may help, or may even end up being required, to do a good job wrt link= ability.

I also heard people say it was less complex for them so "additional co= mplexity" may also not be quite right. (I guess "differently comp= lex" is correct though.)

S.

--
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)



--001a1145bb480afc2e056494e49d-- From nobody Tue Feb 6 18:00:23 2018 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 62C5012D859 for ; Tue, 6 Feb 2018 18:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEbG_eK4V0Fp for ; Tue, 6 Feb 2018 18:00:19 -0800 (PST) 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 77E8B12D0C3 for ; Tue, 6 Feb 2018 18:00:18 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx19.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ejF1q-0005Ie-3t for quic@ietf.org; Wed, 07 Feb 2018 03:00:14 +0100 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 1ejF1F-00047v-Lq for quic@ietf.org; Tue, 06 Feb 2018 21:00:00 -0500 Received: (qmail 8681 invoked from network); 7 Feb 2018 01:59:27 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Feb 2018 01:59:27 -0000 To: Jana Iyengar , Mike Bishop Cc: Praveen Balasubramanian , "Lubashev, Igor" , Roberto Peon , =?UTF-8?Q?Mirja_K=c3=bchlewind?= , "Salz, Rich" , "Brian Trammell (IETF)" , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , QUIC WG , Stephen Farrell References: <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> From: Christian Huitema Message-ID: Date: Tue, 6 Feb 2018 15:59:23 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Packet number encryption X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.23) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5nqqstzE6Z1tGu5LyDzasGYXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsk6/+ravSzTkF+m/CLXlndB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYfVCZ1my7qTGj+pYSPpnV3tZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xe5FFYx70dwpnXuYL0mrvA8FWxgXlWmTYKYIcQI2OJ epJwCsz1H5vcco4g1NZuaV8HmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFDJc/3lHzX92E3nO7lXITicibYT4C2qF2lnc18bVJn65c Lp9FsjCJMVb0boTylPCketz4bKB02BOdxZepNM3KgzwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTwMPXVqLhHTCtUoQNwWJnsFjI1dRH6f16eQCtvwPkeoxEbFBkDEb7h/VcBU3NCXbKl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L 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, 07 Feb 2018 02:00:22 -0000 On 2/6/2018 1:00 PM, Jana Iyengar wrote: > I think we are disagreeing on the precise properties we want from the > transformation in (2). If we can agree on these properties, we can > then figure out whether it's possible and how to construct such a > transform. Here's a union of what folks are concerned about: > 1. Packet number must be unlinkable across connection ID change (for > migration.) Yes. And note the special case when the old and new connection overlap for some time, so that packet N and N+2 may be sent on the old connection, packet N+1 and N+3 on the new one. That kind of pattern should be hidden. > 2. Packet number must start at an arbitrary value, to avoid > ossification of the first packet number. Please explain the reasoning. What do you call packet number there, the value in the ACK or the value in the header? > 3. Some sequencing information -- a few bits of the packet number > perhaps -- should be revealed (for monitoring. Number of bits TBD.) Careful there. This is per path information, so the network might monitor the quality of a path. To continue my example of N and N+2 on the old connection, packet N+1 and N+3 on the new one, I would expose x and x+1 on the old path, y and y+1 on the new path. > 4. Any packet number transformation should not be compute intensive. For some definition of compute intensive. The current PN encryption spec costs 1 block operation; that compares to 8+8 blocks for a 128 byte payload (encrypt and checksum), 80+80 on a 1280 byte payload -- 6% encryption overhead on small packets, 0.6% on large ones. That's less than the difference between AES and Chacha20. > > I'm not looking for a construction, but I'd like to agree on the > problem first. Does this sound like the set of properties we want? Or > is there a contradiction among these properties that I'm not seeing? I am a bit concerned about placing too much emphasis on computation cost. This can lead to "inventing our own crypto substitute". If the PN encoding is easy to break, then it will be routinely broken and ossified.= -- Christian Huitema From nobody Tue Feb 6 18:04:18 2018 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 5B9AE12D0C3 for ; Tue, 6 Feb 2018 18:04:16 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 LIdonMn3DTXm for ; Tue, 6 Feb 2018 18:04:13 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0114.outbound.protection.outlook.com [104.47.42.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 1AB2F12D859 for ; Tue, 6 Feb 2018 18:04:12 -0800 (PST) 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=PbenjYuY3mRatT8o/Pvhiv9+oo6nAi20xUMfdYL7j6w=; b=RpmJPNPZC80Q8P3Tc5/NGTKWlzBj1oj2RKONmeuQ+I1xZ3YlruzZsx87XrXZSgAOwa4ScaqWzki3LSVqjXiJiZS5JuCWPQCAHGzRzw12VBvGNCStL2KU4pQT+lhGwmWJvycYvgr88UWZly4/w8qlu0EfgfJnj3MfRxVBzR81FJ0= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0471.namprd21.prod.outlook.com (10.172.121.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.4; Wed, 7 Feb 2018 02:04:10 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Wed, 7 Feb 2018 02:04:10 +0000 From: Praveen Balasubramanian To: Ian Swett , Eric Rescorla CC: Jana Iyengar , QUIC WG , "Lubashev, Igor" , Roberto Peon , Mike Bishop , "Salz, Rich" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Brian Trammell (IETF)" , Stephen Farrell Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQ Date: Wed, 7 Feb 2018 02:04:10 +0000 Message-ID: References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0471; 7:4rem+73jq0chZ2XmUc12nhsIJbHakR9URmGsFrhvEya2NPhp7zJkqYQ55apH+MnhTH8Dzy+g31bTtis4w4utYnw0xR7KCfsbc85szeYNe6PFKsTgF1AkZ/ajUBQPQlY2Bn7/slI+Bj6nzlG5GB5WjAidtyqxNCgWWME8DqwO0y2U/DnOdHOAi4n7XoSfPGY1dLuaC0eEiS8dtx6LBu5zt/k67yQWyDhCdaUTJOoZH2QEySlDh/J3OscGsuI8sK1E x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 5a9b8320-e5ca-4ea7-ff04-08d56dcf1416 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0471; x-ms-traffictypediagnostic: CY4PR21MB0471: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(32856632585715)(158342451672863)(89211679590171)(85827821059158)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0471; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0471; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(396003)(366004)(39380400002)(376002)(189003)(199004)(13464003)(316002)(33656002)(8936002)(86362001)(8676002)(81156014)(81166006)(3480700004)(236005)(9686003)(54896002)(6306002)(8990500004)(55016002)(10090500001)(53936002)(6436002)(6116002)(790700001)(6246003)(2900100001)(2906002)(105586002)(99286004)(10290500003)(229853002)(478600001)(76176011)(7116003)(77096007)(186003)(86612001)(53546011)(102836004)(6506007)(6346003)(3280700002)(3660700001)(7696005)(68736007)(22452003)(19609705001)(14454004)(93886005)(106356001)(4326008)(97736004)(25786009)(110136005)(5660300001)(54906003)(39060400002)(74316002)(7416002)(561944003)(2950100002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0471; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: XRpdddNZihwYz6bF98bFn4AwaI+Auerd7HI/JbnbGWLvkLluWJT8aLGEuWSZS8cdsHI7RHtIaT4q4QU1EUcm7A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133CCAA6807469BA983D00BB6FC0CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5a9b8320-e5ca-4ea7-ff04-08d56dcf1416 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 02:04:10.4641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0471 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, 07 Feb 2018 02:04:16 -0000 --_000_CY4PR21MB0133CCAA6807469BA983D00BB6FC0CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlYXQgZnJhbWluZyBvZiB0aGUgcHJvYmxlbS4NCg0KUHJvcG9zYWw6IFRyYW5zZm9ybSA9IEFk ZCBhIHNlY3VyZSBhbmQgZml4ZWQgcmFuZG9tIG9mZnNldCB0byB0aGUgYWN0dWFsIHBhY2tldCBu dW1iZXIgZm9yIHRoZSBsaWZldGltZSBvZiBvbmUgcGF0aC4gVHJhbnNwb3J0IGxldmVsIHBhY2tl dCBudW1iZXJzIHN0YXJ0IGF0IDAuIE9uIHdpcmUgcGFja2V0IG51bWJlciBzdGFydCBhdCB0aGUg b2Zmc2V0LiBDbGllbnQgYW5kIHNlcnZlciBwaWNrIHRoZSBvZmZzZXRzIGluZGVwZW5kZW50bHku IEVhY2ggc2lkZSBjb21tdW5pY2F0ZXMgdGhpcyBvZmZzZXQgbnVtYmVyIGluIGFuIGVuY3J5cHRl ZCBmcmFtZSB1bnRpbCB0aGUgZmlyc3QgQUNLLiBPdGhlciBzaWRlIHN1YnRyYWN0cyB0aGUgb2Zm c2V0IHRvIGZpZ3VyZSBvdXQgYWN0dWFsIHBhY2tldCBudW1iZXIgYW5kIHVzZXMgdGhhdCB0byBt YWludGFpbiByZWNlaXZlciBzdGF0ZSBhbmQgZ2VuZXJhdGUgQUNLcy4NCg0KDQogIDEuICBQYWNr ZXQgbnVtYmVyIG11c3QgYmUgdW5saW5rYWJsZSBhY3Jvc3MgY29ubmVjdGlvbiBJRCBjaGFuZ2Ug KGZvciBtaWdyYXRpb24uKQ0KRWFjaCBwYXRoIGdldHMgYSBuZXcgc2VjdXJlIHJhbmRvbSBpbmNy ZW1lbnQgc28gbWFpbnRhaW5zIHVubGlrYWJpbGl0eQ0KDQoNCiAgMS4gIFBhY2tldCBudW1iZXIg bXVzdCBzdGFydCBhdCBhbiBhcmJpdHJhcnkgdmFsdWUsIHRvIGF2b2lkIG9zc2lmaWNhdGlvbiBv ZiB0aGUgZmlyc3QgcGFja2V0IG51bWJlci4NClRydWUgYnkgZGVmaW5pdGlvbiBmb3Igb24gd2ly ZSBwYWNrZXQgbnVtYmVyDQoNCg0KICAxLiAgU29tZSBzZXF1ZW5jaW5nIGluZm9ybWF0aW9uIC0t IGEgZmV3IGJpdHMgb2YgdGhlIHBhY2tldCBudW1iZXIgcGVyaGFwcyAtLSBzaG91bGQgYmUgcmV2 ZWFsZWQgKGZvciBtb25pdG9yaW5nLiBOdW1iZXIgb2YgYml0cyBUQkQuKQ0KQWxsIG9mIHRoZSBi aXRzIGFyZSByZXZlYWxlZCBvbiB0aGUgd2lyZSBhbmQgaW4gc2VxdWVuY2UNCg0KDQogIDEuICBB bnkgcGFja2V0IG51bWJlciB0cmFuc2Zvcm1hdGlvbiBzaG91bGQgbm90IGJlIGNvbXB1dGUgaW50 ZW5zaXZlLg0KTm90IGF0IGFsbCBjb21wdXRlIGludGVuc2l2ZQ0KDQpGcm9tOiBJYW4gU3dldHQg W21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgNiwg MjAxOCA1OjA1IFBNDQpUbzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPg0KQ2M6IEphbmEg SXllbmdhciA8anJpQGdvb2dsZS5jb20+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgUHJhdmVl biBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBMdWJhc2hldiwgSWdvciA8 aWx1YmFzaGVAYWthbWFpLmNvbT47IFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPjsgTWlrZSBC aXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPjsgU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNv bT47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+OyBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+OyBCcmlhbiBUcmFt bWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+OyBTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4u ZmFycmVsbEBjcy50Y2QuaWU+DQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9u DQoNClRoYW5rcyBKYW5hLCBJIHRoaW5rIHRoaXMgaXMgYSBuaWNlIGZyYW1pbmcgb2YgdGhlIHBy b2JsZW0gYW5kIGRpc2N1c3Npb24uDQoNCk9uIFR1ZSwgRmViIDYsIDIwMTggYXQgNzoxMyBQTSwg RXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+PiB3cm90ZToN Cg0KDQpPbiBUdWUsIEZlYiA2LCAyMDE4IGF0IDM6MDAgUE0sIEphbmEgSXllbmdhciA8anJpQGdv b2dsZS5jb208bWFpbHRvOmpyaUBnb29nbGUuY29tPj4gd3JvdGU6DQpJJ20gZ29pbmcgdG8gdHJ5 IGEgZGlmZmVyZW50IGF0dGVtcHQgYXQgbW92aW5nIHRvd2FyZHMgY29udmVyZ2VuY2UuIFRoaW5r aW5nIGFib3V0IHRoaXMgc29tZSBtb3JlLCBhbmQgcGlja2luZyB1cCBzb21ldGhpbmcgdGhhdCBN aXJqYSBzYWlkIHdheSBlYXJsaWVyIGluIHRoaXMgdGhyZWFkLCBJIHRoaW5rIHRoZSBmb2xsb3dp bmcgZGVjb21wb3NpdGlvbiBpcyB1c2VmdWwuDQoNCjEuIEluIHRoZSB0cmFuc3BvcnQsIGFsbCBw YWNrZXQgbnVtYmVycyBzdGFydCBhdCAwLCBpbmNyZWFzaW5nIG1vbm90b25pY2FsbHkuIEFDSyBm cmFtZXMgY2FycnkgdGhlc2UgcGFja2V0IG51bWJlcnMsIGFuZCB0aGVyZWZvcmUgZG8gbm90IGhh dmUgdG8gc3BhbiBsYXJnZSBnYXBzIGFuZCBkbyBub3QgaGF2ZSB0byBkZWFsIHdpdGggaW5jcmVh c2VzIGluIHRoZSBzaXplIG9mIHRoZSBsYXJnZXN0IGFja2VkLiBCYXNpY2FsbHksIG5vIGdhcHMg YXJlIHZpc2libGUgd2l0aGluIHRoZSB0cmFuc3BvcnQgcHJvY2Vzc2luZyBlbmdpbmUuDQoyLiBC ZWZvcmUgc2VuZGluZyBhIHBhY2tldCBvbiB0aGUgd2lyZSwgYW5kIGJlZm9yZSBwcm9jZXNzaW5n IHRoZSBwYWNrZXQsIFFVSUMgdHJhbnNmb3JtcyB0aGUgcGFja2V0IG51bWJlciB3aXRoIHNvbWUg ZnVuY3Rpb24sIHJlcGxhY2luZyB0aGUgdmlzaWJsZSBwYWNrZXQgbnVtYmVyIHdpdGggdGhlIHRy YW5zZm9ybWVkIHZhbHVlLg0KDQpJIHRoaW5rIHdlIGNhbiBhbGwgYWdyZWUgdGhhdCAoMSkgaXMg Z29vZG5lc3MuIEEgc2VuZGVyIGlzIGFsc28gZnJlZSB0byB1c2UgcGFja2V0IG51bWJlcnMgZnJv bSBub24tY29udGlndW91cyBzcGFjZXMgaGVyZSBGV0lXLCBidXQgdGhhdCdzIGVudGlyZWx5IGlu ZGVwZW5kZW50IG9mIHdoYXQncyB2aXNpYmxlIG9uIHRoZSB3aXJlLiBUaGlzIGhlbHBzIG1lIHNl cGFyYXRlIHRyYW5zcG9ydCBwcm9jZXNzaW5nIGNvbXBsZXhpdHkgZnJvbSB0aGUgcmVzdCBvZiBp dCwgd2hpY2ggSSB0aGluayBpcyBoZWxwZnVsLg0KDQpJIHRoaW5rIHdlIGFyZSBkaXNhZ3JlZWlu ZyBvbiB0aGUgcHJlY2lzZSBwcm9wZXJ0aWVzIHdlIHdhbnQgZnJvbSB0aGUgdHJhbnNmb3JtYXRp b24gaW4gKDIpLiBJZiB3ZSBjYW4gYWdyZWUgb24gdGhlc2UgcHJvcGVydGllcywgd2UgY2FuIHRo ZW4gZmlndXJlIG91dCB3aGV0aGVyIGl0J3MgcG9zc2libGUgYW5kIGhvdyB0byBjb25zdHJ1Y3Qg c3VjaCBhIHRyYW5zZm9ybS4gSGVyZSdzIGEgdW5pb24gb2Ygd2hhdCBmb2xrcyBhcmUgY29uY2Vy bmVkIGFib3V0Og0KMS4gUGFja2V0IG51bWJlciBtdXN0IGJlIHVubGlua2FibGUgYWNyb3NzIGNv bm5lY3Rpb24gSUQgY2hhbmdlIChmb3IgbWlncmF0aW9uLikNCjIuIFBhY2tldCBudW1iZXIgbXVz dCBzdGFydCBhdCBhbiBhcmJpdHJhcnkgdmFsdWUsIHRvIGF2b2lkIG9zc2lmaWNhdGlvbiBvZiB0 aGUgZmlyc3QgcGFja2V0IG51bWJlci4NCjMuIFNvbWUgc2VxdWVuY2luZyBpbmZvcm1hdGlvbiAt LSBhIGZldyBiaXRzIG9mIHRoZSBwYWNrZXQgbnVtYmVyIHBlcmhhcHMgLS0gc2hvdWxkIGJlIHJl dmVhbGVkIChmb3IgbW9uaXRvcmluZy4gTnVtYmVyIG9mIGJpdHMgVEJELikNCg0KSSdtIG5vdCBz dXJlIEkgYW0gcGVyc3VhZGVkIG9mIHRoaXMgcG9pbnQNCg0KWWVzLCBJIHRoaW5rIHRoaXMgc2Vl bXMgbGlrZSB0aGUgbGFyZ2VzdCBwb2ludCBvZiBjb250ZW50aW9uLCBhbmQgIzQgaXMgdGhlIHNl Y29uZCBsYXJnZXN0IGNvbmNlcm4uICBHaXZlbiB0aGF0LCBJIHRoaW5rIGl0IG1ha2VzIHNlbnNl IHRvIHRyeSB0byByZXNvbHZlICMzLCBpZiB0aGF0IGlzIHBvc3NpYmxlLg0KDQoNCi1Fa3INCg0K NC4gQW55IHBhY2tldCBudW1iZXIgdHJhbnNmb3JtYXRpb24gc2hvdWxkIG5vdCBiZSBjb21wdXRl IGludGVuc2l2ZS4NCg0KSSdtIG5vdCBsb29raW5nIGZvciBhIGNvbnN0cnVjdGlvbiwgYnV0IEkn ZCBsaWtlIHRvIGFncmVlIG9uIHRoZSBwcm9ibGVtIGZpcnN0LiBEb2VzIHRoaXMgc291bmQgbGlr ZSB0aGUgc2V0IG9mIHByb3BlcnRpZXMgd2Ugd2FudD8gT3IgaXMgdGhlcmUgYSBjb250cmFkaWN0 aW9uIGFtb25nIHRoZXNlIHByb3BlcnRpZXMgdGhhdCBJJ20gbm90IHNlZWluZz8NCg0KT24gVHVl LCBGZWIgNiwgMjAxOCBhdCA5OjU2IEFNLCBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3Uu YmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj4gd3JvdGU6DQpQYWNrZXQgbnVtYmVyIGVu Y3J5cHRpb24gKmRvZXMqIGltcHJvdmUgbGlua2FiaWxpdHkgZXF1aXZhbGVudGx5IHRvIHJhbmRv bSBqdW1wcywgYnV0IHdpdGhvdXQgdGhlIGZyYWdtZW50YXRpb24gb2YgdGhlIEFDSyBwYWNrZXQg d2hpY2ggdGhvc2UganVtcHMgb3RoZXJ3aXNlIGNhdXNlLiAgU28gSSdtIHdpdGggU3RlcGhlbiwg d2UgZG9uJ3QgeWV0IGhhdmUgYWdyZWVtZW50IG9uIHRoYXQgYXNzZXJ0aW9uLg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFN0ZXBoZW4g RmFycmVsbA0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgNiwgMjAxOCA3OjM1IEFNDQpUbzogTWly amEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDxtYWlsdG86bWly amEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4+OyBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2Vu IDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT4+OyBCcmlhbiBU cmFtbWVsbCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g8bWFpbHRvOmlldGZAdHJhbW1lbGwuY2g+ PjsgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2dsZS5jb20+Pg0K Q2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpw cmF2YkBtaWNyb3NvZnQuY29tPj47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNA aWV0Zi5vcmc+PjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb208bWFpbHRvOmZlbml4QGZiLmNv bT4+OyBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFzaGVA YWthbWFpLmNvbT4+OyBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpyc2FsekBh a2FtYWkuY29tPj4NClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KDQpP biAwNi8wMi8xOCAxNToyMywgTWlyamEgS8O8aGxld2luZCB3cm90ZToNCj4NCj4gSXQncyBhbHNv IG15IHVuZGVyc3RhbmRpbmcgdGhhdCB3ZSBkbyBhZ3JlZSB0aGF0IHBhY2tldCBudW1iZXINCj4g ZW5jcnlwdGlvbiBkb2VzIG5vdCBoZWxwIGxpa2FiaWxpdHkgKGFuZCB0aGVyZWJ5IHByaXZhY3kp IGEgbG90LCBvciBhdA0KPiBsZWFzdCB0aGF0IHRoZSBiZW5lZml0cyB3ZSBtaWdodCBnZXQgKG9y IG5vdCkgZG8gbm90IGp1c3RpZnkgdGhlDQo+IGFkZGl0aW9uYWwgY29tcGxleGl0eS4NCg0KRldJ Vywgd2hpY2ggaXNuJ3QgbXVjaCwgSSBkb24ndCAoeWV0KSBhZ3JlZSB0byB0aGUgYWJvdmUuDQpJ IHJlY2tvbiBpdCdsbCBiZSBhIHdoaWxlIGJlZm9yZSB3ZSBrbm93IGhvdyBsaW5rYWJpbGl0eSBw YW5zIG91dC4gSSBkbyBhZ3JlZSB0aGF0IHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbiBpcyBub3Qg YSBwYW5hY2VhIGZvciB1bmxpbmthYmlsaXR5LCBidXQgaXQgbWF5IGhlbHAsIG9yIG1heSBldmVu IGVuZCB1cCBiZWluZyByZXF1aXJlZCwgdG8gZG8gYSBnb29kIGpvYiB3cnQgbGlua2FiaWxpdHku DQoNCkkgYWxzbyBoZWFyZCBwZW9wbGUgc2F5IGl0IHdhcyBsZXNzIGNvbXBsZXggZm9yIHRoZW0g c28gImFkZGl0aW9uYWwgY29tcGxleGl0eSIgbWF5IGFsc28gbm90IGJlIHF1aXRlIHJpZ2h0LiAo SSBndWVzcyAiZGlmZmVyZW50bHkgY29tcGxleCIgaXMgY29ycmVjdCB0aG91Z2guKQ0KDQpTLg0K DQotLQ0KUEdQIGtleSBjaGFuZ2UgdGltZSBmb3IgbWUuDQpOZXctSUQgN0IxNzJCRUE7IG9sZC1J RCA4MDVGOERBMiBleHBpcmVzIEphbiAyNCAyMDE4Lg0KTmV3V2l0aE9sZCBzaWdzIGluIGtleXNl cnZlcnMuDQpTb3JyeSBpZiB0aGF0IG11Y2tzIHNvbWV0aGluZyB1cDstKQ0KDQoNCg0K --_000_CY4PR21MB0133CCAA6807469BA983D00BB6FC0CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ubTYxNTI5MjU1MDE5NjE1ODQy MTRtNjQ2NTQ0Nzg3NDIwMTM4MTU4aW0NCgl7bXNvLXN0eWxlLW5hbWU6bV82MTUyOTI1NTAxOTYx NTg0MjE0bV82NDY1NDQ3ODc0MjAxMzgxNThpbTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlz dCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTkzNzYzODE1NTsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2NDIwMTI0MDYg Njc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdyZWF0IGZyYW1pbmcgb2YgdGhlIHBy b2JsZW0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByb3Bvc2FsOiBUcmFuc2Zvcm0gPSBBZGQg YSBzZWN1cmUgYW5kIGZpeGVkIHJhbmRvbSBvZmZzZXQgdG8gdGhlIGFjdHVhbCBwYWNrZXQgbnVt YmVyIGZvciB0aGUgbGlmZXRpbWUgb2Ygb25lIHBhdGguIFRyYW5zcG9ydCBsZXZlbCBwYWNrZXQg bnVtYmVycyBzdGFydCBhdCAwLiBPbiB3aXJlIHBhY2tldCBudW1iZXIgc3RhcnQgYXQgdGhlIG9m ZnNldC4gQ2xpZW50IGFuZCBzZXJ2ZXIgcGljayB0aGUgb2Zmc2V0cw0KIGluZGVwZW5kZW50bHku IEVhY2ggc2lkZSBjb21tdW5pY2F0ZXMgdGhpcyBvZmZzZXQgbnVtYmVyIGluIGFuIGVuY3J5cHRl ZCBmcmFtZSB1bnRpbCB0aGUgZmlyc3QgQUNLLiBPdGhlciBzaWRlIHN1YnRyYWN0cyB0aGUgb2Zm c2V0IHRvIGZpZ3VyZSBvdXQgYWN0dWFsIHBhY2tldCBudW1iZXIgYW5kIHVzZXMgdGhhdCB0byBt YWludGFpbiByZWNlaXZlciBzdGF0ZSBhbmQgZ2VuZXJhdGUgQUNLcy48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+UGFja2V0IG51bWJlciBtdXN0IGJlIHVu bGlua2FibGUgYWNyb3NzIGNvbm5lY3Rpb24gSUQgY2hhbmdlIChmb3IgbWlncmF0aW9uLik8bzpw PjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVhY2ggcGF0aCBnZXRzIGEg bmV3IHNlY3VyZSByYW5kb20gaW5jcmVtZW50IHNvIG1haW50YWlucyB1bmxpa2FiaWxpdHk8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+UGFja2V0IG51bWJl ciBtdXN0IHN0YXJ0IGF0IGFuIGFyYml0cmFyeSB2YWx1ZSwgdG8gYXZvaWQgb3NzaWZpY2F0aW9u IG9mIHRoZSBmaXJzdCBwYWNrZXQgbnVtYmVyLjxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VHJ1ZSBieSBkZWZpbml0aW9uIGZvciBvbiB3aXJlIHBhY2tldCBudW1i ZXIgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIzIiB0eXBlPSIxIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlNvbWUg c2VxdWVuY2luZyBpbmZvcm1hdGlvbiAtLSBhIGZldyBiaXRzIG9mIHRoZSBwYWNrZXQgbnVtYmVy IHBlcmhhcHMgLS0gc2hvdWxkIGJlIHJldmVhbGVkIChmb3IgbW9uaXRvcmluZy4gTnVtYmVyIG9m IGJpdHMgVEJELik8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFs bCBvZiB0aGUgYml0cyBhcmUgcmV2ZWFsZWQgb24gdGhlIHdpcmUgYW5kIGluIHNlcXVlbmNlIDxv OnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSI0IiB0eXBlPSIxIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPkFueSBwYWNr ZXQgbnVtYmVyIHRyYW5zZm9ybWF0aW9uIHNob3VsZCBub3QgYmUgY29tcHV0ZSBpbnRlbnNpdmUu PG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3QgYXQgYWxsIGNv bXB1dGUgaW50ZW5zaXZlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBJYW4g U3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gVHVl c2RheSwgRmVicnVhcnkgNiwgMjAxOCA1OjA1IFBNPGJyPg0KPGI+VG86PC9iPiBFcmljIFJlc2Nv cmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBKYW5hIEl5ZW5nYXIgJmx0 O2pyaUBnb29nbGUuY29tJmd0OzsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IFByYXZl ZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0OzsgTHViYXNoZXYs IElnb3IgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20mZ3Q7OyBSb2JlcnRvIFBlb24gJmx0O2Zlbml4 QGZiLmNvbSZndDs7IE1pa2UgQmlzaG9wICZsdDttYmlzaG9wQGV2ZXF1ZWZvdS5iZSZndDs7IFNh bHosIFJpY2ggJmx0O3JzYWx6QGFrYW1haS5jb20mZ3Q7OyBNaXJqYSBLw7xobGV3aW5kDQogJmx0 O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7OyBNaWtrZWwgRmFobsO4ZSBKw7hy Z2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBCcmlhbiBUcmFtbWVsbCAoSUVURikg Jmx0O2lldGZAdHJhbW1lbGwuY2gmZ3Q7OyBTdGVwaGVuIEZhcnJlbGwgJmx0O3N0ZXBoZW4uZmFy cmVsbEBjcy50Y2QuaWUmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVy IGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3Mg SmFuYSwgSSB0aGluayB0aGlzIGlzIGEgbmljZSBmcmFtaW5nIG9mIHRoZSBwcm9ibGVtIGFuZCBk aXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBGZWIgNiwgMjAxOCBhdCA3OjEzIFBNLCBFcmljIFJlc2NvcmxhICZsdDs8YSBocmVm PSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWtyQHJ0Zm0uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFR1ZSwgRmViIDYsIDIwMTggYXQgMzowMCBQTSwgSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJt YWlsdG86anJpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JJ20gZ29pbmcgdG8gdHJ5IGEgZGlmZmVyZW50IGF0dGVtcHQgYXQgbW92aW5n IHRvd2FyZHMgY29udmVyZ2VuY2UuJm5ic3A7VGhpbmtpbmcgYWJvdXQgdGhpcyBzb21lIG1vcmUs IGFuZCBwaWNraW5nIHVwIHNvbWV0aGluZyB0aGF0IE1pcmphIHNhaWQgd2F5IGVhcmxpZXIgaW4g dGhpcyB0aHJlYWQsIEkgdGhpbmsgdGhlIGZvbGxvd2luZyBkZWNvbXBvc2l0aW9uIGlzIHVzZWZ1 bC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEuIEluIHRo ZSB0cmFuc3BvcnQsIGFsbCBwYWNrZXQgbnVtYmVycyBzdGFydCBhdCAwLCBpbmNyZWFzaW5nIG1v bm90b25pY2FsbHkuIEFDSyBmcmFtZXMgY2FycnkgdGhlc2UgcGFja2V0IG51bWJlcnMsIGFuZCB0 aGVyZWZvcmUgZG8gbm90IGhhdmUgdG8gc3BhbiBsYXJnZSBnYXBzIGFuZCBkbyBub3QgaGF2ZSB0 byBkZWFsIHdpdGggaW5jcmVhc2VzIGluIHRoZSBzaXplIG9mIHRoZSBsYXJnZXN0IGFja2VkLiBC YXNpY2FsbHksDQogbm8gZ2FwcyBhcmUgdmlzaWJsZSB3aXRoaW4gdGhlIHRyYW5zcG9ydCBwcm9j ZXNzaW5nIGVuZ2luZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjIuIEJlZm9yZSBzZW5kaW5nIGEgcGFja2V0IG9uIHRoZSB3aXJlLCBhbmQgYmVm b3JlIHByb2Nlc3NpbmcgdGhlIHBhY2tldCwgUVVJQyB0cmFuc2Zvcm1zIHRoZSBwYWNrZXQgbnVt YmVyIHdpdGggc29tZSBmdW5jdGlvbiwgcmVwbGFjaW5nIHRoZSB2aXNpYmxlIHBhY2tldCBudW1i ZXIgd2l0aCB0aGUgdHJhbnNmb3JtZWQgdmFsdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgd2UgY2FuIGFsbCBhZ3JlZSB0aGF0 ICgxKSBpcyBnb29kbmVzcy4gQSBzZW5kZXIgaXMgYWxzbyBmcmVlIHRvIHVzZSBwYWNrZXQgbnVt YmVycyBmcm9tIG5vbi1jb250aWd1b3VzIHNwYWNlcyBoZXJlIEZXSVcsIGJ1dCB0aGF0J3MgZW50 aXJlbHkgaW5kZXBlbmRlbnQgb2Ygd2hhdCdzIHZpc2libGUgb24gdGhlIHdpcmUuIFRoaXMgaGVs cHMgbWUgc2VwYXJhdGUgdHJhbnNwb3J0IHByb2Nlc3NpbmcNCiBjb21wbGV4aXR5IGZyb20gdGhl IHJlc3Qgb2YgaXQsIHdoaWNoIEkgdGhpbmsgaXMgaGVscGZ1bC48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB3ZSBhcmUgZGlzYWdy ZWVpbmcgb24gdGhlIHByZWNpc2UgcHJvcGVydGllcyB3ZSB3YW50IGZyb20gdGhlIHRyYW5zZm9y bWF0aW9uIGluICgyKS4gSWYgd2UgY2FuIGFncmVlIG9uIHRoZXNlIHByb3BlcnRpZXMsIHdlIGNh biB0aGVuIGZpZ3VyZSBvdXQgd2hldGhlciBpdCdzIHBvc3NpYmxlIGFuZCBob3cgdG8gY29uc3Ry dWN0IHN1Y2ggYSB0cmFuc2Zvcm0uIEhlcmUncyBhIHVuaW9uIG9mIHdoYXQNCiBmb2xrcyBhcmUg Y29uY2VybmVkIGFib3V0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+MS4gUGFja2V0IG51bWJlciBtdXN0IGJlIHVubGlua2FibGUgYWNyb3NzIGNv bm5lY3Rpb24gSUQgY2hhbmdlIChmb3IgbWlncmF0aW9uLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjIuIFBhY2tldCBudW1iZXIgbXVzdCBzdGFy dCBhdCBhbiBhcmJpdHJhcnkgdmFsdWUsIHRvIGF2b2lkIG9zc2lmaWNhdGlvbiBvZiB0aGUgZmly c3QgcGFja2V0IG51bWJlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4z LiBTb21lIHNlcXVlbmNpbmcgaW5mb3JtYXRpb24gLS0gYSBmZXcgYml0cyBvZiB0aGUgcGFja2V0 IG51bWJlciBwZXJoYXBzIC0tIHNob3VsZCBiZSByZXZlYWxlZCAoZm9yIG1vbml0b3JpbmcuIE51 bWJlciBvZiBiaXRzIFRCRC4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBzdXJlIEkgYW0g cGVyc3VhZGVkIG9mIHRoaXMgcG9pbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WWVzLCBJIHRoaW5rIHRoaXMgc2VlbXMgbGlrZSB0aGUgbGFyZ2VzdCBwb2ludCBvZiBjb250 ZW50aW9uLCBhbmQgIzQgaXMgdGhlIHNlY29uZCBsYXJnZXN0IGNvbmNlcm4uJm5ic3A7IEdpdmVu IHRoYXQsIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gdHJ5IHRvIHJlc29sdmUgIzMsIGlmIHRo YXQgaXMgcG9zc2libGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj40LiBBbnkgcGFja2V0IG51bWJlciB0cmFuc2Zvcm1hdGlvbiBzaG91bGQg bm90IGJlIGNvbXB1dGUgaW50ZW5zaXZlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IGxvb2tpbmcgZm9yIGEgY29uc3RydWN0aW9u LCBidXQgSSdkIGxpa2UgdG8gYWdyZWUgb24gdGhlIHByb2JsZW0gZmlyc3QuIERvZXMgdGhpcyBz b3VuZCBsaWtlIHRoZSBzZXQgb2YgcHJvcGVydGllcyB3ZSB3YW50PyBPciBpcyB0aGVyZSBhIGNv bnRyYWRpY3Rpb24gYW1vbmcgdGhlc2UgcHJvcGVydGllcyB0aGF0IEknbSBub3Qgc2VlaW5nPzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFR1ZSwgRmViIDYsIDIwMTggYXQgOTo1NiBBTSwgTWlrZSBCaXNob3AgJmx0 OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1i aXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5Q YWNrZXQgbnVtYmVyIGVuY3J5cHRpb24gKmRvZXMqIGltcHJvdmUgbGlua2FiaWxpdHkgZXF1aXZh bGVudGx5IHRvIHJhbmRvbSBqdW1wcywgYnV0IHdpdGhvdXQgdGhlIGZyYWdtZW50YXRpb24gb2Yg dGhlIEFDSyBwYWNrZXQgd2hpY2ggdGhvc2UganVtcHMgb3RoZXJ3aXNlIGNhdXNlLiZuYnNwOyBT byBJJ20gd2l0aCBTdGVwaGVuLCB3ZSBkb24ndCB5ZXQgaGF2ZSBhZ3JlZW1lbnQNCiBvbiB0aGF0 IGFzc2VydGlvbi48YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0ibTYxNTI5MjU1MDE5NjE1ODQyMTRt NjQ2NTQ0Nzg3NDIwMTM4MTU4aW0iPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9zcGFuPjxi cj4NCjxzcGFuIGNsYXNzPSJtNjE1MjkyNTUwMTk2MTU4NDIxNG02NDY1NDQ3ODc0MjAxMzgxNThp bSI+RnJvbTogUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYg T2YgU3RlcGhlbiBGYXJyZWxsPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtNjE1MjkyNTUwMTk2 MTU4NDIxNG02NDY1NDQ3ODc0MjAxMzgxNThpbSI+U2VudDogVHVlc2RheSwgRmVicnVhcnkgNiwg MjAxOCA3OjM1IEFNPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtNjE1MjkyNTUwMTk2MTU4NDIx NG02NDY1NDQ3ODc0MjAxMzgxNThpbSI+VG86IE1pcmphIEvDvGhsZXdpbmQgJmx0OzxhIGhyZWY9 Im1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIiB0YXJnZXQ9Il9ibGFuayI+ bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDwvYT4mZ3Q7OyBNaWtrZWwgRmFobsO4ZSBK w7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPiZndDs7DQogQnJpYW4gVHJhbW1lbGwgKElF VEYpICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkB0cmFtbWVsbC5jaCIgdGFyZ2V0PSJfYmxhbmsi PmlldGZAdHJhbW1lbGwuY2g8L2E+Jmd0OzsgSmFuYSBJeWVuZ2FyICZsdDs8YSBocmVmPSJtYWls dG86anJpQGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5qcmlAZ29vZ2xlLmNvbTwvYT4mZ3Q7 PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtNjE1MjkyNTUwMTk2MTU4NDIxNG02NDY1NDQ3ODc0 MjAxMzgxNThpbSI+Q2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWls dG86cHJhdmJAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5j b208L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs7IFJvYmVydG8gUGVvbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOmZlbml4QGZiLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmZlbml4QGZiLmNvbTwv YT4mZ3Q7Ow0KIEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWth bWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OzsgU2Fs eiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6QGFrYW1haS5jb20iIHRhcmdldD0iX2Js YW5rIj5yc2FsekBha2FtYWkuY29tPC9hPiZndDs8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9Im02 MTUyOTI1NTAxOTYxNTg0MjE0bTY0NjU0NDc4NzQyMDEzODE1OGltIj5TdWJqZWN0OiBSZTogUGFj a2V0IG51bWJlciBlbmNyeXB0aW9uPC9zcGFuPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAwNi8wMi8xOCAxNToy MywgTWlyamEgS8O8aGxld2luZCB3cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCdzIGFsc28g bXkgdW5kZXJzdGFuZGluZyB0aGF0IHdlIGRvIGFncmVlIHRoYXQgcGFja2V0IG51bWJlcjxicj4N CiZndDsgZW5jcnlwdGlvbiBkb2VzIG5vdCBoZWxwIGxpa2FiaWxpdHkgKGFuZCB0aGVyZWJ5IHBy aXZhY3kpIGEgbG90LCBvciBhdDxicj4NCiZndDsgbGVhc3QgdGhhdCB0aGUgYmVuZWZpdHMgd2Ug bWlnaHQgZ2V0IChvciBub3QpIGRvIG5vdCBqdXN0aWZ5IHRoZTxicj4NCiZndDsgYWRkaXRpb25h bCBjb21wbGV4aXR5Ljxicj4NCjxicj4NCkZXSVcsIHdoaWNoIGlzbid0IG11Y2gsIEkgZG9uJ3Qg KHlldCkgYWdyZWUgdG8gdGhlIGFib3ZlLjxicj4NCkkgcmVja29uIGl0J2xsIGJlIGEgd2hpbGUg YmVmb3JlIHdlIGtub3cgaG93IGxpbmthYmlsaXR5IHBhbnMgb3V0LiBJIGRvIGFncmVlIHRoYXQg cGFja2V0IG51bWJlciBlbmNyeXB0aW9uIGlzIG5vdCBhIHBhbmFjZWEgZm9yIHVubGlua2FiaWxp dHksIGJ1dCBpdCBtYXkgaGVscCwgb3IgbWF5IGV2ZW4gZW5kIHVwIGJlaW5nIHJlcXVpcmVkLCB0 byBkbyBhIGdvb2Qgam9iIHdydCBsaW5rYWJpbGl0eS48YnI+DQo8YnI+DQpJIGFsc28gaGVhcmQg cGVvcGxlIHNheSBpdCB3YXMgbGVzcyBjb21wbGV4IGZvciB0aGVtIHNvICZxdW90O2FkZGl0aW9u YWwgY29tcGxleGl0eSZxdW90OyBtYXkgYWxzbyBub3QgYmUgcXVpdGUgcmlnaHQuIChJIGd1ZXNz ICZxdW90O2RpZmZlcmVudGx5IGNvbXBsZXgmcXVvdDsgaXMgY29ycmVjdCB0aG91Z2guKTxicj4N Cjxicj4NClMuPGJyPg0KPGJyPg0KLS08YnI+DQpQR1Aga2V5IGNoYW5nZSB0aW1lIGZvciBtZS48 YnI+DQpOZXctSUQgN0IxNzJCRUE7IG9sZC1JRCA4MDVGOERBMiBleHBpcmVzIEphbiAyNCAyMDE4 Ljxicj4NCk5ld1dpdGhPbGQgc2lncyBpbiBrZXlzZXJ2ZXJzLjxicj4NClNvcnJ5IGlmIHRoYXQg bXVja3Mgc29tZXRoaW5nIHVwOy0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0133CCAA6807469BA983D00BB6FC0CY4PR21MB0133namp_-- From nobody Tue Feb 6 22:13:16 2018 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 17D9C12DA25 for ; Tue, 6 Feb 2018 22:13:15 -0800 (PST) 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 cdu5-hXYvXjS for ; Tue, 6 Feb 2018 22:13:12 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 033C012D88B for ; Tue, 6 Feb 2018 22:13:12 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id q12so4125082otg.10 for ; Tue, 06 Feb 2018 22:13:11 -0800 (PST) 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=97NcE1gnyjgN0ImT6XC9lFD7iLx3f7LGoQgHggDNjX0=; b=oAbQnF2qSTYOKiZzJFyPNh0ZC2/d/HEVIBrs8KbIr1W/zdjQJk9RxejI8+B+m0Ak7+ eUXs3m+Yq3iBY/Z7Exv6whNKaM42qVY8ZkRRc65sVUptzsT8W5HD2GAZWoOAIJKsHVRg DA6KzRmCgJRYx4ELg/oNZis4XyYjclhGXdhJRiaCx6Obi8c9fuhcfUzc65+6w+PLX2QX gzZsnQE6CTeUITJ7MaTgFzrjTKdRS1PfE8b5C4/ytNgfrm6hEbKf3OzAfD+CakZo2etR bD8EFh8z2XOc6wq4MTdgk+fgslyaTeKMg09zG2bkRIyMw8CYpe/rXgifIkXOoJvh+lr6 MNVA== 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=97NcE1gnyjgN0ImT6XC9lFD7iLx3f7LGoQgHggDNjX0=; b=IH6ls1vt5uFl3Bv9+CjNwNLGS+0sRwp5vNGvk2z9/iIXU0EUH1wZwrCCPhfijopfMZ 5HwGK/MwoEGf12iJwPy63M8WI80h2SKDwoYP2BTTtuQuDOQVUHKfWZmfkXn63hRSokjh T//cdrOjjzoVl1v2EKRLpnHshYYvRI/CGyu+R9AJn05UeXV6ZXCcuUz0hNXhQfJo92OI cXVLGooU4+kcYzrQyatLc4Cc0DjwaLIc6a7ICrgQijsGbwKWPVAo+EEoTd6Kb4FRMRjv 7Voduq0IntCklc0NwWq/q90PG7gWUqlfMR7vJJx1txhLAY9Khfgr7U8IJ9+vZa3fXn5+ eOeQ== X-Gm-Message-State: APf1xPAy928WBS4aJq5TPTA58PThiULRvezDXNk4tUbJBWrPBGz3aJpg fGYhcyHqeUydhG+NSg2hObJUjPXOoSFBIKubJMg= X-Google-Smtp-Source: AH8x225dnQswyk8leEZ57nogdFbHfKf/1LtxubDsp4Xb9+paDVcEzsTyBxzjI0XtiyxU1YImHfy4p94TvhV7Nm+BN4A= X-Received: by 10.157.72.221 with SMTP id a29mr3620605otj.308.1517983991184; Tue, 06 Feb 2018 22:13:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Tue, 6 Feb 2018 22:13:10 -0800 (PST) In-Reply-To: References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> From: Martin Thomson Date: Wed, 7 Feb 2018 17:13:10 +1100 Message-ID: Subject: Re: Packet number encryption To: Praveen Balasubramanian Cc: Ian Swett , Eric Rescorla , "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Mike Bishop , "Brian Trammell (IETF)" , Jana Iyengar , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG , Stephen Farrell 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, 07 Feb 2018 06:13:15 -0000 That is exactly the solution I proposed. As pointed out, this has several shortcomings, one of which Christian explained in his last email. It is also not appreciably less computation. Considerably more care is required to get this right. On Wed, Feb 7, 2018 at 1:04 PM, Praveen Balasubramanian wrote: > Great framing of the problem. > > > > Proposal: Transform =3D Add a secure and fixed random offset to the actua= l > packet number for the lifetime of one path. Transport level packet number= s > start at 0. On wire packet number start at the offset. Client and server > pick the offsets independently. Each side communicates this offset number= in > an encrypted frame until the first ACK. Other side subtracts the offset t= o > figure out actual packet number and uses that to maintain receiver state = and > generate ACKs. > > > > Packet number must be unlinkable across connection ID change (for > migration.) > > Each path gets a new secure random increment so maintains unlikability > > > > Packet number must start at an arbitrary value, to avoid ossification of = the > first packet number. > > True by definition for on wire packet number > > > > Some sequencing information -- a few bits of the packet number perhaps -- > should be revealed (for monitoring. Number of bits TBD.) > > All of the bits are revealed on the wire and in sequence > > > > Any packet number transformation should not be compute intensive. > > Not at all compute intensive > > > > From: Ian Swett [mailto:ianswett@google.com] > Sent: Tuesday, February 6, 2018 5:05 PM > To: Eric Rescorla > Cc: Jana Iyengar ; QUIC WG ; Praveen > Balasubramanian ; Lubashev, Igor ; > Roberto Peon ; Mike Bishop ; Salz, Ri= ch > ; Mirja K=C3=BChlewind ; > Mikkel Fahn=C3=B8e J=C3=B8rgensen ; Brian Trammell (I= ETF) > ; Stephen Farrell > > > Subject: Re: Packet number encryption > > > > Thanks Jana, I think this is a nice framing of the problem and discussion= . > > > > On Tue, Feb 6, 2018 at 7:13 PM, Eric Rescorla wrote: > > > > > > On Tue, Feb 6, 2018 at 3:00 PM, Jana Iyengar wrote: > > I'm going to try a different attempt at moving towards convergence. Think= ing > about this some more, and picking up something that Mirja said way earlie= r > in this thread, I think the following decomposition is useful. > > > > 1. In the transport, all packet numbers start at 0, increasing > monotonically. ACK frames carry these packet numbers, and therefore do no= t > have to span large gaps and do not have to deal with increases in the siz= e > of the largest acked. Basically, no gaps are visible within the transport > processing engine. > > 2. Before sending a packet on the wire, and before processing the packet, > QUIC transforms the packet number with some function, replacing the visib= le > packet number with the transformed value. > > > > I think we can all agree that (1) is goodness. A sender is also free to u= se > packet numbers from non-contiguous spaces here FWIW, but that's entirely > independent of what's visible on the wire. This helps me separate transpo= rt > processing complexity from the rest of it, which I think is helpful. > > > > I think we are disagreeing on the precise properties we want from the > transformation in (2). If we can agree on these properties, we can then > figure out whether it's possible and how to construct such a transform. > Here's a union of what folks are concerned about: > > 1. Packet number must be unlinkable across connection ID change (for > migration.) > > 2. Packet number must start at an arbitrary value, to avoid ossification = of > the first packet number. > > 3. Some sequencing information -- a few bits of the packet number perhaps= -- > should be revealed (for monitoring. Number of bits TBD.) > > > > I'm not sure I am persuaded of this point > > > > Yes, I think this seems like the largest point of contention, and #4 is t= he > second largest concern. Given that, I think it makes sense to try to > resolve #3, if that is possible. > > > > > > -Ekr > > > > 4. Any packet number transformation should not be compute intensive. > > > > I'm not looking for a construction, but I'd like to agree on the problem > first. Does this sound like the set of properties we want? Or is there a > contradiction among these properties that I'm not seeing? > > > > On Tue, Feb 6, 2018 at 9:56 AM, Mike Bishop wrote: > > Packet number encryption *does* improve linkability equivalently to rando= m > jumps, but without the fragmentation of the ACK packet which those jumps > otherwise cause. So I'm with Stephen, we don't yet have agreement on tha= t > assertion. > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Stephen Farrell > Sent: Tuesday, February 6, 2018 7:35 AM > To: Mirja K=C3=BChlewind ; Mikkel Fahn= =C3=B8e > J=C3=B8rgensen ; Brian Trammell (IETF) ; > Jana Iyengar > Cc: Praveen Balasubramanian ; QUIC WG ; > Roberto Peon ; Lubashev, Igor ; Salz, > Rich > Subject: Re: Packet number encryption > > > On 06/02/18 15:23, Mirja K=C3=BChlewind wrote: >> >> It's also my understanding that we do agree that packet number >> encryption does not help likability (and thereby privacy) a lot, or at >> least that the benefits we might get (or not) do not justify the >> additional complexity. > > FWIW, which isn't much, I don't (yet) agree to the above. > I reckon it'll be a while before we know how linkability pans out. I do > agree that packet number encryption is not a panacea for unlinkability, b= ut > it may help, or may even end up being required, to do a good job wrt > linkability. > > I also heard people say it was less complex for them so "additional > complexity" may also not be quite right. (I guess "differently complex" i= s > correct though.) > > S. > > -- > PGP key change time for me. > New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018. > NewWithOld sigs in keyservers. > Sorry if that mucks something up;-) > > > > > > From nobody Tue Feb 6 22:31:26 2018 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 F2B6D126C89 for ; Tue, 6 Feb 2018 22:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.011 X-Spam-Level: X-Spam-Status: No, score=-3.011 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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 Vlt23f5hEeKC for ; Tue, 6 Feb 2018 22:31:22 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0102.outbound.protection.outlook.com [104.47.40.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F271204DA for ; Tue, 6 Feb 2018 22:31:22 -0800 (PST) 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=zysmmjj+ioG5VbL+KhgU2PLMjr2U3Iz6uWhMWat6tLc=; b=TVf2NZt30Uo+UQeF7j9jixE8uNtWnv3QQw8hrB2SdQ7wbz5/u59c7nyUI+ukTOAmcszekNe1rVcPj6DYYYkKrapsoSqsPrybckgePvMqVTjJqaHsHF+Rn+ZpacSxR9RZlPsc1U2Enk77q0lF0cyYT/aBMFj7xWqLJJW5UtM//ZQ= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0632.namprd21.prod.outlook.com (10.175.115.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Wed, 7 Feb 2018 06:31:19 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Wed, 7 Feb 2018 06:31:19 +0000 From: Praveen Balasubramanian To: Martin Thomson CC: Ian Swett , Eric Rescorla , "Salz, Rich" , "Lubashev, Igor" , Roberto Peon , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Mike Bishop , "Brian Trammell (IETF)" , Jana Iyengar , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , QUIC WG , Stephen Farrell Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQA== Date: Wed, 7 Feb 2018 06:31:19 +0000 Message-ID: References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0632; 7:wBtv2dI91RRH8vOSf8oh3itXkHkpr4uhewcgM2UpU+itzeX5/PCnY5r8P1/RJXoiHNDOnAqJURnoTCbCqu5AWgpjbu4D7FDxDtEg/GmjxEttoy0FXn07vfuZSihP4PqW7VBCyd2u5Gp5PT6afPlMj9emjnU5ejMjC+XyzDPl8wdzwhvlkT7LPeq+ngheHeEr4V4idQj0Ihj7o60gd8kvkg/pQQRiY7I+azQu8f2ODr3z6kkX8Y5YNBNVCIRyYLx6 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: dce16f2d-2033-46d1-3078-08d56df4665c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0632; x-ms-traffictypediagnostic: CY4PR21MB0632: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(32856632585715)(158342451672863)(89211679590171)(85827821059158)(67672495146484)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(3002001)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR21MB0632; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0632; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(366004)(376002)(39380400002)(39860400002)(199004)(189003)(13464003)(105586002)(2950100002)(7736002)(3480700004)(2906002)(6436002)(9686003)(106356001)(74316002)(33656002)(561944003)(97736004)(8936002)(305945005)(7416002)(8676002)(2900100001)(81166006)(81156014)(53936002)(93886005)(316002)(4326008)(22452003)(55016002)(3280700002)(3660700001)(68736007)(10090500001)(14454004)(54906003)(8990500004)(86362001)(6506007)(478600001)(7696005)(7116003)(229853002)(86612001)(6916009)(76176011)(25786009)(77096007)(102836004)(6346003)(6116002)(99286004)(6246003)(53546011)(10290500003)(186003)(39060400002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0632; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: sSrbb32nVyiD7TCEqFPBoaWR5LfAD8vY2xML82TOMNly1N4jwWsKTgJZtO9gBbrZ0vOb+1Uu/iUgGKMZz1os+Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: dce16f2d-2033-46d1-3078-08d56df4665c X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 06:31:19.7667 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0632 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, 07 Feb 2018 06:31:25 -0000 QSBzdWJ0cmFjdGlvbiBhbmQgYWRkaXRpb24gcGVyIHBhY2tldCBpcyBjZXJ0YWlubHkgbXVjaCBs ZXNzIGNvbXB1dGF0aW9uIGNvbXBhcmVkIHRvIGVuY3J5cHRpb24vZGVjcnlwdGlvbi4gT3VyIGV4 cGVyaW1lbnQgc2hvd3MgMSB0byAxLjI1JSBvdmVyaGVhZCBkdWUgYnkgYWRkaW5nIHRoaXMgZXh0 cmEgY3J5cHRvIHN0ZXAgaW4gdGhlIGRhdGEgcGF0aC4gSSBkb27igJl0IGdldCB0aGUgcGFydCBh Ym91dCBtb3JlIGNhcmUsIGl0cyBqdXN0IGEgdHJhbnNmb3JtIGFzIEphbmEgcG9pbnRlZCBvdXQg YW5kIHRoZSBjb3JlIHRyYW5zcG9ydCBjb2RlIGRvZXNu4oCZdCBuZWVkIHRvIG1ha2UgYW55IGNo YW5nZXMsIHRoZSB0cmFuc2Zvcm0gaXMgc2ltcGx5IGRvbmUgZHVyaW5nIGZyYW1pbmcgYWZ0ZXIg b3IgYmVmb3JlIGFsbCBwcm9jZXNzaW5nLiBJJ2QgbGlrZSB0byB1bmRlcnN0YW5kIHRoZSBzaG9y dGNvbWluZ3MgYmV0dGVyIGFuZCBzZWUgaWYgd2UgY2FuIHNvbHZlIHRoZW0gd2l0aG91dCBuZWVk aW5nIGV4cGVuc2l2ZSBvcGVyYXRpb25zIGluIHRoZSBkYXRhIHBhdGgsIG9uZSBvcHRpb24gd291 bGQgYmUgdG8gaGF2ZSBhIG9uZSB0aW1lIGZpeGVkIHNpemUgcGFja2V0IG51bWJlciBqdW1wIGZv ciB0aGUgbmV3IHBhdGggc28gdGhlIG51bWJlcnMgZG9u4oCZdCBnZXQgaW50ZXJsZWF2ZWQgd2l0 aCBnYXBzLiANCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9t c29uIFttYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tXSANClNlbnQ6IFR1ZXNkYXksIEZl YnJ1YXJ5IDYsIDIwMTggMTA6MTMgUE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJh dmJAbWljcm9zb2Z0LmNvbT4NCkNjOiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBF cmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29t PjsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+OyBSb2JlcnRvIFBlb24gPGZl bml4QGZiLmNvbT47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0 aHouY2g+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU+OyBCcmlhbiBUcmFtbWVs bCAoSUVURikgPGlldGZAdHJhbW1lbGwuY2g+OyBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29t PjsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPjsgUVVJQyBX RyA8cXVpY0BpZXRmLm9yZz47IFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRj ZC5pZT4NClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KVGhhdCBpcyBl eGFjdGx5IHRoZSBzb2x1dGlvbiBJIHByb3Bvc2VkLiAgQXMgcG9pbnRlZCBvdXQsIHRoaXMgaGFz IHNldmVyYWwgc2hvcnRjb21pbmdzLCBvbmUgb2Ygd2hpY2ggQ2hyaXN0aWFuIGV4cGxhaW5lZCBp biBoaXMgbGFzdCBlbWFpbC4gIEl0IGlzIGFsc28gbm90IGFwcHJlY2lhYmx5IGxlc3MgY29tcHV0 YXRpb24uICBDb25zaWRlcmFibHkgbW9yZSBjYXJlIGlzIHJlcXVpcmVkIHRvIGdldCB0aGlzIHJp Z2h0Lg0KDQpPbiBXZWQsIEZlYiA3LCAyMDE4IGF0IDE6MDQgUE0sIFByYXZlZW4gQmFsYXN1YnJh bWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gR3JlYXQgZnJhbWluZyBvZiB0 aGUgcHJvYmxlbS4NCj4NCj4NCj4NCj4gUHJvcG9zYWw6IFRyYW5zZm9ybSA9IEFkZCBhIHNlY3Vy ZSBhbmQgZml4ZWQgcmFuZG9tIG9mZnNldCB0byB0aGUgDQo+IGFjdHVhbCBwYWNrZXQgbnVtYmVy IGZvciB0aGUgbGlmZXRpbWUgb2Ygb25lIHBhdGguIFRyYW5zcG9ydCBsZXZlbCANCj4gcGFja2V0 IG51bWJlcnMgc3RhcnQgYXQgMC4gT24gd2lyZSBwYWNrZXQgbnVtYmVyIHN0YXJ0IGF0IHRoZSBv ZmZzZXQuIA0KPiBDbGllbnQgYW5kIHNlcnZlciBwaWNrIHRoZSBvZmZzZXRzIGluZGVwZW5kZW50 bHkuIEVhY2ggc2lkZSANCj4gY29tbXVuaWNhdGVzIHRoaXMgb2Zmc2V0IG51bWJlciBpbiBhbiBl bmNyeXB0ZWQgZnJhbWUgdW50aWwgdGhlIGZpcnN0IA0KPiBBQ0suIE90aGVyIHNpZGUgc3VidHJh Y3RzIHRoZSBvZmZzZXQgdG8gZmlndXJlIG91dCBhY3R1YWwgcGFja2V0IA0KPiBudW1iZXIgYW5k IHVzZXMgdGhhdCB0byBtYWludGFpbiByZWNlaXZlciBzdGF0ZSBhbmQgZ2VuZXJhdGUgQUNLcy4N Cj4NCj4NCj4NCj4gUGFja2V0IG51bWJlciBtdXN0IGJlIHVubGlua2FibGUgYWNyb3NzIGNvbm5l Y3Rpb24gSUQgY2hhbmdlIChmb3INCj4gbWlncmF0aW9uLikNCj4NCj4gRWFjaCBwYXRoIGdldHMg YSBuZXcgc2VjdXJlIHJhbmRvbSBpbmNyZW1lbnQgc28gbWFpbnRhaW5zIHVubGlrYWJpbGl0eQ0K Pg0KPg0KPg0KPiBQYWNrZXQgbnVtYmVyIG11c3Qgc3RhcnQgYXQgYW4gYXJiaXRyYXJ5IHZhbHVl LCB0byBhdm9pZCBvc3NpZmljYXRpb24gDQo+IG9mIHRoZSBmaXJzdCBwYWNrZXQgbnVtYmVyLg0K Pg0KPiBUcnVlIGJ5IGRlZmluaXRpb24gZm9yIG9uIHdpcmUgcGFja2V0IG51bWJlcg0KPg0KPg0K Pg0KPiBTb21lIHNlcXVlbmNpbmcgaW5mb3JtYXRpb24gLS0gYSBmZXcgYml0cyBvZiB0aGUgcGFj a2V0IG51bWJlciBwZXJoYXBzIA0KPiAtLSBzaG91bGQgYmUgcmV2ZWFsZWQgKGZvciBtb25pdG9y aW5nLiBOdW1iZXIgb2YgYml0cyBUQkQuKQ0KPg0KPiBBbGwgb2YgdGhlIGJpdHMgYXJlIHJldmVh bGVkIG9uIHRoZSB3aXJlIGFuZCBpbiBzZXF1ZW5jZQ0KPg0KPg0KPg0KPiBBbnkgcGFja2V0IG51 bWJlciB0cmFuc2Zvcm1hdGlvbiBzaG91bGQgbm90IGJlIGNvbXB1dGUgaW50ZW5zaXZlLg0KPg0K PiBOb3QgYXQgYWxsIGNvbXB1dGUgaW50ZW5zaXZlDQo+DQo+DQo+DQo+IEZyb206IElhbiBTd2V0 dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5 IDYsIDIwMTggNTowNSBQTQ0KPiBUbzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPg0KPiBD YzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+ OyBQcmF2ZWVuIA0KPiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBMdWJh c2hldiwgSWdvciANCj4gPGlsdWJhc2hlQGFrYW1haS5jb20+OyBSb2JlcnRvIFBlb24gPGZlbml4 QGZiLmNvbT47IE1pa2UgQmlzaG9wIA0KPiA8bWJpc2hvcEBldmVxdWVmb3UuYmU+OyBTYWx6LCBS aWNoIDxyc2FsekBha2FtYWkuY29tPjsgTWlyamEgS8O8aGxld2luZCANCj4gPG1pcmphLmt1ZWhs ZXdpbmRAdGlrLmVlLmV0aHouY2g+Ow0KPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtr ZWxmakBnbWFpbC5jb20+OyBCcmlhbiBUcmFtbWVsbCAoSUVURikgDQo+IDxpZXRmQHRyYW1tZWxs LmNoPjsgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPg0KPg0KPg0K PiBTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQo+DQo+DQo+DQo+IFRoYW5r cyBKYW5hLCBJIHRoaW5rIHRoaXMgaXMgYSBuaWNlIGZyYW1pbmcgb2YgdGhlIHByb2JsZW0gYW5k IGRpc2N1c3Npb24uDQo+DQo+DQo+DQo+IE9uIFR1ZSwgRmViIDYsIDIwMTggYXQgNzoxMyBQTSwg RXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPiB3cm90ZToNCj4NCj4NCj4NCj4NCj4NCj4gT24g VHVlLCBGZWIgNiwgMjAxOCBhdCAzOjAwIFBNLCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29t PiB3cm90ZToNCj4NCj4gSSdtIGdvaW5nIHRvIHRyeSBhIGRpZmZlcmVudCBhdHRlbXB0IGF0IG1v dmluZyB0b3dhcmRzIGNvbnZlcmdlbmNlLiANCj4gVGhpbmtpbmcgYWJvdXQgdGhpcyBzb21lIG1v cmUsIGFuZCBwaWNraW5nIHVwIHNvbWV0aGluZyB0aGF0IE1pcmphIA0KPiBzYWlkIHdheSBlYXJs aWVyIGluIHRoaXMgdGhyZWFkLCBJIHRoaW5rIHRoZSBmb2xsb3dpbmcgZGVjb21wb3NpdGlvbiBp cyB1c2VmdWwuDQo+DQo+DQo+DQo+IDEuIEluIHRoZSB0cmFuc3BvcnQsIGFsbCBwYWNrZXQgbnVt YmVycyBzdGFydCBhdCAwLCBpbmNyZWFzaW5nIA0KPiBtb25vdG9uaWNhbGx5LiBBQ0sgZnJhbWVz IGNhcnJ5IHRoZXNlIHBhY2tldCBudW1iZXJzLCBhbmQgdGhlcmVmb3JlIGRvIA0KPiBub3QgaGF2 ZSB0byBzcGFuIGxhcmdlIGdhcHMgYW5kIGRvIG5vdCBoYXZlIHRvIGRlYWwgd2l0aCBpbmNyZWFz ZXMgaW4gDQo+IHRoZSBzaXplIG9mIHRoZSBsYXJnZXN0IGFja2VkLiBCYXNpY2FsbHksIG5vIGdh cHMgYXJlIHZpc2libGUgd2l0aGluIA0KPiB0aGUgdHJhbnNwb3J0IHByb2Nlc3NpbmcgZW5naW5l Lg0KPg0KPiAyLiBCZWZvcmUgc2VuZGluZyBhIHBhY2tldCBvbiB0aGUgd2lyZSwgYW5kIGJlZm9y ZSBwcm9jZXNzaW5nIHRoZSANCj4gcGFja2V0LCBRVUlDIHRyYW5zZm9ybXMgdGhlIHBhY2tldCBu dW1iZXIgd2l0aCBzb21lIGZ1bmN0aW9uLCANCj4gcmVwbGFjaW5nIHRoZSB2aXNpYmxlIHBhY2tl dCBudW1iZXIgd2l0aCB0aGUgdHJhbnNmb3JtZWQgdmFsdWUuDQo+DQo+DQo+DQo+IEkgdGhpbmsg d2UgY2FuIGFsbCBhZ3JlZSB0aGF0ICgxKSBpcyBnb29kbmVzcy4gQSBzZW5kZXIgaXMgYWxzbyBm cmVlIA0KPiB0byB1c2UgcGFja2V0IG51bWJlcnMgZnJvbSBub24tY29udGlndW91cyBzcGFjZXMg aGVyZSBGV0lXLCBidXQgdGhhdCdzIA0KPiBlbnRpcmVseSBpbmRlcGVuZGVudCBvZiB3aGF0J3Mg dmlzaWJsZSBvbiB0aGUgd2lyZS4gVGhpcyBoZWxwcyBtZSANCj4gc2VwYXJhdGUgdHJhbnNwb3J0 IHByb2Nlc3NpbmcgY29tcGxleGl0eSBmcm9tIHRoZSByZXN0IG9mIGl0LCB3aGljaCBJIHRoaW5r IGlzIGhlbHBmdWwuDQo+DQo+DQo+DQo+IEkgdGhpbmsgd2UgYXJlIGRpc2FncmVlaW5nIG9uIHRo ZSBwcmVjaXNlIHByb3BlcnRpZXMgd2Ugd2FudCBmcm9tIHRoZSANCj4gdHJhbnNmb3JtYXRpb24g aW4gKDIpLiBJZiB3ZSBjYW4gYWdyZWUgb24gdGhlc2UgcHJvcGVydGllcywgd2UgY2FuIA0KPiB0 aGVuIGZpZ3VyZSBvdXQgd2hldGhlciBpdCdzIHBvc3NpYmxlIGFuZCBob3cgdG8gY29uc3RydWN0 IHN1Y2ggYSB0cmFuc2Zvcm0uDQo+IEhlcmUncyBhIHVuaW9uIG9mIHdoYXQgZm9sa3MgYXJlIGNv bmNlcm5lZCBhYm91dDoNCj4NCj4gMS4gUGFja2V0IG51bWJlciBtdXN0IGJlIHVubGlua2FibGUg YWNyb3NzIGNvbm5lY3Rpb24gSUQgY2hhbmdlIChmb3INCj4gbWlncmF0aW9uLikNCj4NCj4gMi4g UGFja2V0IG51bWJlciBtdXN0IHN0YXJ0IGF0IGFuIGFyYml0cmFyeSB2YWx1ZSwgdG8gYXZvaWQg DQo+IG9zc2lmaWNhdGlvbiBvZiB0aGUgZmlyc3QgcGFja2V0IG51bWJlci4NCj4NCj4gMy4gU29t ZSBzZXF1ZW5jaW5nIGluZm9ybWF0aW9uIC0tIGEgZmV3IGJpdHMgb2YgdGhlIHBhY2tldCBudW1i ZXIgDQo+IHBlcmhhcHMgLS0gc2hvdWxkIGJlIHJldmVhbGVkIChmb3IgbW9uaXRvcmluZy4gTnVt YmVyIG9mIGJpdHMgVEJELikNCj4NCj4NCj4NCj4gSSdtIG5vdCBzdXJlIEkgYW0gcGVyc3VhZGVk IG9mIHRoaXMgcG9pbnQNCj4NCj4NCj4NCj4gWWVzLCBJIHRoaW5rIHRoaXMgc2VlbXMgbGlrZSB0 aGUgbGFyZ2VzdCBwb2ludCBvZiBjb250ZW50aW9uLCBhbmQgIzQgDQo+IGlzIHRoZSBzZWNvbmQg bGFyZ2VzdCBjb25jZXJuLiAgR2l2ZW4gdGhhdCwgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byAN Cj4gdHJ5IHRvIHJlc29sdmUgIzMsIGlmIHRoYXQgaXMgcG9zc2libGUuDQo+DQo+DQo+DQo+DQo+ DQo+IC1Fa3INCj4NCj4NCj4NCj4gNC4gQW55IHBhY2tldCBudW1iZXIgdHJhbnNmb3JtYXRpb24g c2hvdWxkIG5vdCBiZSBjb21wdXRlIGludGVuc2l2ZS4NCj4NCj4NCj4NCj4gSSdtIG5vdCBsb29r aW5nIGZvciBhIGNvbnN0cnVjdGlvbiwgYnV0IEknZCBsaWtlIHRvIGFncmVlIG9uIHRoZSANCj4g cHJvYmxlbSBmaXJzdC4gRG9lcyB0aGlzIHNvdW5kIGxpa2UgdGhlIHNldCBvZiBwcm9wZXJ0aWVz IHdlIHdhbnQ/IE9yIA0KPiBpcyB0aGVyZSBhIGNvbnRyYWRpY3Rpb24gYW1vbmcgdGhlc2UgcHJv cGVydGllcyB0aGF0IEknbSBub3Qgc2VlaW5nPw0KPg0KPg0KPg0KPiBPbiBUdWUsIEZlYiA2LCAy MDE4IGF0IDk6NTYgQU0sIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT4gd3JvdGU6 DQo+DQo+IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbiAqZG9lcyogaW1wcm92ZSBsaW5rYWJpbGl0 eSBlcXVpdmFsZW50bHkgdG8gDQo+IHJhbmRvbSBqdW1wcywgYnV0IHdpdGhvdXQgdGhlIGZyYWdt ZW50YXRpb24gb2YgdGhlIEFDSyBwYWNrZXQgd2hpY2ggDQo+IHRob3NlIGp1bXBzIG90aGVyd2lz ZSBjYXVzZS4gIFNvIEknbSB3aXRoIFN0ZXBoZW4sIHdlIGRvbid0IHlldCBoYXZlIA0KPiBhZ3Jl ZW1lbnQgb24gdGhhdCBhc3NlcnRpb24uDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBTdGVwaGVuIEZhcnJlbGwNCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgNiwgMjAxOCA3OjM1 IEFNDQo+IFRvOiBNaXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6 LmNoPjsgTWlra2VsIEZhaG7DuGUgDQo+IErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNvbT47 IEJyaWFuIFRyYW1tZWxsIChJRVRGKSANCj4gPGlldGZAdHJhbW1lbGwuY2g+OyBKYW5hIEl5ZW5n YXIgPGpyaUBnb29nbGUuY29tPg0KPiBDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi QG1pY3Jvc29mdC5jb20+OyBRVUlDIFdHIA0KPiA8cXVpY0BpZXRmLm9yZz47IFJvYmVydG8gUGVv biA8ZmVuaXhAZmIuY29tPjsgTHViYXNoZXYsIElnb3IgDQo+IDxpbHViYXNoZUBha2FtYWkuY29t PjsgU2FseiwgUmljaCA8cnNhbHpAYWthbWFpLmNvbT4NCj4gU3ViamVjdDogUmU6IFBhY2tldCBu dW1iZXIgZW5jcnlwdGlvbg0KPg0KPg0KPiBPbiAwNi8wMi8xOCAxNToyMywgTWlyamEgS8O8aGxl d2luZCB3cm90ZToNCj4+DQo+PiBJdCdzIGFsc28gbXkgdW5kZXJzdGFuZGluZyB0aGF0IHdlIGRv IGFncmVlIHRoYXQgcGFja2V0IG51bWJlciANCj4+IGVuY3J5cHRpb24gZG9lcyBub3QgaGVscCBs aWthYmlsaXR5IChhbmQgdGhlcmVieSBwcml2YWN5KSBhIGxvdCwgb3IgDQo+PiBhdCBsZWFzdCB0 aGF0IHRoZSBiZW5lZml0cyB3ZSBtaWdodCBnZXQgKG9yIG5vdCkgZG8gbm90IGp1c3RpZnkgdGhl IA0KPj4gYWRkaXRpb25hbCBjb21wbGV4aXR5Lg0KPg0KPiBGV0lXLCB3aGljaCBpc24ndCBtdWNo LCBJIGRvbid0ICh5ZXQpIGFncmVlIHRvIHRoZSBhYm92ZS4NCj4gSSByZWNrb24gaXQnbGwgYmUg YSB3aGlsZSBiZWZvcmUgd2Uga25vdyBob3cgbGlua2FiaWxpdHkgcGFucyBvdXQuIEkgDQo+IGRv IGFncmVlIHRoYXQgcGFja2V0IG51bWJlciBlbmNyeXB0aW9uIGlzIG5vdCBhIHBhbmFjZWEgZm9y IA0KPiB1bmxpbmthYmlsaXR5LCBidXQgaXQgbWF5IGhlbHAsIG9yIG1heSBldmVuIGVuZCB1cCBi ZWluZyByZXF1aXJlZCwgdG8gDQo+IGRvIGEgZ29vZCBqb2Igd3J0IGxpbmthYmlsaXR5Lg0KPg0K PiBJIGFsc28gaGVhcmQgcGVvcGxlIHNheSBpdCB3YXMgbGVzcyBjb21wbGV4IGZvciB0aGVtIHNv ICJhZGRpdGlvbmFsIA0KPiBjb21wbGV4aXR5IiBtYXkgYWxzbyBub3QgYmUgcXVpdGUgcmlnaHQu IChJIGd1ZXNzICJkaWZmZXJlbnRseSANCj4gY29tcGxleCIgaXMgY29ycmVjdCB0aG91Z2guKQ0K Pg0KPiBTLg0KPg0KPiAtLQ0KPiBQR1Aga2V5IGNoYW5nZSB0aW1lIGZvciBtZS4NCj4gTmV3LUlE IDdCMTcyQkVBOyBvbGQtSUQgODA1RjhEQTIgZXhwaXJlcyBKYW4gMjQgMjAxOC4NCj4gTmV3V2l0 aE9sZCBzaWdzIGluIGtleXNlcnZlcnMuDQo+IFNvcnJ5IGlmIHRoYXQgbXVja3Mgc29tZXRoaW5n IHVwOy0pDQo+DQo+DQo+DQo+DQo+DQo+DQo= From nobody Tue Feb 6 22:51:13 2018 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 2ED4E12DA15 for ; Tue, 6 Feb 2018 22:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mChknQnlUsDl for ; Tue, 6 Feb 2018 22:51:10 -0800 (PST) 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 CEDF712DA13 for ; Tue, 6 Feb 2018 22:51:09 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx36.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1ejJZ2-0006pf-AW for quic@ietf.org; Wed, 07 Feb 2018 07:51:06 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ejJYj-0001as-62 for quic@ietf.org; Wed, 07 Feb 2018 01:50:36 -0500 Received: (qmail 377 invoked from network); 7 Feb 2018 06:50:18 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Feb 2018 06:50:18 -0000 To: quic@ietf.org References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> From: Christian Huitema Message-ID: Date: Tue, 6 Feb 2018 20:50:14 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Packet number encryption X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.36) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5gfa+XzHaWzKs5dqtE4MDbkXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsEt1ako4z635LGRbu3wbX9B98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CmFX1b41xAmRGo9aO45nmgtsMbRWoCGKsmA4H+AUEjH9x6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGIBh0lFb/5eYGUZevpHeMAfU6/u1jAwrBNtINJhEKe6PX j3RxApPjGxr4aS0rd6Or2/40hunyihCqV/g+k4KP3lz1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiBxfty0k7S+n2Au1UL1ERBjh3h1vgDbEdmhrg3iVBpdRbtOs7A8Ul3heojjLqRN1knGpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj 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, 07 Feb 2018 06:51:12 -0000 On 2/6/2018 8:31 PM, Praveen Balasubramanian wrote: > A subtraction and addition per packet is certainly much less computatio= n compared to encryption/decryption. Our experiment shows 1 to 1.25% over= head due by adding this extra crypto step in the data path. I don=E2=80=99= t get the part about more care, its just a transform as Jana pointed out = and the core transport code doesn=E2=80=99t need to make any changes, the= transform is simply done during framing after or before all processing. = I'd like to understand the shortcomings better and see if we can solve th= em without needing expensive operations in the data path, one option woul= d be to have a one time fixed size packet number jump for the new path so= the numbers don=E2=80=99t get interleaved with gaps.=20 There are at least two big shortcomings. First, the proposal does not obscure the position of the packet number field in the header. The field contains a number that increments with every packet, and is thus easy to identify. This means that middle-boxes will get accustomed to seeing that field and tracking its increments. Hence, this simple obfuscation provides no protection against ossification of the packet number field. Second, the proposal does not protect against linkage, if several paths are used simultaneously during a migration. Instead of progressing by increments of 1, the PN will progress by increments that depends on the number of packets sent on other paths. This allows for easy correlation of these paths, despite the random increment. In short, this simple obfuscation does not protect against ossification and also does not prevent linkability. -- Christian Huitema From nobody Tue Feb 6 22:56:04 2018 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 2EBEF120726 for ; Tue, 6 Feb 2018 22:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-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 (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 WyYC-fZ9UXZz for ; Tue, 6 Feb 2018 22:56:00 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0095.outbound.protection.outlook.com [104.47.40.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 149D51204DA for ; Tue, 6 Feb 2018 22:55:59 -0800 (PST) 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=9e2RcHuOM8r5x/LZ8o4f0W5eisMDoGUnyKqxf0NSWXA=; b=QOayZme//y9YedKnEJQhtO4On0TO5sXYDma5DnnHcKTgOwLF32DHyWo55Icm4pdxkz9TUFhx41WMR+sZoEaFuA3zvIbm0r7HmoVTv6+SjfrXsv77ZOHerTAOBJuD0YubOPd17X13ASJ+pZpigM+oZce6NpIHAy9d94hdpAsE2vY= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Wed, 7 Feb 2018 06:55:58 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Wed, 7 Feb 2018 06:55:58 +0000 From: Praveen Balasubramanian To: huitema , "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaA= Date: Wed, 7 Feb 2018 06:55:57 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0504; 7:hdQVvoDNLmkWoRGLGB+xD+9Bxh8OiSVXGcXW3qsGwAAznibM8iss/0aImav753jWuyTRvFMbhiJbE+aWq6o0VKz/sx/erXSvvbvYwCSghpltKZpdbp4KU/pMhBaq3zzaOFdlZclU1+pNVb4qy0f50p3LrdpnFJ0+NjFE+Mv2H3GB9lV1xvo3x18Sz3kuaAOVin6kIDBE0lEXy5EgWK9sjmxC4B1jSB+C36cbOKJSdvv1L/l3u3lczCnEy+7ThCEX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c376617b-da24-452b-8bce-08d56df7d767 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0504; x-ms-traffictypediagnostic: CY4PR21MB0504: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0504; BCL:0; PCL:0; RULEID:(3232008); SRVR:CY4PR21MB0504; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(366004)(39380400002)(346002)(13464003)(199004)(189003)(68736007)(7736002)(305945005)(2906002)(7696005)(76176011)(74316002)(53546011)(6506007)(102836004)(229853002)(55016002)(9686003)(6436002)(53936002)(81156014)(99286004)(3280700002)(93886005)(186003)(3480700004)(97736004)(77096007)(8676002)(81166006)(6346003)(25786009)(316002)(3660700001)(110136005)(22452003)(478600001)(8990500004)(10090500001)(14454004)(2900100001)(6116002)(6246003)(8936002)(86362001)(2501003)(10290500003)(2950100002)(86612001)(5660300001)(7116003)(33656002)(106356001)(561944003)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: zH1ToSdkCFAxPcyfJA4lbXzjC6F2om6KJzaQ+YSgMZKVaIhltfcgd4J3uUSfkwMTxokaZFTPQK3PZt/7yKA8CA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: c376617b-da24-452b-8bce-08d56df7d767 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 06:55:57.9499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504 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, 07 Feb 2018 06:56:02 -0000 SW5saW5lIHByZWZpeGVkIGJ5ID4+Pg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlz dGlhbiBIdWl0ZW1hDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA2LCAyMDE4IDEwOjUwIFBNDQpU bzogcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0K DQpPbiAyLzYvMjAxOCA4OjMxIFBNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiB3cm90ZToNCg0K PiBBIHN1YnRyYWN0aW9uIGFuZCBhZGRpdGlvbiBwZXIgcGFja2V0IGlzIGNlcnRhaW5seSBtdWNo IGxlc3MgY29tcHV0YXRpb24gY29tcGFyZWQgdG8gZW5jcnlwdGlvbi9kZWNyeXB0aW9uLiBPdXIg ZXhwZXJpbWVudCBzaG93cyAxIHRvIDEuMjUlIG92ZXJoZWFkIGR1ZSBieSBhZGRpbmcgdGhpcyBl eHRyYSBjcnlwdG8gc3RlcCBpbiB0aGUgZGF0YSBwYXRoLiBJIGRvbuKAmXQgZ2V0IHRoZSBwYXJ0 IGFib3V0IG1vcmUgY2FyZSwgaXRzIGp1c3QgYSB0cmFuc2Zvcm0gYXMgSmFuYSBwb2ludGVkIG91 dCBhbmQgdGhlIGNvcmUgdHJhbnNwb3J0IGNvZGUgZG9lc27igJl0IG5lZWQgdG8gbWFrZSBhbnkg Y2hhbmdlcywgdGhlIHRyYW5zZm9ybSBpcyBzaW1wbHkgZG9uZSBkdXJpbmcgZnJhbWluZyBhZnRl ciBvciBiZWZvcmUgYWxsIHByb2Nlc3NpbmcuIEknZCBsaWtlIHRvIHVuZGVyc3RhbmQgdGhlIHNo b3J0Y29taW5ncyBiZXR0ZXIgYW5kIHNlZSBpZiB3ZSBjYW4gc29sdmUgdGhlbSB3aXRob3V0IG5l ZWRpbmcgZXhwZW5zaXZlIG9wZXJhdGlvbnMgaW4gdGhlIGRhdGEgcGF0aCwgb25lIG9wdGlvbiB3 b3VsZCBiZSB0byBoYXZlIGEgb25lIHRpbWUgZml4ZWQgc2l6ZSBwYWNrZXQgbnVtYmVyIGp1bXAg Zm9yIHRoZSBuZXcgcGF0aCBzbyB0aGUgbnVtYmVycyBkb27igJl0IGdldCBpbnRlcmxlYXZlZCB3 aXRoIGdhcHMuIA0KDQpUaGVyZSBhcmUgYXQgbGVhc3QgdHdvIGJpZyBzaG9ydGNvbWluZ3MuDQoN CkZpcnN0LCB0aGUgcHJvcG9zYWwgZG9lcyBub3Qgb2JzY3VyZSB0aGUgcG9zaXRpb24gb2YgdGhl IHBhY2tldCBudW1iZXIgZmllbGQgaW4gdGhlIGhlYWRlci4gVGhlIGZpZWxkIGNvbnRhaW5zIGEg bnVtYmVyIHRoYXQgaW5jcmVtZW50cyB3aXRoIGV2ZXJ5IHBhY2tldCwgYW5kIGlzIHRodXMgZWFz eSB0byBpZGVudGlmeS4gVGhpcyBtZWFucyB0aGF0IG1pZGRsZS1ib3hlcyB3aWxsIGdldCBhY2N1 c3RvbWVkIHRvIHNlZWluZyB0aGF0IGZpZWxkIGFuZCB0cmFja2luZyBpdHMgaW5jcmVtZW50cy4N CkhlbmNlLCB0aGlzIHNpbXBsZSBvYmZ1c2NhdGlvbiBwcm92aWRlcyBubyBwcm90ZWN0aW9uIGFn YWluc3Qgb3NzaWZpY2F0aW9uIG9mIHRoZSBwYWNrZXQgbnVtYmVyIGZpZWxkLg0KDQo+Pj4gV2Vs bCBpdCBzZWVtcyBsaWtlIGl0IGlzIGEgcmVxdWlyZW1lbnQgKHNlZSBidWxsZXQgMyBpbiBKYW5h J3MgbGlzdCkgdG8gYWxsb3cgbWlkZGxlYm94ZXMgdG8gc2VlIHNlcXVlbmNpbmcgaW5mb3JtYXRp b24uIEJ5IHBpY2tpbmcgdGhlIGluaXRpYWwgcmFuZG9tIHZhbHVlIG1pZGRsZWJveGVzIGNhbm5v dCBhc3N1bWUgYW55IHBhcnRpY3VsYXIgdmFsdWUuIElmIHBhY2tldCBudW1iZXIgbG9jYXRpb24g YW5kIHNpemUgaXMgbm90IHBhcnQgb2YgaW52YXJpYW50cyB0aGVuIGl0IGNhbm5vdCBiZSBvc3Np ZmllZCwgbWlkZGxlYm94ZXMgd2lsbCBuZWVkIHRvIGJlIHJlc2lsaWVudC4gDQoNCg0KU2Vjb25k LCB0aGUgcHJvcG9zYWwgZG9lcyBub3QgcHJvdGVjdCBhZ2FpbnN0IGxpbmthZ2UsIGlmIHNldmVy YWwgcGF0aHMgYXJlIHVzZWQgc2ltdWx0YW5lb3VzbHkgZHVyaW5nIGEgbWlncmF0aW9uLiBJbnN0 ZWFkIG9mIHByb2dyZXNzaW5nIGJ5IGluY3JlbWVudHMgb2YgMSwgdGhlIFBOIHdpbGwgcHJvZ3Jl c3MgYnkgaW5jcmVtZW50cyB0aGF0IGRlcGVuZHMgb24gdGhlIG51bWJlciBvZiBwYWNrZXRzIHNl bnQgb24gb3RoZXIgcGF0aHMuIFRoaXMgYWxsb3dzIGZvciBlYXN5IGNvcnJlbGF0aW9uIG9mIHRo ZXNlIHBhdGhzLCBkZXNwaXRlIHRoZSByYW5kb20gaW5jcmVtZW50Lg0KDQo+Pj4gWW91IG1pc3Nl ZCB0aGlzIHBhcnQgb2YgbXkgcmVwbHk6ICJvbmUgb3B0aW9uIHdvdWxkIGJlIHRvIGhhdmUgYSBv bmUgdGltZSBmaXhlZCBzaXplIHBhY2tldCBudW1iZXIganVtcCBmb3IgdGhlIG5ldyBwYXRoIHNv IHRoZSBudW1iZXJzIGRvbuKAmXQgZ2V0IGludGVybGVhdmVkIHdpdGggZ2Fwcy4gIiBzbyBpZiBw YWNrZXRzIGFyZSBzZW50IG9uIGJvdGggcGF0aHMgZm9yIGEgd2hpbGUgdGhleSB3aWxsIHN0aWxs IHByb2dyZXNzIGJ5IGluY3JlbWVudHMgb2YgMS4NCg0KSW4gc2hvcnQsIHRoaXMgc2ltcGxlIG9i ZnVzY2F0aW9uIGRvZXMgbm90IHByb3RlY3QgYWdhaW5zdCBvc3NpZmljYXRpb24gYW5kIGFsc28g ZG9lcyBub3QgcHJldmVudCBsaW5rYWJpbGl0eS4NCg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0K From nobody Tue Feb 6 23:20:16 2018 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 12A721205D3 for ; Tue, 6 Feb 2018 23:20:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 zHI98RtZZ0PH for ; Tue, 6 Feb 2018 23:20:13 -0800 (PST) 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 5A9D11204DA for ; Tue, 6 Feb 2018 23:20:13 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ejK1V-0005va-Ch for quic@ietf.org; Wed, 07 Feb 2018 08:20:11 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ejK0y-0008GZ-5c for quic@ietf.org; Wed, 07 Feb 2018 02:20:03 -0500 Received: (qmail 12340 invoked from network); 7 Feb 2018 07:19:31 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Feb 2018 07:19:31 -0000 To: Praveen Balasubramanian , "quic@ietf.org" References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> From: Christian Huitema Message-ID: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> Date: Tue, 6 Feb 2018 21:19:27 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F6CBBDCFA490218DC8928235" Content-Language: en-US Subject: Re: Packet number encryption X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.52) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5hEGR+G5YGY8IIBMfv0dgqAXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fu0YifY8vlY/dYJIUT7F0FyB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31WoCGUWNgo50bBZN3FfqI2VItAPyqRyV95ZNrHd7vkN RgSePfN67Je34MUaf5ne13bh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GsXtI24bFyeVoMfxdsPnJspnHEeB4hpRrmo/duzUUp/JI wA5/nrmgHZTZASJ1Qx2/0DkagYuUqlqG10HsyZ8TcXLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI++1t64FjSfNiueqrnpxei5Ij2lB9TLiDMfXuvSrucRXqrPome/rkmrOims9BAICUApsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g 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, 07 Feb 2018 07:20:15 -0000 This is a multi-part message in MIME format. --------------F6CBBDCFA490218DC8928235 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 2/6/2018 8:55 PM, Praveen Balasubramanian wrote: > First, the proposal does not obscure the position of the packet number field in the header. The field contains a number that increments with every packet, and is thus easy to identify. This means that middle-boxes will get accustomed to seeing that field and tracking its increments. > Hence, this simple obfuscation provides no protection against ossification of the packet number field. > >>>> Well it seems like it is a requirement (see bullet 3 in Jana's list) to allow middleboxes to see sequencing information. By picking the initial random value middleboxes cannot assume any particular value. If packet number location and size is not part of invariants then it cannot be ossified, middleboxes will need to be resilient. This is why I would rather see the exposed bits copied at a fixed location, while the PN itself cannot be located. That way, the exposed bits can ossify, but the actual PN does not. -- Christian Huitema --------------F6CBBDCFA490218DC8928235 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 2/6/2018 8:55 PM, Praveen Balasubramanian wrote:
First, the proposal does not obscure the position of the packet number field in the header. The field contains a number that increments with every packet, and is thus easy to identify. This means that middle-boxes will get accustomed to seeing that field and tracking its increments.
Hence, this simple obfuscation provides no protection against ossification of the packet number field.


Well it seems like it is a requirement (see bullet 3 in Jana's list) to allow middleboxes to see sequencing information. By picking the initial random value middleboxes cannot assume any particular value. If packet number location and size is not part of invariants then it cannot be ossified, middleboxes will need to be resilient.

This is why I would rather see the exposed bits copied at a fixed location, while the PN itself cannot be located. That way, the exposed bits can ossify, but the actual PN does not.

-- Christian Huitema
--------------F6CBBDCFA490218DC8928235-- From nobody Wed Feb 7 00:01:02 2018 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 6B204120726 for ; Wed, 7 Feb 2018 00:01:00 -0800 (PST) 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, 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=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 VTEIjh1iRbZ8 for ; Wed, 7 Feb 2018 00:00:57 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 45F761204DA for ; Wed, 7 Feb 2018 00:00:57 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id j23so2947129uak.13 for ; Wed, 07 Feb 2018 00:00:57 -0800 (PST) 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=jqocO9GK3Ue2AuzzFXnxQPn2WI274LnzmiaY6aCG5ag=; b=OwPhkSrojEPiR6Q5Mq+y0k4S2REri7Xau/OrvjnHzgq1hqaA8isGSfS8Sq42wYOfF1 KslI96n2dDAsle52gtqJqNvfNJt4C57db0yrV6FxH0hBkGVZ1xtqSuoUiq3+RzzxhD42 8CCPw/FjWVoWZJJHTfxL7dlWl2Xnz2MkftDtDKcsp3qCEqXBYBgXyfS0EBZiKq75JAWd hqnGtqWag4U52Y6sqxx9njOCLO1bIcFH/8aVoC3UjDFkfaYBQCoB56GvxlK+FyqaTj/E iYTtN7Y9mEBTeRU9FSR5JwFHCzAewGvKpkzlwxQ9QS/aTKdM4C3VN8SNnrS1yOT8djjt gXCw== 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=jqocO9GK3Ue2AuzzFXnxQPn2WI274LnzmiaY6aCG5ag=; b=VUHpipRwXP24jbpbDMDklFXCQegR+SUeFHJI9qYNrkLMZ5XpwWpJNjFh5iqbYvHbwu vsUfvLmZuuQwaG0IZNU7LjEyMiIZTvoc2Zeb/qBg3cZqmCA6t84Q36muI226GM1zSFES AxGnJhhwpMtW+eD9Vnrm9QU+FFBCw9AfB26tPiZ7UDLtAxwQ1YSLSCwSbs6ya/ADdLjp gtiQpUDCDx4P40chYvPkkIFsvrlp9xFkgnIQIstDEe4LUoWLo3tlNnNQfgruUHs1O4jN xiZ9PvbL/g5UBBaetostCX5XBT3Y1SUfegHTDDi/MflfpQtqCPy9HWqPn8OCekI/dhCk KQ+A== X-Gm-Message-State: APf1xPB6SAX7ASCvOAmLgrb1+quN+A6CqNQPqcx3Lfim8QbGXtJq8Dml QYqdr/uoc37pNmb681VY5uQQvnQJEHKP3jU51IE= X-Google-Smtp-Source: AH8x227dgNl8B78THU7orVDQ6w7TNClAOvBr1ZCJopEfncQYwJDeD3yGRRo5uttjcoqjLc5SW8DWALJyTV5QpFTfK3k= X-Received: by 10.176.4.165 with SMTP id 34mr129189uaw.183.1517990456138; Wed, 07 Feb 2018 00:00:56 -0800 (PST) MIME-Version: 1.0 References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> From: Marten Seemann Date: Wed, 07 Feb 2018 08:00:45 +0000 Message-ID: Subject: Re: Packet number encryption To: Christian Huitema Cc: Praveen Balasubramanian , "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c12585ae91f3605649ab1e1" 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, 07 Feb 2018 08:01:00 -0000 --94eb2c12585ae91f3605649ab1e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 7, 2018 at 3:20 PM Christian Huitema wrote: > > > On 2/6/2018 8:55 PM, Praveen Balasubramanian wrote: > > First, the proposal does not obscure the position of the packet number fi= eld in the header. The field contains a number that increments with every p= acket, and is thus easy to identify. This means that middle-boxes will get = accustomed to seeing that field and tracking its increments. > Hence, this simple obfuscation provides no protection against ossificatio= n of the packet number field. > > > Well it seems like it is a requirement (see bullet 3 in Jana's list) to a= llow middleboxes to see sequencing information. By picking the initial rand= om value middleboxes cannot assume any particular value. If packet number l= ocation and size is not part of invariants then it cannot be ossified, midd= leboxes will need to be resilient. > > > This is why I would rather see the exposed bits copied at a fixed > location, while the PN itself cannot be located. That way, the exposed bi= ts > can ossify, but the actual PN does not. > We still need to be very careful here. If we decide to expose bits, we must make sure that a middlebox can only extract coarse-grained information, if we want to prevent middleboxes from buffering and delaying packets in order to fix / reduce reordering. At this point however, I'm not convinced that exposing any reordering information to the network should be a requirement at all. There's a real risk of misuse of this information, and of ossification of whatever bits we expose. --94eb2c12585ae91f3605649ab1e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed= , Feb 7, 2018 at 3:20 PM Christian Huitema <huitema@huitema.net> wrote:



On 2/6/2018 8:55 P= M, Praveen Balasubramanian wrote:
First, the proposal does not obscure the position of the packet =
number field in the header. The field contains a number that increments wit=
h every packet, and is thus easy to identify. This means that middle-boxes =
will get accustomed to seeing that field and tracking its increments.
Hence, this simple obfuscation provides no protection against ossification =
of the packet number field.


Well it seems like it is a requirement (see bullet 3 in Ja=
na's list) to allow middleboxes to see sequencing information. By picki=
ng the initial random value middleboxes cannot assume any particular value.=
 If packet number location and size is not part of invariants then it canno=
t be ossified, middleboxes will need to be resilient.=20

This is why I would rather see the exposed bits copied at a fixed location, while the PN itself cannot be located. That way, the exposed bits can ossify, but the actual PN does not.
=

We still need to be very careful here. If we decide to = expose bits, we must make sure that a middlebox can only extract coarse-gra= ined information, if we want to prevent middleboxes from buffering and dela= ying packets in order to fix / reduce reordering.
At this point h= owever, I'm not convinced that exposing any reordering information to t= he network should be a requirement at all. There's a real risk of misus= e of this information, and of ossification of whatever bits we expose.
--94eb2c12585ae91f3605649ab1e1-- From nobody Wed Feb 7 00:07:31 2018 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 A6C581200C1; Wed, 7 Feb 2018 00:07:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: quic@ietf.org, lars@netapp.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org Subject: quic - New Interim Meeting Request X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151799084964.4819.14912070956005414090.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 00:07:29 -0800 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: Wed, 07 Feb 2018 08:07:30 -0000 A new interim meeting request has just been submitted by Lars Eggert. This request requires approval by the Transport Area Area Director The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2018-quic-02 --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert City: Kista Country: SE Session 1: Date: 2018-06-06 Start Time: 09:00 Europe/Berlin Duration: 08:00 Remote Participation Information: https://github.com/quicwg/wg-materials/blob/master/interim-18-06/arrangements.md Agenda Note: Preceded by non-IETF QUIC interop event on June 4-5, same location Session 2: Date: 2018-06-07 Start Time: 09:00 Europe/Berlin Duration: 08:00 Remote Participation Information: https://github.com/quicwg/wg-materials/blob/master/interim-18-06/arrangements.md Agenda Note: Preceded by non-IETF QUIC interop event on June 4-5, same location --------------------------------------------------------- From nobody Wed Feb 7 00:38:44 2018 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 64793126BF0 for ; Wed, 7 Feb 2018 00:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 Zva3fnYO1O4v for ; Wed, 7 Feb 2018 00:38:41 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 607381200C1 for ; Wed, 7 Feb 2018 00:38:41 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id f4so1145937ioh.8 for ; Wed, 07 Feb 2018 00:38:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=wC4QLOyZmxLyMirlX8JXoy/iklP9m67zjV9c5eq53AY=; b=gvV+0PRpHOghudUXqkVE8t2nlH2MGD/+KsXUxjUz2OOcKTf9f9RpC8pAvVay1yEjA+ oJRq/0JYCyg1xiaeE4ks+U/fii4z3YqIaS1BBdON1vyjJFT17o7ZEToOJ5iMtzwVANFs 7XB78210PMbNzEccyVfoQjIBDEue9v2+0YtU+fcCGcVTXDuefgrfNGIvUV8Yp5pV0Jfl mWzML8um5zLBdhcGwSzYeA0ma+ewA5cm3+iJocUrbGhOExqF3KgHxE3RCZK4BZ7HaaXL lwYNY8XK3/f4GPQoXk2u2c0tm2V20r+0KkIQLy9I+Q0J0cfIeswkfvCNo9W1qwiyIfmN r1lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=wC4QLOyZmxLyMirlX8JXoy/iklP9m67zjV9c5eq53AY=; b=LVwmHJXXhh+dXPP7jCS+3YockFhaNLI1BWhNe5kmtulM7+yjd0ps6VRxD/4gbm/2Nu DWy2jNnjH7aGkEXskUBBOhs3BHNCGx2UNK3E+9eVUZPuHD29jgHztTkaD7bMsJqDhQm5 AkEsF6BG6mz0zf0MPj47nEjFAOUcmmSPrzjA1CbqW6M/75Zbl4aGdODnBElFQzGhfi+R 2+iyMz3MO7RB+GLUtrXIco0sWvHC7rbFefH0UIoem9eFinZudKE23u998SojBBqllwo4 ro99Ze+NJ9ImtwKyZ55iNMYjSEGtSoFaX8Hpq3JZrokqnM2NR/8DURIsVltymQP3Leu5 Zn3g== X-Gm-Message-State: APf1xPBOj2Hf12IVEZwGv3uyuxO14E3zn8VwCYBe6VVkU34Y4lbwqebU M+uEEju74/9quYlrlX5ooy+B1Rqcl/a7qpC6L90= X-Google-Smtp-Source: AH8x224HhKRZpjQS8A3tPuo5uUNVhGRrX/IQJ5JtTofnA8FRtUahBYi5Mxowasjf9aO6E90CwFa0ZZMTptAK5K3yHLM= X-Received: by 10.107.20.200 with SMTP id 191mr6648058iou.239.1517992720602; Wed, 07 Feb 2018 00:38:40 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 7 Feb 2018 00:38:39 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 7 Feb 2018 00:38:39 -0800 Message-ID: Subject: Re: Packet number encryption To: Christian Huitema , Marten Seemann Cc: "quic@ietf.org" , Praveen Balasubramanian Content-Type: multipart/alternative; boundary="001a114fd4c8e21c0705649b3823" 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, 07 Feb 2018 08:38:43 -0000 --001a114fd4c8e21c0705649b3823 Content-Type: text/plain; charset="UTF-8" > This is why I would rather see the exposed bits copied at a fixed > location, while the PN itself cannot be located. That way, the exposed bits > can ossify, but the actual PN does not. > We still need to be very careful here. If we decide to expose bits, we must make sure that a middlebox can only extract coarse-grained information, if we want to prevent middleboxes from buffering and delaying packets in order to fix / reduce reordering. At this point however, I'm not convinced that exposing any reordering information to the network should be a requirement at all. There's a real risk of misuse of this information, and of ossification of whatever bits we expose. I am fairly convinced that you can and should separate exposure to middleware from packet numbers in whatever form precisely because we want packet numbers to not rely on path and because packet numbers may expose false loss if exposed directly in whatever form. A path specific counter can be done be exposing a few bits of an internal path specific counter that is entirely independent of packet numbering used for AEAD IV and is also independent of any artificial packet number skipping for ACK attack mitigation etc.. It could also be done be emitting a known 1-bit signal whose pattern can be used to identify deviance from that pattern, as discussed in separate thread, e.g. a square wave or a public pseudo-random sequence. The next, and separate question is then, do we want to expose anything even if it only leaks information about loss and reordering on a single path? It could lead to unwanted latency due to middleware packet sorting. It is a very good point, but the concern might be based on a historical case that does not apply to current UDP or future QUIC transports. However, if ordering is exposed as a pseudo-random 1-bit signal such as the Pi sequence, then middleware would have to work very harder than it would find worthwhile to sort packets back in order. --001a114fd4c8e21c0705649b3823 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

This is why I w= ould rather see the exposed bits copied at a fixed location, while the PN i= tself cannot be located. That way, the exposed bits can ossify, but the act= ual PN does not.

We still need to be = very careful here. If we decide to expose bits, we must make sure that a mi= ddlebox can only extract coarse-grained information, if we want to prevent = middleboxes from buffering and delaying packets in order to fix / reduce re= ordering.
At this point however, I'm not convinced that expos= ing any reordering information to the network should be a requirement at al= l. There's a real risk of misuse of this information, and of ossificati= on of whatever bits we expose.

I am fairly convinced that you can and should separate exposu= re to middleware from packet numbers in whatever form precisely because we = want packet numbers to not rely on path and because packet numbers may expo= se false loss if exposed directly in whatever form.

A path specific c= ounter can be done be exposing a few bits of an internal path specific coun= ter that is entirely independent of packet numbering used for AEAD IV and i= s also independent of any artificial packet number skipping for ACK attack = mitigation etc.. It could also be done be emitting a known 1-bit signal who= se pattern can be used to identify deviance from that pattern, as discussed= in separate thread, e.g. a square wave or a public pseudo-random sequence.=

The next, and separate question is then, do we want to expose anythi= ng even if it only leaks information about loss and reordering on a single = path? It could lead to unwanted latency due to middleware packet sorting. I= t is a very good point, but the concern might be based on a historical case= that does not apply to current UDP or future QUIC transports. However, if = ordering is exposed as a pseudo-random 1-bit signal such as the Pi sequence= , then middleware would have to work very harder than it would find worthwh= ile to sort packets back in order.

=
--001a114fd4c8e21c0705649b3823-- From nobody Wed Feb 7 01:10:10 2018 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 69BFC126CC7 for ; Wed, 7 Feb 2018 01:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 e3u9kjpC5SYc for ; Wed, 7 Feb 2018 01:10:06 -0800 (PST) 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 16CDF126BF0 for ; Wed, 7 Feb 2018 01:10:05 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id c80so1390880itb.4 for ; Wed, 07 Feb 2018 01:10:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Zqa6tRubUBCJoWTuWQI/e1vsF54kw/xg+J+ujt/brkM=; b=cu64Q80PfNnY8n4rkl1iHtgOZySdKZivHtRC+jDFdz05+IBhC+V01qeZuBlD6D6RWe 3a2rkfjHdpzT9C8qBOd/dLXjSLFUB0AdK+E+qH+IyuFkTmd9k+iemP3A09wJ3Cb/EYX8 nO1zOmUK3uRgM9MaHwbPkWK6QD/jjZZq0VhxVsS4yA0EbvfpHDijjJTNoo32RspLO2gZ IRe8NB7nfVwV1D4TQju8JyiOfKTp4IP0WqNc8lfqyh6DN2AYxhuRk//osdTNCwKEaB2X tWRRnqm0V/Scd2NvbYHM9ghep7bSdsfXWLDhw/fm4/1C1T4Ktnrgqj4Kevh4xm7WFiVU pxAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Zqa6tRubUBCJoWTuWQI/e1vsF54kw/xg+J+ujt/brkM=; b=IcYSM6w52hhmxwbqFJW1JWReJ+ZkV02caagSfJypAARQbSdVYXMpNRzveF3otPNLiL QJEvf4RcREMhuhj+NPt865Bl6GUii0f9QRWU9+K99lNI8nQIifZFnRLlz1BQioryE7py pbk1VzBfrGyiz2sbwFvs2c0+JJK5d9Cj8trTu94NcWQut/c/G2XDtAnUFBbPxDfISZ7m TBbVT0nX8ocUB0JFFPgnzTpDvFYVA76YJbxOTyV1s+RW5W4X25iJFMarxDYSsgYGhz5+ pK7ozCaxK0eMD86fKcAnvK6xAxQhilnmZUWknJpYRlu1iLIORseRWM0dmiLfeGilkYXi Dolg== X-Gm-Message-State: APf1xPBc1J+YI1UAl5HpvEysefhbxTwbMZaOO13v++Qx4uoFM/oTVpzQ EXdtUeyUBSMHp6x9fyESH4R/T6nT2O+zXtqTham6LTE2 X-Google-Smtp-Source: AH8x227UqmJUy/y1/rbFBN02pWUeBE4bo5CwajReDDpboqOpjh5rQFP/SuAySSFKl7nX+Cm+qkWZ7J5e5fyI7beG5GM= X-Received: by 10.36.131.194 with SMTP id d185mr7341299ite.31.1517994605093; Wed, 07 Feb 2018 01:10:05 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 7 Feb 2018 01:10:04 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 7 Feb 2018 01:10:04 -0800 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: Kazuho Oku Cc: "Brian Trammell (IETF)" , QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0496523528e605649ba96d" 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, 07 Feb 2018 09:10:08 -0000 --94eb2c0496523528e605649ba96d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Instead of a static Pi table, an xorshift+ PRNG could be used. It would likely be preferable to shorten the cycle such that observers can use hash lookups and hamming distance computations against selected segments of the sequence. https://en.wikipedia.org/wiki/Xorshift#xorshift+ http://xoroshiro.di.unimi.it/xorshift128plus.c uint64_t s[2]; uint64_t next(void) { uint64_t s1 =3D s[0]; const uint64_t s0 =3D s[1]; const uint64_t result =3D s0 + s1; s[0] =3D s0; s1 ^=3D s1 << 23; // a s[1] =3D s1 ^ s0 ^ (s1 >> 18) ^ (s0 >> 5); // b, c return result; } A simpler 32-bit version could also be used since we do not care about long cycles. http://excamera.com/sphinx/article-xorshift.html uint32_t seed =3D 7; // 100% random seed value static uint32_t random() { seed ^=3D seed << 13; seed ^=3D seed >> 17; seed ^=3D seed << 5; return seed; } The output would be the bits shifted out of the 32-bit our 64-bit word in either MSB or LSB first. I=E2=80=99d prefer LSB because it is slightly simp= ler to test the LSB bit and divide by 2. On 7 February 2018 at 01.29.18, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: Also note that this approach is insensitive to skipped packet numbers in optimistic ACK attack defence. It leaks zero information when the network is perfect and if the CID hash is random. ------------------------------ *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen *Sent:* Wednesday, February 7, 2018 12:58:33 AM *To:* Kazuho Oku *Cc:* Brian Trammell (IETF); QUIC WG *Subject:* Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) I actually think a static 1KB table of Pi could work quite well. A subset of samples could be indexed in a hashtable and yield loss data early with some probability. Some samples would miss due to reordering or loss. If more exact analysis is wanted the levenshtein distance of a sample sequence against Pi from a synced offset would tell a lot about the data. Or DNA sequencing. This could be hardware optimized. Yet, transmission is always just the next bit in the Pi table. Since Pi is effectively random it will ebentually detect mutations if the observed sequence is long enough. Wrt privacy, the CID may be used as a start offset hash into the Pi table. There isn=E2=80=99t any need to cover a full RTT worth of Pi bits unless it= is used for latency detection, but in that case the spin could be a pattern like 10101010 and 00001111 injected into the Pi sequence. A separate spin bit would be simpler. ------------------------------ *From:* Kazuho Oku *Sent:* Tuesday, February 6, 2018 5:22:35 PM *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen *Cc:* Brian Trammell (IETF); QUIC WG *Subject:* Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) 2018-02-06 23:54 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen : > This idea can be taken further: You can modulate the signal so you use > multiple packets to encode a zero or a one for half the wave duration. Fo= r > example 1 could be encoded as 0101 over four packets and zero could be > encoded as 0011 over four packets. > If there is any reordering, it would show up as an unexpected value in th= e > pulse. That's definitely an option. Actually, I considered using sin wave (that distributes the error among 1-bit samples) as an example instead of the square wave. The primary reason behind my preference to using a square wave is that it is easier to implement; in fact, emitting a square wave with the length of 512 packets is as easy as just taking the 9th bit (counting from LSB) of the packet number (if we forget about the gaps for a moment). -- Kazuho Oku --94eb2c0496523528e605649ba96d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Instead of a static = Pi table, an xorshift+ PRNG could be used. It would likely be preferable to= shorten the cycle such that observers can use hash lookups and hamming dis= tance computations against selected segments of the sequence.


uint64_t s[=
2];

uint64_t next(void) {
	uint64_t s1 =3D s[0];
	const uint64_t s0 =3D s[1];
	const uint64_t result =3D s0 + s1;
	s[0] =3D s0;
	s1 ^=3D s1 << 23; // a
	s[1] =3D s1 ^ s0 ^ (s1 >> 18) ^ (s0 >> 5); // b, c
	return result; =20
}

A simpler 32-bit version could also be used since we do not care about lon=
g cycles.

uint32_t seed =3D 7; =C2=A0// 100% random seed val= ue

static uint32_t random()
{
= =C2=A0 seed ^=3D seed << 13;
=C2=A0 seed ^=3D seed >>= 17;
=C2=A0 seed ^=3D seed << 5;
=C2=A0 return se= ed;
}


The output = would be the bits shifted out of the 32-bit our 64-bit word in either MSB o= r LSB first. I=E2=80=99d prefer LSB because it is slightly simpler to test = the LSB bit and divide by 2.

On 7 February = 2018 at 01.29.18, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

Also note that this approach is insensitive to skipped packet numbers in optimistic ACK attack defence. It leaks zero information when the network is perfect and if the CID hash is random.

From: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com= >
Sent: Wednesday, February 7, 2018 12:58:33 AM
To: Kazuho Oku
Cc: Brian Trammell (IETF); QUIC WG
Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)
=C2=A0
I actually think a static 1KB table of Pi could work quite well.

A subset of samples could be indexed in a hashtable and yield loss data early with some probability. Some samples would miss due to reordering or loss. If more exact analysis is wanted the levenshtein distance of a sample sequence against Pi from a synced offset would tell a lot about the data. Or DNA sequencing. This could be hardware optimized.

Yet, transmission is always just the next bit in the Pi table.

Since Pi is effectively random it will ebentually detect mutations if the observed sequence is long enough.

Wrt privacy, the CID may be used as a start offset hash into the Pi table.

There isn=E2=80=99t any need to cover a full R= TT worth of Pi bits unless it is used for latency detection, but in that case the spin could be a pattern like 10101010 and 00001111 injected into the Pi sequence. A separate spin bit would be simpler.


From: Kazuho Oku <kazuhooku@gmail.com>
Sent: Tuesday, February 6, 2018 5:22:35 PM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen
Cc: Brian Trammell (IETF); QUIC WG
Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption)
=C2=A0
20= 18-02-06 23:54 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>:
> This idea can be taken further: You can modulate the signal so you use
> multiple packets to encode a zero or a one for half the wave duration. For
> example 1 could be encoded as 0101 over four packets and zero could be
> encoded as 0011 over four packets.
> If there is any reordering, it would show up as an unexpected value in the
> pulse.

That's definitely an option.

Actually, I considered using sin wave (that distributes the error
among 1-bit samples) as an example instead of the square wave.

The primary reason behind my preference to using a square wave is that
it is easier to implement; in fact, emitting a square wave with the
length of 512 packets is as easy as just taking the 9th bit (counting
from LSB) of the packet number (if we forget about the gaps for a
moment).


--
Kazuho Oku
--94eb2c0496523528e605649ba96d-- From nobody Wed Feb 7 02:10:25 2018 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 B5A25126CC7 for ; Wed, 7 Feb 2018 02:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 RiVCEEq9bxGF for ; Wed, 7 Feb 2018 02:10:22 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 F07AF1243F3 for ; Wed, 7 Feb 2018 02:10:21 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id u6so249116oiv.9 for ; Wed, 07 Feb 2018 02:10:21 -0800 (PST) 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=tArsiOrxroq17ksRJXZGinVlqOHQ1szjJlXWY3BD95o=; b=i1LKoV2sh7zIXQAXOHgBykpyzDfut/ewXHpUAMhkj/pQU0bUjBfCQEuUc2EXzBx5e3 dFJYCby0mlvf65VCaCBTHDxbpgr/KD6+W7Vis5GZPz8g9ahT5jT2aHn3GDa83fDnKiUr sNvPvaZMLkThcYQYLbiukfO6Ia7ig4jbcvyeUs0Gz7P7GSQodvZtsK3EOUUf5gWgc86E l15B/WAw58qqMeOqFrnL4aqb5dWRaeAI/tsQ93YsoY3gmlBG+K0GLko42oWezmRwS5z/ sUjaMe6q1Iu7dpd308rNRiTUSSNBFBcV1/OHltEeA6Gk5naRQYWCB7bPCS9Cwtbh0AW5 N8tQ== 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=tArsiOrxroq17ksRJXZGinVlqOHQ1szjJlXWY3BD95o=; b=CYWBFpy1+2JBRrEiQ/dyd5jEWc1UwbEpdeABTADEE6s330eFasIM7wQgKuyPHBP7Mb eWNMIdUSqmZRv4AmgcqxlaUGyui9Q/VnFyLSy7wrDcm5hpMesfwVlpNaewh3Az0tqSRK e42wQKr+GA7HoCzjSTFyTEwUJV2dVO3TprJ9dfLfmKHfyPQumD8NLrebhXsjUlwMs4Ga q+z7pEbZ8wgDzg16tO/aA6e3IphbSbeI7WxDULIhThaU2WN4gTjDqklJkfcAjwe7/Ksa QyALwrExsPR+/aJQz6b1iz8CWbp0TcY1NvXzkYDaloKJPyG23alB1PbO+opawP69ZkLH UzoQ== X-Gm-Message-State: APf1xPBCMWnMEmx6Ta+wGIEwvhulguGDiMR7CFjKijLv2L0uuX5Opr0+ C0jgw/asQQAtjANgQZ/DStCfLZBOTlodL3UxjtE= X-Google-Smtp-Source: AH8x224O+4m7AwV4UU5EmQUaPd+Ofxvka/MVMIalwzTM1h8XhNw6Jq6wAxIOahJQ1z/+0dx6bY5zEkwplJARux85LsU= X-Received: by 10.202.184.4 with SMTP id i4mr3252294oif.273.1517998220980; Wed, 07 Feb 2018 02:10:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Wed, 7 Feb 2018 02:10:20 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> From: Martin Thomson Date: Wed, 7 Feb 2018 21:10:20 +1100 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Kazuho Oku , "Brian Trammell (IETF)" , 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, 07 Feb 2018 10:10:24 -0000 I looked into these when I first considered packet number encryption. They are not typically bijective on 2^N-1. That's not a great outcome here. Also, random access is a requirement and that isn't straightforward here, even with the good ones. Also reversing is possible, but more complicated. On Wed, Feb 7, 2018 at 8:10 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Instead of a static Pi table, an xorshift+ PRNG could be used. It would > likely be preferable to shorten the cycle such that observers can use has= h > lookups and hamming distance computations against selected segments of th= e > sequence. > > https://en.wikipedia.org/wiki/Xorshift#xorshift+ > > http://xoroshiro.di.unimi.it/xorshift128plus.c > > uint64_t s[2]; > > uint64_t next(void) { > uint64_t s1 =3D s[0]; > const uint64_t s0 =3D s[1]; > const uint64_t result =3D s0 + s1; > s[0] =3D s0; > s1 ^=3D s1 << 23; // a > s[1] =3D s1 ^ s0 ^ (s1 >> 18) ^ (s0 >> 5); // b, c > return result; > } > > > A simpler 32-bit version could also be used since we do not care about lo= ng > cycles. > > http://excamera.com/sphinx/article-xorshift.html > > uint32_t seed =3D 7; // 100% random seed value > > static uint32_t random() > { > seed ^=3D seed << 13; > seed ^=3D seed >> 17; > seed ^=3D seed << 5; > return seed; > } > > > The output would be the bits shifted out of the 32-bit our 64-bit word in > either MSB or LSB first. I=E2=80=99d prefer LSB because it is slightly si= mpler to > test the LSB bit and divide by 2. > > On 7 February 2018 at 01.29.18, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkel= fj@gmail.com) > wrote: > > Also note that this approach is insensitive to skipped packet numbers in > optimistic ACK attack defence. It leaks zero information when the network= is > perfect and if the CID hash is random. > > ________________________________ > From: Mikkel Fahn=C3=B8e J=C3=B8rgensen > Sent: Wednesday, February 7, 2018 12:58:33 AM > To: Kazuho Oku > Cc: Brian Trammell (IETF); QUIC WG > Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packe= t > number encryption) > > I actually think a static 1KB table of Pi could work quite well. > > A subset of samples could be indexed in a hashtable and yield loss data > early with some probability. Some samples would miss due to reordering or > loss. If more exact analysis is wanted the levenshtein distance of a samp= le > sequence against Pi from a synced offset would tell a lot about the data.= Or > DNA sequencing. This could be hardware optimized. > > Yet, transmission is always just the next bit in the Pi table. > > Since Pi is effectively random it will ebentually detect mutations if the > observed sequence is long enough. > > Wrt privacy, the CID may be used as a start offset hash into the Pi table= . > > There isn=E2=80=99t any need to cover a full RTT worth of Pi bits unless = it is used > for latency detection, but in that case the spin could be a pattern like > 10101010 and 00001111 injected into the Pi sequence. A separate spin bit > would be simpler. > > > ________________________________ > From: Kazuho Oku > Sent: Tuesday, February 6, 2018 5:22:35 PM > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen > Cc: Brian Trammell (IETF); QUIC WG > Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packe= t > number encryption) > > 2018-02-06 23:54 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen : >> This idea can be taken further: You can modulate the signal so you use >> multiple packets to encode a zero or a one for half the wave duration. F= or >> example 1 could be encoded as 0101 over four packets and zero could be >> encoded as 0011 over four packets. >> If there is any reordering, it would show up as an unexpected value in t= he >> pulse. > > That's definitely an option. > > Actually, I considered using sin wave (that distributes the error > among 1-bit samples) as an example instead of the square wave. > > The primary reason behind my preference to using a square wave is that > it is easier to implement; in fact, emitting a square wave with the > length of 512 packets is as easy as just taking the 9th bit (counting > from LSB) of the packet number (if we forget about the gaps for a > moment). > > > -- > Kazuho Oku From nobody Wed Feb 7 02:24:00 2018 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 9A6ED126C19 for ; Wed, 7 Feb 2018 02:23:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 tcdzFBFJBvrY for ; Wed, 7 Feb 2018 02:23:58 -0800 (PST) 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 07107120727 for ; Wed, 7 Feb 2018 02:23:58 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id u12-v6so14964940ite.0 for ; Wed, 07 Feb 2018 02:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=YKQD60bweJ9vOO/Ny2efJ2FbjyV7w6RD6USMetmNkus=; b=KdV9DWdDnL4TwLbo1jOdTcwxfnlqfGBPJ+TCKT/ozS+dyQV5D4ENRQ4COL2QfMIMAj wZEtrULpccdy6DIRp1WjKvUbnnnEOhpC6FO/3W2TJeHZte9DrKVbM3/yASl2Hn4+Jatn F2OGS5+5kKcnTjoH/8MS7Yhg6LGUoL7doAv1D2WrSUWmzU4/Di2dTt1cxrFRtSSK5S0h mauvNhrqRKXWya68Z2S9TrZ4+LEFAi3fr7BYIIwx5XjhKkYik9cWJmUGiwE230NI7h9h TIT4MkAR6aA4SEEhcXQ6xnTdhwOQad97BMYYuu0Cn6mMe60O+vQPmDSdJX3RcW/IQ0VZ nijg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=YKQD60bweJ9vOO/Ny2efJ2FbjyV7w6RD6USMetmNkus=; b=rHqQggoIGGTvqlYemL6RF8kyHUGe3yFmKy+EVjw0lsdPV2N3YHMWkH2iGfHMNJKLmX C2eoT90HRjrGP2nGjTPBNENA0qLHAwP56AkvQr+ZgozEYsOeYwmuc5XWHIeaRIVWSqqa 6d8Hc3Ui9jDh7tT+JwkR/tDg5XV8zo2ycMP66zb0XMRJ+qtSrmlPpHB+liwNfW5uuU0e +6OQ0zXYVKFPsG9gafAhat3NmiI0hRA5rSxwP4QVnMSy5QZB9haA5BidMo2neeGekPt8 t6w3DdKPgO3izJTCqADg2xJ2doYXrrNFUzg8lqP+FUdB8UpuWWhDHEcDej/P+63nm5mV Dp5g== X-Gm-Message-State: APf1xPAk5MHKzbvgvaqPNVft8lE5GEGBx4r6KCJtXM+tRYXCMrh5YgLj RWN9VEge+A0S4BqF5kWVV/O1jv+Ejqd1Rp4kwbU= X-Google-Smtp-Source: AH8x226YTUCRo9SzIqLeCYh/VHrWh+7pJLp14S56X0RIiMEDo7eoZCaAfrp7unD+nxBg3mD69MPoQAWP6hvtsV7a7HQ= X-Received: by 10.36.178.26 with SMTP id u26mr7038759ite.4.1517999037284; Wed, 07 Feb 2018 02:23:57 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 7 Feb 2018 02:23:56 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 7 Feb 2018 02:23:56 -0800 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: Martin Thomson Cc: QUIC WG , "Brian Trammell (IETF)" , Kazuho Oku Content-Type: multipart/alternative; boundary="f403045d914c63042c05649cb174" 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, 07 Feb 2018 10:24:00 -0000 --f403045d914c63042c05649cb174 Content-Type: text/plain; charset="UTF-8" On 7 February 2018 at 11.10.21, Martin Thomson (martin.thomson@gmail.com) wrote: I looked into these when I first considered packet number encryption. Hi Martin, I think you might be misreading the intention behind this sequence. The idea is to generate 1 bit for every packet sent on a specific path, in the order the packet was sent, not to encode packet numbers directly. The encoding of packet numbers is a separate thing whether encrypted or otherwise. When an observer collects these bits into words from several packets, it is possible to compare the gathered string with the expected sequence. The random access is only needed for analytical purposes to know about packet loss in the network, not to operate the QUIC transport as such. If the sequence is fixed and repeats with reasonable cycle length, it can be done efficiently in hardware. It is true that if you sample, say 32 bits, the mapping is not bijective so if you match the sequence, it is ambiguous. But since you already know what to expect next and you can choose the sample length as long as you want, say 128 bits, you do get very good information about where loss and reordering happened. If the sequence was not random, you would not have this property. As to reverse engineering, packets are already sent in order, so learning what the original order was, is hardly a significant compromise, except if you have multiple connections on the same tuple without transmitting an observable connection ID. --f403045d914c63042c05649cb174 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

On 7 February 2018 at 11.10.21, Martin Thomson (martin.thomson@gmail.com) wrote:

<= div>
I looked into these when I first considered packet number encryption.=C2=A0

Hi Martin, I think you might be misreading the intention behin= d this sequence.

The idea is to generate 1 bit for every packet sent = on a specific path, in the order the packet was sent, not to encode packet = numbers directly. The encoding of packet numbers is a separate thing whethe= r encrypted or otherwise.

When an observer collects these bits into w= ords from several packets, it is possible to compare the gathered string wi= th the expected sequence.

The random access is only needed for analyt= ical purposes to know about packet loss in the network, not to operate the = QUIC transport as such. If the sequence is fixed and repeats with reasonabl= e cycle length, it can be done efficiently in hardware.

It is true th= at if you sample, say 32 bits, the mapping is not bijective so if you match= the sequence, it is ambiguous. But since you already know what to expect n= ext and you can choose the sample length as long as you want, say 128 bits,= you do get very good information about where loss and reordering happened.= If the sequence was not random, you would not have this property.

As= to reverse engineering, packets are already sent in order, so learning wha= t the original order was, is hardly a significant compromise, except if you= have multiple connections on the same tuple without transmitting an observ= able connection ID.


--f403045d914c63042c05649cb174-- From nobody Wed Feb 7 03:10:10 2018 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 6E19C126C0F for ; Wed, 7 Feb 2018 03:10:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 QNsld3hAKc7Q for ; Wed, 7 Feb 2018 03:10:06 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (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 6F936124D6C for ; Wed, 7 Feb 2018 03:10:06 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id x25so159032pge.3 for ; Wed, 07 Feb 2018 03:10:06 -0800 (PST) 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=QwiLzwDM6q6ikmZUHzXpfKhi+NaiNKM9rN2pGd7w3Ek=; b=QHCmKdbOtb7OZBi0RHadV+oW/Gs3YQZkMn2C9yeA+FZKZmt97J/zMpL9W0HdudoLHp tyhE+skr7beHI1L2KrGCwiCckmKmUqPR8viriXAVBQYgRzOCN2ks0R+MVl0FMl4gj590 e+Sz/BbOafJxwvNXGpMrJwcxbIPLvZtZlnTcUWiWJqgY30LYTMDaVJJ67a0k27S2ZWjF IH2YQHM8tkPWhSOyUF8VyQgcsiPUHcIzlDAvKZr3QQE++SMqFmZ6gjaHWI5bbnfPuUi1 cdQBkU7SVcxxycrN7tymyAlMjc4DLV8X3Xe7LHQ6JSOThW2j1Z2lx2b3JUg/ed9iuzQy mCkw== 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=QwiLzwDM6q6ikmZUHzXpfKhi+NaiNKM9rN2pGd7w3Ek=; b=JPwS/KZG6K/9eFCOB8YyCtTLtqCSyafEwV2k5HIhNQAVXX/l9r5nS4ZIe0Toq6X+sk y5F9kLwPN2SDxqbTKeyYJdMqTJZZKFYsJe/hyrZRtroAeLPMYhTZnE8PWgDmo037Rcd9 bEO0LQ/wnACxagiY6ehqXrTY+6CdkB7oq9qqiSsMaF+AKx2+j6MlPsxBw9VkTleWM248 WViBQwlkmAmI64ETT1Y/qLhtgDR5AVnk71O7HMaOjcs/1VallePhgM4W7GKEz+tVtU8D hO+b9GTOnpRghU7WLE9ui3VbVZfBDPJeg9GIA46l2hUe2wVpPDcI8jvRC3vx7dmTkPak PNbQ== X-Gm-Message-State: APf1xPCbbkB3ZAkEx2UuHojbVudVRNre4BsG8p0NkSmKoBn7/Goz1s+S cqmd+6Cf1pvc9rqKdioH/XhonWIeDOfmHAWSh40= X-Google-Smtp-Source: AH8x225SJwBouBPQKWg59NNQJP3vFdm0B23Pg3A6koBhH4TCjKf59r7Y9h57j9Xdc6U4QUaKT4GomRG98EGd5f6E9JY= X-Received: by 10.98.19.19 with SMTP id b19mr5708335pfj.118.1518001803660; Wed, 07 Feb 2018 03:10:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Wed, 7 Feb 2018 03:10:02 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> From: Kazuho Oku Date: Wed, 7 Feb 2018 20:10:02 +0900 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: "Brian Trammell (IETF)" , 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, 07 Feb 2018 11:10:08 -0000 2018-02-07 18:10 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen : > Instead of a static Pi table, an xorshift+ PRNG could be used. It would > likely be preferable to shorten the cycle such that observers can use has= h > lookups and hamming distance computations against selected segments of th= e > sequence. The pros of using a sequence that randomly distributes 0 and ones (i.e. PI or xorshift+) is that you can extract good loss / reordering information if the error rate is low. OTOH, it is fragile to high error rate or certain patterns of error. Let me explain two examples. Consider the case where the packet loss rate is 50%. I doubt if you could use pattern matching against those sequences to figure out the loss rate. This is because the power among the sequence is mostly high frequencies. If you use a sequence that distributes power among lower frequencies (like square wave or sin wave that I discussed), you can calculate the loss rate in such cases as well. Consider another case where the sender uses multiple queues to emit packets belonging to a single QUIC connection (BTW, I plan to implement such one). You would see non-neglible amount of reorders. On the wire, it will look like if two adjacent packets packets were swapped; it wouldn't have any practical impact on performance. But such frequent reordering will destroy the observability of a random sequence. To summarize, I think that we need a low frequency signal. It could either be a square wave or sin wave. Using a sin wave might be better here, since you the bit pattern (which flips a lot) to observe at a higher precision when the the error rates of loss and reorder are both low. > > https://en.wikipedia.org/wiki/Xorshift#xorshift+ > > http://xoroshiro.di.unimi.it/xorshift128plus.c > > uint64_t s[2]; > > uint64_t next(void) { > uint64_t s1 =3D s[0]; > const uint64_t s0 =3D s[1]; > const uint64_t result =3D s0 + s1; > s[0] =3D s0; > s1 ^=3D s1 << 23; // a > s[1] =3D s1 ^ s0 ^ (s1 >> 18) ^ (s0 >> 5); // b, c > return result; > } > > > A simpler 32-bit version could also be used since we do not care about lo= ng > cycles. > > http://excamera.com/sphinx/article-xorshift.html > > uint32_t seed =3D 7; // 100% random seed value > > static uint32_t random() > { > seed ^=3D seed << 13; > seed ^=3D seed >> 17; > seed ^=3D seed << 5; > return seed; > } > > > The output would be the bits shifted out of the 32-bit our 64-bit word in > either MSB or LSB first. I=E2=80=99d prefer LSB because it is slightly si= mpler to > test the LSB bit and divide by 2. > > On 7 February 2018 at 01.29.18, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkel= fj@gmail.com) > wrote: > > Also note that this approach is insensitive to skipped packet numbers in > optimistic ACK attack defence. It leaks zero information when the network= is > perfect and if the CID hash is random. > > ________________________________ > From: Mikkel Fahn=C3=B8e J=C3=B8rgensen > Sent: Wednesday, February 7, 2018 12:58:33 AM > To: Kazuho Oku > Cc: Brian Trammell (IETF); QUIC WG > Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packe= t > number encryption) > > I actually think a static 1KB table of Pi could work quite well. > > A subset of samples could be indexed in a hashtable and yield loss data > early with some probability. Some samples would miss due to reordering or > loss. If more exact analysis is wanted the levenshtein distance of a samp= le > sequence against Pi from a synced offset would tell a lot about the data.= Or > DNA sequencing. This could be hardware optimized. > > Yet, transmission is always just the next bit in the Pi table. > > Since Pi is effectively random it will ebentually detect mutations if the > observed sequence is long enough. > > Wrt privacy, the CID may be used as a start offset hash into the Pi table= . > > There isn=E2=80=99t any need to cover a full RTT worth of Pi bits unless = it is used > for latency detection, but in that case the spin could be a pattern like > 10101010 and 00001111 injected into the Pi sequence. A separate spin bit > would be simpler. > > > ________________________________ > From: Kazuho Oku > Sent: Tuesday, February 6, 2018 5:22:35 PM > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen > Cc: Brian Trammell (IETF); QUIC WG > Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packe= t > number encryption) > > 2018-02-06 23:54 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen : >> This idea can be taken further: You can modulate the signal so you use >> multiple packets to encode a zero or a one for half the wave duration. F= or >> example 1 could be encoded as 0101 over four packets and zero could be >> encoded as 0011 over four packets. >> If there is any reordering, it would show up as an unexpected value in t= he >> pulse. > > That's definitely an option. > > Actually, I considered using sin wave (that distributes the error > among 1-bit samples) as an example instead of the square wave. > > The primary reason behind my preference to using a square wave is that > it is easier to implement; in fact, emitting a square wave with the > length of 512 packets is as easy as just taking the 9th bit (counting > from LSB) of the packet number (if we forget about the gaps for a > moment). > > > -- > Kazuho Oku --=20 Kazuho Oku From nobody Wed Feb 7 03:27:13 2018 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 A6FAD126C0F for ; Wed, 7 Feb 2018 03:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.438 X-Spam-Level: X-Spam-Status: No, score=-1.438 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 utgN0vJt6_-H for ; Wed, 7 Feb 2018 03:26:59 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 AF783129516 for ; Wed, 7 Feb 2018 03:26:59 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id n206so1839755itg.1 for ; Wed, 07 Feb 2018 03:26:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=yMQFQFIjLE2NVuHFAtE2r30x59U5C0/kb2KP03HwsUk=; b=oWvo6AoA8t5hp4pSEoBLhKyc2pfjKvZFvPEDwtog55c5QxcKXt1n2pg7KcA8UR/UfH +vv1C8Br1UxPDcTaWhslbfewKEin+/CzU5uFZeW9c/QtcjoPPWayo/bBxx5dQXlaD7wt 4qj0noZY9JTlKSi9cLyd3aKujMOqhAeClHB/k0hZ/rGlLyDiAlxUQRBxCUcoyENv//Pd y7p/9mxngFsyejnIjX9c7pd8X0YjyaitJ8GwFvh7LsmPtF77nCTO+PCRki3xPk8mC81t GEjC6rU9HF9sLXDYJzLfoKCpTfY0NHMu49uvPJLgTFVSyh3X5Y+jx6qE58KmuGA+pyrw pi8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=yMQFQFIjLE2NVuHFAtE2r30x59U5C0/kb2KP03HwsUk=; b=TclvvNP12n9NywCGhY7joEaqJv7mckaPxULw2iWE6gD1QBWPVNP69M8sRY/o7S6+P7 w1TVEWN0u6Fze4UiN1XmbsQK3berWJW43WtCuPnJRfcqBykPtEBR6NlpZS3b/SNSogAW u7kURWuhii2jiDAvO4Mm7RBbp3tHWOzoHCnwSH0U1DBJS2s8gQ2I8tIauXQgB8DymJ+G f3SMtakIbySh9cfkUJuCAwsTZW3q3kbvZCLIGIAR/Nd4jF7n0C65P/F+cvAB+65wya52 cEN0uRsvQwZ7rYwSpzeCiwIdS/p70F2nh30MlbQ446gCwStGNOaim12Ec+Hgt9IF7mXy IehA== X-Gm-Message-State: APf1xPBbTWdoXjO+yfjOhY1kkc4r+Hd5iJsxUl5Ek4TEa3X1R37Ne/3s 9L2TZuBgMxkwT21z+H9Vx4bJ+3TYRI2LPxEHNNU= X-Google-Smtp-Source: AH8x224RVELQD2bQvPsem2mSivzJgn6oZZ7+qEsaA8P7TN4Le4YMw4McRLFq+5hmxWMsdkV9IcrF9/pk5IN+O8UMZ/Y= X-Received: by 10.36.46.23 with SMTP id i23mr7015973ita.55.1518002818989; Wed, 07 Feb 2018 03:26:58 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 7 Feb 2018 03:26:58 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 7 Feb 2018 03:26:58 -0800 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: Kazuho Oku Cc: "Brian Trammell (IETF)" , QUIC WG Content-Type: multipart/alternative; boundary="001a114a9d82cb450305649d926c" 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, 07 Feb 2018 11:27:02 -0000 --001a114a9d82cb450305649d926c Content-Type: text/plain; charset="UTF-8" comment inline On 7 February 2018 at 12.10.06, Kazuho Oku (kazuhooku@gmail.com) wrote: To summarize, I think that we need a low frequency signal. It could either be a square wave or sin wave. Using a sin wave might be better here, since you the bit pattern (which flips a lot) to observe at a higher precision when the the error rates of loss and reorder are both low. This is a good point. However, you could average the random signal over multiple bits to get a lower frequency signal which will give you signature markers even when some segments are lost. A sine is the ultimate low frequency filter. There might be a middle ground where you overlay a low frequency signal into the random sequence. --001a114a9d82cb450305649d926c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = comment inline=

On 7 February 2018 at 12.= 10.06, Kazuho Oku (kazuhooku@gmail.c= om) wrote:

To summarize, I think that we need a low freque= ncy signal. It could=C2=A0
= either be a square wave or sin wave. Using a sin wave might be better=C2=A0
here, since you the bit pa= ttern (which flips a lot) to observe at a=C2=A0
higher precision when the the error rates of loss and = reorder are both=C2=A0
low.= =C2=A0


=
This is a good point. However, you could average the random signal ov= er multiple bits to get a lower frequency signal which will give you signat= ure markers even when some segments are lost. A sine is the ultimate low fr= equency filter.

There might be a middle ground where you= overlay a low frequency signal into the random sequence.
--001a114a9d82cb450305649d926c-- From nobody Wed Feb 7 03:33:15 2018 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 997DA126C0F for ; Wed, 7 Feb 2018 03:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 AQ5BDdjSkmJ9 for ; Wed, 7 Feb 2018 03:33:12 -0800 (PST) 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 5414E124235 for ; Wed, 7 Feb 2018 03:33:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zbzj26plCz15NbC; Wed, 7 Feb 2018 12:33:10 +0100 (CET) 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 6KHXgzagw8VE; Wed, 7 Feb 2018 12:33:09 +0100 (CET) X-MtScore: NO score=0 Received: from [10.2.115.54] (public-docking-etx-0820.ethz.ch [10.2.115.54]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 7 Feb 2018 12:33:09 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Packet number encryption From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 7 Feb 2018 12:33:22 +0100 Cc: Christian Huitema , Praveen Balasubramanian , "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7549D078-C13B-43E1-A650-AE455680ED43@tik.ee.ethz.ch> References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> To: Marten Seemann X-Mailer: Apple Mail (2.3445.5.20) 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, 07 Feb 2018 11:33:14 -0000 Hi, see below. > Am 07.02.2018 um 09:00 schrieb Marten Seemann = : >=20 >=20 >=20 > On Wed, Feb 7, 2018 at 3:20 PM Christian Huitema = wrote: >=20 >=20 > On 2/6/2018 8:55 PM, Praveen Balasubramanian wrote: >> First, the proposal does not obscure the position of the packet = number field in the header. The field contains a number that increments = with every packet, and is thus easy to identify. This means that = middle-boxes will get accustomed to seeing that field and tracking its = increments. >> Hence, this simple obfuscation provides no protection against = ossification of the packet number field. >>=20 >>=20 >>>>> Well it seems like it is a requirement (see bullet 3 in Jana's = list) to allow middleboxes to see sequencing information. By picking the = initial random value middleboxes cannot assume any particular value. If = packet number location and size is not part of invariants then it cannot = be ossified, middleboxes will need to be resilient.=20 >>>>>=20 >=20 > This is why I would rather see the exposed bits copied at a fixed = location, while the PN itself cannot be located. That way, the exposed = bits can ossify, but the actual PN does not. >=20 > We still need to be very careful here. If we decide to expose bits, we = must make sure that a middlebox can only extract coarse-grained = information, if we want to prevent middleboxes from buffering and = delaying packets in order to fix / reduce reordering. This may be done by the network anyway. We were working on a multipath = bandwidth bonding approach for UDP-based traffic and had to add a slim = tunnel header with a sequence number for reordering. As we didn=E2=80=99t = want look any deeper in the packet and see if we can find any hints if = the traffic is reorder-sensitive or not, we had to work on the = conservative assumption that we should avoid reordering to avoid = unwanted negative impacts as this is the assumption some protocols make = today based on what we typically can obverse today. If we want to say that quic traffic should not be reordered in such = situations, we would need an easy way to distinguish quic from other ups = traffic, or even provide an explicit signal (but that=E2=80=99s a = different topic). > At this point however, I'm not convinced that exposing any reordering = information to the network should be a requirement at all. There's a = real risk of misuse of this information, and of ossification of whatever = bits we expose. From nobody Wed Feb 7 04:21:56 2018 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 EB2E8129C6B for ; Wed, 7 Feb 2018 04:21:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 GkR0td_h2zfS for ; Wed, 7 Feb 2018 04:21:53 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 1B11E124205 for ; Wed, 7 Feb 2018 04:21:53 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id p139so2041651itb.1 for ; Wed, 07 Feb 2018 04:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=A9aPlWIZzoL1UKNMIt5laiAxyEouanUCR2OxtaHv3ac=; b=RQDTIudQkM+COuU87SSXvrMWFhEep37XbayVEzgtgMYAhtKbSHkgEwqeNsZ6iWpjfg o5Lq1kos8M0xVYqkyPLQhQX2zjBuzFoWLeaOqS66MaPLjDXfmFUfrSUUIHTMPn5KeAGc YyKzzOpMd522AfpsC0h43gD4X2en/PVc3sEF+xU6biKYAQMpOzOdvsERMgA7xL5DdX8G zKgRKi6q7lB9KX0j/AW4QIVcVdGzE7vJwcApM/OcOpPz6vXuwugr8uBiwhSdYycn35fd AfuKRdm2ZxzbKmmNjcXTJh15tk7KUpQCYZH0KIGGRIPFVg68sdL8n//zHAB/44VmuxJZ Ro+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=A9aPlWIZzoL1UKNMIt5laiAxyEouanUCR2OxtaHv3ac=; b=e21odUOkjJrz/XG/Hjr0CqoTE02qikzbentmPZ0OJF0ToO/61mWOmU/46WmGFsi6PG JwMjaFQzFH5+pZ0RZbxc5l1vqAaVfI6Uq7+UZkefZFtM/J+GK3kYIolZhNn6DcDElF7e Z3ZXEQIcvejp04M/U0FKUnLfO/tS3ZvI7gyhMlRED8pj1Koyjbh5V2QLaDdrnpAgVyAN XlBs8YtTn4JxBKif5xm5KJ8lQrwCy/9OxqIbTo0/JP162m48IdG6CYI21ctfNVx7zBo9 E9YcN6Xq3PYX8B8+gP4rztGPDm+aa5Wt2OU9QhHiyYh2s/33a5PuxAKQ19jXMC3SFt8s iA2g== X-Gm-Message-State: APf1xPC8d1R0N2+CJwCKL4zeZLKMvPJ2YZ/WInZUOy40oC5+9aglk+RC 7UnwdAo47igbF6zz+5ienM6WNvpP0dpmqrYcrBs= X-Google-Smtp-Source: AH8x226sZ6sHvftCFcWrMw8QM9EP6p9JWWMgZGQc3CU5/En3fnL8xdp//08H1v+UKjADwWf7gkkSdcK4b+JLakP7+Dw= X-Received: by 10.36.73.24 with SMTP id z24mr1281457ita.91.1518006112432; Wed, 07 Feb 2018 04:21:52 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 7 Feb 2018 07:21:51 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 7 Feb 2018 07:21:51 -0500 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: Kazuho Oku Cc: "Brian Trammell (IETF)" , QUIC WG Content-Type: multipart/alternative; boundary="001a113520ee19385d05649e57b6" 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, 07 Feb 2018 12:21:55 -0000 --001a113520ee19385d05649e57b6 Content-Type: text/plain; charset="UTF-8" Hmm a periodic truly white noise random signal ought to have an evenly distributed power spectrum meaning it contains all frequencies up to half its cycle length. At least there is a lot of solid communications theory on random signals that could be applied, e.g. https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-011-introduction-to-communication-control-and-signal-processing-spring-2010/readings/MIT6_011S10_chap09.pdf http://bme.elektro.dtu.dk/31610/notes/chap_8.pdf Thus limiting the signal to a square or a sine is effectively wasting a lot of bandwidth, even if naive hash based signal processing is insufficient to deal with a proper random signal. Of course there is the argument of simplicity, but long term I believe more information in the signal is more valuable. --001a113520ee19385d05649e57b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Hmm a periodic truly= white noise random signal ought to have an evenly distributed power spectr= um meaning it contains all frequencies up to half its cycle length. At leas= t there is a lot of solid communications theory on random signals that coul= d be applied, e.g.=C2=A0


=

Thus limiting the signal to a square or a sine is = effectively wasting a lot of bandwidth, even if naive hash based signal pro= cessing is insufficient to deal with a proper random signal. Of course ther= e is the argument of simplicity, but long term I believe more information i= n the signal is more valuable.

--001a113520ee19385d05649e57b6-- From nobody Wed Feb 7 04:52:18 2018 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 1720B126C83 for ; Wed, 7 Feb 2018 04:52:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 elsgJ30-k1UQ for ; Wed, 7 Feb 2018 04:52:15 -0800 (PST) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::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 678401241FC for ; Wed, 7 Feb 2018 04:52:15 -0800 (PST) Received: by mail-pl0-x235.google.com with SMTP id f8so374786plk.11 for ; Wed, 07 Feb 2018 04:52:15 -0800 (PST) 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=86gUVxKHV/fcwqjnZeuef+SQAHQkQq9d5+Jt+Mv7VEY=; b=pIUBmmPrYjYZG6LlmR3wgCjI8lwHdevaWNuZtQBvYp66scKU+ST0uOsTLIwFZ1xR7Y ElIZ1S7yOwgfNNkTcaZzX81zamaPQH0rR5vbWcJS2Ns3QqUK11889IWdvdUHtuVpxF7M eN5SggGKoL9XKxqaB6fF4ydREhwAdMkXZ9oQFrXlb8ikcoVALUj44TEqNOfeEYNV+bEB lLLq7teyd5PPZrr4ci8JGhRMQGDFHf3DAsqJrLcZy3ixBkQ5ejkLE2JKi5lgq6svxfU1 1QpL9qhmJhdxCtx8d89M60PJSOp3CkixmV6ZkyKG66gD7nqzy84M2VPBeNXuuDSSclCW Nfng== 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=86gUVxKHV/fcwqjnZeuef+SQAHQkQq9d5+Jt+Mv7VEY=; b=oQor4YiJF8Kh7Yj81hZI2bTdcfapw+RAM06cFmbbSa5htWHBRBTvLwQ3PKkOmWa+0S Nq49J7J64fkcfFvH15GVfYMAvA7lrGYzLdSgQCh/uGraBD6icBQBniQ4TJnOge8XC1Qx 9DTGR1vzE38iFAYncEWUA6LCWl+CZaSyXyCdK55ShevXiONfbsFfMOe474K7j5WlE7iR bqEreStZRAj5xHwEeZ98mlB3AGVoZL4YkP8NtzNQ3jB2ivdSYSzQfTq9y/JVZuk3yg9+ 1GznKhSlBBxbvfbCPVpCtbWJCVLG18Kqkqe6g1/6P09GsHeYsUTplRbfSEamloUKvQrZ FI/A== X-Gm-Message-State: APf1xPAtT5VIApX18jT2FTwF3I7+tImxqV38VeTyl5LLgAx6JekyoKjd sFaIO1lArhAL5dcItsbUk3YehnvMoHzL+TagulOYKVFL X-Google-Smtp-Source: AH8x224XuZVdL/e7/F70UECW77/MEiX0xU8mI26RhWNuCDin0iv84GQ3xNkOj2p6E/6k7sPct3VSB30mLYc3Ce8s5z4= X-Received: by 2002:a17:902:579d:: with SMTP id l29-v6mr5817694pli.27.1518007934859; Wed, 07 Feb 2018 04:52:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Wed, 7 Feb 2018 04:52:14 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> From: Kazuho Oku Date: Wed, 7 Feb 2018 21:52:14 +0900 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Martin Thomson , QUIC WG , "Brian Trammell (IETF)" 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, 07 Feb 2018 12:52:17 -0000 2018-02-07 19:23 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen : > > On 7 February 2018 at 11.10.21, Martin Thomson (martin.thomson@gmail.com) > wrote: > > I looked into these when I first considered packet number encryption. > > Hi Martin, I think you might be misreading the intention behind this > sequence. > > The idea is to generate 1 bit for every packet sent on a specific path, i= n > the order the packet was sent, not to encode packet numbers directly. What Mikkel says. Or put it another way, below is a short summary of the approaches being proposed: * encode couple of least significant bits of the per-path sequence number ("a small-modulo sequence number") [1] * encode one bit in the middle of the per-path sequence number [2] When observing that one bit of [2] spanning across multiple packets belonging to a particular path, it looks like a square wave. There came out variations of the approach. * use sin wave instead of square wave [3] * use bitsteram of PI instead of square wave [4][5] * use bitstream of xorshift+ instead of square wave [6] I would argue that the approaches discussed in [2] to [6] are superior to [1] due to the fact that they use less bits, expose less information, while possibly given us reasonable observation of loss and reorder rate. [1] https://www.ietf.org/mail-archive/web/quic/current/msg03030.html [2] https://www.ietf.org/mail-archive/web/quic/current/msg03146.html [3] https://www.ietf.org/mail-archive/web/quic/current/msg03146.html [4] https://www.ietf.org/mail-archive/web/quic/current/msg03156.html [5] https://www.ietf.org/mail-archive/web/quic/current/msg03171.html [6] https://www.ietf.org/mail-archive/web/quic/current/msg03186.html > The > encoding of packet numbers is a separate thing whether encrypted or > otherwise. > > When an observer collects these bits into words from several packets, it = is > possible to compare the gathered string with the expected sequence. > > The random access is only needed for analytical purposes to know about > packet loss in the network, not to operate the QUIC transport as such. If > the sequence is fixed and repeats with reasonable cycle length, it can be > done efficiently in hardware. > > It is true that if you sample, say 32 bits, the mapping is not bijective = so > if you match the sequence, it is ambiguous. But since you already know wh= at > to expect next and you can choose the sample length as long as you want, = say > 128 bits, you do get very good information about where loss and reorderin= g > happened. If the sequence was not random, you would not have this propert= y. > > As to reverse engineering, packets are already sent in order, so learning > what the original order was, is hardly a significant compromise, except i= f > you have multiple connections on the same tuple without transmitting an > observable connection ID. > > --=20 Kazuho Oku From nobody Wed Feb 7 05:13:31 2018 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 572CE127058 for ; Wed, 7 Feb 2018 05:13:29 -0800 (PST) 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 DXTyQyzDEtt2 for ; Wed, 7 Feb 2018 05:13:27 -0800 (PST) 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 5ED3B1205F0 for ; Wed, 7 Feb 2018 05:13:27 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id w83so286565pfi.12 for ; Wed, 07 Feb 2018 05:13:27 -0800 (PST) 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=WCXG6+FTNz9dju2TChyew10lYir3DcQnhCRrvUVquuw=; b=hiAwocXSPUyihU+jAVS/JADGM9BIsLeh/n8aTF3yUf7PLSNy7/i5rwgDx5A5oGWD+O v2E+C3/veyJhei44zdbXakWVcydUzNZDPq7W5KkBmnzTi7U2odm+rlcEHpHi60FKuJn8 Kp3UJhMgbvYtEaYtkIvnN0Ff1TVY1zO6JSvLu59Q+0QxO7UUVOwiKuMydfBV8O2CrfM2 Kf2x7AsHLAIJmzuQaSk84zW/HtGQC1alTvRbALefTa79m6Xsc/M+fQSUOydBzvBU83PB yD6Fe2v+UtQFLV9AYcKWjxvD9bTRDVut9Z2kq+doG0artur0WSJ9pHeQ92ybtV6KcwVd Um5g== 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=WCXG6+FTNz9dju2TChyew10lYir3DcQnhCRrvUVquuw=; b=Fz8Sz0zemf2bMFgKyGhWQ8E6qn9rk01BK/v/TpKxKc869Te/mMBmUSfD6IAMmuzGf5 xyibW4OFtHaZQJ6U9RQEyMV9UzsEjfkB3n6S9ErriCM4yJWqkP5dUlDXwi4VqjIGQrle 21F8urPiHWMuWbejkFOqy8gc8yUqEpCxi6VVkskDt69zhEKpbjrXhcKKtR8Oi8UjdkZm rZzGQsXrea+So0sTtDvUciEIi7VGeo/lHv9nx1zcmHcnBPd3ey5HWZNe5NvKDcEw5Fkz zgNr4SyEz0cdYgIAaSU3w0uTsPSSPNXztYsL1TCT++hq9Fyof37borJfU4mgU53U6TCO B4gQ== X-Gm-Message-State: APf1xPDvcfRFL4cr+oGN07cTCO3kQQYZob4G2HxEwzG7Ud5nvFYWof5X T8I6VgjKjMwMs65Ua/0TyITB72y1cgJLOY/0WaI= X-Google-Smtp-Source: AH8x226izCWj1I3foLx0abdeb1PDI5uO/iBCIoPK2kPuR1biXES62kEyi8nSyxBymz//GB0LjXgDBjOFMxxLstR1quw= X-Received: by 10.98.25.207 with SMTP id 198mr6032068pfz.83.1518009206923; Wed, 07 Feb 2018 05:13:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Wed, 7 Feb 2018 05:13:26 -0800 (PST) In-Reply-To: References: <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <5A7191E0.6010003@erg.abdn.ac.uk> <5214AD93-8376-4B25-922F-AF5551CC2E95@netapp.com> <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> From: Kazuho Oku Date: Wed, 7 Feb 2018 22:13:26 +0900 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: "Brian Trammell (IETF)" , 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, 07 Feb 2018 13:13:29 -0000 2018-02-07 21:21 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen : > Hmm a periodic truly white noise random signal ought to have an evenly > distributed power spectrum meaning it contains all frequencies up to half > its cycle length. At least there is a lot of solid communications theory = on > random signals that could be applied, e.g. > > https://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6= -011-introduction-to-communication-control-and-signal-processing-spring-201= 0/readings/MIT6_011S10_chap09.pdf > > http://bme.elektro.dtu.dk/31610/notes/chap_8.pdf > > Thus limiting the signal to a square or a sine is effectively wasting a l= ot > of bandwidth, even if naive hash based signal processing is insufficient = to > deal with a proper random signal. I mostly disagree. The reason I am suggesting to use square or sin wave is because it has a base frequency (i.e. wavelength) that can be used to calculate the loss rate. White noise does not have a "base frequency." Therefore, it becomes harder to observe the metrics when the loss / reorder rate becomes high. Going back to the discussion of the approaches, I am not against mixing in some random signals so that pattern matching can be applied when the error rate is low. But such "mix" should be mild enough that it would not disturb the observation of the base frequency under high error rate. And in fact, you do not even need to mix randomly flipping bits if you select a sin wave, since a sin wave quantized to 1-bit will contain many flipping bits. You can use those bits for pattern matching. OTOH, if we select square wave, it might make sense to apply some bit flipping so that we can apply pattern matching. There are other possibilities as well. However, with that said, I believe that the design decisions need to depend on the actual use-case. What are the loss rates that we need to work on? What are the reorder patterns that we would observe? IMO this is the tricky part of the 1-bit approach. > Of course there is the argument of > simplicity, but long term I believe more information in the signal is mor= e > valuable. > --=20 Kazuho Oku From nobody Wed Feb 7 05:34:50 2018 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 43CC3129C6C for ; Wed, 7 Feb 2018 05:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 fU5uwNkYO5qB for ; Wed, 7 Feb 2018 05:34:46 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D1612D775 for ; Wed, 7 Feb 2018 05:34:42 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8846B340E50; Wed, 7 Feb 2018 14:34:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.20073); Wed, 7 Feb 2018 14:34:40 +0100 (CET) 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, 7 Feb 2018 14:34:40 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 44640605; Wed, 07 Feb 2018 14:34:40 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C5AAB0A9-7BB8-4722-AE7D-2E11458FB174"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Packet number encryption Date: Wed, 7 Feb 2018 14:34:39 +0100 In-Reply-To: Cc: QUIC WG To: Jana Iyengar References: <2C515BE8694C6F4B9B6A578BCAC32E2F83BA1443@MBX021-W3-CA-2.exch021.domain.local> <6E58094ECC8D8344914996DAD28F1CCD861B7F@DGGEMM506-MBX.china.huawei.com> <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> 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: Wed, 07 Feb 2018 13:34:49 -0000 --Apple-Mail=_C5AAB0A9-7BB8-4722-AE7D-2E11458FB174 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, popping back up from the detailed engineering, thank you for this = reframing. I largely agree that this is the question; a few comments / friendly = amendments on each point. > On 7 Feb 2018, at 00:00, Jana Iyengar wrote: >=20 > I'm going to try a different attempt at moving towards convergence. = Thinking about this some more, and picking up something that Mirja said = way earlier in this thread, I think the following decomposition is = useful. >=20 > 1. In the transport, all packet numbers start at 0, increasing = monotonically. ACK frames carry these packet numbers, and therefore do = not have to span large gaps and do not have to deal with increases in = the size of the largest acked. Basically, no gaps are visible within the = transport processing engine. > 2. Before sending a packet on the wire, and before processing the = packet, QUIC transforms the packet number with some function, replacing = the visible packet number with the transformed value. >=20 > I think we can all agree that (1) is goodness. Yep! (modulo the (completely separate and inconsequential for this = discussion) question of whether packet numbers start at 0 or 1) > A sender is also free to use packet numbers from non-contiguous spaces = here FWIW, but that's entirely independent of what's visible on the = wire. This helps me separate transport processing complexity from the = rest of it, which I think is helpful. +1. > I think we are disagreeing on the precise properties we want from the = transformation in (2). If we can agree on these properties, we can then = figure out whether it's possible and how to construct such a transform. = Here's a union of what folks are concerned about: > 1. Packet number must be unlinkable across connection ID change (for = migration.) s/must/should endeavor to be/ -- true unlinkability is unattainable. The = goal here is to make sure the packet number doesn't make it a lot = easier. > 2. Packet number must start at an arbitrary value, to avoid = ossification of the first packet number. Presuming that the model of ossification you're using here is "a = middlebox vendor grabbing on to any bits it can find to distinguish quic = from not-quic UDP traffic", then yes, this seems reasonable. (There are an entirely different space of designs, which contains TCP, = where the packet number itself is an implicit signal to prove to the = path that a packet belongs to a flow beyond the five-tuple. In that case = the arbitrary start would be necessary to have actual entropy for that = signal. But we've abandoned this as a requirement in QUIC, in part due = to the fundamental tension between avoiding linkability and proving = things to devices on the path about the relationships among packets, = i.e., "linkability" in other words.) > 3. Some sequencing information -- a few bits of the packet number = perhaps -- should be revealed (for monitoring. Number of bits TBD.) This is the crux of the argument. On one side we have the risk of misuse = and ossification (well, not ossification -- these bits are *meant* for = the path -- rather the risk that we'll figure out later that we = specified the wrong thing), on the other side we have the loss of = visibility into how QUIC traffic interacts with the network as compared = to TCP, with a side question of whether or not this visibility is really = the transport layer's problem despite the evolution the practice of = diagnostics and troubleshooting using TCP information. If we can come to agreement on this question, everything else falls into = place. I have my arguments here, but as you said, this subthread is not = the place for them. :) > 4. Any packet number transformation should not be compute intensive. I'd say "should not have an inordinate marginal impact on performance", = because otherwise you go down the rabbithole of relative complexity, but = yeah. Cheers, Brian --Apple-Mail=_C5AAB0A9-7BB8-4722-AE7D-2E11458FB174 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlp7AG8ACgkQihK3vwvq RqMfcA/8ChkzxEPoCjbJcbuP9hs8lJPGEMyNvtb/C0BI5UgoNo1yJQqly+yDPITk HeR8d8mLuNR3o6BgZMsomhm+IyvExDlsNu2wtX/feJ9enied57U1WRhWGSBkRvvQ SWuPaMfy0qUAgnwaniB9RCkh57UGuNfzw5PmLsJOyVFWEL7VUisFFpYRdG7FHq1t 0/Zhhn2tvfMPUgI+RwEsR4s7jr1k6ZUpbsGdUBPUqGjE9Ue084y8D7F/M7ey04L2 Urn2r3BiFj9iK1bBmKdP7nIUBi0wBpRpeU+90LdNuMYESbWb3MsG0ZlFPsWbadvg 4MLH9m2FUnUAC7Dx1syuiS7HNjg3ttzD0UaG/E/PlYZ6HB3WMf50YgPnaBdnkkAa Q0yHZo/3pC+yIq0/0jLwJ5rEUwsxVVjude/rpg57vNKiU4UBWamJOgwtLhjdMTLr IObSqvdOkXZFLjlKcO/iKmN5OLsmLv5TqHIACayHfrmUEIQutrmKqtRWOCQWGlAT iKclpwRpaQ/y70SUolQzQM+TKWv36GNCWPHfbgKF/w+AuiZ9D6hF+Lk5av+onoOG Pt6BvhW8PBthMqfrhmXJ2O/CkYx7a8Zx72ZfBFzNAn9OtxeeGwufcab4HVdIyDPQ 6gZFZpU98xxokoHDiNlVxKQuo5/CZClSlvdl9VEhC+vMgjpEusk= =zpj8 -----END PGP SIGNATURE----- --Apple-Mail=_C5AAB0A9-7BB8-4722-AE7D-2E11458FB174-- From nobody Wed Feb 7 06:05:46 2018 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 936091205F0; Wed, 7 Feb 2018 06:05:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Subject: The QUIC WG has placed draft-thomson-quic-invariants in state "Call For Adoption By WG Issued" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151801234556.4811.8987949553392901833.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 06:05:45 -0800 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: Wed, 07 Feb 2018 14:05:45 -0000 The QUIC WG has placed draft-thomson-quic-invariants in state Call For Adoption By WG Issued (entered by Lars Eggert) The document is available at https://datatracker.ietf.org/doc/draft-thomson-quic-invariants/ From nobody Wed Feb 7 06:06:21 2018 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 5B0511205F0; Wed, 7 Feb 2018 06:06:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , Subject: The QUIC WG has placed draft-krasic-quic-qcram in state "Call For Adoption By WG Issued" X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151801237936.4811.7437284436784703703.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 06:06:19 -0800 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: Wed, 07 Feb 2018 14:06:19 -0000 The QUIC WG has placed draft-krasic-quic-qcram in state Call For Adoption By WG Issued (entered by Lars Eggert) The document is available at https://datatracker.ietf.org/doc/draft-krasic-quic-qcram/ From nobody Wed Feb 7 06:09:17 2018 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 40F78126BF7 for ; Wed, 7 Feb 2018 06:09:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Subject: Milestones changed for quic WG X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151801255626.4845.11435622822871680546.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 06:09:16 -0800 From: IETF Secretariat 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: Wed, 07 Feb 2018 14:09:16 -0000 Changed milestone "Working group adoption of Core Protocol document", resolved as "Done". Changed milestone "Working group adoption of Loss detection and Congestion Control document", resolved as "Done". Changed milestone "Working group adoption of TLS 1.3 mapping document", resolved as "Done". Changed milestone "Working group adoption of HTTP/2 mapping document", resolved as "Done". Changed milestone "Working group adoption of QUIC Applicability and Manageability Statement", resolved as "Done". URL: https://datatracker.ietf.org/wg/quic/about/ From nobody Wed Feb 7 09:44:03 2018 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 319F712D833 for ; Wed, 7 Feb 2018 09:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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 (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 5jerI1nLam23 for ; Wed, 7 Feb 2018 09:43:58 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0122.outbound.protection.outlook.com [104.47.36.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C64D12D7E9 for ; Wed, 7 Feb 2018 09:43:58 -0800 (PST) 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=Yjmlnmt9upmBS4cwOWx/RtA9PtLWLFxwT54G1TR+FLQ=; b=Yk1nzDM6U8bLuXiRseew0kwpzEqenkoZcrmkdUX+/4fe/uJIFBeAGCkJ8U1OIqJxtF3grvdYpkRTY5CZvH6r9TzhibuyuY7/GlPUHY10e9a8nm7sd/yfj8rQy2+dyex2AANG4Tb8BGtWdi/Np5uPYymfMLyQhj3ebw3M8yr2gI4= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0630.namprd21.prod.outlook.com (10.175.115.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Wed, 7 Feb 2018 17:43:56 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) by CY4PR21MB0133.namprd21.prod.outlook.com ([10.173.189.15]) with mapi id 15.20.0485.000; Wed, 7 Feb 2018 17:43:56 +0000 From: Praveen Balasubramanian To: Marten Seemann , huitema CC: "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02A= Date: Wed, 7 Feb 2018 17:43:56 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0630; 7:9XZ23WsIj3D9zuLeHR5nRKIwq0KnmGEr+SQETRD0XhBiheVD1TPcI9jte2beOabbQXRFEQ60Df5MeftXN7lR1/QvzZqZH0xycP0S/bdS8uUB3h8Rw//b80rKzMLtrIg4hvoxDwsOnPVC3Qmuu9BKysG/9ZEd1CMoFJELPlzmLcSRGSaNfP+2j4Zrg03opvbOlaEQLn6hp/xDu6F6kIA5QCb9O09zZdjtDJQFQ6fHjcHi3GLxqbkGx/XsZlpgeZXd x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f23f79e6-1006-4c91-56c2-08d56e525cdd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0630; x-ms-traffictypediagnostic: CY4PR21MB0630: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(3002001)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0630; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0630; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39380400002)(366004)(39860400002)(396003)(189003)(199004)(77096007)(6246003)(53936002)(99286004)(186003)(6346003)(790700001)(6116002)(39060400002)(7116003)(76176011)(59450400001)(229853002)(7696005)(10290500003)(5660300001)(8676002)(236005)(86362001)(8936002)(81156014)(81166006)(9686003)(3480700004)(86612001)(74316002)(8990500004)(316002)(110136005)(106356001)(10090500001)(478600001)(4326008)(2906002)(6436002)(7736002)(54896002)(6306002)(3660700001)(25786009)(3280700002)(55016002)(97736004)(68736007)(561944003)(53546011)(6506007)(22452003)(102836004)(33656002)(105586002)(93886005)(2900100001)(2950100002)(14454004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0630; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: /8Aj629W9eqLsZFcdz0mUgz/gzBq8358LB8quEzM5MuTCvvVYY1DNTLipb+K+zo3zr4ysrw9En20SaF8WRz8zQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133A1117B2733BBCF049C5FB6FC0CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f23f79e6-1006-4c91-56c2-08d56e525cdd X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 17:43:56.6075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0630 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, 07 Feb 2018 17:44:01 -0000 --_000_CY4PR21MB0133A1117B2733BBCF049C5FB6FC0CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q291cGxlIG9mIHRoaW5ncyB0byBhZGQ6DQoNCjEuIENvbm5lY3Rpb24gbWlncmF0aW9uIGlzIGFu IG9wdGlvbmFsIHBvcnRpb24gb2YgdGhlIHRyYW5zcG9ydCBhbmQgbm90IG1hbmRhdG9yeS4gSXQg ZG9lcyBub3Qgc2VlbSB0byBiZSBpbmNyZW1lbnRhbGx5IGRlcGxveWFibGUgd2l0aCB0b2RheSdz IHVubW9kaWZpZWQgbG9hZCBiYWxhbmNlcnMuIE1hbnkgZGV2aWNlcyBtYXkgYWxzbyBiZSBzaW5n bGUgaG9tZWQgYW5kIG5vdCBoYXZlIG11bHRpcGxlIGFjdGl2ZSBuZXR3b3JrIGludGVyZmFjZXMu IEkgYWxzbyB0aGluayB0aGUgYXBwIGFuZCBzeXN0ZW0gc2V0dGluZ3Mgd2lsbCBoYXZlIHRvIG9w dC1pbiB0byBpdCAodG8gcHJldmVudCBhZ2dyZXNzaXZlIHVzYWdlIG9mIG1ldGVyZWQgY2VsbHVs YXIgZGF0YSkuIElmIHRoaXMgaXMgdGhlIGNhc2UsIGNyb3NzLXBhdGggbGlua2FiaWxpdHkgd2ls bCBiZSBvZiBsaW1pdGVkIGNvbmNlcm4gZm9yIG1hbnkgUVVJQyBjb25uZWN0aW9ucy4gVGhlcmUg aXMgYWxzbyB0aGUgZmFjdCB0aGF0IHBlcmZlY3QgdW5saW5rYWJpbGl0eSBzZWVtcyB0byBiZSBo YXJkIGFnYWluc3QgYSBtb3RpdmF0ZWQgYWR2ZXJzYXJ5Lg0KDQoyLiBJZiBtaWRkbGVib3ggb3Nz aWZpY2F0aW9uIGlzIGEgYmlnIGNvbmNlcm4sIHdlIG1haW5seSBuZWVkIG9iZnVzY2F0aW9uIGFu ZCBub3QgZW5jcnlwdGlvbi4gQW5vdGhlciBvcHRpb24gZm9yIGV4YW1wbGUgd291bGQgYmUgYW4g WE9SIHRyYW5zZm9ybSB3aXRoIHNvbWUgdmFyaWFibGUgZmllbGQgaW4gdGhlIGVuY3J5cHRlZCBw b3J0aW9uIG9mIHRoZSBwYWNrZXQgKGFzIGFuIGV4YW1wbGUgc2VxdWVuY2UgbnVtYmVyIG9mIHRo ZSBmaXJzdCBzdHJlYW0gZnJhbWUgaWYgaXQgaXMgcHJlc2VudCBvciBzb21lIHJhbmRvbSBwYWQg Ynl0ZXMgd2hlbiBpdHMgbm90IHByZXNlbnQpLiBJIGhvcGUgd2UgY2FuIGJlIGNyZWF0aXZlIGhl cmUgdG8gcmVkdWNlIGNvbXB1dGF0aW9uIGNvc3QuDQoNCg0KRnJvbTogTWFydGVuIFNlZW1hbm4g W21haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgNywgMjAxOCAxMjowMSBBTQ0KVG86IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+DQpD YzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBxdWljQGll dGYub3JnDQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCg0KT24gV2Vk LCBGZWIgNywgMjAxOCBhdCAzOjIwIFBNIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRl bWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj4gd3JvdGU6DQoNCg0KDQpPbiAyLzYv MjAxOCA4OjU1IFBNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiB3cm90ZToNCg0KRmlyc3QsIHRo ZSBwcm9wb3NhbCBkb2VzIG5vdCBvYnNjdXJlIHRoZSBwb3NpdGlvbiBvZiB0aGUgcGFja2V0IG51 bWJlciBmaWVsZCBpbiB0aGUgaGVhZGVyLiBUaGUgZmllbGQgY29udGFpbnMgYSBudW1iZXIgdGhh dCBpbmNyZW1lbnRzIHdpdGggZXZlcnkgcGFja2V0LCBhbmQgaXMgdGh1cyBlYXN5IHRvIGlkZW50 aWZ5LiBUaGlzIG1lYW5zIHRoYXQgbWlkZGxlLWJveGVzIHdpbGwgZ2V0IGFjY3VzdG9tZWQgdG8g c2VlaW5nIHRoYXQgZmllbGQgYW5kIHRyYWNraW5nIGl0cyBpbmNyZW1lbnRzLg0KDQpIZW5jZSwg dGhpcyBzaW1wbGUgb2JmdXNjYXRpb24gcHJvdmlkZXMgbm8gcHJvdGVjdGlvbiBhZ2FpbnN0IG9z c2lmaWNhdGlvbiBvZiB0aGUgcGFja2V0IG51bWJlciBmaWVsZC4NCg0KDQoNCldlbGwgaXQgc2Vl bXMgbGlrZSBpdCBpcyBhIHJlcXVpcmVtZW50IChzZWUgYnVsbGV0IDMgaW4gSmFuYSdzIGxpc3Qp IHRvIGFsbG93IG1pZGRsZWJveGVzIHRvIHNlZSBzZXF1ZW5jaW5nIGluZm9ybWF0aW9uLiBCeSBw aWNraW5nIHRoZSBpbml0aWFsIHJhbmRvbSB2YWx1ZSBtaWRkbGVib3hlcyBjYW5ub3QgYXNzdW1l IGFueSBwYXJ0aWN1bGFyIHZhbHVlLiBJZiBwYWNrZXQgbnVtYmVyIGxvY2F0aW9uIGFuZCBzaXpl IGlzIG5vdCBwYXJ0IG9mIGludmFyaWFudHMgdGhlbiBpdCBjYW5ub3QgYmUgb3NzaWZpZWQsIG1p ZGRsZWJveGVzIHdpbGwgbmVlZCB0byBiZSByZXNpbGllbnQuDQoNClRoaXMgaXMgd2h5IEkgd291 bGQgcmF0aGVyIHNlZSB0aGUgZXhwb3NlZCBiaXRzIGNvcGllZCBhdCBhIGZpeGVkIGxvY2F0aW9u LCB3aGlsZSB0aGUgUE4gaXRzZWxmIGNhbm5vdCBiZSBsb2NhdGVkLiBUaGF0IHdheSwgdGhlIGV4 cG9zZWQgYml0cyBjYW4gb3NzaWZ5LCBidXQgdGhlIGFjdHVhbCBQTiBkb2VzIG5vdC4NCg0KV2Ug c3RpbGwgbmVlZCB0byBiZSB2ZXJ5IGNhcmVmdWwgaGVyZS4gSWYgd2UgZGVjaWRlIHRvIGV4cG9z ZSBiaXRzLCB3ZSBtdXN0IG1ha2Ugc3VyZSB0aGF0IGEgbWlkZGxlYm94IGNhbiBvbmx5IGV4dHJh Y3QgY29hcnNlLWdyYWluZWQgaW5mb3JtYXRpb24sIGlmIHdlIHdhbnQgdG8gcHJldmVudCBtaWRk bGVib3hlcyBmcm9tIGJ1ZmZlcmluZyBhbmQgZGVsYXlpbmcgcGFja2V0cyBpbiBvcmRlciB0byBm aXggLyByZWR1Y2UgcmVvcmRlcmluZy4NCkF0IHRoaXMgcG9pbnQgaG93ZXZlciwgSSdtIG5vdCBj b252aW5jZWQgdGhhdCBleHBvc2luZyBhbnkgcmVvcmRlcmluZyBpbmZvcm1hdGlvbiB0byB0aGUg bmV0d29yayBzaG91bGQgYmUgYSByZXF1aXJlbWVudCBhdCBhbGwuIFRoZXJlJ3MgYSByZWFsIHJp c2sgb2YgbWlzdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24sIGFuZCBvZiBvc3NpZmljYXRpb24gb2Yg d2hhdGV2ZXIgYml0cyB3ZSBleHBvc2UuDQo= --_000_CY4PR21MB0133A1117B2733BBCF049C5FB6FC0CY4PR21MB0133namp_ 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 aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1z b25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5 bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29u c29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0 IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPkNvdXBsZSBvZiB0aGluZ3MgdG8gYWRkOjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+MS4gQ29ubmVjdGlvbiBtaWdyYXRpb24gaXMgYW4gb3B0aW9u YWwgcG9ydGlvbiBvZiB0aGUgdHJhbnNwb3J0IGFuZCBub3QgbWFuZGF0b3J5LiBJdCBkb2VzIG5v dCBzZWVtIHRvIGJlIGluY3JlbWVudGFsbHkgZGVwbG95YWJsZSB3aXRoIHRvZGF5J3MgdW5tb2Rp ZmllZCBsb2FkIGJhbGFuY2Vycy4gTWFueSBkZXZpY2VzIG1heSBhbHNvIGJlIHNpbmdsZSBob21l ZCBhbmQgbm90IGhhdmUgbXVsdGlwbGUgYWN0aXZlDQogbmV0d29yayBpbnRlcmZhY2VzLiBJIGFs c28gdGhpbmsgdGhlIGFwcCBhbmQgc3lzdGVtIHNldHRpbmdzIHdpbGwgaGF2ZSB0byBvcHQtaW4g dG8gaXQgKHRvIHByZXZlbnQgYWdncmVzc2l2ZSB1c2FnZSBvZiBtZXRlcmVkIGNlbGx1bGFyIGRh dGEpLiBJZiB0aGlzIGlzIHRoZSBjYXNlLCBjcm9zcy1wYXRoIGxpbmthYmlsaXR5IHdpbGwgYmUg b2YgbGltaXRlZCBjb25jZXJuIGZvciBtYW55IFFVSUMgY29ubmVjdGlvbnMuIFRoZXJlIGlzIGFs c28gdGhlDQogZmFjdCB0aGF0IHBlcmZlY3QgdW5saW5rYWJpbGl0eSBzZWVtcyB0byBiZSBoYXJk IGFnYWluc3QgYSBtb3RpdmF0ZWQgYWR2ZXJzYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Mi4gSWYgbWlkZGxlYm94IG9zc2lmaWNhdGlvbiBpcyBhIGJpZyBjb25j ZXJuLCB3ZSBtYWlubHkgbmVlZCBvYmZ1c2NhdGlvbiBhbmQgbm90IGVuY3J5cHRpb24uIEFub3Ro ZXIgb3B0aW9uIGZvciBleGFtcGxlIHdvdWxkIGJlIGFuIFhPUiB0cmFuc2Zvcm0gd2l0aCBzb21l IHZhcmlhYmxlIGZpZWxkIGluIHRoZSBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0aGUgcGFja2V0IChh cyBhbiBleGFtcGxlIHNlcXVlbmNlDQogbnVtYmVyIG9mIHRoZSBmaXJzdCBzdHJlYW0gZnJhbWUg aWYgaXQgaXMgcHJlc2VudCBvciBzb21lIHJhbmRvbSBwYWQgYnl0ZXMgd2hlbiBpdHMgbm90IHBy ZXNlbnQpLiBJIGhvcGUgd2UgY2FuIGJlIGNyZWF0aXZlIGhlcmUgdG8gcmVkdWNlIGNvbXB1dGF0 aW9uIGNvc3QuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWFydGVuIFNlZW1hbm4gW21haWx0 bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDcsIDIwMTggMTI6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IGh1aXRlbWEgJmx0O2h1 aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1h bmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIg NywgMjAxOCBhdCAzOjIwIFBNIENocmlzdGlhbiBIdWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86 aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMi82LzIwMTggODo1NSBQTSwgUHJhdmVlbiBC YWxhc3VicmFtYW5pYW4gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT5GaXJz dCwgdGhlIHByb3Bvc2FsIGRvZXMgbm90IG9ic2N1cmUgdGhlIHBvc2l0aW9uIG9mIHRoZSBwYWNr ZXQgbnVtYmVyIGZpZWxkIGluIHRoZSBoZWFkZXIuIFRoZSBmaWVsZCBjb250YWlucyBhIG51bWJl ciB0aGF0IGluY3JlbWVudHMgd2l0aCBldmVyeSBwYWNrZXQsIGFuZCBpcyB0aHVzIGVhc3kgdG8g aWRlbnRpZnkuIFRoaXMgbWVhbnMgdGhhdCBtaWRkbGUtYm94ZXMgd2lsbCBnZXQgYWNjdXN0b21l ZCB0byBzZWVpbmcgdGhhdCBmaWVsZCBhbmQgdHJhY2tpbmcgaXRzIGluY3JlbWVudHMuPG86cD48 L286cD48L3ByZT4NCjxwcmU+SGVuY2UsIHRoaXMgc2ltcGxlIG9iZnVzY2F0aW9uIHByb3ZpZGVz IG5vIHByb3RlY3Rpb24gYWdhaW5zdCBvc3NpZmljYXRpb24gb2YgdGhlIHBhY2tldCBudW1iZXIg ZmllbGQuPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5XZWxsIGl0IHNlZW1zIGxpa2UgaXQg aXMgYSByZXF1aXJlbWVudCAoc2VlIGJ1bGxldCAzIGluIEphbmEncyBsaXN0KSB0byBhbGxvdyBt aWRkbGVib3hlcyB0byBzZWUgc2VxdWVuY2luZyBpbmZvcm1hdGlvbi4gQnkgcGlja2luZyB0aGUg aW5pdGlhbCByYW5kb20gdmFsdWUgbWlkZGxlYm94ZXMgY2Fubm90IGFzc3VtZSBhbnkgcGFydGlj dWxhciB2YWx1ZS4gSWYgcGFja2V0IG51bWJlciBsb2NhdGlvbiBhbmQgc2l6ZSBpcyBub3QgcGFy dCBvZiBpbnZhcmlhbnRzIHRoZW4gaXQgY2Fubm90IGJlIG9zc2lmaWVkLCBtaWRkbGVib3hlcyB3 aWxsIG5lZWQgdG8gYmUgcmVzaWxpZW50LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyB3aHkgSSB3b3VsZCByYXRoZXIgc2VlIHRoZSBl eHBvc2VkIGJpdHMgY29waWVkIGF0IGEgZml4ZWQgbG9jYXRpb24sIHdoaWxlIHRoZSBQTiBpdHNl bGYgY2Fubm90IGJlIGxvY2F0ZWQuIFRoYXQgd2F5LCB0aGUgZXhwb3NlZCBiaXRzIGNhbiBvc3Np ZnksIGJ1dCB0aGUgYWN0dWFsIFBOIGRvZXMgbm90LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBzdGlsbCBuZWVk IHRvIGJlIHZlcnkgY2FyZWZ1bCBoZXJlLiBJZiB3ZSBkZWNpZGUgdG8gZXhwb3NlIGJpdHMsIHdl IG11c3QgbWFrZSBzdXJlIHRoYXQgYSBtaWRkbGVib3ggY2FuIG9ubHkgZXh0cmFjdCBjb2Fyc2Ut Z3JhaW5lZCBpbmZvcm1hdGlvbiwgaWYgd2Ugd2FudCB0byBwcmV2ZW50IG1pZGRsZWJveGVzIGZy b20gYnVmZmVyaW5nIGFuZCBkZWxheWluZyBwYWNrZXRzIGluIG9yZGVyIHRvIGZpeCAvDQogcmVk dWNlIHJlb3JkZXJpbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BdCB0aGlzIHBvaW50IGhvd2V2ZXIsIEknbSBub3QgY29udmluY2VkIHRoYXQg ZXhwb3NpbmcgYW55IHJlb3JkZXJpbmcgaW5mb3JtYXRpb24gdG8gdGhlIG5ldHdvcmsgc2hvdWxk IGJlIGEgcmVxdWlyZW1lbnQgYXQgYWxsLiBUaGVyZSdzIGEgcmVhbCByaXNrIG9mIG1pc3VzZSBv ZiB0aGlzIGluZm9ybWF0aW9uLCBhbmQgb2Ygb3NzaWZpY2F0aW9uIG9mIHdoYXRldmVyIGJpdHMg d2UgZXhwb3NlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0133A1117B2733BBCF049C5FB6FC0CY4PR21MB0133namp_-- From nobody Wed Feb 7 16:37:41 2018 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 A4B25126DED for ; Wed, 7 Feb 2018 16:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkyHbcTt7yYw for ; Wed, 7 Feb 2018 16:37:33 -0800 (PST) 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 E7BED120721 for ; Wed, 7 Feb 2018 16:37:32 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ejaDN-0003lU-Le for quic@ietf.org; Thu, 08 Feb 2018 01:37:26 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ejaDG-0005Bf-Q6 for quic@ietf.org; Wed, 07 Feb 2018 19:37:19 -0500 Received: (qmail 1205 invoked from network); 8 Feb 2018 00:37:18 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Feb 2018 00:37:18 -0000 To: quic@ietf.org References: <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> From: Christian Huitema Message-ID: <0828f8d4-e8cc-c4be-6062-6e9fe843f849@huitema.net> Date: Wed, 7 Feb 2018 14:37:17 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.37) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rtF0XixPV2jHdgxufwKyZ4Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fvgZfXHVShMJl4RfsV9JAzrB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31WoCGUWNgo50bBZN3FfqI2VItAPyqRyV95ZNrHd7vkN RnCZrsXthqMpjY8hecAMutnh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3Goyp65o39wd3xyIqswrw4YJnHEeB4hpRrmo/duzUUp/L9 UD9MCYFan2eRHD4U+beDmq4NFZuQJnJJRLxixstHPXLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+0EF5F4XJDGest21JnLKg8Ij2lB9TLiDMfXuvSrucRXpoVg5fOhUS7LnGpWowDQkTpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g 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: Thu, 08 Feb 2018 00:37:40 -0000 On 2/7/2018 1:10 AM, Kazuho Oku wrote: > The pros of using a sequence that randomly distributes 0 and ones > (i.e. PI or xorshift+) is that you can extract good loss / reordering > information if the error rate is low. > > OTOH, it is fragile to high error rate or certain patterns of error. > Let me explain two examples. > > Consider the case where the packet loss rate is 50%. I doubt if you > could use pattern matching against those sequences to figure out the > loss rate. This is because the power among the sequence is mostly high > frequencies. If you use a sequence that distributes power among lower > frequencies (like square wave or sin wave that I discussed), you can > calculate the loss rate in such cases as well. Actually, it should be possible to build a maximum likelihood decoder for an xorshift sending pattern. You are mostly concerned with erasure and permutations, and you roughly know the range of probability, so you can see likelihood of 1, 2, 3, etc. erasures, or permutations in some range. Obviously, the range that you can manage depends on the length of the code. If you can keep the decoder synchronized, you will be able to measure the erasure rate. If it looses synchronization, you know that the error rate is truly horrendous, and that's information too. And xorshift codes are self synchronizing, so you will regain synchronization quickly. -- Christian Huitema From nobody Wed Feb 7 16:55:51 2018 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 3E0C7127077 for ; Wed, 7 Feb 2018 16:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3GDCWvqfPw4 for ; Wed, 7 Feb 2018 16:55:48 -0800 (PST) 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 509FC124207 for ; Wed, 7 Feb 2018 16:55:48 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx15.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ejaV5-0004Bf-El for quic@ietf.org; Thu, 08 Feb 2018 01:55:45 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ejaUz-0008Fh-H9 for quic@ietf.org; Wed, 07 Feb 2018 19:55:42 -0500 Received: (qmail 19968 invoked from network); 8 Feb 2018 00:55:36 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Feb 2018 00:55:36 -0000 To: quic@ietf.org References: <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> <0828f8d4-e8cc-c4be-6062-6e9fe843f849@huitema.net> From: Christian Huitema Message-ID: <9551271c-2f20-6a47-80ff-536f5ed5c464@huitema.net> Date: Wed, 7 Feb 2018 14:55:36 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <0828f8d4-e8cc-c4be-6062-6e9fe843f849@huitema.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.26) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5gsKNlQNJGgiS7SG2Z3aQpoXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftoshTnTJv8VyhQ30Oc3GxuB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYdTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XIx4AXarfh1O38bAuuIRigptEjxjSIdK/OrMoYfnrE KDBVNFelyoO7Z8swOZlu4HjGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kAN1Mi/5oPXF0IaYXV2I96ukONoJfh+XjGSeeT90H/uIEx rSInjWgdx6zVi70JAQthUn8GbQ0sEFshouqwCA5d92bjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW87eqULwgkV+w1Dqc0gmbgvfFcHV2tQAVqGdj/zM7G/FqHXIoSsvffuCdDqwWbJR15ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w 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: Thu, 08 Feb 2018 00:55:50 -0000 On 2/7/2018 2:37 PM, Christian Huitema wrote: > Actually, it should be possible to build a maximum likelihood decoder > for an xorshift sending pattern. You are mostly concerned with erasure > and permutations, and you roughly know the range of probability, so you= > can see likelihood of 1, 2, 3, etc. erasures, or permutations in some > range. Obviously, the range that you can manage depends on the length o= f > the code. If you can keep the decoder synchronized, you will be able to= > measure the erasure rate. If it looses synchronization, you know that > the error rate is truly horrendous, and that's information too. And > xorshift codes are self synchronizing, so you will regain > synchronization quickly. What I had in mind was a polynomial code, such as crc32 or crc64. The generation operation is: =C2=A0=C2=A0=C2=A0 unsigned int:1 next_bit_in_pattern() =C2=A0=C2=A0=C2=A0 { =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 static uint32_t seed =3D 0xc00= lcode; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 const uint32_t reminder =3D 0x= 1edc6f41; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 overflow =3D seed>>31; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 seed <<=3D 1; =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 seed^=3D (overflow*reminder); =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 return (seed&1); =C2=A0=C2=A0=C2=A0 } Writing the trellis decoder is left as an exercise for the reader... -- Christian Huitema From nobody Wed Feb 7 18:08:30 2018 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 B528D126C26 for ; Wed, 7 Feb 2018 18:08:28 -0800 (PST) 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, 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 iVdaICzNnoGQ for ; Wed, 7 Feb 2018 18:08:27 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::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 EC159124B18 for ; Wed, 7 Feb 2018 18:08:26 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id 17so1171924pfw.11 for ; Wed, 07 Feb 2018 18:08:26 -0800 (PST) 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=CHsjmnVNSkOpKmst6fGXcYR0OZa3QL5zk/extZ3bIMg=; b=SZRUs+PQK47ZOr9X2LrElSHrCFi8FrJk4Cnx1kdAo1SQkrhA/PlN2u8JjeArL/0bv9 I/2YkY+vjKuSamT97GRtOlYtsf+YktNTE/5EVyqa9W3j4Nws77h2WpeupjaGZlDEm7rb Y7n8uL46LD5R4CSwnSL+tbL3z5N50Nxcvkn9Q9bbgs8H6/CO1kXllGdEAsuZL/52Zs6h ajTIhNdFzvEZUBCvIuhmh70079ZUeX+9l+XUV1c5peUBSl8u8cIVD3AfjGgFJslyKWr6 FqVvCJ0kqwVcYKRtPxFY3tzLKM0dtxARNuDh6LzS5F6QEywsdAUoydfjvK+SPF0S7lEs N+0A== 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=CHsjmnVNSkOpKmst6fGXcYR0OZa3QL5zk/extZ3bIMg=; b=oiVmRHTmbwIRz8XPKK32I0XkxxdWcLcSY5PuqoF2SIC5eaEYVUzANijIvkNl2bnu9g 6VGvWKTay5cfQPsSpvF5zuBYEtkVFsRf3Jt/oOr6RuBjkYr7qCo3l5g7lgtnMPZHkwxA 67Zf94GvW+WtIPxWAJUT5gGKvZSkzG0ajvvHA7FF+l7R24WzVG4R6Fhaa068TorJmdQU YviwR9aknHR3Tc04gcet82I3lVUc//Gh7jKvIrH/IZNXKCuNh7xIx38NYWVpEpTPAhJt Tn/xMvXwjIu6dyDJGdSey3lLLmgMQ16vtUQEDQHSapsrRYeBp4WEE7AUkcf1HWfE+8eD 5tlQ== X-Gm-Message-State: APf1xPC3VjxwLnDEgaN0hK6OvCsjDWqSkbfumRb+geRw5cnVfmHgqRGu 0GzyzClQYN0k9fxnyLbnifY5ELkh4lm7gns1kv0+Eg== X-Google-Smtp-Source: AH8x226VNUUy4LQ+ad3KmliOGm4tleRnNwtd49vTYylZfwItUnXZgNDz6tIXfoUkjEltWvxAe06z5r5EdTD9Ors29KE= X-Received: by 10.98.7.214 with SMTP id 83mr7768791pfh.130.1518055706346; Wed, 07 Feb 2018 18:08:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Wed, 7 Feb 2018 18:08:25 -0800 (PST) In-Reply-To: <0828f8d4-e8cc-c4be-6062-6e9fe843f849@huitema.net> References: <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> <0828f8d4-e8cc-c4be-6062-6e9fe843f849@huitema.net> From: Kazuho Oku Date: Thu, 8 Feb 2018 11:08:25 +0900 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: Christian Huitema 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: Thu, 08 Feb 2018 02:08:29 -0000 2018-02-08 9:37 GMT+09:00 Christian Huitema : > > > On 2/7/2018 1:10 AM, Kazuho Oku wrote: >> The pros of using a sequence that randomly distributes 0 and ones >> (i.e. PI or xorshift+) is that you can extract good loss / reordering >> information if the error rate is low. >> >> OTOH, it is fragile to high error rate or certain patterns of error. >> Let me explain two examples. >> >> Consider the case where the packet loss rate is 50%. I doubt if you >> could use pattern matching against those sequences to figure out the >> loss rate. This is because the power among the sequence is mostly high >> frequencies. If you use a sequence that distributes power among lower >> frequencies (like square wave or sin wave that I discussed), you can >> calculate the loss rate in such cases as well. > > Actually, it should be possible to build a maximum likelihood decoder > for an xorshift sending pattern. You are mostly concerned with erasure > and permutations, and you roughly know the range of probability, so you > can see likelihood of 1, 2, 3, etc. erasures, or permutations in some > range. Obviously, the range that you can manage depends on the length of > the code. If you can keep the decoder synchronized, you will be able to > measure the erasure rate. I agree with you that it is possible to detect loss / reorder if the decoder can be kept synchronized. What I am questioning is the possibility of keeping the decoder synchronized under heavy loss / reorder. > If it looses synchronization, you know that > the error rate is truly horrendous, and that's information too. I disagree. It might be true that loosing synchronization due to heavy loss can be a signal. OTOH, loosing synchronization due to massive reorder is not an issue if the reorder resolves in a certain timeframe (IIRC 1/8 RTT). My understanding is that the middleboxes' reliance to the sequence number has led to the ossification of TCP. The ossification has prevented us from doing some nifty things, such as sending some TCP packets through a different node while answering others directly. In QUIC, I am interested in doing such things, and I would expect that others will be. Considering that, I would prefer not to exposing a signal that could give false information to observers when there is a "good" reorder. > And > xorshift codes are self synchronizing, so you will regain > synchronization quickly. > > -- Christian Huitema > -- Kazuho Oku From nobody Wed Feb 7 19:54:51 2018 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 82B7212D84E for ; Wed, 7 Feb 2018 19:54:49 -0800 (PST) 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, 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 ix9-k0b5cRoa for ; Wed, 7 Feb 2018 19:54:47 -0800 (PST) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::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 30F4512D849 for ; Wed, 7 Feb 2018 19:54:47 -0800 (PST) Received: by mail-pl0-x232.google.com with SMTP id v3-v6so1438564plg.3 for ; Wed, 07 Feb 2018 19:54:47 -0800 (PST) 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=KZlODMP9fiU9L34DKEC7ijPAWBDiJygc8OnlnmfsjTw=; b=u7dKTbNUw/GWEfYBefr7R8r66mfITSjg5k6TX7PqXWQoeqehIf/NzFxQfCjK50128/ rzGUSoTKL+sdGlVK9nTp81z/PQwjYpoAma4/LjOyhFBWHLa6zVBuHPcikYcnUy24yPCc lbGS3dspZkL1fAbpn8rGCpd4aISloumQ2CC7LvN+C6JbMeQQRVB1eac0nnesjGk8oc+D hwftGZfczgiCO9xUVFd1aTy0hFDfnsnuev9hp1Hi3PByaeupLC2fBhsHPRghUe3cuj1k Ze/D5HEQwpUKhf8VRhw/hiZTXeNLjDQbxMLbPw19L5XlsRvycpYo/5ZNrBN0quvtwFGX mIeQ== 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=KZlODMP9fiU9L34DKEC7ijPAWBDiJygc8OnlnmfsjTw=; b=ZeET5G5Ic58TABB0LIv7jjMpH+hVnDjlyAVOpUOkCROqHfhPN6eTXnl2hpSF2aEddq MP39CLzdc3xO1XWLPOt0QOUoRMR8IzCp59yX31NZZ5jEgMPWKbT+pmilJ/4hvfQdUSxv 04mX/T/ZDbbZocUCcDruU/nqYgk39xndErLV32RklTmq+mIycEPrSBiBVedMhFN0tBq2 s3wLwoUNGdNp7p/Re7zhjn1NwLVbg0ewYE+fdWk3q6SvmzvL5jrqHtgZbL9k2Ph8xwaW K1HL5uMn3ZOyLO1iS32lF0j7jiRkmO90xOO8Nw9GTwLj3JTDKi+w+i8BSUVnKE71thyk 41Jw== X-Gm-Message-State: APf1xPCs9stgRFlxNgMzLEmlOilYT8PgYlHedQxq4yPdukAG01p199ID U4zXW3DT7bxKwC5Gq0V986s/uxU3RWHkgQYSMDw= X-Google-Smtp-Source: AH8x226Noh4l6A90T5IelaGS+7ubkyQl0DlvFcNmcIBex1z38FIQkEN7iUfpLSPkRKITwZOr65aaxiHNHjyfbkZK+wU= X-Received: by 2002:a17:902:624:: with SMTP id 33-v6mr8100695plg.327.1518062086542; Wed, 07 Feb 2018 19:54:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Wed, 7 Feb 2018 19:54:45 -0800 (PST) In-Reply-To: References: <2CD9DC43-D69B-43F0-8474-DFE798850A52@akamai.com> <5233815B-00F3-4961-ABB8-505906258B89@trammell.ch> <0828f8d4-e8cc-c4be-6062-6e9fe843f849@huitema.net> From: Kazuho Oku Date: Thu, 8 Feb 2018 12:54:45 +0900 Message-ID: Subject: Re: Explicit measurability in the QUIC wire image (was Re: Packet number encryption) To: Christian Huitema 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: Thu, 08 Feb 2018 03:54:49 -0000 2018-02-08 11:08 GMT+09:00 Kazuho Oku : > 2018-02-08 9:37 GMT+09:00 Christian Huitema : >> >> >> On 2/7/2018 1:10 AM, Kazuho Oku wrote: >>> The pros of using a sequence that randomly distributes 0 and ones >>> (i.e. PI or xorshift+) is that you can extract good loss / reordering >>> information if the error rate is low. >>> >>> OTOH, it is fragile to high error rate or certain patterns of error. >>> Let me explain two examples. >>> >>> Consider the case where the packet loss rate is 50%. I doubt if you >>> could use pattern matching against those sequences to figure out the >>> loss rate. This is because the power among the sequence is mostly high >>> frequencies. If you use a sequence that distributes power among lower >>> frequencies (like square wave or sin wave that I discussed), you can >>> calculate the loss rate in such cases as well. >> >> Actually, it should be possible to build a maximum likelihood decoder >> for an xorshift sending pattern. You are mostly concerned with erasure >> and permutations, and you roughly know the range of probability, so you >> can see likelihood of 1, 2, 3, etc. erasures, or permutations in some >> range. Obviously, the range that you can manage depends on the length of >> the code. If you can keep the decoder synchronized, you will be able to >> measure the erasure rate. > > I agree with you that it is possible to detect loss / reorder if the > decoder can be kept synchronized. > > What I am questioning is the possibility of keeping the decoder > synchronized under heavy loss / reorder. > >> If it looses synchronization, you know that >> the error rate is truly horrendous, and that's information too. > > I disagree. > > It might be true that loosing synchronization due to heavy loss can be > a signal. OTOH, loosing synchronization due to massive reorder is not > an issue if the reorder resolves in a certain timeframe (IIRC 1/8 > RTT). > > My understanding is that the middleboxes' reliance to the sequence > number has led to the ossification of TCP. The ossification has > prevented us from doing some nifty things, such as sending some TCP > packets through a different node while answering others directly. In > QUIC, I am interested in doing such things, and I would expect that > others will be. > > Considering that, I would prefer not to exposing a signal that could > give false information to observers when there is a "good" reorder. Please let me paraphrase the last sentence to the following: I would prefer using a signal that is tolerant to "good" reorder (i.e. happening frequently but resolving in a fraction of RTT so that they don't trigger a retransmit). Anyways, I think that we are making progress in sense that we are discussing what is the "best" way to achieve loss / reorder observability using 1 bit, rather than using multiple bits. Use of less bits lead to less chance of leaking information as well as finding space to store the information. > >> And >> xorshift codes are self synchronizing, so you will regain >> synchronization quickly. >> >> -- Christian Huitema >> > > > > -- > Kazuho Oku -- Kazuho Oku From nobody Thu Feb 8 03:10:52 2018 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 6296B126D74 for ; Thu, 8 Feb 2018 03:10:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.291 X-Spam-Level: X-Spam-Status: No, score=0.291 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 GE4bhLpV6hSF for ; Thu, 8 Feb 2018 03:10:48 -0800 (PST) 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 1D655120727 for ; Thu, 8 Feb 2018 03:10:48 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id t129so2304055ywc.3 for ; Thu, 08 Feb 2018 03:10:48 -0800 (PST) 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=nHUBMdlO+U/xgsioPbwYuYsMT71XfgQYXgu1styfw7s=; b=fQi9GFq1Jnz84S9rAFirA2Q7N6169dBvq5hPb/srhtyt8NDtxJp1HJFts7m47B7m+X r5JC+fhvBIzsLnwFv8sRsuOl59o5erDHTDS5tZ4FQFSuyqsVrNVGKJLDOGDVfQA26PuO kNMaJgYQ0lcpsQIPYguuvVIeJCnJuGiueYALxfSBKSi4VIauFiDVGrhdIrCACZbB+NC4 wYFWmnITDGsikVeHBf8StqBdcMzCvTzgrG/57RWLPOABtFeOVwKbE2BxC7gmKTc6xOKl 1r9aU/emO0fwlyE6v18JXY70ME1qjHmjkIfSy1CBMdspCfniBr4gkWoVkZLrF0CetYXT 6Y6Q== 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=nHUBMdlO+U/xgsioPbwYuYsMT71XfgQYXgu1styfw7s=; b=pJDbIyMMbvymEv2pEi7ptbEPCBkPTDSX0aqWwz2+amFv/o8gMrRKNXyaVV4XElPEoF Ar5ehis1FuDcwyMQ+QziTfg39q1okCp3uTkgDkDnPUDIDrvloW+BeUwXhRVyMcX6fouR KGFiXPPwVXH2raz69gLqxrMZ1nlYoo/4Btx0EE6z0u0dLwIChJhyiXMiH5XsrcJVTDfb 3XadStCVGNEj7HOoFMajYPYvvPcaOudd5e2lorhCz2Te+NvQ0EPPOc6LR4luUFah46bD r3J2Q1yRnwYbSb56zdGTjdYP2lGLFzPFLguYNP1H58rOIT2gwf+9k4OmqIFhdRjynJ01 uR6Q== X-Gm-Message-State: APf1xPDbruN67MH+9pIiTKzvGr34ByKloDawt0kMUTXCIapfNXEe196R tlvNMn2fb5ZycXtgVqqMlU39xiteCN9hmAJAzJs= X-Google-Smtp-Source: AH8x225Mx16gB2QjvbkuyWTqPfj59fNCXiqoPXOQ6k0nUpUbgLdcAzyDsCgT+e1cPql9LicCm8pspq2uxaPIJ9FcDbY= X-Received: by 10.129.78.14 with SMTP id c14mr161018ywb.109.1518088246945; Thu, 08 Feb 2018 03:10:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.21.201 with HTTP; Thu, 8 Feb 2018 03:10:46 -0800 (PST) Received: by 10.37.21.201 with HTTP; Thu, 8 Feb 2018 03:10:46 -0800 (PST) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Thu, 8 Feb 2018 05:10:46 -0600 Message-ID: Subject: RE: Call for Adoption: Invariants To: Praveen Balasubramanian Cc: Jana Iyengar , Mike Bishop , Ted Hardie , Mark Nottingham , Lars Eggert , "Brian Trammell (IETF)" , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , QUIC WG Content-Type: multipart/alternative; boundary="001a114d7d3eb26ed90564b17665" 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, 08 Feb 2018 11:10:50 -0000 --001a114d7d3eb26ed90564b17665 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Still with no hat ... On Feb 6, 2018 14:48, "Praveen Balasubramanian" wrote= : +1 on =E2=80=9CThe QUIC transport draft specifically does not say anything = about which UDP ports are to be used -- QUIC is a transport after all, and there is no reason to tie the entire transport to a port.=E2=80=9D Thanks to multiple people who have replied. I understand that QUIC isn't tied to a single UDP port number. I was thinking about the deployability story for a non-backward-compatible QUIC version that can't be demuxed from previous versions - what I think I'm hearing is that such a new QUIC version would require thought about getting a new UDP port opened the way 443 seems to be today. I'll shut up and let you guys do QUIC now :-) Spencer *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar *Sent:* Tuesday, February 6, 2018 11:26 AM *To:* Mike Bishop *Cc:* Ted Hardie ; Mark Nottingham ; Spencer Dawkins at IETF ; Lars Eggert < lars@eggert.org>; Brian Trammell (IETF) ; Mikkel Fahn=C3= =B8e J=C3=B8rgensen ; QUIC WG *Subject:* Re: Call for Adoption: Invariants What Mike said -- UDP/443 was allocated for HTTP over UDP, but is not required for HTTP/QUIC. The HTTP mapping document currently says (in Sectio= n 2.1 ) "Servers MAY serve HTTP/QUIC on any UDP port." We can discuss this, but let's move that discussion to where it belongs, on #495 . The QUIC transport draft specifically does not say anything about which UDP ports are to be used -- QUIC is a transport after all, and there is no reason to tie the entire transport to a port. On Tue, Feb 6, 2018 at 11:09 AM, Mike Bishop wrote: Two notes, one against interest: That PR is old and currently parked, because we don=E2=80=99t have consensus and it=E2=80=99s less urgent. And = secondly, UDP/443 is already allocated by IANA for HTTP over UDP. *From:* Ted Hardie [mailto:ted.ietf@gmail.com] *Sent:* Tuesday, February 6, 2018 10:57 AM *To:* Spencer Dawkins at IETF *Cc:* Mike Bishop ; Brian Trammell (IETF) < ietf@trammell.ch>; Mikkel Fahn=C3=B8e J=C3=B8rgensen ; = QUIC WG < quic@ietf.org>; Mark Nottingham ; Lars Eggert < lars@eggert.org> *Subject:* Re: Call for Adoption: Invariants On Tue, Feb 6, 2018 at 6:54 AM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: Asking with no hat, but ... On Mon, Feb 5, 2018 at 1:00 PM, Mike Bishop wrote: I support adoption. The way to change the invariants will be to mint a new protocol, and not claim that your new protocol is a version of QUIC. If it happens to be startlingly similar, all well and good. If you roll a new protocol, that's not a version of QUIC, is it obvious to everyone but me whether you can run both protocols on UDP/443? Mike Bishop's PR defining httpq as a scheme (https://github.com/quicwg/ base-drafts/pull/348 ) defines UDP 443 as the default for httpq. I think that pretty much asserts that UDP/443 is QUIC, not a forked variant. I thought I remembered that UDP/443 was chosen because firewalls often pass port 443, so that aids deployment. Hence, my question. Yes. That may cause us to consider carefully whether UDP/443 ought to be defined for QUIC more rather than HTTP over QUIC, or even more generally. Ted Thanks, Spencer --001a114d7d3eb26ed90564b17665 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Still with no hat ...
=
On Feb 6, 2018 14:48, "Praveen Balasubr= amanian" <pravb@microsoft.co= m> wrote:

+1 on =E2=80=9CThe QUIC transport draft specifically= does not say anything about which UDP ports are to be used -- QUIC is a tr= ansport after all, and there is no reason to tie the entire transport to a = port.=E2=80=9D

Thanks to multiple people who have replied.

=
I understand that QUIC isn't tied to a single U= DP port number. I was thinking about the deployability story for a non-back= ward-compatible QUIC version that can't be demuxed from previous versio= ns - what I think I'm hearing is that such a new QUIC version would req= uire thought about getting a new UDP port opened the way 443 seems to be to= day.

I'll shut up an= d let you guys do QUIC now :-)

Spencer

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Tuesday, February 6, 2018 11:26 AM
To: Mike Bishop <mbishop@evequefou.be>
Cc: Ted Hardie <ted.ietf@gmail.com>; Mark Nottingham <mnot@mnot.net>; Spencer Dawkins at IE= TF <s= pencerdawkins.ietf@gmail.com>; Lars Eggert <lars@eggert.org>; Brian Trammel= l (IETF) <ietf@tra= mmell.ch>; Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; QUIC WG <quic@ietf.org>


Subject: Re: Call for Adoption: Invariants

=C2=A0

What Mike said -- UDP/443 was allocated for HTTP ove= r UDP, but is not required for HTTP/QUIC.=C2=A0Section 2.1) "Servers MAY serve HTTP= /QUIC on any UDP port." We can discuss this, but let's move that d= iscussion to where it belongs, on=C2=A0#495.

=C2=A0

The QUIC transport dr= aft specifically does not say anything about which UDP ports are to be used= -- QUIC is a transport after all, and there is no reason to tie the entire= transport to a port.

=C2=A0

On Tue, Feb 6, 2018 at 11:09 AM, Mike Bishop <mbishop@evequefou.be= > wrote:

Two notes, one against interest:=C2=A0 That PR is ol= d and currently parked, because we don=E2=80=99t have consensus and it=E2= =80=99s less urgent.=C2=A0 And secondly, UDP/443 is already allocated by IA= NA for HTTP over UDP.

=C2=A0

From: Ted Hardie [mailto:ted.ietf@gmail.com]
Sent: Tuesday, February 6, 2018 10:57 AM
To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Cc: Mike Bishop <mbishop@evequefou.be>; Brian Trammell (IETF) <ietf@trammell.ch>; Mi= kkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>; QUIC WG <quic@ietf.o= rg>; Mark Nottingham <mnot@mnot.net>; Lars Eggert <lars@eggert.org>
Subject: Re: Call for Adoption: Invariants

=C2=A0

On Tue, Feb 6, 2018 at 6:54 AM, Spencer Dawkins at I= ETF <= spencerdawkins.ietf@gmail.com> wrote:

=C2=A0

I thought I remembered that UDP/443 was chosen becau= se firewalls often pass port 443, so that aids deployment. Hence, my questi= on.

=C2=A0

=C2=A0

Yes.=C2=A0 That may c= ause us to consider carefully whether UDP/443 ought to be defined for QUIC = more rather than HTTP over QUIC, or even more generally.

Ted


=C2=A0

Thanks,

=C2=A0

Spencer

=C2=A0

=C2=A0


--001a114d7d3eb26ed90564b17665-- From nobody Thu Feb 8 05:04:29 2018 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 3DDC21241FC; Thu, 8 Feb 2018 05:04:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: quic@ietf.org Subject: QUIC (quic) WG Interim Meeting: 2018-06-06 X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151809506296.17228.17281018611304930059@ietfa.amsl.com> Date: Thu, 08 Feb 2018 05:04:23 -0800 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: Thu, 08 Feb 2018 13:04:23 -0000 The QUIC (quic) Working Group will hold a multi-day interim meeting. Session 1: 2018-06-06 09:00 to 17:00 Europe/Berlin Session 2: 2018-06-07 09:00 to 17:00 Europe/Berlin Meeting Location: Kista, SE Agenda: https://github.com/quicwg/wg-materials/blob/master/interim-18-06/agenda.md Information about remote participation: https://github.com/quicwg/wg-materials/blob/master/interim-18-06/arrangements.md Preceded by non-IETF QUIC interop event on June 4-5, same location From nobody Thu Feb 8 11:49:54 2018 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 19D0F127444 for ; Thu, 8 Feb 2018 11:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 PUIo1ZBdqs4P for ; Thu, 8 Feb 2018 11:49:50 -0800 (PST) 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 34931126CF6 for ; Thu, 8 Feb 2018 11:49:50 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id d129so3866782qke.10 for ; Thu, 08 Feb 2018 11:49:50 -0800 (PST) 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=3vmEFm+jZfTeSrF91qPcOaxNQ92/gV2kKFnXMaoKeVQ=; b=tDM8tgr1ka1MTfgN+vTdQDwChpG02XGyhraccjJxBTgWK7j/iZg/+ra27MwxGkx7xm 9crHUSm+LzYhROf8ixL3k/KXYyGOACfxRZ9EIkG1BZEXvlwVltghqJX42LMWS606Ynu/ pJffoJrEpdJ8cGd7vL2QoJlnRBERf8+0iShPcLcabrSjXQ+j8DhU+tecIdjBcQsxkdbd SndBTtGMUBibPeeC1tW64dlF8wKE34i/oHvtp+mGgoPfe6QgAkGlc1K3AUMOCnQ+isnp w35ohGm6MxoT1mZk9sNLnQ+94Hkd2sAKjCLnjLoncdArpOE+MzF7gBhqTi/WTBxjfb40 uGYQ== 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=3vmEFm+jZfTeSrF91qPcOaxNQ92/gV2kKFnXMaoKeVQ=; b=HJy5gAhO2e44B7cewCSejPe1r7pfO56jnk/084xpeHh7R0t8SO/Xp5RQ18aYzhFIFv KlboSCa2HtnVQYkL8KndbVjGV65CeEvhS6DQl957pyNB+AR9ASm6e0LBCPrM71V2yF3m QiZjSRCt0t9wp87QtC+TIM9ATvOAtQkU1FAEzVZ84X3FzvhvQQaaWs9mdERBYLtH9yVa YWfmvaH0KyC7u1dGjoTOBJXZ1KcRcUTLc3mwwCWzQOj8+2qslcKBDq6IqkRxsYj4k1Y5 RvlPIlUMGsfOYKXLnG2y+IZdnHEqn2UwIlmYhuVM3+lqQ2hnCzDoPu2PnF6Vo8Clv8VW /hhQ== X-Gm-Message-State: APf1xPB3TAXxRf+cYl4ZA+OkuvsZjJhv0+vMabIdcct/Zd/xuzu4hnZN lPflUb6qAzkoh5Y5iI22zX1yRv9Jjy7k4m0eYKCrSQ== X-Google-Smtp-Source: AH8x2278mCckB849BAoaqlBVbeEOLqgmgX7e06ldj0yxyzId7tdYgoqcSBRqmcGJuk19O6ZFhAadHB78s4wyIEblICY= X-Received: by 10.55.24.160 with SMTP id 32mr260056qky.214.1518119389006; Thu, 08 Feb 2018 11:49:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.34.132 with HTTP; Thu, 8 Feb 2018 11:49:48 -0800 (PST) In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> From: Victor Vasiliev Date: Thu, 8 Feb 2018 14:49:48 -0500 Message-ID: Subject: Re: Packet number encryption To: Praveen Balasubramanian Cc: Marten Seemann , huitema , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a11441462e996a70564b8b65c" 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, 08 Feb 2018 19:49:52 -0000 --001a11441462e996a70564b8b65c Content-Type: text/plain; charset="UTF-8" On Wed, Feb 7, 2018 at 12:43 PM, Praveen Balasubramanian < pravb@microsoft.com> wrote: > > 2. If middlebox ossification is a big concern, we mainly need obfuscation > and not encryption. Another option for example would be an XOR transform > with some variable field in the encrypted portion of the packet (as an > example sequence number of the first stream frame if it is present or some > random pad bytes when its not present). I hope we can be creative here to > reduce computation cost. > Obfuscation is just encryption done poorly. I am concerned that in 2018, we still are talking about encryption being expensive -- symmetric block encryption, of all things. --001a11441462e996a70564b8b65c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 7, 2018 at 12:43 PM, Praveen Balasubramanian <= pravb@microsoft.co= m> wrote:

2. If middlebox ossification= is a big concern, we mainly need obfuscation and not encryption. Another o= ption for example would be an XOR transform with some variable field in the= encrypted portion of the packet (as an example sequence number of the first stream frame if it is present or some random pad bytes= when its not present). I hope we can be creative here to reduce computatio= n cost.

Obfuscation is just encryption don= e poorly.

I am concerned that in 2018, we still ar= e talking about encryption being expensive -- symmetric block encryption, o= f all things.
--001a11441462e996a70564b8b65c-- From nobody Thu Feb 8 12:00:06 2018 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 7F0F512D838 for ; Thu, 8 Feb 2018 12:00:04 -0800 (PST) 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, 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 6oK4rR6eDmz4 for ; Thu, 8 Feb 2018 12:00:03 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 02C461267BB for ; Thu, 8 Feb 2018 12:00:02 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w18JvIaU029530; Thu, 8 Feb 2018 19:59:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=aVQb4awZOqN5pT40OoAQb7nIgzgaOjLL+nhsI567v+0=; b=Fjf1sAeUR6aZz0Y9tz0jE+EWrQlujTkE1jwEjOHDqlFgUQ6oUDdaOGQCvmRSIk0YybCw GbUzK9V9E9+supmL8R7gBfdjG30vwMmklDzpB5YlsUyvoVFJVtkHCTxXEhFD2XJceFOe +K1C+FXfrBVff0oua2911u/I7uSKNHH0WYJQmBrFp5/4hWucvnFGhNzk/XwNkHuEm98f urdWmO8BCUWWCqSvuLSv4TPaeKMLyGFU5Mae/HGBvMS8gH6N0zgsT1z8cXYA/k68rWc/ Ou0DiNGLc16p55ZgmDIZ2tUtxxffWZY/Tdn4+YeX598IXjek3asQmsU7FMS6WIidc0pP 5w== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2g05aecds5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 08 Feb 2018 19:59:54 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w18JtuWW009938; Thu, 8 Feb 2018 14:59:53 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fyq7ay5mr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Feb 2018 14:59:53 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 8 Feb 2018 14:59:52 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Thu, 8 Feb 2018 14:59:52 -0500 From: "Salz, Rich" To: Victor Vasiliev , Praveen Balasubramanian CC: Marten Seemann , "quic@ietf.org" , huitema Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31Be9MxlVQxEqrVhXIOG6b4KOM1RYAgABeoICAAAgVAIAAd3KAgAA8YgCAACPDAIAAAicAgAOBloCAALfcgIAACBoAgAEGFwCAANx+AIAAn5GAgAB7xICAADUigIAADBaAgADXOgCAAGaugIAAEEkAgACizACAADhiAIAAHkiAgAADUYCAACdEAIAAVRYAgAAUZgCAAA5oAIAAEIEAgABFkgCAAAUSgIAABUkAgAABmYCAAAaRgIAAC4qAgACi8ACAAbWAAIAAAs+A Date: Thu, 8 Feb 2018 19:59:51 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.210] Content-Type: multipart/alternative; boundary="_000_D7DEE1A564C24465805FABAF31EBD1FFakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-08_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=938 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802080230 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-08_10:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=890 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802080230 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, 08 Feb 2018 20:00:04 -0000 --_000_D7DEE1A564C24465805FABAF31EBD1FFakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIEkgYW0gY29uY2VybmVkIHRoYXQgaW4gMjAxOCwgd2Ugc3RpbGwgYXJlIHRhbGtp bmcgYWJvdXQgZW5jcnlwdGlvbiBiZWluZyBleHBlbnNpdmUgLS0gc3ltbWV0cmljIGJsb2NrIGVu Y3J5cHRpb24sIG9mIGFsbCB0aGluZ3MuDQoNCisxICENCg== --_000_D7DEE1A564C24465805FABAF31EBD1FFakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLm00MTMwMzk0MzQ1ODEzNDk2MjExbXNvcGxhaW50ZXh0LCBsaS5tNDEzMDM5NDM0NTgxMzQ5 NjIxMW1zb3BsYWludGV4dCwgZGl2Lm00MTMwMzk0MzQ1ODEzNDk2MjExbXNvcGxhaW50ZXh0DQoJ e21zby1zdHlsZS1uYW1lOm1fNDEzMDM5NDM0NTgxMzQ5NjIxMW1zb3BsYWludGV4dDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0NzQzNzAxOTU7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMzg3MzMxNjI0IDY3Njk4Njk5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJp Zjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0IGwwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N Cm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjx1bCBzdHls ZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5JIGFt IGNvbmNlcm5lZCB0aGF0IGluIDIwMTgsIHdlIHN0aWxsIGFyZSB0YWxraW5nIGFib3V0IGVuY3J5 cHRpb24gYmVpbmcgZXhwZW5zaXZlIC0tIHN5bW1ldHJpYyBibG9jayBlbmNyeXB0aW9uLCBvZiBh bGwgdGhpbmdzLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzEgITxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D7DEE1A564C24465805FABAF31EBD1FFakamaicom_-- From nobody Thu Feb 8 14:32:52 2018 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 B0F61127876 for ; Thu, 8 Feb 2018 14:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 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_H5=-1, 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=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 8nhQnvKr4wRC for ; Thu, 8 Feb 2018 14:32:47 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0107.outbound.protection.outlook.com [104.47.40.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9FD012711D for ; Thu, 8 Feb 2018 14:32:47 -0800 (PST) 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=kOApcxfWoH442KRuGXBn8M73H5m3syGcBZF3Q/49OTE=; b=jgJK5/VF7cBt3fTQwIq0vtA/taLNE80JP6wxPthGBR53UAyusVsH4TNenKGN/cfuypWLamWHgTNHZ7vODGiD3ahGXbDtW7FaV00HK31661QTgJCbQmJGvrPT7hXTAM/ja28feltCcKT+0XD2C9OB/eGx+L/uRWm/NoMXwmc0Bfo= Received: from MWHPR21MB0144.namprd21.prod.outlook.com (10.173.52.14) by MWHPR21MB0800.namprd21.prod.outlook.com (10.175.142.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.1; Thu, 8 Feb 2018 22:32:45 +0000 Received: from MWHPR21MB0144.namprd21.prod.outlook.com ([10.173.52.14]) by MWHPR21MB0144.namprd21.prod.outlook.com ([10.173.52.14]) with mapi id 15.20.0485.000; Thu, 8 Feb 2018 22:32:45 +0000 From: Praveen Balasubramanian To: Victor Vasiliev CC: Marten Seemann , "quic@ietf.org" , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAbWdAIAAKHbg Date: Thu, 8 Feb 2018 22:32:45 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0800; 7:WZUiSKwDe+BxJ3kAHmGVSnPVA/Wch/MFH3F99apjIM/1Mv9lzmmVml+iwSb7yY0G6PSMaqtiaFFY2zekzthN77TuD8i00UAk7g5zd5lj3qPanMut8FnHIXyXBcDjYdswVA+su8fae4HwgbA5eUggCVlq7rLQeM7xi526aSICM36dIcoE0cxjytR2yA8OAz7ZVesFOX8CTVksJp/UrMjqQeSEjs1BYbGlq+agaf8CzcphHuDNGFkC80OX9aF64E7x x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a6df2e0d-f756-44e3-4027-08d56f43e035 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:MWHPR21MB0800; x-ms-traffictypediagnostic: MWHPR21MB0800: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231101)(2400082)(944501161)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:MWHPR21MB0800; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0800; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(39380400002)(346002)(366004)(199004)(189003)(33656002)(2900100001)(6506007)(6436002)(105586002)(25786009)(8936002)(81166006)(81156014)(93886005)(4326008)(39060400002)(229853002)(76176011)(55016002)(54906003)(6346003)(99286004)(106356001)(186003)(77096007)(102836004)(53546011)(59450400001)(236005)(22452003)(7696005)(10090500001)(6306002)(54896002)(316002)(9686003)(2906002)(14454004)(10290500003)(68736007)(790700001)(6116002)(5660300001)(3660700001)(19609705001)(86612001)(7116003)(478600001)(97736004)(53936002)(7736002)(6246003)(8990500004)(74316002)(2950100002)(6916009)(8676002)(3480700004)(3280700002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0800; H:MWHPR21MB0144.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: 1vvgKYhtE81/lnuKjPukEbDa+GAIj9uLx5aisG1Smsr409gvI9ZhOMP2ODafyJQ6Ch38GP2pnKIAN2i6mzxc9w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0144A36781B9AB9BEC7B99A8B6F30MWHPR21MB0144namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a6df2e0d-f756-44e3-4027-08d56f43e035 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 22:32:45.7461 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0800 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, 08 Feb 2018 22:32:51 -0000 --_000_MWHPR21MB0144A36781B9AB9BEC7B99A8B6F30MWHPR21MB0144namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QUZBSUNUIHRoZSBnb2FsIGlzIHRvIHBlcmZvcm0gc29tZSB0cmFuc2Zvcm0gZm9yIHByZXZlbnRp bmcgbWlkZGxlYm94IG9zc2lmaWNhdGlvbi4gRW5jcnlwdGlvbiBpcyBvbmUgcG9zc2libGUgdHJh bnNmb3JtIGJ1dCBpcyBpdCB0aGUgb25seSBwb3NzaWJsZSBvbmU/IFRoZSBudW1iZXJzIEkgcXVv dGVkIHdlcmUgZnJvbSBhIHF1aWNrIHRlc3QgYnkgbW9kaWZ5aW5nIHRoZSB3aW5xdWljIGltcGxl bWVudGF0aW9uIHRvIGFkZCBhbiBhZGRpdGlvbmFsIGVuY3J5cHQgLyBkZWNyeXB0IHN0ZXAgb24g cGFja2V0IG51bWJlciBzaXplIHdvcnRoIG9mIGRhdGEuIElmIGFueW9uZSBlbHNlIGhhcyBhbnkg ZGF0YSBwbGVhc2Ugc2hhcmUuIFRoZSBkZXNpZ24gY2hvaWNlIGhlcmUgaW1wYWN0cyBwZXIgcGFj a2V0IHByb2Nlc3NpbmcgY29zdHMgZm9yIHRoZSBzZXJ2ZXIgc2lkZSBoZW5jZSB0aGUgcmVxdWVz dCB0byBmaW5kIGlmIHdlIGNhbiBkbyBzb21ldGhpbmcgc2ltcGxlci4NCg0KRnJvbTogUVVJQyBb bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFZpY3RvciBWYXNpbGll dg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggMTE6NTAgQU0NClRvOiBQcmF2ZWVu IEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbT4NCkNjOiBNYXJ0ZW4gU2VlbWFu biA8bWFydGVuc2VlbWFubkBnbWFpbC5jb20+OyBxdWljQGlldGYub3JnOyBodWl0ZW1hIDxodWl0 ZW1hQGh1aXRlbWEubmV0Pg0KU3ViamVjdDogUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0K DQpPbiBXZWQsIEZlYiA3LCAyMDE4IGF0IDEyOjQzIFBNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh biA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbT4+IHdyb3Rl Og0KDQoyLiBJZiBtaWRkbGVib3ggb3NzaWZpY2F0aW9uIGlzIGEgYmlnIGNvbmNlcm4sIHdlIG1h aW5seSBuZWVkIG9iZnVzY2F0aW9uIGFuZCBub3QgZW5jcnlwdGlvbi4gQW5vdGhlciBvcHRpb24g Zm9yIGV4YW1wbGUgd291bGQgYmUgYW4gWE9SIHRyYW5zZm9ybSB3aXRoIHNvbWUgdmFyaWFibGUg ZmllbGQgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBwYWNrZXQgKGFzIGFuIGV4YW1w bGUgc2VxdWVuY2UgbnVtYmVyIG9mIHRoZSBmaXJzdCBzdHJlYW0gZnJhbWUgaWYgaXQgaXMgcHJl c2VudCBvciBzb21lIHJhbmRvbSBwYWQgYnl0ZXMgd2hlbiBpdHMgbm90IHByZXNlbnQpLiBJIGhv cGUgd2UgY2FuIGJlIGNyZWF0aXZlIGhlcmUgdG8gcmVkdWNlIGNvbXB1dGF0aW9uIGNvc3QuDQpP YmZ1c2NhdGlvbiBpcyBqdXN0IGVuY3J5cHRpb24gZG9uZSBwb29ybHkuDQoNCkkgYW0gY29uY2Vy bmVkIHRoYXQgaW4gMjAxOCwgd2Ugc3RpbGwgYXJlIHRhbGtpbmcgYWJvdXQgZW5jcnlwdGlvbiBi ZWluZyBleHBlbnNpdmUgLS0gc3ltbWV0cmljIGJsb2NrIGVuY3J5cHRpb24sIG9mIGFsbCB0aGlu Z3MuDQo= --_000_MWHPR21MB0144A36781B9AB9BEC7B99A8B6F30MWHPR21MB0144namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubTQxMzAzOTQzNDU4MTM0OTYyMTFt c29wbGFpbnRleHQsIGxpLm00MTMwMzk0MzQ1ODEzNDk2MjExbXNvcGxhaW50ZXh0LCBkaXYubTQx MzAzOTQzNDU4MTM0OTYyMTFtc29wbGFpbnRleHQNCgl7bXNvLXN0eWxlLW5hbWU6bV80MTMwMzk0 MzQ1ODEzNDk2MjExbXNvcGxhaW50ZXh0Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFGQUlDVCB0aGUgZ29hbCBpcyB0byBwZXJm b3JtIHNvbWUgdHJhbnNmb3JtIGZvciBwcmV2ZW50aW5nIG1pZGRsZWJveCBvc3NpZmljYXRpb24u IEVuY3J5cHRpb24gaXMgb25lIHBvc3NpYmxlIHRyYW5zZm9ybSBidXQgaXMgaXQgdGhlIG9ubHkg cG9zc2libGUgb25lPyBUaGUgbnVtYmVycyBJIHF1b3RlZCB3ZXJlIGZyb20gYSBxdWljayB0ZXN0 IGJ5IG1vZGlmeWluZyB0aGUgd2lucXVpYyBpbXBsZW1lbnRhdGlvbg0KIHRvIGFkZCBhbiBhZGRp dGlvbmFsIGVuY3J5cHQgLyBkZWNyeXB0IHN0ZXAgb24gcGFja2V0IG51bWJlciBzaXplIHdvcnRo IG9mIGRhdGEuIElmIGFueW9uZSBlbHNlIGhhcyBhbnkgZGF0YSBwbGVhc2Ugc2hhcmUuIFRoZSBk ZXNpZ24gY2hvaWNlIGhlcmUgaW1wYWN0cw0KPGk+cGVyIHBhY2tldDwvaT4gcHJvY2Vzc2luZyBj b3N0cyBmb3IgdGhlIHNlcnZlciBzaWRlIGhlbmNlIHRoZSByZXF1ZXN0IHRvIGZpbmQgaWYgd2Ug Y2FuIGRvIHNvbWV0aGluZyBzaW1wbGVyLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYg T2YNCjwvYj5WaWN0b3IgVmFzaWxpZXY8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1 YXJ5IDgsIDIwMTggMTE6NTAgQU08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFu aWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gTWFydGVuIFNl ZW1hbm4gJmx0O21hcnRlbnNlZW1hbm5AZ21haWwuY29tJmd0OzsgcXVpY0BpZXRmLm9yZzsgaHVp dGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiA3LCAyMDE4IGF0IDEyOjQzIFBNLCBQcmF2ZWVuIEJh bGFzdWJyYW1hbmlhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iIHRh cmdldD0iX2JsYW5rIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0ibTQxMzAzOTQzNDU4 MTM0OTYyMTFtc29wbGFpbnRleHQiPjIuIElmIG1pZGRsZWJveCBvc3NpZmljYXRpb24gaXMgYSBi aWcgY29uY2Vybiwgd2UgbWFpbmx5IG5lZWQgb2JmdXNjYXRpb24gYW5kIG5vdCBlbmNyeXB0aW9u LiBBbm90aGVyIG9wdGlvbiBmb3IgZXhhbXBsZSB3b3VsZCBiZSBhbiBYT1IgdHJhbnNmb3JtIHdp dGggc29tZSB2YXJpYWJsZSBmaWVsZCBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIHBh Y2tldCAoYXMNCiBhbiBleGFtcGxlIHNlcXVlbmNlIG51bWJlciBvZiB0aGUgZmlyc3Qgc3RyZWFt IGZyYW1lIGlmIGl0IGlzIHByZXNlbnQgb3Igc29tZSByYW5kb20gcGFkIGJ5dGVzIHdoZW4gaXRz IG5vdCBwcmVzZW50KS4gSSBob3BlIHdlIGNhbiBiZSBjcmVhdGl2ZSBoZXJlIHRvIHJlZHVjZSBj b21wdXRhdGlvbiBjb3N0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx dW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PYmZ1c2NhdGlvbiBpcyBqdXN0IGVu Y3J5cHRpb24gZG9uZSBwb29ybHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gY29uY2VybmVkIHRoYXQgaW4gMjAxOCwgd2Ugc3RpbGwg YXJlIHRhbGtpbmcgYWJvdXQgZW5jcnlwdGlvbiBiZWluZyBleHBlbnNpdmUgLS0gc3ltbWV0cmlj IGJsb2NrIGVuY3J5cHRpb24sIG9mIGFsbCB0aGluZ3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR21MB0144A36781B9AB9BEC7B99A8B6F30MWHPR21MB0144namp_-- From nobody Thu Feb 8 15:03:09 2018 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 BB8D4126CC7 for ; Thu, 8 Feb 2018 15:03:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (2048-bit key) header.d=mnot.net header.b=JfB7451C; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rlIXY5Js 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 fdDkpF7bqkIY for ; Thu, 8 Feb 2018 15:03:05 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C275126C89 for ; Thu, 8 Feb 2018 15:03:05 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id B29DD20FDA; Thu, 8 Feb 2018 18:03:04 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 08 Feb 2018 18:03:04 -0500 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; s=fm1; bh=AGYsjVQcthrL7wTQsq4iAwXyIYcz/ 6BebbtLXC/4JXc=; b=JfB7451CjUyXsNxCB21fhaUocxXbv57uR4QrGZjo2WdYI jlAIxyFbuKBsxpQYFh70FcAWuGLCHj0zt2nFHoJPvxcVLCExjjBuXC3zBz4l6tJg 2Wl/blq+3SG1MwygVJ/C0HBKvaifnh1vNf7sC1XbAbMWfoRV4m16e4rce4e7+vgo 8BKKmWcFrqM+HCvT5LD5pj7vfwuLKCMmVibgFRP+u7c++jP7Cw2x/yj0nSrqzCpq bPB3+QXkN77m8jv38sQSsZ9SCOfxZ3LOR8JKpX0am5gbkNYW6+trPux0FD0Rxoaq /cgsQwT2vQNWX21okGB1iVvjofwoBMHz5J9ZhRigA== 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; s=fm1; bh=AGYsjV QcthrL7wTQsq4iAwXyIYcz/6BebbtLXC/4JXc=; b=rlIXY5JsowsIL/OawvSv7l d03LQ9a+vSfusoJ3Q6zzaGN3Vl0J8jkAnX1LFvsxVpOJhdaQL8e2cBKTKfM2lUuN M0IR3XlcYz1ms5nlcLOiRaH2FrSXNTrqgNl06VlgPAjc+wtcz/Kn2Zu8QjlrO93N WgkZEMYOCLcyojUX+PBp3jNQfAaJLFmbH1QLzQYSs+tQ9PsJ+sKpy40ru8JIbUVG eg9y5+/JidAtRolRjNqc5jlH2Ggui2arbzeS/jzaRt9k47BGYD/R2iKkPI/lcHNG dgClOcRe0j4PIo8RlMEcnhi9WrYRZdnIr09l30g4wg4h/xDPZOHscLNnMGfu7xkA == X-ME-Sender: Received: from [192.168.1.18] (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id B3B1C24406; Thu, 8 Feb 2018 18:03:03 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: QUIC (quic) WG Interim Meeting: 2018-06-06 From: Mark Nottingham In-Reply-To: <151809506296.17228.17281018611304930059@ietfa.amsl.com> Date: Fri, 9 Feb 2018 10:02:59 +1100 Cc: Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <6203282A-CD65-4049-A499-DED34431E912@mnot.net> References: <151809506296.17228.17281018611304930059@ietfa.amsl.com> To: QUIC WG X-Mailer: Apple Mail (2.3445.5.20) 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, 08 Feb 2018 23:03:08 -0000 Registration is now open; see the arrangements page. Please note the = guidelines for attendance there. Cheers, > On 9 Feb 2018, at 12:04 am, IESG Secretary = wrote: >=20 > The QUIC (quic) Working Group will hold > a multi-day interim meeting. >=20 > Session 1: > 2018-06-06 09:00 to 17:00 Europe/Berlin > Session 2: > 2018-06-07 09:00 to 17:00 Europe/Berlin >=20 > Meeting Location: > Kista, SE >=20 > Agenda: > = https://github.com/quicwg/wg-materials/blob/master/interim-18-06/agenda.md= >=20 > Information about remote participation: > = https://github.com/quicwg/wg-materials/blob/master/interim-18-06/arrangeme= nts.md >=20 > Preceded by non-IETF QUIC interop event on June 4-5, same location >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Thu Feb 8 15:10:15 2018 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 562B8126C89 for ; Thu, 8 Feb 2018 15:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 83jVNTdkGdNt for ; Thu, 8 Feb 2018 15:10:11 -0800 (PST) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3515D120047 for ; Thu, 8 Feb 2018 15:10:11 -0800 (PST) Received: from giant.haxx.se (mail [127.0.0.1]) by giant.haxx.se (8.15.2/8.15.2/Debian-4) with ESMTPS id w18NA5SB025875 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 9 Feb 2018 00:10:05 +0100 Received: from localhost (dast@localhost) by giant.haxx.se (8.15.2/8.15.2/Submit) with ESMTP id w18NA5Mn025870; Fri, 9 Feb 2018 00:10:05 +0100 X-Authentication-Warning: giant.haxx.se: dast owned process doing -bs Date: Fri, 9 Feb 2018 00:10:05 +0100 (CET) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: Mark Nottingham cc: QUIC WG , Lars Eggert Subject: Re: QUIC (quic) WG Interim Meeting: 2018-06-06 In-Reply-To: <6203282A-CD65-4049-A499-DED34431E912@mnot.net> Message-ID: References: <151809506296.17228.17281018611304930059@ietfa.amsl.com> <6203282A-CD65-4049-A499-DED34431E912@mnot.net> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed 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, 08 Feb 2018 23:10:13 -0000 On Fri, 9 Feb 2018, Mark Nottingham wrote: > Registration is now open; see the arrangements page. Please note the > guidelines for attendance there. I noticed a little mistake: the arrangements page says registration closes on June 3rd, while the google forms page says May 3rd... -- / daniel.haxx.se From nobody Thu Feb 8 15:13:52 2018 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 92DFC12D872 for ; Thu, 8 Feb 2018 15:13:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 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, RCVD_IN_MSPIKE_H4=-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=evequefou.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 DiXC4O1pgfaN for ; Thu, 8 Feb 2018 15:13:41 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0111.outbound.protection.outlook.com [104.47.32.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04D4B126CF6 for ; Thu, 8 Feb 2018 15:13:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=AcTxUtCZu2eUnTaSp3NxVPfvAJukehm98I+0oVu4YvE=; b=S8GvYQNqqrfX6lkuEUW+JuQTMt4vgwH7BQSirCvyUT917ZaUduEfa0OX4/Xg/xfM9JZgSzc7sIFRnKuQojIWodBBw8DCp9Qkh+9sq39jxyTme68b/XYQ/Wh1KRLMAz5ChqOV6XiyN1a7/izqcr0eVoWBLqw8plVZj+DLjZuP7QU= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2816.namprd08.prod.outlook.com (10.173.239.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.11; Thu, 8 Feb 2018 23:13:37 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([fe80::5410:deca:3ee5:983f]) by MWHPR08MB2432.namprd08.prod.outlook.com ([fe80::5410:deca:3ee5:983f%16]) with mapi id 15.20.0485.009; Thu, 8 Feb 2018 23:13:37 +0000 From: Mike Bishop To: Praveen Balasubramanian , Marten Seemann , huitema CC: "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW33YzpoOLX0UU2dbBSG8l3vaKOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADXOQCAAGavgIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACabIIAAVcAAgAAUZQCAAA5oAIAAEIEAgABFkgCAAAUSgIAABUkAgAABmYCAAAaRgIAAC4qAgACi8QCAAemoIA== Date: Thu, 8 Feb 2018 23:13:37 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2816; 7:t0N/dytmX4v/hn1vjQHvHxmpJcpJNdLKLufvEGa4XvSf74nC2l73mPqb8WgI7/ML+mTYeYTyQy66sCPPrnNMLH7ODBnbURvCLqdkk81Y5g0WtCgKniFJm4CDYvwl4Z8xc2Sv6ZxM2XHGG+A5NY0AzwePHdqv4naZ6XcWkfLPS3RupL8p5EcfYIMGR1oLXfpicXzvW7yXr/46ayU8UzNazjAMBekVml7EPNGV9yPT11MZE3fsUf9J6F9slMjTr/k1 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 16af3823-605a-4863-721d-08d56f499585 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2816; x-ms-traffictypediagnostic: MWHPR08MB2816: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(10201501046)(6041288)(20161123564045)(20161123558120)(2016111802025)(20161123560045)(20161123562045)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB2816; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2816; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39380400002)(366004)(39830400003)(376002)(199004)(189003)(377424004)(316002)(3660700001)(8676002)(5660300001)(106356001)(39060400002)(55016002)(4326008)(25786009)(81156014)(76176011)(9686003)(74316002)(54896002)(3280700002)(3846002)(6306002)(5250100002)(6436002)(81166006)(8936002)(93886005)(229853002)(3480700004)(53936002)(1511001)(186003)(6246003)(45080400002)(2900100001)(99286004)(14454004)(26005)(105586002)(86362001)(7736002)(74482002)(236005)(7696005)(8666007)(110136005)(59450400001)(2950100002)(6506007)(33656002)(561944003)(68736007)(97736004)(790700001)(6116002)(19609705001)(102836004)(7116003)(2906002)(53546011)(478600001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2816; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: 2je0eKfoNykmZAfRJEU+uh38cjbnkTalfNJZTChFvTrN3e8yiQ+mY9pmBde8K9CNj0hRs3N0U3DdXYiy211Kog== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB24327A7BB5AE1AE70FE5CDB1DAF30MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 16af3823-605a-4863-721d-08d56f499585 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 23:13:37.1045 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2816 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, 08 Feb 2018 23:13:45 -0000 --_000_MWHPR08MB24327A7BB5AE1AE70FE5CDB1DAF30MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 IzIgd29u4oCZdCB3b3JrLiAgVGhlIHBhY2tldCBudW1iZXIgaXMgYW4gaW5wdXQgdG8gdGhlIEFF QUQgbm9uY2UsIHNvIHlvdSBoYXZlIHRvIGdldCB0byB0aGUgcGFja2V0IG51bWJlciBiZWZvcmUg eW91IGNhbiBkZWNyeXB0IHRoZSBwYXlsb2FkLiAgSXQgY2Fu4oCZdCBiZSBiYXNlZCBvbiBhbnl0 aGluZyBpbnRlcm5hbCB0byB0aGUgZW5jcnlwdGVkIHBhY2tldC4NCg0KSW4gTWFydGlu4oCZcyBw cm9wb3NhbCwgaXTigJlzIHVzaW5nIGEgY29tYmluYXRpb24gb2YgdGhlIGVuY3J5cHRlZCBwYXls b2FkICh3aGljaCByZXF1aXJlcyBub3RoaW5nIHRvIGFjY2VzcykgYW5kIHNvbWUgc3RvcmVkIHN0 YXRlIG9uIGVhY2ggZW5kcG9pbnQsIHdoaWNoIHJlcXVpcmVzIG9ubHkgdGhlIENvbm5lY3Rpb24g SUQgdG8gbG9vayB1cC4gIFlvdSB3YW50IHRoZSB0aGluZyB5b3UgWE9SIGJ5IHRvIGJlIGNvbnN0 YW50bHkgY2hhbmdpbmcsIG9yIGl0IGJlY29tZXMgZWFzaWVyIHRvIGxvb2sgYXQgc2VxdWVuY2Vz IG9mIG9iZnVzY2F0ZWQgcGFja2V0IG51bWJlcnMgYW5kIHN0YXJ0IGRyYXdpbmcgaW5mZXJlbmNl cyBhYm91dCB3aGF0IHRoZSBYT1IgdmFsdWUgaXMuICBJZiBvdmVyaGVhZCBpcyB0aGUgcHJpbWFy eSBjb25jZXJuLCBJIHRoaW5rIHRoZXJlIGFyZSBhIGNvdXBsZSBhcHByb2FjaGVzIHRoYXQgbWln aHQgYWxsb3cgeW91IHRvIHByZWNvbXB1dGUgdmFsdWVzIGFuZCBhbW9ydGl6ZSB0aGUgY29zdCBv ZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVwLiAgKEF0IHRoZSBjb3N0IG9mIGtlZXBpbmcgdGhl IHRhYmxlIG9mIHByZWNvbXB1dGVkIHZhbHVlcywgb2YgY291cnNlLikNCg0KSSBzdGlsbCB0aGlu ayBKYW5h4oCZcyBwdXNoaW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24gaGVyZTogIExldOKAmXMg YWdyZWUgb24gZ29hbHMsIGFuZCB0aGVuIHNlZSBpZiB3ZSBjYW4gY3JhZnQgYSBkZXNpZ24gdGhh dCBtZWV0cyB0aG9zZSBnb2Fscy4gIEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92ZXJoZWFk IGlzIGEgZ29hbCwgd2hpY2ggSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiAgSSBhbHNvIHRo aW5rIEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgMS0xLjUlIG92ZXJoZWFkIGlzIHRvbyBoaWdoLCBi dXQgaXQgc291bmRzIGxpa2UgdGhlcmXigJlzIGxlc3MgYWdyZWVtZW50IG9uIHRoYXQuICBZb3Ug YWxzbyByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNvbWUgY2xpZW50cyB3aWxsIGNh cmUgbGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRoZXkgd2lsbCBuZXZlciBpbnRlbnRp b25hbGx5IG1pZ3JhdGUuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSA3LCAyMDE4IDk6NDQgQU0NClRvOiBNYXJ0ZW4gU2VlbWFubiA8bWFydGVuc2Vl bWFubkBnbWFpbC5jb20+OyBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KQ2M6IHF1aWNA aWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KDQpDb3Vw bGUgb2YgdGhpbmdzIHRvIGFkZDoNCg0KMS4gQ29ubmVjdGlvbiBtaWdyYXRpb24gaXMgYW4gb3B0 aW9uYWwgcG9ydGlvbiBvZiB0aGUgdHJhbnNwb3J0IGFuZCBub3QgbWFuZGF0b3J5LiBJdCBkb2Vz IG5vdCBzZWVtIHRvIGJlIGluY3JlbWVudGFsbHkgZGVwbG95YWJsZSB3aXRoIHRvZGF5J3MgdW5t b2RpZmllZCBsb2FkIGJhbGFuY2Vycy4gTWFueSBkZXZpY2VzIG1heSBhbHNvIGJlIHNpbmdsZSBo b21lZCBhbmQgbm90IGhhdmUgbXVsdGlwbGUgYWN0aXZlIG5ldHdvcmsgaW50ZXJmYWNlcy4gSSBh bHNvIHRoaW5rIHRoZSBhcHAgYW5kIHN5c3RlbSBzZXR0aW5ncyB3aWxsIGhhdmUgdG8gb3B0LWlu IHRvIGl0ICh0byBwcmV2ZW50IGFnZ3Jlc3NpdmUgdXNhZ2Ugb2YgbWV0ZXJlZCBjZWxsdWxhciBk YXRhKS4gSWYgdGhpcyBpcyB0aGUgY2FzZSwgY3Jvc3MtcGF0aCBsaW5rYWJpbGl0eSB3aWxsIGJl IG9mIGxpbWl0ZWQgY29uY2VybiBmb3IgbWFueSBRVUlDIGNvbm5lY3Rpb25zLiBUaGVyZSBpcyBh bHNvIHRoZSBmYWN0IHRoYXQgcGVyZmVjdCB1bmxpbmthYmlsaXR5IHNlZW1zIHRvIGJlIGhhcmQg YWdhaW5zdCBhIG1vdGl2YXRlZCBhZHZlcnNhcnkuDQoNCjIuIElmIG1pZGRsZWJveCBvc3NpZmlj YXRpb24gaXMgYSBiaWcgY29uY2Vybiwgd2UgbWFpbmx5IG5lZWQgb2JmdXNjYXRpb24gYW5kIG5v dCBlbmNyeXB0aW9uLiBBbm90aGVyIG9wdGlvbiBmb3IgZXhhbXBsZSB3b3VsZCBiZSBhbiBYT1Ig dHJhbnNmb3JtIHdpdGggc29tZSB2YXJpYWJsZSBmaWVsZCBpbiB0aGUgZW5jcnlwdGVkIHBvcnRp b24gb2YgdGhlIHBhY2tldCAoYXMgYW4gZXhhbXBsZSBzZXF1ZW5jZSBudW1iZXIgb2YgdGhlIGZp cnN0IHN0cmVhbSBmcmFtZSBpZiBpdCBpcyBwcmVzZW50IG9yIHNvbWUgcmFuZG9tIHBhZCBieXRl cyB3aGVuIGl0cyBub3QgcHJlc2VudCkuIEkgaG9wZSB3ZSBjYW4gYmUgY3JlYXRpdmUgaGVyZSB0 byByZWR1Y2UgY29tcHV0YXRpb24gY29zdC4NCg0KDQpGcm9tOiBNYXJ0ZW4gU2VlbWFubiBbbWFp bHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSA3 LCAyMDE4IDEyOjAxIEFNDQpUbzogaHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86 aHVpdGVtYUBodWl0ZW1hLm5ldD4+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZi QG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PjsgcXVpY0BpZXRmLm9y ZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5 cHRpb24NCg0KDQpPbiBXZWQsIEZlYiA3LCAyMDE4IGF0IDM6MjAgUE0gQ2hyaXN0aWFuIEh1aXRl bWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PiB3cm90 ZToNCg0KDQoNCk9uIDIvNi8yMDE4IDg6NTUgUE0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIHdy b3RlOg0KDQpGaXJzdCwgdGhlIHByb3Bvc2FsIGRvZXMgbm90IG9ic2N1cmUgdGhlIHBvc2l0aW9u IG9mIHRoZSBwYWNrZXQgbnVtYmVyIGZpZWxkIGluIHRoZSBoZWFkZXIuIFRoZSBmaWVsZCBjb250 YWlucyBhIG51bWJlciB0aGF0IGluY3JlbWVudHMgd2l0aCBldmVyeSBwYWNrZXQsIGFuZCBpcyB0 aHVzIGVhc3kgdG8gaWRlbnRpZnkuIFRoaXMgbWVhbnMgdGhhdCBtaWRkbGUtYm94ZXMgd2lsbCBn ZXQgYWNjdXN0b21lZCB0byBzZWVpbmcgdGhhdCBmaWVsZCBhbmQgdHJhY2tpbmcgaXRzIGluY3Jl bWVudHMuDQoNCkhlbmNlLCB0aGlzIHNpbXBsZSBvYmZ1c2NhdGlvbiBwcm92aWRlcyBubyBwcm90 ZWN0aW9uIGFnYWluc3Qgb3NzaWZpY2F0aW9uIG9mIHRoZSBwYWNrZXQgbnVtYmVyIGZpZWxkLg0K DQoNCg0KV2VsbCBpdCBzZWVtcyBsaWtlIGl0IGlzIGEgcmVxdWlyZW1lbnQgKHNlZSBidWxsZXQg MyBpbiBKYW5hJ3MgbGlzdCkgdG8gYWxsb3cgbWlkZGxlYm94ZXMgdG8gc2VlIHNlcXVlbmNpbmcg aW5mb3JtYXRpb24uIEJ5IHBpY2tpbmcgdGhlIGluaXRpYWwgcmFuZG9tIHZhbHVlIG1pZGRsZWJv eGVzIGNhbm5vdCBhc3N1bWUgYW55IHBhcnRpY3VsYXIgdmFsdWUuIElmIHBhY2tldCBudW1iZXIg bG9jYXRpb24gYW5kIHNpemUgaXMgbm90IHBhcnQgb2YgaW52YXJpYW50cyB0aGVuIGl0IGNhbm5v dCBiZSBvc3NpZmllZCwgbWlkZGxlYm94ZXMgd2lsbCBuZWVkIHRvIGJlIHJlc2lsaWVudC4NCg0K VGhpcyBpcyB3aHkgSSB3b3VsZCByYXRoZXIgc2VlIHRoZSBleHBvc2VkIGJpdHMgY29waWVkIGF0 IGEgZml4ZWQgbG9jYXRpb24sIHdoaWxlIHRoZSBQTiBpdHNlbGYgY2Fubm90IGJlIGxvY2F0ZWQu IFRoYXQgd2F5LCB0aGUgZXhwb3NlZCBiaXRzIGNhbiBvc3NpZnksIGJ1dCB0aGUgYWN0dWFsIFBO IGRvZXMgbm90Lg0KDQpXZSBzdGlsbCBuZWVkIHRvIGJlIHZlcnkgY2FyZWZ1bCBoZXJlLiBJZiB3 ZSBkZWNpZGUgdG8gZXhwb3NlIGJpdHMsIHdlIG11c3QgbWFrZSBzdXJlIHRoYXQgYSBtaWRkbGVi b3ggY2FuIG9ubHkgZXh0cmFjdCBjb2Fyc2UtZ3JhaW5lZCBpbmZvcm1hdGlvbiwgaWYgd2Ugd2Fu dCB0byBwcmV2ZW50IG1pZGRsZWJveGVzIGZyb20gYnVmZmVyaW5nIGFuZCBkZWxheWluZyBwYWNr ZXRzIGluIG9yZGVyIHRvIGZpeCAvIHJlZHVjZSByZW9yZGVyaW5nLg0KQXQgdGhpcyBwb2ludCBo b3dldmVyLCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IGV4cG9zaW5nIGFueSByZW9yZGVyaW5nIGlu Zm9ybWF0aW9uIHRvIHRoZSBuZXR3b3JrIHNob3VsZCBiZSBhIHJlcXVpcmVtZW50IGF0IGFsbC4g VGhlcmUncyBhIHJlYWwgcmlzayBvZiBtaXN1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiwgYW5kIG9m IG9zc2lmaWNhdGlvbiBvZiB3aGF0ZXZlciBiaXRzIHdlIGV4cG9zZS4NCg== --_000_MWHPR08MB24327A7BB5AE1AE70FE5CDB1DAF30MWHPR08MB2432namp_ 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 aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNv bnNvbGFzO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IzIgd29u4oCZdCB3b3JrLiZuYnNwOyBU aGUgcGFja2V0IG51bWJlciBpcyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwgc28geW91IGhh dmUgdG8gZ2V0IHRvIHRoZSBwYWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRlY3J5cHQgdGhl IHBheWxvYWQuJm5ic3A7IEl0IGNhbuKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcgaW50ZXJuYWwg dG8gdGhlIGVuY3J5cHRlZCBwYWNrZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIE1hcnRp buKAmXMgcHJvcG9zYWwsIGl04oCZcyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mIHRoZSBlbmNyeXB0 ZWQgcGF5bG9hZCAod2hpY2ggcmVxdWlyZXMgbm90aGluZyB0byBhY2Nlc3MpIGFuZCBzb21lIHN0 b3JlZCBzdGF0ZSBvbiBlYWNoIGVuZHBvaW50LCB3aGljaCByZXF1aXJlcyBvbmx5IHRoZSBDb25u ZWN0aW9uIElEIHRvIGxvb2sgdXAuJm5ic3A7IFlvdSB3YW50IHRoZSB0aGluZyB5b3UgWE9SIGJ5 IHRvIGJlIGNvbnN0YW50bHkNCiBjaGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNpZXIgdG8gbG9v ayBhdCBzZXF1ZW5jZXMgb2Ygb2JmdXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQgc3RhcnQgZHJh d2luZyBpbmZlcmVuY2VzIGFib3V0IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4mbmJzcDsgSWYgb3Zl cmhlYWQgaXMgdGhlIHByaW1hcnkgY29uY2VybiwgSSB0aGluayB0aGVyZSBhcmUgYSBjb3VwbGUg YXBwcm9hY2hlcyB0aGF0IG1pZ2h0IGFsbG93IHlvdSB0byBwcmVjb21wdXRlIHZhbHVlcw0KIGFu ZCBhbW9ydGl6ZSB0aGUgY29zdCBvZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVwLiZuYnNwOyAo QXQgdGhlIGNvc3Qgb2Yga2VlcGluZyB0aGUgdGFibGUgb2YgcHJlY29tcHV0ZWQgdmFsdWVzLCBv ZiBjb3Vyc2UuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0aWxsIHRoaW5rIEphbmHigJlz IHB1c2hpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBoZXJlOiZuYnNwOyBMZXTigJlzIGFncmVl IG9uIGdvYWxzLCBhbmQgdGhlbiBzZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWduIHRoYXQgbWVl dHMgdGhvc2UgZ29hbHMuJm5ic3A7IEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92ZXJoZWFk IGlzIGEgZ29hbCwgd2hpY2ggSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiZuYnNwOyBJIGFs c28gdGhpbmsNCiBJIGhlYXIgeW91IHNheWluZyB0aGF0IDEtMS41JSBvdmVyaGVhZCBpcyB0b28g aGlnaCwgYnV0IGl0IHNvdW5kcyBsaWtlIHRoZXJl4oCZcyBsZXNzIGFncmVlbWVudCBvbiB0aGF0 LiZuYnNwOyBZb3UgYWxzbyByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNvbWUgY2xp ZW50cyB3aWxsIGNhcmUgbGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRoZXkgd2lsbCBu ZXZlciBpbnRlbnRpb25hbGx5IG1pZ3JhdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+UHJhdmVlbiBCYWxhc3Vi cmFtYW5pYW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSA3LCAyMDE4IDk6 NDQgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRlbiBTZWVtYW5uICZsdDttYXJ0ZW5zZWVtYW5uQGdt YWlsLmNvbSZndDs7IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQYWNrZXQgbnVt YmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PkNvdXBsZSBvZiB0aGluZ3MgdG8gYWRkOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+MS4gQ29ubmVjdGlvbiBtaWdyYXRpb24gaXMgYW4gb3B0aW9uYWwgcG9ydGlvbiBv ZiB0aGUgdHJhbnNwb3J0IGFuZCBub3QgbWFuZGF0b3J5LiBJdCBkb2VzIG5vdCBzZWVtIHRvIGJl IGluY3JlbWVudGFsbHkgZGVwbG95YWJsZSB3aXRoIHRvZGF5J3MgdW5tb2RpZmllZCBsb2FkIGJh bGFuY2Vycy4gTWFueSBkZXZpY2VzIG1heSBhbHNvIGJlIHNpbmdsZSBob21lZCBhbmQgbm90IGhh dmUgbXVsdGlwbGUgYWN0aXZlDQogbmV0d29yayBpbnRlcmZhY2VzLiBJIGFsc28gdGhpbmsgdGhl IGFwcCBhbmQgc3lzdGVtIHNldHRpbmdzIHdpbGwgaGF2ZSB0byBvcHQtaW4gdG8gaXQgKHRvIHBy ZXZlbnQgYWdncmVzc2l2ZSB1c2FnZSBvZiBtZXRlcmVkIGNlbGx1bGFyIGRhdGEpLiBJZiB0aGlz IGlzIHRoZSBjYXNlLCBjcm9zcy1wYXRoIGxpbmthYmlsaXR5IHdpbGwgYmUgb2YgbGltaXRlZCBj b25jZXJuIGZvciBtYW55IFFVSUMgY29ubmVjdGlvbnMuIFRoZXJlIGlzIGFsc28gdGhlDQogZmFj dCB0aGF0IHBlcmZlY3QgdW5saW5rYWJpbGl0eSBzZWVtcyB0byBiZSBoYXJkIGFnYWluc3QgYSBt b3RpdmF0ZWQgYWR2ZXJzYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Mi4gSWYgbWlkZGxlYm94IG9zc2lmaWNhdGlvbiBpcyBhIGJpZyBjb25jZXJuLCB3ZSBtYWlu bHkgbmVlZCBvYmZ1c2NhdGlvbiBhbmQgbm90IGVuY3J5cHRpb24uIEFub3RoZXIgb3B0aW9uIGZv ciBleGFtcGxlIHdvdWxkIGJlIGFuIFhPUiB0cmFuc2Zvcm0gd2l0aCBzb21lIHZhcmlhYmxlIGZp ZWxkIGluIHRoZSBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0aGUgcGFja2V0IChhcyBhbiBleGFtcGxl IHNlcXVlbmNlDQogbnVtYmVyIG9mIHRoZSBmaXJzdCBzdHJlYW0gZnJhbWUgaWYgaXQgaXMgcHJl c2VudCBvciBzb21lIHJhbmRvbSBwYWQgYnl0ZXMgd2hlbiBpdHMgbm90IHByZXNlbnQpLiBJIGhv cGUgd2UgY2FuIGJlIGNyZWF0aXZlIGhlcmUgdG8gcmVkdWNlIGNvbXB1dGF0aW9uIGNvc3QuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWFydGVuIFNlZW1hbm4gWzxhIGhyZWY9Im1haWx0bzpt YXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbSI+bWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPC9h Pl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDcsIDIwMTggMTI6MDEg QU08YnI+DQo8Yj5Ubzo8L2I+IGh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1 aXRlbWEubmV0Ij5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFBy YXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0 LmNvbSI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNA aWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNr ZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgRmViIDcsIDIwMTggYXQgMzoyMCBQTSBD aHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQi Pmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHA+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzYvMjAxOCA4 OjU1IFBNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cHJlPkZpcnN0LCB0aGUgcHJvcG9zYWwgZG9lcyBub3Qgb2JzY3VyZSB0aGUgcG9z aXRpb24gb2YgdGhlIHBhY2tldCBudW1iZXIgZmllbGQgaW4gdGhlIGhlYWRlci4gVGhlIGZpZWxk IGNvbnRhaW5zIGEgbnVtYmVyIHRoYXQgaW5jcmVtZW50cyB3aXRoIGV2ZXJ5IHBhY2tldCwgYW5k IGlzIHRodXMgZWFzeSB0byBpZGVudGlmeS4gVGhpcyBtZWFucyB0aGF0IG1pZGRsZS1ib3hlcyB3 aWxsIGdldCBhY2N1c3RvbWVkIHRvIHNlZWluZyB0aGF0IGZpZWxkIGFuZCB0cmFja2luZyBpdHMg aW5jcmVtZW50cy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5IZW5jZSwgdGhpcyBzaW1wbGUgb2Jm dXNjYXRpb24gcHJvdmlkZXMgbm8gcHJvdGVjdGlvbiBhZ2FpbnN0IG9zc2lmaWNhdGlvbiBvZiB0 aGUgcGFja2V0IG51bWJlciBmaWVsZC48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw OzwvbzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldlbGwg aXQgc2VlbXMgbGlrZSBpdCBpcyBhIHJlcXVpcmVtZW50IChzZWUgYnVsbGV0IDMgaW4gSmFuYSdz IGxpc3QpIHRvIGFsbG93IG1pZGRsZWJveGVzIHRvIHNlZSBzZXF1ZW5jaW5nIGluZm9ybWF0aW9u LiBCeSBwaWNraW5nIHRoZSBpbml0aWFsIHJhbmRvbSB2YWx1ZSBtaWRkbGVib3hlcyBjYW5ub3Qg YXNzdW1lIGFueSBwYXJ0aWN1bGFyIHZhbHVlLiBJZiBwYWNrZXQgbnVtYmVyIGxvY2F0aW9uIGFu ZCBzaXplIGlzIG5vdCBwYXJ0IG9mIGludmFyaWFudHMgdGhlbiBpdCBjYW5ub3QgYmUgb3NzaWZp ZWQsIG1pZGRsZWJveGVzIHdpbGwgbmVlZCB0byBiZSByZXNpbGllbnQuIDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHdoeSBJIHdvdWxk IHJhdGhlciBzZWUgdGhlIGV4cG9zZWQgYml0cyBjb3BpZWQgYXQgYSBmaXhlZCBsb2NhdGlvbiwg d2hpbGUgdGhlIFBOIGl0c2VsZiBjYW5ub3QgYmUgbG9jYXRlZC4gVGhhdCB3YXksIHRoZSBleHBv c2VkIGJpdHMgY2FuIG9zc2lmeSwgYnV0IHRoZSBhY3R1YWwgUE4gZG9lcyBub3QuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPldlIHN0aWxsIG5lZWQgdG8gYmUgdmVyeSBjYXJlZnVsIGhlcmUuIElmIHdlIGRlY2lkZSB0 byBleHBvc2UgYml0cywgd2UgbXVzdCBtYWtlIHN1cmUgdGhhdCBhIG1pZGRsZWJveCBjYW4gb25s eSBleHRyYWN0IGNvYXJzZS1ncmFpbmVkIGluZm9ybWF0aW9uLCBpZiB3ZSB3YW50IHRvIHByZXZl bnQgbWlkZGxlYm94ZXMgZnJvbSBidWZmZXJpbmcgYW5kIGRlbGF5aW5nIHBhY2tldHMgaW4gb3Jk ZXIgdG8gZml4IC8NCiByZWR1Y2UgcmVvcmRlcmluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF0IHRoaXMgcG9pbnQgaG93ZXZlciwgSSdtIG5v dCBjb252aW5jZWQgdGhhdCBleHBvc2luZyBhbnkgcmVvcmRlcmluZyBpbmZvcm1hdGlvbiB0byB0 aGUgbmV0d29yayBzaG91bGQgYmUgYSByZXF1aXJlbWVudCBhdCBhbGwuIFRoZXJlJ3MgYSByZWFs IHJpc2sgb2YgbWlzdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24sIGFuZCBvZiBvc3NpZmljYXRpb24g b2Ygd2hhdGV2ZXIgYml0cyB3ZSBleHBvc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR08MB24327A7BB5AE1AE70FE5CDB1DAF30MWHPR08MB2432namp_-- From nobody Thu Feb 8 15:54:59 2018 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 4B9F712711E for ; Thu, 8 Feb 2018 15:54:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Q4WDjiBUwJII for ; Thu, 8 Feb 2018 15:54:54 -0800 (PST) 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 55E41127011 for ; Thu, 8 Feb 2018 15:54:54 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx12.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ejw1f-0008BL-Kn for quic@ietf.org; Fri, 09 Feb 2018 00:54:51 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ejw1A-0001FD-LQ for quic@ietf.org; Thu, 08 Feb 2018 18:54:44 -0500 Received: (qmail 16669 invoked from network); 8 Feb 2018 23:53:47 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 8 Feb 2018 23:53:47 -0000 To: quic@ietf.org References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> From: Christian Huitema Message-ID: <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> Date: Thu, 8 Feb 2018 13:53:46 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7ABA0C44FA03DDADB6B4054E" Content-Language: en-US Subject: Re: Packet number encryption X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5o52OcSnHZJXsHmbfQFqnBYXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fur0SniUZO2YupYKxd874kyB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYd851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Vm3SIdO3BpR97t9bfBi5FxwJWxe4AVanuu6Qx5p47D RQ9KsNiMTLNuVe41G8phqGPGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kA/d90Ehtjr2Rr9EnHIEiQBkONoJfh+XjGSeeT90H/uIGA ixD6iqREQNDQmKfhrLECCDSE/o0T+R9dqKqbajE0/GbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWnDLQOyxbLULlVOPz78QcU/fFcHV2tQAVqGdj/zM7G/GArVPZLiHwNOHBLhYro6nu5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w 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: Thu, 08 Feb 2018 23:54:57 -0000 This is a multi-part message in MIME format. --------------7ABA0C44FA03DDADB6B4054E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/8/2018 1:13 PM, Mike Bishop wrote: > #2 won=E2=80=99t work.=C2=A0 The packet number is an input to the AEAD = nonce, so > you have to get to the packet number before you can decrypt the > payload.=C2=A0 It can=E2=80=99t be based on anything internal to the en= crypted packet. > > =C2=A0 > > In Martin=E2=80=99s proposal, it=E2=80=99s using a combination of the e= ncrypted > payload (which requires nothing to access) and some stored state on > each endpoint, which requires only the Connection ID to look up.=C2=A0 = You > want the thing you XOR by to be constantly changing, or it becomes > easier to look at sequences of obfuscated packet numbers and start > drawing inferences about what the XOR value is.=C2=A0 If overhead is th= e > primary concern, I think there are a couple approaches that might > allow you to precompute values and amortize the cost of doing the > encryption step.=C2=A0 (At the cost of keeping the table of precomputed= > values, of course.) > > =C2=A0 > > I still think Jana=E2=80=99s pushing in the right direction here:=C2=A0= Let=E2=80=99s agree > on goals, and then see if we can craft a design that meets those > goals.=C2=A0 I hear you saying that low overhead is a goal, which I thi= nk > we can all agree on.=C2=A0 I also think I hear you saying that 1-1.5% > overhead is too high, but it sounds like there=E2=80=99s less agreement= on > that.=C2=A0 You also raise an interesting point that some clients will = care > less about linkability because they will never intentionally migrate. > I think Victor said it best, "Obfuscation is just encryption done poorly." Either we encrypt, or we don't. But there is no such thing as an obfuscation middle-ground. Obfuscation would just be a speed bump, easily broken. It won't provide privacy, and it won't prevent linkability= =2E As far as I am concerned, there are only two designs that prevent linkability: 1) Martin's PR, in which the packet number is encrypted using sensible crypto; 2) Or, leaving the packet number in the clear but using different encryption contexts for each path, and using separate packet sequences for each path. The second option requires more computation when explicitly setting up a new path. The connection ID would be used as part of the "salt" when deriving connection contexts. The packet number on each path will start at 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK to be per/path, or alternatively adding a PATH-ACK frame that indicates the path for which packets are acked. The pros and cons of the two options are easy to get: 1) Option 2 does not require the cost of encrypting every packet, thus per packet processing will be maybe 1% faster than option 1. 2) Option 2 requires computing encryption contexts for each path, which is more complex than option 1, but the cost will be amortized over the duration of the path. 3) Option 2 requires more complex data structures and ACK management, thus increasing the chances that something goes wrong. 4) Option 2 does nothing against packet number ossification. The packet number effectively becomes part of the invariants. In short, the only advantage of option 2 is to avoid a single symmetric encryption operation per packet, while making the code significantly more complex, and at the cost of not protecting against PN ossification. The way I see that, there is hardly any debate. -- Christian Huitema --------------7ABA0C44FA03DDADB6B4054E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2/8/2018 1:13 PM, Mike Bishop wrote:

#2 won’t work.  The packet number is an input to the AEAD nonce, so you have to get to the packet number before you can decrypt the payload.  It can’t be based on anything internal to the encrypted packet.

 

In Martin’s proposal, it’s using a combination of the encrypted payload (which requires nothing to access) and some stored state on each endpoint, which requires only the Connection ID to look up.  You want the thing you XOR by to be constantly changing, or it becomes easier to look at sequences of obfuscated packet numbers and start drawing inferences about what the XOR value is.  If overhead is the primary concern, I think there are a couple approaches that might allow you to precompute values and amortize the cost of doing the encryption step.  (At the cost of keeping the table of precomputed values, of course.)

 

I still think Jana’s pushing in the right direction here:  Let’s agree on goals, and then see if we can craft a design that meets those goals.  I hear you saying that low overhead is a goal, which I think we can all agree on.  I also think I hear you saying that 1-1.5% overhead is too high, but it sounds like there’s less agreement on that.  You also raise an interesting point that some clients will care less about linkability because they will never intentionally migrate.


I think Victor said it best, "Obfuscation is just encryption done poorly." Either we encrypt, or we don't. But there is no such thing as an obfuscation middle-ground. Obfuscation would just be a speed bump, easily broken. It won't provide privacy, and it won't prevent linkability.

As far as I am concerned, there are only two designs that prevent linkability:

1) Martin's PR, in which the packet number is encrypted using sensible crypto;

2) Or, leaving the packet number in the clear but using different encryption contexts for each path, and using separate packet sequences for each path.

The second option requires more computation when explicitly setting up a new path. The connection ID would be used as part of the "salt" when deriving connection contexts. The packet number on each path will start at 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK to be per/path, or alternatively adding a PATH-ACK frame that indicates the path for which packets are acked.

The pros and cons of the two options are easy to get:

1) Option 2 does not require the cost of encrypting every packet, thus per packet processing will be maybe 1% faster than option 1.

2) Option 2 requires computing encryption contexts for each path, which is more complex than option 1, but the cost will be amortized over the duration of the path.

3) Option 2 requires more complex data structures and ACK management, thus increasing the chances that something goes wrong.

4) Option 2 does nothing against packet number ossification. The packet number effectively becomes part of the invariants.

In short, the only advantage of option 2 is to avoid a single symmetric encryption operation per packet, while making the code significantly more complex, and at the cost of not protecting against PN ossification. The way I see that, there is hardly any debate.

-- Christian Huitema

--------------7ABA0C44FA03DDADB6B4054E-- From nobody Thu Feb 8 16:46:18 2018 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 0FFF3124239 for ; Thu, 8 Feb 2018 16:46:17 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 iZ2xPJ2AOK5P for ; Thu, 8 Feb 2018 16:46:14 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0097.outbound.protection.outlook.com [104.47.37.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9FA126CD6 for ; Thu, 8 Feb 2018 16:46:13 -0800 (PST) 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=8LTKu8r5mvHsWLiWI8I0Uizo668YHOH2mSA5iClzQpM=; b=M1sfu0zA5C7DxiJ059PtUjDpPW43oeWBKN7op9XGQsSyj0J+II/qz08LnJAM/ChnkElAGtV5MG8pfjJ2lCqbPECiEKdsOdiRPrQjcKATDzWjxBJOJWONMVPW2XDMJG7fwxTXHouGFQ0sFPyr5quSkmW3xAilzLmU1TJ30ZhIe/I= Received: from MWHPR21MB0144.namprd21.prod.outlook.com (10.173.52.14) by MWHPR21MB0766.namprd21.prod.outlook.com (10.173.51.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.3; Fri, 9 Feb 2018 00:46:07 +0000 Received: from MWHPR21MB0144.namprd21.prod.outlook.com ([10.173.52.14]) by MWHPR21MB0144.namprd21.prod.outlook.com ([10.173.52.14]) with mapi id 15.20.0485.000; Fri, 9 Feb 2018 00:46:07 +0000 From: Praveen Balasubramanian To: Mike Bishop , Marten Seemann , huitema CC: "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAAGbaQ Date: Fri, 9 Feb 2018 00:46:07 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0766; 7:UvDxd7pJDP1P6QAhTU6WTZJ3153mFHR+gvbHS3TWZ8Sltw6TmxnKB4JxmaSbFzDgQqy5E68D4qKxQUmJg61Ln3Nb6vVenoSl12FQeOm0ccvgN6mnZGwGOLVwxw2bXfAeMFg06lCVBfxaE1VgG75iKXjn7BddhiuQCcjRkhzCYrhCf9b9vK4CcMtGEIbOCq67EVmmEm68EK08is55hfQF8FYcKgDUA4BQ7YGObkr10Wgazq3kru/kCDtoPNdCcioe x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 16609f36-eccc-4b94-b9aa-08d56f568179 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:MWHPR21MB0766; x-ms-traffictypediagnostic: MWHPR21MB0766: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR21MB0766; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0766; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(39860400002)(346002)(366004)(396003)(377424004)(199004)(189003)(6436002)(3660700001)(6346003)(7736002)(102836004)(316002)(3280700002)(7696005)(22452003)(74316002)(54896002)(9686003)(6306002)(93886005)(97736004)(236005)(86362001)(53546011)(59450400001)(76176011)(6506007)(55016002)(790700001)(53936002)(6116002)(8936002)(105586002)(8676002)(81156014)(81166006)(3480700004)(68736007)(7116003)(77096007)(2950100002)(99286004)(2906002)(5660300001)(186003)(8990500004)(4326008)(33656002)(561944003)(86612001)(14454004)(39060400002)(19609705001)(2900100001)(478600001)(10290500003)(10090500001)(25786009)(6246003)(229853002)(110136005)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0766; H:MWHPR21MB0144.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: 5m7NZRO8Oqdnk4FkQmD33qhqvZJjOV2+lgEuL+iyY6k9WN2cbE+jE0efqHlZ1SqsVHruBghwgxgzWZzrz1X/qQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01449EB31E145DC2CFBF7E40B6F20MWHPR21MB0144namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 16609f36-eccc-4b94-b9aa-08d56f568179 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 00:46:07.1851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0766 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, 09 Feb 2018 00:46:17 -0000 --_000_MWHPR21MB01449EB31E145DC2CFBF7E40B6F20MWHPR21MB0144namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGlucHV0IHRvIHRoZSBub25jZSB3aWxsIGJlIHRoZSB0cmFuc2Zvcm1lZCB2YWx1ZSBpbiBj bGVhcnRleHQuDQoNCkZyb206IE1pa2UgQmlzaG9wIFttYWlsdG86bWJpc2hvcEBldmVxdWVmb3Uu YmVdDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCAzOjE0IFBNDQpUbzogUHJhdmVl biBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBNYXJ0ZW4gU2VlbWFubiA8 bWFydGVuc2VlbWFubkBnbWFpbC5jb20+OyBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0K Q2M6IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24N Cg0KIzIgd29u4oCZdCB3b3JrLiAgVGhlIHBhY2tldCBudW1iZXIgaXMgYW4gaW5wdXQgdG8gdGhl IEFFQUQgbm9uY2UsIHNvIHlvdSBoYXZlIHRvIGdldCB0byB0aGUgcGFja2V0IG51bWJlciBiZWZv cmUgeW91IGNhbiBkZWNyeXB0IHRoZSBwYXlsb2FkLiAgSXQgY2Fu4oCZdCBiZSBiYXNlZCBvbiBh bnl0aGluZyBpbnRlcm5hbCB0byB0aGUgZW5jcnlwdGVkIHBhY2tldC4NCg0KSW4gTWFydGlu4oCZ cyBwcm9wb3NhbCwgaXTigJlzIHVzaW5nIGEgY29tYmluYXRpb24gb2YgdGhlIGVuY3J5cHRlZCBw YXlsb2FkICh3aGljaCByZXF1aXJlcyBub3RoaW5nIHRvIGFjY2VzcykgYW5kIHNvbWUgc3RvcmVk IHN0YXRlIG9uIGVhY2ggZW5kcG9pbnQsIHdoaWNoIHJlcXVpcmVzIG9ubHkgdGhlIENvbm5lY3Rp b24gSUQgdG8gbG9vayB1cC4gIFlvdSB3YW50IHRoZSB0aGluZyB5b3UgWE9SIGJ5IHRvIGJlIGNv bnN0YW50bHkgY2hhbmdpbmcsIG9yIGl0IGJlY29tZXMgZWFzaWVyIHRvIGxvb2sgYXQgc2VxdWVu Y2VzIG9mIG9iZnVzY2F0ZWQgcGFja2V0IG51bWJlcnMgYW5kIHN0YXJ0IGRyYXdpbmcgaW5mZXJl bmNlcyBhYm91dCB3aGF0IHRoZSBYT1IgdmFsdWUgaXMuICBJZiBvdmVyaGVhZCBpcyB0aGUgcHJp bWFyeSBjb25jZXJuLCBJIHRoaW5rIHRoZXJlIGFyZSBhIGNvdXBsZSBhcHByb2FjaGVzIHRoYXQg bWlnaHQgYWxsb3cgeW91IHRvIHByZWNvbXB1dGUgdmFsdWVzIGFuZCBhbW9ydGl6ZSB0aGUgY29z dCBvZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVwLiAgKEF0IHRoZSBjb3N0IG9mIGtlZXBpbmcg dGhlIHRhYmxlIG9mIHByZWNvbXB1dGVkIHZhbHVlcywgb2YgY291cnNlLikNCg0KSSBzdGlsbCB0 aGluayBKYW5h4oCZcyBwdXNoaW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24gaGVyZTogIExldOKA mXMgYWdyZWUgb24gZ29hbHMsIGFuZCB0aGVuIHNlZSBpZiB3ZSBjYW4gY3JhZnQgYSBkZXNpZ24g dGhhdCBtZWV0cyB0aG9zZSBnb2Fscy4gIEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92ZXJo ZWFkIGlzIGEgZ29hbCwgd2hpY2ggSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiAgSSBhbHNv IHRoaW5rIEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgMS0xLjUlIG92ZXJoZWFkIGlzIHRvbyBoaWdo LCBidXQgaXQgc291bmRzIGxpa2UgdGhlcmXigJlzIGxlc3MgYWdyZWVtZW50IG9uIHRoYXQuICBZ b3UgYWxzbyByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNvbWUgY2xpZW50cyB3aWxs IGNhcmUgbGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRoZXkgd2lsbCBuZXZlciBpbnRl bnRpb25hbGx5IG1pZ3JhdGUuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2VudDogV2VkbmVz ZGF5LCBGZWJydWFyeSA3LCAyMDE4IDk6NDQgQU0NClRvOiBNYXJ0ZW4gU2VlbWFubiA8bWFydGVu c2VlbWFubkBnbWFpbC5jb208bWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPj47IGh1aXRl bWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+Pg0KQ2M6 IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogUGFja2V0 IG51bWJlciBlbmNyeXB0aW9uDQoNCg0KQ291cGxlIG9mIHRoaW5ncyB0byBhZGQ6DQoNCjEuIENv bm5lY3Rpb24gbWlncmF0aW9uIGlzIGFuIG9wdGlvbmFsIHBvcnRpb24gb2YgdGhlIHRyYW5zcG9y dCBhbmQgbm90IG1hbmRhdG9yeS4gSXQgZG9lcyBub3Qgc2VlbSB0byBiZSBpbmNyZW1lbnRhbGx5 IGRlcGxveWFibGUgd2l0aCB0b2RheSdzIHVubW9kaWZpZWQgbG9hZCBiYWxhbmNlcnMuIE1hbnkg ZGV2aWNlcyBtYXkgYWxzbyBiZSBzaW5nbGUgaG9tZWQgYW5kIG5vdCBoYXZlIG11bHRpcGxlIGFj dGl2ZSBuZXR3b3JrIGludGVyZmFjZXMuIEkgYWxzbyB0aGluayB0aGUgYXBwIGFuZCBzeXN0ZW0g c2V0dGluZ3Mgd2lsbCBoYXZlIHRvIG9wdC1pbiB0byBpdCAodG8gcHJldmVudCBhZ2dyZXNzaXZl IHVzYWdlIG9mIG1ldGVyZWQgY2VsbHVsYXIgZGF0YSkuIElmIHRoaXMgaXMgdGhlIGNhc2UsIGNy b3NzLXBhdGggbGlua2FiaWxpdHkgd2lsbCBiZSBvZiBsaW1pdGVkIGNvbmNlcm4gZm9yIG1hbnkg UVVJQyBjb25uZWN0aW9ucy4gVGhlcmUgaXMgYWxzbyB0aGUgZmFjdCB0aGF0IHBlcmZlY3QgdW5s aW5rYWJpbGl0eSBzZWVtcyB0byBiZSBoYXJkIGFnYWluc3QgYSBtb3RpdmF0ZWQgYWR2ZXJzYXJ5 Lg0KDQoyLiBJZiBtaWRkbGVib3ggb3NzaWZpY2F0aW9uIGlzIGEgYmlnIGNvbmNlcm4sIHdlIG1h aW5seSBuZWVkIG9iZnVzY2F0aW9uIGFuZCBub3QgZW5jcnlwdGlvbi4gQW5vdGhlciBvcHRpb24g Zm9yIGV4YW1wbGUgd291bGQgYmUgYW4gWE9SIHRyYW5zZm9ybSB3aXRoIHNvbWUgdmFyaWFibGUg ZmllbGQgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBwYWNrZXQgKGFzIGFuIGV4YW1w bGUgc2VxdWVuY2UgbnVtYmVyIG9mIHRoZSBmaXJzdCBzdHJlYW0gZnJhbWUgaWYgaXQgaXMgcHJl c2VudCBvciBzb21lIHJhbmRvbSBwYWQgYnl0ZXMgd2hlbiBpdHMgbm90IHByZXNlbnQpLiBJIGhv cGUgd2UgY2FuIGJlIGNyZWF0aXZlIGhlcmUgdG8gcmVkdWNlIGNvbXB1dGF0aW9uIGNvc3QuDQoN Cg0KRnJvbTogTWFydGVuIFNlZW1hbm4gW21haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbV0N ClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgNywgMjAxOCAxMjowMSBBTQ0KVG86IGh1aXRlbWEg PGh1aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+Pg0KQ2M6IFBy YXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBt aWNyb3NvZnQuY29tPj47IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCg0KT24gV2VkLCBGZWIgNywgMjAx OCBhdCAzOjIwIFBNIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0 bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj4gd3JvdGU6DQoNCg0KDQpPbiAyLzYvMjAxOCA4OjU1IFBN LCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiB3cm90ZToNCg0KRmlyc3QsIHRoZSBwcm9wb3NhbCBk b2VzIG5vdCBvYnNjdXJlIHRoZSBwb3NpdGlvbiBvZiB0aGUgcGFja2V0IG51bWJlciBmaWVsZCBp biB0aGUgaGVhZGVyLiBUaGUgZmllbGQgY29udGFpbnMgYSBudW1iZXIgdGhhdCBpbmNyZW1lbnRz IHdpdGggZXZlcnkgcGFja2V0LCBhbmQgaXMgdGh1cyBlYXN5IHRvIGlkZW50aWZ5LiBUaGlzIG1l YW5zIHRoYXQgbWlkZGxlLWJveGVzIHdpbGwgZ2V0IGFjY3VzdG9tZWQgdG8gc2VlaW5nIHRoYXQg ZmllbGQgYW5kIHRyYWNraW5nIGl0cyBpbmNyZW1lbnRzLg0KDQpIZW5jZSwgdGhpcyBzaW1wbGUg b2JmdXNjYXRpb24gcHJvdmlkZXMgbm8gcHJvdGVjdGlvbiBhZ2FpbnN0IG9zc2lmaWNhdGlvbiBv ZiB0aGUgcGFja2V0IG51bWJlciBmaWVsZC4NCg0KDQoNCldlbGwgaXQgc2VlbXMgbGlrZSBpdCBp cyBhIHJlcXVpcmVtZW50IChzZWUgYnVsbGV0IDMgaW4gSmFuYSdzIGxpc3QpIHRvIGFsbG93IG1p ZGRsZWJveGVzIHRvIHNlZSBzZXF1ZW5jaW5nIGluZm9ybWF0aW9uLiBCeSBwaWNraW5nIHRoZSBp bml0aWFsIHJhbmRvbSB2YWx1ZSBtaWRkbGVib3hlcyBjYW5ub3QgYXNzdW1lIGFueSBwYXJ0aWN1 bGFyIHZhbHVlLiBJZiBwYWNrZXQgbnVtYmVyIGxvY2F0aW9uIGFuZCBzaXplIGlzIG5vdCBwYXJ0 IG9mIGludmFyaWFudHMgdGhlbiBpdCBjYW5ub3QgYmUgb3NzaWZpZWQsIG1pZGRsZWJveGVzIHdp bGwgbmVlZCB0byBiZSByZXNpbGllbnQuDQoNClRoaXMgaXMgd2h5IEkgd291bGQgcmF0aGVyIHNl ZSB0aGUgZXhwb3NlZCBiaXRzIGNvcGllZCBhdCBhIGZpeGVkIGxvY2F0aW9uLCB3aGlsZSB0aGUg UE4gaXRzZWxmIGNhbm5vdCBiZSBsb2NhdGVkLiBUaGF0IHdheSwgdGhlIGV4cG9zZWQgYml0cyBj YW4gb3NzaWZ5LCBidXQgdGhlIGFjdHVhbCBQTiBkb2VzIG5vdC4NCg0KV2Ugc3RpbGwgbmVlZCB0 byBiZSB2ZXJ5IGNhcmVmdWwgaGVyZS4gSWYgd2UgZGVjaWRlIHRvIGV4cG9zZSBiaXRzLCB3ZSBt dXN0IG1ha2Ugc3VyZSB0aGF0IGEgbWlkZGxlYm94IGNhbiBvbmx5IGV4dHJhY3QgY29hcnNlLWdy YWluZWQgaW5mb3JtYXRpb24sIGlmIHdlIHdhbnQgdG8gcHJldmVudCBtaWRkbGVib3hlcyBmcm9t IGJ1ZmZlcmluZyBhbmQgZGVsYXlpbmcgcGFja2V0cyBpbiBvcmRlciB0byBmaXggLyByZWR1Y2Ug cmVvcmRlcmluZy4NCkF0IHRoaXMgcG9pbnQgaG93ZXZlciwgSSdtIG5vdCBjb252aW5jZWQgdGhh dCBleHBvc2luZyBhbnkgcmVvcmRlcmluZyBpbmZvcm1hdGlvbiB0byB0aGUgbmV0d29yayBzaG91 bGQgYmUgYSByZXF1aXJlbWVudCBhdCBhbGwuIFRoZXJlJ3MgYSByZWFsIHJpc2sgb2YgbWlzdXNl IG9mIHRoaXMgaW5mb3JtYXRpb24sIGFuZCBvZiBvc3NpZmljYXRpb24gb2Ygd2hhdGV2ZXIgYml0 cyB3ZSBleHBvc2UuDQo= --_000_MWHPR21MB01449EB31E145DC2CFBF7E40B6F20MWHPR21MB0144namp_ 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 aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNv bnNvbGFzO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlucHV0IHRvIHRoZSBub25jZSB3aWxsIGJlIHRoZSB0 cmFuc2Zvcm1lZCB2YWx1ZSBpbiBjbGVhcnRleHQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlrZSBCaXNob3Ag W21haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZV0gPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBGZWJydWFyeSA4LCAyMDE4IDM6MTQgUE08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1 YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0OzsgTWFydGVuIFNlZW1hbm4gJmx0 O21hcnRlbnNlZW1hbm5AZ21haWwuY29tJmd0OzsgaHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1h Lm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+IzIgd29u4oCZdCB3b3JrLiZuYnNwOyBUaGUgcGFja2V0IG51bWJlciBp cyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwgc28geW91IGhhdmUgdG8gZ2V0IHRvIHRoZSBw YWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRlY3J5cHQgdGhlIHBheWxvYWQuJm5ic3A7IEl0 IGNhbuKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcgaW50ZXJuYWwgdG8gdGhlIGVuY3J5cHRlZCBw YWNrZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIE1hcnRpbuKAmXMgcHJvcG9zYWwsIGl0 4oCZcyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mIHRoZSBlbmNyeXB0ZWQgcGF5bG9hZCAod2hpY2gg cmVxdWlyZXMgbm90aGluZyB0byBhY2Nlc3MpIGFuZCBzb21lIHN0b3JlZCBzdGF0ZSBvbiBlYWNo IGVuZHBvaW50LCB3aGljaCByZXF1aXJlcyBvbmx5IHRoZSBDb25uZWN0aW9uIElEIHRvIGxvb2sg dXAuJm5ic3A7IFlvdSB3YW50IHRoZSB0aGluZyB5b3UgWE9SIGJ5IHRvIGJlIGNvbnN0YW50bHkN CiBjaGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNpZXIgdG8gbG9vayBhdCBzZXF1ZW5jZXMgb2Yg b2JmdXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQgc3RhcnQgZHJhd2luZyBpbmZlcmVuY2VzIGFi b3V0IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4mbmJzcDsgSWYgb3ZlcmhlYWQgaXMgdGhlIHByaW1h cnkgY29uY2VybiwgSSB0aGluayB0aGVyZSBhcmUgYSBjb3VwbGUgYXBwcm9hY2hlcyB0aGF0IG1p Z2h0IGFsbG93IHlvdSB0byBwcmVjb21wdXRlIHZhbHVlcw0KIGFuZCBhbW9ydGl6ZSB0aGUgY29z dCBvZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVwLiZuYnNwOyAoQXQgdGhlIGNvc3Qgb2Yga2Vl cGluZyB0aGUgdGFibGUgb2YgcHJlY29tcHV0ZWQgdmFsdWVzLCBvZiBjb3Vyc2UuKTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHN0aWxsIHRoaW5rIEphbmHigJlzIHB1c2hpbmcgaW4gdGhlIHJp Z2h0IGRpcmVjdGlvbiBoZXJlOiZuYnNwOyBMZXTigJlzIGFncmVlIG9uIGdvYWxzLCBhbmQgdGhl biBzZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWduIHRoYXQgbWVldHMgdGhvc2UgZ29hbHMuJm5i c3A7IEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92ZXJoZWFkIGlzIGEgZ29hbCwgd2hpY2gg SSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiZuYnNwOyBJIGFsc28gdGhpbmsNCiBJIGhlYXIg eW91IHNheWluZyB0aGF0IDEtMS41JSBvdmVyaGVhZCBpcyB0b28gaGlnaCwgYnV0IGl0IHNvdW5k cyBsaWtlIHRoZXJl4oCZcyBsZXNzIGFncmVlbWVudCBvbiB0aGF0LiZuYnNwOyBZb3UgYWxzbyBy YWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNvbWUgY2xpZW50cyB3aWxsIGNhcmUgbGVz cyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRoZXkgd2lsbCBuZXZlciBpbnRlbnRpb25hbGx5 IG1pZ3JhdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlByYXZlZW4gQmFsYXN1YnJhbWFuaWFuPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5l c2RheSwgRmVicnVhcnkgNywgMjAxOCA5OjQ0IEFNPGJyPg0KPGI+VG86PC9iPiBNYXJ0ZW4gU2Vl bWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tIj5tYXJ0ZW5z ZWVtYW5uQGdtYWlsLmNvbTwvYT4mZ3Q7OyBodWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVp dGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiA8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Q291cGxlIG9mIHRoaW5ncyB0byBhZGQ6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4xLiBDb25uZWN0aW9uIG1p Z3JhdGlvbiBpcyBhbiBvcHRpb25hbCBwb3J0aW9uIG9mIHRoZSB0cmFuc3BvcnQgYW5kIG5vdCBt YW5kYXRvcnkuIEl0IGRvZXMgbm90IHNlZW0gdG8gYmUgaW5jcmVtZW50YWxseSBkZXBsb3lhYmxl IHdpdGggdG9kYXkncyB1bm1vZGlmaWVkIGxvYWQgYmFsYW5jZXJzLiBNYW55IGRldmljZXMgbWF5 IGFsc28gYmUgc2luZ2xlIGhvbWVkIGFuZCBub3QgaGF2ZSBtdWx0aXBsZSBhY3RpdmUNCiBuZXR3 b3JrIGludGVyZmFjZXMuIEkgYWxzbyB0aGluayB0aGUgYXBwIGFuZCBzeXN0ZW0gc2V0dGluZ3Mg d2lsbCBoYXZlIHRvIG9wdC1pbiB0byBpdCAodG8gcHJldmVudCBhZ2dyZXNzaXZlIHVzYWdlIG9m IG1ldGVyZWQgY2VsbHVsYXIgZGF0YSkuIElmIHRoaXMgaXMgdGhlIGNhc2UsIGNyb3NzLXBhdGgg bGlua2FiaWxpdHkgd2lsbCBiZSBvZiBsaW1pdGVkIGNvbmNlcm4gZm9yIG1hbnkgUVVJQyBjb25u ZWN0aW9ucy4gVGhlcmUgaXMgYWxzbyB0aGUNCiBmYWN0IHRoYXQgcGVyZmVjdCB1bmxpbmthYmls aXR5IHNlZW1zIHRvIGJlIGhhcmQgYWdhaW5zdCBhIG1vdGl2YXRlZCBhZHZlcnNhcnkuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4yLiBJZiBtaWRkbGVib3ggb3NzaWZp Y2F0aW9uIGlzIGEgYmlnIGNvbmNlcm4sIHdlIG1haW5seSBuZWVkIG9iZnVzY2F0aW9uIGFuZCBu b3QgZW5jcnlwdGlvbi4gQW5vdGhlciBvcHRpb24gZm9yIGV4YW1wbGUgd291bGQgYmUgYW4gWE9S IHRyYW5zZm9ybSB3aXRoIHNvbWUgdmFyaWFibGUgZmllbGQgaW4gdGhlIGVuY3J5cHRlZCBwb3J0 aW9uIG9mIHRoZSBwYWNrZXQgKGFzIGFuIGV4YW1wbGUgc2VxdWVuY2UNCiBudW1iZXIgb2YgdGhl IGZpcnN0IHN0cmVhbSBmcmFtZSBpZiBpdCBpcyBwcmVzZW50IG9yIHNvbWUgcmFuZG9tIHBhZCBi eXRlcyB3aGVuIGl0cyBub3QgcHJlc2VudCkuIEkgaG9wZSB3ZSBjYW4gYmUgY3JlYXRpdmUgaGVy ZSB0byByZWR1Y2UgY29tcHV0YXRpb24gY29zdC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBN YXJ0ZW4gU2VlbWFubiBbPGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tIj5t YWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdl ZG5lc2RheSwgRmVicnVhcnkgNywgMjAxOCAxMjowMSBBTTxicj4NCjxiPlRvOjwvYj4gaHVpdGVt YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQiPmh1aXRlbWFAaHVpdGVt YS5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0 OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIj5wcmF2YkBtaWNyb3NvZnQuY29t PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gV2VkLCBGZWIgNywgMjAxOCBhdCAzOjIwIFBNIENocmlzdGlhbiBIdWl0ZW1hICZsdDs8YSBo cmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0 OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIvNi8yMDE4IDg6NTUgUE0sIFByYXZlZW4gQmFsYXN1YnJh bWFuaWFuIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+Rmlyc3QsIHRoZSBw cm9wb3NhbCBkb2VzIG5vdCBvYnNjdXJlIHRoZSBwb3NpdGlvbiBvZiB0aGUgcGFja2V0IG51bWJl ciBmaWVsZCBpbiB0aGUgaGVhZGVyLiBUaGUgZmllbGQgY29udGFpbnMgYSBudW1iZXIgdGhhdCBp bmNyZW1lbnRzIHdpdGggZXZlcnkgcGFja2V0LCBhbmQgaXMgdGh1cyBlYXN5IHRvIGlkZW50aWZ5 LiBUaGlzIG1lYW5zIHRoYXQgbWlkZGxlLWJveGVzIHdpbGwgZ2V0IGFjY3VzdG9tZWQgdG8gc2Vl aW5nIHRoYXQgZmllbGQgYW5kIHRyYWNraW5nIGl0cyBpbmNyZW1lbnRzLjxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPkhlbmNlLCB0aGlzIHNpbXBsZSBvYmZ1c2NhdGlvbiBwcm92aWRlcyBubyBwcm90 ZWN0aW9uIGFnYWluc3Qgb3NzaWZpY2F0aW9uIG9mIHRoZSBwYWNrZXQgbnVtYmVyIGZpZWxkLjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90 ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2VsbCBpdCBzZWVtcyBsaWtlIGl0IGlzIGEgcmVx dWlyZW1lbnQgKHNlZSBidWxsZXQgMyBpbiBKYW5hJ3MgbGlzdCkgdG8gYWxsb3cgbWlkZGxlYm94 ZXMgdG8gc2VlIHNlcXVlbmNpbmcgaW5mb3JtYXRpb24uIEJ5IHBpY2tpbmcgdGhlIGluaXRpYWwg cmFuZG9tIHZhbHVlIG1pZGRsZWJveGVzIGNhbm5vdCBhc3N1bWUgYW55IHBhcnRpY3VsYXIgdmFs dWUuIElmIHBhY2tldCBudW1iZXIgbG9jYXRpb24gYW5kIHNpemUgaXMgbm90IHBhcnQgb2YgaW52 YXJpYW50cyB0aGVuIGl0IGNhbm5vdCBiZSBvc3NpZmllZCwgbWlkZGxlYm94ZXMgd2lsbCBuZWVk IHRvIGJlIHJlc2lsaWVudC4gPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgaXMgd2h5IEkgd291bGQgcmF0aGVyIHNlZSB0aGUgZXhwb3NlZCBi aXRzIGNvcGllZCBhdCBhIGZpeGVkIGxvY2F0aW9uLCB3aGlsZSB0aGUgUE4gaXRzZWxmIGNhbm5v dCBiZSBsb2NhdGVkLiBUaGF0IHdheSwgdGhlIGV4cG9zZWQgYml0cyBjYW4gb3NzaWZ5LCBidXQg dGhlIGFjdHVhbCBQTiBkb2VzIG5vdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugc3RpbGwgbmVlZCB0byBiZSB2 ZXJ5IGNhcmVmdWwgaGVyZS4gSWYgd2UgZGVjaWRlIHRvIGV4cG9zZSBiaXRzLCB3ZSBtdXN0IG1h a2Ugc3VyZSB0aGF0IGEgbWlkZGxlYm94IGNhbiBvbmx5IGV4dHJhY3QgY29hcnNlLWdyYWluZWQg aW5mb3JtYXRpb24sIGlmIHdlIHdhbnQgdG8gcHJldmVudCBtaWRkbGVib3hlcyBmcm9tIGJ1ZmZl cmluZyBhbmQgZGVsYXlpbmcgcGFja2V0cyBpbiBvcmRlciB0byBmaXggLw0KIHJlZHVjZSByZW9y ZGVyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QXQgdGhpcyBwb2ludCBob3dldmVyLCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IGV4cG9zaW5n IGFueSByZW9yZGVyaW5nIGluZm9ybWF0aW9uIHRvIHRoZSBuZXR3b3JrIHNob3VsZCBiZSBhIHJl cXVpcmVtZW50IGF0IGFsbC4gVGhlcmUncyBhIHJlYWwgcmlzayBvZiBtaXN1c2Ugb2YgdGhpcyBp bmZvcm1hdGlvbiwgYW5kIG9mIG9zc2lmaWNhdGlvbiBvZiB3aGF0ZXZlciBiaXRzIHdlIGV4cG9z ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_MWHPR21MB01449EB31E145DC2CFBF7E40B6F20MWHPR21MB0144namp_-- From nobody Thu Feb 8 16:51:58 2018 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 BFA3112DA25 for ; Thu, 8 Feb 2018 16:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-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 (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 xLxrLgsndOWf for ; Thu, 8 Feb 2018 16:51:53 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0106.outbound.protection.outlook.com [104.47.33.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28E3126CD6 for ; Thu, 8 Feb 2018 16:51:52 -0800 (PST) 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=rpjWA8ioS7H/FBILoQZGsKLSReZpjtas75vRKhZHAeA=; b=PXrmgBzyIh+0OYiirNNFa4emwM91h3RCXcMPNNQty/2Ba2Btz4H0imQMsZsI42nshz2VNAAZ4EJc5DHZBI6JI+kWFIfj/2iQ04LkPYiw+QV1Tr4t5GHMU0c7DyIkhesAB23G8q+lTlvEVoV6E6o7R04RyffaC67eOevqd1cx1J0= Received: from MWHPR21MB0144.namprd21.prod.outlook.com (10.173.52.14) by MWHPR21MB0749.namprd21.prod.outlook.com (10.173.51.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.4; Fri, 9 Feb 2018 00:51:49 +0000 Received: from MWHPR21MB0144.namprd21.prod.outlook.com ([10.173.52.14]) by MWHPR21MB0144.namprd21.prod.outlook.com ([10.173.52.14]) with mapi id 15.20.0485.000; Fri, 9 Feb 2018 00:51:49 +0000 From: Praveen Balasubramanian To: Praveen Balasubramanian , Mike Bishop , Marten Seemann , huitema CC: "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAAGbaQgAABKcA= Date: Fri, 9 Feb 2018 00:51:49 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0749; 7:Et5Sm4T7ik50kTt2HYPN7FlBWyqNYr0NPvAiN29jZqkcwHameZT7d0TiqrAhO46xVE6qTWZqEgATyEKG2gigU62PjRzjJ9zC3mCQXdKm9WRBsuwL0/8D8M92xtf1NGtUuoE2RmfpUFypFu/mejJTeh+ZG8HVKtvJ9kNxJgWOJV3Arsi8cAHlICmsSmM49J8Vs7AFEh2KfK3nGUfmwRu4Ab16v4JzDfVV+0+rcwOvSuix/csXFvKCpyV8e63O4c+A x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1fbcb06a-da33-4f3f-ed4a-08d56f574da3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:MWHPR21MB0749; x-ms-traffictypediagnostic: MWHPR21MB0749: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR21MB0749; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0749; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(376002)(346002)(39860400002)(39380400002)(189003)(199004)(377424004)(7736002)(74316002)(39060400002)(5660300001)(19609705001)(6346003)(77096007)(7696005)(8990500004)(86362001)(10090500001)(99286004)(6116002)(790700001)(236005)(55016002)(25786009)(6436002)(2900100001)(9686003)(6306002)(54896002)(229853002)(8676002)(8936002)(3480700004)(7116003)(2950100002)(4326008)(81166006)(81156014)(2940100002)(53936002)(106356001)(97736004)(14454004)(86612001)(59450400001)(76176011)(10290500003)(6246003)(105586002)(561944003)(3280700002)(68736007)(3660700001)(316002)(93886005)(102836004)(6506007)(53546011)(22452003)(110136005)(2906002)(1511001)(478600001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0749; H:MWHPR21MB0144.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: boysRsUJoBwvkKiek9NUsgUCSribENXDIidhGt4zuyHtqq8fisyWWmzLH891cJaDZrzJiqbEMlrhoxT1ZqCGdQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0144D7432CF1ED7A44FC6482B6F20MWHPR21MB0144namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1fbcb06a-da33-4f3f-ed4a-08d56f574da3 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 00:51:49.7259 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0749 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, 09 Feb 2018 00:51:56 -0000 --_000_MWHPR21MB0144D7432CF1ED7A44FC6482B6F20MWHPR21MB0144namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxzbyBJIHRoaW5rIHdlIGFyZSBhbGwgbW9zdGx5IGluIGFncmVlbWVudCB3aXRoIHRoZSBnb2Fs cyBKYW5hIHN0YXRlZC4gSSB3YXMgc2ltcGx5IHRyeWluZyB0byBmaW5kIGEgbGVzcyBjb21wdXRl IGludGVuc2l2ZSBzb2x1dGlvbi4gWWVzIG1pZ3JhdGlvbiBpcyBub3QgdW5pdmVyc2FsbHkgYXBw bGljYWJsZSB0byBhbGwgZGV2aWNlcyBvciBjb25uZWN0aW9ucyBhbmQgaXMgbm90IGEgbWFuZGF0 b3J5IHBhcnQgb2YgdGhlIHRyYW5zcG9ydCBzbyB0aGUgbGVzcyBhbnkgb3ZlcmhlYWQgbmVlZGVk IGZvciB1bmxpbmthYmlsaXR5IGJ5IGRlZmF1bHQgdGhlIGJldHRlci4NCg0KRnJvbTogUVVJQyBb bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFByYXZlZW4gQmFsYXN1 YnJhbWFuaWFuDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCA0OjQ2IFBNDQpUbzog TWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPjsgTWFydGVuIFNlZW1hbm4gPG1hcnRl bnNlZW1hbm5AZ21haWwuY29tPjsgaHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4NCkNjOiBx dWljQGlldGYub3JnDQpTdWJqZWN0OiBSRTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNClRo ZSBpbnB1dCB0byB0aGUgbm9uY2Ugd2lsbCBiZSB0aGUgdHJhbnNmb3JtZWQgdmFsdWUgaW4gY2xl YXJ0ZXh0Lg0KDQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJl XQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggMzoxNCBQTQ0KVG86IFByYXZlZW4g QmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3Nv ZnQuY29tPj47IE1hcnRlbiBTZWVtYW5uIDxtYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTxtYWlsdG86 bWFydGVuc2VlbWFubkBnbWFpbC5jb20+PjsgaHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxt YWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+DQpDYzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVp Y0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KIzIg d29u4oCZdCB3b3JrLiAgVGhlIHBhY2tldCBudW1iZXIgaXMgYW4gaW5wdXQgdG8gdGhlIEFFQUQg bm9uY2UsIHNvIHlvdSBoYXZlIHRvIGdldCB0byB0aGUgcGFja2V0IG51bWJlciBiZWZvcmUgeW91 IGNhbiBkZWNyeXB0IHRoZSBwYXlsb2FkLiAgSXQgY2Fu4oCZdCBiZSBiYXNlZCBvbiBhbnl0aGlu ZyBpbnRlcm5hbCB0byB0aGUgZW5jcnlwdGVkIHBhY2tldC4NCg0KSW4gTWFydGlu4oCZcyBwcm9w b3NhbCwgaXTigJlzIHVzaW5nIGEgY29tYmluYXRpb24gb2YgdGhlIGVuY3J5cHRlZCBwYXlsb2Fk ICh3aGljaCByZXF1aXJlcyBub3RoaW5nIHRvIGFjY2VzcykgYW5kIHNvbWUgc3RvcmVkIHN0YXRl IG9uIGVhY2ggZW5kcG9pbnQsIHdoaWNoIHJlcXVpcmVzIG9ubHkgdGhlIENvbm5lY3Rpb24gSUQg dG8gbG9vayB1cC4gIFlvdSB3YW50IHRoZSB0aGluZyB5b3UgWE9SIGJ5IHRvIGJlIGNvbnN0YW50 bHkgY2hhbmdpbmcsIG9yIGl0IGJlY29tZXMgZWFzaWVyIHRvIGxvb2sgYXQgc2VxdWVuY2VzIG9m IG9iZnVzY2F0ZWQgcGFja2V0IG51bWJlcnMgYW5kIHN0YXJ0IGRyYXdpbmcgaW5mZXJlbmNlcyBh Ym91dCB3aGF0IHRoZSBYT1IgdmFsdWUgaXMuICBJZiBvdmVyaGVhZCBpcyB0aGUgcHJpbWFyeSBj b25jZXJuLCBJIHRoaW5rIHRoZXJlIGFyZSBhIGNvdXBsZSBhcHByb2FjaGVzIHRoYXQgbWlnaHQg YWxsb3cgeW91IHRvIHByZWNvbXB1dGUgdmFsdWVzIGFuZCBhbW9ydGl6ZSB0aGUgY29zdCBvZiBk b2luZyB0aGUgZW5jcnlwdGlvbiBzdGVwLiAgKEF0IHRoZSBjb3N0IG9mIGtlZXBpbmcgdGhlIHRh YmxlIG9mIHByZWNvbXB1dGVkIHZhbHVlcywgb2YgY291cnNlLikNCg0KSSBzdGlsbCB0aGluayBK YW5h4oCZcyBwdXNoaW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24gaGVyZTogIExldOKAmXMgYWdy ZWUgb24gZ29hbHMsIGFuZCB0aGVuIHNlZSBpZiB3ZSBjYW4gY3JhZnQgYSBkZXNpZ24gdGhhdCBt ZWV0cyB0aG9zZSBnb2Fscy4gIEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92ZXJoZWFkIGlz IGEgZ29hbCwgd2hpY2ggSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiAgSSBhbHNvIHRoaW5r IEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgMS0xLjUlIG92ZXJoZWFkIGlzIHRvbyBoaWdoLCBidXQg aXQgc291bmRzIGxpa2UgdGhlcmXigJlzIGxlc3MgYWdyZWVtZW50IG9uIHRoYXQuICBZb3UgYWxz byByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNvbWUgY2xpZW50cyB3aWxsIGNhcmUg bGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRoZXkgd2lsbCBuZXZlciBpbnRlbnRpb25h bGx5IG1pZ3JhdGUuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2VudDogV2VkbmVzZGF5LCBG ZWJydWFyeSA3LCAyMDE4IDk6NDQgQU0NClRvOiBNYXJ0ZW4gU2VlbWFubiA8bWFydGVuc2VlbWFu bkBnbWFpbC5jb208bWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29tPj47IGh1aXRlbWEgPGh1 aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+Pg0KQ2M6IHF1aWNA aWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogUGFja2V0IG51bWJl ciBlbmNyeXB0aW9uDQoNCg0KQ291cGxlIG9mIHRoaW5ncyB0byBhZGQ6DQoNCjEuIENvbm5lY3Rp b24gbWlncmF0aW9uIGlzIGFuIG9wdGlvbmFsIHBvcnRpb24gb2YgdGhlIHRyYW5zcG9ydCBhbmQg bm90IG1hbmRhdG9yeS4gSXQgZG9lcyBub3Qgc2VlbSB0byBiZSBpbmNyZW1lbnRhbGx5IGRlcGxv eWFibGUgd2l0aCB0b2RheSdzIHVubW9kaWZpZWQgbG9hZCBiYWxhbmNlcnMuIE1hbnkgZGV2aWNl cyBtYXkgYWxzbyBiZSBzaW5nbGUgaG9tZWQgYW5kIG5vdCBoYXZlIG11bHRpcGxlIGFjdGl2ZSBu ZXR3b3JrIGludGVyZmFjZXMuIEkgYWxzbyB0aGluayB0aGUgYXBwIGFuZCBzeXN0ZW0gc2V0dGlu Z3Mgd2lsbCBoYXZlIHRvIG9wdC1pbiB0byBpdCAodG8gcHJldmVudCBhZ2dyZXNzaXZlIHVzYWdl IG9mIG1ldGVyZWQgY2VsbHVsYXIgZGF0YSkuIElmIHRoaXMgaXMgdGhlIGNhc2UsIGNyb3NzLXBh dGggbGlua2FiaWxpdHkgd2lsbCBiZSBvZiBsaW1pdGVkIGNvbmNlcm4gZm9yIG1hbnkgUVVJQyBj b25uZWN0aW9ucy4gVGhlcmUgaXMgYWxzbyB0aGUgZmFjdCB0aGF0IHBlcmZlY3QgdW5saW5rYWJp bGl0eSBzZWVtcyB0byBiZSBoYXJkIGFnYWluc3QgYSBtb3RpdmF0ZWQgYWR2ZXJzYXJ5Lg0KDQoy LiBJZiBtaWRkbGVib3ggb3NzaWZpY2F0aW9uIGlzIGEgYmlnIGNvbmNlcm4sIHdlIG1haW5seSBu ZWVkIG9iZnVzY2F0aW9uIGFuZCBub3QgZW5jcnlwdGlvbi4gQW5vdGhlciBvcHRpb24gZm9yIGV4 YW1wbGUgd291bGQgYmUgYW4gWE9SIHRyYW5zZm9ybSB3aXRoIHNvbWUgdmFyaWFibGUgZmllbGQg aW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBwYWNrZXQgKGFzIGFuIGV4YW1wbGUgc2Vx dWVuY2UgbnVtYmVyIG9mIHRoZSBmaXJzdCBzdHJlYW0gZnJhbWUgaWYgaXQgaXMgcHJlc2VudCBv ciBzb21lIHJhbmRvbSBwYWQgYnl0ZXMgd2hlbiBpdHMgbm90IHByZXNlbnQpLiBJIGhvcGUgd2Ug Y2FuIGJlIGNyZWF0aXZlIGhlcmUgdG8gcmVkdWNlIGNvbXB1dGF0aW9uIGNvc3QuDQoNCg0KRnJv bTogTWFydGVuIFNlZW1hbm4gW21haWx0bzptYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgNywgMjAxOCAxMjowMSBBTQ0KVG86IGh1aXRlbWEgPGh1aXRl bWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+Pg0KQ2M6IFByYXZlZW4g QmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3Nv ZnQuY29tPj47IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCg0KT24gV2VkLCBGZWIgNywgMjAxOCBhdCAz OjIwIFBNIENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0 ZW1hQGh1aXRlbWEubmV0Pj4gd3JvdGU6DQoNCg0KDQpPbiAyLzYvMjAxOCA4OjU1IFBNLCBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiB3cm90ZToNCg0KRmlyc3QsIHRoZSBwcm9wb3NhbCBkb2VzIG5v dCBvYnNjdXJlIHRoZSBwb3NpdGlvbiBvZiB0aGUgcGFja2V0IG51bWJlciBmaWVsZCBpbiB0aGUg aGVhZGVyLiBUaGUgZmllbGQgY29udGFpbnMgYSBudW1iZXIgdGhhdCBpbmNyZW1lbnRzIHdpdGgg ZXZlcnkgcGFja2V0LCBhbmQgaXMgdGh1cyBlYXN5IHRvIGlkZW50aWZ5LiBUaGlzIG1lYW5zIHRo YXQgbWlkZGxlLWJveGVzIHdpbGwgZ2V0IGFjY3VzdG9tZWQgdG8gc2VlaW5nIHRoYXQgZmllbGQg YW5kIHRyYWNraW5nIGl0cyBpbmNyZW1lbnRzLg0KDQpIZW5jZSwgdGhpcyBzaW1wbGUgb2JmdXNj YXRpb24gcHJvdmlkZXMgbm8gcHJvdGVjdGlvbiBhZ2FpbnN0IG9zc2lmaWNhdGlvbiBvZiB0aGUg cGFja2V0IG51bWJlciBmaWVsZC4NCg0KDQoNCldlbGwgaXQgc2VlbXMgbGlrZSBpdCBpcyBhIHJl cXVpcmVtZW50IChzZWUgYnVsbGV0IDMgaW4gSmFuYSdzIGxpc3QpIHRvIGFsbG93IG1pZGRsZWJv eGVzIHRvIHNlZSBzZXF1ZW5jaW5nIGluZm9ybWF0aW9uLiBCeSBwaWNraW5nIHRoZSBpbml0aWFs IHJhbmRvbSB2YWx1ZSBtaWRkbGVib3hlcyBjYW5ub3QgYXNzdW1lIGFueSBwYXJ0aWN1bGFyIHZh bHVlLiBJZiBwYWNrZXQgbnVtYmVyIGxvY2F0aW9uIGFuZCBzaXplIGlzIG5vdCBwYXJ0IG9mIGlu dmFyaWFudHMgdGhlbiBpdCBjYW5ub3QgYmUgb3NzaWZpZWQsIG1pZGRsZWJveGVzIHdpbGwgbmVl ZCB0byBiZSByZXNpbGllbnQuDQoNClRoaXMgaXMgd2h5IEkgd291bGQgcmF0aGVyIHNlZSB0aGUg ZXhwb3NlZCBiaXRzIGNvcGllZCBhdCBhIGZpeGVkIGxvY2F0aW9uLCB3aGlsZSB0aGUgUE4gaXRz ZWxmIGNhbm5vdCBiZSBsb2NhdGVkLiBUaGF0IHdheSwgdGhlIGV4cG9zZWQgYml0cyBjYW4gb3Nz aWZ5LCBidXQgdGhlIGFjdHVhbCBQTiBkb2VzIG5vdC4NCg0KV2Ugc3RpbGwgbmVlZCB0byBiZSB2 ZXJ5IGNhcmVmdWwgaGVyZS4gSWYgd2UgZGVjaWRlIHRvIGV4cG9zZSBiaXRzLCB3ZSBtdXN0IG1h a2Ugc3VyZSB0aGF0IGEgbWlkZGxlYm94IGNhbiBvbmx5IGV4dHJhY3QgY29hcnNlLWdyYWluZWQg aW5mb3JtYXRpb24sIGlmIHdlIHdhbnQgdG8gcHJldmVudCBtaWRkbGVib3hlcyBmcm9tIGJ1ZmZl cmluZyBhbmQgZGVsYXlpbmcgcGFja2V0cyBpbiBvcmRlciB0byBmaXggLyByZWR1Y2UgcmVvcmRl cmluZy4NCkF0IHRoaXMgcG9pbnQgaG93ZXZlciwgSSdtIG5vdCBjb252aW5jZWQgdGhhdCBleHBv c2luZyBhbnkgcmVvcmRlcmluZyBpbmZvcm1hdGlvbiB0byB0aGUgbmV0d29yayBzaG91bGQgYmUg YSByZXF1aXJlbWVudCBhdCBhbGwuIFRoZXJlJ3MgYSByZWFsIHJpc2sgb2YgbWlzdXNlIG9mIHRo aXMgaW5mb3JtYXRpb24sIGFuZCBvZiBvc3NpZmljYXRpb24gb2Ygd2hhdGV2ZXIgYml0cyB3ZSBl eHBvc2UuDQo= --_000_MWHPR21MB0144D7432CF1ED7A44FC6482B6F20MWHPR21MB0144namp_ 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 aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNv bnNvbGFzO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4g VGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbHNvIEkgdGhpbmsgd2UgYXJlIGFsbCBtb3N0bHkgaW4gYWdyZWVtZW50IHdp dGggdGhlIGdvYWxzIEphbmEgc3RhdGVkLiBJIHdhcyBzaW1wbHkgdHJ5aW5nIHRvIGZpbmQgYSBs ZXNzIGNvbXB1dGUgaW50ZW5zaXZlIHNvbHV0aW9uLiBZZXMgbWlncmF0aW9uIGlzIG5vdCB1bml2 ZXJzYWxseSBhcHBsaWNhYmxlIHRvIGFsbCBkZXZpY2VzIG9yIGNvbm5lY3Rpb25zIGFuZCBpcyBu b3QgYSBtYW5kYXRvcnkgcGFydA0KIG9mIHRoZSB0cmFuc3BvcnQgc28gdGhlIGxlc3MgYW55IG92 ZXJoZWFkIG5lZWRlZCBmb3IgdW5saW5rYWJpbGl0eSBieSBkZWZhdWx0IHRoZSBiZXR0ZXIuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBC ZWhhbGYgT2YNCjwvYj5QcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCA0OjQ2IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEJp c2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7OyBNYXJ0ZW4gU2VlbWFubiAmbHQ7bWFy dGVuc2VlbWFubkBnbWFpbC5jb20mZ3Q7OyBodWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0 Jmd0Ozxicj4NCjxiPkNjOjwvYj4gcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS RTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGUgaW5wdXQgdG8gdGhlIG5vbmNlIHdpbGwgYmUgdGhlIHRyYW5zZm9ybWVk IHZhbHVlIGluIGNsZWFydGV4dC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBNaWtlIEJpc2hvcCBbPGEgaHJlZj0i bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIj5tYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU8 L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDM6MTQg UE08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJt YWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbSI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7OyBN YXJ0ZW4gU2VlbWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNlZW1hbm5AZ21haWwuY29t Ij5tYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTwvYT4mZ3Q7OyBodWl0ZW1hICZsdDs8YSBocmVmPSJt YWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IzIgd29u4oCZdCB3b3JrLiZu YnNwOyBUaGUgcGFja2V0IG51bWJlciBpcyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwgc28g eW91IGhhdmUgdG8gZ2V0IHRvIHRoZSBwYWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRlY3J5 cHQgdGhlIHBheWxvYWQuJm5ic3A7IEl0IGNhbuKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcgaW50 ZXJuYWwgdG8gdGhlIGVuY3J5cHRlZCBwYWNrZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu IE1hcnRpbuKAmXMgcHJvcG9zYWwsIGl04oCZcyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mIHRoZSBl bmNyeXB0ZWQgcGF5bG9hZCAod2hpY2ggcmVxdWlyZXMgbm90aGluZyB0byBhY2Nlc3MpIGFuZCBz b21lIHN0b3JlZCBzdGF0ZSBvbiBlYWNoIGVuZHBvaW50LCB3aGljaCByZXF1aXJlcyBvbmx5IHRo ZSBDb25uZWN0aW9uIElEIHRvIGxvb2sgdXAuJm5ic3A7IFlvdSB3YW50IHRoZSB0aGluZyB5b3Ug WE9SIGJ5IHRvIGJlIGNvbnN0YW50bHkNCiBjaGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNpZXIg dG8gbG9vayBhdCBzZXF1ZW5jZXMgb2Ygb2JmdXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQgc3Rh cnQgZHJhd2luZyBpbmZlcmVuY2VzIGFib3V0IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4mbmJzcDsg SWYgb3ZlcmhlYWQgaXMgdGhlIHByaW1hcnkgY29uY2VybiwgSSB0aGluayB0aGVyZSBhcmUgYSBj b3VwbGUgYXBwcm9hY2hlcyB0aGF0IG1pZ2h0IGFsbG93IHlvdSB0byBwcmVjb21wdXRlIHZhbHVl cw0KIGFuZCBhbW9ydGl6ZSB0aGUgY29zdCBvZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVwLiZu YnNwOyAoQXQgdGhlIGNvc3Qgb2Yga2VlcGluZyB0aGUgdGFibGUgb2YgcHJlY29tcHV0ZWQgdmFs dWVzLCBvZiBjb3Vyc2UuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0aWxsIHRoaW5rIEph bmHigJlzIHB1c2hpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBoZXJlOiZuYnNwOyBMZXTigJlz IGFncmVlIG9uIGdvYWxzLCBhbmQgdGhlbiBzZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWduIHRo YXQgbWVldHMgdGhvc2UgZ29hbHMuJm5ic3A7IEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92 ZXJoZWFkIGlzIGEgZ29hbCwgd2hpY2ggSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiZuYnNw OyBJIGFsc28gdGhpbmsNCiBJIGhlYXIgeW91IHNheWluZyB0aGF0IDEtMS41JSBvdmVyaGVhZCBp cyB0b28gaGlnaCwgYnV0IGl0IHNvdW5kcyBsaWtlIHRoZXJl4oCZcyBsZXNzIGFncmVlbWVudCBv biB0aGF0LiZuYnNwOyBZb3UgYWxzbyByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNv bWUgY2xpZW50cyB3aWxsIGNhcmUgbGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRoZXkg d2lsbCBuZXZlciBpbnRlbnRpb25hbGx5IG1pZ3JhdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbPGEg aHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnF1aWMtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlByYXZlZW4gQmFsYXN1YnJhbWFuaWFu PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgNywgMjAxOCA5OjQ0IEFNPGJy Pg0KPGI+VG86PC9iPiBNYXJ0ZW4gU2VlbWFubiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRlbnNl ZW1hbm5AZ21haWwuY29tIj5tYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbTwvYT4mZ3Q7OyBodWl0ZW1h ICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1h Lm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9y ZyI+cXVpY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFBhY2tldCBudW1i ZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Q291cGxlIG9mIHRoaW5ncyB0byBhZGQ6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4xLiBDb25uZWN0aW9uIG1pZ3JhdGlvbiBpcyBhbiBvcHRpb25hbCBwb3J0aW9uIG9m IHRoZSB0cmFuc3BvcnQgYW5kIG5vdCBtYW5kYXRvcnkuIEl0IGRvZXMgbm90IHNlZW0gdG8gYmUg aW5jcmVtZW50YWxseSBkZXBsb3lhYmxlIHdpdGggdG9kYXkncyB1bm1vZGlmaWVkIGxvYWQgYmFs YW5jZXJzLiBNYW55IGRldmljZXMgbWF5IGFsc28gYmUgc2luZ2xlIGhvbWVkIGFuZCBub3QgaGF2 ZSBtdWx0aXBsZSBhY3RpdmUNCiBuZXR3b3JrIGludGVyZmFjZXMuIEkgYWxzbyB0aGluayB0aGUg YXBwIGFuZCBzeXN0ZW0gc2V0dGluZ3Mgd2lsbCBoYXZlIHRvIG9wdC1pbiB0byBpdCAodG8gcHJl dmVudCBhZ2dyZXNzaXZlIHVzYWdlIG9mIG1ldGVyZWQgY2VsbHVsYXIgZGF0YSkuIElmIHRoaXMg aXMgdGhlIGNhc2UsIGNyb3NzLXBhdGggbGlua2FiaWxpdHkgd2lsbCBiZSBvZiBsaW1pdGVkIGNv bmNlcm4gZm9yIG1hbnkgUVVJQyBjb25uZWN0aW9ucy4gVGhlcmUgaXMgYWxzbyB0aGUNCiBmYWN0 IHRoYXQgcGVyZmVjdCB1bmxpbmthYmlsaXR5IHNlZW1zIHRvIGJlIGhhcmQgYWdhaW5zdCBhIG1v dGl2YXRlZCBhZHZlcnNhcnkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4yLiBJZiBtaWRkbGVib3ggb3NzaWZpY2F0aW9uIGlzIGEgYmlnIGNvbmNlcm4sIHdlIG1haW5s eSBuZWVkIG9iZnVzY2F0aW9uIGFuZCBub3QgZW5jcnlwdGlvbi4gQW5vdGhlciBvcHRpb24gZm9y IGV4YW1wbGUgd291bGQgYmUgYW4gWE9SIHRyYW5zZm9ybSB3aXRoIHNvbWUgdmFyaWFibGUgZmll bGQgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBwYWNrZXQgKGFzIGFuIGV4YW1wbGUg c2VxdWVuY2UNCiBudW1iZXIgb2YgdGhlIGZpcnN0IHN0cmVhbSBmcmFtZSBpZiBpdCBpcyBwcmVz ZW50IG9yIHNvbWUgcmFuZG9tIHBhZCBieXRlcyB3aGVuIGl0cyBub3QgcHJlc2VudCkuIEkgaG9w ZSB3ZSBjYW4gYmUgY3JlYXRpdmUgaGVyZSB0byByZWR1Y2UgY29tcHV0YXRpb24gY29zdC4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBNYXJ0ZW4gU2VlbWFubiBbPGEgaHJlZj0ibWFpbHRvOm1h cnRlbnNlZW1hbm5AZ21haWwuY29tIj5tYWlsdG86bWFydGVuc2VlbWFubkBnbWFpbC5jb208L2E+ XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgNywgMjAxOCAxMjowMSBB TTxicj4NCjxiPlRvOjwvYj4gaHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVp dGVtYS5uZXQiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUHJh dmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQu Y29tIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86cXVpY0Bp ZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tl dCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgNywgMjAxOCBhdCAzOjIwIFBNIENo cmlzdGlhbiBIdWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+ aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8cD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIvNi8yMDE4IDg6 NTUgUE0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwcmU+Rmlyc3QsIHRoZSBwcm9wb3NhbCBkb2VzIG5vdCBvYnNjdXJlIHRoZSBwb3Np dGlvbiBvZiB0aGUgcGFja2V0IG51bWJlciBmaWVsZCBpbiB0aGUgaGVhZGVyLiBUaGUgZmllbGQg Y29udGFpbnMgYSBudW1iZXIgdGhhdCBpbmNyZW1lbnRzIHdpdGggZXZlcnkgcGFja2V0LCBhbmQg aXMgdGh1cyBlYXN5IHRvIGlkZW50aWZ5LiBUaGlzIG1lYW5zIHRoYXQgbWlkZGxlLWJveGVzIHdp bGwgZ2V0IGFjY3VzdG9tZWQgdG8gc2VlaW5nIHRoYXQgZmllbGQgYW5kIHRyYWNraW5nIGl0cyBp bmNyZW1lbnRzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkhlbmNlLCB0aGlzIHNpbXBsZSBvYmZ1 c2NhdGlvbiBwcm92aWRlcyBubyBwcm90ZWN0aW9uIGFnYWluc3Qgb3NzaWZpY2F0aW9uIG9mIHRo ZSBwYWNrZXQgbnVtYmVyIGZpZWxkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2VsbCBp dCBzZWVtcyBsaWtlIGl0IGlzIGEgcmVxdWlyZW1lbnQgKHNlZSBidWxsZXQgMyBpbiBKYW5hJ3Mg bGlzdCkgdG8gYWxsb3cgbWlkZGxlYm94ZXMgdG8gc2VlIHNlcXVlbmNpbmcgaW5mb3JtYXRpb24u IEJ5IHBpY2tpbmcgdGhlIGluaXRpYWwgcmFuZG9tIHZhbHVlIG1pZGRsZWJveGVzIGNhbm5vdCBh c3N1bWUgYW55IHBhcnRpY3VsYXIgdmFsdWUuIElmIHBhY2tldCBudW1iZXIgbG9jYXRpb24gYW5k IHNpemUgaXMgbm90IHBhcnQgb2YgaW52YXJpYW50cyB0aGVuIGl0IGNhbm5vdCBiZSBvc3NpZmll ZCwgbWlkZGxlYm94ZXMgd2lsbCBuZWVkIHRvIGJlIHJlc2lsaWVudC4gPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgd2h5IEkgd291bGQg cmF0aGVyIHNlZSB0aGUgZXhwb3NlZCBiaXRzIGNvcGllZCBhdCBhIGZpeGVkIGxvY2F0aW9uLCB3 aGlsZSB0aGUgUE4gaXRzZWxmIGNhbm5vdCBiZSBsb2NhdGVkLiBUaGF0IHdheSwgdGhlIGV4cG9z ZWQgYml0cyBjYW4gb3NzaWZ5LCBidXQgdGhlIGFjdHVhbCBQTiBkb2VzIG5vdC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2Ugc3RpbGwgbmVlZCB0byBiZSB2ZXJ5IGNhcmVmdWwgaGVyZS4gSWYgd2UgZGVjaWRlIHRv IGV4cG9zZSBiaXRzLCB3ZSBtdXN0IG1ha2Ugc3VyZSB0aGF0IGEgbWlkZGxlYm94IGNhbiBvbmx5 IGV4dHJhY3QgY29hcnNlLWdyYWluZWQgaW5mb3JtYXRpb24sIGlmIHdlIHdhbnQgdG8gcHJldmVu dCBtaWRkbGVib3hlcyBmcm9tIGJ1ZmZlcmluZyBhbmQgZGVsYXlpbmcgcGFja2V0cyBpbiBvcmRl ciB0byBmaXggLw0KIHJlZHVjZSByZW9yZGVyaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgdGhpcyBwb2ludCBob3dldmVyLCBJJ20gbm90 IGNvbnZpbmNlZCB0aGF0IGV4cG9zaW5nIGFueSByZW9yZGVyaW5nIGluZm9ybWF0aW9uIHRvIHRo ZSBuZXR3b3JrIHNob3VsZCBiZSBhIHJlcXVpcmVtZW50IGF0IGFsbC4gVGhlcmUncyBhIHJlYWwg cmlzayBvZiBtaXN1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiwgYW5kIG9mIG9zc2lmaWNhdGlvbiBv ZiB3aGF0ZXZlciBiaXRzIHdlIGV4cG9zZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR21MB0144D7432CF1ED7A44FC6482B6F20MWHPR21MB0144namp_-- From nobody Thu Feb 8 17:09:23 2018 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 C5D0A120724 for ; Thu, 8 Feb 2018 17:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 gFZFftToeq7k for ; Thu, 8 Feb 2018 17:09:20 -0800 (PST) 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 05D84124239 for ; Thu, 8 Feb 2018 17:09:19 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id l11so845181ywh.2 for ; Thu, 08 Feb 2018 17:09:19 -0800 (PST) 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=mF6yiVpOLhoppBhRFU+Gxj6CNvixzvsOpQy+RLGa3ew=; b=Sr4K8dW3uIFkuBJauN/AGh00zxkrZ7orf0K6xsobYf4g7NY1mwxnXbaei6Jm92Elqg onQ53gTUqujxPa38WLKsLNBJeX8jA92UK0cyx9ysXspuI7HwkHXEgQGMXkRjJSoQgZno 1nZ2hVqkClK5gont1qJe29D2YyOAyshC/yMjZcK+FDYrt/TZSz/u1tp50a2KSDGEXXL4 5pKaQmnNVxFAWd3xNdBae0dBumVNw9bU6spCPlrNTSBTYu36ZBTpdkWDiYLsdtuyYYXS TJqhC6+fiU4b8qeKivxY6BIOvI2rfLPKtjXqi8S6PuZwPeuXBtPt5mXoiUuoZR00U++w OhNA== 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=mF6yiVpOLhoppBhRFU+Gxj6CNvixzvsOpQy+RLGa3ew=; b=uZLp1BdUPVjomMOP1KmuRHXmpjVDF9cjFcGYN6cOTmu7ThkXYVjWurZDLfBk5k/SSr jzGouUCN4yRLejI/tkRdMT1TB/n1kGuH62S6ocRttwHkIGzhOdAitw14GatWqI8X5n3o HkbApMStVfDLdoPdoD/wrOU1D9SV5BDi33w7ruFFVSp/8w54kl/FPRUmspQa8208oKnS F5YC1kh/VdD4kUt3UvKZK9nVUDT2ifOpL1pwyvlSzX73CZ75f8nRdzVebI2jIwbDmnOa Zu6PqvWAXl8AmSCWSGIFnqcVodSlHMOZt73oZ/xhYnVWSJX089L/9No+/8T0Cw/wlQbS pQlg== X-Gm-Message-State: APf1xPDKdmooUWP3CKvMixorPLQ0UBZioUZGMQULkM+DuCr519fjWxpL wxRivvnFyGblWI5u9AIKOvqSwn+wSKWm+xnZiq5MplF7 X-Google-Smtp-Source: AH8x226dGhFobRj1N+oukvW067N3C5WdXoLwQuOsCnonjkDmi7+q99QCNtO3bAP3u6SA+recspPgpv33SLKn6WVy4B4= X-Received: by 10.129.68.40 with SMTP id r40mr746285ywa.371.1518138558919; Thu, 08 Feb 2018 17:09:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Thu, 8 Feb 2018 17:09:18 -0800 (PST) In-Reply-To: References: <151809506296.17228.17281018611304930059@ietfa.amsl.com> <6203282A-CD65-4049-A499-DED34431E912@mnot.net> From: Jana Iyengar Date: Thu, 8 Feb 2018 17:09:18 -0800 Message-ID: Subject: Re: QUIC (quic) WG Interim Meeting: 2018-06-06 To: Daniel Stenberg Cc: Mark Nottingham , Lars Eggert , QUIC WG Content-Type: multipart/alternative; boundary="f403045ed28c86bdac0564bd2d92" 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, 09 Feb 2018 01:09:22 -0000 --f403045ed28c86bdac0564bd2d92 Content-Type: text/plain; charset="UTF-8" This may be worth clarifying, since I was briefly confused at first, and at least one other person missed this detail: The email says Europe/Berlin for timezone, but the location is actually Kista, Sweden. (This is clear if you read the email carefully or if you get to the arrangements page, but clicking on a link can be hard sometimes :-)) On Thu, Feb 8, 2018 at 3:10 PM, Daniel Stenberg wrote: > On Fri, 9 Feb 2018, Mark Nottingham wrote: > > Registration is now open; see the arrangements page. Please note the >> guidelines for attendance there. >> > > I noticed a little mistake: the arrangements page says registration closes > on June 3rd, while the google forms page says May 3rd... > > -- > > / daniel.haxx.se > > --f403045ed28c86bdac0564bd2d92 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This may be worth clarifying, since I was briefly con= fused at first, and at least one other person missed this detail: The email= says Europe/Berlin for timezone, but the location is actually Kista, Swede= n.
(This is clear if you read the email carefully or if you get t= o the arrangements page, but clicking on a link can be hard sometimes :-))<= /div>


On Thu, Feb 8, 2018 at 3:10 PM, Daniel Stenberg = <daniel@haxx.se&= gt; wrote:
On Fri= , 9 Feb 2018, Mark Nottingham wrote:

Registration is now open; see the arrangements page. Please note the guidel= ines for attendance there.

 I noticed a little mistake: the arrangements page says registration closes = on June 3rd, while the google forms page says May 3rd...

--

=C2=A0/ daniel.haxx.se


--f403045ed28c86bdac0564bd2d92-- From nobody Thu Feb 8 17:50:55 2018 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 5A17D120721 for ; Thu, 8 Feb 2018 17:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 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=-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=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 3F_Om6D5mTWn for ; Thu, 8 Feb 2018 17:50:49 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0119.outbound.protection.outlook.com [104.47.37.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCC78124207 for ; Thu, 8 Feb 2018 17:50:48 -0800 (PST) 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=dsvtKBeZI1+BIB+qQux92bgYwJ1Cj+YSOpHw8SkFbl0=; b=hsxu81lD2Ywc0C3Xo1s36OWJu/l36oukWbHgO6TaBBViKGA0TFD1qV3/Kj/1kpcJxnfkj9BiYruSdlHc89t6iHZqer6Fz+I8//mIlWeqfSvXPC7v9flh8ewIYVRovy6SlUthGQJZJvuu03JsaRS0/pMBF0ZiHAOAgyIP7ExHCKg= Received: from MWHPR21MB0144.namprd21.prod.outlook.com (10.173.52.14) by MWHPR21MB0640.namprd21.prod.outlook.com (10.175.141.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Fri, 9 Feb 2018 01:50:47 +0000 Received: from MWHPR21MB0144.namprd21.prod.outlook.com ([10.173.52.14]) by MWHPR21MB0144.namprd21.prod.outlook.com ([10.173.52.14]) with mapi id 15.20.0485.000; Fri, 9 Feb 2018 01:50:47 +0000 From: Praveen Balasubramanian To: huitema , "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3A= Date: Fri, 9 Feb 2018 01:50:46 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0640; 7:oyWSnMts0gVmNcTGagCNhGT4K/tzIqEv6I5F5eU/tglcaIlkcmxQ0ukHiHleb+tCnzuOx5G0W7d7ACeiaaSDwzgOGA1xcSHygNdM2iLaCXyYsvgj/L9kNwFauX6fMqLxZKhlkk1AXhmRz7foftA+okUII10D5RF7umCkThU08K9AGAPS/GJzMSpfoMIgPX330S2kCbl2hbYO3AYUw5/8axYzDUAflRs7PPxi+M6m4C3ZmjyWqH1LFz+LyNx5/jhP x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0c5a5a2d-bb20-433d-f1be-08d56f5f8a21 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:MWHPR21MB0640; x-ms-traffictypediagnostic: MWHPR21MB0640: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR21MB0640; BCL:0; PCL:0; RULEID:; SRVR:MWHPR21MB0640; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(39380400002)(366004)(346002)(396003)(377424004)(199004)(189003)(93886005)(6436002)(6116002)(790700001)(229853002)(77096007)(9686003)(2900100001)(106356001)(8990500004)(54896002)(6306002)(25786009)(316002)(6246003)(97736004)(55016002)(10090500001)(110136005)(3660700001)(5660300001)(7116003)(3280700002)(2950100002)(7696005)(561944003)(33656002)(99286004)(186003)(2906002)(76176011)(7736002)(10290500003)(53936002)(86612001)(102836004)(6346003)(86362001)(14454004)(81156014)(22452003)(478600001)(74316002)(2501003)(53546011)(59450400001)(8936002)(6506007)(105586002)(8676002)(81166006)(3480700004)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0640; H:MWHPR21MB0144.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: BMZTq+6MrTOp9+KjLoxddpoE+sl6DVxaIEhpLBOW1N54QbX2oNyUyARNjnB2BVTcQmUKEGslInkSNI5V+8E2Gg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0144C68102972A668611E1FCB6F20MWHPR21MB0144namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c5a5a2d-bb20-433d-f1be-08d56f5f8a21 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 01:50:47.0838 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0640 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, 09 Feb 2018 01:50:53 -0000 --_000_MWHPR21MB0144C68102972A668611E1FCB6F20MWHPR21MB0144namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBzZXF1ZW5jZXMgZm9yIGVhY2ggcGF0aA0KVGhp cyBhbG9uZSBwcmV2ZW50cyBsaW5rYWJpbGl0eSByaWdodD8NCg0KPj4gVGhlIHBhY2tldCBudW1i ZXIgb24gZWFjaCBwYXRoIHdpbGwgc3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7LSkuDQpJcyBzdXBw b3J0aW5nIG11bHRpcGxlIHBhdGhzIGF0IHRoZSBzYW1lIHRpbWUgYSBnb2FsPyBJZiB5ZXMsIHRo ZW4geWVzIGFsbCBwYXRocyB3aWxsIG5lZWQgdG8gaGF2ZSBzZXBhcmF0ZSB0cmFja2luZyBhbmQg QUNLIHN0YXRlIGFuZCBjb25nZXN0aW9uIGNvbnRyb2wgZXRjLiBJIHRob3VnaHQgdGhpcyBpcyBu b3QgcGFydCBvZiBWMSBSRkMuIElmIGl0cyBqdXN0IG9uZSBhZGRpdGlvbmFsIHBhdGggZm9yIGNv bm5lY3Rpb24gbWlncmF0aW9uIHNjZW5hcmlvIHRoZW4gYWxsIHlvdSBuZWVkIGlzIGEgKHJhbmRv bSkganVtcCB0byBhIG9mZnNldCBpbiBwYWNrZXQgbnVtYmVyIHNwYWNlIGZvciB0aGUgbmV3IHBh dGggc28gdGhhdCB0aGUgZmV3IHBhY2tldHMgaW4gdGhlIG9sZCBwYXRoIGNhbiBjb250aW51ZSBm b3IgYSBsaXR0bGUgYml0LiBUaGlzIHdvcmtzIHdpdGgganVzdCBvbmUgQUNLIHNwYWNlIHNvIG5v IGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuDQoNCj4+IDIpIE9yLCBsZWF2aW5nIHRoZSBwYWNr ZXQgbnVtYmVyIGluIHRoZSBjbGVhciBidXQgdXNpbmcgZGlmZmVyZW50IGVuY3J5cHRpb24gY29u dGV4dHMgZm9yIGVhY2ggcGF0aCwgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBzZXF1ZW5jZXMg Zm9yIGVhY2ggcGF0aC4NCkluIGFkZGl0aW9uIGlmIHRoZSB2YWx1ZSBpbiB0aGUgY2xlYXIgd2Fz IG9iZnVzY2F0ZWQgd2l0aCBhbiBYT1IgdHJhbnNmb3JtIGl0IHdpbGwgaGVscCBwcmV2ZW50IG9z c2lmaWNhdGlvbi4gVGhlIG9iZnVzY2F0aW9uIGlzIG5vdCBtZWFudCB0byBndWFyZCBhZ2FpbnN0 IGxhdGVyIGFuYWx5c2lzIHRoYXQgcmV2ZWFscyB0aGUgcGFja2V0IG51bWJlcnMgLSB3aHkgZG8g d2UgY2FyZSBhYm91dCB0aGF0LiBJdCBpcyBtZWFudCB0byBncmVhc2UgdGhlIHNwYWNlIGFuZCBu b3QgbWFrZSB0aGUgbnVtYmVycyBzZXJpYWwgc28gbWlkZGxlYm94ZXMgY2Fubm90IGFzc3VtZSBv cmRlcmluZyBldGMuDQoNCkFsbCBzYWlkIGlmIEkgYW0gYWxvbmUgaW4gYmVpbmcgY29uY2VybmVk IGFib3V0IHRoZSBwZXJmIGhpdCB0aGVuIEnigJlkIHNheSBnbyBvbiB3aXRoIG9wdGlvbiAxLg0K DQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg Q2hyaXN0aWFuIEh1aXRlbWENClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDM6NTQg UE0NClRvOiBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0 aW9uDQoNCg0KT24gMi84LzIwMTggMToxMyBQTSwgTWlrZSBCaXNob3Agd3JvdGU6DQojMiB3b27i gJl0IHdvcmsuICBUaGUgcGFja2V0IG51bWJlciBpcyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25j ZSwgc28geW91IGhhdmUgdG8gZ2V0IHRvIHRoZSBwYWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2Fu IGRlY3J5cHQgdGhlIHBheWxvYWQuICBJdCBjYW7igJl0IGJlIGJhc2VkIG9uIGFueXRoaW5nIGlu dGVybmFsIHRvIHRoZSBlbmNyeXB0ZWQgcGFja2V0Lg0KDQpJbiBNYXJ0aW7igJlzIHByb3Bvc2Fs LCBpdOKAmXMgdXNpbmcgYSBjb21iaW5hdGlvbiBvZiB0aGUgZW5jcnlwdGVkIHBheWxvYWQgKHdo aWNoIHJlcXVpcmVzIG5vdGhpbmcgdG8gYWNjZXNzKSBhbmQgc29tZSBzdG9yZWQgc3RhdGUgb24g ZWFjaCBlbmRwb2ludCwgd2hpY2ggcmVxdWlyZXMgb25seSB0aGUgQ29ubmVjdGlvbiBJRCB0byBs b29rIHVwLiAgWW91IHdhbnQgdGhlIHRoaW5nIHlvdSBYT1IgYnkgdG8gYmUgY29uc3RhbnRseSBj aGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNpZXIgdG8gbG9vayBhdCBzZXF1ZW5jZXMgb2Ygb2Jm dXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQgc3RhcnQgZHJhd2luZyBpbmZlcmVuY2VzIGFib3V0 IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4gIElmIG92ZXJoZWFkIGlzIHRoZSBwcmltYXJ5IGNvbmNl cm4sIEkgdGhpbmsgdGhlcmUgYXJlIGEgY291cGxlIGFwcHJvYWNoZXMgdGhhdCBtaWdodCBhbGxv dyB5b3UgdG8gcHJlY29tcHV0ZSB2YWx1ZXMgYW5kIGFtb3J0aXplIHRoZSBjb3N0IG9mIGRvaW5n IHRoZSBlbmNyeXB0aW9uIHN0ZXAuICAoQXQgdGhlIGNvc3Qgb2Yga2VlcGluZyB0aGUgdGFibGUg b2YgcHJlY29tcHV0ZWQgdmFsdWVzLCBvZiBjb3Vyc2UuKQ0KDQpJIHN0aWxsIHRoaW5rIEphbmHi gJlzIHB1c2hpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBoZXJlOiAgTGV04oCZcyBhZ3JlZSBv biBnb2FscywgYW5kIHRoZW4gc2VlIGlmIHdlIGNhbiBjcmFmdCBhIGRlc2lnbiB0aGF0IG1lZXRz IHRob3NlIGdvYWxzLiAgSSBoZWFyIHlvdSBzYXlpbmcgdGhhdCBsb3cgb3ZlcmhlYWQgaXMgYSBn b2FsLCB3aGljaCBJIHRoaW5rIHdlIGNhbiBhbGwgYWdyZWUgb24uICBJIGFsc28gdGhpbmsgSSBo ZWFyIHlvdSBzYXlpbmcgdGhhdCAxLTEuNSUgb3ZlcmhlYWQgaXMgdG9vIGhpZ2gsIGJ1dCBpdCBz b3VuZHMgbGlrZSB0aGVyZeKAmXMgbGVzcyBhZ3JlZW1lbnQgb24gdGhhdC4gIFlvdSBhbHNvIHJh aXNlIGFuIGludGVyZXN0aW5nIHBvaW50IHRoYXQgc29tZSBjbGllbnRzIHdpbGwgY2FyZSBsZXNz IGFib3V0IGxpbmthYmlsaXR5IGJlY2F1c2UgdGhleSB3aWxsIG5ldmVyIGludGVudGlvbmFsbHkg bWlncmF0ZS4NCg0KSSB0aGluayBWaWN0b3Igc2FpZCBpdCBiZXN0LCAiT2JmdXNjYXRpb24gaXMg anVzdCBlbmNyeXB0aW9uIGRvbmUgcG9vcmx5LiIgRWl0aGVyIHdlIGVuY3J5cHQsIG9yIHdlIGRv bid0LiBCdXQgdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhbiBvYmZ1c2NhdGlvbiBtaWRkbGUt Z3JvdW5kLiBPYmZ1c2NhdGlvbiB3b3VsZCBqdXN0IGJlIGEgc3BlZWQgYnVtcCwgZWFzaWx5IGJy b2tlbi4gSXQgd29uJ3QgcHJvdmlkZSBwcml2YWN5LCBhbmQgaXQgd29uJ3QgcHJldmVudCBsaW5r YWJpbGl0eS4NCg0KQXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCB0aGVyZSBhcmUgb25seSB0d28g ZGVzaWducyB0aGF0IHByZXZlbnQgbGlua2FiaWxpdHk6DQoNCjEpIE1hcnRpbidzIFBSLCBpbiB3 aGljaCB0aGUgcGFja2V0IG51bWJlciBpcyBlbmNyeXB0ZWQgdXNpbmcgc2Vuc2libGUgY3J5cHRv Ow0KDQoyKSBPciwgbGVhdmluZyB0aGUgcGFja2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVz aW5nIGRpZmZlcmVudCBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2lu ZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBlYWNoIHBhdGguDQoNClRoZSBzZWNvbmQg b3B0aW9uIHJlcXVpcmVzIG1vcmUgY29tcHV0YXRpb24gd2hlbiBleHBsaWNpdGx5IHNldHRpbmcg dXAgYSBuZXcgcGF0aC4gVGhlIGNvbm5lY3Rpb24gSUQgd291bGQgYmUgdXNlZCBhcyBwYXJ0IG9m IHRoZSAic2FsdCIgd2hlbiBkZXJpdmluZyBjb25uZWN0aW9uIGNvbnRleHRzLiBUaGUgcGFja2V0 IG51bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFydCBhdCAxIChvciBtYXliZSAwIDstKS4gVGhp cyByZXF1aXJlcyBtYWludGFpbmluZyBzZXBhcmF0ZSBTQUNLIGRhc2hib2FyZHMgZm9yIGVhY2gg cGF0aC9Db25uZWN0aW9uLUlELCBhbmQgY29uc3RyYWluaW5nIEFDSyB0byBiZSBwZXIvcGF0aCwg b3IgYWx0ZXJuYXRpdmVseSBhZGRpbmcgYSBQQVRILUFDSyBmcmFtZSB0aGF0IGluZGljYXRlcyB0 aGUgcGF0aCBmb3Igd2hpY2ggcGFja2V0cyBhcmUgYWNrZWQuDQoNClRoZSBwcm9zIGFuZCBjb25z IG9mIHRoZSB0d28gb3B0aW9ucyBhcmUgZWFzeSB0byBnZXQ6DQoNCjEpIE9wdGlvbiAyIGRvZXMg bm90IHJlcXVpcmUgdGhlIGNvc3Qgb2YgZW5jcnlwdGluZyBldmVyeSBwYWNrZXQsIHRodXMgcGVy IHBhY2tldCBwcm9jZXNzaW5nIHdpbGwgYmUgbWF5YmUgMSUgZmFzdGVyIHRoYW4gb3B0aW9uIDEu DQoNCjIpIE9wdGlvbiAyIHJlcXVpcmVzIGNvbXB1dGluZyBlbmNyeXB0aW9uIGNvbnRleHRzIGZv ciBlYWNoIHBhdGgsIHdoaWNoIGlzIG1vcmUgY29tcGxleCB0aGFuIG9wdGlvbiAxLCBidXQgdGhl IGNvc3Qgd2lsbCBiZSBhbW9ydGl6ZWQgb3ZlciB0aGUgZHVyYXRpb24gb2YgdGhlIHBhdGguDQoN CjMpIE9wdGlvbiAyIHJlcXVpcmVzIG1vcmUgY29tcGxleCBkYXRhIHN0cnVjdHVyZXMgYW5kIEFD SyBtYW5hZ2VtZW50LCB0aHVzIGluY3JlYXNpbmcgdGhlIGNoYW5jZXMgdGhhdCBzb21ldGhpbmcg Z29lcyB3cm9uZy4NCg0KNCkgT3B0aW9uIDIgZG9lcyBub3RoaW5nIGFnYWluc3QgcGFja2V0IG51 bWJlciBvc3NpZmljYXRpb24uIFRoZSBwYWNrZXQgbnVtYmVyIGVmZmVjdGl2ZWx5IGJlY29tZXMg cGFydCBvZiB0aGUgaW52YXJpYW50cy4NCg0KSW4gc2hvcnQsIHRoZSBvbmx5IGFkdmFudGFnZSBv ZiBvcHRpb24gMiBpcyB0byBhdm9pZCBhIHNpbmdsZSBzeW1tZXRyaWMgZW5jcnlwdGlvbiBvcGVy YXRpb24gcGVyIHBhY2tldCwgd2hpbGUgbWFraW5nIHRoZSBjb2RlIHNpZ25pZmljYW50bHkgbW9y ZSBjb21wbGV4LCBhbmQgYXQgdGhlIGNvc3Qgb2Ygbm90IHByb3RlY3RpbmcgYWdhaW5zdCBQTiBv c3NpZmljYXRpb24uIFRoZSB3YXkgSSBzZWUgdGhhdCwgdGhlcmUgaXMgaGFyZGx5IGFueSBkZWJh dGUuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQo= --_000_MWHPR21MB0144C68102972A668611E1FCB6F20MWHPR21MB0144namp_ 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 YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28t c3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6 Q29uc29sYXM7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBU ZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21w b3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBhbmQgdXNpbmcgc2VwYXJh dGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRoPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGlzIGFsb25lIHByZXZlbnRzIGxpbmthYmlsaXR5IHJpZ2h0PzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBUaGUgcGFja2V0IG51bWJlciBvbiBlYWNoIHBh dGggd2lsbCBzdGFydCBhdCAxIChvciBtYXliZSAwIDstKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklzIHN1cHBvcnRpbmcgbXVsdGlwbGUgcGF0aHMgYXQgdGhlIHNhbWUg dGltZSBhIGdvYWw/IElmIHllcywgdGhlbiB5ZXMgYWxsIHBhdGhzIHdpbGwgbmVlZCB0byBoYXZl IHNlcGFyYXRlIHRyYWNraW5nIGFuZCBBQ0sgc3RhdGUgYW5kIGNvbmdlc3Rpb24gY29udHJvbCBl dGMuIEkgdGhvdWdodCB0aGlzIGlzIG5vdCBwYXJ0IG9mIFYxIFJGQy4gSWYgaXRzIGp1c3Qgb25l IGFkZGl0aW9uYWwgcGF0aCBmb3IgY29ubmVjdGlvbg0KIG1pZ3JhdGlvbiBzY2VuYXJpbyB0aGVu IGFsbCB5b3UgbmVlZCBpcyBhIChyYW5kb20pIGp1bXAgdG8gYSBvZmZzZXQgaW4gcGFja2V0IG51 bWJlciBzcGFjZSBmb3IgdGhlIG5ldyBwYXRoIHNvIHRoYXQgdGhlIGZldyBwYWNrZXRzIGluIHRo ZSBvbGQgcGF0aCBjYW4gY29udGludWUgZm9yIGEgbGl0dGxlIGJpdC4gVGhpcyB3b3JrcyB3aXRo IGp1c3Qgb25lIEFDSyBzcGFjZSBzbyBubyBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyAyKSBPciwgbGVhdmluZyB0aGUgcGFja2V0IG51 bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5nIGRpZmZlcmVudCBlbmNyeXB0aW9uIGNvbnRleHRz IGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBl YWNoIHBhdGguPGJyPg0KSW4gYWRkaXRpb24gaWYgdGhlIHZhbHVlIGluIHRoZSBjbGVhciB3YXMg b2JmdXNjYXRlZCB3aXRoIGFuIFhPUiB0cmFuc2Zvcm0gaXQgd2lsbCBoZWxwIHByZXZlbnQgb3Nz aWZpY2F0aW9uLiBUaGUgb2JmdXNjYXRpb24gaXMgbm90IG1lYW50IHRvIGd1YXJkIGFnYWluc3Qg bGF0ZXIgYW5hbHlzaXMgdGhhdCByZXZlYWxzIHRoZSBwYWNrZXQgbnVtYmVycyAtIHdoeSBkbyB3 ZSBjYXJlIGFib3V0IHRoYXQuIEl0IGlzIG1lYW50IHRvIGdyZWFzZSB0aGUNCiBzcGFjZSBhbmQg bm90IG1ha2UgdGhlIG51bWJlcnMgc2VyaWFsIHNvIG1pZGRsZWJveGVzIGNhbm5vdCBhc3N1bWUg b3JkZXJpbmcgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwgc2FpZCBpZiBJIGFtIGFs b25lIGluIGJlaW5nIGNvbmNlcm5lZCBhYm91dCB0aGUgcGVyZiBoaXQgdGhlbiBJ4oCZZCBzYXkg Z28gb24gd2l0aCBvcHRpb24gMS4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndp bmRvd3RleHQiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5DaHJpc3RpYW4gSHVpdGVtYTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg RmVicnVhcnkgOCwgMjAxOCAzOjU0IFBNPGJyPg0KPGI+VG86PC9iPiBxdWljQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cD5PbiAyLzgvMjAxOCAxOjEzIFBNLCBNaWtlIEJpc2hvcCB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IzIgd29u4oCZdCB3b3Jr LiZuYnNwOyBUaGUgcGFja2V0IG51bWJlciBpcyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwg c28geW91IGhhdmUgdG8gZ2V0IHRvIHRoZSBwYWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRl Y3J5cHQgdGhlIHBheWxvYWQuJm5ic3A7IEl0IGNhbuKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcg aW50ZXJuYWwgdG8gdGhlIGVuY3J5cHRlZCBwYWNrZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkluIE1hcnRpbuKAmXMgcHJvcG9zYWwsIGl04oCZcyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mIHRo ZSBlbmNyeXB0ZWQgcGF5bG9hZCAod2hpY2ggcmVxdWlyZXMgbm90aGluZyB0byBhY2Nlc3MpIGFu ZCBzb21lIHN0b3JlZCBzdGF0ZSBvbiBlYWNoIGVuZHBvaW50LCB3aGljaCByZXF1aXJlcyBvbmx5 IHRoZSBDb25uZWN0aW9uIElEIHRvIGxvb2sgdXAuJm5ic3A7IFlvdSB3YW50IHRoZSB0aGluZyB5 b3UgWE9SIGJ5IHRvIGJlIGNvbnN0YW50bHkNCiBjaGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNp ZXIgdG8gbG9vayBhdCBzZXF1ZW5jZXMgb2Ygb2JmdXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQg c3RhcnQgZHJhd2luZyBpbmZlcmVuY2VzIGFib3V0IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4mbmJz cDsgSWYgb3ZlcmhlYWQgaXMgdGhlIHByaW1hcnkgY29uY2VybiwgSSB0aGluayB0aGVyZSBhcmUg YSBjb3VwbGUgYXBwcm9hY2hlcyB0aGF0IG1pZ2h0IGFsbG93IHlvdSB0byBwcmVjb21wdXRlIHZh bHVlcw0KIGFuZCBhbW9ydGl6ZSB0aGUgY29zdCBvZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVw LiZuYnNwOyAoQXQgdGhlIGNvc3Qgb2Yga2VlcGluZyB0aGUgdGFibGUgb2YgcHJlY29tcHV0ZWQg dmFsdWVzLCBvZiBjb3Vyc2UuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0aWxsIHRoaW5r IEphbmHigJlzIHB1c2hpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBoZXJlOiZuYnNwOyBMZXTi gJlzIGFncmVlIG9uIGdvYWxzLCBhbmQgdGhlbiBzZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWdu IHRoYXQgbWVldHMgdGhvc2UgZ29hbHMuJm5ic3A7IEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93 IG92ZXJoZWFkIGlzIGEgZ29hbCwgd2hpY2ggSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiZu YnNwOyBJIGFsc28gdGhpbmsNCiBJIGhlYXIgeW91IHNheWluZyB0aGF0IDEtMS41JSBvdmVyaGVh ZCBpcyB0b28gaGlnaCwgYnV0IGl0IHNvdW5kcyBsaWtlIHRoZXJl4oCZcyBsZXNzIGFncmVlbWVu dCBvbiB0aGF0LiZuYnNwOyBZb3UgYWxzbyByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0 IHNvbWUgY2xpZW50cyB3aWxsIGNhcmUgbGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRo ZXkgd2lsbCBuZXZlciBpbnRlbnRpb25hbGx5IG1pZ3JhdGUuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCkkgdGhpbmsgVmljdG9yIHNhaWQgaXQgYmVzdCwgJnF1b3Q7T2JmdXNjYXRpb24g aXMganVzdCBlbmNyeXB0aW9uIGRvbmUgcG9vcmx5LiZxdW90OyBFaXRoZXIgd2UgZW5jcnlwdCwg b3Igd2UgZG9uJ3QuIEJ1dCB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGFuIG9iZnVzY2F0aW9u IG1pZGRsZS1ncm91bmQuIE9iZnVzY2F0aW9uIHdvdWxkIGp1c3QgYmUgYSBzcGVlZCBidW1wLCBl YXNpbHkgYnJva2VuLiBJdCB3b24ndCBwcm92aWRlIHByaXZhY3ksIGFuZCBpdCB3b24ndA0KIHBy ZXZlbnQgbGlua2FiaWxpdHkuPGJyPg0KPGJyPg0KQXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCB0 aGVyZSBhcmUgb25seSB0d28gZGVzaWducyB0aGF0IHByZXZlbnQgbGlua2FiaWxpdHk6PGJyPg0K PGJyPg0KMSkgTWFydGluJ3MgUFIsIGluIHdoaWNoIHRoZSBwYWNrZXQgbnVtYmVyIGlzIGVuY3J5 cHRlZCB1c2luZyBzZW5zaWJsZSBjcnlwdG87PGJyPg0KPGJyPg0KMikgT3IsIGxlYXZpbmcgdGhl IHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1dCB1c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlv biBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVl bmNlcyBmb3IgZWFjaCBwYXRoLjxicj4NCjxicj4NClRoZSBzZWNvbmQgb3B0aW9uIHJlcXVpcmVz IG1vcmUgY29tcHV0YXRpb24gd2hlbiBleHBsaWNpdGx5IHNldHRpbmcgdXAgYSBuZXcgcGF0aC4g VGhlIGNvbm5lY3Rpb24gSUQgd291bGQgYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSAmcXVvdDtzYWx0 JnF1b3Q7IHdoZW4gZGVyaXZpbmcgY29ubmVjdGlvbiBjb250ZXh0cy4gVGhlIHBhY2tldCBudW1i ZXIgb24gZWFjaCBwYXRoIHdpbGwgc3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7LSkuIFRoaXMgcmVx dWlyZXMgbWFpbnRhaW5pbmcNCiBzZXBhcmF0ZSBTQUNLIGRhc2hib2FyZHMgZm9yIGVhY2ggcGF0 aC9Db25uZWN0aW9uLUlELCBhbmQgY29uc3RyYWluaW5nIEFDSyB0byBiZSBwZXIvcGF0aCwgb3Ig YWx0ZXJuYXRpdmVseSBhZGRpbmcgYSBQQVRILUFDSyBmcmFtZSB0aGF0IGluZGljYXRlcyB0aGUg cGF0aCBmb3Igd2hpY2ggcGFja2V0cyBhcmUgYWNrZWQuPGJyPg0KPGJyPg0KVGhlIHByb3MgYW5k IGNvbnMgb2YgdGhlIHR3byBvcHRpb25zIGFyZSBlYXN5IHRvIGdldDo8YnI+DQo8YnI+DQoxKSBP cHRpb24gMiBkb2VzIG5vdCByZXF1aXJlIHRoZSBjb3N0IG9mIGVuY3J5cHRpbmcgZXZlcnkgcGFj a2V0LCB0aHVzIHBlciBwYWNrZXQgcHJvY2Vzc2luZyB3aWxsIGJlIG1heWJlIDElIGZhc3RlciB0 aGFuIG9wdGlvbiAxLg0KPGJyPg0KPGJyPg0KMikgT3B0aW9uIDIgcmVxdWlyZXMgY29tcHV0aW5n IGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgd2hpY2ggaXMgbW9yZSBjb21wbGV4 IHRoYW4gb3B0aW9uIDEsIGJ1dCB0aGUgY29zdCB3aWxsIGJlIGFtb3J0aXplZCBvdmVyIHRoZSBk dXJhdGlvbiBvZiB0aGUgcGF0aC48YnI+DQo8YnI+DQozKSBPcHRpb24gMiByZXF1aXJlcyBtb3Jl IGNvbXBsZXggZGF0YSBzdHJ1Y3R1cmVzIGFuZCBBQ0sgbWFuYWdlbWVudCwgdGh1cyBpbmNyZWFz aW5nIHRoZSBjaGFuY2VzIHRoYXQgc29tZXRoaW5nIGdvZXMgd3JvbmcuPGJyPg0KPGJyPg0KNCkg T3B0aW9uIDIgZG9lcyBub3RoaW5nIGFnYWluc3QgcGFja2V0IG51bWJlciBvc3NpZmljYXRpb24u IFRoZSBwYWNrZXQgbnVtYmVyIGVmZmVjdGl2ZWx5IGJlY29tZXMgcGFydCBvZiB0aGUgaW52YXJp YW50cy48YnI+DQo8YnI+DQpJbiBzaG9ydCwgdGhlIG9ubHkgYWR2YW50YWdlIG9mIG9wdGlvbiAy IGlzIHRvIGF2b2lkIGEgc2luZ2xlIHN5bW1ldHJpYyBlbmNyeXB0aW9uIG9wZXJhdGlvbiBwZXIg cGFja2V0LCB3aGlsZSBtYWtpbmcgdGhlIGNvZGUgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXgs IGFuZCBhdCB0aGUgY29zdCBvZiBub3QgcHJvdGVjdGluZyBhZ2FpbnN0IFBOIG9zc2lmaWNhdGlv bi4gVGhlIHdheSBJIHNlZSB0aGF0LCB0aGVyZSBpcyBoYXJkbHkgYW55IGRlYmF0ZS48YnI+DQo8 YnI+DQotLSBDaHJpc3RpYW4gSHVpdGVtYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_MWHPR21MB0144C68102972A668611E1FCB6F20MWHPR21MB0144namp_-- From nobody Thu Feb 8 17:51:12 2018 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 48F5C126CC4 for ; Thu, 8 Feb 2018 17:51:11 -0800 (PST) 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 IEfD4JG5HCNh for ; Thu, 8 Feb 2018 17:50:59 -0800 (PST) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::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 5ACA3120721 for ; Thu, 8 Feb 2018 17:50:59 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id 8so4959924oix.7 for ; Thu, 08 Feb 2018 17:50:59 -0800 (PST) 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=MUowRcmSBrK+OfzT2ewk0XIecAg395UXFKsIS7cgupI=; b=vfTC9Ok6cr4nu4Voxk/xVww6jL2RuAsdOInSyfBR3bGPYjc0YSZKLMrNx5Q5kwmMaX /o7VtjOOagCrhVRZ8Q5eoo2CQV/WP/98CoPsQGTyBU1vXYCn7jfbjHp69JuC+RuO2fE2 6R4A6tpHiNmk4OVboSHcAncC5hBxs8k+bw+0pgIEO+GFyr2x2Y6bOB4NSHCof6OlUAdd vq43LaOe9/JYhUOI201L5z734G/1IAP+nrA/RAJoV5Lslcz5Fsoa8UPQe7iCLnGWpVyM IsS8VCKMm/0xKW6ycjUgiU0gKEKrHysE4MNi6UL2v0+n81SldwJpziU92eoVUUaUE/Y5 PjvQ== 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=MUowRcmSBrK+OfzT2ewk0XIecAg395UXFKsIS7cgupI=; b=MhRtkPoKq7f/eivJ4ufEbtpNIsq7wrXAu9tMfOg+Oj6efoYOM7+Fun7Ezq5WEOEN/G ZMBT2PNWECT1tPQ3+Fd8LiKycEN5jJxn5eW5gBiy5o1dvYGxF0zWbGpGQ3Ux7yBfgH/m /8OJ9fVlreiaR6aeGLiBwohP4K7cWmCeLlBa7pVHQJfdYCGujcnSGHaK9sFPW1/usEAp JvHGcS4bYybL0TM55S6QXN7Pw1L6QoLEj/ds5cBsd1bXAIgs6xJlLjEA0b1QVuMziip8 6TUPx5BoWBWEOsckulUw6It4poazNytZmFCfPyvjKiuUOV8tOuJ424CLlUOLlPekr8Qs ypFQ== X-Gm-Message-State: APf1xPAQX4lvxySEi1kYwIL6KnrT7OnRYFkc+/Wchhl4F3gb1YvUbGaA Kk2Q0+FRrq1aK4EiMCYBMYpmO0pPe5VlD53Ypss= X-Google-Smtp-Source: AH8x225ODeQkMIz/wQVF9tMeBtgf+MLeYXjNlU8Cgm4FDdiIs/qS86S27GU3Z4qjsfc7haHFHJS6ETgk0HY5x1wk9WQ= X-Received: by 10.84.68.22 with SMTP id k22mr698002oiw.284.1518141058644; Thu, 08 Feb 2018 17:50:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Thu, 8 Feb 2018 17:50:58 -0800 (PST) In-Reply-To: <6203282A-CD65-4049-A499-DED34431E912@mnot.net> References: <151809506296.17228.17281018611304930059@ietfa.amsl.com> <6203282A-CD65-4049-A499-DED34431E912@mnot.net> From: Martin Thomson Date: Fri, 9 Feb 2018 12:50:58 +1100 Message-ID: Subject: Re: QUIC (quic) WG Interim Meeting: 2018-06-06 To: Mark Nottingham Cc: QUIC WG , Lars Eggert 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, 09 Feb 2018 01:51:11 -0000 Thanks to our hosts Ericsson. On Fri, Feb 9, 2018 at 10:02 AM, Mark Nottingham wrote: > Registration is now open; see the arrangements page. Please note the guidelines for attendance there. > > Cheers, > > >> On 9 Feb 2018, at 12:04 am, IESG Secretary wrote: >> >> The QUIC (quic) Working Group will hold >> a multi-day interim meeting. >> >> Session 1: >> 2018-06-06 09:00 to 17:00 Europe/Berlin >> Session 2: >> 2018-06-07 09:00 to 17:00 Europe/Berlin >> >> Meeting Location: >> Kista, SE >> >> Agenda: >> https://github.com/quicwg/wg-materials/blob/master/interim-18-06/agenda.md >> >> Information about remote participation: >> https://github.com/quicwg/wg-materials/blob/master/interim-18-06/arrangements.md >> >> Preceded by non-IETF QUIC interop event on June 4-5, same location >> > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Thu Feb 8 21:40:24 2018 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 4B5CC124D68 for ; Thu, 8 Feb 2018 21:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=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 SOzP7vOx3b6H for ; Thu, 8 Feb 2018 21:40:19 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0116.outbound.protection.outlook.com [104.47.34.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93824127871 for ; Thu, 8 Feb 2018 21:40:19 -0800 (PST) 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=2VHc1s5AmtigDxGl5XR4oOqdcSmITwSHRyO7Itwv2VM=; b=JbJxCJV21r0Dh0g6i95KO2yEO5vv+yprTeXLPfMFxLeFy6rEle+b1qKFFDGN0BPGyH4QLSeQim5lRDEYLbLLko8mXzI4A4rPQXIMRPdWIek+7PEuBkeuvXOhQzaW41zIsZBow/JP7p7OZtP1sDcAcwnfRO1YViYc+8T7nDM8jIY= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0695.namprd21.prod.outlook.com (10.175.121.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Fri, 9 Feb 2018 05:40:04 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 05:40:04 +0000 From: Praveen Balasubramanian To: huitema , "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwA== Date: Fri, 9 Feb 2018 05:40:04 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0695; 7:n5qZJOWpdM5WA1Dbrq1zEXcPLYhzMmmFBjNI1Fd2dg/LcuNpp+3SYeZwwN76dg38Fl9wVOQwHI+LjNuaxpErtHPRH1RR8Tl6YhF3NfVXWxGQIdCD0agO3hz+Olz0G5Bq8/GYFRzwQlj+yodkgpCr3y1UjkGWWRrsnJ2g3h2fbcrRewUDS32MqneOqPsvys6nipBlgXaZmVvYZhdQ+lk4sEpi0oXU/u0lkrlTrbeP75WGh9jxwLFOjUw+yFu+fX5W x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e118dd54-2db4-4fd8-fbf3-08d56f7f9213 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0695; x-ms-traffictypediagnostic: CY4PR21MB0695: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0695; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0695; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(376002)(39860400002)(39380400002)(346002)(189003)(199004)(377424004)(2900100001)(55016002)(110136005)(6436002)(74316002)(7736002)(93886005)(186003)(33656002)(8676002)(81166006)(81156014)(3660700001)(236005)(10090500001)(68736007)(316002)(53936002)(9686003)(8990500004)(106356001)(54896002)(22452003)(6306002)(790700001)(6116002)(6246003)(2906002)(76176011)(7116003)(6346003)(102836004)(5660300001)(2950100002)(6506007)(5250100002)(2501003)(59450400001)(53546011)(3280700002)(478600001)(25786009)(10290500003)(86612001)(3480700004)(8936002)(105586002)(14454004)(561944003)(229853002)(7696005)(99286004)(86362001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0695; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: GfIPwUOlkrzkPyNLhR9Vjqdh2FOLE/DuseibtvCEx53gX1kM1vYVlTKoJYL8Yu1i6zQMcPaGMkDYNoVr6TGW0Q== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01332141C3563ABBA240C566B6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: e118dd54-2db4-4fd8-fbf3-08d56f7f9213 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 05:40:04.4045 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0695 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, 09 Feb 2018 05:40:23 -0000 --_000_CY4PR21MB01332141C3563ABBA240C566B6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWN0dWFsbHkgdGFraW5nIGEgc3RlcCBiYWNrIHdoYXQgaWYgd2UgZG9u4oCZdCB3ZSBvdmVybG9h ZGVkIHBhY2tldCBudW1iZXIgYXMgdGhlIG5vbmNlPw0KDQpDYW4gd2U6DQoNCiAgMS4gIFB1dCBw YWNrZXQgbnVtYmVyIGFzIGEgc2VwYXJhdGUgdmFyaWFibGUgbGVuZ3RoIGZpZWxkIGluIHRoZSBl bmNyeXB0ZWQgcG9ydGlvbiBvZiB0aGUgaGVhZGVyLiBUaGlzIGFsbG93cyBmb3IgZ3Jvd3RoIGJl eW9uZCA2NCBiaXRzIGluIGZ1dHVyZSBhbmQgY29tcGxldGVseSBhdm9pZHMgb3NzaWZpY2F0aW9u LiBGb3Igc2hvcnQgbGl2ZWQgZmxvd3MgdmFyaWFibGUgbGVuZ3RoIGVuY29kaW5nIGxlYWRzIHRv IG1pbmltYWwgc3BhY2Ugb3ZlcmhlYWQuDQogIDIuICBQdXQgYSBzZXBhcmF0ZSBwbGFpbnRleHQg bm9uY2Ugd2hpY2ggc3RhcnRzIG91dCBhcyBhIHNlY3VyZSByYW5kb20gbnVtYmVyIGFuZCBtb25v dG9uaWNhbGx5IGluY3JlYXNlcyBhcyBzaG9ydCByYW5kb20ganVtcHMgKGV2ZXJ5IHBhY2tldCBv ciBldmVyeSBmZXcgcGFja2V0cykgYW5kIGNvdWxkIHRoZW4gcm9sbG92ZXIuIFRoaXMgd2lsbCBw cmV2ZW50IGxpbmthYmlsaXR5IGFuZCBzY2FsZXMgdG8gbXVsdGktcGF0aCBhcyB3ZWxsLiBObyBt YWpvciBjb21wdXRlIG92ZXJoZWFkLiBXZSBjYW4gYWxzbyBtYWtlIHRoZSBub25jZSBvcHRpb25h bCBmb3IgY3J5cHRvIGFsZ29yaXRobXMgdGhhdCBkbyBub3QgbmVlZCBhIG5vbmNlIHNhdmluZyBt b3JlIHNwYWNlLg0KDQpTb21lIE1TQiBvZiB0aGUgbm9uY2UgY291bGQgYmUgdXNlZCBmb3Igc2ln bmFsaW5nIHJlb3JkZXIgdG8gdGhlIG5ldHdvcmsgaWYgbmVlZGVkLiBJIGRvbuKAmXQgaGF2ZSB0 aGUgaGlzdG9yaWNhbCBjb250ZXh0IGZvciBvdmVybG9hZGluZyBvZiBQTiBhcyB0aGUgbm9uY2Ug c28gcGFyZG9uIG1lIGlmIHVuLW92ZXJsb2FkaW5nIG9wdGlvbiB3YXMgZGlzY3Vzc2VkIGFuZCBy dWxlZCBvdXQgYmVmb3JlLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NClNlbnQ6IFRodXJzZGF5 LCBGZWJydWFyeSA4LCAyMDE4IDU6NTEgUE0NClRvOiBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEu bmV0PjsgcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlv bg0KDQo+PiBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRo DQpUaGlzIGFsb25lIHByZXZlbnRzIGxpbmthYmlsaXR5IHJpZ2h0Pw0KDQo+PiBUaGUgcGFja2V0 IG51bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFydCBhdCAxIChvciBtYXliZSAwIDstKS4NCklz IHN1cHBvcnRpbmcgbXVsdGlwbGUgcGF0aHMgYXQgdGhlIHNhbWUgdGltZSBhIGdvYWw/IElmIHll cywgdGhlbiB5ZXMgYWxsIHBhdGhzIHdpbGwgbmVlZCB0byBoYXZlIHNlcGFyYXRlIHRyYWNraW5n IGFuZCBBQ0sgc3RhdGUgYW5kIGNvbmdlc3Rpb24gY29udHJvbCBldGMuIEkgdGhvdWdodCB0aGlz IGlzIG5vdCBwYXJ0IG9mIFYxIFJGQy4gSWYgaXRzIGp1c3Qgb25lIGFkZGl0aW9uYWwgcGF0aCBm b3IgY29ubmVjdGlvbiBtaWdyYXRpb24gc2NlbmFyaW8gdGhlbiBhbGwgeW91IG5lZWQgaXMgYSAo cmFuZG9tKSBqdW1wIHRvIGEgb2Zmc2V0IGluIHBhY2tldCBudW1iZXIgc3BhY2UgZm9yIHRoZSBu ZXcgcGF0aCBzbyB0aGF0IHRoZSBmZXcgcGFja2V0cyBpbiB0aGUgb2xkIHBhdGggY2FuIGNvbnRp bnVlIGZvciBhIGxpdHRsZSBiaXQuIFRoaXMgd29ya3Mgd2l0aCBqdXN0IG9uZSBBQ0sgc3BhY2Ug c28gbm8gaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS4NCg0KPj4gMikgT3IsIGxlYXZpbmcgdGhl IHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1dCB1c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlv biBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVl bmNlcyBmb3IgZWFjaCBwYXRoLg0KSW4gYWRkaXRpb24gaWYgdGhlIHZhbHVlIGluIHRoZSBjbGVh ciB3YXMgb2JmdXNjYXRlZCB3aXRoIGFuIFhPUiB0cmFuc2Zvcm0gaXQgd2lsbCBoZWxwIHByZXZl bnQgb3NzaWZpY2F0aW9uLiBUaGUgb2JmdXNjYXRpb24gaXMgbm90IG1lYW50IHRvIGd1YXJkIGFn YWluc3QgbGF0ZXIgYW5hbHlzaXMgdGhhdCByZXZlYWxzIHRoZSBwYWNrZXQgbnVtYmVycyAtIHdo eSBkbyB3ZSBjYXJlIGFib3V0IHRoYXQuIEl0IGlzIG1lYW50IHRvIGdyZWFzZSB0aGUgc3BhY2Ug YW5kIG5vdCBtYWtlIHRoZSBudW1iZXJzIHNlcmlhbCBzbyBtaWRkbGVib3hlcyBjYW5ub3QgYXNz dW1lIG9yZGVyaW5nIGV0Yy4NCg0KQWxsIHNhaWQgaWYgSSBhbSBhbG9uZSBpbiBiZWluZyBjb25j ZXJuZWQgYWJvdXQgdGhlIHBlcmYgaGl0IHRoZW4gSeKAmWQgc2F5IGdvIG9uIHdpdGggb3B0aW9u IDEuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBDaHJpc3RpYW4gSHVpdGVtYQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTgg Mzo1NCBQTQ0KVG86IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCg0KT24gMi84LzIwMTggMToxMyBQTSwg TWlrZSBCaXNob3Agd3JvdGU6DQojMiB3b27igJl0IHdvcmsuICBUaGUgcGFja2V0IG51bWJlciBp cyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwgc28geW91IGhhdmUgdG8gZ2V0IHRvIHRoZSBw YWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRlY3J5cHQgdGhlIHBheWxvYWQuICBJdCBjYW7i gJl0IGJlIGJhc2VkIG9uIGFueXRoaW5nIGludGVybmFsIHRvIHRoZSBlbmNyeXB0ZWQgcGFja2V0 Lg0KDQpJbiBNYXJ0aW7igJlzIHByb3Bvc2FsLCBpdOKAmXMgdXNpbmcgYSBjb21iaW5hdGlvbiBv ZiB0aGUgZW5jcnlwdGVkIHBheWxvYWQgKHdoaWNoIHJlcXVpcmVzIG5vdGhpbmcgdG8gYWNjZXNz KSBhbmQgc29tZSBzdG9yZWQgc3RhdGUgb24gZWFjaCBlbmRwb2ludCwgd2hpY2ggcmVxdWlyZXMg b25seSB0aGUgQ29ubmVjdGlvbiBJRCB0byBsb29rIHVwLiAgWW91IHdhbnQgdGhlIHRoaW5nIHlv dSBYT1IgYnkgdG8gYmUgY29uc3RhbnRseSBjaGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNpZXIg dG8gbG9vayBhdCBzZXF1ZW5jZXMgb2Ygb2JmdXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQgc3Rh cnQgZHJhd2luZyBpbmZlcmVuY2VzIGFib3V0IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4gIElmIG92 ZXJoZWFkIGlzIHRoZSBwcmltYXJ5IGNvbmNlcm4sIEkgdGhpbmsgdGhlcmUgYXJlIGEgY291cGxl IGFwcHJvYWNoZXMgdGhhdCBtaWdodCBhbGxvdyB5b3UgdG8gcHJlY29tcHV0ZSB2YWx1ZXMgYW5k IGFtb3J0aXplIHRoZSBjb3N0IG9mIGRvaW5nIHRoZSBlbmNyeXB0aW9uIHN0ZXAuICAoQXQgdGhl IGNvc3Qgb2Yga2VlcGluZyB0aGUgdGFibGUgb2YgcHJlY29tcHV0ZWQgdmFsdWVzLCBvZiBjb3Vy c2UuKQ0KDQpJIHN0aWxsIHRoaW5rIEphbmHigJlzIHB1c2hpbmcgaW4gdGhlIHJpZ2h0IGRpcmVj dGlvbiBoZXJlOiAgTGV04oCZcyBhZ3JlZSBvbiBnb2FscywgYW5kIHRoZW4gc2VlIGlmIHdlIGNh biBjcmFmdCBhIGRlc2lnbiB0aGF0IG1lZXRzIHRob3NlIGdvYWxzLiAgSSBoZWFyIHlvdSBzYXlp bmcgdGhhdCBsb3cgb3ZlcmhlYWQgaXMgYSBnb2FsLCB3aGljaCBJIHRoaW5rIHdlIGNhbiBhbGwg YWdyZWUgb24uICBJIGFsc28gdGhpbmsgSSBoZWFyIHlvdSBzYXlpbmcgdGhhdCAxLTEuNSUgb3Zl cmhlYWQgaXMgdG9vIGhpZ2gsIGJ1dCBpdCBzb3VuZHMgbGlrZSB0aGVyZeKAmXMgbGVzcyBhZ3Jl ZW1lbnQgb24gdGhhdC4gIFlvdSBhbHNvIHJhaXNlIGFuIGludGVyZXN0aW5nIHBvaW50IHRoYXQg c29tZSBjbGllbnRzIHdpbGwgY2FyZSBsZXNzIGFib3V0IGxpbmthYmlsaXR5IGJlY2F1c2UgdGhl eSB3aWxsIG5ldmVyIGludGVudGlvbmFsbHkgbWlncmF0ZS4NCg0KSSB0aGluayBWaWN0b3Igc2Fp ZCBpdCBiZXN0LCAiT2JmdXNjYXRpb24gaXMganVzdCBlbmNyeXB0aW9uIGRvbmUgcG9vcmx5LiIg RWl0aGVyIHdlIGVuY3J5cHQsIG9yIHdlIGRvbid0LiBCdXQgdGhlcmUgaXMgbm8gc3VjaCB0aGlu ZyBhcyBhbiBvYmZ1c2NhdGlvbiBtaWRkbGUtZ3JvdW5kLiBPYmZ1c2NhdGlvbiB3b3VsZCBqdXN0 IGJlIGEgc3BlZWQgYnVtcCwgZWFzaWx5IGJyb2tlbi4gSXQgd29uJ3QgcHJvdmlkZSBwcml2YWN5 LCBhbmQgaXQgd29uJ3QgcHJldmVudCBsaW5rYWJpbGl0eS4NCg0KQXMgZmFyIGFzIEkgYW0gY29u Y2VybmVkLCB0aGVyZSBhcmUgb25seSB0d28gZGVzaWducyB0aGF0IHByZXZlbnQgbGlua2FiaWxp dHk6DQoNCjEpIE1hcnRpbidzIFBSLCBpbiB3aGljaCB0aGUgcGFja2V0IG51bWJlciBpcyBlbmNy eXB0ZWQgdXNpbmcgc2Vuc2libGUgY3J5cHRvOw0KDQoyKSBPciwgbGVhdmluZyB0aGUgcGFja2V0 IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5nIGRpZmZlcmVudCBlbmNyeXB0aW9uIGNvbnRl eHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZv ciBlYWNoIHBhdGguDQoNClRoZSBzZWNvbmQgb3B0aW9uIHJlcXVpcmVzIG1vcmUgY29tcHV0YXRp b24gd2hlbiBleHBsaWNpdGx5IHNldHRpbmcgdXAgYSBuZXcgcGF0aC4gVGhlIGNvbm5lY3Rpb24g SUQgd291bGQgYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSAic2FsdCIgd2hlbiBkZXJpdmluZyBjb25u ZWN0aW9uIGNvbnRleHRzLiBUaGUgcGFja2V0IG51bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFy dCBhdCAxIChvciBtYXliZSAwIDstKS4gVGhpcyByZXF1aXJlcyBtYWludGFpbmluZyBzZXBhcmF0 ZSBTQUNLIGRhc2hib2FyZHMgZm9yIGVhY2ggcGF0aC9Db25uZWN0aW9uLUlELCBhbmQgY29uc3Ry YWluaW5nIEFDSyB0byBiZSBwZXIvcGF0aCwgb3IgYWx0ZXJuYXRpdmVseSBhZGRpbmcgYSBQQVRI LUFDSyBmcmFtZSB0aGF0IGluZGljYXRlcyB0aGUgcGF0aCBmb3Igd2hpY2ggcGFja2V0cyBhcmUg YWNrZWQuDQoNClRoZSBwcm9zIGFuZCBjb25zIG9mIHRoZSB0d28gb3B0aW9ucyBhcmUgZWFzeSB0 byBnZXQ6DQoNCjEpIE9wdGlvbiAyIGRvZXMgbm90IHJlcXVpcmUgdGhlIGNvc3Qgb2YgZW5jcnlw dGluZyBldmVyeSBwYWNrZXQsIHRodXMgcGVyIHBhY2tldCBwcm9jZXNzaW5nIHdpbGwgYmUgbWF5 YmUgMSUgZmFzdGVyIHRoYW4gb3B0aW9uIDEuDQoNCjIpIE9wdGlvbiAyIHJlcXVpcmVzIGNvbXB1 dGluZyBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIHdoaWNoIGlzIG1vcmUgY29t cGxleCB0aGFuIG9wdGlvbiAxLCBidXQgdGhlIGNvc3Qgd2lsbCBiZSBhbW9ydGl6ZWQgb3ZlciB0 aGUgZHVyYXRpb24gb2YgdGhlIHBhdGguDQoNCjMpIE9wdGlvbiAyIHJlcXVpcmVzIG1vcmUgY29t cGxleCBkYXRhIHN0cnVjdHVyZXMgYW5kIEFDSyBtYW5hZ2VtZW50LCB0aHVzIGluY3JlYXNpbmcg dGhlIGNoYW5jZXMgdGhhdCBzb21ldGhpbmcgZ29lcyB3cm9uZy4NCg0KNCkgT3B0aW9uIDIgZG9l cyBub3RoaW5nIGFnYWluc3QgcGFja2V0IG51bWJlciBvc3NpZmljYXRpb24uIFRoZSBwYWNrZXQg bnVtYmVyIGVmZmVjdGl2ZWx5IGJlY29tZXMgcGFydCBvZiB0aGUgaW52YXJpYW50cy4NCg0KSW4g c2hvcnQsIHRoZSBvbmx5IGFkdmFudGFnZSBvZiBvcHRpb24gMiBpcyB0byBhdm9pZCBhIHNpbmds ZSBzeW1tZXRyaWMgZW5jcnlwdGlvbiBvcGVyYXRpb24gcGVyIHBhY2tldCwgd2hpbGUgbWFraW5n IHRoZSBjb2RlIHNpZ25pZmljYW50bHkgbW9yZSBjb21wbGV4LCBhbmQgYXQgdGhlIGNvc3Qgb2Yg bm90IHByb3RlY3RpbmcgYWdhaW5zdCBQTiBvc3NpZmljYXRpb24uIFRoZSB3YXkgSSBzZWUgdGhh dCwgdGhlcmUgaXMgaGFyZGx5IGFueSBkZWJhdGUuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQo= --_000_CY4PR21MB01332141C3563ABBA240C566B6F20CY4PR21MB0133namp_ 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 YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUGxh aW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTI1DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjYNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTMxDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxNzc1NTkxNjcxOw0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTAzNDc5OTM3MiA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVs Nw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0 ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3 aW5kb3d0ZXh0Ij5BY3R1YWxseSB0YWtpbmcgYSBzdGVwIGJhY2sgd2hhdCBpZiB3ZSBkb27igJl0 IHdlIG92ZXJsb2FkZWQgcGFja2V0IG51bWJlciBhcyB0aGUgbm9uY2U/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5DYW4gd2U6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttYXJnaW4tbGVm dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KUHV0IHBhY2tldCBudW1iZXIgYXMgYSBz ZXBhcmF0ZSB2YXJpYWJsZSBsZW5ndGggZmllbGQgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9m IHRoZSBoZWFkZXIuIFRoaXMgYWxsb3dzIGZvciBncm93dGggYmV5b25kIDY0IGJpdHMgaW4gZnV0 dXJlIGFuZCBjb21wbGV0ZWx5IGF2b2lkcyBvc3NpZmljYXRpb24uIEZvciBzaG9ydCBsaXZlZCBm bG93cyB2YXJpYWJsZSBsZW5ndGggZW5jb2RpbmcgbGVhZHMgdG8gbWluaW1hbCBzcGFjZSBvdmVy aGVhZC4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQpQdXQgYSBzZXBhcmF0ZSBwbGFpbnRleHQgbm9uY2Ugd2hpY2ggc3RhcnRzIG91dCBhcyBh IHNlY3VyZSByYW5kb20gbnVtYmVyIGFuZCBtb25vdG9uaWNhbGx5IGluY3JlYXNlcyBhcyBzaG9y dCByYW5kb20ganVtcHMgKGV2ZXJ5IHBhY2tldCBvciBldmVyeSBmZXcgcGFja2V0cykgYW5kIGNv dWxkIHRoZW4gcm9sbG92ZXIuIFRoaXMgd2lsbCBwcmV2ZW50IGxpbmthYmlsaXR5IGFuZCBzY2Fs ZXMgdG8gbXVsdGktcGF0aCBhcyB3ZWxsLiBObyBtYWpvcg0KIGNvbXB1dGUgb3ZlcmhlYWQuIFdl IGNhbiBhbHNvIG1ha2UgdGhlIG5vbmNlIG9wdGlvbmFsIGZvciBjcnlwdG8gYWxnb3JpdGhtcyB0 aGF0IGRvIG5vdCBuZWVkIGEgbm9uY2Ugc2F2aW5nIG1vcmUgc3BhY2UuDQo8bzpwPjwvbzpwPjwv bGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+U29tZSBNU0Igb2YgdGhlIG5vbmNlIGNvdWxk IGJlIHVzZWQgZm9yIHNpZ25hbGluZyByZW9yZGVyIHRvIHRoZSBuZXR3b3JrIGlmIG5lZWRlZC4g SSBkb27igJl0IGhhdmUgdGhlIGhpc3RvcmljYWwgY29udGV4dCBmb3Igb3ZlcmxvYWRpbmcgb2Yg UE4gYXMgdGhlIG5vbmNlIHNvIHBhcmRvbiBtZSBpZiB1bi1vdmVybG9hZGluZyBvcHRpb24gd2Fz IGRpc2N1c3NlZA0KIGFuZCBydWxlZCBvdXQgYmVmb3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IFFVSUMgW21h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlByYXZlZW4g QmFsYXN1YnJhbWFuaWFuPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSA4LCAy MDE4IDU6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5u ZXQmZ3Q7OyBxdWljQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQYWNrZXQgbnVt YmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7Jmd0OyBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFj aCBwYXRoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGFsb25lIHBy ZXZlbnRzIGxpbmthYmlsaXR5IHJpZ2h0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0 OyBUaGUgcGFja2V0IG51bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFydCBhdCAxIChvciBtYXli ZSAwIDstKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHN1cHBvcnRp bmcgbXVsdGlwbGUgcGF0aHMgYXQgdGhlIHNhbWUgdGltZSBhIGdvYWw/IElmIHllcywgdGhlbiB5 ZXMgYWxsIHBhdGhzIHdpbGwgbmVlZCB0byBoYXZlIHNlcGFyYXRlIHRyYWNraW5nIGFuZCBBQ0sg c3RhdGUgYW5kIGNvbmdlc3Rpb24gY29udHJvbCBldGMuIEkgdGhvdWdodCB0aGlzIGlzIG5vdCBw YXJ0IG9mIFYxIFJGQy4gSWYgaXRzIGp1c3Qgb25lIGFkZGl0aW9uYWwgcGF0aCBmb3IgY29ubmVj dGlvbg0KIG1pZ3JhdGlvbiBzY2VuYXJpbyB0aGVuIGFsbCB5b3UgbmVlZCBpcyBhIChyYW5kb20p IGp1bXAgdG8gYSBvZmZzZXQgaW4gcGFja2V0IG51bWJlciBzcGFjZSBmb3IgdGhlIG5ldyBwYXRo IHNvIHRoYXQgdGhlIGZldyBwYWNrZXRzIGluIHRoZSBvbGQgcGF0aCBjYW4gY29udGludWUgZm9y IGEgbGl0dGxlIGJpdC4gVGhpcyB3b3JrcyB3aXRoIGp1c3Qgb25lIEFDSyBzcGFjZSBzbyBubyBp bXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0 OyAyKSBPciwgbGVhdmluZyB0aGUgcGFja2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5n IGRpZmZlcmVudCBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBz ZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBlYWNoIHBhdGguPGJyPg0KSW4gYWRkaXRpb24g aWYgdGhlIHZhbHVlIGluIHRoZSBjbGVhciB3YXMgb2JmdXNjYXRlZCB3aXRoIGFuIFhPUiB0cmFu c2Zvcm0gaXQgd2lsbCBoZWxwIHByZXZlbnQgb3NzaWZpY2F0aW9uLiBUaGUgb2JmdXNjYXRpb24g aXMgbm90IG1lYW50IHRvIGd1YXJkIGFnYWluc3QgbGF0ZXIgYW5hbHlzaXMgdGhhdCByZXZlYWxz IHRoZSBwYWNrZXQgbnVtYmVycyAtIHdoeSBkbyB3ZSBjYXJlIGFib3V0IHRoYXQuIEl0IGlzIG1l YW50IHRvIGdyZWFzZSB0aGUNCiBzcGFjZSBhbmQgbm90IG1ha2UgdGhlIG51bWJlcnMgc2VyaWFs IHNvIG1pZGRsZWJveGVzIGNhbm5vdCBhc3N1bWUgb3JkZXJpbmcgZXRjLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbGwgc2FpZCBpZiBJIGFtIGFsb25lIGluIGJlaW5nIGNvbmNlcm5lZCBhYm91 dCB0aGUgcGVyZiBoaXQgdGhlbiBJ4oCZZCBzYXkgZ28gb24gd2l0aCBvcHRpb24gMS4NCjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBRVUlDIFs8YSBocmVmPSJt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0aWFuIEh1aXRlbWE8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggMzo1NCBQTTxicj4NCjxiPlRvOjwvYj4g PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cD5PbiAyLzgvMjAxOCAxOjEzIFBNLCBNaWtlIEJpc2hvcCB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IzIgd29u4oCZdCB3b3JrLiZuYnNw OyBUaGUgcGFja2V0IG51bWJlciBpcyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwgc28geW91 IGhhdmUgdG8gZ2V0IHRvIHRoZSBwYWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRlY3J5cHQg dGhlIHBheWxvYWQuJm5ic3A7IEl0IGNhbuKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcgaW50ZXJu YWwgdG8gdGhlIGVuY3J5cHRlZCBwYWNrZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIE1h cnRpbuKAmXMgcHJvcG9zYWwsIGl04oCZcyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mIHRoZSBlbmNy eXB0ZWQgcGF5bG9hZCAod2hpY2ggcmVxdWlyZXMgbm90aGluZyB0byBhY2Nlc3MpIGFuZCBzb21l IHN0b3JlZCBzdGF0ZSBvbiBlYWNoIGVuZHBvaW50LCB3aGljaCByZXF1aXJlcyBvbmx5IHRoZSBD b25uZWN0aW9uIElEIHRvIGxvb2sgdXAuJm5ic3A7IFlvdSB3YW50IHRoZSB0aGluZyB5b3UgWE9S IGJ5IHRvIGJlIGNvbnN0YW50bHkNCiBjaGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNpZXIgdG8g bG9vayBhdCBzZXF1ZW5jZXMgb2Ygb2JmdXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQgc3RhcnQg ZHJhd2luZyBpbmZlcmVuY2VzIGFib3V0IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4mbmJzcDsgSWYg b3ZlcmhlYWQgaXMgdGhlIHByaW1hcnkgY29uY2VybiwgSSB0aGluayB0aGVyZSBhcmUgYSBjb3Vw bGUgYXBwcm9hY2hlcyB0aGF0IG1pZ2h0IGFsbG93IHlvdSB0byBwcmVjb21wdXRlIHZhbHVlcw0K IGFuZCBhbW9ydGl6ZSB0aGUgY29zdCBvZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVwLiZuYnNw OyAoQXQgdGhlIGNvc3Qgb2Yga2VlcGluZyB0aGUgdGFibGUgb2YgcHJlY29tcHV0ZWQgdmFsdWVz LCBvZiBjb3Vyc2UuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0aWxsIHRoaW5rIEphbmHi gJlzIHB1c2hpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBoZXJlOiZuYnNwOyBMZXTigJlzIGFn cmVlIG9uIGdvYWxzLCBhbmQgdGhlbiBzZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWduIHRoYXQg bWVldHMgdGhvc2UgZ29hbHMuJm5ic3A7IEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92ZXJo ZWFkIGlzIGEgZ29hbCwgd2hpY2ggSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiZuYnNwOyBJ IGFsc28gdGhpbmsNCiBJIGhlYXIgeW91IHNheWluZyB0aGF0IDEtMS41JSBvdmVyaGVhZCBpcyB0 b28gaGlnaCwgYnV0IGl0IHNvdW5kcyBsaWtlIHRoZXJl4oCZcyBsZXNzIGFncmVlbWVudCBvbiB0 aGF0LiZuYnNwOyBZb3UgYWxzbyByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNvbWUg Y2xpZW50cyB3aWxsIGNhcmUgbGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRoZXkgd2ls bCBuZXZlciBpbnRlbnRpb25hbGx5IG1pZ3JhdGUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCkkgdGhpbmsgVmljdG9yIHNhaWQgaXQgYmVzdCwgJnF1b3Q7T2JmdXNjYXRpb24gaXMganVz dCBlbmNyeXB0aW9uIGRvbmUgcG9vcmx5LiZxdW90OyBFaXRoZXIgd2UgZW5jcnlwdCwgb3Igd2Ug ZG9uJ3QuIEJ1dCB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGFuIG9iZnVzY2F0aW9uIG1pZGRs ZS1ncm91bmQuIE9iZnVzY2F0aW9uIHdvdWxkIGp1c3QgYmUgYSBzcGVlZCBidW1wLCBlYXNpbHkg YnJva2VuLiBJdCB3b24ndCBwcm92aWRlIHByaXZhY3ksIGFuZCBpdCB3b24ndA0KIHByZXZlbnQg bGlua2FiaWxpdHkuPGJyPg0KPGJyPg0KQXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCB0aGVyZSBh cmUgb25seSB0d28gZGVzaWducyB0aGF0IHByZXZlbnQgbGlua2FiaWxpdHk6PGJyPg0KPGJyPg0K MSkgTWFydGluJ3MgUFIsIGluIHdoaWNoIHRoZSBwYWNrZXQgbnVtYmVyIGlzIGVuY3J5cHRlZCB1 c2luZyBzZW5zaWJsZSBjcnlwdG87PGJyPg0KPGJyPg0KMikgT3IsIGxlYXZpbmcgdGhlIHBhY2tl dCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1dCB1c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlvbiBjb250 ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBm b3IgZWFjaCBwYXRoLjxicj4NCjxicj4NClRoZSBzZWNvbmQgb3B0aW9uIHJlcXVpcmVzIG1vcmUg Y29tcHV0YXRpb24gd2hlbiBleHBsaWNpdGx5IHNldHRpbmcgdXAgYSBuZXcgcGF0aC4gVGhlIGNv bm5lY3Rpb24gSUQgd291bGQgYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSAmcXVvdDtzYWx0JnF1b3Q7 IHdoZW4gZGVyaXZpbmcgY29ubmVjdGlvbiBjb250ZXh0cy4gVGhlIHBhY2tldCBudW1iZXIgb24g ZWFjaCBwYXRoIHdpbGwgc3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7LSkuIFRoaXMgcmVxdWlyZXMg bWFpbnRhaW5pbmcNCiBzZXBhcmF0ZSBTQUNLIGRhc2hib2FyZHMgZm9yIGVhY2ggcGF0aC9Db25u ZWN0aW9uLUlELCBhbmQgY29uc3RyYWluaW5nIEFDSyB0byBiZSBwZXIvcGF0aCwgb3IgYWx0ZXJu YXRpdmVseSBhZGRpbmcgYSBQQVRILUFDSyBmcmFtZSB0aGF0IGluZGljYXRlcyB0aGUgcGF0aCBm b3Igd2hpY2ggcGFja2V0cyBhcmUgYWNrZWQuPGJyPg0KPGJyPg0KVGhlIHByb3MgYW5kIGNvbnMg b2YgdGhlIHR3byBvcHRpb25zIGFyZSBlYXN5IHRvIGdldDo8YnI+DQo8YnI+DQoxKSBPcHRpb24g MiBkb2VzIG5vdCByZXF1aXJlIHRoZSBjb3N0IG9mIGVuY3J5cHRpbmcgZXZlcnkgcGFja2V0LCB0 aHVzIHBlciBwYWNrZXQgcHJvY2Vzc2luZyB3aWxsIGJlIG1heWJlIDElIGZhc3RlciB0aGFuIG9w dGlvbiAxLg0KPGJyPg0KPGJyPg0KMikgT3B0aW9uIDIgcmVxdWlyZXMgY29tcHV0aW5nIGVuY3J5 cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgd2hpY2ggaXMgbW9yZSBjb21wbGV4IHRoYW4g b3B0aW9uIDEsIGJ1dCB0aGUgY29zdCB3aWxsIGJlIGFtb3J0aXplZCBvdmVyIHRoZSBkdXJhdGlv biBvZiB0aGUgcGF0aC48YnI+DQo8YnI+DQozKSBPcHRpb24gMiByZXF1aXJlcyBtb3JlIGNvbXBs ZXggZGF0YSBzdHJ1Y3R1cmVzIGFuZCBBQ0sgbWFuYWdlbWVudCwgdGh1cyBpbmNyZWFzaW5nIHRo ZSBjaGFuY2VzIHRoYXQgc29tZXRoaW5nIGdvZXMgd3JvbmcuPGJyPg0KPGJyPg0KNCkgT3B0aW9u IDIgZG9lcyBub3RoaW5nIGFnYWluc3QgcGFja2V0IG51bWJlciBvc3NpZmljYXRpb24uIFRoZSBw YWNrZXQgbnVtYmVyIGVmZmVjdGl2ZWx5IGJlY29tZXMgcGFydCBvZiB0aGUgaW52YXJpYW50cy48 YnI+DQo8YnI+DQpJbiBzaG9ydCwgdGhlIG9ubHkgYWR2YW50YWdlIG9mIG9wdGlvbiAyIGlzIHRv IGF2b2lkIGEgc2luZ2xlIHN5bW1ldHJpYyBlbmNyeXB0aW9uIG9wZXJhdGlvbiBwZXIgcGFja2V0 LCB3aGlsZSBtYWtpbmcgdGhlIGNvZGUgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXgsIGFuZCBh dCB0aGUgY29zdCBvZiBub3QgcHJvdGVjdGluZyBhZ2FpbnN0IFBOIG9zc2lmaWNhdGlvbi4gVGhl IHdheSBJIHNlZSB0aGF0LCB0aGVyZSBpcyBoYXJkbHkgYW55IGRlYmF0ZS48YnI+DQo8YnI+DQot LSBDaHJpc3RpYW4gSHVpdGVtYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CY4PR21MB01332141C3563ABBA240C566B6F20CY4PR21MB0133namp_-- From nobody Thu Feb 8 22:19:28 2018 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 48427126D45 for ; Thu, 8 Feb 2018 22:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.41 X-Spam-Level: X-Spam-Status: No, score=-1.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 M3BMgihjf4s2 for ; Thu, 8 Feb 2018 22:19:24 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0139.outbound.protection.outlook.com [104.47.38.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB61124319 for ; Thu, 8 Feb 2018 22:19:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6RDBnrmzgIn1KGBOUi4B2Sr67ONyEw5firMB/13I1Ac=; b=LTGpxR6Z8ZrpS1FYAcJvZvgiX5/6eJHbghG/2+7YUJYkpLWebv948gJ/FDNfUlMC2+J+eN6k9KcWrMcjrwZJY4GfaWOpqxOcwIWGPdnYFB1Q/b85y0gWo7GmUgmpHecvTCc4EWIcU4nkUv6Ytj9VFiorN7z9pY8MVH2A/rqLZeQ= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2766.namprd08.prod.outlook.com (10.173.239.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 9 Feb 2018 06:19:18 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([fe80::5410:deca:3ee5:983f]) by MWHPR08MB2432.namprd08.prod.outlook.com ([fe80::5410:deca:3ee5:983f%16]) with mapi id 15.20.0485.009; Fri, 9 Feb 2018 06:19:18 +0000 From: Mike Bishop To: Praveen Balasubramanian , huitema , "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW33YzpoOLX0UU2dbBSG8l3vaKOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADXOQCAAGavgIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACabIIAAVcAAgAAUZQCAAA5oAIAAEIEAgABFkgCAAAUSgIAABUkAgAABmYCAAAaRgIAAC4qAgACi8QCAAemoIIAAEAEAgAAgsACAAEARAIAACIow Date: Fri, 9 Feb 2018 06:19:18 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2601:600:8080:5a28:2090:623a:734:298e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2766; 7:XUOHnQiMVBpjhLKQlekPLMcTMZ7/tvN5818WZo25zR1S4AJ0y/1leKWB3G3d14LitaRqgGi8CNnTd2XgUtD6yytNujOyptpjY5fJYQSEXrt/nT0gkfxWfYHPtMfdsRnULZ5fIGIQ2Lv62EuJU+gcz+qi5Z6kv26RjqkTUja30S7pfccEFnYpQdW8DutTAa2RE4/kcdOotl+ES+VpWOo27O4XXU2eSYS6e9T8wX3tW7PHCSct6lDO5jOnKZJ/WI+j x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c1aaf8a7-43b1-4ccc-b45c-08d56f850d47 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB2766; x-ms-traffictypediagnostic: MWHPR08MB2766: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231101)(2400082)(944501161)(6041288)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(2016111802025)(6043046)(6072148)(201708071742011); SRVR:MWHPR08MB2766; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB2766; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(39830400003)(346002)(39380400002)(396003)(377424004)(189003)(199004)(6506007)(74482002)(316002)(110136005)(186003)(5250100002)(229853002)(2501003)(105586002)(68736007)(8676002)(25786009)(81166006)(7736002)(93886005)(86362001)(6116002)(106356001)(790700001)(7696005)(2900100001)(9686003)(55016002)(3280700002)(236005)(478600001)(8666007)(53546011)(3660700001)(6436002)(74316002)(8936002)(14454004)(6306002)(7116003)(6246003)(5660300001)(54896002)(102836004)(561944003)(76176011)(81156014)(3480700004)(1511001)(2950100002)(53936002)(99286004)(97736004)(2906002)(59450400001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2766; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: TeqNnBH+LqvYC1jH1rPClT0ACZaWc7jbuMyFhHfzSw9CMqBs4J+IFiFaDJcjw+jVktQxiLP4WCgbcrN3wcpclQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432EAF7D176BBFCA28DF3FFDAF20MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: c1aaf8a7-43b1-4ccc-b45c-08d56f850d47 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 06:19:18.4898 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2766 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, 09 Feb 2018 06:19:27 -0000 --_000_MWHPR08MB2432EAF7D176BBFCA28DF3FFDAF20MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IGNhbuKAmXQgc2FmZWx5IHJldXNlIHRoZSBjb21iaW5hdGlvbiBvZiBub25jZSBhbmQga2V5 LCBJSVVDLiAgU2luY2Uga2V5IHJvbGxvdmVyIGlzIGluZnJlcXVlbnQsIHRoZSBub25jZSBoYXMg dG8gY2hhbmdlIGV2ZXJ5IHBhY2tldCBhbmQgYmUgZ3VhcmFudGVlZCB1bmlxdWUgb3ZlciB0aGUg bGlmZXRpbWUgb2YsIGlmIG5vdCB0aGUgY29ubmVjdGlvbiwgYXQgbGVhc3QgdGhlIGN1cnJlbnQg a2V5LiAgU2luY2UgcGFja2V0IG51bWJlcnMgYWxzbyBkb27igJl0IHJlcGVhdCBvdmVyIHRoZSBs aWZldGltZSBvZiB0aGUgY29ubmVjdGlvbiwgSSB0aGluayB1c2luZyBvbmUgYXMgdGhlIHZhcmlh YmxlIHBhcnQgb2YgdGhlIG90aGVyIHdhcyBqdXN0IHRha2luZyBhZHZhbnRhZ2Ugb2YgdGhlIGFs aWdubWVudC4NCg0KSSBkb27igJl0IHRoaW5rIGhhdmluZyBhIHJhbmRvbWl6ZWQgc3RhcnRpbmcg dmFsdWUgYW5kIGluY3JlbWVudGluZyBpcyBuZWNlc3NhcmlseSBhbnkgYmV0dGVyIHRoYW4gZXhw b3NpbmcgdGhlIHBhY2tldCBudW1iZXIuICBIYXZpbmcgYSBQUk5HIHNlZWQgZXN0YWJsaXNoZWQg ZHVyaW5nIHRoZSBoYW5kc2hha2UgYW5kIG1ha2luZyB0aGUgdmlzaWJsZSB0aGluZyB0aGUgbmV4 dCByYW5kb20gb3V0cHV0IHNlZW1zIHBvdGVudGlhbGx5IGludGVyZXN0aW5nLCBidXQgSeKAmWQg d2FudCBvdXIgbW9yZSBjcnlwdG8tbWluZGVkIGZyaWVuZHMgdG8gY29tbWVudC4gIEkgdGhpbmsg dGhlIHJlYWwgaXNzdWUgd291bGQgYmUgZ3VhcmFudGVlcyBhYm91dCBuZXZlci1yZXBlYXRpbmcg ZnJvbSB0aGUgUFJORywgcGFydGljdWxhcmx5IGFzIHlvdSBkb27igJl0IGhhdmUgZ3VhcmFudGVl cyBhYm91dCB5b3VyIHBlZXLigJlzIGltcGxlbWVudGF0aW9uLiAgQSBkZWZpbmVkIGtleSBkZXJp dmF0aW9uIGFuZCBhIGNvdW50ZXIgY2FuIGJlIHZlcmlmaWVkIGluIHRoZSBwcm90b2NvbCwgaW5k ZXBlbmRlbnQgb2YgaG93IGdvb2QgdGhlIHBlZXLigJlzIFBSTkcgaXMuDQoNCkZyb206IFFVSUMg W21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQcmF2ZWVuIEJhbGFz dWJyYW1hbmlhbg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggOTo0MCBQTQ0KVG86 IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBS RTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCkFjdHVhbGx5IHRha2luZyBhIHN0ZXAgYmFj ayB3aGF0IGlmIHdlIGRvbuKAmXQgd2Ugb3ZlcmxvYWRlZCBwYWNrZXQgbnVtYmVyIGFzIHRoZSBu b25jZT8NCg0KQ2FuIHdlOg0KDQogIDEuICBQdXQgcGFja2V0IG51bWJlciBhcyBhIHNlcGFyYXRl IHZhcmlhYmxlIGxlbmd0aCBmaWVsZCBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhl YWRlci4gVGhpcyBhbGxvd3MgZm9yIGdyb3d0aCBiZXlvbmQgNjQgYml0cyBpbiBmdXR1cmUgYW5k IGNvbXBsZXRlbHkgYXZvaWRzIG9zc2lmaWNhdGlvbi4gRm9yIHNob3J0IGxpdmVkIGZsb3dzIHZh cmlhYmxlIGxlbmd0aCBlbmNvZGluZyBsZWFkcyB0byBtaW5pbWFsIHNwYWNlIG92ZXJoZWFkLg0K ICAyLiAgUHV0IGEgc2VwYXJhdGUgcGxhaW50ZXh0IG5vbmNlIHdoaWNoIHN0YXJ0cyBvdXQgYXMg YSBzZWN1cmUgcmFuZG9tIG51bWJlciBhbmQgbW9ub3RvbmljYWxseSBpbmNyZWFzZXMgYXMgc2hv cnQgcmFuZG9tIGp1bXBzIChldmVyeSBwYWNrZXQgb3IgZXZlcnkgZmV3IHBhY2tldHMpIGFuZCBj b3VsZCB0aGVuIHJvbGxvdmVyLiBUaGlzIHdpbGwgcHJldmVudCBsaW5rYWJpbGl0eSBhbmQgc2Nh bGVzIHRvIG11bHRpLXBhdGggYXMgd2VsbC4gTm8gbWFqb3IgY29tcHV0ZSBvdmVyaGVhZC4gV2Ug Y2FuIGFsc28gbWFrZSB0aGUgbm9uY2Ugb3B0aW9uYWwgZm9yIGNyeXB0byBhbGdvcml0aG1zIHRo YXQgZG8gbm90IG5lZWQgYSBub25jZSBzYXZpbmcgbW9yZSBzcGFjZS4NCg0KU29tZSBNU0Igb2Yg dGhlIG5vbmNlIGNvdWxkIGJlIHVzZWQgZm9yIHNpZ25hbGluZyByZW9yZGVyIHRvIHRoZSBuZXR3 b3JrIGlmIG5lZWRlZC4gSSBkb27igJl0IGhhdmUgdGhlIGhpc3RvcmljYWwgY29udGV4dCBmb3Ig b3ZlcmxvYWRpbmcgb2YgUE4gYXMgdGhlIG5vbmNlIHNvIHBhcmRvbiBtZSBpZiB1bi1vdmVybG9h ZGluZyBvcHRpb24gd2FzIGRpc2N1c3NlZCBhbmQgcnVsZWQgb3V0IGJlZm9yZS4NCg0KRnJvbTog UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFByYXZlZW4g QmFsYXN1YnJhbWFuaWFuDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCA1OjUxIFBN DQpUbzogaHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVtYUBodWl0ZW1h Lm5ldD4+OyBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUkU6 IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQo+PiBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0 IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRoDQpUaGlzIGFsb25lIHByZXZlbnRzIGxpbmthYmlsaXR5 IHJpZ2h0Pw0KDQo+PiBUaGUgcGFja2V0IG51bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFydCBh dCAxIChvciBtYXliZSAwIDstKS4NCklzIHN1cHBvcnRpbmcgbXVsdGlwbGUgcGF0aHMgYXQgdGhl IHNhbWUgdGltZSBhIGdvYWw/IElmIHllcywgdGhlbiB5ZXMgYWxsIHBhdGhzIHdpbGwgbmVlZCB0 byBoYXZlIHNlcGFyYXRlIHRyYWNraW5nIGFuZCBBQ0sgc3RhdGUgYW5kIGNvbmdlc3Rpb24gY29u dHJvbCBldGMuIEkgdGhvdWdodCB0aGlzIGlzIG5vdCBwYXJ0IG9mIFYxIFJGQy4gSWYgaXRzIGp1 c3Qgb25lIGFkZGl0aW9uYWwgcGF0aCBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24gc2NlbmFyaW8g dGhlbiBhbGwgeW91IG5lZWQgaXMgYSAocmFuZG9tKSBqdW1wIHRvIGEgb2Zmc2V0IGluIHBhY2tl dCBudW1iZXIgc3BhY2UgZm9yIHRoZSBuZXcgcGF0aCBzbyB0aGF0IHRoZSBmZXcgcGFja2V0cyBp biB0aGUgb2xkIHBhdGggY2FuIGNvbnRpbnVlIGZvciBhIGxpdHRsZSBiaXQuIFRoaXMgd29ya3Mg d2l0aCBqdXN0IG9uZSBBQ0sgc3BhY2Ugc28gbm8gaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS4N Cg0KPj4gMikgT3IsIGxlYXZpbmcgdGhlIHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1dCB1 c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQgdXNp bmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRoLg0KSW4gYWRkaXRpb24g aWYgdGhlIHZhbHVlIGluIHRoZSBjbGVhciB3YXMgb2JmdXNjYXRlZCB3aXRoIGFuIFhPUiB0cmFu c2Zvcm0gaXQgd2lsbCBoZWxwIHByZXZlbnQgb3NzaWZpY2F0aW9uLiBUaGUgb2JmdXNjYXRpb24g aXMgbm90IG1lYW50IHRvIGd1YXJkIGFnYWluc3QgbGF0ZXIgYW5hbHlzaXMgdGhhdCByZXZlYWxz IHRoZSBwYWNrZXQgbnVtYmVycyAtIHdoeSBkbyB3ZSBjYXJlIGFib3V0IHRoYXQuIEl0IGlzIG1l YW50IHRvIGdyZWFzZSB0aGUgc3BhY2UgYW5kIG5vdCBtYWtlIHRoZSBudW1iZXJzIHNlcmlhbCBz byBtaWRkbGVib3hlcyBjYW5ub3QgYXNzdW1lIG9yZGVyaW5nIGV0Yy4NCg0KQWxsIHNhaWQgaWYg SSBhbSBhbG9uZSBpbiBiZWluZyBjb25jZXJuZWQgYWJvdXQgdGhlIHBlcmYgaGl0IHRoZW4gSeKA mWQgc2F5IGdvIG9uIHdpdGggb3B0aW9uIDEuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gSHVpdGVtYQ0KU2VudDogVGh1 cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggMzo1NCBQTQ0KVG86IHF1aWNAaWV0Zi5vcmc8bWFpbHRv OnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoN Cg0KT24gMi84LzIwMTggMToxMyBQTSwgTWlrZSBCaXNob3Agd3JvdGU6DQojMiB3b27igJl0IHdv cmsuICBUaGUgcGFja2V0IG51bWJlciBpcyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwgc28g eW91IGhhdmUgdG8gZ2V0IHRvIHRoZSBwYWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRlY3J5 cHQgdGhlIHBheWxvYWQuICBJdCBjYW7igJl0IGJlIGJhc2VkIG9uIGFueXRoaW5nIGludGVybmFs IHRvIHRoZSBlbmNyeXB0ZWQgcGFja2V0Lg0KDQpJbiBNYXJ0aW7igJlzIHByb3Bvc2FsLCBpdOKA mXMgdXNpbmcgYSBjb21iaW5hdGlvbiBvZiB0aGUgZW5jcnlwdGVkIHBheWxvYWQgKHdoaWNoIHJl cXVpcmVzIG5vdGhpbmcgdG8gYWNjZXNzKSBhbmQgc29tZSBzdG9yZWQgc3RhdGUgb24gZWFjaCBl bmRwb2ludCwgd2hpY2ggcmVxdWlyZXMgb25seSB0aGUgQ29ubmVjdGlvbiBJRCB0byBsb29rIHVw LiAgWW91IHdhbnQgdGhlIHRoaW5nIHlvdSBYT1IgYnkgdG8gYmUgY29uc3RhbnRseSBjaGFuZ2lu Zywgb3IgaXQgYmVjb21lcyBlYXNpZXIgdG8gbG9vayBhdCBzZXF1ZW5jZXMgb2Ygb2JmdXNjYXRl ZCBwYWNrZXQgbnVtYmVycyBhbmQgc3RhcnQgZHJhd2luZyBpbmZlcmVuY2VzIGFib3V0IHdoYXQg dGhlIFhPUiB2YWx1ZSBpcy4gIElmIG92ZXJoZWFkIGlzIHRoZSBwcmltYXJ5IGNvbmNlcm4sIEkg dGhpbmsgdGhlcmUgYXJlIGEgY291cGxlIGFwcHJvYWNoZXMgdGhhdCBtaWdodCBhbGxvdyB5b3Ug dG8gcHJlY29tcHV0ZSB2YWx1ZXMgYW5kIGFtb3J0aXplIHRoZSBjb3N0IG9mIGRvaW5nIHRoZSBl bmNyeXB0aW9uIHN0ZXAuICAoQXQgdGhlIGNvc3Qgb2Yga2VlcGluZyB0aGUgdGFibGUgb2YgcHJl Y29tcHV0ZWQgdmFsdWVzLCBvZiBjb3Vyc2UuKQ0KDQpJIHN0aWxsIHRoaW5rIEphbmHigJlzIHB1 c2hpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBoZXJlOiAgTGV04oCZcyBhZ3JlZSBvbiBnb2Fs cywgYW5kIHRoZW4gc2VlIGlmIHdlIGNhbiBjcmFmdCBhIGRlc2lnbiB0aGF0IG1lZXRzIHRob3Nl IGdvYWxzLiAgSSBoZWFyIHlvdSBzYXlpbmcgdGhhdCBsb3cgb3ZlcmhlYWQgaXMgYSBnb2FsLCB3 aGljaCBJIHRoaW5rIHdlIGNhbiBhbGwgYWdyZWUgb24uICBJIGFsc28gdGhpbmsgSSBoZWFyIHlv dSBzYXlpbmcgdGhhdCAxLTEuNSUgb3ZlcmhlYWQgaXMgdG9vIGhpZ2gsIGJ1dCBpdCBzb3VuZHMg bGlrZSB0aGVyZeKAmXMgbGVzcyBhZ3JlZW1lbnQgb24gdGhhdC4gIFlvdSBhbHNvIHJhaXNlIGFu IGludGVyZXN0aW5nIHBvaW50IHRoYXQgc29tZSBjbGllbnRzIHdpbGwgY2FyZSBsZXNzIGFib3V0 IGxpbmthYmlsaXR5IGJlY2F1c2UgdGhleSB3aWxsIG5ldmVyIGludGVudGlvbmFsbHkgbWlncmF0 ZS4NCg0KSSB0aGluayBWaWN0b3Igc2FpZCBpdCBiZXN0LCAiT2JmdXNjYXRpb24gaXMganVzdCBl bmNyeXB0aW9uIGRvbmUgcG9vcmx5LiIgRWl0aGVyIHdlIGVuY3J5cHQsIG9yIHdlIGRvbid0LiBC dXQgdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhbiBvYmZ1c2NhdGlvbiBtaWRkbGUtZ3JvdW5k LiBPYmZ1c2NhdGlvbiB3b3VsZCBqdXN0IGJlIGEgc3BlZWQgYnVtcCwgZWFzaWx5IGJyb2tlbi4g SXQgd29uJ3QgcHJvdmlkZSBwcml2YWN5LCBhbmQgaXQgd29uJ3QgcHJldmVudCBsaW5rYWJpbGl0 eS4NCg0KQXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCB0aGVyZSBhcmUgb25seSB0d28gZGVzaWdu cyB0aGF0IHByZXZlbnQgbGlua2FiaWxpdHk6DQoNCjEpIE1hcnRpbidzIFBSLCBpbiB3aGljaCB0 aGUgcGFja2V0IG51bWJlciBpcyBlbmNyeXB0ZWQgdXNpbmcgc2Vuc2libGUgY3J5cHRvOw0KDQoy KSBPciwgbGVhdmluZyB0aGUgcGFja2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5nIGRp ZmZlcmVudCBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBzZXBh cmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBlYWNoIHBhdGguDQoNClRoZSBzZWNvbmQgb3B0aW9u IHJlcXVpcmVzIG1vcmUgY29tcHV0YXRpb24gd2hlbiBleHBsaWNpdGx5IHNldHRpbmcgdXAgYSBu ZXcgcGF0aC4gVGhlIGNvbm5lY3Rpb24gSUQgd291bGQgYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSAi c2FsdCIgd2hlbiBkZXJpdmluZyBjb25uZWN0aW9uIGNvbnRleHRzLiBUaGUgcGFja2V0IG51bWJl ciBvbiBlYWNoIHBhdGggd2lsbCBzdGFydCBhdCAxIChvciBtYXliZSAwIDstKS4gVGhpcyByZXF1 aXJlcyBtYWludGFpbmluZyBzZXBhcmF0ZSBTQUNLIGRhc2hib2FyZHMgZm9yIGVhY2ggcGF0aC9D b25uZWN0aW9uLUlELCBhbmQgY29uc3RyYWluaW5nIEFDSyB0byBiZSBwZXIvcGF0aCwgb3IgYWx0 ZXJuYXRpdmVseSBhZGRpbmcgYSBQQVRILUFDSyBmcmFtZSB0aGF0IGluZGljYXRlcyB0aGUgcGF0 aCBmb3Igd2hpY2ggcGFja2V0cyBhcmUgYWNrZWQuDQoNClRoZSBwcm9zIGFuZCBjb25zIG9mIHRo ZSB0d28gb3B0aW9ucyBhcmUgZWFzeSB0byBnZXQ6DQoNCjEpIE9wdGlvbiAyIGRvZXMgbm90IHJl cXVpcmUgdGhlIGNvc3Qgb2YgZW5jcnlwdGluZyBldmVyeSBwYWNrZXQsIHRodXMgcGVyIHBhY2tl dCBwcm9jZXNzaW5nIHdpbGwgYmUgbWF5YmUgMSUgZmFzdGVyIHRoYW4gb3B0aW9uIDEuDQoNCjIp IE9wdGlvbiAyIHJlcXVpcmVzIGNvbXB1dGluZyBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNo IHBhdGgsIHdoaWNoIGlzIG1vcmUgY29tcGxleCB0aGFuIG9wdGlvbiAxLCBidXQgdGhlIGNvc3Qg d2lsbCBiZSBhbW9ydGl6ZWQgb3ZlciB0aGUgZHVyYXRpb24gb2YgdGhlIHBhdGguDQoNCjMpIE9w dGlvbiAyIHJlcXVpcmVzIG1vcmUgY29tcGxleCBkYXRhIHN0cnVjdHVyZXMgYW5kIEFDSyBtYW5h Z2VtZW50LCB0aHVzIGluY3JlYXNpbmcgdGhlIGNoYW5jZXMgdGhhdCBzb21ldGhpbmcgZ29lcyB3 cm9uZy4NCg0KNCkgT3B0aW9uIDIgZG9lcyBub3RoaW5nIGFnYWluc3QgcGFja2V0IG51bWJlciBv c3NpZmljYXRpb24uIFRoZSBwYWNrZXQgbnVtYmVyIGVmZmVjdGl2ZWx5IGJlY29tZXMgcGFydCBv ZiB0aGUgaW52YXJpYW50cy4NCg0KSW4gc2hvcnQsIHRoZSBvbmx5IGFkdmFudGFnZSBvZiBvcHRp b24gMiBpcyB0byBhdm9pZCBhIHNpbmdsZSBzeW1tZXRyaWMgZW5jcnlwdGlvbiBvcGVyYXRpb24g cGVyIHBhY2tldCwgd2hpbGUgbWFraW5nIHRoZSBjb2RlIHNpZ25pZmljYW50bHkgbW9yZSBjb21w bGV4LCBhbmQgYXQgdGhlIGNvc3Qgb2Ygbm90IHByb3RlY3RpbmcgYWdhaW5zdCBQTiBvc3NpZmlj YXRpb24uIFRoZSB3YXkgSSBzZWUgdGhhdCwgdGhlcmUgaXMgaGFyZGx5IGFueSBkZWJhdGUuDQoN Ci0tIENocmlzdGlhbiBIdWl0ZW1hDQo= --_000_MWHPR08MB2432EAF7D176BBFCA28DF3FFDAF20MWHPR08MB2432namp_ 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 YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUGxh aW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDoxOTU2MjY5ODg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0ODY5 MDA3NTI7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTc3NTU5MTY3MTsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwMzQ3OTkzNzIgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0 O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwx OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTps ZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0i d2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6d2luZG93dGV4dCI+WW91IGNhbuKAmXQgc2FmZWx5IHJldXNlIHRoZSBjb21iaW5hdGlvbiBv ZiBub25jZSBhbmQga2V5LCBJSVVDLiZuYnNwOyBTaW5jZSBrZXkgcm9sbG92ZXIgaXMgaW5mcmVx dWVudCwgdGhlIG5vbmNlIGhhcyB0byBjaGFuZ2UgZXZlcnkgcGFja2V0IGFuZCBiZSBndWFyYW50 ZWVkIHVuaXF1ZSBvdmVyIHRoZSBsaWZldGltZSBvZiwgaWYgbm90IHRoZSBjb25uZWN0aW9uLA0K IGF0IGxlYXN0IHRoZSBjdXJyZW50IGtleS4mbmJzcDsgU2luY2UgcGFja2V0IG51bWJlcnMgYWxz byBkb27igJl0IHJlcGVhdCBvdmVyIHRoZSBsaWZldGltZSBvZiB0aGUgY29ubmVjdGlvbiwgSSB0 aGluayB1c2luZyBvbmUgYXMgdGhlIHZhcmlhYmxlIHBhcnQgb2YgdGhlIG90aGVyIHdhcyBqdXN0 IHRha2luZyBhZHZhbnRhZ2Ugb2YgdGhlIGFsaWdubWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPkkgZG9u4oCZdCB0aGluayBoYXZpbmcgYSByYW5kb21pemVk IHN0YXJ0aW5nIHZhbHVlIGFuZCBpbmNyZW1lbnRpbmcgaXMgbmVjZXNzYXJpbHkgYW55IGJldHRl ciB0aGFuIGV4cG9zaW5nIHRoZSBwYWNrZXQgbnVtYmVyLiZuYnNwOyBIYXZpbmcgYSBQUk5HIHNl ZWQgZXN0YWJsaXNoZWQgZHVyaW5nIHRoZSBoYW5kc2hha2UgYW5kIG1ha2luZyB0aGUgdmlzaWJs ZSB0aGluZw0KIHRoZSBuZXh0IHJhbmRvbSBvdXRwdXQgc2VlbXMgcG90ZW50aWFsbHkgaW50ZXJl c3RpbmcsIGJ1dCBJ4oCZZCB3YW50IG91ciBtb3JlIGNyeXB0by1taW5kZWQgZnJpZW5kcyB0byBj b21tZW50LiZuYnNwOyBJIHRoaW5rIHRoZSByZWFsIGlzc3VlIHdvdWxkIGJlIGd1YXJhbnRlZXMg YWJvdXQgbmV2ZXItcmVwZWF0aW5nIGZyb20gdGhlIFBSTkcsIHBhcnRpY3VsYXJseSBhcyB5b3Ug ZG9u4oCZdCBoYXZlIGd1YXJhbnRlZXMgYWJvdXQgeW91ciBwZWVy4oCZcyBpbXBsZW1lbnRhdGlv bi4mbmJzcDsNCiBBIGRlZmluZWQga2V5IGRlcml2YXRpb24gYW5kIGEgY291bnRlciBjYW4gYmUg dmVyaWZpZWQgaW4gdGhlIHByb3RvY29sLCBpbmRlcGVuZGVudCBvZiBob3cgZ29vZCB0aGUgcGVl cuKAmXMgUFJORyBpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjxicj4N CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCA5OjQwIFBNPGJyPg0KPGI+ VG86PC9iPiBodWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0OzsgcXVpY0BpZXRmLm9y Zzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQiPkFjdHVhbGx5IHRha2luZyBhIHN0ZXAgYmFjayB3aGF0IGlmIHdlIGRv buKAmXQgd2Ugb3ZlcmxvYWRlZCBwYWNrZXQgbnVtYmVyIGFzIHRoZSBub25jZT88bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkNhbiB3ZTo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzMiPlB1dCBwYWNrZXQgbnVtYmVyIGFzIGEgc2VwYXJhdGUgdmFyaWFibGUgbGVu Z3RoIGZpZWxkIGluIHRoZSBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0aGUgaGVhZGVyLiBUaGlzIGFs bG93cyBmb3IgZ3Jvd3RoIGJleW9uZCA2NCBiaXRzIGluIGZ1dHVyZSBhbmQgY29tcGxldGVseSBh dm9pZHMgb3NzaWZpY2F0aW9uLiBGb3Igc2hvcnQNCiBsaXZlZCBmbG93cyB2YXJpYWJsZSBsZW5n dGggZW5jb2RpbmcgbGVhZHMgdG8gbWluaW1hbCBzcGFjZSBvdmVyaGVhZC4gPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tbGlz dDpsMSBsZXZlbDEgbGZvMyI+UHV0IGEgc2VwYXJhdGUgcGxhaW50ZXh0IG5vbmNlIHdoaWNoIHN0 YXJ0cyBvdXQgYXMgYSBzZWN1cmUgcmFuZG9tIG51bWJlciBhbmQgbW9ub3RvbmljYWxseSBpbmNy ZWFzZXMgYXMgc2hvcnQgcmFuZG9tIGp1bXBzIChldmVyeSBwYWNrZXQgb3IgZXZlcnkgZmV3IHBh Y2tldHMpIGFuZCBjb3VsZCB0aGVuIHJvbGxvdmVyLiBUaGlzDQogd2lsbCBwcmV2ZW50IGxpbmth YmlsaXR5IGFuZCBzY2FsZXMgdG8gbXVsdGktcGF0aCBhcyB3ZWxsLiBObyBtYWpvciBjb21wdXRl IG92ZXJoZWFkLiBXZSBjYW4gYWxzbyBtYWtlIHRoZSBub25jZSBvcHRpb25hbCBmb3IgY3J5cHRv IGFsZ29yaXRobXMgdGhhdCBkbyBub3QgbmVlZCBhIG5vbmNlIHNhdmluZyBtb3JlIHNwYWNlLg0K PG86cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPlNvbWUgTVNCIG9mIHRo ZSBub25jZSBjb3VsZCBiZSB1c2VkIGZvciBzaWduYWxpbmcgcmVvcmRlciB0byB0aGUgbmV0d29y ayBpZiBuZWVkZWQuIEkgZG9u4oCZdCBoYXZlIHRoZSBoaXN0b3JpY2FsIGNvbnRleHQgZm9yIG92 ZXJsb2FkaW5nIG9mIFBOIGFzIHRoZSBub25jZSBzbyBwYXJkb24gbWUgaWYgdW4tb3ZlcmxvYWRp bmcgb3B0aW9uIHdhcyBkaXNjdXNzZWQNCiBhbmQgcnVsZWQgb3V0IGJlZm9yZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86 cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UHJhdmVlbiBC YWxhc3VicmFtYW5pYW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIw MTggNTo1MSBQTTxicj4NCjxiPlRvOjwvYj4gaHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1 aXRlbWFAaHVpdGVtYS5uZXQiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OzsNCjxhIGhyZWY9 Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tl dCBzZXF1ZW5jZXMgZm9yIGVhY2ggcGF0aDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyBhbG9uZSBwcmV2ZW50cyBsaW5rYWJpbGl0eSByaWdodD88bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OyZndDsgVGhlIHBhY2tldCBudW1iZXIgb24gZWFjaCBwYXRoIHdpbGwg c3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7LSkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JcyBzdXBwb3J0aW5nIG11bHRpcGxlIHBhdGhzIGF0IHRoZSBzYW1lIHRpbWUgYSBn b2FsPyBJZiB5ZXMsIHRoZW4geWVzIGFsbCBwYXRocyB3aWxsIG5lZWQgdG8gaGF2ZSBzZXBhcmF0 ZSB0cmFja2luZyBhbmQgQUNLIHN0YXRlIGFuZCBjb25nZXN0aW9uIGNvbnRyb2wgZXRjLiBJIHRo b3VnaHQgdGhpcyBpcyBub3QgcGFydCBvZiBWMSBSRkMuIElmIGl0cyBqdXN0IG9uZSBhZGRpdGlv bmFsIHBhdGggZm9yIGNvbm5lY3Rpb24NCiBtaWdyYXRpb24gc2NlbmFyaW8gdGhlbiBhbGwgeW91 IG5lZWQgaXMgYSAocmFuZG9tKSBqdW1wIHRvIGEgb2Zmc2V0IGluIHBhY2tldCBudW1iZXIgc3Bh Y2UgZm9yIHRoZSBuZXcgcGF0aCBzbyB0aGF0IHRoZSBmZXcgcGFja2V0cyBpbiB0aGUgb2xkIHBh dGggY2FuIGNvbnRpbnVlIGZvciBhIGxpdHRsZSBiaXQuIFRoaXMgd29ya3Mgd2l0aCBqdXN0IG9u ZSBBQ0sgc3BhY2Ugc28gbm8gaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jmd0OyZndDsgMikgT3IsIGxlYXZpbmcgdGhlIHBhY2tldCBudW1iZXIgaW4g dGhlIGNsZWFyIGJ1dCB1c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFj aCBwYXRoLCBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRo Ljxicj4NCkluIGFkZGl0aW9uIGlmIHRoZSB2YWx1ZSBpbiB0aGUgY2xlYXIgd2FzIG9iZnVzY2F0 ZWQgd2l0aCBhbiBYT1IgdHJhbnNmb3JtIGl0IHdpbGwgaGVscCBwcmV2ZW50IG9zc2lmaWNhdGlv bi4gVGhlIG9iZnVzY2F0aW9uIGlzIG5vdCBtZWFudCB0byBndWFyZCBhZ2FpbnN0IGxhdGVyIGFu YWx5c2lzIHRoYXQgcmV2ZWFscyB0aGUgcGFja2V0IG51bWJlcnMgLSB3aHkgZG8gd2UgY2FyZSBh Ym91dCB0aGF0LiBJdCBpcyBtZWFudCB0byBncmVhc2UgdGhlDQogc3BhY2UgYW5kIG5vdCBtYWtl IHRoZSBudW1iZXJzIHNlcmlhbCBzbyBtaWRkbGVib3hlcyBjYW5ub3QgYXNzdW1lIG9yZGVyaW5n IGV0Yy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWxsIHNhaWQgaWYgSSBhbSBhbG9uZSBpbiBi ZWluZyBjb25jZXJuZWQgYWJvdXQgdGhlIHBlcmYgaGl0IHRoZW4gSeKAmWQgc2F5IGdvIG9uIHdp dGggb3B0aW9uIDEuDQo8c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6 d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 Ij4gUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzdGlhbiBI dWl0ZW1hPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDM6NTQg UE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGll dGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0 aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+T24gMi84LzIwMTggMToxMyBQTSwgTWlr ZSBCaXNob3Agd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiMy IHdvbuKAmXQgd29yay4mbmJzcDsgVGhlIHBhY2tldCBudW1iZXIgaXMgYW4gaW5wdXQgdG8gdGhl IEFFQUQgbm9uY2UsIHNvIHlvdSBoYXZlIHRvIGdldCB0byB0aGUgcGFja2V0IG51bWJlciBiZWZv cmUgeW91IGNhbiBkZWNyeXB0IHRoZSBwYXlsb2FkLiZuYnNwOyBJdCBjYW7igJl0IGJlIGJhc2Vk IG9uIGFueXRoaW5nIGludGVybmFsIHRvIHRoZSBlbmNyeXB0ZWQgcGFja2V0LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbiBNYXJ0aW7igJlzIHByb3Bvc2FsLCBpdOKAmXMgdXNpbmcgYSBjb21i aW5hdGlvbiBvZiB0aGUgZW5jcnlwdGVkIHBheWxvYWQgKHdoaWNoIHJlcXVpcmVzIG5vdGhpbmcg dG8gYWNjZXNzKSBhbmQgc29tZSBzdG9yZWQgc3RhdGUgb24gZWFjaCBlbmRwb2ludCwgd2hpY2gg cmVxdWlyZXMgb25seSB0aGUgQ29ubmVjdGlvbiBJRCB0byBsb29rIHVwLiZuYnNwOyBZb3Ugd2Fu dCB0aGUgdGhpbmcgeW91IFhPUiBieSB0byBiZSBjb25zdGFudGx5DQogY2hhbmdpbmcsIG9yIGl0 IGJlY29tZXMgZWFzaWVyIHRvIGxvb2sgYXQgc2VxdWVuY2VzIG9mIG9iZnVzY2F0ZWQgcGFja2V0 IG51bWJlcnMgYW5kIHN0YXJ0IGRyYXdpbmcgaW5mZXJlbmNlcyBhYm91dCB3aGF0IHRoZSBYT1Ig dmFsdWUgaXMuJm5ic3A7IElmIG92ZXJoZWFkIGlzIHRoZSBwcmltYXJ5IGNvbmNlcm4sIEkgdGhp bmsgdGhlcmUgYXJlIGEgY291cGxlIGFwcHJvYWNoZXMgdGhhdCBtaWdodCBhbGxvdyB5b3UgdG8g cHJlY29tcHV0ZSB2YWx1ZXMNCiBhbmQgYW1vcnRpemUgdGhlIGNvc3Qgb2YgZG9pbmcgdGhlIGVu Y3J5cHRpb24gc3RlcC4mbmJzcDsgKEF0IHRoZSBjb3N0IG9mIGtlZXBpbmcgdGhlIHRhYmxlIG9m IHByZWNvbXB1dGVkIHZhbHVlcywgb2YgY291cnNlLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBzdGlsbCB0aGluayBKYW5h4oCZcyBwdXNoaW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24gaGVy ZTombmJzcDsgTGV04oCZcyBhZ3JlZSBvbiBnb2FscywgYW5kIHRoZW4gc2VlIGlmIHdlIGNhbiBj cmFmdCBhIGRlc2lnbiB0aGF0IG1lZXRzIHRob3NlIGdvYWxzLiZuYnNwOyBJIGhlYXIgeW91IHNh eWluZyB0aGF0IGxvdyBvdmVyaGVhZCBpcyBhIGdvYWwsIHdoaWNoIEkgdGhpbmsgd2UgY2FuIGFs bCBhZ3JlZSBvbi4mbmJzcDsgSSBhbHNvIHRoaW5rDQogSSBoZWFyIHlvdSBzYXlpbmcgdGhhdCAx LTEuNSUgb3ZlcmhlYWQgaXMgdG9vIGhpZ2gsIGJ1dCBpdCBzb3VuZHMgbGlrZSB0aGVyZeKAmXMg bGVzcyBhZ3JlZW1lbnQgb24gdGhhdC4mbmJzcDsgWW91IGFsc28gcmFpc2UgYW4gaW50ZXJlc3Rp bmcgcG9pbnQgdGhhdCBzb21lIGNsaWVudHMgd2lsbCBjYXJlIGxlc3MgYWJvdXQgbGlua2FiaWxp dHkgYmVjYXVzZSB0aGV5IHdpbGwgbmV2ZXIgaW50ZW50aW9uYWxseSBtaWdyYXRlLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48YnI+DQpJIHRoaW5rIFZpY3RvciBzYWlkIGl0IGJlc3QsICZxdW90 O09iZnVzY2F0aW9uIGlzIGp1c3QgZW5jcnlwdGlvbiBkb25lIHBvb3JseS4mcXVvdDsgRWl0aGVy IHdlIGVuY3J5cHQsIG9yIHdlIGRvbid0LiBCdXQgdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBh biBvYmZ1c2NhdGlvbiBtaWRkbGUtZ3JvdW5kLiBPYmZ1c2NhdGlvbiB3b3VsZCBqdXN0IGJlIGEg c3BlZWQgYnVtcCwgZWFzaWx5IGJyb2tlbi4gSXQgd29uJ3QgcHJvdmlkZSBwcml2YWN5LCBhbmQg aXQgd29uJ3QNCiBwcmV2ZW50IGxpbmthYmlsaXR5Ljxicj4NCjxicj4NCkFzIGZhciBhcyBJIGFt IGNvbmNlcm5lZCwgdGhlcmUgYXJlIG9ubHkgdHdvIGRlc2lnbnMgdGhhdCBwcmV2ZW50IGxpbmth YmlsaXR5Ojxicj4NCjxicj4NCjEpIE1hcnRpbidzIFBSLCBpbiB3aGljaCB0aGUgcGFja2V0IG51 bWJlciBpcyBlbmNyeXB0ZWQgdXNpbmcgc2Vuc2libGUgY3J5cHRvOzxicj4NCjxicj4NCjIpIE9y LCBsZWF2aW5nIHRoZSBwYWNrZXQgbnVtYmVyIGluIHRoZSBjbGVhciBidXQgdXNpbmcgZGlmZmVy ZW50IGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgYW5kIHVzaW5nIHNlcGFyYXRl IHBhY2tldCBzZXF1ZW5jZXMgZm9yIGVhY2ggcGF0aC48YnI+DQo8YnI+DQpUaGUgc2Vjb25kIG9w dGlvbiByZXF1aXJlcyBtb3JlIGNvbXB1dGF0aW9uIHdoZW4gZXhwbGljaXRseSBzZXR0aW5nIHVw IGEgbmV3IHBhdGguIFRoZSBjb25uZWN0aW9uIElEIHdvdWxkIGJlIHVzZWQgYXMgcGFydCBvZiB0 aGUgJnF1b3Q7c2FsdCZxdW90OyB3aGVuIGRlcml2aW5nIGNvbm5lY3Rpb24gY29udGV4dHMuIFRo ZSBwYWNrZXQgbnVtYmVyIG9uIGVhY2ggcGF0aCB3aWxsIHN0YXJ0IGF0IDEgKG9yIG1heWJlIDAg Oy0pLiBUaGlzIHJlcXVpcmVzIG1haW50YWluaW5nDQogc2VwYXJhdGUgU0FDSyBkYXNoYm9hcmRz IGZvciBlYWNoIHBhdGgvQ29ubmVjdGlvbi1JRCwgYW5kIGNvbnN0cmFpbmluZyBBQ0sgdG8gYmUg cGVyL3BhdGgsIG9yIGFsdGVybmF0aXZlbHkgYWRkaW5nIGEgUEFUSC1BQ0sgZnJhbWUgdGhhdCBp bmRpY2F0ZXMgdGhlIHBhdGggZm9yIHdoaWNoIHBhY2tldHMgYXJlIGFja2VkLjxicj4NCjxicj4N ClRoZSBwcm9zIGFuZCBjb25zIG9mIHRoZSB0d28gb3B0aW9ucyBhcmUgZWFzeSB0byBnZXQ6PGJy Pg0KPGJyPg0KMSkgT3B0aW9uIDIgZG9lcyBub3QgcmVxdWlyZSB0aGUgY29zdCBvZiBlbmNyeXB0 aW5nIGV2ZXJ5IHBhY2tldCwgdGh1cyBwZXIgcGFja2V0IHByb2Nlc3Npbmcgd2lsbCBiZSBtYXli ZSAxJSBmYXN0ZXIgdGhhbiBvcHRpb24gMS4NCjxicj4NCjxicj4NCjIpIE9wdGlvbiAyIHJlcXVp cmVzIGNvbXB1dGluZyBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIHdoaWNoIGlz IG1vcmUgY29tcGxleCB0aGFuIG9wdGlvbiAxLCBidXQgdGhlIGNvc3Qgd2lsbCBiZSBhbW9ydGl6 ZWQgb3ZlciB0aGUgZHVyYXRpb24gb2YgdGhlIHBhdGguPGJyPg0KPGJyPg0KMykgT3B0aW9uIDIg cmVxdWlyZXMgbW9yZSBjb21wbGV4IGRhdGEgc3RydWN0dXJlcyBhbmQgQUNLIG1hbmFnZW1lbnQs IHRodXMgaW5jcmVhc2luZyB0aGUgY2hhbmNlcyB0aGF0IHNvbWV0aGluZyBnb2VzIHdyb25nLjxi cj4NCjxicj4NCjQpIE9wdGlvbiAyIGRvZXMgbm90aGluZyBhZ2FpbnN0IHBhY2tldCBudW1iZXIg b3NzaWZpY2F0aW9uLiBUaGUgcGFja2V0IG51bWJlciBlZmZlY3RpdmVseSBiZWNvbWVzIHBhcnQg b2YgdGhlIGludmFyaWFudHMuPGJyPg0KPGJyPg0KSW4gc2hvcnQsIHRoZSBvbmx5IGFkdmFudGFn ZSBvZiBvcHRpb24gMiBpcyB0byBhdm9pZCBhIHNpbmdsZSBzeW1tZXRyaWMgZW5jcnlwdGlvbiBv cGVyYXRpb24gcGVyIHBhY2tldCwgd2hpbGUgbWFraW5nIHRoZSBjb2RlIHNpZ25pZmljYW50bHkg bW9yZSBjb21wbGV4LCBhbmQgYXQgdGhlIGNvc3Qgb2Ygbm90IHByb3RlY3RpbmcgYWdhaW5zdCBQ TiBvc3NpZmljYXRpb24uIFRoZSB3YXkgSSBzZWUgdGhhdCwgdGhlcmUgaXMgaGFyZGx5IGFueSBk ZWJhdGUuPGJyPg0KPGJyPg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWE8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR08MB2432EAF7D176BBFCA28DF3FFDAF20MWHPR08MB2432namp_-- From nobody Thu Feb 8 23:05:53 2018 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 BA5F512741D for ; Thu, 8 Feb 2018 23:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.51 X-Spam-Level: X-Spam-Status: No, score=-1.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no 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 fvwpF6yghHgT for ; Thu, 8 Feb 2018 23:05:48 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0135.outbound.protection.outlook.com [104.47.32.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BDA124234 for ; Thu, 8 Feb 2018 23:05:47 -0800 (PST) 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=qp7smzHkqu4bmHWyLqcj6y9ztRrihG2wJHRrkg1tCCs=; b=WcH8ak62ah7vNY1PwCzaT1uMCIzmbLx4NUYNpEFz0RXCyC8sWJWdkt9lJrnf4aQ9aMkwygIVCcbGemv3TaD7R14VJ2VS7I+li+VcO+c63g4umJDT2cd9V87nz75Qz3oq3TUqbtLLgFSzsPjGPXETCyL61D4WemhrfStBCm2RcS0= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0149.namprd21.prod.outlook.com (10.173.189.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Fri, 9 Feb 2018 07:05:45 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 07:05:45 +0000 From: Praveen Balasubramanian To: Mike Bishop , huitema , "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwIAADioAgAALB8A= Date: Fri, 9 Feb 2018 07:05:45 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0149; 7:27EhhJglHf4mXjuZn76mgRO7BYuImQqnB/nKcEWrZUySOQxhyhv1XS/ckxGsKA6tvrOsVxSD5PCA/3XAU9Se70tintt790EMjXYr9BAJLf6hTKaODJdwPSwFet6qS/6PKOras3VouqYo+H1OO01uGH3DsAfg1KeulBnp98voPiCnbOmIfjuVZvqITAXTfVx5c6QbJzk0r9BkQRy1gOiHHFRc/h7V66JU+8bYRxIR28fA6OuFYZ4um6hBoe4w5swr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 868c5def-b76e-42e1-d48c-08d56f8b8a6d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0149; x-ms-traffictypediagnostic: CY4PR21MB0149: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0149; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0149; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(396003)(376002)(346002)(366004)(189003)(199004)(377424004)(97736004)(2950100002)(86362001)(68736007)(2906002)(8676002)(81166006)(74316002)(81156014)(7736002)(6506007)(5250100002)(478600001)(53546011)(33656002)(561944003)(6246003)(110136005)(5660300001)(186003)(7116003)(99286004)(25786009)(93886005)(102836004)(10090500001)(55016002)(54896002)(316002)(59450400001)(6346003)(2900100001)(3280700002)(3660700001)(6436002)(10290500003)(236005)(53936002)(6306002)(9686003)(8990500004)(22452003)(86612001)(2501003)(14454004)(790700001)(6116002)(229853002)(8936002)(76176011)(106356001)(3480700004)(105586002)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0149; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: q7jKatR2RVRqwZJNjoZf5IJLv9eWpKTdMjIrFIM3fR/UTqUy0P5dpqXbhJYrEAGgjFZyMtoxG3c5yb4kWmzWZw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133AB59D37046908D035409B6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 868c5def-b76e-42e1-d48c-08d56f8b8a6d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 07:05:45.5446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0149 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, 09 Feb 2018 07:05:52 -0000 --_000_CY4PR21MB0133AB59D37046908D035409B6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RG9lcyB0aGlzIG1lYW4gd2UgcmVxdWlyZSBhIGtleSByb2xsb3ZlciB0b2RheSBmb3IgZXZlcnkg NCBHQiBvZiBkYXRhIHRyYW5zZmVyIHNpbmNlIHRoZSBQTiBpcyBvbmx5IGEgNCBieXRlIGZpZWxk PyBBbHNvIEkgZG9u4oCZdCBzZWUgdGhlbiBob3cgdGhlIFBOIGVuY3J5cHRpb24gcHJvcG9zYWwg aXMgZ3VhcmFudGVlaW5nIG5vbi1yZXBlYXRpbmcgb3V0cHV0Pw0KDQpZb3UgY2FuIHN0YXJ0IHdp dGggc2VjdXJlIHJhbmRvbSBudW1iZXIgYW5kIHRoZW4gdXNlIFBSTkcgZm9yIHNtYWxsIGp1bXBz IHRvIHByZXZlbnQgb3NzaWZpY2F0aW9uLiBBbmQgZGVwZW5kaW5nIG9uIGhvdyBvZnRlbiB5b3Ug anVtcCB5b3Ugd2lsbCB0aGVuIHJlcXVpcmUga2V5IHJvbGxvdmVyIGVhcmx5IHVudGlsIHlvdSBy b2xsb3ZlciBhbmQgaGl0IHRoZSBzdGFydGluZyBub25jZSBudW1iZXIuIFRoZSBvdGhlciBnb29k IHBhcnQgb2YgdW4tb3ZlcmxvYWRpbmcgaXMgdGhhdCB3ZSBjYW4gbWFrZSB0aGUgbm9uY2Ugb3B0 aW9uYWwgd2hlbiBub3QgbmVlZGVkIG5lZWRlZCBieSBjcnlwdG8uDQoNCkZyb206IE1pa2UgQmlz aG9wIFttYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmVdDQpTZW50OiBUaHVyc2RheSwgRmVicnVh cnkgOCwgMjAxOCAxMDoxOSBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBt aWNyb3NvZnQuY29tPjsgaHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IHF1aWNAaWV0Zi5v cmcNClN1YmplY3Q6IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KWW91IGNhbuKAmXQg c2FmZWx5IHJldXNlIHRoZSBjb21iaW5hdGlvbiBvZiBub25jZSBhbmQga2V5LCBJSVVDLiAgU2lu Y2Uga2V5IHJvbGxvdmVyIGlzIGluZnJlcXVlbnQsIHRoZSBub25jZSBoYXMgdG8gY2hhbmdlIGV2 ZXJ5IHBhY2tldCBhbmQgYmUgZ3VhcmFudGVlZCB1bmlxdWUgb3ZlciB0aGUgbGlmZXRpbWUgb2Ys IGlmIG5vdCB0aGUgY29ubmVjdGlvbiwgYXQgbGVhc3QgdGhlIGN1cnJlbnQga2V5LiAgU2luY2Ug cGFja2V0IG51bWJlcnMgYWxzbyBkb27igJl0IHJlcGVhdCBvdmVyIHRoZSBsaWZldGltZSBvZiB0 aGUgY29ubmVjdGlvbiwgSSB0aGluayB1c2luZyBvbmUgYXMgdGhlIHZhcmlhYmxlIHBhcnQgb2Yg dGhlIG90aGVyIHdhcyBqdXN0IHRha2luZyBhZHZhbnRhZ2Ugb2YgdGhlIGFsaWdubWVudC4NCg0K SSBkb27igJl0IHRoaW5rIGhhdmluZyBhIHJhbmRvbWl6ZWQgc3RhcnRpbmcgdmFsdWUgYW5kIGlu Y3JlbWVudGluZyBpcyBuZWNlc3NhcmlseSBhbnkgYmV0dGVyIHRoYW4gZXhwb3NpbmcgdGhlIHBh Y2tldCBudW1iZXIuICBIYXZpbmcgYSBQUk5HIHNlZWQgZXN0YWJsaXNoZWQgZHVyaW5nIHRoZSBo YW5kc2hha2UgYW5kIG1ha2luZyB0aGUgdmlzaWJsZSB0aGluZyB0aGUgbmV4dCByYW5kb20gb3V0 cHV0IHNlZW1zIHBvdGVudGlhbGx5IGludGVyZXN0aW5nLCBidXQgSeKAmWQgd2FudCBvdXIgbW9y ZSBjcnlwdG8tbWluZGVkIGZyaWVuZHMgdG8gY29tbWVudC4gIEkgdGhpbmsgdGhlIHJlYWwgaXNz dWUgd291bGQgYmUgZ3VhcmFudGVlcyBhYm91dCBuZXZlci1yZXBlYXRpbmcgZnJvbSB0aGUgUFJO RywgcGFydGljdWxhcmx5IGFzIHlvdSBkb27igJl0IGhhdmUgZ3VhcmFudGVlcyBhYm91dCB5b3Vy IHBlZXLigJlzIGltcGxlbWVudGF0aW9uLiAgQSBkZWZpbmVkIGtleSBkZXJpdmF0aW9uIGFuZCBh IGNvdW50ZXIgY2FuIGJlIHZlcmlmaWVkIGluIHRoZSBwcm90b2NvbCwgaW5kZXBlbmRlbnQgb2Yg aG93IGdvb2QgdGhlIHBlZXLigJlzIFBSTkcgaXMuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0K U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggOTo0MCBQTQ0KVG86IGh1aXRlbWEgPGh1 aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PjsgcXVpY0BpZXRm Lm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBQYWNrZXQgbnVtYmVyIGVu Y3J5cHRpb24NCg0KQWN0dWFsbHkgdGFraW5nIGEgc3RlcCBiYWNrIHdoYXQgaWYgd2UgZG9u4oCZ dCB3ZSBvdmVybG9hZGVkIHBhY2tldCBudW1iZXIgYXMgdGhlIG5vbmNlPw0KDQpDYW4gd2U6DQoN CiAgMS4gIFB1dCBwYWNrZXQgbnVtYmVyIGFzIGEgc2VwYXJhdGUgdmFyaWFibGUgbGVuZ3RoIGZp ZWxkIGluIHRoZSBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0aGUgaGVhZGVyLiBUaGlzIGFsbG93cyBm b3IgZ3Jvd3RoIGJleW9uZCA2NCBiaXRzIGluIGZ1dHVyZSBhbmQgY29tcGxldGVseSBhdm9pZHMg b3NzaWZpY2F0aW9uLiBGb3Igc2hvcnQgbGl2ZWQgZmxvd3MgdmFyaWFibGUgbGVuZ3RoIGVuY29k aW5nIGxlYWRzIHRvIG1pbmltYWwgc3BhY2Ugb3ZlcmhlYWQuDQogIDIuICBQdXQgYSBzZXBhcmF0 ZSBwbGFpbnRleHQgbm9uY2Ugd2hpY2ggc3RhcnRzIG91dCBhcyBhIHNlY3VyZSByYW5kb20gbnVt YmVyIGFuZCBtb25vdG9uaWNhbGx5IGluY3JlYXNlcyBhcyBzaG9ydCByYW5kb20ganVtcHMgKGV2 ZXJ5IHBhY2tldCBvciBldmVyeSBmZXcgcGFja2V0cykgYW5kIGNvdWxkIHRoZW4gcm9sbG92ZXIu IFRoaXMgd2lsbCBwcmV2ZW50IGxpbmthYmlsaXR5IGFuZCBzY2FsZXMgdG8gbXVsdGktcGF0aCBh cyB3ZWxsLiBObyBtYWpvciBjb21wdXRlIG92ZXJoZWFkLiBXZSBjYW4gYWxzbyBtYWtlIHRoZSBu b25jZSBvcHRpb25hbCBmb3IgY3J5cHRvIGFsZ29yaXRobXMgdGhhdCBkbyBub3QgbmVlZCBhIG5v bmNlIHNhdmluZyBtb3JlIHNwYWNlLg0KDQpTb21lIE1TQiBvZiB0aGUgbm9uY2UgY291bGQgYmUg dXNlZCBmb3Igc2lnbmFsaW5nIHJlb3JkZXIgdG8gdGhlIG5ldHdvcmsgaWYgbmVlZGVkLiBJIGRv buKAmXQgaGF2ZSB0aGUgaGlzdG9yaWNhbCBjb250ZXh0IGZvciBvdmVybG9hZGluZyBvZiBQTiBh cyB0aGUgbm9uY2Ugc28gcGFyZG9uIG1lIGlmIHVuLW92ZXJsb2FkaW5nIG9wdGlvbiB3YXMgZGlz Y3Vzc2VkIGFuZCBydWxlZCBvdXQgYmVmb3JlLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDU6NTEgUE0NClRvOiBodWl0ZW1hIDxodWl0 ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj47IHF1aWNAaWV0Zi5v cmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogUGFja2V0IG51bWJlciBlbmNy eXB0aW9uDQoNCj4+IGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBlYWNo IHBhdGgNClRoaXMgYWxvbmUgcHJldmVudHMgbGlua2FiaWxpdHkgcmlnaHQ/DQoNCj4+IFRoZSBw YWNrZXQgbnVtYmVyIG9uIGVhY2ggcGF0aCB3aWxsIHN0YXJ0IGF0IDEgKG9yIG1heWJlIDAgOy0p Lg0KSXMgc3VwcG9ydGluZyBtdWx0aXBsZSBwYXRocyBhdCB0aGUgc2FtZSB0aW1lIGEgZ29hbD8g SWYgeWVzLCB0aGVuIHllcyBhbGwgcGF0aHMgd2lsbCBuZWVkIHRvIGhhdmUgc2VwYXJhdGUgdHJh Y2tpbmcgYW5kIEFDSyBzdGF0ZSBhbmQgY29uZ2VzdGlvbiBjb250cm9sIGV0Yy4gSSB0aG91Z2h0 IHRoaXMgaXMgbm90IHBhcnQgb2YgVjEgUkZDLiBJZiBpdHMganVzdCBvbmUgYWRkaXRpb25hbCBw YXRoIGZvciBjb25uZWN0aW9uIG1pZ3JhdGlvbiBzY2VuYXJpbyB0aGVuIGFsbCB5b3UgbmVlZCBp cyBhIChyYW5kb20pIGp1bXAgdG8gYSBvZmZzZXQgaW4gcGFja2V0IG51bWJlciBzcGFjZSBmb3Ig dGhlIG5ldyBwYXRoIHNvIHRoYXQgdGhlIGZldyBwYWNrZXRzIGluIHRoZSBvbGQgcGF0aCBjYW4g Y29udGludWUgZm9yIGEgbGl0dGxlIGJpdC4gVGhpcyB3b3JrcyB3aXRoIGp1c3Qgb25lIEFDSyBz cGFjZSBzbyBubyBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5Lg0KDQo+PiAyKSBPciwgbGVhdmlu ZyB0aGUgcGFja2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5nIGRpZmZlcmVudCBlbmNy eXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQg c2VxdWVuY2VzIGZvciBlYWNoIHBhdGguDQpJbiBhZGRpdGlvbiBpZiB0aGUgdmFsdWUgaW4gdGhl IGNsZWFyIHdhcyBvYmZ1c2NhdGVkIHdpdGggYW4gWE9SIHRyYW5zZm9ybSBpdCB3aWxsIGhlbHAg cHJldmVudCBvc3NpZmljYXRpb24uIFRoZSBvYmZ1c2NhdGlvbiBpcyBub3QgbWVhbnQgdG8gZ3Vh cmQgYWdhaW5zdCBsYXRlciBhbmFseXNpcyB0aGF0IHJldmVhbHMgdGhlIHBhY2tldCBudW1iZXJz IC0gd2h5IGRvIHdlIGNhcmUgYWJvdXQgdGhhdC4gSXQgaXMgbWVhbnQgdG8gZ3JlYXNlIHRoZSBz cGFjZSBhbmQgbm90IG1ha2UgdGhlIG51bWJlcnMgc2VyaWFsIHNvIG1pZGRsZWJveGVzIGNhbm5v dCBhc3N1bWUgb3JkZXJpbmcgZXRjLg0KDQpBbGwgc2FpZCBpZiBJIGFtIGFsb25lIGluIGJlaW5n IGNvbmNlcm5lZCBhYm91dCB0aGUgcGVyZiBoaXQgdGhlbiBJ4oCZZCBzYXkgZ28gb24gd2l0aCBv cHRpb24gMS4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIENocmlzdGlhbiBIdWl0ZW1hDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgOCwg MjAxOCAzOjU0IFBNDQpUbzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KDQpPbiAyLzgvMjAxOCAxOjEz IFBNLCBNaWtlIEJpc2hvcCB3cm90ZToNCiMyIHdvbuKAmXQgd29yay4gIFRoZSBwYWNrZXQgbnVt YmVyIGlzIGFuIGlucHV0IHRvIHRoZSBBRUFEIG5vbmNlLCBzbyB5b3UgaGF2ZSB0byBnZXQgdG8g dGhlIHBhY2tldCBudW1iZXIgYmVmb3JlIHlvdSBjYW4gZGVjcnlwdCB0aGUgcGF5bG9hZC4gIEl0 IGNhbuKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcgaW50ZXJuYWwgdG8gdGhlIGVuY3J5cHRlZCBw YWNrZXQuDQoNCkluIE1hcnRpbuKAmXMgcHJvcG9zYWwsIGl04oCZcyB1c2luZyBhIGNvbWJpbmF0 aW9uIG9mIHRoZSBlbmNyeXB0ZWQgcGF5bG9hZCAod2hpY2ggcmVxdWlyZXMgbm90aGluZyB0byBh Y2Nlc3MpIGFuZCBzb21lIHN0b3JlZCBzdGF0ZSBvbiBlYWNoIGVuZHBvaW50LCB3aGljaCByZXF1 aXJlcyBvbmx5IHRoZSBDb25uZWN0aW9uIElEIHRvIGxvb2sgdXAuICBZb3Ugd2FudCB0aGUgdGhp bmcgeW91IFhPUiBieSB0byBiZSBjb25zdGFudGx5IGNoYW5naW5nLCBvciBpdCBiZWNvbWVzIGVh c2llciB0byBsb29rIGF0IHNlcXVlbmNlcyBvZiBvYmZ1c2NhdGVkIHBhY2tldCBudW1iZXJzIGFu ZCBzdGFydCBkcmF3aW5nIGluZmVyZW5jZXMgYWJvdXQgd2hhdCB0aGUgWE9SIHZhbHVlIGlzLiAg SWYgb3ZlcmhlYWQgaXMgdGhlIHByaW1hcnkgY29uY2VybiwgSSB0aGluayB0aGVyZSBhcmUgYSBj b3VwbGUgYXBwcm9hY2hlcyB0aGF0IG1pZ2h0IGFsbG93IHlvdSB0byBwcmVjb21wdXRlIHZhbHVl cyBhbmQgYW1vcnRpemUgdGhlIGNvc3Qgb2YgZG9pbmcgdGhlIGVuY3J5cHRpb24gc3RlcC4gIChB dCB0aGUgY29zdCBvZiBrZWVwaW5nIHRoZSB0YWJsZSBvZiBwcmVjb21wdXRlZCB2YWx1ZXMsIG9m IGNvdXJzZS4pDQoNCkkgc3RpbGwgdGhpbmsgSmFuYeKAmXMgcHVzaGluZyBpbiB0aGUgcmlnaHQg ZGlyZWN0aW9uIGhlcmU6ICBMZXTigJlzIGFncmVlIG9uIGdvYWxzLCBhbmQgdGhlbiBzZWUgaWYg d2UgY2FuIGNyYWZ0IGEgZGVzaWduIHRoYXQgbWVldHMgdGhvc2UgZ29hbHMuICBJIGhlYXIgeW91 IHNheWluZyB0aGF0IGxvdyBvdmVyaGVhZCBpcyBhIGdvYWwsIHdoaWNoIEkgdGhpbmsgd2UgY2Fu IGFsbCBhZ3JlZSBvbi4gIEkgYWxzbyB0aGluayBJIGhlYXIgeW91IHNheWluZyB0aGF0IDEtMS41 JSBvdmVyaGVhZCBpcyB0b28gaGlnaCwgYnV0IGl0IHNvdW5kcyBsaWtlIHRoZXJl4oCZcyBsZXNz IGFncmVlbWVudCBvbiB0aGF0LiAgWW91IGFsc28gcmFpc2UgYW4gaW50ZXJlc3RpbmcgcG9pbnQg dGhhdCBzb21lIGNsaWVudHMgd2lsbCBjYXJlIGxlc3MgYWJvdXQgbGlua2FiaWxpdHkgYmVjYXVz ZSB0aGV5IHdpbGwgbmV2ZXIgaW50ZW50aW9uYWxseSBtaWdyYXRlLg0KDQpJIHRoaW5rIFZpY3Rv ciBzYWlkIGl0IGJlc3QsICJPYmZ1c2NhdGlvbiBpcyBqdXN0IGVuY3J5cHRpb24gZG9uZSBwb29y bHkuIiBFaXRoZXIgd2UgZW5jcnlwdCwgb3Igd2UgZG9uJ3QuIEJ1dCB0aGVyZSBpcyBubyBzdWNo IHRoaW5nIGFzIGFuIG9iZnVzY2F0aW9uIG1pZGRsZS1ncm91bmQuIE9iZnVzY2F0aW9uIHdvdWxk IGp1c3QgYmUgYSBzcGVlZCBidW1wLCBlYXNpbHkgYnJva2VuLiBJdCB3b24ndCBwcm92aWRlIHBy aXZhY3ksIGFuZCBpdCB3b24ndCBwcmV2ZW50IGxpbmthYmlsaXR5Lg0KDQpBcyBmYXIgYXMgSSBh bSBjb25jZXJuZWQsIHRoZXJlIGFyZSBvbmx5IHR3byBkZXNpZ25zIHRoYXQgcHJldmVudCBsaW5r YWJpbGl0eToNCg0KMSkgTWFydGluJ3MgUFIsIGluIHdoaWNoIHRoZSBwYWNrZXQgbnVtYmVyIGlz IGVuY3J5cHRlZCB1c2luZyBzZW5zaWJsZSBjcnlwdG87DQoNCjIpIE9yLCBsZWF2aW5nIHRoZSBw YWNrZXQgbnVtYmVyIGluIHRoZSBjbGVhciBidXQgdXNpbmcgZGlmZmVyZW50IGVuY3J5cHRpb24g Y29udGV4dHMgZm9yIGVhY2ggcGF0aCwgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBzZXF1ZW5j ZXMgZm9yIGVhY2ggcGF0aC4NCg0KVGhlIHNlY29uZCBvcHRpb24gcmVxdWlyZXMgbW9yZSBjb21w dXRhdGlvbiB3aGVuIGV4cGxpY2l0bHkgc2V0dGluZyB1cCBhIG5ldyBwYXRoLiBUaGUgY29ubmVj dGlvbiBJRCB3b3VsZCBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlICJzYWx0IiB3aGVuIGRlcml2aW5n IGNvbm5lY3Rpb24gY29udGV4dHMuIFRoZSBwYWNrZXQgbnVtYmVyIG9uIGVhY2ggcGF0aCB3aWxs IHN0YXJ0IGF0IDEgKG9yIG1heWJlIDAgOy0pLiBUaGlzIHJlcXVpcmVzIG1haW50YWluaW5nIHNl cGFyYXRlIFNBQ0sgZGFzaGJvYXJkcyBmb3IgZWFjaCBwYXRoL0Nvbm5lY3Rpb24tSUQsIGFuZCBj b25zdHJhaW5pbmcgQUNLIHRvIGJlIHBlci9wYXRoLCBvciBhbHRlcm5hdGl2ZWx5IGFkZGluZyBh IFBBVEgtQUNLIGZyYW1lIHRoYXQgaW5kaWNhdGVzIHRoZSBwYXRoIGZvciB3aGljaCBwYWNrZXRz IGFyZSBhY2tlZC4NCg0KVGhlIHByb3MgYW5kIGNvbnMgb2YgdGhlIHR3byBvcHRpb25zIGFyZSBl YXN5IHRvIGdldDoNCg0KMSkgT3B0aW9uIDIgZG9lcyBub3QgcmVxdWlyZSB0aGUgY29zdCBvZiBl bmNyeXB0aW5nIGV2ZXJ5IHBhY2tldCwgdGh1cyBwZXIgcGFja2V0IHByb2Nlc3Npbmcgd2lsbCBi ZSBtYXliZSAxJSBmYXN0ZXIgdGhhbiBvcHRpb24gMS4NCg0KMikgT3B0aW9uIDIgcmVxdWlyZXMg Y29tcHV0aW5nIGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgd2hpY2ggaXMgbW9y ZSBjb21wbGV4IHRoYW4gb3B0aW9uIDEsIGJ1dCB0aGUgY29zdCB3aWxsIGJlIGFtb3J0aXplZCBv dmVyIHRoZSBkdXJhdGlvbiBvZiB0aGUgcGF0aC4NCg0KMykgT3B0aW9uIDIgcmVxdWlyZXMgbW9y ZSBjb21wbGV4IGRhdGEgc3RydWN0dXJlcyBhbmQgQUNLIG1hbmFnZW1lbnQsIHRodXMgaW5jcmVh c2luZyB0aGUgY2hhbmNlcyB0aGF0IHNvbWV0aGluZyBnb2VzIHdyb25nLg0KDQo0KSBPcHRpb24g MiBkb2VzIG5vdGhpbmcgYWdhaW5zdCBwYWNrZXQgbnVtYmVyIG9zc2lmaWNhdGlvbi4gVGhlIHBh Y2tldCBudW1iZXIgZWZmZWN0aXZlbHkgYmVjb21lcyBwYXJ0IG9mIHRoZSBpbnZhcmlhbnRzLg0K DQpJbiBzaG9ydCwgdGhlIG9ubHkgYWR2YW50YWdlIG9mIG9wdGlvbiAyIGlzIHRvIGF2b2lkIGEg c2luZ2xlIHN5bW1ldHJpYyBlbmNyeXB0aW9uIG9wZXJhdGlvbiBwZXIgcGFja2V0LCB3aGlsZSBt YWtpbmcgdGhlIGNvZGUgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXgsIGFuZCBhdCB0aGUgY29z dCBvZiBub3QgcHJvdGVjdGluZyBhZ2FpbnN0IFBOIG9zc2lmaWNhdGlvbi4gVGhlIHdheSBJIHNl ZSB0aGF0LCB0aGVyZSBpcyBoYXJkbHkgYW55IGRlYmF0ZS4NCg0KLS0gQ2hyaXN0aWFuIEh1aXRl bWENCg== --_000_CY4PR21MB0133AB59D37046908D035409B6F20CY4PR21MB0133namp_ 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 YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUGxh aW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUzMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjEyNzQ4MjE2NTM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjExNjAyODM1NzA7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTc3NTU5MTY3MTsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEwMzQ3OTkzNzIgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTU7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7 bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dCI+RG9lcyB0aGlzIG1lYW4gd2UgcmVxdWlyZSBhIGtleSByb2xsb3ZlciB0b2RheSBmb3Ig ZXZlcnkgNCBHQiBvZiBkYXRhIHRyYW5zZmVyIHNpbmNlIHRoZSBQTiBpcyBvbmx5IGEgNCBieXRl IGZpZWxkPyBBbHNvIEkgZG9u4oCZdCBzZWUgdGhlbiBob3cgdGhlIFBOIGVuY3J5cHRpb24gcHJv cG9zYWwgaXMgZ3VhcmFudGVlaW5nIG5vbi1yZXBlYXRpbmcgb3V0cHV0Pw0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRv d3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Zb3UgY2FuIHN0YXJ0IHdpdGggc2VjdXJl IHJhbmRvbSBudW1iZXIgYW5kIHRoZW4gdXNlIFBSTkcgZm9yIHNtYWxsIGp1bXBzIHRvIHByZXZl bnQgb3NzaWZpY2F0aW9uLiBBbmQgZGVwZW5kaW5nIG9uIGhvdyBvZnRlbiB5b3UganVtcCB5b3Ug d2lsbCB0aGVuIHJlcXVpcmUga2V5IHJvbGxvdmVyIGVhcmx5IHVudGlsIHlvdSByb2xsb3ZlciBh bmQgaGl0IHRoZQ0KIHN0YXJ0aW5nIG5vbmNlIG51bWJlci4gVGhlIG90aGVyIGdvb2QgcGFydCBv ZiB1bi1vdmVybG9hZGluZyBpcyB0aGF0IHdlIGNhbiBtYWtlIHRoZSBub25jZSBvcHRpb25hbCB3 aGVuIG5vdCBuZWVkZWQgbmVlZGVkIGJ5IGNyeXB0by4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IE1pa2UgQmlz aG9wIFttYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmVdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1 cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggMTA6MTkgUE08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4g QmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0OzsgaHVpdGVtYSAmbHQ7 aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs7IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Zb3Ug Y2Fu4oCZdCBzYWZlbHkgcmV1c2UgdGhlIGNvbWJpbmF0aW9uIG9mIG5vbmNlIGFuZCBrZXksIElJ VUMuJm5ic3A7IFNpbmNlIGtleSByb2xsb3ZlciBpcyBpbmZyZXF1ZW50LCB0aGUgbm9uY2UgaGFz IHRvIGNoYW5nZSBldmVyeSBwYWNrZXQgYW5kIGJlIGd1YXJhbnRlZWQgdW5pcXVlIG92ZXIgdGhl IGxpZmV0aW1lIG9mLCBpZiBub3QgdGhlIGNvbm5lY3Rpb24sDQogYXQgbGVhc3QgdGhlIGN1cnJl bnQga2V5LiZuYnNwOyBTaW5jZSBwYWNrZXQgbnVtYmVycyBhbHNvIGRvbuKAmXQgcmVwZWF0IG92 ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZSBjb25uZWN0aW9uLCBJIHRoaW5rIHVzaW5nIG9uZSBhcyB0 aGUgdmFyaWFibGUgcGFydCBvZiB0aGUgb3RoZXIgd2FzIGp1c3QgdGFraW5nIGFkdmFudGFnZSBv ZiB0aGUgYWxpZ25tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+SSBkb27igJl0IHRoaW5rIGhhdmluZyBhIHJhbmRvbWl6ZWQgc3RhcnRpbmcgdmFsdWUgYW5k IGluY3JlbWVudGluZyBpcyBuZWNlc3NhcmlseSBhbnkgYmV0dGVyIHRoYW4gZXhwb3NpbmcgdGhl IHBhY2tldCBudW1iZXIuJm5ic3A7IEhhdmluZyBhIFBSTkcgc2VlZCBlc3RhYmxpc2hlZCBkdXJp bmcgdGhlIGhhbmRzaGFrZSBhbmQgbWFraW5nIHRoZSB2aXNpYmxlIHRoaW5nDQogdGhlIG5leHQg cmFuZG9tIG91dHB1dCBzZWVtcyBwb3RlbnRpYWxseSBpbnRlcmVzdGluZywgYnV0IEnigJlkIHdh bnQgb3VyIG1vcmUgY3J5cHRvLW1pbmRlZCBmcmllbmRzIHRvIGNvbW1lbnQuJm5ic3A7IEkgdGhp bmsgdGhlIHJlYWwgaXNzdWUgd291bGQgYmUgZ3VhcmFudGVlcyBhYm91dCBuZXZlci1yZXBlYXRp bmcgZnJvbSB0aGUgUFJORywgcGFydGljdWxhcmx5IGFzIHlvdSBkb27igJl0IGhhdmUgZ3VhcmFu dGVlcyBhYm91dCB5b3VyIHBlZXLigJlzIGltcGxlbWVudGF0aW9uLiZuYnNwOw0KIEEgZGVmaW5l ZCBrZXkgZGVyaXZhdGlvbiBhbmQgYSBjb3VudGVyIGNhbiBiZSB2ZXJpZmllZCBpbiB0aGUgcHJv dG9jb2wsIGluZGVwZW5kZW50IG9mIGhvdyBnb29kIHRoZSBwZWVy4oCZcyBQUk5HIGlzLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2lu ZG93dGV4dCI+IFFVSUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPm1h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkg OCwgMjAxOCA5OjQwIFBNPGJyPg0KPGI+VG86PC9iPiBodWl0ZW1hICZsdDs8YSBocmVmPSJtYWls dG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7Ow0KPGEg aHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+QWN0dWFsbHkgdGFraW5nIGEgc3RlcCBiYWNrIHdoYXQgaWYgd2UgZG9u4oCZdCB3ZSBvdmVy bG9hZGVkIHBhY2tldCBudW1iZXIgYXMgdGhlIG5vbmNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dCI+Q2FuIHdlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+ UHV0IHBhY2tldCBudW1iZXIgYXMgYSBzZXBhcmF0ZSB2YXJpYWJsZSBsZW5ndGggZmllbGQgaW4g dGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBoZWFkZXIuIFRoaXMgYWxsb3dzIGZvciBncm93 dGggYmV5b25kIDY0IGJpdHMgaW4gZnV0dXJlIGFuZCBjb21wbGV0ZWx5IGF2b2lkcyBvc3NpZmlj YXRpb24uIEZvciBzaG9ydA0KIGxpdmVkIGZsb3dzIHZhcmlhYmxlIGxlbmd0aCBlbmNvZGluZyBs ZWFkcyB0byBtaW5pbWFsIHNwYWNlIG92ZXJoZWFkLiA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O21zby1saXN0OmwxIGxldmVsMSBs Zm8zIj5QdXQgYSBzZXBhcmF0ZSBwbGFpbnRleHQgbm9uY2Ugd2hpY2ggc3RhcnRzIG91dCBhcyBh IHNlY3VyZSByYW5kb20gbnVtYmVyIGFuZCBtb25vdG9uaWNhbGx5IGluY3JlYXNlcyBhcyBzaG9y dCByYW5kb20ganVtcHMgKGV2ZXJ5IHBhY2tldCBvciBldmVyeSBmZXcgcGFja2V0cykgYW5kIGNv dWxkIHRoZW4gcm9sbG92ZXIuIFRoaXMNCiB3aWxsIHByZXZlbnQgbGlua2FiaWxpdHkgYW5kIHNj YWxlcyB0byBtdWx0aS1wYXRoIGFzIHdlbGwuIE5vIG1ham9yIGNvbXB1dGUgb3ZlcmhlYWQuIFdl IGNhbiBhbHNvIG1ha2UgdGhlIG5vbmNlIG9wdGlvbmFsIGZvciBjcnlwdG8gYWxnb3JpdGhtcyB0 aGF0IGRvIG5vdCBuZWVkIGEgbm9uY2Ugc2F2aW5nIG1vcmUgc3BhY2UuDQo8bzpwPjwvbzpwPjwv bGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+U29tZSBNU0Igb2YgdGhlIG5vbmNlIGNvdWxk IGJlIHVzZWQgZm9yIHNpZ25hbGluZyByZW9yZGVyIHRvIHRoZSBuZXR3b3JrIGlmIG5lZWRlZC4g SSBkb27igJl0IGhhdmUgdGhlIGhpc3RvcmljYWwgY29udGV4dCBmb3Igb3ZlcmxvYWRpbmcgb2Yg UE4gYXMgdGhlIG5vbmNlIHNvIHBhcmRvbiBtZSBpZiB1bi1vdmVybG9hZGluZyBvcHRpb24gd2Fz IGRpc2N1c3NlZA0KIGFuZCBydWxlZCBvdXQgYmVmb3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IFFVSUMgWzxh IGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpxdWljLWJvdW5jZXNA aWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QcmF2ZWVuIEJhbGFzdWJyYW1hbmlh bjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCA1OjUxIFBNPGJy Pg0KPGI+VG86PC9iPiBodWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1h Lm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNA aWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQYWNr ZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mZ3Q7Jmd0OyBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBm b3IgZWFjaCBwYXRoPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGFs b25lIHByZXZlbnRzIGxpbmthYmlsaXR5IHJpZ2h0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7Jmd0OyBUaGUgcGFja2V0IG51bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFydCBhdCAxIChv ciBtYXliZSAwIDstKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHN1 cHBvcnRpbmcgbXVsdGlwbGUgcGF0aHMgYXQgdGhlIHNhbWUgdGltZSBhIGdvYWw/IElmIHllcywg dGhlbiB5ZXMgYWxsIHBhdGhzIHdpbGwgbmVlZCB0byBoYXZlIHNlcGFyYXRlIHRyYWNraW5nIGFu ZCBBQ0sgc3RhdGUgYW5kIGNvbmdlc3Rpb24gY29udHJvbCBldGMuIEkgdGhvdWdodCB0aGlzIGlz IG5vdCBwYXJ0IG9mIFYxIFJGQy4gSWYgaXRzIGp1c3Qgb25lIGFkZGl0aW9uYWwgcGF0aCBmb3Ig Y29ubmVjdGlvbg0KIG1pZ3JhdGlvbiBzY2VuYXJpbyB0aGVuIGFsbCB5b3UgbmVlZCBpcyBhIChy YW5kb20pIGp1bXAgdG8gYSBvZmZzZXQgaW4gcGFja2V0IG51bWJlciBzcGFjZSBmb3IgdGhlIG5l dyBwYXRoIHNvIHRoYXQgdGhlIGZldyBwYWNrZXRzIGluIHRoZSBvbGQgcGF0aCBjYW4gY29udGlu dWUgZm9yIGEgbGl0dGxlIGJpdC4gVGhpcyB3b3JrcyB3aXRoIGp1c3Qgb25lIEFDSyBzcGFjZSBz byBubyBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m Z3Q7Jmd0OyAyKSBPciwgbGVhdmluZyB0aGUgcGFja2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0 IHVzaW5nIGRpZmZlcmVudCBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1 c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBlYWNoIHBhdGguPGJyPg0KSW4gYWRk aXRpb24gaWYgdGhlIHZhbHVlIGluIHRoZSBjbGVhciB3YXMgb2JmdXNjYXRlZCB3aXRoIGFuIFhP UiB0cmFuc2Zvcm0gaXQgd2lsbCBoZWxwIHByZXZlbnQgb3NzaWZpY2F0aW9uLiBUaGUgb2JmdXNj YXRpb24gaXMgbm90IG1lYW50IHRvIGd1YXJkIGFnYWluc3QgbGF0ZXIgYW5hbHlzaXMgdGhhdCBy ZXZlYWxzIHRoZSBwYWNrZXQgbnVtYmVycyAtIHdoeSBkbyB3ZSBjYXJlIGFib3V0IHRoYXQuIEl0 IGlzIG1lYW50IHRvIGdyZWFzZSB0aGUNCiBzcGFjZSBhbmQgbm90IG1ha2UgdGhlIG51bWJlcnMg c2VyaWFsIHNvIG1pZGRsZWJveGVzIGNhbm5vdCBhc3N1bWUgb3JkZXJpbmcgZXRjLjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BbGwgc2FpZCBpZiBJIGFtIGFsb25lIGluIGJlaW5nIGNvbmNlcm5l ZCBhYm91dCB0aGUgcGVyZiBoaXQgdGhlbiBJ4oCZZCBzYXkgZ28gb24gd2l0aCBvcHRpb24gMS4N CjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPiBRVUlDIFs8YSBo cmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0aWFuIEh1aXRlbWE8YnI+DQo8 Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggMzo1NCBQTTxicj4NCjxiPlRv OjwvYj4gPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cD5PbiAyLzgvMjAxOCAxOjEzIFBNLCBNaWtlIEJpc2hvcCB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+IzIgd29u4oCZdCB3b3Jr LiZuYnNwOyBUaGUgcGFja2V0IG51bWJlciBpcyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwg c28geW91IGhhdmUgdG8gZ2V0IHRvIHRoZSBwYWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRl Y3J5cHQgdGhlIHBheWxvYWQuJm5ic3A7IEl0IGNhbuKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcg aW50ZXJuYWwgdG8gdGhlIGVuY3J5cHRlZCBwYWNrZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkluIE1hcnRpbuKAmXMgcHJvcG9zYWwsIGl04oCZcyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mIHRo ZSBlbmNyeXB0ZWQgcGF5bG9hZCAod2hpY2ggcmVxdWlyZXMgbm90aGluZyB0byBhY2Nlc3MpIGFu ZCBzb21lIHN0b3JlZCBzdGF0ZSBvbiBlYWNoIGVuZHBvaW50LCB3aGljaCByZXF1aXJlcyBvbmx5 IHRoZSBDb25uZWN0aW9uIElEIHRvIGxvb2sgdXAuJm5ic3A7IFlvdSB3YW50IHRoZSB0aGluZyB5 b3UgWE9SIGJ5IHRvIGJlIGNvbnN0YW50bHkNCiBjaGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNp ZXIgdG8gbG9vayBhdCBzZXF1ZW5jZXMgb2Ygb2JmdXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQg c3RhcnQgZHJhd2luZyBpbmZlcmVuY2VzIGFib3V0IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4mbmJz cDsgSWYgb3ZlcmhlYWQgaXMgdGhlIHByaW1hcnkgY29uY2VybiwgSSB0aGluayB0aGVyZSBhcmUg YSBjb3VwbGUgYXBwcm9hY2hlcyB0aGF0IG1pZ2h0IGFsbG93IHlvdSB0byBwcmVjb21wdXRlIHZh bHVlcw0KIGFuZCBhbW9ydGl6ZSB0aGUgY29zdCBvZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVw LiZuYnNwOyAoQXQgdGhlIGNvc3Qgb2Yga2VlcGluZyB0aGUgdGFibGUgb2YgcHJlY29tcHV0ZWQg dmFsdWVzLCBvZiBjb3Vyc2UuKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHN0aWxsIHRoaW5r IEphbmHigJlzIHB1c2hpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBoZXJlOiZuYnNwOyBMZXTi gJlzIGFncmVlIG9uIGdvYWxzLCBhbmQgdGhlbiBzZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWdu IHRoYXQgbWVldHMgdGhvc2UgZ29hbHMuJm5ic3A7IEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93 IG92ZXJoZWFkIGlzIGEgZ29hbCwgd2hpY2ggSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiZu YnNwOyBJIGFsc28gdGhpbmsNCiBJIGhlYXIgeW91IHNheWluZyB0aGF0IDEtMS41JSBvdmVyaGVh ZCBpcyB0b28gaGlnaCwgYnV0IGl0IHNvdW5kcyBsaWtlIHRoZXJl4oCZcyBsZXNzIGFncmVlbWVu dCBvbiB0aGF0LiZuYnNwOyBZb3UgYWxzbyByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0 IHNvbWUgY2xpZW50cyB3aWxsIGNhcmUgbGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRo ZXkgd2lsbCBuZXZlciBpbnRlbnRpb25hbGx5IG1pZ3JhdGUuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4NCkkgdGhpbmsgVmljdG9yIHNhaWQgaXQgYmVzdCwgJnF1b3Q7T2JmdXNjYXRpb24g aXMganVzdCBlbmNyeXB0aW9uIGRvbmUgcG9vcmx5LiZxdW90OyBFaXRoZXIgd2UgZW5jcnlwdCwg b3Igd2UgZG9uJ3QuIEJ1dCB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGFuIG9iZnVzY2F0aW9u IG1pZGRsZS1ncm91bmQuIE9iZnVzY2F0aW9uIHdvdWxkIGp1c3QgYmUgYSBzcGVlZCBidW1wLCBl YXNpbHkgYnJva2VuLiBJdCB3b24ndCBwcm92aWRlIHByaXZhY3ksIGFuZCBpdCB3b24ndA0KIHBy ZXZlbnQgbGlua2FiaWxpdHkuPGJyPg0KPGJyPg0KQXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCB0 aGVyZSBhcmUgb25seSB0d28gZGVzaWducyB0aGF0IHByZXZlbnQgbGlua2FiaWxpdHk6PGJyPg0K PGJyPg0KMSkgTWFydGluJ3MgUFIsIGluIHdoaWNoIHRoZSBwYWNrZXQgbnVtYmVyIGlzIGVuY3J5 cHRlZCB1c2luZyBzZW5zaWJsZSBjcnlwdG87PGJyPg0KPGJyPg0KMikgT3IsIGxlYXZpbmcgdGhl IHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1dCB1c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlv biBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVl bmNlcyBmb3IgZWFjaCBwYXRoLjxicj4NCjxicj4NClRoZSBzZWNvbmQgb3B0aW9uIHJlcXVpcmVz IG1vcmUgY29tcHV0YXRpb24gd2hlbiBleHBsaWNpdGx5IHNldHRpbmcgdXAgYSBuZXcgcGF0aC4g VGhlIGNvbm5lY3Rpb24gSUQgd291bGQgYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSAmcXVvdDtzYWx0 JnF1b3Q7IHdoZW4gZGVyaXZpbmcgY29ubmVjdGlvbiBjb250ZXh0cy4gVGhlIHBhY2tldCBudW1i ZXIgb24gZWFjaCBwYXRoIHdpbGwgc3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7LSkuIFRoaXMgcmVx dWlyZXMgbWFpbnRhaW5pbmcNCiBzZXBhcmF0ZSBTQUNLIGRhc2hib2FyZHMgZm9yIGVhY2ggcGF0 aC9Db25uZWN0aW9uLUlELCBhbmQgY29uc3RyYWluaW5nIEFDSyB0byBiZSBwZXIvcGF0aCwgb3Ig YWx0ZXJuYXRpdmVseSBhZGRpbmcgYSBQQVRILUFDSyBmcmFtZSB0aGF0IGluZGljYXRlcyB0aGUg cGF0aCBmb3Igd2hpY2ggcGFja2V0cyBhcmUgYWNrZWQuPGJyPg0KPGJyPg0KVGhlIHByb3MgYW5k IGNvbnMgb2YgdGhlIHR3byBvcHRpb25zIGFyZSBlYXN5IHRvIGdldDo8YnI+DQo8YnI+DQoxKSBP cHRpb24gMiBkb2VzIG5vdCByZXF1aXJlIHRoZSBjb3N0IG9mIGVuY3J5cHRpbmcgZXZlcnkgcGFj a2V0LCB0aHVzIHBlciBwYWNrZXQgcHJvY2Vzc2luZyB3aWxsIGJlIG1heWJlIDElIGZhc3RlciB0 aGFuIG9wdGlvbiAxLg0KPGJyPg0KPGJyPg0KMikgT3B0aW9uIDIgcmVxdWlyZXMgY29tcHV0aW5n IGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgd2hpY2ggaXMgbW9yZSBjb21wbGV4 IHRoYW4gb3B0aW9uIDEsIGJ1dCB0aGUgY29zdCB3aWxsIGJlIGFtb3J0aXplZCBvdmVyIHRoZSBk dXJhdGlvbiBvZiB0aGUgcGF0aC48YnI+DQo8YnI+DQozKSBPcHRpb24gMiByZXF1aXJlcyBtb3Jl IGNvbXBsZXggZGF0YSBzdHJ1Y3R1cmVzIGFuZCBBQ0sgbWFuYWdlbWVudCwgdGh1cyBpbmNyZWFz aW5nIHRoZSBjaGFuY2VzIHRoYXQgc29tZXRoaW5nIGdvZXMgd3JvbmcuPGJyPg0KPGJyPg0KNCkg T3B0aW9uIDIgZG9lcyBub3RoaW5nIGFnYWluc3QgcGFja2V0IG51bWJlciBvc3NpZmljYXRpb24u IFRoZSBwYWNrZXQgbnVtYmVyIGVmZmVjdGl2ZWx5IGJlY29tZXMgcGFydCBvZiB0aGUgaW52YXJp YW50cy48YnI+DQo8YnI+DQpJbiBzaG9ydCwgdGhlIG9ubHkgYWR2YW50YWdlIG9mIG9wdGlvbiAy IGlzIHRvIGF2b2lkIGEgc2luZ2xlIHN5bW1ldHJpYyBlbmNyeXB0aW9uIG9wZXJhdGlvbiBwZXIg cGFja2V0LCB3aGlsZSBtYWtpbmcgdGhlIGNvZGUgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXgs IGFuZCBhdCB0aGUgY29zdCBvZiBub3QgcHJvdGVjdGluZyBhZ2FpbnN0IFBOIG9zc2lmaWNhdGlv bi4gVGhlIHdheSBJIHNlZSB0aGF0LCB0aGVyZSBpcyBoYXJkbHkgYW55IGRlYmF0ZS48YnI+DQo8 YnI+DQotLSBDaHJpc3RpYW4gSHVpdGVtYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_CY4PR21MB0133AB59D37046908D035409B6F20CY4PR21MB0133namp_-- From nobody Thu Feb 8 23:08:34 2018 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 8776112741D for ; Thu, 8 Feb 2018 23:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.491 X-Spam-Level: X-Spam-Status: No, score=-1.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no 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 JGfUONjyv9J9 for ; Thu, 8 Feb 2018 23:08:30 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0097.outbound.protection.outlook.com [104.47.34.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 354C0124234 for ; Thu, 8 Feb 2018 23:08:30 -0800 (PST) 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=bFzFbApWTyx0kC8D4fvd5k0AmO5BTfPbSgptI0OI57E=; b=hzvnN6vmhdW73dwrP5AUzRrCY772zaOxEMthTu4PmoZGEdr9NGweC3Gw3mf7eE4fSxwxS3qiKawvZhAtAIHl3ulMoDUEEVgHj6NFvb8ehoDNo97c4s6411Lrr0fR9snV3z2LkX5OTH0AmAytWwX1upNtipU8yRjbPOTCnbIu5xs= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0837.namprd21.prod.outlook.com (10.173.192.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.1; Fri, 9 Feb 2018 07:08:28 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 07:08:28 +0000 From: Praveen Balasubramanian To: Praveen Balasubramanian , Mike Bishop , huitema , "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwIAADioAgAALB8CAAAJ3UA== Date: Fri, 9 Feb 2018 07:08:28 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0837; 7:Vf7/Yi6z91oSDWsE4FSiWmBAMQWr5Hqvq+6XDtxcUqeudNQNBGPM9Ev59RytlN2XIkcajOfS0G78gfXuDwGHzAGlMxvmlWXJdnzINMVjc3Cf69t2IleG+5Wq86peF4SP6OO3KFvT3Lwmd3QLZX4T065dfeXtb46zxO5gr94eZa2aq8i2FSWz2UqKrAgK+DhMux+q+pdqCJOSBjLCL1rscA79IVWef51mpXeCSvCIXkOroqN7r+eTkXgZi2xSeNCg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 2baa8d2b-a1e5-43fc-4d5c-08d56f8beb63 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0837; x-ms-traffictypediagnostic: CY4PR21MB0837: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0837; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0837; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(346002)(366004)(376002)(377424004)(199004)(189003)(790700001)(6116002)(229853002)(86612001)(2906002)(10090500001)(99286004)(478600001)(561944003)(8990500004)(14454004)(33656002)(10290500003)(86362001)(5250100002)(106356001)(3660700001)(105586002)(2501003)(6246003)(2950100002)(3280700002)(2900100001)(25786009)(54896002)(6306002)(93886005)(1511001)(9686003)(97736004)(55016002)(2940100002)(7116003)(6436002)(5660300001)(68736007)(53936002)(81156014)(8676002)(81166006)(236005)(3480700004)(8936002)(74316002)(7696005)(110136005)(76176011)(316002)(22452003)(6346003)(53546011)(7736002)(6506007)(59450400001)(102836004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0837; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: wVrMALhUK0bqeH69hgX3npaDIIdOXGZzCB/Lh5cFywrBw74XoXxsrBpPeYwnKCbU6868RYnt98EtSd+0my2lnA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB013355B5E786890979B98FB2B6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2baa8d2b-a1e5-43fc-4d5c-08d56f8beb63 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 07:08:28.2146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0837 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, 09 Feb 2018 07:08:33 -0000 --_000_CY4PR21MB013355B5E786890979B98FB2B6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2NyYXRjaCB0aGUgcXVlc3Rpb24gb24gUE4gZW5jcnlwdGlvbiBwcm9wb3NhbCBzaW5jZSBpdOKA mXMgdGhlIHBsYWludGV4dCB0aGF04oCZcyB0aGUgbm9uY2Ugbm90IHRoZSBlbmNyeXB0ZWQgdmVy c2lvbi4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkg OCwgMjAxOCAxMTowNiBQTQ0KVG86IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT47 IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBS RTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCkRvZXMgdGhpcyBtZWFuIHdlIHJlcXVpcmUg YSBrZXkgcm9sbG92ZXIgdG9kYXkgZm9yIGV2ZXJ5IDQgR0Igb2YgZGF0YSB0cmFuc2ZlciBzaW5j ZSB0aGUgUE4gaXMgb25seSBhIDQgYnl0ZSBmaWVsZD8gQWxzbyBJIGRvbuKAmXQgc2VlIHRoZW4g aG93IHRoZSBQTiBlbmNyeXB0aW9uIHByb3Bvc2FsIGlzIGd1YXJhbnRlZWluZyBub24tcmVwZWF0 aW5nIG91dHB1dD8NCg0KWW91IGNhbiBzdGFydCB3aXRoIHNlY3VyZSByYW5kb20gbnVtYmVyIGFu ZCB0aGVuIHVzZSBQUk5HIGZvciBzbWFsbCBqdW1wcyB0byBwcmV2ZW50IG9zc2lmaWNhdGlvbi4g QW5kIGRlcGVuZGluZyBvbiBob3cgb2Z0ZW4geW91IGp1bXAgeW91IHdpbGwgdGhlbiByZXF1aXJl IGtleSByb2xsb3ZlciBlYXJseSB1bnRpbCB5b3Ugcm9sbG92ZXIgYW5kIGhpdCB0aGUgc3RhcnRp bmcgbm9uY2UgbnVtYmVyLiBUaGUgb3RoZXIgZ29vZCBwYXJ0IG9mIHVuLW92ZXJsb2FkaW5nIGlz IHRoYXQgd2UgY2FuIG1ha2UgdGhlIG5vbmNlIG9wdGlvbmFsIHdoZW4gbm90IG5lZWRlZCBuZWVk ZWQgYnkgY3J5cHRvLg0KDQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOm1iaXNob3BAZXZlcXVl Zm91LmJlXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggMTA6MTkgUE0NClRvOiBQ cmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJA bWljcm9zb2Z0LmNvbT4+OyBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0 ZW1hQGh1aXRlbWEubmV0Pj47IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSRTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCllvdSBjYW7igJl0IHNhZmVs eSByZXVzZSB0aGUgY29tYmluYXRpb24gb2Ygbm9uY2UgYW5kIGtleSwgSUlVQy4gIFNpbmNlIGtl eSByb2xsb3ZlciBpcyBpbmZyZXF1ZW50LCB0aGUgbm9uY2UgaGFzIHRvIGNoYW5nZSBldmVyeSBw YWNrZXQgYW5kIGJlIGd1YXJhbnRlZWQgdW5pcXVlIG92ZXIgdGhlIGxpZmV0aW1lIG9mLCBpZiBu b3QgdGhlIGNvbm5lY3Rpb24sIGF0IGxlYXN0IHRoZSBjdXJyZW50IGtleS4gIFNpbmNlIHBhY2tl dCBudW1iZXJzIGFsc28gZG9u4oCZdCByZXBlYXQgb3ZlciB0aGUgbGlmZXRpbWUgb2YgdGhlIGNv bm5lY3Rpb24sIEkgdGhpbmsgdXNpbmcgb25lIGFzIHRoZSB2YXJpYWJsZSBwYXJ0IG9mIHRoZSBv dGhlciB3YXMganVzdCB0YWtpbmcgYWR2YW50YWdlIG9mIHRoZSBhbGlnbm1lbnQuDQoNCkkgZG9u 4oCZdCB0aGluayBoYXZpbmcgYSByYW5kb21pemVkIHN0YXJ0aW5nIHZhbHVlIGFuZCBpbmNyZW1l bnRpbmcgaXMgbmVjZXNzYXJpbHkgYW55IGJldHRlciB0aGFuIGV4cG9zaW5nIHRoZSBwYWNrZXQg bnVtYmVyLiAgSGF2aW5nIGEgUFJORyBzZWVkIGVzdGFibGlzaGVkIGR1cmluZyB0aGUgaGFuZHNo YWtlIGFuZCBtYWtpbmcgdGhlIHZpc2libGUgdGhpbmcgdGhlIG5leHQgcmFuZG9tIG91dHB1dCBz ZWVtcyBwb3RlbnRpYWxseSBpbnRlcmVzdGluZywgYnV0IEnigJlkIHdhbnQgb3VyIG1vcmUgY3J5 cHRvLW1pbmRlZCBmcmllbmRzIHRvIGNvbW1lbnQuICBJIHRoaW5rIHRoZSByZWFsIGlzc3VlIHdv dWxkIGJlIGd1YXJhbnRlZXMgYWJvdXQgbmV2ZXItcmVwZWF0aW5nIGZyb20gdGhlIFBSTkcsIHBh cnRpY3VsYXJseSBhcyB5b3UgZG9u4oCZdCBoYXZlIGd1YXJhbnRlZXMgYWJvdXQgeW91ciBwZWVy 4oCZcyBpbXBsZW1lbnRhdGlvbi4gIEEgZGVmaW5lZCBrZXkgZGVyaXZhdGlvbiBhbmQgYSBjb3Vu dGVyIGNhbiBiZSB2ZXJpZmllZCBpbiB0aGUgcHJvdG9jb2wsIGluZGVwZW5kZW50IG9mIGhvdyBn b29kIHRoZSBwZWVy4oCZcyBQUk5HIGlzLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NClNlbnQ6 IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDk6NDAgUE0NClRvOiBodWl0ZW1hIDxodWl0ZW1h QGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj47IHF1aWNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogUGFja2V0IG51bWJlciBlbmNyeXB0 aW9uDQoNCkFjdHVhbGx5IHRha2luZyBhIHN0ZXAgYmFjayB3aGF0IGlmIHdlIGRvbuKAmXQgd2Ug b3ZlcmxvYWRlZCBwYWNrZXQgbnVtYmVyIGFzIHRoZSBub25jZT8NCg0KQ2FuIHdlOg0KDQogIDEu ICBQdXQgcGFja2V0IG51bWJlciBhcyBhIHNlcGFyYXRlIHZhcmlhYmxlIGxlbmd0aCBmaWVsZCBp biB0aGUgZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhlYWRlci4gVGhpcyBhbGxvd3MgZm9yIGdy b3d0aCBiZXlvbmQgNjQgYml0cyBpbiBmdXR1cmUgYW5kIGNvbXBsZXRlbHkgYXZvaWRzIG9zc2lm aWNhdGlvbi4gRm9yIHNob3J0IGxpdmVkIGZsb3dzIHZhcmlhYmxlIGxlbmd0aCBlbmNvZGluZyBs ZWFkcyB0byBtaW5pbWFsIHNwYWNlIG92ZXJoZWFkLg0KICAyLiAgUHV0IGEgc2VwYXJhdGUgcGxh aW50ZXh0IG5vbmNlIHdoaWNoIHN0YXJ0cyBvdXQgYXMgYSBzZWN1cmUgcmFuZG9tIG51bWJlciBh bmQgbW9ub3RvbmljYWxseSBpbmNyZWFzZXMgYXMgc2hvcnQgcmFuZG9tIGp1bXBzIChldmVyeSBw YWNrZXQgb3IgZXZlcnkgZmV3IHBhY2tldHMpIGFuZCBjb3VsZCB0aGVuIHJvbGxvdmVyLiBUaGlz IHdpbGwgcHJldmVudCBsaW5rYWJpbGl0eSBhbmQgc2NhbGVzIHRvIG11bHRpLXBhdGggYXMgd2Vs bC4gTm8gbWFqb3IgY29tcHV0ZSBvdmVyaGVhZC4gV2UgY2FuIGFsc28gbWFrZSB0aGUgbm9uY2Ug b3B0aW9uYWwgZm9yIGNyeXB0byBhbGdvcml0aG1zIHRoYXQgZG8gbm90IG5lZWQgYSBub25jZSBz YXZpbmcgbW9yZSBzcGFjZS4NCg0KU29tZSBNU0Igb2YgdGhlIG5vbmNlIGNvdWxkIGJlIHVzZWQg Zm9yIHNpZ25hbGluZyByZW9yZGVyIHRvIHRoZSBuZXR3b3JrIGlmIG5lZWRlZC4gSSBkb27igJl0 IGhhdmUgdGhlIGhpc3RvcmljYWwgY29udGV4dCBmb3Igb3ZlcmxvYWRpbmcgb2YgUE4gYXMgdGhl IG5vbmNlIHNvIHBhcmRvbiBtZSBpZiB1bi1vdmVybG9hZGluZyBvcHRpb24gd2FzIGRpc2N1c3Nl ZCBhbmQgcnVsZWQgb3V0IGJlZm9yZS4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQpTZW50OiBU aHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCA1OjUxIFBNDQpUbzogaHVpdGVtYSA8aHVpdGVtYUBo dWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+OyBxdWljQGlldGYub3JnPG1h aWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlv bg0KDQo+PiBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRo DQpUaGlzIGFsb25lIHByZXZlbnRzIGxpbmthYmlsaXR5IHJpZ2h0Pw0KDQo+PiBUaGUgcGFja2V0 IG51bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFydCBhdCAxIChvciBtYXliZSAwIDstKS4NCklz IHN1cHBvcnRpbmcgbXVsdGlwbGUgcGF0aHMgYXQgdGhlIHNhbWUgdGltZSBhIGdvYWw/IElmIHll cywgdGhlbiB5ZXMgYWxsIHBhdGhzIHdpbGwgbmVlZCB0byBoYXZlIHNlcGFyYXRlIHRyYWNraW5n IGFuZCBBQ0sgc3RhdGUgYW5kIGNvbmdlc3Rpb24gY29udHJvbCBldGMuIEkgdGhvdWdodCB0aGlz IGlzIG5vdCBwYXJ0IG9mIFYxIFJGQy4gSWYgaXRzIGp1c3Qgb25lIGFkZGl0aW9uYWwgcGF0aCBm b3IgY29ubmVjdGlvbiBtaWdyYXRpb24gc2NlbmFyaW8gdGhlbiBhbGwgeW91IG5lZWQgaXMgYSAo cmFuZG9tKSBqdW1wIHRvIGEgb2Zmc2V0IGluIHBhY2tldCBudW1iZXIgc3BhY2UgZm9yIHRoZSBu ZXcgcGF0aCBzbyB0aGF0IHRoZSBmZXcgcGFja2V0cyBpbiB0aGUgb2xkIHBhdGggY2FuIGNvbnRp bnVlIGZvciBhIGxpdHRsZSBiaXQuIFRoaXMgd29ya3Mgd2l0aCBqdXN0IG9uZSBBQ0sgc3BhY2Ug c28gbm8gaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS4NCg0KPj4gMikgT3IsIGxlYXZpbmcgdGhl IHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1dCB1c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlv biBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVl bmNlcyBmb3IgZWFjaCBwYXRoLg0KSW4gYWRkaXRpb24gaWYgdGhlIHZhbHVlIGluIHRoZSBjbGVh ciB3YXMgb2JmdXNjYXRlZCB3aXRoIGFuIFhPUiB0cmFuc2Zvcm0gaXQgd2lsbCBoZWxwIHByZXZl bnQgb3NzaWZpY2F0aW9uLiBUaGUgb2JmdXNjYXRpb24gaXMgbm90IG1lYW50IHRvIGd1YXJkIGFn YWluc3QgbGF0ZXIgYW5hbHlzaXMgdGhhdCByZXZlYWxzIHRoZSBwYWNrZXQgbnVtYmVycyAtIHdo eSBkbyB3ZSBjYXJlIGFib3V0IHRoYXQuIEl0IGlzIG1lYW50IHRvIGdyZWFzZSB0aGUgc3BhY2Ug YW5kIG5vdCBtYWtlIHRoZSBudW1iZXJzIHNlcmlhbCBzbyBtaWRkbGVib3hlcyBjYW5ub3QgYXNz dW1lIG9yZGVyaW5nIGV0Yy4NCg0KQWxsIHNhaWQgaWYgSSBhbSBhbG9uZSBpbiBiZWluZyBjb25j ZXJuZWQgYWJvdXQgdGhlIHBlcmYgaGl0IHRoZW4gSeKAmWQgc2F5IGdvIG9uIHdpdGggb3B0aW9u IDEuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBDaHJpc3RpYW4gSHVpdGVtYQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTgg Mzo1NCBQTQ0KVG86IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCg0KT24gMi84LzIwMTggMToxMyBQTSwg TWlrZSBCaXNob3Agd3JvdGU6DQojMiB3b27igJl0IHdvcmsuICBUaGUgcGFja2V0IG51bWJlciBp cyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwgc28geW91IGhhdmUgdG8gZ2V0IHRvIHRoZSBw YWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRlY3J5cHQgdGhlIHBheWxvYWQuICBJdCBjYW7i gJl0IGJlIGJhc2VkIG9uIGFueXRoaW5nIGludGVybmFsIHRvIHRoZSBlbmNyeXB0ZWQgcGFja2V0 Lg0KDQpJbiBNYXJ0aW7igJlzIHByb3Bvc2FsLCBpdOKAmXMgdXNpbmcgYSBjb21iaW5hdGlvbiBv ZiB0aGUgZW5jcnlwdGVkIHBheWxvYWQgKHdoaWNoIHJlcXVpcmVzIG5vdGhpbmcgdG8gYWNjZXNz KSBhbmQgc29tZSBzdG9yZWQgc3RhdGUgb24gZWFjaCBlbmRwb2ludCwgd2hpY2ggcmVxdWlyZXMg b25seSB0aGUgQ29ubmVjdGlvbiBJRCB0byBsb29rIHVwLiAgWW91IHdhbnQgdGhlIHRoaW5nIHlv dSBYT1IgYnkgdG8gYmUgY29uc3RhbnRseSBjaGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNpZXIg dG8gbG9vayBhdCBzZXF1ZW5jZXMgb2Ygb2JmdXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQgc3Rh cnQgZHJhd2luZyBpbmZlcmVuY2VzIGFib3V0IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4gIElmIG92 ZXJoZWFkIGlzIHRoZSBwcmltYXJ5IGNvbmNlcm4sIEkgdGhpbmsgdGhlcmUgYXJlIGEgY291cGxl IGFwcHJvYWNoZXMgdGhhdCBtaWdodCBhbGxvdyB5b3UgdG8gcHJlY29tcHV0ZSB2YWx1ZXMgYW5k IGFtb3J0aXplIHRoZSBjb3N0IG9mIGRvaW5nIHRoZSBlbmNyeXB0aW9uIHN0ZXAuICAoQXQgdGhl IGNvc3Qgb2Yga2VlcGluZyB0aGUgdGFibGUgb2YgcHJlY29tcHV0ZWQgdmFsdWVzLCBvZiBjb3Vy c2UuKQ0KDQpJIHN0aWxsIHRoaW5rIEphbmHigJlzIHB1c2hpbmcgaW4gdGhlIHJpZ2h0IGRpcmVj dGlvbiBoZXJlOiAgTGV04oCZcyBhZ3JlZSBvbiBnb2FscywgYW5kIHRoZW4gc2VlIGlmIHdlIGNh biBjcmFmdCBhIGRlc2lnbiB0aGF0IG1lZXRzIHRob3NlIGdvYWxzLiAgSSBoZWFyIHlvdSBzYXlp bmcgdGhhdCBsb3cgb3ZlcmhlYWQgaXMgYSBnb2FsLCB3aGljaCBJIHRoaW5rIHdlIGNhbiBhbGwg YWdyZWUgb24uICBJIGFsc28gdGhpbmsgSSBoZWFyIHlvdSBzYXlpbmcgdGhhdCAxLTEuNSUgb3Zl cmhlYWQgaXMgdG9vIGhpZ2gsIGJ1dCBpdCBzb3VuZHMgbGlrZSB0aGVyZeKAmXMgbGVzcyBhZ3Jl ZW1lbnQgb24gdGhhdC4gIFlvdSBhbHNvIHJhaXNlIGFuIGludGVyZXN0aW5nIHBvaW50IHRoYXQg c29tZSBjbGllbnRzIHdpbGwgY2FyZSBsZXNzIGFib3V0IGxpbmthYmlsaXR5IGJlY2F1c2UgdGhl eSB3aWxsIG5ldmVyIGludGVudGlvbmFsbHkgbWlncmF0ZS4NCg0KSSB0aGluayBWaWN0b3Igc2Fp ZCBpdCBiZXN0LCAiT2JmdXNjYXRpb24gaXMganVzdCBlbmNyeXB0aW9uIGRvbmUgcG9vcmx5LiIg RWl0aGVyIHdlIGVuY3J5cHQsIG9yIHdlIGRvbid0LiBCdXQgdGhlcmUgaXMgbm8gc3VjaCB0aGlu ZyBhcyBhbiBvYmZ1c2NhdGlvbiBtaWRkbGUtZ3JvdW5kLiBPYmZ1c2NhdGlvbiB3b3VsZCBqdXN0 IGJlIGEgc3BlZWQgYnVtcCwgZWFzaWx5IGJyb2tlbi4gSXQgd29uJ3QgcHJvdmlkZSBwcml2YWN5 LCBhbmQgaXQgd29uJ3QgcHJldmVudCBsaW5rYWJpbGl0eS4NCg0KQXMgZmFyIGFzIEkgYW0gY29u Y2VybmVkLCB0aGVyZSBhcmUgb25seSB0d28gZGVzaWducyB0aGF0IHByZXZlbnQgbGlua2FiaWxp dHk6DQoNCjEpIE1hcnRpbidzIFBSLCBpbiB3aGljaCB0aGUgcGFja2V0IG51bWJlciBpcyBlbmNy eXB0ZWQgdXNpbmcgc2Vuc2libGUgY3J5cHRvOw0KDQoyKSBPciwgbGVhdmluZyB0aGUgcGFja2V0 IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5nIGRpZmZlcmVudCBlbmNyeXB0aW9uIGNvbnRl eHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZv ciBlYWNoIHBhdGguDQoNClRoZSBzZWNvbmQgb3B0aW9uIHJlcXVpcmVzIG1vcmUgY29tcHV0YXRp b24gd2hlbiBleHBsaWNpdGx5IHNldHRpbmcgdXAgYSBuZXcgcGF0aC4gVGhlIGNvbm5lY3Rpb24g SUQgd291bGQgYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSAic2FsdCIgd2hlbiBkZXJpdmluZyBjb25u ZWN0aW9uIGNvbnRleHRzLiBUaGUgcGFja2V0IG51bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFy dCBhdCAxIChvciBtYXliZSAwIDstKS4gVGhpcyByZXF1aXJlcyBtYWludGFpbmluZyBzZXBhcmF0 ZSBTQUNLIGRhc2hib2FyZHMgZm9yIGVhY2ggcGF0aC9Db25uZWN0aW9uLUlELCBhbmQgY29uc3Ry YWluaW5nIEFDSyB0byBiZSBwZXIvcGF0aCwgb3IgYWx0ZXJuYXRpdmVseSBhZGRpbmcgYSBQQVRI LUFDSyBmcmFtZSB0aGF0IGluZGljYXRlcyB0aGUgcGF0aCBmb3Igd2hpY2ggcGFja2V0cyBhcmUg YWNrZWQuDQoNClRoZSBwcm9zIGFuZCBjb25zIG9mIHRoZSB0d28gb3B0aW9ucyBhcmUgZWFzeSB0 byBnZXQ6DQoNCjEpIE9wdGlvbiAyIGRvZXMgbm90IHJlcXVpcmUgdGhlIGNvc3Qgb2YgZW5jcnlw dGluZyBldmVyeSBwYWNrZXQsIHRodXMgcGVyIHBhY2tldCBwcm9jZXNzaW5nIHdpbGwgYmUgbWF5 YmUgMSUgZmFzdGVyIHRoYW4gb3B0aW9uIDEuDQoNCjIpIE9wdGlvbiAyIHJlcXVpcmVzIGNvbXB1 dGluZyBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIHdoaWNoIGlzIG1vcmUgY29t cGxleCB0aGFuIG9wdGlvbiAxLCBidXQgdGhlIGNvc3Qgd2lsbCBiZSBhbW9ydGl6ZWQgb3ZlciB0 aGUgZHVyYXRpb24gb2YgdGhlIHBhdGguDQoNCjMpIE9wdGlvbiAyIHJlcXVpcmVzIG1vcmUgY29t cGxleCBkYXRhIHN0cnVjdHVyZXMgYW5kIEFDSyBtYW5hZ2VtZW50LCB0aHVzIGluY3JlYXNpbmcg dGhlIGNoYW5jZXMgdGhhdCBzb21ldGhpbmcgZ29lcyB3cm9uZy4NCg0KNCkgT3B0aW9uIDIgZG9l cyBub3RoaW5nIGFnYWluc3QgcGFja2V0IG51bWJlciBvc3NpZmljYXRpb24uIFRoZSBwYWNrZXQg bnVtYmVyIGVmZmVjdGl2ZWx5IGJlY29tZXMgcGFydCBvZiB0aGUgaW52YXJpYW50cy4NCg0KSW4g c2hvcnQsIHRoZSBvbmx5IGFkdmFudGFnZSBvZiBvcHRpb24gMiBpcyB0byBhdm9pZCBhIHNpbmds ZSBzeW1tZXRyaWMgZW5jcnlwdGlvbiBvcGVyYXRpb24gcGVyIHBhY2tldCwgd2hpbGUgbWFraW5n IHRoZSBjb2RlIHNpZ25pZmljYW50bHkgbW9yZSBjb21wbGV4LCBhbmQgYXQgdGhlIGNvc3Qgb2Yg bm90IHByb3RlY3RpbmcgYWdhaW5zdCBQTiBvc3NpZmljYXRpb24uIFRoZSB3YXkgSSBzZWUgdGhh dCwgdGhlcmUgaXMgaGFyZGx5IGFueSBkZWJhdGUuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQo= --_000_CY4PR21MB013355B5E786890979B98FB2B6F20CY4PR21MB0133namp_ 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 YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6YmxhY2s7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9y OmJsYWNrO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjpibGFjazt9DQpzcGFuLkhUTUxQ cmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9y bWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCnNwYW4uUGxh aW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyNQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTM0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NzMy ODk0NDM5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1MTQzNTgxNjY7fQ0KQGxpc3QgbDENCgl7 bXNvLWxpc3QtaWQ6MTc3NTU5MTY3MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTEwMzQ3OTkzNzIgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxp c3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwy DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJv bWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+U2NyYXRj aCB0aGUgcXVlc3Rpb24gb24gUE4gZW5jcnlwdGlvbiBwcm9wb3NhbCBzaW5jZSBpdOKAmXMgdGhl IHBsYWludGV4dCB0aGF04oCZcyB0aGUgbm9uY2Ugbm90IHRoZSBlbmNyeXB0ZWQgdmVyc2lvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5QcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCAxMTowNiBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBC aXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0OzsgaHVpdGVtYSAmbHQ7aHVpdGVtYUBo dWl0ZW1hLm5ldCZndDs7IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFBh Y2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Eb2VzIHRoaXMgbWVh biB3ZSByZXF1aXJlIGEga2V5IHJvbGxvdmVyIHRvZGF5IGZvciBldmVyeSA0IEdCIG9mIGRhdGEg dHJhbnNmZXIgc2luY2UgdGhlIFBOIGlzIG9ubHkgYSA0IGJ5dGUgZmllbGQ/IEFsc28gSSBkb27i gJl0IHNlZSB0aGVuIGhvdyB0aGUgUE4gZW5jcnlwdGlvbiBwcm9wb3NhbCBpcyBndWFyYW50ZWVp bmcgbm9uLXJlcGVhdGluZyBvdXRwdXQ/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OndpbmRvd3RleHQiPllvdSBjYW4gc3RhcnQgd2l0aCBzZWN1cmUgcmFuZG9tIG51bWJlciBhbmQg dGhlbiB1c2UgUFJORyBmb3Igc21hbGwganVtcHMgdG8gcHJldmVudCBvc3NpZmljYXRpb24uIEFu ZCBkZXBlbmRpbmcgb24gaG93IG9mdGVuIHlvdSBqdW1wIHlvdSB3aWxsIHRoZW4gcmVxdWlyZSBr ZXkgcm9sbG92ZXIgZWFybHkgdW50aWwgeW91IHJvbGxvdmVyIGFuZCBoaXQgdGhlDQogc3RhcnRp bmcgbm9uY2UgbnVtYmVyLiBUaGUgb3RoZXIgZ29vZCBwYXJ0IG9mIHVuLW92ZXJsb2FkaW5nIGlz IHRoYXQgd2UgY2FuIG1ha2UgdGhlIG5vbmNlIG9wdGlvbmFsIHdoZW4gbm90IG5lZWRlZCBuZWVk ZWQgYnkgY3J5cHRvLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij4gTWlrZSBCaXNob3AgWzxhIGhyZWY9Im1haWx0 bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSI+bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPl0N Cjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCAxMDoxOSBQTTxi cj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0 bzpwcmF2YkBtaWNyb3NvZnQuY29tIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZndDs7IGh1aXRl bWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Ij5odWl0ZW1hQGh1aXRl bWEubmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlv bjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Zb3UgY2Fu4oCZdCBzYWZlbHkgcmV1c2UgdGhlIGNvbWJp bmF0aW9uIG9mIG5vbmNlIGFuZCBrZXksIElJVUMuJm5ic3A7IFNpbmNlIGtleSByb2xsb3ZlciBp cyBpbmZyZXF1ZW50LCB0aGUgbm9uY2UgaGFzIHRvIGNoYW5nZSBldmVyeSBwYWNrZXQgYW5kIGJl IGd1YXJhbnRlZWQgdW5pcXVlIG92ZXIgdGhlIGxpZmV0aW1lIG9mLCBpZiBub3QgdGhlIGNvbm5l Y3Rpb24sDQogYXQgbGVhc3QgdGhlIGN1cnJlbnQga2V5LiZuYnNwOyBTaW5jZSBwYWNrZXQgbnVt YmVycyBhbHNvIGRvbuKAmXQgcmVwZWF0IG92ZXIgdGhlIGxpZmV0aW1lIG9mIHRoZSBjb25uZWN0 aW9uLCBJIHRoaW5rIHVzaW5nIG9uZSBhcyB0aGUgdmFyaWFibGUgcGFydCBvZiB0aGUgb3RoZXIg d2FzIGp1c3QgdGFraW5nIGFkdmFudGFnZSBvZiB0aGUgYWxpZ25tZW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0 ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+SSBkb27igJl0IHRoaW5rIGhhdmluZyBhIHJh bmRvbWl6ZWQgc3RhcnRpbmcgdmFsdWUgYW5kIGluY3JlbWVudGluZyBpcyBuZWNlc3NhcmlseSBh bnkgYmV0dGVyIHRoYW4gZXhwb3NpbmcgdGhlIHBhY2tldCBudW1iZXIuJm5ic3A7IEhhdmluZyBh IFBSTkcgc2VlZCBlc3RhYmxpc2hlZCBkdXJpbmcgdGhlIGhhbmRzaGFrZSBhbmQgbWFraW5nIHRo ZSB2aXNpYmxlIHRoaW5nDQogdGhlIG5leHQgcmFuZG9tIG91dHB1dCBzZWVtcyBwb3RlbnRpYWxs eSBpbnRlcmVzdGluZywgYnV0IEnigJlkIHdhbnQgb3VyIG1vcmUgY3J5cHRvLW1pbmRlZCBmcmll bmRzIHRvIGNvbW1lbnQuJm5ic3A7IEkgdGhpbmsgdGhlIHJlYWwgaXNzdWUgd291bGQgYmUgZ3Vh cmFudGVlcyBhYm91dCBuZXZlci1yZXBlYXRpbmcgZnJvbSB0aGUgUFJORywgcGFydGljdWxhcmx5 IGFzIHlvdSBkb27igJl0IGhhdmUgZ3VhcmFudGVlcyBhYm91dCB5b3VyIHBlZXLigJlzIGltcGxl bWVudGF0aW9uLiZuYnNwOw0KIEEgZGVmaW5lZCBrZXkgZGVyaXZhdGlvbiBhbmQgYSBjb3VudGVy IGNhbiBiZSB2ZXJpZmllZCBpbiB0aGUgcHJvdG9jb2wsIGluZGVwZW5kZW50IG9mIGhvdyBnb29k IHRoZSBwZWVy4oCZcyBQUk5HIGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IFFVSUMgWzxhIGhyZWY9Im1haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5QcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjxicj4NCjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCA5OjQwIFBNPGJyPg0KPGI+VG86PC9i PiBodWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVt YUBodWl0ZW1hLm5ldDwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1 aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQYWNrZXQgbnVtYmVyIGVu Y3J5cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+QWN0dWFsbHkgdGFraW5nIGEgc3RlcCBiYWNr IHdoYXQgaWYgd2UgZG9u4oCZdCB3ZSBvdmVybG9hZGVkIHBhY2tldCBudW1iZXIgYXMgdGhlIG5v bmNlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+Q2FuIHdlOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIx IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+UHV0IHBhY2tldCBudW1iZXIgYXMgYSBzZXBhcmF0 ZSB2YXJpYWJsZSBsZW5ndGggZmllbGQgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBo ZWFkZXIuIFRoaXMgYWxsb3dzIGZvciBncm93dGggYmV5b25kIDY0IGJpdHMgaW4gZnV0dXJlIGFu ZCBjb21wbGV0ZWx5IGF2b2lkcyBvc3NpZmljYXRpb24uIEZvciBzaG9ydA0KIGxpdmVkIGZsb3dz IHZhcmlhYmxlIGxlbmd0aCBlbmNvZGluZyBsZWFkcyB0byBtaW5pbWFsIHNwYWNlIG92ZXJoZWFk LiA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O21zby1saXN0OmwxIGxldmVsMSBsZm8zIj5QdXQgYSBzZXBhcmF0ZSBwbGFpbnRleHQg bm9uY2Ugd2hpY2ggc3RhcnRzIG91dCBhcyBhIHNlY3VyZSByYW5kb20gbnVtYmVyIGFuZCBtb25v dG9uaWNhbGx5IGluY3JlYXNlcyBhcyBzaG9ydCByYW5kb20ganVtcHMgKGV2ZXJ5IHBhY2tldCBv ciBldmVyeSBmZXcgcGFja2V0cykgYW5kIGNvdWxkIHRoZW4gcm9sbG92ZXIuIFRoaXMNCiB3aWxs IHByZXZlbnQgbGlua2FiaWxpdHkgYW5kIHNjYWxlcyB0byBtdWx0aS1wYXRoIGFzIHdlbGwuIE5v IG1ham9yIGNvbXB1dGUgb3ZlcmhlYWQuIFdlIGNhbiBhbHNvIG1ha2UgdGhlIG5vbmNlIG9wdGlv bmFsIGZvciBjcnlwdG8gYWxnb3JpdGhtcyB0aGF0IGRvIG5vdCBuZWVkIGEgbm9uY2Ugc2F2aW5n IG1vcmUgc3BhY2UuDQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+ U29tZSBNU0Igb2YgdGhlIG5vbmNlIGNvdWxkIGJlIHVzZWQgZm9yIHNpZ25hbGluZyByZW9yZGVy IHRvIHRoZSBuZXR3b3JrIGlmIG5lZWRlZC4gSSBkb27igJl0IGhhdmUgdGhlIGhpc3RvcmljYWwg Y29udGV4dCBmb3Igb3ZlcmxvYWRpbmcgb2YgUE4gYXMgdGhlIG5vbmNlIHNvIHBhcmRvbiBtZSBp ZiB1bi1vdmVybG9hZGluZyBvcHRpb24gd2FzIGRpc2N1c3NlZA0KIGFuZCBydWxlZCBvdXQgYmVm b3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Y29sb3I6d2luZG93dGV4dCI+IFFVSUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5QcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg RmVicnVhcnkgOCwgMjAxOCA1OjUxIFBNPGJyPg0KPGI+VG86PC9iPiBodWl0ZW1hICZsdDs8YSBo cmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4m Z3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBhbmQgdXNpbmcg c2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRoPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGFsb25lIHByZXZlbnRzIGxpbmthYmlsaXR5IHJpZ2h0 PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyBUaGUgcGFja2V0IG51bWJlciBvbiBl YWNoIHBhdGggd2lsbCBzdGFydCBhdCAxIChvciBtYXliZSAwIDstKS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHN1cHBvcnRpbmcgbXVsdGlwbGUgcGF0aHMgYXQgdGhl IHNhbWUgdGltZSBhIGdvYWw/IElmIHllcywgdGhlbiB5ZXMgYWxsIHBhdGhzIHdpbGwgbmVlZCB0 byBoYXZlIHNlcGFyYXRlIHRyYWNraW5nIGFuZCBBQ0sgc3RhdGUgYW5kIGNvbmdlc3Rpb24gY29u dHJvbCBldGMuIEkgdGhvdWdodCB0aGlzIGlzIG5vdCBwYXJ0IG9mIFYxIFJGQy4gSWYgaXRzIGp1 c3Qgb25lIGFkZGl0aW9uYWwgcGF0aCBmb3IgY29ubmVjdGlvbg0KIG1pZ3JhdGlvbiBzY2VuYXJp byB0aGVuIGFsbCB5b3UgbmVlZCBpcyBhIChyYW5kb20pIGp1bXAgdG8gYSBvZmZzZXQgaW4gcGFj a2V0IG51bWJlciBzcGFjZSBmb3IgdGhlIG5ldyBwYXRoIHNvIHRoYXQgdGhlIGZldyBwYWNrZXRz IGluIHRoZSBvbGQgcGF0aCBjYW4gY29udGludWUgZm9yIGEgbGl0dGxlIGJpdC4gVGhpcyB3b3Jr cyB3aXRoIGp1c3Qgb25lIEFDSyBzcGFjZSBzbyBubyBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jmd0OyAyKSBPciwgbGVhdmluZyB0aGUgcGFj a2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5nIGRpZmZlcmVudCBlbmNyeXB0aW9uIGNv bnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2Vz IGZvciBlYWNoIHBhdGguPGJyPg0KSW4gYWRkaXRpb24gaWYgdGhlIHZhbHVlIGluIHRoZSBjbGVh ciB3YXMgb2JmdXNjYXRlZCB3aXRoIGFuIFhPUiB0cmFuc2Zvcm0gaXQgd2lsbCBoZWxwIHByZXZl bnQgb3NzaWZpY2F0aW9uLiBUaGUgb2JmdXNjYXRpb24gaXMgbm90IG1lYW50IHRvIGd1YXJkIGFn YWluc3QgbGF0ZXIgYW5hbHlzaXMgdGhhdCByZXZlYWxzIHRoZSBwYWNrZXQgbnVtYmVycyAtIHdo eSBkbyB3ZSBjYXJlIGFib3V0IHRoYXQuIEl0IGlzIG1lYW50IHRvIGdyZWFzZSB0aGUNCiBzcGFj ZSBhbmQgbm90IG1ha2UgdGhlIG51bWJlcnMgc2VyaWFsIHNvIG1pZGRsZWJveGVzIGNhbm5vdCBh c3N1bWUgb3JkZXJpbmcgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwgc2FpZCBpZiBJ IGFtIGFsb25lIGluIGJlaW5nIGNvbmNlcm5lZCBhYm91dCB0aGUgcGVyZiBoaXQgdGhlbiBJ4oCZ ZCBzYXkgZ28gb24gd2l0aCBvcHRpb24gMS4NCjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0 Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6d2luZG93dGV4dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQiPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+Q2hyaXN0aWFuIEh1aXRlbWE8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5 IDgsIDIwMTggMzo1NCBQTTxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0 Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQg bnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD5PbiAyLzgvMjAx OCAxOjEzIFBNLCBNaWtlIEJpc2hvcCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+IzIgd29u4oCZdCB3b3JrLiZuYnNwOyBUaGUgcGFja2V0IG51bWJlciBpcyBh biBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwgc28geW91IGhhdmUgdG8gZ2V0IHRvIHRoZSBwYWNr ZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRlY3J5cHQgdGhlIHBheWxvYWQuJm5ic3A7IEl0IGNh buKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcgaW50ZXJuYWwgdG8gdGhlIGVuY3J5cHRlZCBwYWNr ZXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIE1hcnRpbuKAmXMgcHJvcG9zYWwsIGl04oCZ cyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mIHRoZSBlbmNyeXB0ZWQgcGF5bG9hZCAod2hpY2ggcmVx dWlyZXMgbm90aGluZyB0byBhY2Nlc3MpIGFuZCBzb21lIHN0b3JlZCBzdGF0ZSBvbiBlYWNoIGVu ZHBvaW50LCB3aGljaCByZXF1aXJlcyBvbmx5IHRoZSBDb25uZWN0aW9uIElEIHRvIGxvb2sgdXAu Jm5ic3A7IFlvdSB3YW50IHRoZSB0aGluZyB5b3UgWE9SIGJ5IHRvIGJlIGNvbnN0YW50bHkNCiBj aGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNpZXIgdG8gbG9vayBhdCBzZXF1ZW5jZXMgb2Ygb2Jm dXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQgc3RhcnQgZHJhd2luZyBpbmZlcmVuY2VzIGFib3V0 IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4mbmJzcDsgSWYgb3ZlcmhlYWQgaXMgdGhlIHByaW1hcnkg Y29uY2VybiwgSSB0aGluayB0aGVyZSBhcmUgYSBjb3VwbGUgYXBwcm9hY2hlcyB0aGF0IG1pZ2h0 IGFsbG93IHlvdSB0byBwcmVjb21wdXRlIHZhbHVlcw0KIGFuZCBhbW9ydGl6ZSB0aGUgY29zdCBv ZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVwLiZuYnNwOyAoQXQgdGhlIGNvc3Qgb2Yga2VlcGlu ZyB0aGUgdGFibGUgb2YgcHJlY29tcHV0ZWQgdmFsdWVzLCBvZiBjb3Vyc2UuKTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHN0aWxsIHRoaW5rIEphbmHigJlzIHB1c2hpbmcgaW4gdGhlIHJpZ2h0 IGRpcmVjdGlvbiBoZXJlOiZuYnNwOyBMZXTigJlzIGFncmVlIG9uIGdvYWxzLCBhbmQgdGhlbiBz ZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWduIHRoYXQgbWVldHMgdGhvc2UgZ29hbHMuJm5ic3A7 IEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92ZXJoZWFkIGlzIGEgZ29hbCwgd2hpY2ggSSB0 aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiZuYnNwOyBJIGFsc28gdGhpbmsNCiBJIGhlYXIgeW91 IHNheWluZyB0aGF0IDEtMS41JSBvdmVyaGVhZCBpcyB0b28gaGlnaCwgYnV0IGl0IHNvdW5kcyBs aWtlIHRoZXJl4oCZcyBsZXNzIGFncmVlbWVudCBvbiB0aGF0LiZuYnNwOyBZb3UgYWxzbyByYWlz ZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNvbWUgY2xpZW50cyB3aWxsIGNhcmUgbGVzcyBh Ym91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRoZXkgd2lsbCBuZXZlciBpbnRlbnRpb25hbGx5IG1p Z3JhdGUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkkgdGhpbmsgVmljdG9yIHNhaWQg aXQgYmVzdCwgJnF1b3Q7T2JmdXNjYXRpb24gaXMganVzdCBlbmNyeXB0aW9uIGRvbmUgcG9vcmx5 LiZxdW90OyBFaXRoZXIgd2UgZW5jcnlwdCwgb3Igd2UgZG9uJ3QuIEJ1dCB0aGVyZSBpcyBubyBz dWNoIHRoaW5nIGFzIGFuIG9iZnVzY2F0aW9uIG1pZGRsZS1ncm91bmQuIE9iZnVzY2F0aW9uIHdv dWxkIGp1c3QgYmUgYSBzcGVlZCBidW1wLCBlYXNpbHkgYnJva2VuLiBJdCB3b24ndCBwcm92aWRl IHByaXZhY3ksIGFuZCBpdCB3b24ndA0KIHByZXZlbnQgbGlua2FiaWxpdHkuPGJyPg0KPGJyPg0K QXMgZmFyIGFzIEkgYW0gY29uY2VybmVkLCB0aGVyZSBhcmUgb25seSB0d28gZGVzaWducyB0aGF0 IHByZXZlbnQgbGlua2FiaWxpdHk6PGJyPg0KPGJyPg0KMSkgTWFydGluJ3MgUFIsIGluIHdoaWNo IHRoZSBwYWNrZXQgbnVtYmVyIGlzIGVuY3J5cHRlZCB1c2luZyBzZW5zaWJsZSBjcnlwdG87PGJy Pg0KPGJyPg0KMikgT3IsIGxlYXZpbmcgdGhlIHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1 dCB1c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQg dXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRoLjxicj4NCjxicj4N ClRoZSBzZWNvbmQgb3B0aW9uIHJlcXVpcmVzIG1vcmUgY29tcHV0YXRpb24gd2hlbiBleHBsaWNp dGx5IHNldHRpbmcgdXAgYSBuZXcgcGF0aC4gVGhlIGNvbm5lY3Rpb24gSUQgd291bGQgYmUgdXNl ZCBhcyBwYXJ0IG9mIHRoZSAmcXVvdDtzYWx0JnF1b3Q7IHdoZW4gZGVyaXZpbmcgY29ubmVjdGlv biBjb250ZXh0cy4gVGhlIHBhY2tldCBudW1iZXIgb24gZWFjaCBwYXRoIHdpbGwgc3RhcnQgYXQg MSAob3IgbWF5YmUgMCA7LSkuIFRoaXMgcmVxdWlyZXMgbWFpbnRhaW5pbmcNCiBzZXBhcmF0ZSBT QUNLIGRhc2hib2FyZHMgZm9yIGVhY2ggcGF0aC9Db25uZWN0aW9uLUlELCBhbmQgY29uc3RyYWlu aW5nIEFDSyB0byBiZSBwZXIvcGF0aCwgb3IgYWx0ZXJuYXRpdmVseSBhZGRpbmcgYSBQQVRILUFD SyBmcmFtZSB0aGF0IGluZGljYXRlcyB0aGUgcGF0aCBmb3Igd2hpY2ggcGFja2V0cyBhcmUgYWNr ZWQuPGJyPg0KPGJyPg0KVGhlIHByb3MgYW5kIGNvbnMgb2YgdGhlIHR3byBvcHRpb25zIGFyZSBl YXN5IHRvIGdldDo8YnI+DQo8YnI+DQoxKSBPcHRpb24gMiBkb2VzIG5vdCByZXF1aXJlIHRoZSBj b3N0IG9mIGVuY3J5cHRpbmcgZXZlcnkgcGFja2V0LCB0aHVzIHBlciBwYWNrZXQgcHJvY2Vzc2lu ZyB3aWxsIGJlIG1heWJlIDElIGZhc3RlciB0aGFuIG9wdGlvbiAxLg0KPGJyPg0KPGJyPg0KMikg T3B0aW9uIDIgcmVxdWlyZXMgY29tcHV0aW5nIGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2gg cGF0aCwgd2hpY2ggaXMgbW9yZSBjb21wbGV4IHRoYW4gb3B0aW9uIDEsIGJ1dCB0aGUgY29zdCB3 aWxsIGJlIGFtb3J0aXplZCBvdmVyIHRoZSBkdXJhdGlvbiBvZiB0aGUgcGF0aC48YnI+DQo8YnI+ DQozKSBPcHRpb24gMiByZXF1aXJlcyBtb3JlIGNvbXBsZXggZGF0YSBzdHJ1Y3R1cmVzIGFuZCBB Q0sgbWFuYWdlbWVudCwgdGh1cyBpbmNyZWFzaW5nIHRoZSBjaGFuY2VzIHRoYXQgc29tZXRoaW5n IGdvZXMgd3JvbmcuPGJyPg0KPGJyPg0KNCkgT3B0aW9uIDIgZG9lcyBub3RoaW5nIGFnYWluc3Qg cGFja2V0IG51bWJlciBvc3NpZmljYXRpb24uIFRoZSBwYWNrZXQgbnVtYmVyIGVmZmVjdGl2ZWx5 IGJlY29tZXMgcGFydCBvZiB0aGUgaW52YXJpYW50cy48YnI+DQo8YnI+DQpJbiBzaG9ydCwgdGhl IG9ubHkgYWR2YW50YWdlIG9mIG9wdGlvbiAyIGlzIHRvIGF2b2lkIGEgc2luZ2xlIHN5bW1ldHJp YyBlbmNyeXB0aW9uIG9wZXJhdGlvbiBwZXIgcGFja2V0LCB3aGlsZSBtYWtpbmcgdGhlIGNvZGUg c2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXgsIGFuZCBhdCB0aGUgY29zdCBvZiBub3QgcHJvdGVj dGluZyBhZ2FpbnN0IFBOIG9zc2lmaWNhdGlvbi4gVGhlIHdheSBJIHNlZSB0aGF0LCB0aGVyZSBp cyBoYXJkbHkgYW55IGRlYmF0ZS48YnI+DQo8YnI+DQotLSBDaHJpc3RpYW4gSHVpdGVtYTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB013355B5E786890979B98FB2B6F20CY4PR21MB0133namp_-- From nobody Thu Feb 8 23:22:10 2018 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 E4788127873 for ; Thu, 8 Feb 2018 23:22:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.188 X-Spam-Level: X-Spam-Status: No, score=-2.188 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, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 REbJw4P8Vfhg for ; Thu, 8 Feb 2018 23:22:06 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 DE82D12741D for ; Thu, 8 Feb 2018 23:22:05 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id 196so9624835iti.5 for ; Thu, 08 Feb 2018 23:22:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=20JrfCQjcC+3kOf4JLQCW3mW5JKG/ql9ZjS/+0fdhjs=; b=Rk/eOBwBQephCNSQOZ94XwAzACcVkab/6JrIJ3l6hLT40aKzI2+Cd9hYwwTaflpUXb g/tt3hiYjIQZKLDG9gaSHeGUQzuRHYnTMMSbGV1LBbGo9yogMAv2fwav8EID7x8PA5jQ W/wD91Wax7pV1EIipicFVxwsvIJ20q2BTBcm/Gfuhr84YF9Nf91iWJB88v3owO0bzM98 6Tzyd2JNdV3YGKGoS0w21hi9H4M71N98pjl47rMMQci4KkIN+IoqHOAYDeVC2fI6fh5F vXqyt+iGbhZyBFvnjfHkz619gU0pTp9j8ifIXt/LzCK2gRmwR7rkikU/pndpDfkKPxSN rJrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=20JrfCQjcC+3kOf4JLQCW3mW5JKG/ql9ZjS/+0fdhjs=; b=kpvUb/PANzwY0owVbMlPJpCr82hYo4Hv1V9C0bCciE7DoSvP5GZPr0bsSi1o+9ENEh WOjoDEP5HSF283uX7r5pe92xrGvgW1ojddvTKs1IrtJQcHlhcTeUJKlIv6KQQX97v6wz N7vL75f+SOuxxUXPmDqI9XiLWeR0DXXJNwUjfU5ILNhumYMI8XnRkew7vCQGBngIQA3i z4tTghn00bPCSDKZubt4C8osKPxSkn3ItkSVNisvHCaGnKlzws8v6ckdg0+0yX0SkI2t auZYp+dd7ldoZvlhoEHjjoZohc0+IYfcHN84qEmiShoygc2cB4VcXgtZbL2rVnObbfuV oufw== X-Gm-Message-State: APf1xPBb/yWMBDJDLUxeHBGnp9aUehGb7i5+joajVQZMXEG+1lhMgIgy 9ffoD8NwEg1ioWNnfCCF/a+52WuPTKjDzVwjumg= X-Google-Smtp-Source: AH8x2251s+kH7PdRHCCZDZ6xbyL1In2LKUyDx+URmW9vVPTC4Cr4h0qhzKhilp9Nhy3IzQNK6BO59QZ3PRU+3geHZ3E= X-Received: by 10.36.46.23 with SMTP id i23mr2300489ita.55.1518160925240; Thu, 08 Feb 2018 23:22:05 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 02:22:04 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 02:22:04 -0500 Message-ID: Subject: RE: Packet number encryption To: Praveen Balasubramanian , Mike Bishop , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="001a114a9d82a932310564c2624a" 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, 09 Feb 2018 07:22:09 -0000 --001a114a9d82a932310564c2624a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable You can=E2=80=99t safely reuse the combination of nonce and key, IIUC. Sin= ce key rollover is infrequent, the nonce has to change every packet and be guaranteed unique over the lifetime of, if not the connection, at least the current key. For CTR mode encryption which AES-GCM is, it is extremely bad to reuse the nonce. But it is still permitted if nonce only repeats with very low probability, like 2^-32 or so, don=E2=80=99t recall. This means that using = a crypto hashed packet numbers as a nonce is an option, but a homegrown obfuscation is not. As to hashing the packet number instead of encrypting, there is hardly any worthwhile hash that is faster than using AES, but precomputing the AES over several blocks as Mike and I have suggested earlier, is an option unless you expect large losses where a small lookup table is insufficient on average. I share the concern on relying on the a peers weak PRNG for packet jumps etc. especially if it is not the same as the crypto PRNG because if that is broken, it doesn=E2=80=99t matter anyway. As the the 1% number - it is the only real life data we have, but I already argued that the overhead can much higher in low-latency operations with short packets. It has also been argued that packet number is lower than AEAD because it is shorter, but encrypting 64 bytes AEAD for a message is the same as encrypting 16 bytes packet number because of instruction level parallelism on current Intel hardware. You can see how the performance increases with data length in appendix A https://software.intel.com/sites/default/files/m/d/4/1/d/8/10TB24_Breakthro= ugh_AES_Performance_with_Intel_AES_New_Instructions.final.secure.pdf Mikkel On 9 February 2018 at 07.19.32, Mike Bishop (mbishop@evequefou.be) wrote: You can=E2=80=99t safely reuse the combination of nonce and key, IIUC. Sin= ce key rollover is infrequent, the nonce has to change every packet and be guaranteed unique over the lifetime of, if not the connection, at least the current key. Since packet numbers also don=E2=80=99t repeat over the lifet= ime of the connection, I think using one as the variable part of the other was just taking advantage of the alignment. I don=E2=80=99t think having a randomized starting value and incrementing i= s necessarily any better than exposing the packet number. Having a PRNG seed established during the handshake and making the visible thing the next random output seems potentially interesting, but I=E2=80=99d want our more crypto-minded friends to comment. I think the real issue would be guarantees about never-repeating from the PRNG, particularly as you don=E2= =80=99t have guarantees about your peer=E2=80=99s implementation. A defined key de= rivation and a counter can be verified in the protocol, independent of how good the peer=E2=80=99s PRNG is. *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen Balasubramanian *Sent:* Thursday, February 8, 2018 9:40 PM *To:* huitema ; quic@ietf.org *Subject:* RE: Packet number encryption Actually taking a step back what if we don=E2=80=99t we overloaded packet n= umber as the nonce? Can we: 1. Put packet number as a separate variable length field in the encrypted portion of the header. This allows for growth beyond 64 bits i= n future and completely avoids ossification. For short lived flows variabl= e length encoding leads to minimal space overhead. 2. Put a separate plaintext nonce which starts out as a secure random number and monotonically increases as short random jumps (every packet o= r every few packets) and could then rollover. This will prevent linkabilit= y and scales to multi-path as well. No major compute overhead. We can also make the nonce optional for crypto algorithms that do not need a nonce saving more space. Some MSB of the nonce could be used for signaling reorder to the network if needed. I don=E2=80=99t have the historical context for overloading of PN a= s the nonce so pardon me if un-overloading option was discussed and ruled out before. *From:* QUIC [mailto:quic-bounces@ietf.org ] *On Behalf Of *Praveen Balasubramanian *Sent:* Thursday, February 8, 2018 5:51 PM *To:* huitema ; quic@ietf.org *Subject:* RE: Packet number encryption >> and using separate packet sequences for each path This alone prevents linkability right? >> The packet number on each path will start at 1 (or maybe 0 ;-). Is supporting multiple paths at the same time a goal? If yes, then yes all paths will need to have separate tracking and ACK state and congestion control etc. I thought this is not part of V1 RFC. If its just one additional path for connection migration scenario then all you need is a (random) jump to a offset in packet number space for the new path so that the few packets in the old path can continue for a little bit. This works with just one ACK space so no implementation complexity. >> 2) Or, leaving the packet number in the clear but using different encryption contexts for each path, and using separate packet sequences for each path. In addition if the value in the clear was obfuscated with an XOR transform it will help prevent ossification. The obfuscation is not meant to guard against later analysis that reveals the packet numbers - why do we care about that. It is meant to grease the space and not make the numbers serial so middleboxes cannot assume ordering etc. All said if I am alone in being concerned about the perf hit then I=E2=80= =99d say go on with option 1. *From:* QUIC [mailto:quic-bounces@ietf.org ] *On Behalf Of *Christian Huitema *Sent:* Thursday, February 8, 2018 3:54 PM *To:* quic@ietf.org *Subject:* Re: Packet number encryption On 2/8/2018 1:13 PM, Mike Bishop wrote: #2 won=E2=80=99t work. The packet number is an input to the AEAD nonce, so= you have to get to the packet number before you can decrypt the payload. It can=E2=80=99t be based on anything internal to the encrypted packet. In Martin=E2=80=99s proposal, it=E2=80=99s using a combination of the encry= pted payload (which requires nothing to access) and some stored state on each endpoint, which requires only the Connection ID to look up. You want the thing you XOR by to be constantly changing, or it becomes easier to look at sequences of obfuscated packet numbers and start drawing inferences about what the XOR value is. If overhead is the primary concern, I think there are a couple approaches that might allow you to precompute values and amortize the cost of doing the encryption step. (At the cost of keeping the table of precomputed values, of course.) I still think Jana=E2=80=99s pushing in the right direction here: Let=E2= =80=99s agree on goals, and then see if we can craft a design that meets those goals. I hear you saying that low overhead is a goal, which I think we can all agree on. I also think I hear you saying that 1-1.5% overhead is too high, but it sounds like there=E2=80=99s less agreement on that. You also raise an interesting point that some clients will care less about linkability because they will never intentionally migrate. I think Victor said it best, "Obfuscation is just encryption done poorly." Either we encrypt, or we don't. But there is no such thing as an obfuscation middle-ground. Obfuscation would just be a speed bump, easily broken. It won't provide privacy, and it won't prevent linkability. As far as I am concerned, there are only two designs that prevent linkability: 1) Martin's PR, in which the packet number is encrypted using sensible crypto; 2) Or, leaving the packet number in the clear but using different encryption contexts for each path, and using separate packet sequences for each path. The second option requires more computation when explicitly setting up a new path. The connection ID would be used as part of the "salt" when deriving connection contexts. The packet number on each path will start at 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK to be per/path, or alternatively adding a PATH-ACK frame that indicates the path for which packets are acked. The pros and cons of the two options are easy to get: 1) Option 2 does not require the cost of encrypting every packet, thus per packet processing will be maybe 1% faster than option 1. 2) Option 2 requires computing encryption contexts for each path, which is more complex than option 1, but the cost will be amortized over the duration of the path. 3) Option 2 requires more complex data structures and ACK management, thus increasing the chances that something goes wrong. 4) Option 2 does nothing against packet number ossification. The packet number effectively becomes part of the invariants. In short, the only advantage of option 2 is to avoid a single symmetric encryption operation per packet, while making the code significantly more complex, and at the cost of not protecting against PN ossification. The way I see that, there is hardly any debate. -- Christian Huitema --001a114a9d82a932310564c2624a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

You can=E2=80=99t safely reuse the combination = of nonce and key, IIUC.=C2=A0 Since key rollover is infrequent, the nonce h= as to change every packet and be guaranteed unique over the lifetime of, if= not the connection, at least the current key.

For CTR mode encryption which AES-GCM is, it is extremely bad= to reuse the nonce. But it is still permitted if nonce only repeats with v= ery low probability, like 2^-32 or so, don=E2=80=99t recall. This means tha= t using a crypto hashed packet numbers as a nonce is an option, but a homeg= rown obfuscation is not.

As to hashing the packet number= instead of encrypting, there is hardly any worthwhile hash that is faster = than using AES, but precomputing the AES over several blocks as Mike and I = have suggested earlier, is an option unless you expect large losses where a= small lookup table is insufficient on average.

I sh= are the concern on relying on the a peers weak PRNG for packet jumps etc. e= specially =C2=A0if it is not the same as the crypto PRNG because if that is= broken, it doesn=E2=80=99t matter anyway.

As the = the 1% number - it is the only real life data we have, but I already argued= that the overhead can much higher in low-latency operations with short pac= kets. It has also been argued that packet number is lower than AEAD because= it is shorter, but encrypting 64 bytes AEAD for a message is the same as e= ncrypting 16 bytes packet number because of instruction level parallelism o= n current Intel hardware. You can see how the performance increases with da= ta length in appendix A


Mikkel

On 9 February 2018 at 07.19.32,= Mike Bishop (mbishop@evequefou.be<= /a>) wrote:

You can=E2=80=99t s= afely reuse the combination of nonce and key, IIUC.=C2=A0 Since key rollove= r is infrequent, the nonce has to change every packet and be guaranteed uni= que over the lifetime of, if not the connection, at least the current key.=C2=A0 Since packet numbers also don=E2=80=99t re= peat over the lifetime of the connection, I think using one as the variable= part of the other was just taking advantage of the alignment.

=C2=A0

I don=E2=80=99t thi= nk having a randomized starting value and incrementing is necessarily any b= etter than exposing the packet number.=C2=A0 Having a PRNG seed established= during the handshake and making the visible thing the next random output seems potentially interesting, but I=E2=80=99d want= our more crypto-minded friends to comment.=C2=A0 I think the real issue wo= uld be guarantees about never-repeating from the PRNG, particularly as you = don=E2=80=99t have guarantees about your peer=E2=80=99s implementation.=C2= =A0 A defined key derivation and a counter can be verified in the protocol, in= dependent of how good the peer=E2=80=99s PRNG is.

=C2=A0

From:= QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Thursday, February 8, 2018 9:40 PM
To: huitema <huitema@huite= ma.net>; quic@ietf.org
Subject: RE: Packet number encryption

=C2=A0

Actually taking a s= tep back what if we don=E2=80=99t we overloaded packet number as the nonce?=

=C2=A0

Can we:

  1. Put packet number as a s= eparate variable length field in the encrypted portion of the header. This = allows for growth beyond 64 bits in future and completely avoids ossificati= on. For short lived flows variable length encoding leads to minimal space overhead.
  2. Put a separate plaintex= t nonce which starts out as a secure random number and monotonically increa= ses as short random jumps (every packet or every few packets) and could the= n rollover. This will prevent linkability and scales to multi-path as well. No major comput= e overhead. We can also make the nonce optional for crypto algorithms that = do not need a nonce saving more space.

=C2=A0

Some MSB of the non= ce could be used for signaling reorder to the network if needed. I don=E2= =80=99t have the historical context for overloading of PN as the nonce so p= ardon me if un-overloading option was discussed and ruled out before.

=C2=A0

From:= QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Thursday, February 8, 2018 5:51 PM
To: huitema <huitema@huite= ma.net>; quic@ietf.org
Subject: RE: Packet number encryption

=C2=A0

>> and using separate packet sequences for eac= h path

This alone prevents linkability right?

=C2=A0

>> The packet number on each path will start a= t 1 (or maybe 0 ;-).

Is supporting multiple paths at the same time a goal= ? If yes, then yes all paths will need to have separate tracking and ACK st= ate and congestion control etc. I thought this is not part of V1 RFC. If it= s just one additional path for connection migration scenario then all you need is a (random) jump to a offset in pac= ket number space for the new path so that the few packets in the old path c= an continue for a little bit. This works with just one ACK space so no impl= ementation complexity.

=C2=A0

>> 2) Or, leaving the packet number in the cle= ar but using different encryption contexts for each path, and using separat= e packet sequences for each path.
In addition if the value in the clear was obfuscated with an XOR transform = it will help prevent ossification. The obfuscation is not meant to guard ag= ainst later analysis that reveals the packet numbers - why do we care about= that. It is meant to grease the space and not make the numbers serial so middleboxes cannot assume orderin= g etc.

=C2=A0

All said if I am alone in being concerned about the = perf hit then I=E2=80=99d say go on with option 1.

=C2=A0

From:= QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Thursday, February 8, 2018 3:54 PM
To: quic@ietf.org
Subject: Re: Packet number encryption

=C2=A0

On 2/8/2018 1:13 PM, Mike Bishop wrote:

#2 won=E2=80=99t work.=C2=A0 The packet number is an= input to the AEAD nonce, so you have to get to the packet number before yo= u can decrypt the payload.=C2=A0 It can=E2=80=99t be based on anything inte= rnal to the encrypted packet.

=C2=A0

In Martin=E2=80=99s proposal, it=E2=80=99s using a c= ombination of the encrypted payload (which requires nothing to access) and = some stored state on each endpoint, which requires only the Connection ID t= o look up.=C2=A0 You want the thing you XOR by to be constantly changing, or it becomes easier to look at sequences of obfuscated packet n= umbers and start drawing inferences about what the XOR value is.=C2=A0 If o= verhead is the primary concern, I think there are a couple approaches that = might allow you to precompute values and amortize the cost of doing the encryption step.=C2=A0 (At the cost of = keeping the table of precomputed values, of course.)

=C2=A0

I still think Jana=E2=80=99s pushing in the right di= rection here:=C2=A0 Let=E2=80=99s agree on goals, and then see if we can cr= aft a design that meets those goals.=C2=A0 I hear you saying that low overh= ead is a goal, which I think we can all agree on.=C2=A0 I also think I hear you saying that 1-1.5% overhead is too high, but it sounds like the= re=E2=80=99s less agreement on that.=C2=A0 You also raise an interesting po= int that some clients will care less about linkability because they will ne= ver intentionally migrate.


I think Victor said it best, "Obfuscation is just encryption done poor= ly." Either we encrypt, or we don't. But there is no such thing as= an obfuscation middle-ground. Obfuscation would just be a speed bump, easi= ly broken. It won't provide privacy, and it won't prevent linkability.

As far as I am concerned, there are only two designs that prevent linkabili= ty:

1) Martin's PR, in which the packet number is encrypted using sensible = crypto;

2) Or, leaving the packet number in the clear but using different encryptio= n contexts for each path, and using separate packet sequences for each path= .

The second option requires more computation when explicitly setting up a ne= w path. The connection ID would be used as part of the "salt" whe= n deriving connection contexts. The packet number on each path will start a= t 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK= to be per/path, or alternatively adding a PATH-ACK frame that indicates th= e path for which packets are acked.

The pros and cons of the two options are easy to get:

1) Option 2 does not require the cost of encrypting every packet, thus per = packet processing will be maybe 1% faster than option 1.

2) Option 2 requires computing encryption contexts for each path, which is = more complex than option 1, but the cost will be amortized over the duratio= n of the path.

3) Option 2 requires more complex data structures and ACK management, thus = increasing the chances that something goes wrong.

4) Option 2 does nothing against packet number ossification. The packet num= ber effectively becomes part of the invariants.

In short, the only advantage of option 2 is to avoid a single symmetric enc= ryption operation per packet, while making the code significantly more comp= lex, and at the cost of not protecting against PN ossification. The way I s= ee that, there is hardly any debate.

-- Christian Huitema

--001a114a9d82a932310564c2624a-- From nobody Thu Feb 8 23:26:08 2018 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 A7A1712741D for ; Thu, 8 Feb 2018 23:26:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.469 X-Spam-Level: X-Spam-Status: No, score=0.469 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no 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 gSaqCnFrMvDM for ; Thu, 8 Feb 2018 23:26:02 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0135.outbound.protection.outlook.com [104.47.34.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DB98124234 for ; Thu, 8 Feb 2018 23:26:02 -0800 (PST) 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=CUDyPD/Mcq8L2A2/8hS6186mNTStd0cHhpWIYRiaLTA=; b=AKCxw8MZTbZ+Udg7hrXg1xakqGb5vYikL2PxbDoNZzcaDaRVxjeDE02WGMXBkIiyDShwJimRfrcxbq1Qn77v0E7fN5Fu0OY0vSBXxEntX3pl68wH5gDwchkaVA9YgU2gL7C5d82Jgekha4FWkYIkLUvqu3WTMFHXVfBj3mTfLb4= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0632.namprd21.prod.outlook.com (10.175.115.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Fri, 9 Feb 2018 07:25:42 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 07:25:42 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Mike Bishop , "quic@ietf.org" , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwIAADioAgAARigCAAABaEA== Date: Fri, 9 Feb 2018 07:25:42 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0632; 7:0+PqKv/U0yuFsWsINO6YAAH3CsieytwMeoIYdu1CmUp/Ejw7DrkaxPEd/0WQDrVf428PiYVOkaiaU/p3KsCArRFrh1aJtPRwSa4edzLH2XNZ0E9nEJXQBVT4RBOMq5qGlaNh9mGy8eFEIOpIBw0Hg3539jkrmfY76h6AewaAbhqBxV6sJ4JaYnYqfn4uvLd3uGw06YaEx992Q4Ty3VThEUYQH2TutKRfQnseEeXLuGIMbXPSK0stZe84BElBPDD/ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d3f9b41d-a9b0-448f-b1dd-08d56f8e53c6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0632; x-ms-traffictypediagnostic: CY4PR21MB0632: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(108984395545644)(89211679590171)(189930954265078)(85827821059158)(219752817060721)(21748063052155)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0632; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0632; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39380400002)(396003)(346002)(39860400002)(377424004)(189003)(199004)(316002)(102836004)(6506007)(59450400001)(7696005)(22452003)(7736002)(76176011)(966005)(5250100002)(110136005)(97736004)(8676002)(2501003)(106356001)(74316002)(93886005)(6116002)(790700001)(561944003)(6346003)(8936002)(3480700004)(606006)(81156014)(81166006)(33656002)(478600001)(9686003)(236005)(3280700002)(99286004)(6306002)(54896002)(3660700001)(19609705001)(68736007)(2906002)(10090500001)(10290500003)(39060400002)(14454004)(8990500004)(2950100002)(7116003)(229853002)(55016002)(5660300001)(186003)(25786009)(53546011)(86362001)(53936002)(6246003)(6436002)(105586002)(2900100001)(86612001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0632; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: IjQN8Lv0rwjlPcMdXH13D+3xXSO8vwzCHCjQRVfZ/3rG3iDBRjYaqDteqjbVBZSGtCIjJTi61EsAQYva2nZ3+w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133F887774049426C51145DB6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: d3f9b41d-a9b0-448f-b1dd-08d56f8e53c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 07:25:42.2956 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0632 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, 09 Feb 2018 07:26:06 -0000 --_000_CY4PR21MB0133F887774049426C51145DB6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHByb3Bvc2FsIGlzIHRvIGtlZXAgdGhlIFBOIGluIGVuY3J5cHRlZCBwb3J0aW9uIG9mIGhl YWRlciBhbmQgdXNlIGEgZGVkaWNhdGVkIG5vbmNlIGluIHBsYWluIHRleHQuIElmIG5vbi1yZXBl YXRpbmcgbm9uY2UgaXMgbmVlZGVkIHdpdGggdGhhdCBwcm9iYWJpbGl0eSB0aGVuIHdlIHdpbGwg bmVlZCBtdWNoIGxhcmdlciBub25jZSBzaW5jZSAxMCBHYnBzKyByYXRlcyBhcmUgY29tbW9uIGlu IHRoZSBkYXRhY2VudGVyLiBBIG5vbmNlIGNhbiBzaW1wbHkgYmUgZ2VuZXJhdGVkIHVzaW5nIFBS TkcuIFdoeSBkb2VzIHRoZSBwZWVy4oCZcyBQUk5HIG1hdHRlcj8gVGhlIHBlZXIgdXNlcyBhIGRp ZmZlcmVudCBQTiBzcGFjZS4gVGhlIGp1bXBzIGFyZSBjb21wbGV0ZWx5IGRldGVybWluZWQgYnkg dGhlIHNlbmRlciBhcyBuZWVkZWQgYW5kIGl0cyBqdXN0IHRvIHByZXZlbnQgb3NzaWZpY2F0aW9u IG9mIGFzc3VtaW5nIHRoYXQgbm9uY2UgYWx3YXlzIGluY3JlbWVudHMgYnkgMS4NCg0KRnJvbTog TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbV0NClNl bnQ6IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDExOjIyIFBNDQpUbzogUHJhdmVlbiBCYWxh c3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBNaWtlIEJpc2hvcCA8bWJpc2hvcEBl dmVxdWVmb3UuYmU+OyBxdWljQGlldGYub3JnOyBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0 Pg0KU3ViamVjdDogUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpZb3UgY2Fu4oCZdCBz YWZlbHkgcmV1c2UgdGhlIGNvbWJpbmF0aW9uIG9mIG5vbmNlIGFuZCBrZXksIElJVUMuICBTaW5j ZSBrZXkgcm9sbG92ZXIgaXMgaW5mcmVxdWVudCwgdGhlIG5vbmNlIGhhcyB0byBjaGFuZ2UgZXZl cnkgcGFja2V0IGFuZCBiZSBndWFyYW50ZWVkIHVuaXF1ZSBvdmVyIHRoZSBsaWZldGltZSBvZiwg aWYgbm90IHRoZSBjb25uZWN0aW9uLCBhdCBsZWFzdCB0aGUgY3VycmVudCBrZXkuDQpGb3IgQ1RS IG1vZGUgZW5jcnlwdGlvbiB3aGljaCBBRVMtR0NNIGlzLCBpdCBpcyBleHRyZW1lbHkgYmFkIHRv IHJldXNlIHRoZSBub25jZS4gQnV0IGl0IGlzIHN0aWxsIHBlcm1pdHRlZCBpZiBub25jZSBvbmx5 IHJlcGVhdHMgd2l0aCB2ZXJ5IGxvdyBwcm9iYWJpbGl0eSwgbGlrZSAyXi0zMiBvciBzbywgZG9u 4oCZdCByZWNhbGwuIFRoaXMgbWVhbnMgdGhhdCB1c2luZyBhIGNyeXB0byBoYXNoZWQgcGFja2V0 IG51bWJlcnMgYXMgYSBub25jZSBpcyBhbiBvcHRpb24sIGJ1dCBhIGhvbWVncm93biBvYmZ1c2Nh dGlvbiBpcyBub3QuDQoNCkFzIHRvIGhhc2hpbmcgdGhlIHBhY2tldCBudW1iZXIgaW5zdGVhZCBv ZiBlbmNyeXB0aW5nLCB0aGVyZSBpcyBoYXJkbHkgYW55IHdvcnRod2hpbGUgaGFzaCB0aGF0IGlz IGZhc3RlciB0aGFuIHVzaW5nIEFFUywgYnV0IHByZWNvbXB1dGluZyB0aGUgQUVTIG92ZXIgc2V2 ZXJhbCBibG9ja3MgYXMgTWlrZSBhbmQgSSBoYXZlIHN1Z2dlc3RlZCBlYXJsaWVyLCBpcyBhbiBv cHRpb24gdW5sZXNzIHlvdSBleHBlY3QgbGFyZ2UgbG9zc2VzIHdoZXJlIGEgc21hbGwgbG9va3Vw IHRhYmxlIGlzIGluc3VmZmljaWVudCBvbiBhdmVyYWdlLg0KDQpJIHNoYXJlIHRoZSBjb25jZXJu IG9uIHJlbHlpbmcgb24gdGhlIGEgcGVlcnMgd2VhayBQUk5HIGZvciBwYWNrZXQganVtcHMgZXRj LiBlc3BlY2lhbGx5ICBpZiBpdCBpcyBub3QgdGhlIHNhbWUgYXMgdGhlIGNyeXB0byBQUk5HIGJl Y2F1c2UgaWYgdGhhdCBpcyBicm9rZW4sIGl0IGRvZXNu4oCZdCBtYXR0ZXIgYW55d2F5Lg0KDQpB cyB0aGUgdGhlIDElIG51bWJlciAtIGl0IGlzIHRoZSBvbmx5IHJlYWwgbGlmZSBkYXRhIHdlIGhh dmUsIGJ1dCBJIGFscmVhZHkgYXJndWVkIHRoYXQgdGhlIG92ZXJoZWFkIGNhbiBtdWNoIGhpZ2hl ciBpbiBsb3ctbGF0ZW5jeSBvcGVyYXRpb25zIHdpdGggc2hvcnQgcGFja2V0cy4gSXQgaGFzIGFs c28gYmVlbiBhcmd1ZWQgdGhhdCBwYWNrZXQgbnVtYmVyIGlzIGxvd2VyIHRoYW4gQUVBRCBiZWNh dXNlIGl0IGlzIHNob3J0ZXIsIGJ1dCBlbmNyeXB0aW5nIDY0IGJ5dGVzIEFFQUQgZm9yIGEgbWVz c2FnZSBpcyB0aGUgc2FtZSBhcyBlbmNyeXB0aW5nIDE2IGJ5dGVzIHBhY2tldCBudW1iZXIgYmVj YXVzZSBvZiBpbnN0cnVjdGlvbiBsZXZlbCBwYXJhbGxlbGlzbSBvbiBjdXJyZW50IEludGVsIGhh cmR3YXJlLiBZb3UgY2FuIHNlZSBob3cgdGhlIHBlcmZvcm1hbmNlIGluY3JlYXNlcyB3aXRoIGRh dGEgbGVuZ3RoIGluIGFwcGVuZGl4IEENCg0KaHR0cHM6Ly9zb2Z0d2FyZS5pbnRlbC5jb20vc2l0 ZXMvZGVmYXVsdC9maWxlcy9tL2QvNC8xL2QvOC8xMFRCMjRfQnJlYWt0aHJvdWdoX0FFU19QZXJm b3JtYW5jZV93aXRoX0ludGVsX0FFU19OZXdfSW5zdHJ1Y3Rpb25zLmZpbmFsLnNlY3VyZS5wZGY8 aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZzb2Z0d2FyZS5pbnRlbC5jb20lMkZzaXRlcyUyRmRlZmF1bHQlMkZmaWxlcyUyRm0l MkZkJTJGNCUyRjElMkZkJTJGOCUyRjEwVEIyNF9CcmVha3Rocm91Z2hfQUVTX1BlcmZvcm1hbmNl X3dpdGhfSW50ZWxfQUVTX05ld19JbnN0cnVjdGlvbnMuZmluYWwuc2VjdXJlLnBkZiZkYXRhPTA0 JTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0MyMGU2MTVhYTgwZGU0MzM1NGFlMTA4ZDU2 ZjhkZDJjOSU3Q2VlMzMwM2Q3ZmI3MzRiMGM4NTg5YmNkODQ3ZjFjMjc3JTdDMSU3QzElN0M2MzY1 Mzc1NzcyODIzMzE0MTklN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01E QWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aWZRJTNEJTNEJTdDLTEmc2RhdGE9MlNo JTJCelA2V0M3ZkJHckt3VUhVaDRDRUpUZTJoV2szYlI4WkFOJTJCUWNEMWMlM0QmcmVzZXJ2ZWQ9 MD4NCg0KTWlra2VsDQoNCk9uIDkgRmVicnVhcnkgMjAxOCBhdCAwNy4xOS4zMiwgTWlrZSBCaXNo b3AgKG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4pIHdy b3RlOg0KWW91IGNhbuKAmXQgc2FmZWx5IHJldXNlIHRoZSBjb21iaW5hdGlvbiBvZiBub25jZSBh bmQga2V5LCBJSVVDLiAgU2luY2Uga2V5IHJvbGxvdmVyIGlzIGluZnJlcXVlbnQsIHRoZSBub25j ZSBoYXMgdG8gY2hhbmdlIGV2ZXJ5IHBhY2tldCBhbmQgYmUgZ3VhcmFudGVlZCB1bmlxdWUgb3Zl ciB0aGUgbGlmZXRpbWUgb2YsIGlmIG5vdCB0aGUgY29ubmVjdGlvbiwgYXQgbGVhc3QgdGhlIGN1 cnJlbnQga2V5LiAgU2luY2UgcGFja2V0IG51bWJlcnMgYWxzbyBkb27igJl0IHJlcGVhdCBvdmVy IHRoZSBsaWZldGltZSBvZiB0aGUgY29ubmVjdGlvbiwgSSB0aGluayB1c2luZyBvbmUgYXMgdGhl IHZhcmlhYmxlIHBhcnQgb2YgdGhlIG90aGVyIHdhcyBqdXN0IHRha2luZyBhZHZhbnRhZ2Ugb2Yg dGhlIGFsaWdubWVudC4NCg0KSSBkb27igJl0IHRoaW5rIGhhdmluZyBhIHJhbmRvbWl6ZWQgc3Rh cnRpbmcgdmFsdWUgYW5kIGluY3JlbWVudGluZyBpcyBuZWNlc3NhcmlseSBhbnkgYmV0dGVyIHRo YW4gZXhwb3NpbmcgdGhlIHBhY2tldCBudW1iZXIuICBIYXZpbmcgYSBQUk5HIHNlZWQgZXN0YWJs aXNoZWQgZHVyaW5nIHRoZSBoYW5kc2hha2UgYW5kIG1ha2luZyB0aGUgdmlzaWJsZSB0aGluZyB0 aGUgbmV4dCByYW5kb20gb3V0cHV0IHNlZW1zIHBvdGVudGlhbGx5IGludGVyZXN0aW5nLCBidXQg SeKAmWQgd2FudCBvdXIgbW9yZSBjcnlwdG8tbWluZGVkIGZyaWVuZHMgdG8gY29tbWVudC4gIEkg dGhpbmsgdGhlIHJlYWwgaXNzdWUgd291bGQgYmUgZ3VhcmFudGVlcyBhYm91dCBuZXZlci1yZXBl YXRpbmcgZnJvbSB0aGUgUFJORywgcGFydGljdWxhcmx5IGFzIHlvdSBkb27igJl0IGhhdmUgZ3Vh cmFudGVlcyBhYm91dCB5b3VyIHBlZXLigJlzIGltcGxlbWVudGF0aW9uLiAgQSBkZWZpbmVkIGtl eSBkZXJpdmF0aW9uIGFuZCBhIGNvdW50ZXIgY2FuIGJlIHZlcmlmaWVkIGluIHRoZSBwcm90b2Nv bCwgaW5kZXBlbmRlbnQgb2YgaG93IGdvb2QgdGhlIHBlZXLigJlzIFBSTkcgaXMuDQoNCkZyb206 IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0Bp ZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2VudDogVGh1 cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggOTo0MCBQTQ0KVG86IGh1aXRlbWEgPGh1aXRlbWFAaHVp dGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+PjsgcXVpY0BpZXRmLm9yZzxtYWls dG86cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24N Cg0KQWN0dWFsbHkgdGFraW5nIGEgc3RlcCBiYWNrIHdoYXQgaWYgd2UgZG9u4oCZdCB3ZSBvdmVy bG9hZGVkIHBhY2tldCBudW1iZXIgYXMgdGhlIG5vbmNlPw0KDQpDYW4gd2U6DQoNCiAgMS4gIFB1 dCBwYWNrZXQgbnVtYmVyIGFzIGEgc2VwYXJhdGUgdmFyaWFibGUgbGVuZ3RoIGZpZWxkIGluIHRo ZSBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0aGUgaGVhZGVyLiBUaGlzIGFsbG93cyBmb3IgZ3Jvd3Ro IGJleW9uZCA2NCBiaXRzIGluIGZ1dHVyZSBhbmQgY29tcGxldGVseSBhdm9pZHMgb3NzaWZpY2F0 aW9uLiBGb3Igc2hvcnQgbGl2ZWQgZmxvd3MgdmFyaWFibGUgbGVuZ3RoIGVuY29kaW5nIGxlYWRz IHRvIG1pbmltYWwgc3BhY2Ugb3ZlcmhlYWQuDQogIDIuICBQdXQgYSBzZXBhcmF0ZSBwbGFpbnRl eHQgbm9uY2Ugd2hpY2ggc3RhcnRzIG91dCBhcyBhIHNlY3VyZSByYW5kb20gbnVtYmVyIGFuZCBt b25vdG9uaWNhbGx5IGluY3JlYXNlcyBhcyBzaG9ydCByYW5kb20ganVtcHMgKGV2ZXJ5IHBhY2tl dCBvciBldmVyeSBmZXcgcGFja2V0cykgYW5kIGNvdWxkIHRoZW4gcm9sbG92ZXIuIFRoaXMgd2ls bCBwcmV2ZW50IGxpbmthYmlsaXR5IGFuZCBzY2FsZXMgdG8gbXVsdGktcGF0aCBhcyB3ZWxsLiBO byBtYWpvciBjb21wdXRlIG92ZXJoZWFkLiBXZSBjYW4gYWxzbyBtYWtlIHRoZSBub25jZSBvcHRp b25hbCBmb3IgY3J5cHRvIGFsZ29yaXRobXMgdGhhdCBkbyBub3QgbmVlZCBhIG5vbmNlIHNhdmlu ZyBtb3JlIHNwYWNlLg0KDQpTb21lIE1TQiBvZiB0aGUgbm9uY2UgY291bGQgYmUgdXNlZCBmb3Ig c2lnbmFsaW5nIHJlb3JkZXIgdG8gdGhlIG5ldHdvcmsgaWYgbmVlZGVkLiBJIGRvbuKAmXQgaGF2 ZSB0aGUgaGlzdG9yaWNhbCBjb250ZXh0IGZvciBvdmVybG9hZGluZyBvZiBQTiBhcyB0aGUgbm9u Y2Ugc28gcGFyZG9uIG1lIGlmIHVuLW92ZXJsb2FkaW5nIG9wdGlvbiB3YXMgZGlzY3Vzc2VkIGFu ZCBydWxlZCBvdXQgYmVmb3JlLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4NClNlbnQ6IFRodXJz ZGF5LCBGZWJydWFyeSA4LCAyMDE4IDU6NTEgUE0NClRvOiBodWl0ZW1hIDxodWl0ZW1hQGh1aXRl bWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj47IHF1aWNAaWV0Zi5vcmc8bWFpbHRv OnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoN Cj4+IGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBlYWNoIHBhdGgNClRo aXMgYWxvbmUgcHJldmVudHMgbGlua2FiaWxpdHkgcmlnaHQ/DQoNCj4+IFRoZSBwYWNrZXQgbnVt YmVyIG9uIGVhY2ggcGF0aCB3aWxsIHN0YXJ0IGF0IDEgKG9yIG1heWJlIDAgOy0pLg0KSXMgc3Vw cG9ydGluZyBtdWx0aXBsZSBwYXRocyBhdCB0aGUgc2FtZSB0aW1lIGEgZ29hbD8gSWYgeWVzLCB0 aGVuIHllcyBhbGwgcGF0aHMgd2lsbCBuZWVkIHRvIGhhdmUgc2VwYXJhdGUgdHJhY2tpbmcgYW5k IEFDSyBzdGF0ZSBhbmQgY29uZ2VzdGlvbiBjb250cm9sIGV0Yy4gSSB0aG91Z2h0IHRoaXMgaXMg bm90IHBhcnQgb2YgVjEgUkZDLiBJZiBpdHMganVzdCBvbmUgYWRkaXRpb25hbCBwYXRoIGZvciBj b25uZWN0aW9uIG1pZ3JhdGlvbiBzY2VuYXJpbyB0aGVuIGFsbCB5b3UgbmVlZCBpcyBhIChyYW5k b20pIGp1bXAgdG8gYSBvZmZzZXQgaW4gcGFja2V0IG51bWJlciBzcGFjZSBmb3IgdGhlIG5ldyBw YXRoIHNvIHRoYXQgdGhlIGZldyBwYWNrZXRzIGluIHRoZSBvbGQgcGF0aCBjYW4gY29udGludWUg Zm9yIGEgbGl0dGxlIGJpdC4gVGhpcyB3b3JrcyB3aXRoIGp1c3Qgb25lIEFDSyBzcGFjZSBzbyBu byBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5Lg0KDQo+PiAyKSBPciwgbGVhdmluZyB0aGUgcGFj a2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5nIGRpZmZlcmVudCBlbmNyeXB0aW9uIGNv bnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2Vz IGZvciBlYWNoIHBhdGguDQpJbiBhZGRpdGlvbiBpZiB0aGUgdmFsdWUgaW4gdGhlIGNsZWFyIHdh cyBvYmZ1c2NhdGVkIHdpdGggYW4gWE9SIHRyYW5zZm9ybSBpdCB3aWxsIGhlbHAgcHJldmVudCBv c3NpZmljYXRpb24uIFRoZSBvYmZ1c2NhdGlvbiBpcyBub3QgbWVhbnQgdG8gZ3VhcmQgYWdhaW5z dCBsYXRlciBhbmFseXNpcyB0aGF0IHJldmVhbHMgdGhlIHBhY2tldCBudW1iZXJzIC0gd2h5IGRv IHdlIGNhcmUgYWJvdXQgdGhhdC4gSXQgaXMgbWVhbnQgdG8gZ3JlYXNlIHRoZSBzcGFjZSBhbmQg bm90IG1ha2UgdGhlIG51bWJlcnMgc2VyaWFsIHNvIG1pZGRsZWJveGVzIGNhbm5vdCBhc3N1bWUg b3JkZXJpbmcgZXRjLg0KDQpBbGwgc2FpZCBpZiBJIGFtIGFsb25lIGluIGJlaW5nIGNvbmNlcm5l ZCBhYm91dCB0aGUgcGVyZiBoaXQgdGhlbiBJ4oCZZCBzYXkgZ28gb24gd2l0aCBvcHRpb24gMS4N Cg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IENocmlzdGlhbiBIdWl0ZW1hDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCAzOjU0 IFBNDQpUbzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KDQpPbiAyLzgvMjAxOCAxOjEzIFBNLCBNaWtl IEJpc2hvcCB3cm90ZToNCiMyIHdvbuKAmXQgd29yay4gIFRoZSBwYWNrZXQgbnVtYmVyIGlzIGFu IGlucHV0IHRvIHRoZSBBRUFEIG5vbmNlLCBzbyB5b3UgaGF2ZSB0byBnZXQgdG8gdGhlIHBhY2tl dCBudW1iZXIgYmVmb3JlIHlvdSBjYW4gZGVjcnlwdCB0aGUgcGF5bG9hZC4gIEl0IGNhbuKAmXQg YmUgYmFzZWQgb24gYW55dGhpbmcgaW50ZXJuYWwgdG8gdGhlIGVuY3J5cHRlZCBwYWNrZXQuDQoN CkluIE1hcnRpbuKAmXMgcHJvcG9zYWwsIGl04oCZcyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mIHRo ZSBlbmNyeXB0ZWQgcGF5bG9hZCAod2hpY2ggcmVxdWlyZXMgbm90aGluZyB0byBhY2Nlc3MpIGFu ZCBzb21lIHN0b3JlZCBzdGF0ZSBvbiBlYWNoIGVuZHBvaW50LCB3aGljaCByZXF1aXJlcyBvbmx5 IHRoZSBDb25uZWN0aW9uIElEIHRvIGxvb2sgdXAuICBZb3Ugd2FudCB0aGUgdGhpbmcgeW91IFhP UiBieSB0byBiZSBjb25zdGFudGx5IGNoYW5naW5nLCBvciBpdCBiZWNvbWVzIGVhc2llciB0byBs b29rIGF0IHNlcXVlbmNlcyBvZiBvYmZ1c2NhdGVkIHBhY2tldCBudW1iZXJzIGFuZCBzdGFydCBk cmF3aW5nIGluZmVyZW5jZXMgYWJvdXQgd2hhdCB0aGUgWE9SIHZhbHVlIGlzLiAgSWYgb3Zlcmhl YWQgaXMgdGhlIHByaW1hcnkgY29uY2VybiwgSSB0aGluayB0aGVyZSBhcmUgYSBjb3VwbGUgYXBw cm9hY2hlcyB0aGF0IG1pZ2h0IGFsbG93IHlvdSB0byBwcmVjb21wdXRlIHZhbHVlcyBhbmQgYW1v cnRpemUgdGhlIGNvc3Qgb2YgZG9pbmcgdGhlIGVuY3J5cHRpb24gc3RlcC4gIChBdCB0aGUgY29z dCBvZiBrZWVwaW5nIHRoZSB0YWJsZSBvZiBwcmVjb21wdXRlZCB2YWx1ZXMsIG9mIGNvdXJzZS4p DQoNCkkgc3RpbGwgdGhpbmsgSmFuYeKAmXMgcHVzaGluZyBpbiB0aGUgcmlnaHQgZGlyZWN0aW9u IGhlcmU6ICBMZXTigJlzIGFncmVlIG9uIGdvYWxzLCBhbmQgdGhlbiBzZWUgaWYgd2UgY2FuIGNy YWZ0IGEgZGVzaWduIHRoYXQgbWVldHMgdGhvc2UgZ29hbHMuICBJIGhlYXIgeW91IHNheWluZyB0 aGF0IGxvdyBvdmVyaGVhZCBpcyBhIGdvYWwsIHdoaWNoIEkgdGhpbmsgd2UgY2FuIGFsbCBhZ3Jl ZSBvbi4gIEkgYWxzbyB0aGluayBJIGhlYXIgeW91IHNheWluZyB0aGF0IDEtMS41JSBvdmVyaGVh ZCBpcyB0b28gaGlnaCwgYnV0IGl0IHNvdW5kcyBsaWtlIHRoZXJl4oCZcyBsZXNzIGFncmVlbWVu dCBvbiB0aGF0LiAgWW91IGFsc28gcmFpc2UgYW4gaW50ZXJlc3RpbmcgcG9pbnQgdGhhdCBzb21l IGNsaWVudHMgd2lsbCBjYXJlIGxlc3MgYWJvdXQgbGlua2FiaWxpdHkgYmVjYXVzZSB0aGV5IHdp bGwgbmV2ZXIgaW50ZW50aW9uYWxseSBtaWdyYXRlLg0KDQpJIHRoaW5rIFZpY3RvciBzYWlkIGl0 IGJlc3QsICJPYmZ1c2NhdGlvbiBpcyBqdXN0IGVuY3J5cHRpb24gZG9uZSBwb29ybHkuIiBFaXRo ZXIgd2UgZW5jcnlwdCwgb3Igd2UgZG9uJ3QuIEJ1dCB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFz IGFuIG9iZnVzY2F0aW9uIG1pZGRsZS1ncm91bmQuIE9iZnVzY2F0aW9uIHdvdWxkIGp1c3QgYmUg YSBzcGVlZCBidW1wLCBlYXNpbHkgYnJva2VuLiBJdCB3b24ndCBwcm92aWRlIHByaXZhY3ksIGFu ZCBpdCB3b24ndCBwcmV2ZW50IGxpbmthYmlsaXR5Lg0KDQpBcyBmYXIgYXMgSSBhbSBjb25jZXJu ZWQsIHRoZXJlIGFyZSBvbmx5IHR3byBkZXNpZ25zIHRoYXQgcHJldmVudCBsaW5rYWJpbGl0eToN Cg0KMSkgTWFydGluJ3MgUFIsIGluIHdoaWNoIHRoZSBwYWNrZXQgbnVtYmVyIGlzIGVuY3J5cHRl ZCB1c2luZyBzZW5zaWJsZSBjcnlwdG87DQoNCjIpIE9yLCBsZWF2aW5nIHRoZSBwYWNrZXQgbnVt YmVyIGluIHRoZSBjbGVhciBidXQgdXNpbmcgZGlmZmVyZW50IGVuY3J5cHRpb24gY29udGV4dHMg Zm9yIGVhY2ggcGF0aCwgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBzZXF1ZW5jZXMgZm9yIGVh Y2ggcGF0aC4NCg0KVGhlIHNlY29uZCBvcHRpb24gcmVxdWlyZXMgbW9yZSBjb21wdXRhdGlvbiB3 aGVuIGV4cGxpY2l0bHkgc2V0dGluZyB1cCBhIG5ldyBwYXRoLiBUaGUgY29ubmVjdGlvbiBJRCB3 b3VsZCBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlICJzYWx0IiB3aGVuIGRlcml2aW5nIGNvbm5lY3Rp b24gY29udGV4dHMuIFRoZSBwYWNrZXQgbnVtYmVyIG9uIGVhY2ggcGF0aCB3aWxsIHN0YXJ0IGF0 IDEgKG9yIG1heWJlIDAgOy0pLiBUaGlzIHJlcXVpcmVzIG1haW50YWluaW5nIHNlcGFyYXRlIFNB Q0sgZGFzaGJvYXJkcyBmb3IgZWFjaCBwYXRoL0Nvbm5lY3Rpb24tSUQsIGFuZCBjb25zdHJhaW5p bmcgQUNLIHRvIGJlIHBlci9wYXRoLCBvciBhbHRlcm5hdGl2ZWx5IGFkZGluZyBhIFBBVEgtQUNL IGZyYW1lIHRoYXQgaW5kaWNhdGVzIHRoZSBwYXRoIGZvciB3aGljaCBwYWNrZXRzIGFyZSBhY2tl ZC4NCg0KVGhlIHByb3MgYW5kIGNvbnMgb2YgdGhlIHR3byBvcHRpb25zIGFyZSBlYXN5IHRvIGdl dDoNCg0KMSkgT3B0aW9uIDIgZG9lcyBub3QgcmVxdWlyZSB0aGUgY29zdCBvZiBlbmNyeXB0aW5n IGV2ZXJ5IHBhY2tldCwgdGh1cyBwZXIgcGFja2V0IHByb2Nlc3Npbmcgd2lsbCBiZSBtYXliZSAx JSBmYXN0ZXIgdGhhbiBvcHRpb24gMS4NCg0KMikgT3B0aW9uIDIgcmVxdWlyZXMgY29tcHV0aW5n IGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgd2hpY2ggaXMgbW9yZSBjb21wbGV4 IHRoYW4gb3B0aW9uIDEsIGJ1dCB0aGUgY29zdCB3aWxsIGJlIGFtb3J0aXplZCBvdmVyIHRoZSBk dXJhdGlvbiBvZiB0aGUgcGF0aC4NCg0KMykgT3B0aW9uIDIgcmVxdWlyZXMgbW9yZSBjb21wbGV4 IGRhdGEgc3RydWN0dXJlcyBhbmQgQUNLIG1hbmFnZW1lbnQsIHRodXMgaW5jcmVhc2luZyB0aGUg Y2hhbmNlcyB0aGF0IHNvbWV0aGluZyBnb2VzIHdyb25nLg0KDQo0KSBPcHRpb24gMiBkb2VzIG5v dGhpbmcgYWdhaW5zdCBwYWNrZXQgbnVtYmVyIG9zc2lmaWNhdGlvbi4gVGhlIHBhY2tldCBudW1i ZXIgZWZmZWN0aXZlbHkgYmVjb21lcyBwYXJ0IG9mIHRoZSBpbnZhcmlhbnRzLg0KDQpJbiBzaG9y dCwgdGhlIG9ubHkgYWR2YW50YWdlIG9mIG9wdGlvbiAyIGlzIHRvIGF2b2lkIGEgc2luZ2xlIHN5 bW1ldHJpYyBlbmNyeXB0aW9uIG9wZXJhdGlvbiBwZXIgcGFja2V0LCB3aGlsZSBtYWtpbmcgdGhl IGNvZGUgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXgsIGFuZCBhdCB0aGUgY29zdCBvZiBub3Qg cHJvdGVjdGluZyBhZ2FpbnN0IFBOIG9zc2lmaWNhdGlvbi4gVGhlIHdheSBJIHNlZSB0aGF0LCB0 aGVyZSBpcyBoYXJkbHkgYW55IGRlYmF0ZS4NCg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg== --_000_CY4PR21MB0133F887774049426C51145DB6F20CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFp bG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFp bF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTI1NTY2Njg7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDgxMDY4NzY4O30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcHJvcG9zYWwgaXMgdG8ga2VlcCB0 aGUgUE4gaW4gZW5jcnlwdGVkIHBvcnRpb24gb2YgaGVhZGVyIGFuZCB1c2UgYSBkZWRpY2F0ZWQg bm9uY2UgaW4gcGxhaW4gdGV4dC4gSWYgbm9uLXJlcGVhdGluZyBub25jZSBpcyBuZWVkZWQgd2l0 aCB0aGF0IHByb2JhYmlsaXR5IHRoZW4gd2Ugd2lsbCBuZWVkIG11Y2ggbGFyZ2VyIG5vbmNlIHNp bmNlIDEwIEdicHMmIzQzOyByYXRlcyBhcmUgY29tbW9uIGluIHRoZSBkYXRhY2VudGVyLg0KIEEg bm9uY2UgY2FuIHNpbXBseSBiZSBnZW5lcmF0ZWQgdXNpbmcgUFJORy4gV2h5IGRvZXMgdGhlIHBl ZXLigJlzIFBSTkcgbWF0dGVyPyBUaGUgcGVlciB1c2VzIGEgZGlmZmVyZW50IFBOIHNwYWNlLiBU aGUganVtcHMgYXJlIGNvbXBsZXRlbHkgZGV0ZXJtaW5lZCBieSB0aGUgc2VuZGVyIGFzIG5lZWRl ZCBhbmQgaXRzIGp1c3QgdG8gcHJldmVudCBvc3NpZmljYXRpb24gb2YgYXNzdW1pbmcgdGhhdCBu b25jZSBhbHdheXMgaW5jcmVtZW50cyBieSAxLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlra2VsIEZhaG7D uGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCAxMToyMiBQTTxicj4NCjxiPlRvOjwvYj4g UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7OyBNaWtl IEJpc2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7OyBxdWljQGlldGYub3JnOyBodWl0 ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog UGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9v cF9jdXN0b21mb250Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5Zb3UgY2Fu4oCZdCBzYWZlbHkgcmV1c2UgdGhlIGNvbWJpbmF0aW9u IG9mIG5vbmNlIGFuZCBrZXksIElJVUMuJm5ic3A7IFNpbmNlIGtleSByb2xsb3ZlciBpcyBpbmZy ZXF1ZW50LCB0aGUgbm9uY2UgaGFzDQogdG8gY2hhbmdlIGV2ZXJ5IHBhY2tldCBhbmQgYmUgZ3Vh cmFudGVlZCB1bmlxdWUgb3ZlciB0aGUgbGlmZXRpbWUgb2YsIGlmIG5vdCB0aGUgY29ubmVjdGlv biwgYXQgbGVhc3QgdGhlIGN1cnJlbnQga2V5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5Gb3IgQ1RSIG1vZGUgZW5jcnlwdGlvbiB3aGljaCBBRVMtR0NNIGlz LCBpdCBpcyBleHRyZW1lbHkgYmFkIHRvIHJldXNlIHRoZSBub25jZS4gQnV0IGl0IGlzIHN0aWxs IHBlcm1pdHRlZCBpZiBub25jZSBvbmx5IHJlcGVhdHMgd2l0aCB2ZXJ5IGxvdyBwcm9iYWJpbGl0 eSwgbGlrZSAyXi0zMiBvcg0KIHNvLCBkb27igJl0IHJlY2FsbC4gVGhpcyBtZWFucyB0aGF0IHVz aW5nIGEgY3J5cHRvIGhhc2hlZCBwYWNrZXQgbnVtYmVycyBhcyBhIG5vbmNlIGlzIGFuIG9wdGlv biwgYnV0IGEgaG9tZWdyb3duIG9iZnVzY2F0aW9uIGlzIG5vdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5BcyB0byBoYXNoaW5nIHRoZSBwYWNrZXQgbnVtYmVyIGlu c3RlYWQgb2YgZW5jcnlwdGluZywgdGhlcmUgaXMgaGFyZGx5IGFueSB3b3J0aHdoaWxlIGhhc2gg dGhhdCBpcyBmYXN0ZXIgdGhhbiB1c2luZyBBRVMsIGJ1dCBwcmVjb21wdXRpbmcgdGhlIEFFUyBv dmVyIHNldmVyYWwgYmxvY2tzIGFzDQogTWlrZSBhbmQgSSBoYXZlIHN1Z2dlc3RlZCBlYXJsaWVy LCBpcyBhbiBvcHRpb24gdW5sZXNzIHlvdSBleHBlY3QgbGFyZ2UgbG9zc2VzIHdoZXJlIGEgc21h bGwgbG9va3VwIHRhYmxlIGlzIGluc3VmZmljaWVudCBvbiBhdmVyYWdlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgc2hhcmUgdGhlIGNvbmNlcm4gb24gcmVseWlu ZyBvbiB0aGUgYSBwZWVycyB3ZWFrIFBSTkcgZm9yIHBhY2tldCBqdW1wcyBldGMuIGVzcGVjaWFs bHkgJm5ic3A7aWYgaXQgaXMgbm90IHRoZSBzYW1lIGFzIHRoZSBjcnlwdG8gUFJORyBiZWNhdXNl IGlmIHRoYXQgaXMgYnJva2VuLCBpdCBkb2VzbuKAmXQgbWF0dGVyDQogYW55d2F5LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QXMgdGhlIHRoZSAxJSBu dW1iZXIgLSBpdCBpcyB0aGUgb25seSByZWFsIGxpZmUgZGF0YSB3ZSBoYXZlLCBidXQgSSBhbHJl YWR5IGFyZ3VlZCB0aGF0IHRoZSBvdmVyaGVhZCBjYW4gbXVjaCBoaWdoZXIgaW4gbG93LWxhdGVu Y3kgb3BlcmF0aW9ucyB3aXRoIHNob3J0IHBhY2tldHMuIEl0IGhhcw0KIGFsc28gYmVlbiBhcmd1 ZWQgdGhhdCBwYWNrZXQgbnVtYmVyIGlzIGxvd2VyIHRoYW4gQUVBRCBiZWNhdXNlIGl0IGlzIHNo b3J0ZXIsIGJ1dCBlbmNyeXB0aW5nIDY0IGJ5dGVzIEFFQUQgZm9yIGEgbWVzc2FnZSBpcyB0aGUg c2FtZSBhcyBlbmNyeXB0aW5nIDE2IGJ5dGVzIHBhY2tldCBudW1iZXIgYmVjYXVzZSBvZiBpbnN0 cnVjdGlvbiBsZXZlbCBwYXJhbGxlbGlzbSBvbiBjdXJyZW50IEludGVsIGhhcmR3YXJlLiBZb3Ug Y2FuIHNlZSBob3cgdGhlDQogcGVyZm9ybWFuY2UgaW5jcmVhc2VzIHdpdGggZGF0YSBsZW5ndGgg aW4gYXBwZW5kaXggQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZzb2Z0d2FyZS5pbnRlbC5jb20lMkZzaXRlcyUyRmRlZmF1 bHQlMkZmaWxlcyUyRm0lMkZkJTJGNCUyRjElMkZkJTJGOCUyRjEwVEIyNF9CcmVha3Rocm91Z2hf QUVTX1BlcmZvcm1hbmNlX3dpdGhfSW50ZWxfQUVTX05ld19JbnN0cnVjdGlvbnMuZmluYWwuc2Vj dXJlLnBkZiZhbXA7ZGF0YT0wNCU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDMjBlNjE1 YWE4MGRlNDMzNTRhZTEwOGQ1NmY4ZGQyYzklN0NlZTMzMDNkN2ZiNzM0YjBjODU4OWJjZDg0N2Yx YzI3NyU3QzElN0MxJTdDNjM2NTM3NTc3MjgyMzMxNDE5JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNk OGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lmUSUz RCUzRCU3Qy0xJmFtcDtzZGF0YT0yU2glMkJ6UDZXQzdmQkdyS3dVSFVoNENFSlRlMmhXazNiUjha QU4lMkJRY0QxYyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+aHR0cHM6Ly9zb2Z0d2FyZS5pbnRlbC5jb20v c2l0ZXMvZGVmYXVsdC9maWxlcy9tL2QvNC8xL2QvOC8xMFRCMjRfQnJlYWt0aHJvdWdoX0FFU19Q ZXJmb3JtYW5jZV93aXRoX0ludGVsX0FFU19OZXdfSW5zdHJ1Y3Rpb25zLmZpbmFsLnNlY3VyZS5w ZGY8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5N aWtrZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iYWly bWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gOSBGZWJydWFyeSAyMDE4IGF0IDA3LjE5LjMy LCBNaWtlIEJpc2hvcCAoPGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIj5tYmlz aG9wQGV2ZXF1ZWZvdS5iZTwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+WW91IGNhbuKAmXQgc2FmZWx5IHJldXNlIHRoZSBjb21iaW5hdGlvbiBvZiBub25jZSBhbmQg a2V5LCBJSVVDLiZuYnNwOyBTaW5jZSBrZXkgcm9sbG92ZXIgaXMgaW5mcmVxdWVudCwgdGhlIG5v bmNlIGhhcw0KIHRvIGNoYW5nZSBldmVyeSBwYWNrZXQgYW5kIGJlIGd1YXJhbnRlZWQgdW5pcXVl IG92ZXIgdGhlIGxpZmV0aW1lIG9mLCBpZiBub3QgdGhlIGNvbm5lY3Rpb24sIGF0IGxlYXN0IHRo ZSBjdXJyZW50IGtleS4mbmJzcDsgU2luY2UgcGFja2V0IG51bWJlcnMgYWxzbyBkb27igJl0IHJl cGVhdCBvdmVyIHRoZSBsaWZldGltZSBvZiB0aGUgY29ubmVjdGlvbiwgSSB0aGluayB1c2luZyBv bmUgYXMgdGhlIHZhcmlhYmxlIHBhcnQgb2YgdGhlIG90aGVyIHdhcyBqdXN0DQogdGFraW5nIGFk dmFudGFnZSBvZiB0aGUgYWxpZ25tZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9u4oCZ dCB0aGluayBoYXZpbmcgYSByYW5kb21pemVkIHN0YXJ0aW5nIHZhbHVlIGFuZCBpbmNyZW1lbnRp bmcgaXMgbmVjZXNzYXJpbHkgYW55IGJldHRlciB0aGFuIGV4cG9zaW5nIHRoZSBwYWNrZXQNCiBu dW1iZXIuJm5ic3A7IEhhdmluZyBhIFBSTkcgc2VlZCBlc3RhYmxpc2hlZCBkdXJpbmcgdGhlIGhh bmRzaGFrZSBhbmQgbWFraW5nIHRoZSB2aXNpYmxlIHRoaW5nIHRoZSBuZXh0IHJhbmRvbSBvdXRw dXQgc2VlbXMgcG90ZW50aWFsbHkgaW50ZXJlc3RpbmcsIGJ1dCBJ4oCZZCB3YW50IG91ciBtb3Jl IGNyeXB0by1taW5kZWQgZnJpZW5kcyB0byBjb21tZW50LiZuYnNwOyBJIHRoaW5rIHRoZSByZWFs IGlzc3VlIHdvdWxkIGJlIGd1YXJhbnRlZXMgYWJvdXQgbmV2ZXItcmVwZWF0aW5nDQogZnJvbSB0 aGUgUFJORywgcGFydGljdWxhcmx5IGFzIHlvdSBkb27igJl0IGhhdmUgZ3VhcmFudGVlcyBhYm91 dCB5b3VyIHBlZXLigJlzIGltcGxlbWVudGF0aW9uLiZuYnNwOyBBIGRlZmluZWQga2V5IGRlcml2 YXRpb24gYW5kIGEgY291bnRlciBjYW4gYmUgdmVyaWZpZWQgaW4gdGhlIHByb3RvY29sLCBpbmRl cGVuZGVudCBvZiBob3cgZ29vZCB0aGUgcGVlcuKAmXMgUFJORyBpcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPlByYXZlZW4gQmFsYXN1YnJhbWFuaWFuPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz ZGF5LCBGZWJydWFyeSA4LCAyMDE4IDk6NDAgUE08YnI+DQo8Yj5Ubzo8L2I+IGh1aXRlbWEgJmx0 OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Ij5odWl0ZW1hQGh1aXRlbWEubmV0 PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BY3R1YWxseSB0YWtpbmcgYSBzdGVw IGJhY2sgd2hhdCBpZiB3ZSBkb27igJl0IHdlIG92ZXJsb2FkZWQgcGFja2V0IG51bWJlciBhcyB0 aGUgbm9uY2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q2FuIHdlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5QdXQgcGFja2V0IG51 bWJlciBhcyBhIHNlcGFyYXRlIHZhcmlhYmxlIGxlbmd0aCBmaWVsZCBpbiB0aGUgZW5jcnlwdGVk IHBvcnRpb24gb2YgdGhlIGhlYWRlci4gVGhpcyBhbGxvd3MgZm9yIGdyb3d0aCBiZXlvbmQgNjQg Yml0cyBpbiBmdXR1cmUgYW5kIGNvbXBsZXRlbHkgYXZvaWRzIG9zc2lmaWNhdGlvbi4gRm9yIHNo b3J0IGxpdmVkDQogZmxvd3MgdmFyaWFibGUgbGVuZ3RoIGVuY29kaW5nIGxlYWRzIHRvIG1pbmlt YWwgc3BhY2Ugb3ZlcmhlYWQuIDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UHV0 IGEgc2VwYXJhdGUgcGxhaW50ZXh0IG5vbmNlIHdoaWNoIHN0YXJ0cyBvdXQgYXMgYSBzZWN1cmUg cmFuZG9tIG51bWJlciBhbmQgbW9ub3RvbmljYWxseSBpbmNyZWFzZXMgYXMgc2hvcnQgcmFuZG9t IGp1bXBzIChldmVyeSBwYWNrZXQgb3IgZXZlcnkgZmV3IHBhY2tldHMpIGFuZCBjb3VsZCB0aGVu IHJvbGxvdmVyLiBUaGlzIHdpbGwNCiBwcmV2ZW50IGxpbmthYmlsaXR5IGFuZCBzY2FsZXMgdG8g bXVsdGktcGF0aCBhcyB3ZWxsLiBObyBtYWpvciBjb21wdXRlIG92ZXJoZWFkLiBXZSBjYW4gYWxz byBtYWtlIHRoZSBub25jZSBvcHRpb25hbCBmb3IgY3J5cHRvIGFsZ29yaXRobXMgdGhhdCBkbyBu b3QgbmVlZCBhIG5vbmNlIHNhdmluZyBtb3JlIHNwYWNlLg0KPG86cD48L286cD48L3NwYW4+PC9s aT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+U29tZSBNU0Igb2YgdGhlIG5vbmNlIGNvdWxkIGJlIHVzZWQgZm9yIHNpZ25hbGlu ZyByZW9yZGVyIHRvIHRoZSBuZXR3b3JrIGlmIG5lZWRlZC4gSSBkb27igJl0IGhhdmUgdGhlIGhp c3RvcmljYWwNCiBjb250ZXh0IGZvciBvdmVybG9hZGluZyBvZiBQTiBhcyB0aGUgbm9uY2Ugc28g cGFyZG9uIG1lIGlmIHVuLW92ZXJsb2FkaW5nIG9wdGlvbiB3YXMgZGlzY3Vzc2VkIGFuZCBydWxl ZCBvdXQgYmVmb3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiBRVUlD IFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UHJhdmVlbiBCYWxhc3VicmFt YW5pYW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggNTo1MSBQ TTxicj4NCjxiPlRvOjwvYj4gaHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVp dGVtYS5uZXQiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpx dWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog UGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7IGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBl YWNoIHBhdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5UaGlzIGFsb25lIHByZXZlbnRzIGxpbmthYmlsaXR5IHJpZ2h0Pzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7IFRoZSBwYWNrZXQgbnVtYmVyIG9uIGVhY2gg cGF0aCB3aWxsIHN0YXJ0IGF0IDEgKG9yIG1heWJlIDAgOy0pLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklzIHN1cHBvcnRp bmcgbXVsdGlwbGUgcGF0aHMgYXQgdGhlIHNhbWUgdGltZSBhIGdvYWw/IElmIHllcywgdGhlbiB5 ZXMgYWxsIHBhdGhzIHdpbGwgbmVlZCB0byBoYXZlIHNlcGFyYXRlIHRyYWNraW5nDQogYW5kIEFD SyBzdGF0ZSBhbmQgY29uZ2VzdGlvbiBjb250cm9sIGV0Yy4gSSB0aG91Z2h0IHRoaXMgaXMgbm90 IHBhcnQgb2YgVjEgUkZDLiBJZiBpdHMganVzdCBvbmUgYWRkaXRpb25hbCBwYXRoIGZvciBjb25u ZWN0aW9uIG1pZ3JhdGlvbiBzY2VuYXJpbyB0aGVuIGFsbCB5b3UgbmVlZCBpcyBhIChyYW5kb20p IGp1bXAgdG8gYSBvZmZzZXQgaW4gcGFja2V0IG51bWJlciBzcGFjZSBmb3IgdGhlIG5ldyBwYXRo IHNvIHRoYXQgdGhlIGZldyBwYWNrZXRzDQogaW4gdGhlIG9sZCBwYXRoIGNhbiBjb250aW51ZSBm b3IgYSBsaXR0bGUgYml0LiBUaGlzIHdvcmtzIHdpdGgganVzdCBvbmUgQUNLIHNwYWNlIHNvIG5v IGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZn dDsgMikgT3IsIGxlYXZpbmcgdGhlIHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1dCB1c2lu ZyBkaWZmZXJlbnQgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQgdXNpbmcN CiBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBlYWNoIHBhdGguPGJyPg0KSW4gYWRkaXRp b24gaWYgdGhlIHZhbHVlIGluIHRoZSBjbGVhciB3YXMgb2JmdXNjYXRlZCB3aXRoIGFuIFhPUiB0 cmFuc2Zvcm0gaXQgd2lsbCBoZWxwIHByZXZlbnQgb3NzaWZpY2F0aW9uLiBUaGUgb2JmdXNjYXRp b24gaXMgbm90IG1lYW50IHRvIGd1YXJkIGFnYWluc3QgbGF0ZXIgYW5hbHlzaXMgdGhhdCByZXZl YWxzIHRoZSBwYWNrZXQgbnVtYmVycyAtIHdoeSBkbyB3ZSBjYXJlIGFib3V0IHRoYXQuIEl0IGlz IG1lYW50IHRvIGdyZWFzZSB0aGUNCiBzcGFjZSBhbmQgbm90IG1ha2UgdGhlIG51bWJlcnMgc2Vy aWFsIHNvIG1pZGRsZWJveGVzIGNhbm5vdCBhc3N1bWUgb3JkZXJpbmcgZXRjLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPkFsbCBzYWlkIGlmIEkgYW0gYWxvbmUgaW4gYmVpbmcgY29uY2VybmVkIGFi b3V0IHRoZSBwZXJmIGhpdCB0aGVuIEnigJlkIHNheSBnbyBvbiB3aXRoIG9wdGlvbiAxLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBp biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMgWzxhIGhyZWY9Im1haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RpYW4gSHVpdGVtYTxicj4NCjxiPlNlbnQ6PC9i PiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAxOCAzOjU0IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBo cmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ T24gMi84LzIwMTggMToxMyBQTSwgTWlrZSBCaXNob3Agd3JvdGU6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4jMiB3b27i gJl0IHdvcmsuJm5ic3A7IFRoZSBwYWNrZXQgbnVtYmVyIGlzIGFuIGlucHV0IHRvIHRoZSBBRUFE IG5vbmNlLCBzbyB5b3UgaGF2ZSB0byBnZXQgdG8gdGhlIHBhY2tldCBudW1iZXIgYmVmb3JlDQog eW91IGNhbiBkZWNyeXB0IHRoZSBwYXlsb2FkLiZuYnNwOyBJdCBjYW7igJl0IGJlIGJhc2VkIG9u IGFueXRoaW5nIGludGVybmFsIHRvIHRoZSBlbmNyeXB0ZWQgcGFja2V0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPkluIE1hcnRpbuKAmXMgcHJvcG9zYWwsIGl04oCZcyB1c2luZyBhIGNvbWJpbmF0 aW9uIG9mIHRoZSBlbmNyeXB0ZWQgcGF5bG9hZCAod2hpY2ggcmVxdWlyZXMgbm90aGluZyB0byBh Y2Nlc3MpIGFuZA0KIHNvbWUgc3RvcmVkIHN0YXRlIG9uIGVhY2ggZW5kcG9pbnQsIHdoaWNoIHJl cXVpcmVzIG9ubHkgdGhlIENvbm5lY3Rpb24gSUQgdG8gbG9vayB1cC4mbmJzcDsgWW91IHdhbnQg dGhlIHRoaW5nIHlvdSBYT1IgYnkgdG8gYmUgY29uc3RhbnRseSBjaGFuZ2luZywgb3IgaXQgYmVj b21lcyBlYXNpZXIgdG8gbG9vayBhdCBzZXF1ZW5jZXMgb2Ygb2JmdXNjYXRlZCBwYWNrZXQgbnVt YmVycyBhbmQgc3RhcnQgZHJhd2luZyBpbmZlcmVuY2VzIGFib3V0IHdoYXQgdGhlDQogWE9SIHZh bHVlIGlzLiZuYnNwOyBJZiBvdmVyaGVhZCBpcyB0aGUgcHJpbWFyeSBjb25jZXJuLCBJIHRoaW5r IHRoZXJlIGFyZSBhIGNvdXBsZSBhcHByb2FjaGVzIHRoYXQgbWlnaHQgYWxsb3cgeW91IHRvIHBy ZWNvbXB1dGUgdmFsdWVzIGFuZCBhbW9ydGl6ZSB0aGUgY29zdCBvZiBkb2luZyB0aGUgZW5jcnlw dGlvbiBzdGVwLiZuYnNwOyAoQXQgdGhlIGNvc3Qgb2Yga2VlcGluZyB0aGUgdGFibGUgb2YgcHJl Y29tcHV0ZWQgdmFsdWVzLCBvZiBjb3Vyc2UuKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgc3Rp bGwgdGhpbmsgSmFuYeKAmXMgcHVzaGluZyBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uIGhlcmU6Jm5i c3A7IExldOKAmXMgYWdyZWUgb24gZ29hbHMsIGFuZCB0aGVuIHNlZSBpZiB3ZSBjYW4gY3JhZnQg YQ0KIGRlc2lnbiB0aGF0IG1lZXRzIHRob3NlIGdvYWxzLiZuYnNwOyBJIGhlYXIgeW91IHNheWlu ZyB0aGF0IGxvdyBvdmVyaGVhZCBpcyBhIGdvYWwsIHdoaWNoIEkgdGhpbmsgd2UgY2FuIGFsbCBh Z3JlZSBvbi4mbmJzcDsgSSBhbHNvIHRoaW5rIEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgMS0xLjUl IG92ZXJoZWFkIGlzIHRvbyBoaWdoLCBidXQgaXQgc291bmRzIGxpa2UgdGhlcmXigJlzIGxlc3Mg YWdyZWVtZW50IG9uIHRoYXQuJm5ic3A7IFlvdSBhbHNvIHJhaXNlIGFuIGludGVyZXN0aW5nDQog cG9pbnQgdGhhdCBzb21lIGNsaWVudHMgd2lsbCBjYXJlIGxlc3MgYWJvdXQgbGlua2FiaWxpdHkg YmVjYXVzZSB0aGV5IHdpbGwgbmV2ZXIgaW50ZW50aW9uYWxseSBtaWdyYXRlLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxicj4NCkkgdGhpbmsgVmljdG9yIHNhaWQgaXQgYmVzdCwgJnF1b3Q7T2JmdXNjYXRp b24gaXMganVzdCBlbmNyeXB0aW9uIGRvbmUgcG9vcmx5LiZxdW90OyBFaXRoZXIgd2UgZW5jcnlw dCwgb3Igd2UgZG9uJ3QuIEJ1dCB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGFuIG9iZnVzY2F0 aW9uIG1pZGRsZS1ncm91bmQuIE9iZnVzY2F0aW9uIHdvdWxkIGp1c3QgYmUgYSBzcGVlZCBidW1w LCBlYXNpbHkgYnJva2VuLiBJdCB3b24ndCBwcm92aWRlIHByaXZhY3ksIGFuZCBpdCB3b24ndA0K IHByZXZlbnQgbGlua2FiaWxpdHkuPGJyPg0KPGJyPg0KQXMgZmFyIGFzIEkgYW0gY29uY2VybmVk LCB0aGVyZSBhcmUgb25seSB0d28gZGVzaWducyB0aGF0IHByZXZlbnQgbGlua2FiaWxpdHk6PGJy Pg0KPGJyPg0KMSkgTWFydGluJ3MgUFIsIGluIHdoaWNoIHRoZSBwYWNrZXQgbnVtYmVyIGlzIGVu Y3J5cHRlZCB1c2luZyBzZW5zaWJsZSBjcnlwdG87PGJyPg0KPGJyPg0KMikgT3IsIGxlYXZpbmcg dGhlIHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1dCB1c2luZyBkaWZmZXJlbnQgZW5jcnlw dGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNl cXVlbmNlcyBmb3IgZWFjaCBwYXRoLjxicj4NCjxicj4NClRoZSBzZWNvbmQgb3B0aW9uIHJlcXVp cmVzIG1vcmUgY29tcHV0YXRpb24gd2hlbiBleHBsaWNpdGx5IHNldHRpbmcgdXAgYSBuZXcgcGF0 aC4gVGhlIGNvbm5lY3Rpb24gSUQgd291bGQgYmUgdXNlZCBhcyBwYXJ0IG9mIHRoZSAmcXVvdDtz YWx0JnF1b3Q7IHdoZW4gZGVyaXZpbmcgY29ubmVjdGlvbiBjb250ZXh0cy4gVGhlIHBhY2tldCBu dW1iZXIgb24gZWFjaCBwYXRoIHdpbGwgc3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7LSkuIFRoaXMg cmVxdWlyZXMgbWFpbnRhaW5pbmcNCiBzZXBhcmF0ZSBTQUNLIGRhc2hib2FyZHMgZm9yIGVhY2gg cGF0aC9Db25uZWN0aW9uLUlELCBhbmQgY29uc3RyYWluaW5nIEFDSyB0byBiZSBwZXIvcGF0aCwg b3IgYWx0ZXJuYXRpdmVseSBhZGRpbmcgYSBQQVRILUFDSyBmcmFtZSB0aGF0IGluZGljYXRlcyB0 aGUgcGF0aCBmb3Igd2hpY2ggcGFja2V0cyBhcmUgYWNrZWQuPGJyPg0KPGJyPg0KVGhlIHByb3Mg YW5kIGNvbnMgb2YgdGhlIHR3byBvcHRpb25zIGFyZSBlYXN5IHRvIGdldDo8YnI+DQo8YnI+DQox KSBPcHRpb24gMiBkb2VzIG5vdCByZXF1aXJlIHRoZSBjb3N0IG9mIGVuY3J5cHRpbmcgZXZlcnkg cGFja2V0LCB0aHVzIHBlciBwYWNrZXQgcHJvY2Vzc2luZyB3aWxsIGJlIG1heWJlIDElIGZhc3Rl ciB0aGFuIG9wdGlvbiAxLg0KPGJyPg0KPGJyPg0KMikgT3B0aW9uIDIgcmVxdWlyZXMgY29tcHV0 aW5nIGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgd2hpY2ggaXMgbW9yZSBjb21w bGV4IHRoYW4gb3B0aW9uIDEsIGJ1dCB0aGUgY29zdCB3aWxsIGJlIGFtb3J0aXplZCBvdmVyIHRo ZSBkdXJhdGlvbiBvZiB0aGUgcGF0aC48YnI+DQo8YnI+DQozKSBPcHRpb24gMiByZXF1aXJlcyBt b3JlIGNvbXBsZXggZGF0YSBzdHJ1Y3R1cmVzIGFuZCBBQ0sgbWFuYWdlbWVudCwgdGh1cyBpbmNy ZWFzaW5nIHRoZSBjaGFuY2VzIHRoYXQgc29tZXRoaW5nIGdvZXMgd3JvbmcuPGJyPg0KPGJyPg0K NCkgT3B0aW9uIDIgZG9lcyBub3RoaW5nIGFnYWluc3QgcGFja2V0IG51bWJlciBvc3NpZmljYXRp b24uIFRoZSBwYWNrZXQgbnVtYmVyIGVmZmVjdGl2ZWx5IGJlY29tZXMgcGFydCBvZiB0aGUgaW52 YXJpYW50cy48YnI+DQo8YnI+DQpJbiBzaG9ydCwgdGhlIG9ubHkgYWR2YW50YWdlIG9mIG9wdGlv biAyIGlzIHRvIGF2b2lkIGEgc2luZ2xlIHN5bW1ldHJpYyBlbmNyeXB0aW9uIG9wZXJhdGlvbiBw ZXIgcGFja2V0LCB3aGlsZSBtYWtpbmcgdGhlIGNvZGUgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBs ZXgsIGFuZCBhdCB0aGUgY29zdCBvZiBub3QgcHJvdGVjdGluZyBhZ2FpbnN0IFBOIG9zc2lmaWNh dGlvbi4gVGhlIHdheSBJIHNlZSB0aGF0LCB0aGVyZSBpcyBoYXJkbHkgYW55IGRlYmF0ZS48YnI+ DQo8YnI+DQotLSBDaHJpc3RpYW4gSHVpdGVtYTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0133F887774049426C51145DB6F20CY4PR21MB0133namp_-- From nobody Thu Feb 8 23:34:55 2018 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 C52F512741D for ; Thu, 8 Feb 2018 23:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=ericsson.com header.b=BfC5zD5E; dkim=pass (1024-bit key) header.d=ericsson.com header.b=gqwyblpV 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 nn7L3NT1XKwa for ; Thu, 8 Feb 2018 23:34:50 -0800 (PST) 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 1CFBB124234 for ; Thu, 8 Feb 2018 23:34:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518161688; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wEpLfwoX3GVlM+dwrBcDw93gulVvL+7MIZ29Sb/sgac=; b=BfC5zD5EQseaxJ+Ik8xk6xw8oDznnAfri6ly+Ujmvceb9IYJWV5Z4TU1nX6oNN6A nfYxnxafEyMN2CeEcyvrqNgKpq6pctqltFvGM8H1ctqZLlSwcQPBUk4ujaITKcGg X7BM0bLyOkmlv5WL7qZktfC+DMZaGbTFri98kwFm8r0=; X-AuditID: c1b4fb2d-4b1ff70000005540-3e-5a7d4f184085 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.F0.21824.81F4D7A5; Fri, 9 Feb 2018 08:34:48 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 9 Feb 2018 08:34:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wEpLfwoX3GVlM+dwrBcDw93gulVvL+7MIZ29Sb/sgac=; b=gqwyblpVMYbGMpYinr6/zpEBl36M8jdnCElZS6woo98FaWHKh5GCJNXxyCAksKm626dFH+CZKGv3bpyHmKbxn4wYtskyfyY3QyzoJQI3thFonF6KsT3lfTfwjBpApDzJNpn8zsdFBAGu2/l9WMifyOdwpkY+3UBsmSe1Txh5p+4= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3564.eurprd07.prod.outlook.com (52.133.6.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Fri, 9 Feb 2018 07:34:46 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::38e6:dea0:2f4f:715]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::38e6:dea0:2f4f:715%13]) with mapi id 15.20.0485.009; Fri, 9 Feb 2018 07:34:46 +0000 From: Ingemar Johansson S To: "De Schepper, Koen (Nokia - BE/Antwerp)" , "ekinnear@apple.com" CC: QUIC WG , Ian Swett , "Lubashev, Igor" , Christian Huitema , "Ingemar Johansson S" Subject: RE: ECN in QUIC connection migration Thread-Topic: ECN in QUIC connection migration Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25AAZWcAAAB/s3/ABUaWKkA== Date: Fri, 9 Feb 2018 07:34:46 +0000 Message-ID: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3564; 7:cCEZQcmubo9zgA+TiuhXa4zvifXIkLicemR1bmYRFCC8E2c4RgLXjBfJquCWusfMN3mwBaKkwZmlZ5klQuBbYOP0i5lbvCJa6inawJ/4XrW019Mkhub3Vhe5D6tsGi9gk3Yd0kqoXnFeBP0wcT9wQv4HOoqCDCoVbtEkFZGaH7VAx2wA4UGLftV3vW7mxvXnFd6iVisL1dNoVNFluqWekLjHDdWO7bgC/pJ/sQ0YkMgtEmWZiY1IwI0O4uhZPfPK x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(366004)(396003)(376002)(39380400002)(346002)(39860400002)(189003)(51914003)(199004)(229853002)(7736002)(966005)(3660700001)(186003)(26005)(14454004)(6436002)(8666007)(2501003)(55016002)(8676002)(2950100002)(3280700002)(478600001)(99286004)(59450400001)(5250100002)(105586002)(33656002)(68736007)(2906002)(66066001)(25786009)(81166006)(2900100001)(790700001)(3846002)(81156014)(316002)(6246003)(76176011)(5660300001)(53546011)(19609705001)(53936002)(54896002)(9686003)(97736004)(102836004)(106356001)(74316002)(6506007)(8936002)(7696005)(6306002)(606006)(110136005)(236005)(86362001)(54906003)(4326008)(107886003)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3564; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: bfbe6938-fe5f-41ee-532d-08d56f8f97e1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3564; x-ms-traffictypediagnostic: HE1PR0702MB3564: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(166708455590820)(211936372134217)(202460600054446)(153496737603132)(21748063052155)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231101)(2400082)(944501161)(6041288)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR0702MB3564; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3564; x-forefront-prvs: 057859F9C5 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: y/6/H3oVwNHX8SA8fHodEKS6a2LCyeNPu0g0qgL4yNbnVs3dZ6hFvFdkq09tL33uvn/5qCg5xLW7O2lz0XMFsw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB36256D92C008302CBD908DE9C2F20HE1PR0702MB3625_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bfbe6938-fe5f-41ee-532d-08d56f8f97e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 07:34:46.1301 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3564 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SWUwTURSGvTOd6VCtXivLESFKhUTUggKSPhAimEgNIfKofYEGJtDIlg4Q AYmlEZdSFkUNi0g1xY2IBi1FwQfAqCwRQVCEBFkqihgTEKlEKNIOJrx95//Pf8+5N5chJX2U J6NOy2Q1aaoUKS0SVJ6wKGVwPF95wG7dLjfMRsnLC6qF8sXRZ5Rcp71Hyl8t1BFyg3HjYVpR /tJIKsydf2iFsTFLMVzRJVCYTIuEQrdwm46llaKwRDZFnc1qAsPjRckdAxYqY24Kndb3RGjR tzGkRwwDOAQu1ATpkYiR4A4ENYV2ii9eIxjpaSMdhQDPEWAsqyZ55xoBgz8aaL6wIljSX1w9 y4WhcRjcb7chh+GKdQimSy8RjoLE3QhuausoR9c2LAOzrpt0sCsOgGnDOYrnSLh110w5thJg X/gwLnDIYhwPfbXWtWnfEViqB5z9LlgFb00TzskIe8Nn26gzQGIPGLbWEg4GjMHU2kvy7AbT k3aK70+AuU/FFK/vgqX+CZpnb+ivLXLeAHATAQXLs2tGMOjLWtcCLTSMVoTyHAPVb4ppPtCF YGjFhnhjP/TqB4U8p4O9uHltiwYE3YZUPnCDhJGSbqIMBVSt25zndJj/+cTJYrwVOiutgqrV lyGxPzx6Hsi3+MDVonEhz3ug8EaNcL1uRMIHyI1jOS41KSg4gNWoEzguPS0gjc1sRKsfre3p X1kzqp+JaEeYQdJN4pPyfKWEUmVzOantCBhS6ip+F7MqiRNVObmsJj1Ok5XCcu1oByOQeog7 j4mVEpykymRPsWwGq/nvEoyLpxZd33Dkt79f6NL8ZVFp61Gzz/L5ZPfgkoIXWbujvSZjI7R9 Xk0mn9mxuJk8b1mtbT5SPmTRBbP75nf6UUzEnVizYbhTndi8RJZ+iX4Pv4ano4omReqWkC0u Zyyq+KYx34q8lTBQnt0sqQutX6yc+sgdCnd/GOSqHr/y+GuPNTdVKuCSVQf3khpO9Q/yqmxM ZAMAAA== 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, 09 Feb 2018 07:34:54 -0000 --_000_HE1PR0702MB36256D92C008302CBD908DE9C2F20HE1PR0702MB3625_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgRXJpYywgS29lbiArIG90aGVycw0KDQpUaGFua3MgZm9yIHRoZSBjb21tZW50cyBhbmQgdGhl IHVwZGF0ZS4gQSBxdWVzdGlvbiB0byB0aGUgcmVzdCBvZiB0aGUgYXVkaWVuY2UsIGRvZXMgdGhl IHByZXNlbnRlZCB0ZXh0IGV4cGxhaW4gc3VmZmljaWVudGx5IGVub3VnaCBob3cgRUNOIHdvcmtz IHdpdGggY29ubmVjdGlvbiBtaWdyYXRpb24gPw0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9i YXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1RVUlDI3RyYW5zcG9ydC1kcmFmdC1jb25uZWN0aW9uLW1p Z3JhdGlvbg0KDQoNCi9JbmdlbWFyDQoNCg0KRnJvbTogRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lh IC0gQkUvQW50d2VycCkgW21haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5j b21dDQpTZW50OiBkZW4gMiBmZWJydWFyaSAyMDE4IDE1OjQ0DQpUbzogZWtpbm5lYXJAYXBwbGUu Y29tOyBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNv bT4NCkNjOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29n bGUuY29tPjsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+OyBDaHJpc3RpYW4g SHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4NClN1YmplY3Q6IFJFOiBFQ04gaW4gUVVJQyBj b25uZWN0aW9uIG1pZ3JhdGlvbg0KDQpIaSBJbmdlbWFyLA0KDQpJIGFsc28gcmVhZCBhZ2FpbiB0 aHJvdWdoIHRoZSBkb2N1bWVudCwgYW5kIGhhZCBmb2xsb3dpbmcgY29tbWVudHM6DQoNCkkgcmVw bGFjZWQ6DQrigJxUaGUgQUNLX0VDTiBmcmFtZSBpcyB1c2VkIHRvIGNvbnZleSBBQ0tzIHdoZW4g dGhlIEVDTiBjYXBhYmlsaXR5IGV4Y2hhbmdlIGNvbmNsdWRlcyB0aGF0IEVDTiBzaG91bGQgYmUg dXNlZCBmb3IgdGhlIGdpdmVuIGNvbm5lY3Rpb24u4oCdDQpPcmlnaW5hbGx5IGl0IHNvdW5kcyBh cyBpZiB0aGUgY291bnRlcnMgYXJlIG5vdCBlY2hvZWQgYW55bW9yZSBpZiB0aGUgRUNOIGNhcGFi aWxpdHkgY2hlY2sgZmFpbHMuIEkgYXNzdW1lIHRoaXMgd2FzIG5vdCB0aGUgaW50ZW50aW9uLCBi dXQgaWYgaXQgaXM6IEZpcnN0LCB3ZSBkb27igJl0IGhhdmUgYSBwcm90b2NvbCBvciBkZWNpc2lv biBwb2ludCBkZWZpbmVkIHdoZW4gdGhhdCBjb25kaXRpb24gaXMgbWV0IChzZW5kZXIgc2hvdWxk IGxldCB0aGUgcmVjZWl2ZXIga25vdyBpbiB0aGUgbmV4dCBwYWNrZXQpLCBhbmQgc2Vjb25kLCBJ IHdvdWxkIGFsd2F5cyBzZW5kIHRoZSBlY2hvLCBhcyB3ZSBtaWdodCDigJx0cnkgYWdhaW4gbGF0 ZXIgKHdpdGggYW5vdGhlciBFQ1Q/KeKAnSwgb3IgbWlnaHQgZGVjaWRlIHRvIHVzZSB0aGUgRUNO IGJpdHMgZGlmZmVyZW50bHkgbGF0ZXIuDQoNCkkgYWxzbyBjaGFuZ2VkIHRoZSB0ZXh0IGFyb3Vu ZCB0aGUgY29ubmVjdGlvbiBtaWdyYXRpb24sIEkgdGhpbmsgYmVmb3JlIEVyaWMgcmV2aWV3ZWQg aXQuIEkgbWFkZSBpdCBzdWNoIHRoYXQgZXZlcnkgbmV3IHBhdGggY3JlYXRlcyBhIG5ldyBjb25u ZWN0aW9uIHN0YXRlIHdpdGggYW4gaW5pdGlhbGl6ZWQgY29uZ2VzdGlvbiBjb250cm9sIHN0YXRl IGFuZCBFQ04gY291bnRlcnMgKGF0IGxlYXN0IEVDTiBjb3VudGVycyByZXNldCB0byAwcykuIE5v dCBzdXJlIGlmIHRoaXMgbWF0Y2hlcyB3aXRoIHRoZSBvdGhlciBzZWN0aW9ucyBpbiB0aGUgUVVJ QyBkcmFmdC4NCg0KSSBhbHNvIGhhZCB0aGUgdGhvdWdodCB3aGV0aGVyIGl0IHdhcyByZWFsbHkg bmVlZGVkIHRvIGhhdmUgdGhlIDIgY2FzZXMuIEkgYWdyZWUgd2Ugc2hvdWxkIHNpbXBsaWZ5LCBi eSBqdXN0IHN0YXJ0aW5nIG92ZXIgYW5kIGRvaW5nIHRoZSBjaGVjayB1bmNvbmRpdGlvbmFsbHkg d2hldGhlciBpdCB3YXMgc3VjY2Vzc2Z1bCBvciBub3QgaW4gYSBwcmV2aW91cyBwYXRoLg0KDQpS ZWdhcmRzLA0KS29lbi4NCg0KRnJvbTogZWtpbm5lYXJAYXBwbGUuY29tPG1haWx0bzpla2lubmVh ckBhcHBsZS5jb20+IFttYWlsdG86ZWtpbm5lYXJAYXBwbGUuY29tXQ0KU2VudDogRnJpZGF5LCBG ZWJydWFyeSAyLCAyMDE4IDEyOjAyIEFNDQpUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1h ci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJp Y3Nzb24uY29tPj4NCkNjOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYu b3JnPj47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29v Z2xlLmNvbT4+OyBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1 YmFzaGVAYWthbWFpLmNvbT4+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5l dDxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+OyBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEg LSBCRS9BbnR3ZXJwKSA8a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tPG1haWx0 bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20+Pg0KU3ViamVjdDogUmU6IEVD TiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uDQoNCkhpIEluZ2VtYXIsDQoNClRoaXMgZ2Vu ZXJhbGx5IGxvb2tzIGdvb2QgdG8gbWUhDQpBIGZldyBxdWVzdGlvbnMgYW5kIG9ic2VydmF0aW9u czoNCg0KVGhlcmUgYXJlIHR3byB1bmlxdWUgY2FzZXM6DQogICAgICAgICAgICAgICAg4oCiIEVD TiBjYXBhYmlsaXR5IGNoZWNrIHN1Y2Nlc3NmdWwgYXQgaW5pdGlhbCBjb25uZWN0aW9uIHNldHVw DQogICAgICAgICAgICAgICAg4oCiIEVDTiBjYXBhYmlsaXR5IGNoZWNrIGZhaWxlZCBhdCBpbml0 aWFsIGNvbm5lY3Rpb24gc2V0dXANCg0KQXJlIHRoZXNlIGFjdHVhbGx5IGFueSBkaWZmZXJlbnQg aW4gdGVybXMgb2YgYWN0aW9uIHRha2VuIGJ5IGFuIGVuZHBvaW50Pw0KSXQgc2VlbXMgbGlrZSBv biB0aGUgbmV3IG5ldHdvcmsgcGF0aCB0aGUgZW5kcG9pbnQgd291bGQgZ28gdGhyb3VnaCB0aGUg c2FtZSBwcm9jZXNzIG9mOiAoYSkgdmVyaWZ5IEVDTiBjYXBhYmlsaXR5IGFuZCBpZiBzdWNjZXNz ZnVsIHRvIHdoYXRldmVyIGRlZ3JlZSB0aGVuIChiKSBydW4gdGhlIHJlc3Qgb2YgdGhlIEVDTiBt YWNoaW5lcnkgYXMgYXBwcm9wcmlhdGUuDQoNCkluIG90aGVyIHdvcmRzLCBhcyBsb25nIGFzIHlv dSBhbGxvdyBwZW9wbGUgdG8gc3RhcnQgdXNpbmcgRUNOIHVwb24gbWlncmF0aW9uIChpbiBvdGhl ciB3b3JkcywgdG8gYWxsb3cgc3RhcnRpbmcgaXQgYWZ0ZXIgdGhlIGluaXRpYWwgY29ubmVjdGlv biBlc3RhYmxpc2htZW50KSwgdGhlbiB0aGUgc3BlY2lmaWNzIGZvciBFQ04gd2l0aCBtaWdyYXRp b24gaXMgZXNzZW50aWFsbHkgb25lIHN0YXRlbWVudCwgd2hpY2ggaXMg4oCcZG8gdGhlIEVDTiBw cm9jZXNzIG9uIGVhY2ggbmV3IG5ldHdvcmsgcGF0aCB0aGF0IHlvdSB1c2XigJ0uDQoNCkNvbm5l Y3Rpb24gbWlncmF0aW9uIGhhcyBpbXBhY3Qgb24gdGhlIG51bWJlciBvZiByZXBvcnRlZCBDRSBt YXJrZWQgcGFja2V0cy4gQSBuZXcgY29ubmVjdGlvbiBzdGF0ZSB3aXRoIG5ldyBjb25nZXN0aW9u IGNvbnRyb2wgc3RhdGUgYW5kIEVDTiBjb3VudGVycyBpcyBpbnN0YW50aWF0ZWQgYXQgdGhlIHNl bmRlciBhbmQgcmVjZWl2ZXIuIFRoZSBFQ04gY291bnRlcnMgTVVTVCBzdGFydCBmcm9tIHplcm8g YWdhaW4uDQoNClRoaXMgc2VlbXMgZmluZSB0byBtZSwgaXTigJlzIGlubGluZSB3aXRoIHRoZSBy ZXN0IG9mIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wvbG9zcyByZWNvdmVyeSBzdGF0ZSB0aGF0IGFs c28gbmVlZHMgdG8gYmUgcmVzZXQgZm9yIHRoZSBuZXcgcGF0aC4NCg0KR2l2ZW4gdGhhdCBlYWNo IG1pZ3JhdGlvbiByZXF1aXJlcyBhdCBsZWFzdCBvbmUgZXhjaGFuZ2Ugb2YgcGFja2V0cyBhdCB0 aGUgYmVnaW5uaW5nIChhdCB0aGUgdmVyeSBsZWFzdCBmb3IgYWRkcmVzcyB2YWxpZGF0aW9uIGZy b20gdGhlIHNpZGUgb2YgdGhlIGVuZHBvaW50IHRoYXQgZGlkbuKAmXQgbWlncmF0ZSksIGl0IHNl ZW1zIGxpa2UgdGhhdOKAmXMgYW4gZXhjZWxsZW50IG1vbWVudCB0byBtYXJrIHRoZSBwYWNrZXRz IGFuZCBwZXJmb3JtIHRoZSBFQ04gY2FwYWJpbGl0eSBkZXRlY3Rpb24uIFRob3NlIHBhY2tldHMg YXJlIGFsc28gbGlrZWx5IHBhZGRlZCwgZXRjLiBzaW1pbGFyIHRvIGluaXRpYWwgcGFja2V0cyBz aW5jZSB0aGV54oCZcmUgb24gYSBwcmV2aW91c2x5IHVudXNlZCBuZXR3b3JrIHBhdGguDQoNCkkg dGhpbmsgdGhlIGN1cnJlbnQgcHJvcG9zZWQgcmVxdWlyZW1lbnQgb2YganVzdCB1c2luZyB0aGUg 4oCcZmlyc3TigJ0gcGFja2V0cyBhbmQgbWFya2luZyB0aG9zZSBpcyBzdWZmaWNpZW50IChhbmQg Z29vZCB0byBhdm9pZCBhbnkgcmVxdWlyZW1lbnQgYXMgdG8gd2hpY2ggZnJhbWVzIGFyZSBjb250 YWluZWQgaW4gdGhvc2UgcGFja2V0cyksIHNpbmNlIHdlIGFyZSBhbHdheXMgZXhjaGFuZ2luZyBw YWNrZXRzIGluIGJvdGggZGlyZWN0aW9ucyBpbW1lZGlhdGVseSBhZnRlciBtaWdyYXRpb24uDQoN ClRoaXMgaGFzIHRoZSBhZGRlZCBiZW5lZml0IHN1Y2ggdGhhdCBhbnkgZW5kcG9pbnQg4oCccHJv YmluZ+KAnSBwb3NzaWJsZSBuZXR3b3JrIHBhdGhzIGNvdWxkIGluY2x1ZGUgdGhlIGJpdHMgbmVj ZXNzYXJ5IHRvIGRldGVjdCBFQ04gY2FwYWJpbGl0eSBvbiB0aGUgcGF0aCBiZWluZyBwcm9iZWQs IHNvIGl0IGNvdWxkIGV2ZW4ga25vdyBiZWZvcmUgbWlncmF0aW5nIHdoZXRoZXIgb3Igbm90IGl0 IHdvdWxkIGJlIGFibGUgdG8gdXNlIEVDTiBvbiB0aGF0IG5ldyBwYXRoLg0KDQpUaGFua3MsDQpF cmljDQoNCg0KDQpPbiBGZWIgMSwgMjAxOCwgYXQgMzowNyBBTSwgSW5nZW1hciBKb2hhbnNzb24g UyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hh bnNzb25AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQoNCkhpDQpJIGhhdmUgd3JpdHRlbiB1cCBkaWZm ZXJlbnQgYXNwZWN0cyBvZiBjb25uZWN0aW9uIG1pZ3JhdGlvbiBhbmQgaG93IGl0IHBsYXlzIHdp dGggRUNOLg0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1p bi1RVUlDI3RyYW5zcG9ydC1kcmFmdC1jb25uZWN0aW9uLW1pZ3JhdGlvbg0KDQpBIGNhdmVhdC4u IEkgYW0gYSBiaXQgdW5zdXJlIGFib3V0IHRoZSBkZWZpbml0aW9uIG9mIGNvbm5lY3Rpb24gbWln cmF0aW9uIC4gTXkgaW50ZXJwcmV0YXRpb24gaXMgdGhhdCBhIGNsaWVudCBtb3ZlcyB0byBhIG5l dyBJUCBhZGRyZXNzIGR1ZSB0byBlLmcuIGEgTkFUIHJlYmluZCBvciBzd2l0Y2ggZnJvbSBXaUZp IHRvIGNlbGx1bGFyLCByaWdodCA/LiBJcyBhIG5ldyBjb25uZWN0aW9uIGluc3RhbnRpYXRlZCBh dCBhIGNvbm5lY3Rpb24gbWlncmF0aW9uID8NCg0KL0luZ2VtYXINCg0KPT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KSW5nZW1hciBKb2hhbnNzb24gIE0uU2MuDQpNYXN0ZXIgUmVz ZWFyY2hlcg0KDQpFcmljc3NvbiBSZXNlYXJjaA0KTmV0d29yayBQcm90b2NvbHMgJiBFMkUgUGVy Zm9ybWFuY2UNCkxhYnJhdG9yaWVncsOkbmQgMTENCjk3MSAyOCwgTHVsZcOlLCBTd2VkZW4NClBo b25lICs0Ni0xMDcxIDQzMDQyDQpTTVMvTU1TICs0Ni03MyAwNzggMzI4OQ0KaW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24u Y29tPg0Kd3d3LmVyaWNzc29uLmNvbTx4LW1zZzovLzMxNi93d3cuZXJpY3Nzb24uY29tPg0KDQog ICAgICAgICAgICAgICAgIFlvdSBjYW4ndCBzdGFydCBhIGZpcmUNCiAgV29ycnlpbmcgJ2JvdXQg eW91ciBsaXR0bGUgd29ybGQgZmFsbGluZyBhcGFydA0KICAgICAgICAgICAgICAgQnJ1Y2UgU3By aW5nc3RlZW4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0K --_000_HE1PR0702MB36256D92C008302CBD908DE9C2F20HE1PR0702MB3625_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7 bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4w cHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEVyaWMs IEtvZW4gJiM0Mzsgb3RoZXJzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhl IGNvbW1lbnRzIGFuZCB0aGUgdXBkYXRlLiBBIHF1ZXN0aW9uIHRvIHRoZSByZXN0IG9mIHRoZSBh dWRpZW5jZSwgZG9lcyB0aGUgcHJlc2VudGVkIHRleHQgZXhwbGFpbiBzdWZmaWNpZW50bHkgZW5v dWdoIGhvdyBFQ04gd29ya3Mgd2l0aCBjb25uZWN0aW9uIG1pZ3JhdGlvbiA/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVp Y3dnL2Jhc2UtZHJhZnRzL3dpa2kvRUNOLWluLVFVSUMjdHJhbnNwb3J0LWRyYWZ0LWNvbm5lY3Rp b24tbWlncmF0aW9uIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczovL2dpdGh1Yi5j b20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvRUNOLWluLVFVSUMjdHJhbnNwb3J0LWRyYWZ0LWNv bm5lY3Rpb24tbWlncmF0aW9uPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vSW5nZW1hcjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0 LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnAp IFttYWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tXQ0KPGJyPg0KPGI+ U2VudDo8L2I+IGRlbiAyIGZlYnJ1YXJpIDIwMTggMTU6NDQ8YnI+DQo8Yj5Ubzo8L2I+IGVraW5u ZWFyQGFwcGxlLmNvbTsgSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7aW5nZW1hci5zLmpvaGFuc3Nv bkBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBRVUlDIFdHICZsdDtxdWljQGlldGYu b3JnJmd0OzsgSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29nbGUuY29tJmd0OzsgTHViYXNoZXYs IElnb3IgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20mZ3Q7OyBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7 aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEVDTiBpbiBR VUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSBJbmdlbWFyLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFsc28gcmVhZCBh Z2FpbiB0aHJvdWdoIHRoZSBkb2N1bWVudCwgYW5kIGhhZCBmb2xsb3dpbmcgY29tbWVudHM6PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcmVwbGFjZWQ6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj7igJxUaGUgQUNLX0VDTiBmcmFtZSBpcyB1c2VkIHRvIGNvbnZleSBBQ0tz IHdoZW4gdGhlIEVDTiBjYXBhYmlsaXR5IGV4Y2hhbmdlIGNvbmNsdWRlcyB0aGF0IEVDTiBzaG91 bGQgYmUgdXNlZCBmb3IgdGhlIGdpdmVuIGNvbm5lY3Rpb24u4oCdPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PcmlnaW5hbGx5IGl0IHNvdW5kcyBhcyBpZiB0aGUgY291bnRl cnMgYXJlIG5vdCBlY2hvZWQgYW55bW9yZSBpZiB0aGUgRUNOIGNhcGFiaWxpdHkgY2hlY2sgZmFp bHMuIEkgYXNzdW1lIHRoaXMgd2FzIG5vdCB0aGUgaW50ZW50aW9uLCBidXQgaWYgaXQgaXM6IEZp cnN0LCB3ZSBkb27igJl0IGhhdmUgYSBwcm90b2NvbCBvciBkZWNpc2lvbiBwb2ludCBkZWZpbmVk IHdoZW4gdGhhdCBjb25kaXRpb24gaXMgbWV0IChzZW5kZXINCiBzaG91bGQgbGV0IHRoZSByZWNl aXZlciBrbm93IGluIHRoZSBuZXh0IHBhY2tldCksIGFuZCBzZWNvbmQsIEkgd291bGQgYWx3YXlz IHNlbmQgdGhlIGVjaG8sIGFzIHdlIG1pZ2h0IOKAnHRyeSBhZ2FpbiBsYXRlciAod2l0aCBhbm90 aGVyIEVDVD8p4oCdLCBvciBtaWdodCBkZWNpZGUgdG8gdXNlIHRoZSBFQ04gYml0cyBkaWZmZXJl bnRseSBsYXRlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbHNvIGNoYW5nZWQgdGhlIHRl eHQgYXJvdW5kIHRoZSBjb25uZWN0aW9uIG1pZ3JhdGlvbiwgSSB0aGluayBiZWZvcmUgRXJpYyBy ZXZpZXdlZCBpdC4gSSBtYWRlIGl0IHN1Y2ggdGhhdCBldmVyeSBuZXcgcGF0aCBjcmVhdGVzIGEg bmV3IGNvbm5lY3Rpb24gc3RhdGUgd2l0aCBhbiBpbml0aWFsaXplZCBjb25nZXN0aW9uIGNvbnRy b2wgc3RhdGUgYW5kIEVDTiBjb3VudGVycyAoYXQgbGVhc3QgRUNOIGNvdW50ZXJzDQogcmVzZXQg dG8gMHMpLiBOb3Qgc3VyZSBpZiB0aGlzIG1hdGNoZXMgd2l0aCB0aGUgb3RoZXIgc2VjdGlvbnMg aW4gdGhlIFFVSUMgZHJhZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBoYWQgdGhl IHRob3VnaHQgd2hldGhlciBpdCB3YXMgcmVhbGx5IG5lZWRlZCB0byBoYXZlIHRoZSAyIGNhc2Vz LiBJIGFncmVlIHdlIHNob3VsZCBzaW1wbGlmeSwgYnkganVzdCBzdGFydGluZyBvdmVyIGFuZCBk b2luZyB0aGUgY2hlY2sgdW5jb25kaXRpb25hbGx5IHdoZXRoZXIgaXQgd2FzIHN1Y2Nlc3NmdWwg b3Igbm90IGluIGEgcHJldmlvdXMgcGF0aC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktvZW4uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOmVraW5uZWFyQGFwcGxlLmNvbSI+ZWtpbm5lYXJAYXBwbGUuY29t PC9hPiBbPGEgaHJlZj0ibWFpbHRvOmVraW5uZWFyQGFwcGxlLmNvbSI+bWFpbHRvOmVraW5uZWFy QGFwcGxlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAyLCAy MDE4IDEyOjAyIEFNPGJyPg0KPGI+VG86PC9iPiBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDs8YSBo cmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20iPmluZ2VtYXIucy5q b2hhbnNzb25AZXJpY3Nzb24uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFFVSUMgV0cgJmx0 OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDs7IElh biBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iPmlhbnN3ZXR0 QGdvb2dsZS5jb208L2E+Jmd0OzsgTHViYXNoZXYsIElnb3IgJmx0OzxhIGhyZWY9Im1haWx0bzpp bHViYXNoZUBha2FtYWkuY29tIj5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZndDs7IENocmlzdGlh biBIdWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVt YUBodWl0ZW1hLm5ldDwvYT4mZ3Q7Ow0KIERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0Fu dHdlcnApICZsdDs8YSBocmVmPSJtYWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxh YnMuY29tIj5rb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb208L2E+Jmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogRUNOIGluIFFVSUMgY29ubmVjdGlvbiBtaWdyYXRpb248bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEluZ2VtYXIsJm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGdlbmVyYWxs eSBsb29rcyBnb29kIHRvIG1lITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QSBmZXcgcXVlc3Rpb25zIGFuZCBvYnNlcnZhdGlvbnM6Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5UaGVyZSBhcmUgdHdvIHVuaXF1ZSBjYXNlczo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw bGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+4oCi IEVDTiBjYXBhYmlsaXR5IGNoZWNrIHN1Y2Nlc3NmdWwgYXQgaW5pdGlhbCBjb25uZWN0aW9uIHNl dHVwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L3NwYW4+4oCiIEVDTiBjYXBhYmlsaXR5IGNoZWNrIGZhaWxlZCBhdCBpbml0aWFsIGNv bm5lY3Rpb24gc2V0dXA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgdGhlc2UgYWN0dWFsbHkgYW55IGRpZmZlcmVudCBpbiB0 ZXJtcyBvZiBhY3Rpb24gdGFrZW4gYnkgYW4gZW5kcG9pbnQ/PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyBsaWtlIG9uIHRoZSBuZXcg bmV0d29yayBwYXRoIHRoZSBlbmRwb2ludCB3b3VsZCBnbyB0aHJvdWdoIHRoZSBzYW1lIHByb2Nl c3Mgb2Y6IChhKSB2ZXJpZnkgRUNOIGNhcGFiaWxpdHkgYW5kIGlmIHN1Y2Nlc3NmdWwgdG8gd2hh dGV2ZXIgZGVncmVlIHRoZW4gKGIpIHJ1biB0aGUgcmVzdCBvZiB0aGUgRUNOIG1hY2hpbmVyeSBh cyBhcHByb3ByaWF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SW4gb3RoZXIgd29yZHMsIGFzIGxvbmcgYXMgeW91IGFsbG93IHBlb3BsZSB0 byBzdGFydCB1c2luZyBFQ04gdXBvbiBtaWdyYXRpb24gKGluIG90aGVyIHdvcmRzLCB0byBhbGxv dyBzdGFydGluZyBpdCBhZnRlciB0aGUgaW5pdGlhbCBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQp LCB0aGVuIHRoZSBzcGVjaWZpY3MgZm9yIEVDTiB3aXRoIG1pZ3JhdGlvbiBpcyBlc3NlbnRpYWxs eSBvbmUgc3RhdGVtZW50LCB3aGljaA0KIGlzIOKAnGRvIHRoZSBFQ04gcHJvY2VzcyBvbiBlYWNo IG5ldyBuZXR3b3JrIHBhdGggdGhhdCB5b3UgdXNl4oCdLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNvbm5lY3Rpb24gbWlncmF0 aW9uIGhhcyBpbXBhY3Qgb24gdGhlIG51bWJlciBvZiByZXBvcnRlZCBDRSBtYXJrZWQgcGFja2V0 cy4gQSBuZXcgY29ubmVjdGlvbiBzdGF0ZSB3aXRoIG5ldyBjb25nZXN0aW9uJm5ic3A7Y29udHJv bCBzdGF0ZSBhbmQgRUNOIGNvdW50ZXJzIGlzIGluc3RhbnRpYXRlZCBhdCB0aGUgc2VuZGVyIGFu ZCByZWNlaXZlci4gVGhlIEVDTiBjb3VudGVycyBNVVNUIHN0YXJ0IGZyb20gemVybyBhZ2Fpbi48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhp cyBzZWVtcyBmaW5lIHRvIG1lLCBpdOKAmXMgaW5saW5lIHdpdGggdGhlIHJlc3Qgb2YgdGhlIGNv bmdlc3Rpb24gY29udHJvbC9sb3NzIHJlY292ZXJ5IHN0YXRlIHRoYXQgYWxzbyBuZWVkcyB0byBi ZSByZXNldCBmb3IgdGhlIG5ldyBwYXRoLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HaXZlbiB0aGF0IGVhY2ggbWlncmF0aW9uIHJl cXVpcmVzIGF0IGxlYXN0IG9uZSBleGNoYW5nZSBvZiBwYWNrZXRzIGF0IHRoZSBiZWdpbm5pbmcg KGF0IHRoZSB2ZXJ5IGxlYXN0IGZvciBhZGRyZXNzIHZhbGlkYXRpb24gZnJvbSB0aGUgc2lkZSBv ZiB0aGUgZW5kcG9pbnQgdGhhdCBkaWRu4oCZdCBtaWdyYXRlKSwgaXQgc2VlbXMgbGlrZSB0aGF0 4oCZcyBhbiBleGNlbGxlbnQgbW9tZW50IHRvIG1hcmsgdGhlIHBhY2tldHMNCiBhbmQgcGVyZm9y bSB0aGUgRUNOIGNhcGFiaWxpdHkgZGV0ZWN0aW9uLiBUaG9zZSBwYWNrZXRzIGFyZSBhbHNvIGxp a2VseSBwYWRkZWQsIGV0Yy4gc2ltaWxhciB0byBpbml0aWFsIHBhY2tldHMgc2luY2UgdGhleeKA mXJlIG9uIGEgcHJldmlvdXNseSB1bnVzZWQgbmV0d29yayBwYXRoLiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZSBj dXJyZW50IHByb3Bvc2VkIHJlcXVpcmVtZW50IG9mIGp1c3QgdXNpbmcgdGhlIOKAnGZpcnN04oCd IHBhY2tldHMgYW5kIG1hcmtpbmcgdGhvc2UgaXMgc3VmZmljaWVudCAoYW5kIGdvb2QgdG8gYXZv aWQgYW55IHJlcXVpcmVtZW50IGFzIHRvIHdoaWNoIGZyYW1lcyBhcmUgY29udGFpbmVkIGluIHRo b3NlIHBhY2tldHMpLCBzaW5jZSB3ZSBhcmUgYWx3YXlzIGV4Y2hhbmdpbmcgcGFja2V0cyBpbg0K IGJvdGggZGlyZWN0aW9ucyBpbW1lZGlhdGVseSBhZnRlciBtaWdyYXRpb24uJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaGFz IHRoZSBhZGRlZCBiZW5lZml0IHN1Y2ggdGhhdCBhbnkgZW5kcG9pbnQg4oCccHJvYmluZ+KAnSBw b3NzaWJsZSBuZXR3b3JrIHBhdGhzIGNvdWxkIGluY2x1ZGUgdGhlIGJpdHMgbmVjZXNzYXJ5IHRv IGRldGVjdCBFQ04gY2FwYWJpbGl0eSBvbiB0aGUgcGF0aCBiZWluZyBwcm9iZWQsIHNvIGl0IGNv dWxkIGV2ZW4ga25vdyBiZWZvcmUgbWlncmF0aW5nIHdoZXRoZXIgb3Igbm90IGl0IHdvdWxkIGJl IGFibGUNCiB0byB1c2UgRUNOIG9uIHRoYXQgbmV3IHBhdGguJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVyaWM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAxLCAyMDE4LCBhdCAzOjA3IEFNLCBJbmdlbWFy IEpvaGFuc3NvbiBTICZsdDs8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb20iPmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHdyaXR0 ZW4gdXAgZGlmZmVyZW50IGFzcGVjdHMgb2YgY29ubmVjdGlvbiBtaWdyYXRpb24gYW5kIGhvdyBp dCBwbGF5cyB3aXRoIEVDTi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFm dHMvd2lraS9FQ04taW4tUVVJQyN0cmFuc3BvcnQtZHJhZnQtY29ubmVjdGlvbi1taWdyYXRpb24i PjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFz ZS1kcmFmdHMvd2lraS9FQ04taW4tUVVJQyN0cmFuc3BvcnQtZHJhZnQtY29ubmVjdGlvbi1taWdy YXRpb248L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BIGNhdmVhdC4uIEkgYW0gYSBiaXQgdW5zdXJlIGFib3V0IHRoZSBkZWZp bml0aW9uIG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uIC4gTXkgaW50ZXJwcmV0YXRpb24gaXMgdGhh dCBhIGNsaWVudCBtb3ZlcyB0byBhIG5ldyBJUCBhZGRyZXNzIGR1ZSB0byBlLmcuIGEgTkFUIHJl YmluZCBvciBzd2l0Y2ggZnJvbSBXaUZpIHRvIGNlbGx1bGFyLCByaWdodCA/LiBJcyBhIG5ldyBj b25uZWN0aW9uIGluc3RhbnRpYXRlZA0KIGF0IGEgY29ubmVjdGlvbiBtaWdyYXRpb24gPzxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4vSW5nZW1hcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPklu Z2VtYXIgSm9oYW5zc29uJm5ic3A7IE0uU2MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TWFzdGVyIFJlc2Vh cmNoZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Fcmljc3NvbiBS ZXNlYXJjaDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk5ldHdvcmsgUHJvdG9jb2xzICZhbXA7IEUyRSBQZXJm b3JtYW5jZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkxhYnJhdG9yaWVncsOkbmQgMTE8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj45NzEgMjgsIEx1bGXDpSwgU3dlZGVuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UGhvbmUgJiM0Mzs0 Ni0xMDcxIDQzMDQyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+U01TL01NUyAmIzQzOzQ2LTczIDA3OCAzMjg5 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOndpbmRvd3RleHQiPmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24u Y29tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9IngtbXNnOi8vMzE2L3d3dy5lcmljc3Nvbi5jb20iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6d2luZG93dGV4dCI+d3d3LmVyaWNzc29uLmNvbTwvc3Bhbj48L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2JhY2tncm91bmQ6I0NDQ0NERCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5k OndoaXRlIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgWW91IGNhbid0 IHN0YXJ0IGEgZmlyZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8c3BhbiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+Jm5ic3A7IFdvcnJ5aW5nICdib3V0IHlvdXIgbGl0dGxlIHdvcmxkIGZh bGxpbmcgYXBhcnQ8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtiYWNrZ3JvdW5kOndoaXRlIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQnJ1Y2UgU3ByaW5nc3RlZW48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+PGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_HE1PR0702MB36256D92C008302CBD908DE9C2F20HE1PR0702MB3625_-- From nobody Thu Feb 8 23:43:52 2018 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 4443C12741D for ; Thu, 8 Feb 2018 23:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 4Jk7e4x5Jd0I for ; Thu, 8 Feb 2018 23:43:48 -0800 (PST) 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 6EAB512420B for ; Thu, 8 Feb 2018 23:43:48 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id f89so8747891ioj.4 for ; Thu, 08 Feb 2018 23:43:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=oaubPKRBZduKc6iGBRZjSP+L192RwZaNZIz1zBSSc20=; b=WsmvwKZ5+NStTXYUB+fcP0Eaf8BTIWgyvxlOn3GRZ4T+cOv/IA7mTbl5EGAegMn9Uz PRao6lRFVjSJEUQPdz5qBlQh8WheTtmH72h9WQEs0qICssoEhkGI68oT7QrnIwfEqMco Ey4zLgDsynixX4bBafWaMyCrcTEfE1ks1SIZ0Vu4Sg1mKbapXAs/+7nN5/WbvZNMmkGP AEp6L9eRgIoYC/AgFFu3/FUSwVH8/1utOtt98ZQkOt8pCV0A3/QRL9mdFh3RcqHQxyPU QWzO+w1MAsmzruz6M51xB2SxUvHtG0NZA8/hchWTMmtbcsFtWrM5Y+8ftPDxfI6+7Ohn jFCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=oaubPKRBZduKc6iGBRZjSP+L192RwZaNZIz1zBSSc20=; b=SySIXInCHfsL6gJUP83iCY8c/LdQobHHvGNwDafM+GXtxL8I5iC87mCCfxVahuhoDm flCp3KjMlA/z4CAHTSWuZhoRXbzmWkdUo6Dz/ersqIlLdYgsR3yIEKRoquyjjl8J/H+G UX0+gES7cI5fV8fd4d0olkushO8vaJMZLZsGAjJNo9PQBQKjAt93/tvG0FyfO5h+ecEt 4Q8UUnsTAzdQpagldN4F1RozZHMIr4L6L445vl/NAkNgHm3XKwtFloErMgAeRTH2Ao6L 0NWqnL974pHb3phrdGqGXDyNf6bG+/xZm7Y40LaXcaDCWHLaelWDG2eP2A1mnZsUlSZk zHOA== X-Gm-Message-State: APf1xPA6RPlrzhzzHGbIz+K1V8k1gwHqVCfflkTtZowIoAWC/pmYosU2 xxa5RPWlDBaWcpggl82F0x+OoIc2jnbqNQeSusg= X-Google-Smtp-Source: AH8x227np8pa+csqJ64H9kEWjadvGby6l3CWknrxc1CnN6Cat2R7ocGw4TaQw/N4tkBWF29+CR3AVBgyC5lBcQie93k= X-Received: by 10.107.34.199 with SMTP id i190mr2300048ioi.297.1518162227883; Thu, 08 Feb 2018 23:43:47 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 02:43:47 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 02:43:47 -0500 Message-ID: Subject: RE: Packet number encryption To: Praveen Balasubramanian , Mike Bishop , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="001a1140d9444e0bc40564c2b077" 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, 09 Feb 2018 07:43:50 -0000 --001a1140d9444e0bc40564c2b077 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Why does the peer=E2=80=99s PRNG matter? The peer uses a different PN space= . The jumps are completely determined by the sender as needed and its just to prevent ossification of assuming that nonce always increments by 1. Because linkability goes both ways. --001a1140d9444e0bc40564c2b077 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Why does the peer=E2=80=99s PRNG matter? The peer uses a di= fferent PN space. The jumps are completely determined by the sender as need= ed and its just to prevent ossification of assuming that nonce always incre= ments by 1.

Because linkability go= es both ways.

--001a1140d9444e0bc40564c2b077-- From nobody Thu Feb 8 23:50:37 2018 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 B7F041243F6 for ; Thu, 8 Feb 2018 23:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 Ld7vAXlZ5lap for ; Thu, 8 Feb 2018 23:50:35 -0800 (PST) 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 0860012420B for ; Thu, 8 Feb 2018 23:50:34 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id k131so9939147ith.4 for ; Thu, 08 Feb 2018 23:50:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=AuGg1rwnu1xOqRDm+26Ul1Y72aljnpmZ5R12OaPpFzA=; b=l26rtSaDQ3KZ22d2NqrGeVFzWrTgXNPpm743ei2rjO1guYB/1GIVsXmcSbp8UX+wm/ NujR4FkBTW0hGIVE4Tv2XeRk9tmFAQkCdYLfx9jdZreDM63kr9oyichs1XQjeCbT6IC1 ov3rGyGl0RbEQVvPuktf2HN5nWwf9RfkzpO2BfFaQ01l35m3CiB4fd8qNXLE/ApADbzg nuSPeul3/xuQqeXqzrKYuyypBoxZZGbHNr/Lths2wpKOy/67FkQjgvtKPNYYCTsPNnnj 9SXBqp9XmPt6mycw/Og0y9/6Xr0v3Qx4YXVtzgm8Gx35MlXuuAHQcTXWcpedcMf5Dch2 iZlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=AuGg1rwnu1xOqRDm+26Ul1Y72aljnpmZ5R12OaPpFzA=; b=R1sGcY+uu2jhuTsZkx+Agpnx3zav//LJo9XpdqxLT+ngg+70XxPZ/kD0Grf5BYoihF 3YcMqZ7FQRLKpjka4uAzhRwjE5JbLrNOmsRbr8peCWSTJu+AzNkbsjt03l89binO37Oh 9Y+mEBVDppMVXWRX3yBLvbPNXtzjkjaJo8ZqnY7YlhQh1RiHP946aQ5q577OCQcks6/2 0KghzrS++mH2wsIR3C2oNYSQjF+L+F6KWexez+VH6rdDKD03ADMsmq6rjOOX12pXIfEM OSul1DBhFdoNpnmsPy6/R/0hgsmbBoOfRfp2auMjaNWkOHJG63COQQgOgyfT7r8yG3RE PqZg== X-Gm-Message-State: APf1xPB3T2Zm809BqK/eHHlcn7qgimkr5Bcj5N0Y6xat6UFK4XfOqLPb WcLAtPkhErdoJ/CMcLbIYan95WD97JWEIJEJPLE= X-Google-Smtp-Source: AH8x226xgeJwfrYxgdiiKt7XkgJMgBaDjtTLUo573R4GE4mQJF8+jkF2RmaVC4gmA9CdfD5CbT+w/nR664u5Aiwlt+k= X-Received: by 10.36.73.24 with SMTP id z24mr2340284ita.91.1518162634251; Thu, 08 Feb 2018 23:50:34 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 02:50:33 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 02:50:33 -0500 Message-ID: Subject: RE: Packet number encryption To: Praveen Balasubramanian , Mike Bishop , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="001a113520ee86a2c10564c2c873" 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, 09 Feb 2018 07:50:37 -0000 --001a113520ee86a2c10564c2c873 Content-Type: text/plain; charset="UTF-8" On 9 February 2018 at 08.26.02, Praveen Balasubramanian (pravb@microsoft.com) wrote: If non-repeating nonce is needed with that probability then we will need much larger nonce since 10 Gbps+ rates are common in the datacenter. A nonce can simply be generated using PRNG. It is decided by the lifetime of the key, not the bandwidth. The lifetime is typically limited to about 2^32 bytes because AES-GCM says so though other ciphers could allow for more. The nonce can be generated by a PRNG, but incidentally a solid PRNG is often implemented by encrypting a counter, so we are back to square one, only now using more space and crypto. --001a113520ee86a2c10564c2c873 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 9 February 2018 a= t 08.26.02, Praveen Balasubramanian (pravb@microsoft.com) wrote:
=C2=A0If non-repeating nonce is needed wi= th that probability then we will need much larger nonce since 10 Gbps+ rate= s are common in the datacenter. A nonce can simply be generated using PRNG.= =C2=A0

It is decided by the lifetime of the key, not the bandwid= th. The lifetime is typically limited to about 2^32 bytes because AES-GCM s= ays so though other ciphers could allow for more.

The nonce can be ge= nerated by a PRNG, but incidentally a solid PRNG is often implemented by en= crypting a counter, so we are back to square one, only now using more space= and crypto.

--001a113520ee86a2c10564c2c873-- From nobody Fri Feb 9 00:25:11 2018 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 AD6A4126DEE for ; Fri, 9 Feb 2018 00:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 npN1Do5Jgn3G for ; Fri, 9 Feb 2018 00:25:08 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 B547012420B for ; Fri, 9 Feb 2018 00:25:08 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id i144so10022390ita.3 for ; Fri, 09 Feb 2018 00:25:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=YkDotoDvHp+7hzhsYzUCX/iOLPgqAVPCYZVlmhckhsU=; b=OwD9UMIqdCSkpinM0w+6p2JslbDbbY1hV+aq/Ozq7gllhswGQ7U410adW4XewisQIA 7r7/YKP/gYquWS4w25ePu+6LJi0f3t0rSD96Qfpm0Xt/i0wDwBxuaDPe90BJOC8dvKDb iXMdWUypTqjTFh0IYsG8oL6Qhu6Ab9pJeu9AnOiwXvhaaJpaKsxxhhPa2rRuBtSId9+6 ExdhgwtIbY7QCotHAAZrT8qwnxRYcDp3eRHl1+mkaHLm+0AFWhPwCHPt2OvKHLO74AZQ ULH/999nsj25I0cYDgeopda3I7lWUiivE52WH3hlI24dPZ0vAEnPbYU6USLhzr1V0d3a CcXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=YkDotoDvHp+7hzhsYzUCX/iOLPgqAVPCYZVlmhckhsU=; b=s0BFlaQXDb++Nvrpe+UbAweMnrokSBe9ll7zefdKGiMLG1c/dR5OYKcVQHNRvDWU/6 OLPM7SIbNNNnim+tf3pOSN9v/N/nEaN+/zY1Jj+mmzOdB+ftCDnHdmQKk9TUQjmCkQjO esSm4KkCtKIsVnqlpmlQyaHA3Pm5kS+Wn+p3ADMaqRF4mNwjeSDcUUQq6M1LUp6TeRlS JNwf2TwslZXA+doguDB50l2Is8dIdh//kyTlwtjnOSyQw7NyX1S/gi4HqGje4FASOR0/ pK8bPIWrl3R19m5DsGSmEZ1BXxLW4sXPQ/UizmGncGIwgudJ5umXeTWBD7BgHWSbaKm2 dzRg== X-Gm-Message-State: APf1xPDeSYYJVGq7+ja0dUmgxdESjSd2sjiSOYJy6sEaLDmgR02rJc5y z9RvBBU/AzAYHnTKj+5MTj+ix+y6o113J0siKTScaA== X-Google-Smtp-Source: AH8x2254HDc6FJ3T0EVC4UWyYl+xC3eD0/FPk6FfQWGH5n0jLKurYGkI+//HQh0kEvVvfJXpukSJalzG7/neotBxU/I= X-Received: by 10.36.10.207 with SMTP id 198mr2425673itw.42.1518164708108; Fri, 09 Feb 2018 00:25:08 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 03:25:07 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 03:25:07 -0500 Message-ID: Subject: RE: Packet number encryption To: Praveen Balasubramanian , Mike Bishop , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="001a1144b828232efc0564c344bd" 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, 09 Feb 2018 08:25:11 -0000 --001a1144b828232efc0564c344bd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The lifetime is typically limited to about 2^32 bytes because AES-GCM says so though There is a limit in bytes per packet as well, but I actually I meant to say 2^32 invocations, i.e. distinct packets and nonces based on NIST requirements, FWTW. IETF TLS requires IV=E2=80=99s (aka nonce) to be unique= whereas NIST allows for random IV but it must then use 96 bits and still not exceed 2^32 invocations. Since IETF does not permit reuse, that random construct is out, and it would also be using too much space. http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pd= f --001a1144b828232efc0564c344bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
The lifetime is typically limited to about 2^= 32 bytes because AES-GCM says so though=C2=A0

There is a limit i= n bytes per packet as well, but I actually I meant to say 2^32 invocations,= i.e. distinct packets and nonces based on NIST requirements, FWTW. IETF TL= S requires IV=E2=80=99s (aka nonce) to be unique whereas NIST allows for ra= ndom IV but it must then use 96 bits and still not exceed 2^32 invocations.=

Since IETF does not permit reuse, that random construct is out= , and it would also be using too much space.

http://nvl= pubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf

<= div> --001a1144b828232efc0564c344bd-- From nobody Fri Feb 9 01:34:37 2018 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 3B84B12420B for ; Fri, 9 Feb 2018 01:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 LPTH-_YPnc8h for ; Fri, 9 Feb 2018 01:34:33 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 C40B5120726 for ; Fri, 9 Feb 2018 01:34:33 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id q9so7171849oti.0 for ; Fri, 09 Feb 2018 01:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=QGeMn+Cz5M3Dg1wNfJThSpK0U+ra7I2I1g58M7AsqTo=; b=FLwJJkzf3gX5wEREmSQVKs3ZUnoi84LjJth573dqcRfLUJpwqx4ijyNaKOg7FBp6hP B6Ab4dWiP5ysPe2TU+40lMB7w5qWFML/fBrpbg6jspRwENmPRl1XofJEMi+2/Tg1BfRW Bd50eXdfQPNUZLyJ5HMrjwPdk+k4qZTElfNkpSqm4Ik/6RGUmGOiUo6Rm3WEEzFoNRm2 /3BJrJLNWPo6Y0Vl8K/BIoT2qDEpcaJqApBsMf7TNVNQ6FLOL27DxxsE/uNTRAcBgU5i RW1X3yvA0+36dzZ2JT4CkT61JGkjO58C55/DxyTDVm/WplVCIUHSzMEAmBH+XeiSQyKe 9p5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=QGeMn+Cz5M3Dg1wNfJThSpK0U+ra7I2I1g58M7AsqTo=; b=ZET7FWejI5li1cX8I+KVb5LN/qASrYSkcLiquTGUwhnQ2J2ZPcw2bvBx/yaC3cSZ7+ 8RB/fcmol8Sqnu4YgocrgTprtEYgP7E1PyOSu0Dqlgwcy0TCtDdOCF2W6LnuvKaUnweC UakJis0rCmqmkVEQ8X8utzfVcpMLE89UF032Q0W1TOYtormHGWuGW2prYEyF5Ckdoolh VzHDG3otnZFbJcmFkZxrWxF1JZLexz2u/1jTXVBHLlybG+kG1lPR2llSHvzthagIJ0C0 4Az+gWSrrk/EQsZpa6nfPAS8V2TMasNxmMclHKKXc0Bfa8zFNLXqavCYc0v/Nmstitv0 6y/A== X-Gm-Message-State: APf1xPCpF/v/ez09cXg2x7YHh/sSu/xmg2SyqSsncskx+0WCMPjfJuky BV/CaMvD5D75/v0206ZbT/DfPrb6 X-Google-Smtp-Source: AH8x226jl8qYWJn27Opm7uz4oRbHU1ta1XSlCU4gkQHLmYAU6QFVRGhuyrIGIp1EGAl35L5Uu97Axw== X-Received: by 10.157.81.82 with SMTP id u18mr1723949oti.210.1518168872983; Fri, 09 Feb 2018 01:34:32 -0800 (PST) Received: from Justins-MacBook-Pro.local ([103.65.40.65]) by smtp.gmail.com with ESMTPSA id 38sm1161353otq.0.2018.02.09.01.34.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Feb 2018 01:34:32 -0800 (PST) To: "quic@ietf.org" From: Lingmo Zhu Subject: Questions about Version Negotiation Concerning Possible Handshake Interruption Message-ID: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> Date: Fri, 9 Feb 2018 17:34:29 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 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: Fri, 09 Feb 2018 09:34:35 -0000 Hi I'm new to QUIC and not sure if that could be considered but for Version Negotiation with the same connection ID as Initial packet, client should choose an acceptable version from the list. What if spoofing from something like router happens? Should mitigations be considered, such as adding a delay for validated Version Negotiation handling so that following handshake packets could be received later and that fake Version Negotiation could be ignored? Such concerning is just come out from DNS hijacking which is partially similar, though for QUIC it would only interrupt the handshake. I'm not sure but it might be used by downgrade attack in the future. Of course I'm new to this field so my opinion would be wrong. Thanks. Lingmo Zhu From nobody Fri Feb 9 02:08:53 2018 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 0E041126CB6 for ; Fri, 9 Feb 2018 02:08:51 -0800 (PST) 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 506zDS9JAFHj for ; Fri, 9 Feb 2018 02:08:48 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 B563F127342 for ; Fri, 9 Feb 2018 02:08:48 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id l5so7237009otj.11 for ; Fri, 09 Feb 2018 02:08:48 -0800 (PST) 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=lt+rO+fRWymMz55xiuyJESmFlrPWgSl6neuiHKEDUP8=; b=iOsaBieTxraiZC51UpQFF7xrNUj8b9MWAjq06SpO3YdITq1U5d76WE7w9b95QWVPKK FXxeiOpb6fNGxV6QJqbwH7/NbMUnj2nr/gZRKetY508K19aYZok7OejG0f/eoBRx4yYA gD/OgYPEpmXG5+v0AAJFuJ82cbq3B/KPGOmq/IumBOKkj1SZhHBvXXWEh6emRtQKWOKj E92l/w5bOHxLLFhqaiOFIwZnT0ra0BdCggcGqzr3bMcC8rrX8T6WsUbL59pAf5HBS0KU 8glrezAnvtBpSDi6ZXDBtdll3NM9zJqA3T2bR6AEOooJgF3zuaZxfJd2Ft0NIGNt1B4m 32sw== 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=lt+rO+fRWymMz55xiuyJESmFlrPWgSl6neuiHKEDUP8=; b=nHWwYCCW4RPjHiVBfDvyBoFH80XwykJs4i2IIoOWm5dAhPpVksxA4T2MjwevjKQfyA 6u97GykI4Z2J0Or/Nz5QmeUIZ3UoGMByWGpML3Zt3MgaVVrfZdcSF1TfZTp0qPTlNALf TRpYZ4bNvBm2DPmVNi8ReSlQ97pwM5qntq1T5chg8boTxTLApVr+NzRBs4Rfc9zlX5VW JavvLfCLpKEjhogl1SD9eIWh/L8Rgf0hazWqz1zKrMfK0RJMoTj8cJXRIJWIembvDB8t COGO7eigzBzG66KQ93aoQcOUcKVYPXODy27cyLQMcRatOmyYVUoMSqp/y6NmZaZxtZ6D QGuw== X-Gm-Message-State: APf1xPC/ZVZwiFQa+5E/RnszQg8F6lnJgi51lCGJwQuxVNtUMKlDtVRn FXoCc/TMGf6fi+D+SiRmCsbcfYeA4A9c/7nh81JRsc+l X-Google-Smtp-Source: AH8x225U1QIbDZAjvFL3e+Jtuueh9adqqm5+mFndAE7NWQJMOnSGpJ1Wt/CEHSB6U9O64FWTjhX8Vm7Qx5mFDQ8DHSE= X-Received: by 10.157.50.132 with SMTP id u4mr1803374otb.133.1518170927714; Fri, 09 Feb 2018 02:08:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Fri, 9 Feb 2018 02:08:46 -0800 (PST) From: Martin Thomson Date: Fri, 9 Feb 2018 21:08:46 +1100 Message-ID: Subject: Review of QCRAM 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: Fri, 09 Feb 2018 10:08:51 -0000 I have implemented QCRAM and have a few things to comment on. My implementation is here: https://github.com/martinthomson/minhq/tree/master/hc This is my first attempt at go, so this took a little longer than it might have otherwise. Test coverage is still a little light, though go thinks that I have pretty good coverage. There's probably still a lot to go on the corner cases, but I think that I've done enough to get an idea for the complexity bump. I started by implementing HPACK, which is surprisingly easy if you don't care about being efficient. Though I knew that I was going to add QCRAM, I made only minimal design concessions when building HPACK. Building QCRAM on top of HPACK took at least 50% more than just doing HPACK (at a guess, HPACK took about 10-12 hours, QCRAM took closer to 20). Even though you can reuse Huffman coding and most of the primitives, retrofitting it was tricky. My lack of familiarity with go definitely contributed a lot to that, but I'd say that QCRAM is more difficult to implement than it seems in theory. I didn't implement QCRAM entirely as specified. There are a few things that I'll describe below that would make it either better or easier to implement (or both). # Separate Stream Roles There are actually three streams of data that are of interest, and there is no clarity about those streams. 1. I suggest that we use unidirectional streams in each direction for table updates. 2. A separate stream for acknowledgments ensures that the encoder can consume that separately to the decoder. 3. Request/response streams. I think that we all understand these. These can be separate from the hq control stream, and they should be. Rather than pick a specific stream number, we should add a header for these streams that will allow them to be identified clearly. If we do that, add strict rules about cardinality. # Define Framing More Clearly The definition of the framing that is used on the control stream is unclear. I assume that the intent is to use HEADERS frames, but I'm only really guessing. If you take my suggestion for separate framing, then you can use very different logic for the different streams. Honestly, the overhead of framing is excessive for anything but request/response streams. I found that framing on the control stream wasn't necessary at all. This might depend on implementation strategy, because it might be easier to collect a framed thing than it is to read until you are blocked, then pickle that state so that you can go back to something else. In my implementation I hold state on the stack, so it's pretty easy. Also, it should suffice to have just a stream of varints indicating acknowledgments. Duplicates can be used to acknowledge multiple header blocks on the same stream in order. # Split the Instruction Space Having to check that only certain instructions appear on different streams is annoying to implement and a waste of bits. Define two separate spaces. That should make things much simpler: there are exactly two instructions in each space then (leaving aside acknowledgments, which I will cover below). # Base in Every HEADERS Frame Base (the number of inserts in the table at the start of a header block) seems to be required for all HEADERS frames, including both table modification and request/response streams. But... # Base on the Table Update Stream You don't need base for table updates. It is more of a hazard than a help. It is easier if you treat indexing on the table update stream as in HPACK where each insert moves the reference point for the next insertion. # Remove BLOCKING The BLOCKING flag complicates the design unnecessarily. As a fixed overhead, pay the extra byte always. Furthermore, the table update stream will never need to use depends, so that further motivates having different instruction sets (and formats) for different streams. And you don't need it... # Base and the Static Table It is not explained at all that the base is applied to the dynamic table only. That is, index 1 is a straight index into the static table and that index 62 will use the current number of inserts and the base to determine the actual index into the dynamic table (this is the first table entry only when the number of table inserts and base are the same, if the base is smaller, then it will be further along the table). To be clear, my logic for finding entries is: if i == 0: error if i <= len(staticTable): return staticTable[i-1] delta = tableBase - base if delta < 0: error return dynamicTable[i - len(staticTable) - 1 + delta] # Remove Depends Depends is useless. I did not implement it. Base is sufficient. This follows from preferring to use the smallest value for base possible. Doing that also keeps table references as small as possible. (Because references are counted in the opposite direction to base, a larger base means larger references.) The cost is that you have to do a two pass check: the first to find the newest reference, the second to write out the header block. I find that it's basically necessary to do two passes anyway: on the first I write out the table updates, on the second I write the header block. During that phase you want to do lookups anyway, so you can save the largest base from that pass. Also, when you insert anything, that tends to set the base, so it's pretty easy overall. # Tracking ACKs is Harder Than It Seems There are multiple header blocks per stream, and ACKs only identify the stream. You can't just store a stream reference (or Request-ID) against each header block, you have to store a tuple of stream and header block index. This needs to be explained somewhere. I decided to externalize ACKs - the QCRAM encoder takes a generic blob as input when it encodes a header block and the same generic blob to acknowledge it. The caller then has to combine stream ID and header block index in a sensible fashion. # Acknowledge Dmitry So I don't forget... Dmitry did a lot of work on the design team. # Dynamic Table Overhead The draft has a TODO about overhead for each dynamic entry. I added a field to every entry that allows it to know its own position in the table, but that is a simplification/optimization, and you don't really need that. The other per-record overheads are all the same for the decoder, with a small increase to the fixed overhead. It's a little more state for an encoder, but that is mostly because of having to track usage. I don't think that we need to change from a 32 byte overhead. This decision could reduce code complexity in shared QCRAM/HPACK implementations (in my implementation it would). # Duplication Doesn't Need to Reference the Static Table Duplication only makes sense for dynamic entries and yet the index is (I assume), the normal table index. That is highly suboptimal. This is worse because the prefix is only 5 bits for this instruction (up to 62 values), which leads to the encoding taking an extra byte always. If you take my suggestion for separate instruction spaces, this is better, but still not as good as a direct index into the dynamic table, starting at 0. Better yet would be a reverse index, starting from the end of the table, because duplication often needs to refer to the end of the table. # Need Better Advice on Referencing strategy Referencing entries near the end of the table in a new header block is hazardous. If you just compress as you do in HPACK, you can end up pinning entries in the header table, making it impossible to add new entries. Thus, you have to stop referencing entries as they get nearer to the table capacity limit. In my implementation I added a threshold variable that governs my referencing strategy. A portion of the header table space is marked as being off-limits for header block usage. The encoder duplicates those entries if it wants to compress, but won't reference them. If the table is under pressure from the new header fields being added, then it should be able to advance by at least this amount every round trip. This is a simple strategy, and probably suboptimal in various ways, but it seems to work out. For instance, I continuously update the cutoff as entries are inserted, so that a header block might end up referencing things that get pushed into this space by later header fields. You can imagine more advanced techniques. For instance, you might tune this window automatically based on the rate that the header table grows. Because references in that window block eviction, it should be sized to the rate of *desired* growth in the header table over a round trip. Taking a running estimate of that desired growth and allowing a margin for variance could produce the right value. I haven't experimented with this. From nobody Fri Feb 9 02:10:30 2018 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 AB012127698 for ; Fri, 9 Feb 2018 02:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 9ZqLZr-JEtRs for ; Fri, 9 Feb 2018 02:10:27 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 61005127342 for ; Fri, 9 Feb 2018 02:10:27 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id i144so10304166ita.3 for ; Fri, 09 Feb 2018 02:10:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=I/R0061AMUFSbq4sZH5vbrVEVe/sBfJN7rqj6rGAzYo=; b=f2TgFNMBvl0X8j91DdX6tT7LpTRBkozWhKvSbNpjqEFlBwOL8Xd1dJAr2wIxKfgwbe 3RN4bcFRgYYe0gMir9aOs+csOyQBBCWWCZ1Li4z/KPC0vKiHx3PbPA8QgjF7GBj/DbBR pi+fX+HOZdt0kIgbEdQKIWvGXgGXF+Id52nFe6LSZ6FkRsS+tZw2wjcHCshNUYa9pweH qhbOFwKRfH3Js8dN09/XcTE72qhjMAREA6FjWzF9GRnonIZLFfktMPffOHWJ6khdcFhc EBZOGKdoiedzegciEaUYjSR+Vyqfy//aycbTsrzOWurbxnqeiKqlenDjZ1oFlGXM3/zM 7F+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=I/R0061AMUFSbq4sZH5vbrVEVe/sBfJN7rqj6rGAzYo=; b=TQAkLGfnoaKtGHZfxgBc2nx1FmobNSC6l5UWOYahlMRKyNbQ4EApk+qk08t+atNQ6s L7sLPMiT61nbjjhNDlHhwk1cIkY9RawSEo8nM2b8bhCPl3H2/DF8QIb0D7vAq4eU1Dny 4FZ6/uwcGK+P1JsBIUyfSXV34sjB7ju79eyAx9yoaFadMbL/fWY/9Fppu6/pY+EDKG9a 01U6RJDsCaSKa7GfAhBAMknWjrKdERzFLFHP4OjJOFarErsysOE73cIigpUoAyIc5F+S DW3uQ+7PzuO6xJUt2bp2Am6sO4y9BByoLiTC4tzl6owTFooZfMNAd33T1pm4g6XJDRuf SjkQ== X-Gm-Message-State: APf1xPCXDlFcAQvgALFZwoMfWjmseGuYQkzp+3gCxcdJDIRBrnX2uS8H EXCEgND74NEe4ds6XEWbyqj1aCG1TFs5aR2lXLM= X-Google-Smtp-Source: AH8x226ucIA9kg1iPhuuOqTRkqQWhMwcX9w28uotYX/k4OUIE2urWGp/35bSsaMO72obBofUHnQuZhIVW+CfB/CAYBg= X-Received: by 10.36.73.24 with SMTP id z24mr2726608ita.91.1518171026768; Fri, 09 Feb 2018 02:10:26 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 05:10:25 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 05:10:25 -0500 Message-ID: Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: Lingmo Zhu , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a113520eec24a150564c4bced" 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, 09 Feb 2018 10:10:30 -0000 --001a113520eec24a150564c4bced Content-Type: text/plain; charset="UTF-8" > What if spoofing from something like router happens? There are integrity checks in place to protect against false packets: https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#version-validation A false version negotiation packet could also just confuse and interrupt an existing handshake, but this can also happen in other ways including handling of retry packets. The general consensus seems to be that you cannot really prevent on path attacks that wants to disrupt a handshake. I believe more could be done to prevent off-path attacks, but the spec changes frequently in this area. For example, if a stateless retry packet does not reflect the clients connection ID, a third party could send a retry packet which might not be accepted but could still cause a lot of confusion, and it would be an off path attack to the extend the receivers port and address can be guessed. --001a113520eec24a150564c4bced Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = >=C2=A0What = if spoofing from=C2=A0something like router h= appens?

There are integrity checks in=C2= =A0place to=C2=A0protect against false packets:

A false version neg= otiation packet could also just confuse and interrupt an existing handshake= , but this can also happen in other ways including handling of retry packet= s. The general consensus seems to be that you cannot really prevent on path= attacks that wants to disrupt a handshake. I believe more could be done to= prevent off-path attacks, but the spec changes frequently in this area. Fo= r example, if a stateless retry packet does not reflect the clients connect= ion ID, a third party could send a retry packet which might not be accepted= but could still cause a lot of confusion, and it would be an off path atta= ck to the extend the receivers port and address can be guessed.
= --001a113520eec24a150564c4bced-- From nobody Fri Feb 9 02:11:12 2018 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 D330A127342 for ; Fri, 9 Feb 2018 02:11:10 -0800 (PST) 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 5vX_EBx7d9as for ; Fri, 9 Feb 2018 02:11:09 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 8B71E126CB6 for ; Fri, 9 Feb 2018 02:11:09 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id f18so7247640otf.6 for ; Fri, 09 Feb 2018 02:11:09 -0800 (PST) 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=TRSr/+eF98ET0YWumd84J2j5M2ZQqyF+p6L/R0FRjLE=; b=PxDNB0MaT6tv6I1PIDZznCQo9RGKHriXfkEzJIQPcIuaPTDy0ABg0AOIcz4HjhEsXU 5TeJvdFVMoj5EiECddLhMV/pti6B9SLxedUgifueLPXEl+PTnuF4qtXuNt8H2wzL9PTJ bkujZwobqXQW83VGebu8D7DoL4RcKjTwMYsGckMQSUvlW9Pfmxm0OUyxurxYRKJoTeMQ GlEzPvCV03pYpMoDlnj3AiLZtqXJJIHVkDJQ4tZP0YL4B4LfBFUbJbY40/CXPrkvapRV QFHrr2tsCpHKFh01uh2BpGbkHINGAJcgPF4e0CXWh3vG1BKa2HZ5k8QUjpkK7n5Vom0m qgog== 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=TRSr/+eF98ET0YWumd84J2j5M2ZQqyF+p6L/R0FRjLE=; b=UlwfB1uMbWB+V81FaHQvmBnLHbNwyhaHVIFHhyy0Qqq29xyUR6jEQev9nGJ+f8y7PT PuYt0rsrFBJssvPcfrllrxo2BIozCdwP674BiZ0Qibk4ncLL7O+Vcc/xDOKTCa3o3PP/ Sc+9wPri/rB298ECQ54BwgEdCG2jmkfkViZ20C0KNQhLENHqn3f2JDAyD8MHNhrlTOMs PbXlE9B6N8oUY094YTNhBF+nMFr9XJHKj/WOl/Va4Qf/j+LnTNIkGJRqmDgoI0GXqDIB dyU9ZjU47ayOZBkyqLCqF0HOpDRFQeCGkOaUBAT3KIdRtx9QfblMBu91LR3P0AQRCBf9 ndgQ== X-Gm-Message-State: APf1xPDKfMdhJo1YHRavjXYlVcuIkTHKD9BRzD1H03lMJPI1Bxeke7FN Bg7xFRbtBxZySGgOMRhOAeUinHwoND+r0fSuyDQ= X-Google-Smtp-Source: AH8x226kmZ0tNxFtUTCanKG4z4m/RPkXrj/HgQmZFms5lPp3vKk9dQiXxnlaBTW3fs42p3rKEq0l3YVaa8KWFMM8ZFU= X-Received: by 10.157.46.206 with SMTP id w72mr1833586ota.16.1518171068877; Fri, 09 Feb 2018 02:11:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Fri, 9 Feb 2018 02:11:08 -0800 (PST) In-Reply-To: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> From: Martin Thomson Date: Fri, 9 Feb 2018 21:11:08 +1100 Message-ID: Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: Lingmo Zhu Cc: "quic@ietf.org" 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, 09 Feb 2018 10:11:11 -0000 Any spoofed version negotiation packet will be detected once the handshake completes: the server is required to include its list of supported versions in the TLS handshake. See the link Mikkel provided for details. On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu wrote: > Hi > > I'm new to QUIC and not sure if that could be considered but for Version > Negotiation with the same connection ID as Initial packet, client should > choose an acceptable version from the list. What if spoofing from something > like router happens? Should mitigations be considered, such as adding a > delay for validated Version Negotiation handling so that following handshake > packets could be received later and that fake Version Negotiation could be > ignored? > > Such concerning is just come out from DNS hijacking which is partially > similar, though for QUIC it would only interrupt the handshake. I'm not sure > but it might be used by downgrade attack in the future. Of course I'm new to > this field so my opinion would be wrong. > > Thanks. > > Lingmo Zhu > From nobody Fri Feb 9 02:22:55 2018 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 22811127775 for ; Fri, 9 Feb 2018 02:22:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 AvJgLxI1U9sS for ; Fri, 9 Feb 2018 02:22:52 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 866C012773A for ; Fri, 9 Feb 2018 02:22:52 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id b66so10328814itd.5 for ; Fri, 09 Feb 2018 02:22:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=oj9oyYKZYAiZ0SXnXbfsYqHeTKreCUk6ORGtQIaEFys=; b=cWDPMVFWbM6W7J6rnjpcYcXFDgqkZZUGinCc5xCWirS9XlZ1orAT8V8G+QokW6FGwn JKiIKIXxRdxwdjnGPJFh3/p2chLXc31I6L8KAHdk64uSRNaVeFywORk43PNn/+Ij/YM+ EFgrXqPX2MJKSvWT+zu11iLjxtHQU8sQ9l7/BROGPTHQ0ERROSMMB7oDY2lOObCF3B7W Anr4C7+Cgxa8U7oWzR2fK/K11sP1kG9rNlg8ISJ0RzecOicZGywKdwrxF+wCtGaOACo8 Reuq56y//Jt25MS9oBRJ3gb4sjfIQrzFSMF3eGvnSwEWuKcK2f5BskOJoD9vYDLC6S42 eMSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=oj9oyYKZYAiZ0SXnXbfsYqHeTKreCUk6ORGtQIaEFys=; b=jG5K4kTIoaVhoLtEQBPWXQVAWvCrKndeH1x/g9rg9SnyEOW0tOLiJRccvVEdyJoBNa XCMxOUUyOLwFb7BzyA4PRUVzmIx8yMCGpa8Ns5LmeiDgVeVKXj5PZxiFW5KHmn9hctoT aez6N7wxG5PHOEaZhfVxu/jcO4E/LUGI5TKu+cTU1IKnw/155jC/h7FXIYUGXxMJEW15 g3hrLjO4QDi4qNcGxB8FlzpjNn8hpr8Gh5BEw+Sv5Oq7PBRzhm/bMzBlizE2ucNgLZVj wU9qOUuZ/pAG8AoKeNaX3CPrVW2QXDIu+dc9w19HdjGAVsrgaEZJFR10OYLQe+s2symU tg8w== X-Gm-Message-State: APf1xPDxuvoSZcs2+SLFXo2jGWLKmQKC7dz/gEescy83YNq19qEPQva5 jPzTQEtziYoUa8BQuU8l15V3o+gd8vAHL0kugCA= X-Google-Smtp-Source: AH8x226ZLtZv/Jj1KtKB7hKVp8rkoCNizW3C5S5UogbMxd6DV9SKl+24F1dmPQn64pIwxnAe+aUGMBAlmI6Vy6fRaMk= X-Received: by 10.36.178.26 with SMTP id u26mr2731418ite.4.1518171771904; Fri, 09 Feb 2018 02:22:51 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 05:22:51 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 05:22:51 -0500 Message-ID: Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: Martin Thomson , Lingmo Zhu Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="f403045d914c2c26170564c4e9ab" 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, 09 Feb 2018 10:22:54 -0000 --f403045d914c2c26170564c4e9ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A possible attack scenario: A server cluster accepts version X and version Y, and sends {X, Y} in VNEG message if it sees any other requested version. Except: the cluster also accepts version X_old to deal with hard to upgrade baby alarms. It never announces X_old in VNEG but it will accept it if proposed by the client. Middleware now tries to inject X_old in version negotiation to convince the client to use that version in instead of version X the client would normally use. If VNEG wins the handshake race, X_old is now triggered. But the cluster knows that it would never have proposed X_old so if the client does verify properly, the handshake should fail. What I=E2=80=99m not sure about is if the current logic actually supports a= case were X_old is accepted if volunteered, but never when negotiated. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 February 2018 at 11.11.13, Martin Thomson (martin.thomson@gmail.com) wrote: Any spoofed version negotiation packet will be detected once the handshake completes: the server is required to include its list of supported versions in the TLS handshake. See the link Mikkel provided for details. On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu wrote: > Hi > > I'm new to QUIC and not sure if that could be considered but for Version > Negotiation with the same connection ID as Initial packet, client should > choose an acceptable version from the list. What if spoofing from something > like router happens? Should mitigations be considered, such as adding a > delay for validated Version Negotiation handling so that following handshake > packets could be received later and that fake Version Negotiation could be > ignored? > > Such concerning is just come out from DNS hijacking which is partially > similar, though for QUIC it would only interrupt the handshake. I'm not sure > but it might be used by downgrade attack in the future. Of course I'm new to > this field so my opinion would be wrong. > > Thanks. > > Lingmo Zhu > --f403045d914c2c26170564c4e9ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = A possible attack sc= enario:

<= /div>
A server clus= ter accepts version X and version Y, and sends {X, Y} in VNEG message if it= sees any other requested version.
Except: the cluster also accepts version X_old to de= al with hard to upgrade baby alarms. It never announces X_old in VNEG but i= t will accept it if proposed by the client.

Middleware now tries to inject X_old in version nego= tiation to convince the client to use that version in instead of version X = the client would normally use. If VNEG wins the handshake race, X_old is no= w triggered.
=
But the = cluster knows that it would never have proposed X_old so if the client does= verify properly, the handshake should fail.

What I=E2=80=99m not sure about is if the current l= ogic actually supports a case were X_old is accepted if volunteered, but ne= ver when negotiated.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

=

On 9 February 2018 at 11.11.13, Martin Thomson = (martin.thomson@gmail.com) = wrote:

Any spoofed version negotiation packet will be detected once the
handshake completes: the server is required to include its list of
supported versions in the TLS handshake. See the link Mikkel provided
for details.

On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu <zlm2006@gmail.com> wrote:
> Hi
>
> I'm new to QUIC and not sure if that could be considered but f= or Version
> Negotiation with the same connection ID as Initial packet, client = should
> choose an acceptable version from the list. What if spoofing from = something
> like router happens? Should mitigations be considered, such as add= ing a
> delay for validated Version Negotiation handling so that following= handshake
> packets could be received later and that fake Version Negotiation = could be
> ignored?
>
> Such concerning is just come out from DNS hijacking which is parti= ally
> similar, though for QUIC it would only interrupt the handshake. I&= #39;m not sure
> but it might be used by downgrade attack in the future. Of course = I'm new to
> this field so my opinion would be wrong.
>
> Thanks.
>
> Lingmo Zhu
>

--f403045d914c2c26170564c4e9ab-- From nobody Fri Feb 9 02:51:13 2018 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 0DFBD126BF0 for ; Fri, 9 Feb 2018 02:51:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 n8V2Fg7dAXcm for ; Fri, 9 Feb 2018 02:51:08 -0800 (PST) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 342B4126D0C for ; Fri, 9 Feb 2018 02:51:08 -0800 (PST) Received: from BGB01XI1012.national.core.bbc.co.uk (bgb01xi1012.national.core.bbc.co.uk [10.161.14.16]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w19Ap56f010308; Fri, 9 Feb 2018 10:51:05 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1012.national.core.bbc.co.uk ([10.161.14.16]) with mapi id 14.03.0361.001; Fri, 9 Feb 2018 10:51:05 +0000 From: Lucas Pardue To: Martin Thomson , QUIC WG Subject: RE: Review of QCRAM Thread-Topic: Review of QCRAM Thread-Index: AQHToY6+4prgEKb1ZUaH/mQGX5+sVqOb4Nzw Date: Fri, 9 Feb 2018 10:51:05 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAD6C5A@bgb01xud1012> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23650.006 x-tm-as-result: No--23.080000-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 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: Fri, 09 Feb 2018 10:51:11 -0000 SGkgTWFydGluLA0KDQpWZXJ5IGludGVyZXN0aW5nLCB0aGFua3MuDQoNCkdpdmVuIHRoYXQgeW91 ciBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyBib3RoIEhQQUNLIGFuZCBRQ1JBTSwgZG8geW91IGhh dmUgYW55IG9waW5pb24gaG93IG11Y2ggcGFpbiBpdCB3b3VsZCBiZSB0byBoYXZlIGRpZmZlcmVu dCBzdGF0aWMgdGFibGVzIGJldHdlZW4gdGhlbT8NCg0KUmVnYXJkcw0KTHVjYXMNCg0KPiAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NCj4gU2VudDogMDkgRmVicnVh cnkgMjAxOCAxMDowOQ0KPiBUbzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NCj4gU3ViamVjdDog UmV2aWV3IG9mIFFDUkFNDQo+IA0KPiBJIGhhdmUgaW1wbGVtZW50ZWQgUUNSQU0gYW5kIGhhdmUg YSBmZXcgdGhpbmdzIHRvIGNvbW1lbnQgb24uDQo+IA0KPiBNeSBpbXBsZW1lbnRhdGlvbiBpcyBo ZXJlOg0KPiAgIGh0dHBzOi8vZ2l0aHViLmNvbS9tYXJ0aW50aG9tc29uL21pbmhxL3RyZWUvbWFz dGVyL2hjDQo+IA0KPiBUaGlzIGlzIG15IGZpcnN0IGF0dGVtcHQgYXQgZ28sIHNvIHRoaXMgdG9v ayBhIGxpdHRsZSBsb25nZXIgdGhhbiBpdCBtaWdodCBoYXZlDQo+IG90aGVyd2lzZS4gVGVzdCBj b3ZlcmFnZSBpcyBzdGlsbCBhIGxpdHRsZSBsaWdodCwgdGhvdWdoIGdvIHRoaW5rcyB0aGF0IEkg aGF2ZQ0KPiBwcmV0dHkgZ29vZCBjb3ZlcmFnZS4gVGhlcmUncyBwcm9iYWJseSBzdGlsbCBhIGxv dCB0byBnbyBvbiB0aGUgY29ybmVyIGNhc2VzLA0KPiBidXQgSSB0aGluayB0aGF0IEkndmUgZG9u ZSBlbm91Z2ggdG8gZ2V0IGFuIGlkZWEgZm9yIHRoZSBjb21wbGV4aXR5IGJ1bXAuDQo+IA0KPiBJ IHN0YXJ0ZWQgYnkgaW1wbGVtZW50aW5nIEhQQUNLLCB3aGljaCBpcyBzdXJwcmlzaW5nbHkgZWFz eSBpZiB5b3UgZG9uJ3QgY2FyZQ0KPiBhYm91dCBiZWluZyBlZmZpY2llbnQuIFRob3VnaCBJIGtu ZXcgdGhhdCBJIHdhcyBnb2luZyB0byBhZGQgUUNSQU0sIEkgbWFkZQ0KPiBvbmx5IG1pbmltYWwg ZGVzaWduIGNvbmNlc3Npb25zIHdoZW4gYnVpbGRpbmcgSFBBQ0suDQo+IA0KPiBCdWlsZGluZyBR Q1JBTSBvbiB0b3Agb2YgSFBBQ0sgdG9vayBhdCBsZWFzdCA1MCUgbW9yZSB0aGFuIGp1c3QgZG9p bmcNCj4gSFBBQ0sgKGF0IGEgZ3Vlc3MsIEhQQUNLIHRvb2sgYWJvdXQgMTAtMTIgaG91cnMsIFFD UkFNIHRvb2sgY2xvc2VyIHRvIDIwKS4NCj4gRXZlbiB0aG91Z2ggeW91IGNhbiByZXVzZSBIdWZm bWFuIGNvZGluZyBhbmQgbW9zdCBvZiB0aGUgcHJpbWl0aXZlcywNCj4gcmV0cm9maXR0aW5nIGl0 IHdhcyB0cmlja3kuIE15IGxhY2sgb2YgZmFtaWxpYXJpdHkgd2l0aCBnbyBkZWZpbml0ZWx5IGNv bnRyaWJ1dGVkIGENCj4gbG90IHRvIHRoYXQsIGJ1dCBJJ2Qgc2F5IHRoYXQgUUNSQU0gaXMgbW9y ZSBkaWZmaWN1bHQgdG8gaW1wbGVtZW50IHRoYW4gaXQNCj4gc2VlbXMgaW4gdGhlb3J5Lg0KPiAN Cj4gSSBkaWRuJ3QgaW1wbGVtZW50IFFDUkFNIGVudGlyZWx5IGFzIHNwZWNpZmllZC4gVGhlcmUg YXJlIGEgZmV3IHRoaW5ncyB0aGF0DQo+IEknbGwgZGVzY3JpYmUgYmVsb3cgdGhhdCB3b3VsZCBt YWtlIGl0IGVpdGhlciBiZXR0ZXIgb3IgZWFzaWVyIHRvIGltcGxlbWVudA0KPiAob3IgYm90aCku DQo+IA0KPiANCj4gIyBTZXBhcmF0ZSBTdHJlYW0gUm9sZXMNCj4gDQo+IFRoZXJlIGFyZSBhY3R1 YWxseSB0aHJlZSBzdHJlYW1zIG9mIGRhdGEgdGhhdCBhcmUgb2YgaW50ZXJlc3QsIGFuZCB0aGVy ZSBpcyBubw0KPiBjbGFyaXR5IGFib3V0IHRob3NlIHN0cmVhbXMuDQo+IA0KPiAxLiBJIHN1Z2dl c3QgdGhhdCB3ZSB1c2UgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBpbiBlYWNoIGRpcmVjdGlvbiBm b3IgdGFibGUNCj4gdXBkYXRlcy4NCj4gDQo+IDIuIEEgc2VwYXJhdGUgc3RyZWFtIGZvciBhY2tu b3dsZWRnbWVudHMgZW5zdXJlcyB0aGF0IHRoZSBlbmNvZGVyIGNhbg0KPiBjb25zdW1lIHRoYXQg c2VwYXJhdGVseSB0byB0aGUgZGVjb2Rlci4NCj4gDQo+IDMuIFJlcXVlc3QvcmVzcG9uc2Ugc3Ry ZWFtcy4gSSB0aGluayB0aGF0IHdlIGFsbCB1bmRlcnN0YW5kIHRoZXNlLg0KPiANCj4gVGhlc2Ug Y2FuIGJlIHNlcGFyYXRlIGZyb20gdGhlIGhxIGNvbnRyb2wgc3RyZWFtLCBhbmQgdGhleSBzaG91 bGQgYmUuDQo+IFJhdGhlciB0aGFuIHBpY2sgYSBzcGVjaWZpYyBzdHJlYW0gbnVtYmVyLCB3ZSBz aG91bGQgYWRkIGEgaGVhZGVyIGZvciB0aGVzZQ0KPiBzdHJlYW1zIHRoYXQgd2lsbCBhbGxvdyB0 aGVtIHRvIGJlIGlkZW50aWZpZWQgY2xlYXJseS4gSWYgd2UgZG8gdGhhdCwgYWRkIHN0cmljdA0K PiBydWxlcyBhYm91dCBjYXJkaW5hbGl0eS4NCj4gDQo+ICMgRGVmaW5lIEZyYW1pbmcgTW9yZSBD bGVhcmx5DQo+IA0KPiBUaGUgZGVmaW5pdGlvbiBvZiB0aGUgZnJhbWluZyB0aGF0IGlzIHVzZWQg b24gdGhlIGNvbnRyb2wgc3RyZWFtIGlzIHVuY2xlYXIuIEkNCj4gYXNzdW1lIHRoYXQgdGhlIGlu dGVudCBpcyB0byB1c2UgSEVBREVSUyBmcmFtZXMsIGJ1dCBJJ20gb25seSByZWFsbHkNCj4gZ3Vl c3NpbmcuDQo+IElmIHlvdSB0YWtlIG15IHN1Z2dlc3Rpb24gZm9yIHNlcGFyYXRlIGZyYW1pbmcs IHRoZW4geW91IGNhbiB1c2UgdmVyeQ0KPiBkaWZmZXJlbnQgbG9naWMgZm9yIHRoZSBkaWZmZXJl bnQgc3RyZWFtcy4NCj4gDQo+IEhvbmVzdGx5LCB0aGUgb3ZlcmhlYWQgb2YgZnJhbWluZyBpcyBl eGNlc3NpdmUgZm9yIGFueXRoaW5nIGJ1dA0KPiByZXF1ZXN0L3Jlc3BvbnNlIHN0cmVhbXMuIEkg Zm91bmQgdGhhdCBmcmFtaW5nIG9uIHRoZSBjb250cm9sIHN0cmVhbSB3YXNuJ3QNCj4gbmVjZXNz YXJ5IGF0IGFsbC4gVGhpcyBtaWdodCBkZXBlbmQgb24gaW1wbGVtZW50YXRpb24gc3RyYXRlZ3ks IGJlY2F1c2UgaXQNCj4gbWlnaHQgYmUgZWFzaWVyIHRvIGNvbGxlY3QgYSBmcmFtZWQgdGhpbmcg dGhhbiBpdCBpcyB0byByZWFkIHVudGlsIHlvdSBhcmUNCj4gYmxvY2tlZCwgdGhlbiBwaWNrbGUg dGhhdCBzdGF0ZSBzbyB0aGF0IHlvdSBjYW4gZ28gYmFjayB0byBzb21ldGhpbmcgZWxzZS4gSW4N Cj4gbXkgaW1wbGVtZW50YXRpb24gSSBob2xkIHN0YXRlIG9uIHRoZSBzdGFjaywgc28gaXQncyBw cmV0dHkgZWFzeS4NCj4gDQo+IEFsc28sIGl0IHNob3VsZCBzdWZmaWNlIHRvIGhhdmUganVzdCBh IHN0cmVhbSBvZiB2YXJpbnRzIGluZGljYXRpbmcNCj4gYWNrbm93bGVkZ21lbnRzLiBEdXBsaWNh dGVzIGNhbiBiZSB1c2VkIHRvIGFja25vd2xlZGdlIG11bHRpcGxlIGhlYWRlcg0KPiBibG9ja3Mg b24gdGhlIHNhbWUgc3RyZWFtIGluIG9yZGVyLg0KPiANCj4gIyBTcGxpdCB0aGUgSW5zdHJ1Y3Rp b24gU3BhY2UNCj4gDQo+IEhhdmluZyB0byBjaGVjayB0aGF0IG9ubHkgY2VydGFpbiBpbnN0cnVj dGlvbnMgYXBwZWFyIG9uIGRpZmZlcmVudCBzdHJlYW1zIGlzDQo+IGFubm95aW5nIHRvIGltcGxl bWVudCBhbmQgYSB3YXN0ZSBvZiBiaXRzLiBEZWZpbmUgdHdvIHNlcGFyYXRlIHNwYWNlcy4gVGhh dA0KPiBzaG91bGQgbWFrZSB0aGluZ3MgbXVjaCBzaW1wbGVyOiB0aGVyZSBhcmUgZXhhY3RseSB0 d28gaW5zdHJ1Y3Rpb25zIGluIGVhY2gNCj4gc3BhY2UgdGhlbiAobGVhdmluZyBhc2lkZSBhY2tu b3dsZWRnbWVudHMsIHdoaWNoIEkgd2lsbCBjb3ZlciBiZWxvdykuDQo+IA0KPiAjIEJhc2UgaW4g RXZlcnkgSEVBREVSUyBGcmFtZQ0KPiANCj4gQmFzZSAodGhlIG51bWJlciBvZiBpbnNlcnRzIGlu IHRoZSB0YWJsZSBhdCB0aGUgc3RhcnQgb2YgYSBoZWFkZXIgYmxvY2spIHNlZW1zDQo+IHRvIGJl IHJlcXVpcmVkIGZvciBhbGwgSEVBREVSUyBmcmFtZXMsIGluY2x1ZGluZyBib3RoIHRhYmxlIG1v ZGlmaWNhdGlvbiBhbmQNCj4gcmVxdWVzdC9yZXNwb25zZSBzdHJlYW1zLiAgQnV0Li4uDQo+IA0K PiAjIEJhc2Ugb24gdGhlIFRhYmxlIFVwZGF0ZSBTdHJlYW0NCj4gDQo+IFlvdSBkb24ndCBuZWVk IGJhc2UgZm9yIHRhYmxlIHVwZGF0ZXMuIEl0IGlzIG1vcmUgb2YgYSBoYXphcmQgdGhhbiBhIGhl bHAuIEl0IGlzDQo+IGVhc2llciBpZiB5b3UgdHJlYXQgaW5kZXhpbmcgb24gdGhlIHRhYmxlIHVw ZGF0ZSBzdHJlYW0gYXMgaW4gSFBBQ0sgd2hlcmUNCj4gZWFjaCBpbnNlcnQgbW92ZXMgdGhlIHJl ZmVyZW5jZSBwb2ludCBmb3IgdGhlIG5leHQgaW5zZXJ0aW9uLg0KPiANCj4gIyBSZW1vdmUgQkxP Q0tJTkcNCj4gDQo+IFRoZSBCTE9DS0lORyBmbGFnIGNvbXBsaWNhdGVzIHRoZSBkZXNpZ24gdW5u ZWNlc3NhcmlseS4gQXMgYSBmaXhlZA0KPiBvdmVyaGVhZCwgcGF5IHRoZSBleHRyYSBieXRlIGFs d2F5cy4gRnVydGhlcm1vcmUsIHRoZSB0YWJsZSB1cGRhdGUgc3RyZWFtDQo+IHdpbGwgbmV2ZXIg bmVlZCB0byB1c2UgZGVwZW5kcywgc28gdGhhdCBmdXJ0aGVyIG1vdGl2YXRlcyBoYXZpbmcgZGlm ZmVyZW50DQo+IGluc3RydWN0aW9uIHNldHMgKGFuZCBmb3JtYXRzKSBmb3IgZGlmZmVyZW50IHN0 cmVhbXMuICBBbmQgeW91IGRvbid0IG5lZWQgaXQuLi4NCj4gDQo+ICMgQmFzZSBhbmQgdGhlIFN0 YXRpYyBUYWJsZQ0KPiANCj4gSXQgaXMgbm90IGV4cGxhaW5lZCBhdCBhbGwgdGhhdCB0aGUgYmFz ZSBpcyBhcHBsaWVkIHRvIHRoZSBkeW5hbWljIHRhYmxlIG9ubHkuDQo+IFRoYXQgaXMsIGluZGV4 IDEgaXMgYSBzdHJhaWdodCBpbmRleCBpbnRvIHRoZSBzdGF0aWMgdGFibGUgYW5kIHRoYXQgaW5k ZXggNjIgd2lsbA0KPiB1c2UgdGhlIGN1cnJlbnQgbnVtYmVyIG9mIGluc2VydHMgYW5kIHRoZSBi YXNlIHRvIGRldGVybWluZSB0aGUgYWN0dWFsDQo+IGluZGV4IGludG8gdGhlIGR5bmFtaWMgdGFi bGUgKHRoaXMgaXMgdGhlIGZpcnN0IHRhYmxlIGVudHJ5IG9ubHkgd2hlbiB0aGUNCj4gbnVtYmVy IG9mIHRhYmxlIGluc2VydHMgYW5kIGJhc2UgYXJlIHRoZSBzYW1lLCBpZiB0aGUgYmFzZSBpcyBz bWFsbGVyLCB0aGVuIGl0DQo+IHdpbGwgYmUgZnVydGhlciBhbG9uZyB0aGUgdGFibGUpLg0KPiAN Cj4gVG8gYmUgY2xlYXIsIG15IGxvZ2ljIGZvciBmaW5kaW5nIGVudHJpZXMgaXM6DQo+IA0KPiAg ICAgaWYgaSA9PSAwOiBlcnJvcg0KPiAgICAgaWYgaSA8PSBsZW4oc3RhdGljVGFibGUpOiByZXR1 cm4gc3RhdGljVGFibGVbaS0xXQ0KPiAgICAgZGVsdGEgPSB0YWJsZUJhc2UgLSBiYXNlDQo+ICAg ICBpZiBkZWx0YSA8IDA6IGVycm9yDQo+ICAgICByZXR1cm4gZHluYW1pY1RhYmxlW2kgLSBsZW4o c3RhdGljVGFibGUpIC0gMSArIGRlbHRhXQ0KPiANCj4gIyBSZW1vdmUgRGVwZW5kcw0KPiANCj4g RGVwZW5kcyBpcyB1c2VsZXNzLiBJIGRpZCBub3QgaW1wbGVtZW50IGl0LiBCYXNlIGlzIHN1ZmZp Y2llbnQuDQo+IA0KPiBUaGlzIGZvbGxvd3MgZnJvbSBwcmVmZXJyaW5nIHRvIHVzZSB0aGUgc21h bGxlc3QgdmFsdWUgZm9yIGJhc2UgcG9zc2libGUuDQo+IERvaW5nIHRoYXQgYWxzbyBrZWVwcyB0 YWJsZSByZWZlcmVuY2VzIGFzIHNtYWxsIGFzIHBvc3NpYmxlLiAoQmVjYXVzZQ0KPiByZWZlcmVu Y2VzIGFyZSBjb3VudGVkIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24gdG8gYmFzZSwgYSBsYXJn ZXIgYmFzZQ0KPiBtZWFucyBsYXJnZXINCj4gcmVmZXJlbmNlcy4pDQo+IA0KPiBUaGUgY29zdCBp cyB0aGF0IHlvdSBoYXZlIHRvIGRvIGEgdHdvIHBhc3MgY2hlY2s6IHRoZSBmaXJzdCB0byBmaW5k IHRoZSBuZXdlc3QNCj4gcmVmZXJlbmNlLCB0aGUgc2Vjb25kIHRvIHdyaXRlIG91dCB0aGUgaGVh ZGVyIGJsb2NrLiBJIGZpbmQgdGhhdCBpdCdzIGJhc2ljYWxseQ0KPiBuZWNlc3NhcnkgdG8gZG8g dHdvIHBhc3NlcyBhbnl3YXk6IG9uIHRoZSBmaXJzdCBJIHdyaXRlIG91dCB0aGUgdGFibGUNCj4g dXBkYXRlcywgb24gdGhlIHNlY29uZCBJIHdyaXRlIHRoZSBoZWFkZXIgYmxvY2suIER1cmluZyB0 aGF0IHBoYXNlIHlvdSB3YW50DQo+IHRvIGRvIGxvb2t1cHMgYW55d2F5LCBzbyB5b3UgY2FuIHNh dmUgdGhlIGxhcmdlc3QgYmFzZSBmcm9tIHRoYXQgcGFzcy4gQWxzbywNCj4gd2hlbiB5b3UgaW5z ZXJ0IGFueXRoaW5nLCB0aGF0IHRlbmRzIHRvIHNldCB0aGUgYmFzZSwgc28gaXQncyBwcmV0dHkg ZWFzeQ0KPiBvdmVyYWxsLg0KPiANCj4gIyBUcmFja2luZyBBQ0tzIGlzIEhhcmRlciBUaGFuIEl0 IFNlZW1zDQo+IA0KPiBUaGVyZSBhcmUgbXVsdGlwbGUgaGVhZGVyIGJsb2NrcyBwZXIgc3RyZWFt LCBhbmQgQUNLcyBvbmx5IGlkZW50aWZ5IHRoZQ0KPiBzdHJlYW0uDQo+IFlvdSBjYW4ndCBqdXN0 IHN0b3JlIGEgc3RyZWFtIHJlZmVyZW5jZSAob3IgUmVxdWVzdC1JRCkgYWdhaW5zdCBlYWNoIGhl YWRlcg0KPiBibG9jaywgeW91IGhhdmUgdG8gc3RvcmUgYSB0dXBsZSBvZiBzdHJlYW0gYW5kIGhl YWRlciBibG9jayBpbmRleC4gVGhpcyBuZWVkcw0KPiB0byBiZSBleHBsYWluZWQgc29tZXdoZXJl Lg0KPiANCj4gSSBkZWNpZGVkIHRvIGV4dGVybmFsaXplIEFDS3MgLSB0aGUgUUNSQU0gZW5jb2Rl ciB0YWtlcyBhIGdlbmVyaWMgYmxvYiBhcw0KPiBpbnB1dCB3aGVuIGl0IGVuY29kZXMgYSBoZWFk ZXIgYmxvY2sgYW5kIHRoZSBzYW1lIGdlbmVyaWMgYmxvYiB0bw0KPiBhY2tub3dsZWRnZSBpdC4g VGhlIGNhbGxlciB0aGVuIGhhcyB0byBjb21iaW5lIHN0cmVhbSBJRCBhbmQgaGVhZGVyIGJsb2Nr DQo+IGluZGV4IGluIGEgc2Vuc2libGUgZmFzaGlvbi4NCj4gDQo+ICMgQWNrbm93bGVkZ2UgRG1p dHJ5DQo+IA0KPiBTbyBJIGRvbid0IGZvcmdldC4uLiBEbWl0cnkgZGlkIGEgbG90IG9mIHdvcmsg b24gdGhlIGRlc2lnbiB0ZWFtLg0KPiANCj4gIyBEeW5hbWljIFRhYmxlIE92ZXJoZWFkDQo+IA0K PiBUaGUgZHJhZnQgaGFzIGEgVE9ETyBhYm91dCBvdmVyaGVhZCBmb3IgZWFjaCBkeW5hbWljIGVu dHJ5LiBJIGFkZGVkIGEgZmllbGQNCj4gdG8gZXZlcnkgZW50cnkgdGhhdCBhbGxvd3MgaXQgdG8g a25vdyBpdHMgb3duIHBvc2l0aW9uIGluIHRoZSB0YWJsZSwgYnV0IHRoYXQgaXMgYQ0KPiBzaW1w bGlmaWNhdGlvbi9vcHRpbWl6YXRpb24sIGFuZCB5b3UgZG9uJ3QgcmVhbGx5IG5lZWQgdGhhdC4g VGhlIG90aGVyIHBlci0NCj4gcmVjb3JkIG92ZXJoZWFkcyBhcmUgYWxsIHRoZSBzYW1lIGZvciB0 aGUgZGVjb2Rlciwgd2l0aCBhIHNtYWxsIGluY3JlYXNlIHRvDQo+IHRoZSBmaXhlZCBvdmVyaGVh ZC4gSXQncyBhIGxpdHRsZSBtb3JlIHN0YXRlIGZvciBhbiBlbmNvZGVyLCBidXQgdGhhdCBpcyBt b3N0bHkNCj4gYmVjYXVzZSBvZiBoYXZpbmcgdG8gdHJhY2sgdXNhZ2UuDQo+IA0KPiBJIGRvbid0 IHRoaW5rIHRoYXQgd2UgbmVlZCB0byBjaGFuZ2UgZnJvbSBhIDMyIGJ5dGUgb3ZlcmhlYWQuIFRo aXMgZGVjaXNpb24NCj4gY291bGQgcmVkdWNlIGNvZGUgY29tcGxleGl0eSBpbiBzaGFyZWQgUUNS QU0vSFBBQ0sgaW1wbGVtZW50YXRpb25zIChpbg0KPiBteSBpbXBsZW1lbnRhdGlvbiBpdCB3b3Vs ZCkuDQo+IA0KPiAjIER1cGxpY2F0aW9uIERvZXNuJ3QgTmVlZCB0byBSZWZlcmVuY2UgdGhlIFN0 YXRpYyBUYWJsZQ0KPiANCj4gRHVwbGljYXRpb24gb25seSBtYWtlcyBzZW5zZSBmb3IgZHluYW1p YyBlbnRyaWVzIGFuZCB5ZXQgdGhlIGluZGV4IGlzIChJDQo+IGFzc3VtZSksIHRoZSBub3JtYWwg dGFibGUgaW5kZXguIFRoYXQgaXMgaGlnaGx5IHN1Ym9wdGltYWwuIFRoaXMgaXMgd29yc2UNCj4g YmVjYXVzZSB0aGUgcHJlZml4IGlzIG9ubHkgNSBiaXRzIGZvciB0aGlzIGluc3RydWN0aW9uICh1 cCB0byA2MiB2YWx1ZXMpLCB3aGljaA0KPiBsZWFkcyB0byB0aGUgZW5jb2RpbmcgdGFraW5nIGFu IGV4dHJhIGJ5dGUgYWx3YXlzLiBJZiB5b3UgdGFrZSBteSBzdWdnZXN0aW9uDQo+IGZvciBzZXBh cmF0ZSBpbnN0cnVjdGlvbiBzcGFjZXMsIHRoaXMgaXMgYmV0dGVyLCBidXQgc3RpbGwgbm90IGFz IGdvb2QgYXMgYSBkaXJlY3QNCj4gaW5kZXggaW50byB0aGUgZHluYW1pYyB0YWJsZSwgc3RhcnRp bmcgYXQgMC4gQmV0dGVyIHlldCB3b3VsZCBiZSBhIHJldmVyc2UNCj4gaW5kZXgsIHN0YXJ0aW5n IGZyb20gdGhlIGVuZCBvZiB0aGUgdGFibGUsIGJlY2F1c2UgZHVwbGljYXRpb24gb2Z0ZW4gbmVl ZHMgdG8NCj4gcmVmZXIgdG8gdGhlIGVuZCBvZiB0aGUgdGFibGUuDQo+IA0KPiAjIE5lZWQgQmV0 dGVyIEFkdmljZSBvbiBSZWZlcmVuY2luZyBzdHJhdGVneQ0KPiANCj4gUmVmZXJlbmNpbmcgZW50 cmllcyBuZWFyIHRoZSBlbmQgb2YgdGhlIHRhYmxlIGluIGEgbmV3IGhlYWRlciBibG9jayBpcw0K PiBoYXphcmRvdXMuIElmIHlvdSBqdXN0IGNvbXByZXNzIGFzIHlvdSBkbyBpbiBIUEFDSywgeW91 IGNhbiBlbmQgdXAgcGlubmluZw0KPiBlbnRyaWVzIGluIHRoZSBoZWFkZXIgdGFibGUsIG1ha2lu ZyBpdCBpbXBvc3NpYmxlIHRvIGFkZCBuZXcgZW50cmllcy4gVGh1cywNCj4geW91IGhhdmUgdG8g c3RvcCByZWZlcmVuY2luZyBlbnRyaWVzIGFzIHRoZXkgZ2V0IG5lYXJlciB0byB0aGUgdGFibGUg Y2FwYWNpdHkNCj4gbGltaXQuDQo+IA0KPiBJbiBteSBpbXBsZW1lbnRhdGlvbiBJIGFkZGVkIGEg dGhyZXNob2xkIHZhcmlhYmxlIHRoYXQgZ292ZXJucyBteQ0KPiByZWZlcmVuY2luZyBzdHJhdGVn eS4gQSBwb3J0aW9uIG9mIHRoZSBoZWFkZXIgdGFibGUgc3BhY2UgaXMgbWFya2VkIGFzIGJlaW5n DQo+IG9mZi1saW1pdHMgZm9yIGhlYWRlciBibG9jayB1c2FnZS4gVGhlIGVuY29kZXIgZHVwbGlj YXRlcyB0aG9zZSBlbnRyaWVzIGlmIGl0DQo+IHdhbnRzIHRvIGNvbXByZXNzLCBidXQgd29uJ3Qg cmVmZXJlbmNlIHRoZW0uIElmIHRoZSB0YWJsZSBpcyB1bmRlciBwcmVzc3VyZQ0KPiBmcm9tIHRo ZSBuZXcgaGVhZGVyIGZpZWxkcyBiZWluZyBhZGRlZCwgdGhlbiBpdCBzaG91bGQgYmUgYWJsZSB0 byBhZHZhbmNlDQo+IGJ5IGF0IGxlYXN0IHRoaXMgYW1vdW50IGV2ZXJ5IHJvdW5kIHRyaXAuDQo+ IA0KPiBUaGlzIGlzIGEgc2ltcGxlIHN0cmF0ZWd5LCBhbmQgcHJvYmFibHkgc3Vib3B0aW1hbCBp biB2YXJpb3VzIHdheXMsIGJ1dCBpdA0KPiBzZWVtcyB0byB3b3JrIG91dC4gRm9yIGluc3RhbmNl LCBJIGNvbnRpbnVvdXNseSB1cGRhdGUgdGhlIGN1dG9mZiBhcyBlbnRyaWVzDQo+IGFyZSBpbnNl cnRlZCwgc28gdGhhdCBhIGhlYWRlciBibG9jayBtaWdodCBlbmQgdXAgcmVmZXJlbmNpbmcgdGhp bmdzIHRoYXQgZ2V0DQo+IHB1c2hlZCBpbnRvIHRoaXMgc3BhY2UgYnkgbGF0ZXIgaGVhZGVyIGZp ZWxkcy4NCj4gDQo+IFlvdSBjYW4gaW1hZ2luZSBtb3JlIGFkdmFuY2VkIHRlY2huaXF1ZXMuIEZv ciBpbnN0YW5jZSwgeW91IG1pZ2h0IHR1bmUNCj4gdGhpcyB3aW5kb3cgYXV0b21hdGljYWxseSBi YXNlZCBvbiB0aGUgcmF0ZSB0aGF0IHRoZSBoZWFkZXIgdGFibGUgZ3Jvd3MuDQo+IEJlY2F1c2Ug cmVmZXJlbmNlcyBpbiB0aGF0IHdpbmRvdyBibG9jayBldmljdGlvbiwgaXQgc2hvdWxkIGJlIHNp emVkIHRvIHRoZQ0KPiByYXRlIG9mDQo+ICpkZXNpcmVkKiBncm93dGggaW4gdGhlIGhlYWRlciB0 YWJsZSBvdmVyIGEgcm91bmQgdHJpcC4gVGFraW5nIGEgcnVubmluZw0KPiBlc3RpbWF0ZSBvZiB0 aGF0IGRlc2lyZWQgZ3Jvd3RoIGFuZCBhbGxvd2luZyBhIG1hcmdpbiBmb3IgdmFyaWFuY2UgY291 bGQNCj4gcHJvZHVjZSB0aGUgcmlnaHQgdmFsdWUuIEkgaGF2ZW4ndCBleHBlcmltZW50ZWQgd2l0 aCB0aGlzLg0KDQo= From nobody Fri Feb 9 03:19:53 2018 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 211EA126D0C for ; Fri, 9 Feb 2018 03:19:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 ah8rjOh64TwW for ; Fri, 9 Feb 2018 03:19:50 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 3008E1200C1 for ; Fri, 9 Feb 2018 03:19:50 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id o13so10497437ito.2 for ; Fri, 09 Feb 2018 03:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ytDpyNHo7W6GtWhCdNN2chcO0uSRZCUyRpcebvopMns=; b=YbnGJfLLG2np4hDnyZrD7t1Kx8f/7ivlZdP4kc/iRpCzyJKK+dtO0J2dsuiXW3Idtk XMWFwqwcbCAxDzIbo9Mctf62ex9rvBlwda1+vKt4XNp/vz8XJ27LqQd2v+hre8uPpQAG BlucI87/Ymfdc3rRK/Z779Exc8GIyFHfMmISV+5CUgYgbcNlJuC2aGEqQF5hRin1FV2I wKOP4L7ANxA9gGwNk5LHI+M7pO0DxOH2lNzkmJF53czvC3wGnEh8ueLJHxsyR+tLWYx8 jvbTxTQCbrXaW8Neo187mTpTcoV5Zo1/49rgRUCrBusvKiN8uyaOobU7Xb9Y9I1KEhKZ S/FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ytDpyNHo7W6GtWhCdNN2chcO0uSRZCUyRpcebvopMns=; b=G4HuIGHj1wRwty/Y+XqXvGHoFONnOAsljb4VnTQnBQjz0UcQrxQQwjSZCffbSBAm8r rptSVf04agVH9l61w1K3X4Ykpi0dsszR7sJnAb+rUDwo/KT5KhSfQ1uX33jt7tLNI4P8 wZ4Dg2HUf7Mvtg3TWwtCOOCoPBkWOrJAtpngVwhEamdEqWREM1m2MWWbMsn2Ha9r2w2p LO4tdP6A57i9EJ6l+CtOU6JHG53oK0SQ4phOLRhD99s9ABZcndY7+aRwfLxxk+BQzMft 4qVoOfM++IR1fVetlF97f4fpzX56VwBCiL92735gbxGlv/sO+EfUD0C5eok4Tz74ylIY aSww== X-Gm-Message-State: APf1xPDsOIZVJny8NO/44qQQ1GLGZhxx6Rm48+0+3AApcpKHBZtoqQRz 43LWIO+Adg/JKnfjv+jbCyquvasmb3Y= X-Google-Smtp-Source: AH8x224AFXLu8guKJteSygSm+dzd0lS1cbuozbOo5T8hnGJExNGJjjhn1fkmcpk0ovF3EqIzd+PMnA== X-Received: by 10.36.125.8 with SMTP id b8mr2997973itc.149.1518175189391; Fri, 09 Feb 2018 03:19:49 -0800 (PST) Received: from Justins-MacBook-Pro.local ([103.65.40.65]) by smtp.gmail.com with ESMTPSA id b41sm2956293iod.30.2018.02.09.03.19.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Feb 2018 03:19:48 -0800 (PST) Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Martin Thomson Cc: "quic@ietf.org" References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> From: Lingmo Zhu Message-ID: <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> Date: Fri, 9 Feb 2018 19:19:45 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CE7773FF3340A993A48E7FF0" Content-Language: en-US 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, 09 Feb 2018 11:19:52 -0000 This is a multi-part message in MIME format. --------------CE7773FF3340A993A48E7FF0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you for the clarification. I admit that downgrade attack could be hard to imagine. In fact what I really concerned is some scenario like: The client accepts version set X and the server cluster accepts some versions in X, so handshake should go well. But middle box tries to send VNEG with a version list excluding X. If VNEG wins, handshake could be aborted. In that scenario, HTTP could fall back to TCP and be interrupted simply by RST. TBH I just hope QUIC could not be easily interrupted. I'm not sure if such corner case should be considered. On 2018/02/09 18:22, Mikkel Fahnøe Jørgensen wrote: > A possible attack scenario: > > A server cluster accepts version X and version Y, and sends {X, Y} in > VNEG message if it sees any other requested version. > Except: the cluster also accepts version X_old to deal with hard to > upgrade baby alarms. It never announces X_old in VNEG but it will > accept it if proposed by the client. > > Middleware now tries to inject X_old in version negotiation to > convince the client to use that version in instead of version X the > client would normally use. If VNEG wins the handshake race, X_old is > now triggered. > > But the cluster knows that it would never have proposed X_old so if > the client does verify properly, the handshake should fail. > > What I’m not sure about is if the current logic actually supports a > case were X_old is accepted if volunteered, but never when negotiated. > > > Kind Regards, > Mikkel Fahnøe Jørgensen > > > On 9 February 2018 at 11.11.13, Martin Thomson > (martin.thomson@gmail.com ) wrote: > >> Any spoofed version negotiation packet will be detected once the >> handshake completes: the server is required to include its list of >> supported versions in the TLS handshake. See the link Mikkel provided >> for details. >> >> On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu > > wrote: >> > Hi >> > >> > I'm new to QUIC and not sure if that could be considered but for >> Version >> > Negotiation with the same connection ID as Initial packet, client >> should >> > choose an acceptable version from the list. What if spoofing from >> something >> > like router happens? Should mitigations be considered, such as >> adding a >> > delay for validated Version Negotiation handling so that following >> handshake >> > packets could be received later and that fake Version Negotiation >> could be >> > ignored? >> > >> > Such concerning is just come out from DNS hijacking which is partially >> > similar, though for QUIC it would only interrupt the handshake. I'm >> not sure >> > but it might be used by downgrade attack in the future. Of course >> I'm new to >> > this field so my opinion would be wrong. >> > >> > Thanks. >> > >> > Lingmo Zhu >> > >> --------------CE7773FF3340A993A48E7FF0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thank you for the clarification. I admit that downgrade attack could be hard to imagine. In fact what I really concerned is some scenario like:

The client accepts version set X and the server cluster accepts some versions in X, so handshake should go well. But middle box tries to send VNEG with a version list excluding X. If VNEG wins, handshake could be aborted.

In that scenario, HTTP could fall back to TCP and be interrupted simply by RST. TBH I just hope QUIC could not be easily interrupted. I'm not sure if such corner case should be considered.


On 2018/02/09 18:22, Mikkel Fahnøe Jørgensen wrote:
A possible attack scenario:

A server cluster accepts version X and version Y, and sends {X, Y} in VNEG message if it sees any other requested version.
Except: the cluster also accepts version X_old to deal with hard to upgrade baby alarms. It never announces X_old in VNEG but it will accept it if proposed by the client.

Middleware now tries to inject X_old in version negotiation to convince the client to use that version in instead of version X the client would normally use. If VNEG wins the handshake race, X_old is now triggered.

But the cluster knows that it would never have proposed X_old so if the client does verify properly, the handshake should fail.

What I’m not sure about is if the current logic actually supports a case were X_old is accepted if volunteered, but never when negotiated.


Kind Regards,
Mikkel Fahnøe Jørgensen


On 9 February 2018 at 11.11.13, Martin Thomson (martin.thomson@gmail.com) wrote:

Any spoofed version negotiation packet will be detected once the
handshake completes: the server is required to include its list of
supported versions in the TLS handshake. See the link Mikkel provided
for details.

On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu <zlm2006@gmail.com> wrote:
> Hi
>
> I'm new to QUIC and not sure if that could be considered but for Version
> Negotiation with the same connection ID as Initial packet, client should
> choose an acceptable version from the list. What if spoofing from something
> like router happens? Should mitigations be considered, such as adding a
> delay for validated Version Negotiation handling so that following handshake
> packets could be received later and that fake Version Negotiation could be
> ignored?
>
> Such concerning is just come out from DNS hijacking which is partially
> similar, though for QUIC it would only interrupt the handshake. I'm not sure
> but it might be used by downgrade attack in the future. Of course I'm new to
> this field so my opinion would be wrong.
>
> Thanks.
>
> Lingmo Zhu
>


--------------CE7773FF3340A993A48E7FF0-- From nobody Fri Feb 9 03:23:14 2018 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 D3A7D126BF0 for ; Fri, 9 Feb 2018 03:23:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 aYBn3DZOSfUy for ; Fri, 9 Feb 2018 03:23:11 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 B807E1200C1 for ; Fri, 9 Feb 2018 03:23:11 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id k131so10511156ith.4 for ; Fri, 09 Feb 2018 03:23:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=jhgg41LvoFDgrF4ISbKy0WIPVA21UlBIqs6xSGl0q+g=; b=idz1vxgEd4Iw0Dd5DuDdf+xe3eCfWblMiWPTH9PcVaTSLRz78gfDgycPgB1jRjmkXf Eprhu+83JW6tQaKEkEIFedmDJ5zOfJQHEA6GzNQbYLc7i63fdIC5qVHvI9aH7cofwOtV LU17pO5Xb7tEAKDnt602+hyYAFGiJivdm+pguXb11X6GDf+k5ujWVQMv8sT6g2CKhUyv Lw8K8Leq849BDy+/bur/aufKIVbgF9yNKBBlIJO8Z2PNeJt48/e8SN8vNfDoAeYZBBAl +fWpWcs0ci68lgtcwZ1bLAmLaD+CAZKXekx1HgdJtunDPrjbPbraskLd7u3qEN3qK1yC 9mjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=jhgg41LvoFDgrF4ISbKy0WIPVA21UlBIqs6xSGl0q+g=; b=eQlUw6XfTjKEc77IjLsfjiAaltfwnNGDwLcd4d8+XUp4MSfQtkebWQL77hpo4NlXYp lv2nIDvHqAfRxEHOxmzmFDtPpzyZj3tH3PmOtgkDSpo7oUuVjR9KQs9hz+ou66je8Gn6 IAvu7dxwutWbtWMbQWxGKxMzQHbVG6OpbVGpKxr2ZduU8hSNJz6gZdzbWikqhLaUCmVh kfJ5Mk3PXfQi6/St9FKZNr0azH0WtDHjEEBnjssXZJNdW2lpNAIsrOTniv0x9Rh5Ykjk 1XsStyQ75P0sb6jMLWSAJrCcF1uJ04R97dHBsLzHGim5jnS/1AHAjR0TjKu9BS1CROCw 6Fhw== X-Gm-Message-State: APf1xPAhz1BASph06/6ycSqTdBtaf7AAFXkzc6an7MEvkj1VJ9ShMCnF CnVr/9VicLqMZgb/URJtiwNLa76issTh8/uEVFY= X-Google-Smtp-Source: AH8x2265mHBQThQSrupV5L3S6IYjfAz56xKPlDQ58fc3ss+U1XaHTLVJyA1XBhNzFZ2jd0TLjFanEo/ZZftUqDdSKt0= X-Received: by 10.36.178.26 with SMTP id u26mr2930692ite.4.1518175391077; Fri, 09 Feb 2018 03:23:11 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 06:23:10 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 06:23:10 -0500 Message-ID: Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: Martin Thomson , Lingmo Zhu Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="f403045d914ce45afe0564c5c01c" 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, 09 Feb 2018 11:23:14 -0000 --f403045d914ce45afe0564c5c01c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable For the TCP fallback case, this is higher level protocol specific. For HTTP/QUIC v1 I believe there is a requirement to not fall back to anything there is a requirement to below TLS 1.3. But it is a valid concern. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 February 2018 at 12.19.50, Lingmo Zhu (zlm2006@gmail.com) wrote: Thank you for the clarification. I admit that downgrade attack could be hard to imagine. In fact what I really concerned is some scenario like: The client accepts version set X and the server cluster accepts some versions in X, so handshake should go well. But middle box tries to send VNEG with a version list excluding X. If VNEG wins, handshake could be aborted. In that scenario, HTTP could fall back to TCP and be interrupted simply by RST. TBH I just hope QUIC could not be easily interrupted. I'm not sure if such corner case should be considered. On 2018/02/09 18:22, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: A possible attack scenario: A server cluster accepts version X and version Y, and sends {X, Y} in VNEG message if it sees any other requested version. Except: the cluster also accepts version X_old to deal with hard to upgrade baby alarms. It never announces X_old in VNEG but it will accept it if proposed by the client. Middleware now tries to inject X_old in version negotiation to convince the client to use that version in instead of version X the client would normally use. If VNEG wins the handshake race, X_old is now triggered. But the cluster knows that it would never have proposed X_old so if the client does verify properly, the handshake should fail. What I=E2=80=99m not sure about is if the current logic actually supports a= case were X_old is accepted if volunteered, but never when negotiated. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 February 2018 at 11.11.13, Martin Thomson (martin.thomson@gmail.com) wrote: Any spoofed version negotiation packet will be detected once the handshake completes: the server is required to include its list of supported versions in the TLS handshake. See the link Mikkel provided for details. On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu wrote: > Hi > > I'm new to QUIC and not sure if that could be considered but for Version > Negotiation with the same connection ID as Initial packet, client should > choose an acceptable version from the list. What if spoofing from something > like router happens? Should mitigations be considered, such as adding a > delay for validated Version Negotiation handling so that following handshake > packets could be received later and that fake Version Negotiation could b= e > ignored? > > Such concerning is just come out from DNS hijacking which is partially > similar, though for QUIC it would only interrupt the handshake. I'm not sure > but it might be used by downgrade attack in the future. Of course I'm new to > this field so my opinion would be wrong. > > Thanks. > > Lingmo Zhu > --f403045d914ce45afe0564c5c01c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = For the TCP fallback= case, this is higher level protocol specific. For HTTP/QUIC v1 I believe t= here is a requirement to not fall back to anything there is a requirement t= o below TLS 1.3.

But = it is a valid concern.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 9 February 2018 at 12.19.50, Lingmo Zhu (zlm2006@gmail.com) wrote:

<= div>

Thank you for the clarification. I admit that downgrade attack could be hard to imagine. In fact what I really concerned is some scenario like:

The client accepts version set X and the server cluster accepts some versions in X, so handshake should go well. But middle box tries to send VNEG with a version list excluding X. If VNEG wins, handshake could be aborted.

In that scenario, HTTP could fall back to TCP and be interrupted simply by RST. TBH I just hope QUIC could not be easily interrupted. I'm not sure if such corner case should be considered.


On 2018/02/09 18:22, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote:
A possible attack scenario:

A server cluster accepts version X and version Y, and sends {X, Y} in VNEG message if it sees any other requested version.
Except: the cluster also accepts version X_old to deal with hard to upgrade baby alarms. It never announces X_old in VNEG but it will accept it if proposed by the client.

Middleware now tries to inject X_old in version negotiation to convince the client to use that version in instead of version X the client would normally use. If VNEG wins the handshake race, X_old is now triggered.

But the cluster knows that it would never have proposed X_old so if the client does verify properly, the handshake should fail.

What I=E2=80=99m not sure about is if the current logic actually supports a case were X_old is accepted if volunteered, but never when negotiated.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 9 February 2018 at 11.11.13, Martin Thomson (martin.thomson@gmail.c= om) wrote:

Any spoofed version negotiation packet will be detected once the
handshake completes: the server is required to include its list of
supported versions in the TLS handshake. See the link Mikkel provided
for details.

On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu <zlm2006@gmail.com> wrote:
> Hi
>
> I'm new to QUIC and not sure if that could be considered but for Version
> Negotiation with the same connection ID as Initial packet, client should
> choose an acceptable version from the list. What if spoofing from something
> like router happens? Should mitigations be considered, such as adding a
> delay for validated Version Negotiation handling so that following handshake
> packets could be received later and that fake Version Negotiation could be
> ignored?
>
> Such concerning is just come out from DNS hijacking which is partially
> similar, though for QUIC it would only interrupt the handshake. I'm not sure
> but it might be used by downgrade attack in the future. Of course I'm new to
> this field so my opinion would be wrong.
>
> Thanks.
>
> Lingmo Zhu
>


--f403045d914ce45afe0564c5c01c-- From nobody Fri Feb 9 03:31:32 2018 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 5C141126BF6 for ; Fri, 9 Feb 2018 03:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 sHvpGxkajA9a for ; Fri, 9 Feb 2018 03:31:29 -0800 (PST) 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 A8965126BF0 for ; Fri, 9 Feb 2018 03:31:29 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id t4so2390183pgp.8 for ; Fri, 09 Feb 2018 03:31:29 -0800 (PST) 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=HdNEnrqcSOp5aR8G5Ma1dUn+SUH+dbEZ37NIZHXrb2c=; b=P/oEd1hQu3XfM1M+AcxyuM9DtijTg5vuLUaEbbfc4fVlvP8KUF0E7xFWSAc3n+XEV5 K27az8B9YDisK5ZPnqslpx4hLZnKW2JZV/NJbLfaiptOOu9RKBwhbpZTADPLRijMY/oe EW+aT2BubIWPzhWleBPwoPy55mC3hYMDrFfdi72Vfz0O3cWs5zOQBH6BgnDZrzHKVMeB kpXu5MOU4PXystQ6r2ac9vfdcRHaWpokWfhEtVFb6k2BG16nFWkB/f1Nv7N/5tqUGGrw UtbLKirDJbl6AZPSfcblwUP41moXCnCN6Ws+HSAP+AVUWCJeqphpERJBCrI6Ee27kpgW +xqg== 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=HdNEnrqcSOp5aR8G5Ma1dUn+SUH+dbEZ37NIZHXrb2c=; b=AmQOKUkpRDIfxAOdHE2Ehljfz3glkun8C6sK8NxdIaCX4Minpd18DGiTe7srDQAt1+ 40SjpmWQFWNSom1wjLKnU/zUNGu+n3+MUeALGsNjCPtr9oA8FlpmLb9nPW7uNze473o9 KssRI2o8FTXGdQo2SV3aqHihtL4UNlpwSySWMCD4Zzmma90/gghraa9has4HZ9ilIgvv S+avB2ugKjC2AP7SNioQgYEhWJynTPnYexSGmvDPXUNinZq3tQ8rUwYct34WLfkafmTb 4UPAXBMhPNkUgfX45SyJfrvcVZekFCcgiEi36L4TExkkRLsnGbgKP80fDqPbLiJ42KCS kw6Q== X-Gm-Message-State: APf1xPDhLl4+aGv1tx+bEHBixJgUaKCalRtsSyImts1uFhQY+SRBnYxr M7aJvKzjlyCB5ge8B8AaErCS9sMFqJBSE26gcMYASA== X-Google-Smtp-Source: AH8x224EMk7tQfDSdSjWvYT4DQ8PzILzbc8+XRxsC7w19IXYnSFc5OR92GYEFrCdexw1NPJ1Iwo3m65TFi3fA7hHi5Y= X-Received: by 10.99.124.66 with SMTP id l2mr2124555pgn.290.1518175889100; Fri, 09 Feb 2018 03:31:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Fri, 9 Feb 2018 03:31:28 -0800 (PST) In-Reply-To: <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> From: Kazuho Oku Date: Fri, 9 Feb 2018 20:31:28 +0900 Message-ID: Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: Lingmo Zhu Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Martin Thomson , "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: Fri, 09 Feb 2018 11:31:31 -0000 2018-02-09 20:19 GMT+09:00 Lingmo Zhu : > Thank you for the clarification. I admit that downgrade attack could be h= ard > to imagine. In fact what I really concerned is some scenario like: > > The client accepts version set X and the server cluster accepts some > versions in X, so handshake should go well. But middle box tries to send > VNEG with a version list excluding X. If VNEG wins, handshake could be > aborted. > > In that scenario, HTTP could fall back to TCP and be interrupted simply b= y > RST. TBH I just hope QUIC could not be easily interrupted. I'm not sure i= f > such corner case should be considered. I think that this is a valid concern. QUIC is tolerant to on-path attackers trying to reset the connection, once the handshake succeeds. We should spend reasonable effort to achieve tolerance during the handshake as well. Regarding how to fix the issue, I think the mitigation that Lingmo suggested in his first post makes sense (i.e. client waits for some time even after receiving a VERSION_NEGOTIATION packet). OTOH, I think that we have room for improving version negotiation. In TLS, client offers multiple versions and server selects one; therefore, the handshake finishes in minimal round-trips, which is good for performance and also gives less chance for on-path attacks to succeed. In QUIC, the server sends a list of versions and let the client send another unprotected packet. This is both waste of time and also is more prone to attacks, due to spending an extra round without protection. I think we should change the negotiation scheme so that the server can select the version to use. The hard part of making such change would be the fact that we need to decouple the TLS version and the QUIC version, though. > > > On 2018/02/09 18:22, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > > A possible attack scenario: > > A server cluster accepts version X and version Y, and sends {X, Y} in VNE= G > message if it sees any other requested version. > Except: the cluster also accepts version X_old to deal with hard to upgra= de > baby alarms. It never announces X_old in VNEG but it will accept it if > proposed by the client. > > Middleware now tries to inject X_old in version negotiation to convince t= he > client to use that version in instead of version X the client would norma= lly > use. If VNEG wins the handshake race, X_old is now triggered. > > But the cluster knows that it would never have proposed X_old so if the > client does verify properly, the handshake should fail. > > What I=E2=80=99m not sure about is if the current logic actually supports= a case > were X_old is accepted if volunteered, but never when negotiated. > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 9 February 2018 at 11.11.13, Martin Thomson (martin.thomson@gmail.com) > wrote: > > Any spoofed version negotiation packet will be detected once the > handshake completes: the server is required to include its list of > supported versions in the TLS handshake. See the link Mikkel provided > for details. > > On Fri, Feb 9, 2018 at 8:34 PM, Lingmo Zhu wrote: >> Hi >> >> I'm new to QUIC and not sure if that could be considered but for Version >> Negotiation with the same connection ID as Initial packet, client should >> choose an acceptable version from the list. What if spoofing from >> something >> like router happens? Should mitigations be considered, such as adding a >> delay for validated Version Negotiation handling so that following >> handshake >> packets could be received later and that fake Version Negotiation could = be >> ignored? >> >> Such concerning is just come out from DNS hijacking which is partially >> similar, though for QUIC it would only interrupt the handshake. I'm not >> sure >> but it might be used by downgrade attack in the future. Of course I'm ne= w >> to >> this field so my opinion would be wrong. >> >> Thanks. >> >> Lingmo Zhu >> > > --=20 Kazuho Oku From nobody Fri Feb 9 03:56:55 2018 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 79B4F126E01 for ; Fri, 9 Feb 2018 03:56:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 CtO0z37ThHws for ; Fri, 9 Feb 2018 03:56:53 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 D1362126BF0 for ; Fri, 9 Feb 2018 03:56:52 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id i144so10608299ita.3 for ; Fri, 09 Feb 2018 03:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=MAdaVyCKitDHPoyYLEm9O8RZ53uml4zTEJEDfA4zjBg=; b=EdOUcvaonI+iUIIZJrqnBRqzJ8aO+S43VpBH9Ctuvb71oG7NNmeYtbT7g0xpEbxcov CjsAaFpcjFVBu4/KQdZFaaAV371ppMgr1uaW9OmV14/Obv1xQ2Lz14qCc1FF8iLTtjHs Xy1+PyToa4hik64FJEHt3ckt4fQKKFyX4tZAOvt9yJ3wcUgv03V37BtI3PkmVTi6dc8Y kMKHq1kFks1DXFefeo19AGEnlCMkWwDrspNpTfyRBVXhzZgkuMoAnH6QgKAIqs9y6HuB 8ULbBUdzlGe2RQH8wOuBP7Nb7igugexHJ2w0ucRbe0Kwk2Hv3LZhrhCyZbjSa/BY+9np VO5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=MAdaVyCKitDHPoyYLEm9O8RZ53uml4zTEJEDfA4zjBg=; b=dqDz1IpNctMbcJPv76PUjPn7t5d3LiBXpvxRGo3eJ8Y4vuShklzZIsM+5HtX/4+jM4 x93bnEPCGT1n0L/lKiYzIZp4tmkSCHFD2nN1I9tqVFsld+U23/iqbXgMqEtXr4lInfIA XRyXZfR3hZcraMOKfNvqLfg6sjEDNkavKv8QqpUNUIt1MEjpsqoF3+vV56waqMU9sLBF R9SEzgqt7G/ZJfW+VD1dmcdR58QRJ1BTE9Odas98l6y9RvYXiU79/CENy1NqfraQFeKK du4mzl+ZVsFEdMQWmcpfE/aZOWNh6th6kWCe1RLpGJj3ckmPEjFCOsWo5PKVLUTqj8+s eFfQ== X-Gm-Message-State: APf1xPBMfApdUwjpFzyAYNxTRlW7Jh4yhsCqEQNvX/P6jA+7WRF6vhrA aaW7qk0BKJnVCG7wcan0YXpt2Xs/jLFw9/zAB7s= X-Google-Smtp-Source: AH8x224nzkGoL/FqABhY/J1LHYT5F4GZAIRuwpwKMkP/9w7YC9yH1z3VlCZR8pKI0q4/rst08LGYBfkaPGvJWBrdmIs= X-Received: by 10.36.10.207 with SMTP id 198mr3058854itw.42.1518177412180; Fri, 09 Feb 2018 03:56:52 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 06:56:51 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 06:56:51 -0500 Message-ID: Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: Lingmo Zhu , Kazuho Oku Cc: Martin Thomson , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a1144b8285bf0f20564c63989" 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, 09 Feb 2018 11:56:54 -0000 --001a1144b8285bf0f20564c63989 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A realistic on-path attack involves a government body that taps optic fiber at an internet distribution node. The original intention behind the construct may be to trigger an alarm whenever the string =E2=80=9Cdirty bom= b=E2=80=9D appears in a protocol RFC 821 message (such as this one), and subsequently for logging purposes to monitor traffic directed towards bulk fertiliser suppliers. It is not possible to drop packets both due to the mechanical construct, due to legislation, and because it might be too obvious. However, having a datacenter with optic fibre near said access point gives excellent insights into early handshakes including IP, port, connection ID, and possible even a profile of the PRNG being used at some endpoint. This makes it very simple to spoof and inject packets into handshake with a good chance of winning any race. More difficult, but possible, it could also observe packets and inject packets closer to the endpoint, for example using long distance point to point radio communication to race the ordinary packet stream. Any argument about friendly gov is void because the internet travels across multiple regions that each with near certainty have taps as those described above making it a prime target in cyber warfare. The question is then to what extend such a position can be utilised to interfere with the handshake and what the outcome of such interference would be, rather than a discussion of how plausible such an attack is, because it is probably a 99% given if feasible. --001a1144b8285bf0f20564c63989 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = A = realistic on-path attack involves a government body that taps optic fiber a= t an internet distribution node. The original intention behind the construc= t may be to trigger an alarm whenever the string =E2=80=9Cdirty bomb=E2=80= =9D appears in a protocol RFC 821 message (such as this one), and subsequen= tly for logging purposes to monitor traffic directed towards bulk fertilise= r suppliers. It is not possible to drop packets both due to the mechanical = construct, due to legislation, and because it might be too obvious. However= , having a datacenter with optic fibre near said access point gives excelle= nt insights into early handshakes including IP, port, connection ID, and po= ssible even a profile of the PRNG being used at some endpoint.

This makes it very simple to spoof and inject packets into handshake= with a good chance of winning any race. More difficult, but possible, it c= ould also observe packets and inject packets closer to the endpoint, for ex= ample using long distance point to point radio communication to race the or= dinary packet stream.

Any argument about friendly = gov is void because the internet travels across multiple regions that each = with near certainty have taps as those described above making it a prime ta= rget in cyber warfare.

The question is then to wha= t extend such a position can be utilised to interfere with the handshake an= d what the outcome of such interference would be, rather than a discussion = of how plausible such an attack is, because it is probably a 99% given if f= easible.
--001a1144b8285bf0f20564c63989-- From nobody Fri Feb 9 04:54:11 2018 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 BF35512778D for ; Fri, 9 Feb 2018 04:54:08 -0800 (PST) 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, 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 UT8CrrYQ9OtP for ; Fri, 9 Feb 2018 04:54:07 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 1922B127775 for ; Fri, 9 Feb 2018 04:54:07 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w19CqAW2023731; Fri, 9 Feb 2018 12:53:57 GMT 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=Htv+V8BGoIlsuA7D/RBN53QbZUPVBugqz4l55QM+SfU=; b=deIE1GH5NcRnLMdFiEW9yrQpOk/TqepyFP6y2WtrRfpah25BPqjHymHriXcdQCvqEamP +wT0Sy0iYkV4cKs/CCh7K8GPSXHO7OgEP9Exlqsi4T50+VGBZbIQA9vJd+G816WoIXZW Shw5TqkBe92y6zuAGoIuuBwtKMeYg4loAEW9LhW06EMe2VpZSk5t8fW2Id9+BZRx2k3N iCgbpEXmKxlkLK5wmsseXkEenePk0hAg9wm5CCjhAjEcqVfJh4hECV89uaHC8StuHbVD INaIgwFwgAaTrix2rpXhuE8iOHVL7JJqgDGFj9cT3twQXFuZJGm0d2h9zZyS9wbJLXar Fw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2g0x25j4ad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2018 12:53:57 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w19CkF6u006280; Fri, 9 Feb 2018 07:53:56 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fw9a18u02-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2018 07:53:56 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 9 Feb 2018 07:53:55 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 9 Feb 2018 07:53:55 -0500 From: "Salz, Rich" To: Praveen Balasubramanian , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Mike Bishop" , "quic@ietf.org" , huitema Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31Be9MxlVQxEqrVhXIOG6b4KOM1RYAgABeoICAAAgVAIAAd3KAgAA8YgCAACPDAIAAAicAgAOBloCAALfcgIAACBoAgAEGFwCAANx+AIAAn5GAgAB7xICAADUigIAADBaAgADXOgCAAGaugIAAEEkAgACizACAADhiAIAAHkiAgAADUYCAACdEAIAAVRYAgAAUZgCAAA5oAIAAEIEAgABFkgCAAAUSgIAABUkAgAABmYCAAAaRgIAAC4qAgACi8ACAAe5ygIAACzgAgAAgsACAAEARAIAACvYAgAARiQCAAAEEAIAAW6iA Date: Fri, 9 Feb 2018 12:53:55 +0000 Message-ID: <84BA46ED-BA37-4B06-8902-B14D0C91B8EE@akamai.com> References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.235] Content-Type: multipart/alternative; boundary="_000_84BA46EDBA374B068902B14D0C91B8EEakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090165 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_07:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=947 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090166 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, 09 Feb 2018 12:54:09 -0000 --_000_84BA46EDBA374B068902B14D0C91B8EEakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q2FuIHlvdSBwbGVhc2UgZXhwbGFpbiB3aHkgeW91IHdhbnQgdGhlIHBhY2tldCBudW1iZXIgaW4g dGhlIGNsZWFyPyAgT3IgcG9zdCBhIGxpbmsgdG8gdGhlIGVtYWlsIGFyY2hpdmUgaWYgeW914oCZ dmUgYWxyZWFkeSBkb25lIHNvLiAgQmVjYXVzZSwgdG8gbXkgY2FzdWFsIG9ic2VydmVyIHZpZXdw b2ludCwgeW91IGFyZSB0cnlpbmcgZmFpcmx5IGhhcmQgdG8gZG8gdGhpcywgaW5jbHVkaW5nIHNv bWUgdG9ydHVyZWQvcXVlc3Rpb25hYmxlIGNyeXB0bzsgc28sIHdoeT8NCg0K --_000_84BA46EDBA374B068902B14D0C91B8EEakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1h cmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KcC5haXJtYWlsb24sIGxpLmFpcm1haWxvbiwgZGl2LmFpcm1haWxvbg0K CXttc28tc3R5bGUtbmFtZTphaXJtYWlsX29uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2lu LWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5 MjU1NjY2ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE0ODEwNjg3Njg7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC10 YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3MDE2MzQ2NzY7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0xMzg2MzE1NDcyO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21h cmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3 aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgcGxlYXNlIGV4 cGxhaW4gd2h5IHlvdSB3YW50IHRoZSBwYWNrZXQgbnVtYmVyIGluIHRoZSBjbGVhcj8mbmJzcDsg T3IgcG9zdCBhIGxpbmsgdG8gdGhlIGVtYWlsIGFyY2hpdmUgaWYgeW914oCZdmUgYWxyZWFkeSBk b25lIHNvLiZuYnNwOyBCZWNhdXNlLCB0byBteSBjYXN1YWwgb2JzZXJ2ZXIgdmlld3BvaW50LCB5 b3UgYXJlIHRyeWluZyBmYWlybHkgaGFyZCB0byBkbyB0aGlzLCBpbmNsdWRpbmcgc29tZSB0b3J0 dXJlZC9xdWVzdGlvbmFibGUNCiBjcnlwdG87IHNvLCB3aHk/PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_84BA46EDBA374B068902B14D0C91B8EEakamaicom_-- From nobody Fri Feb 9 05:34:26 2018 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 7F632129515 for ; Fri, 9 Feb 2018 05:34:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no 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 ccC06EKQr_qI for ; Fri, 9 Feb 2018 05:34:17 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002: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 08DB01289B0 for ; Fri, 9 Feb 2018 05:34:17 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id b16so5057937ywh.12 for ; Fri, 09 Feb 2018 05:34:17 -0800 (PST) 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=JaGN7iZIgY5Y4JRL0ofcQ3EaapuAydAUx/m3rNpBH+c=; b=WS35PdN3rca+hZ8A1hfbcVhdAAvlXoDvKdHp3s/UioEzYPUiA+ntqTIMvGB+DWKnp/ zokU9QK+ELzm2+xqAY3Cd7OCnjemM9rDbtHuhGz8HoSxBfOrkUqaJRcCQR4Cq7MrJKYs CFHaNVhp/AJFCnziufPKZr2JcL3eWSu94SoR72uE8mDUAGW42MkKpEbjY2Rk3uKgzZoH PK5ST/Z1b/ux5EDj8gQzBzuSAq0qPNRJGYujkdy/kOCZMvfO3xeBnnSDb7K6ZSzen1Pq 7hQa/7tRTsF9epDFSsUeX4IWVWo06QFgbxBDrMJUACaE4zeStqXawQolh77gnUnXSMLY M2FQ== 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=JaGN7iZIgY5Y4JRL0ofcQ3EaapuAydAUx/m3rNpBH+c=; b=qStIZ+WRZUsARx/2sc4wwa16/cLfjV+sxXNL97RtpNNNthMQ94XGZPuKse443s95Te hWcVagaCJXga2y/4XWBGJm0IWHTNFOdKDg/Mub112ogOSCZpuZYvHpi+9YvcAXkL26Om lsafA7vDBJ6tYfR/raWPBNYkXYfhc4hWaZYvZYHTE2xK0GEUxJANYpPH32DvD1gY55XO canzPcE7c6jDx1ECWbb2Top+6b6o7zhJzgF4T2ONEBbthh7T7+eYnCencaFYZiBNSaMp dsljSEwJ8kU6B9WAVczLvzPO9EwuS37T72s5HXXsWLm9nH/yd2aoCNtITGyStecjv224 W0sQ== X-Gm-Message-State: APf1xPB4fBDxK1xsJ2fROKMHP9nXhUfQZYRo1F7zfSlI/uDPLbnOfLYQ NHmInChlch7L56hqrG0f6mEalFCx8TEI0JFrFICByw== X-Google-Smtp-Source: AH8x227GLr5PUgMeaLLcwCD8ljNZ00qjRMWDYcdD4UJvH4rgk/d/mEIBte2ynvCmrjdBV3Y7BsGSdWkqFMFbq4sINr8= X-Received: by 10.129.39.213 with SMTP id n204mr792836ywn.5.1518183256080; Fri, 09 Feb 2018 05:34:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Fri, 9 Feb 2018 05:33:35 -0800 (PST) In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> From: Eric Rescorla Date: Fri, 9 Feb 2018 05:33:35 -0800 Message-ID: Subject: Re: Packet number encryption To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Praveen Balasubramanian , Mike Bishop , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="001a11413fc4aedbf00564c795a1" 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, 09 Feb 2018 13:34:24 -0000 --001a11413fc4aedbf00564c795a1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 8, 2018 at 11:22 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > You can=E2=80=99t safely reuse the combination of nonce and key, IIUC. S= ince key > rollover is infrequent, the nonce has to change every packet and be > guaranteed unique over the lifetime of, if not the connection, at least t= he > current key. > > For CTR mode encryption which AES-GCM is, it is extremely bad to reuse th= e > nonce. But it is still permitted if nonce only repeats with very low > probability, like 2^-32 or so, don=E2=80=99t recall. This means that usin= g a crypto > hashed packet numbers as a nonce is an option, but a homegrown obfuscatio= n > is not. > I'm not sure where you are getting this from. Any nonce reuse at all with AES-GCM is catastrophic: http://csrc.nist.gov/groups/ ST/toolkit/BCM/documents/comments/800-38_ Series-Drafts/GCM/Joux_comments.pdf -Ekr Mikkel > > On 9 February 2018 at 07.19.32, Mike Bishop (mbishop@evequefou.be) wrote: > > You can=E2=80=99t safely reuse the combination of nonce and key, IIUC. S= ince key > rollover is infrequent, the nonce has to change every packet and be > guaranteed unique over the lifetime of, if not the connection, at least t= he > current key. Since packet numbers also don=E2=80=99t repeat over the lif= etime of > the connection, I think using one as the variable part of the other was > just taking advantage of the alignment. > > > > I don=E2=80=99t think having a randomized starting value and incrementing= is > necessarily any better than exposing the packet number. Having a PRNG se= ed > established during the handshake and making the visible thing the next > random output seems potentially interesting, but I=E2=80=99d want our mor= e > crypto-minded friends to comment. I think the real issue would be > guarantees about never-repeating from the PRNG, particularly as you don= =E2=80=99t > have guarantees about your peer=E2=80=99s implementation. A defined key = derivation > and a counter can be verified in the protocol, independent of how good th= e > peer=E2=80=99s PRNG is. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen > Balasubramanian > *Sent:* Thursday, February 8, 2018 9:40 PM > *To:* huitema ; quic@ietf.org > *Subject:* RE: Packet number encryption > > > > Actually taking a step back what if we don=E2=80=99t we overloaded packet= number > as the nonce? > > > > Can we: > > 1. Put packet number as a separate variable length field in the > encrypted portion of the header. This allows for growth beyond 64 bits= in > future and completely avoids ossification. For short lived flows varia= ble > length encoding leads to minimal space overhead. > 2. Put a separate plaintext nonce which starts out as a secure random > number and monotonically increases as short random jumps (every packet= or > every few packets) and could then rollover. This will prevent linkabil= ity > and scales to multi-path as well. No major compute overhead. We can al= so > make the nonce optional for crypto algorithms that do not need a nonce > saving more space. > > > > Some MSB of the nonce could be used for signaling reorder to the network > if needed. I don=E2=80=99t have the historical context for overloading of= PN as the > nonce so pardon me if un-overloading option was discussed and ruled out > before. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Praveen Balasubramanian > *Sent:* Thursday, February 8, 2018 5:51 PM > *To:* huitema ; quic@ietf.org > *Subject:* RE: Packet number encryption > > > > >> and using separate packet sequences for each path > > This alone prevents linkability right? > > > > >> The packet number on each path will start at 1 (or maybe 0 ;-). > > Is supporting multiple paths at the same time a goal? If yes, then yes al= l > paths will need to have separate tracking and ACK state and congestion > control etc. I thought this is not part of V1 RFC. If its just one > additional path for connection migration scenario then all you need is a > (random) jump to a offset in packet number space for the new path so that > the few packets in the old path can continue for a little bit. This works > with just one ACK space so no implementation complexity. > > > > >> 2) Or, leaving the packet number in the clear but using different > encryption contexts for each path, and using separate packet sequences fo= r > each path. > In addition if the value in the clear was obfuscated with an XOR transfor= m > it will help prevent ossification. The obfuscation is not meant to guard > against later analysis that reveals the packet numbers - why do we care > about that. It is meant to grease the space and not make the numbers seri= al > so middleboxes cannot assume ordering etc. > > > > All said if I am alone in being concerned about the perf hit then I=E2=80= =99d say > go on with option 1. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Christian Huitema > *Sent:* Thursday, February 8, 2018 3:54 PM > *To:* quic@ietf.org > *Subject:* Re: Packet number encryption > > > > On 2/8/2018 1:13 PM, Mike Bishop wrote: > > #2 won=E2=80=99t work. The packet number is an input to the AEAD nonce, = so you > have to get to the packet number before you can decrypt the payload. It > can=E2=80=99t be based on anything internal to the encrypted packet. > > > > In Martin=E2=80=99s proposal, it=E2=80=99s using a combination of the enc= rypted payload > (which requires nothing to access) and some stored state on each endpoint= , > which requires only the Connection ID to look up. You want the thing you > XOR by to be constantly changing, or it becomes easier to look at sequenc= es > of obfuscated packet numbers and start drawing inferences about what the > XOR value is. If overhead is the primary concern, I think there are a > couple approaches that might allow you to precompute values and amortize > the cost of doing the encryption step. (At the cost of keeping the table > of precomputed values, of course.) > > > > I still think Jana=E2=80=99s pushing in the right direction here: Let=E2= =80=99s agree on > goals, and then see if we can craft a design that meets those goals. I > hear you saying that low overhead is a goal, which I think we can all agr= ee > on. I also think I hear you saying that 1-1.5% overhead is too high, but > it sounds like there=E2=80=99s less agreement on that. You also raise an > interesting point that some clients will care less about linkability > because they will never intentionally migrate. > > > I think Victor said it best, "Obfuscation is just encryption done poorly.= " > Either we encrypt, or we don't. But there is no such thing as an > obfuscation middle-ground. Obfuscation would just be a speed bump, easily > broken. It won't provide privacy, and it won't prevent linkability. > > As far as I am concerned, there are only two designs that prevent > linkability: > > 1) Martin's PR, in which the packet number is encrypted using sensible > crypto; > > 2) Or, leaving the packet number in the clear but using different > encryption contexts for each path, and using separate packet sequences fo= r > each path. > > The second option requires more computation when explicitly setting up a > new path. The connection ID would be used as part of the "salt" when > deriving connection contexts. The packet number on each path will start a= t > 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for > each path/Connection-ID, and constraining ACK to be per/path, or > alternatively adding a PATH-ACK frame that indicates the path for which > packets are acked. > > The pros and cons of the two options are easy to get: > > 1) Option 2 does not require the cost of encrypting every packet, thus pe= r > packet processing will be maybe 1% faster than option 1. > > 2) Option 2 requires computing encryption contexts for each path, which i= s > more complex than option 1, but the cost will be amortized over the > duration of the path. > > 3) Option 2 requires more complex data structures and ACK management, thu= s > increasing the chances that something goes wrong. > > 4) Option 2 does nothing against packet number ossification. The packet > number effectively becomes part of the invariants. > > In short, the only advantage of option 2 is to avoid a single symmetric > encryption operation per packet, while making the code significantly more > complex, and at the cost of not protecting against PN ossification. The w= ay > I see that, there is hardly any debate. > > -- Christian Huitema > > --001a11413fc4aedbf00564c795a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 8, 2018 at 11:22 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <m= ikkelfj@gmail.com> wrote:

You can=E2= =80=99t safely reuse the combination of nonce and key, IIUC.=C2=A0 Since ke= y rollover is infrequent, the nonce has to change every packet and be guara= nteed unique over the lifetime of, if not the connection, at least the curr= ent key.

For CTR mode encr= yption which AES-GCM is, it is extremely bad to reuse the nonce. But it is = still permitted if nonce only repeats with very low probability, like 2^-32= or so, don=E2=80=99t recall. This means that using a crypto hashed packet = numbers as a nonce is an option, but a homegrown obfuscation is not.
<= /blockquote>

I'm not sure where you are getting this= from. Any nonce reuse at all with AES-GCM is catastrophic:
http://csrc.nist.gov/groups/ ST/too= lkit/BCM/documents/comments/800-38_ Series-Drafts/GCM/Joux_comments.pdf

-Ekr

Mikkel

On 9 February 2018 at 07.19.32, Mike Bishop (mbishop@evequefou.be) wrote:

<= blockquote type=3D"cite" class=3D"gmail-m_-4603647876781282200clean_bq">

You can=E2=80=99t s= afely reuse the combination of nonce and key, IIUC.=C2=A0 Since key rollove= r is infrequent, the nonce has to change every packet and be guaranteed uni= que over the lifetime of, if not the connection, at least the current key.=C2=A0 Since packet numbers also don=E2=80=99t re= peat over the lifetime of the connection, I think using one as the variable= part of the other was just taking advantage of the alignment.

=C2=A0

I don=E2=80=99t thi= nk having a randomized starting value and incrementing is necessarily any b= etter than exposing the packet number.=C2=A0 Having a PRNG seed established= during the handshake and making the visible thing the next random output seems potentially interesting, but I=E2=80=99d want= our more crypto-minded friends to comment.=C2=A0 I think the real issue wo= uld be guarantees about never-repeating from the PRNG, particularly as you = don=E2=80=99t have guarantees about your peer=E2=80=99s implementation.=C2= =A0 A defined key derivation and a counter can be verified in the protocol, in= dependent of how good the peer=E2=80=99s PRNG is.

=C2=A0

From:= QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Thursday, February 8, 2018 9:40 PM
To: huitema <huitema@huitema.net>; quic@ietf.org
Subject: RE: Packet number encryption

=C2=A0

Actually taking a s= tep back what if we don=E2=80=99t we overloaded packet number as the nonce?=

=C2=A0

Can we:

  1. Put packet number as a s= eparate variable length field in the encrypted portion of the header. This = allows for growth beyond 64 bits in future and completely avoids ossificati= on. For short lived flows variable length encoding leads to minimal space overhead.
  2. Put a separate plaintex= t nonce which starts out as a secure random number and monotonically increa= ses as short random jumps (every packet or every few packets) and could the= n rollover. This will prevent linkability and scales to multi-path as well. No major comput= e overhead. We can also make the nonce optional for crypto algorithms that = do not need a nonce saving more space.

=C2=A0

Some MSB of the non= ce could be used for signaling reorder to the network if needed. I don=E2= =80=99t have the historical context for overloading of PN as the nonce so p= ardon me if un-overloading option was discussed and ruled out before.

=C2=A0

From:= QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Thursday, February 8, 2018 5:51 PM
To: huitema <huitema@huitema.net>; quic@ietf.org
Subject: RE: Packet number encryption

=C2=A0

>> and using separate packet sequences for eac= h path

This alone prevents linkability right?

=C2=A0

>> The packet number on each path will start a= t 1 (or maybe 0 ;-).

Is supporting multiple paths at the same time a goal= ? If yes, then yes all paths will need to have separate tracking and ACK st= ate and congestion control etc. I thought this is not part of V1 RFC. If it= s just one additional path for connection migration scenario then all you need is a (random) jump to a offset in pac= ket number space for the new path so that the few packets in the old path c= an continue for a little bit. This works with just one ACK space so no impl= ementation complexity.

=C2=A0

>> 2) Or, leaving the packet number in the cle= ar but using different encryption contexts for each path, and using separat= e packet sequences for each path.
In addition if the value in the clear was obfuscated with an XOR transform = it will help prevent ossification. The obfuscation is not meant to guard ag= ainst later analysis that reveals the packet numbers - why do we care about= that. It is meant to grease the space and not make the numbers serial so middleboxes cannot assume orderin= g etc.

=C2=A0

All said if I am alone in being concerned about the = perf hit then I=E2=80=99d say go on with option 1.

=C2=A0

From:= QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Thursday, February 8, 2018 3:54 PM
To: quic@ietf.org=
Subject: Re: Packet number encryption

=C2=A0

On 2/8/2018 1:13 PM, Mike Bishop wrote:

#2 won=E2=80=99t work.=C2=A0 The packet number is an= input to the AEAD nonce, so you have to get to the packet number before yo= u can decrypt the payload.=C2=A0 It can=E2=80=99t be based on anything inte= rnal to the encrypted packet.

=C2=A0

In Martin=E2=80=99s proposal, it=E2=80=99s using a c= ombination of the encrypted payload (which requires nothing to access) and = some stored state on each endpoint, which requires only the Connection ID t= o look up.=C2=A0 You want the thing you XOR by to be constantly changing, or it becomes easier to look at sequences of obfuscated packet n= umbers and start drawing inferences about what the XOR value is.=C2=A0 If o= verhead is the primary concern, I think there are a couple approaches that = might allow you to precompute values and amortize the cost of doing the encryption step.=C2=A0 (At the cost of = keeping the table of precomputed values, of course.)

=C2=A0

I still think Jana=E2=80=99s pushing in the right di= rection here:=C2=A0 Let=E2=80=99s agree on goals, and then see if we can cr= aft a design that meets those goals.=C2=A0 I hear you saying that low overh= ead is a goal, which I think we can all agree on.=C2=A0 I also think I hear you saying that 1-1.5% overhead is too high, but it sounds like the= re=E2=80=99s less agreement on that.=C2=A0 You also raise an interesting po= int that some clients will care less about linkability because they will ne= ver intentionally migrate.


I think Victor said it best, "Obfuscation is just encryption done poor= ly." Either we encrypt, or we don't. But there is no such thing as= an obfuscation middle-ground. Obfuscation would just be a speed bump, easi= ly broken. It won't provide privacy, and it won't prevent linkability.

As far as I am concerned, there are only two designs that prevent linkabili= ty:

1) Martin's PR, in which the packet number is encrypted using sensible = crypto;

2) Or, leaving the packet number in the clear but using different encryptio= n contexts for each path, and using separate packet sequences for each path= .

The second option requires more computation when explicitly setting up a ne= w path. The connection ID would be used as part of the "salt" whe= n deriving connection contexts. The packet number on each path will start a= t 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK= to be per/path, or alternatively adding a PATH-ACK frame that indicates th= e path for which packets are acked.

The pros and cons of the two options are easy to get:

1) Option 2 does not require the cost of encrypting every packet, thus per = packet processing will be maybe 1% faster than option 1.

2) Option 2 requires computing encryption contexts for each path, which is = more complex than option 1, but the cost will be amortized over the duratio= n of the path.

3) Option 2 requires more complex data structures and ACK management, thus = increasing the chances that something goes wrong.

4) Option 2 does nothing against packet number ossification. The packet num= ber effectively becomes part of the invariants.

In short, the only advantage of option 2 is to avoid a single symmetric enc= ryption operation per packet, while making the code significantly more comp= lex, and at the cost of not protecting against PN ossification. The way I s= ee that, there is hardly any debate.

-- Christian Huitema


--001a11413fc4aedbf00564c795a1-- From nobody Fri Feb 9 05:52:33 2018 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 41C53120726 for ; Fri, 9 Feb 2018 05:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 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, 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=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 H7zkjHxdR8su for ; Fri, 9 Feb 2018 05:52:29 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::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 1B8FA124235 for ; Fri, 9 Feb 2018 05:52:29 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id u17so5101593ywg.9 for ; Fri, 09 Feb 2018 05:52:29 -0800 (PST) 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=WqrjyQ0Z/KXOK7k3SRy8HTNwjuL9KDuT8CRYISL204s=; b=HlLlzp4xQQjK3QWgi7pLpqy5lV2FQg9I6CNY997YFOL0SulXwRVgk28sDi0xlxRZvk /jzxO/cx9+0UEYKUwTGR0jgWYw7U2qZ57J5L7ZSju96eoDJXDXIX8nSGx+3qyblRPZWG mwdEENXQHu+JKdoj9J7xuTZMHb4mqVpPOc2hWkEkN3/okNuAtM4NOD516HJy/2pNIeId yW9KFMOx95DxcstGDeAzr3PDLtoDTADSsWj9dS5LKNEfJi4zlglifOryTzetUShvs8cs 7rLt8rMG3w6yXLMiI1BlW6xpLCG5+8m/qBZ1bh/mThNsSh+c37FCC/YP+26CMJZFRa6m mEFA== 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=WqrjyQ0Z/KXOK7k3SRy8HTNwjuL9KDuT8CRYISL204s=; b=qNsBVQ3I5R8WusLVNkRm+/Bc7+dKZoHP/japqLYAaYUoVv6QBJyEsWP78CWaKCMIsx m5bk5WbrqkzRoHr+MEHQUqlHhLZDyewlyaoqJ0R/I66g0NwoKHrqvjiESAp5mtb1UnJM gYwaKefs/5F4bbhPQsPmOY2sy493rMHTPFWU3TTRxK0B1tfuPQOChWJrlXqEI4RUzQuJ 2tJ6PusuGSpGpj+m+cfQAlb1EphEB4z+Ru/0/ldInmxr0v/uA0q4Q/JcoDs2h0NZfCLi YOAJJUUaO9t3nu5CYNrXn8yiT/Gv68qRW1gDVw42+K6IftQ8/cUdViGWoW5kngAsLfHI M0rw== X-Gm-Message-State: APf1xPANpqEn8xH+zU4YYjZ3zW1B3z+uB3EQ3h/ROZVDM1GYxn370S0u x3VbAfYVx7qisALHISJIwWhUo6+koTXvQziBfmZQWgzJ X-Google-Smtp-Source: AH8x227ZRIFfQc9B/Y4CDKuFIeqSmigv2lca8AkMNefoJHhbHCtfDNIvlOFz//MbzARJZ41I4HKs77Qsmm53MBOKwOE= X-Received: by 10.129.153.201 with SMTP id q192mr1866624ywg.504.1518184348217; Fri, 09 Feb 2018 05:52:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Fri, 9 Feb 2018 05:51:47 -0800 (PST) In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> From: Eric Rescorla Date: Fri, 9 Feb 2018 05:51:47 -0800 Message-ID: Subject: Re: Packet number encryption To: Praveen Balasubramanian Cc: huitema , "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0b7332c787710564c7d631" 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, 09 Feb 2018 13:52:32 -0000 --94eb2c0b7332c787710564c7d631 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubramanian wrote: > Actually taking a step back what if we don=E2=80=99t we overloaded packet= number > as the nonce? > > > > Can we: > > 1. Put packet number as a separate variable length field in the > encrypted portion of the header. This allows for growth beyond 64 bits= in > future and completely avoids ossification. For short lived flows varia= ble > length encoding leads to minimal space overhead. > 2. Put a separate plaintext nonce which starts out as a secure random > number and monotonically increases as short random jumps (every packet= or > every few packets) and could then rollover. This will prevent linkabil= ity > and scales to multi-path as well. No major compute overhead. We can al= so > make the nonce optional for crypto algorithms that do not need a nonce > saving more space. > > I'm not sure how to do #2 safely and efficiently. The primary concern is that short random jumps don't actually prevent linkability because the high order bits don't change and long random jumps are effectively randomly sampling out of the nonce space, and you start to run into birthday problems. Additionally, the cheapest PRNGs are basically ciphers in counter mode, so at best you're going to get a small amount of overhead reduction by getting multiple jump computations out of a single block, though if you use 96-bit jumps, you only get 25% savings... -Ekr Some MSB of the nonce could be used for signaling reorder to the network if > needed. I don=E2=80=99t have the historical context for overloading of PN= as the > nonce so pardon me if un-overloading option was discussed and ruled out > before. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen > Balasubramanian > *Sent:* Thursday, February 8, 2018 5:51 PM > *To:* huitema ; quic@ietf.org > *Subject:* RE: Packet number encryption > > > > >> and using separate packet sequences for each path > > This alone prevents linkability right? > > > > >> The packet number on each path will start at 1 (or maybe 0 ;-). > > Is supporting multiple paths at the same time a goal? If yes, then yes al= l > paths will need to have separate tracking and ACK state and congestion > control etc. I thought this is not part of V1 RFC. If its just one > additional path for connection migration scenario then all you need is a > (random) jump to a offset in packet number space for the new path so that > the few packets in the old path can continue for a little bit. This works > with just one ACK space so no implementation complexity. > > > > >> 2) Or, leaving the packet number in the clear but using different > encryption contexts for each path, and using separate packet sequences fo= r > each path. > In addition if the value in the clear was obfuscated with an XOR transfor= m > it will help prevent ossification. The obfuscation is not meant to guard > against later analysis that reveals the packet numbers - why do we care > about that. It is meant to grease the space and not make the numbers seri= al > so middleboxes cannot assume ordering etc. > > > > All said if I am alone in being concerned about the perf hit then I=E2=80= =99d say > go on with option 1. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Christian Huitema > *Sent:* Thursday, February 8, 2018 3:54 PM > *To:* quic@ietf.org > *Subject:* Re: Packet number encryption > > > > On 2/8/2018 1:13 PM, Mike Bishop wrote: > > #2 won=E2=80=99t work. The packet number is an input to the AEAD nonce, = so you > have to get to the packet number before you can decrypt the payload. It > can=E2=80=99t be based on anything internal to the encrypted packet. > > > > In Martin=E2=80=99s proposal, it=E2=80=99s using a combination of the enc= rypted payload > (which requires nothing to access) and some stored state on each endpoint= , > which requires only the Connection ID to look up. You want the thing you > XOR by to be constantly changing, or it becomes easier to look at sequenc= es > of obfuscated packet numbers and start drawing inferences about what the > XOR value is. If overhead is the primary concern, I think there are a > couple approaches that might allow you to precompute values and amortize > the cost of doing the encryption step. (At the cost of keeping the table > of precomputed values, of course.) > > > > I still think Jana=E2=80=99s pushing in the right direction here: Let=E2= =80=99s agree on > goals, and then see if we can craft a design that meets those goals. I > hear you saying that low overhead is a goal, which I think we can all agr= ee > on. I also think I hear you saying that 1-1.5% overhead is too high, but > it sounds like there=E2=80=99s less agreement on that. You also raise an > interesting point that some clients will care less about linkability > because they will never intentionally migrate. > > > I think Victor said it best, "Obfuscation is just encryption done poorly.= " > Either we encrypt, or we don't. But there is no such thing as an > obfuscation middle-ground. Obfuscation would just be a speed bump, easily > broken. It won't provide privacy, and it won't prevent linkability. > > As far as I am concerned, there are only two designs that prevent > linkability: > > 1) Martin's PR, in which the packet number is encrypted using sensible > crypto; > > 2) Or, leaving the packet number in the clear but using different > encryption contexts for each path, and using separate packet sequences fo= r > each path. > > The second option requires more computation when explicitly setting up a > new path. The connection ID would be used as part of the "salt" when > deriving connection contexts. The packet number on each path will start a= t > 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for > each path/Connection-ID, and constraining ACK to be per/path, or > alternatively adding a PATH-ACK frame that indicates the path for which > packets are acked. > > The pros and cons of the two options are easy to get: > > 1) Option 2 does not require the cost of encrypting every packet, thus pe= r > packet processing will be maybe 1% faster than option 1. > > 2) Option 2 requires computing encryption contexts for each path, which i= s > more complex than option 1, but the cost will be amortized over the > duration of the path. > > 3) Option 2 requires more complex data structures and ACK management, thu= s > increasing the chances that something goes wrong. > > 4) Option 2 does nothing against packet number ossification. The packet > number effectively becomes part of the invariants. > > In short, the only advantage of option 2 is to avoid a single symmetric > encryption operation per packet, while making the code significantly more > complex, and at the cost of not protecting against PN ossification. The w= ay > I see that, there is hardly any debate. > > -- Christian Huitema > --94eb2c0b7332c787710564c7d631 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubramanian <pravb@micro= soft.com> wrote:

Actually taking a s= tep back what if we don=E2=80=99t we overloaded packet number as the nonce?=

=C2=A0

Can we:

  1. Put packet number as a separate variable length field in the encrypted port= ion of the header. This allows for growth beyond 64 bits in future and comp= letely avoids ossification. For short lived flows variable length encoding = leads to minimal space overhead.
  2. Put a separate plaintext nonce which starts out as a secure random number a= nd monotonically increases as short random jumps (every packet or every few= packets) and could then rollover. This will prevent linkability and scales= to multi-path as well. No major compute overhead. We can also make the nonce optional for crypto algorithm= s that do not need a nonce saving more space.

I'm not sure how to do #2 safely and efficient= ly. The primary concern is that short random jumps don't actually preve= nt linkability because the high order bits don't change and long random= jumps are effectively randomly sampling out of the nonce space, and you st= art to run into birthday problems. Additionally, the cheapest PRNGs are bas= ically ciphers in counter mode, so at best you're going to get a small = amount of overhead reduction by getting multiple jump computations out of a= single block, though if you use 96-bit jumps, you only get 25% savings...<= /div>

-Ekr



<= /div>

Some MSB of the non= ce could be used for signaling reorder to the network if needed. I don=E2= =80=99t have the historical context for overloading of PN as the nonce so p= ardon me if un-overloading option was discussed and ruled out before.

=C2=A0

From:= QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Thursday, February 8, 2018 5:51 PM
To: huitema <huitema@huitema.net>; quic@ietf.org
Subject: RE: Packet number encryption

=C2=A0

>> and using separate packet sequences for eac= h path

This alone prevents linkability right?=

=C2=A0

>> The packet number on each path will start a= t 1 (or maybe 0 ;-).

Is supporting multiple paths at the same time a goal= ? If yes, then yes all paths will need to have separate tracking and ACK st= ate and congestion control etc. I thought this is not part of V1 RFC. If it= s just one additional path for connection migration scenario then all you need is a (random) jump to a offset in pac= ket number space for the new path so that the few packets in the old path c= an continue for a little bit. This works with just one ACK space so no impl= ementation complexity.

=C2=A0

>> 2) Or, leaving the packet number in the cle= ar but using different encryption contexts for each path, and using separat= e packet sequences for each path.
In addition if the value in the clear was obfuscated with an XOR transform = it will help prevent ossification. The obfuscation is not meant to guard ag= ainst later analysis that reveals the packet numbers - why do we care about= that. It is meant to grease the space and not make the numbers serial so middleboxes cannot assume orderin= g etc.

=C2=A0

All said if I am alone in being concerned about the = perf hit then I=E2=80=99d say go on with option 1.

=C2=A0

From:= QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Thursday, February 8, 2018 3:54 PM
To: quic@ietf.org=
Subject: Re: Packet number encryption

=C2=A0

On 2/8/2018 1:13 PM, Mike Bishop wrote:

#2 won=E2=80=99t work.=C2=A0 The packet number is an= input to the AEAD nonce, so you have to get to the packet number before yo= u can decrypt the payload.=C2=A0 It can=E2=80=99t be based on anything inte= rnal to the encrypted packet.

=C2=A0

In Martin=E2=80=99s proposal, it=E2=80=99s using a c= ombination of the encrypted payload (which requires nothing to access) and = some stored state on each endpoint, which requires only the Connection ID t= o look up.=C2=A0 You want the thing you XOR by to be constantly changing, or it becomes easier to look at sequences of obfuscated packet n= umbers and start drawing inferences about what the XOR value is.=C2=A0 If o= verhead is the primary concern, I think there are a couple approaches that = might allow you to precompute values and amortize the cost of doing the encryption step.=C2=A0 (At the cost of = keeping the table of precomputed values, of course.)

=C2=A0

I still think Jana=E2=80=99s pushing in the right di= rection here:=C2=A0 Let=E2=80=99s agree on goals, and then see if we can cr= aft a design that meets those goals.=C2=A0 I hear you saying that low overh= ead is a goal, which I think we can all agree on.=C2=A0 I also think I hear you saying that 1-1.5% overhead is too high, but it sounds like the= re=E2=80=99s less agreement on that.=C2=A0 You also raise an interesting po= int that some clients will care less about linkability because they will ne= ver intentionally migrate.


I think Victor said it best, "Obfuscation is just encryption done poor= ly." Either we encrypt, or we don't. But there is no such thing as= an obfuscation middle-ground. Obfuscation would just be a speed bump, easi= ly broken. It won't provide privacy, and it won't prevent linkability.

As far as I am concerned, there are only two designs that prevent linkabili= ty:

1) Martin's PR, in which the packet number is encrypted using sensible = crypto;

2) Or, leaving the packet number in the clear but using different encryptio= n contexts for each path, and using separate packet sequences for each path= .

The second option requires more computation when explicitly setting up a ne= w path. The connection ID would be used as part of the "salt" whe= n deriving connection contexts. The packet number on each path will start a= t 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK= to be per/path, or alternatively adding a PATH-ACK frame that indicates th= e path for which packets are acked.

The pros and cons of the two options are easy to get:

1) Option 2 does not require the cost of encrypting every packet, thus per = packet processing will be maybe 1% faster than option 1.

2) Option 2 requires computing encryption contexts for each path, which is = more complex than option 1, but the cost will be amortized over the duratio= n of the path.

3) Option 2 requires more complex data structures and ACK management, thus = increasing the chances that something goes wrong.

4) Option 2 does nothing against packet number ossification. The packet num= ber effectively becomes part of the invariants.

In short, the only advantage of option 2 is to avoid a single symmetric enc= ryption operation per packet, while making the code significantly more comp= lex, and at the cost of not protecting against PN ossification. The way I s= ee that, there is hardly any debate.

-- Christian Huitema


--94eb2c0b7332c787710564c7d631-- From nobody Fri Feb 9 06:05:41 2018 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 CCC81124235 for ; Fri, 9 Feb 2018 06:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 8zAPA1ys4jN9 for ; Fri, 9 Feb 2018 06:05:38 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::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 EB9781241FC for ; Fri, 9 Feb 2018 06:05:37 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id f34so9722178ioi.13 for ; Fri, 09 Feb 2018 06:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=nNm45szi2uVPfS6vC9Zi1T4/VGeTcjX13HwQTKoUyYM=; b=JDMRd/P1eVGOePOENTbA3jW58VarmFE/GNzuIPQ0rDbCnquEQwWWJ8sDbrk4Dc+IHt t5fVpdoy7PF9DCQ0H7btfESIpM46Q5EEdqVaNbfo2KVEoJ7sidJBZDtbrfDF3RxSPPHH twDc8GBKsbcNSjMv2p4A8zTMufiKeP+IC1ocfL2FBXkNvXFa6f/Pr+K09+y9oYQzbPud /VTv2mqN8DxGLsnsTzh+V5sl9MzEvILgsuWqLefsopJe/gCQJLF3gxvr6SvadHCOZOL5 bMZc/Pvw+vNaciLsw4dtbok1fm9QmDleYf1VkSfk/cKIO9P3lGzEL2BywppbuXIPcqmb EFNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=nNm45szi2uVPfS6vC9Zi1T4/VGeTcjX13HwQTKoUyYM=; b=P+EOpg5yoYJMy5w8NABCLB0HJM/O4V75yaNjbdQBXuMNg3hcfTRfC7L5DIGfMttpvP qM+nr3M5EZ0B3ACUC/ELv1tBrqchhPJmIjajy01WnhxvmhvGKz9KqV7H6KK4JCW4/4dz hVmj08ArtyipTEwUtsKc/LltA3UI13/qd6wAL0Va9c2cbSfouVWO/1RVXqq5csCbHfwE CaPYaEHsBkC2RSjgh0wmZtI7QQYx0F/RrvYSV/bIZ+j9jfI3r4ydFCP2eTBUtM2bqxnR b8PveXMc+pIbXNBKX37+IwrI/LTUzgDfFL39lHJgHH22m+CKBMziMfQFFxnduc28KT1u n04g== X-Gm-Message-State: APf1xPAM5N/zD2YcgZh4pcYI13I02VCFX6Ae/itcUhrDJE1wN1ggh+1R B5G6zJWGuz4swd/+Jme5uRB/8E6jtu0Nzt2G/OM= X-Google-Smtp-Source: AH8x227ZgytR5Dp6drjooDg5iPP/rC9mrjLeNrIwASvRw9oCwn+ycsbkE18oVH81cqJiqWmpYUml114xpJgNXjo8Azc= X-Received: by 10.107.148.139 with SMTP id w133mr2178890iod.175.1518185137415; Fri, 09 Feb 2018 06:05:37 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 09:05:36 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 09:05:36 -0500 Message-ID: Subject: Re: Packet number encryption To: Eric Rescorla Cc: Praveen Balasubramanian , Mike Bishop , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="001a113fa926d1abbe0564c805dd" 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, 09 Feb 2018 14:05:40 -0000 --001a113fa926d1abbe0564c805dd Content-Type: text/plain; charset="UTF-8" On 9 February 2018 at 14.34.17, Eric Rescorla (ekr@rtfm.com) wrote: I'm not sure where you are getting this from. Any nonce reuse at all with AES-GCM is catastrophic: http://csrc.nist.gov/groups/ ST/toolkit/BCM/documents/comments/800-38_ Series-Drafts/GCM/Joux_comments.pdf I read it in a NIST paper I also linked to in other mail here, but it appears they have gone back on that based on the Ferguson paper. It nows says Legacy in url, but still shows up prominently in a google search. http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf --001a113fa926d1abbe0564c805dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 9 February 2018 a= t 14.34.17, Eric Rescorla (ekr@rtfm.com= ) wrote:

I'm not sure where you are getting this from. Any nonce reus= e at all with AES-GCM is catastrophic:
http://csrc.nist.gov/= groups/=C2=A0ST/toolkit/BC= M/documents/comments/800-38_ Series-Drafts/GCM/Joux_comments.pdf


I read it in a NIST paper I also l= inked to in other mail here, but it appears they have gone back on that bas= ed on the Ferguson paper. It nows says Legacy in url, but still shows up pr= ominently in a google search.

http://nvlpubs.nist.gov/ni= stpubs/Legacy/SP/nistspecialpublication800-38d.pdf

--001a113fa926d1abbe0564c805dd-- From nobody Fri Feb 9 06:08:02 2018 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 B01DA12946D for ; Fri, 9 Feb 2018 06:08:00 -0800 (PST) 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 V3dZLo4Wc6Cd for ; Fri, 9 Feb 2018 06:07:58 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::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 0832D127698 for ; Fri, 9 Feb 2018 06:07:58 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id l11so1962424ywh.2 for ; Fri, 09 Feb 2018 06:07:58 -0800 (PST) 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=lToDSt1EWQMhyUAOb5RJrRTzPgmkx3+FUCt3xNtuw+E=; b=zKcjOFUhF4X0lJEp2yjob0fzR9CnX7ipn5faZ4OKJeUCbfvjJd3pgEfPjM92FZTccr C45J0IowVt6YVWE2VZcBEfcabpUzQwJyXhbT3kGowO/IejPdpxylYeQDUidQSpWORgG/ vyK8YvFIKru6K9yuOkbYi8rXwOQ7J/ETF/EizzM6jkCu577O+aX1WdpZj4AJHjW38gOa 5+MKNuZgUSPlYa0x3B/Xy9me0JM35DPWN+VOsEuDq31qB9i5w78ccL/Wo2qpSKBbbUxK bX7WWGUmDGXl8a+uLXlQd4By13QjObkpUffl81JY+cJiDW3lx1g/3rEJZpiAh9HbROK7 3NRA== 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=lToDSt1EWQMhyUAOb5RJrRTzPgmkx3+FUCt3xNtuw+E=; b=cqf+hL/d1HyZyD+Tapjwcpoyhotsa79lygsibqqham80LEUdyhujyTNOi/C5IrusrG +FLLonRrWz4EULS1LGuItv3BW5GNJ99CFMOgLSQRTwviPQnUl2jk+/uiwOy/TtmjF+eJ q2ELOGERD/ljypVUzHd98rfJrfWoMd5gOj3CJzlOCZIRqapY41Ha5dZd4PJwbstPAYBG HBCk/c/DbuqvuKuKYNXkAcgcgVtcmIIih1q1R0Kqut0XiWYr74EfSk27YAffgrlC/n6f 7DpU2s7NjPkLSdwR3Fdi8MR+lmVgdstmDA3cMAtR4nNj1k2JlZ/qlmcqpTrxtbg+TwhI w2bw== X-Gm-Message-State: APf1xPBdNUVnyYDDPjOwhqiWyZcXmteop9DkONjbjl7RbUC/HCIi0GO5 oQbs3X0F3hX2ktrPhHSnoX00ase5ZyyHOWLzfKyGtg== X-Google-Smtp-Source: AH8x224KnDT+mTxxsF/fSmyQpihIYUrYkl+/bsQHcJy62Aq8kNLQRS+PEa4C1PkjfE+pqq58w0kam9nKRKgHjryuX14= X-Received: by 10.129.172.90 with SMTP id z26mr1924878ywj.363.1518185276963; Fri, 09 Feb 2018 06:07:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.160.201 with HTTP; Fri, 9 Feb 2018 06:07:16 -0800 (PST) In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> From: Eric Rescorla Date: Fri, 9 Feb 2018 06:07:16 -0800 Message-ID: Subject: Re: Packet number encryption To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Praveen Balasubramanian , Mike Bishop , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="f403045f1076232e840564c80e70" 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, 09 Feb 2018 14:08:01 -0000 --f403045f1076232e840564c80e70 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As far as I know, this is just NIST's judgement of how low a risk of nonce-reuse has to be in order to be safe. To the best of my knowledge, there's still no safe level of actual reuse. For that you'd need something like AES-GCM-SIV. -Ekr On Fri, Feb 9, 2018 at 6:05 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > On 9 February 2018 at 14.34.17, Eric Rescorla (ekr@rtfm.com) wrote: > > > I'm not sure where you are getting this from. Any nonce reuse at all with > AES-GCM is catastrophic: > http://csrc.nist.gov/groups/ ST/toolkit/BCM/documents/comments/800-38_ > Series-Drafts/GCM/Joux_comments.pdf > > > I read it in a NIST paper I also linked to in other mail here, but it > appears they have gone back on that based on the Ferguson paper. It nows > says Legacy in url, but still shows up prominently in a google search. > > http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d. > pdf > --f403045f1076232e840564c80e70 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As far as I know, this is just NIST's judgement of how= low a risk of nonce-reuse has to be in order to be safe. To the best of my= knowledge, there's still no safe level of actual reuse. For that you&#= 39;d need something like AES-GCM-SIV.

-Ekr

On F= ri, Feb 9, 2018 at 6:05 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@g= mail.com> wrote:
<= div id=3D"m_3175929965892286058bloop_customfont" style=3D"font-family:Helve= tica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto= ">On 9 February 2018 at 14.34.17, Eric Rescorla (ekr@rtfm.com) wrote:

I'm not sure where you are getting this from. Any n= once reuse at all with AES-GCM is catastrophic:
http://csrc.nist.gov/groups/=C2=A0ST/toolkit/BCM/documents/comme= nts/800-38_ Series-Drafts/GCM/Joux_comments.pdf


I read it in a NIST paper I also linked= to in other mail here, but it appears they have gone back on that based on= the Ferguson paper. It nows says Legacy in url, but still shows up promine= ntly in a google search.

http://nvlpub= s.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.= pdf


--f403045f1076232e840564c80e70-- From nobody Fri Feb 9 06:09:39 2018 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 557F0129516 for ; Fri, 9 Feb 2018 06:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 Kn-yVrodqWuo for ; Fri, 9 Feb 2018 06:09:36 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 97C8D127698 for ; Fri, 9 Feb 2018 06:09:36 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id c80so10767141itb.4 for ; Fri, 09 Feb 2018 06:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=OoEKxSKf7cTHf1C/SjJkEpObHCE/bBPcW7GniKhwmm8=; b=BhvuuaI9TrIbBXD9SzT9DjMxD+3g4yk/ohYzf8j8II7dHfFLp/pv4kaPGN5LEB9iAT 0L1E4dVbA/0qzQX6bSPMuTHTjRQNMG4H7Dk5Z68jR8C8oBZTwItyF46LbnH9I7HbdAfW g0aE9csJc+eF58yXxxcGn/sNUY7LcJI6xjA/m6TUHKgMsqDSkI5TYiZCNEqlr69DguTA FMRYwvyF312Ax+uo+UF1fAxSREYSzKm4WPScF8UfppQcwqTaTvL23o+tTc4lzKOR8kxC 2XA2M1dyIPk5b02T0yVpRJCVGLhQ5mSg/1Tfea5oNSgMhJyK43vU055Z4E/GBMNq9jc3 1Iag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=OoEKxSKf7cTHf1C/SjJkEpObHCE/bBPcW7GniKhwmm8=; b=P16KIlE2wy+E4dDWXeaESTULXkHDwEKge4SS2efe7WOy5QaAsudZ0Ubg/e5mIZwQ5k +GZRIb9S/LBzMlapR9E06UKtJoLetMIJ15JRuwAeOU+37IvkldoQRWc0bj/VDT8eDdq4 ARDIiRjioYbKBL0VcjMifjT5A4Zz41ZxtQQyWmqC6k7oZWQyupU/Qiyt5MqDXC5TaJco qlBoosmBVykJqrGfamBzJkza53adhd0jrsT0suaGDOQjMAob6G3GlIZjUyef08/lTijQ IkVAXbQeIYOgVEjWKCKEsMq6ygssXVcKwPMHwYrs2Ne+Cgg2WzkPxW8e4hbwDHhVjn0X jWfQ== X-Gm-Message-State: APf1xPBAvtwqq0iDkoXta69/Zq4oDQed7a0aQySMnp9dzqMwSKdP3ddL WE817UGMka1p9zqQstner8QCL/2yAIeh6sHmtdU= X-Google-Smtp-Source: AH8x2249LaRNGzQpSAgMaoJpG9k6yI7gINOUJKh2QWR0rw/v6mgguVB1qZjrCDL7ui1aqprgiNVsEc2IOEZoqR7Lbcg= X-Received: by 10.36.46.23 with SMTP id i23mr3583296ita.55.1518185376060; Fri, 09 Feb 2018 06:09:36 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 09:09:35 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 09:09:35 -0500 Message-ID: Subject: Re: Packet number encryption To: Eric Rescorla Cc: Praveen Balasubramanian , Mike Bishop , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="001a114a9d820b1b300564c81430" 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, 09 Feb 2018 14:09:38 -0000 --001a114a9d820b1b300564c81430 Content-Type: text/plain; charset="UTF-8" As far as I know, this is just NIST's judgement of how low a risk of nonce-reuse has to be in order to be safe. To the best of my knowledge, there's still no safe level of actual reuse. For that you'd need something like AES-GCM-SIV. OK, but as I also pointed out in another recent mail, correcting myself, IETF requires unique nonces in TLS, so the point is mood. --001a114a9d820b1b300564c81430 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
As far as I know, this is just NIST's judgement of how low a risk of nonce-reuse has to be in order to be safe. To the best of my knowledge, there's still no safe level of actual reuse. For that you'd need something like AES-GCM-SIV.


OK, but= as I also pointed out in another recent mail, correcting myself, IETF requ= ires unique nonces in TLS, so the point is mood. --001a114a9d820b1b300564c81430-- From nobody Fri Feb 9 06:15:05 2018 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 CCE63127698 for ; Fri, 9 Feb 2018 06:15:03 -0800 (PST) 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] 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 Vr_ypFw_Linz for ; Fri, 9 Feb 2018 06:15:01 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 D5371124205 for ; Fri, 9 Feb 2018 06:15:00 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id n7so9786601iob.0 for ; Fri, 09 Feb 2018 06:15:00 -0800 (PST) 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=5zNDOtdQVhF8aOyDBdOXBUCS5LKrnUDvZP2KShO2c+w=; b=trwoMW9l6zAp+IOGJarvs33c8nGB6NCyzbB55q//6kkJsc0bpAQ5EKj6rS/4LqM6G9 dwO8ulJ55MqUF9526Bew7/vbRNiuh06IUnli7eU9XdekFyFke+lU0imNkRCTcI9irS4P 1McB8zZiL3bu+3w+ZsWfYA9nCsbZ2+W8mUFFfgCCvmM98s0xEg44ifFybNQk8aUh29Ax s/aAxP39mO56fRZE4Ksd6VZ9aerq4EoYfI3Rc5iEe9k33QWLynI2Q6m40u7jMEc/JwCQ D8mQhWFqWb8Ie80GN9CLMkNzEPu9XKXHAWhhiA7H+BT4TtKxM03P5F9A25WFQdrFSLK1 xEGQ== 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=5zNDOtdQVhF8aOyDBdOXBUCS5LKrnUDvZP2KShO2c+w=; b=Gx7rISRcdtjY9lT0kktHFhJGyFmDD04kUorll7e/nzJDhQiCHUAeAseQube+CueuCS 524djxd8uVtwkHlLQ9TRWmXRmQHcKNcjouBYWsu8VjDyEL9egU7aXIUheO8+6hSr/sjy 2tdGLhbF/F5ouaGEgSaY/aftMIVLKYc4UjQ0Co6B/ujcAypjc7dCMv7VfzfkllMv8T39 +czx4d+iFQV2LRg+NAzn5B1qaLvRLnP9Ak2mVhV3zBuD9HAWSuMTDhqVArg6TKjysren ZdjlETbVIXtGjQndh3NJrK8WkIwKbYmb6v4tQObxacuHpR9Rw3x5pTDEd6cqHaxTqH2n KQ2A== X-Gm-Message-State: APf1xPD4wtGc8SlCpk19Y+yrbnvWtJr1hqKwO09ID15iZxkYMexi1T7t ymftx5cLbOituw0GDAHO4BmhnzMfmdY1plNG5jkFpRGw X-Google-Smtp-Source: AH8x224j8ivNucBmCBrQAzyQL6LowFPsH2JsH+wIUoMW5imPPnrm2i3CBcI6hJCWJqnOGBZ3hqlX0ucOugZ0NXWwQoY= X-Received: by 10.107.89.11 with SMTP id n11mr3247918iob.154.1518185700015; Fri, 09 Feb 2018 06:15:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Fri, 9 Feb 2018 06:14:39 -0800 (PST) In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> From: Ian Swett Date: Fri, 9 Feb 2018 09:14:39 -0500 Message-ID: Subject: Re: Packet number encryption To: Eric Rescorla Cc: Praveen Balasubramanian , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="f4f5e80671985acf250564c82775" 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, 09 Feb 2018 14:15:04 -0000 --f4f5e80671985acf250564c82775 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Feb 9, 2018 at 8:51 AM, Eric Rescorla wrote: > > > On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > >> Actually taking a step back what if we don=E2=80=99t we overloaded packe= t number >> as the nonce? >> >> >> >> Can we: >> >> 1. Put packet number as a separate variable length field in the >> encrypted portion of the header. This allows for growth beyond 64 bit= s in >> future and completely avoids ossification. For short lived flows vari= able >> length encoding leads to minimal space overhead. >> 2. Put a separate plaintext nonce which starts out as a secure random >> number and monotonically increases as short random jumps (every packe= t or >> every few packets) and could then rollover. This will prevent linkabi= lity >> and scales to multi-path as well. No major compute overhead. We can a= lso >> make the nonce optional for crypto algorithms that do not need a nonc= e >> saving more space. >> >> > I'm not sure how to do #2 safely and efficiently. The primary concern is > that short random jumps don't actually prevent linkability because the hi= gh > order bits don't change and long random jumps are effectively randomly > sampling out of the nonce space, and you start to run into birthday > problems. Additionally, the cheapest PRNGs are basically ciphers in count= er > mode, so at best you're going to get a small amount of overhead reduction > by getting multiple jump computations out of a single block, though if yo= u > use 96-bit jumps, you only get 25% savings... > > -Ekr > > > > Some MSB of the nonce could be used for signaling reorder to the network >> if needed. I don=E2=80=99t have the historical context for overloading o= f PN as the >> nonce so pardon me if un-overloading option was discussed and ruled out >> before. >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen >> Balasubramanian >> *Sent:* Thursday, February 8, 2018 5:51 PM >> *To:* huitema ; quic@ietf.org >> *Subject:* RE: Packet number encryption >> >> >> >> >> and using separate packet sequences for each path >> >> This alone prevents linkability right? >> >> >> >> >> The packet number on each path will start at 1 (or maybe 0 ;-). >> >> Is supporting multiple paths at the same time a goal? If yes, then yes >> all paths will need to have separate tracking and ACK state and congesti= on >> control etc. I thought this is not part of V1 RFC. If its just one >> additional path for connection migration scenario then all you need is a >> (random) jump to a offset in packet number space for the new path so tha= t >> the few packets in the old path can continue for a little bit. This work= s >> with just one ACK space so no implementation complexity. >> >> >> >> >> 2) Or, leaving the packet number in the clear but using different >> encryption contexts for each path, and using separate packet sequences f= or >> each path. >> In addition if the value in the clear was obfuscated with an XOR >> transform it will help prevent ossification. The obfuscation is not mean= t >> to guard against later analysis that reveals the packet numbers - why do= we >> care about that. It is meant to grease the space and not make the number= s >> serial so middleboxes cannot assume ordering etc. >> >> >> >> All said if I am alone in being concerned about the perf hit then I=E2= =80=99d say >> go on with option 1. >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org ] *On >> Behalf Of *Christian Huitema >> *Sent:* Thursday, February 8, 2018 3:54 PM >> *To:* quic@ietf.org >> *Subject:* Re: Packet number encryption >> >> >> >> On 2/8/2018 1:13 PM, Mike Bishop wrote: >> >> #2 won=E2=80=99t work. The packet number is an input to the AEAD nonce,= so you >> have to get to the packet number before you can decrypt the payload. It >> can=E2=80=99t be based on anything internal to the encrypted packet. >> >> >> >> In Martin=E2=80=99s proposal, it=E2=80=99s using a combination of the en= crypted payload >> (which requires nothing to access) and some stored state on each endpoin= t, >> which requires only the Connection ID to look up. You want the thing yo= u >> XOR by to be constantly changing, or it becomes easier to look at sequen= ces >> of obfuscated packet numbers and start drawing inferences about what the >> XOR value is. If overhead is the primary concern, I think there are a >> couple approaches that might allow you to precompute values and amortize >> the cost of doing the encryption step. (At the cost of keeping the tabl= e >> of precomputed values, of course.) >> >> >> >> I still think Jana=E2=80=99s pushing in the right direction here: Let= =E2=80=99s agree on >> goals, and then see if we can craft a design that meets those goals. I >> hear you saying that low overhead is a goal, which I think we can all ag= ree >> on. I also think I hear you saying that 1-1.5% overhead is too high, bu= t >> it sounds like there=E2=80=99s less agreement on that. You also raise a= n >> interesting point that some clients will care less about linkability >> because they will never intentionally migrate. >> >> >> I think Victor said it best, "Obfuscation is just encryption done >> poorly." Either we encrypt, or we don't. But there is no such thing as a= n >> obfuscation middle-ground. Obfuscation would just be a speed bump, easil= y >> broken. It won't provide privacy, and it won't prevent linkability. >> >> As far as I am concerned, there are only two designs that prevent >> linkability: >> >> 1) Martin's PR, in which the packet number is encrypted using sensible >> crypto; >> >> 2) Or, leaving the packet number in the clear but using different >> encryption contexts for each path, and using separate packet sequences f= or >> each path. >> > I don't believe the second is necessary if we want to leave the PN in the clear. Avoiding nonce reuse is relatively easy. Avoiding linkability is more annoying, but doable. On net, I think encryption may be the best approach, but I don't think not doing encryption demands the complexity you indicate. > The second option requires more computation when explicitly setting up a >> new path. The connection ID would be used as part of the "salt" when >> deriving connection contexts. The packet number on each path will start = at >> 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards fo= r >> each path/Connection-ID, and constraining ACK to be per/path, or >> alternatively adding a PATH-ACK frame that indicates the path for which >> packets are acked. >> >> The pros and cons of the two options are easy to get: >> >> 1) Option 2 does not require the cost of encrypting every packet, thus >> per packet processing will be maybe 1% faster than option 1. >> >> 2) Option 2 requires computing encryption contexts for each path, which >> is more complex than option 1, but the cost will be amortized over the >> duration of the path. >> >> 3) Option 2 requires more complex data structures and ACK management, >> thus increasing the chances that something goes wrong. >> >> 4) Option 2 does nothing against packet number ossification. The packet >> number effectively becomes part of the invariants. >> >> In short, the only advantage of option 2 is to avoid a single symmetric >> encryption operation per packet, while making the code significantly mor= e >> complex, and at the cost of not protecting against PN ossification. The = way >> I see that, there is hardly any debate. >> >> -- Christian Huitema >> > > --f4f5e80671985acf250564c82775 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 9, 2018 at 8:51 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Thu, Feb 8, 2018 a= t 9:40 PM, Praveen Balasubramanian <pravb@microsoft.com> w= rote:

Actually taking a s= tep back what if we don=E2=80=99t we overloaded packet number as the nonce?=

=C2=A0

Can we:

  1. Put packet number as a separate variable length field in the encrypted port= ion of the header. This allows for growth beyond 64 bits in future and comp= letely avoids ossification. For short lived flows variable length encoding = leads to minimal space overhead.
  2. Put a separate plaintext nonce which starts out as a secure random number a= nd monotonically increases as short random jumps (every packet or every few= packets) and could then rollover. This will prevent linkability and scales= to multi-path as well. No major compute overhead. We can also make the nonce optional for crypto algorithm= s that do not need a nonce saving more space.

I'm not sure how to do #2 safely and ef= ficiently. The primary concern is that short random jumps don't actuall= y prevent linkability because the high order bits don't change and long= random jumps are effectively randomly sampling out of the nonce space, and= you start to run into birthday problems. Additionally, the cheapest PRNGs = are basically ciphers in counter mode, so at best you're going to get a= small amount of overhead reduction by getting multiple jump computations o= ut of a single block, though if you use 96-bit jumps, you only get 25% savi= ngs...

-Ekr

<= /div>


Some MSB of the non= ce could be used for signaling reorder to the network if needed. I don=E2= =80=99t have the historical context for overloading of PN as the nonce so p= ardon me if un-overloading option was discussed and ruled out before.

=C2=A0

From:= QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Thursday, February 8, 2018 5:51 PM
To: huitema <huitema@huitema.net>; quic@ietf.org
Subject: RE: Packet number encryption

=C2=A0

>> and using separate packet sequences for eac= h path

This alone prevents linkability right?=

=C2=A0

>> The packet number on each path will start a= t 1 (or maybe 0 ;-).

Is supporting multiple paths at the same time a goal= ? If yes, then yes all paths will need to have separate tracking and ACK st= ate and congestion control etc. I thought this is not part of V1 RFC. If it= s just one additional path for connection migration scenario then all you need is a (random) jump to a offset in pac= ket number space for the new path so that the few packets in the old path c= an continue for a little bit. This works with just one ACK space so no impl= ementation complexity.

=C2=A0

>> 2) Or, leaving the packet number in the cle= ar but using different encryption contexts for each path, and using separat= e packet sequences for each path.
In addition if the value in the clear was obfuscated with an XOR transform = it will help prevent ossification. The obfuscation is not meant to guard ag= ainst later analysis that reveals the packet numbers - why do we care about= that. It is meant to grease the space and not make the numbers serial so middleboxes cannot assume orderin= g etc.

=C2=A0

All said if I am alone in being concerned about the = perf hit then I=E2=80=99d say go on with option 1.

=C2=A0

From:= QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Thursday, February 8, 2018 3:54 PM
To: quic@ietf.org=
Subject: Re: Packet number encryption

=C2=A0

On 2/8/2018 1:13 PM, Mike Bishop wrote:

#2 won=E2=80=99t work.=C2=A0 The packet number is an= input to the AEAD nonce, so you have to get to the packet number before yo= u can decrypt the payload.=C2=A0 It can=E2=80=99t be based on anything inte= rnal to the encrypted packet.

=C2=A0

In Martin=E2=80=99s proposal, it=E2=80=99s using a c= ombination of the encrypted payload (which requires nothing to access) and = some stored state on each endpoint, which requires only the Connection ID t= o look up.=C2=A0 You want the thing you XOR by to be constantly changing, or it becomes easier to look at sequences of obfuscated packet n= umbers and start drawing inferences about what the XOR value is.=C2=A0 If o= verhead is the primary concern, I think there are a couple approaches that = might allow you to precompute values and amortize the cost of doing the encryption step.=C2=A0 (At the cost of = keeping the table of precomputed values, of course.)

=C2=A0

I still think Jana=E2=80=99s pushing in the right di= rection here:=C2=A0 Let=E2=80=99s agree on goals, and then see if we can cr= aft a design that meets those goals.=C2=A0 I hear you saying that low overh= ead is a goal, which I think we can all agree on.=C2=A0 I also think I hear you saying that 1-1.5% overhead is too high, but it sounds like the= re=E2=80=99s less agreement on that.=C2=A0 You also raise an interesting po= int that some clients will care less about linkability because they will ne= ver intentionally migrate.


I think Victor said it best, "Obfuscation is just encryption done poor= ly." Either we encrypt, or we don't. But there is no such thing as= an obfuscation middle-ground. Obfuscation would just be a speed bump, easi= ly broken. It won't provide privacy, and it won't prevent linkability.

As far as I am concerned, there are only two designs that prevent linkabili= ty:

1) Martin's PR, in which the packet number is encrypted using sensible = crypto;

2) Or, leaving the packet number in the clear but using different encryptio= n contexts for each path, and using separate packet sequences for each path= .

I don't believe the second is necessary if we want t= o leave the PN in the clear.=C2=A0 Avoiding nonce reuse is relatively easy.= =C2=A0 Avoiding linkability is more annoying, but doable.=C2=A0
<= br>
On net, I think encryption may be the best approach, but I do= n't think not doing encryption demands the complexity you indicate.
=
=C2=A0

The second option requires more computation when explicitly setting up a ne= w path. The connection ID would be used as part of the "salt" whe= n deriving connection contexts. The packet number on each path will start a= t 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK= to be per/path, or alternatively adding a PATH-ACK frame that indicates th= e path for which packets are acked.

The pros and cons of the two options are easy to get:

1) Option 2 does not require the cost of encrypting every packet, thus per = packet processing will be maybe 1% faster than option 1.

2) Option 2 requires computing encryption contexts for each path, which is = more complex than option 1, but the cost will be amortized over the duratio= n of the path.

3) Option 2 requires more complex data structures and ACK management, thus = increasing the chances that something goes wrong.

4) Option 2 does nothing against packet number ossification. The packet num= ber effectively becomes part of the invariants.

In short, the only advantage of option 2 is to avoid a single symmetric enc= ryption operation per packet, while making the code significantly more comp= lex, and at the cost of not protecting against PN ossification. The way I s= ee that, there is hardly any debate.

-- Christian Huitema



--f4f5e80671985acf250564c82775-- From nobody Fri Feb 9 09:15:39 2018 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 E9BA712D7F5 for ; Fri, 9 Feb 2018 09:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.01 X-Spam-Level: X-Spam-Status: No, score=-3.01 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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 iwDaZqiODOLW for ; Fri, 9 Feb 2018 09:15:33 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0102.outbound.protection.outlook.com [104.47.40.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAF7612D86D for ; Fri, 9 Feb 2018 09:15:08 -0800 (PST) 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=xz4EVxuCoJKjyZd6F3FAK/BQa+6Cyxhu5YjFGOEFiXg=; b=dE9WYmm/0AJgeidGeXcNbRBFYHCfgCQxn4gGdD7+IlL6VD8NRvpvjqapEzpXcectiRKv+uKANUghIL6t0d6lkEfv++H8Vt4kK0Ke2YIhur5DGkcbpAd8RuJOub6fUaDhSfegjwmocWfntqE+DE64JxWONrVBMpFwmzEXCvn9MLg= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0821.namprd21.prod.outlook.com (10.173.192.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Fri, 9 Feb 2018 17:15:06 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 17:15:06 +0000 From: Praveen Balasubramanian To: "Salz, Rich" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Mike Bishop , "quic@ietf.org" , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwIAADioAgAARigCAAABaEIAAXF6AgABIk/A= Date: Fri, 9 Feb 2018 17:15:06 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> <84BA46ED-BA37-4B06-8902-B14D0C91B8EE@akamai.com> In-Reply-To: <84BA46ED-BA37-4B06-8902-B14D0C91B8EE@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0821; 7:eqF7PbQ1MbC+TPiwqzFYvezrG0iCxTesETzP/9jMpCaKA7O8yOtdZBWBLBeOFJRZT+CqHzGRCGFe/iLkblMFM/NI5paiD84uYigqsZTrwFM77UQlfmvJbjLZKFR81bbS9olNOEz27y8Ng07Lih56PHevIuVA2olGt6ElEAYgyCIBs0Iw9EZrLbbV0rnjIQE/wdx4Tzllh9jIgd8M84UPw/v7wEoNpZcSBX0773exfAbuJspVfjK3wukI8O2CbBKy x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 5e150331-a062-4f3e-8efd-08d56fe0aa80 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0821; x-ms-traffictypediagnostic: CY4PR21MB0821: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(10201501046)(3231101)(944501161)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0821; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0821; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(346002)(366004)(376002)(39860400002)(396003)(199004)(189003)(6346003)(53546011)(102836004)(6506007)(68736007)(6246003)(186003)(39060400002)(2501003)(76176011)(316002)(478600001)(22452003)(25786009)(2906002)(110136005)(5250100002)(14454004)(229853002)(7696005)(86612001)(93886005)(74316002)(3480700004)(86362001)(10090500001)(99286004)(5660300001)(3280700002)(3660700001)(2950100002)(33656002)(53936002)(561944003)(2900100001)(6436002)(10290500003)(790700001)(6116002)(8936002)(7736002)(105586002)(97736004)(7116003)(55016002)(8990500004)(8676002)(106356001)(9686003)(54896002)(81156014)(81166006)(6306002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0821; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: IwzRu9PT3hE1Dng7T/JsUzAzieJzyqubEmhU5Te/dDt3pXwfv3GmJ+2JaRvVULkQwFEhYCfNNyDJuHzzFmh0sA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB013342BD31A6910BE350C389B6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e150331-a062-4f3e-8efd-08d56fe0aa80 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 17:15:06.5296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0821 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, 09 Feb 2018 17:15:36 -0000 --_000_CY4PR21MB013342BD31A6910BE350C389B6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8gSSBkb27igJl0IHdhbnQgaXQgaW4gdGhlIGNsZWFyLiBUaGUgcHJvcG9zYWwgaXMgdG8gcHV0 IFBOIGluIGVuY3J5cHRlZCBoZWFkZXIgYW5kIHVzZSBhIHNlcGFyYXRlIG5vbmNlIGZpZWxkIGlu IHRoZSBjbGVhci4gUGxlYXNlIGlnbm9yZSB0aGUgd2hvbGUgb2JmdXNjYXRpb24gZGlzY3Vzc2lv biBmb3Igbm93LCB0aGF0IHdhcyBhbiBhdHRlbXB0IHRvIHByb2R1Y2UgYSB0cmFuc2Zvcm0gY2hl YXBlciB0aGFuIGNyeXB0byBhbmQgZG9lc27igJl0IHNlZW0gdG8gYmUgZ29pbmcgYW55d2hlcmUu DQoNCkZyb206IFNhbHosIFJpY2ggW21haWx0bzpyc2FsekBha2FtYWkuY29tXQ0KU2VudDogRnJp ZGF5LCBGZWJydWFyeSA5LCAyMDE4IDQ6NTQgQU0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlh biA8cHJhdmJAbWljcm9zb2Z0LmNvbT47IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tl bGZqQGdtYWlsLmNvbT47IE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT47IHF1aWNA aWV0Zi5vcmc7IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+DQpTdWJqZWN0OiBSZTogUGFj a2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCkNhbiB5b3UgcGxlYXNlIGV4cGxhaW4gd2h5IHlvdSB3 YW50IHRoZSBwYWNrZXQgbnVtYmVyIGluIHRoZSBjbGVhcj8gIE9yIHBvc3QgYSBsaW5rIHRvIHRo ZSBlbWFpbCBhcmNoaXZlIGlmIHlvdeKAmXZlIGFscmVhZHkgZG9uZSBzby4gIEJlY2F1c2UsIHRv IG15IGNhc3VhbCBvYnNlcnZlciB2aWV3cG9pbnQsIHlvdSBhcmUgdHJ5aW5nIGZhaXJseSBoYXJk IHRvIGRvIHRoaXMsIGluY2x1ZGluZyBzb21lIHRvcnR1cmVkL3F1ZXN0aW9uYWJsZSBjcnlwdG87 IHNvLCB3aHk/DQoNCg== --_000_CY4PR21MB013342BD31A6910BE350C389B6F20CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHlsZS1u YW1lOmFpcm1haWxfb247DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ObyBJIGRvbuKAmXQgd2FudCBpdCBpbiB0aGUgY2xl YXIuIFRoZSBwcm9wb3NhbCBpcyB0byBwdXQgUE4gaW4gZW5jcnlwdGVkIGhlYWRlciBhbmQgdXNl IGEgc2VwYXJhdGUgbm9uY2UgZmllbGQgaW4gdGhlIGNsZWFyLiBQbGVhc2UgaWdub3JlIHRoZSB3 aG9sZSBvYmZ1c2NhdGlvbiBkaXNjdXNzaW9uIGZvciBub3csIHRoYXQgd2FzIGFuIGF0dGVtcHQg dG8gcHJvZHVjZSBhIHRyYW5zZm9ybSBjaGVhcGVyIHRoYW4NCiBjcnlwdG8gYW5kIGRvZXNu4oCZ dCBzZWVtIHRvIGJlIGdvaW5nIGFueXdoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFNhbHosIFJpY2ggW21h aWx0bzpyc2FsekBha2FtYWkuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFy eSA5LCAyMDE4IDQ6NTQgQU08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFu ICZsdDtwcmF2YkBtaWNyb3NvZnQuY29tJmd0OzsgTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAm bHQ7bWlra2VsZmpAZ21haWwuY29tJmd0OzsgTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVl Zm91LmJlJmd0OzsgcXVpY0BpZXRmLm9yZzsgaHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5l dCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2FuIHlvdSBwbGVhc2UgZXhw bGFpbiB3aHkgeW91IHdhbnQgdGhlIHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyPyZuYnNwOyBP ciBwb3N0IGEgbGluayB0byB0aGUgZW1haWwgYXJjaGl2ZSBpZiB5b3XigJl2ZSBhbHJlYWR5IGRv bmUgc28uJm5ic3A7IEJlY2F1c2UsIHRvIG15IGNhc3VhbCBvYnNlcnZlciB2aWV3cG9pbnQsIHlv dSBhcmUgdHJ5aW5nIGZhaXJseSBoYXJkIHRvIGRvIHRoaXMsIGluY2x1ZGluZyBzb21lIHRvcnR1 cmVkL3F1ZXN0aW9uYWJsZQ0KIGNyeXB0bzsgc28sIHdoeT88bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB013342BD31A6910BE350C389B6F20CY4PR21MB0133namp_-- From nobody Fri Feb 9 09:38:09 2018 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 96F46120454 for ; Fri, 9 Feb 2018 09:38:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-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 (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 9RDNLrJixT6J for ; Fri, 9 Feb 2018 09:38:05 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0108.outbound.protection.outlook.com [104.47.42.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D69471201F8 for ; Fri, 9 Feb 2018 09:38:04 -0800 (PST) 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=2PyFcTByJbOUHjRUbpBvCxPCnmGXrnydwR3rP54sGC0=; b=BfMGmUZr0GI51gjpbs9l1HEHOYWNv5PWGiWIOxRW5zj3WvK7fRnDPjfFOFFcFfEURivz1aDcUUfVXWSdk8wXLWEJQnq9b4MET4ATgpsbg0+8mZ/HpcwtgQy0E+jiXr2CkkQlxZttChKghoHmlhO7g30JtBFyTDkzCZuGCOEv9IA= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0839.namprd21.prod.outlook.com (10.173.192.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.1; Fri, 9 Feb 2018 17:38:02 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 17:38:02 +0000 From: Praveen Balasubramanian To: Eric Rescorla CC: huitema , "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwIAAjJeAgAA5dnA= Date: Fri, 9 Feb 2018 17:38:02 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0839; 7:+ApExpU3Aob++qWPObHFXUOBQ9xiiT3gHc/+HjrT052u/vjPpAJ6UtZM1PODze5A7H/0JmRCWRCI7dE3RrYwwPqYQ1Uk5ezQDfXI6uvA8LEOheIjciw4Ox+2iPdg9oQ8mB75bW5JgxJacknzIszpqwya74MP2wMpxkjXd5Vtl/fC0UakjdgYcxa0RTbVLLhobi7kWU2H4yjy9Gq3Jy0/bIio02tQupyyrXqedXbFWyiBtTWvUJiibabGsLvIMdFh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 181f8538-b0bc-4028-a365-08d56fe3ded0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0839; x-ms-traffictypediagnostic: CY4PR21MB0839: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(93006095)(93001095)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0839; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0839; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(39860400002)(396003)(376002)(346002)(377424004)(199004)(189003)(54906003)(6116002)(790700001)(2900100001)(561944003)(33656002)(106356001)(68736007)(53546011)(14454004)(6506007)(102836004)(8990500004)(25786009)(59450400001)(478600001)(99286004)(86362001)(97736004)(10090500001)(6436002)(4326008)(7116003)(5660300001)(6346003)(86612001)(229853002)(8676002)(19609705001)(6916009)(2950100002)(81156014)(81166006)(6246003)(186003)(105586002)(22452003)(5250100002)(93886005)(236005)(55016002)(9686003)(54896002)(10290500003)(6306002)(74316002)(316002)(53936002)(76176011)(7736002)(2906002)(3480700004)(8936002)(3660700001)(7696005)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0839; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: cJ9PdCTH/kWaBeNENZgGYi3XjzLGtK9rLIfOt7gnVQA6yxeJaDE1PN0CgaXL04AVQdUWuo3DTDndd55bTtdisw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01337A5E81D8A8A1D7518D97B6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 181f8538-b0bc-4028-a365-08d56fe3ded0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 17:38:02.8017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0839 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, 09 Feb 2018 17:38:09 -0000 --_000_CY4PR21MB01337A5E81D8A8A1D7518D97B6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGV0IG1lIHRyeSB0byBzdW1tYXJpemUgdGhlIHByb3Bvc2FsIGFnYWluOg0KDQoNCiAgMS4gIFBh Y2tldCBudW1iZXIgaXMgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBoZWFkZXIgYW5k IGlzIG5vIGxvbmdlciB1c2VkIGFzIHRoZSBub25jZS4gSXQgaXMgZW5jb2RlZCBhcyBhIHZhcmlh YmxlIGxlbmd0aCBudW1iZXIuIEFsd2F5cyBzdGFydHMgYXQgMC4NCiAgICAgKiAgIE5vIG9zc2lm aWNhdGlvbiBvZiBQTg0KICAgICAqICAgTm8gbGlua2FiaWxpdHkgdXNpbmcgUE4NCiAgICAgKiAg IEFsbG93cyBmb3IgZ3Jvd3RoIGJleW9uZCA2NCBiaXRzIGlmIG5lZWRlZCBpbiBmdXR1cmUNCiAg Mi4gIFRoZSBub25jZSBpcyBpbiB0aGUgY2xlYXIgaW4gcGxhaW50ZXh0IGhlYWRlci4gSXQgaXMg Z2VuZXJhdGVkIHBlciBwYXRoIGFzIGEgc2VjdXJlIHJhbmRvbSBudW1iZXIuIENhbGwgdGhpcyB0 aGUg4oCcc3RhcnRpbmcgdmFsdWXigJ0uIEJvdGggc2lkZXMgTVVTVCBpbml0aWFsaXplIHRoZSDi gJxzdGFydGluZyB2YWx1ZeKAnSBub25jZSBwZXIgcGF0aC4gV2l0aGluIGEgcGF0aCBpdCBncm93 cyBtb25vdG9uaWNhbGx5ICh0byBhdm9pZCByZXBlYXRzIGp1c3QgbGlrZSBQTiB0b2RheSkgYW5k IGNhbiBpbmNsdWRlIHNob3J0IHJhbmRvbSBqdW1wcyBwZXJpb2RpY2FsbHkgc28gdGhhdCBtaWRk bGVib3hlcyBjYW5ub3QgYXNzdW1lIGFueXRoaW5nIGFib3V0IHRoZSBmaWVsZC4gU2luY2Ugbm9u Y2UgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBQTiB0aGUganVtcHMgZG9u4oCZdCBhZGQgYW55IGNv bXBsZXhpdHkgdG8gdHJhbnNwb3J0IGxvZ2ljLiBKdW1wcyBhcmUgZm9yIGdyZWFzaW5nIGFuZCBw cmV2ZW50aW5nIG9zc2lmaWNhdGlvbi4gV2hlbiB0aGUgbm9uY2Ugcm9sbHMgb3ZlciBhbmQgcmVh Y2hlcyBjbG9zZSB0byB0aGUg4oCcc3RhcnRpbmcgdmFsdWXigJ0sIGtleSByb2xsb3ZlciBtdXN0 IGhhcHBlbi4gQXQgaGlnaCBkYXRhIHJhdGVzIHRoZSBub25jZSBmaWVsZCBjYW4gYmUgNjQtYml0 cyB0byBwcmV2ZW50IGZyZXF1ZW50IGtleSByb2xsb3Zlci4gRm9yIGNyeXB0byB0aGF0IGRvZXNu 4oCZdCBuZWVkIG5vbmNlcywgdGhlIGZpZWxkIGNhbiBiZSBvbWl0dGVkLg0KICAgICAqICAgTm8g b3NzaWZpY2F0aW9uIGJlY2F1c2UgdGhlcmUgaXMgbm8gcHJlLWRldGVybWluZWQgc2VxdWVuY2Ug dG8gdGhlIG5vbmNlLg0KICAgICAqICAgSW4gZ1FVSUMgYW5kIHRoZSBSRkMgYXMgZGVmaW5lZCB0 aGUgbm9uY2UgaXMgYSBzaW1wbGUgc2VxdWVuY2UgdGhhdCBpbmNyZW1lbnRzIGJ5IG9uZSwgc28g dGhpcyBpcyBubyB3b3JzZSBvZmYgaW4gdGVybXMgb2Ygc2VjdXJpdHkuIEl0IGlzIG5vbi1yZXBl YXRpbmcuDQogICAgICogICBObyBsaW5rYWJpbGl0eSBiZWNhdXNlIGRpZmZlcmVudCBwYXRocyBz dGFydCBhdCBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IHJhbmRvbSBudW1iZXIuIElmIHJlcGVhdGlu ZyBpcyBhIGNvbmNlcm4gdGhlbiBkaWZmZXJlbnQgcGF0aHMgdXNlIGRpZmZlcmVudCBrZXlzLiBD YXJyaWVzIGZvcndhcmQgdG8gbm90IGp1c3QgY29ubmVjdGlvbiBtaWdyYXRpb24gYnV0IG11dGxp LXBhdGguDQogICAgICogICBTdXBwb3J0cyBrZXkgcm9sbG92ZXIganVzdCBsaWtlIGdRVUlDIGFu ZCBjdXJyZW50bHkgZGVmaW5lZCBkcmFmdCBSRkMuDQogICAgICogICBBbGxvd3MgZm9yIG9taXR0 aW5nIHRoZSBub25jZSB3aGVuIHdlIHVzZSBjcnlwdG8gdGhhdCBkb2VzbuKAmXQgbmVlZCBpdC4N CiAgICAgKiAgIEFsbG93cyBmb3IgbGFyZ2VyIG5vbmNlcyBmb3IgaGlnaCBkYXRhIHJhdGVzLg0K ICAgICAqICAgSXQgZG9lc27igJl0IHByZWNsdWRlIGFueSBvdGhlciB0eXBlIG9mIG5vbi1yZXBl YXRpbmcgbm9uY2VzIHdpdGhvdXQgaGF2aW5nIHRvIG1vZGlmeSB0aGUgUkZDISBTbyBpbXBsZW1l bnRhdGlvbnMgdGhhdCB3YW50IHRvIHVzZSBjcnlwdG9ncmFwaGljIG5vbmNlcyBjYW4gc3RpbGwg ZG8gc28uDQoNClRoZSBkb3duc2lkZXM6DQoNCiAgMS4gIEV2ZW4gd2l0aCB2YXJpYWJsZSBsZW5n dGggZW5jb2RpbmcgdGhlIGV4dHJhIFBOIGZpZWxkIGlzIG1vcmUgc3BhY2UgdXNlZCBwZXIgcGFj a2V0IHdoZW4gYSBub25jZSBpcyByZXF1aXJlZC4gSSB0aGluayB3ZSBjYW4gZG8gd2l0aCAyIGJ5 dGVzIGluIHZlcnNpb24gMS4NCiAgMi4gIEl04oCZcyBub3QgcGVyZmVjdCB1bmxpbmthYmlsdGl5 IGJ1dCBJIGhhdmUgeWV0IHRvIHNlZSBhbnkgc29sdXRpb24gdGhhdCBjYW4gcHJvdmlkZSB0aGlz LiBBIHNpbXBsZSB0aW1lIGJhc2VkIGFuYWx5c2lzIHVzaW5nIG1hY2hpbmUgbGVhcm5pbmcgd2ls bCBhbGxvdyBmbG93IGNvcnJlbGF0aW9uIGVzcGVjaWFsbHkgZm9yIGNvbm5lY3Rpb24gbWlncmF0 aW9uLiBUaGUgSVAgYWRkcmVzc2VzIGluIHRoZSBjbGVhciBhbGxvdyBmb3IgYSBoaWdoIGRlZ3Jl ZSBvZiBjb3JyZWxhdGlvbi4gVGhlcmUgaXMgYWxzbyB0aGUgYXBwbGljYXRpb24gc2VuZGluZyBw YXR0ZXJuIGFuZCBvdGhlciBzaWduYWxzIHRoYXQgY291bGQgYmUgdXNlZC4NCg0KRnJvbTogRXJp YyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkg OSwgMjAxOCA1OjUyIEFNDQpUbzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jv c29mdC5jb20+DQpDYzogaHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IHF1aWNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KDQoNCk9uIFRodSwg RmViIDgsIDIwMTggYXQgOTo0MCBQTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1p Y3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkFjdHVhbGx5 IHRha2luZyBhIHN0ZXAgYmFjayB3aGF0IGlmIHdlIGRvbuKAmXQgd2Ugb3ZlcmxvYWRlZCBwYWNr ZXQgbnVtYmVyIGFzIHRoZSBub25jZT8NCg0KQ2FuIHdlOg0KDQogIDEuICBQdXQgcGFja2V0IG51 bWJlciBhcyBhIHNlcGFyYXRlIHZhcmlhYmxlIGxlbmd0aCBmaWVsZCBpbiB0aGUgZW5jcnlwdGVk IHBvcnRpb24gb2YgdGhlIGhlYWRlci4gVGhpcyBhbGxvd3MgZm9yIGdyb3d0aCBiZXlvbmQgNjQg Yml0cyBpbiBmdXR1cmUgYW5kIGNvbXBsZXRlbHkgYXZvaWRzIG9zc2lmaWNhdGlvbi4gRm9yIHNo b3J0IGxpdmVkIGZsb3dzIHZhcmlhYmxlIGxlbmd0aCBlbmNvZGluZyBsZWFkcyB0byBtaW5pbWFs IHNwYWNlIG92ZXJoZWFkLg0KICAyLiAgUHV0IGEgc2VwYXJhdGUgcGxhaW50ZXh0IG5vbmNlIHdo aWNoIHN0YXJ0cyBvdXQgYXMgYSBzZWN1cmUgcmFuZG9tIG51bWJlciBhbmQgbW9ub3RvbmljYWxs eSBpbmNyZWFzZXMgYXMgc2hvcnQgcmFuZG9tIGp1bXBzIChldmVyeSBwYWNrZXQgb3IgZXZlcnkg ZmV3IHBhY2tldHMpIGFuZCBjb3VsZCB0aGVuIHJvbGxvdmVyLiBUaGlzIHdpbGwgcHJldmVudCBs aW5rYWJpbGl0eSBhbmQgc2NhbGVzIHRvIG11bHRpLXBhdGggYXMgd2VsbC4gTm8gbWFqb3IgY29t cHV0ZSBvdmVyaGVhZC4gV2UgY2FuIGFsc28gbWFrZSB0aGUgbm9uY2Ugb3B0aW9uYWwgZm9yIGNy eXB0byBhbGdvcml0aG1zIHRoYXQgZG8gbm90IG5lZWQgYSBub25jZSBzYXZpbmcgbW9yZSBzcGFj ZS4NCg0KSSdtIG5vdCBzdXJlIGhvdyB0byBkbyAjMiBzYWZlbHkgYW5kIGVmZmljaWVudGx5LiBU aGUgcHJpbWFyeSBjb25jZXJuIGlzIHRoYXQgc2hvcnQgcmFuZG9tIGp1bXBzIGRvbid0IGFjdHVh bGx5IHByZXZlbnQgbGlua2FiaWxpdHkgYmVjYXVzZSB0aGUgaGlnaCBvcmRlciBiaXRzIGRvbid0 IGNoYW5nZSBhbmQgbG9uZyByYW5kb20ganVtcHMgYXJlIGVmZmVjdGl2ZWx5IHJhbmRvbWx5IHNh bXBsaW5nIG91dCBvZiB0aGUgbm9uY2Ugc3BhY2UsIGFuZCB5b3Ugc3RhcnQgdG8gcnVuIGludG8g YmlydGhkYXkgcHJvYmxlbXMuIEFkZGl0aW9uYWxseSwgdGhlIGNoZWFwZXN0IFBSTkdzIGFyZSBi YXNpY2FsbHkgY2lwaGVycyBpbiBjb3VudGVyIG1vZGUsIHNvIGF0IGJlc3QgeW91J3JlIGdvaW5n IHRvIGdldCBhIHNtYWxsIGFtb3VudCBvZiBvdmVyaGVhZCByZWR1Y3Rpb24gYnkgZ2V0dGluZyBt dWx0aXBsZSBqdW1wIGNvbXB1dGF0aW9ucyBvdXQgb2YgYSBzaW5nbGUgYmxvY2ssIHRob3VnaCBp ZiB5b3UgdXNlIDk2LWJpdCBqdW1wcywgeW91IG9ubHkgZ2V0IDI1JSBzYXZpbmdzLi4uDQoNCi1F a3INCg0KDQoNClNvbWUgTVNCIG9mIHRoZSBub25jZSBjb3VsZCBiZSB1c2VkIGZvciBzaWduYWxp bmcgcmVvcmRlciB0byB0aGUgbmV0d29yayBpZiBuZWVkZWQuIEkgZG9u4oCZdCBoYXZlIHRoZSBo aXN0b3JpY2FsIGNvbnRleHQgZm9yIG92ZXJsb2FkaW5nIG9mIFBOIGFzIHRoZSBub25jZSBzbyBw YXJkb24gbWUgaWYgdW4tb3ZlcmxvYWRpbmcgb3B0aW9uIHdhcyBkaXNjdXNzZWQgYW5kIHJ1bGVk IG91dCBiZWZvcmUuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBQcmF2ZWVuIEJhbGFz dWJyYW1hbmlhbg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggNTo1MSBQTQ0KVG86 IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+ PjsgcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBQYWNr ZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KPj4gYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBzZXF1 ZW5jZXMgZm9yIGVhY2ggcGF0aA0KVGhpcyBhbG9uZSBwcmV2ZW50cyBsaW5rYWJpbGl0eSByaWdo dD8NCg0KPj4gVGhlIHBhY2tldCBudW1iZXIgb24gZWFjaCBwYXRoIHdpbGwgc3RhcnQgYXQgMSAo b3IgbWF5YmUgMCA7LSkuDQpJcyBzdXBwb3J0aW5nIG11bHRpcGxlIHBhdGhzIGF0IHRoZSBzYW1l IHRpbWUgYSBnb2FsPyBJZiB5ZXMsIHRoZW4geWVzIGFsbCBwYXRocyB3aWxsIG5lZWQgdG8gaGF2 ZSBzZXBhcmF0ZSB0cmFja2luZyBhbmQgQUNLIHN0YXRlIGFuZCBjb25nZXN0aW9uIGNvbnRyb2wg ZXRjLiBJIHRob3VnaHQgdGhpcyBpcyBub3QgcGFydCBvZiBWMSBSRkMuIElmIGl0cyBqdXN0IG9u ZSBhZGRpdGlvbmFsIHBhdGggZm9yIGNvbm5lY3Rpb24gbWlncmF0aW9uIHNjZW5hcmlvIHRoZW4g YWxsIHlvdSBuZWVkIGlzIGEgKHJhbmRvbSkganVtcCB0byBhIG9mZnNldCBpbiBwYWNrZXQgbnVt YmVyIHNwYWNlIGZvciB0aGUgbmV3IHBhdGggc28gdGhhdCB0aGUgZmV3IHBhY2tldHMgaW4gdGhl IG9sZCBwYXRoIGNhbiBjb250aW51ZSBmb3IgYSBsaXR0bGUgYml0LiBUaGlzIHdvcmtzIHdpdGgg anVzdCBvbmUgQUNLIHNwYWNlIHNvIG5vIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuDQoNCj4+ IDIpIE9yLCBsZWF2aW5nIHRoZSBwYWNrZXQgbnVtYmVyIGluIHRoZSBjbGVhciBidXQgdXNpbmcg ZGlmZmVyZW50IGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgYW5kIHVzaW5nIHNl cGFyYXRlIHBhY2tldCBzZXF1ZW5jZXMgZm9yIGVhY2ggcGF0aC4NCkluIGFkZGl0aW9uIGlmIHRo ZSB2YWx1ZSBpbiB0aGUgY2xlYXIgd2FzIG9iZnVzY2F0ZWQgd2l0aCBhbiBYT1IgdHJhbnNmb3Jt IGl0IHdpbGwgaGVscCBwcmV2ZW50IG9zc2lmaWNhdGlvbi4gVGhlIG9iZnVzY2F0aW9uIGlzIG5v dCBtZWFudCB0byBndWFyZCBhZ2FpbnN0IGxhdGVyIGFuYWx5c2lzIHRoYXQgcmV2ZWFscyB0aGUg cGFja2V0IG51bWJlcnMgLSB3aHkgZG8gd2UgY2FyZSBhYm91dCB0aGF0LiBJdCBpcyBtZWFudCB0 byBncmVhc2UgdGhlIHNwYWNlIGFuZCBub3QgbWFrZSB0aGUgbnVtYmVycyBzZXJpYWwgc28gbWlk ZGxlYm94ZXMgY2Fubm90IGFzc3VtZSBvcmRlcmluZyBldGMuDQoNCkFsbCBzYWlkIGlmIEkgYW0g YWxvbmUgaW4gYmVpbmcgY29uY2VybmVkIGFib3V0IHRoZSBwZXJmIGhpdCB0aGVuIEnigJlkIHNh eSBnbyBvbiB3aXRoIG9wdGlvbiAxLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEh1aXRlbWENClNlbnQ6IFRodXJzZGF5 LCBGZWJydWFyeSA4LCAyMDE4IDM6NTQgUE0NClRvOiBxdWljQGlldGYub3JnPG1haWx0bzpxdWlj QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQoNCk9u IDIvOC8yMDE4IDE6MTMgUE0sIE1pa2UgQmlzaG9wIHdyb3RlOg0KIzIgd29u4oCZdCB3b3JrLiAg VGhlIHBhY2tldCBudW1iZXIgaXMgYW4gaW5wdXQgdG8gdGhlIEFFQUQgbm9uY2UsIHNvIHlvdSBo YXZlIHRvIGdldCB0byB0aGUgcGFja2V0IG51bWJlciBiZWZvcmUgeW91IGNhbiBkZWNyeXB0IHRo ZSBwYXlsb2FkLiAgSXQgY2Fu4oCZdCBiZSBiYXNlZCBvbiBhbnl0aGluZyBpbnRlcm5hbCB0byB0 aGUgZW5jcnlwdGVkIHBhY2tldC4NCg0KSW4gTWFydGlu4oCZcyBwcm9wb3NhbCwgaXTigJlzIHVz aW5nIGEgY29tYmluYXRpb24gb2YgdGhlIGVuY3J5cHRlZCBwYXlsb2FkICh3aGljaCByZXF1aXJl cyBub3RoaW5nIHRvIGFjY2VzcykgYW5kIHNvbWUgc3RvcmVkIHN0YXRlIG9uIGVhY2ggZW5kcG9p bnQsIHdoaWNoIHJlcXVpcmVzIG9ubHkgdGhlIENvbm5lY3Rpb24gSUQgdG8gbG9vayB1cC4gIFlv dSB3YW50IHRoZSB0aGluZyB5b3UgWE9SIGJ5IHRvIGJlIGNvbnN0YW50bHkgY2hhbmdpbmcsIG9y IGl0IGJlY29tZXMgZWFzaWVyIHRvIGxvb2sgYXQgc2VxdWVuY2VzIG9mIG9iZnVzY2F0ZWQgcGFj a2V0IG51bWJlcnMgYW5kIHN0YXJ0IGRyYXdpbmcgaW5mZXJlbmNlcyBhYm91dCB3aGF0IHRoZSBY T1IgdmFsdWUgaXMuICBJZiBvdmVyaGVhZCBpcyB0aGUgcHJpbWFyeSBjb25jZXJuLCBJIHRoaW5r IHRoZXJlIGFyZSBhIGNvdXBsZSBhcHByb2FjaGVzIHRoYXQgbWlnaHQgYWxsb3cgeW91IHRvIHBy ZWNvbXB1dGUgdmFsdWVzIGFuZCBhbW9ydGl6ZSB0aGUgY29zdCBvZiBkb2luZyB0aGUgZW5jcnlw dGlvbiBzdGVwLiAgKEF0IHRoZSBjb3N0IG9mIGtlZXBpbmcgdGhlIHRhYmxlIG9mIHByZWNvbXB1 dGVkIHZhbHVlcywgb2YgY291cnNlLikNCg0KSSBzdGlsbCB0aGluayBKYW5h4oCZcyBwdXNoaW5n IGluIHRoZSByaWdodCBkaXJlY3Rpb24gaGVyZTogIExldOKAmXMgYWdyZWUgb24gZ29hbHMsIGFu ZCB0aGVuIHNlZSBpZiB3ZSBjYW4gY3JhZnQgYSBkZXNpZ24gdGhhdCBtZWV0cyB0aG9zZSBnb2Fs cy4gIEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92ZXJoZWFkIGlzIGEgZ29hbCwgd2hpY2gg SSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiAgSSBhbHNvIHRoaW5rIEkgaGVhciB5b3Ugc2F5 aW5nIHRoYXQgMS0xLjUlIG92ZXJoZWFkIGlzIHRvbyBoaWdoLCBidXQgaXQgc291bmRzIGxpa2Ug dGhlcmXigJlzIGxlc3MgYWdyZWVtZW50IG9uIHRoYXQuICBZb3UgYWxzbyByYWlzZSBhbiBpbnRl cmVzdGluZyBwb2ludCB0aGF0IHNvbWUgY2xpZW50cyB3aWxsIGNhcmUgbGVzcyBhYm91dCBsaW5r YWJpbGl0eSBiZWNhdXNlIHRoZXkgd2lsbCBuZXZlciBpbnRlbnRpb25hbGx5IG1pZ3JhdGUuDQoN CkkgdGhpbmsgVmljdG9yIHNhaWQgaXQgYmVzdCwgIk9iZnVzY2F0aW9uIGlzIGp1c3QgZW5jcnlw dGlvbiBkb25lIHBvb3JseS4iIEVpdGhlciB3ZSBlbmNyeXB0LCBvciB3ZSBkb24ndC4gQnV0IHRo ZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgYW4gb2JmdXNjYXRpb24gbWlkZGxlLWdyb3VuZC4gT2Jm dXNjYXRpb24gd291bGQganVzdCBiZSBhIHNwZWVkIGJ1bXAsIGVhc2lseSBicm9rZW4uIEl0IHdv bid0IHByb3ZpZGUgcHJpdmFjeSwgYW5kIGl0IHdvbid0IHByZXZlbnQgbGlua2FiaWxpdHkuDQoN CkFzIGZhciBhcyBJIGFtIGNvbmNlcm5lZCwgdGhlcmUgYXJlIG9ubHkgdHdvIGRlc2lnbnMgdGhh dCBwcmV2ZW50IGxpbmthYmlsaXR5Og0KDQoxKSBNYXJ0aW4ncyBQUiwgaW4gd2hpY2ggdGhlIHBh Y2tldCBudW1iZXIgaXMgZW5jcnlwdGVkIHVzaW5nIHNlbnNpYmxlIGNyeXB0bzsNCg0KMikgT3Is IGxlYXZpbmcgdGhlIHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1dCB1c2luZyBkaWZmZXJl bnQgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQgdXNpbmcgc2VwYXJhdGUg cGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRoLg0KDQpUaGUgc2Vjb25kIG9wdGlvbiByZXF1 aXJlcyBtb3JlIGNvbXB1dGF0aW9uIHdoZW4gZXhwbGljaXRseSBzZXR0aW5nIHVwIGEgbmV3IHBh dGguIFRoZSBjb25uZWN0aW9uIElEIHdvdWxkIGJlIHVzZWQgYXMgcGFydCBvZiB0aGUgInNhbHQi IHdoZW4gZGVyaXZpbmcgY29ubmVjdGlvbiBjb250ZXh0cy4gVGhlIHBhY2tldCBudW1iZXIgb24g ZWFjaCBwYXRoIHdpbGwgc3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7LSkuIFRoaXMgcmVxdWlyZXMg bWFpbnRhaW5pbmcgc2VwYXJhdGUgU0FDSyBkYXNoYm9hcmRzIGZvciBlYWNoIHBhdGgvQ29ubmVj dGlvbi1JRCwgYW5kIGNvbnN0cmFpbmluZyBBQ0sgdG8gYmUgcGVyL3BhdGgsIG9yIGFsdGVybmF0 aXZlbHkgYWRkaW5nIGEgUEFUSC1BQ0sgZnJhbWUgdGhhdCBpbmRpY2F0ZXMgdGhlIHBhdGggZm9y IHdoaWNoIHBhY2tldHMgYXJlIGFja2VkLg0KDQpUaGUgcHJvcyBhbmQgY29ucyBvZiB0aGUgdHdv IG9wdGlvbnMgYXJlIGVhc3kgdG8gZ2V0Og0KDQoxKSBPcHRpb24gMiBkb2VzIG5vdCByZXF1aXJl IHRoZSBjb3N0IG9mIGVuY3J5cHRpbmcgZXZlcnkgcGFja2V0LCB0aHVzIHBlciBwYWNrZXQgcHJv Y2Vzc2luZyB3aWxsIGJlIG1heWJlIDElIGZhc3RlciB0aGFuIG9wdGlvbiAxLg0KDQoyKSBPcHRp b24gMiByZXF1aXJlcyBjb21wdXRpbmcgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRo LCB3aGljaCBpcyBtb3JlIGNvbXBsZXggdGhhbiBvcHRpb24gMSwgYnV0IHRoZSBjb3N0IHdpbGwg YmUgYW1vcnRpemVkIG92ZXIgdGhlIGR1cmF0aW9uIG9mIHRoZSBwYXRoLg0KDQozKSBPcHRpb24g MiByZXF1aXJlcyBtb3JlIGNvbXBsZXggZGF0YSBzdHJ1Y3R1cmVzIGFuZCBBQ0sgbWFuYWdlbWVu dCwgdGh1cyBpbmNyZWFzaW5nIHRoZSBjaGFuY2VzIHRoYXQgc29tZXRoaW5nIGdvZXMgd3Jvbmcu DQoNCjQpIE9wdGlvbiAyIGRvZXMgbm90aGluZyBhZ2FpbnN0IHBhY2tldCBudW1iZXIgb3NzaWZp Y2F0aW9uLiBUaGUgcGFja2V0IG51bWJlciBlZmZlY3RpdmVseSBiZWNvbWVzIHBhcnQgb2YgdGhl IGludmFyaWFudHMuDQoNCkluIHNob3J0LCB0aGUgb25seSBhZHZhbnRhZ2Ugb2Ygb3B0aW9uIDIg aXMgdG8gYXZvaWQgYSBzaW5nbGUgc3ltbWV0cmljIGVuY3J5cHRpb24gb3BlcmF0aW9uIHBlciBw YWNrZXQsIHdoaWxlIG1ha2luZyB0aGUgY29kZSBzaWduaWZpY2FudGx5IG1vcmUgY29tcGxleCwg YW5kIGF0IHRoZSBjb3N0IG9mIG5vdCBwcm90ZWN0aW5nIGFnYWluc3QgUE4gb3NzaWZpY2F0aW9u LiBUaGUgd2F5IEkgc2VlIHRoYXQsIHRoZXJlIGlzIGhhcmRseSBhbnkgZGViYXRlLg0KDQotLSBD aHJpc3RpYW4gSHVpdGVtYQ0KDQo= --_000_CY4PR21MB01337A5E81D8A8A1D7518D97B6F20CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1i b3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjQ4MTU4NDEyNTsNCgltc28tbGlz dC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTAxODk3NDQxMCA2NzY5ODcw MyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2 NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDo1MDUzNjQ5MTk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNDQ2NDUxNTU4O30NCkBsaXN0 IGwyDQoJe21zby1saXN0LWlkOjEwMjQ4NzAzMzQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDkwNjA4MTk2IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwy OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjps ZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjExOTQwNzg1OTc7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOi02NzI4NzE4MTg7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3Qt aWQ6MTM1NzM0NzcxNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE3NzIwNjIzMTA7fQ0KQGxp c3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWwy DQoJe21zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9w OjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBs aXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsNDpsZXZl bDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtdGFiLXN0 b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1pZDoxNTY0ODc1ODAzOw0KCW1zby1saXN0 LXRlbXBsYXRlLWlkczotODE3ODczMTY4O30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpv bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGV0IG1lIHRy eSB0byBzdW1tYXJpemUgdGhlIHByb3Bvc2FsIGFnYWluOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1saXN0OmwwIGxldmVsMSBsZm8zIj5QYWNrZXQgbnVtYmVyIGlzIGluIHRoZSBlbmNyeXB0 ZWQgcG9ydGlvbiBvZiB0aGUgaGVhZGVyIGFuZCBpcyBubyBsb25nZXIgdXNlZCBhcyB0aGUgbm9u Y2UuIEl0IGlzIGVuY29kZWQgYXMgYSB2YXJpYWJsZSBsZW5ndGggbnVtYmVyLiBBbHdheXMgc3Rh cnRzIGF0IDAuPG86cD48L286cD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIx IiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2 ZWwyIGxmbzMiPk5vIG9zc2lmaWNhdGlvbiBvZiBQTjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMiBsZm8zIj5ObyBsaW5rYWJpbGl0 eSB1c2luZyBQTjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1saXN0OmwwIGxldmVsMiBsZm8zIj5BbGxvd3MgZm9yIGdyb3d0aCBiZXlvbmQgNjQgYml0cyBp ZiBuZWVkZWQgaW4gZnV0dXJlPG86cD48L286cD48L2xpPjwvb2w+DQo8L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPlRoZSBub25jZSBpcyBp biB0aGUgY2xlYXIgaW4gcGxhaW50ZXh0IGhlYWRlci4gSXQgaXMgZ2VuZXJhdGVkDQo8aT5wZXIg cGF0aDwvaT4gYXMgYSBzZWN1cmUgcmFuZG9tIG51bWJlci4gQ2FsbCB0aGlzIHRoZSDigJxzdGFy dGluZyB2YWx1ZeKAnS4gQm90aCBzaWRlcyBNVVNUIGluaXRpYWxpemUgdGhlIOKAnHN0YXJ0aW5n IHZhbHVl4oCdIG5vbmNlDQo8aT5wZXIgcGF0aDwvaT4uIFdpdGhpbiBhIHBhdGggaXQgZ3Jvd3Mg bW9ub3RvbmljYWxseSAodG8gYXZvaWQgcmVwZWF0cyBqdXN0IGxpa2UgUE4gdG9kYXkpIGFuZCBj YW4gaW5jbHVkZSBzaG9ydCByYW5kb20ganVtcHMgcGVyaW9kaWNhbGx5IHNvIHRoYXQgbWlkZGxl Ym94ZXMgY2Fubm90IGFzc3VtZSBhbnl0aGluZyBhYm91dCB0aGUgZmllbGQuIFNpbmNlIG5vbmNl IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggUE4gdGhlIGp1bXBzIGRvbuKAmXQgYWRkDQogYW55IGNv bXBsZXhpdHkgdG8gdHJhbnNwb3J0IGxvZ2ljLiBKdW1wcyBhcmUgZm9yIGdyZWFzaW5nIGFuZCBw cmV2ZW50aW5nIG9zc2lmaWNhdGlvbi4gV2hlbiB0aGUgbm9uY2Ugcm9sbHMgb3ZlciBhbmQgcmVh Y2hlcyBjbG9zZSB0byB0aGUg4oCcc3RhcnRpbmcgdmFsdWXigJ0sIGtleSByb2xsb3ZlciBtdXN0 IGhhcHBlbi4gQXQgaGlnaCBkYXRhIHJhdGVzIHRoZSBub25jZSBmaWVsZCBjYW4gYmUgNjQtYml0 cyB0byBwcmV2ZW50IGZyZXF1ZW50IGtleQ0KIHJvbGxvdmVyLiBGb3IgY3J5cHRvIHRoYXQgZG9l c27igJl0IG5lZWQgbm9uY2VzLCB0aGUgZmllbGQgY2FuIGJlIG9taXR0ZWQuIDxvOnA+PC9vOnA+ DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iYSI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwwIGxldmVsMiBsZm8zIj5ObyBvc3NpZmlj YXRpb24gYmVjYXVzZSB0aGVyZSBpcyBubyBwcmUtZGV0ZXJtaW5lZCBzZXF1ZW5jZSB0byB0aGUg bm9uY2UuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxp c3Q6bDAgbGV2ZWwyIGxmbzMiPkluIGdRVUlDIGFuZCB0aGUgUkZDIGFzIGRlZmluZWQgdGhlIG5v bmNlIGlzIGEgc2ltcGxlIHNlcXVlbmNlIHRoYXQgaW5jcmVtZW50cyBieSBvbmUsIHNvIHRoaXMg aXMgbm8gd29yc2Ugb2ZmIGluIHRlcm1zIG9mIHNlY3VyaXR5LiBJdCBpcyBub24tcmVwZWF0aW5n LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omww IGxldmVsMiBsZm8zIj5ObyBsaW5rYWJpbGl0eSBiZWNhdXNlIGRpZmZlcmVudCBwYXRocyBzdGFy dCBhdCBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IHJhbmRvbSBudW1iZXIuIElmIHJlcGVhdGluZyBp cyBhIGNvbmNlcm4gdGhlbiBkaWZmZXJlbnQgcGF0aHMgdXNlIGRpZmZlcmVudCBrZXlzLiBDYXJy aWVzIGZvcndhcmQgdG8gbm90IGp1c3QgY29ubmVjdGlvbiBtaWdyYXRpb24gYnV0DQogbXV0bGkt cGF0aC4gPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxp c3Q6bDAgbGV2ZWwyIGxmbzMiPlN1cHBvcnRzIGtleSByb2xsb3ZlciBqdXN0IGxpa2UgZ1FVSUMg YW5kIGN1cnJlbnRseSBkZWZpbmVkIGRyYWZ0IFJGQy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+QWxsb3dzIGZvciBv bWl0dGluZyB0aGUgbm9uY2Ugd2hlbiB3ZSB1c2UgY3J5cHRvIHRoYXQgZG9lc27igJl0IG5lZWQg aXQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6 bDAgbGV2ZWwyIGxmbzMiPkFsbG93cyBmb3IgbGFyZ2VyIG5vbmNlcyBmb3IgaGlnaCBkYXRhIHJh dGVzLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxp c3Q6bDAgbGV2ZWwyIGxmbzMiPkl0IGRvZXNu4oCZdCBwcmVjbHVkZSBhbnkgb3RoZXIgdHlwZSBv ZiBub24tcmVwZWF0aW5nIG5vbmNlcyB3aXRob3V0IGhhdmluZyB0byBtb2RpZnkgdGhlIFJGQyEg U28gaW1wbGVtZW50YXRpb25zIHRoYXQgd2FudCB0byB1c2UgY3J5cHRvZ3JhcGhpYyBub25jZXMg Y2FuIHN0aWxsIGRvIHNvLg0KPG86cD48L286cD48L2xpPjwvb2w+DQo8L2xpPjwvb2w+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBkb3duc2lkZXM6PG86cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1saXN0OmwyIGxldmVsMSBsZm83Ij5FdmVuIHdpdGggdmFyaWFibGUgbGVuZ3RoIGVuY29kaW5n IHRoZSBleHRyYSBQTiBmaWVsZCBpcyBtb3JlIHNwYWNlIHVzZWQgcGVyIHBhY2tldCB3aGVuIGEg bm9uY2UgaXMgcmVxdWlyZWQuIEkgdGhpbmsgd2UgY2FuIGRvIHdpdGggMiBieXRlcyBpbiB2ZXJz aW9uIDEuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxp c3Q6bDIgbGV2ZWwxIGxmbzciPkl04oCZcyBub3QgcGVyZmVjdCB1bmxpbmthYmlsdGl5IGJ1dCBJ IGhhdmUgeWV0IHRvIHNlZSBhbnkgc29sdXRpb24gdGhhdCBjYW4gcHJvdmlkZSB0aGlzLiBBIHNp bXBsZSB0aW1lIGJhc2VkIGFuYWx5c2lzIHVzaW5nIG1hY2hpbmUgbGVhcm5pbmcgd2lsbCBhbGxv dyBmbG93IGNvcnJlbGF0aW9uIGVzcGVjaWFsbHkgZm9yIGNvbm5lY3Rpb24gbWlncmF0aW9uLg0K IFRoZSBJUCBhZGRyZXNzZXMgaW4gdGhlIGNsZWFyIGFsbG93IGZvciBhIGhpZ2ggZGVncmVlIG9m IGNvcnJlbGF0aW9uLiBUaGVyZSBpcyBhbHNvIHRoZSBhcHBsaWNhdGlvbiBzZW5kaW5nIHBhdHRl cm4gYW5kIG90aGVyIHNpZ25hbHMgdGhhdCBjb3VsZCBiZSB1c2VkLg0KPG86cD48L286cD48L2xp Pjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0 Zm0uY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSA5LCAyMDE4IDU6NTIg QU08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2YkBtaWNy b3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1h Lm5ldCZndDs7IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tldCBu dW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBGZWIgOCwgMjAxOCBh dCA5OjQwIFBNLCBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBy YXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5BY3R1YWxseSB0YWtpbmcgYSBzdGVwIGJhY2sgd2hhdCBpZiB3ZSBkb27igJl0IHdlIG92ZXJs b2FkZWQgcGFja2V0IG51bWJlciBhcyB0aGUgbm9uY2U/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5DYW4gd2U6PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNCBsZXZlbDEgbGZvMTAiPg0KUHV0IHBhY2tl dCBudW1iZXIgYXMgYSBzZXBhcmF0ZSB2YXJpYWJsZSBsZW5ndGggZmllbGQgaW4gdGhlIGVuY3J5 cHRlZCBwb3J0aW9uIG9mIHRoZSBoZWFkZXIuIFRoaXMgYWxsb3dzIGZvciBncm93dGggYmV5b25k IDY0IGJpdHMgaW4gZnV0dXJlIGFuZCBjb21wbGV0ZWx5IGF2b2lkcyBvc3NpZmljYXRpb24uIEZv ciBzaG9ydCBsaXZlZCBmbG93cyB2YXJpYWJsZSBsZW5ndGggZW5jb2RpbmcgbGVhZHMgdG8gbWlu aW1hbCBzcGFjZSBvdmVyaGVhZC4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0Omw0IGxldmVsMSBsZm8xMCI+DQpQdXQgYSBzZXBhcmF0ZSBwbGFpbnRleHQg bm9uY2Ugd2hpY2ggc3RhcnRzIG91dCBhcyBhIHNlY3VyZSByYW5kb20gbnVtYmVyIGFuZCBtb25v dG9uaWNhbGx5IGluY3JlYXNlcyBhcyBzaG9ydCByYW5kb20ganVtcHMgKGV2ZXJ5IHBhY2tldCBv ciBldmVyeSBmZXcgcGFja2V0cykgYW5kIGNvdWxkIHRoZW4gcm9sbG92ZXIuIFRoaXMgd2lsbCBw cmV2ZW50IGxpbmthYmlsaXR5IGFuZCBzY2FsZXMgdG8gbXVsdGktcGF0aCBhcyB3ZWxsLiBObyBt YWpvcg0KIGNvbXB1dGUgb3ZlcmhlYWQuIFdlIGNhbiBhbHNvIG1ha2UgdGhlIG5vbmNlIG9wdGlv bmFsIGZvciBjcnlwdG8gYWxnb3JpdGhtcyB0aGF0IGRvIG5vdCBuZWVkIGEgbm9uY2Ugc2F2aW5n IG1vcmUgc3BhY2UuPG86cD48L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIG5vdCBzdXJlIGhvdyB0 byBkbyAjMiBzYWZlbHkgYW5kIGVmZmljaWVudGx5LiBUaGUgcHJpbWFyeSBjb25jZXJuIGlzIHRo YXQgc2hvcnQgcmFuZG9tIGp1bXBzIGRvbid0IGFjdHVhbGx5IHByZXZlbnQgbGlua2FiaWxpdHkg YmVjYXVzZSB0aGUgaGlnaCBvcmRlciBiaXRzIGRvbid0IGNoYW5nZSBhbmQgbG9uZyByYW5kb20g anVtcHMgYXJlIGVmZmVjdGl2ZWx5IHJhbmRvbWx5IHNhbXBsaW5nIG91dCBvZg0KIHRoZSBub25j ZSBzcGFjZSwgYW5kIHlvdSBzdGFydCB0byBydW4gaW50byBiaXJ0aGRheSBwcm9ibGVtcy4gQWRk aXRpb25hbGx5LCB0aGUgY2hlYXBlc3QgUFJOR3MgYXJlIGJhc2ljYWxseSBjaXBoZXJzIGluIGNv dW50ZXIgbW9kZSwgc28gYXQgYmVzdCB5b3UncmUgZ29pbmcgdG8gZ2V0IGEgc21hbGwgYW1vdW50 IG9mIG92ZXJoZWFkIHJlZHVjdGlvbiBieSBnZXR0aW5nIG11bHRpcGxlIGp1bXAgY29tcHV0YXRp b25zIG91dCBvZiBhIHNpbmdsZQ0KIGJsb2NrLCB0aG91Z2ggaWYgeW91IHVzZSA5Ni1iaXQganVt cHMsIHlvdSBvbmx5IGdldCAyNSUgc2F2aW5ncy4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNvbWUgTVNCIG9mIHRoZSBub25j ZSBjb3VsZCBiZSB1c2VkIGZvciBzaWduYWxpbmcgcmVvcmRlciB0byB0aGUgbmV0d29yayBpZiBu ZWVkZWQuIEkgZG9u4oCZdCBoYXZlIHRoZSBoaXN0b3JpY2FsIGNvbnRleHQgZm9yIG92ZXJsb2Fk aW5nIG9mIFBOIGFzIHRoZSBub25jZSBzbyBwYXJkb24gbWUgaWYgdW4tb3ZlcmxvYWRpbmcNCiBv cHRpb24gd2FzIGRpc2N1c3NlZCBhbmQgcnVsZWQgb3V0IGJlZm9yZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwv Yj4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5QcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg RmVicnVhcnkgOCwgMjAxOCA1OjUxIFBNPGJyPg0KPGI+VG86PC9iPiBodWl0ZW1hICZsdDs8YSBo cmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmh1aXRlbWFA aHVpdGVtYS5uZXQ8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFBh Y2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZndDsmZ3Q7IGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZv ciBlYWNoIHBhdGg8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5UaGlzIGFsb25lIHByZXZlbnRzIGxpbmthYmlsaXR5IHJpZ2h0PzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZndDsgVGhlIHBhY2tldCBudW1iZXIgb24gZWFjaCBwYXRo IHdpbGwgc3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7LSkuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPklzIHN1cHBvcnRpbmcgbXVsdGlwbGUgcGF0aHMgYXQgdGhlIHNhbWUg dGltZSBhIGdvYWw/IElmIHllcywgdGhlbiB5ZXMgYWxsIHBhdGhzIHdpbGwgbmVlZCB0byBoYXZl IHNlcGFyYXRlIHRyYWNraW5nIGFuZCBBQ0sgc3RhdGUgYW5kIGNvbmdlc3Rpb24gY29udHJvbCBl dGMuIEkgdGhvdWdodCB0aGlzIGlzDQogbm90IHBhcnQgb2YgVjEgUkZDLiBJZiBpdHMganVzdCBv bmUgYWRkaXRpb25hbCBwYXRoIGZvciBjb25uZWN0aW9uIG1pZ3JhdGlvbiBzY2VuYXJpbyB0aGVu IGFsbCB5b3UgbmVlZCBpcyBhIChyYW5kb20pIGp1bXAgdG8gYSBvZmZzZXQgaW4gcGFja2V0IG51 bWJlciBzcGFjZSBmb3IgdGhlIG5ldyBwYXRoIHNvIHRoYXQgdGhlIGZldyBwYWNrZXRzIGluIHRo ZSBvbGQgcGF0aCBjYW4gY29udGludWUgZm9yIGEgbGl0dGxlIGJpdC4gVGhpcyB3b3Jrcw0KIHdp dGgganVzdCBvbmUgQUNLIHNwYWNlIHNvIG5vIGltcGxlbWVudGF0aW9uIGNvbXBsZXhpdHkuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7Jmd0OyAyKSBPciwgbGVhdmluZyB0aGUgcGFj a2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5nIGRpZmZlcmVudCBlbmNyeXB0aW9uIGNv bnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2Vz IGZvciBlYWNoIHBhdGguPGJyPg0KSW4gYWRkaXRpb24gaWYgdGhlIHZhbHVlIGluIHRoZSBjbGVh ciB3YXMgb2JmdXNjYXRlZCB3aXRoIGFuIFhPUiB0cmFuc2Zvcm0gaXQgd2lsbCBoZWxwIHByZXZl bnQgb3NzaWZpY2F0aW9uLiBUaGUgb2JmdXNjYXRpb24gaXMgbm90IG1lYW50IHRvIGd1YXJkIGFn YWluc3QgbGF0ZXIgYW5hbHlzaXMgdGhhdCByZXZlYWxzIHRoZSBwYWNrZXQgbnVtYmVycyAtIHdo eSBkbyB3ZSBjYXJlIGFib3V0IHRoYXQuIEl0IGlzIG1lYW50IHRvIGdyZWFzZSB0aGUNCiBzcGFj ZSBhbmQgbm90IG1ha2UgdGhlIG51bWJlcnMgc2VyaWFsIHNvIG1pZGRsZWJveGVzIGNhbm5vdCBh c3N1bWUgb3JkZXJpbmcgZXRjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QWxsIHNhaWQg aWYgSSBhbSBhbG9uZSBpbiBiZWluZyBjb25jZXJuZWQgYWJvdXQgdGhlIHBlcmYgaGl0IHRoZW4g SeKAmWQgc2F5IGdvIG9uIHdpdGggb3B0aW9uIDEuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUVVJQyBb PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5DaHJp c3RpYW4gSHVpdGVtYTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgRmVicnVhcnkgOCwgMjAx OCAzOjU0IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+T24gMi84 LzIwMTggMToxMyBQTSwgTWlrZSBCaXNob3Agd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+IzIgd29u4oCZdCB3b3JrLiZuYnNwOyBUaGUgcGFja2V0IG51bWJl ciBpcyBhbiBpbnB1dCB0byB0aGUgQUVBRCBub25jZSwgc28geW91IGhhdmUgdG8gZ2V0IHRvIHRo ZSBwYWNrZXQgbnVtYmVyIGJlZm9yZSB5b3UgY2FuIGRlY3J5cHQgdGhlIHBheWxvYWQuJm5ic3A7 IEl0IGNhbuKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcgaW50ZXJuYWwNCiB0byB0aGUgZW5jcnlw dGVkIHBhY2tldC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIE1hcnRpbuKAmXMgcHJv cG9zYWwsIGl04oCZcyB1c2luZyBhIGNvbWJpbmF0aW9uIG9mIHRoZSBlbmNyeXB0ZWQgcGF5bG9h ZCAod2hpY2ggcmVxdWlyZXMgbm90aGluZyB0byBhY2Nlc3MpIGFuZCBzb21lIHN0b3JlZCBzdGF0 ZSBvbiBlYWNoIGVuZHBvaW50LCB3aGljaCByZXF1aXJlcyBvbmx5IHRoZSBDb25uZWN0aW9uDQog SUQgdG8gbG9vayB1cC4mbmJzcDsgWW91IHdhbnQgdGhlIHRoaW5nIHlvdSBYT1IgYnkgdG8gYmUg Y29uc3RhbnRseSBjaGFuZ2luZywgb3IgaXQgYmVjb21lcyBlYXNpZXIgdG8gbG9vayBhdCBzZXF1 ZW5jZXMgb2Ygb2JmdXNjYXRlZCBwYWNrZXQgbnVtYmVycyBhbmQgc3RhcnQgZHJhd2luZyBpbmZl cmVuY2VzIGFib3V0IHdoYXQgdGhlIFhPUiB2YWx1ZSBpcy4mbmJzcDsgSWYgb3ZlcmhlYWQgaXMg dGhlIHByaW1hcnkgY29uY2VybiwgSSB0aGluayB0aGVyZSBhcmUNCiBhIGNvdXBsZSBhcHByb2Fj aGVzIHRoYXQgbWlnaHQgYWxsb3cgeW91IHRvIHByZWNvbXB1dGUgdmFsdWVzIGFuZCBhbW9ydGl6 ZSB0aGUgY29zdCBvZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVwLiZuYnNwOyAoQXQgdGhlIGNv c3Qgb2Yga2VlcGluZyB0aGUgdGFibGUgb2YgcHJlY29tcHV0ZWQgdmFsdWVzLCBvZiBjb3Vyc2Uu KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSBzdGlsbCB0aGluayBKYW5h4oCZcyBwdXNo aW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24gaGVyZTombmJzcDsgTGV04oCZcyBhZ3JlZSBvbiBn b2FscywgYW5kIHRoZW4gc2VlIGlmIHdlIGNhbiBjcmFmdCBhIGRlc2lnbiB0aGF0IG1lZXRzIHRo b3NlIGdvYWxzLiZuYnNwOyBJIGhlYXIgeW91IHNheWluZyB0aGF0IGxvdyBvdmVyaGVhZA0KIGlz IGEgZ29hbCwgd2hpY2ggSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiZuYnNwOyBJIGFsc28g dGhpbmsgSSBoZWFyIHlvdSBzYXlpbmcgdGhhdCAxLTEuNSUgb3ZlcmhlYWQgaXMgdG9vIGhpZ2gs IGJ1dCBpdCBzb3VuZHMgbGlrZSB0aGVyZeKAmXMgbGVzcyBhZ3JlZW1lbnQgb24gdGhhdC4mbmJz cDsgWW91IGFsc28gcmFpc2UgYW4gaW50ZXJlc3RpbmcgcG9pbnQgdGhhdCBzb21lIGNsaWVudHMg d2lsbCBjYXJlIGxlc3MgYWJvdXQgbGlua2FiaWxpdHkgYmVjYXVzZQ0KIHRoZXkgd2lsbCBuZXZl ciBpbnRlbnRpb25hbGx5IG1pZ3JhdGUuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxicj4NCkkgdGhpbmsgVmljdG9yIHNhaWQgaXQgYmVzdCwgJnF1b3Q7 T2JmdXNjYXRpb24gaXMganVzdCBlbmNyeXB0aW9uIGRvbmUgcG9vcmx5LiZxdW90OyBFaXRoZXIg d2UgZW5jcnlwdCwgb3Igd2UgZG9uJ3QuIEJ1dCB0aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGFu IG9iZnVzY2F0aW9uIG1pZGRsZS1ncm91bmQuIE9iZnVzY2F0aW9uIHdvdWxkIGp1c3QgYmUgYSBz cGVlZCBidW1wLCBlYXNpbHkgYnJva2VuLiBJdCB3b24ndCBwcm92aWRlIHByaXZhY3ksIGFuZCBp dCB3b24ndA0KIHByZXZlbnQgbGlua2FiaWxpdHkuPGJyPg0KPGJyPg0KQXMgZmFyIGFzIEkgYW0g Y29uY2VybmVkLCB0aGVyZSBhcmUgb25seSB0d28gZGVzaWducyB0aGF0IHByZXZlbnQgbGlua2Fi aWxpdHk6PGJyPg0KPGJyPg0KMSkgTWFydGluJ3MgUFIsIGluIHdoaWNoIHRoZSBwYWNrZXQgbnVt YmVyIGlzIGVuY3J5cHRlZCB1c2luZyBzZW5zaWJsZSBjcnlwdG87PGJyPg0KPGJyPg0KMikgT3Is IGxlYXZpbmcgdGhlIHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1dCB1c2luZyBkaWZmZXJl bnQgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQgdXNpbmcgc2VwYXJhdGUg cGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRoLjxicj4NCjxicj4NClRoZSBzZWNvbmQgb3B0 aW9uIHJlcXVpcmVzIG1vcmUgY29tcHV0YXRpb24gd2hlbiBleHBsaWNpdGx5IHNldHRpbmcgdXAg YSBuZXcgcGF0aC4gVGhlIGNvbm5lY3Rpb24gSUQgd291bGQgYmUgdXNlZCBhcyBwYXJ0IG9mIHRo ZSAmcXVvdDtzYWx0JnF1b3Q7IHdoZW4gZGVyaXZpbmcgY29ubmVjdGlvbiBjb250ZXh0cy4gVGhl IHBhY2tldCBudW1iZXIgb24gZWFjaCBwYXRoIHdpbGwgc3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7 LSkuIFRoaXMgcmVxdWlyZXMgbWFpbnRhaW5pbmcNCiBzZXBhcmF0ZSBTQUNLIGRhc2hib2FyZHMg Zm9yIGVhY2ggcGF0aC9Db25uZWN0aW9uLUlELCBhbmQgY29uc3RyYWluaW5nIEFDSyB0byBiZSBw ZXIvcGF0aCwgb3IgYWx0ZXJuYXRpdmVseSBhZGRpbmcgYSBQQVRILUFDSyBmcmFtZSB0aGF0IGlu ZGljYXRlcyB0aGUgcGF0aCBmb3Igd2hpY2ggcGFja2V0cyBhcmUgYWNrZWQuPGJyPg0KPGJyPg0K VGhlIHByb3MgYW5kIGNvbnMgb2YgdGhlIHR3byBvcHRpb25zIGFyZSBlYXN5IHRvIGdldDo8YnI+ DQo8YnI+DQoxKSBPcHRpb24gMiBkb2VzIG5vdCByZXF1aXJlIHRoZSBjb3N0IG9mIGVuY3J5cHRp bmcgZXZlcnkgcGFja2V0LCB0aHVzIHBlciBwYWNrZXQgcHJvY2Vzc2luZyB3aWxsIGJlIG1heWJl IDElIGZhc3RlciB0aGFuIG9wdGlvbiAxLg0KPGJyPg0KPGJyPg0KMikgT3B0aW9uIDIgcmVxdWly ZXMgY29tcHV0aW5nIGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgd2hpY2ggaXMg bW9yZSBjb21wbGV4IHRoYW4gb3B0aW9uIDEsIGJ1dCB0aGUgY29zdCB3aWxsIGJlIGFtb3J0aXpl ZCBvdmVyIHRoZSBkdXJhdGlvbiBvZiB0aGUgcGF0aC48YnI+DQo8YnI+DQozKSBPcHRpb24gMiBy ZXF1aXJlcyBtb3JlIGNvbXBsZXggZGF0YSBzdHJ1Y3R1cmVzIGFuZCBBQ0sgbWFuYWdlbWVudCwg dGh1cyBpbmNyZWFzaW5nIHRoZSBjaGFuY2VzIHRoYXQgc29tZXRoaW5nIGdvZXMgd3JvbmcuPGJy Pg0KPGJyPg0KNCkgT3B0aW9uIDIgZG9lcyBub3RoaW5nIGFnYWluc3QgcGFja2V0IG51bWJlciBv c3NpZmljYXRpb24uIFRoZSBwYWNrZXQgbnVtYmVyIGVmZmVjdGl2ZWx5IGJlY29tZXMgcGFydCBv ZiB0aGUgaW52YXJpYW50cy48YnI+DQo8YnI+DQpJbiBzaG9ydCwgdGhlIG9ubHkgYWR2YW50YWdl IG9mIG9wdGlvbiAyIGlzIHRvIGF2b2lkIGEgc2luZ2xlIHN5bW1ldHJpYyBlbmNyeXB0aW9uIG9w ZXJhdGlvbiBwZXIgcGFja2V0LCB3aGlsZSBtYWtpbmcgdGhlIGNvZGUgc2lnbmlmaWNhbnRseSBt b3JlIGNvbXBsZXgsIGFuZCBhdCB0aGUgY29zdCBvZiBub3QgcHJvdGVjdGluZyBhZ2FpbnN0IFBO IG9zc2lmaWNhdGlvbi4gVGhlIHdheSBJIHNlZSB0aGF0LCB0aGVyZSBpcyBoYXJkbHkgYW55IGRl YmF0ZS48YnI+DQo8YnI+DQotLSBDaHJpc3RpYW4gSHVpdGVtYTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY4PR21MB01337A5E81D8A8A1D7518D97B6F20CY4PR21MB0133namp_-- From nobody Fri Feb 9 09:42:56 2018 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 DCCE9120454 for ; Fri, 9 Feb 2018 09:42:54 -0800 (PST) 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, 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 6FcbKdD0J8_D for ; Fri, 9 Feb 2018 09:42:53 -0800 (PST) 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 50CF01201F8 for ; Fri, 9 Feb 2018 09:42:53 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w19HgQ0i006024; Fri, 9 Feb 2018 17:42:26 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=elgd0YQE5rCYVQ3MwHPKz4ZajBm6OSbyqaXkwKvBqq8=; b=eqHvG8AN3HbnazRmzanwJluAAJ7WBFGsoAN2l67GqMdTCOpvSM2zGkVZpKjGEpM0NhdE wN5yH7j59p8IKBsS+MrZ3otwR48x8n3IkDfhpIpJUo5EVhGySKm2xOhLztrsIkxOR9sA 0FywlvlyMYdLHMErAlbi6fgsJqP8QD0KuVgQbMaOkumhpBH9wXn54sKcCK29zJuVh/8J TyPBDxGsZOShhOWPQ+dImRxqOh25dqkH3mhfDRkmpz5Ix1gE2Zfy9Hd1FMDlQw2+VPyK aDsu3VbD5afNmy7Z1Lmrd4RxITsxV3i10DvHwgSFG6yaKZ6O7jAps6nkBJsvOxkgYpX6 EA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0b-00190b01.pphosted.com with ESMTP id 2g0x242h66-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2018 17:42:26 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w19HeiTJ027007; Fri, 9 Feb 2018 12:42:25 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2fw9a19h90-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2018 12:42:25 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 9 Feb 2018 12:42:24 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 9 Feb 2018 12:42:23 -0500 From: "Salz, Rich" To: Praveen Balasubramanian , Eric Rescorla CC: "quic@ietf.org" , huitema Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31Be9MxlVQxEqrVhXIOG6b4KOM1RYAgABeoICAAAgVAIAAd3KAgAA8YgCAACPDAIAAAicAgAOBloCAALfcgIAACBoAgAEGFwCAANx+AIAAn5GAgAB7xICAADUigIAADBaAgADXOgCAAGaugIAAEEkAgACizACAADhiAIAAHkiAgAADUYCAACdEAIAAVRYAgAAUZgCAAA5oAIAAEIEAgABFkgCAAAUSgIAABUkAgAABmYCAAAaRgIAAC4qAgACi8ACAAe5ygIAACzgAgAAgsACAAEARAIAAiWKAgAA/NwD//61lgA== Date: Fri, 9 Feb 2018 17:42:23 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.80] Content-Type: multipart/alternative; boundary="_000_D3800B30E1F549558F856FEF36AD2E23akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=787 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090224 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_09:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=741 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090224 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, 09 Feb 2018 17:42:55 -0000 --_000_D3800B30E1F549558F856FEF36AD2E23akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgc3VtbWFyeS4gIFdoeSBkbyB5b3Ugd2FudCB0byBkbyB0aGlzPw0KDQo= --_000_D3800B30E1F549558F856FEF36AD2E23akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <4291B26160A89240985BF7195DC0A6DA@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIj MDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgc3VtbWFyeS4mbmJzcDsgV2h5IGRvIHlv dSB3YW50IHRvIGRvIHRoaXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D3800B30E1F549558F856FEF36AD2E23akamaicom_-- From nobody Fri Feb 9 09:48:19 2018 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 1028A12D7F9 for ; Fri, 9 Feb 2018 09:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 qaS5JDH4sQQj for ; Fri, 9 Feb 2018 09:48:11 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 5C72D12D7F6 for ; Fri, 9 Feb 2018 09:48:11 -0800 (PST) Received: from mail-ot0-f171.google.com (mail-ot0-f171.google.com [74.125.82.171]) by linode64.ducksong.com (Postfix) with ESMTPSA id C14D93A019 for ; Fri, 9 Feb 2018 12:48:10 -0500 (EST) Received: by mail-ot0-f171.google.com with SMTP id e64so8455503ote.4 for ; Fri, 09 Feb 2018 09:48:10 -0800 (PST) X-Gm-Message-State: APf1xPBeNvkJaURL0GKFyT0iVFt5BR9Xt9EDsBQLtkrL5gDQYzM1njT3 5g6UmuJjoriNGfZG6EPuh4vE1SYpLEigA5ftzBM= X-Google-Smtp-Source: AH8x224FjJtqmgUj/SohbiohOSdkpxw5mOBNULPQMRl4ZyvqVW0LkEEMrNpuoa9suveDiqoTSZmCPlbsDIFAgAalu/0= X-Received: by 10.157.81.197 with SMTP id d5mr2971535oth.300.1518198490481; Fri, 09 Feb 2018 09:48:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.95.80 with HTTP; Fri, 9 Feb 2018 09:48:09 -0800 (PST) From: Patrick McManus Date: Fri, 9 Feb 2018 12:48:09 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: The Recovery Period To: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403043d7ef0b94b7a0564cb2148" 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, 09 Feb 2018 17:48:13 -0000 --f403043d7ef0b94b7a0564cb2148 Content-Type: text/plain; charset="UTF-8" Hi All, 4.3 of the recovery draft: Recovery is a period of time beginning with detection of a lost packet. Because QUIC retransmits stream data and control frames, not packets, it defines the end of recovery as a packet sent after the start of recovery being acknowledged. and then in 4.7.2 end_of_recovery: The largest packet number sent when QUIC detects a loss. When a larger packet is acknowledged, QUIC exits recovery. and then in 4.7.6 OnPacketsLost() [...] end_of_recovery = largest_sent_packet I think these are inconsistent.. essentially 4.7.2 and 4.7.6 should be "next packet number sent" not "largest currently sent" - true? --f403043d7ef0b94b7a0564cb2148 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

4.3 of the recovery = draft:

Recovery is a p= eriod of time beginning with detection of a lost packet.=20 Because QUIC retransmits stream data and control frames, not packets,=20 it defines the end of recovery as a packet sent after the start of=20 recovery being acknowledged.=C2=A0

and then= in 4.7.2

end_of_recovery:
The largest pack= et number sent when QUIC detects a loss. When a larger packet is acknowled= ged, QUIC exits recovery.

and then in 4.7.6
= 
OnPacketsLost() [...]
=C2=A0end_of_recovery =3D lar=
gest_sent_packet
I think these are inconsistent.. essential= ly 4.7.2 and 4.7.6 should be "next packet number sent" not "= largest currently sent" - true?




--f403043d7ef0b94b7a0564cb2148-- From nobody Fri Feb 9 09:56:27 2018 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 AFA1712D778 for ; Fri, 9 Feb 2018 09:56:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=evequefou.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 8p16_hDTqDln for ; Fri, 9 Feb 2018 09:56:21 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0098.outbound.protection.outlook.com [104.47.33.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884BF1201F8 for ; Fri, 9 Feb 2018 09:56:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oS79Ssd8nOc2AJbTXFDDYrqwzz8K7I0Z69L3C164rlY=; b=K+zYJ3LdEwon39imSgUkbYV9tHIFbbhtrnxhrMN0g9BkZX+P4uuQlTx4PtYabOrYr9NBMru7364xDM7eO5Vvv3EgMT6+iuxMbyMk1xX5tF6Udwhj37YzpeDdCCrWaYj2cBK6/ndMgpVIp4DZsihNWqX1RhCVYKkoJXKWnraIOzs= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB3342.namprd08.prod.outlook.com (10.164.192.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Fri, 9 Feb 2018 17:56:15 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([fe80::5410:deca:3ee5:983f]) by MWHPR08MB2432.namprd08.prod.outlook.com ([fe80::5410:deca:3ee5:983f%16]) with mapi id 15.20.0485.009; Fri, 9 Feb 2018 17:56:15 +0000 From: Mike Bishop To: Lucas Pardue , Martin Thomson , QUIC WG Subject: RE: Review of QCRAM Thread-Topic: Review of QCRAM Thread-Index: AQHToY4AwuLQ2LxqoUij8/v50HkPW6Ob5KiAgABxEPA= Date: Fri, 9 Feb 2018 17:56:15 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAD6C5A@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAD6C5A@bgb01xud1012> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [12.130.119.134] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB3342; 7:1KXWjW4FQvLia5ErXkNSLDVsyQqpUepIjT15ZLOGxzG9KgUI+MWJ58wLi9RNXWrWcCRMwJZd8jaaZT9ff28aPHvZV4qW6V19cFBO5L1MFXa/B92rrXYqg2QYyKeRaQHSN5vfcSSZI5sLHAk1LkidniNXB0iozKWkQyi2zgRxxT5IaqXVyH7K0GZn8Zjl5q+ezUCED9YwxRaHV7s53EFvmsMq28VCkYjUXoAUGU4Bb13Zajk1xhSfoDKB5tyqF95D x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9411d8f1-3cb8-41cc-32f7-08d56fe66a43 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB3342; x-ms-traffictypediagnostic: MWHPR08MB3342: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(85827821059158)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(6041288)(20161123560045)(20161123564045)(20161123562045)(2016111802025)(20161123558120)(6043046)(6072148)(201708071742011); SRVR:MWHPR08MB3342; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB3342; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(346002)(376002)(366004)(39380400002)(396003)(13464003)(52314003)(51444003)(199004)(189003)(186003)(68736007)(3480700004)(2900100001)(99286004)(105586002)(6436002)(606006)(86362001)(106356001)(2906002)(966005)(6346003)(8936002)(102836004)(26005)(478600001)(55016002)(7736002)(2950100002)(59450400001)(66066001)(53546011)(229853002)(6506007)(81156014)(39060400002)(74316002)(14454004)(7116003)(25786009)(5660300001)(76176011)(81166006)(7696005)(5250100002)(74482002)(3280700002)(8676002)(33656002)(790700001)(97736004)(3846002)(6116002)(53936002)(236005)(6306002)(54896002)(6246003)(9686003)(3660700001)(316002)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB3342; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-microsoft-antispam-message-info: zIj4nEP6W8jnK/OOzkUCOqiYcrHN1YufbeMcEDv3gWEWttl3+puXBPMkZ26XBj/EkTagl5yE05B1z9fZQqIe2A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB24321A1087F2D7CC7EA46F36DAF20MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 9411d8f1-3cb8-41cc-32f7-08d56fe66a43 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 17:56:15.7649 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB3342 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, 09 Feb 2018 17:56:26 -0000 --_000_MWHPR08MB24321A1087F2D7CC7EA46F36DAF20MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBkb2luZyB0aGlzLCBNYXJ0aW4uICBJJ3ZlIGJlZW4gd2FpdGluZyBmb3IgdGhl IGFkb3B0aW9uIGNhbGwgdG8gYmUgZm9ybWFsbHkgY29uY2x1ZGVkIGJlZm9yZSBJIHN0YXJ0ZWQg YnJpbmdpbmcgdGhlIGxhdW5kcnkgbGlzdCBvZiBpbXByb3ZlbWVudHMsIGJ1dCBteSBvd24gYWxp Z25zIHdpdGggeW91cnM6DQoNCiAgKiAgIFRocmVlLWxheWVyZWQgc3RyZWFtIG1vZGVsLCBkaXN0 aW5jdCBpbnN0cnVjdGlvbiBzcGFjZXMgb24gZWFjaCBzdHJlYW0NCiAgKiAgIENvbnNpZGVyIGNo YW5naW5nIGZyb20gdGhlIHN0YXRpYy1hdC1mcm9udCBtb2RlbCB0byBhIHN0YXRpYy9keW5hbWlj IGJpdCBhbmQgYSBzaG9ydGVyIHJlZmVyZW5jZQ0KICAgICAqICAgVGhpcyB3b3VsZCBtYWtlIGEg bGFyZ2VyIHN0YXRpYyB0YWJsZSBtb3JlIHBhbGF0YWJsZSwgYW5kIHNlZW1zIHRvIGJyZWFrIGV2 ZW4gZm9yIGR5bmFtaWMgZW50cmllcyBpbiB0aGUgZGlzdGluY3QgaW5zdHJ1Y3Rpb24gc3BhY2Vz DQoNCg0KDQpZb3VyIG9ic2VydmF0aW9uIHRoYXQgeW914oCZcmUga2VlcGluZyBhIHR1cGxlIG9m IHN0cmVhbS1ibG9ja251bSBvbiBlYWNoIGVudHJ5IGlzIGludGVyZXN0aW5nLiAgQ2FuIHlvdSBn byBpbnRvIG1vcmUgZGV0YWlsIHdoZXJlIHRoaXMgaXM/ICBDb3VsZG7igJl0IHlvdSBhbHNvIGtl ZXAgYSBzaW1wbGUgcmVmY291bnQgb2Ygb3V0c3RhbmRpbmcgYmxvY2tzLCB0aGVuIHNlcGFyYXRl bHkgdHJhY2sgd2hpY2ggZW50cmllcyBhcmUgcmVmZXJlbmNlZCBieSBvdXRzdGFuZGluZyBibG9j a3M/ICBJSVJDLCBpbiBRQ1JBTSB0aGVyZeKAmXMgbm90IGEgc2l0dWF0aW9uIGluIHdoaWNoIHlv dSBuZWVkIHRvIGRldGVybWluZSB3aGljaCBvdXRzdGFuZGluZyBoZWFkZXIgYmxvY2sgaXMgYmxv Y2tpbmcgZXZpY3Rpb24sIG9ubHkgd2hldGhlciBhbiBvdXRzdGFuZGluZyBIRUFERVJTIGZyYW1l IGJsb2NrcyBldmljdGlvbi4gIE9yIGFtIEkgbWlzdW5kZXJzdGFuZGluZyB3aGVyZSB5b3XigJly ZSBrZWVwaW5nIHRoZSB0dXBsZT8NCg0KDQoNCk9mIGNvdXJzZSwgYSBkaWN0aW9uYXJ5IG9mIHF1 ZXVlcyBtaWdodCBiZSBtb3JlIGV4cGVuc2l2ZSB0aGFuIGp1c3Qgc3RvcmluZyB0aGUgdHVwbGUs IGJ1dCBJIGJlbGlldmUgeW91IG5lZWQgc29tZXRoaW5nIGxpa2UgdGhhdCByZWdhcmRsZXNzIHNv IHlvdSBjYW4gZmluZCB0aGUgZW50cmllcyB5b3UgbmVlZCB0byByZW1vdmUgdGhlIG91dHN0YW5k aW5nIHJlZmVyZW5jZSBmcm9tLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMdWNh cyBQYXJkdWUNClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgOSwgMjAxOCAyOjUxIEFNDQpUbzogTWFy dGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSRTogUmV2aWV3IG9mIFFDUkFNDQoNCg0KDQpIaSBNYXJ0aW4sDQoN Cg0KDQpWZXJ5IGludGVyZXN0aW5nLCB0aGFua3MuDQoNCg0KDQpHaXZlbiB0aGF0IHlvdXIgaW1w bGVtZW50YXRpb24gc3VwcG9ydHMgYm90aCBIUEFDSyBhbmQgUUNSQU0sIGRvIHlvdSBoYXZlIGFu eSBvcGluaW9uIGhvdyBtdWNoIHBhaW4gaXQgd291bGQgYmUgdG8gaGF2ZSBkaWZmZXJlbnQgc3Rh dGljIHRhYmxlcyBiZXR3ZWVuIHRoZW0/DQoNCg0KDQpSZWdhcmRzDQoNCkx1Y2FzDQoNCg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1hcnRpbiBUaG9tc29uDQoNCj4gU2VudDog MDkgRmVicnVhcnkgMjAxOCAxMDowOQ0KDQo+IFRvOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1h aWx0bzpxdWljQGlldGYub3JnPj4NCg0KPiBTdWJqZWN0OiBSZXZpZXcgb2YgUUNSQU0NCg0KPg0K DQo+IEkgaGF2ZSBpbXBsZW1lbnRlZCBRQ1JBTSBhbmQgaGF2ZSBhIGZldyB0aGluZ3MgdG8gY29t bWVudCBvbi4NCg0KPg0KDQo+IE15IGltcGxlbWVudGF0aW9uIGlzIGhlcmU6DQoNCj4gICBodHRw czovL2dpdGh1Yi5jb20vbWFydGludGhvbXNvbi9taW5ocS90cmVlL21hc3Rlci9oYw0KDQo+DQoN Cj4gVGhpcyBpcyBteSBmaXJzdCBhdHRlbXB0IGF0IGdvLCBzbyB0aGlzIHRvb2sgYSBsaXR0bGUg bG9uZ2VyIHRoYW4gaXQNCg0KPiBtaWdodCBoYXZlIG90aGVyd2lzZS4gVGVzdCBjb3ZlcmFnZSBp cyBzdGlsbCBhIGxpdHRsZSBsaWdodCwgdGhvdWdoIGdvDQoNCj4gdGhpbmtzIHRoYXQgSSBoYXZl IHByZXR0eSBnb29kIGNvdmVyYWdlLiBUaGVyZSdzIHByb2JhYmx5IHN0aWxsIGEgbG90DQoNCj4g dG8gZ28gb24gdGhlIGNvcm5lciBjYXNlcywgYnV0IEkgdGhpbmsgdGhhdCBJJ3ZlIGRvbmUgZW5v dWdoIHRvIGdldCBhbiBpZGVhIGZvciB0aGUgY29tcGxleGl0eSBidW1wLg0KDQo+DQoNCj4gSSBz dGFydGVkIGJ5IGltcGxlbWVudGluZyBIUEFDSywgd2hpY2ggaXMgc3VycHJpc2luZ2x5IGVhc3kg aWYgeW91DQoNCj4gZG9uJ3QgY2FyZSBhYm91dCBiZWluZyBlZmZpY2llbnQuIFRob3VnaCBJIGtu ZXcgdGhhdCBJIHdhcyBnb2luZyB0bw0KDQo+IGFkZCBRQ1JBTSwgSSBtYWRlIG9ubHkgbWluaW1h bCBkZXNpZ24gY29uY2Vzc2lvbnMgd2hlbiBidWlsZGluZyBIUEFDSy4NCg0KPg0KDQo+IEJ1aWxk aW5nIFFDUkFNIG9uIHRvcCBvZiBIUEFDSyB0b29rIGF0IGxlYXN0IDUwJSBtb3JlIHRoYW4ganVz dCBkb2luZw0KDQo+IEhQQUNLIChhdCBhIGd1ZXNzLCBIUEFDSyB0b29rIGFib3V0IDEwLTEyIGhv dXJzLCBRQ1JBTSB0b29rIGNsb3NlciB0byAyMCkuDQoNCj4gRXZlbiB0aG91Z2ggeW91IGNhbiBy ZXVzZSBIdWZmbWFuIGNvZGluZyBhbmQgbW9zdCBvZiB0aGUgcHJpbWl0aXZlcywNCg0KPiByZXRy b2ZpdHRpbmcgaXQgd2FzIHRyaWNreS4gTXkgbGFjayBvZiBmYW1pbGlhcml0eSB3aXRoIGdvIGRl ZmluaXRlbHkNCg0KPiBjb250cmlidXRlZCBhIGxvdCB0byB0aGF0LCBidXQgSSdkIHNheSB0aGF0 IFFDUkFNIGlzIG1vcmUgZGlmZmljdWx0IHRvDQoNCj4gaW1wbGVtZW50IHRoYW4gaXQgc2VlbXMg aW4gdGhlb3J5Lg0KDQo+DQoNCj4gSSBkaWRuJ3QgaW1wbGVtZW50IFFDUkFNIGVudGlyZWx5IGFz IHNwZWNpZmllZC4gVGhlcmUgYXJlIGEgZmV3IHRoaW5ncw0KDQo+IHRoYXQgSSdsbCBkZXNjcmli ZSBiZWxvdyB0aGF0IHdvdWxkIG1ha2UgaXQgZWl0aGVyIGJldHRlciBvciBlYXNpZXIgdG8NCg0K PiBpbXBsZW1lbnQgKG9yIGJvdGgpLg0KDQo+DQoNCj4NCg0KPiAjIFNlcGFyYXRlIFN0cmVhbSBS b2xlcw0KDQo+DQoNCj4gVGhlcmUgYXJlIGFjdHVhbGx5IHRocmVlIHN0cmVhbXMgb2YgZGF0YSB0 aGF0IGFyZSBvZiBpbnRlcmVzdCwgYW5kDQoNCj4gdGhlcmUgaXMgbm8gY2xhcml0eSBhYm91dCB0 aG9zZSBzdHJlYW1zLg0KDQo+DQoNCj4gMS4gSSBzdWdnZXN0IHRoYXQgd2UgdXNlIHVuaWRpcmVj dGlvbmFsIHN0cmVhbXMgaW4gZWFjaCBkaXJlY3Rpb24gZm9yDQoNCj4gdGFibGUgdXBkYXRlcy4N Cg0KPg0KDQo+IDIuIEEgc2VwYXJhdGUgc3RyZWFtIGZvciBhY2tub3dsZWRnbWVudHMgZW5zdXJl cyB0aGF0IHRoZSBlbmNvZGVyIGNhbg0KDQo+IGNvbnN1bWUgdGhhdCBzZXBhcmF0ZWx5IHRvIHRo ZSBkZWNvZGVyLg0KDQo+DQoNCj4gMy4gUmVxdWVzdC9yZXNwb25zZSBzdHJlYW1zLiBJIHRoaW5r IHRoYXQgd2UgYWxsIHVuZGVyc3RhbmQgdGhlc2UuDQoNCj4NCg0KPiBUaGVzZSBjYW4gYmUgc2Vw YXJhdGUgZnJvbSB0aGUgaHEgY29udHJvbCBzdHJlYW0sIGFuZCB0aGV5IHNob3VsZCBiZS4NCg0K PiBSYXRoZXIgdGhhbiBwaWNrIGEgc3BlY2lmaWMgc3RyZWFtIG51bWJlciwgd2Ugc2hvdWxkIGFk ZCBhIGhlYWRlciBmb3INCg0KPiB0aGVzZSBzdHJlYW1zIHRoYXQgd2lsbCBhbGxvdyB0aGVtIHRv IGJlIGlkZW50aWZpZWQgY2xlYXJseS4gSWYgd2UgZG8NCg0KPiB0aGF0LCBhZGQgc3RyaWN0IHJ1 bGVzIGFib3V0IGNhcmRpbmFsaXR5Lg0KDQo+DQoNCj4gIyBEZWZpbmUgRnJhbWluZyBNb3JlIENs ZWFybHkNCg0KPg0KDQo+IFRoZSBkZWZpbml0aW9uIG9mIHRoZSBmcmFtaW5nIHRoYXQgaXMgdXNl ZCBvbiB0aGUgY29udHJvbCBzdHJlYW0gaXMNCg0KPiB1bmNsZWFyLiBJIGFzc3VtZSB0aGF0IHRo ZSBpbnRlbnQgaXMgdG8gdXNlIEhFQURFUlMgZnJhbWVzLCBidXQgSSdtDQoNCj4gb25seSByZWFs bHkgZ3Vlc3NpbmcuDQoNCj4gSWYgeW91IHRha2UgbXkgc3VnZ2VzdGlvbiBmb3Igc2VwYXJhdGUg ZnJhbWluZywgdGhlbiB5b3UgY2FuIHVzZSB2ZXJ5DQoNCj4gZGlmZmVyZW50IGxvZ2ljIGZvciB0 aGUgZGlmZmVyZW50IHN0cmVhbXMuDQoNCj4NCg0KPiBIb25lc3RseSwgdGhlIG92ZXJoZWFkIG9m IGZyYW1pbmcgaXMgZXhjZXNzaXZlIGZvciBhbnl0aGluZyBidXQNCg0KPiByZXF1ZXN0L3Jlc3Bv bnNlIHN0cmVhbXMuIEkgZm91bmQgdGhhdCBmcmFtaW5nIG9uIHRoZSBjb250cm9sIHN0cmVhbQ0K DQo+IHdhc24ndCBuZWNlc3NhcnkgYXQgYWxsLiBUaGlzIG1pZ2h0IGRlcGVuZCBvbiBpbXBsZW1l bnRhdGlvbiBzdHJhdGVneSwNCg0KPiBiZWNhdXNlIGl0IG1pZ2h0IGJlIGVhc2llciB0byBjb2xs ZWN0IGEgZnJhbWVkIHRoaW5nIHRoYW4gaXQgaXMgdG8NCg0KPiByZWFkIHVudGlsIHlvdSBhcmUg YmxvY2tlZCwgdGhlbiBwaWNrbGUgdGhhdCBzdGF0ZSBzbyB0aGF0IHlvdSBjYW4gZ28NCg0KPiBi YWNrIHRvIHNvbWV0aGluZyBlbHNlLiBJbiBteSBpbXBsZW1lbnRhdGlvbiBJIGhvbGQgc3RhdGUg b24gdGhlIHN0YWNrLCBzbyBpdCdzIHByZXR0eSBlYXN5Lg0KDQo+DQoNCj4gQWxzbywgaXQgc2hv dWxkIHN1ZmZpY2UgdG8gaGF2ZSBqdXN0IGEgc3RyZWFtIG9mIHZhcmludHMgaW5kaWNhdGluZw0K DQo+IGFja25vd2xlZGdtZW50cy4gRHVwbGljYXRlcyBjYW4gYmUgdXNlZCB0byBhY2tub3dsZWRn ZSBtdWx0aXBsZSBoZWFkZXINCg0KPiBibG9ja3Mgb24gdGhlIHNhbWUgc3RyZWFtIGluIG9yZGVy Lg0KDQo+DQoNCj4gIyBTcGxpdCB0aGUgSW5zdHJ1Y3Rpb24gU3BhY2UNCg0KPg0KDQo+IEhhdmlu ZyB0byBjaGVjayB0aGF0IG9ubHkgY2VydGFpbiBpbnN0cnVjdGlvbnMgYXBwZWFyIG9uIGRpZmZl cmVudA0KDQo+IHN0cmVhbXMgaXMgYW5ub3lpbmcgdG8gaW1wbGVtZW50IGFuZCBhIHdhc3RlIG9m IGJpdHMuIERlZmluZSB0d28NCg0KPiBzZXBhcmF0ZSBzcGFjZXMuIFRoYXQgc2hvdWxkIG1ha2Ug dGhpbmdzIG11Y2ggc2ltcGxlcjogdGhlcmUgYXJlDQoNCj4gZXhhY3RseSB0d28gaW5zdHJ1Y3Rp b25zIGluIGVhY2ggc3BhY2UgdGhlbiAobGVhdmluZyBhc2lkZSBhY2tub3dsZWRnbWVudHMsIHdo aWNoIEkgd2lsbCBjb3ZlciBiZWxvdykuDQoNCj4NCg0KPiAjIEJhc2UgaW4gRXZlcnkgSEVBREVS UyBGcmFtZQ0KDQo+DQoNCj4gQmFzZSAodGhlIG51bWJlciBvZiBpbnNlcnRzIGluIHRoZSB0YWJs ZSBhdCB0aGUgc3RhcnQgb2YgYSBoZWFkZXINCg0KPiBibG9jaykgc2VlbXMgdG8gYmUgcmVxdWly ZWQgZm9yIGFsbCBIRUFERVJTIGZyYW1lcywgaW5jbHVkaW5nIGJvdGgNCg0KPiB0YWJsZSBtb2Rp ZmljYXRpb24gYW5kIHJlcXVlc3QvcmVzcG9uc2Ugc3RyZWFtcy4gIEJ1dC4uLg0KDQo+DQoNCj4g IyBCYXNlIG9uIHRoZSBUYWJsZSBVcGRhdGUgU3RyZWFtDQoNCj4NCg0KPiBZb3UgZG9uJ3QgbmVl ZCBiYXNlIGZvciB0YWJsZSB1cGRhdGVzLiBJdCBpcyBtb3JlIG9mIGEgaGF6YXJkIHRoYW4gYQ0K DQo+IGhlbHAuIEl0IGlzIGVhc2llciBpZiB5b3UgdHJlYXQgaW5kZXhpbmcgb24gdGhlIHRhYmxl IHVwZGF0ZSBzdHJlYW0gYXMNCg0KPiBpbiBIUEFDSyB3aGVyZSBlYWNoIGluc2VydCBtb3ZlcyB0 aGUgcmVmZXJlbmNlIHBvaW50IGZvciB0aGUgbmV4dCBpbnNlcnRpb24uDQoNCj4NCg0KPiAjIFJl bW92ZSBCTE9DS0lORw0KDQo+DQoNCj4gVGhlIEJMT0NLSU5HIGZsYWcgY29tcGxpY2F0ZXMgdGhl IGRlc2lnbiB1bm5lY2Vzc2FyaWx5LiBBcyBhIGZpeGVkDQoNCj4gb3ZlcmhlYWQsIHBheSB0aGUg ZXh0cmEgYnl0ZSBhbHdheXMuIEZ1cnRoZXJtb3JlLCB0aGUgdGFibGUgdXBkYXRlDQoNCj4gc3Ry ZWFtIHdpbGwgbmV2ZXIgbmVlZCB0byB1c2UgZGVwZW5kcywgc28gdGhhdCBmdXJ0aGVyIG1vdGl2 YXRlcw0KDQo+IGhhdmluZyBkaWZmZXJlbnQgaW5zdHJ1Y3Rpb24gc2V0cyAoYW5kIGZvcm1hdHMp IGZvciBkaWZmZXJlbnQgc3RyZWFtcy4gIEFuZCB5b3UgZG9uJ3QgbmVlZCBpdC4uLg0KDQo+DQoN Cj4gIyBCYXNlIGFuZCB0aGUgU3RhdGljIFRhYmxlDQoNCj4NCg0KPiBJdCBpcyBub3QgZXhwbGFp bmVkIGF0IGFsbCB0aGF0IHRoZSBiYXNlIGlzIGFwcGxpZWQgdG8gdGhlIGR5bmFtaWMgdGFibGUg b25seS4NCg0KPiBUaGF0IGlzLCBpbmRleCAxIGlzIGEgc3RyYWlnaHQgaW5kZXggaW50byB0aGUg c3RhdGljIHRhYmxlIGFuZCB0aGF0DQoNCj4gaW5kZXggNjIgd2lsbCB1c2UgdGhlIGN1cnJlbnQg bnVtYmVyIG9mIGluc2VydHMgYW5kIHRoZSBiYXNlIHRvDQoNCj4gZGV0ZXJtaW5lIHRoZSBhY3R1 YWwgaW5kZXggaW50byB0aGUgZHluYW1pYyB0YWJsZSAodGhpcyBpcyB0aGUgZmlyc3QNCg0KPiB0 YWJsZSBlbnRyeSBvbmx5IHdoZW4gdGhlIG51bWJlciBvZiB0YWJsZSBpbnNlcnRzIGFuZCBiYXNl IGFyZSB0aGUNCg0KPiBzYW1lLCBpZiB0aGUgYmFzZSBpcyBzbWFsbGVyLCB0aGVuIGl0IHdpbGwg YmUgZnVydGhlciBhbG9uZyB0aGUgdGFibGUpLg0KDQo+DQoNCj4gVG8gYmUgY2xlYXIsIG15IGxv Z2ljIGZvciBmaW5kaW5nIGVudHJpZXMgaXM6DQoNCj4NCg0KPiAgICAgaWYgaSA9PSAwOiBlcnJv cg0KDQo+ICAgICBpZiBpIDw9IGxlbihzdGF0aWNUYWJsZSk6IHJldHVybiBzdGF0aWNUYWJsZVtp LTFdDQoNCj4gICAgIGRlbHRhID0gdGFibGVCYXNlIC0gYmFzZQ0KDQo+ICAgICBpZiBkZWx0YSA8 IDA6IGVycm9yDQoNCj4gICAgIHJldHVybiBkeW5hbWljVGFibGVbaSAtIGxlbihzdGF0aWNUYWJs ZSkgLSAxICsgZGVsdGFdDQoNCj4NCg0KPiAjIFJlbW92ZSBEZXBlbmRzDQoNCj4NCg0KPiBEZXBl bmRzIGlzIHVzZWxlc3MuIEkgZGlkIG5vdCBpbXBsZW1lbnQgaXQuIEJhc2UgaXMgc3VmZmljaWVu dC4NCg0KPg0KDQo+IFRoaXMgZm9sbG93cyBmcm9tIHByZWZlcnJpbmcgdG8gdXNlIHRoZSBzbWFs bGVzdCB2YWx1ZSBmb3IgYmFzZSBwb3NzaWJsZS4NCg0KPiBEb2luZyB0aGF0IGFsc28ga2VlcHMg dGFibGUgcmVmZXJlbmNlcyBhcyBzbWFsbCBhcyBwb3NzaWJsZS4gKEJlY2F1c2UNCg0KPiByZWZl cmVuY2VzIGFyZSBjb3VudGVkIGluIHRoZSBvcHBvc2l0ZSBkaXJlY3Rpb24gdG8gYmFzZSwgYSBs YXJnZXINCg0KPiBiYXNlIG1lYW5zIGxhcmdlcg0KDQo+IHJlZmVyZW5jZXMuKQ0KDQo+DQoNCj4g VGhlIGNvc3QgaXMgdGhhdCB5b3UgaGF2ZSB0byBkbyBhIHR3byBwYXNzIGNoZWNrOiB0aGUgZmly c3QgdG8gZmluZA0KDQo+IHRoZSBuZXdlc3QgcmVmZXJlbmNlLCB0aGUgc2Vjb25kIHRvIHdyaXRl IG91dCB0aGUgaGVhZGVyIGJsb2NrLiBJIGZpbmQNCg0KPiB0aGF0IGl0J3MgYmFzaWNhbGx5IG5l Y2Vzc2FyeSB0byBkbyB0d28gcGFzc2VzIGFueXdheTogb24gdGhlIGZpcnN0IEkNCg0KPiB3cml0 ZSBvdXQgdGhlIHRhYmxlIHVwZGF0ZXMsIG9uIHRoZSBzZWNvbmQgSSB3cml0ZSB0aGUgaGVhZGVy IGJsb2NrLg0KDQo+IER1cmluZyB0aGF0IHBoYXNlIHlvdSB3YW50IHRvIGRvIGxvb2t1cHMgYW55 d2F5LCBzbyB5b3UgY2FuIHNhdmUgdGhlDQoNCj4gbGFyZ2VzdCBiYXNlIGZyb20gdGhhdCBwYXNz LiBBbHNvLCB3aGVuIHlvdSBpbnNlcnQgYW55dGhpbmcsIHRoYXQNCg0KPiB0ZW5kcyB0byBzZXQg dGhlIGJhc2UsIHNvIGl0J3MgcHJldHR5IGVhc3kgb3ZlcmFsbC4NCg0KPg0KDQo+ICMgVHJhY2tp bmcgQUNLcyBpcyBIYXJkZXIgVGhhbiBJdCBTZWVtcw0KDQo+DQoNCj4gVGhlcmUgYXJlIG11bHRp cGxlIGhlYWRlciBibG9ja3MgcGVyIHN0cmVhbSwgYW5kIEFDS3Mgb25seSBpZGVudGlmeQ0KDQo+ IHRoZSBzdHJlYW0uDQoNCj4gWW91IGNhbid0IGp1c3Qgc3RvcmUgYSBzdHJlYW0gcmVmZXJlbmNl IChvciBSZXF1ZXN0LUlEKSBhZ2FpbnN0IGVhY2gNCg0KPiBoZWFkZXIgYmxvY2ssIHlvdSBoYXZl IHRvIHN0b3JlIGEgdHVwbGUgb2Ygc3RyZWFtIGFuZCBoZWFkZXIgYmxvY2sNCg0KPiBpbmRleC4g VGhpcyBuZWVkcyB0byBiZSBleHBsYWluZWQgc29tZXdoZXJlLg0KDQo+DQoNCj4gSSBkZWNpZGVk IHRvIGV4dGVybmFsaXplIEFDS3MgLSB0aGUgUUNSQU0gZW5jb2RlciB0YWtlcyBhIGdlbmVyaWMg YmxvYg0KDQo+IGFzIGlucHV0IHdoZW4gaXQgZW5jb2RlcyBhIGhlYWRlciBibG9jayBhbmQgdGhl IHNhbWUgZ2VuZXJpYyBibG9iIHRvDQoNCj4gYWNrbm93bGVkZ2UgaXQuIFRoZSBjYWxsZXIgdGhl biBoYXMgdG8gY29tYmluZSBzdHJlYW0gSUQgYW5kIGhlYWRlcg0KDQo+IGJsb2NrIGluZGV4IGlu IGEgc2Vuc2libGUgZmFzaGlvbi4NCg0KPg0KDQo+ICMgQWNrbm93bGVkZ2UgRG1pdHJ5DQoNCj4N Cg0KPiBTbyBJIGRvbid0IGZvcmdldC4uLiBEbWl0cnkgZGlkIGEgbG90IG9mIHdvcmsgb24gdGhl IGRlc2lnbiB0ZWFtLg0KDQo+DQoNCj4gIyBEeW5hbWljIFRhYmxlIE92ZXJoZWFkDQoNCj4NCg0K PiBUaGUgZHJhZnQgaGFzIGEgVE9ETyBhYm91dCBvdmVyaGVhZCBmb3IgZWFjaCBkeW5hbWljIGVu dHJ5LiBJIGFkZGVkIGENCg0KPiBmaWVsZCB0byBldmVyeSBlbnRyeSB0aGF0IGFsbG93cyBpdCB0 byBrbm93IGl0cyBvd24gcG9zaXRpb24gaW4gdGhlDQoNCj4gdGFibGUsIGJ1dCB0aGF0IGlzIGEg c2ltcGxpZmljYXRpb24vb3B0aW1pemF0aW9uLCBhbmQgeW91IGRvbid0IHJlYWxseQ0KDQo+IG5l ZWQgdGhhdC4gVGhlIG90aGVyIHBlci0gcmVjb3JkIG92ZXJoZWFkcyBhcmUgYWxsIHRoZSBzYW1l IGZvciB0aGUNCg0KPiBkZWNvZGVyLCB3aXRoIGEgc21hbGwgaW5jcmVhc2UgdG8gdGhlIGZpeGVk IG92ZXJoZWFkLiBJdCdzIGEgbGl0dGxlDQoNCj4gbW9yZSBzdGF0ZSBmb3IgYW4gZW5jb2Rlciwg YnV0IHRoYXQgaXMgbW9zdGx5IGJlY2F1c2Ugb2YgaGF2aW5nIHRvIHRyYWNrIHVzYWdlLg0KDQo+ DQoNCj4gSSBkb24ndCB0aGluayB0aGF0IHdlIG5lZWQgdG8gY2hhbmdlIGZyb20gYSAzMiBieXRl IG92ZXJoZWFkLiBUaGlzDQoNCj4gZGVjaXNpb24gY291bGQgcmVkdWNlIGNvZGUgY29tcGxleGl0 eSBpbiBzaGFyZWQgUUNSQU0vSFBBQ0sNCg0KPiBpbXBsZW1lbnRhdGlvbnMgKGluIG15IGltcGxl bWVudGF0aW9uIGl0IHdvdWxkKS4NCg0KPg0KDQo+ICMgRHVwbGljYXRpb24gRG9lc24ndCBOZWVk IHRvIFJlZmVyZW5jZSB0aGUgU3RhdGljIFRhYmxlDQoNCj4NCg0KPiBEdXBsaWNhdGlvbiBvbmx5 IG1ha2VzIHNlbnNlIGZvciBkeW5hbWljIGVudHJpZXMgYW5kIHlldCB0aGUgaW5kZXggaXMNCg0K PiAoSSBhc3N1bWUpLCB0aGUgbm9ybWFsIHRhYmxlIGluZGV4LiBUaGF0IGlzIGhpZ2hseSBzdWJv cHRpbWFsLiBUaGlzIGlzDQoNCj4gd29yc2UgYmVjYXVzZSB0aGUgcHJlZml4IGlzIG9ubHkgNSBi aXRzIGZvciB0aGlzIGluc3RydWN0aW9uICh1cCB0byA2Mg0KDQo+IHZhbHVlcyksIHdoaWNoIGxl YWRzIHRvIHRoZSBlbmNvZGluZyB0YWtpbmcgYW4gZXh0cmEgYnl0ZSBhbHdheXMuIElmDQoNCj4g eW91IHRha2UgbXkgc3VnZ2VzdGlvbiBmb3Igc2VwYXJhdGUgaW5zdHJ1Y3Rpb24gc3BhY2VzLCB0 aGlzIGlzDQoNCj4gYmV0dGVyLCBidXQgc3RpbGwgbm90IGFzIGdvb2QgYXMgYSBkaXJlY3QgaW5k ZXggaW50byB0aGUgZHluYW1pYw0KDQo+IHRhYmxlLCBzdGFydGluZyBhdCAwLiBCZXR0ZXIgeWV0 IHdvdWxkIGJlIGEgcmV2ZXJzZSBpbmRleCwgc3RhcnRpbmcNCg0KPiBmcm9tIHRoZSBlbmQgb2Yg dGhlIHRhYmxlLCBiZWNhdXNlIGR1cGxpY2F0aW9uIG9mdGVuIG5lZWRzIHRvIHJlZmVyIHRvIHRo ZSBlbmQgb2YgdGhlIHRhYmxlLg0KDQo+DQoNCj4gIyBOZWVkIEJldHRlciBBZHZpY2Ugb24gUmVm ZXJlbmNpbmcgc3RyYXRlZ3kNCg0KPg0KDQo+IFJlZmVyZW5jaW5nIGVudHJpZXMgbmVhciB0aGUg ZW5kIG9mIHRoZSB0YWJsZSBpbiBhIG5ldyBoZWFkZXIgYmxvY2sgaXMNCg0KPiBoYXphcmRvdXMu IElmIHlvdSBqdXN0IGNvbXByZXNzIGFzIHlvdSBkbyBpbiBIUEFDSywgeW91IGNhbiBlbmQgdXAN Cg0KPiBwaW5uaW5nIGVudHJpZXMgaW4gdGhlIGhlYWRlciB0YWJsZSwgbWFraW5nIGl0IGltcG9z c2libGUgdG8gYWRkIG5ldw0KDQo+IGVudHJpZXMuIFRodXMsIHlvdSBoYXZlIHRvIHN0b3AgcmVm ZXJlbmNpbmcgZW50cmllcyBhcyB0aGV5IGdldCBuZWFyZXINCg0KPiB0byB0aGUgdGFibGUgY2Fw YWNpdHkgbGltaXQuDQoNCj4NCg0KPiBJbiBteSBpbXBsZW1lbnRhdGlvbiBJIGFkZGVkIGEgdGhy ZXNob2xkIHZhcmlhYmxlIHRoYXQgZ292ZXJucyBteQ0KDQo+IHJlZmVyZW5jaW5nIHN0cmF0ZWd5 LiBBIHBvcnRpb24gb2YgdGhlIGhlYWRlciB0YWJsZSBzcGFjZSBpcyBtYXJrZWQgYXMNCg0KPiBi ZWluZyBvZmYtbGltaXRzIGZvciBoZWFkZXIgYmxvY2sgdXNhZ2UuIFRoZSBlbmNvZGVyIGR1cGxp Y2F0ZXMgdGhvc2UNCg0KPiBlbnRyaWVzIGlmIGl0IHdhbnRzIHRvIGNvbXByZXNzLCBidXQgd29u J3QgcmVmZXJlbmNlIHRoZW0uIElmIHRoZQ0KDQo+IHRhYmxlIGlzIHVuZGVyIHByZXNzdXJlIGZy b20gdGhlIG5ldyBoZWFkZXIgZmllbGRzIGJlaW5nIGFkZGVkLCB0aGVuDQoNCj4gaXQgc2hvdWxk IGJlIGFibGUgdG8gYWR2YW5jZSBieSBhdCBsZWFzdCB0aGlzIGFtb3VudCBldmVyeSByb3VuZCB0 cmlwLg0KDQo+DQoNCj4gVGhpcyBpcyBhIHNpbXBsZSBzdHJhdGVneSwgYW5kIHByb2JhYmx5IHN1 Ym9wdGltYWwgaW4gdmFyaW91cyB3YXlzLA0KDQo+IGJ1dCBpdCBzZWVtcyB0byB3b3JrIG91dC4g Rm9yIGluc3RhbmNlLCBJIGNvbnRpbnVvdXNseSB1cGRhdGUgdGhlDQoNCj4gY3V0b2ZmIGFzIGVu dHJpZXMgYXJlIGluc2VydGVkLCBzbyB0aGF0IGEgaGVhZGVyIGJsb2NrIG1pZ2h0IGVuZCB1cA0K DQo+IHJlZmVyZW5jaW5nIHRoaW5ncyB0aGF0IGdldCBwdXNoZWQgaW50byB0aGlzIHNwYWNlIGJ5 IGxhdGVyIGhlYWRlciBmaWVsZHMuDQoNCj4NCg0KPiBZb3UgY2FuIGltYWdpbmUgbW9yZSBhZHZh bmNlZCB0ZWNobmlxdWVzLiBGb3IgaW5zdGFuY2UsIHlvdSBtaWdodCB0dW5lDQoNCj4gdGhpcyB3 aW5kb3cgYXV0b21hdGljYWxseSBiYXNlZCBvbiB0aGUgcmF0ZSB0aGF0IHRoZSBoZWFkZXIgdGFi bGUgZ3Jvd3MuDQoNCj4gQmVjYXVzZSByZWZlcmVuY2VzIGluIHRoYXQgd2luZG93IGJsb2NrIGV2 aWN0aW9uLCBpdCBzaG91bGQgYmUgc2l6ZWQNCg0KPiB0byB0aGUgcmF0ZSBvZg0KDQo+ICpkZXNp cmVkKiBncm93dGggaW4gdGhlIGhlYWRlciB0YWJsZSBvdmVyIGEgcm91bmQgdHJpcC4gVGFraW5n IGENCg0KPiBydW5uaW5nIGVzdGltYXRlIG9mIHRoYXQgZGVzaXJlZCBncm93dGggYW5kIGFsbG93 aW5nIGEgbWFyZ2luIGZvcg0KDQo+IHZhcmlhbmNlIGNvdWxkIHByb2R1Y2UgdGhlIHJpZ2h0IHZh bHVlLiBJIGhhdmVuJ3QgZXhwZXJpbWVudGVkIHdpdGggdGhpcy4NCg0KDQo= --_000_MWHPR08MB24321A1087F2D7CC7EA46F36DAF20MWHPR08MB2432namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMzc2MDA2Nzc3Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2ODAyNjM4NDggNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow aW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5r PSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij5UaGFua3MgZm9yIGRvaW5nIHRoaXMsIE1hcnRpbi4mbmJzcDsgSSd2ZSBiZWVuIHdh aXRpbmcgZm9yIHRoZSBhZG9wdGlvbiBjYWxsIHRvIGJlIGZvcm1hbGx5IGNvbmNsdWRlZCBiZWZv cmUgSSBzdGFydGVkIGJyaW5naW5nIHRoZSBsYXVuZHJ5IGxpc3Qgb2YgaW1wcm92ZW1lbnRzLCBi dXQgbXkgb3duIGFsaWducyB3aXRoIHlvdXJzOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1zby1saXN0OmwwIGxldmVsMSBsZm8xIj5UaHJlZS1sYXllcmVkIHN0cmVhbSBtb2RlbCwg ZGlzdGluY3QgaW5zdHJ1Y3Rpb24gc3BhY2VzIG9uIGVhY2ggc3RyZWFtPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PkNvbnNpZGVyIGNoYW5naW5nIGZyb20gdGhlIHN0YXRpYy1hdC1mcm9udCBtb2RlbCB0byBhIHN0 YXRpYy9keW5hbWljIGJpdCBhbmQgYSBzaG9ydGVyIHJlZmVyZW5jZTxvOnA+PC9vOnA+DQo8dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+VGhpcyB3b3VsZCBtYWtlIGEg bGFyZ2VyIHN0YXRpYyB0YWJsZSBtb3JlIHBhbGF0YWJsZSwgYW5kIHNlZW1zIHRvIGJyZWFrIGV2 ZW4gZm9yIGR5bmFtaWMgZW50cmllcyBpbiB0aGUgZGlzdGluY3QgaW5zdHJ1Y3Rpb24gc3BhY2Vz PG86cD48L286cD48L2xpPjwvdWw+DQo8L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPllvdXIgb2Jz ZXJ2YXRpb24gdGhhdCB5b3XigJlyZSBrZWVwaW5nIGEgdHVwbGUgb2Ygc3RyZWFtLWJsb2NrbnVt IG9uIGVhY2ggZW50cnkgaXMgaW50ZXJlc3RpbmcuJm5ic3A7IENhbiB5b3UgZ28gaW50byBtb3Jl IGRldGFpbCB3aGVyZSB0aGlzIGlzPyZuYnNwOyBDb3VsZG7igJl0IHlvdSBhbHNvIGtlZXAgYSBz aW1wbGUgcmVmY291bnQgb2Ygb3V0c3RhbmRpbmcgYmxvY2tzLCB0aGVuIHNlcGFyYXRlbHkgdHJh Y2sgd2hpY2ggZW50cmllcw0KIGFyZSByZWZlcmVuY2VkIGJ5IG91dHN0YW5kaW5nIGJsb2Nrcz8m bmJzcDsgSUlSQywgaW4gUUNSQU0gdGhlcmXigJlzIG5vdCBhIHNpdHVhdGlvbiBpbiB3aGljaCB5 b3UgbmVlZCB0byBkZXRlcm1pbmUNCjxpPndoaWNoPC9pPiBvdXRzdGFuZGluZyBoZWFkZXIgYmxv Y2sgaXMgYmxvY2tpbmcgZXZpY3Rpb24sIG9ubHkgPGk+d2hldGhlcjwvaT4gYW4gb3V0c3RhbmRp bmcgSEVBREVSUyBmcmFtZSBibG9ja3MgZXZpY3Rpb24uJm5ic3A7IE9yIGFtIEkgbWlzdW5kZXJz dGFuZGluZyB3aGVyZSB5b3XigJlyZSBrZWVwaW5nIHRoZSB0dXBsZT88bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+T2YgY291cnNlLCBhIGRpY3Rpb25hcnkgb2YgcXVldWVzIG1pZ2h0IGJl IG1vcmUgZXhwZW5zaXZlIHRoYW4ganVzdCBzdG9yaW5nIHRoZSB0dXBsZSwgYnV0IEkgYmVsaWV2 ZSB5b3UgbmVlZCBzb21ldGhpbmcgbGlrZSB0aGF0IHJlZ2FyZGxlc3Mgc28geW91IGNhbiBmaW5k IHRoZSBlbnRyaWVzIHlvdSBuZWVkIHRvIHJlbW92ZSB0aGUgb3V0c3RhbmRpbmcgcmVmZXJlbmNl IGZyb20uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tPGJyPg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEx1Y2FzIFBhcmR1ZTxicj4NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgOSwgMjAx OCAyOjUxIEFNPGJyPg0KVG86IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhvbXNvbkBnbWFp bC5jb20mZ3Q7OyBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NClN1YmplY3Q6IFJF OiBSZXZpZXcgb2YgUUNSQU08L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpIE1hcnRpbiw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+VmVyeSBpbnRlcmVzdGluZywgdGhhbmtzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij5HaXZlbiB0aGF0IHlvdXIgaW1wbGVtZW50YXRpb24gc3VwcG9y dHMgYm90aCBIUEFDSyBhbmQgUUNSQU0sIGRvIHlvdSBoYXZlIGFueSBvcGluaW9uIGhvdyBtdWNo IHBhaW4gaXQgd291bGQgYmUgdG8gaGF2ZSBkaWZmZXJlbnQgc3RhdGljIHRhYmxlcyBiZXR3ZWVu IHRoZW0/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlJlZ2FyZHM8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkx1Y2FzPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRnJvbTogUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPl0g T24gQmVoYWxmIE9mIE1hcnRpbiBUaG9tc29uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IFNlbnQ6IDA5IEZlYnJ1YXJ5IDIwMTggMTA6MDk8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVG86IFFVSUMgV0cgJmx0OzxhIGhyZWY9 Im1haWx0bzpxdWljQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0 LWRlY29yYXRpb246bm9uZSI+cXVpY0BpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0OzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBTdWJqZWN0OiBSZXZpZXcgb2YgUUNS QU08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEkgaGF2ZSBpbXBsZW1lbnRlZCBR Q1JBTSBhbmQgaGF2ZSBhIGZldyB0aGluZ3MgdG8gY29tbWVudCBvbi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IE15IGltcGxlbWVudGF0aW9uIGlzIGhlcmU6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0 dHBzOi8vZ2l0aHViLmNvbS9tYXJ0aW50aG9tc29uL21pbmhxL3RyZWUvbWFzdGVyL2hjIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczov L2dpdGh1Yi5jb20vbWFydGludGhvbXNvbi9taW5ocS90cmVlL21hc3Rlci9oYzwvc3Bhbj48L2E+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGlzIGlzIG15IGZpcnN0IGF0dGVt cHQgYXQgZ28sIHNvIHRoaXMgdG9vayBhIGxpdHRsZSBsb25nZXIgdGhhbiBpdA0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IG1pZ2h0IGhhdmUgb3RoZXJ3aXNl LiBUZXN0IGNvdmVyYWdlIGlzIHN0aWxsIGEgbGl0dGxlIGxpZ2h0LCB0aG91Z2ggZ28NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGlua3MgdGhhdCBJIGhh dmUgcHJldHR5IGdvb2QgY292ZXJhZ2UuIFRoZXJlJ3MgcHJvYmFibHkgc3RpbGwgYSBsb3QNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0byBnbyBvbiB0aGUg Y29ybmVyIGNhc2VzLCBidXQgSSB0aGluayB0aGF0IEkndmUgZG9uZSBlbm91Z2ggdG8gZ2V0IGFu IGlkZWEgZm9yIHRoZSBjb21wbGV4aXR5IGJ1bXAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBJIHN0YXJ0ZWQgYnkgaW1wbGVtZW50aW5nIEhQQUNLLCB3aGljaCBpcyBzdXJwcmlz aW5nbHkgZWFzeSBpZiB5b3UNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBkb24ndCBjYXJlIGFib3V0IGJlaW5nIGVmZmljaWVudC4gVGhvdWdoIEkga25ldyB0 aGF0IEkgd2FzIGdvaW5nIHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgYWRkIFFDUkFNLCBJIG1hZGUgb25seSBtaW5pbWFsIGRlc2lnbiBjb25jZXNzaW9u cyB3aGVuIGJ1aWxkaW5nIEhQQUNLLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg QnVpbGRpbmcgUUNSQU0gb24gdG9wIG9mIEhQQUNLIHRvb2sgYXQgbGVhc3QgNTAlIG1vcmUgdGhh biBqdXN0IGRvaW5nDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgSFBBQ0sgKGF0IGEgZ3Vlc3MsIEhQQUNLIHRvb2sgYWJvdXQgMTAtMTIgaG91cnMsIFFDUkFN IHRvb2sgY2xvc2VyIHRvIDIwKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgRXZlbiB0aG91Z2ggeW91IGNhbiByZXVzZSBIdWZmbWFuIGNvZGluZyBhbmQgbW9z dCBvZiB0aGUgcHJpbWl0aXZlcywNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyByZXRyb2ZpdHRpbmcgaXQgd2FzIHRyaWNreS4gTXkgbGFjayBvZiBmYW1pbGlh cml0eSB3aXRoIGdvIGRlZmluaXRlbHkNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBjb250cmlidXRlZCBhIGxvdCB0byB0aGF0LCBidXQgSSdkIHNheSB0aGF0 IFFDUkFNIGlzIG1vcmUgZGlmZmljdWx0IHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgaW1wbGVtZW50IHRoYW4gaXQgc2VlbXMgaW4gdGhlb3J5LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgSSBkaWRuJ3QgaW1wbGVtZW50IFFDUkFNIGVu dGlyZWx5IGFzIHNwZWNpZmllZC4gVGhlcmUgYXJlIGEgZmV3IHRoaW5ncw0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoYXQgSSdsbCBkZXNjcmliZSBiZWxv dyB0aGF0IHdvdWxkIG1ha2UgaXQgZWl0aGVyIGJldHRlciBvciBlYXNpZXIgdG8NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBpbXBsZW1lbnQgKG9yIGJvdGgp LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICMgU2VwYXJhdGUgU3RyZWFtIFJvbGVzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGVyZSBhcmUgYWN0dWFsbHkgdGhyZWUgc3RyZWFt cyBvZiBkYXRhIHRoYXQgYXJlIG9mIGludGVyZXN0LCBhbmQNCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGVyZSBpcyBubyBjbGFyaXR5IGFib3V0IHRob3Nl IHN0cmVhbXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAxLiBJIHN1Z2dlc3Qg dGhhdCB3ZSB1c2UgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBpbiBlYWNoIGRpcmVjdGlvbiBmb3IN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0YWJsZSB1cGRh dGVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgMi4gQSBzZXBhcmF0ZSBzdHJl YW0gZm9yIGFja25vd2xlZGdtZW50cyBlbnN1cmVzIHRoYXQgdGhlIGVuY29kZXIgY2FuDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgY29uc3VtZSB0aGF0IHNl cGFyYXRlbHkgdG8gdGhlIGRlY29kZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyAzLiBSZXF1ZXN0L3Jlc3BvbnNlIHN0cmVhbXMuIEkgdGhpbmsgdGhhdCB3ZSBhbGwgdW5kZXJz dGFuZCB0aGVzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoZXNlIGNhbiBi ZSBzZXBhcmF0ZSBmcm9tIHRoZSBocSBjb250cm9sIHN0cmVhbSwgYW5kIHRoZXkgc2hvdWxkIGJl LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBSYXRoZXIgdGhh biBwaWNrIGEgc3BlY2lmaWMgc3RyZWFtIG51bWJlciwgd2Ugc2hvdWxkIGFkZCBhIGhlYWRlciBm b3INCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGVzZSBz dHJlYW1zIHRoYXQgd2lsbCBhbGxvdyB0aGVtIHRvIGJlIGlkZW50aWZpZWQgY2xlYXJseS4gSWYg d2UgZG8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0aGF0 LCBhZGQgc3RyaWN0IHJ1bGVzIGFib3V0IGNhcmRpbmFsaXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgIyBEZWZpbmUgRnJhbWluZyBNb3JlIENsZWFybHk8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoZSBkZWZpbml0aW9uIG9mIHRoZSBmcmFtaW5nIHRoYXQg aXMgdXNlZCBvbiB0aGUgY29udHJvbCBzdHJlYW0gaXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB1bmNsZWFyLiBJIGFzc3VtZSB0aGF0IHRoZSBpbnRlbnQg aXMgdG8gdXNlIEhFQURFUlMgZnJhbWVzLCBidXQgSSdtDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgb25seSByZWFsbHkgZ3Vlc3NpbmcuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IElmIHlvdSB0YWtlIG15IHN1Z2dlc3Rp b24gZm9yIHNlcGFyYXRlIGZyYW1pbmcsIHRoZW4geW91IGNhbiB1c2UgdmVyeQ0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGRpZmZlcmVudCBsb2dpYyBmb3Ig dGhlIGRpZmZlcmVudCBzdHJlYW1zLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg SG9uZXN0bHksIHRoZSBvdmVyaGVhZCBvZiBmcmFtaW5nIGlzIGV4Y2Vzc2l2ZSBmb3IgYW55dGhp bmcgYnV0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVx dWVzdC9yZXNwb25zZSBzdHJlYW1zLiBJIGZvdW5kIHRoYXQgZnJhbWluZyBvbiB0aGUgY29udHJv bCBzdHJlYW0NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB3 YXNuJ3QgbmVjZXNzYXJ5IGF0IGFsbC4gVGhpcyBtaWdodCBkZXBlbmQgb24gaW1wbGVtZW50YXRp b24gc3RyYXRlZ3ksDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgYmVjYXVzZSBpdCBtaWdodCBiZSBlYXNpZXIgdG8gY29sbGVjdCBhIGZyYW1lZCB0aGluZyB0 aGFuIGl0IGlzIHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgcmVhZCB1bnRpbCB5b3UgYXJlIGJsb2NrZWQsIHRoZW4gcGlja2xlIHRoYXQgc3RhdGUgc28g dGhhdCB5b3UgY2FuIGdvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgYmFjayB0byBzb21ldGhpbmcgZWxzZS4gSW4gbXkgaW1wbGVtZW50YXRpb24gSSBob2xk IHN0YXRlIG9uIHRoZSBzdGFjaywgc28gaXQncyBwcmV0dHkgZWFzeS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IEFsc28sIGl0IHNob3VsZCBzdWZmaWNlIHRvIGhhdmUganVzdCBh IHN0cmVhbSBvZiB2YXJpbnRzIGluZGljYXRpbmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBhY2tub3dsZWRnbWVudHMuIER1cGxpY2F0ZXMgY2FuIGJlIHVz ZWQgdG8gYWNrbm93bGVkZ2UgbXVsdGlwbGUgaGVhZGVyDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgYmxvY2tzIG9uIHRoZSBzYW1lIHN0cmVhbSBpbiBvcmRl ci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICMgU3BsaXQgdGhlIEluc3RydWN0 aW9uIFNwYWNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBIYXZpbmcgdG8gY2hl Y2sgdGhhdCBvbmx5IGNlcnRhaW4gaW5zdHJ1Y3Rpb25zIGFwcGVhciBvbiBkaWZmZXJlbnQNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzdHJlYW1zIGlzIGFu bm95aW5nIHRvIGltcGxlbWVudCBhbmQgYSB3YXN0ZSBvZiBiaXRzLiBEZWZpbmUgdHdvDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgc2VwYXJhdGUgc3BhY2Vz LiBUaGF0IHNob3VsZCBtYWtlIHRoaW5ncyBtdWNoIHNpbXBsZXI6IHRoZXJlIGFyZQ0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IGV4YWN0bHkgdHdvIGluc3Ry dWN0aW9ucyBpbiBlYWNoIHNwYWNlIHRoZW4gKGxlYXZpbmcgYXNpZGUgYWNrbm93bGVkZ21lbnRz LCB3aGljaCBJIHdpbGwgY292ZXIgYmVsb3cpLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgIyBCYXNlIGluIEV2ZXJ5IEhFQURFUlMgRnJhbWU8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IEJhc2UgKHRoZSBudW1iZXIgb2YgaW5zZXJ0cyBpbiB0aGUgdGFibGUgYXQg dGhlIHN0YXJ0IG9mIGEgaGVhZGVyDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgYmxvY2spIHNlZW1zIHRvIGJlIHJlcXVpcmVkIGZvciBhbGwgSEVBREVSUyBm cmFtZXMsIGluY2x1ZGluZyBib3RoDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgdGFibGUgbW9kaWZpY2F0aW9uIGFuZCByZXF1ZXN0L3Jlc3BvbnNlIHN0cmVh bXMuJm5ic3A7IEJ1dC4uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgIyBCYXNl IG9uIHRoZSBUYWJsZSBVcGRhdGUgU3RyZWFtPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBZb3UgZG9uJ3QgbmVlZCBiYXNlIGZvciB0YWJsZSB1cGRhdGVzLiBJdCBpcyBtb3JlIG9m IGEgaGF6YXJkIHRoYW4gYQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGhlbHAuIEl0IGlzIGVhc2llciBpZiB5b3UgdHJlYXQgaW5kZXhpbmcgb24gdGhlIHRh YmxlIHVwZGF0ZSBzdHJlYW0gYXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBpbiBIUEFDSyB3aGVyZSBlYWNoIGluc2VydCBtb3ZlcyB0aGUgcmVmZXJlbmNl IHBvaW50IGZvciB0aGUgbmV4dCBpbnNlcnRpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyAjIFJlbW92ZSBCTE9DS0lORzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgVGhlIEJMT0NLSU5HIGZsYWcgY29tcGxpY2F0ZXMgdGhlIGRlc2lnbiB1bm5lY2Vzc2FyaWx5 LiBBcyBhIGZpeGVkDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgb3ZlcmhlYWQsIHBheSB0aGUgZXh0cmEgYnl0ZSBhbHdheXMuIEZ1cnRoZXJtb3JlLCB0aGUg dGFibGUgdXBkYXRlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgc3RyZWFtIHdpbGwgbmV2ZXIgbmVlZCB0byB1c2UgZGVwZW5kcywgc28gdGhhdCBmdXJ0aGVy IG1vdGl2YXRlcw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7 IGhhdmluZyBkaWZmZXJlbnQgaW5zdHJ1Y3Rpb24gc2V0cyAoYW5kIGZvcm1hdHMpIGZvciBkaWZm ZXJlbnQgc3RyZWFtcy4mbmJzcDsgQW5kIHlvdSBkb24ndCBuZWVkIGl0Li4uPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAjIEJhc2UgYW5kIHRoZSBTdGF0aWMgVGFibGU8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IEl0IGlzIG5vdCBleHBsYWluZWQgYXQgYWxsIHRo YXQgdGhlIGJhc2UgaXMgYXBwbGllZCB0byB0aGUgZHluYW1pYyB0YWJsZSBvbmx5LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGF0IGlzLCBpbmRleCAxIGlz IGEgc3RyYWlnaHQgaW5kZXggaW50byB0aGUgc3RhdGljIHRhYmxlIGFuZCB0aGF0DQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgaW5kZXggNjIgd2lsbCB1c2Ug dGhlIGN1cnJlbnQgbnVtYmVyIG9mIGluc2VydHMgYW5kIHRoZSBiYXNlIHRvDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgZGV0ZXJtaW5lIHRoZSBhY3R1YWwg aW5kZXggaW50byB0aGUgZHluYW1pYyB0YWJsZSAodGhpcyBpcyB0aGUgZmlyc3QNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyB0YWJsZSBlbnRyeSBvbmx5IHdo ZW4gdGhlIG51bWJlciBvZiB0YWJsZSBpbnNlcnRzIGFuZCBiYXNlIGFyZSB0aGUNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBzYW1lLCBpZiB0aGUgYmFzZSBp cyBzbWFsbGVyLCB0aGVuIGl0IHdpbGwgYmUgZnVydGhlciBhbG9uZyB0aGUgdGFibGUpLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgVG8gYmUgY2xlYXIsIG15IGxvZ2ljIGZvciBm aW5kaW5nIGVudHJpZXMgaXM6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBpZiBpID09IDA6IGVycm9yPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIGkgJmx0 Oz0gbGVuKHN0YXRpY1RhYmxlKTogcmV0dXJuIHN0YXRpY1RhYmxlW2ktMV08bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg ZGVsdGEgPSB0YWJsZUJhc2UgLSBiYXNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlmIGRlbHRhICZsdDsgMDogZXJy b3I8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgcmV0dXJuIGR5bmFtaWNUYWJsZVtpIC0gbGVuKHN0YXRpY1RhYmxlKSAt IDEgJiM0MzsgZGVsdGFdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyAjIFJlbW92 ZSBEZXBlbmRzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBEZXBlbmRzIGlzIHVz ZWxlc3MuIEkgZGlkIG5vdCBpbXBsZW1lbnQgaXQuIEJhc2UgaXMgc3VmZmljaWVudC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFRoaXMgZm9sbG93cyBmcm9tIHByZWZlcnJpbmcg dG8gdXNlIHRoZSBzbWFsbGVzdCB2YWx1ZSBmb3IgYmFzZSBwb3NzaWJsZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRG9pbmcgdGhhdCBhbHNvIGtlZXBzIHRh YmxlIHJlZmVyZW5jZXMgYXMgc21hbGwgYXMgcG9zc2libGUuIChCZWNhdXNlDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVmZXJlbmNlcyBhcmUgY291bnRl ZCBpbiB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uIHRvIGJhc2UsIGEgbGFyZ2VyDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgYmFzZSBtZWFucyBsYXJnZXI8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgcmVmZXJlbmNlcy4pPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGUgY29zdCBpcyB0aGF0IHlvdSBoYXZl IHRvIGRvIGEgdHdvIHBhc3MgY2hlY2s6IHRoZSBmaXJzdCB0byBmaW5kDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIG5ld2VzdCByZWZlcmVuY2UsIHRo ZSBzZWNvbmQgdG8gd3JpdGUgb3V0IHRoZSBoZWFkZXIgYmxvY2suIEkgZmluZA0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRoYXQgaXQncyBiYXNpY2FsbHkg bmVjZXNzYXJ5IHRvIGRvIHR3byBwYXNzZXMgYW55d2F5OiBvbiB0aGUgZmlyc3QgSQ0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHdyaXRlIG91dCB0aGUgdGFi bGUgdXBkYXRlcywgb24gdGhlIHNlY29uZCBJIHdyaXRlIHRoZSBoZWFkZXIgYmxvY2suDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgRHVyaW5nIHRoYXQgcGhh c2UgeW91IHdhbnQgdG8gZG8gbG9va3VwcyBhbnl3YXksIHNvIHlvdSBjYW4gc2F2ZSB0aGUNCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBsYXJnZXN0IGJhc2Ug ZnJvbSB0aGF0IHBhc3MuIEFsc28sIHdoZW4geW91IGluc2VydCBhbnl0aGluZywgdGhhdA0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHRlbmRzIHRvIHNldCB0 aGUgYmFzZSwgc28gaXQncyBwcmV0dHkgZWFzeSBvdmVyYWxsLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgIyBUcmFja2luZyBBQ0tzIGlzIEhhcmRlciBUaGFuIEl0IFNlZW1zPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBUaGVyZSBhcmUgbXVsdGlwbGUgaGVhZGVy IGJsb2NrcyBwZXIgc3RyZWFtLCBhbmQgQUNLcyBvbmx5IGlkZW50aWZ5DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgdGhlIHN0cmVhbS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgWW91IGNhbid0IGp1c3Qgc3RvcmUgYSBz dHJlYW0gcmVmZXJlbmNlIChvciBSZXF1ZXN0LUlEKSBhZ2FpbnN0IGVhY2gNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBoZWFkZXIgYmxvY2ssIHlvdSBoYXZl IHRvIHN0b3JlIGEgdHVwbGUgb2Ygc3RyZWFtIGFuZCBoZWFkZXIgYmxvY2sNCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyBpbmRleC4gVGhpcyBuZWVkcyB0byBi ZSBleHBsYWluZWQgc29tZXdoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsg SSBkZWNpZGVkIHRvIGV4dGVybmFsaXplIEFDS3MgLSB0aGUgUUNSQU0gZW5jb2RlciB0YWtlcyBh IGdlbmVyaWMgYmxvYg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IGFzIGlucHV0IHdoZW4gaXQgZW5jb2RlcyBhIGhlYWRlciBibG9jayBhbmQgdGhlIHNhbWUg Z2VuZXJpYyBibG9iIHRvDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PiZndDsgYWNrbm93bGVkZ2UgaXQuIFRoZSBjYWxsZXIgdGhlbiBoYXMgdG8gY29tYmluZSBzdHJl YW0gSUQgYW5kIGhlYWRlcg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij4mZ3Q7IGJsb2NrIGluZGV4IGluIGEgc2Vuc2libGUgZmFzaGlvbi48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7ICMgQWNrbm93bGVkZ2UgRG1pdHJ5PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBTbyBJIGRvbid0IGZvcmdldC4uLiBEbWl0cnkgZGlkIGEgbG90IG9m IHdvcmsgb24gdGhlIGRlc2lnbiB0ZWFtLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZn dDsgIyBEeW5hbWljIFRhYmxlIE92ZXJoZWFkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Jmd0OyBUaGUgZHJhZnQgaGFzIGEgVE9ETyBhYm91dCBvdmVyaGVhZCBmb3IgZWFjaCBkeW5hbWlj IGVudHJ5LiBJIGFkZGVkIGENCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBmaWVsZCB0byBldmVyeSBlbnRyeSB0aGF0IGFsbG93cyBpdCB0byBrbm93IGl0cyBv d24gcG9zaXRpb24gaW4gdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgdGFibGUsIGJ1dCB0aGF0IGlzIGEgc2ltcGxpZmljYXRpb24vb3B0aW1pemF0aW9u LCBhbmQgeW91IGRvbid0IHJlYWxseQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IG5lZWQgdGhhdC4gVGhlIG90aGVyIHBlci0gcmVjb3JkIG92ZXJoZWFkcyBh cmUgYWxsIHRoZSBzYW1lIGZvciB0aGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBkZWNvZGVyLCB3aXRoIGEgc21hbGwgaW5jcmVhc2UgdG8gdGhlIGZpeGVk IG92ZXJoZWFkLiBJdCdzIGEgbGl0dGxlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgbW9yZSBzdGF0ZSBmb3IgYW4gZW5jb2RlciwgYnV0IHRoYXQgaXMgbW9z dGx5IGJlY2F1c2Ugb2YgaGF2aW5nIHRvIHRyYWNrIHVzYWdlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgSSBkb24ndCB0aGluayB0aGF0IHdlIG5lZWQgdG8gY2hhbmdlIGZyb20g YSAzMiBieXRlIG92ZXJoZWFkLiBUaGlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPiZndDsgZGVjaXNpb24gY291bGQgcmVkdWNlIGNvZGUgY29tcGxleGl0eSBpbiBz aGFyZWQgUUNSQU0vSFBBQ0sNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBpbXBsZW1lbnRhdGlvbnMgKGluIG15IGltcGxlbWVudGF0aW9uIGl0IHdvdWxkKS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7ICMgRHVwbGljYXRpb24gRG9lc24ndCBO ZWVkIHRvIFJlZmVyZW5jZSB0aGUgU3RhdGljIFRhYmxlPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+Jmd0OyBEdXBsaWNhdGlvbiBvbmx5IG1ha2VzIHNlbnNlIGZvciBkeW5hbWljIGVudHJp ZXMgYW5kIHlldCB0aGUgaW5kZXggaXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyAoSSBhc3N1bWUpLCB0aGUgbm9ybWFsIHRhYmxlIGluZGV4LiBUaGF0IGlz IGhpZ2hseSBzdWJvcHRpbWFsLiBUaGlzIGlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgd29yc2UgYmVjYXVzZSB0aGUgcHJlZml4IGlzIG9ubHkgNSBiaXRz IGZvciB0aGlzIGluc3RydWN0aW9uICh1cCB0byA2Mg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IHZhbHVlcyksIHdoaWNoIGxlYWRzIHRvIHRoZSBlbmNvZGlu ZyB0YWtpbmcgYW4gZXh0cmEgYnl0ZSBhbHdheXMuIElmDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPiZndDsgeW91IHRha2UgbXkgc3VnZ2VzdGlvbiBmb3Igc2VwYXJh dGUgaW5zdHJ1Y3Rpb24gc3BhY2VzLCB0aGlzIGlzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgYmV0dGVyLCBidXQgc3RpbGwgbm90IGFzIGdvb2QgYXMgYSBk aXJlY3QgaW5kZXggaW50byB0aGUgZHluYW1pYw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IHRhYmxlLCBzdGFydGluZyBhdCAwLiBCZXR0ZXIgeWV0IHdvdWxk IGJlIGEgcmV2ZXJzZSBpbmRleCwgc3RhcnRpbmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBmcm9tIHRoZSBlbmQgb2YgdGhlIHRhYmxlLCBiZWNhdXNlIGR1 cGxpY2F0aW9uIG9mdGVuIG5lZWRzIHRvIHJlZmVyIHRvIHRoZSBlbmQgb2YgdGhlIHRhYmxlLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZndDsgIyBOZWVkIEJldHRlciBBZHZpY2Ugb24g UmVmZXJlbmNpbmcgc3RyYXRlZ3k8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZndDsgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IFJl ZmVyZW5jaW5nIGVudHJpZXMgbmVhciB0aGUgZW5kIG9mIHRoZSB0YWJsZSBpbiBhIG5ldyBoZWFk ZXIgYmxvY2sgaXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBoYXphcmRvdXMuIElmIHlvdSBqdXN0IGNvbXByZXNzIGFzIHlvdSBkbyBpbiBIUEFDSywgeW91 IGNhbiBlbmQgdXANCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Jmd0 OyBwaW5uaW5nIGVudHJpZXMgaW4gdGhlIGhlYWRlciB0YWJsZSwgbWFraW5nIGl0IGltcG9zc2li bGUgdG8gYWRkIG5ldw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4m Z3Q7IGVudHJpZXMuIFRodXMsIHlvdSBoYXZlIHRvIHN0b3AgcmVmZXJlbmNpbmcgZW50cmllcyBh cyB0aGV5IGdldCBuZWFyZXINCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyB0byB0aGUgdGFibGUgY2FwYWNpdHkgbGltaXQuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+Jmd0OyBJbiBteSBpbXBsZW1lbnRhdGlvbiBJIGFkZGVkIGEgdGhyZXNob2xkIHZh cmlhYmxlIHRoYXQgZ292ZXJucyBteQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IHJlZmVyZW5jaW5nIHN0cmF0ZWd5LiBBIHBvcnRpb24gb2YgdGhlIGhlYWRl ciB0YWJsZSBzcGFjZSBpcyBtYXJrZWQgYXMNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+Jmd0OyBiZWluZyBvZmYtbGltaXRzIGZvciBoZWFkZXIgYmxvY2sgdXNhZ2Uu IFRoZSBlbmNvZGVyIGR1cGxpY2F0ZXMgdGhvc2UNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+Jmd0OyBlbnRyaWVzIGlmIGl0IHdhbnRzIHRvIGNvbXByZXNzLCBidXQg d29uJ3QgcmVmZXJlbmNlIHRoZW0uIElmIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IHRhYmxlIGlzIHVuZGVyIHByZXNzdXJlIGZyb20gdGhlIG5ldyBo ZWFkZXIgZmllbGRzIGJlaW5nIGFkZGVkLCB0aGVuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgaXQgc2hvdWxkIGJlIGFibGUgdG8gYWR2YW5jZSBieSBhdCBs ZWFzdCB0aGlzIGFtb3VudCBldmVyeSByb3VuZCB0cmlwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+Jmd0OyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgVGhpcyBpcyBhIHNpbXBsZSBzdHJhdGVneSwgYW5kIHByb2JhYmx5IHN1Ym9w dGltYWwgaW4gdmFyaW91cyB3YXlzLA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IGJ1dCBpdCBzZWVtcyB0byB3b3JrIG91dC4gRm9yIGluc3RhbmNlLCBJIGNv bnRpbnVvdXNseSB1cGRhdGUgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgY3V0b2ZmIGFzIGVudHJpZXMgYXJlIGluc2VydGVkLCBzbyB0aGF0IGEgaGVh ZGVyIGJsb2NrIG1pZ2h0IGVuZCB1cA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij4mZ3Q7IHJlZmVyZW5jaW5nIHRoaW5ncyB0aGF0IGdldCBwdXNoZWQgaW50byB0aGlz IHNwYWNlIGJ5IGxhdGVyIGhlYWRlciBmaWVsZHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jmd0OyBZb3UgY2FuIGltYWdpbmUgbW9yZSBhZHZhbmNlZCB0ZWNobmlxdWVzLiBGb3IgaW5z dGFuY2UsIHlvdSBtaWdodCB0dW5lDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZndDsgdGhpcyB3aW5kb3cgYXV0b21hdGljYWxseSBiYXNlZCBvbiB0aGUgcmF0ZSB0 aGF0IHRoZSBoZWFkZXIgdGFibGUgZ3Jvd3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij4mZ3Q7IEJlY2F1c2UgcmVmZXJlbmNlcyBpbiB0aGF0IHdpbmRvdyBibG9jayBl dmljdGlvbiwgaXQgc2hvdWxkIGJlIHNpemVkDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgdG8gdGhlIHJhdGUgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPiZndDsgKmRlc2lyZWQqIGdyb3d0aCBpbiB0aGUgaGVhZGVyIHRhYmxl IG92ZXIgYSByb3VuZCB0cmlwLiBUYWtpbmcgYQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mZ3Q7IHJ1bm5pbmcgZXN0aW1hdGUgb2YgdGhhdCBkZXNpcmVkIGdyb3d0 aCBhbmQgYWxsb3dpbmcgYSBtYXJnaW4gZm9yDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZndDsgdmFyaWFuY2UgY291bGQgcHJvZHVjZSB0aGUgcmlnaHQgdmFsdWUu IEkgaGF2ZW4ndCBleHBlcmltZW50ZWQgd2l0aCB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_MWHPR08MB24321A1087F2D7CC7EA46F36DAF20MWHPR08MB2432namp_-- From nobody Fri Feb 9 10:15:30 2018 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 98DFA1201F8 for ; Fri, 9 Feb 2018 10:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 IoM1Qf2iMuBU for ; Fri, 9 Feb 2018 10:15:26 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 0EAE71200B9 for ; Fri, 9 Feb 2018 10:15:26 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id 196so11716018iti.5 for ; Fri, 09 Feb 2018 10:15:25 -0800 (PST) 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=yVOyz0TJnPtmJ8tPkNKiqvJNaCNtB6/O5ANEGS+HVtE=; b=IiUC8/C/17DLEmiTM6tpKqBPbvU+GjTdjNtBMOFXyx+w+HmT4BXwzovJ3PgbgEgr/J vYwf6QUGYsMVq5hKNtAwk8Kx+MBwY8A7NKTUGkK99n8FuSNVIVzTxQMd1EscFDlgqbym w7q/eZWBw1ukLRSmMEAQnFat6femYDygFbhhUaQxufPZ51L4NE1zoaSgX944Tw6OY2lA Tr13tcNLzCk94YNTU1MJO91cCBcPwc8Od1Q2WiMqKIR3zXLuf6PmyHdBKUoH7eFe9T7h K/5Y7qKEvaQ/IJCZnyQtg59KVbXCCPLmCpGFpqyxukx4qUlQlAy3nUvN5INH1w6mFdCk yF/w== 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=yVOyz0TJnPtmJ8tPkNKiqvJNaCNtB6/O5ANEGS+HVtE=; b=SnqMPX9zc4Hq/BMLHA2kQyil8LOzrd5FI2SZBmFoQqtmyb2zc8qCbHKXoi8xYGCH60 4FhOsiz4kU5+h+Vnn3UWt89JdH9+bjIer7kVpBa+mrV3CTMTCCPez1pfH4r975ftdlqF V4WT4S+Wx/2hGwyaKP2imSUpbhLcGGy9vWRKE03cO5K3YEsHMlYCst2M9x09Co00QxVv Y/1DRqYKMsZD5E6lnlVkscHS8gn5re3z5sPaGhOAhUgRHGRvJSi4Y78ijPlFPLFzKXqE 5uAz2QUwrdU9ZhFSBVfIlIepj1rx/yxDYaim7/g2z+M619ioawjvQwIKcF7prf6uAixq 1IdA== X-Gm-Message-State: APf1xPC/wRllnHqoEyyhG3VGvQw/51GJZXAacWCm3PhpB4sNo9HA6j3E KpZD/o8CkUJ+jUweVWR6CITbDvcIYoYuX2nxhA+N X-Google-Smtp-Source: AH8x2247wGzzFaBcFW5wgIXdVg2DkvAOmOS4fsgF6TUDjwEqxQTAMv+qtEFXV1kGh6o6WHd4ZrSX2N0HMJXyWUfhi00= X-Received: by 10.36.178.18 with SMTP id u18mr4917925ite.8.1518200124874; Fri, 09 Feb 2018 10:15:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.176.207 with HTTP; Fri, 9 Feb 2018 10:15:04 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Fri, 9 Feb 2018 10:15:04 -0800 Message-ID: Subject: Re: Review of QCRAM To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="f403045d99ea24f0520564cb830b" 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, 09 Feb 2018 18:15:29 -0000 --f403045d99ea24f0520564cb830b Content-Type: text/plain; charset="UTF-8" Thanks Martin! I am behind in digesting this, I intend to comment later today. In the meantime though, have you looked at QCRAM doc github repo ? (Notice it has working diff against -04). The reason I ask, is that I made updates there in response to various comments around the time of the interim. I think the diffs relate partially to some of your ideas. On Fri, Feb 9, 2018 at 2:08 AM, Martin Thomson wrote: > I have implemented QCRAM and have a few things to comment on. > > My implementation is here: > https://github.com/martinthomson/minhq/tree/master/hc > > This is my first attempt at go, so this took a little longer than it might > have > otherwise. Test coverage is still a little light, though go thinks that I > have > pretty good coverage. There's probably still a lot to go on the corner > cases, > but I think that I've done enough to get an idea for the complexity bump. > > I started by implementing HPACK, which is surprisingly easy if you don't > care > about being efficient. Though I knew that I was going to add QCRAM, I made > only > minimal design concessions when building HPACK. > > Building QCRAM on top of HPACK took at least 50% more than just doing > HPACK (at > a guess, HPACK took about 10-12 hours, QCRAM took closer to 20). Even > though > you can reuse Huffman coding and most of the primitives, retrofitting it > was > tricky. My lack of familiarity with go definitely contributed a lot to > that, > but I'd say that QCRAM is more difficult to implement than it seems in > theory. > > I didn't implement QCRAM entirely as specified. There are a few things that > I'll describe below that would make it either better or easier to > implement (or > both). > > > # Separate Stream Roles > > There are actually three streams of data that are of interest, and there > is no > clarity about those streams. > > 1. I suggest that we use unidirectional streams in each direction for table > updates. > > 2. A separate stream for acknowledgments ensures that the encoder can > consume > that separately to the decoder. > > 3. Request/response streams. I think that we all understand these. > > These can be separate from the hq control stream, and they should be. > Rather > than pick a specific stream number, we should add a header for these > streams > that will allow them to be identified clearly. If we do that, add strict > rules > about cardinality. > > # Define Framing More Clearly > > The definition of the framing that is used on the control stream is > unclear. I > assume that the intent is to use HEADERS frames, but I'm only really > guessing. > If you take my suggestion for separate framing, then you can use very > different > logic for the different streams. > > Honestly, the overhead of framing is excessive for anything but > request/response streams. I found that framing on the control stream wasn't > necessary at all. This might depend on implementation strategy, because it > might be easier to collect a framed thing than it is to read until you are > blocked, then pickle that state so that you can go back to something else. > In > my implementation I hold state on the stack, so it's pretty easy. > > Also, it should suffice to have just a stream of varints indicating > acknowledgments. Duplicates can be used to acknowledge multiple header > blocks > on the same stream in order. > > # Split the Instruction Space > > Having to check that only certain instructions appear on different streams > is > annoying to implement and a waste of bits. Define two separate spaces. That > should make things much simpler: there are exactly two instructions in each > space then (leaving aside acknowledgments, which I will cover below). > > # Base in Every HEADERS Frame > > Base (the number of inserts in the table at the start of a header block) > seems > to be required for all HEADERS frames, including both table modification > and > request/response streams. But... > > # Base on the Table Update Stream > > You don't need base for table updates. It is more of a hazard than a help. > It > is easier if you treat indexing on the table update stream as in HPACK > where > each insert moves the reference point for the next insertion. > > # Remove BLOCKING > > The BLOCKING flag complicates the design unnecessarily. As a fixed > overhead, > pay the extra byte always. Furthermore, the table update stream will never > need > to use depends, so that further motivates having different instruction sets > (and formats) for different streams. And you don't need it... > > # Base and the Static Table > > It is not explained at all that the base is applied to the dynamic table > only. > That is, index 1 is a straight index into the static table and that index > 62 > will use the current number of inserts and the base to determine the actual > index into the dynamic table (this is the first table entry only when the > number of table inserts and base are the same, if the base is smaller, > then it > will be further along the table). > > To be clear, my logic for finding entries is: > > if i == 0: error > if i <= len(staticTable): return staticTable[i-1] > delta = tableBase - base > if delta < 0: error > return dynamicTable[i - len(staticTable) - 1 + delta] > > # Remove Depends > > Depends is useless. I did not implement it. Base is sufficient. > > This follows from preferring to use the smallest value for base possible. > Doing > that also keeps table references as small as possible. (Because references > are > counted in the opposite direction to base, a larger base means larger > references.) > > The cost is that you have to do a two pass check: the first to find the > newest > reference, the second to write out the header block. I find that it's > basically > necessary to do two passes anyway: on the first I write out the table > updates, > on the second I write the header block. During that phase you want to do > lookups anyway, so you can save the largest base from that pass. Also, > when you > insert anything, that tends to set the base, so it's pretty easy overall. > > # Tracking ACKs is Harder Than It Seems > > There are multiple header blocks per stream, and ACKs only identify the > stream. > You can't just store a stream reference (or Request-ID) against each header > block, you have to store a tuple of stream and header block index. This > needs > to be explained somewhere. > > I decided to externalize ACKs - the QCRAM encoder takes a generic blob as > input > when it encodes a header block and the same generic blob to acknowledge > it. The > caller then has to combine stream ID and header block index in a sensible > fashion. > > # Acknowledge Dmitry > > So I don't forget... Dmitry did a lot of work on the design team. > > # Dynamic Table Overhead > > The draft has a TODO about overhead for each dynamic entry. I added a > field to > every entry that allows it to know its own position in the table, but that > is a > simplification/optimization, and you don't really need that. The other > per-record overheads are all the same for the decoder, with a small > increase to > the fixed overhead. It's a little more state for an encoder, but that is > mostly > because of having to track usage. > > I don't think that we need to change from a 32 byte overhead. This decision > could reduce code complexity in shared QCRAM/HPACK implementations (in my > implementation it would). > > # Duplication Doesn't Need to Reference the Static Table > > Duplication only makes sense for dynamic entries and yet the index is (I > assume), the normal table index. That is highly suboptimal. This is worse > because the prefix is only 5 bits for this instruction (up to 62 values), > which > leads to the encoding taking an extra byte always. If you take my > suggestion > for separate instruction spaces, this is better, but still not as good as a > direct index into the dynamic table, starting at 0. Better yet would be a > reverse index, starting from the end of the table, because duplication > often > needs to refer to the end of the table. > > # Need Better Advice on Referencing strategy > > Referencing entries near the end of the table in a new header block is > hazardous. If you just compress as you do in HPACK, you can end up pinning > entries in the header table, making it impossible to add new entries. > Thus, you > have to stop referencing entries as they get nearer to the table capacity > limit. > > In my implementation I added a threshold variable that governs my > referencing > strategy. A portion of the header table space is marked as being > off-limits for > header block usage. The encoder duplicates those entries if it wants to > compress, but won't reference them. If the table is under pressure from > the new > header fields being added, then it should be able to advance by at least > this > amount every round trip. > > This is a simple strategy, and probably suboptimal in various ways, but it > seems to work out. For instance, I continuously update the cutoff as > entries > are inserted, so that a header block might end up referencing things that > get > pushed into this space by later header fields. > > You can imagine more advanced techniques. For instance, you might tune this > window automatically based on the rate that the header table grows. Because > references in that window block eviction, it should be sized to the rate of > *desired* growth in the header table over a round trip. Taking a running > estimate of that desired growth and allowing a margin for variance could > produce the right value. I haven't experimented with this. > > -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --f403045d99ea24f0520564cb830b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Martin!

I am behind in digesting= this, I intend to comment later today.

In the mea= ntime though, have you looked at=C2=A0QCRAM doc github repo=C2=A0?=C2=A0 (Notice it = has working diff against -04).=C2=A0 The reason I ask, is that I made updat= es there in response to various comments around the time of the interim.=C2= =A0 =C2=A0I think the diffs relate partially to some of your ideas.



On Fri, Feb 9, 2018 at 2:08 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I have implemented QCRAM and have a few things to comment on.

My implementation is here:
=C2=A0 https://github.com/martinthomson/mi= nhq/tree/master/hc

This is my first attempt at go, so this took a little longer than it might = have
otherwise. Test coverage is still a little light, though go thinks that I h= ave
pretty good coverage. There's probably still a lot to go on the corner = cases,
but I think that I've done enough to get an idea for the complexity bum= p.

I started by implementing HPACK, which is surprisingly easy if you don'= t care
about being efficient. Though I knew that I was going to add QCRAM, I made = only
minimal design concessions when building HPACK.

Building QCRAM on top of HPACK took at least 50% more than just doing HPACK= (at
a guess, HPACK took about 10-12 hours, QCRAM took closer to 20). Even thoug= h
you can reuse Huffman coding and most of the primitives, retrofitting it wa= s
tricky. My lack of familiarity with go definitely contributed a lot to that= ,
but I'd say that QCRAM is more difficult to implement than it seems in = theory.

I didn't implement QCRAM entirely as specified. There are a few things = that
I'll describe below that would make it either better or easier to imple= ment (or
both).


# Separate Stream Roles

There are actually three streams of data that are of interest, and there is= no
clarity about those streams.

1. I suggest that we use unidirectional streams in each direction for table=
updates.

2. A separate stream for acknowledgments ensures that the encoder can consu= me
that separately to the decoder.

3. Request/response streams. I think that we all understand these.

These can be separate from the hq control stream, and they should be. Rathe= r
than pick a specific stream number, we should add a header for these stream= s
that will allow them to be identified clearly. If we do that, add strict ru= les
about cardinality.

# Define Framing More Clearly

The definition of the framing that is used on the control stream is unclear= . I
assume that the intent is to use HEADERS frames, but I'm only really gu= essing.
If you take my suggestion for separate framing, then you can use very diffe= rent
logic for the different streams.

Honestly, the overhead of framing is excessive for anything but
request/response streams. I found that framing on the control stream wasn&#= 39;t
necessary at all. This might depend on implementation strategy, because it<= br> might be easier to collect a framed thing than it is to read until you are<= br> blocked, then pickle that state so that you can go back to something else. = In
my implementation I hold state on the stack, so it's pretty easy.

Also, it should suffice to have just a stream of varints indicating
acknowledgments. Duplicates can be used to acknowledge multiple header bloc= ks
on the same stream in order.

# Split the Instruction Space

Having to check that only certain instructions appear on different streams = is
annoying to implement and a waste of bits. Define two separate spaces. That=
should make things much simpler: there are exactly two instructions in each=
space then (leaving aside acknowledgments, which I will cover below).

# Base in Every HEADERS Frame

Base (the number of inserts in the table at the start of a header block) se= ems
to be required for all HEADERS frames, including both table modification an= d
request/response streams.=C2=A0 But...

# Base on the Table Update Stream

You don't need base for table updates. It is more of a hazard than a he= lp. It
is easier if you treat indexing on the table update stream as in HPACK wher= e
each insert moves the reference point for the next insertion.

# Remove BLOCKING

The BLOCKING flag complicates the design unnecessarily. As a fixed overhead= ,
pay the extra byte always. Furthermore, the table update stream will never = need
to use depends, so that further motivates having different instruction sets=
(and formats) for different streams.=C2=A0 And you don't need it...

# Base and the Static Table

It is not explained at all that the base is applied to the dynamic table on= ly.
That is, index 1 is a straight index into the static table and that index 6= 2
will use the current number of inserts and the base to determine the actual=
index into the dynamic table (this is the first table entry only when the number of table inserts and base are the same, if the base is smaller, then= it
will be further along the table).

To be clear, my logic for finding entries is:

=C2=A0 =C2=A0 if i =3D=3D 0: error
=C2=A0 =C2=A0 if i <=3D len(staticTable): return staticTable[i-1]
=C2=A0 =C2=A0 delta =3D tableBase - base
=C2=A0 =C2=A0 if delta < 0: error
=C2=A0 =C2=A0 return dynamicTable[i - len(staticTable) - 1 + delta]

# Remove Depends

Depends is useless. I did not implement it. Base is sufficient.

This follows from preferring to use the smallest value for base possible. D= oing
that also keeps table references as small as possible. (Because references = are
counted in the opposite direction to base, a larger base means larger
references.)

The cost is that you have to do a two pass check: the first to find the new= est
reference, the second to write out the header block. I find that it's b= asically
necessary to do two passes anyway: on the first I write out the table updat= es,
on the second I write the header block. During that phase you want to do lookups anyway, so you can save the largest base from that pass. Also, when= you
insert anything, that tends to set the base, so it's pretty easy overal= l.

# Tracking ACKs is Harder Than It Seems

There are multiple header blocks per stream, and ACKs only identify the str= eam.
You can't just store a stream reference (or Request-ID) against each he= ader
block, you have to store a tuple of stream and header block index. This nee= ds
to be explained somewhere.

I decided to externalize ACKs - the QCRAM encoder takes a generic blob as i= nput
when it encodes a header block and the same generic blob to acknowledge it.= The
caller then has to combine stream ID and header block index in a sensible fashion.

# Acknowledge Dmitry

So I don't forget... Dmitry did a lot of work on the design team.

# Dynamic Table Overhead

The draft has a TODO about overhead for each dynamic entry. I added a field= to
every entry that allows it to know its own position in the table, but that = is a
simplification/optimization, and you don't really need that. The other<= br> per-record overheads are all the same for the decoder, with a small increas= e to
the fixed overhead. It's a little more state for an encoder, but that i= s mostly
because of having to track usage.

I don't think that we need to change from a 32 byte overhead. This deci= sion
could reduce code complexity in shared QCRAM/HPACK implementations (in my implementation it would).

# Duplication Doesn't Need to Reference the Static Table

Duplication only makes sense for dynamic entries and yet the index is (I assume), the normal table index. That is highly suboptimal. This is worse because the prefix is only 5 bits for this instruction (up to 62 values), w= hich
leads to the encoding taking an extra byte always. If you take my suggestio= n
for separate instruction spaces, this is better, but still not as good as a=
direct index into the dynamic table, starting at 0. Better yet would be a reverse index, starting from the end of the table, because duplication ofte= n
needs to refer to the end of the table.

# Need Better Advice on Referencing strategy

Referencing entries near the end of the table in a new header block is
hazardous. If you just compress as you do in HPACK, you can end up pinning<= br> entries in the header table, making it impossible to add new entries. Thus,= you
have to stop referencing entries as they get nearer to the table capacity limit.

In my implementation I added a threshold variable that governs my referenci= ng
strategy. A portion of the header table space is marked as being off-limits= for
header block usage. The encoder duplicates those entries if it wants to
compress, but won't reference them. If the table is under pressure from= the new
header fields being added, then it should be able to advance by at least th= is
amount every round trip.

This is a simple strategy, and probably suboptimal in various ways, but it<= br> seems to work out. For instance, I continuously update the cutoff as entrie= s
are inserted, so that a header block might end up referencing things that g= et
pushed into this space by later header fields.

You can imagine more advanced techniques. For instance, you might tune this=
window automatically based on the rate that the header table grows. Because=
references in that window block eviction, it should be sized to the rate of=
*desired* growth in the header table over a round trip. Taking a running estimate of that desired growth and allowing a margin for variance could produce the right value. I haven't experimented with this.




--
Charles '= ;Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141

--f403045d99ea24f0520564cb830b-- From nobody Fri Feb 9 10:21:17 2018 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 65BF412D778 for ; Fri, 9 Feb 2018 10:21:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 h21DBX07Qkid for ; Fri, 9 Feb 2018 10:21:13 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 98C401201F8 for ; Fri, 9 Feb 2018 10:21:13 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id j21so3710131ita.1 for ; Fri, 09 Feb 2018 10:21:13 -0800 (PST) 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=HIjeTnzgfGH0euaII+Z5m8hZKG/VAVUma428eWEz5k8=; b=u4Kg1cQ6s3URmKBrduLg0YxfewhcG7HCRfws7AoW9p4HuSgiM0+50bYY+RsH+GnSXg gOAJVBG9e+O75WDx5wcR1KxNcdtUQZyyx2aePeuNGK3yH0VIdU4HWbcwZfGTxY19710b 8On4ZvmhdCUPHbZ90UNdRlrj2G2pT8zyT0cvPQCbcHt7tZlan9fsusdrYtk7/hyQ5NPj r9mBF5WnrZG/8XbOdHuO7w9zUwSuj/Zcw+j+EGXamKo53Et9z1h/5jSg6EPxfHAlQ4HY Huk9d6h/DNk47BW6z6/zWzXYRpHIJqeNLrX37OFs6tc713SPXgDFFZ2dIGRRD+o2VEVV 6p5g== 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=HIjeTnzgfGH0euaII+Z5m8hZKG/VAVUma428eWEz5k8=; b=RC40mrKzzX4FA/25ZtsrPKcQqWYisarAhZaCTsKoeifbo4oJOrrQcWVKQvrqGNMuTM lyy30Dkp8WHNoQ1qAO33XsdcrQy+Q9R8XzHLbDQEWVnG1+1O21IC8CFQVz5LsDVuBSyA zovG9oHDV5DKIV96coEKV6PB1CLaCSXmGbFpB25cSF5//THvjt+xH0ibemUKQmMhswky Nzn/m+xwIdpq5jIKvel/3Hrw98eloCHXXTj9Cx/Pj1CaArY/MbjXni4JgQ0DhbrLyHHd cfmIQL45qYW7iH1QIiJ9psFMA69r3qf6cK6QcsRiMfC+ESjh+TTXG63UtDR0eIs4sYW3 hTIg== X-Gm-Message-State: APf1xPDgr7b0w8dFzJ0wW7WObzV9I4nARUWCYpY86zLcHzHsXs/4tywV RiwEOj/qU8Z0DixBSjZ7YBkf8dkWOkT7pBEyUML4dooi X-Google-Smtp-Source: AH8x227iW804IvUM4N+B0XYIWoTPrwzzxErM6SilOExEGWWAE6iQfPgw5b9sUNeHAwA3b33Ehpsg6jUlO6X5ajRx8us= X-Received: by 10.36.167.67 with SMTP id s3mr4865942iti.66.1518200472833; Fri, 09 Feb 2018 10:21:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Fri, 9 Feb 2018 10:20:52 -0800 (PST) In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> From: Ian Swett Date: Fri, 9 Feb 2018 13:20:52 -0500 Message-ID: Subject: Re: Packet number encryption To: "Salz, Rich" Cc: Praveen Balasubramanian , Eric Rescorla , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="f403045fb1c8e206c30564cb9713" 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, 09 Feb 2018 18:21:15 -0000 --f403045fb1c8e206c30564cb9713 Content-Type: text/plain; charset="UTF-8" One issue with the current encryption proposal is you can't use hardware crypto offload for the bulk encryption because the packet number has to be encrypted after the bulk data. Any suggestions on how to fix that? On Fri, Feb 9, 2018 at 12:42 PM, Salz, Rich wrote: > Thanks for the summary. Why do you want to do this? > > > --f403045fb1c8e206c30564cb9713 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
One issue with the current encryption proposal is you can&= #39;t use hardware crypto offload for the bulk encryption because the packe= t number has to be encrypted after the bulk data.

Any su= ggestions on how to fix that?

On Fri, Feb 9, 2018 at 12:42 PM, Salz, Rich <rsalz@= akamai.com> wrote:

Thanks for the summary.=C2=A0 Why do you want to do = this?

=C2=A0


--f403045fb1c8e206c30564cb9713-- From nobody Fri Feb 9 10:32:27 2018 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 34CF812704A for ; Fri, 9 Feb 2018 10:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 m3QCxQ1XoDO3 for ; Fri, 9 Feb 2018 10:32:24 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 770161200B9 for ; Fri, 9 Feb 2018 10:32:24 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id x128so12099336ite.0 for ; Fri, 09 Feb 2018 10:32:24 -0800 (PST) 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=lFseSQoINnMaxx86/k/cauP/vEHD3raknSJ9MF21LIY=; b=RXOxbj9PlacuD7FL8UABLteg9o9/iVbo6N+22ZCPZN2vtfJmYs2UdteUqw1uOGpdpK RqGFZiCimxoMfYMcQ6dpX0VUGbnPPeUdkdXioTDUZos/Fc+3NNRGIaU9ZZz/6Y7vqHQk bjK2jGW793pXFQVRHwBJYQ4B6LYppyXL6sMRK1ZEdiP51fuaXx3n1pDf13Lo3+7cSrks RQM/r9iwyrg4BClsszb14eLVOThd5+ht+nptZcZ6t4gfM8Mk3ACPKwuzQqxhSIK10NT5 9Qz5uA3sUX6bmDEI1bikGXUz5RhfKzawyA5ieWjO/q5C/+arZJRQ4/MBVgUKMP/SMpsa fd6Q== 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=lFseSQoINnMaxx86/k/cauP/vEHD3raknSJ9MF21LIY=; b=TzSAIJCi1D1u8EczSvYXhBXPVOtcu40fD6aoZml8wbx3V5XJZ2aobbPLCiGIkBI/zj FSLNS9BpOaaQ5UqX1Ur71jx4ai4ZMLNdr7Gao4YzdIKdK6DcaSkvhnS3OZambsuvAR5x W8dX+1YIJQRNk2IfIZChCmJl2hrGozthbunLGR23yudCCFkdK269iw0WwAu4Bwa1NrkA d1C10dH8GgkQjr50dnXhMBm/h2Hn0l5xSwzX3diRhNouDskbZiy0y7eiwRvcL0Jiolyi 32u7Wazo9hmoyfhLqkMLgBE+4yAid174ToxkNkq4B78lmdOtYuUWyuLKFkFsVzEP0o0T Smvg== X-Gm-Message-State: APf1xPDSqjdi4WuYntrNPb10jogII5fbxJZi/GloF1FeO4EFqRYbtMPS yn5DJr6l7pLfbAsfsPz9o/wknMrctx95fDmLNyNlL97U X-Google-Smtp-Source: AH8x226odly4/AlDqWg7ZMVbTsicFmhMA/AZpkh0mivm9f3soiU5S/y7OU9gwl7un22Hqqkt5saES2d6XgeEbNsPIUw= X-Received: by 10.36.43.20 with SMTP id h20mr4933381ita.42.1518201143644; Fri, 09 Feb 2018 10:32:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Fri, 9 Feb 2018 10:32:03 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Fri, 9 Feb 2018 13:32:03 -0500 Message-ID: Subject: Re: The Recovery Period To: Patrick McManus Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11459092de0f510564cbbf85" 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, 09 Feb 2018 18:32:26 -0000 --001a11459092de0f510564cbbf85 Content-Type: text/plain; charset="UTF-8" I think this is consistent, but possibly a psuedocode definition of InRecovery() is warranted as well? InRecovery() return largest_acked_packet <= end_of_recovery Or maybe end_of_recovery is a slightly confusing term? On Fri, Feb 9, 2018 at 12:48 PM, Patrick McManus wrote: > Hi All, > > 4.3 of the recovery draft: > > Recovery is a period of time beginning with detection of a lost packet. > Because QUIC retransmits stream data and control frames, not packets, it > defines the end of recovery as a packet sent after the start of recovery > being acknowledged. > > and then in 4.7.2 > > end_of_recovery: The largest packet number sent when QUIC detects a loss. > When a larger packet is acknowledged, QUIC exits recovery. > and then in 4.7.6 > > OnPacketsLost() [...] > end_of_recovery = largest_sent_packet > > I think these are inconsistent.. essentially 4.7.2 and 4.7.6 should be > "next packet number sent" not "largest currently sent" - true? > > > > > --001a11459092de0f510564cbbf85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is consistent, but possibly a psuedocode defi= nition of InRecovery() is warranted as well?

InRecovery(= )
=C2=A0 return largest_acked_packet <=3D end_of_recovery

Or maybe end_of_recovery is a slightly confusing term?=

On Fri, Feb= 9, 2018 at 12:48 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
Hi All,<= /div>

4.3 of the recovery draft:

Recovery is a period of time beginning with= detection of a lost packet.=20 Because QUIC retransmits stream data and control frames, not packets,=20 it defines the end of recovery as a packet sent after the start of=20 recovery being acknowledged.=C2=A0

and then= in 4.7.2

end_of_recovery:
The largest pack= et number sent when QUIC detects a loss. When a larger packet is acknowled= ged, QUIC exits recovery.

and then in 4.7.6
= 
OnPacketsLost() [...]
=C2=A0end_of_recovery =3D lar=
gest_sent_packet
I think these are inconsistent.. essential= ly 4.7.2 and 4.7.6 should be "next packet number sent" not "= largest currently sent" - true?





--001a11459092de0f510564cbbf85-- From nobody Fri Feb 9 11:10:19 2018 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 6FAFD12D7F3 for ; Fri, 9 Feb 2018 11:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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 (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 0rbkvS-oZURE for ; Fri, 9 Feb 2018 11:10:15 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0100.outbound.protection.outlook.com [104.47.32.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30CC12D7E9 for ; Fri, 9 Feb 2018 11:10:14 -0800 (PST) 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=i3U+YoPK7cG7lUoGBVWIvaPBGVWMXenD7x5uPac5oSs=; b=O9Idj0kj/jQEtvWsQMfqKfWs4y8JKcyWEoc9ZM1/tydN+0FBHCEAaR0h/sL6KuBZCXuWHhdcMLPVl3FO6R086Uc6kTnk+AEq2cvApw9yZ6KbAPV2c1RHz+glKA1nnoMXXmZdnYY5E8uHQ0HN+ML+po/xH4NLpqDp1XHrm/282jc= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0469.namprd21.prod.outlook.com (10.172.121.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.4; Fri, 9 Feb 2018 19:10:13 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 19:10:13 +0000 From: Praveen Balasubramanian To: "Salz, Rich" , Eric Rescorla CC: "quic@ietf.org" , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwIAAjJeAgAA5dnCAAAb3gIAAF6YA Date: Fri, 9 Feb 2018 19:10:12 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0469; 7:oVrIV0dXgiAPwgHbaVgyK4koJXp7/V3wsoRK2DCrIIpALaa9UJZldp+/Y+m+YoXQFGloU+7rwWOibHEORatIjLywIHXaEeJ66dEoXun4r1PojeeXqHd8U1AuTVkHLcd5GpHrHXs2ncuBvwLWfwGbaVF9zQVIA9A0WLOu343AkxjVMp9iuoI39HQg7chhMvimXf+gi+/Ffxu+bF5AUBZ9yV2tq65ian2M6XjbCuA10lIpvZJpCOZK7Phl6MSpCGa5 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 9f92e09b-72ae-41a5-762d-08d56ff0bf01 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0469; x-ms-traffictypediagnostic: CY4PR21MB0469: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0469; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0469; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(346002)(376002)(396003)(366004)(51914003)(199004)(189003)(25786009)(68736007)(33656002)(93886005)(3480700004)(3660700001)(74316002)(4326008)(316002)(105586002)(110136005)(54906003)(10090500001)(106356001)(2906002)(7736002)(22452003)(8990500004)(6346003)(102836004)(6116002)(790700001)(76176011)(6436002)(53546011)(6506007)(2900100001)(186003)(2950100002)(97736004)(5660300001)(5250100002)(3280700002)(6246003)(55016002)(6306002)(54896002)(9686003)(7116003)(229853002)(53936002)(10290500003)(7696005)(81156014)(81166006)(478600001)(8676002)(99286004)(14454004)(86362001)(86612001)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0469; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: eKQkBtoQmSqlCb3Spew+c0a9btFfvUnyR2IYG+wRewmO0n4ihsNtQiBNYzkpZI/sUR60x6iMjcNdSXLbxf85Pw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133427E65B3587C7577A454B6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f92e09b-72ae-41a5-762d-08d56ff0bf01 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 19:10:12.9233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0469 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, 09 Feb 2018 19:10:17 -0000 --_000_CY4PR21MB0133427E65B3587C7577A454B6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmVjYXVzZSBvZiB0aGUgbGlzdGVkIGFkdmFudGFnZXMuIENsZWFyIHNlcGFyYXRpb24gb2YgY29u Y2VybnMgcmVzdWx0cyBpZiB3ZSBkb27igJl0IG92ZXJsb2FkIHRoZSBwYWNrZXQgbnVtYmVyIGFz IHRoZSBub25jZS4gQ29ubmVjdGlvbiBtaWdyYXRpb24gYW5kIG11bHRpLXBhdGggYXJlIG9wdGlv bmFsIGZlYXR1cmVzIGFuZCB3ZSBwYXkgbm8gZXh0cmEgY29tcHV0ZSBjb3N0IGZvciBtb3N0IGNv bm5lY3Rpb25zIHRoYXQgYXJlIG5vdCBpbXBhY3RlZCBieSB1bmxua2FiaWxpdHkuIE5vbmNlIGZp ZWxkIGJlY29tZXMgb3B0aW9uYWwgZm9yIGNyeXB0byB0aGF0IGRvZXNu4oCZdCBuZWVkIGl0IGFu ZCBjYW4gZ3JvdyB0byBsYXJnZXIgc2l6ZSBhcyBuZWVkZWQgZm9yIGJ1bGsgdHJhbnNmZXJzIHRv IHByZXZlbnQgZnJlcXVlbnQga2V5IHJvbGxvdmVycyAoc2F5IGluIGRhdGFjZW50ZXIgc2NlbmFy aW9zKS4NCg0KRnJvbTogU2FseiwgUmljaCBbbWFpbHRvOnJzYWx6QGFrYW1haS5jb21dDQpTZW50 OiBGcmlkYXksIEZlYnJ1YXJ5IDksIDIwMTggOTo0MiBBTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJh bWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29t Pg0KQ2M6IHF1aWNAaWV0Zi5vcmc7IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+DQpTdWJq ZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNClRoYW5rcyBmb3IgdGhlIHN1bW1h cnkuICBXaHkgZG8geW91IHdhbnQgdG8gZG8gdGhpcz8NCg0K --_000_CY4PR21MB0133427E65B3587C7577A454B6F20CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWNhdXNlIG9mIHRoZSBsaXN0 ZWQgYWR2YW50YWdlcy4gQ2xlYXIgc2VwYXJhdGlvbiBvZiBjb25jZXJucyByZXN1bHRzIGlmIHdl IGRvbuKAmXQgb3ZlcmxvYWQgdGhlIHBhY2tldCBudW1iZXIgYXMgdGhlIG5vbmNlLiBDb25uZWN0 aW9uIG1pZ3JhdGlvbiBhbmQgbXVsdGktcGF0aCBhcmUgb3B0aW9uYWwgZmVhdHVyZXMgYW5kIHdl IHBheSBubyBleHRyYSBjb21wdXRlIGNvc3QgZm9yIG1vc3QgY29ubmVjdGlvbnMNCiB0aGF0IGFy ZSBub3QgaW1wYWN0ZWQgYnkgdW5sbmthYmlsaXR5LiBOb25jZSBmaWVsZCBiZWNvbWVzIG9wdGlv bmFsIGZvciBjcnlwdG8gdGhhdCBkb2VzbuKAmXQgbmVlZCBpdCBhbmQgY2FuIGdyb3cgdG8gbGFy Z2VyIHNpemUgYXMgbmVlZGVkIGZvciBidWxrIHRyYW5zZmVycyB0byBwcmV2ZW50IGZyZXF1ZW50 IGtleSByb2xsb3ZlcnMgKHNheSBpbiBkYXRhY2VudGVyIHNjZW5hcmlvcykuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBTYWx6LCBSaWNoIFttYWlsdG86cnNhbHpAYWthbWFpLmNvbV0gPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgRmVicnVhcnkgOSwgMjAxOCA5OjQyIEFNPGJyPg0KPGI+VG86PC9iPiBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs7IEVyaWMgUmVz Y29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHF1aWNAaWV0Zi5vcmc7 IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhlIHN1bW1hcnkuJm5ic3A7IFdoeSBkbyB5b3Ugd2Fu dCB0byBkbyB0aGlzPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0133427E65B3587C7577A454B6F20CY4PR21MB0133namp_-- From nobody Fri Feb 9 11:11:56 2018 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 443D512D7E9 for ; Fri, 9 Feb 2018 11:11:55 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 1t4-bmZ4aRSV for ; Fri, 9 Feb 2018 11:11:53 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0111.outbound.protection.outlook.com [104.47.33.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE6C7126DFF for ; Fri, 9 Feb 2018 11:11:52 -0800 (PST) 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=Go6Lh3LXvhS6bBN/djdTue8Z+/81aE8XK8d5JvQ+GFQ=; b=QPTrzFKBBdz52jrOS8fvZMmme6IYNcIqksA5VJwaeYDmCq8JlAoKWVBZIpMYPd8w8NJ7Y9pCQYN6rPbxttwCA2CJuxH9DoexUvALPi9WIcQnbxnQS2lf3k7JJnjWwHazHWjG/lM3wHHb1ZSFeSRuAFDx3pQm/pxivhh3wwACyx0= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0184.namprd21.prod.outlook.com (10.173.193.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.8; Fri, 9 Feb 2018 19:11:50 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 19:11:50 +0000 From: Praveen Balasubramanian To: Ian Swett , "Salz, Rich" CC: Eric Rescorla , "quic@ietf.org" , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwIAAjJeAgAA5dnCAAAb3gIAACsEAgAANzUA= Date: Fri, 9 Feb 2018 19:11:50 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0184; 7:uycU6zm5ry89Ir2B5UG4fI1nhrafc3iazEQrdKJiEXDIQQe4hj8DnXH8Xosn8sHWMn4d52v4XqwYyQuILBy8bzJj+wnMId1hs/fMKxMM4iGxM5zrlCX8vSJi+VHvKY7PTQg3ptucncG2jgmAB8qqTv2BDSx37S4ZQLbzFvXgwgG2yDCrcsGafnZA6LKgxFmVOK9MAeEmByA9i1IC7P8DC5CLhA0EDqueMFmzSqgxD2dYySM+aMJUjQwF/Kt2W6j+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 62ce8eff-d865-4777-96ff-08d56ff0f8ff x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0184; x-ms-traffictypediagnostic: CY4PR21MB0184: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0184; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0184; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(346002)(376002)(39380400002)(189003)(199004)(51914003)(5660300001)(6436002)(236005)(10290500003)(2900100001)(6346003)(186003)(7116003)(316002)(55016002)(5250100002)(25786009)(6306002)(22452003)(19609705001)(9686003)(4326008)(54896002)(110136005)(478600001)(2906002)(53936002)(3280700002)(99286004)(7736002)(74316002)(6246003)(33656002)(53546011)(790700001)(561944003)(6116002)(54906003)(97736004)(6506007)(102836004)(93886005)(7696005)(76176011)(14454004)(106356001)(8936002)(8990500004)(2950100002)(3660700001)(86612001)(3480700004)(68736007)(86362001)(81166006)(10090500001)(8676002)(81156014)(105586002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0184; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: Oylqbychx88A7ea08du31eWD9jAeWMOkho9JRy8vC1b+IgZn+QbzX6eafy/a2U99nCs3pa4AunEibPbCLsVY0A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133649771089F9032C10215B6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 62ce8eff-d865-4777-96ff-08d56ff0f8ff X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 19:11:50.2189 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0184 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, 09 Feb 2018 19:11:55 -0000 --_000_CY4PR21MB0133649771089F9032C10215B6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdGhhdCBhbnkgcHJvcG9zZWQgc29sdXRpb24gc2hvdWxkIG5vdCBwcmVjbHVkZSBjcnlwdG8g b2ZmbG9hZC4NCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0N ClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgOSwgMjAxOCAxMDoyMSBBTQ0KVG86IFNhbHosIFJpY2gg PHJzYWx6QGFrYW1haS5jb20+DQpDYzogUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1p Y3Jvc29mdC5jb20+OyBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBxdWljQGlldGYub3Jn OyBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KU3ViamVjdDogUmU6IFBhY2tldCBudW1i ZXIgZW5jcnlwdGlvbg0KDQpPbmUgaXNzdWUgd2l0aCB0aGUgY3VycmVudCBlbmNyeXB0aW9uIHBy b3Bvc2FsIGlzIHlvdSBjYW4ndCB1c2UgaGFyZHdhcmUgY3J5cHRvIG9mZmxvYWQgZm9yIHRoZSBi dWxrIGVuY3J5cHRpb24gYmVjYXVzZSB0aGUgcGFja2V0IG51bWJlciBoYXMgdG8gYmUgZW5jcnlw dGVkIGFmdGVyIHRoZSBidWxrIGRhdGEuDQoNCkFueSBzdWdnZXN0aW9ucyBvbiBob3cgdG8gZml4 IHRoYXQ/DQoNCk9uIEZyaSwgRmViIDksIDIwMTggYXQgMTI6NDIgUE0sIFNhbHosIFJpY2ggPHJz YWx6QGFrYW1haS5jb208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3cm90ZToNClRoYW5rcyBm b3IgdGhlIHN1bW1hcnkuICBXaHkgZG8geW91IHdhbnQgdG8gZG8gdGhpcz8NCg0KDQo= --_000_CY4PR21MB0133649771089F9032C10215B6F20CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m IzQzOzEgdGhhdCBhbnkgcHJvcG9zZWQgc29sdXRpb24gc2hvdWxkIG5vdCBwcmVjbHVkZSBjcnlw dG8gb2ZmbG9hZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IElhbiBTd2V0 dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IEZlYnJ1YXJ5IDksIDIwMTggMTA6MjEgQU08YnI+DQo8Yj5Ubzo8L2I+IFNhbHosIFJpY2ggJmx0 O3JzYWx6QGFrYW1haS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1h bmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs7IEVyaWMgUmVzY29ybGEgJmx0O2VrckBy dGZtLmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc7IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5u ZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBpc3N1ZSB3aXRoIHRoZSBjdXJyZW50 IGVuY3J5cHRpb24gcHJvcG9zYWwgaXMgeW91IGNhbid0IHVzZSBoYXJkd2FyZSBjcnlwdG8gb2Zm bG9hZCBmb3IgdGhlIGJ1bGsgZW5jcnlwdGlvbiBiZWNhdXNlIHRoZSBwYWNrZXQgbnVtYmVyIGhh cyB0byBiZSBlbmNyeXB0ZWQgYWZ0ZXIgdGhlIGJ1bGsgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFueSBzdWdnZXN0aW9ucyBvbiBob3cgdG8gZml4 IHRoYXQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEZyaSwgRmViIDksIDIwMTggYXQgMTI6NDIgUE0sIFNhbHosIFJpY2ggJmx0OzxhIGhy ZWY9Im1haWx0bzpyc2FsekBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+cnNhbHpAYWthbWFp LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGFua3MgZm9yIHRoZSBzdW1tYXJ5LiZuYnNw OyBXaHkgZG8geW91IHdhbnQgdG8gZG8gdGhpcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0133649771089F9032C10215B6F20CY4PR21MB0133namp_-- From nobody Fri Feb 9 11:39:17 2018 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 A466A1242F7 for ; Fri, 9 Feb 2018 11:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 9dOAFFaqvpTi for ; Fri, 9 Feb 2018 11:39:11 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::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 29A4D1270AE for ; Fri, 9 Feb 2018 11:39:11 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id x27so11934028qtm.12 for ; Fri, 09 Feb 2018 11:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xUdLkkgq45AyDwcFNJF46uMzBSW5slPkrfsBqVCJMc4=; b=hJhTbdoXv9pdByG0zg7uanmRlpSsnfaMGZ0WsWSziiRPGMWKqb3Ou7QyXZQ5Ohb8Jr YTp1vkpttWKuhe7bYem69Nf/BglkCLXvr2piTr8wB8Oj9ugoCPoP+2U+yHBqfY3GubmS xH59CVJJ+Y0KCX/fCJpHa7fJGmVYOWv4sjztA= 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=xUdLkkgq45AyDwcFNJF46uMzBSW5slPkrfsBqVCJMc4=; b=sfbqnbUIOV/TeyoSosbHxN5U1vxY1wlT+7EE/SuOxJT0cclhNAyUFqFmDAF32hB5C3 7MCE0pMQE4fYe2Z1gI86IJmSDZic0t18curaRpRKePGiohbuVhLNK1CL2vFvlIgK+d+B 5/oG4X9yuhr4MomgqHClCVLgBFL/CBlV5GebtzWhLC7nJg1TpoBQp+pvzsuU2u5N+9ti uUV+cL0Ny8NUa9EK9mpIM9+wVnUVd8ZX1kG399Xhri7nnYsDmyD99zuEVyKrRCyn9lCZ R3obOISkDevSdialQNe503PswqLTH9WvRLPs+JqSv0TFWyh2uqb4crmas4I2B8F2mlMg 55pg== X-Gm-Message-State: APf1xPAPpxGelvYxpdQTzVnehURVlbkkJlJhh82Jq3T4i8//mL8K2rLw sIV13ZKPeXm5qEVzttMh8kofYvAqfn4s+8Ruv+GyMj8= X-Google-Smtp-Source: AH8x226r7G4QhHMc1Vr8MurxitVt7wPHTey1m918/RbsRvwsppzMwTNjcowKR2pvx/4tOz+5UrWucKPWf9bU2cMtkL4= X-Received: by 10.200.68.80 with SMTP id m16mr6149094qtn.294.1518205149943; Fri, 09 Feb 2018 11:39:09 -0800 (PST) MIME-Version: 1.0 References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: From: David Benjamin Date: Fri, 09 Feb 2018 19:38:57 +0000 Message-ID: Subject: Re: Packet number encryption To: Praveen Balasubramanian Cc: Eric Rescorla , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="f4f5e80afa48a91dc30564ccae95" 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, 09 Feb 2018 19:39:16 -0000 --f4f5e80afa48a91dc30564ccae95 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Your primary worry here was the extra block cipher operation, right? By moving the packet number into the plaintext, this proposal increases the length, which will cost that same one extra block cipher operation, no? It is one block operation under the same key, rather than a different key so I suppose there are minuscule cache footprint wins (one symmetric key is 16 or 32 bytes). But the cost is per-packet (!) bandwidth and complexity. I do not see how this could be worth it. Note that, for AES, many CPUs have dedicated instructions for it already. > Clear separation of concerns results if we don=E2=80=99t overload the pac= ket number as the nonce. Connection migration and multi-path are optional features and we pay no extra compute cost for most connections that are not impacted by unlnkability. Nonce field becomes optional for crypto that doesn=E2=80=99t need it and can grow to larger size as needed for bulk tran= sfers to prevent frequent key rollovers (say in datacenter scenarios). You're not going to find AEADs that don't require a nonce. Encryption must not produce the same ciphertext twice for the same plaintext, so you need some input to diversify them. That input is the nonce. Nonces also are not variable-length, so you don't get to arbitrarily grow them. (AES-GCM per spec is variable length, but that's a spec bug. If you size it above 96 bits, it's as if you randomized it and your nonce space crashes per birthday.) It is also harmful to separate the two concerns. When you are building a transport, derive the nonce from a sequence number. TLS 1.2 AES-GCM separated them, which was a mistake. It's less efficient (the world wasted quite a lot of bandwidth due to this), and more error-prone. There was nothing stopping implementations from sending the same nonce or generating nonces randomly (the AEADs we use don't have large enough nonces for that), and indeed some did just that. If you use some sort of sequence number, you can lean on existing work both to filter out the obvious implementation mistakes and to avoid sending unnecessary data. On Fri, Feb 9, 2018 at 12:38 PM Praveen Balasubramanian wrote: > Let me try to summarize the proposal again: > > > > 1. Packet number is in the encrypted portion of the header and is no > longer used as the nonce. It is encoded as a variable length number. A= lways > starts at 0. > 1. No ossification of PN > 2. No linkability using PN > 3. Allows for growth beyond 64 bits if needed in future > 2. The nonce is in the clear in plaintext header. It is generated *per > path* as a secure random number. Call this the =E2=80=9Cstarting value= =E2=80=9D. Both > sides MUST initialize the =E2=80=9Cstarting value=E2=80=9D nonce *per = path*. Within a > path it grows monotonically (to avoid repeats just like PN today) and = can > include short random jumps periodically so that middleboxes cannot ass= ume > anything about the field. Since nonce has nothing to do with PN the ju= mps > don=E2=80=99t add any complexity to transport logic. Jumps are for gre= asing and > preventing ossification. When the nonce rolls over and reaches close t= o the > =E2=80=9Cstarting value=E2=80=9D, key rollover must happen. At high da= ta rates the nonce > field can be 64-bits to prevent frequent key rollover. For crypto that > doesn=E2=80=99t need nonces, the field can be omitted. > 1. No ossification because there is no pre-determined sequence to > the nonce. > 2. In gQUIC and the RFC as defined the nonce is a simple sequence > that increments by one, so this is no worse off in terms of securit= y. It is > non-repeating. > 3. No linkability because different paths start at a completely > different random number. If repeating is a concern then different p= aths use > different keys. Carries forward to not just connection migration bu= t > mutli-path. > 4. Supports key rollover just like gQUIC and currently defined > draft RFC. > 5. Allows for omitting the nonce when we use crypto that doesn=E2= =80=99t > need it. > 6. Allows for larger nonces for high data rates. > 7. It doesn=E2=80=99t preclude any other type of non-repeating nonc= es > without having to modify the RFC! So implementations that want to u= se > cryptographic nonces can still do so. > > > > The downsides: > > 1. Even with variable length encoding the extra PN field is more space > used per packet when a nonce is required. I think we can do with 2 byt= es in > version 1. > 2. It=E2=80=99s not perfect unlinkabiltiy but I have yet to see any so= lution > that can provide this. A simple time based analysis using machine lear= ning > will allow flow correlation especially for connection migration. The I= P > addresses in the clear allow for a high degree of correlation. There i= s > also the application sending pattern and other signals that could be u= sed. > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Friday, February 9, 2018 5:52 AM > *To:* Praveen Balasubramanian > *Cc:* huitema ; quic@ietf.org > > > *Subject:* Re: Packet number encryption > > > > > > > > On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > Actually taking a step back what if we don=E2=80=99t we overloaded packet= number > as the nonce? > > > > Can we: > > 1. Put packet number as a separate variable length field in the > encrypted portion of the header. This allows for growth beyond 64 bits= in > future and completely avoids ossification. For short lived flows varia= ble > length encoding leads to minimal space overhead. > 2. Put a separate plaintext nonce which starts out as a secure random > number and monotonically increases as short random jumps (every packet= or > every few packets) and could then rollover. This will prevent linkabil= ity > and scales to multi-path as well. No major compute overhead. We can al= so > make the nonce optional for crypto algorithms that do not need a nonce > saving more space. > > > > I'm not sure how to do #2 safely and efficiently. The primary concern is > that short random jumps don't actually prevent linkability because the hi= gh > order bits don't change and long random jumps are effectively randomly > sampling out of the nonce space, and you start to run into birthday > problems. Additionally, the cheapest PRNGs are basically ciphers in count= er > mode, so at best you're going to get a small amount of overhead reduction > by getting multiple jump computations out of a single block, though if yo= u > use 96-bit jumps, you only get 25% savings... > > > > -Ekr > > > > > > > > Some MSB of the nonce could be used for signaling reorder to the network > if needed. I don=E2=80=99t have the historical context for overloading of= PN as the > nonce so pardon me if un-overloading option was discussed and ruled out > before. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen > Balasubramanian > *Sent:* Thursday, February 8, 2018 5:51 PM > *To:* huitema ; quic@ietf.org > *Subject:* RE: Packet number encryption > > > > >> and using separate packet sequences for each path > > This alone prevents linkability right? > > > > >> The packet number on each path will start at 1 (or maybe 0 ;-). > > Is supporting multiple paths at the same time a goal? If yes, then yes al= l > paths will need to have separate tracking and ACK state and congestion > control etc. I thought this is not part of V1 RFC. If its just one > additional path for connection migration scenario then all you need is a > (random) jump to a offset in packet number space for the new path so that > the few packets in the old path can continue for a little bit. This works > with just one ACK space so no implementation complexity. > > > > >> 2) Or, leaving the packet number in the clear but using different > encryption contexts for each path, and using separate packet sequences fo= r > each path. > In addition if the value in the clear was obfuscated with an XOR transfor= m > it will help prevent ossification. The obfuscation is not meant to guard > against later analysis that reveals the packet numbers - why do we care > about that. It is meant to grease the space and not make the numbers seri= al > so middleboxes cannot assume ordering etc. > > > > All said if I am alone in being concerned about the perf hit then I=E2=80= =99d say > go on with option 1. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Christian Huitema > *Sent:* Thursday, February 8, 2018 3:54 PM > *To:* quic@ietf.org > *Subject:* Re: Packet number encryption > > > > On 2/8/2018 1:13 PM, Mike Bishop wrote: > > #2 won=E2=80=99t work. The packet number is an input to the AEAD nonce, = so you > have to get to the packet number before you can decrypt the payload. It > can=E2=80=99t be based on anything internal to the encrypted packet. > > > > In Martin=E2=80=99s proposal, it=E2=80=99s using a combination of the enc= rypted payload > (which requires nothing to access) and some stored state on each endpoint= , > which requires only the Connection ID to look up. You want the thing you > XOR by to be constantly changing, or it becomes easier to look at sequenc= es > of obfuscated packet numbers and start drawing inferences about what the > XOR value is. If overhead is the primary concern, I think there are a > couple approaches that might allow you to precompute values and amortize > the cost of doing the encryption step. (At the cost of keeping the table > of precomputed values, of course.) > > > > I still think Jana=E2=80=99s pushing in the right direction here: Let=E2= =80=99s agree on > goals, and then see if we can craft a design that meets those goals. I > hear you saying that low overhead is a goal, which I think we can all agr= ee > on. I also think I hear you saying that 1-1.5% overhead is too high, but > it sounds like there=E2=80=99s less agreement on that. You also raise an > interesting point that some clients will care less about linkability > because they will never intentionally migrate. > > > I think Victor said it best, "Obfuscation is just encryption done poorly.= " > Either we encrypt, or we don't. But there is no such thing as an > obfuscation middle-ground. Obfuscation would just be a speed bump, easily > broken. It won't provide privacy, and it won't prevent linkability. > > As far as I am concerned, there are only two designs that prevent > linkability: > > 1) Martin's PR, in which the packet number is encrypted using sensible > crypto; > > 2) Or, leaving the packet number in the clear but using different > encryption contexts for each path, and using separate packet sequences fo= r > each path. > > The second option requires more computation when explicitly setting up a > new path. The connection ID would be used as part of the "salt" when > deriving connection contexts. The packet number on each path will start a= t > 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for > each path/Connection-ID, and constraining ACK to be per/path, or > alternatively adding a PATH-ACK frame that indicates the path for which > packets are acked. > > The pros and cons of the two options are easy to get: > > 1) Option 2 does not require the cost of encrypting every packet, thus pe= r > packet processing will be maybe 1% faster than option 1. > > 2) Option 2 requires computing encryption contexts for each path, which i= s > more complex than option 1, but the cost will be amortized over the > duration of the path. > > 3) Option 2 requires more complex data structures and ACK management, thu= s > increasing the chances that something goes wrong. > > 4) Option 2 does nothing against packet number ossification. The packet > number effectively becomes part of the invariants. > > In short, the only advantage of option 2 is to avoid a single symmetric > encryption operation per packet, while making the code significantly more > complex, and at the cost of not protecting against PN ossification. The w= ay > I see that, there is hardly any debate. > > -- Christian Huitema > > > --f4f5e80afa48a91dc30564ccae95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Your primary worry here was the extra block cipher operati= on, right? By moving the packet number into the plaintext, this proposal in= creases the length, which will cost that same one extra block cipher operat= ion, no?

It is one block operation under the same k= ey, rather than a different key so I suppose there are minuscule=C2=A0cache= footprint wins (one symmetric key is 16 or 32 bytes). But the cost is per-= packet (!) bandwidth and complexity. I do not see how this could be worth i= t.=C2=A0Note that, for AES, many CPUs have dedicated instructions for it al= ready.

>=C2=A0C= lear separation of concerns results if we don=E2=80=99t overload the packet= number as the nonce. Connection migration and multi-path are optional feat= ures and we pay no extra compute cost for most connections that are not imp= acted by unlnkability. Nonce field becomes optional for crypto that doesn= =E2=80=99t need it and can grow to larger size as needed for bulk transfers= to prevent frequent key rollovers (say in datacenter scenarios).

You're not going to find A= EADs that don't require a nonce. Encryption must not produce the same c= iphertext twice for the same plaintext, so you need some input to diversify= them. That input is the nonce. Nonces also are not variable-length, so you= don't get to arbitrarily grow them. (AES-GCM per spec is variable leng= th, but that's a spec bug. If you size it above 96 bits, it's as if= you randomized it and your nonce space crashes per birthday.)
It is also harmful to separate the two concerns.=C2=A0When you= are building a transport, derive the nonce from a sequence number. TLS 1.2= AES-GCM separated them, which was a mistake. It's less efficient (the = world wasted quite a lot of bandwidth due to this), and more error-prone. T= here was nothing stopping implementations from sending the same nonce or ge= nerating nonces randomly (the AEADs we use don't have large enough nonc= es for that), and indeed some did just that. If you use some sort of sequen= ce number, you can lean on existing work both to filter out the obvious imp= lementation mistakes and to avoid sending unnecessary data.

On Fri, Feb 9, 2018 at 12:38 PM Praveen B= alasubramanian <pravb@microsoft.com> wrote:

Let me try to summarize the proposal again:

=C2=A0

  1. Packet number is in the encrypted portion of the he= ader and is no longer used as the nonce. It is encoded as a variable length= number. Always starts at 0.
    1. No ossification of PN
    2. No linkability using PN
    3. Allows for growth beyond 64 bits if needed in future
  2. The nonce is in the clear in plaintext header.= It is generated per path as a secure random number. Call this the =E2=80=9Cstarting = value=E2=80=9D. Both sides MUST initialize the =E2=80=9Cstarting value=E2= =80=9D nonce per path. Within a path it grows monotonically (to avoid repeats jus= t like PN today) and can include short random jumps periodically so that mi= ddleboxes cannot assume anything about the field. Since nonce has nothing t= o do with PN the jumps don=E2=80=99t add any complexity to transport logic. Jumps are for greasing and preventing o= ssification. When the nonce rolls over and reaches close to the =E2=80=9Cst= arting value=E2=80=9D, key rollover must happen. At high data rates the non= ce field can be 64-bits to prevent frequent key rollover. For crypto that doesn=E2=80=99t need nonces, the field can be om= itted.
    1. No ossification because there is no pre-determined = sequence to the nonce.
    2. In gQUIC a= nd the RFC as defined the nonce is a simple sequence that increments by one= , so this is no worse off in terms of security. It is non-repeating.=
    3. No linkability because different paths = start at a completely different random number. If repeating is a concern th= en different paths use different keys. Carries forward to not just connecti= on migration but mutli-path.
    4. Supports key rollov= er just like gQUIC and currently defined draft RFC.
    5. Allows for omitting the nonce when we use crypto that do= esn=E2=80=99t need it.
    6. Allows for= larger nonces for high data rates.
    7. It doesn=E2=80=99t preclude any = other type of non-repeating nonces without having to modify the RFC! So imp= lementations that want to use cryptographic nonces can still do so.

=C2=A0

The downsides:

  1. Even with variable length encoding the extra PN fie= ld is more space used per packet when a nonce is required. I think we can d= o with 2 bytes in version 1.
  2. It= =E2=80=99s not perfect unlinkabiltiy but I have yet to see any solution tha= t can provide this. A simple time based analysis using machine learning wil= l allow flow correlation especially for connection migration. The IP addresses in the clear allow for a high degree of correlation. Ther= e is also the application sending pattern and other signals that could be u= sed.

=C2=A0

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Friday, February 9, 2018 5:52 AM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: huitema <huitema@huitema.net>; quic@ietf.org


Subject: Re: Packet number encryption

<= div lang=3D"EN-US" link=3D"blue" vlink=3D"purple">

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubraman= ian <pravb@micr= osoft.com> wrote:

Actually taking a step back what if we don=E2=80=99t= we overloaded packet number as the nonce?

=C2=A0

Can we:

  1. Put packet number as a separate variable length field in the encrypted port= ion of the header. This allows for growth beyond 64 bits in future and comp= letely avoids ossification. For short lived flows variable length encoding = leads to minimal space overhead.
  2. Put a separate plaintext nonce which starts out as a secure random number a= nd monotonically increases as short random jumps (every packet or every few= packets) and could then rollover. This will prevent linkability and scales= to multi-path as well. No major compute overhead. We can also make the nonce optional for crypto algorithm= s that do not need a nonce saving more space.

=C2=A0

I'm not sure how to do #2 safely and efficiently= . The primary concern is that short random jumps don't actually prevent= linkability because the high order bits don't change and long random j= umps are effectively randomly sampling out of the nonce space, and you start to run into birthday problems. Additionally= , the cheapest PRNGs are basically ciphers in counter mode, so at best you&= #39;re going to get a small amount of overhead reduction by getting multipl= e jump computations out of a single block, though if you use 96-bit jumps, you only get 25% savings...<= u>

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

Some MSB of the nonce could be used for signaling re= order to the network if needed. I don=E2=80=99t have the historical context= for overloading of PN as the nonce so pardon me if un-overloading option was discussed and ruled out before.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Thursday, February 8, 2018 5:51 PM
To: huitema <huitema@huitema.net>; quic@ietf.org
Subject: RE: Packet number encryption

=C2=A0

>> and using separate packet sequences for eac= h path

This alone prevents linkability right?=

=C2=A0

>> The packet number on each path will start a= t 1 (or maybe 0 ;-).

Is supporting multiple paths at the same time a goal= ? If yes, then yes all paths will need to have separate tracking and ACK st= ate and congestion control etc. I thought this is not part of V1 RFC. If its just one additional path for connection migrati= on scenario then all you need is a (random) jump to a offset in packet numb= er space for the new path so that the few packets in the old path can conti= nue for a little bit. This works with just one ACK space so no implementation complexity.

=C2=A0

>> 2) Or, leaving the packet number in the cle= ar but using different encryption contexts for each path, and using separat= e packet sequences for each path.
In addition if the value in the clear was obfuscated with an XOR transform = it will help prevent ossification. The obfuscation is not meant to guard ag= ainst later analysis that reveals the packet numbers - why do we care about= that. It is meant to grease the space and not make the numbers serial so middleboxes cannot assume orderin= g etc.

=C2=A0

All said if I am alone in being concerned about the = perf hit then I=E2=80=99d say go on with option 1.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Thursday, February 8, 2018 3:54 PM
To: quic@ietf.org=
Subject: Re: Packet number encryption

=C2=A0

On 2/8/2018 1:13 PM, Mike Bishop wrote:

#2 won=E2=80=99t work.=C2=A0 The packet number is an= input to the AEAD nonce, so you have to get to the packet number before yo= u can decrypt the payload.=C2=A0 It can=E2=80=99t be based on anything inte= rnal to the encrypted packet.

=C2=A0

In Martin=E2=80=99s proposal, it=E2=80=99s using a c= ombination of the encrypted payload (which requires nothing to access) and = some stored state on each endpoint, which requires only the Connection ID to look up.=C2=A0 You want the thing you XOR by to be constantly changi= ng, or it becomes easier to look at sequences of obfuscated packet numbers = and start drawing inferences about what the XOR value is.=C2=A0 If overhead= is the primary concern, I think there are a couple approaches that might allow you to precompute values and amortize= the cost of doing the encryption step.=C2=A0 (At the cost of keeping the t= able of precomputed values, of course.)

=C2=A0

I still think Jana=E2=80=99s pushing in the right di= rection here:=C2=A0 Let=E2=80=99s agree on goals, and then see if we can cr= aft a design that meets those goals.=C2=A0 I hear you saying that low overh= ead is a goal, which I think we can all agree on.=C2=A0 I also think I hear yo= u saying that 1-1.5% overhead is too high, but it sounds like there=E2=80= =99s less agreement on that.=C2=A0 You also raise an interesting point that= some clients will care less about linkability because they will never intentionally migrate.


I think Victor said it best, "Obfuscation is just encryption done poor= ly." Either we encrypt, or we don't. But there is no such thing as= an obfuscation middle-ground. Obfuscation would just be a speed bump, easi= ly broken. It won't provide privacy, and it won't prevent linkability.

As far as I am concerned, there are only two designs that prevent linkabili= ty:

1) Martin's PR, in which the packet number is encrypted using sensible = crypto;

2) Or, leaving the packet number in the clear but using different encryptio= n contexts for each path, and using separate packet sequences for each path= .

The second option requires more computation when explicitly setting up a ne= w path. The connection ID would be used as part of the "salt" whe= n deriving connection contexts. The packet number on each path will start a= t 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK= to be per/path, or alternatively adding a PATH-ACK frame that indicates th= e path for which packets are acked.

The pros and cons of the two options are easy to get:

1) Option 2 does not require the cost of encrypting every packet, thus per = packet processing will be maybe 1% faster than option 1.

2) Option 2 requires computing encryption contexts for each path, which is = more complex than option 1, but the cost will be amortized over the duratio= n of the path.

3) Option 2 requires more complex data structures and ACK management, thus = increasing the chances that something goes wrong.

4) Option 2 does nothing against packet number ossification. The packet num= ber effectively becomes part of the invariants.

In short, the only advantage of option 2 is to avoid a single symmetric enc= ryption operation per packet, while making the code significantly more comp= lex, and at the cost of not protecting against PN ossification. The way I s= ee that, there is hardly any debate.

-- Christian Huitema

=C2=A0

--f4f5e80afa48a91dc30564ccae95-- From nobody Fri Feb 9 11:58:45 2018 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 01DC8126DFF for ; Fri, 9 Feb 2018 11:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-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 (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 OzxJTCgzDbem for ; Fri, 9 Feb 2018 11:58:40 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0139.outbound.protection.outlook.com [104.47.32.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735CB1242F7 for ; Fri, 9 Feb 2018 11:58:40 -0800 (PST) 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=ubdA7XxVOGDrbDGSbqpNFHQQFV/02BX+baznfRZqGjw=; b=LDgFwjaVj2BzZ4HELwbTCjg1FGmiJCeDF6/sTV4PA4xBc4dGPFFAYcK77d86cVUSlCWvtnczSxAskd6ua3IB/DdzkByzknWY4lym1HJJO/2i+HyQ9UGmpFxlh24zTGm+UesIqFrvb774g4/rsYkmy082UXIIksxsyxMdUbiKzI4= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0504.namprd21.prod.outlook.com (10.172.122.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Fri, 9 Feb 2018 19:58:38 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 19:58:38 +0000 From: Praveen Balasubramanian To: David Benjamin CC: Eric Rescorla , "quic@ietf.org" , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwIAAjJeAgAA5dnCAACeJgIAAApzg Date: Fri, 9 Feb 2018 19:58:38 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0504; 7:t1+5Xux6x6DMqDvYt4a9ld6kMt33X8zJcFt18kXwwzPksyFDruhilhOvRGCqjr9So/NJ2R1f2bQsxtQ2GqVyvKJHWFa/25lS7tx0tF9nKBvPwgZQObzf5CPejhkFFGLduJDWfJOF765Zu6f2sjDWIqV7meWX2Jg/a+p47q3Xh/sLVW6qJ4QvoWGRtMk/3h9hbp/n1yYGA9TlHAjWJt/QdJWFbBHiyP21JUATksOJV/xf/PYm4mi6Ucn0KSsClQs7 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1514f5cf-906f-4f36-7098-08d56ff782b8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0504; x-ms-traffictypediagnostic: CY4PR21MB0504: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0504; BCL:0; PCL:0; RULEID:(3232008); SRVR:CY4PR21MB0504; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(366004)(396003)(376002)(39380400002)(199004)(189003)(377424004)(97736004)(25786009)(3280700002)(3480700004)(2906002)(6346003)(102836004)(68736007)(19609705001)(186003)(4326008)(53546011)(6506007)(59450400001)(76176011)(8936002)(10090500001)(99286004)(8990500004)(7696005)(3660700001)(105586002)(5250100002)(5660300001)(86362001)(81156014)(81166006)(7116003)(14454004)(7736002)(74316002)(6246003)(93886005)(9686003)(54896002)(236005)(6306002)(53936002)(8676002)(86612001)(54906003)(6916009)(6116002)(790700001)(2950100002)(2900100001)(55016002)(6436002)(561944003)(316002)(10290500003)(229853002)(22452003)(478600001)(33656002)(106356001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0504; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: flsOv15o1ryNI86M2xRVsO+Tl7xVUdhu7DwLmfSq/lYTs0XhTO2SUsKAI7KDM7yBbbeZJim2GBKY7goPCJf/2w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133A4FC7160DA1FABAA291BB6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1514f5cf-906f-4f36-7098-08d56ff782b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 19:58:38.2742 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0504 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, 09 Feb 2018 19:58:44 -0000 --_000_CY4PR21MB0133A4FC7160DA1FABAA291BB6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2l0aCBWTEUgaXRzIG1pbmltYWwgb3ZlcmhlYWQgcGVyIHBhY2tldCBzbyB5b3UgYXJlIG5vdCBl bmNyeXB0aW5nIDQgYnl0ZXMgbW9yZSBhbGwgdGhlIHRpbWUgZXZlbiB3aXRoIDY0IGJpdCBvciAx MjggYml0IHBhY2tldCBudW1iZXIgLiBTbyBpdHMgZGVjaWRlZGx5IGJldHRlci4gQWxzbyBmZXdl ciBjYWxscyBpbnRvIFRMUywgYnV0IEkgc3VwcG9zZSBvbmUgY291bGQgZG8gc29tZSByZWZhY3Rv cmluZyBvZiBUTFMgQVBJLiBNYW55IENQVXMgeWVzIGJ1dCB0aGlzIGlzIGEgZ2VuZXJhbCBwdXJw b3NlIHRyYW5zcG9ydCBhbmQgY291bGQgcnVuIG9uIENQVXMgdGhhdCBkb27igJl0Lg0KDQpEaWRu 4oCZdCBhc2sgZm9yIG5vbmNlIHRvIGJlIHZhcmlhYmxlIGxlbmd0aC4gRml4ZWQgbGVuZ3RoIGZv ciBjb25uZWN0aW9uIGxpZmV0aW1lLiBEYXRhY2VudGVycyBjb25uZWN0aW9ucyBjb3VsZCB1c2Ug NjQtYml0IG5vbmNlIHRvIGF2b2lkIGZyZXF1ZW50IGtleSByb2xsb3Zlci4NCg0KRWZmZWN0aXZl bHkgdGhlIHBsYWluIHRleHQgbm9uY2UgaXMgYSBzZXF1ZW5jZSBudW1iZXIgc2luY2UgaXQgaW5j cmVhc2VzIG1vbm90b25pY2FsbHkgd2l0aCBzbWFsbCBqdW1wcyBhcyBuZWVkZWQgdG8gYXZvaWQg b3NzaWZpY2F0aW9uLiBTbyBubyB3b3JzZSBvZmYgdGhhbiBnUVVJQyBvciBjdXJyZW50IGRyYWZ0 LiBObyBtb3JlIGNvbXBsZXggdGhhbiB1c2luZyB0aGUgcGFja2V0IG51bWJlci4gSnVzdCB0aGUg c3RhcnRpbmcgbnVtYmVyIGlzIHJhbmRvbWl6ZWQuIEFsc28gcGxlYXNlIG5vdGljZSB0aGF0IHRo aXMgcHJvcG9zYWwgZG9lcyBub3QgcHJlY2x1ZGUgdXNpbmcgZW5jcnlwdGVkIHBhY2tldCBudW1i ZXIgYXMgdGhlIG5vbmNlIGFzIHByb3Bvc2VkIHByZXZpb3VzbHkuIENoYW5naW5nIGhvdyB0aGUg bm9uY2Ugd29ya3MgbWFrZXMgMCBpbXBhY3Qgb24gdGhlIHRyYW5zcG9ydCBsb2dpYy4gQW4gaW1w bGVtZW50YXRpb24gY2FuIGNob29zZSB0byBpbXBsZW1lbnQgYW55IGZvcm0gb2Ygbm9uLXJlcGVh dGluZyBub25jZSB3aXRob3V0IHJldnZpbmcgdGhlIFJGQy4gVGhpcyBpcyB0aGUgYmlnZ2VzdCBh ZHZhbnRhZ2Ugb2Ygc2VwYXJhdGlvbiBvZiBjb25jZXJucyBJTUhPLg0KDQpGcm9tOiBEYXZpZCBC ZW5qYW1pbiBbbWFpbHRvOmRhdmlkYmVuQGNocm9taXVtLm9yZ10NClNlbnQ6IEZyaWRheSwgRmVi cnVhcnkgOSwgMjAxOCAxMTozOSBBTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2 YkBtaWNyb3NvZnQuY29tPg0KQ2M6IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT47IHF1aWNA aWV0Zi5vcmc7IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+DQpTdWJqZWN0OiBSZTogUGFj a2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCllvdXIgcHJpbWFyeSB3b3JyeSBoZXJlIHdhcyB0aGUg ZXh0cmEgYmxvY2sgY2lwaGVyIG9wZXJhdGlvbiwgcmlnaHQ/IEJ5IG1vdmluZyB0aGUgcGFja2V0 IG51bWJlciBpbnRvIHRoZSBwbGFpbnRleHQsIHRoaXMgcHJvcG9zYWwgaW5jcmVhc2VzIHRoZSBs ZW5ndGgsIHdoaWNoIHdpbGwgY29zdCB0aGF0IHNhbWUgb25lIGV4dHJhIGJsb2NrIGNpcGhlciBv cGVyYXRpb24sIG5vPw0KDQpJdCBpcyBvbmUgYmxvY2sgb3BlcmF0aW9uIHVuZGVyIHRoZSBzYW1l IGtleSwgcmF0aGVyIHRoYW4gYSBkaWZmZXJlbnQga2V5IHNvIEkgc3VwcG9zZSB0aGVyZSBhcmUg bWludXNjdWxlIGNhY2hlIGZvb3RwcmludCB3aW5zIChvbmUgc3ltbWV0cmljIGtleSBpcyAxNiBv ciAzMiBieXRlcykuIEJ1dCB0aGUgY29zdCBpcyBwZXItcGFja2V0ICghKSBiYW5kd2lkdGggYW5k IGNvbXBsZXhpdHkuIEkgZG8gbm90IHNlZSBob3cgdGhpcyBjb3VsZCBiZSB3b3J0aCBpdC4gTm90 ZSB0aGF0LCBmb3IgQUVTLCBtYW55IENQVXMgaGF2ZSBkZWRpY2F0ZWQgaW5zdHJ1Y3Rpb25zIGZv ciBpdCBhbHJlYWR5Lg0KDQo+IENsZWFyIHNlcGFyYXRpb24gb2YgY29uY2VybnMgcmVzdWx0cyBp ZiB3ZSBkb27igJl0IG92ZXJsb2FkIHRoZSBwYWNrZXQgbnVtYmVyIGFzIHRoZSBub25jZS4gQ29u bmVjdGlvbiBtaWdyYXRpb24gYW5kIG11bHRpLXBhdGggYXJlIG9wdGlvbmFsIGZlYXR1cmVzIGFu ZCB3ZSBwYXkgbm8gZXh0cmEgY29tcHV0ZSBjb3N0IGZvciBtb3N0IGNvbm5lY3Rpb25zIHRoYXQg YXJlIG5vdCBpbXBhY3RlZCBieSB1bmxua2FiaWxpdHkuIE5vbmNlIGZpZWxkIGJlY29tZXMgb3B0 aW9uYWwgZm9yIGNyeXB0byB0aGF0IGRvZXNu4oCZdCBuZWVkIGl0IGFuZCBjYW4gZ3JvdyB0byBs YXJnZXIgc2l6ZSBhcyBuZWVkZWQgZm9yIGJ1bGsgdHJhbnNmZXJzIHRvIHByZXZlbnQgZnJlcXVl bnQga2V5IHJvbGxvdmVycyAoc2F5IGluIGRhdGFjZW50ZXIgc2NlbmFyaW9zKS4NCg0KWW91J3Jl IG5vdCBnb2luZyB0byBmaW5kIEFFQURzIHRoYXQgZG9uJ3QgcmVxdWlyZSBhIG5vbmNlLiBFbmNy eXB0aW9uIG11c3Qgbm90IHByb2R1Y2UgdGhlIHNhbWUgY2lwaGVydGV4dCB0d2ljZSBmb3IgdGhl IHNhbWUgcGxhaW50ZXh0LCBzbyB5b3UgbmVlZCBzb21lIGlucHV0IHRvIGRpdmVyc2lmeSB0aGVt LiBUaGF0IGlucHV0IGlzIHRoZSBub25jZS4gTm9uY2VzIGFsc28gYXJlIG5vdCB2YXJpYWJsZS1s ZW5ndGgsIHNvIHlvdSBkb24ndCBnZXQgdG8gYXJiaXRyYXJpbHkgZ3JvdyB0aGVtLiAoQUVTLUdD TSBwZXIgc3BlYyBpcyB2YXJpYWJsZSBsZW5ndGgsIGJ1dCB0aGF0J3MgYSBzcGVjIGJ1Zy4gSWYg eW91IHNpemUgaXQgYWJvdmUgOTYgYml0cywgaXQncyBhcyBpZiB5b3UgcmFuZG9taXplZCBpdCBh bmQgeW91ciBub25jZSBzcGFjZSBjcmFzaGVzIHBlciBiaXJ0aGRheS4pDQoNCkl0IGlzIGFsc28g aGFybWZ1bCB0byBzZXBhcmF0ZSB0aGUgdHdvIGNvbmNlcm5zLiBXaGVuIHlvdSBhcmUgYnVpbGRp bmcgYSB0cmFuc3BvcnQsIGRlcml2ZSB0aGUgbm9uY2UgZnJvbSBhIHNlcXVlbmNlIG51bWJlci4g VExTIDEuMiBBRVMtR0NNIHNlcGFyYXRlZCB0aGVtLCB3aGljaCB3YXMgYSBtaXN0YWtlLiBJdCdz IGxlc3MgZWZmaWNpZW50ICh0aGUgd29ybGQgd2FzdGVkIHF1aXRlIGEgbG90IG9mIGJhbmR3aWR0 aCBkdWUgdG8gdGhpcyksIGFuZCBtb3JlIGVycm9yLXByb25lLiBUaGVyZSB3YXMgbm90aGluZyBz dG9wcGluZyBpbXBsZW1lbnRhdGlvbnMgZnJvbSBzZW5kaW5nIHRoZSBzYW1lIG5vbmNlIG9yIGdl bmVyYXRpbmcgbm9uY2VzIHJhbmRvbWx5ICh0aGUgQUVBRHMgd2UgdXNlIGRvbid0IGhhdmUgbGFy Z2UgZW5vdWdoIG5vbmNlcyBmb3IgdGhhdCksIGFuZCBpbmRlZWQgc29tZSBkaWQganVzdCB0aGF0 LiBJZiB5b3UgdXNlIHNvbWUgc29ydCBvZiBzZXF1ZW5jZSBudW1iZXIsIHlvdSBjYW4gbGVhbiBv biBleGlzdGluZyB3b3JrIGJvdGggdG8gZmlsdGVyIG91dCB0aGUgb2J2aW91cyBpbXBsZW1lbnRh dGlvbiBtaXN0YWtlcyBhbmQgdG8gYXZvaWQgc2VuZGluZyB1bm5lY2Vzc2FyeSBkYXRhLg0KDQpP biBGcmksIEZlYiA5LCAyMDE4IGF0IDEyOjM4IFBNIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxw cmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpM ZXQgbWUgdHJ5IHRvIHN1bW1hcml6ZSB0aGUgcHJvcG9zYWwgYWdhaW46DQoNCg0KICAxLiAgUGFj a2V0IG51bWJlciBpcyBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhlYWRlciBhbmQg aXMgbm8gbG9uZ2VyIHVzZWQgYXMgdGhlIG5vbmNlLiBJdCBpcyBlbmNvZGVkIGFzIGEgdmFyaWFi bGUgbGVuZ3RoIG51bWJlci4gQWx3YXlzIHN0YXJ0cyBhdCAwLg0KDQogICAgICogICBObyBvc3Np ZmljYXRpb24gb2YgUE4NCiAgICAgKiAgIE5vIGxpbmthYmlsaXR5IHVzaW5nIFBODQogICAgICog ICBBbGxvd3MgZm9yIGdyb3d0aCBiZXlvbmQgNjQgYml0cyBpZiBuZWVkZWQgaW4gZnV0dXJlDQoN CiAgMS4gIFRoZSBub25jZSBpcyBpbiB0aGUgY2xlYXIgaW4gcGxhaW50ZXh0IGhlYWRlci4gSXQg aXMgZ2VuZXJhdGVkIHBlciBwYXRoIGFzIGEgc2VjdXJlIHJhbmRvbSBudW1iZXIuIENhbGwgdGhp cyB0aGUg4oCcc3RhcnRpbmcgdmFsdWXigJ0uIEJvdGggc2lkZXMgTVVTVCBpbml0aWFsaXplIHRo ZSDigJxzdGFydGluZyB2YWx1ZeKAnSBub25jZSBwZXIgcGF0aC4gV2l0aGluIGEgcGF0aCBpdCBn cm93cyBtb25vdG9uaWNhbGx5ICh0byBhdm9pZCByZXBlYXRzIGp1c3QgbGlrZSBQTiB0b2RheSkg YW5kIGNhbiBpbmNsdWRlIHNob3J0IHJhbmRvbSBqdW1wcyBwZXJpb2RpY2FsbHkgc28gdGhhdCBt aWRkbGVib3hlcyBjYW5ub3QgYXNzdW1lIGFueXRoaW5nIGFib3V0IHRoZSBmaWVsZC4gU2luY2Ug bm9uY2UgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBQTiB0aGUganVtcHMgZG9u4oCZdCBhZGQgYW55 IGNvbXBsZXhpdHkgdG8gdHJhbnNwb3J0IGxvZ2ljLiBKdW1wcyBhcmUgZm9yIGdyZWFzaW5nIGFu ZCBwcmV2ZW50aW5nIG9zc2lmaWNhdGlvbi4gV2hlbiB0aGUgbm9uY2Ugcm9sbHMgb3ZlciBhbmQg cmVhY2hlcyBjbG9zZSB0byB0aGUg4oCcc3RhcnRpbmcgdmFsdWXigJ0sIGtleSByb2xsb3ZlciBt dXN0IGhhcHBlbi4gQXQgaGlnaCBkYXRhIHJhdGVzIHRoZSBub25jZSBmaWVsZCBjYW4gYmUgNjQt Yml0cyB0byBwcmV2ZW50IGZyZXF1ZW50IGtleSByb2xsb3Zlci4gRm9yIGNyeXB0byB0aGF0IGRv ZXNu4oCZdCBuZWVkIG5vbmNlcywgdGhlIGZpZWxkIGNhbiBiZSBvbWl0dGVkLg0KDQogICAgICog ICBObyBvc3NpZmljYXRpb24gYmVjYXVzZSB0aGVyZSBpcyBubyBwcmUtZGV0ZXJtaW5lZCBzZXF1 ZW5jZSB0byB0aGUgbm9uY2UuDQogICAgICogICBJbiBnUVVJQyBhbmQgdGhlIFJGQyBhcyBkZWZp bmVkIHRoZSBub25jZSBpcyBhIHNpbXBsZSBzZXF1ZW5jZSB0aGF0IGluY3JlbWVudHMgYnkgb25l LCBzbyB0aGlzIGlzIG5vIHdvcnNlIG9mZiBpbiB0ZXJtcyBvZiBzZWN1cml0eS4gSXQgaXMgbm9u LXJlcGVhdGluZy4NCiAgICAgKiAgIE5vIGxpbmthYmlsaXR5IGJlY2F1c2UgZGlmZmVyZW50IHBh dGhzIHN0YXJ0IGF0IGEgY29tcGxldGVseSBkaWZmZXJlbnQgcmFuZG9tIG51bWJlci4gSWYgcmVw ZWF0aW5nIGlzIGEgY29uY2VybiB0aGVuIGRpZmZlcmVudCBwYXRocyB1c2UgZGlmZmVyZW50IGtl eXMuIENhcnJpZXMgZm9yd2FyZCB0byBub3QganVzdCBjb25uZWN0aW9uIG1pZ3JhdGlvbiBidXQg bXV0bGktcGF0aC4NCiAgICAgKiAgIFN1cHBvcnRzIGtleSByb2xsb3ZlciBqdXN0IGxpa2UgZ1FV SUMgYW5kIGN1cnJlbnRseSBkZWZpbmVkIGRyYWZ0IFJGQy4NCiAgICAgKiAgIEFsbG93cyBmb3Ig b21pdHRpbmcgdGhlIG5vbmNlIHdoZW4gd2UgdXNlIGNyeXB0byB0aGF0IGRvZXNu4oCZdCBuZWVk IGl0Lg0KICAgICAqICAgQWxsb3dzIGZvciBsYXJnZXIgbm9uY2VzIGZvciBoaWdoIGRhdGEgcmF0 ZXMuDQogICAgICogICBJdCBkb2VzbuKAmXQgcHJlY2x1ZGUgYW55IG90aGVyIHR5cGUgb2Ygbm9u LXJlcGVhdGluZyBub25jZXMgd2l0aG91dCBoYXZpbmcgdG8gbW9kaWZ5IHRoZSBSRkMhIFNvIGlt cGxlbWVudGF0aW9ucyB0aGF0IHdhbnQgdG8gdXNlIGNyeXB0b2dyYXBoaWMgbm9uY2VzIGNhbiBz dGlsbCBkbyBzby4NCg0KVGhlIGRvd25zaWRlczoNCg0KICAxLiAgRXZlbiB3aXRoIHZhcmlhYmxl IGxlbmd0aCBlbmNvZGluZyB0aGUgZXh0cmEgUE4gZmllbGQgaXMgbW9yZSBzcGFjZSB1c2VkIHBl ciBwYWNrZXQgd2hlbiBhIG5vbmNlIGlzIHJlcXVpcmVkLiBJIHRoaW5rIHdlIGNhbiBkbyB3aXRo IDIgYnl0ZXMgaW4gdmVyc2lvbiAxLg0KICAyLiAgSXTigJlzIG5vdCBwZXJmZWN0IHVubGlua2Fi aWx0aXkgYnV0IEkgaGF2ZSB5ZXQgdG8gc2VlIGFueSBzb2x1dGlvbiB0aGF0IGNhbiBwcm92aWRl IHRoaXMuIEEgc2ltcGxlIHRpbWUgYmFzZWQgYW5hbHlzaXMgdXNpbmcgbWFjaGluZSBsZWFybmlu ZyB3aWxsIGFsbG93IGZsb3cgY29ycmVsYXRpb24gZXNwZWNpYWxseSBmb3IgY29ubmVjdGlvbiBt aWdyYXRpb24uIFRoZSBJUCBhZGRyZXNzZXMgaW4gdGhlIGNsZWFyIGFsbG93IGZvciBhIGhpZ2gg ZGVncmVlIG9mIGNvcnJlbGF0aW9uLiBUaGVyZSBpcyBhbHNvIHRoZSBhcHBsaWNhdGlvbiBzZW5k aW5nIHBhdHRlcm4gYW5kIG90aGVyIHNpZ25hbHMgdGhhdCBjb3VsZCBiZSB1c2VkLg0KDQpGcm9t OiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+ XQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSA5LCAyMDE4IDU6NTIgQU0NClRvOiBQcmF2ZWVuIEJh bGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJAbWljcm9zb2Z0 LmNvbT4+DQpDYzogaHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVtYUBo dWl0ZW1hLm5ldD4+OyBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KDQpTdWJq ZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCg0KDQpPbiBUaHUsIEZlYiA4LCAy MDE4IGF0IDk6NDAgUE0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQu Y29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpBY3R1YWxseSB0YWtpbmcg YSBzdGVwIGJhY2sgd2hhdCBpZiB3ZSBkb27igJl0IHdlIG92ZXJsb2FkZWQgcGFja2V0IG51bWJl ciBhcyB0aGUgbm9uY2U/DQoNCkNhbiB3ZToNCg0KICAxLiAgUHV0IHBhY2tldCBudW1iZXIgYXMg YSBzZXBhcmF0ZSB2YXJpYWJsZSBsZW5ndGggZmllbGQgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9u IG9mIHRoZSBoZWFkZXIuIFRoaXMgYWxsb3dzIGZvciBncm93dGggYmV5b25kIDY0IGJpdHMgaW4g ZnV0dXJlIGFuZCBjb21wbGV0ZWx5IGF2b2lkcyBvc3NpZmljYXRpb24uIEZvciBzaG9ydCBsaXZl ZCBmbG93cyB2YXJpYWJsZSBsZW5ndGggZW5jb2RpbmcgbGVhZHMgdG8gbWluaW1hbCBzcGFjZSBv dmVyaGVhZC4NCiAgMi4gIFB1dCBhIHNlcGFyYXRlIHBsYWludGV4dCBub25jZSB3aGljaCBzdGFy dHMgb3V0IGFzIGEgc2VjdXJlIHJhbmRvbSBudW1iZXIgYW5kIG1vbm90b25pY2FsbHkgaW5jcmVh c2VzIGFzIHNob3J0IHJhbmRvbSBqdW1wcyAoZXZlcnkgcGFja2V0IG9yIGV2ZXJ5IGZldyBwYWNr ZXRzKSBhbmQgY291bGQgdGhlbiByb2xsb3Zlci4gVGhpcyB3aWxsIHByZXZlbnQgbGlua2FiaWxp dHkgYW5kIHNjYWxlcyB0byBtdWx0aS1wYXRoIGFzIHdlbGwuIE5vIG1ham9yIGNvbXB1dGUgb3Zl cmhlYWQuIFdlIGNhbiBhbHNvIG1ha2UgdGhlIG5vbmNlIG9wdGlvbmFsIGZvciBjcnlwdG8gYWxn b3JpdGhtcyB0aGF0IGRvIG5vdCBuZWVkIGEgbm9uY2Ugc2F2aW5nIG1vcmUgc3BhY2UuDQoNCkkn bSBub3Qgc3VyZSBob3cgdG8gZG8gIzIgc2FmZWx5IGFuZCBlZmZpY2llbnRseS4gVGhlIHByaW1h cnkgY29uY2VybiBpcyB0aGF0IHNob3J0IHJhbmRvbSBqdW1wcyBkb24ndCBhY3R1YWxseSBwcmV2 ZW50IGxpbmthYmlsaXR5IGJlY2F1c2UgdGhlIGhpZ2ggb3JkZXIgYml0cyBkb24ndCBjaGFuZ2Ug YW5kIGxvbmcgcmFuZG9tIGp1bXBzIGFyZSBlZmZlY3RpdmVseSByYW5kb21seSBzYW1wbGluZyBv dXQgb2YgdGhlIG5vbmNlIHNwYWNlLCBhbmQgeW91IHN0YXJ0IHRvIHJ1biBpbnRvIGJpcnRoZGF5 IHByb2JsZW1zLiBBZGRpdGlvbmFsbHksIHRoZSBjaGVhcGVzdCBQUk5HcyBhcmUgYmFzaWNhbGx5 IGNpcGhlcnMgaW4gY291bnRlciBtb2RlLCBzbyBhdCBiZXN0IHlvdSdyZSBnb2luZyB0byBnZXQg YSBzbWFsbCBhbW91bnQgb2Ygb3ZlcmhlYWQgcmVkdWN0aW9uIGJ5IGdldHRpbmcgbXVsdGlwbGUg anVtcCBjb21wdXRhdGlvbnMgb3V0IG9mIGEgc2luZ2xlIGJsb2NrLCB0aG91Z2ggaWYgeW91IHVz ZSA5Ni1iaXQganVtcHMsIHlvdSBvbmx5IGdldCAyNSUgc2F2aW5ncy4uLg0KDQotRWtyDQoNCg0K DQpTb21lIE1TQiBvZiB0aGUgbm9uY2UgY291bGQgYmUgdXNlZCBmb3Igc2lnbmFsaW5nIHJlb3Jk ZXIgdG8gdGhlIG5ldHdvcmsgaWYgbmVlZGVkLiBJIGRvbuKAmXQgaGF2ZSB0aGUgaGlzdG9yaWNh bCBjb250ZXh0IGZvciBvdmVybG9hZGluZyBvZiBQTiBhcyB0aGUgbm9uY2Ugc28gcGFyZG9uIG1l IGlmIHVuLW92ZXJsb2FkaW5nIG9wdGlvbiB3YXMgZGlzY3Vzc2VkIGFuZCBydWxlZCBvdXQgYmVm b3JlLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUHJhdmVlbiBCYWxhc3VicmFtYW5p YW4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDU6NTEgUE0NClRvOiBodWl0ZW1h IDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj47IHF1aWNA aWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogUGFja2V0IG51bWJl ciBlbmNyeXB0aW9uDQoNCj4+IGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZv ciBlYWNoIHBhdGgNClRoaXMgYWxvbmUgcHJldmVudHMgbGlua2FiaWxpdHkgcmlnaHQ/DQoNCj4+ IFRoZSBwYWNrZXQgbnVtYmVyIG9uIGVhY2ggcGF0aCB3aWxsIHN0YXJ0IGF0IDEgKG9yIG1heWJl IDAgOy0pLg0KSXMgc3VwcG9ydGluZyBtdWx0aXBsZSBwYXRocyBhdCB0aGUgc2FtZSB0aW1lIGEg Z29hbD8gSWYgeWVzLCB0aGVuIHllcyBhbGwgcGF0aHMgd2lsbCBuZWVkIHRvIGhhdmUgc2VwYXJh dGUgdHJhY2tpbmcgYW5kIEFDSyBzdGF0ZSBhbmQgY29uZ2VzdGlvbiBjb250cm9sIGV0Yy4gSSB0 aG91Z2h0IHRoaXMgaXMgbm90IHBhcnQgb2YgVjEgUkZDLiBJZiBpdHMganVzdCBvbmUgYWRkaXRp b25hbCBwYXRoIGZvciBjb25uZWN0aW9uIG1pZ3JhdGlvbiBzY2VuYXJpbyB0aGVuIGFsbCB5b3Ug bmVlZCBpcyBhIChyYW5kb20pIGp1bXAgdG8gYSBvZmZzZXQgaW4gcGFja2V0IG51bWJlciBzcGFj ZSBmb3IgdGhlIG5ldyBwYXRoIHNvIHRoYXQgdGhlIGZldyBwYWNrZXRzIGluIHRoZSBvbGQgcGF0 aCBjYW4gY29udGludWUgZm9yIGEgbGl0dGxlIGJpdC4gVGhpcyB3b3JrcyB3aXRoIGp1c3Qgb25l IEFDSyBzcGFjZSBzbyBubyBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5Lg0KDQo+PiAyKSBPciwg bGVhdmluZyB0aGUgcGFja2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5nIGRpZmZlcmVu dCBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBzZXBhcmF0ZSBw YWNrZXQgc2VxdWVuY2VzIGZvciBlYWNoIHBhdGguDQpJbiBhZGRpdGlvbiBpZiB0aGUgdmFsdWUg aW4gdGhlIGNsZWFyIHdhcyBvYmZ1c2NhdGVkIHdpdGggYW4gWE9SIHRyYW5zZm9ybSBpdCB3aWxs IGhlbHAgcHJldmVudCBvc3NpZmljYXRpb24uIFRoZSBvYmZ1c2NhdGlvbiBpcyBub3QgbWVhbnQg dG8gZ3VhcmQgYWdhaW5zdCBsYXRlciBhbmFseXNpcyB0aGF0IHJldmVhbHMgdGhlIHBhY2tldCBu dW1iZXJzIC0gd2h5IGRvIHdlIGNhcmUgYWJvdXQgdGhhdC4gSXQgaXMgbWVhbnQgdG8gZ3JlYXNl IHRoZSBzcGFjZSBhbmQgbm90IG1ha2UgdGhlIG51bWJlcnMgc2VyaWFsIHNvIG1pZGRsZWJveGVz IGNhbm5vdCBhc3N1bWUgb3JkZXJpbmcgZXRjLg0KDQpBbGwgc2FpZCBpZiBJIGFtIGFsb25lIGlu IGJlaW5nIGNvbmNlcm5lZCBhYm91dCB0aGUgcGVyZiBoaXQgdGhlbiBJ4oCZZCBzYXkgZ28gb24g d2l0aCBvcHRpb24gMS4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIENocmlzdGlhbiBIdWl0ZW1hDQpTZW50OiBUaHVyc2RheSwgRmVicnVh cnkgOCwgMjAxOCAzOjU0IFBNDQpUbzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9y Zz4NClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KDQpPbiAyLzgvMjAx OCAxOjEzIFBNLCBNaWtlIEJpc2hvcCB3cm90ZToNCiMyIHdvbuKAmXQgd29yay4gIFRoZSBwYWNr ZXQgbnVtYmVyIGlzIGFuIGlucHV0IHRvIHRoZSBBRUFEIG5vbmNlLCBzbyB5b3UgaGF2ZSB0byBn ZXQgdG8gdGhlIHBhY2tldCBudW1iZXIgYmVmb3JlIHlvdSBjYW4gZGVjcnlwdCB0aGUgcGF5bG9h ZC4gIEl0IGNhbuKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcgaW50ZXJuYWwgdG8gdGhlIGVuY3J5 cHRlZCBwYWNrZXQuDQoNCkluIE1hcnRpbuKAmXMgcHJvcG9zYWwsIGl04oCZcyB1c2luZyBhIGNv bWJpbmF0aW9uIG9mIHRoZSBlbmNyeXB0ZWQgcGF5bG9hZCAod2hpY2ggcmVxdWlyZXMgbm90aGlu ZyB0byBhY2Nlc3MpIGFuZCBzb21lIHN0b3JlZCBzdGF0ZSBvbiBlYWNoIGVuZHBvaW50LCB3aGlj aCByZXF1aXJlcyBvbmx5IHRoZSBDb25uZWN0aW9uIElEIHRvIGxvb2sgdXAuICBZb3Ugd2FudCB0 aGUgdGhpbmcgeW91IFhPUiBieSB0byBiZSBjb25zdGFudGx5IGNoYW5naW5nLCBvciBpdCBiZWNv bWVzIGVhc2llciB0byBsb29rIGF0IHNlcXVlbmNlcyBvZiBvYmZ1c2NhdGVkIHBhY2tldCBudW1i ZXJzIGFuZCBzdGFydCBkcmF3aW5nIGluZmVyZW5jZXMgYWJvdXQgd2hhdCB0aGUgWE9SIHZhbHVl IGlzLiAgSWYgb3ZlcmhlYWQgaXMgdGhlIHByaW1hcnkgY29uY2VybiwgSSB0aGluayB0aGVyZSBh cmUgYSBjb3VwbGUgYXBwcm9hY2hlcyB0aGF0IG1pZ2h0IGFsbG93IHlvdSB0byBwcmVjb21wdXRl IHZhbHVlcyBhbmQgYW1vcnRpemUgdGhlIGNvc3Qgb2YgZG9pbmcgdGhlIGVuY3J5cHRpb24gc3Rl cC4gIChBdCB0aGUgY29zdCBvZiBrZWVwaW5nIHRoZSB0YWJsZSBvZiBwcmVjb21wdXRlZCB2YWx1 ZXMsIG9mIGNvdXJzZS4pDQoNCkkgc3RpbGwgdGhpbmsgSmFuYeKAmXMgcHVzaGluZyBpbiB0aGUg cmlnaHQgZGlyZWN0aW9uIGhlcmU6ICBMZXTigJlzIGFncmVlIG9uIGdvYWxzLCBhbmQgdGhlbiBz ZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWduIHRoYXQgbWVldHMgdGhvc2UgZ29hbHMuICBJIGhl YXIgeW91IHNheWluZyB0aGF0IGxvdyBvdmVyaGVhZCBpcyBhIGdvYWwsIHdoaWNoIEkgdGhpbmsg d2UgY2FuIGFsbCBhZ3JlZSBvbi4gIEkgYWxzbyB0aGluayBJIGhlYXIgeW91IHNheWluZyB0aGF0 IDEtMS41JSBvdmVyaGVhZCBpcyB0b28gaGlnaCwgYnV0IGl0IHNvdW5kcyBsaWtlIHRoZXJl4oCZ cyBsZXNzIGFncmVlbWVudCBvbiB0aGF0LiAgWW91IGFsc28gcmFpc2UgYW4gaW50ZXJlc3Rpbmcg cG9pbnQgdGhhdCBzb21lIGNsaWVudHMgd2lsbCBjYXJlIGxlc3MgYWJvdXQgbGlua2FiaWxpdHkg YmVjYXVzZSB0aGV5IHdpbGwgbmV2ZXIgaW50ZW50aW9uYWxseSBtaWdyYXRlLg0KDQpJIHRoaW5r IFZpY3RvciBzYWlkIGl0IGJlc3QsICJPYmZ1c2NhdGlvbiBpcyBqdXN0IGVuY3J5cHRpb24gZG9u ZSBwb29ybHkuIiBFaXRoZXIgd2UgZW5jcnlwdCwgb3Igd2UgZG9uJ3QuIEJ1dCB0aGVyZSBpcyBu byBzdWNoIHRoaW5nIGFzIGFuIG9iZnVzY2F0aW9uIG1pZGRsZS1ncm91bmQuIE9iZnVzY2F0aW9u IHdvdWxkIGp1c3QgYmUgYSBzcGVlZCBidW1wLCBlYXNpbHkgYnJva2VuLiBJdCB3b24ndCBwcm92 aWRlIHByaXZhY3ksIGFuZCBpdCB3b24ndCBwcmV2ZW50IGxpbmthYmlsaXR5Lg0KDQpBcyBmYXIg YXMgSSBhbSBjb25jZXJuZWQsIHRoZXJlIGFyZSBvbmx5IHR3byBkZXNpZ25zIHRoYXQgcHJldmVu dCBsaW5rYWJpbGl0eToNCg0KMSkgTWFydGluJ3MgUFIsIGluIHdoaWNoIHRoZSBwYWNrZXQgbnVt YmVyIGlzIGVuY3J5cHRlZCB1c2luZyBzZW5zaWJsZSBjcnlwdG87DQoNCjIpIE9yLCBsZWF2aW5n IHRoZSBwYWNrZXQgbnVtYmVyIGluIHRoZSBjbGVhciBidXQgdXNpbmcgZGlmZmVyZW50IGVuY3J5 cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBz ZXF1ZW5jZXMgZm9yIGVhY2ggcGF0aC4NCg0KVGhlIHNlY29uZCBvcHRpb24gcmVxdWlyZXMgbW9y ZSBjb21wdXRhdGlvbiB3aGVuIGV4cGxpY2l0bHkgc2V0dGluZyB1cCBhIG5ldyBwYXRoLiBUaGUg Y29ubmVjdGlvbiBJRCB3b3VsZCBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlICJzYWx0IiB3aGVuIGRl cml2aW5nIGNvbm5lY3Rpb24gY29udGV4dHMuIFRoZSBwYWNrZXQgbnVtYmVyIG9uIGVhY2ggcGF0 aCB3aWxsIHN0YXJ0IGF0IDEgKG9yIG1heWJlIDAgOy0pLiBUaGlzIHJlcXVpcmVzIG1haW50YWlu aW5nIHNlcGFyYXRlIFNBQ0sgZGFzaGJvYXJkcyBmb3IgZWFjaCBwYXRoL0Nvbm5lY3Rpb24tSUQs IGFuZCBjb25zdHJhaW5pbmcgQUNLIHRvIGJlIHBlci9wYXRoLCBvciBhbHRlcm5hdGl2ZWx5IGFk ZGluZyBhIFBBVEgtQUNLIGZyYW1lIHRoYXQgaW5kaWNhdGVzIHRoZSBwYXRoIGZvciB3aGljaCBw YWNrZXRzIGFyZSBhY2tlZC4NCg0KVGhlIHByb3MgYW5kIGNvbnMgb2YgdGhlIHR3byBvcHRpb25z IGFyZSBlYXN5IHRvIGdldDoNCg0KMSkgT3B0aW9uIDIgZG9lcyBub3QgcmVxdWlyZSB0aGUgY29z dCBvZiBlbmNyeXB0aW5nIGV2ZXJ5IHBhY2tldCwgdGh1cyBwZXIgcGFja2V0IHByb2Nlc3Npbmcg d2lsbCBiZSBtYXliZSAxJSBmYXN0ZXIgdGhhbiBvcHRpb24gMS4NCg0KMikgT3B0aW9uIDIgcmVx dWlyZXMgY29tcHV0aW5nIGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgd2hpY2gg aXMgbW9yZSBjb21wbGV4IHRoYW4gb3B0aW9uIDEsIGJ1dCB0aGUgY29zdCB3aWxsIGJlIGFtb3J0 aXplZCBvdmVyIHRoZSBkdXJhdGlvbiBvZiB0aGUgcGF0aC4NCg0KMykgT3B0aW9uIDIgcmVxdWly ZXMgbW9yZSBjb21wbGV4IGRhdGEgc3RydWN0dXJlcyBhbmQgQUNLIG1hbmFnZW1lbnQsIHRodXMg aW5jcmVhc2luZyB0aGUgY2hhbmNlcyB0aGF0IHNvbWV0aGluZyBnb2VzIHdyb25nLg0KDQo0KSBP cHRpb24gMiBkb2VzIG5vdGhpbmcgYWdhaW5zdCBwYWNrZXQgbnVtYmVyIG9zc2lmaWNhdGlvbi4g VGhlIHBhY2tldCBudW1iZXIgZWZmZWN0aXZlbHkgYmVjb21lcyBwYXJ0IG9mIHRoZSBpbnZhcmlh bnRzLg0KDQpJbiBzaG9ydCwgdGhlIG9ubHkgYWR2YW50YWdlIG9mIG9wdGlvbiAyIGlzIHRvIGF2 b2lkIGEgc2luZ2xlIHN5bW1ldHJpYyBlbmNyeXB0aW9uIG9wZXJhdGlvbiBwZXIgcGFja2V0LCB3 aGlsZSBtYWtpbmcgdGhlIGNvZGUgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXgsIGFuZCBhdCB0 aGUgY29zdCBvZiBub3QgcHJvdGVjdGluZyBhZ2FpbnN0IFBOIG9zc2lmaWNhdGlvbi4gVGhlIHdh eSBJIHNlZSB0aGF0LCB0aGVyZSBpcyBoYXJkbHkgYW55IGRlYmF0ZS4NCg0KLS0gQ2hyaXN0aWFu IEh1aXRlbWENCg0K --_000_CY4PR21MB0133A4FC7160DA1FABAA291BB6F20CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM1NjM1 MDIyNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTEyMjgyMjAyO30NCkBsaXN0IGwxDQoJe21z by1saXN0LWlkOjQxNDc0NDQ5NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTQzOTU0MDkyO30N CkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjgzODQyMTcxMjsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTI0OTIxMTE2O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCBWTEUgaXRzIG1pbmltYWwg b3ZlcmhlYWQgcGVyIHBhY2tldCBzbyB5b3UgYXJlIG5vdCBlbmNyeXB0aW5nIDQgYnl0ZXMgbW9y ZSBhbGwgdGhlIHRpbWUgZXZlbiB3aXRoIDY0IGJpdCBvciAxMjggYml0IHBhY2tldCBudW1iZXIg LiBTbyBpdHMgZGVjaWRlZGx5IGJldHRlci4gQWxzbyBmZXdlciBjYWxscyBpbnRvIFRMUywgYnV0 IEkgc3VwcG9zZSBvbmUgY291bGQgZG8gc29tZSByZWZhY3RvcmluZyBvZg0KIFRMUyBBUEkuIE1h bnkgQ1BVcyB5ZXMgYnV0IHRoaXMgaXMgYSBnZW5lcmFsIHB1cnBvc2UgdHJhbnNwb3J0IGFuZCBj b3VsZCBydW4gb24gQ1BVcyB0aGF0IGRvbuKAmXQuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RGlkbuKAmXQgYXNrIGZvciBub25jZSB0byBiZSB2YXJpYWJsZSBsZW5ndGguIEZpeGVkIGxlbmd0 aCBmb3IgY29ubmVjdGlvbiBsaWZldGltZS4gRGF0YWNlbnRlcnMgY29ubmVjdGlvbnMgY291bGQg dXNlIDY0LWJpdCBub25jZSB0byBhdm9pZCBmcmVxdWVudCBrZXkgcm9sbG92ZXIuDQo8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RWZmZWN0aXZlbHkgdGhlIHBsYWluIHRleHQgbm9uY2UgaXMgYSBz ZXF1ZW5jZSBudW1iZXIgc2luY2UgaXQgaW5jcmVhc2VzIG1vbm90b25pY2FsbHkgd2l0aCBzbWFs bCBqdW1wcyBhcyBuZWVkZWQgdG8gYXZvaWQgb3NzaWZpY2F0aW9uLiBTbyBubyB3b3JzZSBvZmYg dGhhbiBnUVVJQyBvciBjdXJyZW50IGRyYWZ0LiBObyBtb3JlIGNvbXBsZXggdGhhbiB1c2luZyB0 aGUgcGFja2V0IG51bWJlci4gSnVzdCB0aGUNCiBzdGFydGluZyBudW1iZXIgaXMgcmFuZG9taXpl ZC4gQWxzbyBwbGVhc2Ugbm90aWNlIHRoYXQgdGhpcyBwcm9wb3NhbCBkb2VzIG5vdCBwcmVjbHVk ZSB1c2luZyBlbmNyeXB0ZWQgcGFja2V0IG51bWJlciBhcyB0aGUgbm9uY2UgYXMgcHJvcG9zZWQg cHJldmlvdXNseS4gQ2hhbmdpbmcgaG93IHRoZSBub25jZSB3b3JrcyBtYWtlcyAwIGltcGFjdCBv biB0aGUgdHJhbnNwb3J0IGxvZ2ljLiBBbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2hvb3NlIHRvIGlt cGxlbWVudA0KIGFueSBmb3JtIG9mIG5vbi1yZXBlYXRpbmcgbm9uY2Ugd2l0aG91dCByZXZ2aW5n IHRoZSBSRkMuIFRoaXMgaXMgdGhlIGJpZ2dlc3QgYWR2YW50YWdlIG9mIHNlcGFyYXRpb24gb2Yg Y29uY2VybnMgSU1ITy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IERhdmlk IEJlbmphbWluIFttYWlsdG86ZGF2aWRiZW5AY2hyb21pdW0ub3JnXSA8YnI+DQo8Yj5TZW50Ojwv Yj4gRnJpZGF5LCBGZWJydWFyeSA5LCAyMDE4IDExOjM5IEFNPGJyPg0KPGI+VG86PC9iPiBQcmF2 ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc7 IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPllvdXIgcHJpbWFyeSB3b3JyeSBoZXJlIHdhcyB0aGUgZXh0cmEgYmxvY2sgY2lwaGVyIG9w ZXJhdGlvbiwgcmlnaHQ/IEJ5IG1vdmluZyB0aGUgcGFja2V0IG51bWJlciBpbnRvIHRoZSBwbGFp bnRleHQsIHRoaXMgcHJvcG9zYWwgaW5jcmVhc2VzIHRoZSBsZW5ndGgsIHdoaWNoIHdpbGwgY29z dCB0aGF0IHNhbWUgb25lIGV4dHJhIGJsb2NrIGNpcGhlciBvcGVyYXRpb24sIG5vPzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGlzIG9uZSBi bG9jayBvcGVyYXRpb24gdW5kZXIgdGhlIHNhbWUga2V5LCByYXRoZXIgdGhhbiBhIGRpZmZlcmVu dCBrZXkgc28gSSBzdXBwb3NlIHRoZXJlIGFyZSBtaW51c2N1bGUmbmJzcDtjYWNoZSBmb290cHJp bnQgd2lucyAob25lIHN5bW1ldHJpYyBrZXkgaXMgMTYgb3IgMzIgYnl0ZXMpLiBCdXQgdGhlIGNv c3QgaXMgcGVyLXBhY2tldCAoISkgYmFuZHdpZHRoIGFuZCBjb21wbGV4aXR5LiBJIGRvIG5vdCBz ZWUNCiBob3cgdGhpcyBjb3VsZCBiZSB3b3J0aCBpdC4mbmJzcDtOb3RlIHRoYXQsIGZvciBBRVMs IG1hbnkgQ1BVcyBoYXZlIGRlZGljYXRlZCBpbnN0cnVjdGlvbnMgZm9yIGl0IGFscmVhZHkuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7Q2xlYXIgc2VwYXJhdGlvbiBvZiBjb25jZXJucyBy ZXN1bHRzIGlmIHdlIGRvbuKAmXQgb3ZlcmxvYWQgdGhlIHBhY2tldCBudW1iZXIgYXMgdGhlIG5v bmNlLiBDb25uZWN0aW9uIG1pZ3JhdGlvbiBhbmQgbXVsdGktcGF0aCBhcmUgb3B0aW9uYWwgZmVh dHVyZXMgYW5kIHdlIHBheSBubyBleHRyYSBjb21wdXRlIGNvc3QgZm9yIG1vc3QgY29ubmVjdGlv bnMgdGhhdCBhcmUgbm90IGltcGFjdGVkIGJ5IHVubG5rYWJpbGl0eS4NCiBOb25jZSBmaWVsZCBi ZWNvbWVzIG9wdGlvbmFsIGZvciBjcnlwdG8gdGhhdCBkb2VzbuKAmXQgbmVlZCBpdCBhbmQgY2Fu IGdyb3cgdG8gbGFyZ2VyIHNpemUgYXMgbmVlZGVkIGZvciBidWxrIHRyYW5zZmVycyB0byBwcmV2 ZW50IGZyZXF1ZW50IGtleSByb2xsb3ZlcnMgKHNheSBpbiBkYXRhY2VudGVyIHNjZW5hcmlvcyku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91J3JlIG5vdCBnb2luZyB0byBmaW5kIEFFQURzIHRoYXQg ZG9uJ3QgcmVxdWlyZSBhIG5vbmNlLiBFbmNyeXB0aW9uIG11c3Qgbm90IHByb2R1Y2UgdGhlIHNh bWUgY2lwaGVydGV4dCB0d2ljZSBmb3IgdGhlIHNhbWUgcGxhaW50ZXh0LCBzbyB5b3UgbmVlZCBz b21lIGlucHV0IHRvIGRpdmVyc2lmeSB0aGVtLiBUaGF0IGlucHV0IGlzIHRoZSBub25jZS4gTm9u Y2VzIGFsc28gYXJlIG5vdCB2YXJpYWJsZS1sZW5ndGgsDQogc28geW91IGRvbid0IGdldCB0byBh cmJpdHJhcmlseSBncm93IHRoZW0uIChBRVMtR0NNIHBlciBzcGVjIGlzIHZhcmlhYmxlIGxlbmd0 aCwgYnV0IHRoYXQncyBhIHNwZWMgYnVnLiBJZiB5b3Ugc2l6ZSBpdCBhYm92ZSA5NiBiaXRzLCBp dCdzIGFzIGlmIHlvdSByYW5kb21pemVkIGl0IGFuZCB5b3VyIG5vbmNlIHNwYWNlIGNyYXNoZXMg cGVyIGJpcnRoZGF5Lik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SXQgaXMgYWxzbyBoYXJtZnVsIHRvIHNlcGFyYXRlIHRoZSB0d28gY29uY2Vy bnMuJm5ic3A7V2hlbiB5b3UgYXJlIGJ1aWxkaW5nIGEgdHJhbnNwb3J0LCBkZXJpdmUgdGhlIG5v bmNlIGZyb20gYSBzZXF1ZW5jZSBudW1iZXIuIFRMUyAxLjIgQUVTLUdDTSBzZXBhcmF0ZWQgdGhl bSwgd2hpY2ggd2FzIGEgbWlzdGFrZS4gSXQncyBsZXNzIGVmZmljaWVudCAodGhlIHdvcmxkIHdh c3RlZCBxdWl0ZSBhIGxvdCBvZiBiYW5kd2lkdGgNCiBkdWUgdG8gdGhpcyksIGFuZCBtb3JlIGVy cm9yLXByb25lLiBUaGVyZSB3YXMgbm90aGluZyBzdG9wcGluZyBpbXBsZW1lbnRhdGlvbnMgZnJv bSBzZW5kaW5nIHRoZSBzYW1lIG5vbmNlIG9yIGdlbmVyYXRpbmcgbm9uY2VzIHJhbmRvbWx5ICh0 aGUgQUVBRHMgd2UgdXNlIGRvbid0IGhhdmUgbGFyZ2UgZW5vdWdoIG5vbmNlcyBmb3IgdGhhdCks IGFuZCBpbmRlZWQgc29tZSBkaWQganVzdCB0aGF0LiBJZiB5b3UgdXNlIHNvbWUgc29ydCBvZiBz ZXF1ZW5jZQ0KIG51bWJlciwgeW91IGNhbiBsZWFuIG9uIGV4aXN0aW5nIHdvcmsgYm90aCB0byBm aWx0ZXIgb3V0IHRoZSBvYnZpb3VzIGltcGxlbWVudGF0aW9uIG1pc3Rha2VzIGFuZCB0byBhdm9p ZCBzZW5kaW5nIHVubmVjZXNzYXJ5IGRhdGEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBGZWIgOSwgMjAx OCBhdCAxMjozOCBQTSBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OnByYXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5wcmF2YkBtaWNyb3NvZnQuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TGV0IG1lIHRyeSB0byBzdW1tYXJpemUg dGhlIHByb3Bvc2FsIGFnYWluOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NClBhY2tldCBudW1iZXIg aXMgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBoZWFkZXIgYW5kIGlzIG5vIGxvbmdl ciB1c2VkIGFzIHRoZSBub25jZS4gSXQgaXMgZW5jb2RlZCBhcyBhIHZhcmlhYmxlIGxlbmd0aCBu dW1iZXIuIEFsd2F5cyBzdGFydHMgYXQgMC4NCjxvOnA+PC9vOnA+PC9saT48L29sPg0KPG9sIHN0 YXJ0PSIxIiB0eXBlPSIxIj4NCjxvbCBzdGFydD0iMSIgdHlwZT0iYSI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMiBsZm8xIj4NCk5vIG9zc2lmaWNhdGlvbiBvZiBQ TjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVs MiBsZm8xIj4NCk5vIGxpbmthYmlsaXR5IHVzaW5nIFBOPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzEiPg0KQWxsb3dzIGZvciBncm93 dGggYmV5b25kIDY0IGJpdHMgaWYgbmVlZGVkIGluIGZ1dHVyZTxvOnA+PC9vOnA+PC9saT48L29s Pg0KPC9vbD4NCjxvbCBzdGFydD0iMiIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NClRoZSBub25jZSBpcyBpbiB0aGUgY2xlYXIgaW4g cGxhaW50ZXh0IGhlYWRlci4gSXQgaXMgZ2VuZXJhdGVkIDxpPnBlciBwYXRoPC9pPiBhcyBhIHNl Y3VyZSByYW5kb20gbnVtYmVyLiBDYWxsIHRoaXMgdGhlIOKAnHN0YXJ0aW5nIHZhbHVl4oCdLiBC b3RoIHNpZGVzIE1VU1QgaW5pdGlhbGl6ZSB0aGUg4oCcc3RhcnRpbmcgdmFsdWXigJ0gbm9uY2UN CjxpPnBlciBwYXRoPC9pPi4gV2l0aGluIGEgcGF0aCBpdCBncm93cyBtb25vdG9uaWNhbGx5ICh0 byBhdm9pZCByZXBlYXRzIGp1c3QgbGlrZSBQTiB0b2RheSkgYW5kIGNhbiBpbmNsdWRlIHNob3J0 IHJhbmRvbSBqdW1wcyBwZXJpb2RpY2FsbHkgc28gdGhhdCBtaWRkbGVib3hlcyBjYW5ub3QgYXNz dW1lIGFueXRoaW5nIGFib3V0IHRoZSBmaWVsZC4gU2luY2Ugbm9uY2UgaGFzIG5vdGhpbmcgdG8g ZG8gd2l0aCBQTiB0aGUganVtcHMgZG9u4oCZdCBhZGQNCiBhbnkgY29tcGxleGl0eSB0byB0cmFu c3BvcnQgbG9naWMuIEp1bXBzIGFyZSBmb3IgZ3JlYXNpbmcgYW5kIHByZXZlbnRpbmcgb3NzaWZp Y2F0aW9uLiBXaGVuIHRoZSBub25jZSByb2xscyBvdmVyIGFuZCByZWFjaGVzIGNsb3NlIHRvIHRo ZSDigJxzdGFydGluZyB2YWx1ZeKAnSwga2V5IHJvbGxvdmVyIG11c3QgaGFwcGVuLiBBdCBoaWdo IGRhdGEgcmF0ZXMgdGhlIG5vbmNlIGZpZWxkIGNhbiBiZSA2NC1iaXRzIHRvIHByZXZlbnQgZnJl cXVlbnQga2V5DQogcm9sbG92ZXIuIEZvciBjcnlwdG8gdGhhdCBkb2VzbuKAmXQgbmVlZCBub25j ZXMsIHRoZSBmaWVsZCBjYW4gYmUgb21pdHRlZC4gPG86cD48L286cD48L2xpPjwvb2w+DQo8b2wg c3RhcnQ9IjIiIHR5cGU9IjEiPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzIiPg0KTm8gb3NzaWZpY2F0aW9uIGJl Y2F1c2UgdGhlcmUgaXMgbm8gcHJlLWRldGVybWluZWQgc2VxdWVuY2UgdG8gdGhlIG5vbmNlLjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMiBs Zm8yIj4NCkluIGdRVUlDIGFuZCB0aGUgUkZDIGFzIGRlZmluZWQgdGhlIG5vbmNlIGlzIGEgc2lt cGxlIHNlcXVlbmNlIHRoYXQgaW5jcmVtZW50cyBieSBvbmUsIHNvIHRoaXMgaXMgbm8gd29yc2Ug b2ZmIGluIHRlcm1zIG9mIHNlY3VyaXR5LiBJdCBpcyBub24tcmVwZWF0aW5nLjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMiBsZm8yIj4NCk5v IGxpbmthYmlsaXR5IGJlY2F1c2UgZGlmZmVyZW50IHBhdGhzIHN0YXJ0IGF0IGEgY29tcGxldGVs eSBkaWZmZXJlbnQgcmFuZG9tIG51bWJlci4gSWYgcmVwZWF0aW5nIGlzIGEgY29uY2VybiB0aGVu IGRpZmZlcmVudCBwYXRocyB1c2UgZGlmZmVyZW50IGtleXMuIENhcnJpZXMgZm9yd2FyZCB0byBu b3QganVzdCBjb25uZWN0aW9uIG1pZ3JhdGlvbiBidXQgbXV0bGktcGF0aC4NCjxvOnA+PC9vOnA+ PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMiBsZm8yIj4NClN1 cHBvcnRzIGtleSByb2xsb3ZlciBqdXN0IGxpa2UgZ1FVSUMgYW5kIGN1cnJlbnRseSBkZWZpbmVk IGRyYWZ0IFJGQy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMiBsZXZlbDIgbGZvMiI+DQpBbGxvd3MgZm9yIG9taXR0aW5nIHRoZSBub25jZSB3aGVuIHdl IHVzZSBjcnlwdG8gdGhhdCBkb2VzbuKAmXQgbmVlZCBpdC48bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIgbGZvMiI+DQpBbGxvd3MgZm9yIGxh cmdlciBub25jZXMgZm9yIGhpZ2ggZGF0YSByYXRlcy4gPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzIiPg0KSXQgZG9lc27igJl0IHBy ZWNsdWRlIGFueSBvdGhlciB0eXBlIG9mIG5vbi1yZXBlYXRpbmcgbm9uY2VzIHdpdGhvdXQgaGF2 aW5nIHRvIG1vZGlmeSB0aGUgUkZDISBTbyBpbXBsZW1lbnRhdGlvbnMgdGhhdCB3YW50IHRvIHVz ZSBjcnlwdG9ncmFwaGljIG5vbmNlcyBjYW4gc3RpbGwgZG8gc28uDQo8bzpwPjwvbzpwPjwvbGk+ PC9vbD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgZG93bnNpZGVzOjxvOnA+PC9vOnA+PC9wPg0K PG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzMiPg0KRXZlbiB3aXRoIHZhcmlhYmxlIGxlbmd0aCBlbmNvZGluZyB0aGUg ZXh0cmEgUE4gZmllbGQgaXMgbW9yZSBzcGFjZSB1c2VkIHBlciBwYWNrZXQgd2hlbiBhIG5vbmNl IGlzIHJlcXVpcmVkLiBJIHRoaW5rIHdlIGNhbiBkbyB3aXRoIDIgYnl0ZXMgaW4gdmVyc2lvbiAx LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs MSBsZm8zIj4NCkl04oCZcyBub3QgcGVyZmVjdCB1bmxpbmthYmlsdGl5IGJ1dCBJIGhhdmUgeWV0 IHRvIHNlZSBhbnkgc29sdXRpb24gdGhhdCBjYW4gcHJvdmlkZSB0aGlzLiBBIHNpbXBsZSB0aW1l IGJhc2VkIGFuYWx5c2lzIHVzaW5nIG1hY2hpbmUgbGVhcm5pbmcgd2lsbCBhbGxvdyBmbG93IGNv cnJlbGF0aW9uIGVzcGVjaWFsbHkgZm9yIGNvbm5lY3Rpb24gbWlncmF0aW9uLiBUaGUgSVAgYWRk cmVzc2VzIGluIHRoZSBjbGVhciBhbGxvdyBmb3IgYSBoaWdoIGRlZ3JlZQ0KIG9mIGNvcnJlbGF0 aW9uLiBUaGVyZSBpcyBhbHNvIHRoZSBhcHBsaWNhdGlvbiBzZW5kaW5nIHBhdHRlcm4gYW5kIG90 aGVyIHNpZ25hbHMgdGhhdCBjb3VsZCBiZSB1c2VkLg0KPG86cD48L286cD48L2xpPjwvb2w+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gRXJpYyBSZXNjb3JsYSBbbWFpbHRvOjxhIGhyZWY9Im1h aWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgOSwgMjAxOCA1OjUyIEFNPGJyPg0KPGI+ VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnByYXZi QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5wcmF2YkBtaWNyb3NvZnQuY29tPC9hPiZn dDs8YnI+DQo8Yj5DYzo8L2I+IGh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1 aXRlbWEubmV0IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7Ow0K PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYu b3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tldCBudW1i ZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBUaHUsIEZlYiA4LCAyMDE4IGF0IDk6NDAgUE0sIFByYXZlZW4gQmFs YXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbSIgdGFy Z2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFjdHVhbGx5IHRha2luZyBhIHN0 ZXAgYmFjayB3aGF0IGlmIHdlIGRvbuKAmXQgd2Ugb3ZlcmxvYWRlZCBwYWNrZXQgbnVtYmVyIGFz IHRoZSBub25jZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNhbiB3ZTo8bzpwPjwvbzpw PjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwxIGxldmVsMSBsZm80Ij4NClB1dCBwYWNrZXQgbnVtYmVyIGFzIGEgc2VwYXJhdGUg dmFyaWFibGUgbGVuZ3RoIGZpZWxkIGluIHRoZSBlbmNyeXB0ZWQgcG9ydGlvbiBvZiB0aGUgaGVh ZGVyLiBUaGlzIGFsbG93cyBmb3IgZ3Jvd3RoIGJleW9uZCA2NCBiaXRzIGluIGZ1dHVyZSBhbmQg Y29tcGxldGVseSBhdm9pZHMgb3NzaWZpY2F0aW9uLiBGb3Igc2hvcnQgbGl2ZWQgZmxvd3MgdmFy aWFibGUgbGVuZ3RoIGVuY29kaW5nIGxlYWRzIHRvIG1pbmltYWwgc3BhY2Ugb3ZlcmhlYWQuDQo8 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEg bGZvNCI+DQpQdXQgYSBzZXBhcmF0ZSBwbGFpbnRleHQgbm9uY2Ugd2hpY2ggc3RhcnRzIG91dCBh cyBhIHNlY3VyZSByYW5kb20gbnVtYmVyIGFuZCBtb25vdG9uaWNhbGx5IGluY3JlYXNlcyBhcyBz aG9ydCByYW5kb20ganVtcHMgKGV2ZXJ5IHBhY2tldCBvciBldmVyeSBmZXcgcGFja2V0cykgYW5k IGNvdWxkIHRoZW4gcm9sbG92ZXIuIFRoaXMgd2lsbCBwcmV2ZW50IGxpbmthYmlsaXR5IGFuZCBz Y2FsZXMgdG8gbXVsdGktcGF0aCBhcyB3ZWxsLiBObyBtYWpvcg0KIGNvbXB1dGUgb3ZlcmhlYWQu IFdlIGNhbiBhbHNvIG1ha2UgdGhlIG5vbmNlIG9wdGlvbmFsIGZvciBjcnlwdG8gYWxnb3JpdGht cyB0aGF0IGRvIG5vdCBuZWVkIGEgbm9uY2Ugc2F2aW5nIG1vcmUgc3BhY2UuPG86cD48L286cD48 L2xpPjwvb2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkknbSBub3Qgc3VyZSBob3cgdG8gZG8gIzIgc2FmZWx5IGFuZCBl ZmZpY2llbnRseS4gVGhlIHByaW1hcnkgY29uY2VybiBpcyB0aGF0IHNob3J0IHJhbmRvbSBqdW1w cyBkb24ndCBhY3R1YWxseSBwcmV2ZW50IGxpbmthYmlsaXR5IGJlY2F1c2UgdGhlIGhpZ2ggb3Jk ZXIgYml0cyBkb24ndCBjaGFuZ2UgYW5kDQogbG9uZyByYW5kb20ganVtcHMgYXJlIGVmZmVjdGl2 ZWx5IHJhbmRvbWx5IHNhbXBsaW5nIG91dCBvZiB0aGUgbm9uY2Ugc3BhY2UsIGFuZCB5b3Ugc3Rh cnQgdG8gcnVuIGludG8gYmlydGhkYXkgcHJvYmxlbXMuIEFkZGl0aW9uYWxseSwgdGhlIGNoZWFw ZXN0IFBSTkdzIGFyZSBiYXNpY2FsbHkgY2lwaGVycyBpbiBjb3VudGVyIG1vZGUsIHNvIGF0IGJl c3QgeW91J3JlIGdvaW5nIHRvIGdldCBhIHNtYWxsIGFtb3VudCBvZiBvdmVyaGVhZCByZWR1Y3Rp b24NCiBieSBnZXR0aW5nIG11bHRpcGxlIGp1bXAgY29tcHV0YXRpb25zIG91dCBvZiBhIHNpbmds ZSBibG9jaywgdGhvdWdoIGlmIHlvdSB1c2UgOTYtYml0IGp1bXBzLCB5b3Ugb25seSBnZXQgMjUl IHNhdmluZ3MuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U29tZSBNU0Igb2YgdGhlIG5vbmNlIGNvdWxkIGJl IHVzZWQgZm9yIHNpZ25hbGluZyByZW9yZGVyIHRvIHRoZSBuZXR3b3JrIGlmIG5lZWRlZC4gSSBk b27igJl0IGhhdmUgdGhlIGhpc3RvcmljYWwgY29udGV4dCBmb3Igb3ZlcmxvYWRpbmcgb2YgUE4g YXMgdGhlIG5vbmNlIHNvIHBhcmRvbiBtZSBpZiB1bi1vdmVybG9hZGluZw0KIG9wdGlvbiB3YXMg ZGlzY3Vzc2VkIGFuZCBydWxlZCBvdXQgYmVmb3JlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBRVUlDIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlByYXZl ZW4gQmFsYXN1YnJhbWFuaWFuPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSA4 LCAyMDE4IDU6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IGh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0 bzpodWl0ZW1hQGh1aXRlbWEubmV0IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBodWl0ZW1hLm5l dDwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5xdWljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogUGFja2V0IG51bWJl ciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jmd0OyZndDsgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBzZXF1ZW5jZXMgZm9yIGVhY2ggcGF0 aDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRo aXMgYWxvbmUgcHJldmVudHMgbGlua2FiaWxpdHkgcmlnaHQ/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mZ3Q7Jmd0OyBUaGUgcGFja2V0IG51bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFy dCBhdCAxIChvciBtYXliZSAwIDstKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SXMgc3VwcG9ydGluZyBtdWx0aXBsZSBwYXRocyBhdCB0aGUgc2FtZSB0aW1lIGEgZ29h bD8gSWYgeWVzLCB0aGVuIHllcyBhbGwgcGF0aHMgd2lsbCBuZWVkIHRvIGhhdmUgc2VwYXJhdGUg dHJhY2tpbmcgYW5kIEFDSyBzdGF0ZSBhbmQgY29uZ2VzdGlvbiBjb250cm9sIGV0Yy4gSSB0aG91 Z2h0IHRoaXMgaXMNCiBub3QgcGFydCBvZiBWMSBSRkMuIElmIGl0cyBqdXN0IG9uZSBhZGRpdGlv bmFsIHBhdGggZm9yIGNvbm5lY3Rpb24gbWlncmF0aW9uIHNjZW5hcmlvIHRoZW4gYWxsIHlvdSBu ZWVkIGlzIGEgKHJhbmRvbSkganVtcCB0byBhIG9mZnNldCBpbiBwYWNrZXQgbnVtYmVyIHNwYWNl IGZvciB0aGUgbmV3IHBhdGggc28gdGhhdCB0aGUgZmV3IHBhY2tldHMgaW4gdGhlIG9sZCBwYXRo IGNhbiBjb250aW51ZSBmb3IgYSBsaXR0bGUgYml0LiBUaGlzIHdvcmtzDQogd2l0aCBqdXN0IG9u ZSBBQ0sgc3BhY2Ugc28gbm8gaW1wbGVtZW50YXRpb24gY29tcGxleGl0eS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZndDsmZ3Q7IDIpIE9yLCBsZWF2aW5nIHRoZSBwYWNrZXQgbnVtYmVy IGluIHRoZSBjbGVhciBidXQgdXNpbmcgZGlmZmVyZW50IGVuY3J5cHRpb24gY29udGV4dHMgZm9y IGVhY2ggcGF0aCwgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBzZXF1ZW5jZXMgZm9yIGVhY2gg cGF0aC48YnI+DQpJbiBhZGRpdGlvbiBpZiB0aGUgdmFsdWUgaW4gdGhlIGNsZWFyIHdhcyBvYmZ1 c2NhdGVkIHdpdGggYW4gWE9SIHRyYW5zZm9ybSBpdCB3aWxsIGhlbHAgcHJldmVudCBvc3NpZmlj YXRpb24uIFRoZSBvYmZ1c2NhdGlvbiBpcyBub3QgbWVhbnQgdG8gZ3VhcmQgYWdhaW5zdCBsYXRl ciBhbmFseXNpcyB0aGF0IHJldmVhbHMgdGhlIHBhY2tldCBudW1iZXJzIC0gd2h5IGRvIHdlIGNh cmUgYWJvdXQgdGhhdC4gSXQgaXMgbWVhbnQgdG8gZ3JlYXNlIHRoZQ0KIHNwYWNlIGFuZCBub3Qg bWFrZSB0aGUgbnVtYmVycyBzZXJpYWwgc28gbWlkZGxlYm94ZXMgY2Fubm90IGFzc3VtZSBvcmRl cmluZyBldGMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BbGwgc2FpZCBpZiBJIGFtIGFs b25lIGluIGJlaW5nIGNvbmNlcm5lZCBhYm91dCB0aGUgcGVyZiBoaXQgdGhlbiBJ4oCZZCBzYXkg Z28gb24gd2l0aCBvcHRpb24gMS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBRVUlDIFs8YSBocmVmPSJt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzdGlhbiBIdWl0 ZW1hPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDM6NTQgUE08 YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+cXVpY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tldCBu dW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5PbiAyLzgvMjAxOCAxOjEz IFBNLCBNaWtlIEJpc2hvcCB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4jMiB3b27igJl0IHdvcmsuJm5ic3A7IFRoZSBwYWNrZXQgbnVtYmVyIGlzIGFuIGlu cHV0IHRvIHRoZSBBRUFEIG5vbmNlLCBzbyB5b3UgaGF2ZSB0byBnZXQgdG8gdGhlIHBhY2tldCBu dW1iZXIgYmVmb3JlIHlvdSBjYW4gZGVjcnlwdCB0aGUgcGF5bG9hZC4mbmJzcDsgSXQgY2Fu4oCZ dCBiZSBiYXNlZCBvbiBhbnl0aGluZyBpbnRlcm5hbA0KIHRvIHRoZSBlbmNyeXB0ZWQgcGFja2V0 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gTWFydGlu4oCZcyBwcm9wb3NhbCwgaXTi gJlzIHVzaW5nIGEgY29tYmluYXRpb24gb2YgdGhlIGVuY3J5cHRlZCBwYXlsb2FkICh3aGljaCBy ZXF1aXJlcyBub3RoaW5nIHRvIGFjY2VzcykgYW5kIHNvbWUgc3RvcmVkIHN0YXRlIG9uIGVhY2gg ZW5kcG9pbnQsIHdoaWNoIHJlcXVpcmVzIG9ubHkgdGhlIENvbm5lY3Rpb24NCiBJRCB0byBsb29r IHVwLiZuYnNwOyBZb3Ugd2FudCB0aGUgdGhpbmcgeW91IFhPUiBieSB0byBiZSBjb25zdGFudGx5 IGNoYW5naW5nLCBvciBpdCBiZWNvbWVzIGVhc2llciB0byBsb29rIGF0IHNlcXVlbmNlcyBvZiBv YmZ1c2NhdGVkIHBhY2tldCBudW1iZXJzIGFuZCBzdGFydCBkcmF3aW5nIGluZmVyZW5jZXMgYWJv dXQgd2hhdCB0aGUgWE9SIHZhbHVlIGlzLiZuYnNwOyBJZiBvdmVyaGVhZCBpcyB0aGUgcHJpbWFy eSBjb25jZXJuLCBJIHRoaW5rIHRoZXJlIGFyZQ0KIGEgY291cGxlIGFwcHJvYWNoZXMgdGhhdCBt aWdodCBhbGxvdyB5b3UgdG8gcHJlY29tcHV0ZSB2YWx1ZXMgYW5kIGFtb3J0aXplIHRoZSBjb3N0 IG9mIGRvaW5nIHRoZSBlbmNyeXB0aW9uIHN0ZXAuJm5ic3A7IChBdCB0aGUgY29zdCBvZiBrZWVw aW5nIHRoZSB0YWJsZSBvZiBwcmVjb21wdXRlZCB2YWx1ZXMsIG9mIGNvdXJzZS4pPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JIHN0aWxsIHRoaW5rIEphbmHigJlzIHB1c2hpbmcgaW4gdGhl IHJpZ2h0IGRpcmVjdGlvbiBoZXJlOiZuYnNwOyBMZXTigJlzIGFncmVlIG9uIGdvYWxzLCBhbmQg dGhlbiBzZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWduIHRoYXQgbWVldHMgdGhvc2UgZ29hbHMu Jm5ic3A7IEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92ZXJoZWFkDQogaXMgYSBnb2FsLCB3 aGljaCBJIHRoaW5rIHdlIGNhbiBhbGwgYWdyZWUgb24uJm5ic3A7IEkgYWxzbyB0aGluayBJIGhl YXIgeW91IHNheWluZyB0aGF0IDEtMS41JSBvdmVyaGVhZCBpcyB0b28gaGlnaCwgYnV0IGl0IHNv dW5kcyBsaWtlIHRoZXJl4oCZcyBsZXNzIGFncmVlbWVudCBvbiB0aGF0LiZuYnNwOyBZb3UgYWxz byByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNvbWUgY2xpZW50cyB3aWxsIGNhcmUg bGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlDQogdGhleSB3aWxsIG5ldmVyIGludGVudGlv bmFsbHkgbWlncmF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEy LjBwdCI+PGJyPg0KSSB0aGluayBWaWN0b3Igc2FpZCBpdCBiZXN0LCAmcXVvdDtPYmZ1c2NhdGlv biBpcyBqdXN0IGVuY3J5cHRpb24gZG9uZSBwb29ybHkuJnF1b3Q7IEVpdGhlciB3ZSBlbmNyeXB0 LCBvciB3ZSBkb24ndC4gQnV0IHRoZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgYW4gb2JmdXNjYXRp b24gbWlkZGxlLWdyb3VuZC4gT2JmdXNjYXRpb24gd291bGQganVzdCBiZSBhIHNwZWVkIGJ1bXAs IGVhc2lseSBicm9rZW4uIEl0IHdvbid0IHByb3ZpZGUgcHJpdmFjeSwgYW5kIGl0IHdvbid0DQog cHJldmVudCBsaW5rYWJpbGl0eS48YnI+DQo8YnI+DQpBcyBmYXIgYXMgSSBhbSBjb25jZXJuZWQs IHRoZXJlIGFyZSBvbmx5IHR3byBkZXNpZ25zIHRoYXQgcHJldmVudCBsaW5rYWJpbGl0eTo8YnI+ DQo8YnI+DQoxKSBNYXJ0aW4ncyBQUiwgaW4gd2hpY2ggdGhlIHBhY2tldCBudW1iZXIgaXMgZW5j cnlwdGVkIHVzaW5nIHNlbnNpYmxlIGNyeXB0bzs8YnI+DQo8YnI+DQoyKSBPciwgbGVhdmluZyB0 aGUgcGFja2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5nIGRpZmZlcmVudCBlbmNyeXB0 aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2Vx dWVuY2VzIGZvciBlYWNoIHBhdGguPGJyPg0KPGJyPg0KVGhlIHNlY29uZCBvcHRpb24gcmVxdWly ZXMgbW9yZSBjb21wdXRhdGlvbiB3aGVuIGV4cGxpY2l0bHkgc2V0dGluZyB1cCBhIG5ldyBwYXRo LiBUaGUgY29ubmVjdGlvbiBJRCB3b3VsZCBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlICZxdW90O3Nh bHQmcXVvdDsgd2hlbiBkZXJpdmluZyBjb25uZWN0aW9uIGNvbnRleHRzLiBUaGUgcGFja2V0IG51 bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFydCBhdCAxIChvciBtYXliZSAwIDstKS4gVGhpcyBy ZXF1aXJlcyBtYWludGFpbmluZw0KIHNlcGFyYXRlIFNBQ0sgZGFzaGJvYXJkcyBmb3IgZWFjaCBw YXRoL0Nvbm5lY3Rpb24tSUQsIGFuZCBjb25zdHJhaW5pbmcgQUNLIHRvIGJlIHBlci9wYXRoLCBv ciBhbHRlcm5hdGl2ZWx5IGFkZGluZyBhIFBBVEgtQUNLIGZyYW1lIHRoYXQgaW5kaWNhdGVzIHRo ZSBwYXRoIGZvciB3aGljaCBwYWNrZXRzIGFyZSBhY2tlZC48YnI+DQo8YnI+DQpUaGUgcHJvcyBh bmQgY29ucyBvZiB0aGUgdHdvIG9wdGlvbnMgYXJlIGVhc3kgdG8gZ2V0Ojxicj4NCjxicj4NCjEp IE9wdGlvbiAyIGRvZXMgbm90IHJlcXVpcmUgdGhlIGNvc3Qgb2YgZW5jcnlwdGluZyBldmVyeSBw YWNrZXQsIHRodXMgcGVyIHBhY2tldCBwcm9jZXNzaW5nIHdpbGwgYmUgbWF5YmUgMSUgZmFzdGVy IHRoYW4gb3B0aW9uIDEuDQo8YnI+DQo8YnI+DQoyKSBPcHRpb24gMiByZXF1aXJlcyBjb21wdXRp bmcgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCB3aGljaCBpcyBtb3JlIGNvbXBs ZXggdGhhbiBvcHRpb24gMSwgYnV0IHRoZSBjb3N0IHdpbGwgYmUgYW1vcnRpemVkIG92ZXIgdGhl IGR1cmF0aW9uIG9mIHRoZSBwYXRoLjxicj4NCjxicj4NCjMpIE9wdGlvbiAyIHJlcXVpcmVzIG1v cmUgY29tcGxleCBkYXRhIHN0cnVjdHVyZXMgYW5kIEFDSyBtYW5hZ2VtZW50LCB0aHVzIGluY3Jl YXNpbmcgdGhlIGNoYW5jZXMgdGhhdCBzb21ldGhpbmcgZ29lcyB3cm9uZy48YnI+DQo8YnI+DQo0 KSBPcHRpb24gMiBkb2VzIG5vdGhpbmcgYWdhaW5zdCBwYWNrZXQgbnVtYmVyIG9zc2lmaWNhdGlv bi4gVGhlIHBhY2tldCBudW1iZXIgZWZmZWN0aXZlbHkgYmVjb21lcyBwYXJ0IG9mIHRoZSBpbnZh cmlhbnRzLjxicj4NCjxicj4NCkluIHNob3J0LCB0aGUgb25seSBhZHZhbnRhZ2Ugb2Ygb3B0aW9u IDIgaXMgdG8gYXZvaWQgYSBzaW5nbGUgc3ltbWV0cmljIGVuY3J5cHRpb24gb3BlcmF0aW9uIHBl ciBwYWNrZXQsIHdoaWxlIG1ha2luZyB0aGUgY29kZSBzaWduaWZpY2FudGx5IG1vcmUgY29tcGxl eCwgYW5kIGF0IHRoZSBjb3N0IG9mIG5vdCBwcm90ZWN0aW5nIGFnYWluc3QgUE4gb3NzaWZpY2F0 aW9uLiBUaGUgd2F5IEkgc2VlIHRoYXQsIHRoZXJlIGlzIGhhcmRseSBhbnkgZGViYXRlLjxicj4N Cjxicj4NCi0tIENocmlzdGlhbiBIdWl0ZW1hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0133A4FC7160DA1FABAA291BB6F20CY4PR21MB0133namp_-- From nobody Fri Feb 9 12:24:26 2018 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 0E0D7126DFF for ; Fri, 9 Feb 2018 12:24:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.101 X-Spam-Level: ** X-Spam-Status: No, score=2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, 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 BIBTWttYfQEa for ; Fri, 9 Feb 2018 12:24:23 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3D91242F7 for ; Fri, 9 Feb 2018 12:24:23 -0800 (PST) Received: from mail-ot0-f169.google.com (mail-ot0-f169.google.com [74.125.82.169]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3E2C83A085 for ; Fri, 9 Feb 2018 15:24:21 -0500 (EST) Received: by mail-ot0-f169.google.com with SMTP id r23so8865464ote.8 for ; Fri, 09 Feb 2018 12:24:21 -0800 (PST) X-Gm-Message-State: APf1xPDcF8FSSUcdVco2gNYcK1euqxA3MDyDtXpsPhWirklx/iOuVSBn R9s7sp3WY72uCAQk/J/kWJFtseiMqmIA/5uL0CY= X-Google-Smtp-Source: AH8x225Ja0ETHyREdPLnbdjQKCg4tcdw4lWhzFEmn6PXe2A78s5pZ5pXXYIuCgicYvIqJMBYTppiQNat4t8ezGTWn7U= X-Received: by 10.157.62.89 with SMTP id h25mr3345360otg.282.1518207860888; Fri, 09 Feb 2018 12:24:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.95.80 with HTTP; Fri, 9 Feb 2018 12:24:20 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Fri, 9 Feb 2018 15:24:20 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: The Recovery Period To: Ian Swett Cc: Patrick McManus , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045e5dd43e5c420564cd50d5" 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, 09 Feb 2018 20:24:25 -0000 --f403045e5dd43e5c420564cd50d5 Content-Type: text/plain; charset="UTF-8" you're right - its ok. I missed the "when a larger" part (reading it as "when it is recovered"). --f403045e5dd43e5c420564cd50d5 Content-Type: text/html; charset="UTF-8"
you're right - its ok. I missed the "when a larger" part (reading it as "when it is recovered").
--f403045e5dd43e5c420564cd50d5-- From nobody Fri Feb 9 12:37:00 2018 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 4ED36126DFF for ; Fri, 9 Feb 2018 12:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 VBO0vLxhfT0Y for ; Fri, 9 Feb 2018 12:36:54 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 9367D1242F7 for ; Fri, 9 Feb 2018 12:36:54 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id g14so4823675iob.9 for ; Fri, 09 Feb 2018 12:36:54 -0800 (PST) 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=F4KTaBKTk3GzivVKribUenQ1bKqWFnbP6nXZfYVIsu8=; b=EPRywabj6VQ3R0SVe8AeXVpZdQ/qCSj/2iOFB6FLpgg7T0KSGT9saRrFKbA0RXtkzR WWdCcWS8p4AChuuX0gg8wg62a0fnWEaYqZAuPY4YUU/IL+B7GlaYRgxTksAqesP+Grrv MSHP3HGSG+oSoCvWLwodHNmasagRazJrBspVxP5qeCyqq/qQfIpevxP5nRU2ixY+io8X hJi1ZCMmviVLILK+ePjWk23NNNBMxEIAN2CbBB3oP8BubJ9PYEqMEUgDNCufzUu/ZhJU WaV9UZ0YMVDvyLyXXqVWQKjvXTsYd95oxSBumMgBXNgVEdZ95jqLrPC2iYZGdj1Lfv0Z PiOA== 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=F4KTaBKTk3GzivVKribUenQ1bKqWFnbP6nXZfYVIsu8=; b=OLaennVwt5EbSr1LfH2hiGLiwgHdZuFqCKbG/q4l1MZ0tpJZEX3NsIKGAw7shIESk0 8JMBzDVYvGgrExDg3o+2vBcoeQMh2q4ATvxCsZGTBSUggvwdy2JhPGOdNAYwFlnt/TfT 0Scp3lxJkHESEDC7GhYn7izKecbkmXjRvlNRMe4/1zNrHJt5J4mHBkRObQIvwJ+rsK2r NQBXGzH6aWHIO38CfrHV8fV8mR+BvkRw8AWXe3GBfX8A2VTCWNaQ6xrrvqpLUF+Jv5Q3 Vq0NV4oxkd4kSCoHco7mNj7F9dERbqejUS5/E1tu5sVgEYujLHwq/hYW0pfmMwHjMzpt 3XYA== X-Gm-Message-State: APf1xPAkupD75X/pkURlxGnCIgaE8J+d9+gBWYBtnU/AG12Mire64+PD YdY/9yFUVclMmA1Yac+JzJBoz3/HXfv0OKWcsKbf X-Google-Smtp-Source: AH8x227pN5IrnEnhpMLKFhqdGMzbAgVzBZnx/xdexJIGxryfwqKsCZcrjGSQeMyiUZZEOopkn1OnGu+ohd4/E4aboaE= X-Received: by 10.107.167.136 with SMTP id q130mr4551258ioe.173.1518208613292; Fri, 09 Feb 2018 12:36:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.176.207 with HTTP; Fri, 9 Feb 2018 12:36:32 -0800 (PST) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Fri, 9 Feb 2018 12:36:32 -0800 Message-ID: Subject: Re: Review of QCRAM To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a1142340217d02e0564cd7dc9" 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, 09 Feb 2018 20:36:58 -0000 --001a1142340217d02e0564cd7dc9 Content-Type: text/plain; charset="UTF-8" Some comments below, but *tldr;* Sorry for crossed wires, but I think much of what you raise is addressed in 3.2 , 3.3 and 4.2 of the editor's copy (changes were announced on this list ). On Fri, Feb 9, 2018 at 2:08 AM, Martin Thomson wrote: > I have implemented QCRAM and have a few things to comment on. > > My implementation is here: > https://github.com/martinthomson/minhq/tree/master/hc > > This is my first attempt at go, so this took a little longer than it might > have > otherwise. Test coverage is still a little light, though go thinks that I > have > pretty good coverage. There's probably still a lot to go on the corner > cases, > but I think that I've done enough to get an idea for the complexity bump. > > I started by implementing HPACK, which is surprisingly easy if you don't > care > about being efficient. Though I knew that I was going to add QCRAM, I made > only > minimal design concessions when building HPACK. > > Building QCRAM on top of HPACK took at least 50% more than just doing > HPACK (at > a guess, HPACK took about 10-12 hours, QCRAM took closer to 20). Even > though > you can reuse Huffman coding and most of the primitives, retrofitting it > was > tricky. My lack of familiarity with go definitely contributed a lot to > that, > but I'd say that QCRAM is more difficult to implement than it seems in > theory. > > I didn't implement QCRAM entirely as specified. There are a few things that > I'll describe below that would make it either better or easier to > implement (or > both). > > > # Separate Stream Roles > > There are actually three streams of data that are of interest, and there > is no > clarity about those streams. > > 1. I suggest that we use unidirectional streams in each direction for table > updates. > 2. A separate stream for acknowledgments ensures that the encoder can > consume > that separately to the decoder. > I have a hard time seeing a practical difference, but sure. > > 3. Request/response streams. I think that we all understand these. > > These can be separate from the hq control stream, and they should be. > Rather > than pick a specific stream number, we should add a header for these > streams > that will allow them to be identified clearly. If we do that, add strict > rules > about cardinality. > > > # Define Framing More Clearly > > The definition of the framing that is used on the control stream is > unclear. I > assume that the intent is to use HEADERS frames, but I'm only really > guessing. > If you take my suggestion for separate framing, then you can use very > different > logic for the different streams. > > Honestly, the overhead of framing is excessive for anything but > request/response streams. I found that framing on the control stream wasn't > necessary at all. This might depend on implementation strategy, because it > might be easier to collect a framed thing than it is to read until you are > blocked, then pickle that state so that you can go back to something else. > In > my implementation I hold state on the stack, so it's pretty easy. > > Also, it should suffice to have just a stream of varints indicating > acknowledgments. Duplicates can be used to acknowledge multiple header > blocks > on the same stream in order. > > # Split the Instruction Space > > Having to check that only certain instructions appear on different streams > is > annoying to implement and a waste of bits. Define two separate spaces. That > should make things much simpler: there are exactly two instructions in each > space then (leaving aside acknowledgments, which I will cover below). > > # Base in Every HEADERS Frame > > Base (the number of inserts in the table at the start of a header block) > seems > to be required for all HEADERS frames, including both table modification > and > request/response streams. But... > > FWIW, in the editor's copy there was already a change that the prefix is only for request-response streams (see 3.2 and 3.3 ) > # Base on the Table Update Stream > > You don't need base for table updates. It is more of a hazard than a help. > It > is easier if you treat indexing on the table update stream as in HPACK > where > each insert moves the reference point for the next insertion. > Yep, see above. > > # Remove BLOCKING > > The BLOCKING flag complicates the design unnecessarily. As a fixed > overhead, > pay the extra byte always. I disagree. Fixed overheads in every header block do really hurt. Close to 1% per byte. Since blocking is less than 10% of blocks, I think your proposal is a material waste. > Furthermore, the table update stream will never need > to use depends, so that further motivates having different instruction sets > (and formats) for different streams. And you don't need it... > > This is true, and was already addressed as mentioned above. > # Base and the Static Table > > It is not explained at all that the base is applied to the dynamic table > only. > afrind@ pointed this out Jan. 24 in a design committee thread (About simplifying QCRAM further.) The editors copy had significant work to try and clarify these points. Again sections 3.2 and 3.3. Also in response to earlier feedback, Section 4.2 , has a lot of new implementation guidance. > That is, index 1 is a straight index into the static table and that index > 62 > will use the current number of inserts and the base to determine the actual > index into the dynamic table (this is the first table entry only when the > number of table inserts and base are the same, if the base is smaller, > then it > will be further along the table). > > To be clear, my logic for finding entries is: > > if i == 0: error > if i <= len(staticTable): return staticTable[i-1] > delta = tableBase - base > if delta < 0: error > return dynamicTable[i - len(staticTable) - 1 + delta] > > # Remove Depends > > Depends is useless. I did not implement it. Base is sufficient. > > This follows from preferring to use the smallest value for base possible. > Doing > that also keeps table references as small as possible. (Because references > are > counted in the opposite direction to base, a larger base means larger > references.) > > The cost is that you have to do a two pass check: the first to find the > newest > reference, the second to write out the header block. I find that it's > basically > necessary to do two passes anyway: on the first I write out the table > updates, > on the second I write the header block. During that phase you want to do > lookups anyway, so you can save the largest base from that pass. Also, > when you > insert anything, that tends to set the base, so it's pretty easy overall. > It's a nit, but in my proxygen prototype , I didn't have to do two passes, partly because FB's IOBuf abstraction has powerful abilities to prepend prefixes to an existing buf, avoiding the need for two pass logic. > > # Tracking ACKs is Harder Than It Seems > > There are multiple header blocks per stream, and ACKs only identify the > stream. > You can't just store a stream reference (or Request-ID) against each header > block, you have to store a tuple of stream and header block index. This > needs > to be explained somewhere. > See above, I think the new stuff in Section 4.2 covers this. > > I decided to externalize ACKs - the QCRAM encoder takes a generic blob as > input > when it encodes a header block and the same generic blob to acknowledge > it. The > caller then has to combine stream ID and header block index in a sensible > fashion. > > # Acknowledge Dmitry > > So I don't forget... Dmitry did a lot of work on the design team. > Already done in the editor's copy. > > # Dynamic Table Overhead > > The draft has a TODO about overhead for each dynamic entry. I added a > field to > every entry that allows it to know its own position in the table, but that > is a > simplification/optimization, and you don't really need that. The other > per-record overheads are all the same for the decoder, with a small > increase to > the fixed overhead. It's a little more state for an encoder, but that is > mostly > because of having to track usage. > > I don't think that we need to change from a 32 byte overhead. This decision > could reduce code complexity in shared QCRAM/HPACK implementations (in my > implementation it would).Section 4.2 > > # Duplication Doesn't Need to Reference the Static Table > > Duplication only makes sense for dynamic entries and yet the index is (I > assume), the normal table index. That is highly suboptimal. This is worse > because the prefix is only 5 bits for this instruction (up to 62 values), > which > leads to the encoding taking an extra byte always. If you take my > suggestion > for separate instruction spaces, this is better, but still not as good as a > direct index into the dynamic table, starting at 0. Better yet would be a > reverse index, starting from the end of the table, because duplication > often > needs to refer to the end of the table. > > # Need Better Advice on Referencing strategy > > Referencing entries near the end of the table in a new header block is > hazardous. If you just compress as you do in HPACK, you can end up pinning > entries in the header table, making it impossible to add new entries. > Thus, you > have to stop referencing entries as they get nearer to the table capacity > limit. > > In my implementation I added a threshold variable that governs my > referencing > strategy. A portion of the header table space is marked as being > off-limits for > header block usage. The encoder duplicates those entries if it wants to > compress, but won't reference them. If the table is under pressure from > the new > header fields being added, then it should be able to advance by at least > this > amount every round trip. > > This is a simple strategy, and probably suboptimal in various ways, but it > seems to work out. For instance, I continuously update the cutoff as > entries > are inserted, so that a header block might end up referencing things that > get > pushed into this space by later header fields. > > You can imagine more advanced techniques. For instance, you might tune this > window automatically based on the rate that the header table grows. Because > references in that window block eviction, it should be sized to the rate of > *desired* growth in the header table over a round trip. Taking a running > estimate of that desired growth and allowing a margin for variance could > produce the right value. I haven't experimented with this. > > -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a1142340217d02e0564cd7dc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some comments below, but=C2=A0

tldr;= =C2=A0=C2=A0Sorry for crossed wires, but I th= ink much of what you raise is addressed in=C2=A03.2,=C2=A03.3=C2=A0 and=C2=A04.2=C2=A0of the editor's copy (changes=C2=A0were announced on this list).

On Fri, Feb 9, 2018 at 2:08 AM, M= artin Thomson <martin.thomson@gmail.com> wrote:
I have implemented QCRAM an= d have a few things to comment on.

My implementation is here:
=C2=A0 https://github.com/martinthomson/mi= nhq/tree/master/hc

This is my first attempt at go, so this took a little longer than it might = have
otherwise. Test coverage is still a little light, though go thinks that I h= ave
pretty good coverage. There's probably still a lot to go on the corner = cases,
but I think that I've done enough to get an idea for the complexity bum= p.

I started by implementing HPACK, which is surprisingly easy if you don'= t care
about being efficient. Though I knew that I was going to add QCRAM, I made = only
minimal design concessions when building HPACK.

Building QCRAM on top of HPACK took at least 50% more than just doing HPACK= (at
a guess, HPACK took about 10-12 hours, QCRAM took closer to 20). Even thoug= h
you can reuse Huffman coding and most of the primitives, retrofitting it wa= s
tricky. My lack of familiarity with go definitely contributed a lot to that= ,
but I'd say that QCRAM is more difficult to implement than it seems in = theory.

I didn't implement QCRAM entirely as specified. There are a few things = that
I'll describe below that would make it either better or easier to imple= ment (or
both).


# Separate Stream Roles

There are actually three streams of data that are of interest, and there is= no
clarity about those streams.

1. I suggest that we use unidirectional streams in each direction for table=
updates.=C2=A0
=C2=A0
2. A separate stream for acknowledgments ensures that the encoder can consu= me
that separately to the decoder.

I have = a hard time seeing a practical difference, but sure.
=C2=A0
=

3. Request/response streams. I think that we all understand these.

These can be separate from the hq control stream, and they should be. Rathe= r
than pick a specific stream number, we should add a header for these stream= s
that will allow them to be identified clearly. If we do that, add strict ru= les
about cardinality.

=C2=A0

# Define Framing More Clearly

The definition of the framing that is used on the control stream is unclear= . I
assume that the intent is to use HEADERS frames, but I'm only really gu= essing.
If you take my suggestion for separate framing, then you can use very diffe= rent
logic for the different streams.

Honestly, the overhead of framing is excessive for anything but
request/response streams. I found that framing on the control stream wasn&#= 39;t
necessary at all. This might depend on implementation strategy, because it<= br> might be easier to collect a framed thing than it is to read until you are<= br> blocked, then pickle that state so that you can go back to something else. = In
my implementation I hold state on the stack, so it's pretty easy.

Also, it should suffice to have just a stream of varints indicating
acknowledgments. Duplicates can be used to acknowledge multiple header bloc= ks
on the same stream in order.

# Split the Instruction Space

Having to check that only certain instructions appear on different streams = is
annoying to implement and a waste of bits. Define two separate spaces. That=
should make things much simpler: there are exactly two instructions in each=
space then (leaving aside acknowledgments, which I will cover below).

# Base in Every HEADERS Frame

Base (the number of inserts in the table at the start of a header block) se= ems
to be required for all HEADERS frames, including both table modification an= d
request/response streams.=C2=A0 But...


FWIW, in the editor's copy there w= as already a change that the prefix is only for request-response streams (s= ee=C2=A03.2=C2=A0and=C2=A03.3)
=C2=A0
# Base on the Table Update Stream

You don't need base for table updates. It is more of a hazard than a he= lp. It
is easier if you treat indexing on the table update stream as in HPACK wher= e
each insert moves the reference point for the next insertion.

Yep, see above.
=C2=A0

# Remove BLOCKING

The BLOCKING flag complicates the design unnecessarily. As a fixed overhead= ,
pay the extra byte always.

I disagree.=C2= =A0 Fixed overheads in every header block do really hurt.=C2=A0 =C2=A0Close= to 1% per byte.=C2=A0 =C2=A0Since blocking is less than 10% of blocks, I t= hink your proposal is a material waste.=C2=A0

=C2= =A0
Furthermore, the= table update stream will never need
to use depends, so that further motivates having different instruction sets=
(and formats) for different streams.=C2=A0 And you don't need it...

This is true, and was already addressed as mentioned = above.

=C2=A0
# Base and the Static Table

It is not explained at all that the base is applied to the dynamic table on= ly.

afrind@ pointed this out Jan. 24 in= a design committee thread (About simplifying QCRAM further.)=C2=A0 =C2=A0 = The editors copy had significant work to try and clarify these points.=C2= =A0 =C2=A0Again sections 3.2 and 3.3.=C2=A0 Also in response to earlier fee= dback,=C2=A0Section 4.2, has a lot of ne= w implementation guidance.

=C2=A0
That is, index 1 is a straight index into the static table and that index 6= 2
will use the current number of inserts and the base to determine the actual=
index into the dynamic table (this is the first table entry only when the number of table inserts and base are the same, if the base is smaller, then= it
will be further along the table).

To be clear, my logic for finding entries is:

=C2=A0 =C2=A0 if i =3D=3D 0: error
=C2=A0 =C2=A0 if i <=3D len(staticTable): return staticTable[i-1]
=C2=A0 =C2=A0 delta =3D tableBase - base
=C2=A0 =C2=A0 if delta < 0: error
=C2=A0 =C2=A0 return dynamicTable[i - len(staticTable) - 1 + delta]

# Remove Depends

Depends is useless. I did not implement it. Base is sufficient.

This follows from preferring to use the smallest value for base possible. D= oing
that also keeps table references as small as possible. (Because references = are
counted in the opposite direction to base, a larger base means larger
references.)

The cost is that you have to do a two pass check: the first to find the new= est
reference, the second to write out the header block. I find that it's b= asically
necessary to do two passes anyway: on the first I write out the table updat= es,
on the second I write the header block. During that phase you want to do lookups anyway, so you can save the largest base from that pass. Also, when= you
insert anything, that tends to set the base, so it's pretty easy overal= l.

It's a nit, but in my proxygen prototype, I didn't h= ave to do two passes, partly because FB's IOBuf abstraction has powerfu= l abilities to prepend prefixes to an existing buf, avoiding the need for t= wo pass logic.
=C2=A0

# Tracking ACKs is Harder Than It Seems

There are multiple header blocks per stream, and ACKs only identify the str= eam.
You can't just store a stream reference (or Request-ID) against each he= ader
block, you have to store a tuple of stream and header block index. This nee= ds
to be explained somewhere.

See above, I= think the new stuff in=C2=A0Secti= on 4.2=C2=A0covers this.

=C2=A0

I decided to externalize ACKs - the QCRAM encoder takes a generic blob as i= nput
when it encodes a header block and the same generic blob to acknowledge it.= The
caller then has to combine stream ID and header block index in a sensible fashion.

# Acknowledge Dmitry

So I don't forget... Dmitry did a lot of work on the design team.

Already done in the editor's copy.
=
=C2=A0

# Dynamic Table Overhead

The draft has a TODO about overhead for each dynamic entry. I added a field= to
every entry that allows it to know its own position in the table, but that = is a
simplification/optimization, and you don't really need that. The other<= br> per-record overheads are all the same for the decoder, with a small increas= e to
the fixed overhead. It's a little more state for an encoder, but that i= s mostly
because of having to track usage.

I don't think that we need to change from a 32 byte overhead. This deci= sion
could reduce code complexity in shared QCRAM/HPACK implementations (in my implementation it would).Section 4.2

# Duplication Doesn't Need to Reference the Static Table

Duplication only makes sense for dynamic entries and yet the index is (I assume), the normal table index. That is highly suboptimal. This is worse because the prefix is only 5 bits for this instruction (up to 62 values), w= hich
leads to the encoding taking an extra byte always. If you take my suggestio= n
for separate instruction spaces, this is better, but still not as good as a=
direct index into the dynamic table, starting at 0. Better yet would be a reverse index, starting from the end of the table, because duplication ofte= n
needs to refer to the end of the table.

# Need Better Advice on Referencing strategy

Referencing entries near the end of the table in a new header block is
hazardous. If you just compress as you do in HPACK, you can end up pinning<= br> entries in the header table, making it impossible to add new entries. Thus,= you
have to stop referencing entries as they get nearer to the table capacity limit.

In my implementation I added a threshold variable that governs my referenci= ng
strategy. A portion of the header table space is marked as being off-limits= for
header block usage. The encoder duplicates those entries if it wants to
compress, but won't reference them. If the table is under pressure from= the new
header fields being added, then it should be able to advance by at least th= is
amount every round trip.

This is a simple strategy, and probably suboptimal in various ways, but it<= br> seems to work out. For instance, I continuously update the cutoff as entrie= s
are inserted, so that a header block might end up referencing things that g= et
pushed into this space by later header fields.

You can imagine more advanced techniques. For instance, you might tune this=
window automatically based on the rate that the header table grows. Because=
references in that window block eviction, it should be sized to the rate of=
*desired* growth in the header table over a round trip. Taking a running estimate of that desired growth and allowing a margin for variance could produce the right value. I haven't experimented with this.




--
Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412= -1141

--001a1142340217d02e0564cd7dc9-- From nobody Fri Feb 9 12:55:30 2018 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 87B451267BB for ; Fri, 9 Feb 2018 12:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 K8lbqZvPtxFL for ; Fri, 9 Feb 2018 12:55:25 -0800 (PST) Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (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 C27D61242F7 for ; Fri, 9 Feb 2018 12:55:25 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2018 12:55:25 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos; i="5.46,485,1511856000"; d="scan'208,217"; a="16568014" Received: from orsmsx107.amr.corp.intel.com ([10.22.240.5]) by orsmga007.jf.intel.com with ESMTP; 09 Feb 2018 12:55:25 -0800 Received: from orsmsx158.amr.corp.intel.com (10.22.240.20) by ORSMSX107.amr.corp.intel.com (10.22.240.5) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 9 Feb 2018 12:55:24 -0800 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.253]) by ORSMSX158.amr.corp.intel.com ([169.254.10.162]) with mapi id 14.03.0319.002; Fri, 9 Feb 2018 12:55:24 -0800 From: "Deval, Manasi" To: Praveen Balasubramanian , David Benjamin CC: Eric Rescorla , "quic@ietf.org" , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW386uUhPOthz0i/5zfm2bWSLKONB2AAgABeoYCAAAgUAIAAd3OAgAA8YgCAACPDAIAAAicAgAOBlYCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADXOQCAAGavgIAAEEkAgACiywCAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5pAIAAEIAAgABFkgCAAAUSgIAABUkAgAABmYCAAAaRgIAAC4qAgACi8QCAAe5xgIAACzgAgAAgsQCAAEAQAIAAiWOAgAA/NgCAACHJgIAABYAA//+Ja8A= Date: Fri, 9 Feb 2018 20:55:24 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B58BAD7@ORSMSX111.amr.corp.intel.com> References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B58BAD7ORSMSX111amrcor_" 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: Fri, 09 Feb 2018 20:55:29 -0000 --_000_1F436ED13A22A246A59CA374CBC543998B58BAD7ORSMSX111amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29pbmcgYmFjayB0byBJYW7igJlzIHBvaW50IGhlcmUg4oCTIENhbiB5b3UgYmUgZXhwbGljaXQg YWJvdXQgdGhlIGlzc3VlIHlvdSBzZWUgaW4gdGhlIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbj8N Cg0KVGhhbmtzLA0KTWFuYXNpDQoNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuDQpTZW50OiBGcmlk YXksIEZlYnJ1YXJ5IDA5LCAyMDE4IDExOjU5IEFNDQpUbzogRGF2aWQgQmVuamFtaW4gPGRhdmlk YmVuQGNocm9taXVtLm9yZz4NCkNjOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBxdWlj QGlldGYub3JnOyBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KU3ViamVjdDogUkU6IFBh Y2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpXaXRoIFZMRSBpdHMgbWluaW1hbCBvdmVyaGVhZCBw ZXIgcGFja2V0IHNvIHlvdSBhcmUgbm90IGVuY3J5cHRpbmcgNCBieXRlcyBtb3JlIGFsbCB0aGUg dGltZSBldmVuIHdpdGggNjQgYml0IG9yIDEyOCBiaXQgcGFja2V0IG51bWJlciAuIFNvIGl0cyBk ZWNpZGVkbHkgYmV0dGVyLiBBbHNvIGZld2VyIGNhbGxzIGludG8gVExTLCBidXQgSSBzdXBwb3Nl IG9uZSBjb3VsZCBkbyBzb21lIHJlZmFjdG9yaW5nIG9mIFRMUyBBUEkuIE1hbnkgQ1BVcyB5ZXMg YnV0IHRoaXMgaXMgYSBnZW5lcmFsIHB1cnBvc2UgdHJhbnNwb3J0IGFuZCBjb3VsZCBydW4gb24g Q1BVcyB0aGF0IGRvbuKAmXQuDQoNCkRpZG7igJl0IGFzayBmb3Igbm9uY2UgdG8gYmUgdmFyaWFi bGUgbGVuZ3RoLiBGaXhlZCBsZW5ndGggZm9yIGNvbm5lY3Rpb24gbGlmZXRpbWUuIERhdGFjZW50 ZXJzIGNvbm5lY3Rpb25zIGNvdWxkIHVzZSA2NC1iaXQgbm9uY2UgdG8gYXZvaWQgZnJlcXVlbnQg a2V5IHJvbGxvdmVyLg0KDQpFZmZlY3RpdmVseSB0aGUgcGxhaW4gdGV4dCBub25jZSBpcyBhIHNl cXVlbmNlIG51bWJlciBzaW5jZSBpdCBpbmNyZWFzZXMgbW9ub3RvbmljYWxseSB3aXRoIHNtYWxs IGp1bXBzIGFzIG5lZWRlZCB0byBhdm9pZCBvc3NpZmljYXRpb24uIFNvIG5vIHdvcnNlIG9mZiB0 aGFuIGdRVUlDIG9yIGN1cnJlbnQgZHJhZnQuIE5vIG1vcmUgY29tcGxleCB0aGFuIHVzaW5nIHRo ZSBwYWNrZXQgbnVtYmVyLiBKdXN0IHRoZSBzdGFydGluZyBudW1iZXIgaXMgcmFuZG9taXplZC4g QWxzbyBwbGVhc2Ugbm90aWNlIHRoYXQgdGhpcyBwcm9wb3NhbCBkb2VzIG5vdCBwcmVjbHVkZSB1 c2luZyBlbmNyeXB0ZWQgcGFja2V0IG51bWJlciBhcyB0aGUgbm9uY2UgYXMgcHJvcG9zZWQgcHJl dmlvdXNseS4gQ2hhbmdpbmcgaG93IHRoZSBub25jZSB3b3JrcyBtYWtlcyAwIGltcGFjdCBvbiB0 aGUgdHJhbnNwb3J0IGxvZ2ljLiBBbiBpbXBsZW1lbnRhdGlvbiBjYW4gY2hvb3NlIHRvIGltcGxl bWVudCBhbnkgZm9ybSBvZiBub24tcmVwZWF0aW5nIG5vbmNlIHdpdGhvdXQgcmV2dmluZyB0aGUg UkZDLiBUaGlzIGlzIHRoZSBiaWdnZXN0IGFkdmFudGFnZSBvZiBzZXBhcmF0aW9uIG9mIGNvbmNl cm5zIElNSE8uDQoNCkZyb206IERhdmlkIEJlbmphbWluIFttYWlsdG86ZGF2aWRiZW5AY2hyb21p dW0ub3JnXQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSA5LCAyMDE4IDExOjM5IEFNDQpUbzogUHJh dmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+DQpDYzogRXJpYyBSZXNj b3JsYSA8ZWtyQHJ0Zm0uY29tPjsgcXVpY0BpZXRmLm9yZzsgaHVpdGVtYSA8aHVpdGVtYUBodWl0 ZW1hLm5ldD4NClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KWW91ciBw cmltYXJ5IHdvcnJ5IGhlcmUgd2FzIHRoZSBleHRyYSBibG9jayBjaXBoZXIgb3BlcmF0aW9uLCBy aWdodD8gQnkgbW92aW5nIHRoZSBwYWNrZXQgbnVtYmVyIGludG8gdGhlIHBsYWludGV4dCwgdGhp cyBwcm9wb3NhbCBpbmNyZWFzZXMgdGhlIGxlbmd0aCwgd2hpY2ggd2lsbCBjb3N0IHRoYXQgc2Ft ZSBvbmUgZXh0cmEgYmxvY2sgY2lwaGVyIG9wZXJhdGlvbiwgbm8/DQoNCkl0IGlzIG9uZSBibG9j ayBvcGVyYXRpb24gdW5kZXIgdGhlIHNhbWUga2V5LCByYXRoZXIgdGhhbiBhIGRpZmZlcmVudCBr ZXkgc28gSSBzdXBwb3NlIHRoZXJlIGFyZSBtaW51c2N1bGUgY2FjaGUgZm9vdHByaW50IHdpbnMg KG9uZSBzeW1tZXRyaWMga2V5IGlzIDE2IG9yIDMyIGJ5dGVzKS4gQnV0IHRoZSBjb3N0IGlzIHBl ci1wYWNrZXQgKCEpIGJhbmR3aWR0aCBhbmQgY29tcGxleGl0eS4gSSBkbyBub3Qgc2VlIGhvdyB0 aGlzIGNvdWxkIGJlIHdvcnRoIGl0LiBOb3RlIHRoYXQsIGZvciBBRVMsIG1hbnkgQ1BVcyBoYXZl IGRlZGljYXRlZCBpbnN0cnVjdGlvbnMgZm9yIGl0IGFscmVhZHkuDQoNCj4gQ2xlYXIgc2VwYXJh dGlvbiBvZiBjb25jZXJucyByZXN1bHRzIGlmIHdlIGRvbuKAmXQgb3ZlcmxvYWQgdGhlIHBhY2tl dCBudW1iZXIgYXMgdGhlIG5vbmNlLiBDb25uZWN0aW9uIG1pZ3JhdGlvbiBhbmQgbXVsdGktcGF0 aCBhcmUgb3B0aW9uYWwgZmVhdHVyZXMgYW5kIHdlIHBheSBubyBleHRyYSBjb21wdXRlIGNvc3Qg Zm9yIG1vc3QgY29ubmVjdGlvbnMgdGhhdCBhcmUgbm90IGltcGFjdGVkIGJ5IHVubG5rYWJpbGl0 eS4gTm9uY2UgZmllbGQgYmVjb21lcyBvcHRpb25hbCBmb3IgY3J5cHRvIHRoYXQgZG9lc27igJl0 IG5lZWQgaXQgYW5kIGNhbiBncm93IHRvIGxhcmdlciBzaXplIGFzIG5lZWRlZCBmb3IgYnVsayB0 cmFuc2ZlcnMgdG8gcHJldmVudCBmcmVxdWVudCBrZXkgcm9sbG92ZXJzIChzYXkgaW4gZGF0YWNl bnRlciBzY2VuYXJpb3MpLg0KDQpZb3UncmUgbm90IGdvaW5nIHRvIGZpbmQgQUVBRHMgdGhhdCBk b24ndCByZXF1aXJlIGEgbm9uY2UuIEVuY3J5cHRpb24gbXVzdCBub3QgcHJvZHVjZSB0aGUgc2Ft ZSBjaXBoZXJ0ZXh0IHR3aWNlIGZvciB0aGUgc2FtZSBwbGFpbnRleHQsIHNvIHlvdSBuZWVkIHNv bWUgaW5wdXQgdG8gZGl2ZXJzaWZ5IHRoZW0uIFRoYXQgaW5wdXQgaXMgdGhlIG5vbmNlLiBOb25j ZXMgYWxzbyBhcmUgbm90IHZhcmlhYmxlLWxlbmd0aCwgc28geW91IGRvbid0IGdldCB0byBhcmJp dHJhcmlseSBncm93IHRoZW0uIChBRVMtR0NNIHBlciBzcGVjIGlzIHZhcmlhYmxlIGxlbmd0aCwg YnV0IHRoYXQncyBhIHNwZWMgYnVnLiBJZiB5b3Ugc2l6ZSBpdCBhYm92ZSA5NiBiaXRzLCBpdCdz IGFzIGlmIHlvdSByYW5kb21pemVkIGl0IGFuZCB5b3VyIG5vbmNlIHNwYWNlIGNyYXNoZXMgcGVy IGJpcnRoZGF5LikNCg0KSXQgaXMgYWxzbyBoYXJtZnVsIHRvIHNlcGFyYXRlIHRoZSB0d28gY29u Y2VybnMuIFdoZW4geW91IGFyZSBidWlsZGluZyBhIHRyYW5zcG9ydCwgZGVyaXZlIHRoZSBub25j ZSBmcm9tIGEgc2VxdWVuY2UgbnVtYmVyLiBUTFMgMS4yIEFFUy1HQ00gc2VwYXJhdGVkIHRoZW0s IHdoaWNoIHdhcyBhIG1pc3Rha2UuIEl0J3MgbGVzcyBlZmZpY2llbnQgKHRoZSB3b3JsZCB3YXN0 ZWQgcXVpdGUgYSBsb3Qgb2YgYmFuZHdpZHRoIGR1ZSB0byB0aGlzKSwgYW5kIG1vcmUgZXJyb3It cHJvbmUuIFRoZXJlIHdhcyBub3RoaW5nIHN0b3BwaW5nIGltcGxlbWVudGF0aW9ucyBmcm9tIHNl bmRpbmcgdGhlIHNhbWUgbm9uY2Ugb3IgZ2VuZXJhdGluZyBub25jZXMgcmFuZG9tbHkgKHRoZSBB RUFEcyB3ZSB1c2UgZG9uJ3QgaGF2ZSBsYXJnZSBlbm91Z2ggbm9uY2VzIGZvciB0aGF0KSwgYW5k IGluZGVlZCBzb21lIGRpZCBqdXN0IHRoYXQuIElmIHlvdSB1c2Ugc29tZSBzb3J0IG9mIHNlcXVl bmNlIG51bWJlciwgeW91IGNhbiBsZWFuIG9uIGV4aXN0aW5nIHdvcmsgYm90aCB0byBmaWx0ZXIg b3V0IHRoZSBvYnZpb3VzIGltcGxlbWVudGF0aW9uIG1pc3Rha2VzIGFuZCB0byBhdm9pZCBzZW5k aW5nIHVubmVjZXNzYXJ5IGRhdGEuDQoNCk9uIEZyaSwgRmViIDksIDIwMTggYXQgMTI6MzggUE0g UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZi QG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCkxldCBtZSB0cnkgdG8gc3VtbWFyaXplIHRoZSBwcm9w b3NhbCBhZ2FpbjoNCg0KDQogIDEuICBQYWNrZXQgbnVtYmVyIGlzIGluIHRoZSBlbmNyeXB0ZWQg cG9ydGlvbiBvZiB0aGUgaGVhZGVyIGFuZCBpcyBubyBsb25nZXIgdXNlZCBhcyB0aGUgbm9uY2Uu IEl0IGlzIGVuY29kZWQgYXMgYSB2YXJpYWJsZSBsZW5ndGggbnVtYmVyLiBBbHdheXMgc3RhcnRz IGF0IDAuDQoNCiAgICAgKiAgIE5vIG9zc2lmaWNhdGlvbiBvZiBQTg0KICAgICAqICAgTm8gbGlu a2FiaWxpdHkgdXNpbmcgUE4NCiAgICAgKiAgIEFsbG93cyBmb3IgZ3Jvd3RoIGJleW9uZCA2NCBi aXRzIGlmIG5lZWRlZCBpbiBmdXR1cmUNCg0KICAxLiAgVGhlIG5vbmNlIGlzIGluIHRoZSBjbGVh ciBpbiBwbGFpbnRleHQgaGVhZGVyLiBJdCBpcyBnZW5lcmF0ZWQgcGVyIHBhdGggYXMgYSBzZWN1 cmUgcmFuZG9tIG51bWJlci4gQ2FsbCB0aGlzIHRoZSDigJxzdGFydGluZyB2YWx1ZeKAnS4gQm90 aCBzaWRlcyBNVVNUIGluaXRpYWxpemUgdGhlIOKAnHN0YXJ0aW5nIHZhbHVl4oCdIG5vbmNlIHBl ciBwYXRoLiBXaXRoaW4gYSBwYXRoIGl0IGdyb3dzIG1vbm90b25pY2FsbHkgKHRvIGF2b2lkIHJl cGVhdHMganVzdCBsaWtlIFBOIHRvZGF5KSBhbmQgY2FuIGluY2x1ZGUgc2hvcnQgcmFuZG9tIGp1 bXBzIHBlcmlvZGljYWxseSBzbyB0aGF0IG1pZGRsZWJveGVzIGNhbm5vdCBhc3N1bWUgYW55dGhp bmcgYWJvdXQgdGhlIGZpZWxkLiBTaW5jZSBub25jZSBoYXMgbm90aGluZyB0byBkbyB3aXRoIFBO IHRoZSBqdW1wcyBkb27igJl0IGFkZCBhbnkgY29tcGxleGl0eSB0byB0cmFuc3BvcnQgbG9naWMu IEp1bXBzIGFyZSBmb3IgZ3JlYXNpbmcgYW5kIHByZXZlbnRpbmcgb3NzaWZpY2F0aW9uLiBXaGVu IHRoZSBub25jZSByb2xscyBvdmVyIGFuZCByZWFjaGVzIGNsb3NlIHRvIHRoZSDigJxzdGFydGlu ZyB2YWx1ZeKAnSwga2V5IHJvbGxvdmVyIG11c3QgaGFwcGVuLiBBdCBoaWdoIGRhdGEgcmF0ZXMg dGhlIG5vbmNlIGZpZWxkIGNhbiBiZSA2NC1iaXRzIHRvIHByZXZlbnQgZnJlcXVlbnQga2V5IHJv bGxvdmVyLiBGb3IgY3J5cHRvIHRoYXQgZG9lc27igJl0IG5lZWQgbm9uY2VzLCB0aGUgZmllbGQg Y2FuIGJlIG9taXR0ZWQuDQoNCiAgICAgKiAgIE5vIG9zc2lmaWNhdGlvbiBiZWNhdXNlIHRoZXJl IGlzIG5vIHByZS1kZXRlcm1pbmVkIHNlcXVlbmNlIHRvIHRoZSBub25jZS4NCiAgICAgKiAgIElu IGdRVUlDIGFuZCB0aGUgUkZDIGFzIGRlZmluZWQgdGhlIG5vbmNlIGlzIGEgc2ltcGxlIHNlcXVl bmNlIHRoYXQgaW5jcmVtZW50cyBieSBvbmUsIHNvIHRoaXMgaXMgbm8gd29yc2Ugb2ZmIGluIHRl cm1zIG9mIHNlY3VyaXR5LiBJdCBpcyBub24tcmVwZWF0aW5nLg0KICAgICAqICAgTm8gbGlua2Fi aWxpdHkgYmVjYXVzZSBkaWZmZXJlbnQgcGF0aHMgc3RhcnQgYXQgYSBjb21wbGV0ZWx5IGRpZmZl cmVudCByYW5kb20gbnVtYmVyLiBJZiByZXBlYXRpbmcgaXMgYSBjb25jZXJuIHRoZW4gZGlmZmVy ZW50IHBhdGhzIHVzZSBkaWZmZXJlbnQga2V5cy4gQ2FycmllcyBmb3J3YXJkIHRvIG5vdCBqdXN0 IGNvbm5lY3Rpb24gbWlncmF0aW9uIGJ1dCBtdXRsaS1wYXRoLg0KICAgICAqICAgU3VwcG9ydHMg a2V5IHJvbGxvdmVyIGp1c3QgbGlrZSBnUVVJQyBhbmQgY3VycmVudGx5IGRlZmluZWQgZHJhZnQg UkZDLg0KICAgICAqICAgQWxsb3dzIGZvciBvbWl0dGluZyB0aGUgbm9uY2Ugd2hlbiB3ZSB1c2Ug Y3J5cHRvIHRoYXQgZG9lc27igJl0IG5lZWQgaXQuDQogICAgICogICBBbGxvd3MgZm9yIGxhcmdl ciBub25jZXMgZm9yIGhpZ2ggZGF0YSByYXRlcy4NCiAgICAgKiAgIEl0IGRvZXNu4oCZdCBwcmVj bHVkZSBhbnkgb3RoZXIgdHlwZSBvZiBub24tcmVwZWF0aW5nIG5vbmNlcyB3aXRob3V0IGhhdmlu ZyB0byBtb2RpZnkgdGhlIFJGQyEgU28gaW1wbGVtZW50YXRpb25zIHRoYXQgd2FudCB0byB1c2Ug Y3J5cHRvZ3JhcGhpYyBub25jZXMgY2FuIHN0aWxsIGRvIHNvLg0KDQpUaGUgZG93bnNpZGVzOg0K DQogIDEuICBFdmVuIHdpdGggdmFyaWFibGUgbGVuZ3RoIGVuY29kaW5nIHRoZSBleHRyYSBQTiBm aWVsZCBpcyBtb3JlIHNwYWNlIHVzZWQgcGVyIHBhY2tldCB3aGVuIGEgbm9uY2UgaXMgcmVxdWly ZWQuIEkgdGhpbmsgd2UgY2FuIGRvIHdpdGggMiBieXRlcyBpbiB2ZXJzaW9uIDEuDQogIDIuICBJ dOKAmXMgbm90IHBlcmZlY3QgdW5saW5rYWJpbHRpeSBidXQgSSBoYXZlIHlldCB0byBzZWUgYW55 IHNvbHV0aW9uIHRoYXQgY2FuIHByb3ZpZGUgdGhpcy4gQSBzaW1wbGUgdGltZSBiYXNlZCBhbmFs eXNpcyB1c2luZyBtYWNoaW5lIGxlYXJuaW5nIHdpbGwgYWxsb3cgZmxvdyBjb3JyZWxhdGlvbiBl c3BlY2lhbGx5IGZvciBjb25uZWN0aW9uIG1pZ3JhdGlvbi4gVGhlIElQIGFkZHJlc3NlcyBpbiB0 aGUgY2xlYXIgYWxsb3cgZm9yIGEgaGlnaCBkZWdyZWUgb2YgY29ycmVsYXRpb24uIFRoZXJlIGlz IGFsc28gdGhlIGFwcGxpY2F0aW9uIHNlbmRpbmcgcGF0dGVybiBhbmQgb3RoZXIgc2lnbmFscyB0 aGF0IGNvdWxkIGJlIHVzZWQuDQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRm bS5jb208bWFpbHRvOmVrckBydGZtLmNvbT5dDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDksIDIw MTggNTo1MiBBTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQu Y29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4NCkNjOiBodWl0ZW1hIDxodWl0ZW1hQGh1 aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj47IHF1aWNAaWV0Zi5vcmc8bWFp bHRvOnF1aWNAaWV0Zi5vcmc+DQoNClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRp b24NCg0KDQoNCk9uIFRodSwgRmViIDgsIDIwMTggYXQgOTo0MCBQTSwgUHJhdmVlbiBCYWxhc3Vi cmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb208bWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20+ PiB3cm90ZToNCkFjdHVhbGx5IHRha2luZyBhIHN0ZXAgYmFjayB3aGF0IGlmIHdlIGRvbuKAmXQg d2Ugb3ZlcmxvYWRlZCBwYWNrZXQgbnVtYmVyIGFzIHRoZSBub25jZT8NCg0KQ2FuIHdlOg0KDQog IDEuICBQdXQgcGFja2V0IG51bWJlciBhcyBhIHNlcGFyYXRlIHZhcmlhYmxlIGxlbmd0aCBmaWVs ZCBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhlYWRlci4gVGhpcyBhbGxvd3MgZm9y IGdyb3d0aCBiZXlvbmQgNjQgYml0cyBpbiBmdXR1cmUgYW5kIGNvbXBsZXRlbHkgYXZvaWRzIG9z c2lmaWNhdGlvbi4gRm9yIHNob3J0IGxpdmVkIGZsb3dzIHZhcmlhYmxlIGxlbmd0aCBlbmNvZGlu ZyBsZWFkcyB0byBtaW5pbWFsIHNwYWNlIG92ZXJoZWFkLg0KICAyLiAgUHV0IGEgc2VwYXJhdGUg cGxhaW50ZXh0IG5vbmNlIHdoaWNoIHN0YXJ0cyBvdXQgYXMgYSBzZWN1cmUgcmFuZG9tIG51bWJl ciBhbmQgbW9ub3RvbmljYWxseSBpbmNyZWFzZXMgYXMgc2hvcnQgcmFuZG9tIGp1bXBzIChldmVy eSBwYWNrZXQgb3IgZXZlcnkgZmV3IHBhY2tldHMpIGFuZCBjb3VsZCB0aGVuIHJvbGxvdmVyLiBU aGlzIHdpbGwgcHJldmVudCBsaW5rYWJpbGl0eSBhbmQgc2NhbGVzIHRvIG11bHRpLXBhdGggYXMg d2VsbC4gTm8gbWFqb3IgY29tcHV0ZSBvdmVyaGVhZC4gV2UgY2FuIGFsc28gbWFrZSB0aGUgbm9u Y2Ugb3B0aW9uYWwgZm9yIGNyeXB0byBhbGdvcml0aG1zIHRoYXQgZG8gbm90IG5lZWQgYSBub25j ZSBzYXZpbmcgbW9yZSBzcGFjZS4NCg0KSSdtIG5vdCBzdXJlIGhvdyB0byBkbyAjMiBzYWZlbHkg YW5kIGVmZmljaWVudGx5LiBUaGUgcHJpbWFyeSBjb25jZXJuIGlzIHRoYXQgc2hvcnQgcmFuZG9t IGp1bXBzIGRvbid0IGFjdHVhbGx5IHByZXZlbnQgbGlua2FiaWxpdHkgYmVjYXVzZSB0aGUgaGln aCBvcmRlciBiaXRzIGRvbid0IGNoYW5nZSBhbmQgbG9uZyByYW5kb20ganVtcHMgYXJlIGVmZmVj dGl2ZWx5IHJhbmRvbWx5IHNhbXBsaW5nIG91dCBvZiB0aGUgbm9uY2Ugc3BhY2UsIGFuZCB5b3Ug c3RhcnQgdG8gcnVuIGludG8gYmlydGhkYXkgcHJvYmxlbXMuIEFkZGl0aW9uYWxseSwgdGhlIGNo ZWFwZXN0IFBSTkdzIGFyZSBiYXNpY2FsbHkgY2lwaGVycyBpbiBjb3VudGVyIG1vZGUsIHNvIGF0 IGJlc3QgeW91J3JlIGdvaW5nIHRvIGdldCBhIHNtYWxsIGFtb3VudCBvZiBvdmVyaGVhZCByZWR1 Y3Rpb24gYnkgZ2V0dGluZyBtdWx0aXBsZSBqdW1wIGNvbXB1dGF0aW9ucyBvdXQgb2YgYSBzaW5n bGUgYmxvY2ssIHRob3VnaCBpZiB5b3UgdXNlIDk2LWJpdCBqdW1wcywgeW91IG9ubHkgZ2V0IDI1 JSBzYXZpbmdzLi4uDQoNCi1Fa3INCg0KDQoNClNvbWUgTVNCIG9mIHRoZSBub25jZSBjb3VsZCBi ZSB1c2VkIGZvciBzaWduYWxpbmcgcmVvcmRlciB0byB0aGUgbmV0d29yayBpZiBuZWVkZWQuIEkg ZG9u4oCZdCBoYXZlIHRoZSBoaXN0b3JpY2FsIGNvbnRleHQgZm9yIG92ZXJsb2FkaW5nIG9mIFBO IGFzIHRoZSBub25jZSBzbyBwYXJkb24gbWUgaWYgdW4tb3ZlcmxvYWRpbmcgb3B0aW9uIHdhcyBk aXNjdXNzZWQgYW5kIHJ1bGVkIG91dCBiZWZvcmUuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFs ZiBPZiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbg0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDgs IDIwMTggNTo1MSBQTQ0KVG86IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRvOmh1 aXRlbWFAaHVpdGVtYS5uZXQ+PjsgcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KPj4gYW5kIHVzaW5nIHNl cGFyYXRlIHBhY2tldCBzZXF1ZW5jZXMgZm9yIGVhY2ggcGF0aA0KVGhpcyBhbG9uZSBwcmV2ZW50 cyBsaW5rYWJpbGl0eSByaWdodD8NCg0KPj4gVGhlIHBhY2tldCBudW1iZXIgb24gZWFjaCBwYXRo IHdpbGwgc3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7LSkuDQpJcyBzdXBwb3J0aW5nIG11bHRpcGxl IHBhdGhzIGF0IHRoZSBzYW1lIHRpbWUgYSBnb2FsPyBJZiB5ZXMsIHRoZW4geWVzIGFsbCBwYXRo cyB3aWxsIG5lZWQgdG8gaGF2ZSBzZXBhcmF0ZSB0cmFja2luZyBhbmQgQUNLIHN0YXRlIGFuZCBj b25nZXN0aW9uIGNvbnRyb2wgZXRjLiBJIHRob3VnaHQgdGhpcyBpcyBub3QgcGFydCBvZiBWMSBS RkMuIElmIGl0cyBqdXN0IG9uZSBhZGRpdGlvbmFsIHBhdGggZm9yIGNvbm5lY3Rpb24gbWlncmF0 aW9uIHNjZW5hcmlvIHRoZW4gYWxsIHlvdSBuZWVkIGlzIGEgKHJhbmRvbSkganVtcCB0byBhIG9m ZnNldCBpbiBwYWNrZXQgbnVtYmVyIHNwYWNlIGZvciB0aGUgbmV3IHBhdGggc28gdGhhdCB0aGUg ZmV3IHBhY2tldHMgaW4gdGhlIG9sZCBwYXRoIGNhbiBjb250aW51ZSBmb3IgYSBsaXR0bGUgYml0 LiBUaGlzIHdvcmtzIHdpdGgganVzdCBvbmUgQUNLIHNwYWNlIHNvIG5vIGltcGxlbWVudGF0aW9u IGNvbXBsZXhpdHkuDQoNCj4+IDIpIE9yLCBsZWF2aW5nIHRoZSBwYWNrZXQgbnVtYmVyIGluIHRo ZSBjbGVhciBidXQgdXNpbmcgZGlmZmVyZW50IGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2gg cGF0aCwgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBzZXF1ZW5jZXMgZm9yIGVhY2ggcGF0aC4N CkluIGFkZGl0aW9uIGlmIHRoZSB2YWx1ZSBpbiB0aGUgY2xlYXIgd2FzIG9iZnVzY2F0ZWQgd2l0 aCBhbiBYT1IgdHJhbnNmb3JtIGl0IHdpbGwgaGVscCBwcmV2ZW50IG9zc2lmaWNhdGlvbi4gVGhl IG9iZnVzY2F0aW9uIGlzIG5vdCBtZWFudCB0byBndWFyZCBhZ2FpbnN0IGxhdGVyIGFuYWx5c2lz IHRoYXQgcmV2ZWFscyB0aGUgcGFja2V0IG51bWJlcnMgLSB3aHkgZG8gd2UgY2FyZSBhYm91dCB0 aGF0LiBJdCBpcyBtZWFudCB0byBncmVhc2UgdGhlIHNwYWNlIGFuZCBub3QgbWFrZSB0aGUgbnVt YmVycyBzZXJpYWwgc28gbWlkZGxlYm94ZXMgY2Fubm90IGFzc3VtZSBvcmRlcmluZyBldGMuDQoN CkFsbCBzYWlkIGlmIEkgYW0gYWxvbmUgaW4gYmVpbmcgY29uY2VybmVkIGFib3V0IHRoZSBwZXJm IGhpdCB0aGVuIEnigJlkIHNheSBnbyBvbiB3aXRoIG9wdGlvbiAxLg0KDQpGcm9tOiBRVUlDIFtt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0aWFuIEh1aXRl bWENClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDM6NTQgUE0NClRvOiBxdWljQGll dGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFBhY2tldCBudW1iZXIg ZW5jcnlwdGlvbg0KDQoNCk9uIDIvOC8yMDE4IDE6MTMgUE0sIE1pa2UgQmlzaG9wIHdyb3RlOg0K IzIgd29u4oCZdCB3b3JrLiAgVGhlIHBhY2tldCBudW1iZXIgaXMgYW4gaW5wdXQgdG8gdGhlIEFF QUQgbm9uY2UsIHNvIHlvdSBoYXZlIHRvIGdldCB0byB0aGUgcGFja2V0IG51bWJlciBiZWZvcmUg eW91IGNhbiBkZWNyeXB0IHRoZSBwYXlsb2FkLiAgSXQgY2Fu4oCZdCBiZSBiYXNlZCBvbiBhbnl0 aGluZyBpbnRlcm5hbCB0byB0aGUgZW5jcnlwdGVkIHBhY2tldC4NCg0KSW4gTWFydGlu4oCZcyBw cm9wb3NhbCwgaXTigJlzIHVzaW5nIGEgY29tYmluYXRpb24gb2YgdGhlIGVuY3J5cHRlZCBwYXls b2FkICh3aGljaCByZXF1aXJlcyBub3RoaW5nIHRvIGFjY2VzcykgYW5kIHNvbWUgc3RvcmVkIHN0 YXRlIG9uIGVhY2ggZW5kcG9pbnQsIHdoaWNoIHJlcXVpcmVzIG9ubHkgdGhlIENvbm5lY3Rpb24g SUQgdG8gbG9vayB1cC4gIFlvdSB3YW50IHRoZSB0aGluZyB5b3UgWE9SIGJ5IHRvIGJlIGNvbnN0 YW50bHkgY2hhbmdpbmcsIG9yIGl0IGJlY29tZXMgZWFzaWVyIHRvIGxvb2sgYXQgc2VxdWVuY2Vz IG9mIG9iZnVzY2F0ZWQgcGFja2V0IG51bWJlcnMgYW5kIHN0YXJ0IGRyYXdpbmcgaW5mZXJlbmNl cyBhYm91dCB3aGF0IHRoZSBYT1IgdmFsdWUgaXMuICBJZiBvdmVyaGVhZCBpcyB0aGUgcHJpbWFy eSBjb25jZXJuLCBJIHRoaW5rIHRoZXJlIGFyZSBhIGNvdXBsZSBhcHByb2FjaGVzIHRoYXQgbWln aHQgYWxsb3cgeW91IHRvIHByZWNvbXB1dGUgdmFsdWVzIGFuZCBhbW9ydGl6ZSB0aGUgY29zdCBv ZiBkb2luZyB0aGUgZW5jcnlwdGlvbiBzdGVwLiAgKEF0IHRoZSBjb3N0IG9mIGtlZXBpbmcgdGhl IHRhYmxlIG9mIHByZWNvbXB1dGVkIHZhbHVlcywgb2YgY291cnNlLikNCg0KSSBzdGlsbCB0aGlu ayBKYW5h4oCZcyBwdXNoaW5nIGluIHRoZSByaWdodCBkaXJlY3Rpb24gaGVyZTogIExldOKAmXMg YWdyZWUgb24gZ29hbHMsIGFuZCB0aGVuIHNlZSBpZiB3ZSBjYW4gY3JhZnQgYSBkZXNpZ24gdGhh dCBtZWV0cyB0aG9zZSBnb2Fscy4gIEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92ZXJoZWFk IGlzIGEgZ29hbCwgd2hpY2ggSSB0aGluayB3ZSBjYW4gYWxsIGFncmVlIG9uLiAgSSBhbHNvIHRo aW5rIEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgMS0xLjUlIG92ZXJoZWFkIGlzIHRvbyBoaWdoLCBi dXQgaXQgc291bmRzIGxpa2UgdGhlcmXigJlzIGxlc3MgYWdyZWVtZW50IG9uIHRoYXQuICBZb3Ug YWxzbyByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNvbWUgY2xpZW50cyB3aWxsIGNh cmUgbGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlIHRoZXkgd2lsbCBuZXZlciBpbnRlbnRp b25hbGx5IG1pZ3JhdGUuDQoNCkkgdGhpbmsgVmljdG9yIHNhaWQgaXQgYmVzdCwgIk9iZnVzY2F0 aW9uIGlzIGp1c3QgZW5jcnlwdGlvbiBkb25lIHBvb3JseS4iIEVpdGhlciB3ZSBlbmNyeXB0LCBv ciB3ZSBkb24ndC4gQnV0IHRoZXJlIGlzIG5vIHN1Y2ggdGhpbmcgYXMgYW4gb2JmdXNjYXRpb24g bWlkZGxlLWdyb3VuZC4gT2JmdXNjYXRpb24gd291bGQganVzdCBiZSBhIHNwZWVkIGJ1bXAsIGVh c2lseSBicm9rZW4uIEl0IHdvbid0IHByb3ZpZGUgcHJpdmFjeSwgYW5kIGl0IHdvbid0IHByZXZl bnQgbGlua2FiaWxpdHkuDQoNCkFzIGZhciBhcyBJIGFtIGNvbmNlcm5lZCwgdGhlcmUgYXJlIG9u bHkgdHdvIGRlc2lnbnMgdGhhdCBwcmV2ZW50IGxpbmthYmlsaXR5Og0KDQoxKSBNYXJ0aW4ncyBQ UiwgaW4gd2hpY2ggdGhlIHBhY2tldCBudW1iZXIgaXMgZW5jcnlwdGVkIHVzaW5nIHNlbnNpYmxl IGNyeXB0bzsNCg0KMikgT3IsIGxlYXZpbmcgdGhlIHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFy IGJ1dCB1c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBh bmQgdXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRoLg0KDQpUaGUg c2Vjb25kIG9wdGlvbiByZXF1aXJlcyBtb3JlIGNvbXB1dGF0aW9uIHdoZW4gZXhwbGljaXRseSBz ZXR0aW5nIHVwIGEgbmV3IHBhdGguIFRoZSBjb25uZWN0aW9uIElEIHdvdWxkIGJlIHVzZWQgYXMg cGFydCBvZiB0aGUgInNhbHQiIHdoZW4gZGVyaXZpbmcgY29ubmVjdGlvbiBjb250ZXh0cy4gVGhl IHBhY2tldCBudW1iZXIgb24gZWFjaCBwYXRoIHdpbGwgc3RhcnQgYXQgMSAob3IgbWF5YmUgMCA7 LSkuIFRoaXMgcmVxdWlyZXMgbWFpbnRhaW5pbmcgc2VwYXJhdGUgU0FDSyBkYXNoYm9hcmRzIGZv ciBlYWNoIHBhdGgvQ29ubmVjdGlvbi1JRCwgYW5kIGNvbnN0cmFpbmluZyBBQ0sgdG8gYmUgcGVy L3BhdGgsIG9yIGFsdGVybmF0aXZlbHkgYWRkaW5nIGEgUEFUSC1BQ0sgZnJhbWUgdGhhdCBpbmRp Y2F0ZXMgdGhlIHBhdGggZm9yIHdoaWNoIHBhY2tldHMgYXJlIGFja2VkLg0KDQpUaGUgcHJvcyBh bmQgY29ucyBvZiB0aGUgdHdvIG9wdGlvbnMgYXJlIGVhc3kgdG8gZ2V0Og0KDQoxKSBPcHRpb24g MiBkb2VzIG5vdCByZXF1aXJlIHRoZSBjb3N0IG9mIGVuY3J5cHRpbmcgZXZlcnkgcGFja2V0LCB0 aHVzIHBlciBwYWNrZXQgcHJvY2Vzc2luZyB3aWxsIGJlIG1heWJlIDElIGZhc3RlciB0aGFuIG9w dGlvbiAxLg0KDQoyKSBPcHRpb24gMiByZXF1aXJlcyBjb21wdXRpbmcgZW5jcnlwdGlvbiBjb250 ZXh0cyBmb3IgZWFjaCBwYXRoLCB3aGljaCBpcyBtb3JlIGNvbXBsZXggdGhhbiBvcHRpb24gMSwg YnV0IHRoZSBjb3N0IHdpbGwgYmUgYW1vcnRpemVkIG92ZXIgdGhlIGR1cmF0aW9uIG9mIHRoZSBw YXRoLg0KDQozKSBPcHRpb24gMiByZXF1aXJlcyBtb3JlIGNvbXBsZXggZGF0YSBzdHJ1Y3R1cmVz IGFuZCBBQ0sgbWFuYWdlbWVudCwgdGh1cyBpbmNyZWFzaW5nIHRoZSBjaGFuY2VzIHRoYXQgc29t ZXRoaW5nIGdvZXMgd3JvbmcuDQoNCjQpIE9wdGlvbiAyIGRvZXMgbm90aGluZyBhZ2FpbnN0IHBh Y2tldCBudW1iZXIgb3NzaWZpY2F0aW9uLiBUaGUgcGFja2V0IG51bWJlciBlZmZlY3RpdmVseSBi ZWNvbWVzIHBhcnQgb2YgdGhlIGludmFyaWFudHMuDQoNCkluIHNob3J0LCB0aGUgb25seSBhZHZh bnRhZ2Ugb2Ygb3B0aW9uIDIgaXMgdG8gYXZvaWQgYSBzaW5nbGUgc3ltbWV0cmljIGVuY3J5cHRp b24gb3BlcmF0aW9uIHBlciBwYWNrZXQsIHdoaWxlIG1ha2luZyB0aGUgY29kZSBzaWduaWZpY2Fu dGx5IG1vcmUgY29tcGxleCwgYW5kIGF0IHRoZSBjb3N0IG9mIG5vdCBwcm90ZWN0aW5nIGFnYWlu c3QgUE4gb3NzaWZpY2F0aW9uLiBUaGUgd2F5IEkgc2VlIHRoYXQsIHRoZXJlIGlzIGhhcmRseSBh bnkgZGViYXRlLg0KDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0KDQo= --_000_1F436ED13A22A246A59CA374CBC543998B58BAD7ORSMSX111amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM1NjM1MDIyNzsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6NTEyMjgyMjAyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt dGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MS4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDENCgl7bXNv LWxpc3QtaWQ6NDE0NzQ0NDk0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDM5NTQwOTI7fQ0K QGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTps ZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21z by1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo4Mzg0MjE3MTI7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjEyNDkyMTExNjt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2 ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28t bGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjps ZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21z by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+R29pbmcgYmFjayB0 byBJYW7igJlzIHBvaW50IGhlcmUg4oCTIENhbiB5b3UgYmUgZXhwbGljaXQgYWJvdXQgdGhlIGlz c3VlIHlvdSBzZWUgaW4gdGhlIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbj8NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5NYW5hc2k8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBb bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+UHJhdmVl biBCYWxhc3VicmFtYW5pYW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAwOSwg MjAxOCAxMTo1OSBBTTxicj4NCjxiPlRvOjwvYj4gRGF2aWQgQmVuamFtaW4gJmx0O2RhdmlkYmVu QGNocm9taXVtLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBy dGZtLmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc7IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5u ZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldpdGggVkxFIGl0cyBtaW5p bWFsIG92ZXJoZWFkIHBlciBwYWNrZXQgc28geW91IGFyZSBub3QgZW5jcnlwdGluZyA0IGJ5dGVz IG1vcmUgYWxsIHRoZSB0aW1lIGV2ZW4gd2l0aCA2NCBiaXQgb3IgMTI4IGJpdCBwYWNrZXQgbnVt YmVyIC4gU28gaXRzIGRlY2lkZWRseSBiZXR0ZXIuIEFsc28gZmV3ZXIgY2FsbHMgaW50byBUTFMs IGJ1dCBJIHN1cHBvc2Ugb25lIGNvdWxkIGRvIHNvbWUgcmVmYWN0b3Jpbmcgb2YNCiBUTFMgQVBJ LiBNYW55IENQVXMgeWVzIGJ1dCB0aGlzIGlzIGEgZ2VuZXJhbCBwdXJwb3NlIHRyYW5zcG9ydCBh bmQgY291bGQgcnVuIG9uIENQVXMgdGhhdCBkb27igJl0Lg0KPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkRpZG7igJl0IGFzayBmb3Igbm9uY2UgdG8gYmUgdmFyaWFibGUgbGVuZ3RoLiBGaXhlZCBs ZW5ndGggZm9yIGNvbm5lY3Rpb24gbGlmZXRpbWUuIERhdGFjZW50ZXJzIGNvbm5lY3Rpb25zIGNv dWxkIHVzZSA2NC1iaXQgbm9uY2UgdG8gYXZvaWQgZnJlcXVlbnQga2V5IHJvbGxvdmVyLg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVmZmVjdGl2ZWx5IHRoZSBwbGFpbiB0ZXh0IG5vbmNlIGlz IGEgc2VxdWVuY2UgbnVtYmVyIHNpbmNlIGl0IGluY3JlYXNlcyBtb25vdG9uaWNhbGx5IHdpdGgg c21hbGwganVtcHMgYXMgbmVlZGVkIHRvIGF2b2lkIG9zc2lmaWNhdGlvbi4gU28gbm8gd29yc2Ug b2ZmIHRoYW4gZ1FVSUMgb3IgY3VycmVudCBkcmFmdC4gTm8gbW9yZSBjb21wbGV4IHRoYW4gdXNp bmcgdGhlIHBhY2tldCBudW1iZXIuIEp1c3QgdGhlDQogc3RhcnRpbmcgbnVtYmVyIGlzIHJhbmRv bWl6ZWQuIEFsc28gcGxlYXNlIG5vdGljZSB0aGF0IHRoaXMgcHJvcG9zYWwgZG9lcyBub3QgcHJl Y2x1ZGUgdXNpbmcgZW5jcnlwdGVkIHBhY2tldCBudW1iZXIgYXMgdGhlIG5vbmNlIGFzIHByb3Bv c2VkIHByZXZpb3VzbHkuIENoYW5naW5nIGhvdyB0aGUgbm9uY2Ugd29ya3MgbWFrZXMgMCBpbXBh Y3Qgb24gdGhlIHRyYW5zcG9ydCBsb2dpYy4gQW4gaW1wbGVtZW50YXRpb24gY2FuIGNob29zZSB0 byBpbXBsZW1lbnQNCiBhbnkgZm9ybSBvZiBub24tcmVwZWF0aW5nIG5vbmNlIHdpdGhvdXQgcmV2 dmluZyB0aGUgUkZDLiBUaGlzIGlzIHRoZSBiaWdnZXN0IGFkdmFudGFnZSBvZiBzZXBhcmF0aW9u IG9mIGNvbmNlcm5zIElNSE8uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBE YXZpZCBCZW5qYW1pbiBbbWFpbHRvOmRhdmlkYmVuQGNocm9taXVtLm9yZ10gPGJyPg0KPGI+U2Vu dDo8L2I+IEZyaWRheSwgRmVicnVhcnkgOSwgMjAxOCAxMTozOSBBTTxicj4NCjxiPlRvOjwvYj4g UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBFcmljIFJlc2NvcmxhICZsdDtla3JAcnRmbS5jb20mZ3Q7OyBxdWljQGlldGYu b3JnOyBodWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Zb3VyIHByaW1hcnkgd29ycnkgaGVyZSB3YXMgdGhlIGV4dHJhIGJsb2NrIGNpcGhl ciBvcGVyYXRpb24sIHJpZ2h0PyBCeSBtb3ZpbmcgdGhlIHBhY2tldCBudW1iZXIgaW50byB0aGUg cGxhaW50ZXh0LCB0aGlzIHByb3Bvc2FsIGluY3JlYXNlcyB0aGUgbGVuZ3RoLCB3aGljaCB3aWxs IGNvc3QgdGhhdCBzYW1lIG9uZSBleHRyYSBibG9jayBjaXBoZXIgb3BlcmF0aW9uLCBubz88bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBv bmUgYmxvY2sgb3BlcmF0aW9uIHVuZGVyIHRoZSBzYW1lIGtleSwgcmF0aGVyIHRoYW4gYSBkaWZm ZXJlbnQga2V5IHNvIEkgc3VwcG9zZSB0aGVyZSBhcmUgbWludXNjdWxlJm5ic3A7Y2FjaGUgZm9v dHByaW50IHdpbnMgKG9uZSBzeW1tZXRyaWMga2V5IGlzIDE2IG9yIDMyIGJ5dGVzKS4gQnV0IHRo ZSBjb3N0IGlzIHBlci1wYWNrZXQgKCEpIGJhbmR3aWR0aCBhbmQgY29tcGxleGl0eS4gSSBkbyBu b3Qgc2VlDQogaG93IHRoaXMgY291bGQgYmUgd29ydGggaXQuJm5ic3A7Tm90ZSB0aGF0LCBmb3Ig QUVTLCBtYW55IENQVXMgaGF2ZSBkZWRpY2F0ZWQgaW5zdHJ1Y3Rpb25zIGZvciBpdCBhbHJlYWR5 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwO0NsZWFyIHNlcGFyYXRpb24gb2YgY29uY2Vy bnMgcmVzdWx0cyBpZiB3ZSBkb27igJl0IG92ZXJsb2FkIHRoZSBwYWNrZXQgbnVtYmVyIGFzIHRo ZSBub25jZS4gQ29ubmVjdGlvbiBtaWdyYXRpb24gYW5kIG11bHRpLXBhdGggYXJlIG9wdGlvbmFs IGZlYXR1cmVzIGFuZCB3ZSBwYXkgbm8gZXh0cmEgY29tcHV0ZSBjb3N0IGZvciBtb3N0IGNvbm5l Y3Rpb25zIHRoYXQgYXJlIG5vdCBpbXBhY3RlZCBieSB1bmxua2FiaWxpdHkuDQogTm9uY2UgZmll bGQgYmVjb21lcyBvcHRpb25hbCBmb3IgY3J5cHRvIHRoYXQgZG9lc27igJl0IG5lZWQgaXQgYW5k IGNhbiBncm93IHRvIGxhcmdlciBzaXplIGFzIG5lZWRlZCBmb3IgYnVsayB0cmFuc2ZlcnMgdG8g cHJldmVudCBmcmVxdWVudCBrZXkgcm9sbG92ZXJzIChzYXkgaW4gZGF0YWNlbnRlciBzY2VuYXJp b3MpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSdyZSBub3QgZ29pbmcgdG8gZmluZCBBRUFEcyB0 aGF0IGRvbid0IHJlcXVpcmUgYSBub25jZS4gRW5jcnlwdGlvbiBtdXN0IG5vdCBwcm9kdWNlIHRo ZSBzYW1lIGNpcGhlcnRleHQgdHdpY2UgZm9yIHRoZSBzYW1lIHBsYWludGV4dCwgc28geW91IG5l ZWQgc29tZSBpbnB1dCB0byBkaXZlcnNpZnkgdGhlbS4gVGhhdCBpbnB1dCBpcyB0aGUgbm9uY2Uu IE5vbmNlcyBhbHNvIGFyZSBub3QgdmFyaWFibGUtbGVuZ3RoLA0KIHNvIHlvdSBkb24ndCBnZXQg dG8gYXJiaXRyYXJpbHkgZ3JvdyB0aGVtLiAoQUVTLUdDTSBwZXIgc3BlYyBpcyB2YXJpYWJsZSBs ZW5ndGgsIGJ1dCB0aGF0J3MgYSBzcGVjIGJ1Zy4gSWYgeW91IHNpemUgaXQgYWJvdmUgOTYgYml0 cywgaXQncyBhcyBpZiB5b3UgcmFuZG9taXplZCBpdCBhbmQgeW91ciBub25jZSBzcGFjZSBjcmFz aGVzIHBlciBiaXJ0aGRheS4pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0IGlzIGFsc28gaGFybWZ1bCB0byBzZXBhcmF0ZSB0aGUgdHdvIGNv bmNlcm5zLiZuYnNwO1doZW4geW91IGFyZSBidWlsZGluZyBhIHRyYW5zcG9ydCwgZGVyaXZlIHRo ZSBub25jZSBmcm9tIGEgc2VxdWVuY2UgbnVtYmVyLiBUTFMgMS4yIEFFUy1HQ00gc2VwYXJhdGVk IHRoZW0sIHdoaWNoIHdhcyBhIG1pc3Rha2UuIEl0J3MgbGVzcyBlZmZpY2llbnQgKHRoZSB3b3Js ZCB3YXN0ZWQgcXVpdGUgYSBsb3Qgb2YgYmFuZHdpZHRoDQogZHVlIHRvIHRoaXMpLCBhbmQgbW9y ZSBlcnJvci1wcm9uZS4gVGhlcmUgd2FzIG5vdGhpbmcgc3RvcHBpbmcgaW1wbGVtZW50YXRpb25z IGZyb20gc2VuZGluZyB0aGUgc2FtZSBub25jZSBvciBnZW5lcmF0aW5nIG5vbmNlcyByYW5kb21s eSAodGhlIEFFQURzIHdlIHVzZSBkb24ndCBoYXZlIGxhcmdlIGVub3VnaCBub25jZXMgZm9yIHRo YXQpLCBhbmQgaW5kZWVkIHNvbWUgZGlkIGp1c3QgdGhhdC4gSWYgeW91IHVzZSBzb21lIHNvcnQg b2Ygc2VxdWVuY2UNCiBudW1iZXIsIHlvdSBjYW4gbGVhbiBvbiBleGlzdGluZyB3b3JrIGJvdGgg dG8gZmlsdGVyIG91dCB0aGUgb2J2aW91cyBpbXBsZW1lbnRhdGlvbiBtaXN0YWtlcyBhbmQgdG8g YXZvaWQgc2VuZGluZyB1bm5lY2Vzc2FyeSBkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgRmViIDks IDIwMTggYXQgMTI6MzggUE0gUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHJhdmJAbWljcm9zb2Z0 LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5n OjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5MZXQgbWUgdHJ5IHRvIHN1bW1hcml6ZSB0aGUgcHJvcG9zYWwgYWdh aW46PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEiPg0KUGFja2V0IG51bWJlciBpcyBpbiB0aGUgZW5jcnlw dGVkIHBvcnRpb24gb2YgdGhlIGhlYWRlciBhbmQgaXMgbm8gbG9uZ2VyIHVzZWQgYXMgdGhlIG5v bmNlLiBJdCBpcyBlbmNvZGVkIGFzIGEgdmFyaWFibGUgbGVuZ3RoIG51bWJlci4gQWx3YXlzIHN0 YXJ0cyBhdCAwLg0KPG86cD48L286cD48L2xpPjwvb2w+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEi Pg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDIgbGV2ZWwyIGxmbzEiPg0KTm8gb3NzaWZpY2F0aW9uIG9mIFBOPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzEiPg0KTm8gbGlu a2FiaWxpdHkgdXNpbmcgUE48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMiBsZXZlbDIgbGZvMSI+DQpBbGxvd3MgZm9yIGdyb3d0aCBiZXlvbmQgNjQgYml0 cyBpZiBuZWVkZWQgaW4gZnV0dXJlPG86cD48L286cD48L2xpPjwvb2w+DQo8L29sPg0KPG9sIHN0 YXJ0PSIyIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2 ZWwxIGxmbzEiPg0KVGhlIG5vbmNlIGlzIGluIHRoZSBjbGVhciBpbiBwbGFpbnRleHQgaGVhZGVy LiBJdCBpcyBnZW5lcmF0ZWQgPGk+cGVyIHBhdGg8L2k+IGFzIGEgc2VjdXJlIHJhbmRvbSBudW1i ZXIuIENhbGwgdGhpcyB0aGUg4oCcc3RhcnRpbmcgdmFsdWXigJ0uIEJvdGggc2lkZXMgTVVTVCBp bml0aWFsaXplIHRoZSDigJxzdGFydGluZyB2YWx1ZeKAnSBub25jZQ0KPGk+cGVyIHBhdGg8L2k+ LiBXaXRoaW4gYSBwYXRoIGl0IGdyb3dzIG1vbm90b25pY2FsbHkgKHRvIGF2b2lkIHJlcGVhdHMg anVzdCBsaWtlIFBOIHRvZGF5KSBhbmQgY2FuIGluY2x1ZGUgc2hvcnQgcmFuZG9tIGp1bXBzIHBl cmlvZGljYWxseSBzbyB0aGF0IG1pZGRsZWJveGVzIGNhbm5vdCBhc3N1bWUgYW55dGhpbmcgYWJv dXQgdGhlIGZpZWxkLiBTaW5jZSBub25jZSBoYXMgbm90aGluZyB0byBkbyB3aXRoIFBOIHRoZSBq dW1wcyBkb27igJl0IGFkZA0KIGFueSBjb21wbGV4aXR5IHRvIHRyYW5zcG9ydCBsb2dpYy4gSnVt cHMgYXJlIGZvciBncmVhc2luZyBhbmQgcHJldmVudGluZyBvc3NpZmljYXRpb24uIFdoZW4gdGhl IG5vbmNlIHJvbGxzIG92ZXIgYW5kIHJlYWNoZXMgY2xvc2UgdG8gdGhlIOKAnHN0YXJ0aW5nIHZh bHVl4oCdLCBrZXkgcm9sbG92ZXIgbXVzdCBoYXBwZW4uIEF0IGhpZ2ggZGF0YSByYXRlcyB0aGUg bm9uY2UgZmllbGQgY2FuIGJlIDY0LWJpdHMgdG8gcHJldmVudCBmcmVxdWVudCBrZXkNCiByb2xs b3Zlci4gRm9yIGNyeXB0byB0aGF0IGRvZXNu4oCZdCBuZWVkIG5vbmNlcywgdGhlIGZpZWxkIGNh biBiZSBvbWl0dGVkLiA8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxvbCBzdGFydD0iMiIgdHlwZT0i MSI+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMiBsZXZlbDIgbGZvMiI+DQpObyBvc3NpZmljYXRpb24gYmVjYXVzZSB0aGVyZSBpcyBu byBwcmUtZGV0ZXJtaW5lZCBzZXF1ZW5jZSB0byB0aGUgbm9uY2UuPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzIiPg0KSW4gZ1FVSUMg YW5kIHRoZSBSRkMgYXMgZGVmaW5lZCB0aGUgbm9uY2UgaXMgYSBzaW1wbGUgc2VxdWVuY2UgdGhh dCBpbmNyZW1lbnRzIGJ5IG9uZSwgc28gdGhpcyBpcyBubyB3b3JzZSBvZmYgaW4gdGVybXMgb2Yg c2VjdXJpdHkuIEl0IGlzIG5vbi1yZXBlYXRpbmcuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzIiPg0KTm8gbGlua2FiaWxpdHkgYmVj YXVzZSBkaWZmZXJlbnQgcGF0aHMgc3RhcnQgYXQgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCByYW5k b20gbnVtYmVyLiBJZiByZXBlYXRpbmcgaXMgYSBjb25jZXJuIHRoZW4gZGlmZmVyZW50IHBhdGhz IHVzZSBkaWZmZXJlbnQga2V5cy4gQ2FycmllcyBmb3J3YXJkIHRvIG5vdCBqdXN0IGNvbm5lY3Rp b24gbWlncmF0aW9uIGJ1dCBtdXRsaS1wYXRoLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzIiPg0KU3VwcG9ydHMga2V5IHJvbGxv dmVyIGp1c3QgbGlrZSBnUVVJQyBhbmQgY3VycmVudGx5IGRlZmluZWQgZHJhZnQgUkZDLjxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMiBsZm8y Ij4NCkFsbG93cyBmb3Igb21pdHRpbmcgdGhlIG5vbmNlIHdoZW4gd2UgdXNlIGNyeXB0byB0aGF0 IGRvZXNu4oCZdCBuZWVkIGl0LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwyIGxldmVsMiBsZm8yIj4NCkFsbG93cyBmb3IgbGFyZ2VyIG5vbmNlcyBmb3Ig aGlnaCBkYXRhIHJhdGVzLiA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMiBsZXZlbDIgbGZvMiI+DQpJdCBkb2VzbuKAmXQgcHJlY2x1ZGUgYW55IG90aGVy IHR5cGUgb2Ygbm9uLXJlcGVhdGluZyBub25jZXMgd2l0aG91dCBoYXZpbmcgdG8gbW9kaWZ5IHRo ZSBSRkMhIFNvIGltcGxlbWVudGF0aW9ucyB0aGF0IHdhbnQgdG8gdXNlIGNyeXB0b2dyYXBoaWMg bm9uY2VzIGNhbiBzdGlsbCBkbyBzby4NCjxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9vbD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPlRoZSBkb3duc2lkZXM6PG86cD48L286cD48L3A+DQo8b2wgc3RhcnQ9IjEiIHR5 cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+ DQpFdmVuIHdpdGggdmFyaWFibGUgbGVuZ3RoIGVuY29kaW5nIHRoZSBleHRyYSBQTiBmaWVsZCBp cyBtb3JlIHNwYWNlIHVzZWQgcGVyIHBhY2tldCB3aGVuIGEgbm9uY2UgaXMgcmVxdWlyZWQuIEkg dGhpbmsgd2UgY2FuIGRvIHdpdGggMiBieXRlcyBpbiB2ZXJzaW9uIDEuPG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KSXTigJlz IG5vdCBwZXJmZWN0IHVubGlua2FiaWx0aXkgYnV0IEkgaGF2ZSB5ZXQgdG8gc2VlIGFueSBzb2x1 dGlvbiB0aGF0IGNhbiBwcm92aWRlIHRoaXMuIEEgc2ltcGxlIHRpbWUgYmFzZWQgYW5hbHlzaXMg dXNpbmcgbWFjaGluZSBsZWFybmluZyB3aWxsIGFsbG93IGZsb3cgY29ycmVsYXRpb24gZXNwZWNp YWxseSBmb3IgY29ubmVjdGlvbiBtaWdyYXRpb24uIFRoZSBJUCBhZGRyZXNzZXMgaW4gdGhlIGNs ZWFyIGFsbG93IGZvciBhIGhpZ2ggZGVncmVlDQogb2YgY29ycmVsYXRpb24uIFRoZXJlIGlzIGFs c28gdGhlIGFwcGxpY2F0aW9uIHNlbmRpbmcgcGF0dGVybiBhbmQgb3RoZXIgc2lnbmFscyB0aGF0 IGNvdWxkIGJlIHVzZWQuDQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZy b206PC9iPiBFcmljIFJlc2NvcmxhIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g RnJpZGF5LCBGZWJydWFyeSA5LCAyMDE4IDU6NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4g QmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gaHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQiIHRhcmdl dD0iX2JsYW5rIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9u IFRodSwgRmViIDgsIDIwMTggYXQgOTo0MCBQTSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0 OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+cHJh dmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+QWN0dWFsbHkgdGFraW5nIGEgc3RlcCBiYWNrIHdoYXQgaWYg d2UgZG9u4oCZdCB3ZSBvdmVybG9hZGVkIHBhY2tldCBudW1iZXIgYXMgdGhlIG5vbmNlPzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2FuIHdlOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0YXJ0 PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzQiPg0KUHV0IHBhY2tldCBudW1iZXIgYXMgYSBzZXBhcmF0ZSB2YXJpYWJsZSBsZW5ndGgg ZmllbGQgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBoZWFkZXIuIFRoaXMgYWxsb3dz IGZvciBncm93dGggYmV5b25kIDY0IGJpdHMgaW4gZnV0dXJlIGFuZCBjb21wbGV0ZWx5IGF2b2lk cyBvc3NpZmljYXRpb24uIEZvciBzaG9ydCBsaXZlZCBmbG93cyB2YXJpYWJsZSBsZW5ndGggZW5j b2RpbmcgbGVhZHMgdG8gbWluaW1hbCBzcGFjZSBvdmVyaGVhZC4NCjxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4NClB1dCBhIHNl cGFyYXRlIHBsYWludGV4dCBub25jZSB3aGljaCBzdGFydHMgb3V0IGFzIGEgc2VjdXJlIHJhbmRv bSBudW1iZXIgYW5kIG1vbm90b25pY2FsbHkgaW5jcmVhc2VzIGFzIHNob3J0IHJhbmRvbSBqdW1w cyAoZXZlcnkgcGFja2V0IG9yIGV2ZXJ5IGZldyBwYWNrZXRzKSBhbmQgY291bGQgdGhlbiByb2xs b3Zlci4gVGhpcyB3aWxsIHByZXZlbnQgbGlua2FiaWxpdHkgYW5kIHNjYWxlcyB0byBtdWx0aS1w YXRoIGFzIHdlbGwuIE5vIG1ham9yDQogY29tcHV0ZSBvdmVyaGVhZC4gV2UgY2FuIGFsc28gbWFr ZSB0aGUgbm9uY2Ugb3B0aW9uYWwgZm9yIGNyeXB0byBhbGdvcml0aG1zIHRoYXQgZG8gbm90IG5l ZWQgYSBub25jZSBzYXZpbmcgbW9yZSBzcGFjZS48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+SSdtIG5vdCBzdXJlIGhvdyB0byBkbyAjMiBzYWZlbHkgYW5kIGVmZmljaWVudGx5LiBUaGUg cHJpbWFyeSBjb25jZXJuIGlzIHRoYXQgc2hvcnQgcmFuZG9tIGp1bXBzIGRvbid0IGFjdHVhbGx5 IHByZXZlbnQgbGlua2FiaWxpdHkgYmVjYXVzZSB0aGUgaGlnaCBvcmRlciBiaXRzIGRvbid0IGNo YW5nZSBhbmQNCiBsb25nIHJhbmRvbSBqdW1wcyBhcmUgZWZmZWN0aXZlbHkgcmFuZG9tbHkgc2Ft cGxpbmcgb3V0IG9mIHRoZSBub25jZSBzcGFjZSwgYW5kIHlvdSBzdGFydCB0byBydW4gaW50byBi aXJ0aGRheSBwcm9ibGVtcy4gQWRkaXRpb25hbGx5LCB0aGUgY2hlYXBlc3QgUFJOR3MgYXJlIGJh c2ljYWxseSBjaXBoZXJzIGluIGNvdW50ZXIgbW9kZSwgc28gYXQgYmVzdCB5b3UncmUgZ29pbmcg dG8gZ2V0IGEgc21hbGwgYW1vdW50IG9mIG92ZXJoZWFkIHJlZHVjdGlvbg0KIGJ5IGdldHRpbmcg bXVsdGlwbGUganVtcCBjb21wdXRhdGlvbnMgb3V0IG9mIGEgc2luZ2xlIGJsb2NrLCB0aG91Z2gg aWYgeW91IHVzZSA5Ni1iaXQganVtcHMsIHlvdSBvbmx5IGdldCAyNSUgc2F2aW5ncy4uLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LUVr cjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Tb21lIE1TQiBvZiB0aGUgbm9uY2UgY291bGQgYmUgdXNlZCBmb3Igc2lnbmFs aW5nIHJlb3JkZXIgdG8gdGhlIG5ldHdvcmsgaWYgbmVlZGVkLiBJIGRvbuKAmXQgaGF2ZSB0aGUg aGlzdG9yaWNhbCBjb250ZXh0IGZvciBvdmVybG9hZGluZyBvZiBQTiBhcyB0aGUgbm9uY2Ugc28g cGFyZG9uIG1lIGlmIHVuLW92ZXJsb2FkaW5nDQogb3B0aW9uIHdhcyBkaXNjdXNzZWQgYW5kIHJ1 bGVkIG91dCBiZWZvcmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzo8YSBocmVmPSJt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2Vz QGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UHJhdmVlbiBCYWxhc3VicmFtYW5p YW48YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggNTo1MSBQTTxi cj4NCjxiPlRvOjwvYj4gaHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFAaHVpdGVt YS5uZXQiIHRhcmdldD0iX2JsYW5rIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9hPiZndDs7DQo8YSBo cmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8 L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7Jmd0OyBhbmQgdXNp bmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRoPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpcyBhbG9uZSBwcmV2ZW50 cyBsaW5rYWJpbGl0eSByaWdodD88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsmZ3Q7 IFRoZSBwYWNrZXQgbnVtYmVyIG9uIGVhY2ggcGF0aCB3aWxsIHN0YXJ0IGF0IDEgKG9yIG1heWJl IDAgOy0pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JcyBzdXBwb3J0 aW5nIG11bHRpcGxlIHBhdGhzIGF0IHRoZSBzYW1lIHRpbWUgYSBnb2FsPyBJZiB5ZXMsIHRoZW4g eWVzIGFsbCBwYXRocyB3aWxsIG5lZWQgdG8gaGF2ZSBzZXBhcmF0ZSB0cmFja2luZyBhbmQgQUNL IHN0YXRlIGFuZCBjb25nZXN0aW9uIGNvbnRyb2wgZXRjLiBJIHRob3VnaHQgdGhpcyBpcw0KIG5v dCBwYXJ0IG9mIFYxIFJGQy4gSWYgaXRzIGp1c3Qgb25lIGFkZGl0aW9uYWwgcGF0aCBmb3IgY29u bmVjdGlvbiBtaWdyYXRpb24gc2NlbmFyaW8gdGhlbiBhbGwgeW91IG5lZWQgaXMgYSAocmFuZG9t KSBqdW1wIHRvIGEgb2Zmc2V0IGluIHBhY2tldCBudW1iZXIgc3BhY2UgZm9yIHRoZSBuZXcgcGF0 aCBzbyB0aGF0IHRoZSBmZXcgcGFja2V0cyBpbiB0aGUgb2xkIHBhdGggY2FuIGNvbnRpbnVlIGZv ciBhIGxpdHRsZSBiaXQuIFRoaXMgd29ya3MNCiB3aXRoIGp1c3Qgb25lIEFDSyBzcGFjZSBzbyBu byBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jmd0OyZndDsgMikgT3IsIGxlYXZpbmcgdGhlIHBhY2tldCBudW1iZXIgaW4gdGhlIGNsZWFyIGJ1 dCB1c2luZyBkaWZmZXJlbnQgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRoLCBhbmQg dXNpbmcgc2VwYXJhdGUgcGFja2V0IHNlcXVlbmNlcyBmb3IgZWFjaCBwYXRoLjxicj4NCkluIGFk ZGl0aW9uIGlmIHRoZSB2YWx1ZSBpbiB0aGUgY2xlYXIgd2FzIG9iZnVzY2F0ZWQgd2l0aCBhbiBY T1IgdHJhbnNmb3JtIGl0IHdpbGwgaGVscCBwcmV2ZW50IG9zc2lmaWNhdGlvbi4gVGhlIG9iZnVz Y2F0aW9uIGlzIG5vdCBtZWFudCB0byBndWFyZCBhZ2FpbnN0IGxhdGVyIGFuYWx5c2lzIHRoYXQg cmV2ZWFscyB0aGUgcGFja2V0IG51bWJlcnMgLSB3aHkgZG8gd2UgY2FyZSBhYm91dCB0aGF0LiBJ dCBpcyBtZWFudCB0byBncmVhc2UgdGhlDQogc3BhY2UgYW5kIG5vdCBtYWtlIHRoZSBudW1iZXJz IHNlcmlhbCBzbyBtaWRkbGVib3hlcyBjYW5ub3QgYXNzdW1lIG9yZGVyaW5nIGV0Yy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkFsbCBzYWlkIGlmIEkgYW0gYWxvbmUgaW4gYmVpbmcgY29u Y2VybmVkIGFib3V0IHRoZSBwZXJmIGhpdCB0aGVuIEnigJlkIHNheSBnbyBvbiB3aXRoIG9wdGlv biAxLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFFVSUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn PC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0aWFuIEh1aXRlbWE8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDgsIDIwMTggMzo1NCBQTTxicj4NCjxiPlRvOjwvYj4g PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPk9uIDIvOC8yMDE4IDE6MTMgUE0sIE1pa2UgQmlzaG9w IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiMyIHdvbuKA mXQgd29yay4mbmJzcDsgVGhlIHBhY2tldCBudW1iZXIgaXMgYW4gaW5wdXQgdG8gdGhlIEFFQUQg bm9uY2UsIHNvIHlvdSBoYXZlIHRvIGdldCB0byB0aGUgcGFja2V0IG51bWJlciBiZWZvcmUgeW91 IGNhbiBkZWNyeXB0IHRoZSBwYXlsb2FkLiZuYnNwOyBJdCBjYW7igJl0IGJlIGJhc2VkIG9uIGFu eXRoaW5nIGludGVybmFsDQogdG8gdGhlIGVuY3J5cHRlZCBwYWNrZXQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5JbiBNYXJ0aW7igJlzIHByb3Bvc2FsLCBpdOKAmXMgdXNpbmcgYSBjb21i aW5hdGlvbiBvZiB0aGUgZW5jcnlwdGVkIHBheWxvYWQgKHdoaWNoIHJlcXVpcmVzIG5vdGhpbmcg dG8gYWNjZXNzKSBhbmQgc29tZSBzdG9yZWQgc3RhdGUgb24gZWFjaCBlbmRwb2ludCwgd2hpY2gg cmVxdWlyZXMgb25seSB0aGUgQ29ubmVjdGlvbg0KIElEIHRvIGxvb2sgdXAuJm5ic3A7IFlvdSB3 YW50IHRoZSB0aGluZyB5b3UgWE9SIGJ5IHRvIGJlIGNvbnN0YW50bHkgY2hhbmdpbmcsIG9yIGl0 IGJlY29tZXMgZWFzaWVyIHRvIGxvb2sgYXQgc2VxdWVuY2VzIG9mIG9iZnVzY2F0ZWQgcGFja2V0 IG51bWJlcnMgYW5kIHN0YXJ0IGRyYXdpbmcgaW5mZXJlbmNlcyBhYm91dCB3aGF0IHRoZSBYT1Ig dmFsdWUgaXMuJm5ic3A7IElmIG92ZXJoZWFkIGlzIHRoZSBwcmltYXJ5IGNvbmNlcm4sIEkgdGhp bmsgdGhlcmUgYXJlDQogYSBjb3VwbGUgYXBwcm9hY2hlcyB0aGF0IG1pZ2h0IGFsbG93IHlvdSB0 byBwcmVjb21wdXRlIHZhbHVlcyBhbmQgYW1vcnRpemUgdGhlIGNvc3Qgb2YgZG9pbmcgdGhlIGVu Y3J5cHRpb24gc3RlcC4mbmJzcDsgKEF0IHRoZSBjb3N0IG9mIGtlZXBpbmcgdGhlIHRhYmxlIG9m IHByZWNvbXB1dGVkIHZhbHVlcywgb2YgY291cnNlLik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkkgc3RpbGwgdGhpbmsgSmFuYeKAmXMgcHVzaGluZyBpbiB0aGUgcmlnaHQgZGlyZWN0aW9u IGhlcmU6Jm5ic3A7IExldOKAmXMgYWdyZWUgb24gZ29hbHMsIGFuZCB0aGVuIHNlZSBpZiB3ZSBj YW4gY3JhZnQgYSBkZXNpZ24gdGhhdCBtZWV0cyB0aG9zZSBnb2Fscy4mbmJzcDsgSSBoZWFyIHlv dSBzYXlpbmcgdGhhdCBsb3cgb3ZlcmhlYWQNCiBpcyBhIGdvYWwsIHdoaWNoIEkgdGhpbmsgd2Ug Y2FuIGFsbCBhZ3JlZSBvbi4mbmJzcDsgSSBhbHNvIHRoaW5rIEkgaGVhciB5b3Ugc2F5aW5nIHRo YXQgMS0xLjUlIG92ZXJoZWFkIGlzIHRvbyBoaWdoLCBidXQgaXQgc291bmRzIGxpa2UgdGhlcmXi gJlzIGxlc3MgYWdyZWVtZW50IG9uIHRoYXQuJm5ic3A7IFlvdSBhbHNvIHJhaXNlIGFuIGludGVy ZXN0aW5nIHBvaW50IHRoYXQgc29tZSBjbGllbnRzIHdpbGwgY2FyZSBsZXNzIGFib3V0IGxpbmth YmlsaXR5IGJlY2F1c2UNCiB0aGV5IHdpbGwgbmV2ZXIgaW50ZW50aW9uYWxseSBtaWdyYXRlLjxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpJIHRo aW5rIFZpY3RvciBzYWlkIGl0IGJlc3QsICZxdW90O09iZnVzY2F0aW9uIGlzIGp1c3QgZW5jcnlw dGlvbiBkb25lIHBvb3JseS4mcXVvdDsgRWl0aGVyIHdlIGVuY3J5cHQsIG9yIHdlIGRvbid0LiBC dXQgdGhlcmUgaXMgbm8gc3VjaCB0aGluZyBhcyBhbiBvYmZ1c2NhdGlvbiBtaWRkbGUtZ3JvdW5k LiBPYmZ1c2NhdGlvbiB3b3VsZCBqdXN0IGJlIGEgc3BlZWQgYnVtcCwgZWFzaWx5IGJyb2tlbi4g SXQgd29uJ3QgcHJvdmlkZSBwcml2YWN5LCBhbmQgaXQgd29uJ3QNCiBwcmV2ZW50IGxpbmthYmls aXR5Ljxicj4NCjxicj4NCkFzIGZhciBhcyBJIGFtIGNvbmNlcm5lZCwgdGhlcmUgYXJlIG9ubHkg dHdvIGRlc2lnbnMgdGhhdCBwcmV2ZW50IGxpbmthYmlsaXR5Ojxicj4NCjxicj4NCjEpIE1hcnRp bidzIFBSLCBpbiB3aGljaCB0aGUgcGFja2V0IG51bWJlciBpcyBlbmNyeXB0ZWQgdXNpbmcgc2Vu c2libGUgY3J5cHRvOzxicj4NCjxicj4NCjIpIE9yLCBsZWF2aW5nIHRoZSBwYWNrZXQgbnVtYmVy IGluIHRoZSBjbGVhciBidXQgdXNpbmcgZGlmZmVyZW50IGVuY3J5cHRpb24gY29udGV4dHMgZm9y IGVhY2ggcGF0aCwgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBzZXF1ZW5jZXMgZm9yIGVhY2gg cGF0aC48YnI+DQo8YnI+DQpUaGUgc2Vjb25kIG9wdGlvbiByZXF1aXJlcyBtb3JlIGNvbXB1dGF0 aW9uIHdoZW4gZXhwbGljaXRseSBzZXR0aW5nIHVwIGEgbmV3IHBhdGguIFRoZSBjb25uZWN0aW9u IElEIHdvdWxkIGJlIHVzZWQgYXMgcGFydCBvZiB0aGUgJnF1b3Q7c2FsdCZxdW90OyB3aGVuIGRl cml2aW5nIGNvbm5lY3Rpb24gY29udGV4dHMuIFRoZSBwYWNrZXQgbnVtYmVyIG9uIGVhY2ggcGF0 aCB3aWxsIHN0YXJ0IGF0IDEgKG9yIG1heWJlIDAgOy0pLiBUaGlzIHJlcXVpcmVzIG1haW50YWlu aW5nDQogc2VwYXJhdGUgU0FDSyBkYXNoYm9hcmRzIGZvciBlYWNoIHBhdGgvQ29ubmVjdGlvbi1J RCwgYW5kIGNvbnN0cmFpbmluZyBBQ0sgdG8gYmUgcGVyL3BhdGgsIG9yIGFsdGVybmF0aXZlbHkg YWRkaW5nIGEgUEFUSC1BQ0sgZnJhbWUgdGhhdCBpbmRpY2F0ZXMgdGhlIHBhdGggZm9yIHdoaWNo IHBhY2tldHMgYXJlIGFja2VkLjxicj4NCjxicj4NClRoZSBwcm9zIGFuZCBjb25zIG9mIHRoZSB0 d28gb3B0aW9ucyBhcmUgZWFzeSB0byBnZXQ6PGJyPg0KPGJyPg0KMSkgT3B0aW9uIDIgZG9lcyBu b3QgcmVxdWlyZSB0aGUgY29zdCBvZiBlbmNyeXB0aW5nIGV2ZXJ5IHBhY2tldCwgdGh1cyBwZXIg cGFja2V0IHByb2Nlc3Npbmcgd2lsbCBiZSBtYXliZSAxJSBmYXN0ZXIgdGhhbiBvcHRpb24gMS4N Cjxicj4NCjxicj4NCjIpIE9wdGlvbiAyIHJlcXVpcmVzIGNvbXB1dGluZyBlbmNyeXB0aW9uIGNv bnRleHRzIGZvciBlYWNoIHBhdGgsIHdoaWNoIGlzIG1vcmUgY29tcGxleCB0aGFuIG9wdGlvbiAx LCBidXQgdGhlIGNvc3Qgd2lsbCBiZSBhbW9ydGl6ZWQgb3ZlciB0aGUgZHVyYXRpb24gb2YgdGhl IHBhdGguPGJyPg0KPGJyPg0KMykgT3B0aW9uIDIgcmVxdWlyZXMgbW9yZSBjb21wbGV4IGRhdGEg c3RydWN0dXJlcyBhbmQgQUNLIG1hbmFnZW1lbnQsIHRodXMgaW5jcmVhc2luZyB0aGUgY2hhbmNl cyB0aGF0IHNvbWV0aGluZyBnb2VzIHdyb25nLjxicj4NCjxicj4NCjQpIE9wdGlvbiAyIGRvZXMg bm90aGluZyBhZ2FpbnN0IHBhY2tldCBudW1iZXIgb3NzaWZpY2F0aW9uLiBUaGUgcGFja2V0IG51 bWJlciBlZmZlY3RpdmVseSBiZWNvbWVzIHBhcnQgb2YgdGhlIGludmFyaWFudHMuPGJyPg0KPGJy Pg0KSW4gc2hvcnQsIHRoZSBvbmx5IGFkdmFudGFnZSBvZiBvcHRpb24gMiBpcyB0byBhdm9pZCBh IHNpbmdsZSBzeW1tZXRyaWMgZW5jcnlwdGlvbiBvcGVyYXRpb24gcGVyIHBhY2tldCwgd2hpbGUg bWFraW5nIHRoZSBjb2RlIHNpZ25pZmljYW50bHkgbW9yZSBjb21wbGV4LCBhbmQgYXQgdGhlIGNv c3Qgb2Ygbm90IHByb3RlY3RpbmcgYWdhaW5zdCBQTiBvc3NpZmljYXRpb24uIFRoZSB3YXkgSSBz ZWUgdGhhdCwgdGhlcmUgaXMgaGFyZGx5IGFueSBkZWJhdGUuPGJyPg0KPGJyPg0KLS0gQ2hyaXN0 aWFuIEh1aXRlbWE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1F436ED13A22A246A59CA374CBC543998B58BAD7ORSMSX111amrcor_-- From nobody Fri Feb 9 13:16:42 2018 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 063121272E1 for ; Fri, 9 Feb 2018 13:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.93 X-Spam-Level: X-Spam-Status: No, score=-6.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 gPydglrvqMN3 for ; Fri, 9 Feb 2018 13:16:37 -0800 (PST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) (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 21238127286 for ; Fri, 9 Feb 2018 13:16:37 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Feb 2018 13:16:36 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,485,1511856000"; d="scan'208,217";a="202978000" Received: from orsmsx103.amr.corp.intel.com ([10.22.225.130]) by fmsmga006.fm.intel.com with ESMTP; 09 Feb 2018 13:16:35 -0800 Received: from orsmsx154.amr.corp.intel.com (10.22.226.12) by ORSMSX103.amr.corp.intel.com (10.22.225.130) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 9 Feb 2018 13:16:35 -0800 Received: from orsmsx111.amr.corp.intel.com ([169.254.12.253]) by ORSMSX154.amr.corp.intel.com ([169.254.11.77]) with mapi id 14.03.0319.002; Fri, 9 Feb 2018 13:16:35 -0800 From: "Deval, Manasi" To: "Deval, Manasi" , Praveen Balasubramanian , David Benjamin CC: Eric Rescorla , "quic@ietf.org" , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW386uUhPOthz0i/5zfm2bWSLKONB2AAgABeoYCAAAgUAIAAd3OAgAA8YgCAACPDAIAAAicAgAOBlYCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADXOQCAAGavgIAAEEkAgACiywCAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5pAIAAEIAAgABFkgCAAAUSgIAABUkAgAABmYCAAAaRgIAAC4qAgACi8QCAAe5xgIAACzgAgAAgsQCAAEAQAIAAiWOAgAA/NgCAACHJgIAABYAA//+Ja8CAAAYT4A== Date: Fri, 9 Feb 2018 21:16:35 +0000 Message-ID: <1F436ED13A22A246A59CA374CBC543998B58BB1B@ORSMSX111.amr.corp.intel.com> References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B58BAD7@ORSMSX111.amr.corp.intel.com> In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B58BAD7@ORSMSX111.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.22.254.139] Content-Type: multipart/alternative; boundary="_000_1F436ED13A22A246A59CA374CBC543998B58BB1BORSMSX111amrcor_" 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: Fri, 09 Feb 2018 21:16:41 -0000 --_000_1F436ED13A22A246A59CA374CBC543998B58BB1BORSMSX111amrcor_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWxsLA0KDQoNCg0KVGhlIGlzc3VlIHdpdGggVENQIGNyeXB0byBvZmZsb2FkIGRvZXMgbm90 IGRpcmVjdGx5IGFwcGx5IHRvIHRoZSBRVUlDIENyeXB0byBvZmZsb2FkLiBGb3IgZXhhbXBsZSwg cmVjZWl2ZWQgVENQIGZyYW1lcyBuZWVkIHRvIGJlIGNvYWxlc2NlZCBiZWZvcmUgZGVjcnlwdGlv bi4gVGhpcyBpcyBhIHByb2hpYml0aXZlIG9wZXJhdGlvbiB0byBhY2hpZXZlIGluIGhhcmR3YXJl IGJ1dCBtdWNoIHNpbXBsZXIgdG8gYWNoaWV2ZSBpbiB0aGUgc29mdHdhcmUuIFRoZSBRVUlDIGRh dGEgZW5jcnlwdGlvbiBhbmQgaGVhZGVyIHVwZGF0ZSBpcyB0aGVyZWZvcmUgYWNoaWV2YWJsZS4N Cg0KDQoNCkVuY3J5cHRpbmcgdGhlIHBhY2tldCBudW1iZXIgY29tcGxpY2F0ZXMgdGhlIGNyeXB0 byBvZmZsb2FkLCB0aG91Z2guIElzIHRoZXJlIGFub3RoZXIgd2F5IHRvIGFjaGlldmUgdGhlIHNh bWUgc2VjdXJpdHk/IEluIHNvbWUgZWFybHkgdGVzdHMgd2l0aCB0aGUgZXhpc3RpbmcgUVVJQyBz dGFja3MsIEkgc2VlIHRoYXQgdGhlIGNyeXB0byBjb3N0IGlzIHF1aXRlIHNpZ25pZmljYW50IHNv IGhpZ2ggc3BlZWQgZGVwbG95bWVudHMgbWF5IGZpbmQgdXNlIG9mIGNyeXB0byBvZmZsb2FkLg0K DQoNCg0KVGhhbmtzLA0KDQpNYW5hc2kNCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgRGV2YWwsIE1hbmFzaQ0KU2VudDogRnJpZGF5LCBG ZWJydWFyeSAwOSwgMjAxOCAxMjo1NSBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxw cmF2YkBtaWNyb3NvZnQuY29tPjsgRGF2aWQgQmVuamFtaW4gPGRhdmlkYmVuQGNocm9taXVtLm9y Zz4NCkNjOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+OyBxdWljQGlldGYub3JnOyBodWl0 ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KU3ViamVjdDogUkU6IFBhY2tldCBudW1iZXIgZW5j cnlwdGlvbg0KDQpHb2luZyBiYWNrIHRvIElhbuKAmXMgcG9pbnQgaGVyZSDigJMgQ2FuIHlvdSBi ZSBleHBsaWNpdCBhYm91dCB0aGUgaXNzdWUgeW91IHNlZSBpbiB0aGUgcGFja2V0IG51bWJlciBl bmNyeXB0aW9uPw0KDQpUaGFua3MsDQpNYW5hc2kNCg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4N ClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMDksIDIwMTggMTE6NTkgQU0NClRvOiBEYXZpZCBCZW5q YW1pbiA8ZGF2aWRiZW5AY2hyb21pdW0ub3JnPG1haWx0bzpkYXZpZGJlbkBjaHJvbWl1bS5vcmc+ Pg0KQ2M6IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPj47 IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+OyBodWl0ZW1hIDxodWl0ZW1hQGh1 aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj4NClN1YmplY3Q6IFJFOiBQYWNr ZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KV2l0aCBWTEUgaXRzIG1pbmltYWwgb3ZlcmhlYWQgcGVy IHBhY2tldCBzbyB5b3UgYXJlIG5vdCBlbmNyeXB0aW5nIDQgYnl0ZXMgbW9yZSBhbGwgdGhlIHRp bWUgZXZlbiB3aXRoIDY0IGJpdCBvciAxMjggYml0IHBhY2tldCBudW1iZXIgLiBTbyBpdHMgZGVj aWRlZGx5IGJldHRlci4gQWxzbyBmZXdlciBjYWxscyBpbnRvIFRMUywgYnV0IEkgc3VwcG9zZSBv bmUgY291bGQgZG8gc29tZSByZWZhY3RvcmluZyBvZiBUTFMgQVBJLiBNYW55IENQVXMgeWVzIGJ1 dCB0aGlzIGlzIGEgZ2VuZXJhbCBwdXJwb3NlIHRyYW5zcG9ydCBhbmQgY291bGQgcnVuIG9uIENQ VXMgdGhhdCBkb27igJl0Lg0KDQpEaWRu4oCZdCBhc2sgZm9yIG5vbmNlIHRvIGJlIHZhcmlhYmxl IGxlbmd0aC4gRml4ZWQgbGVuZ3RoIGZvciBjb25uZWN0aW9uIGxpZmV0aW1lLiBEYXRhY2VudGVy cyBjb25uZWN0aW9ucyBjb3VsZCB1c2UgNjQtYml0IG5vbmNlIHRvIGF2b2lkIGZyZXF1ZW50IGtl eSByb2xsb3Zlci4NCg0KRWZmZWN0aXZlbHkgdGhlIHBsYWluIHRleHQgbm9uY2UgaXMgYSBzZXF1 ZW5jZSBudW1iZXIgc2luY2UgaXQgaW5jcmVhc2VzIG1vbm90b25pY2FsbHkgd2l0aCBzbWFsbCBq dW1wcyBhcyBuZWVkZWQgdG8gYXZvaWQgb3NzaWZpY2F0aW9uLiBTbyBubyB3b3JzZSBvZmYgdGhh biBnUVVJQyBvciBjdXJyZW50IGRyYWZ0LiBObyBtb3JlIGNvbXBsZXggdGhhbiB1c2luZyB0aGUg cGFja2V0IG51bWJlci4gSnVzdCB0aGUgc3RhcnRpbmcgbnVtYmVyIGlzIHJhbmRvbWl6ZWQuIEFs c28gcGxlYXNlIG5vdGljZSB0aGF0IHRoaXMgcHJvcG9zYWwgZG9lcyBub3QgcHJlY2x1ZGUgdXNp bmcgZW5jcnlwdGVkIHBhY2tldCBudW1iZXIgYXMgdGhlIG5vbmNlIGFzIHByb3Bvc2VkIHByZXZp b3VzbHkuIENoYW5naW5nIGhvdyB0aGUgbm9uY2Ugd29ya3MgbWFrZXMgMCBpbXBhY3Qgb24gdGhl IHRyYW5zcG9ydCBsb2dpYy4gQW4gaW1wbGVtZW50YXRpb24gY2FuIGNob29zZSB0byBpbXBsZW1l bnQgYW55IGZvcm0gb2Ygbm9uLXJlcGVhdGluZyBub25jZSB3aXRob3V0IHJldnZpbmcgdGhlIFJG Qy4gVGhpcyBpcyB0aGUgYmlnZ2VzdCBhZHZhbnRhZ2Ugb2Ygc2VwYXJhdGlvbiBvZiBjb25jZXJu cyBJTUhPLg0KDQpGcm9tOiBEYXZpZCBCZW5qYW1pbiBbbWFpbHRvOmRhdmlkYmVuQGNocm9taXVt Lm9yZ10NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgOSwgMjAxOCAxMTozOSBBTQ0KVG86IFByYXZl ZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNy b3NvZnQuY29tPj4NCkNjOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBy dGZtLmNvbT4+OyBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPjsgaHVpdGVtYSA8 aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+DQpTdWJqZWN0 OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCllvdXIgcHJpbWFyeSB3b3JyeSBoZXJl IHdhcyB0aGUgZXh0cmEgYmxvY2sgY2lwaGVyIG9wZXJhdGlvbiwgcmlnaHQ/IEJ5IG1vdmluZyB0 aGUgcGFja2V0IG51bWJlciBpbnRvIHRoZSBwbGFpbnRleHQsIHRoaXMgcHJvcG9zYWwgaW5jcmVh c2VzIHRoZSBsZW5ndGgsIHdoaWNoIHdpbGwgY29zdCB0aGF0IHNhbWUgb25lIGV4dHJhIGJsb2Nr IGNpcGhlciBvcGVyYXRpb24sIG5vPw0KDQpJdCBpcyBvbmUgYmxvY2sgb3BlcmF0aW9uIHVuZGVy IHRoZSBzYW1lIGtleSwgcmF0aGVyIHRoYW4gYSBkaWZmZXJlbnQga2V5IHNvIEkgc3VwcG9zZSB0 aGVyZSBhcmUgbWludXNjdWxlIGNhY2hlIGZvb3RwcmludCB3aW5zIChvbmUgc3ltbWV0cmljIGtl eSBpcyAxNiBvciAzMiBieXRlcykuIEJ1dCB0aGUgY29zdCBpcyBwZXItcGFja2V0ICghKSBiYW5k d2lkdGggYW5kIGNvbXBsZXhpdHkuIEkgZG8gbm90IHNlZSBob3cgdGhpcyBjb3VsZCBiZSB3b3J0 aCBpdC4gTm90ZSB0aGF0LCBmb3IgQUVTLCBtYW55IENQVXMgaGF2ZSBkZWRpY2F0ZWQgaW5zdHJ1 Y3Rpb25zIGZvciBpdCBhbHJlYWR5Lg0KDQo+IENsZWFyIHNlcGFyYXRpb24gb2YgY29uY2VybnMg cmVzdWx0cyBpZiB3ZSBkb27igJl0IG92ZXJsb2FkIHRoZSBwYWNrZXQgbnVtYmVyIGFzIHRoZSBu b25jZS4gQ29ubmVjdGlvbiBtaWdyYXRpb24gYW5kIG11bHRpLXBhdGggYXJlIG9wdGlvbmFsIGZl YXR1cmVzIGFuZCB3ZSBwYXkgbm8gZXh0cmEgY29tcHV0ZSBjb3N0IGZvciBtb3N0IGNvbm5lY3Rp b25zIHRoYXQgYXJlIG5vdCBpbXBhY3RlZCBieSB1bmxua2FiaWxpdHkuIE5vbmNlIGZpZWxkIGJl Y29tZXMgb3B0aW9uYWwgZm9yIGNyeXB0byB0aGF0IGRvZXNu4oCZdCBuZWVkIGl0IGFuZCBjYW4g Z3JvdyB0byBsYXJnZXIgc2l6ZSBhcyBuZWVkZWQgZm9yIGJ1bGsgdHJhbnNmZXJzIHRvIHByZXZl bnQgZnJlcXVlbnQga2V5IHJvbGxvdmVycyAoc2F5IGluIGRhdGFjZW50ZXIgc2NlbmFyaW9zKS4N Cg0KWW91J3JlIG5vdCBnb2luZyB0byBmaW5kIEFFQURzIHRoYXQgZG9uJ3QgcmVxdWlyZSBhIG5v bmNlLiBFbmNyeXB0aW9uIG11c3Qgbm90IHByb2R1Y2UgdGhlIHNhbWUgY2lwaGVydGV4dCB0d2lj ZSBmb3IgdGhlIHNhbWUgcGxhaW50ZXh0LCBzbyB5b3UgbmVlZCBzb21lIGlucHV0IHRvIGRpdmVy c2lmeSB0aGVtLiBUaGF0IGlucHV0IGlzIHRoZSBub25jZS4gTm9uY2VzIGFsc28gYXJlIG5vdCB2 YXJpYWJsZS1sZW5ndGgsIHNvIHlvdSBkb24ndCBnZXQgdG8gYXJiaXRyYXJpbHkgZ3JvdyB0aGVt LiAoQUVTLUdDTSBwZXIgc3BlYyBpcyB2YXJpYWJsZSBsZW5ndGgsIGJ1dCB0aGF0J3MgYSBzcGVj IGJ1Zy4gSWYgeW91IHNpemUgaXQgYWJvdmUgOTYgYml0cywgaXQncyBhcyBpZiB5b3UgcmFuZG9t aXplZCBpdCBhbmQgeW91ciBub25jZSBzcGFjZSBjcmFzaGVzIHBlciBiaXJ0aGRheS4pDQoNCkl0 IGlzIGFsc28gaGFybWZ1bCB0byBzZXBhcmF0ZSB0aGUgdHdvIGNvbmNlcm5zLiBXaGVuIHlvdSBh cmUgYnVpbGRpbmcgYSB0cmFuc3BvcnQsIGRlcml2ZSB0aGUgbm9uY2UgZnJvbSBhIHNlcXVlbmNl IG51bWJlci4gVExTIDEuMiBBRVMtR0NNIHNlcGFyYXRlZCB0aGVtLCB3aGljaCB3YXMgYSBtaXN0 YWtlLiBJdCdzIGxlc3MgZWZmaWNpZW50ICh0aGUgd29ybGQgd2FzdGVkIHF1aXRlIGEgbG90IG9m IGJhbmR3aWR0aCBkdWUgdG8gdGhpcyksIGFuZCBtb3JlIGVycm9yLXByb25lLiBUaGVyZSB3YXMg bm90aGluZyBzdG9wcGluZyBpbXBsZW1lbnRhdGlvbnMgZnJvbSBzZW5kaW5nIHRoZSBzYW1lIG5v bmNlIG9yIGdlbmVyYXRpbmcgbm9uY2VzIHJhbmRvbWx5ICh0aGUgQUVBRHMgd2UgdXNlIGRvbid0 IGhhdmUgbGFyZ2UgZW5vdWdoIG5vbmNlcyBmb3IgdGhhdCksIGFuZCBpbmRlZWQgc29tZSBkaWQg anVzdCB0aGF0LiBJZiB5b3UgdXNlIHNvbWUgc29ydCBvZiBzZXF1ZW5jZSBudW1iZXIsIHlvdSBj YW4gbGVhbiBvbiBleGlzdGluZyB3b3JrIGJvdGggdG8gZmlsdGVyIG91dCB0aGUgb2J2aW91cyBp bXBsZW1lbnRhdGlvbiBtaXN0YWtlcyBhbmQgdG8gYXZvaWQgc2VuZGluZyB1bm5lY2Vzc2FyeSBk YXRhLg0KDQpPbiBGcmksIEZlYiA5LCAyMDE4IGF0IDEyOjM4IFBNIFByYXZlZW4gQmFsYXN1YnJh bWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4g d3JvdGU6DQpMZXQgbWUgdHJ5IHRvIHN1bW1hcml6ZSB0aGUgcHJvcG9zYWwgYWdhaW46DQoNCg0K ICAxLiAgUGFja2V0IG51bWJlciBpcyBpbiB0aGUgZW5jcnlwdGVkIHBvcnRpb24gb2YgdGhlIGhl YWRlciBhbmQgaXMgbm8gbG9uZ2VyIHVzZWQgYXMgdGhlIG5vbmNlLiBJdCBpcyBlbmNvZGVkIGFz IGEgdmFyaWFibGUgbGVuZ3RoIG51bWJlci4gQWx3YXlzIHN0YXJ0cyBhdCAwLg0KDQogICAgICog ICBObyBvc3NpZmljYXRpb24gb2YgUE4NCiAgICAgKiAgIE5vIGxpbmthYmlsaXR5IHVzaW5nIFBO DQogICAgICogICBBbGxvd3MgZm9yIGdyb3d0aCBiZXlvbmQgNjQgYml0cyBpZiBuZWVkZWQgaW4g ZnV0dXJlDQoNCiAgMS4gIFRoZSBub25jZSBpcyBpbiB0aGUgY2xlYXIgaW4gcGxhaW50ZXh0IGhl YWRlci4gSXQgaXMgZ2VuZXJhdGVkIHBlciBwYXRoIGFzIGEgc2VjdXJlIHJhbmRvbSBudW1iZXIu IENhbGwgdGhpcyB0aGUg4oCcc3RhcnRpbmcgdmFsdWXigJ0uIEJvdGggc2lkZXMgTVVTVCBpbml0 aWFsaXplIHRoZSDigJxzdGFydGluZyB2YWx1ZeKAnSBub25jZSBwZXIgcGF0aC4gV2l0aGluIGEg cGF0aCBpdCBncm93cyBtb25vdG9uaWNhbGx5ICh0byBhdm9pZCByZXBlYXRzIGp1c3QgbGlrZSBQ TiB0b2RheSkgYW5kIGNhbiBpbmNsdWRlIHNob3J0IHJhbmRvbSBqdW1wcyBwZXJpb2RpY2FsbHkg c28gdGhhdCBtaWRkbGVib3hlcyBjYW5ub3QgYXNzdW1lIGFueXRoaW5nIGFib3V0IHRoZSBmaWVs ZC4gU2luY2Ugbm9uY2UgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBQTiB0aGUganVtcHMgZG9u4oCZ dCBhZGQgYW55IGNvbXBsZXhpdHkgdG8gdHJhbnNwb3J0IGxvZ2ljLiBKdW1wcyBhcmUgZm9yIGdy ZWFzaW5nIGFuZCBwcmV2ZW50aW5nIG9zc2lmaWNhdGlvbi4gV2hlbiB0aGUgbm9uY2Ugcm9sbHMg b3ZlciBhbmQgcmVhY2hlcyBjbG9zZSB0byB0aGUg4oCcc3RhcnRpbmcgdmFsdWXigJ0sIGtleSBy b2xsb3ZlciBtdXN0IGhhcHBlbi4gQXQgaGlnaCBkYXRhIHJhdGVzIHRoZSBub25jZSBmaWVsZCBj YW4gYmUgNjQtYml0cyB0byBwcmV2ZW50IGZyZXF1ZW50IGtleSByb2xsb3Zlci4gRm9yIGNyeXB0 byB0aGF0IGRvZXNu4oCZdCBuZWVkIG5vbmNlcywgdGhlIGZpZWxkIGNhbiBiZSBvbWl0dGVkLg0K DQogICAgICogICBObyBvc3NpZmljYXRpb24gYmVjYXVzZSB0aGVyZSBpcyBubyBwcmUtZGV0ZXJt aW5lZCBzZXF1ZW5jZSB0byB0aGUgbm9uY2UuDQogICAgICogICBJbiBnUVVJQyBhbmQgdGhlIFJG QyBhcyBkZWZpbmVkIHRoZSBub25jZSBpcyBhIHNpbXBsZSBzZXF1ZW5jZSB0aGF0IGluY3JlbWVu dHMgYnkgb25lLCBzbyB0aGlzIGlzIG5vIHdvcnNlIG9mZiBpbiB0ZXJtcyBvZiBzZWN1cml0eS4g SXQgaXMgbm9uLXJlcGVhdGluZy4NCiAgICAgKiAgIE5vIGxpbmthYmlsaXR5IGJlY2F1c2UgZGlm ZmVyZW50IHBhdGhzIHN0YXJ0IGF0IGEgY29tcGxldGVseSBkaWZmZXJlbnQgcmFuZG9tIG51bWJl ci4gSWYgcmVwZWF0aW5nIGlzIGEgY29uY2VybiB0aGVuIGRpZmZlcmVudCBwYXRocyB1c2UgZGlm ZmVyZW50IGtleXMuIENhcnJpZXMgZm9yd2FyZCB0byBub3QganVzdCBjb25uZWN0aW9uIG1pZ3Jh dGlvbiBidXQgbXV0bGktcGF0aC4NCiAgICAgKiAgIFN1cHBvcnRzIGtleSByb2xsb3ZlciBqdXN0 IGxpa2UgZ1FVSUMgYW5kIGN1cnJlbnRseSBkZWZpbmVkIGRyYWZ0IFJGQy4NCiAgICAgKiAgIEFs bG93cyBmb3Igb21pdHRpbmcgdGhlIG5vbmNlIHdoZW4gd2UgdXNlIGNyeXB0byB0aGF0IGRvZXNu 4oCZdCBuZWVkIGl0Lg0KICAgICAqICAgQWxsb3dzIGZvciBsYXJnZXIgbm9uY2VzIGZvciBoaWdo IGRhdGEgcmF0ZXMuDQogICAgICogICBJdCBkb2VzbuKAmXQgcHJlY2x1ZGUgYW55IG90aGVyIHR5 cGUgb2Ygbm9uLXJlcGVhdGluZyBub25jZXMgd2l0aG91dCBoYXZpbmcgdG8gbW9kaWZ5IHRoZSBS RkMhIFNvIGltcGxlbWVudGF0aW9ucyB0aGF0IHdhbnQgdG8gdXNlIGNyeXB0b2dyYXBoaWMgbm9u Y2VzIGNhbiBzdGlsbCBkbyBzby4NCg0KVGhlIGRvd25zaWRlczoNCg0KICAxLiAgRXZlbiB3aXRo IHZhcmlhYmxlIGxlbmd0aCBlbmNvZGluZyB0aGUgZXh0cmEgUE4gZmllbGQgaXMgbW9yZSBzcGFj ZSB1c2VkIHBlciBwYWNrZXQgd2hlbiBhIG5vbmNlIGlzIHJlcXVpcmVkLiBJIHRoaW5rIHdlIGNh biBkbyB3aXRoIDIgYnl0ZXMgaW4gdmVyc2lvbiAxLg0KICAyLiAgSXTigJlzIG5vdCBwZXJmZWN0 IHVubGlua2FiaWx0aXkgYnV0IEkgaGF2ZSB5ZXQgdG8gc2VlIGFueSBzb2x1dGlvbiB0aGF0IGNh biBwcm92aWRlIHRoaXMuIEEgc2ltcGxlIHRpbWUgYmFzZWQgYW5hbHlzaXMgdXNpbmcgbWFjaGlu ZSBsZWFybmluZyB3aWxsIGFsbG93IGZsb3cgY29ycmVsYXRpb24gZXNwZWNpYWxseSBmb3IgY29u bmVjdGlvbiBtaWdyYXRpb24uIFRoZSBJUCBhZGRyZXNzZXMgaW4gdGhlIGNsZWFyIGFsbG93IGZv ciBhIGhpZ2ggZGVncmVlIG9mIGNvcnJlbGF0aW9uLiBUaGVyZSBpcyBhbHNvIHRoZSBhcHBsaWNh dGlvbiBzZW5kaW5nIHBhdHRlcm4gYW5kIG90aGVyIHNpZ25hbHMgdGhhdCBjb3VsZCBiZSB1c2Vk Lg0KDQpGcm9tOiBFcmljIFJlc2NvcmxhIFttYWlsdG86ZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JA cnRmbS5jb20+XQ0KU2VudDogRnJpZGF5LCBGZWJydWFyeSA5LCAyMDE4IDU6NTIgQU0NClRvOiBQ cmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWljcm9zb2Z0LmNvbTxtYWlsdG86cHJhdmJA bWljcm9zb2Z0LmNvbT4+DQpDYzogaHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldDxtYWlsdG86 aHVpdGVtYUBodWl0ZW1hLm5ldD4+OyBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3Jn Pg0KDQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCg0KDQpPbiBUaHUs IEZlYiA4LCAyMDE4IGF0IDk6NDAgUE0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBt aWNyb3NvZnQuY29tPG1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpBY3R1YWxs eSB0YWtpbmcgYSBzdGVwIGJhY2sgd2hhdCBpZiB3ZSBkb27igJl0IHdlIG92ZXJsb2FkZWQgcGFj a2V0IG51bWJlciBhcyB0aGUgbm9uY2U/DQoNCkNhbiB3ZToNCg0KICAxLiAgUHV0IHBhY2tldCBu dW1iZXIgYXMgYSBzZXBhcmF0ZSB2YXJpYWJsZSBsZW5ndGggZmllbGQgaW4gdGhlIGVuY3J5cHRl ZCBwb3J0aW9uIG9mIHRoZSBoZWFkZXIuIFRoaXMgYWxsb3dzIGZvciBncm93dGggYmV5b25kIDY0 IGJpdHMgaW4gZnV0dXJlIGFuZCBjb21wbGV0ZWx5IGF2b2lkcyBvc3NpZmljYXRpb24uIEZvciBz aG9ydCBsaXZlZCBmbG93cyB2YXJpYWJsZSBsZW5ndGggZW5jb2RpbmcgbGVhZHMgdG8gbWluaW1h bCBzcGFjZSBvdmVyaGVhZC4NCiAgMi4gIFB1dCBhIHNlcGFyYXRlIHBsYWludGV4dCBub25jZSB3 aGljaCBzdGFydHMgb3V0IGFzIGEgc2VjdXJlIHJhbmRvbSBudW1iZXIgYW5kIG1vbm90b25pY2Fs bHkgaW5jcmVhc2VzIGFzIHNob3J0IHJhbmRvbSBqdW1wcyAoZXZlcnkgcGFja2V0IG9yIGV2ZXJ5 IGZldyBwYWNrZXRzKSBhbmQgY291bGQgdGhlbiByb2xsb3Zlci4gVGhpcyB3aWxsIHByZXZlbnQg bGlua2FiaWxpdHkgYW5kIHNjYWxlcyB0byBtdWx0aS1wYXRoIGFzIHdlbGwuIE5vIG1ham9yIGNv bXB1dGUgb3ZlcmhlYWQuIFdlIGNhbiBhbHNvIG1ha2UgdGhlIG5vbmNlIG9wdGlvbmFsIGZvciBj cnlwdG8gYWxnb3JpdGhtcyB0aGF0IGRvIG5vdCBuZWVkIGEgbm9uY2Ugc2F2aW5nIG1vcmUgc3Bh Y2UuDQoNCkknbSBub3Qgc3VyZSBob3cgdG8gZG8gIzIgc2FmZWx5IGFuZCBlZmZpY2llbnRseS4g VGhlIHByaW1hcnkgY29uY2VybiBpcyB0aGF0IHNob3J0IHJhbmRvbSBqdW1wcyBkb24ndCBhY3R1 YWxseSBwcmV2ZW50IGxpbmthYmlsaXR5IGJlY2F1c2UgdGhlIGhpZ2ggb3JkZXIgYml0cyBkb24n dCBjaGFuZ2UgYW5kIGxvbmcgcmFuZG9tIGp1bXBzIGFyZSBlZmZlY3RpdmVseSByYW5kb21seSBz YW1wbGluZyBvdXQgb2YgdGhlIG5vbmNlIHNwYWNlLCBhbmQgeW91IHN0YXJ0IHRvIHJ1biBpbnRv IGJpcnRoZGF5IHByb2JsZW1zLiBBZGRpdGlvbmFsbHksIHRoZSBjaGVhcGVzdCBQUk5HcyBhcmUg YmFzaWNhbGx5IGNpcGhlcnMgaW4gY291bnRlciBtb2RlLCBzbyBhdCBiZXN0IHlvdSdyZSBnb2lu ZyB0byBnZXQgYSBzbWFsbCBhbW91bnQgb2Ygb3ZlcmhlYWQgcmVkdWN0aW9uIGJ5IGdldHRpbmcg bXVsdGlwbGUganVtcCBjb21wdXRhdGlvbnMgb3V0IG9mIGEgc2luZ2xlIGJsb2NrLCB0aG91Z2gg aWYgeW91IHVzZSA5Ni1iaXQganVtcHMsIHlvdSBvbmx5IGdldCAyNSUgc2F2aW5ncy4uLg0KDQot RWtyDQoNCg0KDQpTb21lIE1TQiBvZiB0aGUgbm9uY2UgY291bGQgYmUgdXNlZCBmb3Igc2lnbmFs aW5nIHJlb3JkZXIgdG8gdGhlIG5ldHdvcmsgaWYgbmVlZGVkLiBJIGRvbuKAmXQgaGF2ZSB0aGUg aGlzdG9yaWNhbCBjb250ZXh0IGZvciBvdmVybG9hZGluZyBvZiBQTiBhcyB0aGUgbm9uY2Ugc28g cGFyZG9uIG1lIGlmIHVuLW92ZXJsb2FkaW5nIG9wdGlvbiB3YXMgZGlzY3Vzc2VkIGFuZCBydWxl ZCBvdXQgYmVmb3JlLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUHJhdmVlbiBCYWxh c3VicmFtYW5pYW4NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDU6NTEgUE0NClRv OiBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0 Pj47IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogUGFj a2V0IG51bWJlciBlbmNyeXB0aW9uDQoNCj4+IGFuZCB1c2luZyBzZXBhcmF0ZSBwYWNrZXQgc2Vx dWVuY2VzIGZvciBlYWNoIHBhdGgNClRoaXMgYWxvbmUgcHJldmVudHMgbGlua2FiaWxpdHkgcmln aHQ/DQoNCj4+IFRoZSBwYWNrZXQgbnVtYmVyIG9uIGVhY2ggcGF0aCB3aWxsIHN0YXJ0IGF0IDEg KG9yIG1heWJlIDAgOy0pLg0KSXMgc3VwcG9ydGluZyBtdWx0aXBsZSBwYXRocyBhdCB0aGUgc2Ft ZSB0aW1lIGEgZ29hbD8gSWYgeWVzLCB0aGVuIHllcyBhbGwgcGF0aHMgd2lsbCBuZWVkIHRvIGhh dmUgc2VwYXJhdGUgdHJhY2tpbmcgYW5kIEFDSyBzdGF0ZSBhbmQgY29uZ2VzdGlvbiBjb250cm9s IGV0Yy4gSSB0aG91Z2h0IHRoaXMgaXMgbm90IHBhcnQgb2YgVjEgUkZDLiBJZiBpdHMganVzdCBv bmUgYWRkaXRpb25hbCBwYXRoIGZvciBjb25uZWN0aW9uIG1pZ3JhdGlvbiBzY2VuYXJpbyB0aGVu IGFsbCB5b3UgbmVlZCBpcyBhIChyYW5kb20pIGp1bXAgdG8gYSBvZmZzZXQgaW4gcGFja2V0IG51 bWJlciBzcGFjZSBmb3IgdGhlIG5ldyBwYXRoIHNvIHRoYXQgdGhlIGZldyBwYWNrZXRzIGluIHRo ZSBvbGQgcGF0aCBjYW4gY29udGludWUgZm9yIGEgbGl0dGxlIGJpdC4gVGhpcyB3b3JrcyB3aXRo IGp1c3Qgb25lIEFDSyBzcGFjZSBzbyBubyBpbXBsZW1lbnRhdGlvbiBjb21wbGV4aXR5Lg0KDQo+ PiAyKSBPciwgbGVhdmluZyB0aGUgcGFja2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVzaW5n IGRpZmZlcmVudCBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2luZyBz ZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBlYWNoIHBhdGguDQpJbiBhZGRpdGlvbiBpZiB0 aGUgdmFsdWUgaW4gdGhlIGNsZWFyIHdhcyBvYmZ1c2NhdGVkIHdpdGggYW4gWE9SIHRyYW5zZm9y bSBpdCB3aWxsIGhlbHAgcHJldmVudCBvc3NpZmljYXRpb24uIFRoZSBvYmZ1c2NhdGlvbiBpcyBu b3QgbWVhbnQgdG8gZ3VhcmQgYWdhaW5zdCBsYXRlciBhbmFseXNpcyB0aGF0IHJldmVhbHMgdGhl IHBhY2tldCBudW1iZXJzIC0gd2h5IGRvIHdlIGNhcmUgYWJvdXQgdGhhdC4gSXQgaXMgbWVhbnQg dG8gZ3JlYXNlIHRoZSBzcGFjZSBhbmQgbm90IG1ha2UgdGhlIG51bWJlcnMgc2VyaWFsIHNvIG1p ZGRsZWJveGVzIGNhbm5vdCBhc3N1bWUgb3JkZXJpbmcgZXRjLg0KDQpBbGwgc2FpZCBpZiBJIGFt IGFsb25lIGluIGJlaW5nIGNvbmNlcm5lZCBhYm91dCB0aGUgcGVyZiBoaXQgdGhlbiBJ4oCZZCBz YXkgZ28gb24gd2l0aCBvcHRpb24gMS4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGlhbiBIdWl0ZW1hDQpTZW50OiBUaHVyc2Rh eSwgRmVicnVhcnkgOCwgMjAxOCAzOjU0IFBNDQpUbzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVp Y0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24NCg0KDQpP biAyLzgvMjAxOCAxOjEzIFBNLCBNaWtlIEJpc2hvcCB3cm90ZToNCiMyIHdvbuKAmXQgd29yay4g IFRoZSBwYWNrZXQgbnVtYmVyIGlzIGFuIGlucHV0IHRvIHRoZSBBRUFEIG5vbmNlLCBzbyB5b3Ug aGF2ZSB0byBnZXQgdG8gdGhlIHBhY2tldCBudW1iZXIgYmVmb3JlIHlvdSBjYW4gZGVjcnlwdCB0 aGUgcGF5bG9hZC4gIEl0IGNhbuKAmXQgYmUgYmFzZWQgb24gYW55dGhpbmcgaW50ZXJuYWwgdG8g dGhlIGVuY3J5cHRlZCBwYWNrZXQuDQoNCkluIE1hcnRpbuKAmXMgcHJvcG9zYWwsIGl04oCZcyB1 c2luZyBhIGNvbWJpbmF0aW9uIG9mIHRoZSBlbmNyeXB0ZWQgcGF5bG9hZCAod2hpY2ggcmVxdWly ZXMgbm90aGluZyB0byBhY2Nlc3MpIGFuZCBzb21lIHN0b3JlZCBzdGF0ZSBvbiBlYWNoIGVuZHBv aW50LCB3aGljaCByZXF1aXJlcyBvbmx5IHRoZSBDb25uZWN0aW9uIElEIHRvIGxvb2sgdXAuICBZ b3Ugd2FudCB0aGUgdGhpbmcgeW91IFhPUiBieSB0byBiZSBjb25zdGFudGx5IGNoYW5naW5nLCBv ciBpdCBiZWNvbWVzIGVhc2llciB0byBsb29rIGF0IHNlcXVlbmNlcyBvZiBvYmZ1c2NhdGVkIHBh Y2tldCBudW1iZXJzIGFuZCBzdGFydCBkcmF3aW5nIGluZmVyZW5jZXMgYWJvdXQgd2hhdCB0aGUg WE9SIHZhbHVlIGlzLiAgSWYgb3ZlcmhlYWQgaXMgdGhlIHByaW1hcnkgY29uY2VybiwgSSB0aGlu ayB0aGVyZSBhcmUgYSBjb3VwbGUgYXBwcm9hY2hlcyB0aGF0IG1pZ2h0IGFsbG93IHlvdSB0byBw cmVjb21wdXRlIHZhbHVlcyBhbmQgYW1vcnRpemUgdGhlIGNvc3Qgb2YgZG9pbmcgdGhlIGVuY3J5 cHRpb24gc3RlcC4gIChBdCB0aGUgY29zdCBvZiBrZWVwaW5nIHRoZSB0YWJsZSBvZiBwcmVjb21w dXRlZCB2YWx1ZXMsIG9mIGNvdXJzZS4pDQoNCkkgc3RpbGwgdGhpbmsgSmFuYeKAmXMgcHVzaGlu ZyBpbiB0aGUgcmlnaHQgZGlyZWN0aW9uIGhlcmU6ICBMZXTigJlzIGFncmVlIG9uIGdvYWxzLCBh bmQgdGhlbiBzZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWduIHRoYXQgbWVldHMgdGhvc2UgZ29h bHMuICBJIGhlYXIgeW91IHNheWluZyB0aGF0IGxvdyBvdmVyaGVhZCBpcyBhIGdvYWwsIHdoaWNo IEkgdGhpbmsgd2UgY2FuIGFsbCBhZ3JlZSBvbi4gIEkgYWxzbyB0aGluayBJIGhlYXIgeW91IHNh eWluZyB0aGF0IDEtMS41JSBvdmVyaGVhZCBpcyB0b28gaGlnaCwgYnV0IGl0IHNvdW5kcyBsaWtl IHRoZXJl4oCZcyBsZXNzIGFncmVlbWVudCBvbiB0aGF0LiAgWW91IGFsc28gcmFpc2UgYW4gaW50 ZXJlc3RpbmcgcG9pbnQgdGhhdCBzb21lIGNsaWVudHMgd2lsbCBjYXJlIGxlc3MgYWJvdXQgbGlu a2FiaWxpdHkgYmVjYXVzZSB0aGV5IHdpbGwgbmV2ZXIgaW50ZW50aW9uYWxseSBtaWdyYXRlLg0K DQpJIHRoaW5rIFZpY3RvciBzYWlkIGl0IGJlc3QsICJPYmZ1c2NhdGlvbiBpcyBqdXN0IGVuY3J5 cHRpb24gZG9uZSBwb29ybHkuIiBFaXRoZXIgd2UgZW5jcnlwdCwgb3Igd2UgZG9uJ3QuIEJ1dCB0 aGVyZSBpcyBubyBzdWNoIHRoaW5nIGFzIGFuIG9iZnVzY2F0aW9uIG1pZGRsZS1ncm91bmQuIE9i ZnVzY2F0aW9uIHdvdWxkIGp1c3QgYmUgYSBzcGVlZCBidW1wLCBlYXNpbHkgYnJva2VuLiBJdCB3 b24ndCBwcm92aWRlIHByaXZhY3ksIGFuZCBpdCB3b24ndCBwcmV2ZW50IGxpbmthYmlsaXR5Lg0K DQpBcyBmYXIgYXMgSSBhbSBjb25jZXJuZWQsIHRoZXJlIGFyZSBvbmx5IHR3byBkZXNpZ25zIHRo YXQgcHJldmVudCBsaW5rYWJpbGl0eToNCg0KMSkgTWFydGluJ3MgUFIsIGluIHdoaWNoIHRoZSBw YWNrZXQgbnVtYmVyIGlzIGVuY3J5cHRlZCB1c2luZyBzZW5zaWJsZSBjcnlwdG87DQoNCjIpIE9y LCBsZWF2aW5nIHRoZSBwYWNrZXQgbnVtYmVyIGluIHRoZSBjbGVhciBidXQgdXNpbmcgZGlmZmVy ZW50IGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgYW5kIHVzaW5nIHNlcGFyYXRl IHBhY2tldCBzZXF1ZW5jZXMgZm9yIGVhY2ggcGF0aC4NCg0KVGhlIHNlY29uZCBvcHRpb24gcmVx dWlyZXMgbW9yZSBjb21wdXRhdGlvbiB3aGVuIGV4cGxpY2l0bHkgc2V0dGluZyB1cCBhIG5ldyBw YXRoLiBUaGUgY29ubmVjdGlvbiBJRCB3b3VsZCBiZSB1c2VkIGFzIHBhcnQgb2YgdGhlICJzYWx0 IiB3aGVuIGRlcml2aW5nIGNvbm5lY3Rpb24gY29udGV4dHMuIFRoZSBwYWNrZXQgbnVtYmVyIG9u IGVhY2ggcGF0aCB3aWxsIHN0YXJ0IGF0IDEgKG9yIG1heWJlIDAgOy0pLiBUaGlzIHJlcXVpcmVz IG1haW50YWluaW5nIHNlcGFyYXRlIFNBQ0sgZGFzaGJvYXJkcyBmb3IgZWFjaCBwYXRoL0Nvbm5l Y3Rpb24tSUQsIGFuZCBjb25zdHJhaW5pbmcgQUNLIHRvIGJlIHBlci9wYXRoLCBvciBhbHRlcm5h dGl2ZWx5IGFkZGluZyBhIFBBVEgtQUNLIGZyYW1lIHRoYXQgaW5kaWNhdGVzIHRoZSBwYXRoIGZv ciB3aGljaCBwYWNrZXRzIGFyZSBhY2tlZC4NCg0KVGhlIHByb3MgYW5kIGNvbnMgb2YgdGhlIHR3 byBvcHRpb25zIGFyZSBlYXN5IHRvIGdldDoNCg0KMSkgT3B0aW9uIDIgZG9lcyBub3QgcmVxdWly ZSB0aGUgY29zdCBvZiBlbmNyeXB0aW5nIGV2ZXJ5IHBhY2tldCwgdGh1cyBwZXIgcGFja2V0IHBy b2Nlc3Npbmcgd2lsbCBiZSBtYXliZSAxJSBmYXN0ZXIgdGhhbiBvcHRpb24gMS4NCg0KMikgT3B0 aW9uIDIgcmVxdWlyZXMgY29tcHV0aW5nIGVuY3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0 aCwgd2hpY2ggaXMgbW9yZSBjb21wbGV4IHRoYW4gb3B0aW9uIDEsIGJ1dCB0aGUgY29zdCB3aWxs IGJlIGFtb3J0aXplZCBvdmVyIHRoZSBkdXJhdGlvbiBvZiB0aGUgcGF0aC4NCg0KMykgT3B0aW9u IDIgcmVxdWlyZXMgbW9yZSBjb21wbGV4IGRhdGEgc3RydWN0dXJlcyBhbmQgQUNLIG1hbmFnZW1l bnQsIHRodXMgaW5jcmVhc2luZyB0aGUgY2hhbmNlcyB0aGF0IHNvbWV0aGluZyBnb2VzIHdyb25n Lg0KDQo0KSBPcHRpb24gMiBkb2VzIG5vdGhpbmcgYWdhaW5zdCBwYWNrZXQgbnVtYmVyIG9zc2lm aWNhdGlvbi4gVGhlIHBhY2tldCBudW1iZXIgZWZmZWN0aXZlbHkgYmVjb21lcyBwYXJ0IG9mIHRo ZSBpbnZhcmlhbnRzLg0KDQpJbiBzaG9ydCwgdGhlIG9ubHkgYWR2YW50YWdlIG9mIG9wdGlvbiAy IGlzIHRvIGF2b2lkIGEgc2luZ2xlIHN5bW1ldHJpYyBlbmNyeXB0aW9uIG9wZXJhdGlvbiBwZXIg cGFja2V0LCB3aGlsZSBtYWtpbmcgdGhlIGNvZGUgc2lnbmlmaWNhbnRseSBtb3JlIGNvbXBsZXgs IGFuZCBhdCB0aGUgY29zdCBvZiBub3QgcHJvdGVjdGluZyBhZ2FpbnN0IFBOIG9zc2lmaWNhdGlv bi4gVGhlIHdheSBJIHNlZSB0aGF0LCB0aGVyZSBpcyBoYXJkbHkgYW55IGRlYmF0ZS4NCg0KLS0g Q2hyaXN0aWFuIEh1aXRlbWENCg0K --_000_1F436ED13A22A246A59CA374CBC543998B58BB1BORSMSX111amrcor_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4t dG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1p bHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MzU2MzUwMjI3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo1MTIyODIyMDI7fQ0K QGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28t bGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21z by1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo0MTQ3NDQ0OTQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjE0Mzk1NDA5Mjt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDUN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZl bC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyDQoJe21z by1saXN0LWlkOjgzODQyMTcxMjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTI0OTIxMTE2O30N CkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47fQ0KQGxpc3QgbDI6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDYN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJe21zby1sZXZl bC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPkhpIEFsbCw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhlIGlzc3VlIHdpdGggVENQIGNyeXB0byBv ZmZsb2FkIGRvZXMgbm90IGRpcmVjdGx5IGFwcGx5IHRvIHRoZSBRVUlDIENyeXB0byBvZmZsb2Fk LiBGb3IgZXhhbXBsZSwgcmVjZWl2ZWQgVENQIGZyYW1lcyBuZWVkIHRvIGJlIGNvYWxlc2NlZCBi ZWZvcmUgZGVjcnlwdGlvbi4gVGhpcyBpcyBhIHByb2hpYml0aXZlIG9wZXJhdGlvbiB0byBhY2hp ZXZlIGluIGhhcmR3YXJlIGJ1dCBtdWNoIHNpbXBsZXIgdG8NCiBhY2hpZXZlIGluIHRoZSBzb2Z0 d2FyZS4gVGhlIFFVSUMgZGF0YSBlbmNyeXB0aW9uIGFuZCBoZWFkZXIgdXBkYXRlIGlzIHRoZXJl Zm9yZSBhY2hpZXZhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5FbmNyeXB0aW5n IHRoZSBwYWNrZXQgbnVtYmVyIGNvbXBsaWNhdGVzIHRoZSBjcnlwdG8gb2ZmbG9hZCwgdGhvdWdo LiBJcyB0aGVyZSBhbm90aGVyIHdheSB0byBhY2hpZXZlIHRoZSBzYW1lIHNlY3VyaXR5PyBJbiBz b21lIGVhcmx5IHRlc3RzIHdpdGggdGhlIGV4aXN0aW5nIFFVSUMgc3RhY2tzLCBJIHNlZSB0aGF0 IHRoZSBjcnlwdG8gY29zdCBpcyBxdWl0ZSBzaWduaWZpY2FudCBzbyBoaWdoIHNwZWVkDQogZGVw bG95bWVudHMgbWF5IGZpbmQgdXNlIG9mIGNyeXB0byBvZmZsb2FkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij5NYW5hc2k8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBR VUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5E ZXZhbCwgTWFuYXNpPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgMDksIDIwMTgg MTI6NTUgUE08YnI+DQo8Yj5Ubzo8L2I+IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDtwcmF2 YkBtaWNyb3NvZnQuY29tJmd0OzsgRGF2aWQgQmVuamFtaW4gJmx0O2RhdmlkYmVuQGNocm9taXVt Lm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZn dDs7IHF1aWNAaWV0Zi5vcmc7IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5Hb2luZyBiYWNrIHRvIElhbuKAmXMgcG9pbnQgaGVyZSDigJMgQ2FuIHlvdSBiZSBleHBsaWNp dCBhYm91dCB0aGUgaXNzdWUgeW91IHNlZSBpbiB0aGUgcGFja2V0IG51bWJlciBlbmNyeXB0aW9u Pw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGFua3MsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPk1hbmFzaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86 cXVpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0N CjxiPk9uIEJlaGFsZiBPZiA8L2I+UHJhdmVlbiBCYWxhc3VicmFtYW5pYW48YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBGZWJydWFyeSAwOSwgMjAxOCAxMTo1OSBBTTxicj4NCjxiPlRvOjwvYj4g RGF2aWQgQmVuamFtaW4gJmx0OzxhIGhyZWY9Im1haWx0bzpkYXZpZGJlbkBjaHJvbWl1bS5vcmci PmRhdmlkYmVuQGNocm9taXVtLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBFcmljIFJlc2Nv cmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+Jmd0 OzsgPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPg0KcXVpY0BpZXRmLm9yZzwvYT47IGh1 aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Ij5odWl0ZW1hQGh1 aXRlbWEubmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFBhY2tldCBudW1iZXIg ZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCBW TEUgaXRzIG1pbmltYWwgb3ZlcmhlYWQgcGVyIHBhY2tldCBzbyB5b3UgYXJlIG5vdCBlbmNyeXB0 aW5nIDQgYnl0ZXMgbW9yZSBhbGwgdGhlIHRpbWUgZXZlbiB3aXRoIDY0IGJpdCBvciAxMjggYml0 IHBhY2tldCBudW1iZXIgLiBTbyBpdHMgZGVjaWRlZGx5IGJldHRlci4gQWxzbyBmZXdlciBjYWxs cyBpbnRvIFRMUywgYnV0IEkgc3VwcG9zZSBvbmUgY291bGQgZG8gc29tZSByZWZhY3RvcmluZyBv Zg0KIFRMUyBBUEkuIE1hbnkgQ1BVcyB5ZXMgYnV0IHRoaXMgaXMgYSBnZW5lcmFsIHB1cnBvc2Ug dHJhbnNwb3J0IGFuZCBjb3VsZCBydW4gb24gQ1BVcyB0aGF0IGRvbuKAmXQuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+RGlkbuKAmXQgYXNrIGZvciBub25jZSB0byBiZSB2YXJpYWJsZSBsZW5n dGguIEZpeGVkIGxlbmd0aCBmb3IgY29ubmVjdGlvbiBsaWZldGltZS4gRGF0YWNlbnRlcnMgY29u bmVjdGlvbnMgY291bGQgdXNlIDY0LWJpdCBub25jZSB0byBhdm9pZCBmcmVxdWVudCBrZXkgcm9s bG92ZXIuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RWZmZWN0aXZlbHkgdGhlIHBsYWluIHRl eHQgbm9uY2UgaXMgYSBzZXF1ZW5jZSBudW1iZXIgc2luY2UgaXQgaW5jcmVhc2VzIG1vbm90b25p Y2FsbHkgd2l0aCBzbWFsbCBqdW1wcyBhcyBuZWVkZWQgdG8gYXZvaWQgb3NzaWZpY2F0aW9uLiBT byBubyB3b3JzZSBvZmYgdGhhbiBnUVVJQyBvciBjdXJyZW50IGRyYWZ0LiBObyBtb3JlIGNvbXBs ZXggdGhhbiB1c2luZyB0aGUgcGFja2V0IG51bWJlci4gSnVzdCB0aGUNCiBzdGFydGluZyBudW1i ZXIgaXMgcmFuZG9taXplZC4gQWxzbyBwbGVhc2Ugbm90aWNlIHRoYXQgdGhpcyBwcm9wb3NhbCBk b2VzIG5vdCBwcmVjbHVkZSB1c2luZyBlbmNyeXB0ZWQgcGFja2V0IG51bWJlciBhcyB0aGUgbm9u Y2UgYXMgcHJvcG9zZWQgcHJldmlvdXNseS4gQ2hhbmdpbmcgaG93IHRoZSBub25jZSB3b3JrcyBt YWtlcyAwIGltcGFjdCBvbiB0aGUgdHJhbnNwb3J0IGxvZ2ljLiBBbiBpbXBsZW1lbnRhdGlvbiBj YW4gY2hvb3NlIHRvIGltcGxlbWVudA0KIGFueSBmb3JtIG9mIG5vbi1yZXBlYXRpbmcgbm9uY2Ug d2l0aG91dCByZXZ2aW5nIHRoZSBSRkMuIFRoaXMgaXMgdGhlIGJpZ2dlc3QgYWR2YW50YWdlIG9m IHNlcGFyYXRpb24gb2YgY29uY2VybnMgSU1ITy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ RnJvbTo8L2I+IERhdmlkIEJlbmphbWluIFs8YSBocmVmPSJtYWlsdG86ZGF2aWRiZW5AY2hyb21p dW0ub3JnIj5tYWlsdG86ZGF2aWRiZW5AY2hyb21pdW0ub3JnPC9hPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDksIDIwMTggMTE6MzkgQU08YnI+DQo8Yj5Ubzo8L2I+IFBy YXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0 LmNvbSI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBFcmljIFJl c2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208L2E+ Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPg0KcXVpY0BpZXRmLm9yZzwvYT47 IGh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Ij5odWl0ZW1h QGh1aXRlbWEubmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFBhY2tldCBudW1i ZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91ciBwcmltYXJ5 IHdvcnJ5IGhlcmUgd2FzIHRoZSBleHRyYSBibG9jayBjaXBoZXIgb3BlcmF0aW9uLCByaWdodD8g QnkgbW92aW5nIHRoZSBwYWNrZXQgbnVtYmVyIGludG8gdGhlIHBsYWludGV4dCwgdGhpcyBwcm9w b3NhbCBpbmNyZWFzZXMgdGhlIGxlbmd0aCwgd2hpY2ggd2lsbCBjb3N0IHRoYXQgc2FtZSBvbmUg ZXh0cmEgYmxvY2sgY2lwaGVyIG9wZXJhdGlvbiwgbm8/PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaXMgb25lIGJsb2NrIG9wZXJhdGlvbiB1 bmRlciB0aGUgc2FtZSBrZXksIHJhdGhlciB0aGFuIGEgZGlmZmVyZW50IGtleSBzbyBJIHN1cHBv c2UgdGhlcmUgYXJlIG1pbnVzY3VsZSZuYnNwO2NhY2hlIGZvb3RwcmludCB3aW5zIChvbmUgc3lt bWV0cmljIGtleSBpcyAxNiBvciAzMiBieXRlcykuIEJ1dCB0aGUgY29zdCBpcyBwZXItcGFja2V0 ICghKSBiYW5kd2lkdGggYW5kIGNvbXBsZXhpdHkuIEkgZG8gbm90IHNlZQ0KIGhvdyB0aGlzIGNv dWxkIGJlIHdvcnRoIGl0LiZuYnNwO05vdGUgdGhhdCwgZm9yIEFFUywgbWFueSBDUFVzIGhhdmUg ZGVkaWNhdGVkIGluc3RydWN0aW9ucyBmb3IgaXQgYWxyZWFkeS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsmbmJzcDtDbGVhciBzZXBhcmF0aW9uIG9mIGNvbmNlcm5zIHJlc3VsdHMgaWYgd2UgZG9u 4oCZdCBvdmVybG9hZCB0aGUgcGFja2V0IG51bWJlciBhcyB0aGUgbm9uY2UuIENvbm5lY3Rpb24g bWlncmF0aW9uIGFuZCBtdWx0aS1wYXRoIGFyZSBvcHRpb25hbCBmZWF0dXJlcyBhbmQgd2UgcGF5 IG5vIGV4dHJhIGNvbXB1dGUgY29zdCBmb3IgbW9zdCBjb25uZWN0aW9ucyB0aGF0IGFyZSBub3Qg aW1wYWN0ZWQgYnkgdW5sbmthYmlsaXR5Lg0KIE5vbmNlIGZpZWxkIGJlY29tZXMgb3B0aW9uYWwg Zm9yIGNyeXB0byB0aGF0IGRvZXNu4oCZdCBuZWVkIGl0IGFuZCBjYW4gZ3JvdyB0byBsYXJnZXIg c2l6ZSBhcyBuZWVkZWQgZm9yIGJ1bGsgdHJhbnNmZXJzIHRvIHByZXZlbnQgZnJlcXVlbnQga2V5 IHJvbGxvdmVycyAoc2F5IGluIGRhdGFjZW50ZXIgc2NlbmFyaW9zKS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Zb3UncmUgbm90IGdvaW5nIHRvIGZpbmQgQUVBRHMgdGhhdCBkb24ndCByZXF1aXJlIGEg bm9uY2UuIEVuY3J5cHRpb24gbXVzdCBub3QgcHJvZHVjZSB0aGUgc2FtZSBjaXBoZXJ0ZXh0IHR3 aWNlIGZvciB0aGUgc2FtZSBwbGFpbnRleHQsIHNvIHlvdSBuZWVkIHNvbWUgaW5wdXQgdG8gZGl2 ZXJzaWZ5IHRoZW0uIFRoYXQgaW5wdXQgaXMgdGhlIG5vbmNlLiBOb25jZXMgYWxzbyBhcmUgbm90 IHZhcmlhYmxlLWxlbmd0aCwNCiBzbyB5b3UgZG9uJ3QgZ2V0IHRvIGFyYml0cmFyaWx5IGdyb3cg dGhlbS4gKEFFUy1HQ00gcGVyIHNwZWMgaXMgdmFyaWFibGUgbGVuZ3RoLCBidXQgdGhhdCdzIGEg c3BlYyBidWcuIElmIHlvdSBzaXplIGl0IGFib3ZlIDk2IGJpdHMsIGl0J3MgYXMgaWYgeW91IHJh bmRvbWl6ZWQgaXQgYW5kIHlvdXIgbm9uY2Ugc3BhY2UgY3Jhc2hlcyBwZXIgYmlydGhkYXkuKTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBp cyBhbHNvIGhhcm1mdWwgdG8gc2VwYXJhdGUgdGhlIHR3byBjb25jZXJucy4mbmJzcDtXaGVuIHlv dSBhcmUgYnVpbGRpbmcgYSB0cmFuc3BvcnQsIGRlcml2ZSB0aGUgbm9uY2UgZnJvbSBhIHNlcXVl bmNlIG51bWJlci4gVExTIDEuMiBBRVMtR0NNIHNlcGFyYXRlZCB0aGVtLCB3aGljaCB3YXMgYSBt aXN0YWtlLiBJdCdzIGxlc3MgZWZmaWNpZW50ICh0aGUgd29ybGQgd2FzdGVkIHF1aXRlIGEgbG90 IG9mIGJhbmR3aWR0aA0KIGR1ZSB0byB0aGlzKSwgYW5kIG1vcmUgZXJyb3ItcHJvbmUuIFRoZXJl IHdhcyBub3RoaW5nIHN0b3BwaW5nIGltcGxlbWVudGF0aW9ucyBmcm9tIHNlbmRpbmcgdGhlIHNh bWUgbm9uY2Ugb3IgZ2VuZXJhdGluZyBub25jZXMgcmFuZG9tbHkgKHRoZSBBRUFEcyB3ZSB1c2Ug ZG9uJ3QgaGF2ZSBsYXJnZSBlbm91Z2ggbm9uY2VzIGZvciB0aGF0KSwgYW5kIGluZGVlZCBzb21l IGRpZCBqdXN0IHRoYXQuIElmIHlvdSB1c2Ugc29tZSBzb3J0IG9mIHNlcXVlbmNlDQogbnVtYmVy LCB5b3UgY2FuIGxlYW4gb24gZXhpc3Rpbmcgd29yayBib3RoIHRvIGZpbHRlciBvdXQgdGhlIG9i dmlvdXMgaW1wbGVtZW50YXRpb24gbWlzdGFrZXMgYW5kIHRvIGF2b2lkIHNlbmRpbmcgdW5uZWNl c3NhcnkgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiA5LCAyMDE4IGF0IDEyOjM4IFBNIFBy YXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJhdmJAbWljcm9zb2Z0 LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TGV0 IG1lIHRyeSB0byBzdW1tYXJpemUgdGhlIHByb3Bvc2FsIGFnYWluOjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0i MSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBs Zm8xIj4NClBhY2tldCBudW1iZXIgaXMgaW4gdGhlIGVuY3J5cHRlZCBwb3J0aW9uIG9mIHRoZSBo ZWFkZXIgYW5kIGlzIG5vIGxvbmdlciB1c2VkIGFzIHRoZSBub25jZS4gSXQgaXMgZW5jb2RlZCBh cyBhIHZhcmlhYmxlIGxlbmd0aCBudW1iZXIuIEFsd2F5cyBzdGFydHMgYXQgMC4NCjxvOnA+PC9v OnA+PC9saT48L29sPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxvbCBzdGFydD0iMSIgdHlw ZT0iYSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMiBsZm8xIj4N Ck5vIG9zc2lmaWNhdGlvbiBvZiBQTjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwyIGxldmVsMiBsZm8xIj4NCk5vIGxpbmthYmlsaXR5IHVzaW5nIFBOPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxm bzEiPg0KQWxsb3dzIGZvciBncm93dGggYmV5b25kIDY0IGJpdHMgaWYgbmVlZGVkIGluIGZ1dHVy ZTxvOnA+PC9vOnA+PC9saT48L29sPg0KPC9vbD4NCjxvbCBzdGFydD0iMiIgdHlwZT0iMSI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8xIj4NClRoZSBub25j ZSBpcyBpbiB0aGUgY2xlYXIgaW4gcGxhaW50ZXh0IGhlYWRlci4gSXQgaXMgZ2VuZXJhdGVkIDxp PnBlciBwYXRoPC9pPiBhcyBhIHNlY3VyZSByYW5kb20gbnVtYmVyLiBDYWxsIHRoaXMgdGhlIOKA nHN0YXJ0aW5nIHZhbHVl4oCdLiBCb3RoIHNpZGVzIE1VU1QgaW5pdGlhbGl6ZSB0aGUg4oCcc3Rh cnRpbmcgdmFsdWXigJ0gbm9uY2UNCjxpPnBlciBwYXRoPC9pPi4gV2l0aGluIGEgcGF0aCBpdCBn cm93cyBtb25vdG9uaWNhbGx5ICh0byBhdm9pZCByZXBlYXRzIGp1c3QgbGlrZSBQTiB0b2RheSkg YW5kIGNhbiBpbmNsdWRlIHNob3J0IHJhbmRvbSBqdW1wcyBwZXJpb2RpY2FsbHkgc28gdGhhdCBt aWRkbGVib3hlcyBjYW5ub3QgYXNzdW1lIGFueXRoaW5nIGFib3V0IHRoZSBmaWVsZC4gU2luY2Ug bm9uY2UgaGFzIG5vdGhpbmcgdG8gZG8gd2l0aCBQTiB0aGUganVtcHMgZG9u4oCZdCBhZGQNCiBh bnkgY29tcGxleGl0eSB0byB0cmFuc3BvcnQgbG9naWMuIEp1bXBzIGFyZSBmb3IgZ3JlYXNpbmcg YW5kIHByZXZlbnRpbmcgb3NzaWZpY2F0aW9uLiBXaGVuIHRoZSBub25jZSByb2xscyBvdmVyIGFu ZCByZWFjaGVzIGNsb3NlIHRvIHRoZSDigJxzdGFydGluZyB2YWx1ZeKAnSwga2V5IHJvbGxvdmVy IG11c3QgaGFwcGVuLiBBdCBoaWdoIGRhdGEgcmF0ZXMgdGhlIG5vbmNlIGZpZWxkIGNhbiBiZSA2 NC1iaXRzIHRvIHByZXZlbnQgZnJlcXVlbnQga2V5DQogcm9sbG92ZXIuIEZvciBjcnlwdG8gdGhh dCBkb2VzbuKAmXQgbmVlZCBub25jZXMsIHRoZSBmaWVsZCBjYW4gYmUgb21pdHRlZC4gPG86cD48 L286cD48L2xpPjwvb2w+DQo8b2wgc3RhcnQ9IjIiIHR5cGU9IjEiPg0KPG9sIHN0YXJ0PSIxIiB0 eXBlPSJhIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzIi Pg0KTm8gb3NzaWZpY2F0aW9uIGJlY2F1c2UgdGhlcmUgaXMgbm8gcHJlLWRldGVybWluZWQgc2Vx dWVuY2UgdG8gdGhlIG5vbmNlLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwyIGxldmVsMiBsZm8yIj4NCkluIGdRVUlDIGFuZCB0aGUgUkZDIGFzIGRlZmlu ZWQgdGhlIG5vbmNlIGlzIGEgc2ltcGxlIHNlcXVlbmNlIHRoYXQgaW5jcmVtZW50cyBieSBvbmUs IHNvIHRoaXMgaXMgbm8gd29yc2Ugb2ZmIGluIHRlcm1zIG9mIHNlY3VyaXR5LiBJdCBpcyBub24t cmVwZWF0aW5nLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwyIGxldmVsMiBsZm8yIj4NCk5vIGxpbmthYmlsaXR5IGJlY2F1c2UgZGlmZmVyZW50IHBhdGhz IHN0YXJ0IGF0IGEgY29tcGxldGVseSBkaWZmZXJlbnQgcmFuZG9tIG51bWJlci4gSWYgcmVwZWF0 aW5nIGlzIGEgY29uY2VybiB0aGVuIGRpZmZlcmVudCBwYXRocyB1c2UgZGlmZmVyZW50IGtleXMu IENhcnJpZXMgZm9yd2FyZCB0byBub3QganVzdCBjb25uZWN0aW9uIG1pZ3JhdGlvbiBidXQgbXV0 bGktcGF0aC4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwyIGxldmVsMiBsZm8yIj4NClN1cHBvcnRzIGtleSByb2xsb3ZlciBqdXN0IGxpa2UgZ1FVSUMg YW5kIGN1cnJlbnRseSBkZWZpbmVkIGRyYWZ0IFJGQy48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIgbGZvMiI+DQpBbGxvd3MgZm9yIG9taXR0 aW5nIHRoZSBub25jZSB3aGVuIHdlIHVzZSBjcnlwdG8gdGhhdCBkb2VzbuKAmXQgbmVlZCBpdC48 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIg bGZvMiI+DQpBbGxvd3MgZm9yIGxhcmdlciBub25jZXMgZm9yIGhpZ2ggZGF0YSByYXRlcy4gPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxm bzIiPg0KSXQgZG9lc27igJl0IHByZWNsdWRlIGFueSBvdGhlciB0eXBlIG9mIG5vbi1yZXBlYXRp bmcgbm9uY2VzIHdpdGhvdXQgaGF2aW5nIHRvIG1vZGlmeSB0aGUgUkZDISBTbyBpbXBsZW1lbnRh dGlvbnMgdGhhdCB3YW50IHRvIHVzZSBjcnlwdG9ncmFwaGljIG5vbmNlcyBjYW4gc3RpbGwgZG8g c28uDQo8bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgZG93bnNp ZGVzOjxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KRXZlbiB3aXRoIHZhcmlhYmxl IGxlbmd0aCBlbmNvZGluZyB0aGUgZXh0cmEgUE4gZmllbGQgaXMgbW9yZSBzcGFjZSB1c2VkIHBl ciBwYWNrZXQgd2hlbiBhIG5vbmNlIGlzIHJlcXVpcmVkLiBJIHRoaW5rIHdlIGNhbiBkbyB3aXRo IDIgYnl0ZXMgaW4gdmVyc2lvbiAxLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj4NCkl04oCZcyBub3QgcGVyZmVjdCB1bmxpbmth YmlsdGl5IGJ1dCBJIGhhdmUgeWV0IHRvIHNlZSBhbnkgc29sdXRpb24gdGhhdCBjYW4gcHJvdmlk ZSB0aGlzLiBBIHNpbXBsZSB0aW1lIGJhc2VkIGFuYWx5c2lzIHVzaW5nIG1hY2hpbmUgbGVhcm5p bmcgd2lsbCBhbGxvdyBmbG93IGNvcnJlbGF0aW9uIGVzcGVjaWFsbHkgZm9yIGNvbm5lY3Rpb24g bWlncmF0aW9uLiBUaGUgSVAgYWRkcmVzc2VzIGluIHRoZSBjbGVhciBhbGxvdyBmb3IgYSBoaWdo IGRlZ3JlZQ0KIG9mIGNvcnJlbGF0aW9uLiBUaGVyZSBpcyBhbHNvIHRoZSBhcHBsaWNhdGlvbiBz ZW5kaW5nIHBhdHRlcm4gYW5kIG90aGVyIHNpZ25hbHMgdGhhdCBjb3VsZCBiZSB1c2VkLg0KPG86 cD48L286cD48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gRXJpYyBSZXNjb3Js YSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5l a3JAcnRmbS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgRmVicnVhcnkgOSwg MjAxOCA1OjUyIEFNPGJyPg0KPGI+VG86PC9iPiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnByYXZiQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5wcmF2 YkBtaWNyb3NvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IGh1aXRlbWEgJmx0OzxhIGhy ZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0IiB0YXJnZXQ9Il9ibGFuayI+aHVpdGVtYUBo dWl0ZW1hLm5ldDwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBUaHUsIEZlYiA4LCAyMDE4IGF0 IDk6NDAgUE0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuICZsdDs8YSBocmVmPSJtYWlsdG86cHJh dmJAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnByYXZiQG1pY3Jvc29mdC5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PkFjdHVhbGx5IHRha2luZyBhIHN0ZXAgYmFjayB3aGF0IGlmIHdlIGRvbuKAmXQgd2Ugb3Zlcmxv YWRlZCBwYWNrZXQgbnVtYmVyIGFzIHRoZSBub25jZT88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPkNhbiB3ZTo8bzpwPjwvbzpwPjwvcD4NCjxvbCBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMSBsZm80Ij4NClB1dCBwYWNrZXQg bnVtYmVyIGFzIGEgc2VwYXJhdGUgdmFyaWFibGUgbGVuZ3RoIGZpZWxkIGluIHRoZSBlbmNyeXB0 ZWQgcG9ydGlvbiBvZiB0aGUgaGVhZGVyLiBUaGlzIGFsbG93cyBmb3IgZ3Jvd3RoIGJleW9uZCA2 NCBiaXRzIGluIGZ1dHVyZSBhbmQgY29tcGxldGVseSBhdm9pZHMgb3NzaWZpY2F0aW9uLiBGb3Ig c2hvcnQgbGl2ZWQgZmxvd3MgdmFyaWFibGUgbGVuZ3RoIGVuY29kaW5nIGxlYWRzIHRvIG1pbmlt YWwgc3BhY2Ugb3ZlcmhlYWQuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvNCI+DQpQdXQgYSBzZXBhcmF0ZSBwbGFpbnRleHQgbm9u Y2Ugd2hpY2ggc3RhcnRzIG91dCBhcyBhIHNlY3VyZSByYW5kb20gbnVtYmVyIGFuZCBtb25vdG9u aWNhbGx5IGluY3JlYXNlcyBhcyBzaG9ydCByYW5kb20ganVtcHMgKGV2ZXJ5IHBhY2tldCBvciBl dmVyeSBmZXcgcGFja2V0cykgYW5kIGNvdWxkIHRoZW4gcm9sbG92ZXIuIFRoaXMgd2lsbCBwcmV2 ZW50IGxpbmthYmlsaXR5IGFuZCBzY2FsZXMgdG8gbXVsdGktcGF0aCBhcyB3ZWxsLiBObyBtYWpv cg0KIGNvbXB1dGUgb3ZlcmhlYWQuIFdlIGNhbiBhbHNvIG1ha2UgdGhlIG5vbmNlIG9wdGlvbmFs IGZvciBjcnlwdG8gYWxnb3JpdGhtcyB0aGF0IGRvIG5vdCBuZWVkIGEgbm9uY2Ugc2F2aW5nIG1v cmUgc3BhY2UuPG86cD48L286cD48L2xpPjwvb2w+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkknbSBub3Qgc3VyZSBob3cg dG8gZG8gIzIgc2FmZWx5IGFuZCBlZmZpY2llbnRseS4gVGhlIHByaW1hcnkgY29uY2VybiBpcyB0 aGF0IHNob3J0IHJhbmRvbSBqdW1wcyBkb24ndCBhY3R1YWxseSBwcmV2ZW50IGxpbmthYmlsaXR5 IGJlY2F1c2UgdGhlIGhpZ2ggb3JkZXIgYml0cyBkb24ndCBjaGFuZ2UgYW5kDQogbG9uZyByYW5k b20ganVtcHMgYXJlIGVmZmVjdGl2ZWx5IHJhbmRvbWx5IHNhbXBsaW5nIG91dCBvZiB0aGUgbm9u Y2Ugc3BhY2UsIGFuZCB5b3Ugc3RhcnQgdG8gcnVuIGludG8gYmlydGhkYXkgcHJvYmxlbXMuIEFk ZGl0aW9uYWxseSwgdGhlIGNoZWFwZXN0IFBSTkdzIGFyZSBiYXNpY2FsbHkgY2lwaGVycyBpbiBj b3VudGVyIG1vZGUsIHNvIGF0IGJlc3QgeW91J3JlIGdvaW5nIHRvIGdldCBhIHNtYWxsIGFtb3Vu dCBvZiBvdmVyaGVhZCByZWR1Y3Rpb24NCiBieSBnZXR0aW5nIG11bHRpcGxlIGp1bXAgY29tcHV0 YXRpb25zIG91dCBvZiBhIHNpbmdsZSBibG9jaywgdGhvdWdoIGlmIHlvdSB1c2UgOTYtYml0IGp1 bXBzLCB5b3Ugb25seSBnZXQgMjUlIHNhdmluZ3MuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U29tZSBNU0Ig b2YgdGhlIG5vbmNlIGNvdWxkIGJlIHVzZWQgZm9yIHNpZ25hbGluZyByZW9yZGVyIHRvIHRoZSBu ZXR3b3JrIGlmIG5lZWRlZC4gSSBkb27igJl0IGhhdmUgdGhlIGhpc3RvcmljYWwgY29udGV4dCBm b3Igb3ZlcmxvYWRpbmcgb2YgUE4gYXMgdGhlIG5vbmNlIHNvIHBhcmRvbiBtZSBpZiB1bi1vdmVy bG9hZGluZw0KIG9wdGlvbiB3YXMgZGlzY3Vzc2VkIGFuZCBydWxlZCBvdXQgYmVmb3JlLjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPlByYXZlZW4gQmFsYXN1YnJhbWFuaWFuPGJyPg0KPGI+U2VudDo8L2I+ IFRodXJzZGF5LCBGZWJydWFyeSA4LCAyMDE4IDU6NTEgUE08YnI+DQo8Yj5Ubzo8L2I+IGh1aXRl bWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0IiB0YXJnZXQ9Il9ibGFu ayI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jmd0OyZndDsgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tldCBz ZXF1ZW5jZXMgZm9yIGVhY2ggcGF0aDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoaXMgYWxvbmUgcHJldmVudHMgbGlua2FiaWxpdHkgcmlnaHQ/ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mZ3Q7Jmd0OyBUaGUgcGFja2V0IG51bWJlciBv biBlYWNoIHBhdGggd2lsbCBzdGFydCBhdCAxIChvciBtYXliZSAwIDstKS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SXMgc3VwcG9ydGluZyBtdWx0aXBsZSBwYXRocyBh dCB0aGUgc2FtZSB0aW1lIGEgZ29hbD8gSWYgeWVzLCB0aGVuIHllcyBhbGwgcGF0aHMgd2lsbCBu ZWVkIHRvIGhhdmUgc2VwYXJhdGUgdHJhY2tpbmcgYW5kIEFDSyBzdGF0ZSBhbmQgY29uZ2VzdGlv biBjb250cm9sIGV0Yy4gSSB0aG91Z2h0IHRoaXMgaXMNCiBub3QgcGFydCBvZiBWMSBSRkMuIElm IGl0cyBqdXN0IG9uZSBhZGRpdGlvbmFsIHBhdGggZm9yIGNvbm5lY3Rpb24gbWlncmF0aW9uIHNj ZW5hcmlvIHRoZW4gYWxsIHlvdSBuZWVkIGlzIGEgKHJhbmRvbSkganVtcCB0byBhIG9mZnNldCBp biBwYWNrZXQgbnVtYmVyIHNwYWNlIGZvciB0aGUgbmV3IHBhdGggc28gdGhhdCB0aGUgZmV3IHBh Y2tldHMgaW4gdGhlIG9sZCBwYXRoIGNhbiBjb250aW51ZSBmb3IgYSBsaXR0bGUgYml0LiBUaGlz IHdvcmtzDQogd2l0aCBqdXN0IG9uZSBBQ0sgc3BhY2Ugc28gbm8gaW1wbGVtZW50YXRpb24gY29t cGxleGl0eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZndDsmZ3Q7IDIpIE9yLCBsZWF2 aW5nIHRoZSBwYWNrZXQgbnVtYmVyIGluIHRoZSBjbGVhciBidXQgdXNpbmcgZGlmZmVyZW50IGVu Y3J5cHRpb24gY29udGV4dHMgZm9yIGVhY2ggcGF0aCwgYW5kIHVzaW5nIHNlcGFyYXRlIHBhY2tl dCBzZXF1ZW5jZXMgZm9yIGVhY2ggcGF0aC48YnI+DQpJbiBhZGRpdGlvbiBpZiB0aGUgdmFsdWUg aW4gdGhlIGNsZWFyIHdhcyBvYmZ1c2NhdGVkIHdpdGggYW4gWE9SIHRyYW5zZm9ybSBpdCB3aWxs IGhlbHAgcHJldmVudCBvc3NpZmljYXRpb24uIFRoZSBvYmZ1c2NhdGlvbiBpcyBub3QgbWVhbnQg dG8gZ3VhcmQgYWdhaW5zdCBsYXRlciBhbmFseXNpcyB0aGF0IHJldmVhbHMgdGhlIHBhY2tldCBu dW1iZXJzIC0gd2h5IGRvIHdlIGNhcmUgYWJvdXQgdGhhdC4gSXQgaXMgbWVhbnQgdG8gZ3JlYXNl IHRoZQ0KIHNwYWNlIGFuZCBub3QgbWFrZSB0aGUgbnVtYmVycyBzZXJpYWwgc28gbWlkZGxlYm94 ZXMgY2Fubm90IGFzc3VtZSBvcmRlcmluZyBldGMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5BbGwgc2FpZCBpZiBJIGFtIGFsb25lIGluIGJlaW5nIGNvbmNlcm5lZCBhYm91dCB0aGUgcGVy ZiBoaXQgdGhlbiBJ4oCZZCBzYXkgZ28gb24gd2l0aCBvcHRpb24gMS4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206 PC9iPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPkNocmlzdGlhbiBIdWl0ZW1hPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJy dWFyeSA4LCAyMDE4IDM6NTQgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpxdWlj QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8cD5PbiAyLzgvMjAxOCAxOjEzIFBNLCBNaWtlIEJpc2hvcCB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4jMiB3b27igJl0IHdvcmsuJm5ic3A7IFRoZSBw YWNrZXQgbnVtYmVyIGlzIGFuIGlucHV0IHRvIHRoZSBBRUFEIG5vbmNlLCBzbyB5b3UgaGF2ZSB0 byBnZXQgdG8gdGhlIHBhY2tldCBudW1iZXIgYmVmb3JlIHlvdSBjYW4gZGVjcnlwdCB0aGUgcGF5 bG9hZC4mbmJzcDsgSXQgY2Fu4oCZdCBiZSBiYXNlZCBvbiBhbnl0aGluZyBpbnRlcm5hbA0KIHRv IHRoZSBlbmNyeXB0ZWQgcGFja2V0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW4gTWFy dGlu4oCZcyBwcm9wb3NhbCwgaXTigJlzIHVzaW5nIGEgY29tYmluYXRpb24gb2YgdGhlIGVuY3J5 cHRlZCBwYXlsb2FkICh3aGljaCByZXF1aXJlcyBub3RoaW5nIHRvIGFjY2VzcykgYW5kIHNvbWUg c3RvcmVkIHN0YXRlIG9uIGVhY2ggZW5kcG9pbnQsIHdoaWNoIHJlcXVpcmVzIG9ubHkgdGhlIENv bm5lY3Rpb24NCiBJRCB0byBsb29rIHVwLiZuYnNwOyBZb3Ugd2FudCB0aGUgdGhpbmcgeW91IFhP UiBieSB0byBiZSBjb25zdGFudGx5IGNoYW5naW5nLCBvciBpdCBiZWNvbWVzIGVhc2llciB0byBs b29rIGF0IHNlcXVlbmNlcyBvZiBvYmZ1c2NhdGVkIHBhY2tldCBudW1iZXJzIGFuZCBzdGFydCBk cmF3aW5nIGluZmVyZW5jZXMgYWJvdXQgd2hhdCB0aGUgWE9SIHZhbHVlIGlzLiZuYnNwOyBJZiBv dmVyaGVhZCBpcyB0aGUgcHJpbWFyeSBjb25jZXJuLCBJIHRoaW5rIHRoZXJlIGFyZQ0KIGEgY291 cGxlIGFwcHJvYWNoZXMgdGhhdCBtaWdodCBhbGxvdyB5b3UgdG8gcHJlY29tcHV0ZSB2YWx1ZXMg YW5kIGFtb3J0aXplIHRoZSBjb3N0IG9mIGRvaW5nIHRoZSBlbmNyeXB0aW9uIHN0ZXAuJm5ic3A7 IChBdCB0aGUgY29zdCBvZiBrZWVwaW5nIHRoZSB0YWJsZSBvZiBwcmVjb21wdXRlZCB2YWx1ZXMs IG9mIGNvdXJzZS4pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JIHN0aWxsIHRoaW5rIEph bmHigJlzIHB1c2hpbmcgaW4gdGhlIHJpZ2h0IGRpcmVjdGlvbiBoZXJlOiZuYnNwOyBMZXTigJlz IGFncmVlIG9uIGdvYWxzLCBhbmQgdGhlbiBzZWUgaWYgd2UgY2FuIGNyYWZ0IGEgZGVzaWduIHRo YXQgbWVldHMgdGhvc2UgZ29hbHMuJm5ic3A7IEkgaGVhciB5b3Ugc2F5aW5nIHRoYXQgbG93IG92 ZXJoZWFkDQogaXMgYSBnb2FsLCB3aGljaCBJIHRoaW5rIHdlIGNhbiBhbGwgYWdyZWUgb24uJm5i c3A7IEkgYWxzbyB0aGluayBJIGhlYXIgeW91IHNheWluZyB0aGF0IDEtMS41JSBvdmVyaGVhZCBp cyB0b28gaGlnaCwgYnV0IGl0IHNvdW5kcyBsaWtlIHRoZXJl4oCZcyBsZXNzIGFncmVlbWVudCBv biB0aGF0LiZuYnNwOyBZb3UgYWxzbyByYWlzZSBhbiBpbnRlcmVzdGluZyBwb2ludCB0aGF0IHNv bWUgY2xpZW50cyB3aWxsIGNhcmUgbGVzcyBhYm91dCBsaW5rYWJpbGl0eSBiZWNhdXNlDQogdGhl eSB3aWxsIG5ldmVyIGludGVudGlvbmFsbHkgbWlncmF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KSSB0aGluayBWaWN0b3Igc2FpZCBpdCBi ZXN0LCAmcXVvdDtPYmZ1c2NhdGlvbiBpcyBqdXN0IGVuY3J5cHRpb24gZG9uZSBwb29ybHkuJnF1 b3Q7IEVpdGhlciB3ZSBlbmNyeXB0LCBvciB3ZSBkb24ndC4gQnV0IHRoZXJlIGlzIG5vIHN1Y2gg dGhpbmcgYXMgYW4gb2JmdXNjYXRpb24gbWlkZGxlLWdyb3VuZC4gT2JmdXNjYXRpb24gd291bGQg anVzdCBiZSBhIHNwZWVkIGJ1bXAsIGVhc2lseSBicm9rZW4uIEl0IHdvbid0IHByb3ZpZGUgcHJp dmFjeSwgYW5kIGl0IHdvbid0DQogcHJldmVudCBsaW5rYWJpbGl0eS48YnI+DQo8YnI+DQpBcyBm YXIgYXMgSSBhbSBjb25jZXJuZWQsIHRoZXJlIGFyZSBvbmx5IHR3byBkZXNpZ25zIHRoYXQgcHJl dmVudCBsaW5rYWJpbGl0eTo8YnI+DQo8YnI+DQoxKSBNYXJ0aW4ncyBQUiwgaW4gd2hpY2ggdGhl IHBhY2tldCBudW1iZXIgaXMgZW5jcnlwdGVkIHVzaW5nIHNlbnNpYmxlIGNyeXB0bzs8YnI+DQo8 YnI+DQoyKSBPciwgbGVhdmluZyB0aGUgcGFja2V0IG51bWJlciBpbiB0aGUgY2xlYXIgYnV0IHVz aW5nIGRpZmZlcmVudCBlbmNyeXB0aW9uIGNvbnRleHRzIGZvciBlYWNoIHBhdGgsIGFuZCB1c2lu ZyBzZXBhcmF0ZSBwYWNrZXQgc2VxdWVuY2VzIGZvciBlYWNoIHBhdGguPGJyPg0KPGJyPg0KVGhl IHNlY29uZCBvcHRpb24gcmVxdWlyZXMgbW9yZSBjb21wdXRhdGlvbiB3aGVuIGV4cGxpY2l0bHkg c2V0dGluZyB1cCBhIG5ldyBwYXRoLiBUaGUgY29ubmVjdGlvbiBJRCB3b3VsZCBiZSB1c2VkIGFz IHBhcnQgb2YgdGhlICZxdW90O3NhbHQmcXVvdDsgd2hlbiBkZXJpdmluZyBjb25uZWN0aW9uIGNv bnRleHRzLiBUaGUgcGFja2V0IG51bWJlciBvbiBlYWNoIHBhdGggd2lsbCBzdGFydCBhdCAxIChv ciBtYXliZSAwIDstKS4gVGhpcyByZXF1aXJlcyBtYWludGFpbmluZw0KIHNlcGFyYXRlIFNBQ0sg ZGFzaGJvYXJkcyBmb3IgZWFjaCBwYXRoL0Nvbm5lY3Rpb24tSUQsIGFuZCBjb25zdHJhaW5pbmcg QUNLIHRvIGJlIHBlci9wYXRoLCBvciBhbHRlcm5hdGl2ZWx5IGFkZGluZyBhIFBBVEgtQUNLIGZy YW1lIHRoYXQgaW5kaWNhdGVzIHRoZSBwYXRoIGZvciB3aGljaCBwYWNrZXRzIGFyZSBhY2tlZC48 YnI+DQo8YnI+DQpUaGUgcHJvcyBhbmQgY29ucyBvZiB0aGUgdHdvIG9wdGlvbnMgYXJlIGVhc3kg dG8gZ2V0Ojxicj4NCjxicj4NCjEpIE9wdGlvbiAyIGRvZXMgbm90IHJlcXVpcmUgdGhlIGNvc3Qg b2YgZW5jcnlwdGluZyBldmVyeSBwYWNrZXQsIHRodXMgcGVyIHBhY2tldCBwcm9jZXNzaW5nIHdp bGwgYmUgbWF5YmUgMSUgZmFzdGVyIHRoYW4gb3B0aW9uIDEuDQo8YnI+DQo8YnI+DQoyKSBPcHRp b24gMiByZXF1aXJlcyBjb21wdXRpbmcgZW5jcnlwdGlvbiBjb250ZXh0cyBmb3IgZWFjaCBwYXRo LCB3aGljaCBpcyBtb3JlIGNvbXBsZXggdGhhbiBvcHRpb24gMSwgYnV0IHRoZSBjb3N0IHdpbGwg YmUgYW1vcnRpemVkIG92ZXIgdGhlIGR1cmF0aW9uIG9mIHRoZSBwYXRoLjxicj4NCjxicj4NCjMp IE9wdGlvbiAyIHJlcXVpcmVzIG1vcmUgY29tcGxleCBkYXRhIHN0cnVjdHVyZXMgYW5kIEFDSyBt YW5hZ2VtZW50LCB0aHVzIGluY3JlYXNpbmcgdGhlIGNoYW5jZXMgdGhhdCBzb21ldGhpbmcgZ29l cyB3cm9uZy48YnI+DQo8YnI+DQo0KSBPcHRpb24gMiBkb2VzIG5vdGhpbmcgYWdhaW5zdCBwYWNr ZXQgbnVtYmVyIG9zc2lmaWNhdGlvbi4gVGhlIHBhY2tldCBudW1iZXIgZWZmZWN0aXZlbHkgYmVj b21lcyBwYXJ0IG9mIHRoZSBpbnZhcmlhbnRzLjxicj4NCjxicj4NCkluIHNob3J0LCB0aGUgb25s eSBhZHZhbnRhZ2Ugb2Ygb3B0aW9uIDIgaXMgdG8gYXZvaWQgYSBzaW5nbGUgc3ltbWV0cmljIGVu Y3J5cHRpb24gb3BlcmF0aW9uIHBlciBwYWNrZXQsIHdoaWxlIG1ha2luZyB0aGUgY29kZSBzaWdu aWZpY2FudGx5IG1vcmUgY29tcGxleCwgYW5kIGF0IHRoZSBjb3N0IG9mIG5vdCBwcm90ZWN0aW5n IGFnYWluc3QgUE4gb3NzaWZpY2F0aW9uLiBUaGUgd2F5IEkgc2VlIHRoYXQsIHRoZXJlIGlzIGhh cmRseSBhbnkgZGViYXRlLjxicj4NCjxicj4NCi0tIENocmlzdGlhbiBIdWl0ZW1hPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1F436ED13A22A246A59CA374CBC543998B58BB1BORSMSX111amrcor_-- From nobody Fri Feb 9 13:17:16 2018 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 704381242F7 for ; Fri, 9 Feb 2018 13:17:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 rDTKhuI0HQNk for ; Fri, 9 Feb 2018 13:17:12 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 A6B431270AE for ; Fri, 9 Feb 2018 13:17:12 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id a9so5688398qtj.8 for ; Fri, 09 Feb 2018 13:17:12 -0800 (PST) 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=FVtq7IiN/XnnMGx+q9RbGgrfevsfx8phRvBXAg/wWaY=; b=kKpvB96g9o1nVJ8tfPhVGl2NezgtlMAncKO437eoCgr0htIWK8yTgK8G7FAHKU/ZPP 5RNPrGOpe0CZToebPUC9HdWskl1bkNx/cet6zCTJ71JYLZeZL3JFMPuHRhPc2fqXuJOV PhpqnjSvWFWch55SIDqpKIr9uJJ1Rju4inNulqMNpTgYXsdmiquMa2NJzsiROhghsNLk qGqIxJmqDcycgL0f5O/b0vER4fGOP9r/dERuWCmAWjbbpRH98LAFWYwJyIt1Ax+G494Y tZ891q8wr2aSQfP7lvqEdto9GgphMDaJrxbeLe4QuLCTsFhueJaR3JC4ZSGo44SB0YlV U9kg== 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=FVtq7IiN/XnnMGx+q9RbGgrfevsfx8phRvBXAg/wWaY=; b=EwOCXjphBVX/YvcLqUWSUXMHLo3t8/bXF5+nAhWuaGve1Re+0vpPqefQlLc6tkAQmm x4RLk/qtZ8uPROb0WXkI0ZVFJVD0i5VhN/TmAFjA8B2T91gw6J/GvQ1NcFzHJDsdr+yI ruaM7Av0abZoxiS3iqZEMN+cwQVslWIZZyQtTxd22L5oQVzcc0GcHYjLKrX+KtPndABp 3A2RyHHm+8hH5NOk4L7EW9k5QZDWd+XD3tIJtwcQq0umtGK/goF6wY0GQWtHQJ/zCwQ8 HcdBz8J/B2zxc9ewrvHZwqC1VLTu8lbDYRkJf0suvsi0agMX2dpa3Ip7w/tNKhcVfnks /OfA== X-Gm-Message-State: APf1xPApENO6zm48DUW7WO0zKwxaCNh4oxqSTDpxGsp2OHjKf9X3u3NP 7uTgrfEHpFPQBRgILSve3/Z5pUFCNK6AuKcuTzZ4hg== X-Google-Smtp-Source: AH8x225yOJZpifkIdIANy/wwyGrDySL5gfz+jpYLTzhoh/GZOILC12B8XpAqZ4PHlbqs0mZjeSxfTebWJGeb3pQPc20= X-Received: by 10.237.49.199 with SMTP id 65mr6742601qth.204.1518211031580; Fri, 09 Feb 2018 13:17:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.34.132 with HTTP; Fri, 9 Feb 2018 13:17:10 -0800 (PST) In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> From: Victor Vasiliev Date: Fri, 9 Feb 2018 16:17:10 -0500 Message-ID: Subject: Re: Packet number encryption To: Praveen Balasubramanian Cc: Marten Seemann , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="94eb2c124aa23bd91b0564ce0d6a" 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, 09 Feb 2018 21:17:14 -0000 --94eb2c124aa23bd91b0564ce0d6a Content-Type: text/plain; charset="UTF-8" On Thu, Feb 8, 2018 at 5:32 PM, Praveen Balasubramanian wrote: > AFAICT the goal is to perform some transform for preventing middlebox > ossification. Encryption is one possible transform but is it the only > possible one? > The goal of the transform is to prevent the middleboxes from interpreting the packet number, so yes, anything you'll propose would be encryption. > The numbers I quoted were from a quick test by modifying the winquic > implementation to add an additional encrypt / decrypt step on packet number > size worth of data. If anyone else has any data please share. > I am very confused about the 1.25% number. 1280 bytes is about 80 AES blocks, and one extra block is 1.25% on top of total *encryption* costs (you don't have to MAC the PN, so that's even cheaper). And the encryption itself is fairly cheap compared to almost any other part of the QUIC stack (sent packet tracking, ack processing, I/O, timers, etc). --94eb2c124aa23bd91b0564ce0d6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 8, 2018 at 5:32 PM, Praveen Balasubramanian <<= a href=3D"mailto:pravb@microsoft.com" target=3D"_blank">pravb@microsoft.com= > wrote:

AFAICT the goal is to perform some transform for pre= venting middlebox ossification. Encryption is one possible transform but is= it the only possible one?


= The goal of the transform is to prevent the middleboxes from interpreting t= he packet number, so yes, anything you'll propose would be encryption.<= /div>
=C2=A0

The numbers I quoted were from a quick test by m= odifying the winquic implementation to add an additional encrypt / decrypt step on packet number size worth of= data. If anyone else has any data please share.


I am very confused about the 1.25% number.=C2=A0 1280= bytes is about 80 AES blocks, and one extra block is 1.25% on top of total= *encryption* costs (you don't have to MAC the PN, so that's even c= heaper).=C2=A0 And the encryption itself is fairly cheap compared to almost= any other part of the QUIC stack (sent packet tracking, ack processing, I/= O, timers, etc).
--94eb2c124aa23bd91b0564ce0d6a-- From nobody Fri Feb 9 13:18:25 2018 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 3017E127286 for ; Fri, 9 Feb 2018 13:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 75c_pggSVdmE for ; Fri, 9 Feb 2018 13:18:20 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 2510F1242F7 for ; Fri, 9 Feb 2018 13:18:20 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id e1so12317859ita.0 for ; Fri, 09 Feb 2018 13:18:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Sx9uWqdM5yRwaNuFA/GCgDShIWMjyc16f6lbb94ol3I=; b=mlVN041nx7mg3iq8oqbhiPwmMsNB9uafSZtmJQl7J5eXspy61v7ry/kjHtIysUDZK/ 4nJ+UOyOev1EreNj8AytIKZVnznoIlOZ3OWU/d0bhbRwKxleiwhZDE5FcgLwZ00jazAS cgRiOiuu9uKKyTpX2xeffkIGr8czYHix8ANSq3HdGdnTsnWhqhejKh52m88EEpl/HtPJ IRqWSwWZWpWqtIhR+7LYORf7rKJaq1fh3hFrwlxUULoLsJuhqVzZsvb/C1kLWwilheiF UnSBe5+Fq2Kq8h9980x0b244eTaYQjJYWndlalJ4AVs7Pf7hnSinei7Qh9QJH51oZWvw uivA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Sx9uWqdM5yRwaNuFA/GCgDShIWMjyc16f6lbb94ol3I=; b=KkuBixR5sA1pQc8s0bot3DZ90xWoCe/hBqQyiTmOXkj8W8ZWhCdI3GMzluQxwv07S2 tLOFpdKa5YzZC6AEMarqCO4Ga8HOy1QF2DzwNE+AKRc4MrADdhwnjP0nSINYtjhwmlB8 BgimYq4CNtVTStSgpwlR90syglkLIAEHwCT4A4h/Nj2XOaC9eK7eDUG+ytRaAsvimkna 4o5EyXqDI9fkl5MIn1GZDyvErnlhBTNFMTUkEVqdQJKN/P9tlVBjne6rBR/6yr6Q8nSw uyVr93vCqDNoPXV/NE6wfCjiWGAJqAoh+qCHjazRmRe6/b8KHvMTB+s1B1ssfyBb9t1j 1Pwg== X-Gm-Message-State: APf1xPB9wWvYm80xFP7NHBxTiZ/vOnR76aJahNJz8WdbSwginDzyJgav KiGzb0lRzWdkED1LezYrGlBsbqfAgNBQdXd00zU= X-Google-Smtp-Source: AH8x225yIDEL8rpT8LoibZC1w+Vr+Bstw2SCJQ7Zf5hCVs3qhZveetrn/7nXY3BDPMmeJrd7DxmL3+Frmq7erOITq2Q= X-Received: by 10.36.178.26 with SMTP id u26mr5058784ite.4.1518211099393; Fri, 09 Feb 2018 13:18:19 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 13:18:18 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B58BAD7@ORSMSX111.amr.corp.intel.com> References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B58BAD7@ORSMSX111.amr.corp.intel.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 13:18:18 -0800 Message-ID: Subject: RE: Packet number encryption To: David Benjamin , "Deval, Manasi" , Praveen Balasubramanian Cc: Eric Rescorla , huitema , "quic@ietf.org" Content-Type: multipart/alternative; boundary="f403045d914c4603dc0564ce1166" 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, 09 Feb 2018 21:18:24 -0000 --f403045d914c4603dc0564ce1166 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The obvious advantage of a clear text nonce is that it can be immediately decrypted without extra processing and without modifying the packet content, and it avoids latency from a separate packet number decryption step. However, having per path unique nonces per path jumping randomly in order to gain an insignificant amount of anti-ossification is not every appealing. Neither is the extra space required for having both packet numbers and nonces, when they in the majority of cases is one and the same, effectively. The random jumps are effectively a hidden encryption step although cheaper than packet number encryption. So, I propose having a nonce that counts from 0 per path per direction and also having a unique connection identifier per path direction (asymmetric CID). Lets call this a half-path context (CID+nonce counter). It could also work shared path CID as today, but it is not as clean. The nonce can at most count to 2^32-1 due to hard limits on AES-GCM and possibly general TLS requirements. This leaves the packet number encoding: If we enumerate each half-path with a path ID PID as a simpler counter starting at zero, we have a 1-1 mapping from PID to CID. The packet number PN is then encoded as . The PN is used explicitly and implicitly in ACK frames but is never carried directly on the wire. During path migration packet numbers in the same ACK frame may have large predictable jumps, but the ACK frame already competently deals with this, and the jumps are limited to the number of concurrently active paths. The only loss is the ossification concern of having predictable per path counters, but I think that is low price of admission. There are no linkability concerns with this, and all the networking monitoring people would be happy too. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 9 February 2018 at 21.55.33, Deval, Manasi (manasi.deval@intel.com) wrote: Going back to Ian=E2=80=99s point here =E2=80=93 Can you be explicit about = the issue you see in the packet number encryption? Thanks, Manasi *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen Balasubramanian *Sent:* Friday, February 09, 2018 11:59 AM *To:* David Benjamin *Cc:* Eric Rescorla ; quic@ietf.org; huitema < huitema@huitema.net> *Subject:* RE: Packet number encryption With VLE its minimal overhead per packet so you are not encrypting 4 bytes more all the time even with 64 bit or 128 bit packet number . So its decidedly better. Also fewer calls into TLS, but I suppose one could do some refactoring of TLS API. Many CPUs yes but this is a general purpose transport and could run on CPUs that don=E2=80=99t. Didn=E2=80=99t ask for nonce to be variable length. Fixed length for connec= tion lifetime. Datacenters connections could use 64-bit nonce to avoid frequent key rollover. Effectively the plain text nonce is a sequence number since it increases monotonically with small jumps as needed to avoid ossification. So no worse off than gQUIC or current draft. No more complex than using the packet number. Just the starting number is randomized. Also please notice that this proposal does not preclude using encrypted packet number as the nonce as proposed previously. Changing how the nonce works makes 0 impact on the transport logic. An implementation can choose to implement any form of non-repeating nonce without revving the RFC. This is the biggest advantage of separation of concerns IMHO. *From:* David Benjamin [mailto:davidben@chromium.org] *Sent:* Friday, February 9, 2018 11:39 AM *To:* Praveen Balasubramanian *Cc:* Eric Rescorla ; quic@ietf.org; huitema < huitema@huitema.net> *Subject:* Re: Packet number encryption Your primary worry here was the extra block cipher operation, right? By moving the packet number into the plaintext, this proposal increases the length, which will cost that same one extra block cipher operation, no? It is one block operation under the same key, rather than a different key so I suppose there are minuscule cache footprint wins (one symmetric key is 16 or 32 bytes). But the cost is per-packet (!) bandwidth and complexity. I do not see how this could be worth it. Note that, for AES, many CPUs have dedicated instructions for it already. > Clear separation of concerns results if we don=E2=80=99t overload the pac= ket number as the nonce. Connection migration and multi-path are optional features and we pay no extra compute cost for most connections that are not impacted by unlnkability. Nonce field becomes optional for crypto that doesn=E2=80=99t need it and can grow to larger size as needed for bulk tran= sfers to prevent frequent key rollovers (say in datacenter scenarios). You're not going to find AEADs that don't require a nonce. Encryption must not produce the same ciphertext twice for the same plaintext, so you need some input to diversify them. That input is the nonce. Nonces also are not variable-length, so you don't get to arbitrarily grow them. (AES-GCM per spec is variable length, but that's a spec bug. If you size it above 96 bits, it's as if you randomized it and your nonce space crashes per birthday.) It is also harmful to separate the two concerns. When you are building a transport, derive the nonce from a sequence number. TLS 1.2 AES-GCM separated them, which was a mistake. It's less efficient (the world wasted quite a lot of bandwidth due to this), and more error-prone. There was nothing stopping implementations from sending the same nonce or generating nonces randomly (the AEADs we use don't have large enough nonces for that), and indeed some did just that. If you use some sort of sequence number, you can lean on existing work both to filter out the obvious implementation mistakes and to avoid sending unnecessary data. On Fri, Feb 9, 2018 at 12:38 PM Praveen Balasubramanian wrote: Let me try to summarize the proposal again: 1. Packet number is in the encrypted portion of the header and is no longer used as the nonce. It is encoded as a variable length number. Alw= ays starts at 0. 1. No ossification of PN 2. No linkability using PN 3. Allows for growth beyond 64 bits if needed in future 1. The nonce is in the clear in plaintext header. It is generated *per path* as a secure random number. Call this the =E2=80=9Cstarting value= =E2=80=9D. Both sides MUST initialize the =E2=80=9Cstarting value=E2=80=9D nonce *per pa= th*. Within a path it grows monotonically (to avoid repeats just like PN today) and ca= n include short random jumps periodically so that middleboxes cannot assum= e anything about the field. Since nonce has nothing to do with PN the jump= s don=E2=80=99t add any complexity to transport logic. Jumps are for greas= ing and preventing ossification. When the nonce rolls over and reaches close to = the =E2=80=9Cstarting value=E2=80=9D, key rollover must happen. At high data= rates the nonce field can be 64-bits to prevent frequent key rollover. For crypto that doesn=E2=80=99t need nonces, the field can be omitted. 1. No ossification because there is no pre-determined sequence to the nonce. 2. In gQUIC and the RFC as defined the nonce is a simple sequence that increments by one, so this is no worse off in terms of security. It is non-repeating. 3. No linkability because different paths start at a completely different random number. If repeating is a concern then different paths use different keys. Carries forward to not just connection migration but mutli-path. 4. Supports key rollover just like gQUIC and currently defined draft RFC. 5. Allows for omitting the nonce when we use crypto that doesn=E2=80= =99t need it. 6. Allows for larger nonces for high data rates. 7. It doesn=E2=80=99t preclude any other type of non-repeating nonces= without having to modify the RFC! So implementations that want to use cryptographic nonces can still do so. The downsides: 1. Even with variable length encoding the extra PN field is more space used per packet when a nonce is required. I think we can do with 2 bytes= in version 1. 2. It=E2=80=99s not perfect unlinkabiltiy but I have yet to see any solu= tion that can provide this. A simple time based analysis using machine learni= ng will allow flow correlation especially for connection migration. The IP addresses in the clear allow for a high degree of correlation. There is also the application sending pattern and other signals that could be use= d. *From:* Eric Rescorla [mailto:ekr@rtfm.com] *Sent:* Friday, February 9, 2018 5:52 AM *To:* Praveen Balasubramanian *Cc:* huitema ; quic@ietf.org *Subject:* Re: Packet number encryption On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubramanian wrote: Actually taking a step back what if we don=E2=80=99t we overloaded packet n= umber as the nonce? Can we: 1. Put packet number as a separate variable length field in the encrypted portion of the header. This allows for growth beyond 64 bits i= n future and completely avoids ossification. For short lived flows variabl= e length encoding leads to minimal space overhead. 2. Put a separate plaintext nonce which starts out as a secure random number and monotonically increases as short random jumps (every packet o= r every few packets) and could then rollover. This will prevent linkabilit= y and scales to multi-path as well. No major compute overhead. We can also make the nonce optional for crypto algorithms that do not need a nonce saving more space. I'm not sure how to do #2 safely and efficiently. The primary concern is that short random jumps don't actually prevent linkability because the high order bits don't change and long random jumps are effectively randomly sampling out of the nonce space, and you start to run into birthday problems. Additionally, the cheapest PRNGs are basically ciphers in counter mode, so at best you're going to get a small amount of overhead reduction by getting multiple jump computations out of a single block, though if you use 96-bit jumps, you only get 25% savings... -Ekr Some MSB of the nonce could be used for signaling reorder to the network if needed. I don=E2=80=99t have the historical context for overloading of PN a= s the nonce so pardon me if un-overloading option was discussed and ruled out before. *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen Balasubramanian *Sent:* Thursday, February 8, 2018 5:51 PM *To:* huitema ; quic@ietf.org *Subject:* RE: Packet number encryption >> and using separate packet sequences for each path This alone prevents linkability right? >> The packet number on each path will start at 1 (or maybe 0 ;-). Is supporting multiple paths at the same time a goal? If yes, then yes all paths will need to have separate tracking and ACK state and congestion control etc. I thought this is not part of V1 RFC. If its just one additional path for connection migration scenario then all you need is a (random) jump to a offset in packet number space for the new path so that the few packets in the old path can continue for a little bit. This works with just one ACK space so no implementation complexity. >> 2) Or, leaving the packet number in the clear but using different encryption contexts for each path, and using separate packet sequences for each path. In addition if the value in the clear was obfuscated with an XOR transform it will help prevent ossification. The obfuscation is not meant to guard against later analysis that reveals the packet numbers - why do we care about that. It is meant to grease the space and not make the numbers serial so middleboxes cannot assume ordering etc. All said if I am alone in being concerned about the perf hit then I=E2=80= =99d say go on with option 1. *From:* QUIC [mailto:quic-bounces@ietf.org ] *On Behalf Of *Christian Huitema *Sent:* Thursday, February 8, 2018 3:54 PM *To:* quic@ietf.org *Subject:* Re: Packet number encryption On 2/8/2018 1:13 PM, Mike Bishop wrote: #2 won=E2=80=99t work. The packet number is an input to the AEAD nonce, so= you have to get to the packet number before you can decrypt the payload. It can=E2=80=99t be based on anything internal to the encrypted packet. In Martin=E2=80=99s proposal, it=E2=80=99s using a combination of the encry= pted payload (which requires nothing to access) and some stored state on each endpoint, which requires only the Connection ID to look up. You want the thing you XOR by to be constantly changing, or it becomes easier to look at sequences of obfuscated packet numbers and start drawing inferences about what the XOR value is. If overhead is the primary concern, I think there are a couple approaches that might allow you to precompute values and amortize the cost of doing the encryption step. (At the cost of keeping the table of precomputed values, of course.) I still think Jana=E2=80=99s pushing in the right direction here: Let=E2= =80=99s agree on goals, and then see if we can craft a design that meets those goals. I hear you saying that low overhead is a goal, which I think we can all agree on. I also think I hear you saying that 1-1.5% overhead is too high, but it sounds like there=E2=80=99s less agreement on that. You also raise an interesting point that some clients will care less about linkability because they will never intentionally migrate. I think Victor said it best, "Obfuscation is just encryption done poorly." Either we encrypt, or we don't. But there is no such thing as an obfuscation middle-ground. Obfuscation would just be a speed bump, easily broken. It won't provide privacy, and it won't prevent linkability. As far as I am concerned, there are only two designs that prevent linkability: 1) Martin's PR, in which the packet number is encrypted using sensible crypto; 2) Or, leaving the packet number in the clear but using different encryption contexts for each path, and using separate packet sequences for each path. The second option requires more computation when explicitly setting up a new path. The connection ID would be used as part of the "salt" when deriving connection contexts. The packet number on each path will start at 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK to be per/path, or alternatively adding a PATH-ACK frame that indicates the path for which packets are acked. The pros and cons of the two options are easy to get: 1) Option 2 does not require the cost of encrypting every packet, thus per packet processing will be maybe 1% faster than option 1. 2) Option 2 requires computing encryption contexts for each path, which is more complex than option 1, but the cost will be amortized over the duration of the path. 3) Option 2 requires more complex data structures and ACK management, thus increasing the chances that something goes wrong. 4) Option 2 does nothing against packet number ossification. The packet number effectively becomes part of the invariants. In short, the only advantage of option 2 is to avoid a single symmetric encryption operation per packet, while making the code significantly more complex, and at the cost of not protecting against PN ossification. The way I see that, there is hardly any debate. -- Christian Huitema --f403045d914c4603dc0564ce1166 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = The obvious advantag= e of a clear text nonce is that it can be immediately decrypted without ext= ra processing and without modifying the packet content, and it avoids laten= cy from a separate packet number decryption step.

However, having per path unique nonces per pat= h jumping randomly in order to gain an insignificant amount of anti-ossific= ation is not every appealing. Neither is the extra space required for havin= g both packet numbers and nonces, when they in the majority of cases is one= and the same, effectively. The random jumps are effectively a hidden encry= ption step although cheaper than packet number encryption.

So, I propose having a nonce that cou= nts from 0 per path per direction and also having a unique connection ident= ifier per path direction (asymmetric CID). Lets call this a half-path conte= xt (CID+nonce counter). It could also work shared path CID as today, but it= is not as clean.

The= nonce can at most count to 2^32-1 due to hard limits on AES-GCM and possib= ly general TLS requirements.

This leaves the packet number encoding:

If we enumerate each half-path with a path ID PI= D as a simpler counter starting at zero, we have a 1-1 mapping from PID to = CID. The packet number PN is then encoded as <PID * 2^32 + nonce counter= >. The PN is used explicitly and implicitly in ACK frames but is never c= arried directly on the wire.

During path migration packet numbers in the same ACK frame may have= large predictable jumps, but the ACK frame already competently deals with = this, and the jumps are limited to the number of concurrently active paths.=

<= div>The only loss is the ossification concern of having predictable per pat= h counters, but I think that is low price of admission. There are no linkab= ility concerns with this, and all the networking monitoring people would be= happy too.
Kind R= egards,
Mikk= el Fahn=C3=B8e J=C3=B8rgensen


On 9 February 2018 at 21.55.33, Deval, Manasi (manasi.deval@intel.com) wrote:

Going back to Ian=E2= =80=99s point here =E2=80=93 Can you be explicit about the issue you see in= the packet number encryption?

=C2=A0

Thanks,

Manasi

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Friday, February 09, 2018 11:59 AM
To: David Benjamin <davi= dben@chromium.org>
Cc: Eric Rescorla <ekr@rtfm.com>; quic@ietf.org; huitema <huitema@huitema.net>
Subject: RE: Packet number encryption

=C2=A0

With VLE its minimal overhead per packet so you are = not encrypting 4 bytes more all the time even with 64 bit or 128 bit packet= number . So its decidedly better. Also fewer calls into TLS, but I suppose= one could do some refactoring of TLS API. Many CPUs yes but this is a general purpose transport and could r= un on CPUs that don=E2=80=99t.

=C2=A0

Didn=E2=80=99t ask for nonce to be variable length. = Fixed length for connection lifetime. Datacenters connections could use 64-= bit nonce to avoid frequent key rollover.

=C2=A0

Effectively the plain text nonce is a sequence numbe= r since it increases monotonically with small jumps as needed to avoid ossi= fication. So no worse off than gQUIC or current draft. No more complex than= using the packet number. Just the starting number is randomized. Also please notice that this proposal does = not preclude using encrypted packet number as the nonce as proposed previou= sly. Changing how the nonce works makes 0 impact on the transport logic. An= implementation can choose to implement any form of non-repeating nonce without revving the RFC. This is the bigge= st advantage of separation of concerns IMHO.

=C2=A0

From: David Benjamin [mailto:davidben@chromium.org]
Sent: Friday, February 9, 2018 11:39 AM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Eric Rescorla <ekr@rtfm.com>; quic@ietf.org; huitema <huitema@huitema.net>
Subject: Re: Packet number encryption

=C2=A0

Your primary worry here was the extra block cipher o= peration, right? By moving the packet number into the plaintext, this propo= sal increases the length, which will cost that same one extra block cipher = operation, no?

=C2=A0

It is one block operation under the same key, rather= than a different key so I suppose there are minuscule=C2=A0cache footprint= wins (one symmetric key is 16 or 32 bytes). But the cost is per-packet (!)= bandwidth and complexity. I do not see how this could be worth it.=C2=A0Note that, for AES, many CPUs have dedica= ted instructions for it already.

=C2=A0

>=C2=A0Clear separation of concerns results if we= don=E2=80=99t overload the packet number as the nonce. Connection migratio= n and multi-path are optional features and we pay no extra compute cost for= most connections that are not impacted by unlnkability. Nonce field becomes optional for crypto that doesn=E2=80=99t need it and c= an grow to larger size as needed for bulk transfers to prevent frequent key= rollovers (say in datacenter scenarios).

=C2=A0

You're not going to find AEADs that don't re= quire a nonce. Encryption must not produce the same ciphertext twice for th= e same plaintext, so you need some input to diversify them. That input is t= he nonce. Nonces also are not variable-length, so you don't get to arbitrarily grow them. (AES-GCM per spec is variab= le length, but that's a spec bug. If you size it above 96 bits, it'= s as if you randomized it and your nonce space crashes per birthday.)

=C2=A0

It is also harmful to separate the two concerns.=C2= =A0When you are building a transport, derive the nonce from a sequence numb= er. TLS 1.2 AES-GCM separated them, which was a mistake. It's less effi= cient (the world wasted quite a lot of bandwidth due to this), and more error-prone. There was nothing stopping implementat= ions from sending the same nonce or generating nonces randomly (the AEADs w= e use don't have large enough nonces for that), and indeed some did jus= t that. If you use some sort of sequence number, you can lean on existing work both to filter out the obvious imple= mentation mistakes and to avoid sending unnecessary data.

=C2=A0

On Fri, Feb 9, 2018 at 12:38 PM Praveen Balasubraman= ian <pravb@micr= osoft.com> wrote:

Let me try to summarize the proposal again:

=C2=A0

  1. Packet number is in the encrypted portion of the header and is no longer us= ed as the nonce. It is encoded as a variable length number. Always starts a= t 0.
    1. No ossification of PN
    2. No linkability using PN
    3. Allows for growth beyond 64 bits if needed in future
  1. The nonce is in the clear in plaintext header. It is generated per path<= /i> as a secure random number. Call this the =E2=80=9Cstarting value=E2=80= =9D. Both sides MUST initialize the =E2=80=9Cstarting value=E2=80=9D nonce per path. Within a path it grows monotonically (to avoid repeats jus= t like PN today) and can include short random jumps periodically so that mi= ddleboxes cannot assume anything about the field. Since nonce has nothing t= o do with PN the jumps don=E2=80=99t add any complexity to transport logic. Jumps are for greasing and preventing o= ssification. When the nonce rolls over and reaches close to the =E2=80=9Cst= arting value=E2=80=9D, key rollover must happen. At high data rates the non= ce field can be 64-bits to prevent frequent key rollover. For crypto that doesn=E2=80=99t need nonces, the field can be om= itted.
    1. No ossification because there is no pre-determined sequence to the nonce.
    2. In gQUIC and the RFC as defined the nonce is a simple sequence that increme= nts by one, so this is no worse off in terms of security. It is non-repeati= ng.
    3. No linkability because different paths start at a completely different rand= om number. If repeating is a concern then different paths use different key= s. Carries forward to not just connection migration but mutli-path.
    4. Supports key rollover just like gQUIC and currently defined draft RFC.
      5. =
    5. Allows for omitting the nonce when we use crypto that doesn=E2=80=99t need = it.
    6. Allows for larger nonces for high data rates.
    7. It doesn=E2=80=99t preclude any other type of non-repeating nonces without = having to modify the RFC! So implementations that want to use cryptographic= nonces can still do so.

=C2=A0

The downsides:

  1. Even with variable length encoding the extra PN field is more space used pe= r packet when a nonce is required. I think we can do with 2 bytes in versio= n 1.
  2. It=E2=80=99s not perfect unlinkabiltiy but I have yet to see any solution t= hat can provide this. A simple time based analysis using machine learning w= ill allow flow correlation especially for connection migration. The IP addr= esses in the clear allow for a high degree of correlation. There is also the application sending pattern and other si= gnals that could be used.

=C2=A0

From: Eric Rescorla [mailto:ekr@rtfm.com]
Sent: Friday, February 9, 2018 5:52 AM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: huitema <huitema@huitema.net>; quic@ietf.org


Subject: Re: Packet number encryption

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubramanian <pravb@microsoft.com&= gt; wrote:

Actually taking a step back what if we don=E2=80=99t we overloaded= packet number as the nonce?

=C2=A0

Can we:

  1. Put packet number as a separate variable length field in the encrypted port= ion of the header. This allows for growth beyond 64 bits in future and comp= letely avoids ossification. For short lived flows variable length encoding = leads to minimal space overhead.
  2. Put a separate plaintext nonce which starts out as a secure random number a= nd monotonically increases as short random jumps (every packet or every few= packets) and could then rollover. This will prevent linkability and scales= to multi-path as well. No major compute overhead. We can also make the nonce optional for crypto algorithm= s that do not need a nonce saving more space.

=C2=A0

I'm not sure how to do #2 safely and efficiently. The primary = concern is that short random jumps don't actually prevent linkability b= ecause the high order bits don't change and long random jumps are effectively randomly sampling out of the nonce space= , and you start to run into birthday problems. Additionally, the cheapest P= RNGs are basically ciphers in counter mode, so at best you're going to = get a small amount of overhead reduction by getting multiple jump computations out of a single block, though if you= use 96-bit jumps, you only get 25% savings...

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

Some MSB of the nonce could be used for signaling reorder to the n= etwork if needed. I don=E2=80=99t have the historical context for overloadi= ng of PN as the nonce so pardon me if un-overloading option was discussed and ruled out before.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Thursday, February 8, 2018 5:51 PM
To: huitema <huitema@huitema.net>; quic@ietf.org
Subject: RE: Packet number encryption

=C2=A0

>> and using separate packet sequences for each path

This alone prevents linkability right?

=C2=A0

>> The packet number on each path will start at 1 (or maybe = 0 ;-).

Is supporting multiple paths at the same time a goal? If yes, then= yes all paths will need to have separate tracking and ACK state and conges= tion control etc. I thought this is not part of V1 RFC. If its just one additional path for connection migrati= on scenario then all you need is a (random) jump to a offset in packet numb= er space for the new path so that the few packets in the old path can conti= nue for a little bit. This works with just one ACK space so no implementation complexity.

=C2=A0

>> 2) Or, leaving the packet number in the clear but using d= ifferent encryption contexts for each path, and using separate packet seque= nces for each path.
In addition if the value in the clear was obfuscated with an XOR transform = it will help prevent ossification. The obfuscation is not meant to guard ag= ainst later analysis that reveals the packet numbers - why do we care about= that. It is meant to grease the space and not make the numbers serial so middleboxes cannot assume orderin= g etc.

=C2=A0

All said if I am alone in being concerned about the perf hit then = I=E2=80=99d say go on with option 1.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Thursday, February 8, 2018 3:54 PM
To: quic@ietf.org=
Subject: Re: Packet number encryption

=C2=A0

On 2/8/2018 1:13 PM, Mike Bishop wrote:

#2 won=E2=80=99t work.=C2=A0 The packet number is an input to the = AEAD nonce, so you have to get to the packet number before you can decrypt = the payload.=C2=A0 It can=E2=80=99t be based on anything internal to the encrypted packet.

=C2=A0

In Martin=E2=80=99s proposal, it=E2=80=99s using a combination of = the encrypted payload (which requires nothing to access) and some stored st= ate on each endpoint, which requires only the Connection ID to look up.=C2=A0 You want the thing you XOR by to be constantly changi= ng, or it becomes easier to look at sequences of obfuscated packet numbers = and start drawing inferences about what the XOR value is.=C2=A0 If overhead= is the primary concern, I think there are a couple approaches that might allow you to precompute values and amortize= the cost of doing the encryption step.=C2=A0 (At the cost of keeping the t= able of precomputed values, of course.)

=C2=A0

I still think Jana=E2=80=99s pushing in the right direction here:= =C2=A0 Let=E2=80=99s agree on goals, and then see if we can craft a design = that meets those goals.=C2=A0 I hear you saying that low overhead is a goal, which I think we can all agree on.=C2=A0 I also think I hear yo= u saying that 1-1.5% overhead is too high, but it sounds like there=E2=80= =99s less agreement on that.=C2=A0 You also raise an interesting point that= some clients will care less about linkability because they will never intentionally migrate.


I think Victor said it best, "Obfuscation is just encryption done poor= ly." Either we encrypt, or we don't. But there is no such thing as= an obfuscation middle-ground. Obfuscation would just be a speed bump, easi= ly broken. It won't provide privacy, and it won't prevent linkability.

As far as I am concerned, there are only two designs that prevent linkabili= ty:

1) Martin's PR, in which the packet number is encrypted using sensible = crypto;

2) Or, leaving the packet number in the clear but using different encryptio= n contexts for each path, and using separate packet sequences for each path= .

The second option requires more computation when explicitly setting up a ne= w path. The connection ID would be used as part of the "salt" whe= n deriving connection contexts. The packet number on each path will start a= t 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK= to be per/path, or alternatively adding a PATH-ACK frame that indicates th= e path for which packets are acked.

The pros and cons of the two options are easy to get:

1) Option 2 does not require the cost of encrypting every packet, thus per = packet processing will be maybe 1% faster than option 1.

2) Option 2 requires computing encryption contexts for each path, which is = more complex than option 1, but the cost will be amortized over the duratio= n of the path.

3) Option 2 requires more complex data structures and ACK management, thus = increasing the chances that something goes wrong.

4) Option 2 does nothing against packet number ossification. The packet num= ber effectively becomes part of the invariants.

In short, the only advantage of option 2 is to avoid a single symmetric enc= ryption operation per packet, while making the code significantly more comp= lex, and at the cost of not protecting against PN ossification. The way I s= ee that, there is hardly any debate.

-- Christian Huitema

=C2=A0

--f403045d914c4603dc0564ce1166-- From nobody Fri Feb 9 13:20:10 2018 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 7F10C1270AE for ; Fri, 9 Feb 2018 13:20:08 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 fT8szALFkimF for ; Fri, 9 Feb 2018 13:20:06 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0094.outbound.protection.outlook.com [104.47.38.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19F91270A3 for ; Fri, 9 Feb 2018 13:20:05 -0800 (PST) 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=WVtCAZY0g7UdTl0Z/poGGNnfHR9g3qM3/oHeKzT3nRw=; b=EGDg2mp/DbtgWwwW3KGIT3XF6JF4vgKgon/FGkfwWAnLlh5SzlXGSoT6ZLdL+MFKKtRSc9gLCWBsVHGjeG3vGu5Rc8q8qWyQPm1F3jrAmz7qdpvW1AwBkZarGZvCcEC4qBe6/BPixyA6JY6BpbQSUweV45P6h1JV5AuISUZQLWg= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0856.namprd21.prod.outlook.com (10.173.192.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.1; Fri, 9 Feb 2018 21:20:03 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 21:20:03 +0000 From: Praveen Balasubramanian To: Victor Vasiliev CC: Marten Seemann , "quic@ietf.org" , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAbWdAIAAKHbggAGCSACAAABM8A== Date: Fri, 9 Feb 2018 21:20:03 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0856; 7:7itj44qlM/XkrB4S1cPTYV5KyyaRJW7CsK2n+QmDIaP/CNQt8yi5qx6+s2Ks6+wXQcPe3BR4wx1fT5G8t3oFitKBm9c/vy9fJJf13lZ1rZJFC+S2E8aRe4VYWhJNo57sL6fZScGA4MWXGGtI2IVFX/P+/7+ti6bKTETJy/L5yMlsNKfNUl3X69EXeO87WKcQaBXS0JA0vzglfl5OgDLlxry9C7RPUNNL7DkQPoi4L5oBltcP1ojd8EDKBk4Atxus x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a2a909d4-6576-4e7d-08c6-08d57002e2c6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0856; x-ms-traffictypediagnostic: CY4PR21MB0856: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(944501161)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0856; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0856; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(376002)(396003)(366004)(346002)(189003)(199004)(74316002)(790700001)(6116002)(86362001)(2906002)(5660300001)(7116003)(68736007)(81166006)(54906003)(81156014)(8936002)(3280700002)(8676002)(561944003)(33656002)(3480700004)(3660700001)(316002)(2900100001)(19609705001)(22452003)(106356001)(5250100002)(4326008)(9686003)(6246003)(55016002)(39060400002)(54896002)(236005)(6306002)(6436002)(229853002)(53936002)(2950100002)(102836004)(53546011)(6506007)(7736002)(6916009)(6346003)(86612001)(25786009)(76176011)(93886005)(14454004)(7696005)(99286004)(186003)(97736004)(478600001)(10290500003)(10090500001)(8990500004)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0856; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: 8tI8Ta58KuwhOWxEmi36cqGmmSZHAWz31tAi0OCILQKabYAfoP8X8MX9i+WSlnUdlsw0buJScf524N5BdOV7kw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01336C1E0AB349A62AE1F9CEB6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a2a909d4-6576-4e7d-08c6-08d57002e2c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 21:20:03.8574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0856 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, 09 Feb 2018 21:20:08 -0000 --_000_CY4PR21MB01336C1E0AB349A62AE1F9CEB6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIGlnbm9yZSB0aGUgcHJldmlvdXMgcHJvcG9zYWwgYW5kIGxvb2sgYXQgdGhlIG5ldyBw cm9wb3NhbCB3aGVyZSBQTiBpcyBlbmNyeXB0ZWQgYW5kIGRlY291cGxlZCBmcm9tIHRoZSBub25j ZS4gSSBhbSBhYmFuZG9uaW5nIHRoZSBwcmV2aW91cyBwcm9wb3NhbCB0aGF0IHdhcyB0cnlpbmcg dG8gdXNlIG9iZnVzY2F0aW9uIG9mIFBOIGluIGNsZWFydGV4dC4NCg0KRnJvbTogVmljdG9yIFZh c2lsaWV2IFttYWlsdG86dmFzaWx2dkBnb29nbGUuY29tXQ0KU2VudDogRnJpZGF5LCBGZWJydWFy eSA5LCAyMDE4IDE6MTcgUE0NClRvOiBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiA8cHJhdmJAbWlj cm9zb2Z0LmNvbT4NCkNjOiBNYXJ0ZW4gU2VlbWFubiA8bWFydGVuc2VlbWFubkBnbWFpbC5jb20+ OyBxdWljQGlldGYub3JnOyBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KU3ViamVjdDog UmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpPbiBUaHUsIEZlYiA4LCAyMDE4IGF0IDU6 MzIgUE0sIFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPG1haWx0 bzpwcmF2YkBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpBRkFJQ1QgdGhlIGdvYWwgaXMgdG8gcGVy Zm9ybSBzb21lIHRyYW5zZm9ybSBmb3IgcHJldmVudGluZyBtaWRkbGVib3ggb3NzaWZpY2F0aW9u LiBFbmNyeXB0aW9uIGlzIG9uZSBwb3NzaWJsZSB0cmFuc2Zvcm0gYnV0IGlzIGl0IHRoZSBvbmx5 IHBvc3NpYmxlIG9uZT8NCg0KVGhlIGdvYWwgb2YgdGhlIHRyYW5zZm9ybSBpcyB0byBwcmV2ZW50 IHRoZSBtaWRkbGVib3hlcyBmcm9tIGludGVycHJldGluZyB0aGUgcGFja2V0IG51bWJlciwgc28g eWVzLCBhbnl0aGluZyB5b3UnbGwgcHJvcG9zZSB3b3VsZCBiZSBlbmNyeXB0aW9uLg0KDQpUaGUg bnVtYmVycyBJIHF1b3RlZCB3ZXJlIGZyb20gYSBxdWljayB0ZXN0IGJ5IG1vZGlmeWluZyB0aGUg d2lucXVpYyBpbXBsZW1lbnRhdGlvbiB0byBhZGQgYW4gYWRkaXRpb25hbCBlbmNyeXB0IC8gZGVj cnlwdCBzdGVwIG9uIHBhY2tldCBudW1iZXIgc2l6ZSB3b3J0aCBvZiBkYXRhLiBJZiBhbnlvbmUg ZWxzZSBoYXMgYW55IGRhdGEgcGxlYXNlIHNoYXJlLg0KDQpJIGFtIHZlcnkgY29uZnVzZWQgYWJv dXQgdGhlIDEuMjUlIG51bWJlci4gIDEyODAgYnl0ZXMgaXMgYWJvdXQgODAgQUVTIGJsb2Nrcywg YW5kIG9uZSBleHRyYSBibG9jayBpcyAxLjI1JSBvbiB0b3Agb2YgdG90YWwgKmVuY3J5cHRpb24q IGNvc3RzICh5b3UgZG9uJ3QgaGF2ZSB0byBNQUMgdGhlIFBOLCBzbyB0aGF0J3MgZXZlbiBjaGVh cGVyKS4gIEFuZCB0aGUgZW5jcnlwdGlvbiBpdHNlbGYgaXMgZmFpcmx5IGNoZWFwIGNvbXBhcmVk IHRvIGFsbW9zdCBhbnkgb3RoZXIgcGFydCBvZiB0aGUgUVVJQyBzdGFjayAoc2VudCBwYWNrZXQg dHJhY2tpbmcsIGFjayBwcm9jZXNzaW5nLCBJL08sIHRpbWVycywgZXRjKS4NCg== --_000_CY4PR21MB01336C1E0AB349A62AE1F9CEB6F20CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBpZ25vcmUgdGhlIHByZXZpb3VzIHByb3Bvc2FsIGFu ZCBsb29rIGF0IHRoZSBuZXcgcHJvcG9zYWwgd2hlcmUgUE4gaXMgZW5jcnlwdGVkIGFuZCBkZWNv dXBsZWQgZnJvbSB0aGUgbm9uY2UuIEkgYW0gYWJhbmRvbmluZyB0aGUgcHJldmlvdXMgcHJvcG9z YWwgdGhhdCB3YXMgdHJ5aW5nIHRvIHVzZSBvYmZ1c2NhdGlvbiBvZiBQTiBpbiBjbGVhcnRleHQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBWaWN0b3IgVmFzaWxpZXYgW21h aWx0bzp2YXNpbHZ2QGdvb2dsZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1 YXJ5IDksIDIwMTggMToxNyBQTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3VicmFtYW5p YW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0ZW4gU2Vl bWFubiAmbHQ7bWFydGVuc2VlbWFubkBnbWFpbC5jb20mZ3Q7OyBxdWljQGlldGYub3JnOyBodWl0 ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog UGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFRodSwgRmViIDgsIDIwMTggYXQgNTozMiBQTSwgUHJhdmVlbiBCYWxh c3VicmFtYW5pYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpwcmF2YkBtaWNyb3NvZnQuY29tIiB0YXJn ZXQ9Il9ibGFuayI+cHJhdmJAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QUZBSUNUIHRoZSBnb2FsIGlzIHRv IHBlcmZvcm0gc29tZSB0cmFuc2Zvcm0gZm9yIHByZXZlbnRpbmcgbWlkZGxlYm94IG9zc2lmaWNh dGlvbi4gRW5jcnlwdGlvbiBpcyBvbmUgcG9zc2libGUgdHJhbnNmb3JtIGJ1dCBpcyBpdCB0aGUg b25seSBwb3NzaWJsZSBvbmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGdvYWwgb2YgdGhlIHRy YW5zZm9ybSBpcyB0byBwcmV2ZW50IHRoZSBtaWRkbGVib3hlcyBmcm9tIGludGVycHJldGluZyB0 aGUgcGFja2V0IG51bWJlciwgc28geWVzLCBhbnl0aGluZyB5b3UnbGwgcHJvcG9zZSB3b3VsZCBi ZSBlbmNyeXB0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t cmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoZSBudW1iZXJzIEkgcXVvdGVkIHdlcmUgZnJvbSBhIHF1aWNrIHRlc3Qg YnkgbW9kaWZ5aW5nIHRoZSB3aW5xdWljIGltcGxlbWVudGF0aW9uIHRvIGFkZCBhbiBhZGRpdGlv bmFsIGVuY3J5cHQgLyBkZWNyeXB0IHN0ZXAgb24gcGFja2V0IG51bWJlciBzaXplIHdvcnRoIG9m IGRhdGEuIElmIGFueW9uZSBlbHNlDQogaGFzIGFueSBkYXRhIHBsZWFzZSBzaGFyZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGFtIHZlcnkgY29uZnVzZWQgYWJvdXQgdGhlIDEuMjUlIG51bWJlci4m bmJzcDsgMTI4MCBieXRlcyBpcyBhYm91dCA4MCBBRVMgYmxvY2tzLCBhbmQgb25lIGV4dHJhIGJs b2NrIGlzIDEuMjUlIG9uIHRvcCBvZiB0b3RhbCAqZW5jcnlwdGlvbiogY29zdHMgKHlvdSBkb24n dCBoYXZlIHRvIE1BQyB0aGUgUE4sIHNvIHRoYXQncyBldmVuIGNoZWFwZXIpLiZuYnNwOyBBbmQg dGhlIGVuY3J5cHRpb24gaXRzZWxmIGlzIGZhaXJseQ0KIGNoZWFwIGNvbXBhcmVkIHRvIGFsbW9z dCBhbnkgb3RoZXIgcGFydCBvZiB0aGUgUVVJQyBzdGFjayAoc2VudCBwYWNrZXQgdHJhY2tpbmcs IGFjayBwcm9jZXNzaW5nLCBJL08sIHRpbWVycywgZXRjKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB01336C1E0AB349A62AE1F9CEB6F20CY4PR21MB0133namp_-- From nobody Fri Feb 9 13:27:45 2018 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 022221242F7 for ; Fri, 9 Feb 2018 13:27:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 ZEYLjBsDF_La for ; Fri, 9 Feb 2018 13:27:42 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 616B81272E1 for ; Fri, 9 Feb 2018 13:27:39 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id f89so11154329ioj.4 for ; Fri, 09 Feb 2018 13:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=Cyk6TVoPbikO0Rm7c3Ni6R4nqsHDu7OayY+0D2jqehM=; b=BN/64F/NfC3/PshDGoA4Dled5JsSJujq/E6bZBPNQH+tKjeLarIF5w4//PRyWpiIrm PueRTgtKw9k/RTXyZyMZuhAS5PPhz3yIIa4Q+RD1kkr2yhcMidSQkdm29QYj6J6f1VrA XVdvysy5nHB8ZGCTLmWUy/m6IKcA3OI5CTjqhAKPG4nA0dVkrW0l1ANL06QgWijuvELT X7nPN6bfN0X6v3s43LvwNarYwa47afb2/2n+GRzokVrS57vlWQG6rwModSLLbZT1Tfs9 IP7qGetuurgJk1ZCnZIqvBVO3v7MBmIjso8IFsXMArqz6ehmfywZN4xFN2Dguo0OQvq6 sukQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=Cyk6TVoPbikO0Rm7c3Ni6R4nqsHDu7OayY+0D2jqehM=; b=rrTolTLREmuptKL1IuHt3o7B8/QVUG9lFSmoTtomWR4BgKAvwPXBfd9gqM4YTaBG71 EkH35HnoncqhjdJiauP2MhLrubeouJXMHWzMxJ0wEZAtH07V9ap8gcehgynhX+WBtAwI 7BXLTyNiveFH7zLW3jCwsrpLfmd6zWjLVebX31Dsw50chhLlKwB70IunHqv9GCB2Nr0V LlrqXgVgACaYNakQ4q33GZzOq2f53LFctd+RakxUL3mJI8JBcLrv6mS4UeM6XrAPOKBO VQTetbYoshX+dPg8ZMLPdrToTyH+8yqOgACZcI3M41LzEvi7oa/lbVmt1W9FfDCAZ7om Z7Vg== X-Gm-Message-State: APf1xPAsaXfnYc2KiwANQae98tARCkVuhpmoqmAWCSHg5FGtbfQ8mfrO x185ZgEzN9Ln2UaZNapdV7dPvvtpcmseXT4Rgxg= X-Google-Smtp-Source: AH8x225KieAX7rsPgbS7rvR7O0kLRHa/oPKU9fvHFevHvK7xE2fkdIWL+ANCS8YbaaY6JKEHAeFAYgJecUNHz0yJ1eQ= X-Received: by 10.107.34.199 with SMTP id i190mr5079118ioi.297.1518211658747; Fri, 09 Feb 2018 13:27:38 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 13:27:38 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 13:27:38 -0800 Message-ID: Subject: Re: Packet number encryption To: Victor Vasiliev , Praveen Balasubramanian Cc: "quic@ietf.org" , huitema , Marten Seemann Content-Type: multipart/alternative; boundary="001a1140d9449d126c0564ce3224" 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, 09 Feb 2018 21:27:44 -0000 --001a1140d9449d126c0564ce3224 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am very confused about the 1.25% number. 1280 bytes is about 80 AES blocks, and one extra block is 1.25% on top of total *encryption* costs (you don't have to MAC the PN, so that's even cheaper). And the encryption itself is fairly cheap compared to almost any other part of the QUIC stack (sent packet tracking, ack processing, I/O, timers, etc). This is for the large file upload case. It does not consider low latency applications with small messages and separate cores for different responsibilities. It also does not consider that that a single block costs the same as 4 blocks on Intel, nor does it consider that the packet cannot be decoded in-place. But yes, in the common large file download case, the cost is not very significant. But it can be significant enough to choose another protocol in other scenarios. So there needs to be a really good reason to add this extra latency step. Linkability might be an argument, and ossification might be too, and the complexity of alternatives might as well. However, I=E2=80=99m not convinced. I=E2=80=99m also not completely d= ismissing it, but I would like to see alternatives explored more thoroughly before throwing in a cost for no good reason. --001a1140d9449d126c0564ce3224 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
I am ve= ry confused about the 1.25% number.=C2=A0 1280 bytes is about 80 AES blocks= , and one extra block is 1.25% on top of total *encryption* costs (you don&= #39;t have to MAC the PN, so that's even cheaper).=C2=A0 And the encryp= tion itself is fairly cheap compared to almost any other part of the QUIC s= tack (sent packet tracking, ack processing, I/O, timers, etc).
<= /div>

This is for the large f= ile upload case. It does not consider low latency applications with small m= essages and separate cores for different responsibilities. It also does not= consider that that a single block costs the same as 4 blocks on Intel, nor= does it consider that the packet cannot be decoded in-place. But yes, in t= he common large file download case, the cost is not very significant. But i= t can be significant enough to choose another protocol in other scenarios. = So there needs to be a really good reason to add this extra latency step. L= inkability might be an argument, and ossification might be too, and the com= plexity of alternatives might as well. However, I=E2=80=99m not convinced. = I=E2=80=99m also not completely dismissing it, but I would like to see alte= rnatives explored more thoroughly before throwing in a cost for no good rea= son.

=
--001a1140d9449d126c0564ce3224-- From nobody Fri Feb 9 13:35:08 2018 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 41A3F127275 for ; Fri, 9 Feb 2018 13:35:06 -0800 (PST) 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 8KiYkqXKuL6Z for ; Fri, 9 Feb 2018 13:35:04 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 3E3881242F7 for ; Fri, 9 Feb 2018 13:35:04 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id r23so9026204ote.8 for ; Fri, 09 Feb 2018 13:35:04 -0800 (PST) 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=KtTYsl4MeT6CSM57xgToR9KwAPbbVs2FCMSAwb8ms4k=; b=D47jwfbz0fABuZybS9glhq8Ml/PfCtAYHQD4UsJq5KVFPHYhfxQr7N3xKbKQqedZ6z GlMS3vGKi+Ov1y020b76k5raD5GSLIsy4YOoZVrdInydZ62Xp+EN6AeIFjT0+NZJA5ur E08Y4waq6qJwVaAxTLnsGSBbs1Qv1zBOiRFi24/bK95IpPwmJgkxOQATaSxCcxpYF1ym lVvRKMK0Jy3PTFHRdIXFZBCSwN8jrx8mCEIysCc96TMNWeKWxOPaR6nF0Op58Z89RcvS EQuHdpSDqDriFbJfmut+peJbSOSAtEnjQkoKQ3ttIYgWE17ZKfWrjJd0FhNnTvEs7d+Z hzSA== 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=KtTYsl4MeT6CSM57xgToR9KwAPbbVs2FCMSAwb8ms4k=; b=Dn+sEYl0v/HnItKoFbHIV3xieTJ9halFoHfhKpbFX3jwQgJJo6jED3bBTTpJLKWZ7h HzyaGBAumGgXOd6ORV51nObfguBstXcZPIBJ0TRGJOBighSTIdg1lWq7H9aTJ8ohuQNJ RZrT9VkfWquukfPPv4Io6AN61NEuuHiRGEqWkRUqhenyeNi23aNAi3fwCM0nLXYSy//M TnRZx16Gm/gdBnCA1tJgA59hDWSGs7D2p6d2SCW3vcVC8DYedT1T0IaPLELFkk3+q0hn oAGnXEBPRruE7zYSAkVi6+53U4e4GEFhT0bAxYm+s+9M8Q0GepjVVyVxQrjDCP+sI4GO cyIg== X-Gm-Message-State: APf1xPA8TGMS9MbuFtabo/Zw7CTTij+cuf/XHr1s+rfWZlNAZPrzdUuK zlx1NziSGTqTe/knrDkxR/Fs7MOmUOnlkA6HvIc= X-Google-Smtp-Source: AH8x224wZILZqLd0lJZ9xZZetv6sv8f0jvtFTeaWOJA03HRMJffXVH0A5Cc+IocpC7KR7u6Vj8Q1sZsFBeEv+OouqUk= X-Received: by 10.157.46.206 with SMTP id w72mr3476634ota.16.1518212103546; Fri, 09 Feb 2018 13:35:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Fri, 9 Feb 2018 13:35:03 -0800 (PST) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAD6C5A@bgb01xud1012> From: Martin Thomson Date: Sat, 10 Feb 2018 08:35:03 +1100 Message-ID: Subject: Re: Review of QCRAM To: Mike Bishop Cc: Lucas Pardue , 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, 09 Feb 2018 21:35:06 -0000 On Sat, Feb 10, 2018 at 4:56 AM, Mike Bishop wrote: > Your observation that you=E2=80=99re keeping a tuple of stream-blocknum o= n each > entry is interesting. Can you go into more detail where this is? Couldn= =E2=80=99t > you also keep a simple refcount of outstanding blocks, then separately tr= ack > which entries are referenced by outstanding blocks? IIRC, in QCRAM there= =E2=80=99s > not a situation in which you need to determine which outstanding header > block is blocking eviction, only whether an outstanding HEADERS frame blo= cks > eviction. Or am I misunderstanding where you=E2=80=99re keeping the tupl= e? So you send out two header blocks on a stream. One includes :status=3D307, the other digest=3Dblah. When the acks come in, they identify the stream. The first ack needs to ensure that it removes any block on :status=3D307, the second digest=3Dblah. You can't just say that ":status=3D307 is blocked from eviction, because you need to know when it is no longer blocked, which means tracking where you sent it. A refcount of outstanding blocks will likely never hit zero, meaning you can never evict. I realize now that I didn't consider stream resets, which my scheme doesn't manage well (you need to have a nuke-all-that-partially-match option). From nobody Fri Feb 9 13:36:08 2018 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 E6EA61272E1 for ; Fri, 9 Feb 2018 13:36:06 -0800 (PST) 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 vJ4s-ZYi1gxg for ; Fri, 9 Feb 2018 13:36:04 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 19CF91242F7 for ; Fri, 9 Feb 2018 13:36:04 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id f56so9026032otj.13 for ; Fri, 09 Feb 2018 13:36:04 -0800 (PST) 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=Zo3ZNFx/VHF6vj0ubpjxONeDSjqEb9QLqRBHEP0MLN4=; b=J9ZfCR9YG5CWfTGs11duKsZbjO7Ixn11ot0tPrJA0EmTh5y/lIqzPI8ptZ1/4Jar4X LbVXFinR0rHxeakAiMPR7/zlponc1uSMPHf0AClltko412vFxiZHp5+zh3t3MrvjQLMG YcIbL2S+xJg7oO9s6f7V+pklx3wweLdwK4ei6lNLntGYoasyjDD5/cNaQpbhFdg9/ZmF 3P1vGIhMcr/wzW612VrvxtUqF3iW/yD8wt4y3wqXsk5MmG99aYDAWtX9Mal97ESgaGOh isL14Ha8wfqtDJl5qLZismZ+A6Io3XExUFotnizotsuSJLwsH2aOOgxqyKSd5kl77Ovz mA7w== 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=Zo3ZNFx/VHF6vj0ubpjxONeDSjqEb9QLqRBHEP0MLN4=; b=FXnM83mAD9Q++jnPN9tiMkL4QNpxRzQV9JcHhQpZNNAupIi+R8eEhCx/MrYXy2uAto 2ik63KJNAfpYnb/2xurjVZNEfDEexva5S7a56Lk0HxMeqIBQoW9GlZLFacto7wgwfzkb fswlEWuoWruGRTqXUpyKYhc9tReQhch3cTpFGg+fdAm30Bg4WHrTyrJiArtIOXxoK84K W7/8AU64N1tBlSUWGCsU+i275TCqS/9JvUwU7aJVazXXETSRalUJJEqBN1wJw5BPf/kp EDbYV7LC7aXlsSFcdxlyGiQKG+GkzhmUuRWzxQNjdnczOEzBDyeoTRxO8LSY4wZc3NWs 0btA== X-Gm-Message-State: APf1xPAk585tCaNeAWeeLfDQq3L6jpOn/ZT4NgBUFsRebIZtRaEEcNHp tuC4zZdshKQso7BYeeFAAZr8h/2onwvreASKxAJgTg== X-Google-Smtp-Source: AH8x225PkGJF/T8t9PVxSlbJcN3LghMCzDyKKD9yS14sipCeZL/Jlku2AJbx+e+qWLGVGigcUrwnfNzNkXVndCUHFS8= X-Received: by 10.157.50.132 with SMTP id u4mr3460654otb.133.1518212163355; Fri, 09 Feb 2018 13:36:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Fri, 9 Feb 2018 13:36:02 -0800 (PST) In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAD6C5A@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAD6C5A@bgb01xud1012> From: Martin Thomson Date: Sat, 10 Feb 2018 08:36:02 +1100 Message-ID: Subject: Re: Review of QCRAM To: Lucas Pardue 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: Fri, 09 Feb 2018 21:36:07 -0000 It would be relatively easy in my implementation to have different static tables. (I was a bit harder in other versions of my code.) On Fri, Feb 9, 2018 at 9:51 PM, Lucas Pardue wrote: > Hi Martin, > > Very interesting, thanks. > > Given that your implementation supports both HPACK and QCRAM, do you have any opinion how much pain it would be to have different static tables between them? > > Regards > Lucas > >> -----Original Message----- >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Martin Thomson >> Sent: 09 February 2018 10:09 >> To: QUIC WG >> Subject: Review of QCRAM >> >> I have implemented QCRAM and have a few things to comment on. >> >> My implementation is here: >> https://github.com/martinthomson/minhq/tree/master/hc >> >> This is my first attempt at go, so this took a little longer than it might have >> otherwise. Test coverage is still a little light, though go thinks that I have >> pretty good coverage. There's probably still a lot to go on the corner cases, >> but I think that I've done enough to get an idea for the complexity bump. >> >> I started by implementing HPACK, which is surprisingly easy if you don't care >> about being efficient. Though I knew that I was going to add QCRAM, I made >> only minimal design concessions when building HPACK. >> >> Building QCRAM on top of HPACK took at least 50% more than just doing >> HPACK (at a guess, HPACK took about 10-12 hours, QCRAM took closer to 20). >> Even though you can reuse Huffman coding and most of the primitives, >> retrofitting it was tricky. My lack of familiarity with go definitely contributed a >> lot to that, but I'd say that QCRAM is more difficult to implement than it >> seems in theory. >> >> I didn't implement QCRAM entirely as specified. There are a few things that >> I'll describe below that would make it either better or easier to implement >> (or both). >> >> >> # Separate Stream Roles >> >> There are actually three streams of data that are of interest, and there is no >> clarity about those streams. >> >> 1. I suggest that we use unidirectional streams in each direction for table >> updates. >> >> 2. A separate stream for acknowledgments ensures that the encoder can >> consume that separately to the decoder. >> >> 3. Request/response streams. I think that we all understand these. >> >> These can be separate from the hq control stream, and they should be. >> Rather than pick a specific stream number, we should add a header for these >> streams that will allow them to be identified clearly. If we do that, add strict >> rules about cardinality. >> >> # Define Framing More Clearly >> >> The definition of the framing that is used on the control stream is unclear. I >> assume that the intent is to use HEADERS frames, but I'm only really >> guessing. >> If you take my suggestion for separate framing, then you can use very >> different logic for the different streams. >> >> Honestly, the overhead of framing is excessive for anything but >> request/response streams. I found that framing on the control stream wasn't >> necessary at all. This might depend on implementation strategy, because it >> might be easier to collect a framed thing than it is to read until you are >> blocked, then pickle that state so that you can go back to something else. In >> my implementation I hold state on the stack, so it's pretty easy. >> >> Also, it should suffice to have just a stream of varints indicating >> acknowledgments. Duplicates can be used to acknowledge multiple header >> blocks on the same stream in order. >> >> # Split the Instruction Space >> >> Having to check that only certain instructions appear on different streams is >> annoying to implement and a waste of bits. Define two separate spaces. That >> should make things much simpler: there are exactly two instructions in each >> space then (leaving aside acknowledgments, which I will cover below). >> >> # Base in Every HEADERS Frame >> >> Base (the number of inserts in the table at the start of a header block) seems >> to be required for all HEADERS frames, including both table modification and >> request/response streams. But... >> >> # Base on the Table Update Stream >> >> You don't need base for table updates. It is more of a hazard than a help. It is >> easier if you treat indexing on the table update stream as in HPACK where >> each insert moves the reference point for the next insertion. >> >> # Remove BLOCKING >> >> The BLOCKING flag complicates the design unnecessarily. As a fixed >> overhead, pay the extra byte always. Furthermore, the table update stream >> will never need to use depends, so that further motivates having different >> instruction sets (and formats) for different streams. And you don't need it... >> >> # Base and the Static Table >> >> It is not explained at all that the base is applied to the dynamic table only. >> That is, index 1 is a straight index into the static table and that index 62 will >> use the current number of inserts and the base to determine the actual >> index into the dynamic table (this is the first table entry only when the >> number of table inserts and base are the same, if the base is smaller, then it >> will be further along the table). >> >> To be clear, my logic for finding entries is: >> >> if i == 0: error >> if i <= len(staticTable): return staticTable[i-1] >> delta = tableBase - base >> if delta < 0: error >> return dynamicTable[i - len(staticTable) - 1 + delta] >> >> # Remove Depends >> >> Depends is useless. I did not implement it. Base is sufficient. >> >> This follows from preferring to use the smallest value for base possible. >> Doing that also keeps table references as small as possible. (Because >> references are counted in the opposite direction to base, a larger base >> means larger >> references.) >> >> The cost is that you have to do a two pass check: the first to find the newest >> reference, the second to write out the header block. I find that it's basically >> necessary to do two passes anyway: on the first I write out the table >> updates, on the second I write the header block. During that phase you want >> to do lookups anyway, so you can save the largest base from that pass. Also, >> when you insert anything, that tends to set the base, so it's pretty easy >> overall. >> >> # Tracking ACKs is Harder Than It Seems >> >> There are multiple header blocks per stream, and ACKs only identify the >> stream. >> You can't just store a stream reference (or Request-ID) against each header >> block, you have to store a tuple of stream and header block index. This needs >> to be explained somewhere. >> >> I decided to externalize ACKs - the QCRAM encoder takes a generic blob as >> input when it encodes a header block and the same generic blob to >> acknowledge it. The caller then has to combine stream ID and header block >> index in a sensible fashion. >> >> # Acknowledge Dmitry >> >> So I don't forget... Dmitry did a lot of work on the design team. >> >> # Dynamic Table Overhead >> >> The draft has a TODO about overhead for each dynamic entry. I added a field >> to every entry that allows it to know its own position in the table, but that is a >> simplification/optimization, and you don't really need that. The other per- >> record overheads are all the same for the decoder, with a small increase to >> the fixed overhead. It's a little more state for an encoder, but that is mostly >> because of having to track usage. >> >> I don't think that we need to change from a 32 byte overhead. This decision >> could reduce code complexity in shared QCRAM/HPACK implementations (in >> my implementation it would). >> >> # Duplication Doesn't Need to Reference the Static Table >> >> Duplication only makes sense for dynamic entries and yet the index is (I >> assume), the normal table index. That is highly suboptimal. This is worse >> because the prefix is only 5 bits for this instruction (up to 62 values), which >> leads to the encoding taking an extra byte always. If you take my suggestion >> for separate instruction spaces, this is better, but still not as good as a direct >> index into the dynamic table, starting at 0. Better yet would be a reverse >> index, starting from the end of the table, because duplication often needs to >> refer to the end of the table. >> >> # Need Better Advice on Referencing strategy >> >> Referencing entries near the end of the table in a new header block is >> hazardous. If you just compress as you do in HPACK, you can end up pinning >> entries in the header table, making it impossible to add new entries. Thus, >> you have to stop referencing entries as they get nearer to the table capacity >> limit. >> >> In my implementation I added a threshold variable that governs my >> referencing strategy. A portion of the header table space is marked as being >> off-limits for header block usage. The encoder duplicates those entries if it >> wants to compress, but won't reference them. If the table is under pressure >> from the new header fields being added, then it should be able to advance >> by at least this amount every round trip. >> >> This is a simple strategy, and probably suboptimal in various ways, but it >> seems to work out. For instance, I continuously update the cutoff as entries >> are inserted, so that a header block might end up referencing things that get >> pushed into this space by later header fields. >> >> You can imagine more advanced techniques. For instance, you might tune >> this window automatically based on the rate that the header table grows. >> Because references in that window block eviction, it should be sized to the >> rate of >> *desired* growth in the header table over a round trip. Taking a running >> estimate of that desired growth and allowing a margin for variance could >> produce the right value. I haven't experimented with this. > From nobody Fri Feb 9 13:46:54 2018 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 81F5F1270FC for ; Fri, 9 Feb 2018 13:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 SUSAct2yug6j for ; Fri, 9 Feb 2018 13:46:50 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 838BE1242F7 for ; Fri, 9 Feb 2018 13:46:50 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id k6so26014ita.3 for ; Fri, 09 Feb 2018 13:46:50 -0800 (PST) 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=Z/qd/h/9NxVDMrFl7DeqmO3onmBoZFZ0V5Qc72Gbyjw=; b=qXgExNylIrKrAa/Xk4luGRNjl4/20hm1YUZ1hAH2I34Lq2Bsgg+ZoPWt6s4lhZ4kHK 3TN0VpsUTNr1Z8yoB7jUk5b2Qh6N/DPnGZ2ShmnhYcYgNNZapePb/7egZZxixawVzuY/ dkp3o9mlDm8GfsGfftcCz7+g9mHLyynK5eEiqRj/7+JS3KY2i/R9nhHeTVT1ikRuHMt2 xcSc1vJesofM7mWzLZfehJqAla5TCOHe9xnFaeIpxo4ZNN9onxUYi2NNczVnlyGLH2F8 B2ElUJcQf1eUNY+jgu+gDSx6WIupU/IGlRhtoaAd5caQvMR3mbV4XzUWb0OTjO7NJyBb 6kHw== 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=Z/qd/h/9NxVDMrFl7DeqmO3onmBoZFZ0V5Qc72Gbyjw=; b=ZZ3vILeJaj1aEKndBp2unU0Fe9sbsUH6pYFopwwdLQ782djCTMCJEvDZNTxdWHzXKM PfWD3FCevNolzwN9RY3qzLhKC9zTYnNiHycLkaHqCf2aIK6laUtSSqppKGKRH1TAlrYz RnFM4xRdEf5bCsXFjvVNlRX4DjW6fRRQGpoEpIBJ6aYdDizgEn2qNGWMdaUJNADhglvm 56zWNHtOzWLDR0osa2n/81k9QQ7nttszr7ws51br0e4YRxzzmzLitfYP+O0Z+tUw29Io 62yiEFLAOcl6HOtnPIjbOqgv4DzhoaAo3eIf2bHGYVlQ9mbufA0vZ2HljJ7FLV2U58Lh 6bog== X-Gm-Message-State: APf1xPC8DhgSYSuS8PTXvVVW+eVzUcqZiCf9GS6o8YcF2SCDvvES0RY3 V6Wj2hqiUsAZG+6Vs8JBaw852UYbJwcpNFNczNMZ2Q== X-Google-Smtp-Source: AH8x226E95fMZicLLDCwwBSm9bJ43T+bbNWQqZWvVZCBZ9Q6HedWmYqanM/52F1WzdntoOrAlMNF4uxnUpzbLGGYXxM= X-Received: by 10.36.188.135 with SMTP id n129mr5353242ite.81.1518212809553; Fri, 09 Feb 2018 13:46:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Fri, 9 Feb 2018 13:46:28 -0800 (PST) In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> From: Ian Swett Date: Fri, 9 Feb 2018 16:46:28 -0500 Message-ID: Subject: Re: hardware offload (was: Packet number encryption) To: Christian Huitema Cc: "Salz, Rich" , Praveen Balasubramanian , Eric Rescorla , "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11479635b1240564ce77f4" 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, 09 Feb 2018 21:46:52 -0000 --94eb2c11479635b1240564ce77f4 Content-Type: text/plain; charset="UTF-8" I should say that I don't have a specific API, implementation, or NIC in mind, so hopefully someone(Praveen?) can provide some context about what is possible with existing APIs or what is relatively easy to add to them. The API I had in mind was of the "encrypt this byte string" form, but in the NIC. ie: When I write a sequence of packets I supply crypto info, as well as a minimum release time(or pacing rate). The goal is to do the bulk crypto as the network stack is packetizing and copying into the NIC memory. Ideally this can avoid an extra memcpy and avoids touching the data to be sent until the last possible moment. Hardware acceleration of AES in modern CPUs is extremely good, so another approach is to do the above in a userspace networking stack or the kernel and use the CPU's AES acceleration. If the networking code that was writing into NIC memory had a deep understanding of QUIC, possibly it could do the packet number encryption as a second pass? On Fri, Feb 9, 2018 at 3:17 PM, Christian Huitema wrote: > On 2/9/2018 8:20 AM, Ian Swett wrote: > > > One issue with the current encryption proposal is you can't use > > hardware crypto offload for the bulk encryption because the packet > > number has to be encrypted after the bulk data. > > > > Any suggestions on how to fix that? > > Ian, could you be a bit more explicit about the type of hardware offload > that you have in mind? > > I can think of two extreme types. One is embedding crypto offload in the > NIC, and is generally tied to TCP/TLS/TLO. That one type has no hope > whatsoever of working with UDP/QUIC. The other type is simply providing > an "encrypt this byte string" API, and can be trivially used with QUIC > -- much like we can use Intel's AES extended instructions today. So > obviously you have something else in mind, and maybe you should explain it. > > -- Christian Huitema > > > > --94eb2c11479635b1240564ce77f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I should say that I don't have a specific API, im= plementation, or NIC in mind, so hopefully someone(Praveen?) can provide so= me context about what is possible with existing APIs or what is relatively = easy to add to them.

The API I had in mind was of the &= quot;encrypt this byte string" form, but in the NIC.=C2=A0 ie: When I = write a sequence of packets I supply crypto info, as well as a minimum rele= ase time(or pacing rate).=C2=A0 The goal is to do the bulk crypto as the ne= twork stack is packetizing and copying into the NIC memory.=C2=A0 Ideally t= his can avoid an extra memcpy and avoids touching the data to be sent until= the last possible moment.

Hardware acceleration of AES = in modern CPUs is extremely good, so another approach is to do the above in= a userspace networking stack or the kernel and use the CPU's AES accel= eration.=C2=A0 If the networking code that was writing into NIC memory had = a deep understanding of QUIC, possibly it could do the packet number encryp= tion as a second pass?

On Fri, Feb 9, 2018 at 3:17 PM, Christian Huitema <huit= ema@huitema.net> wrote:
On = 2/9/2018 8:20 AM, Ian Swett wrote:

> One issue with the current encryption proposal is you can't use > hardware crypto offload for the bulk encryption because the packet
> number has to be encrypted after the bulk data.
>
> Any suggestions on how to fix that?

Ian, could you be a bit more explicit about the type of hardware offload that you have in mind?

I can think of two extreme types. One is embedding crypto offload in the NIC, and is generally tied to TCP/TLS/TLO. That one type has no hope
whatsoever of working with UDP/QUIC. The other type is simply providing
an "encrypt this byte string" API, and can be trivially used with= QUIC
-- much like we can use Intel's AES extended instructions today. So
obviously you have something else in mind, and maybe you should explain it.=

-- Christian Huitema




--94eb2c11479635b1240564ce77f4-- From nobody Fri Feb 9 13:49:55 2018 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 D91DE1270FC for ; Fri, 9 Feb 2018 13:49:53 -0800 (PST) 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 g7FsfgNkPwnL for ; Fri, 9 Feb 2018 13:49:52 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 44FAE1242F7 for ; Fri, 9 Feb 2018 13:49:52 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id a2so9080363otf.2 for ; Fri, 09 Feb 2018 13:49:52 -0800 (PST) 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=/Yz/CzKKsRDpLtHk2BakwwfdnGVOnEk8CsDsxJIG+A8=; b=H7AipHnihK/CdXEOlXy/ZY8BybfQInT65JG8+GAWv7fayCxHDbb9Q7M2FglKQZjw9W oLOUpN/579IrGU2ihWqCf+R45WkbQhgvlNZcdQECFjER3fdsyTWmVJG95G2RINrfkcMU FUxw6TJVoNy9I7BKktlyZCvCd1B9VMPsW/M69f7QGd85+IK1Tfi7WvhW5FMujGtOahDj 0b5y3jOJRXs6R+Oz6oHdhD/YdICaBmaB9ZjbnYegxR8TeJ0oonNrI0TUxl8wmtXsMa1P ZM+BusQVDp7e3umTx6Jc2x8h3YoyqgP4lEUrXJICg1k8SM/P2JqWPTY1kcZowxxh32OW ov8A== 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=/Yz/CzKKsRDpLtHk2BakwwfdnGVOnEk8CsDsxJIG+A8=; b=hm2o0ea9V/itMfNjWXyjLvb6uZ/b0MhnMZVQIsDediV+cAr+72nz7tg64eVv2BXIkJ ePwfTwjTnRd1XsDFzgSTc5KkF39nMMcM/ewtQYDwjhVaBO4rOmc2RDyFLe+wCOq/yBFo KBXwS1M4ZtsXD2bDxfqnZIqZvF7hVkqAqp3V6Jb8eqEi97RCGPcjt7zMUOuV2jPn3JbW Ujpwwveyt2pHdZ1OP0ua0SHDjwfjeEOdgfXdhTLj8fKHgbK4+igz0PiC1nS1vp7uRgS+ jhc8tVVVJ0kAz7fJlpK4D2V/0T57byxhl/HHdi/hFERFpvzFNiU0FqxOpBjnJRYqw4ko L5gA== X-Gm-Message-State: APf1xPDTs5NioTK7aFsHfypzlaPP2W/FUf8wZ5Q3PnPUN5vGy9xlafn4 oZarUZu0866w0b2R8LMU0NhIaglXtI22b04pqtw= X-Google-Smtp-Source: AH8x226s8ZlZerPNnffbo8YwKrvt1avUQEbXCK7X+zh+WekYmmAnPKBmKWwp8MMTwfl/ySUYusjNN+BuB2MNfgEOa4E= X-Received: by 10.157.50.132 with SMTP id u4mr3485149otb.133.1518212991578; Fri, 09 Feb 2018 13:49:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Fri, 9 Feb 2018 13:49:51 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Sat, 10 Feb 2018 08:49:51 +1100 Message-ID: Subject: Re: Review of QCRAM To: "Charles 'Buck' Krasic" 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: Fri, 09 Feb 2018 21:49:54 -0000 On Sat, Feb 10, 2018 at 7:36 AM, Charles 'Buck' Krasic wrote: >> 2. A separate stream for acknowledgments ensures that the encoder can >> consume that separately to the decoder. > > I have a hard time seeing a practical difference, but sure. Consider that acknowledgments go to an encoder, and stream updates go to a decoder. These are entirely separate in my code, and I'd expect that to be common. Having to demux could be difficult - and it adds overhead. >> # Base and the Static Table >> >> It is not explained at all that the base is applied to the dynamic table >> only. > > afrind@ pointed this out Jan. 24 in a design committee thread (About > simplifying QCRAM further.) The editors copy had significant work to try > and clarify these points. Again sections 3.2 and 3.3. Also in response to > earlier feedback, Section 4.2, has a lot of new implementation guidance. I don't understand 3.3. I'm happy to send a PR that clarifies things. > It's a nit, but in my proxygen prototype, I didn't have to do two passes, > partly because FB's IOBuf abstraction has powerful abilities to prepend > prefixes to an existing buf, avoiding the need for two pass logic. Sure, if you can do that, you just update the base at the end. I found that to be unnecessary because it's easy to write out table changes in one pass, then all the references in a second pass. The only extra overhead is iteration (over small N, that's not a real cost). >> # Tracking ACKs is Harder Than It Seems > > See above, I think the new stuff in Section 4.2 covers this. I think that could be improved. I might have a PR for you later (or maybe after this becomes a WG item). From nobody Fri Feb 9 13:53:53 2018 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 027A4126C3D for ; Fri, 9 Feb 2018 13:53:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 FDBF5xNpUStg for ; Fri, 9 Feb 2018 13:53:46 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 6B83F1270A3 for ; Fri, 9 Feb 2018 13:53:46 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id p188so11207169ioe.12 for ; Fri, 09 Feb 2018 13:53:46 -0800 (PST) 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=lbOpC/SfG/eAD0W1OF+BgpkpieN3QDi8KgxuhbcA4yE=; b=lCnNs3F6xhl3CLMb5nrvzh1+fX+rnbzNHhijHyPzTbIHHJLZ8WTvMKGHcba90KOULU yi+J2n6EyW2sB+VpLJc9vTxUXvzHpl1VC58XaD5ZxFKAtT4ujwMb7zMwybzu3wagAmB3 av6cfZ0cAWtwq3wgSTExOe7oq8REPPOE1fKlvNINGpyKDCnUzHEd7pr+yVnlqZ3DoWDP e68b6iFQhTmzpTj/OIHpuoo7rf49bkyxarwbxfsdF49KkGYHV4d6oSunJMcrm/mppf1k WDivKI2W04KzxkgAnJNjkM58wMGex6rbVxHPoQcQLgQ3dSDdoVm58biMuI3qEHitY/j+ bLfQ== 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=lbOpC/SfG/eAD0W1OF+BgpkpieN3QDi8KgxuhbcA4yE=; b=FYN5oNU5A84m1/nlIaoaLiVJMZom3C9iQxHlCMEDWZIFrCOnBF9sc5eMi70FGsvGgV lgdQIUli+kF/1C6Rl1LUMcbAeMGI1LY7XO0mZTbvae3FhDzB7jAQbDovIT4mob1Diwje qbelnPcD0NKMIatiVyUhNDuTsBeXQqvGPslfRa9l8cLm0NEJUAHIArBSLu3q+XXesouH 1demQrek5jLw88kAtX8Sl/yWRJpWDmTiCQxnHVlwhROaMlh5zran9/7nAjyX2ziyVzkQ VVK25t0koeI8eaIKRO5wBwrLIHwOUI/2CT5LxeWP138mjECisNqkTF70549ckvQbjkY3 T/Yw== X-Gm-Message-State: APf1xPA1oPHthtbOPBgY3AVwpZ8c3IRvF/z1F5rcb/Smog7Po1jjfVxA tfLSzVXckZde0kLP7H1k8fGKYyfeMRTpTAsZXIucDg== X-Google-Smtp-Source: AH8x226+HRekTCuo7qyOeapydprabWZKHHmO+luXp7J3vShxMDh2DpaIRQT5G+RXRcwlBisgQcqAZVy7+WyU6ljKlfE= X-Received: by 10.107.19.213 with SMTP id 82mr4681894iot.276.1518213225471; Fri, 09 Feb 2018 13:53:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Fri, 9 Feb 2018 13:53:24 -0800 (PST) In-Reply-To: <1F436ED13A22A246A59CA374CBC543998B58BB1B@ORSMSX111.amr.corp.intel.com> References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B58BAD7@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B58BB1B@ORSMSX111.amr.corp.intel.com> From: Ian Swett Date: Fri, 9 Feb 2018 16:53:24 -0500 Message-ID: Subject: Re: Packet number encryption To: "Deval, Manasi" Cc: Praveen Balasubramanian , David Benjamin , Eric Rescorla , "quic@ietf.org" , huitema Content-Type: multipart/alternative; boundary="001a113f94f40019ea0564ce909a" 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, 09 Feb 2018 21:53:52 -0000 --001a113f94f40019ea0564ce909a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Good question. I'm still trying to understand how crypto offload might work for QUIC, but I tried to clarify what I was thinking on the side thread Christian started. But yes, the two step encryption was the concern, particularly the need to use the results of the bulk crypto when encrypting the packet number. On Fri, Feb 9, 2018 at 4:16 PM, Deval, Manasi wrote: > Hi All, > > > > The issue with TCP crypto offload does not directly apply to the QUIC > Crypto offload. For example, received TCP frames need to be coalesced > before decryption. This is a prohibitive operation to achieve in hardware > but much simpler to achieve in the software. The QUIC data encryption and > header update is therefore achievable. > > > > Encrypting the packet number complicates the crypto offload, though. Is > there another way to achieve the same security? In some early tests with > the existing QUIC stacks, I see that the crypto cost is quite significant > so high speed deployments may find use of crypto offload. > > > > Thanks, > > Manasi > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Deval, Manasi > *Sent:* Friday, February 09, 2018 12:55 PM > *To:* Praveen Balasubramanian ; David Benjamin < > davidben@chromium.org> > > *Cc:* Eric Rescorla ; quic@ietf.org; huitema < > huitema@huitema.net> > *Subject:* RE: Packet number encryption > > > > Going back to Ian=E2=80=99s point here =E2=80=93 Can you be explicit abou= t the issue you > see in the packet number encryption? > > > > Thanks, > > Manasi > > > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Praveen Balasubramanian > *Sent:* Friday, February 09, 2018 11:59 AM > *To:* David Benjamin > *Cc:* Eric Rescorla ; quic@ietf.org; huitema < > huitema@huitema.net> > *Subject:* RE: Packet number encryption > > > > With VLE its minimal overhead per packet so you are not encrypting 4 byte= s > more all the time even with 64 bit or 128 bit packet number . So its > decidedly better. Also fewer calls into TLS, but I suppose one could do > some refactoring of TLS API. Many CPUs yes but this is a general purpose > transport and could run on CPUs that don=E2=80=99t. > > > > Didn=E2=80=99t ask for nonce to be variable length. Fixed length for conn= ection > lifetime. Datacenters connections could use 64-bit nonce to avoid frequen= t > key rollover. > > > > Effectively the plain text nonce is a sequence number since it increases > monotonically with small jumps as needed to avoid ossification. So no wor= se > off than gQUIC or current draft. No more complex than using the packet > number. Just the starting number is randomized. Also please notice that > this proposal does not preclude using encrypted packet number as the nonc= e > as proposed previously. Changing how the nonce works makes 0 impact on th= e > transport logic. An implementation can choose to implement any form of > non-repeating nonce without revving the RFC. This is the biggest advantag= e > of separation of concerns IMHO. > > > > *From:* David Benjamin [mailto:davidben@chromium.org > ] > *Sent:* Friday, February 9, 2018 11:39 AM > *To:* Praveen Balasubramanian > *Cc:* Eric Rescorla ; quic@ietf.org; huitema < > huitema@huitema.net> > *Subject:* Re: Packet number encryption > > > > Your primary worry here was the extra block cipher operation, right? By > moving the packet number into the plaintext, this proposal increases the > length, which will cost that same one extra block cipher operation, no? > > > > It is one block operation under the same key, rather than a different key > so I suppose there are minuscule cache footprint wins (one symmetric key = is > 16 or 32 bytes). But the cost is per-packet (!) bandwidth and complexity.= I > do not see how this could be worth it. Note that, for AES, many CPUs have > dedicated instructions for it already. > > > > > Clear separation of concerns results if we don=E2=80=99t overload the p= acket > number as the nonce. Connection migration and multi-path are optional > features and we pay no extra compute cost for most connections that are n= ot > impacted by unlnkability. Nonce field becomes optional for crypto that > doesn=E2=80=99t need it and can grow to larger size as needed for bulk tr= ansfers to > prevent frequent key rollovers (say in datacenter scenarios). > > > > You're not going to find AEADs that don't require a nonce. Encryption mus= t > not produce the same ciphertext twice for the same plaintext, so you need > some input to diversify them. That input is the nonce. Nonces also are no= t > variable-length, so you don't get to arbitrarily grow them. (AES-GCM per > spec is variable length, but that's a spec bug. If you size it above 96 > bits, it's as if you randomized it and your nonce space crashes per > birthday.) > > > > It is also harmful to separate the two concerns. When you are building a > transport, derive the nonce from a sequence number. TLS 1.2 AES-GCM > separated them, which was a mistake. It's less efficient (the world waste= d > quite a lot of bandwidth due to this), and more error-prone. There was > nothing stopping implementations from sending the same nonce or generatin= g > nonces randomly (the AEADs we use don't have large enough nonces for that= ), > and indeed some did just that. If you use some sort of sequence number, y= ou > can lean on existing work both to filter out the obvious implementation > mistakes and to avoid sending unnecessary data. > > > > On Fri, Feb 9, 2018 at 12:38 PM Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > Let me try to summarize the proposal again: > > > > 1. Packet number is in the encrypted portion of the header and is no > longer used as the nonce. It is encoded as a variable length number. A= lways > starts at 0. > > > 1. No ossification of PN > 2. No linkability using PN > 3. Allows for growth beyond 64 bits if needed in future > > > 1. The nonce is in the clear in plaintext header. It is generated *per > path* as a secure random number. Call this the =E2=80=9Cstarting value= =E2=80=9D. Both > sides MUST initialize the =E2=80=9Cstarting value=E2=80=9D nonce *per = path*. Within a > path it grows monotonically (to avoid repeats just like PN today) and = can > include short random jumps periodically so that middleboxes cannot ass= ume > anything about the field. Since nonce has nothing to do with PN the ju= mps > don=E2=80=99t add any complexity to transport logic. Jumps are for gre= asing and > preventing ossification. When the nonce rolls over and reaches close t= o the > =E2=80=9Cstarting value=E2=80=9D, key rollover must happen. At high da= ta rates the nonce > field can be 64-bits to prevent frequent key rollover. For crypto that > doesn=E2=80=99t need nonces, the field can be omitted. > > > 1. No ossification because there is no pre-determined sequence to the > nonce. > 2. In gQUIC and the RFC as defined the nonce is a simple sequence > that increments by one, so this is no worse off in terms of securit= y. It is > non-repeating. > 3. No linkability because different paths start at a completely > different random number. If repeating is a concern then different p= aths use > different keys. Carries forward to not just connection migration bu= t > mutli-path. > 4. Supports key rollover just like gQUIC and currently defined > draft RFC. > 5. Allows for omitting the nonce when we use crypto that doesn=E2= =80=99t > need it. > 6. Allows for larger nonces for high data rates. > 7. It doesn=E2=80=99t preclude any other type of non-repeating nonc= es > without having to modify the RFC! So implementations that want to u= se > cryptographic nonces can still do so. > > > > The downsides: > > 1. Even with variable length encoding the extra PN field is more space > used per packet when a nonce is required. I think we can do with 2 byt= es in > version 1. > 2. It=E2=80=99s not perfect unlinkabiltiy but I have yet to see any so= lution > that can provide this. A simple time based analysis using machine lear= ning > will allow flow correlation especially for connection migration. The I= P > addresses in the clear allow for a high degree of correlation. There i= s > also the application sending pattern and other signals that could be u= sed. > > > > *From:* Eric Rescorla [mailto:ekr@rtfm.com] > *Sent:* Friday, February 9, 2018 5:52 AM > *To:* Praveen Balasubramanian > *Cc:* huitema ; quic@ietf.org > > > *Subject:* Re: Packet number encryption > > > > > > > > On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > > Actually taking a step back what if we don=E2=80=99t we overloaded packet= number > as the nonce? > > > > Can we: > > 1. Put packet number as a separate variable length field in the > encrypted portion of the header. This allows for growth beyond 64 bits= in > future and completely avoids ossification. For short lived flows varia= ble > length encoding leads to minimal space overhead. > 2. Put a separate plaintext nonce which starts out as a secure random > number and monotonically increases as short random jumps (every packet= or > every few packets) and could then rollover. This will prevent linkabil= ity > and scales to multi-path as well. No major compute overhead. We can al= so > make the nonce optional for crypto algorithms that do not need a nonce > saving more space. > > > > I'm not sure how to do #2 safely and efficiently. The primary concern is > that short random jumps don't actually prevent linkability because the hi= gh > order bits don't change and long random jumps are effectively randomly > sampling out of the nonce space, and you start to run into birthday > problems. Additionally, the cheapest PRNGs are basically ciphers in count= er > mode, so at best you're going to get a small amount of overhead reduction > by getting multiple jump computations out of a single block, though if yo= u > use 96-bit jumps, you only get 25% savings... > > > > -Ekr > > > > > > > > Some MSB of the nonce could be used for signaling reorder to the network > if needed. I don=E2=80=99t have the historical context for overloading of= PN as the > nonce so pardon me if un-overloading option was discussed and ruled out > before. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Praveen > Balasubramanian > *Sent:* Thursday, February 8, 2018 5:51 PM > *To:* huitema ; quic@ietf.org > *Subject:* RE: Packet number encryption > > > > >> and using separate packet sequences for each path > > This alone prevents linkability right? > > > > >> The packet number on each path will start at 1 (or maybe 0 ;-). > > Is supporting multiple paths at the same time a goal? If yes, then yes al= l > paths will need to have separate tracking and ACK state and congestion > control etc. I thought this is not part of V1 RFC. If its just one > additional path for connection migration scenario then all you need is a > (random) jump to a offset in packet number space for the new path so that > the few packets in the old path can continue for a little bit. This works > with just one ACK space so no implementation complexity. > > > > >> 2) Or, leaving the packet number in the clear but using different > encryption contexts for each path, and using separate packet sequences fo= r > each path. > In addition if the value in the clear was obfuscated with an XOR transfor= m > it will help prevent ossification. The obfuscation is not meant to guard > against later analysis that reveals the packet numbers - why do we care > about that. It is meant to grease the space and not make the numbers seri= al > so middleboxes cannot assume ordering etc. > > > > All said if I am alone in being concerned about the perf hit then I=E2=80= =99d say > go on with option 1. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Christian Huitema > *Sent:* Thursday, February 8, 2018 3:54 PM > *To:* quic@ietf.org > *Subject:* Re: Packet number encryption > > > > On 2/8/2018 1:13 PM, Mike Bishop wrote: > > #2 won=E2=80=99t work. The packet number is an input to the AEAD nonce, = so you > have to get to the packet number before you can decrypt the payload. It > can=E2=80=99t be based on anything internal to the encrypted packet. > > > > In Martin=E2=80=99s proposal, it=E2=80=99s using a combination of the enc= rypted payload > (which requires nothing to access) and some stored state on each endpoint= , > which requires only the Connection ID to look up. You want the thing you > XOR by to be constantly changing, or it becomes easier to look at sequenc= es > of obfuscated packet numbers and start drawing inferences about what the > XOR value is. If overhead is the primary concern, I think there are a > couple approaches that might allow you to precompute values and amortize > the cost of doing the encryption step. (At the cost of keeping the table > of precomputed values, of course.) > > > > I still think Jana=E2=80=99s pushing in the right direction here: Let=E2= =80=99s agree on > goals, and then see if we can craft a design that meets those goals. I > hear you saying that low overhead is a goal, which I think we can all agr= ee > on. I also think I hear you saying that 1-1.5% overhead is too high, but > it sounds like there=E2=80=99s less agreement on that. You also raise an > interesting point that some clients will care less about linkability > because they will never intentionally migrate. > > > I think Victor said it best, "Obfuscation is just encryption done poorly.= " > Either we encrypt, or we don't. But there is no such thing as an > obfuscation middle-ground. Obfuscation would just be a speed bump, easily > broken. It won't provide privacy, and it won't prevent linkability. > > As far as I am concerned, there are only two designs that prevent > linkability: > > 1) Martin's PR, in which the packet number is encrypted using sensible > crypto; > > 2) Or, leaving the packet number in the clear but using different > encryption contexts for each path, and using separate packet sequences fo= r > each path. > > The second option requires more computation when explicitly setting up a > new path. The connection ID would be used as part of the "salt" when > deriving connection contexts. The packet number on each path will start a= t > 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for > each path/Connection-ID, and constraining ACK to be per/path, or > alternatively adding a PATH-ACK frame that indicates the path for which > packets are acked. > > The pros and cons of the two options are easy to get: > > 1) Option 2 does not require the cost of encrypting every packet, thus pe= r > packet processing will be maybe 1% faster than option 1. > > 2) Option 2 requires computing encryption contexts for each path, which i= s > more complex than option 1, but the cost will be amortized over the > duration of the path. > > 3) Option 2 requires more complex data structures and ACK management, thu= s > increasing the chances that something goes wrong. > > 4) Option 2 does nothing against packet number ossification. The packet > number effectively becomes part of the invariants. > > In short, the only advantage of option 2 is to avoid a single symmetric > encryption operation per packet, while making the code significantly more > complex, and at the cost of not protecting against PN ossification. The w= ay > I see that, there is hardly any debate. > > -- Christian Huitema > > > > --001a113f94f40019ea0564ce909a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good question.=C2=A0 I'm still trying to understand ho= w crypto offload might work for QUIC, but I tried to clarify what I was thi= nking on the side thread Christian started.=C2=A0 But yes, the two step enc= ryption was the concern, particularly the need to use the results of the bu= lk crypto when encrypting the packet number.

On Fri, Feb 9, 2018 at 4:16 PM, Deval, Man= asi <manasi.deval@intel.com> wrote:

Hi All,

=C2=A0

The issue with TCP crypto o= ffload does not directly apply to the QUIC Crypto offload. For example, rec= eived TCP frames need to be coalesced before decryption. This is a prohibit= ive operation to achieve in hardware but much simpler to achieve in the software. The QUIC data encryption and header update is the= refore achievable.

=C2=A0

Encrypting the packet numbe= r complicates the crypto offload, though. Is there another way to achieve t= he same security? In some early tests with the existing QUIC stacks, I see = that the crypto cost is quite significant so high speed deployments may find use of crypto offload.

=C2=A0

Thanks,

Manasi

=C2=A0

<= span style=3D"color:#1f497d">=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Deval, Manasi
Sent: Friday, February 09, 2018 12:55 PM
To: Praveen Balasubramanian <pravb@microsoft.com>; David Benjamin <davidben@chromium.org<= /a>>


Cc: Eric Rescorla <ekr@rtfm.com>; quic@ietf.org; huitema <huitema@huitema.net>
Subject: RE: Packet number encryption

=C2=A0

Going back to Ian=E2= =80=99s point here =E2=80=93 Can you be explicit about the issue you see in= the packet number encryption?

=C2=A0

Thanks,<= /span>

Manasi

=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Friday, February 09, 2018 11:59 AM
To: David Benjamin <davidben@chromium.org>
Cc: Eric Rescorla <ekr@rtfm.com>; quic@ietf.org; huitema <huitema@huitema.net>
Subject: RE: Packet number encryption

=C2=A0

With VLE its minimal overhead per packet so you are = not encrypting 4 bytes more all the time even with 64 bit or 128 bit packet= number . So its decidedly better. Also fewer calls into TLS, but I suppose= one could do some refactoring of TLS API. Many CPUs yes but this is a general purpose transport and could r= un on CPUs that don=E2=80=99t.

=C2=A0

Didn=E2=80=99t ask for nonce to be variable length. = Fixed length for connection lifetime. Datacenters connections could use 64-= bit nonce to avoid frequent key rollover.

=C2=A0

Effectively the plain text nonce is a sequence numbe= r since it increases monotonically with small jumps as needed to avoid ossi= fication. So no worse off than gQUIC or current draft. No more complex than= using the packet number. Just the starting number is randomized. Also please notice that this proposal does = not preclude using encrypted packet number as the nonce as proposed previou= sly. Changing how the nonce works makes 0 impact on the transport logic. An= implementation can choose to implement any form of non-repeating nonce without revving the RFC. This is the bigge= st advantage of separation of concerns IMHO.

=C2=A0

From: David Benjamin [mailto:davidben@chromium.org]
Sent: Friday, February 9, 2018 11:39 AM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: Eric Rescorla <ekr@rtfm.com>; quic@ietf.org; huitema <huitema@huitema.net>
Subject: Re: Packet number encryption

=C2=A0

Your primary worry here was the extra block cipher o= peration, right? By moving the packet number into the plaintext, this propo= sal increases the length, which will cost that same one extra block cipher = operation, no?

=C2=A0

It is one block operation under the same key, rather= than a different key so I suppose there are minuscule=C2=A0cache footprint= wins (one symmetric key is 16 or 32 bytes). But the cost is per-packet (!)= bandwidth and complexity. I do not see how this could be worth it.=C2=A0Note that, for AES, many CPUs have dedica= ted instructions for it already.

=C2=A0

>=C2=A0Clear separation of concerns results if we= don=E2=80=99t overload the packet number as the nonce. Connection migratio= n and multi-path are optional features and we pay no extra compute cost for= most connections that are not impacted by unlnkability. Nonce field becomes optional for crypto that doesn=E2=80=99t need it and c= an grow to larger size as needed for bulk transfers to prevent frequent key= rollovers (say in datacenter scenarios).

=C2=A0

You're not going to find AEADs that don't re= quire a nonce. Encryption must not produce the same ciphertext twice for th= e same plaintext, so you need some input to diversify them. That input is t= he nonce. Nonces also are not variable-length, so you don't get to arbitrarily grow them. (AES-GCM per spec is variab= le length, but that's a spec bug. If you size it above 96 bits, it'= s as if you randomized it and your nonce space crashes per birthday.)

=C2=A0

It is also harmful to separate the two concerns.=C2= =A0When you are building a transport, derive the nonce from a sequence numb= er. TLS 1.2 AES-GCM separated them, which was a mistake. It's less effi= cient (the world wasted quite a lot of bandwidth due to this), and more error-prone. There was nothing stopping implementat= ions from sending the same nonce or generating nonces randomly (the AEADs w= e use don't have large enough nonces for that), and indeed some did jus= t that. If you use some sort of sequence number, you can lean on existing work both to filter out the obvious imple= mentation mistakes and to avoid sending unnecessary data.

=C2=A0

On Fri, Feb 9, 2018 at 12:38 PM Praveen Balasubraman= ian <pravb@micr= osoft.com> wrote:

Let me try to summarize the proposal again:

=C2=A0

  1. Packet number is in the encrypted portion of the header and is no longer us= ed as the nonce. It is encoded as a variable length number. Always starts a= t 0.
    1. No ossification of PN
    2. No linkability using PN
    3. Allows for growth beyond 64 bits if needed in future
    1. The nonce is in the clear in plaintext header. It is generated per path<= /i> as a secure random number. Call this the =E2=80=9Cstarting value=E2=80= =9D. Both sides MUST initialize the =E2=80=9Cstarting value=E2=80=9D nonce per path. Within a path it grows monotonically (to avoid repeats jus= t like PN today) and can include short random jumps periodically so that mi= ddleboxes cannot assume anything about the field. Since nonce has nothing t= o do with PN the jumps don=E2=80=99t add any complexity to transport logic. Jumps are for greasing and preventing o= ssification. When the nonce rolls over and reaches close to the =E2=80=9Cst= arting value=E2=80=9D, key rollover must happen. At high data rates the non= ce field can be 64-bits to prevent frequent key rollover. For crypto that doesn=E2=80=99t need nonces, the field can be om= itted.
      1. No ossification because there is no pre-determined sequence to the nonce.
      2. In gQUIC and the RFC as defined the nonce is a simple sequence that increme= nts by one, so this is no worse off in terms of security. It is non-repeati= ng.
      3. No linkability because different paths start at a completely different rand= om number. If repeating is a concern then different paths use different key= s. Carries forward to not just connection migration but mutli-path.
      4. Supports key rollover just like gQUIC and currently defined draft RFC.
      5. Allows for omitting the nonce when we use crypto that doesn=E2=80=99t need = it.
      6. Allows for larger nonces for high data rates.
      7. It doesn=E2=80=99t preclude any other type of non-repeating nonces without = having to modify the RFC! So implementations that want to use cryptographic= nonces can still do so.

    =C2=A0

    The downsides:

    1. Even with variable length encoding the extra PN field is more space used pe= r packet when a nonce is required. I think we can do with 2 bytes in versio= n 1.
    2. It=E2=80=99s not perfect unlinkabiltiy but I have yet to see any solution t= hat can provide this. A simple time based analysis using machine learning w= ill allow flow correlation especially for connection migration. The IP addr= esses in the clear allow for a high degree of correlation. There is also the application sending pattern and other si= gnals that could be used.

    =C2=A0

    From: Eric Rescorla [mailto:ekr@rtfm.com]
    Sent: Friday, February 9, 2018 5:52 AM
    To: Praveen Balasubramanian <pravb@microsoft.com>
    Cc: huitema <huitema@huitema.net>; quic@ietf.org=


Subject: Re: Packet number encryption

=C2=A0

=C2=A0

=C2=A0

On Thu, Feb 8, 2018 at 9:40 PM, Praveen Balasubraman= ian <pravb@micr= osoft.com> wrote:

Actually taking a step back what if we don=E2=80=99t= we overloaded packet number as the nonce?

=C2=A0

Can we:

  1. Put packet number as a separate variable length field in the encrypted port= ion of the header. This allows for growth beyond 64 bits in future and comp= letely avoids ossification. For short lived flows variable length encoding = leads to minimal space overhead.
  2. Put a separate plaintext nonce which starts out as a secure random number a= nd monotonically increases as short random jumps (every packet or every few= packets) and could then rollover. This will prevent linkability and scales= to multi-path as well. No major compute overhead. We can also make the nonce optional for crypto algorithm= s that do not need a nonce saving more space.

=C2=A0

I'm not sure how to do #2 safely and efficiently= . The primary concern is that short random jumps don't actually prevent= linkability because the high order bits don't change and long random jumps are effectively randomly sampling out of the nonce space= , and you start to run into birthday problems. Additionally, the cheapest P= RNGs are basically ciphers in counter mode, so at best you're going to = get a small amount of overhead reduction by getting multiple jump computations out of a single block, though if you= use 96-bit jumps, you only get 25% savings...

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

Some MSB of the nonce could be used for signaling re= order to the network if needed. I don=E2=80=99t have the historical context= for overloading of PN as the nonce so pardon me if un-overloading option was discussed and ruled out before.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Praveen Balasubramanian
Sent: Thursday, February 8, 2018 5:51 PM
To: huitema <huitema@huitema.net>; quic@ietf.org
Subject: RE: Packet number encryption

=C2=A0

>> and using separate packet sequences for eac= h path

This alone prevents linkability right?=

=C2=A0

>> The packet number on each path will start a= t 1 (or maybe 0 ;-).

Is supporting multiple paths at the same time a goal= ? If yes, then yes all paths will need to have separate tracking and ACK st= ate and congestion control etc. I thought this is not part of V1 RFC. If its just one additional path for connection migrati= on scenario then all you need is a (random) jump to a offset in packet numb= er space for the new path so that the few packets in the old path can conti= nue for a little bit. This works with just one ACK space so no implementation complexity.

=C2=A0

>> 2) Or, leaving the packet number in the cle= ar but using different encryption contexts for each path, and using separat= e packet sequences for each path.
In addition if the value in the clear was obfuscated with an XOR transform = it will help prevent ossification. The obfuscation is not meant to guard ag= ainst later analysis that reveals the packet numbers - why do we care about= that. It is meant to grease the space and not make the numbers serial so middleboxes cannot assume orderin= g etc.

=C2=A0

All said if I am alone in being concerned about the = perf hit then I=E2=80=99d say go on with option 1.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Christian Huitema
Sent: Thursday, February 8, 2018 3:54 PM
To: quic@ietf.org=
Subject: Re: Packet number encryption

=C2=A0

On 2/8/2018 1:13 PM, Mike Bishop wrote:

#2 won=E2=80=99t work.=C2=A0 The packet number is an= input to the AEAD nonce, so you have to get to the packet number before yo= u can decrypt the payload.=C2=A0 It can=E2=80=99t be based on anything inte= rnal to the encrypted packet.

=C2=A0

In Martin=E2=80=99s proposal, it=E2=80=99s using a c= ombination of the encrypted payload (which requires nothing to access) and = some stored state on each endpoint, which requires only the Connection ID to look up.=C2=A0 You want the thing you XOR by to be constantly changi= ng, or it becomes easier to look at sequences of obfuscated packet numbers = and start drawing inferences about what the XOR value is.=C2=A0 If overhead= is the primary concern, I think there are a couple approaches that might allow you to precompute values and amortize= the cost of doing the encryption step.=C2=A0 (At the cost of keeping the t= able of precomputed values, of course.)

=C2=A0

I still think Jana=E2=80=99s pushing in the right di= rection here:=C2=A0 Let=E2=80=99s agree on goals, and then see if we can cr= aft a design that meets those goals.=C2=A0 I hear you saying that low overh= ead is a goal, which I think we can all agree on.=C2=A0 I also think I hear yo= u saying that 1-1.5% overhead is too high, but it sounds like there=E2=80= =99s less agreement on that.=C2=A0 You also raise an interesting point that= some clients will care less about linkability because they will never intentionally migrate.


I think Victor said it best, "Obfuscation is just encryption done poor= ly." Either we encrypt, or we don't. But there is no such thing as= an obfuscation middle-ground. Obfuscation would just be a speed bump, easi= ly broken. It won't provide privacy, and it won't prevent linkability.

As far as I am concerned, there are only two designs that prevent linkabili= ty:

1) Martin's PR, in which the packet number is encrypted using sensible = crypto;

2) Or, leaving the packet number in the clear but using different encryptio= n contexts for each path, and using separate packet sequences for each path= .

The second option requires more computation when explicitly setting up a ne= w path. The connection ID would be used as part of the "salt" whe= n deriving connection contexts. The packet number on each path will start a= t 1 (or maybe 0 ;-). This requires maintaining separate SACK dashboards for each path/Connection-ID, and constraining ACK= to be per/path, or alternatively adding a PATH-ACK frame that indicates th= e path for which packets are acked.

The pros and cons of the two options are easy to get:

1) Option 2 does not require the cost of encrypting every packet, thus per = packet processing will be maybe 1% faster than option 1.

2) Option 2 requires computing encryption contexts for each path, which is = more complex than option 1, but the cost will be amortized over the duratio= n of the path.

3) Option 2 requires more complex data structures and ACK management, thus = increasing the chances that something goes wrong.

4) Option 2 does nothing against packet number ossification. The packet num= ber effectively becomes part of the invariants.

In short, the only advantage of option 2 is to avoid a single symmetric enc= ryption operation per packet, while making the code significantly more comp= lex, and at the cost of not protecting against PN ossification. The way I s= ee that, there is hardly any debate.

-- Christian Huitema

=C2=A0


--001a113f94f40019ea0564ce909a-- From nobody Fri Feb 9 13:54:19 2018 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 4D58E12D7EF for ; Fri, 9 Feb 2018 13:54:17 -0800 (PST) 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 Tjia0JDZfA4j for ; Fri, 9 Feb 2018 13:54:15 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 66C95127369 for ; Fri, 9 Feb 2018 13:54:15 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id q9so9102049oti.0 for ; Fri, 09 Feb 2018 13:54:15 -0800 (PST) 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=2OvhZ+SCB56HMb1MU3hseMGZAztUPPMIQnaUryU6u2I=; b=j5BJq5rs5x9CtjXzOBpoLCg2AqDf8kqgUJGiCbv+rUwkRKEp2C0ENoz5CTH0JFiH/m C0kAzZurNYrzBQUiW1r9y3G2XVt2AcA6f3QOdjKuie3jgLfRxsICknOARJpB4AyK5ZHm NXHaLvNicczlo2AzAs8j+6H/PP2KnFWtLdIUcT/6SYx7CuIthgw47bs/JlNuI9l30dYc CktSY3yAwTIS9WRBvvfGC0QtoEGmQ+iKgMTvT4apnB34SZMftIqoyO8CxWlMHutsDKKk ro4ZIhDcL8K0v1/5UkIWl+OrtCz5ixQaaFBoiZYjvj4ghcxKnMloFopt1wDG4vZ87HWx f45g== 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=2OvhZ+SCB56HMb1MU3hseMGZAztUPPMIQnaUryU6u2I=; b=hEbJcLs7WpMa8Ew8RVfGn2CJLMKIgWmje+QmTrWYtV4VMhOhoAcZpedDAKV7+hp+JA fePJndmZGvYiqaVty9tmOcOPnLBC8WbL+iXl2DHlmr3XDo24BKlYwvHIfGpdtaanGZg5 58CrVo2zuKKY0VRmbZ5QnILwSuNQkBgl0fZ5Cn2EN9eBiORaWVRU4qSG8XtSLV+elmUJ VSqZaRPq5OKe9I4d7ua8TxYiO9fIh89FWkr+EchiNhGupoNHeZlOz7sKlaR2zo+Exjr+ S44xL9stJR9+8DAk6BrG2s+Lx8RYlvP4Mz9eKcDoC5SQFhYCg2vFwXFDpskkCyu+Vfoh 3YxQ== X-Gm-Message-State: APf1xPBBLlR/bCmwva159fE2qE78uxHe/wDxsaY3eCGBHCDyeQPYTjiQ rzD/60QkOfag594tKaieRX+8tFC29MFRQTs0ABM= X-Google-Smtp-Source: AH8x227N6fpYMT+vRhyYsms7A/QhjnRGIKvPEogWzF1wLtZ4v82toJowlFbmlI2bvMO66SPZ/LWhAYd2HNC6G5rVtfA= X-Received: by 10.157.50.132 with SMTP id u4mr3493056otb.133.1518213254735; Fri, 09 Feb 2018 13:54:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Fri, 9 Feb 2018 13:54:14 -0800 (PST) In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> From: Martin Thomson Date: Sat, 10 Feb 2018 08:54:14 +1100 Message-ID: Subject: Re: Packet number encryption To: Ian Swett Cc: "Salz, Rich" , Praveen Balasubramanian , Eric Rescorla , "quic@ietf.org" , huitema 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, 09 Feb 2018 21:54:17 -0000 On Sat, Feb 10, 2018 at 5:20 AM, Ian Swett wrote: > One issue with the current encryption proposal is you can't use hardware > crypto offload for the bulk encryption because the packet number has to be > encrypted after the bulk data. Why? Are you expecting the hardware to take the packet and run away with it? (I know that happens, but is that really a requirement?) From nobody Fri Feb 9 13:58:42 2018 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 0DC141270A3 for ; Fri, 9 Feb 2018 13:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 1hU-0m13jG1v for ; Fri, 9 Feb 2018 13:58:39 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 74E521242F7 for ; Fri, 9 Feb 2018 13:58:39 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id t22so11241643ioa.7 for ; Fri, 09 Feb 2018 13:58:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=tkypiPn2TzLcgskOrfsLIhkQ+PSD1g4jwVjZao4JU5c=; b=ujuQcYHz9UdId8301jv/spV99CPtQg8mRRHIUg6W4tbde6th7g+CaOgi/I3AYzwD7N L7oCM/zj6shNWzb2eME3mtnLIAEbzqFTUPnf0h2gc49QcC8joLqwY/zcGp9pmLw2fk4w cYD247YTH18juuuPGMusQvNHlO9Kvn0IXsc3nmaKKmQcYBjfu1Gk8WpmL+h8k3GwWFKF Bsr2OVu4851i/lNzmqk62sGF95zclT+vVgj5S+J/+qkwdu9eW8BxMgAgoMWI6JnOCUF5 iQEwq9EnfviwrpTYxfBYhagueiniZXMStPV4txgiyoIJ1nVQBvLo9VHZy23Jboay5fgc qSjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=tkypiPn2TzLcgskOrfsLIhkQ+PSD1g4jwVjZao4JU5c=; b=p8ncDLpKFfuEh1S/OnfT0FHy6Hv6xIin7gmnZmxvaDeyPfR+LTXcBMWY13ykrKGBMF nyPDrZBShtPkbEylEBl6EfTvLYUJY2efps2k8ug3Q2Yg+rtvR1eRh5zvfMy3NmcmcuQv 0v9/nkBRX6DG/5s9dzk7N/k8NLwIYWTUQFnquBAIIlLhAcN1gl1NAy3+jg2utjm+/lpa CnaI5rKOA8/XpsTSpZI4vnPNSv7m4TT6WfFUODN87og9AfVo69B2YizVHPAr1XSghPzU 2CV5z/AmyVs01vkDA0t7KN7KXpH670Dp94yOmaqKeprvTxg9JAKSg1I6VcK7P86GBcI4 /a6w== X-Gm-Message-State: APf1xPCMoZNZIyqqt439Q4O2wLO1gW0SyEAFiUP2KSLKWULTQGsk3e/d XtpLfDsvSHEO5MtNcYRy6Cz+Xmt/LNozJaZvABc= X-Google-Smtp-Source: AH8x227uTIUf5MSnbu4YDLuHgo4AClNfIGT+pY73gRB4oLrOKQN5rSSe1HKwOhX9XKhyWP4QKhrtwfgKf2BeLaGVIZc= X-Received: by 10.107.146.137 with SMTP id u131mr324532iod.96.1518213518935; Fri, 09 Feb 2018 13:58:38 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 13:58:38 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B58BAD7@ORSMSX111.amr.corp.intel.com> <1F436ED13A22A246A59CA374CBC543998B58BB1B@ORSMSX111.amr.corp.intel.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 13:58:38 -0800 Message-ID: Subject: Re: Packet number encryption To: Ian Swett , "Deval, Manasi" Cc: Praveen Balasubramanian , Eric Rescorla , "quic@ietf.org" , David Benjamin , huitema Content-Type: multipart/alternative; boundary="94eb2c05667a7d4b720564cea185" 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, 09 Feb 2018 21:58:41 -0000 --94eb2c05667a7d4b720564cea185 Content-Type: text/plain; charset="UTF-8" I'm still trying to understand how crypto offload might work for QUIC, You could start looking at the netmap API. It exposes a vector of fixed size buffers than can originate directly from the NIC buffer memory. The same API can also be used to offload work by other CPU cores because you essentially commit a buffer and leave it for the next stage in a pipeline. https://www.freebsd.org/cgi/man.cgi?query=netmap&sektion=4 --94eb2c05667a7d4b720564cea185 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
=C2=A0I'm still trying to understand how crypto offload might work for QUIC,=

You could start looking at the ne= tmap API. It exposes a vector of fixed size buffers than can originate dire= ctly from the NIC buffer memory. The same API can also be used to offload w= ork by other CPU cores because you essentially commit a buffer and leave it= for the next stage in a pipeline.

https://www.freebsd.org/cgi/ma= n.cgi?query=3Dnetmap&sektion=3D4

--94eb2c05667a7d4b720564cea185-- From nobody Fri Feb 9 14:03:38 2018 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 EE58E127241 for ; Fri, 9 Feb 2018 14:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 SqmG0tziERkf for ; Fri, 9 Feb 2018 14:03:35 -0800 (PST) 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 6945B1270FC for ; Fri, 9 Feb 2018 14:03:35 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id h27so2383827ywk.10 for ; Fri, 09 Feb 2018 14:03:35 -0800 (PST) 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=U//K7bTDL8KaYInmcROqTh/daXvijLOqEMx2V59sNjU=; b=SsJnPCkzQQHs+KMmVRqIa2OjOCOd3CXBvNRxLDNdDJfKYtuEmGurFvKJ1PdF1mY1Yt UnfR+ai6Wq12SLxsUjRgy2/g6z61JjIoDVd/StUih8MRrBuCzCQDYkiyE+cy8CnS3FR+ g7tRAICOFI2btQH2/3EHeNZRqA2/PNsOC9/avYqpvmVaMDkl1O1EMBF20lNbU4Z1tbmr nnCt9z/rVaFGTIiFc74M29SRuPUBCcdavwjPoCqY0n7t8HLz/E8U1VBdS6Usg8xSDk7o n9UdnwQ+DM/1EF0qoxkWvB9o4LFCLiWmP1TsBEEMMygfSWLYSdMGzAzZLQjZ/4hrj/3U OJDA== 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=U//K7bTDL8KaYInmcROqTh/daXvijLOqEMx2V59sNjU=; b=BNr65xGOUAv6weCpFYuiECMb9tSoTbQ0SE8xsxDwZCIszTBp2yJkZHFDnLS1cnKT3k wQpgbLnFGXcmRBGg+j9T+rWqL4lLITHMejBdo1zxP1anTrG3o47/PZexpmTGfx0mUKGY Jd8Bd8ScViGbc57lya1mdj6R5PyRKsgXGfRuDh89ZAXpE23AQpn0PgPxu8BmaI2BIv5z d+Z9rwZbLVrrcpr4/VJXsbt70YjCD6AA0uxby0xHYwVzPJ80qYNTTIzCSw4AH6Dxwjvv RNA95+VazVuibEoLvuneZM9TxVcKdJ+FbghNgyRdcts0uR0VFdm9xC55vgUsCWDYM5/v Sf5w== X-Gm-Message-State: APf1xPBZgkZOron9bLxT6AZ2zcY+6ezSFZ/NTKgdMUarw5KMICz/coF2 apMFvTVSXgGuMUTLPC8bjU7QLNxeacctMGiK3NwTHg== X-Google-Smtp-Source: AH8x2256s7XuKV6MHpMbUdYewFxXUinzCJWneAHCHNGe1oz0SP4v9rxr0tpv0GEk8ZyyJfiqHfQPQEzIx2J6+AT7QFc= X-Received: by 10.129.112.207 with SMTP id l198mr3163794ywc.139.1518213814183; Fri, 09 Feb 2018 14:03:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Fri, 9 Feb 2018 14:03:33 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Fri, 9 Feb 2018 14:03:33 -0800 Message-ID: Subject: Re: The Recovery Period To: Patrick McManus Cc: Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0b14841702ba0564ceb34d" 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, 09 Feb 2018 22:03:37 -0000 --94eb2c0b14841702ba0564ceb34d Content-Type: text/plain; charset="UTF-8" Suggest text if you think it can be made better! On Fri, Feb 9, 2018 at 12:24 PM, Patrick McManus wrote: > you're right - its ok. I missed the "when a larger" part (reading it as > "when it is recovered"). > --94eb2c0b14841702ba0564ceb34d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Suggest text if you think it can be made better!

On Fri, Feb 9, 2018 a= t 12:24 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:=
you're right - its = ok. I missed the "when a larger" part (reading it as "when i= t is recovered").

--94eb2c0b14841702ba0564ceb34d-- From nobody Fri Feb 9 14:21:01 2018 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 0227B1270FC for ; Fri, 9 Feb 2018 14:21:00 -0800 (PST) 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 2kjIikrgAPVi for ; Fri, 9 Feb 2018 14:20:58 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::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 94256126D3F for ; Fri, 9 Feb 2018 14:20:58 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id k15so7218357oib.1 for ; Fri, 09 Feb 2018 14:20:58 -0800 (PST) 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=x2N6aelguyF2kbab8DbYXnI6v+OhxJ4qRgfpZXnbulE=; b=f2GROexR3q3CzkiTm5/KvRvNEPLMH2Emnjd2jXBW7p5vSFAtjYoUzWUnUutnNdOXM4 60lmkeaK8aFA9oKiGXXO+mQJScKZngCA3ghEkl1rfaxs7TdCRQ3Rjxn7olJ3uTEPRchR nx6dCNIA3dqSe7BUH4PIEsOBh+RN/Z7mFAKhX4RxnneBi9GZEsb2tGl4TQTlF0Edt5s7 WWT/rkRiVqkttUPcRGERRqP+GGPY3Bape57rH0mFGqgmXQVsgONUtTrZSsMgZoxZaYPf ysD4h68oGEuP2/MOKPygx1r/Vo63tEBw/Ju8WyAw2s8S//o4h4XEdLxxoNvgEb51D+SB Wr3g== 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=x2N6aelguyF2kbab8DbYXnI6v+OhxJ4qRgfpZXnbulE=; b=jx1W/WkNy8O2bEiSHyjbCTIeVPd44yEVKtpnfT4F+HiHbwvNZcOYmmzhDzm/UdmEvz FiEBhNmdTMPdEngBX58zrXhP7lKXL6YuV40tbOaEEoWRxP4rVclmEWAVDESxhpuJg/T1 uhreSuKdJiORRPdKi/a9kCMyTVuIuydr9JpOOsB+6XevBOfXSN2v7OfZxBiTBxghMg22 KRFtXabW2v++RribAsEAoftLu0d/5UvsT6SbPr7g4INDQKeHVFe6JKhXzNYrLt+w/QnT LHVhHtcW+NlKUN0PIt6N+Sk+AVbuziL4yNIsVcRaPQhJa3WzoQpx4IaY521NcLbvmbBv 31oQ== X-Gm-Message-State: APf1xPC8JPDsIDZ2rfLZKOi2MOlU3BqOrW7y7J5Z/YrJ4MT1B6T5aayH 9g83r7qFbkKmfhY7X1vgOiGkQVCTRzy9Dq/KE+0= X-Google-Smtp-Source: AH8x225O7Sgun2USEDAui3uC7+5jYEVB5Um/VXJpTtH8AiXsIKeN3xsI6U0bk8wS+flSnFTU5hpv/yqyDIxoS0N7q90= X-Received: by 10.202.217.2 with SMTP id q2mr2986464oig.28.1518214857882; Fri, 09 Feb 2018 14:20:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Fri, 9 Feb 2018 14:20:57 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Sat, 10 Feb 2018 09:20:57 +1100 Message-ID: Subject: Re: The Recovery Period To: Jana Iyengar Cc: Patrick McManus , Ian Swett , 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: Fri, 09 Feb 2018 22:21:00 -0000 Ian already did. I think that putting that in the draft would be a good idea. On Sat, Feb 10, 2018 at 9:03 AM, Jana Iyengar wrote: > Suggest text if you think it can be made better! > > On Fri, Feb 9, 2018 at 12:24 PM, Patrick McManus > wrote: >> >> you're right - its ok. I missed the "when a larger" part (reading it as >> "when it is recovered"). > > From nobody Fri Feb 9 14:22:48 2018 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 543CE127241 for ; Fri, 9 Feb 2018 14:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 I59gXB6w9fLy for ; Fri, 9 Feb 2018 14:22:44 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::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 95B99126D3F for ; Fri, 9 Feb 2018 14:22:44 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id b66so118526itd.5 for ; Fri, 09 Feb 2018 14:22:44 -0800 (PST) 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=X4kQfdmUGdrDkdWt/PbBMXuolGRocaauM1TaNsKWOZ0=; b=Emw9RTAvYpz55yxfwpEm2fxFhbFfgRixaoGH61lHSormANYvAr0UPMPOtBvSyxXXyK +1wE3fcGJhLJYyMm6aVYYW82gXR/a3iymRpMR8QTglW7HGQR9eaGyD0kGkIgGdlI9fK3 NenQsLOn4jWAPM5C642V8X7YSYYiV/29AVpbZqsRJlZw1pmkhCiuJfwkTitt705Iyiso 8enYcf0Z/oayG2vWJlCcn+v98oN6iQ7orwJbYu6XqKonY6A0yWHhjHTMsxZrMK5piZzB mpjBXH6vP0ESjaoOjncpKbNXsUxJcUdVP/OI3natyCw7K1aJRF9nQzOa6JvZPTqmEXnD iYRg== 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=X4kQfdmUGdrDkdWt/PbBMXuolGRocaauM1TaNsKWOZ0=; b=XODF2cCWVOBZBoPIzYEoim6J9tGNPP8i1uiEybitSJEjI/ocXQN1+rumsaA/+pXCTw 0uN3mFwSC+VcHonyHggmalzifr6vhBr4TAY5R3Qi5v+X/Nhx5Ch2eOY6DBBAjSOqJfby d13IC3uC10qkNZR1hQG3yC9+Xz7y33Kl9PsgjpuAcsAGz5VzYi6G7qFuaFQXMo0s6xDl z24Ajs4iebuRkUtj+PURv68L9C/UlpuMGXg94FeziUbqEaQ9W2uQ311xZ4fvwpCAkRHw uuDTUTy4Qjom0NDc7CroLVXi4SOwUDqWoSpIJ/6Py0hzP7HIbc6TOhr97d+GIy++ngfW nmGw== X-Gm-Message-State: APf1xPCF1ogpu4e/58UvfLBsaKVFI+20TNRJM1W3FRbYlhpsdkXLQPBn M46diLRggIKwBe4ZqsZfwuV/E/mPA37mDPXC2Dzm5pg= X-Google-Smtp-Source: AH8x227DMnbMNeAqlGHwtkYVb5AHXLxomOk53RHQIYxpdmDo02SsYIPtRtZsb8zY8VgTN62uU7cAaFekV0XLLCAjfAY= X-Received: by 10.36.178.26 with SMTP id u26mr5238930ite.4.1518214963470; Fri, 09 Feb 2018 14:22:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.176.207 with HTTP; Fri, 9 Feb 2018 14:22:22 -0800 (PST) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAD6C5A@bgb01xud1012> From: "Charles 'Buck' Krasic" Date: Fri, 9 Feb 2018 14:22:22 -0800 Message-ID: Subject: Re: Review of QCRAM To: Martin Thomson Cc: Mike Bishop , Lucas Pardue , QUIC WG Content-Type: multipart/alternative; boundary="f403045d914c97c9410564cef757" 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, 09 Feb 2018 22:22:47 -0000 --f403045d914c97c9410564cef757 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On blocked evictions. a) there's a real possibility that setting table size to 64KB is the most elegant solution, because evictions may not happen for the vast majority of connections. Perhaps something along these lines is worth mentioning (in section 4?)= . b) if not it should be possible to prevent blocked evictions using indexed duplicates (Section 3.5 ), I can think of a couple of complementary policies that might be useful: 1. based on index, duplicate if the encoder emits a reference that is (getting close to) the threshold where the HPACK instruction size jumps from 1 to 2 bytes. (I'm feeling too lazy to figure this out precisely, = but I think it is when the HPACK relative index is getting close to 128). t= his practice also benefits compression ratio independent of evictions. 2. based on dynamic table fill. duplicate if the encoder the cumulative number of bytes for the referenced entry (the size of the entry and all newer entries in the table) is more than some threshold (e.g. 80% of tab= le capacity). Neither of the above works if you have an entry that sits in the table un-referenced until it is time to evict. My intuition is such a scenario should not arise in practice. On Fri, Feb 9, 2018 at 1:35 PM, Martin Thomson wrote: > On Sat, Feb 10, 2018 at 4:56 AM, Mike Bishop wrote= : > > Your observation that you=E2=80=99re keeping a tuple of stream-blocknum= on each > > entry is interesting. Can you go into more detail where this is? > Couldn=E2=80=99t > > you also keep a simple refcount of outstanding blocks, then separately > track > > which entries are referenced by outstanding blocks? IIRC, in QCRAM > there=E2=80=99s > > not a situation in which you need to determine which outstanding header > > block is blocking eviction, only whether an outstanding HEADERS frame > blocks > > eviction. Or am I misunderstanding where you=E2=80=99re keeping the tu= ple? > > So you send out two header blocks on a stream. One includes > :status=3D307, the other digest=3Dblah. When the acks come in, they > identify the stream. The first ack needs to ensure that it removes > any block on :status=3D307, the second digest=3Dblah. You can't just say > that ":status=3D307 is blocked from eviction, because you need to know > when it is no longer blocked, which means tracking where you sent it. > > A refcount of outstanding blocks will likely never hit zero, meaning > you can never evict. > > I realize now that I didn't consider stream resets, which my scheme > doesn't manage well (you need to have a nuke-all-that-partially-match > option). > > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --f403045d914c97c9410564cef757 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On blocked evictions.

a) there's a = real possibility that setting table size to 64KB is the most elegant soluti= on, because evictions may not happen for the vast majority of connections.<= /div>
=C2=A0 =C2=A0 Perhaps something along these lines is worth mentio= ning (in section 4?).

b) if not it should be possi= ble to prevent blocked evictions using indexed duplicates (Section 3.5), I can think of a couple of complementary p= olicies that might be useful:
  1. based on index, duplicate i= f the encoder emits a reference that is (getting close to) the threshold wh= ere the HPACK instruction size jumps from 1 to 2 bytes.=C2=A0 (I'm feel= ing too lazy to figure this out precisely, but I think it is when the HPACK= relative index is getting close to 128).=C2=A0 this practice also benefits= compression ratio independent of evictions.
  2. based on dynamic table= fill.=C2=A0 duplicate if the encoder the cumulative number of bytes for th= e referenced entry (the size of the entry and all newer entries in the tabl= e) is more than some threshold (e.g. 80% of table capacity).=C2=A0
    3. =C2=A0 =C2=A0Neither of the above works if you have an entry that sit= s in the table un-referenced until it is time to evict.=C2=A0 My intuition = is such a scenario should not arise in practice.

=



On Fri, Feb 9, 2018 at 1:35 PM, Martin Thomson <martin.= thomson@gmail.com> wrote:
<= span class=3D"">On Sat, Feb 10, 2018 at 4:56 AM, Mike Bishop <mbishop@evequefou.be> wrote:
> Your observation that you=E2=80=99re keeping a tuple of stream-blocknu= m on each
> entry is interesting.=C2=A0 Can you go into more detail where this is?= =C2=A0 Couldn=E2=80=99t
> you also keep a simple refcount of outstanding blocks, then separately= track
> which entries are referenced by outstanding blocks?=C2=A0 IIRC, in QCR= AM there=E2=80=99s
> not a situation in which you need to determine which outstanding heade= r
> block is blocking eviction, only whether an outstanding HEADERS frame = blocks
> eviction.=C2=A0 Or am I misunderstanding where you=E2=80=99re keeping = the tuple?

So you send out two header blocks on a stream.=C2=A0 One includes :status=3D307, the other digest=3Dblah.=C2=A0 When the acks come in, they identify the stream.=C2=A0 The first ack needs to ensure that it removes any block on :status=3D307, the second digest=3Dblah.=C2=A0 You can't j= ust say
that ":status=3D307 is blocked from eviction, because you need to know=
when it is no longer blocked, which means tracking where you sent it.

A refcount of outstanding blocks will likely never hit zero, meaning
you can never evict.

I realize now that I didn't consider stream resets, which my scheme
doesn't manage well (you need to have a nuke-all-that-partially-match option).




--
Charles '= ;Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141

--f403045d914c97c9410564cef757-- From nobody Fri Feb 9 15:13:11 2018 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 5670612D7EC for ; Fri, 9 Feb 2018 15:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_H4=-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 (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 8aJDoo9g6SvP for ; Fri, 9 Feb 2018 15:13:07 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0131.outbound.protection.outlook.com [104.47.34.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36E9128D2E for ; Fri, 9 Feb 2018 15:13:07 -0800 (PST) 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=IQ/c0E1u52iD7Ua0sInX1fY8xA8xZqO5VN2s0wdXd/s=; b=EN1ZiR7ft4Wgaq8/0tg/Y6YwCjNpO2LLmYLPg00Ib7QBxu5BiF0PoFvYbSFS7G651bThgJlQsDI+fL4fr015u7EYdggMV8rApeoom3yC1S040wzX0Y7lGVEbvcbGQoAgT7F+Pp5oFimW2Fa9owvjtIq1mCqne0EqOXD9kcdqryo= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0120.namprd21.prod.outlook.com (10.173.189.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.1; Fri, 9 Feb 2018 23:13:06 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 23:13:06 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Victor Vasiliev CC: "quic@ietf.org" , huitema , Marten Seemann Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAbWdAIAAKHbggAGCSACAAALsAIAAG8kA Date: Fri, 9 Feb 2018 23:13:05 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0120; 7:2ui1Gysn8fsDWliDhN4hDFwuZrptgSQTV4B3CleVqP2nuNPOrpqPG/+VR26y4FkzdyUsCNLCfw9TOyUvKVWjgrhE24kQZcOX2U2V1GpQqmhQaxdPXjDk+D7LDQJmtErAMH/qw0QE+mWg5iXvmR4xOVwC8qh6sMR93hDCO9QikFyit7Xjo7HfEO5J5/7hY3TCi3IjekXLbZgmOY2EvrMSVG2mqyV9M67flJpIY6GcCrhOQKTM/UhHrkHsOf8Dh3y0 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 831edcc8-d164-4b0e-659f-08d57012ad3e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0120; x-ms-traffictypediagnostic: CY4PR21MB0120: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(278428928389397)(89211679590171)(85827821059158)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231101)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:CY4PR21MB0120; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0120; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(376002)(39860400002)(39380400002)(189003)(199004)(25786009)(478600001)(10290500003)(81156014)(81166006)(186003)(6346003)(53936002)(8676002)(39060400002)(14454004)(2906002)(6246003)(86612001)(4326008)(74316002)(8936002)(68736007)(7736002)(106356001)(3480700004)(2950100002)(3660700001)(6436002)(5250100002)(790700001)(9686003)(97736004)(6306002)(54896002)(102836004)(55016002)(6116002)(5660300001)(10090500001)(3280700002)(86362001)(7116003)(93886005)(8990500004)(105586002)(33656002)(99286004)(7696005)(229853002)(110136005)(54906003)(76176011)(22452003)(316002)(6506007)(53546011)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0120; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: hes00jq0jeOdAcz8NVgRZHEY6oD6Fai8WlRKsBlcZKlz6OSExH6sUw5DAa8gmiVd9/OPXIQe4UbevahImi/V7g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB013370F753D8095B4A640F04B6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 831edcc8-d164-4b0e-659f-08d57012ad3e X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 23:13:05.9344 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0120 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, 09 Feb 2018 23:13:10 -0000 --_000_CY4PR21MB013370F753D8095B4A640F04B6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29tcGxldGVseSBhZ3JlZS4gSW4gb3VyIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gY3J5cHRvIGlz IGEgaHVnZSBjb3N0ICh3ZSBzZWUgYSBzaXplYWJsZSBwZXJmIGRpZmZlcmVuY2UgYmV0d2VlbiBh IHBsYWludGV4dCAodGVzdCBvbmx5KSBtb2RlIHZlcnN1cyBub3QpIGFuZCB3ZSBleHBlY3QgdGhh dCB0byBnZXQgZXZlbiBtb3JlIHByb25vdW5jZWQgYXMgdGhlIG1haW4gYm90dGxlbmVjayBhcyB3 ZSBjb250aW51ZSB0byBpbXByb3ZlIFVEUCBwZXJmLg0KDQpGcm9tOiBNaWtrZWwgRmFobsO4ZSBK w7hyZ2Vuc2VuIFttYWlsdG86bWlra2VsZmpAZ21haWwuY29tXQ0KU2VudDogRnJpZGF5LCBGZWJy dWFyeSA5LCAyMDE4IDE6MjggUE0NClRvOiBWaWN0b3IgVmFzaWxpZXYgPHZhc2lsdnZAZ29vZ2xl LmNvbT47IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPg0KQ2M6 IHF1aWNAaWV0Zi5vcmc7IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+OyBNYXJ0ZW4gU2Vl bWFubiA8bWFydGVuc2VlbWFubkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogUGFja2V0IG51bWJl ciBlbmNyeXB0aW9uDQoNCkkgYW0gdmVyeSBjb25mdXNlZCBhYm91dCB0aGUgMS4yNSUgbnVtYmVy LiAgMTI4MCBieXRlcyBpcyBhYm91dCA4MCBBRVMgYmxvY2tzLCBhbmQgb25lIGV4dHJhIGJsb2Nr IGlzIDEuMjUlIG9uIHRvcCBvZiB0b3RhbCAqZW5jcnlwdGlvbiogY29zdHMgKHlvdSBkb24ndCBo YXZlIHRvIE1BQyB0aGUgUE4sIHNvIHRoYXQncyBldmVuIGNoZWFwZXIpLiAgQW5kIHRoZSBlbmNy eXB0aW9uIGl0c2VsZiBpcyBmYWlybHkgY2hlYXAgY29tcGFyZWQgdG8gYWxtb3N0IGFueSBvdGhl ciBwYXJ0IG9mIHRoZSBRVUlDIHN0YWNrIChzZW50IHBhY2tldCB0cmFja2luZywgYWNrIHByb2Nl c3NpbmcsIEkvTywgdGltZXJzLCBldGMpLg0KDQpUaGlzIGlzIGZvciB0aGUgbGFyZ2UgZmlsZSB1 cGxvYWQgY2FzZS4gSXQgZG9lcyBub3QgY29uc2lkZXIgbG93IGxhdGVuY3kgYXBwbGljYXRpb25z IHdpdGggc21hbGwgbWVzc2FnZXMgYW5kIHNlcGFyYXRlIGNvcmVzIGZvciBkaWZmZXJlbnQgcmVz cG9uc2liaWxpdGllcy4gSXQgYWxzbyBkb2VzIG5vdCBjb25zaWRlciB0aGF0IHRoYXQgYSBzaW5n bGUgYmxvY2sgY29zdHMgdGhlIHNhbWUgYXMgNCBibG9ja3Mgb24gSW50ZWwsIG5vciBkb2VzIGl0 IGNvbnNpZGVyIHRoYXQgdGhlIHBhY2tldCBjYW5ub3QgYmUgZGVjb2RlZCBpbi1wbGFjZS4gQnV0 IHllcywgaW4gdGhlIGNvbW1vbiBsYXJnZSBmaWxlIGRvd25sb2FkIGNhc2UsIHRoZSBjb3N0IGlz IG5vdCB2ZXJ5IHNpZ25pZmljYW50LiBCdXQgaXQgY2FuIGJlIHNpZ25pZmljYW50IGVub3VnaCB0 byBjaG9vc2UgYW5vdGhlciBwcm90b2NvbCBpbiBvdGhlciBzY2VuYXJpb3MuIFNvIHRoZXJlIG5l ZWRzIHRvIGJlIGEgcmVhbGx5IGdvb2QgcmVhc29uIHRvIGFkZCB0aGlzIGV4dHJhIGxhdGVuY3kg c3RlcC4gTGlua2FiaWxpdHkgbWlnaHQgYmUgYW4gYXJndW1lbnQsIGFuZCBvc3NpZmljYXRpb24g bWlnaHQgYmUgdG9vLCBhbmQgdGhlIGNvbXBsZXhpdHkgb2YgYWx0ZXJuYXRpdmVzIG1pZ2h0IGFz IHdlbGwuIEhvd2V2ZXIsIEnigJltIG5vdCBjb252aW5jZWQuIEnigJltIGFsc28gbm90IGNvbXBs ZXRlbHkgZGlzbWlzc2luZyBpdCwgYnV0IEkgd291bGQgbGlrZSB0byBzZWUgYWx0ZXJuYXRpdmVz IGV4cGxvcmVkIG1vcmUgdGhvcm91Z2hseSBiZWZvcmUgdGhyb3dpbmcgaW4gYSBjb3N0IGZvciBu byBnb29kIHJlYXNvbi4NCg== --_000_CY4PR21MB013370F753D8095B4A640F04B6F20CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGlu az0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q29tcGxldGVseSBhZ3JlZS4gSW4gb3VyIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gY3J5 cHRvIGlzIGEgaHVnZSBjb3N0ICh3ZSBzZWUgYSBzaXplYWJsZSBwZXJmIGRpZmZlcmVuY2UgYmV0 d2VlbiBhIHBsYWludGV4dCAodGVzdCBvbmx5KSBtb2RlIHZlcnN1cyBub3QpIGFuZCB3ZSBleHBl Y3QgdGhhdCB0byBnZXQgZXZlbiBtb3JlIHByb25vdW5jZWQgYXMgdGhlIG1haW4gYm90dGxlbmVj ayBhcyB3ZSBjb250aW51ZQ0KIHRvIGltcHJvdmUgVURQIHBlcmYuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlr a2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbV0NCjxicj4N CjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDksIDIwMTggMToyOCBQTTxicj4NCjxiPlRv OjwvYj4gVmljdG9yIFZhc2lsaWV2ICZsdDt2YXNpbHZ2QGdvb2dsZS5jb20mZ3Q7OyBQcmF2ZWVu IEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IHF1aWNAaWV0Zi5vcmc7IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7OyBN YXJ0ZW4gU2VlbWFubiAmbHQ7bWFydGVuc2VlbWFubkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGFtIHZlcnkgY29uZnVzZWQgYWJv dXQgdGhlIDEuMjUlIG51bWJlci4mbmJzcDsgMTI4MCBieXRlcyBpcyBhYm91dCA4MCBBRVMgYmxv Y2tzLCBhbmQgb25lIGV4dHJhIGJsb2NrIGlzIDEuMjUlIG9uIHRvcCBvZiB0b3RhbCAqZW5jcnlw dGlvbiogY29zdHMgKHlvdSBkb24ndCBoYXZlIHRvIE1BQyB0aGUNCiBQTiwgc28gdGhhdCdzIGV2 ZW4gY2hlYXBlcikuJm5ic3A7IEFuZCB0aGUgZW5jcnlwdGlvbiBpdHNlbGYgaXMgZmFpcmx5IGNo ZWFwIGNvbXBhcmVkIHRvIGFsbW9zdCBhbnkgb3RoZXIgcGFydCBvZiB0aGUgUVVJQyBzdGFjayAo c2VudCBwYWNrZXQgdHJhY2tpbmcsIGFjayBwcm9jZXNzaW5nLCBJL08sIHRpbWVycywgZXRjKS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5UaGlzIGlzIGZvciB0aGUgbGFyZ2UgZmlsZSB1cGxvYWQgY2FzZS4gSXQgZG9lcyBub3QgY29u c2lkZXIgbG93IGxhdGVuY3kgYXBwbGljYXRpb25zIHdpdGggc21hbGwgbWVzc2FnZXMgYW5kIHNl cGFyYXRlIGNvcmVzIGZvciBkaWZmZXJlbnQgcmVzcG9uc2liaWxpdGllcy4gSXQgYWxzbyBkb2Vz IG5vdCBjb25zaWRlciB0aGF0DQogdGhhdCBhIHNpbmdsZSBibG9jayBjb3N0cyB0aGUgc2FtZSBh cyA0IGJsb2NrcyBvbiBJbnRlbCwgbm9yIGRvZXMgaXQgY29uc2lkZXIgdGhhdCB0aGUgcGFja2V0 IGNhbm5vdCBiZSBkZWNvZGVkIGluLXBsYWNlLiBCdXQgeWVzLCBpbiB0aGUgY29tbW9uIGxhcmdl IGZpbGUgZG93bmxvYWQgY2FzZSwgdGhlIGNvc3QgaXMgbm90IHZlcnkgc2lnbmlmaWNhbnQuIEJ1 dCBpdCBjYW4gYmUgc2lnbmlmaWNhbnQgZW5vdWdoIHRvIGNob29zZSBhbm90aGVyDQogcHJvdG9j b2wgaW4gb3RoZXIgc2NlbmFyaW9zLiBTbyB0aGVyZSBuZWVkcyB0byBiZSBhIHJlYWxseSBnb29k IHJlYXNvbiB0byBhZGQgdGhpcyBleHRyYSBsYXRlbmN5IHN0ZXAuIExpbmthYmlsaXR5IG1pZ2h0 IGJlIGFuIGFyZ3VtZW50LCBhbmQgb3NzaWZpY2F0aW9uIG1pZ2h0IGJlIHRvbywgYW5kIHRoZSBj b21wbGV4aXR5IG9mIGFsdGVybmF0aXZlcyBtaWdodCBhcyB3ZWxsLiBIb3dldmVyLCBJ4oCZbSBu b3QgY29udmluY2VkLiBJ4oCZbSBhbHNvIG5vdA0KIGNvbXBsZXRlbHkgZGlzbWlzc2luZyBpdCwg YnV0IEkgd291bGQgbGlrZSB0byBzZWUgYWx0ZXJuYXRpdmVzIGV4cGxvcmVkIG1vcmUgdGhvcm91 Z2hseSBiZWZvcmUgdGhyb3dpbmcgaW4gYSBjb3N0IGZvciBubyBnb29kIHJlYXNvbi48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB013370F753D8095B4A640F04B6F20CY4PR21MB0133namp_-- From nobody Fri Feb 9 15:16:55 2018 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 F292A127AD4 for ; Fri, 9 Feb 2018 15:16:53 -0800 (PST) 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, 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 6yZlybt28fqq for ; Fri, 9 Feb 2018 15:16:52 -0800 (PST) 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 73A5F1242F7 for ; Fri, 9 Feb 2018 15:16:52 -0800 (PST) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w19NBqu7015226; Fri, 9 Feb 2018 23:16:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=dyoFMVYbR/42UGh6fUaUi/RSa2MXTf2lN2WvOZFYT0g=; b=FClY+E4b4/z/0IK6eW6KuD2GfUgpU31RpDl1L/VLczTJDbY87kh5cT+2rqtShhvXqOpK eBM0O/vPcEWtKXgfDpMivcInm6Ow8ighC+Iq59/Jd/DrgeEvDXeWiUpm9hgU10Hq73y6 +eY2QlkYF24KLBrB6mtayY3iRwSBTmrW9yCNKXGTmXTDjWANTrg7PHy3i9xTYMOwvwxS 8vDSXD+YAf0F/Drx4/Y3p8g4TJg0TqtAOemM0TTmD3WbRcHFQ5/81OJAlQJOg6vOoJE+ gI+52eLzH34vMAjfAE0m1xA2fNw0kXh+vyuiyLFedKKMC13yElGbCTXEMv1mfD2mk7VG 8g== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2g0x2438rp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2018 23:16:43 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w19NGIqn032687; Fri, 9 Feb 2018 18:16:42 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint1.akamai.com with ESMTP id 2fw9a0f93k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2018 18:16:42 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 9 Feb 2018 18:16:41 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 9 Feb 2018 18:16:41 -0500 From: "Salz, Rich" To: Praveen Balasubramanian , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "Victor Vasiliev" CC: Marten Seemann , "quic@ietf.org" , huitema Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31Be9MxlVQxEqrVhXIOG6b4KOM1RYAgABeoICAAAgVAIAAd3KAgAA8YgCAACPDAIAAAicAgAOBloCAALfcgIAACBoAgAEGFwCAANx+AIAAn5GAgAB7xICAADUigIAADBaAgADXOgCAAGaugIAAEEkAgACizACAADhiAIAAHkiAgAADUYCAACdEAIAAVRYAgAAUZgCAAA5oAIAAEIEAgABFkgCAAAUSgIAABUkAgAABmYCAAAaRgIAAC4qAgACi8ACAAbWAAIAALYeAgAF9NgCAAALtAIAAHXaA//+tMIA= Date: Fri, 9 Feb 2018 23:16:41 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.245] Content-Type: multipart/alternative; boundary="_000_A2AF9845FBA042DE8FB1A23C9E80702Aakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=752 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090293 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_13:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=705 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090293 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, 09 Feb 2018 23:16:54 -0000 --_000_A2AF9845FBA042DE8FB1A23C9E80702Aakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnV0IHBsYWludGV4dC9lbmNyeXB0aW9uIGlzbuKAmXQgdGhlIHJlYWwgY29tcGFyaXNvbiwgaXTi gJlzIGVuY3J5cHRpbmcgQSB2cyBBLW4sIHJpZ2h0Pw0KDQoNCg== --_000_A2AF9845FBA042DE8FB1A23C9E80702Aakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <40E8E76961C57449916497107773751A@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CdXQgcGxhaW50ZXh0L2VuY3J5cHRpb24gaXNu4oCZdCB0aGUgcmVhbCBjb21wYXJp c29uLCBpdOKAmXMgZW5jcnlwdGluZyBBIHZzIEEtbiwgcmlnaHQ/PG86cD48L286cD48L3A+DQo8 cD48YSBuYW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L2E+PC9wPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A2AF9845FBA042DE8FB1A23C9E80702Aakamaicom_-- From nobody Fri Feb 9 15:33:35 2018 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 F362212D837 for ; Fri, 9 Feb 2018 15:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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 (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 p3pDElSp4o5M for ; Fri, 9 Feb 2018 15:33:31 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0110.outbound.protection.outlook.com [104.47.42.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11ECA12711D for ; Fri, 9 Feb 2018 15:33:30 -0800 (PST) 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=FGiwmeLO+i6Vqm0WgnQbdEVZWyhGeSi7Gsaw+Px8CzI=; b=ASeBkQ9R82GSJZLEleE8lpJ6eagvKQf6Z8im17cnA/x+IcOp7T5P+DKlZoR5eEMC2NMq8hiQQH+Lvj6UdXkHhIxAsXPZsozL9Kj5DzfUgqDyCWjSqZNfg6IkBVYEwbELFvIZai1izNxfJG7A+F6t2s/9ktt0FIYzb3xfgaeRu6k= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0472.namprd21.prod.outlook.com (10.172.121.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.4; Fri, 9 Feb 2018 23:33:29 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 23:33:29 +0000 From: Praveen Balasubramanian To: "Salz, Rich" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Victor Vasiliev CC: Marten Seemann , "quic@ietf.org" , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAbWdAIAAKHbggAGCSACAAALsAIAAG8kAgAACr4CAAAPPQA== Date: Fri, 9 Feb 2018 23:33:29 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0472; 7:yyV1SG44g5frLXmZl7+xTIe+GI9SKpcFfKyQYHqG9t+XPawOm12N0DdVDuOPMdWQK2jYh7q00cM69KbIkgwy1B+llfLzgfQWrUbGjIFJwpAHRLGSg/lvbjkGwJ/uu7ygiTN7aZyZi+qNqctRIPK3/qDQxe55ll4X6PZ7uh3n76+7jqkhiXJp/Pik7NkMu43pRdtm5jiQFOPbdcVlvvWxIzEwcbnlk56suOQBjDWiyyzA849MQ0cqKHySCRNzDHer x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3a183cc6-7fba-4f50-c93f-08d57015865b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0472; x-ms-traffictypediagnostic: CY4PR21MB0472: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(85827821059158)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0472; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0472; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(346002)(39380400002)(366004)(189003)(199004)(14454004)(86362001)(5250100002)(2950100002)(22452003)(10290500003)(99286004)(7116003)(478600001)(81156014)(81166006)(316002)(8990500004)(110136005)(54906003)(68736007)(25786009)(86612001)(6246003)(5660300001)(53936002)(10090500001)(6306002)(39060400002)(54896002)(9686003)(6116002)(93886005)(790700001)(55016002)(4326008)(6436002)(3660700001)(74316002)(3280700002)(106356001)(186003)(7736002)(3480700004)(8936002)(2900100001)(8676002)(33656002)(6506007)(229853002)(53546011)(102836004)(2906002)(105586002)(97736004)(76176011)(6346003)(7696005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0472; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: LEWVAcCaY70O/3eKma2pbzh6wa+aWw0T/Dkzv2SuemF3jtI0H8E6+f2g9cSNuTuu1qaLTMwfOaretdlh8D7McQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133A0BDD44DCCEDBD66351CB6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a183cc6-7fba-4f50-c93f-08d57015865b X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 23:33:29.2173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0472 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, 09 Feb 2018 23:33:34 -0000 --_000_CY4PR21MB0133A0BDD44DCCEDBD66351CB6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVwIGluIGNvbnRleHQgb2YgdGhlIHByb3Bvc2FscyB5ZXMgYW5kIHRoYXQgaXMgYXQgYWJvdXQg MSUrIChiYXNlZCBvbiBhIHF1aWNrIHRlc3QpIGFuZCBtaWdodCBnZXQgbW9yZSBwcm9ub3VuY2Vk IHdoZW4gb3RoZXIgYm90dGxlbmVja3MgZGlzYXBwZWFyLiBJIHdhcyBtZXJlbHkgY29tbWVudGlu ZyB0aGF0IGNyeXB0byBpcyBhbHJlYWR5IGEgbGFyZ2UgZnJhY3Rpb24gb2Ygb3ZlcmFsbCBwcm9j ZXNzaW5nIGNvc3QgYW5kIHdpbGwgb25seSBiZWNvbWUgYSBsYXJnZXIgZmFjdG9yIHdpdGggb3Ro ZXIgaW1wcm92ZW1lbnRzLg0KDQpGcm9tOiBTYWx6LCBSaWNoIFttYWlsdG86cnNhbHpAYWthbWFp LmNvbV0NClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgOSwgMjAxOCAzOjE3IFBNDQpUbzogUHJhdmVl biBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBNaWtrZWwgRmFobsO4ZSBK w7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb20+OyBWaWN0b3IgVmFzaWxpZXYgPHZhc2lsdnZA Z29vZ2xlLmNvbT4NCkNjOiBNYXJ0ZW4gU2VlbWFubiA8bWFydGVuc2VlbWFubkBnbWFpbC5jb20+ OyBxdWljQGlldGYub3JnOyBodWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KU3ViamVjdDog UmU6IFBhY2tldCBudW1iZXIgZW5jcnlwdGlvbg0KDQpCdXQgcGxhaW50ZXh0L2VuY3J5cHRpb24g aXNu4oCZdCB0aGUgcmVhbCBjb21wYXJpc29uLCBpdOKAmXMgZW5jcnlwdGluZyBBIHZzIEEtbiwg cmlnaHQ/DQoNCg0K --_000_CY4PR21MB0133A0BDD44DCCEDBD66351CB6F20CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWlu IDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcCBpbiBjb250ZXh0IG9mIHRoZSBwcm9wb3Nh bHMgeWVzIGFuZCB0aGF0IGlzIGF0IGFib3V0IDElJiM0MzsgKGJhc2VkIG9uIGEgcXVpY2sgdGVz dCkgYW5kIG1pZ2h0IGdldCBtb3JlIHByb25vdW5jZWQgd2hlbiBvdGhlciBib3R0bGVuZWNrcyBk aXNhcHBlYXIuIEkgd2FzIG1lcmVseSBjb21tZW50aW5nIHRoYXQgY3J5cHRvIGlzIGFscmVhZHkg YSBsYXJnZSBmcmFjdGlvbiBvZiBvdmVyYWxsIHByb2Nlc3NpbmcgY29zdA0KIGFuZCB3aWxsIG9u bHkgYmVjb21lIGEgbGFyZ2VyIGZhY3RvciB3aXRoIG90aGVyIGltcHJvdmVtZW50cy4gPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gU2FseiwgUmljaCBbbWFpbHRvOnJzYWx6QGFrYW1haS5jb21dIDxicj4NCjxiPlNl bnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDksIDIwMTggMzoxNyBQTTxicj4NCjxiPlRvOjwvYj4g UHJhdmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7OyBNaWtr ZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20mZ3Q7OyBWaWN0b3Ig VmFzaWxpZXYgJmx0O3Zhc2lsdnZAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IE1hcnRl biBTZWVtYW5uICZsdDttYXJ0ZW5zZWVtYW5uQGdtYWlsLmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc7 IGh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+ IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkJ1dCBwbGFpbnRleHQvZW5jcnlwdGlvbiBpc27igJl0IHRoZSByZWFsIGNv bXBhcmlzb24sIGl04oCZcyBlbmNyeXB0aW5nIEEgdnMgQS1uLCByaWdodD88bzpwPjwvbzpwPjwv cD4NCjxwPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0133A0BDD44DCCEDBD66351CB6F20CY4PR21MB0133namp_-- From nobody Fri Feb 9 15:35:36 2018 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 7B8F312D84D for ; Fri, 9 Feb 2018 15:35:34 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 w_pMwg3JV-IN for ; Fri, 9 Feb 2018 15:35:31 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0093.outbound.protection.outlook.com [104.47.41.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79BF312D838 for ; Fri, 9 Feb 2018 15:35:31 -0800 (PST) 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=hLzK3xt3U6VkR31A6kACwuECC0w62gnkPaIHVUnoy0c=; b=bH0Tv918BDBJIR8Xzw/iD9BCEicH+U/KEpepPPVAFi5jxGMjg2Dp/yA4iZW2CUqmUUwbnyIbaNGsBpAKiEYacFzaUqd66dH1pKSqedxxhCzIvNRySCDjnYcO06DQmV7oq+oZN65jap6gZdIPbFjt9feeb6FJ8+2jsJMR/NTg1w0= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0149.namprd21.prod.outlook.com (10.173.189.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Fri, 9 Feb 2018 23:35:29 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Fri, 9 Feb 2018 23:35:29 +0000 From: Praveen Balasubramanian To: Ian Swett , huitema CC: "Salz, Rich" , Eric Rescorla , "quic@ietf.org" Subject: RE: hardware offload (was: Packet number encryption) Thread-Topic: hardware offload (was: Packet number encryption) Thread-Index: AQHToeMqYmtt/wnF60OrwLUYIJRfoKOcmxoAgAAYXpA= Date: Fri, 9 Feb 2018 23:35:29 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0149; 7:lnqgjSSkW4JIQiMDcugVcIAAWtERCbfIld1g3DtJCb0dq9BrXSHIW3lhGCJd0PyuCUO5FNrVOgmZ3UE6eSNm1d7ZXfV8L6DJCugOyD2NL6GaUr64QkQuz2KODXhOG7KWzvBhjkiBYthB7tU/ZYgTol1CGn/zQxPdeRT5RlEQYKhzjdVjbQ1Xo6yrwYsVHzbIYDeRbDTwQxW0zDS/k+ceL/2rc4nRwlQLHNM4O24S/GSYLLYYYA/Vuv8gfE+4MTyx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7f59eb76-aaa9-45ad-44bb-08d57015ce08 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0149; x-ms-traffictypediagnostic: CY4PR21MB0149: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(275133514327357)(28532068793085)(89211679590171)(211936372134217)(21748063052155)(47284530071512); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0149; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0149; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39380400002)(346002)(39860400002)(376002)(199004)(189003)(22452003)(6436002)(229853002)(10290500003)(3660700001)(2900100001)(3280700002)(6346003)(86612001)(9686003)(53936002)(236005)(8990500004)(6306002)(55016002)(316002)(10090500001)(102836004)(54896002)(8936002)(105586002)(966005)(7696005)(106356001)(76176011)(6116002)(790700001)(14454004)(81156014)(81166006)(2906002)(74316002)(8676002)(478600001)(5250100002)(53546011)(6506007)(7736002)(68736007)(2950100002)(4326008)(97736004)(86362001)(19609705001)(5660300001)(186003)(99286004)(561944003)(25786009)(93886005)(33656002)(110136005)(606006)(6246003)(54906003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0149; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: JMX28tctei///zQzu5ZxUrdyrP6xPwNR6wtqYHxa245ZW2hJi5+2wC7Q9xKjS9L94Ez4RtUJHRseq5ldl6Yg9A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01337BAE464D5FE1CDE85913B6F20CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7f59eb76-aaa9-45ad-44bb-08d57015ce08 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 23:35:29.4346 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0149 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, 09 Feb 2018 23:35:34 -0000 --_000_CY4PR21MB01337BAE464D5FE1CDE85913B6F20CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaGF2ZSBwcmVjZWRlbmNlIGluIFdpbmRvd3Mgd2l0aCBJUHNlYyB0YXNrIG9mZmxvYWQgd2hp Y2ggaXMgc3ltbWV0cmljIGNyeXB0byBvZmZsb2FkLiBUaGUgZ29hbCBpcyB0byBub3QgaGF2ZSB0 byBtYWtlIHNlcGFyYXRlIEFQSSBjYWxscyB0byBwcm9jZXNzIGNyeXB0by4gVGhlIG1haW4gYWR2 YW50YWdlIG9mIGNyeXB0byBvZmZsb2FkIHJlc3VsdHMgZnJvbSBiZWluZyBhYmxlIHRvIG1ha2Ug aXQgYSBpbmxpbmUgc3RlcCBpbiB0aGUgTklDIHBhY2tldCBwcm9jZXNzaW5nIGVuZ2luZSBhcyBw YXJ0IG9mIHRoZSBkYXRhIHBhdGguIFRoaXMgYWxsb3dzIHlvdSB0byBvZmZsb2FkIG1vcmUgbXVu ZGFuZSBwYWNrZXQgcHJvY2Vzc2luZyB0YXNrcyBnb2luZyBmb3J3YXJkIGxpa2Ugd2UgZG8gd2l0 aCBUQ1AuIFNvbWUgcHJvZ3JhbW1hYmxlIE5JQ3MgbWlnaHQgYmUgYWJsZSB0byBkbyBhIHNlY29u ZCBwYXNzIGJ1dCBJIGFtIG5vdCBhIGhhcmR3YXJlIGV4cGVydCB0byBzYXkgaWYgYWxsIE5JQ3Mg d2lsbCBiZSBhYmxlIHRvLiBUaGVyZSBpcyBwcmVjZWRlbmNlIG9mIHNvbWUgZm9ybSBvZiBoYXJk d2FyZSBjcnlwdG8gb2ZmbG9hZCBmb3IgVENQL1RMUyBib3RoIGFzIGEgc2lkZSBmdW5jdGlvbiBh bmQgaW5saW5lIGluIG5ldHdvcmsgY2FyZC4gU29tZSBsaW5rcyBmcm9tIGEgcXVpY2sgd2ViIHNl YXJjaDoNCmh0dHBzOi8vd3d3LmNoZWxzaW8uY29tL2NyeXB0by1vZmZsb2FkLw0KaHR0cHM6Ly9h d3MuYW1hem9uLmNvbS9kb2N1bWVudGF0aW9uL2Nsb3VkaHNtLw0KaHR0cHM6Ly9uZXRkZXZjb25m Lm9yZy8xLjIvc2Vzc2lvbi5odG1sP2JvcmlzLXBpc21lbm55DQpJIGNhbm5vdCBjb21tZW50IG9u IHdoZXRoZXIgcmVxdWlyaW5nIGFuIGV4dHJhIHBhc3Mgd2lsbCByZW5kZXIgZXhpc3RpbmcgaGFy ZHdhcmUgaW5hcHBsaWNhYmxlIGZvciBRVUlDLiBJIGhhdmUgYmVlbiB0cnlpbmcgaGFyZCB0byBz ZWUgaWYgd2UgY2FuIGF2b2lkIGFuIGV4dHJhIHN0ZXAgcmVnYXJkbGVzcyBvZiBjcnlwdG8gb2Zm bG9hZC4NCg0KRnJvbTogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbV0NClNl bnQ6IEZyaWRheSwgRmVicnVhcnkgOSwgMjAxOCAxOjQ2IFBNDQpUbzogaHVpdGVtYSA8aHVpdGVt YUBodWl0ZW1hLm5ldD4NCkNjOiBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPjsgUHJhdmVl biBCYWxhc3VicmFtYW5pYW4gPHByYXZiQG1pY3Jvc29mdC5jb20+OyBFcmljIFJlc2NvcmxhIDxl a3JAcnRmbS5jb20+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogaGFyZHdhcmUgb2ZmbG9h ZCAod2FzOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24pDQoNCkkgc2hvdWxkIHNheSB0aGF0IEkg ZG9uJ3QgaGF2ZSBhIHNwZWNpZmljIEFQSSwgaW1wbGVtZW50YXRpb24sIG9yIE5JQyBpbiBtaW5k LCBzbyBob3BlZnVsbHkgc29tZW9uZShQcmF2ZWVuPykgY2FuIHByb3ZpZGUgc29tZSBjb250ZXh0 IGFib3V0IHdoYXQgaXMgcG9zc2libGUgd2l0aCBleGlzdGluZyBBUElzIG9yIHdoYXQgaXMgcmVs YXRpdmVseSBlYXN5IHRvIGFkZCB0byB0aGVtLg0KDQpUaGUgQVBJIEkgaGFkIGluIG1pbmQgd2Fz IG9mIHRoZSAiZW5jcnlwdCB0aGlzIGJ5dGUgc3RyaW5nIiBmb3JtLCBidXQgaW4gdGhlIE5JQy4g IGllOiBXaGVuIEkgd3JpdGUgYSBzZXF1ZW5jZSBvZiBwYWNrZXRzIEkgc3VwcGx5IGNyeXB0byBp bmZvLCBhcyB3ZWxsIGFzIGEgbWluaW11bSByZWxlYXNlIHRpbWUob3IgcGFjaW5nIHJhdGUpLiAg VGhlIGdvYWwgaXMgdG8gZG8gdGhlIGJ1bGsgY3J5cHRvIGFzIHRoZSBuZXR3b3JrIHN0YWNrIGlz IHBhY2tldGl6aW5nIGFuZCBjb3B5aW5nIGludG8gdGhlIE5JQyBtZW1vcnkuICBJZGVhbGx5IHRo aXMgY2FuIGF2b2lkIGFuIGV4dHJhIG1lbWNweSBhbmQgYXZvaWRzIHRvdWNoaW5nIHRoZSBkYXRh IHRvIGJlIHNlbnQgdW50aWwgdGhlIGxhc3QgcG9zc2libGUgbW9tZW50Lg0KDQpIYXJkd2FyZSBh Y2NlbGVyYXRpb24gb2YgQUVTIGluIG1vZGVybiBDUFVzIGlzIGV4dHJlbWVseSBnb29kLCBzbyBh bm90aGVyIGFwcHJvYWNoIGlzIHRvIGRvIHRoZSBhYm92ZSBpbiBhIHVzZXJzcGFjZSBuZXR3b3Jr aW5nIHN0YWNrIG9yIHRoZSBrZXJuZWwgYW5kIHVzZSB0aGUgQ1BVJ3MgQUVTIGFjY2VsZXJhdGlv bi4gIElmIHRoZSBuZXR3b3JraW5nIGNvZGUgdGhhdCB3YXMgd3JpdGluZyBpbnRvIE5JQyBtZW1v cnkgaGFkIGEgZGVlcCB1bmRlcnN0YW5kaW5nIG9mIFFVSUMsIHBvc3NpYmx5IGl0IGNvdWxkIGRv IHRoZSBwYWNrZXQgbnVtYmVyIGVuY3J5cHRpb24gYXMgYSBzZWNvbmQgcGFzcz8NCg0KT24gRnJp LCBGZWIgOSwgMjAxOCBhdCAzOjE3IFBNLCBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0 ZW1hLm5ldDxtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldD4+IHdyb3RlOg0KT24gMi85LzIwMTgg ODoyMCBBTSwgSWFuIFN3ZXR0IHdyb3RlOg0KDQo+IE9uZSBpc3N1ZSB3aXRoIHRoZSBjdXJyZW50 IGVuY3J5cHRpb24gcHJvcG9zYWwgaXMgeW91IGNhbid0IHVzZQ0KPiBoYXJkd2FyZSBjcnlwdG8g b2ZmbG9hZCBmb3IgdGhlIGJ1bGsgZW5jcnlwdGlvbiBiZWNhdXNlIHRoZSBwYWNrZXQNCj4gbnVt YmVyIGhhcyB0byBiZSBlbmNyeXB0ZWQgYWZ0ZXIgdGhlIGJ1bGsgZGF0YS4NCj4NCj4gQW55IHN1 Z2dlc3Rpb25zIG9uIGhvdyB0byBmaXggdGhhdD8NCg0KSWFuLCBjb3VsZCB5b3UgYmUgYSBiaXQg bW9yZSBleHBsaWNpdCBhYm91dCB0aGUgdHlwZSBvZiBoYXJkd2FyZSBvZmZsb2FkDQp0aGF0IHlv dSBoYXZlIGluIG1pbmQ/DQoNCkkgY2FuIHRoaW5rIG9mIHR3byBleHRyZW1lIHR5cGVzLiBPbmUg aXMgZW1iZWRkaW5nIGNyeXB0byBvZmZsb2FkIGluIHRoZQ0KTklDLCBhbmQgaXMgZ2VuZXJhbGx5 IHRpZWQgdG8gVENQL1RMUy9UTE8uIFRoYXQgb25lIHR5cGUgaGFzIG5vIGhvcGUNCndoYXRzb2V2 ZXIgb2Ygd29ya2luZyB3aXRoIFVEUC9RVUlDLiBUaGUgb3RoZXIgdHlwZSBpcyBzaW1wbHkgcHJv dmlkaW5nDQphbiAiZW5jcnlwdCB0aGlzIGJ5dGUgc3RyaW5nIiBBUEksIGFuZCBjYW4gYmUgdHJp dmlhbGx5IHVzZWQgd2l0aCBRVUlDDQotLSBtdWNoIGxpa2Ugd2UgY2FuIHVzZSBJbnRlbCdzIEFF UyBleHRlbmRlZCBpbnN0cnVjdGlvbnMgdG9kYXkuIFNvDQpvYnZpb3VzbHkgeW91IGhhdmUgc29t ZXRoaW5nIGVsc2UgaW4gbWluZCwgYW5kIG1heWJlIHlvdSBzaG91bGQgZXhwbGFpbiBpdC4NCg0K LS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0KDQoNCg== --_000_CY4PR21MB01337BAE464D5FE1CDE85913B6F20CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XZSBoYXZlIHByZWNlZGVuY2UgaW4gV2luZG93cyB3aXRoIElQc2VjIHRhc2sgb2ZmbG9hZCB3 aGljaCBpcyBzeW1tZXRyaWMgY3J5cHRvIG9mZmxvYWQuIFRoZSBnb2FsIGlzIHRvIG5vdCBoYXZl IHRvIG1ha2Ugc2VwYXJhdGUgQVBJIGNhbGxzIHRvIHByb2Nlc3MgY3J5cHRvLiBUaGUgbWFpbiBh ZHZhbnRhZ2Ugb2YgY3J5cHRvIG9mZmxvYWQgcmVzdWx0cyBmcm9tIGJlaW5nIGFibGUgdG8gbWFr ZSBpdCBhIGlubGluZQ0KIHN0ZXAgaW4gdGhlIE5JQyBwYWNrZXQgcHJvY2Vzc2luZyBlbmdpbmUg YXMgcGFydCBvZiB0aGUgZGF0YSBwYXRoLiBUaGlzIGFsbG93cyB5b3UgdG8gb2ZmbG9hZCBtb3Jl IG11bmRhbmUgcGFja2V0IHByb2Nlc3NpbmcgdGFza3MgZ29pbmcgZm9yd2FyZCBsaWtlIHdlIGRv IHdpdGggVENQLiBTb21lIHByb2dyYW1tYWJsZSBOSUNzIG1pZ2h0IGJlIGFibGUgdG8gZG8gYSBz ZWNvbmQgcGFzcyBidXQgSSBhbSBub3QgYSBoYXJkd2FyZSBleHBlcnQgdG8NCiBzYXkgaWYgYWxs IE5JQ3Mgd2lsbCBiZSBhYmxlIHRvLiBUaGVyZSBpcyBwcmVjZWRlbmNlIG9mIHNvbWUgZm9ybSBv ZiBoYXJkd2FyZSBjcnlwdG8gb2ZmbG9hZCBmb3IgVENQL1RMUyBib3RoIGFzIGEgc2lkZSBmdW5j dGlvbiBhbmQgaW5saW5lIGluIG5ldHdvcmsgY2FyZC4gU29tZSBsaW5rcyBmcm9tIGEgcXVpY2sg d2ViIHNlYXJjaDo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmNoZWxzaW8uY29tL2NyeXB0by1vZmZsb2FkLyI+aHR0cHM6Ly93d3cuY2hl bHNpby5jb20vY3J5cHRvLW9mZmxvYWQvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9kb2N1bWVudGF0aW9uL2Ns b3VkaHNtLyI+aHR0cHM6Ly9hd3MuYW1hem9uLmNvbS9kb2N1bWVudGF0aW9uL2Nsb3VkaHNtLzwv YT48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8v bmV0ZGV2Y29uZi5vcmcvMS4yL3Nlc3Npb24uaHRtbD9ib3Jpcy1waXNtZW5ueSI+aHR0cHM6Ly9u ZXRkZXZjb25mLm9yZy8xLjIvc2Vzc2lvbi5odG1sP2JvcmlzLXBpc21lbm55PC9hPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjYW5ub3QgY29tbWVudCBvbiB3aGV0aGVy IHJlcXVpcmluZyBhbiBleHRyYSBwYXNzIHdpbGwgcmVuZGVyIGV4aXN0aW5nIGhhcmR3YXJlIGlu YXBwbGljYWJsZSBmb3IgUVVJQy4gSSBoYXZlIGJlZW4gdHJ5aW5nIGhhcmQgdG8gc2VlIGlmIHdl IGNhbiBhdm9pZCBhbiBleHRyYSBzdGVwIHJlZ2FyZGxlc3Mgb2YgY3J5cHRvIG9mZmxvYWQuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IElhbiBTd2V0dCBbbWFpbHRvOmlh bnN3ZXR0QGdvb2dsZS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEZlYnJ1YXJ5IDks IDIwMTggMTo0NiBQTTxicj4NCjxiPlRvOjwvYj4gaHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1h Lm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IFNhbHosIFJpY2ggJmx0O3JzYWx6QGFrYW1haS5jb20m Z3Q7OyBQcmF2ZWVuIEJhbGFzdWJyYW1hbmlhbiAmbHQ7cHJhdmJAbWljcm9zb2Z0LmNvbSZndDs7 IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IGhhcmR3YXJlIG9mZmxvYWQgKHdhczogUGFja2V0IG51bWJlciBl bmNyeXB0aW9uKTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2hvdWxk IHNheSB0aGF0IEkgZG9uJ3QgaGF2ZSBhIHNwZWNpZmljIEFQSSwgaW1wbGVtZW50YXRpb24sIG9y IE5JQyBpbiBtaW5kLCBzbyBob3BlZnVsbHkgc29tZW9uZShQcmF2ZWVuPykgY2FuIHByb3ZpZGUg c29tZSBjb250ZXh0IGFib3V0IHdoYXQgaXMgcG9zc2libGUgd2l0aCBleGlzdGluZyBBUElzIG9y IHdoYXQgaXMgcmVsYXRpdmVseSBlYXN5IHRvIGFkZCB0byB0aGVtLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBBUEkgSSBoYWQgaW4gbWluZCB3YXMg b2YgdGhlICZxdW90O2VuY3J5cHQgdGhpcyBieXRlIHN0cmluZyZxdW90OyBmb3JtLCBidXQgaW4g dGhlIE5JQy4mbmJzcDsgaWU6IFdoZW4gSSB3cml0ZSBhIHNlcXVlbmNlIG9mIHBhY2tldHMgSSBz dXBwbHkgY3J5cHRvIGluZm8sIGFzIHdlbGwgYXMgYSBtaW5pbXVtIHJlbGVhc2UgdGltZShvciBw YWNpbmcgcmF0ZSkuJm5ic3A7IFRoZSBnb2FsIGlzIHRvIGRvIHRoZSBidWxrIGNyeXB0byBhcyB0 aGUNCiBuZXR3b3JrIHN0YWNrIGlzIHBhY2tldGl6aW5nIGFuZCBjb3B5aW5nIGludG8gdGhlIE5J QyBtZW1vcnkuJm5ic3A7IElkZWFsbHkgdGhpcyBjYW4gYXZvaWQgYW4gZXh0cmEgbWVtY3B5IGFu ZCBhdm9pZHMgdG91Y2hpbmcgdGhlIGRhdGEgdG8gYmUgc2VudCB1bnRpbCB0aGUgbGFzdCBwb3Nz aWJsZSBtb21lbnQuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IYXJkd2FyZSBhY2NlbGVyYXRpb24gb2YgQUVTIGluIG1vZGVybiBDUFVzIGlzIGV4dHJlbWVs eSBnb29kLCBzbyBhbm90aGVyIGFwcHJvYWNoIGlzIHRvIGRvIHRoZSBhYm92ZSBpbiBhIHVzZXJz cGFjZSBuZXR3b3JraW5nIHN0YWNrIG9yIHRoZSBrZXJuZWwgYW5kIHVzZSB0aGUgQ1BVJ3MgQUVT IGFjY2VsZXJhdGlvbi4mbmJzcDsgSWYgdGhlIG5ldHdvcmtpbmcgY29kZSB0aGF0IHdhcyB3cml0 aW5nIGludG8gTklDIG1lbW9yeQ0KIGhhZCBhIGRlZXAgdW5kZXJzdGFuZGluZyBvZiBRVUlDLCBw b3NzaWJseSBpdCBjb3VsZCBkbyB0aGUgcGFja2V0IG51bWJlciBlbmNyeXB0aW9uIGFzIGEgc2Vj b25kIHBhc3M/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEZyaSwgRmViIDksIDIwMTggYXQgMzoxNyBQTSwgQ2hyaXN0aWFuIEh1aXRlbWEg Jmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0IiB0YXJnZXQ9Il9ibGFuayI+ aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9uIDIvOS8yMDE4IDg6MjAgQU0s IElhbiBTd2V0dCB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IE9uZSBpc3N1ZSB3aXRoIHRoZSBjdXJy ZW50IGVuY3J5cHRpb24gcHJvcG9zYWwgaXMgeW91IGNhbid0IHVzZTxicj4NCiZndDsgaGFyZHdh cmUgY3J5cHRvIG9mZmxvYWQgZm9yIHRoZSBidWxrIGVuY3J5cHRpb24gYmVjYXVzZSB0aGUgcGFj a2V0PGJyPg0KJmd0OyBudW1iZXIgaGFzIHRvIGJlIGVuY3J5cHRlZCBhZnRlciB0aGUgYnVsayBk YXRhLjxicj4NCiZndDs8YnI+DQomZ3Q7IEFueSBzdWdnZXN0aW9ucyBvbiBob3cgdG8gZml4IHRo YXQ/PGJyPg0KPGJyPg0KSWFuLCBjb3VsZCB5b3UgYmUgYSBiaXQgbW9yZSBleHBsaWNpdCBhYm91 dCB0aGUgdHlwZSBvZiBoYXJkd2FyZSBvZmZsb2FkPGJyPg0KdGhhdCB5b3UgaGF2ZSBpbiBtaW5k Pzxicj4NCjxicj4NCkkgY2FuIHRoaW5rIG9mIHR3byBleHRyZW1lIHR5cGVzLiBPbmUgaXMgZW1i ZWRkaW5nIGNyeXB0byBvZmZsb2FkIGluIHRoZTxicj4NCk5JQywgYW5kIGlzIGdlbmVyYWxseSB0 aWVkIHRvIFRDUC9UTFMvVExPLiBUaGF0IG9uZSB0eXBlIGhhcyBubyBob3BlPGJyPg0Kd2hhdHNv ZXZlciBvZiB3b3JraW5nIHdpdGggVURQL1FVSUMuIFRoZSBvdGhlciB0eXBlIGlzIHNpbXBseSBw cm92aWRpbmc8YnI+DQphbiAmcXVvdDtlbmNyeXB0IHRoaXMgYnl0ZSBzdHJpbmcmcXVvdDsgQVBJ LCBhbmQgY2FuIGJlIHRyaXZpYWxseSB1c2VkIHdpdGggUVVJQzxicj4NCi0tIG11Y2ggbGlrZSB3 ZSBjYW4gdXNlIEludGVsJ3MgQUVTIGV4dGVuZGVkIGluc3RydWN0aW9ucyB0b2RheS4gU288YnI+ DQpvYnZpb3VzbHkgeW91IGhhdmUgc29tZXRoaW5nIGVsc2UgaW4gbWluZCwgYW5kIG1heWJlIHlv dSBzaG91bGQgZXhwbGFpbiBpdC48YnI+DQo8c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+PGJy Pg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+LS0gQ2hyaXN0aWFuIEh1aXRlbWE8L3NwYW4+PGJyPg0K PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB01337BAE464D5FE1CDE85913B6F20CY4PR21MB0133namp_-- From nobody Fri Feb 9 15:37:18 2018 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 EF82F12D862 for ; Fri, 9 Feb 2018 15:37:16 -0800 (PST) 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, 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 EL_JZl0BKUEV for ; Fri, 9 Feb 2018 15:37:14 -0800 (PST) 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 A243E12D865 for ; Fri, 9 Feb 2018 15:37:02 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w19NanpF029624; Fri, 9 Feb 2018 23:37:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=rScc2oX2rRcsW8+OZtN/1VcFUI4K3J+GT1DmB4C7At0=; b=clm/LPt4+sSk4N2gIyKVgfDu9jFuPDQYh8s/dIEMFYE9/k/9A6WAcAwzySNFkz7Q6/Iz mbek4weUaP7s3rNusef0ATQvZnRAwwzWx4oh32LxaOF13JYALCkBuXLrouaT/7XBWwF7 LDB1PAu7oCn1EqN9Gzlg72p6rIiI1JYVcUilNH4X5xhQhzlJF1NxlJ0j0rejyysZZz4i pURzka/6/LkrIeMP6iixzsZVs3NyFgl+nsZ2OQQAhuLtnOL+XDi+cpzJ37AlY/odZqN4 5L11U+NfoABmjQmeeT9emPQQM4Bc0OxB1vLF5O+qEQEEyH5BH82q4hIMvh2OkjPGmnDi eA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2g0x243a7h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2018 23:37:00 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w19Na5on009532; Fri, 9 Feb 2018 18:36:59 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2fyq7b3n67-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2018 18:36:59 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 9 Feb 2018 18:36:58 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Fri, 9 Feb 2018 18:36:58 -0500 From: "Salz, Rich" To: Praveen Balasubramanian CC: "quic@ietf.org" Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31Be9MxlVQxEqrVhXIOG6b4KOM1RYAgABeoICAAAgVAIAAd3KAgAA8YgCAACPDAIAAAicAgAOBloCAALfcgIAACBoAgAEGFwCAANx+AIAAn5GAgAB7xICAADUigIAADBaAgADXOgCAAGaugIAAEEkAgACizACAADhiAIAAHkiAgAADUYCAACdEAIAAVRYAgAAUZgCAAA5oAIAAEIEAgABFkgCAAAUSgIAABUkAgAABmYCAAAaRgIAAC4qAgACi8ACAAe5ygIAACzgAgAAgsACAAEARAIAAiWKAgAA/NwD//61lgIAAbFsA///2toA= Date: Fri, 9 Feb 2018 23:36:58 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.245] Content-Type: multipart/alternative; boundary="_000_E002EFE4528845B2BAF4D9CE0A9DBCC5akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090298 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_13:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=954 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090298 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, 09 Feb 2018 23:37:17 -0000 --_000_E002EFE4528845B2BAF4D9CE0A9DBCC5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBDbGVhciBzZXBhcmF0aW9uIG9mIGNvbmNlcm5zIHJlc3VsdHMgaWYgd2UgZG9u4oCZdCBvdmVy bG9hZCB0aGUgcGFja2V0IG51bWJlciBhcyB0aGUgbm9uY2UuIENvbm5lY3Rpb24gbWlncmF0aW9u IGFuZCBtdWx0aS1wYXRoIGFyZSBvcHRpb25hbCBmZWF0dXJlcyBhbmQgd2UgcGF5IG5vIGV4dHJh IGNvbXB1dGUgY29zdCBmb3IgbW9zdCBjb25uZWN0aW9ucyB0aGF0IGFyZSBub3QgaW1wYWN0ZWQg YnkgdW5sbmthYmlsaXR5LiBOb25jZSBmaWVsZCBiZWNvbWVzIG9wdGlvbmFsIGZvciBjcnlwdG8g dGhhdCBkb2VzbuKAmXQgbmVlZCBpdCBhbmQgY2FuIGdyb3cgdG8gbGFyZ2VyIHNpemUgYXMgbmVl ZGVkIGZvciBidWxrIHRyYW5zZmVycyB0byBwcmV2ZW50IGZyZXF1ZW50IGtleSByb2xsb3ZlcnMg KHNheSBpbiBkYXRhY2VudGVyIHNjZW5hcmlvcykuDQoNCkRhdmlkIGFscmVhZHkgcmVwbGllZCBw cmV0dHkgZGVmaW5pdGl2ZWx5LCBidXQgZm9yIHRob3NlIG5vdCBvbiBoaXMgbGV2ZWwg4oCmDQoN Ckl0IHNlZW1zIGhpZ2hseSB1bmxpa2VseSB0aGF0IHdlIHdpbGwgd2FudCB0byB1c2Ugbm9uLWF1 dGhlbnRpY2F0ZWQgY3J5cHRvIOKAkyBpZS4sIEFFQUQgb3Igc2ltaWxhci4gIFRMUyAxLjMgaXMg YWxsIGFuZCBvbmx5IGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbi4gIFRoZSBkaWZmZXJlbmNlIGlu IGNvc3QgaXMgYSBmZXcgZXh0cmEgYnl0ZXMgb2YgZW5jcnlwdGlvbiwgYXMgb3Bwb3NlZCB0byBi aWdnZXIgcGFja2V0cyBmb3IgcGxhaW50ZXh0IGFuZCB0aGVuIGVuY3J5cHRpbmcgdGhlIG5vbmNl LCByaWdodD8gIFRoYXQgZGlmZmVyZW5jZSBzaG91bGQgYmUgaGFyZCB0byBub3RpY2UuDQoNCklm IHdlIGFzc3VtZSBpdOKAmXMgYWxsIGF1dGhlbnRpY2F0ZWQgY3J5cHRvLCBhbmQgdGhlcmVmb3Jl IHdlIG5lZWQgYSBub25jZSwgdGhlbiBzZXBhcmF0aW9uIG9mIGNvbmNlcm5zIGJlY29tZXMgYSBu b24taXNzdWUuIEluIGZhY3QsIGFzIERhdmlkIHBvaW50ZWQgb3V0LCBhIHBhY2tldCBudW1iZXIg KmV4YWN0bHkqIG1lZXRzIHRoZSByZXF1aXJlbWVudHMgb2YgYW4gYXV0aGVudGljYXRlZCBlbmNy eXB0ZWQgbm9uY2UuIE5vdCB1c2luZyBpdCBmb3IgdGhhdCBwdXJwb3NlIGlzIGJlaW5nIHdhc3Rl ZnVsIGZvciBhYnNvbHV0ZWx5IG5vIGdvb2QgcmVhc29uLg0KDQpEbyB5b3UgaGF2ZSBhIG5vbi1h dXRoZW50aWNhdGVkIGNyeXB0byBtZWNoYW5pc20gd2Ugc2hvdWxkIGNvbnNpZGVyPw0K --_000_E002EFE4528845B2BAF4D9CE0A9DBCC5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8F95C7F0B8E09046A23F03474D7FBA82@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRG NzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IG5hbWU9Il9NYWlsT3JpZ2luYWxCb2R5Ij4mZ3Q7IENsZWFyIHNlcGFyYXRpb24gb2YgY29uY2Vy bnMgcmVzdWx0cyBpZiB3ZSBkb27igJl0IG92ZXJsb2FkIHRoZSBwYWNrZXQgbnVtYmVyIGFzIHRo ZSBub25jZS4gQ29ubmVjdGlvbiBtaWdyYXRpb24gYW5kIG11bHRpLXBhdGggYXJlIG9wdGlvbmFs IGZlYXR1cmVzIGFuZCB3ZSBwYXkgbm8gZXh0cmEgY29tcHV0ZSBjb3N0IGZvciBtb3N0IGNvbm5l Y3Rpb25zIHRoYXQNCiBhcmUgbm90IGltcGFjdGVkIGJ5IHVubG5rYWJpbGl0eS4gTm9uY2UgZmll bGQgYmVjb21lcyBvcHRpb25hbCBmb3IgY3J5cHRvIHRoYXQgZG9lc27igJl0IG5lZWQgaXQgYW5k IGNhbiBncm93IHRvIGxhcmdlciBzaXplIGFzIG5lZWRlZCBmb3IgYnVsayB0cmFuc2ZlcnMgdG8g cHJldmVudCBmcmVxdWVudCBrZXkgcm9sbG92ZXJzIChzYXkgaW4gZGF0YWNlbnRlciBzY2VuYXJp b3MpLg0KPG86cD48L286cD48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpf TWFpbE9yaWdpbmFsQm9keSI+RGF2aWQgYWxyZWFkeSByZXBsaWVkIHByZXR0eSBkZWZpbml0aXZl bHksIGJ1dCBmb3IgdGhvc2Ugbm90IG9uIGhpcyBsZXZlbCDigKY8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWls T3JpZ2luYWxCb2R5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JdCBz ZWVtcyBoaWdobHkgdW5saWtlbHkgdGhhdCB3ZSB3aWxsIHdhbnQgdG8gdXNlIG5vbi1hdXRoZW50 aWNhdGVkIGNyeXB0byDigJMgaWUuLCBBRUFEIG9yIHNpbWlsYXIuJm5ic3A7IFRMUyAxLjMgaXMg YWxsIGFuZCBvbmx5IGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbi4mbmJzcDsgVGhlIGRpZmZlcmVu Y2UgaW4gY29zdCBpcyBhIGZldyBleHRyYSBieXRlcw0KIG9mIGVuY3J5cHRpb24sIGFzIG9wcG9z ZWQgdG8gYmlnZ2VyIHBhY2tldHMgZm9yIHBsYWludGV4dCBhbmQgdGhlbiBlbmNyeXB0aW5nIHRo ZSBub25jZSwgcmlnaHQ/Jm5ic3A7IFRoYXQgZGlmZmVyZW5jZSBzaG91bGQgYmUgaGFyZCB0byBu b3RpY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+SWYgd2UgYXNzdW1lIGl04oCZcyBhbGwgYXV0aGVudGljYXRl ZCBjcnlwdG8sIGFuZCB0aGVyZWZvcmUgd2UgbmVlZCBhIG5vbmNlLCB0aGVuIHNlcGFyYXRpb24g b2YgY29uY2VybnMgYmVjb21lcyBhIG5vbi1pc3N1ZS4gSW4gZmFjdCwgYXMgRGF2aWQgcG9pbnRl ZCBvdXQsIGEgcGFja2V0IG51bWJlciAqPGI+ZXhhY3RseTwvYj4qIG1lZXRzDQogdGhlIHJlcXVp cmVtZW50cyBvZiBhbiBhdXRoZW50aWNhdGVkIGVuY3J5cHRlZCBub25jZS4gTm90IHVzaW5nIGl0 IGZvciB0aGF0IHB1cnBvc2UgaXMgYmVpbmcgd2FzdGVmdWwgZm9yIGFic29sdXRlbHkgbm8gZ29v ZCByZWFzb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+RG8geW91IGhhdmUgYSBub24tYXV0aGVudGljYXRlZCBj cnlwdG8gbWVjaGFuaXNtIHdlIHNob3VsZCBjb25zaWRlcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E002EFE4528845B2BAF4D9CE0A9DBCC5akamaicom_-- From nobody Fri Feb 9 15:56:18 2018 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 A82C0120227 for ; Fri, 9 Feb 2018 15:56:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 rnvhMvuDIqiX for ; Fri, 9 Feb 2018 15:56:15 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 C0F4E120047 for ; Fri, 9 Feb 2018 15:56:15 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id z6so11471195iob.11 for ; Fri, 09 Feb 2018 15:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=6faG7O1r0JhtTsr/7V6RGbv5R0nDMwlZ8cmKWSqZ+Qs=; b=WYRJXheU8czu019v+moZBbNkqd1UmqqWktxtsQDjGKoZiCod5U+DDCZflxyhibNoLA xh43/G3BTzfs9wy5F95kCSU8Zsd4HQ0/V3mDLpD4Snci4j4KFswFv7qVwVyAG2RIy+My EPq1VT48V1C7obd2jMYmIWGRX04TrXGfJD6pT9tu9GU/uwPeZioM29EoA2rFX7bE/2Td qnH6k64As8lR1mykvy+LpO4JrzrEfnqsRIoMbQHlwFh3F6CfUlY+y3DKPLRPl9E8DGOH rApykKI4Eoe+b8wtZawoq/hesBWRV2k/VcQDEqV0pYpniKSd35mtK7jaCcEf2mlPe8w9 d0Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=6faG7O1r0JhtTsr/7V6RGbv5R0nDMwlZ8cmKWSqZ+Qs=; b=UlGSfg+m1es/apQkaeXWROVvvXngv8jHfDY+w6F9dgdZH2dJXz4PNow6xmmugdpNzM 6dxepAaz0Mojzalrlt3v2cH4jK0gbcxoObaavHSqUJfQtvrpEe40XzC7YHL5Dy72XuPR e/NtHzDeCwluq5cdOzdokgogxdRunEcSLljp9cj2uu/8b+xjgUmhUpGZuU3zUlsFcZ4g MPTrZ2BeA3ZtGqeXfovcgu+Dr9Cy6vSgetIhHFePTy7d4CIkCzMPhIfQ2yCzhVZZkgqe E/UcxaouJTiItrwZDH2Pu0D2NzLLH232NzJTtiI3rgorFPnftG2ae+nx0XGGIRMHNfnI 7g2A== X-Gm-Message-State: APf1xPAI6IPfmc/PA7NrizOWAb/oemLTYNNnAErE44vJysXUBPwe40Do WFZAbuYs6m194/R0/U97Agx8XghmPvVpzebGBUk= X-Google-Smtp-Source: AH8x226mNq61r5mhFxgCTWMZyVdAZMdZKEY/QKIp88ldQo86mB1mz9Rz5g1+BIsv3t4JKdIR6AP7cNMYyb3MHiBonXs= X-Received: by 10.107.146.137 with SMTP id u131mr600109iod.96.1518220575087; Fri, 09 Feb 2018 15:56:15 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 9 Feb 2018 15:56:14 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> <1F436ED13A22A246A59CA374CBC543998B58BAD7@ORSMSX111.amr.corp.intel.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 9 Feb 2018 15:56:14 -0800 Message-ID: Subject: RE: Packet number encryption To: David Benjamin , "Deval, Manasi" , Praveen Balasubramanian Cc: Eric Rescorla , huitema , "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c05667a11a1470564d0465e" 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, 09 Feb 2018 23:56:17 -0000 --94eb2c05667a11a1470564d0465e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 9 February 2018 at 22.18.18, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: If we enumerate each half-path with a path ID PID as a simpler counter starting at zero, we have a 1-1 mapping from PID to CID. The packet number PN is then encoded as . The PN is used explicitly and implicitly in ACK frames but is never carried directly on the wire. Using a segment packet number space can also be used to deal with optimistic ACK attacks: Each path is given two connection ID=E2=80=99s which may very just at the l= ower bit. Rather than randomly skipping some packet numbers, a few packets could be sent on the alternative CID. This will introduce gaps but each nonce range remains gapless which keeps the ACK frame defragmented and avoids false loss signals. It does required that CID is present on the wire, but if it is not, a single header bit could be used to imply which of packet number segments is in use. On its own this is not a very attractive ack attack solution, but it may be relevant if packet numbers are segmented, and especially with a v2 multi-path solution. --94eb2c05667a11a1470564d0465e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 9 February 2018 a= t 22.18.18, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:
If we enumerate each h= alf-path with a path ID PID as a simpler counter starting at zero, we have = a 1-1 mapping from PID to CID. The packet number PN is then encoded as <= PID * 2^32 + nonce counter>. The PN is used explicitly and implicitly in= ACK frames but is never carried directly on the wire.
<= /blockquote>

Using a segment packet number space can also be used t= o deal with optimistic ACK attacks:

Each path is given two connection= ID=E2=80=99s which may very just at the lower bit. Rather than randomly sk= ipping some packet numbers, a few packets could be sent on the alternative = CID. This will introduce gaps but each nonce range remains gapless which ke= eps the ACK frame defragmented and avoids false loss signals. It does requi= red that CID is present on the wire, but if it is not, a single header bit = could be used to imply which of packet number segments is in use. On its ow= n this is not a very attractive ack attack solution, but it may be relevant= if packet numbers are segmented, and especially with a v2 multi-path solut= ion.

--94eb2c05667a11a1470564d0465e-- From nobody Fri Feb 9 17:01:43 2018 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 EBB64124F57 for ; Fri, 9 Feb 2018 17:01:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 PBz0YuoatE_J for ; Fri, 9 Feb 2018 17:01:39 -0800 (PST) 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 02778120227 for ; Fri, 9 Feb 2018 17:01:39 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id b204so279480qkg.5 for ; Fri, 09 Feb 2018 17:01:38 -0800 (PST) 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=NaZE0vZX4zDE9SCYtfRHDm8gOpOdhnoENOjEe5o6xOk=; b=qIInt9S0pkjd/T7UNAdRkpwpT+orI2IBcEKrsWIF4rlOrMS2OdhEhTMr3sZnK/cl0C tKOngUucauf2aqex3x1SpJTn4OXtKVfws7NQbN5BHbOGSh0+u56/WHU/iTTmtgAWjOyd uqR79NqahHVcbscaWTbqDq7STPaa37gfwmKgtnslIsM8e381cOIMZRTlx69K74iBs4XY DUIzkIVyDzXC8veX+m88tYIp7/kVCKnnAPdyHieob0Od9TUR+2pqv2fG4p22IZuPO5/d iAD3eZBpCo6ed5evWW00a2iSKcUfSOb4XmYIpdTO25lCSMDg14qWenvpgd/4j4Tf0iT6 lJEA== 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=NaZE0vZX4zDE9SCYtfRHDm8gOpOdhnoENOjEe5o6xOk=; b=W0mJsT8ps0Mg6bzFm4CaX25QnRdC1nHYAhcfoj8/NgGtyNqeMgJ54LVMX4gHqt5kle 5lClVxU8MRLzTIxQua3HmAqkZR3WEIr064nY2rDp/Jgh5jkA6OBVCGMsOiy20Npj2l8M +P0jd/GH9xI7CYcVMOiv32rR03dbkA7ymzLJLHbgUb9ghGgF/PZmQh2pc76aJuEJRuH9 O+pt9CqE7aoiZMEoIuvNhU6cfxIe0REq5m1RZry0tf/jnsmuEeG2qb8TGqJsojeEEWmA pkXGgD+6jBZWgVmCry0AK4ZwaLpaL3SU5WWFXRNwYUuQZU76i9dKcTuNmO+LRoNSXooW NMgA== X-Gm-Message-State: APf1xPATQ0df87sclEIndNl4qsMLhWoj6l7v6psAiMrIp7jchhY1Aru1 nUmST/c+FrvmyIZZPHKWHIEsPWK1PKwSxu3ffZ3G0w== X-Google-Smtp-Source: AH8x2264B8QtJsPMZiV4GDqUZTdSTfhU4z/63uwQ+bOmPgwDgRjRzvkmwMeJc7EOdISzORKr/txR/xjKkMhyxQSkybg= X-Received: by 10.55.27.18 with SMTP id b18mr2477463qkb.355.1518224497859; Fri, 09 Feb 2018 17:01:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.34.132 with HTTP; Fri, 9 Feb 2018 17:01:37 -0800 (PST) In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> From: Victor Vasiliev Date: Fri, 9 Feb 2018 20:01:37 -0500 Message-ID: Subject: Re: Packet number encryption To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Praveen Balasubramanian , "quic@ietf.org" , huitema , Marten Seemann Content-Type: multipart/alternative; boundary="001a1147ed36e327ac0564d12ff0" 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, 10 Feb 2018 01:01:41 -0000 --001a1147ed36e327ac0564d12ff0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Large download case is the case in which the percent of time spent on symmetric crypto is the greatest. As your packets become smaller, non-cryptographic overheads of sending a packet become bigger. On Fri, Feb 9, 2018 at 4:27 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > I am very confused about the 1.25% number. 1280 bytes is about 80 AES > blocks, and one extra block is 1.25% on top of total *encryption* costs > (you don't have to MAC the PN, so that's even cheaper). And the encrypti= on > itself is fairly cheap compared to almost any other part of the QUIC stac= k > (sent packet tracking, ack processing, I/O, timers, etc). > > This is for the large file upload case. It does not consider low latency > applications with small messages and separate cores for different > responsibilities. It also does not consider that that a single block cost= s > the same as 4 blocks on Intel, nor does it consider that the packet canno= t > be decoded in-place. But yes, in the common large file download case, the > cost is not very significant. But it can be significant enough to choose > another protocol in other scenarios. So there needs to be a really good > reason to add this extra latency step. Linkability might be an argument, > and ossification might be too, and the complexity of alternatives might a= s > well. However, I=E2=80=99m not convinced. I=E2=80=99m also not completely= dismissing it, > but I would like to see alternatives explored more thoroughly before > throwing in a cost for no good reason. > > --001a1147ed36e327ac0564d12ff0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Large download case is the case in which the percent of ti= me spent on symmetric crypto is the greatest.=C2=A0 As your packets become = smaller, non-cryptographic overheads of sending a packet become bigger.
=

On Fri, Feb 9, 20= 18 at 4:27 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com&= gt; wrote:
I = am very confused about the 1.25% number.=C2=A0 1280 bytes is about 80 AES b= locks, and one extra block is 1.25% on top of total *encryption* costs (you= don't have to MAC the PN, so that's even cheaper).=C2=A0 And the e= ncryption itself is fairly cheap compared to almost any other part of the Q= UIC stack (sent packet tracking, ack processing, I/O, timers, etc).

This is for= the large file upload case. It does not consider low latency applications = with small messages and separate cores for different responsibilities. It a= lso does not consider that that a single block costs the same as 4 blocks o= n Intel, nor does it consider that the packet cannot be decoded in-place. B= ut yes, in the common large file download case, the cost is not very signif= icant. But it can be significant enough to choose another protocol in other= scenarios. So there needs to be a really good reason to add this extra lat= ency step. Linkability might be an argument, and ossification might be too,= and the complexity of alternatives might as well. However, I=E2=80=99m not= convinced. I=E2=80=99m also not completely dismissing it, but I would like= to see alternatives explored more thoroughly before throwing in a cost for= no good reason.


--001a1147ed36e327ac0564d12ff0-- From nobody Fri Feb 9 17:06:47 2018 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 887C4126CBF for ; Fri, 9 Feb 2018 17:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 DngvVI0F-DZj for ; Fri, 9 Feb 2018 17:06:43 -0800 (PST) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 CAF3B124F57 for ; Fri, 9 Feb 2018 17:06:43 -0800 (PST) Received: by mail-pl0-x22f.google.com with SMTP id t4so2250616plo.0 for ; Fri, 09 Feb 2018 17:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=IXrD3roRNq/PryUMIfenCL6iguOUR6/KKDPkJnwX+10=; b=TTmg6XQ8oQfsAYyu1QLTzl7x6+AccOJ3QAS4xuOkE3r5JbNsls3MUTgZQDQjmg4nIw TDr3iI3KusqWJ7SR6MODQhyBAwK5EWLKQWEpIsQCw/PXdMOwKwVazL7R3ZCE3Ocf/I3h 2V/Cmu26iAbCftrqDYA04bXDv9tzMbikfSZaLHW2/yYtTVHcvuw1eVF3KedNrcqlVozO Efr4XWkY6JUyucuez0mXNVRO0KdimH2Vl+kpgCGZApBb1cmCx/qqTpV5GDZoJe+CLq7/ IftkbtY/4H1oEHdD2rTwPScBQVTgoI/OA9wKjY8prsvmcdfQ2p9EBWHziTnyTaxMVYIq iJxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=IXrD3roRNq/PryUMIfenCL6iguOUR6/KKDPkJnwX+10=; b=YWX+G0XHCksFX1vGwRGYeFR6sijKw9uS2nQQ4EJP0C1Bn8R/w+purAMF+NU8fgpnsx VF6VlshJ+PrXRlk9e3MAnjmyQ5FUtIYTucVltEYsGJJTqGxWeBh3QaVWnoYimUYO0X7r vXhc8vH0/Dad5mVPJsBnYsCsk9/NH+g3M5Wq8HjIBPyQtDwRD+otYIf9KwLB845KJWqQ /5dXY207JNMzSO9yAjtZFxH+5q14LH12KVFxo0ah39lzFlsRw0ghcjAqVi+Ja8Yghcnw lJmqd7pkf0vTvhoM0UFghkgcMkgnNelLX6oEUSvaKyuFV34yC9/1fMPpargFye5HyNDG RdVA== X-Gm-Message-State: APf1xPCk7175EcbHWYK3T9cbyv1NSWerB5CwXgvYMjwKLF/StOXomn1F MSvCwgEjY5W3+5XXukhiKNXtNZ9EKQo= X-Google-Smtp-Source: AH8x226GKpLhwgXjIwKODe4MMjVZj9oqq+5RSOtZKzHcUPy0W/UfsnLAV5ip8mc2LlPG4MQgvcMWiw== X-Received: by 2002:a17:902:7486:: with SMTP id h6-v6mr4271756pll.236.1518224803028; Fri, 09 Feb 2018 17:06:43 -0800 (PST) Received: from Justins-MacBook-Pro.local (tk2-262-40902.vs.sakura.ne.jp. [160.16.241.156]) by smtp.gmail.com with ESMTPSA id z125sm8055502pfz.27.2018.02.09.17.06.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Feb 2018 17:06:42 -0800 (PST) Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Kazuho Oku Cc: Martin Thomson , "quic@ietf.org" References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> From: Lingmo Zhu Message-ID: <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> Date: Sat, 10 Feb 2018 09:06:38 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C161A067F8A746B5DFD645AE" Content-Language: en-US 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, 10 Feb 2018 01:06:45 -0000 This is a multi-part message in MIME format. --------------C161A067F8A746B5DFD645AE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit IMHO we can see that such interference is pretty easy to be used and it could leading to aborted QUIC connection and probably a fallback to any old approach for higher level protocol. Even virus targeting home routers could do that, without gov involved. For what outcome, I think it's pretty simple: forcing higher level protocol fallback to other transport protocol. Since QUIC has been designed much more secure than older protocols, it could be hard to do some eavesdropping or hijacking. But if fallback happens, it would be another story. Considering DNS over QUIC, a virus-infected home router could interfere with QUIC handshake cause fallback to TLS, then RST may cause fallback to clear text, which is easy to be hijacked and leads client to some phishing site. On 2018/02/09 19:56, Mikkel Fahnøe Jørgensen wrote: > A realistic on-path attack involves a government body that taps optic > fiber at an internet distribution node. The original intention behind > the construct may be to trigger an alarm whenever the string “dirty > bomb” appears in a protocol RFC 821 message (such as this one), and > subsequently for logging purposes to monitor traffic directed towards > bulk fertiliser suppliers. It is not possible to drop packets both due > to the mechanical construct, due to legislation, and because it might > be too obvious. However, having a datacenter with optic fibre near > said access point gives excellent insights into early handshakes > including IP, port, connection ID, and possible even a profile of the > PRNG being used at some endpoint. > > This makes it very simple to spoof and inject packets into handshake > with a good chance of winning any race. More difficult, but possible, > it could also observe packets and inject packets closer to the > endpoint, for example using long distance point to point radio > communication to race the ordinary packet stream. > > Any argument about friendly gov is void because the internet travels > across multiple regions that each with near certainty have taps as > those described above making it a prime target in cyber warfare. > > The question is then to what extend such a position can be utilised to > interfere with the handshake and what the outcome of such interference > would be, rather than a discussion of how plausible such an attack is, > because it is probably a 99% given if feasible. --------------C161A067F8A746B5DFD645AE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

IMHO we can see that such interference is pretty easy to be used and it could leading to aborted QUIC connection and probably a fallback to any old approach for higher level protocol. Even virus targeting home routers could do that, without gov involved. For what outcome, I think it's pretty simple: forcing higher level protocol fallback to other transport protocol. Since QUIC has been designed much more secure than older protocols, it could be hard to do some eavesdropping or hijacking. But if fallback happens, it would be another story. Considering DNS over QUIC, a virus-infected home router could interfere with QUIC handshake cause fallback to TLS, then RST may cause fallback to clear text, which is easy to be hijacked and leads client to some phishing site.


On 2018/02/09 19:56, Mikkel Fahnøe Jørgensen wrote:
A realistic on-path attack involves a government body that taps optic fiber at an internet distribution node. The original intention behind the construct may be to trigger an alarm whenever the string “dirty bomb” appears in a protocol RFC 821 message (such as this one), and subsequently for logging purposes to monitor traffic directed towards bulk fertiliser suppliers. It is not possible to drop packets both due to the mechanical construct, due to legislation, and because it might be too obvious. However, having a datacenter with optic fibre near said access point gives excellent insights into early handshakes including IP, port, connection ID, and possible even a profile of the PRNG being used at some endpoint.

This makes it very simple to spoof and inject packets into handshake with a good chance of winning any race. More difficult, but possible, it could also observe packets and inject packets closer to the endpoint, for example using long distance point to point radio communication to race the ordinary packet stream.

Any argument about friendly gov is void because the internet travels across multiple regions that each with near certainty have taps as those described above making it a prime target in cyber warfare.

The question is then to what extend such a position can be utilised to interfere with the handshake and what the outcome of such interference would be, rather than a discussion of how plausible such an attack is, because it is probably a 99% given if feasible.

--------------C161A067F8A746B5DFD645AE-- From nobody Fri Feb 9 21:17:42 2018 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 5A25A1241F8 for ; Fri, 9 Feb 2018 21:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nx7dNsA0qJi7 for ; Fri, 9 Feb 2018 21:17:38 -0800 (PST) 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 CD343126D85 for ; Fri, 9 Feb 2018 21:17:37 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx37.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ekF8S-0005F7-8K for quic@ietf.org; Fri, 09 Feb 2018 21:19:04 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ekF8Q-00083Y-Hm for quic@ietf.org; Fri, 09 Feb 2018 15:19:03 -0500 Received: (qmail 12169 invoked from network); 9 Feb 2018 20:17:53 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 9 Feb 2018 20:17:53 -0000 To: Ian Swett , "Salz, Rich" Cc: Praveen Balasubramanian , Eric Rescorla , "quic@ietf.org" References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> From: Christian Huitema Message-ID: Date: Fri, 9 Feb 2018 10:17:52 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: hardware offload (was: Packet number encryption) X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.24) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5naFvUnYQ8IAcp/fhsd9wscXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fv4i5bWdaOOh35Q+kHQgHYIB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXsyb8kPdw8E5fjseDcUSkOjZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XSWizyN/9VXiZ4elFzVDIjrsNHLD5iuK9LgA8bTWyd hYAA0yJvEM53nPrTZ5aF1kRZ0VwEd+iNUj65ezw/iijHw95cPWLsHiU6tFs2fFlaJuRMyksc0Dx4 iQa9AzGuG3nTPpuFqUUQz+mM8JAD4ECW5KgQQDk8tyKC/NeBLLoliqf4b0gaZx7Nq9QqOn1O3qTO G/srEDYAbd+JkBf9HkwTR4B44azPcrply6nBgbVn7CG7X+t1TW39Ja77LGPpOwDCYR4kEX6t994C WVS20AAh62+cNv80wh1h7LzKSJ1PRVAxXqQU4SUCmX1X8Fu4HDGTJ7q4QftjYVRI4vivMj6DQk2H BukllN/eBZD4GGbFsCT/dtMIs/LqOU9hZ/v31oRzg7QgpumQxgT4IcKeAlfy/bB/laLK9WZp+I7d gzC3lLdvK/cKOEqlCIPGIfYQDNKLLI6rY1d8Qdsix0hWyXbo 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: Sat, 10 Feb 2018 05:17:40 -0000 On 2/9/2018 8:20 AM, Ian Swett wrote: > One issue with the current encryption proposal is you can't use > hardware crypto offload for the bulk encryption because the packet > number has to be encrypted after the bulk data. > > Any suggestions on how to fix that? Ian, could you be a bit more explicit about the type of hardware offload that you have in mind? I can think of two extreme types. One is embedding crypto offload in the NIC, and is generally tied to TCP/TLS/TLO. That one type has no hope whatsoever of working with UDP/QUIC. The other type is simply providing an "encrypt this byte string" API, and can be trivially used with QUIC -- much like we can use Intel's AES extended instructions today. So obviously you have something else in mind, and maybe you should explain i= t. -- Christian Huitema From nobody Fri Feb 9 21:18:29 2018 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 87578126DCA for ; Fri, 9 Feb 2018 21:18:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 Xh9AeSLvIB0t for ; Fri, 9 Feb 2018 21:18:26 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e: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 335121242EA for ; Fri, 9 Feb 2018 21:18:26 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id o1so4976400pgn.4 for ; Fri, 09 Feb 2018 21:18:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=J0zmta5W0WErY3KUTp0sJ0mp660zMhEXB/w5YhppEzw=; b=u/XgubHEhn1rqLOrrwkmpNku7++qGgh6VhkmKJzy95ITa/vqQaAmYUsUvNuNtupv9p ps6UOkMVdnV6x/mACDhGlKR13K+oMWx10Y6niY4xLEjLuQq7HtKm4jZ9moHwWiRG2SFy 3vyJ4qeieXZeUw7ya4bUIogHZk8/ZxnMPe60WedVdRycJ6slJdDjjBECAGoIBYTby1tu ilb5kcx76p9O24v+8H3yMUpkAzHJmxhJa1PcIrF5icM4dp/srmRbCv/i2ma+RL8unwsz /R/gvFbRl59jEzeouKokgTi5p6Pv3IdAQnTxEcePEMKGqo5mpIVzO3YlSm58Ti1hKs0Y ScRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=J0zmta5W0WErY3KUTp0sJ0mp660zMhEXB/w5YhppEzw=; b=cpIMhg3j2yNWP0mp6eTKMPoO6tc9JFzfj5Qfu3dMnyqxJu/BAwtEtbjSYGYchtjnaJ KHRs1SkFDbps2Gag3ddzQT+Ql3htImiT9DPD9nciLBU45PjKFuQY9S74y8RrLKgAwy5Q yzamzM3TyuZQjfMU1MhUACc9DwTxymKKngs7FVxxoOGW3/knQH1GKlromsn0oWSeqoNc Nesxs6W8SE3ERTESWf0+TqvLjZNx1IjfsneB0yqi7rNuARn3VKdvidLgkXkPKkNlTJIy 6rNmzo41UXB62w879PTIM40yUt0nXUWr8tAzgHK/PKgABqtHeGsNAmHHszlqt5u14VXm RjSA== X-Gm-Message-State: APf1xPCSX38YRfksfK/N0Ef+gavmZcaqe+lyumX/qLtjWks3FArNTIl4 tm8jtqm+DdW81nQ5frdxm9w= X-Google-Smtp-Source: AH8x226SHVuiSCb895Knf4juclCTkShkUu8TGwgQNOsLiDlC1LUa5n61W9WEnMU2+A4LaSc+LGLq3A== X-Received: by 10.101.97.5 with SMTP id z5mr4186360pgu.270.1518239905758; Fri, 09 Feb 2018 21:18:25 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id 27sm17984498pfj.173.2018.02.09.21.18.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 09 Feb 2018 21:18:25 -0800 (PST) From: =?Windows-1252?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Victor Vasiliev CC: Praveen Balasubramanian , "quic@ietf.org" , huitema , Marten Seemann Subject: Re: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AdOiC23yPjuHQYOq5U2Xo3VH04y7gAAIyLPn X-MS-Exchange-MessageSentRepresentingType: 2 Date: Sat, 10 Feb 2018 05:18:20 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB176692436653B08C1CA949C2ACF10DB6PR10MB1766EURP_" 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: Sat, 10 Feb 2018 05:18:28 -0000 --_000_DB6PR10MB176692436653B08C1CA949C2ACF10DB6PR10MB1766EURP_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 98ns for 68 byte messages https://www.solarflare.com/solarflare-lda-penguin-unleash-ultimate-trading-= machine-stac-t0-benchmark ________________________________ From: Victor Vasiliev Sent: Saturday, February 10, 2018 2:01:37 AM To: Mikkel Fahn=F8e J=F8rgensen Cc: Praveen Balasubramanian; quic@ietf.org; huitema; Marten Seemann Subject: Re: Packet number encryption Large download case is the case in which the percent of time spent on symme= tric crypto is the greatest. As your packets become smaller, non-cryptogra= phic overheads of sending a packet become bigger. On Fri, Feb 9, 2018 at 4:27 PM, Mikkel Fahn=F8e J=F8rgensen > wrote: I am very confused about the 1.25% number. 1280 bytes is about 80 AES bloc= ks, and one extra block is 1.25% on top of total *encryption* costs (you do= n't have to MAC the PN, so that's even cheaper). And the encryption itself= is fairly cheap compared to almost any other part of the QUIC stack (sent = packet tracking, ack processing, I/O, timers, etc). This is for the large file upload case. It does not consider low latency ap= plications with small messages and separate cores for different responsibil= ities. It also does not consider that that a single block costs the same as= 4 blocks on Intel, nor does it consider that the packet cannot be decoded = in-place. But yes, in the common large file download case, the cost is not = very significant. But it can be significant enough to choose another protoc= ol in other scenarios. So there needs to be a really good reason to add thi= s extra latency step. Linkability might be an argument, and ossification mi= ght be too, and the complexity of alternatives might as well. However, I=92= m not convinced. I=92m also not completely dismissing it, but I would like = to see alternatives explored more thoroughly before throwing in a cost for = no good reason. --_000_DB6PR10MB176692436653B08C1CA949C2ACF10DB6PR10MB1766EURP_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
98ns for 68 byte messages

https://www.solarflare.com/solarflare-lda-peng= uin-unleash-ultimate-trading-machine-stac-t0-benchmark

From: Victor Vasiliev <v= asilvv@google.com>
Sent: Saturday, February 10, 2018 2:01:37 AM
To: Mikkel Fahn=F8e J=F8rgensen
Cc: Praveen Balasubramanian; quic@ietf.org; huitema; Marten Seemann<= br> Subject: Re: Packet number encryption
 
Large download case is the case in which the percent of ti= me spent on symmetric crypto is the greatest.  As your packets become = smaller, non-cryptographic overheads of sending a packet become bigger.

On Fri, Feb 9, 2018 at 4:27 PM, Mikkel Fahn=F8e = J=F8rgensen <mikkelfj@gmail.= com> wrote:
I am very confused about the 1.25% number.  1280 bytes is about 8= 0 AES blocks, and one extra block is 1.25% on top of total *encryption* cos= ts (you don't have to MAC the PN, so that's even cheaper).  And the en= cryption itself is fairly cheap compared to almost any other part of the QUIC stack (sent packet tracking, ack process= ing, I/O, timers, etc).

This is for the large file upload case. It does not consider low latency= applications with small messages and separate cores for different responsi= bilities. It also does not consider that that a single block costs the same= as 4 blocks on Intel, nor does it consider that the packet cannot be decoded in-place. But yes, in the co= mmon large file download case, the cost is not very significant. But it can= be significant enough to choose another protocol in other scenarios. So th= ere needs to be a really good reason to add this extra latency step. Linkability might be an argument, and ossi= fication might be too, and the complexity of alternatives might as well. Ho= wever, I=92m not convinced. I=92m also not completely dismissing it, but I = would like to see alternatives explored more thoroughly before throwing in a cost for no good reason.


--_000_DB6PR10MB176692436653B08C1CA949C2ACF10DB6PR10MB1766EURP_-- From nobody Fri Feb 9 22:25:08 2018 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 DA1EB1241F8 for ; Fri, 9 Feb 2018 22:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CPecPpRRe_2 for ; Fri, 9 Feb 2018 22:25:04 -0800 (PST) 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 9E3361241F3 for ; Fri, 9 Feb 2018 22:25:03 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx1.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1ekOan-00086I-FF for quic@ietf.org; Sat, 10 Feb 2018 07:24:58 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ekOak-00078q-9m for quic@ietf.org; Sat, 10 Feb 2018 01:24:55 -0500 Received: (qmail 17383 invoked from network); 10 Feb 2018 06:24:44 -0000 Received: from unknown (HELO [192.168.200.68]) (Authenticated-user:_huitema@huitema.net@[72.235.171.77]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 10 Feb 2018 06:24:44 -0000 To: Lingmo Zhu , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Kazuho Oku Cc: "quic@ietf.org" , Martin Thomson References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> From: Christian Huitema Message-ID: <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> Date: Fri, 9 Feb 2018 20:24:42 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.30) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5imXPLxlWTMvok0sQ9ot8bAXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fu6v+gany42dBpcnupRv2zDB98yDTitFWvbHwz9vKZpm3I5 mq5AFk9iXeoOoZGPBgSZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyZFjIToX6GLbbHCBsyyfoCLFQwbgMCItJaYYOhQRv6/ UGvez0tiveIVkxvydwTaUEvh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3Goyp65o39wd3xyIqswrw4YJnHEeB4hpRrmo/duzUUp/Le F+ZXED8J4mkrkZhP7Gp/UG6J3KZkZnCUxiuNwn8fB3LYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+0EF5F4XJDGest21JnLKg8Ij2lB9TLiDMfXuvSrucRXpoVg5fOhUS7LnGpWowDQkTpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g 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: Sat, 10 Feb 2018 06:25:07 -0000 On 2/9/2018 3:06 PM, Lingmo Zhu wrote: > > IMHO we can see that such interference is pretty easy to be used and > it could leading to aborted QUIC connection and probably a fallback to > any old approach for higher level protocol. Even virus targeting home > routers could do that, without gov involved. For what outcome, I think > it's pretty simple: forcing higher level protocol fallback to other > transport protocol. Since QUIC has been designed much more secure than > older protocols, it could be hard to do some eavesdropping or > hijacking. But if fallback happens, it would be another story. > Considering DNS over QUIC, a virus-infected home router could > interfere with QUIC handshake cause fallback to TLS, then RST may > cause fallback to clear text, which is easy to be hijacked and leads > client to some phishing site. > In theory, it should be possible to protect against "man on the side" attacks. Do some kind of speculative execution on the first packet that you receive, but also keep the context available for some time in case a "better" packet comes later. With that approach, the attacker could not just inject a "packet of death"; they will also need to suppress the correct response from the actual server. That's an interesting idea. Have you tried some experiments? -- Christian Huitema From nobody Sat Feb 10 00:34:50 2018 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 094A71274D2 for ; Sat, 10 Feb 2018 00:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 F2MB69bFJ09j for ; Sat, 10 Feb 2018 00:34:47 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F081243F6 for ; Sat, 10 Feb 2018 00:34:46 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 0C12921253; Sat, 10 Feb 2018 09:34:45 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id DFD481A0054; Sat, 10 Feb 2018 09:34:44 +0100 (CET) Received: from lat6466.rd.francetelecom.fr (10.168.234.4) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 10 Feb 2018 09:34:44 +0100 Message-ID: <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> Date: Sat, 10 Feb 2018 09:34:45 +0100 From: Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Christian Huitema CC: Lingmo Zhu , =?ISO-8859-1?Q?Mikkel_Fahn=F8e_J=F8?= =?ISO-8859-1?Q?rgensen?= , Kazuho Oku , "quic@ietf.org" , Martin Thomson Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> In-Reply-To: <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.4] 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, 10 Feb 2018 08:34:48 -0000 On 10/02/2018 07:24, Christian Huitema wrote: > > > On 2/9/2018 3:06 PM, Lingmo Zhu wrote: >> >> IMHO we can see that such interference is pretty easy to be used and >> it could leading to aborted QUIC connection and probably a fallback to >> any old approach for higher level protocol. Even virus targeting home >> routers could do that, without gov involved. For what outcome, I think >> it's pretty simple: forcing higher level protocol fallback to other >> transport protocol. Since QUIC has been designed much more secure than >> older protocols, it could be hard to do some eavesdropping or >> hijacking. But if fallback happens, it would be another story. >> Considering DNS over QUIC, a virus-infected home router could >> interfere with QUIC handshake cause fallback to TLS, then RST may >> cause fallback to clear text, which is easy to be hijacked and leads >> client to some phishing site. >> > > In theory, it should be possible to protect against "man on the side" > attacks. Do some kind of speculative execution on the first packet that > you receive, but also keep the context available for some time in case a > "better" packet comes later. With that approach, the attacker could not > just inject a "packet of death"; they will also need to suppress the > correct response from the actual server. That's an interesting idea. > Have you tried some experiments? Alternatively, what about a "no fallback" mode for sensitive applications like DNS ? _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Sat Feb 10 00:48:52 2018 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 1F5BC126DEE for ; Sat, 10 Feb 2018 00:48:51 -0800 (PST) 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 gtQW3PKvxUwJ for ; Sat, 10 Feb 2018 00:48:49 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 78BD7124234 for ; Sat, 10 Feb 2018 00:48:49 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id 73so9919798oti.12 for ; Sat, 10 Feb 2018 00:48:49 -0800 (PST) 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=iuDjdtyhvEbgzYbji20c/dPh2nEtmF02gU6A8O7a4CA=; b=Kkio3fKihmY3m0cAJZjstr41NkSgUt7V+tA1Cv+4w/l7tmphudefMuhk/W2RNZ/+u6 GnqVRgFjfPGNbgIRK5nHSCiMzH1phV8EwlFJdhNxAPXc4+9h10KdbaHuPzEyIB0OWPxy FOMcZTis1CkwS7BazRmhjvW+YGIFVNxbGnyC8Jk0P5FNIQLuFvxKxUTf5gB7Fh24+AhC 8ISNhMlPvn5uxGMYZTxgiRjSbHBvV2G4kfO466/EWg0WmaEl9b09b01BI5ATUCNo5amG 0Fra4WhvFYTrfohtD06Uekn9G/4hlCKCSS35n/owvmwHnmhRpls0IM1cf1aUSv9XL23Y ULtw== 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=iuDjdtyhvEbgzYbji20c/dPh2nEtmF02gU6A8O7a4CA=; b=LwrGL19L1VXBTbW/IbDS6KBzIeAyZdQQqqePVIUSeUqhGul8Sn8nwPfGx/A6ZPg/rk 9kBuA7do+0proPbcHIw4eLDfsaot5PEoHHU+/ICPO3fbRDGP79sKeyiYrUgYIYHIB8x+ eGhybxz3Z9ZABFA74pSDXjVK07HObVhL8xS5Azbfqsysv0Fs6/GsX2G3v0uMZmZP0yaW y72kTV3b5k6NiV6THuWyTj7ajh4KbivmbFkxqrIsoI7qztJnWdHea8QZnKPyuKh7+sbc eQhvDAP4FspNyqIO+q9azMxi1d5J5Nl+8xRbsz8yEFPMUOmJdTrrcoyHhee2SeuJPU7+ JxXg== X-Gm-Message-State: APf1xPDW73f/fk53jsXbgPK3EbQ5j6WpwoK7sfKy1Z6I8a5USc6rIbv5 PhSrOOJ2ulLyeKj6JM2n84mBeqCazgYN789KEX4= X-Google-Smtp-Source: AH8x224fR5eqWEYY7wqzH8ncBowVYooWUKqSbmo3SidaLKnHFNb9LsLGoqKjbVuOcILhM+fZdBIyzzb8jTGZzsa8+ck= X-Received: by 10.157.36.137 with SMTP id z9mr4178944ota.175.1518252528627; Sat, 10 Feb 2018 00:48:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Sat, 10 Feb 2018 00:48:48 -0800 (PST) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAD6C5A@bgb01xud1012> From: Martin Thomson Date: Sat, 10 Feb 2018 19:48:48 +1100 Message-ID: Subject: Re: Review of QCRAM To: "Charles 'Buck' Krasic" Cc: Mike Bishop , Lucas Pardue , 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: Sat, 10 Feb 2018 08:48:51 -0000 On Sat, Feb 10, 2018 at 9:22 AM, Charles 'Buck' Krasic wrote: > On blocked evictions. > > a) there's a real possibility that setting table size to 64KB is the most > elegant solution, because evictions may not happen for the vast majority of > connections. > Perhaps something along these lines is worth mentioning (in section 4?). Setting a higher limit just delays things (or makes them much more unlikely). It's not a real solution, unless you think that throwing away the connection or suffering compression degradation is preferable to using duplication. > b) if not it should be possible to prevent blocked evictions using indexed > duplicates (Section 3.5), I can think of a couple of complementary policies > that might be useful: > > based on index, duplicate if the encoder emits a reference that is (getting > close to) the threshold where the HPACK instruction size jumps from 1 to 2 > bytes. (I'm feeling too lazy to figure this out precisely, but I think it > is when the HPACK relative index is getting close to 128). this practice > also benefits compression ratio independent of evictions. > based on dynamic table fill. duplicate if the encoder the cumulative number > of bytes for the referenced entry (the size of the entry and all newer > entries in the table) is more than some threshold (e.g. 80% of table > capacity). I have implemented the latter, and though I don't have a lot of tests to confirm it, it seems to work. The threshold is tunable (I covered this point in the OP). > Neither of the above works if you have an entry that sits in the table > un-referenced until it is time to evict. My intuition is such a scenario > should not arise in practice. Not sure why you would be concerned about this. That would only happen if you speculatively added things to the table. Possible, but probably not that useful. Nor is this really a problem aside from the opportunity cost, which could be zero anyway. From nobody Sat Feb 10 00:56:46 2018 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 647921274D2 for ; Sat, 10 Feb 2018 00:56:45 -0800 (PST) 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 pcmvAYtssCgD for ; Sat, 10 Feb 2018 00:56:43 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 AD8FE124234 for ; Sat, 10 Feb 2018 00:56:43 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id 24so7834562oij.3 for ; Sat, 10 Feb 2018 00:56:43 -0800 (PST) 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=qM/7DWm5DvjhrnypXXlMDRVB9OHUsIKlhrqMqxzlquE=; b=gHXYuNuViUzgi7YRw0wHdXlVghVO/edyLTDJ0/yo7mkmnk1io+aeTYpIENKbXLbZ0P cRvzNfpHrw5kEi5K4UeA7L4rcoGaj2GoX1SIq584A1LlqwKGuRW2+0/vBNbCrLhp3UCA AxpGNmTV92jH2WwankCTNeXGZWGEH8yjxcnfLaWE2mNwk7Z5EhJuWhPZ95Tghe+54Wf7 x7tA1tLzwUo889h0ejv423BFNRb4CWmfFZA2+BJiY2BflugYpi4OVF7OYwBMYI+KibVD 7cRHJtiZ79myKZk+NeS6RkP+5IjGaELPyNnz7YfqC2J8Je6vAuNZD11FrmVV8hkwj3Ts B9mw== 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=qM/7DWm5DvjhrnypXXlMDRVB9OHUsIKlhrqMqxzlquE=; b=SYHT9z4q3VRWRPYPnmjoEM9AL+bROFA/Pqe/BQddjfQ6mECt2ZvqIVnM2gVGzs6m94 MZ0Z+J1HzmrwrppaZwfh6tPok5uk43Ui2YIuKeYbMFr6ZuDWbTGG1+zstT2iGGkpmKJ9 MjqDhzssDR2KSG5A2afBEx5PMRklZOxlFMc+KjSKnKI5J0ZSWqk0cvDdyuCCHN80wwF3 eBfwKuxx5Id99s4u0lWnqkKVsD5p+l2hIrVfVh8qj7FhdkhHF9XtaOH5RrfI2hSFO3tq Gjg3/3SP3b7D8480XNQBFj3i4GCZO3iR7isEw+YOk+aUwtfiF1q19Br0ZPZpWkfZRKQv Q92A== X-Gm-Message-State: APf1xPCFupDMcl4enB07JwLROd+9jJYPV3i7lpkVA7AQgptnt9MIcMlh zQ+Mtyl6Eq1mJvLo1RFNOdP0+AuYnrzPE6Xt5sA= X-Google-Smtp-Source: AH8x226yihTp5VoVPaEHbrsjRNC3uWQyQ6bHS4WA4aUg+LEwqHbv+ZpyI3YNnNAKLtaZuv7lk8hc9Arm2iM7NurkwaI= X-Received: by 10.202.184.4 with SMTP id i4mr3370888oif.273.1518253002954; Sat, 10 Feb 2018 00:56:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Sat, 10 Feb 2018 00:56:42 -0800 (PST) In-Reply-To: <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> From: Martin Thomson Date: Sat, 10 Feb 2018 19:56:42 +1100 Message-ID: Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: alexandre.ferrieux@orange.com Cc: Christian Huitema , Lingmo Zhu , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Kazuho Oku , "quic@ietf.org" 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: Sat, 10 Feb 2018 08:56:45 -0000 On Sat, Feb 10, 2018 at 7:34 PM, wrote: > Alternatively, what about a "no fallback" mode for sensitive applications > like DNS ? If versioning were strictly linear, you could do as we do for TLS and remember that server X supported version Y and ignore any version negotiation from X that claimed to support only Y-1. That's not necessarily an ideal outcome, but you can do that. From nobody Sat Feb 10 01:00:12 2018 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 E4B19124234 for ; Sat, 10 Feb 2018 01:00:10 -0800 (PST) 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, 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 BNR1LCrdAb_x for ; Sat, 10 Feb 2018 01:00:08 -0800 (PST) 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 CAEC6127867 for ; Sat, 10 Feb 2018 01:00:08 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id o1so5075575pgn.4 for ; Sat, 10 Feb 2018 01:00:08 -0800 (PST) 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=BjpwvnL6CiLlewPQBBfQ6UsyACeV8dia5fw47gfsupc=; b=M92EkJmyK9li0xz9gLG0IL00jC7GzB59rdUg3cLHuzp31HmPWk+zoxucHDxR1Xk4BB HX/1+1DuvmJnyihANnYLdGLanwEOtd1JwMvtuhYCwJWon9m3B+FOFwDP+VeEEeQM59eY 3R4KWhaO8F7wFLHsxhUOOq8RVkFnYfggbGf1EgjoDPCJxjgIMOwcHMhFJXPz9kjmYxeo iMmoi2vas839N5GNdf7j5uVEWl3Gr2NzUjToh0Dvoc8XE3Avi6w6u8dSgQQUStuX+XcW pjuMFcfNP7tgaVE48Qj5db4IcheKDg99TxOAqJiZzEAkE/Sm+ZigINW3UW/nrBPgweqT h/XA== 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=BjpwvnL6CiLlewPQBBfQ6UsyACeV8dia5fw47gfsupc=; b=eJoQqOrknRasZt2OEoE518+ZIfPqvM0c2PAmPv28Ohb9xGhOHybqIh9Xip/sj6G5Xv KHod4wBYR1CuXcq8noy2/z3d+wRFC79jPdcq0GG6CE8qwuvucGT4ltPspKGnyFoE78oQ JXkBK1273B0kElsQ1cPurwC7Mm6HZNHsbrrIbkfSK4Birw7MoqqkiLFTFqaPDvpSyXpn t4NS7m+XDwLW/UIwQEiOHDjOl1RQOjcfgd/U2NU2pNxovPSjrAcsyJPT2KvLNv5F4cfn SLRrrXb/vXYb2ntt+FsXNrzIFUH/FVBhi/gojqz0LQsCkobCazniFZDeQpa++s0Y+lIa urFg== X-Gm-Message-State: APf1xPA7/SOgB1zsF30JSEYeXmj71rNODa0yLDxfDC4DZoMGK8GEfZ+X jkxETOdJHGqWGlzHqTDibTFc3yuI7+vF3/yQlWM= X-Google-Smtp-Source: AH8x225x4o/f+O39B55Lr0Hw0JJgxG+sc6MH5JvnE9rqcYJZvvdXbW7kF9QGFPXrW1gVIVb2OsdraKD2rQoyNQ4Noeg= X-Received: by 10.98.25.207 with SMTP id 198mr5573728pfz.83.1518253208292; Sat, 10 Feb 2018 01:00:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Sat, 10 Feb 2018 01:00:07 -0800 (PST) In-Reply-To: <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> From: Kazuho Oku Date: Sat, 10 Feb 2018 18:00:07 +0900 Message-ID: Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: alexandre.ferrieux@orange.com Cc: Christian Huitema , Lingmo Zhu , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Martin Thomson 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: Sat, 10 Feb 2018 09:00:11 -0000 2018-02-10 17:34 GMT+09:00 : > On 10/02/2018 07:24, Christian Huitema wrote: >> >> >> >> On 2/9/2018 3:06 PM, Lingmo Zhu wrote: >>> >>> >>> IMHO we can see that such interference is pretty easy to be used and >>> it could leading to aborted QUIC connection and probably a fallback to >>> any old approach for higher level protocol. Even virus targeting home >>> routers could do that, without gov involved. For what outcome, I think >>> it's pretty simple: forcing higher level protocol fallback to other >>> transport protocol. Since QUIC has been designed much more secure than >>> older protocols, it could be hard to do some eavesdropping or >>> hijacking. But if fallback happens, it would be another story. >>> Considering DNS over QUIC, a virus-infected home router could >>> interfere with QUIC handshake cause fallback to TLS, then RST may >>> cause fallback to clear text, which is easy to be hijacked and leads >>> client to some phishing site. >>> >> >> In theory, it should be possible to protect against "man on the side" >> attacks. Do some kind of speculative execution on the first packet that >> you receive, but also keep the context available for some time in case a >> "better" packet comes later. With that approach, the attacker could not >> just inject a "packet of death"; they will also need to suppress the >> correct response from the actual server. That's an interesting idea. >> Have you tried some experiments? > > > Alternatively, what about a "no fallback" mode for sensitive applications > like DNS ? I agree that providing such an option would narrow the attack window. The other option is to let the client propose multiple versions and the server select one, as proposed in my previous mail. But even if we do that, there's still the chance of an attacker injecting a Handshake packet that contains a corrupt ServerHello message. In such case, the client would fail to complete the handshake with the server. To evade such attacks, a client is required to create a backup of its TLS context before handling the Handshake packet that might have been sent from an attacker, so that it could restore the context one the TLS handshake ends up in an error. However, I am not sure if any of the TLS stacks provide such a feature (personally I would be interested in adding one in picotls, though). > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > -- Kazuho Oku From nobody Sat Feb 10 01:10:15 2018 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 45613127601 for ; Sat, 10 Feb 2018 01:10:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 xYVSVW4CAEd0 for ; Sat, 10 Feb 2018 01:10:12 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6EFA124234 for ; Sat, 10 Feb 2018 01:10:11 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id B5F27C1266; Sat, 10 Feb 2018 10:10:10 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 846681A0051; Sat, 10 Feb 2018 10:10:10 +0100 (CET) Received: from lat6466.rd.francetelecom.fr (10.168.234.6) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 10 Feb 2018 10:10:10 +0100 Message-ID: <32019_1518253810_5A7EB6F2_32019_65_1_5A7EB6F3.20509@orange.com> Date: Sat, 10 Feb 2018 10:10:11 +0100 From: Reply-To: Alexandre Ferrieux Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Kazuho Oku CC: Christian Huitema , Lingmo Zhu , =?ISO-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , "quic@ietf.org" , Martin Thomson Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.6] 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, 10 Feb 2018 09:10:13 -0000 On 10/02/2018 10:00, Kazuho Oku wrote: >> > Alternatively, what about a "no fallback" mode for sensitive applications >> > like DNS ? > > I agree that providing such an option would narrow the attack window. > The other option is to let the client propose multiple versions and > the server select one, as proposed in my previous mail. > > But even if we do that, there's still the chance of an attacker > injecting a Handshake packet that contains a corrupt ServerHello > message. In such case, the client would fail to complete the handshake > with the server. Yes, but this weakens the threat from outright intrusion to mere DOS, right ? If so, note that the attacker may always follow its packet-of-death with a flood, making the receiver-side UDP socket overflow and eventually drop the legitimate server's response. In this case, not even a TLS context backup will be able to recover. Agreed, that's a heavier sword for a thicker shield, but that's doable ;) _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Sat Feb 10 02:30:35 2018 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 E9C9512D86A for ; Sat, 10 Feb 2018 02:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 4c8y_ocKSgsW for ; Sat, 10 Feb 2018 02:30:32 -0800 (PST) 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 4674C12D86C for ; Sat, 10 Feb 2018 02:30:32 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id p139so1446926itb.1 for ; Sat, 10 Feb 2018 02:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=eq9k9LRg3i+zCLaIpmVWkJMD+kXyzkJHyfu2bnh9ugo=; b=SHGQ4hLdb1aLBQ0j9XB5ouE12YyC1dswfEskerDjNNksfFaw/uNGMCML7fbGocb8Ma 0x8gxsFVS2wOCbVKfe22161bw9N7V91BLGZ+8oqqjuLYvaFSNmKHflFDToAw+UNOCAQz k9EkMqdStTvduiM9FrQX2e249PegjHphNdMGAy2qfrk4OvbaHda739/0o7l3Sh7py4YP fG0Q8oygFKBRnqgtsi/L2knB0/mvLciWaycOeH4MyODNfqYNM3dJfXiafr+eniz8EWWV FfZuvMZwfII+eYAytVXXhfcqJO1WyXMqR7yrnk30Xi0ZgUo9mJb0+b/LR7oHbL2vXPxy D/gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=eq9k9LRg3i+zCLaIpmVWkJMD+kXyzkJHyfu2bnh9ugo=; b=qTVXmA/aDolBjg24aU3lto163/+N4yTUVO03UotaB6X6oVchX3R9951/pW+/jPMDAB NQ1vvoKM8ydtvnTdHPshRizUXoLTcYJftZEU2hl4xBN4tlDbGqBnKrrOjo4jEeTG1eqd 3MNVG8DC6lKz4RBkz/6tlNescjzpeV5j+RPVPzw4r4OjM5LIvF1/zaN7txMa/IZTeuXY 7g3YNuTsylWJTwAoupyn2ggk0U3hkUrozVyenTKODpPEtMN2j3k1SNCTuZvxZLvgvc3H 1qr4L1kmN3JVvzc9ZqqcJGXv3r3DEWienhTRPur4hDNbysbK1Bo+G1ygLvlnls9Y5JNe lZ8w== X-Gm-Message-State: APf1xPAW8cYENMjte5EH4PI+3flW0MtfPeWQEEbBCAbM1h1CffvQv8Xe D/dXX7K2Lrvc2IyVjh9M9uI= X-Google-Smtp-Source: AH8x225JAN3ltYYla+3uLf4AMqJAdqhNEdCVxGbdB4SSupG7OuLW1C1GfQEfnJ29wNuvDV9q2Y9XdA== X-Received: by 10.36.179.14 with SMTP id e14mr7099519itf.139.1518258631529; Sat, 10 Feb 2018 02:30:31 -0800 (PST) Received: from Justins-MacBook-Pro.local (tk2-262-40902.vs.sakura.ne.jp. [160.16.241.156]) by smtp.gmail.com with ESMTPSA id s20sm5101087ioa.26.2018.02.10.02.30.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Feb 2018 02:30:31 -0800 (PST) Subject: Re: Questions about Version Negotiation Concerning Possible Handshake Interruption To: Kazuho Oku , alexandre.ferrieux@orange.com, Christian Huitema Cc: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "quic@ietf.org" , Martin Thomson References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> From: Lingmo Zhu Message-ID: Date: Sat, 10 Feb 2018 18:30:22 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US 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: Sat, 10 Feb 2018 10:30:34 -0000 On 10/02/2018 07:24, Christian Huitema wrote: > > In theory, it should be possible to protect against "man on the side" > attacks. Do some kind of speculative execution on the first packet that > you receive, but also keep the context available for some time in case a > "better" packet comes later. With that approach, the attacker could not > just inject a "packet of death"; they will also need to suppress the > correct response from the actual server. That's an interesting idea. > Have you tried some experiments? No experiments yet but I'd love to. Though my current work is not so related to this field so maybe I'm not professional enough. On 2018/02/10 17:00, Kazuho Oku wrote: > 2018-02-10 17:34 GMT+09:00 : >> On 10/02/2018 07:24, Christian Huitema wrote: >>> >>> In theory, it should be possible to protect against "man on the side" >>> attacks. Do some kind of speculative execution on the first packet that >>> you receive, but also keep the context available for some time in case a >>> "better" packet comes later. With that approach, the attacker could not >>> just inject a "packet of death"; they will also need to suppress the >>> correct response from the actual server. That's an interesting idea. >>> Have you tried some experiments? >> >> >> Alternatively, what about a "no fallback" mode for sensitive applications >> like DNS ? > > I agree that providing such an option would narrow the attack window. > The other option is to let the client propose multiple versions and > the server select one, as proposed in my previous mail. > > But even if we do that, there's still the chance of an attacker > injecting a Handshake packet that contains a corrupt ServerHello > message. In such case, the client would fail to complete the handshake > with the server. > > To evade such attacks, a client is required to create a backup of its > TLS context before handling the Handshake packet that might have been > sent from an attacker, so that it could restore the context one the > TLS handshake ends up in an error. > > However, I am not sure if any of the TLS stacks provide such a feature > (personally I would be interested in adding one in picotls, though). > > IMHO even though we want no fallback for service like DNS, in reality that could not be possible for several years due to deploying progress and its critical position (if no fallback, no name resolving would be available if QUIC & TLS connection failed if my understanding is correct). To be cleared, spoofing clear text VERSION NEGOTIATION packet is cheap from my POV so it could be misused easily. I'm not sure but injecting corrupt ServerHello message could be sort of expensive thanks to encryption so I didn't consider that far. So if we still decide to use current version negotiation mechanism, considering only the attack approach using VERSION NEGOTIATION and we hold different contexts for a short period, there would be several cases: * fake VERSION NEGOTIATION with no acceptable versions was sent to the client but the server could accept the QUIC version INITIAL packet used, it could be mitigated by simply wait for a short period. Retry might be applied considering packet lost. * sever actually could not accept any version that the client supported, client would abort the QUIC connection after several retries and that should be expected. * fake VERSION NEGOTIATION with no acceptable versions was sent to the client and the server also rejected the QUIC version with a VERSION NEGOTIATION with acceptable versions, client could try an acceptable version and process the handshake. * fake VERSION NEGOTIATION with acceptable versions was sent to the client and the server could accept the QUIC version INITIAL packet used, things could be tricky. At least two contexts should be hold by the client. If the new version selected by client is not acceptable to server, that could be a better scenario since the original context would simply become the finally negotiated one. But if the new version is also acceptable by server, I'm not sure what would happen. * fake VERSION NEGOTIATION with acceptable versions was sent to the client but the server rejected the QUIC version with a VERSION NEGOTIATION with acceptable versions, things would be really complex. But the downgrade attack mentioned by Mikkel should be tolerant by current verifying mechanism. I'm not sure if we should consider this case. So as a summary, holding original context for a short period should be enough for mitigating the interruption caused by VERSION NEGOTIATION according to the first three cases. But for the remaining misuse cases, it might need further consideration if they should. Lingmo Zhu >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu >> ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages >> electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou >> falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been >> modified, changed or falsified. >> Thank you. >> > > > From nobody Sat Feb 10 03:35:51 2018 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 738C012773A for ; Sat, 10 Feb 2018 03:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, UNPARSEABLE_RELAY=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 oZaRNInIoKeJ for ; Sat, 10 Feb 2018 03:35:47 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 383A0126BFD for ; Sat, 10 Feb 2018 03:35:47 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id i144so1546522ita.3 for ; Sat, 10 Feb 2018 03:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=zp9brfWHZTaPklOeTUinFniSTDgDAk09whG3yQ6x2YM=; b=f8896HFICLWlIwcLclkU0ZTWh9q31vPNBezGmr19F6j/DYyUbgNdsmIoq37nUmrRic eas1IoDx6YvKc+wNZki9CMuygQ9830Q52JzCjHcdU1rVkqFKpgeTDEsExN+LUAi5kpic 0YcOzpMApeVhah0RX+HD5/oe6TBks/we6d/PvAoLGVZdTfkt6aMmfStxmVZ4FS+gN2eh 9NGUro72u3Q8bUwgdwHUHZWWVixRzKh8hjRJUSez+77ns8+vb2KS+HTzl/oCkjesZVDP KtkcLq+DwkrQ1l1+IRtT+SLRKOKc7bof8CpXtXxjy7+/4Yq3OHifTlJsEVX9anNA1eTD rnBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=zp9brfWHZTaPklOeTUinFniSTDgDAk09whG3yQ6x2YM=; b=LIu1bPhUw/U0pdUOv0kUzT8l/VDDeuDqdJFYdm7PfhUcE3hcTaHhKKrk9YMvB6Y1u7 5wIY0q5gT7JQRXMNb7HbAH0XkCI5V7+xhNiYAT6++NWq8LhJsOOIxK6OMZTPJ0WbGHw0 X4JM6ythsvYzko8fwhU29m84bRMRYrwz24yT8aAzgF96AMh7YOQq7XQqNMPsoVUcIo7s fpQY1NpqNeLwyTUDUgQ5OduqFq8f0OPrjjo0pihMJZ7r7E24PZv+pdltS43mYhN5c0+e 3U20FeMwCp6vQgu8qXHXr/WR3p2Kw0P91mLwbEbPWAT+BDP3I1ssxK/KCqNrebliBZ6e olEQ== X-Gm-Message-State: APf1xPDbQAsE88wdHNF/9zYFyqn2aEjUoczichNCoQKHUh5TmYNPZUQK Jdll/tsZl+b+iKi8YJQ85aweaRGbxWeHa++y0S0= X-Google-Smtp-Source: AH8x224UZ5Cdj5OImsIEEdEY7RfZ3qGI2P+ZfLnutCFeE1MkLoLDyTc1g3PB/eGH73n9f1YTgDtIFF52aaRnv7X7X90= X-Received: by 10.36.10.207 with SMTP id 198mr7006461itw.42.1518262546640; Sat, 10 Feb 2018 03:35:46 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 10 Feb 2018 03:35:45 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 10 Feb 2018 03:35:45 -0800 Message-ID: Subject: Re: Packet number encryption To: Victor Vasiliev Cc: Praveen Balasubramanian , "quic@ietf.org" , Marten Seemann , huitema Content-Type: multipart/alternative; boundary="001a1144b828c4b7580564da0ba7" 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, 10 Feb 2018 11:35:49 -0000 --001a1144b828c4b7580564da0ba7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To put numbers into perspective using Intel 2015 data https://software.intel.com/en-us/articles/improving-openssl-performance#_To= c416943490 A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte or 66 cycles total, or 22ns on a 3GHz core. For packet numbers we use the CBC encrypt numbers because here AES cannot exploit block parallelism. Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz setup that would amount to about 24ns overhead for packet encryption. Clearly it makes no sense that AES-GCM is faster than a single AES block encryption, but these are only approximate numbers and CBC mode might have a little overhead, so we clamp packet numbers to 22ns. Taking the 98ns overhead by the Solarflare report we get a total (simplified) processing time is 98ns non-crypto, 22ns for packet number, and 22ns for AEAD totalling 142ns. So the packet number encryption overhead would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeeping= , but that can be done in other cores or outside the latency critical window. This does not take into account that AEAD operation may operate less than optimal because the packet number must be extracted first. On the other hand, it is also not a disastrous overhead if no good alternative can be found. Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycles i= n HW for a single AES-128 block which would be 33ns per packet number in the above example. On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: 98ns for 68 byte messages --001a1144b828c4b7580564da0ba7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = To put numbers into = perspective using Intel 2015 data


A 64 byte message in A= ES-GCM AEAD in HW would use 1.03 cycles per byte or 66 cycles total, or 22n= s on a 3GHz core.

For packet numbers we = use the CBC encrypt numbers because here AES cannot exploit block paralleli= sm.
Here we see 4.44= cycles/byte in HW or 71 cycles per block. With a 3GHz setup that would amo= unt to about 24ns overhead for packet encryption.

Clearly it makes no sense that AES-GCM is faste= r than a single AES block encryption, but these are only approximate number= s and CBC mode might have a little overhead, so we clamp packet numbers to = 22ns.

Taking the 98ns= overhead by the Solarflare report we get a total (simplified) processing t= ime is 98ns non-crypto, 22ns for packet number, and 22ns for AEAD totalling= 142ns. So the packet number encryption overhead would be 22/(98+22)*100% = =3D 18%. The numbers ignore other QUIC bookkeeping, but that can be done in= other cores or outside the latency critical window.

This does not take into account that AEAD o= peration may operate less than optimal because the packet number must be ex= tracted first. On the other hand, it is also not a disastrous overhead if n= o good alternative can be found.=C2=A0

Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests = around 100cycles in HW for a single AES-128 block which would be 33ns per p= acket number in the above example.

On 10 February 201= 8 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

98ns f= or 68 byte messages
--001a1144b828c4b7580564da0ba7-- From nobody Sat Feb 10 06:25:53 2018 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 99853124D6C for ; Sat, 10 Feb 2018 06:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9fkrFPUf2tfB for ; Sat, 10 Feb 2018 06:25:51 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E976A12421A for ; Sat, 10 Feb 2018 06:25:50 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,489,1511856000"; d="asc'?scan'208,217";a="240820696" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx144-out.netapp.com with ESMTP; 10 Feb 2018 06:25:50 -0800 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 10 Feb 2018 06:25:50 -0800 Received: from VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 10 Feb 2018 06:25:49 -0800 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Sat, 10 Feb 2018 06:25:50 -0800 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=Kye/JrfsrUR1S9Q/XVwYWedQFxnxAXXPF4pr3sGsppM=; b=d4rlP30MFIjcU5nPJyQzg7zCOj4k8ocfR+zwG8EVmcNeAUGuuJtEUIwe3jBq59W9BhT/9FINzrykVJtVyNkQndC0aku/pvmTqwfAf+uyEAF58hXJE4db30UoNnc4mHA4R0RKkyx8c3YtXoz56/qm9D8esqy0Jdd4doHnNmdVGQ4= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB481.namprd06.prod.outlook.com (10.141.203.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Sat, 10 Feb 2018 14:25:40 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::7dc2:7ad3:3b8b:755d]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::7dc2:7ad3:3b8b:755d%13]) with mapi id 15.20.0485.009; Sat, 10 Feb 2018 14:25:39 +0000 From: "Eggert, Lars" To: Ian Swett CC: Christian Huitema , "Salz, Rich" , Eric Rescorla , "quic@ietf.org" , "Praveen Balasubramanian" Subject: Re: hardware offload (was: Packet number encryption) Thread-Topic: hardware offload (was: Packet number encryption) Thread-Index: AQHToe+MzOUTIc03mkW3czVqIr88u6OdsisA Date: Sat, 10 Feb 2018 14:25:39 +0000 Message-ID: <17971C0F-7BFB-4DCF-A9EE-3128FB180CF2@netapp.com> References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> 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.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [12.229.60.66] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB481; 6:DEvVUJztr2cBW4RvVMKQzqQrRi7OqPWwVBv4TxeDNrEuyv9L823N0OrT82n4UcFj4eXh/9LUAchC7OjVL6r1ySsUSjdlOUJ72KyIlgdcf54I7eFGpLStOZlPHRDM328xsHOsmgwrcQ4GWrzKKvkVpuFuQEmi77iimz7AUhSPIVwxvyYQBhSQksv7sqHcUKVL0cEBW2zaNQ1XWYkmRtw8ya+HrKBodI/xvpzrokve3TzMKmayS/SswjjBHFTCCEvADyUfag2wZfw2w8fWYc98H2rtHW0W6rARpavrywj9/do6dtWpgGCe+H+IzWHuxAZMujGBtuy6634P5LvDPZlB3jJGBOA6CgtUDhPiioKK70xTz0igMwYhU+EZhclUDbKN; 5:J8PVYMZayM0fCzt/ddPFKXOm3UVfa+LQ+ABbviOOtce3jNYk/nVZqNUfjF5SoLkDdM3DDn5kRwHokce/LFv1R3MNLcpi5jH8l6GdBXizHqkbLXzvLkoILR1lm5cPOtS/1xVTpFkQPAylFlckTqXWlMqc0lkGrNC83vJGMkxk6PU=; 24:okyaXyU4v8PJ33EMXvpgOw2kH7ZaQAIvhePsKZ4TSV6M2jRXL08XigD0t6PKED2RAWd253RSUfN7LL4XiCsCd+uIqWlrrG0UGKBeZlbKRW8=; 7:bzBUuuiAe5NCII5MOj1Q/jBJTf/w+44E5auya7SdctCNjhb3htWdQhxIsRIp/l/khXNw8WOedjbVUZHjwdI8SaTvu3Bpy/BCkrn5LBvlOu5pSiw3rKkBCUI7p6OrHhbw8HRTMCR+L/1n4mAtj3nC8oHaiS8zDS9aVXW2k9nFRLBShw+Ql0DBc1A6zWclK57Pfe2cGbQ5EAW0uunKOq9RVv/0pHFvUBzvSKyHiA8Z2/YrMYhqIZgmiQyguyVD0oRE x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9ecafb7f-5c46-4388-f451-08d570922906 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB481; x-ms-traffictypediagnostic: BLUPR06MB481: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(6055026)(6041288)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BLUPR06MB481; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB481; x-forefront-prvs: 057906460E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(39380400002)(39860400002)(376002)(396003)(377424004)(189003)(199004)(76176011)(4326008)(8936002)(8676002)(5250100002)(81166006)(53546011)(81156014)(86362001)(6506007)(82746002)(57306001)(50226002)(2906002)(478600001)(6486002)(25786009)(4001150100001)(54906003)(6436002)(26005)(7736002)(99936001)(68736007)(106356001)(14454004)(186003)(33656002)(6116002)(5660300001)(6246003)(105586002)(236005)(229853002)(97736004)(93886005)(99286004)(53936002)(102836004)(2900100001)(83716003)(3846002)(8666007)(2950100002)(6512007)(6916009)(3660700001)(3280700002)(54896002)(316002)(36756003)(66066001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB481; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ZkoeB97zscseld3xCGGa88U9S/QpUSMddkPj7jPKsN4AVgV5JjVosfC8ykNz21hfCZIyargzTQFpOypsWHj0Uw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_D0864420-E000-4291-AB6B-1B12275B1F16"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9ecafb7f-5c46-4388-f451-08d570922906 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2018 14:25:39.6463 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB481 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: Sat, 10 Feb 2018 14:25:52 -0000 --Apple-Mail=_D0864420-E000-4291-AB6B-1B12275B1F16 Content-Type: multipart/alternative; boundary="Apple-Mail=_44DC5A63-5ED2-4E37-B9AF-C3B389B36F11" --Apple-Mail=_44DC5A63-5ED2-4E37-B9AF-C3B389B36F11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2018-2-9, at 13:46, Ian Swett wrote: > Hardware acceleration of AES in modern CPUs is extremely good, so = another approach is to do the above in a userspace networking stack or = the kernel and use the CPU's AES acceleration. If the networking code = that was writing into NIC memory had a deep understanding of QUIC, = possibly it could do the packet number encryption as a second pass? FWIW, this is exactly what I intend on doing with quant, which can sit = on top of netmap. At the moment, I do the crypto on the same core as = anything else (so I can run-to-completion w/o locks), but eventually I = want to try to push things over to other cores for crypto. I'm also chatting with the Cambridge NetFPGA people to see what type of = crypto (and segmentation offload they could provide that would tie in = well with a QUIC stack. Lars --Apple-Mail=_44DC5A63-5ED2-4E37-B9AF-C3B389B36F11 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 2018-2-9, at 13:46, Ian Swett <ianswett@google.com> wrote:
Hardware acceleration of AES in modern = CPUs is extremely good, so another approach is to do the above in a = userspace networking stack or the kernel and use the CPU's AES = acceleration.  If the networking code that was writing into NIC = memory had a deep understanding of QUIC, possibly it could do the packet = number encryption as a second pass?

FWIW, this is exactly what I intend on doing = with quant, which can sit on top of netmap. At the moment, I do the = crypto on the same core as anything else (so I can run-to-completion w/o = locks), but eventually I want to try to push things over to other cores = for crypto.

I'm = also chatting with the Cambridge NetFPGA people to see what type of = crypto (and segmentation offload they could provide that would tie in = well with a QUIC stack.

Lars
= --Apple-Mail=_44DC5A63-5ED2-4E37-B9AF-C3B389B36F11-- --Apple-Mail=_D0864420-E000-4291-AB6B-1B12275B1F16 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlp/AOIACgkQVLXDCb9w wVeqLg//UGGYQzVDXqx46l1v46trZSAhs6v5hmNZgg5Gq3566tVMPCcd1K681GEl hJW4HVRaAcqW/RkFlhccjOVRd7LZrEbwM0arqXUkUr2evQYFQAW0DjKgEQCEnajR q13ii4JRojsGRmNuX4k5s8dcBN9qDMEGlpfMQjyRCj+7ZEmxhk9yYDbWuHuDoGdc zpX1xFDlqBU6UAYK5gdyb+9Z1YlI1ez9F2RRsEHJw6xAzTfW/Y3JkAWy4cdtb/wH SS7gLgJVFQTRGYMhDbOO3nyMS+bk92fnmOZfd1PgqEUF2HdAf73MNXM48ymu9C0g A/dSIFm526ynFkccWV6TLfeDXJAkJQElNUJmDUAKHU8dqm0P3Bqas0NYCT7Im/Hq acmdxqQgb9Vt7h3H9EJi1gWXDqf9ERAdgjtNBzKF+ZrNZGtcy7l3rMs9g9ifiK/G 7waWaSJ7878hc46q93qdqjAKQ3dvSmOf9u2p6oL0eZtg8WteXLJNYobn7RP8VGeF LCKJwQaSSCnS/78t13PBwTH/N0ht3hrOhAEjVoOB/JbGUn854jQgi08bfZ/GAGje BteW66VmCfUka7JtHeIwJAZ98DMwkQZptbW16EzlWtyQ0C2TE7wmcl6a3fJXdxw1 /bKW7fH8N1QK7fouqectUmLoOA8YyHI75PG9eliVrA/FGwgaq8Y= =IrFE -----END PGP SIGNATURE----- --Apple-Mail=_D0864420-E000-4291-AB6B-1B12275B1F16-- From nobody Sat Feb 10 08:08:34 2018 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 A2EDF12DA12 for ; Sat, 10 Feb 2018 08:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 Fo66LwSushnJ for ; Sat, 10 Feb 2018 08:08:31 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d: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 0633E124205 for ; Sat, 10 Feb 2018 08:08:31 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id d72so13709275qkc.6 for ; Sat, 10 Feb 2018 08:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=xSeBkvKmyn8inIY8gth2p2XWUWWwfuswJDK7p7C3cdg=; b=mRD+lhGkZRftu3kmtrar+BMFV/etJ81iJIcRTMq66A8+bIG3SWmVu7Eu+8na1BdB6R PaOgIO6/mDHHglpXF7hhcj6ArWuRkjbim7WwBBjwKB6CCWArfiHyncpwyUZqjhg+nEJ3 wJd821kQBKD0SWFbHnELoBCja/rGkqB5nwlIgBK3lckO9YU8H8FbnayNSHFczZEWRjue 8Pq8pGwLrb6dJBNLp87ZYEpSmXdSURc2OHkT35dsZ+nywx3RcSZ5nQHWaafRJwE9l7n1 Zfde78JbxpLDhpukHpKckXgdvGUGOpFq0CV4nQMQZBYgybCSGkbm96L334S+Io6j8O5u rYpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=xSeBkvKmyn8inIY8gth2p2XWUWWwfuswJDK7p7C3cdg=; b=so52qECmaDzhBgQJkUyRnPLLR+w/DoEB3pW0+zOwbF/UJPGyh/D/xI0zuVrb6wB4TD EDeZ0OFWb7kJOkY2LpyaifdftXCYVGr+pf2zAEBmyEX6HAw+nOboGgdIoQMBnYLzhHiB 0am6ZXkkPGfcSf9eIQmZrbuB7y5+XfI2J26R945YTkbT/ge9kcDIpA3xDHoBx+B4TQ0b b4ZSRvorR2JKCNWCsLzwd8/z9KbrJQvRReylCeDLJq3tA1y8lRK3+leyka3fe11laWaI KJY2qTy3jaYH7UewTOO9rH0yRAHhrPZCGafJAanO3+vyAK2BeXF0SefBI46uY4X96MzD mWLQ== X-Gm-Message-State: APf1xPCUCEaH/90x1o7ws3wWrb4o8m+mA3Tvreq9jC0Zw2TN99TUwbGp N05LEumX591AaezhXaiZ2vVvIw== X-Google-Smtp-Source: AH8x224YIfjURsOyfuSr4RrdP/wof2tngPOaVo0dUzhtb9keV7sLWE4w4q0rjpKWsaR/Hkr6BcigDg== X-Received: by 10.55.25.28 with SMTP id k28mr5097084qkh.22.1518278908739; Sat, 10 Feb 2018 08:08:28 -0800 (PST) Received: from ubuntu-dmitri (ool-45715890.dyn.optonline.net. [69.113.88.144]) by smtp.gmail.com with ESMTPSA id f9sm3651227qta.86.2018.02.10.08.08.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 10 Feb 2018 08:08:25 -0800 (PST) Date: Sat, 10 Feb 2018 11:08:18 -0500 From: Dmitri Tikhonov To: Charles 'Buck' Krasic Cc: Martin Thomson , Lucas Pardue , QUIC WG , Mike Bishop Subject: Re: Review of QCRAM Message-ID: <20180210160817.GA29877@ubuntu-dmitri> Mail-Followup-To: Charles 'Buck' Krasic , Martin Thomson , Lucas Pardue , QUIC WG , Mike Bishop References: <7CF7F94CB496BF4FAB1676F375F9666A3BAD6C5A@bgb01xud1012> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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, 10 Feb 2018 16:08:32 -0000 On Fri, Feb 09, 2018 at 02:22:22PM -0800, Charles 'Buck' Krasic wrote: > On blocked evictions. > > a) there's a real possibility that setting table size to 64KB is the most > elegant solution, because evictions may not happen for the vast majority of > connections. I think this is the opposite of "elegant." HTTPQ is not just a protocol for web browsers. We should try to make the header compression mechanism perform well in various scenarios. In addition, we were getting good compression performance with 4KB tables in our simulations. Increasing the size to 64KB to address that which can be solved by other means seems like a suboptimal approach. - Dmitri. From nobody Sat Feb 10 09:13:01 2018 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 20DB61276AF for ; Sat, 10 Feb 2018 09:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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=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 NgBXps_eOx1s for ; Sat, 10 Feb 2018 09:12:57 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0125.outbound.protection.outlook.com [104.47.34.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D4D126BF3 for ; Sat, 10 Feb 2018 09:12:56 -0800 (PST) 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=Anvih2CvI3K+IJ58iyQsyr16CvI6EBunF1IeOSCBto4=; b=hlTrPkaA8YocG8rWn6+YScmIs3fXtPIMW3thMc11MlOJDfUcI/m31XnTXKk/gDnUU2tMRhTTbmS75Sml5Ikv3zQmFM44EJEp9Dkm3/HH5DEo+Fnb+CvKwVDsrMOuHKdr89MDT8Ilwo8dstD5e7Zk9Tzf7HwYvgQorRraeC/kiRU= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0693.namprd21.prod.outlook.com (10.175.121.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.4; Sat, 10 Feb 2018 17:12:51 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Sat, 10 Feb 2018 17:12:51 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Victor Vasiliev CC: "quic@ietf.org" , Marten Seemann , huitema Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAbWdAIAAKHbggAGCSACAAALsAIAAO8qAgABHugCAAGlygIAAXGZA Date: Sat, 10 Feb 2018 17:12:50 +0000 Message-ID: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0693; 7:4PvGpQ+Hvmo6nVcR9hB6gXDEwqJiT00kIEXiPMcBYiaUb/JQPahe82SCiZUmonRWSkEyt9v5GIe8f3vg23YWqh+zXERBS/1x8G6GBYj+o3JA2/kXdlO8dRTTvW7AZnZB6wCC9NRavOzW2PjAdZPBKNukucRyq5cpsv1P4xepXm2K/wy3Y56BRklNRqd99bfffbm76GEsYBm9UbtDlRkWWk4UZkK5sAvfTtqKNEWWDzKBoqIjSAjw0/PKYA10EkIe x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 12e72fe0-4911-4f1b-1564-08d570a98432 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0693; x-ms-traffictypediagnostic: CY4PR21MB0693: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(108984395545644)(89211679590171)(189930954265078)(85827821059158)(211936372134217)(153496737603132)(219752817060721)(21748063052155)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:CY4PR21MB0693; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0693; x-forefront-prvs: 057906460E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(39860400002)(376002)(396003)(346002)(189003)(199004)(11905935001)(10290500003)(7696005)(86612001)(33656002)(97736004)(3480700004)(25786009)(81166006)(106356001)(2906002)(8676002)(81156014)(8936002)(8990500004)(606006)(6246003)(3660700001)(5250100002)(186003)(3280700002)(10090500001)(110136005)(105586002)(93886005)(2900100001)(54906003)(39060400002)(4326008)(99286004)(19609705001)(790700001)(5660300001)(22452003)(229853002)(6116002)(59450400001)(966005)(74316002)(316002)(236005)(2950100002)(7116003)(6506007)(53546011)(14454004)(55016002)(478600001)(6346003)(9686003)(53936002)(68736007)(7736002)(102836004)(54896002)(6306002)(86362001)(6436002)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0693; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: c65vEZGQM594KFUiBOv8aZ+yc755FmhX7Gyn2MvZhDDpy0xWC6NvOlhYwnCmdG/syNPjybrJPaQImCjsR88bPw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133D903AD60734920BBC910B6F10CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12e72fe0-4911-4f1b-1564-08d570a98432 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2018 17:12:51.0889 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0693 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, 10 Feb 2018 17:13:00 -0000 --_000_CY4PR21MB0133D903AD60734920BBC910B6F10CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWFrZXMgc2Vuc2UuIFRoZSAxJSsgb3ZlcmhlYWQgSSBoYWQgcXVvdGVkIHdhcyBpbiBjb21wYXJp c29uIHRvIGZ1bGwgcHJvdG9jb2wgcHJvY2Vzc2luZyBhbGwgdGhlIHdheSBmcm9tIGFwcCB0byBO SUMuIFRoaXMgaXMgd2l0aCBhbiB1bm9wdGltaXplZCBlYXJseSBRVUlDIGltcGxlbWVudGF0aW9u IGFuZCBub3QgZnVsbHkgb3B0aW1pemVkIFVEUC9JUCBzdGFjayAod2UgaGF2ZSBmb2N1c2VkIG11 Y2ggbXVjaCBtb3JlIG9uIG9wdGltaXppbmcgVENQIGluIHRoZSBwYXN0KS4gQWZ0ZXIgc29mdHdh cmUgc3RhY2sgb3B0aW1pemF0aW9ucywgdGhlIGNyeXB0byBzaGFyZSBvZiB0aGUgY29zdCB3aWxs IG9ubHkga2VlcCBnb2luZyB1cCBmb3Igd2hpY2ggd2UgaGF2ZSBubyB0ZWNobmlxdWUgb3RoZXIg dGhhbiB0byBvZmZsb2FkIHdoZW4gc3VjaCBzdXBwb3J0IGlzIGF2YWlsYWJsZSBpbiBoYXJkd2Fy ZSBhbmQgb2ZmbG9hZCBpcyB3YXkgbW9yZSBjaGFsbGVuZ2luZyB3aGVuIHdvcmtsb2FkIGlzIGhv c3RlZCBpbiBWTXMgYW5kIGNvbnRhaW5lcnMuDQoNCkZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJn ZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb21dDQpTZW50OiBTYXR1cmRheSwgRmVicnVh cnkgMTAsIDIwMTggMzozNiBBTQ0KVG86IFZpY3RvciBWYXNpbGlldiA8dmFzaWx2dkBnb29nbGUu Y29tPg0KQ2M6IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQuY29tPjsg cXVpY0BpZXRmLm9yZzsgTWFydGVuIFNlZW1hbm4gPG1hcnRlbnNlZW1hbm5AZ21haWwuY29tPjsg aHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4NClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVy IGVuY3J5cHRpb24NCg0KVG8gcHV0IG51bWJlcnMgaW50byBwZXJzcGVjdGl2ZSB1c2luZyBJbnRl bCAyMDE1IGRhdGENCg0KaHR0cHM6Ly9zb2Z0d2FyZS5pbnRlbC5jb20vZW4tdXMvYXJ0aWNsZXMv aW1wcm92aW5nLW9wZW5zc2wtcGVyZm9ybWFuY2UjX1RvYzQxNjk0MzQ5MDxodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnNvZnR3 YXJlLmludGVsLmNvbSUyRmVuLXVzJTJGYXJ0aWNsZXMlMkZpbXByb3Zpbmctb3BlbnNzbC1wZXJm b3JtYW5jZSUyM19Ub2M0MTY5NDM0OTAmZGF0YT0wNCU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQu Y29tJTdDOTQ3ZWE5NmQ1OTJjNDk4MTMwZGYwOGQ1NzA3YTZkYjElN0NlZTMzMDNkN2ZiNzM0YjBj ODU4OWJjZDg0N2YxYzI3NyU3QzElN0MwJTdDNjM2NTM4NTkzNTA3MTI5OTU3JTdDVW5rbm93biU3 Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2 SWsxaGFXd2lmUSUzRCUzRCU3Qy0xJnNkYXRhPUkxJTJCbnZ2RkJmc1ExUCUyQndTSTdyaVdyJTJG a1A5eWRrQWloeGxwQWdwRmdnRWclM0QmcmVzZXJ2ZWQ9MD4NCg0KQSA2NCBieXRlIG1lc3NhZ2Ug aW4gQUVTLUdDTSBBRUFEIGluIEhXIHdvdWxkIHVzZSAxLjAzIGN5Y2xlcyBwZXIgYnl0ZSBvciA2 NiBjeWNsZXMgdG90YWwsIG9yIDIybnMgb24gYSAzR0h6IGNvcmUuDQoNCkZvciBwYWNrZXQgbnVt YmVycyB3ZSB1c2UgdGhlIENCQyBlbmNyeXB0IG51bWJlcnMgYmVjYXVzZSBoZXJlIEFFUyBjYW5u b3QgZXhwbG9pdCBibG9jayBwYXJhbGxlbGlzbS4NCkhlcmUgd2Ugc2VlIDQuNDQgY3ljbGVzL2J5 dGUgaW4gSFcgb3IgNzEgY3ljbGVzIHBlciBibG9jay4gV2l0aCBhIDNHSHogc2V0dXAgdGhhdCB3 b3VsZCBhbW91bnQgdG8gYWJvdXQgMjRucyBvdmVyaGVhZCBmb3IgcGFja2V0IGVuY3J5cHRpb24u DQoNCkNsZWFybHkgaXQgbWFrZXMgbm8gc2Vuc2UgdGhhdCBBRVMtR0NNIGlzIGZhc3RlciB0aGFu IGEgc2luZ2xlIEFFUyBibG9jayBlbmNyeXB0aW9uLCBidXQgdGhlc2UgYXJlIG9ubHkgYXBwcm94 aW1hdGUgbnVtYmVycyBhbmQgQ0JDIG1vZGUgbWlnaHQgaGF2ZSBhIGxpdHRsZSBvdmVyaGVhZCwg c28gd2UgY2xhbXAgcGFja2V0IG51bWJlcnMgdG8gMjJucy4NCg0KVGFraW5nIHRoZSA5OG5zIG92 ZXJoZWFkIGJ5IHRoZSBTb2xhcmZsYXJlIHJlcG9ydCB3ZSBnZXQgYSB0b3RhbCAoc2ltcGxpZmll ZCkgcHJvY2Vzc2luZyB0aW1lIGlzIDk4bnMgbm9uLWNyeXB0bywgMjJucyBmb3IgcGFja2V0IG51 bWJlciwgYW5kIDIybnMgZm9yIEFFQUQgdG90YWxsaW5nIDE0Mm5zLiBTbyB0aGUgcGFja2V0IG51 bWJlciBlbmNyeXB0aW9uIG92ZXJoZWFkIHdvdWxkIGJlIDIyLyg5OCsyMikqMTAwJSA9IDE4JS4g VGhlIG51bWJlcnMgaWdub3JlIG90aGVyIFFVSUMgYm9va2tlZXBpbmcsIGJ1dCB0aGF0IGNhbiBi ZSBkb25lIGluIG90aGVyIGNvcmVzIG9yIG91dHNpZGUgdGhlIGxhdGVuY3kgY3JpdGljYWwgd2lu ZG93Lg0KDQpUaGlzIGRvZXMgbm90IHRha2UgaW50byBhY2NvdW50IHRoYXQgQUVBRCBvcGVyYXRp b24gbWF5IG9wZXJhdGUgbGVzcyB0aGFuIG9wdGltYWwgYmVjYXVzZSB0aGUgcGFja2V0IG51bWJl ciBtdXN0IGJlIGV4dHJhY3RlZCBmaXJzdC4gT24gdGhlIG90aGVyIGhhbmQsIGl0IGlzIGFsc28g bm90IGEgZGlzYXN0cm91cyBvdmVyaGVhZCBpZiBubyBnb29kIGFsdGVybmF0aXZlIGNhbiBiZSBm b3VuZC4NCg0KRWFybGllciBBRVMtTkkgSeKAmXZlIHNlZW4gZnJvbSBJbnRlbCBkb2Mgc3VnZ2Vz dHMgYXJvdW5kIDEwMGN5Y2xlcyBpbiBIVyBmb3IgYSBzaW5nbGUgQUVTLTEyOCBibG9jayB3aGlj aCB3b3VsZCBiZSAzM25zIHBlciBwYWNrZXQgbnVtYmVyIGluIHRoZSBhYm92ZSBleGFtcGxlLg0K DQoNCk9uIDEwIEZlYnJ1YXJ5IDIwMTggYXQgMDYuMTguMjUsIE1pa2tlbCBGYWhuw7hlIErDuHJn ZW5zZW4gKG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPikgd3Jv dGU6DQo5OG5zIGZvciA2OCBieXRlIG1lc3NhZ2VzDQo= --_000_CY4PR21MB0133D903AD60734920BBC910B6F10CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNh IE5ldWUiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bh bi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLmFpcm1haWxvbiwgbGkuYWly bWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHlsZS1uYW1lOmFpcm1haWxfb247DQoJbXNv LW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYWtlcyBzZW5zZS4gVGhl IDElJiM0Mzsgb3ZlcmhlYWQgSSBoYWQgcXVvdGVkIHdhcyBpbiBjb21wYXJpc29uIHRvDQo8aT5m dWxsIHByb3RvY29sIHByb2Nlc3NpbmcgYWxsIHRoZSB3YXkgZnJvbSBhcHAgdG8gTklDPC9pPi4g VGhpcyBpcyB3aXRoIGFuIHVub3B0aW1pemVkIGVhcmx5IFFVSUMgaW1wbGVtZW50YXRpb24gYW5k IG5vdCBmdWxseSBvcHRpbWl6ZWQgVURQL0lQIHN0YWNrICh3ZSBoYXZlIGZvY3VzZWQgbXVjaCBt dWNoIG1vcmUgb24gb3B0aW1pemluZyBUQ1AgaW4gdGhlIHBhc3QpLiBBZnRlciBzb2Z0d2FyZSBz dGFjayBvcHRpbWl6YXRpb25zLCB0aGUgY3J5cHRvDQogc2hhcmUgb2YgdGhlIGNvc3Qgd2lsbCBv bmx5IGtlZXAgZ29pbmcgdXAgZm9yIHdoaWNoIHdlIGhhdmUgbm8gdGVjaG5pcXVlIG90aGVyIHRo YW4gdG8gb2ZmbG9hZCB3aGVuIHN1Y2ggc3VwcG9ydCBpcyBhdmFpbGFibGUgaW4gaGFyZHdhcmUg YW5kIG9mZmxvYWQgaXMgd2F5IG1vcmUgY2hhbGxlbmdpbmcgd2hlbiB3b3JrbG9hZCBpcyBob3N0 ZWQgaW4gVk1zIGFuZCBjb250YWluZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IE1pa2tlbCBGYWhuw7hlIErD uHJnZW5zZW4gW21haWx0bzptaWtrZWxmakBnbWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g U2F0dXJkYXksIEZlYnJ1YXJ5IDEwLCAyMDE4IDM6MzYgQU08YnI+DQo8Yj5Ubzo8L2I+IFZpY3Rv ciBWYXNpbGlldiAmbHQ7dmFzaWx2dkBnb29nbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUHJh dmVlbiBCYWxhc3VicmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7OyBxdWljQGll dGYub3JnOyBNYXJ0ZW4gU2VlbWFubiAmbHQ7bWFydGVuc2VlbWFubkBnbWFpbC5jb20mZ3Q7OyBo dWl0ZW1hICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogUGFja2V0IG51bWJlciBlbmNyeXB0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJi bG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5UbyBwdXQgbnVtYmVycyBpbnRvIHBlcnNwZWN0aXZlIHVzaW5nIEludGVsIDIwMTUgZGF0YTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxkaXYg aWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGc29mdHdhcmUuaW50ZWwuY29tJTJGZW4tdXMlMkZhcnRp Y2xlcyUyRmltcHJvdmluZy1vcGVuc3NsLXBlcmZvcm1hbmNlJTIzX1RvYzQxNjk0MzQ5MCZhbXA7 ZGF0YT0wNCU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDOTQ3ZWE5NmQ1OTJjNDk4MTMw ZGYwOGQ1NzA3YTZkYjElN0NlZTMzMDNkN2ZiNzM0YjBjODU4OWJjZDg0N2YxYzI3NyU3QzElN0Mw JTdDNjM2NTM4NTkzNTA3MTI5OTU3JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0 d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lmUSUzRCUzRCU3Qy0xJmFt cDtzZGF0YT1JMSUyQm52dkZCZnNRMVAlMkJ3U0k3cmlXciUyRmtQOXlka0FpaHhscEFncEZnZ0Vn JTNEJmFtcDtyZXNlcnZlZD0wIj5odHRwczovL3NvZnR3YXJlLmludGVsLmNvbS9lbi11cy9hcnRp Y2xlcy9pbXByb3Zpbmctb3BlbnNzbC1wZXJmb3JtYW5jZSNfVG9jNDE2OTQzNDkwPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QSA2NCBieXRlIG1l c3NhZ2UgaW4gQUVTLUdDTSBBRUFEIGluIEhXIHdvdWxkIHVzZSAxLjAzIGN5Y2xlcyBwZXIgYnl0 ZSBvciA2NiBjeWNsZXMgdG90YWwsIG9yIDIybnMgb24gYSAzR0h6IGNvcmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8ZGl2IGlk PSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5Gb3IgcGFja2V0IG51bWJlcnMgd2UgdXNlIHRoZSBDQkMgZW5jcnlwdCBudW1iZXJzIGJl Y2F1c2UgaGVyZSBBRVMgY2Fubm90IGV4cGxvaXQgYmxvY2sgcGFyYWxsZWxpc20uPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5IZXJlIHdlIHNlZSA0LjQ0IGN5Y2xl cy9ieXRlIGluIEhXIG9yIDcxIGN5Y2xlcyBwZXIgYmxvY2suIFdpdGggYSAzR0h6IHNldHVwIHRo YXQgd291bGQgYW1vdW50IHRvIGFib3V0IDI0bnMgb3ZlcmhlYWQgZm9yIHBhY2tldCBlbmNyeXB0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3Rv bWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNsZWFybHkg aXQgbWFrZXMgbm8gc2Vuc2UgdGhhdCBBRVMtR0NNIGlzIGZhc3RlciB0aGFuIGEgc2luZ2xlIEFF UyBibG9jayBlbmNyeXB0aW9uLCBidXQgdGhlc2UgYXJlIG9ubHkgYXBwcm94aW1hdGUgbnVtYmVy cyBhbmQgQ0JDIG1vZGUgbWlnaHQgaGF2ZSBhIGxpdHRsZSBvdmVyaGVhZCwgc28NCiB3ZSBjbGFt cCBwYWNrZXQgbnVtYmVycyB0byAyMm5zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5UYWtpbmcgdGhlIDk4bnMgb3ZlcmhlYWQgYnkgdGhlIFNvbGFyZmxhcmUgcmVwb3J0IHdl IGdldCBhIHRvdGFsIChzaW1wbGlmaWVkKSBwcm9jZXNzaW5nIHRpbWUgaXMgOThucyBub24tY3J5 cHRvLCAyMm5zIGZvciBwYWNrZXQgbnVtYmVyLCBhbmQgMjJucyBmb3IgQUVBRCB0b3RhbGxpbmcg MTQybnMuDQogU28gdGhlIHBhY2tldCBudW1iZXIgZW5jcnlwdGlvbiBvdmVyaGVhZCB3b3VsZCBi ZSAyMi8oOTgmIzQzOzIyKSoxMDAlID0gMTglLiBUaGUgbnVtYmVycyBpZ25vcmUgb3RoZXIgUVVJ QyBib29ra2VlcGluZywgYnV0IHRoYXQgY2FuIGJlIGRvbmUgaW4gb3RoZXIgY29yZXMgb3Igb3V0 c2lkZSB0aGUgbGF0ZW5jeSBjcml0aWNhbCB3aW5kb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlRoaXMgZG9lcyBub3QgdGFrZSBpbnRvIGFjY291bnQgdGhhdCBBRUFEIG9w ZXJhdGlvbiBtYXkgb3BlcmF0ZSBsZXNzIHRoYW4gb3B0aW1hbCBiZWNhdXNlIHRoZSBwYWNrZXQg bnVtYmVyIG11c3QgYmUgZXh0cmFjdGVkIGZpcnN0LiBPbiB0aGUgb3RoZXIgaGFuZCwgaXQgaXMg YWxzbyBub3QgYSBkaXNhc3Ryb3VzDQogb3ZlcmhlYWQgaWYgbm8gZ29vZCBhbHRlcm5hdGl2ZSBj YW4gYmUgZm91bmQuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29w X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkVh cmxpZXIgQUVTLU5JIEnigJl2ZSBzZWVuIGZyb20gSW50ZWwgZG9jIHN1Z2dlc3RzIGFyb3VuZCAx MDBjeWNsZXMgaW4gSFcgZm9yIGEgc2luZ2xlIEFFUy0xMjggYmxvY2sgd2hpY2ggd291bGQgYmUg MzNucyBwZXIgcGFja2V0IG51bWJlciBpbiB0aGUgYWJvdmUgZXhhbXBsZS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9ImFpcm1haWxvbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDEw IEZlYnJ1YXJ5IDIwMTggYXQgMDYuMTguMjUsIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gKDxh IGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4p IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSBOZXVlJnF1b3Q7O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPjk4bnMgZm9yIDY4 IGJ5dGUgbWVzc2FnZXM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0133D903AD60734920BBC910B6F10CY4PR21MB0133namp_-- From nobody Sat Feb 10 09:19:06 2018 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 214B312D574 for ; Sat, 10 Feb 2018 09:19:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_H4=-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=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 NrzN6ibo7Zlx for ; Sat, 10 Feb 2018 09:19:02 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0093.outbound.protection.outlook.com [104.47.38.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8851276AF for ; Sat, 10 Feb 2018 09:19:02 -0800 (PST) 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=3gry0/svwGl3mTqw9XVEzifxdmtpUrHw0oZFy8ndqpI=; b=gKKRZSlYPfqGrVHu52JjhZHmicl4M8CWidxa6hDGZoPepzpXaAXl3s4m8CHKaMCBkEn3rSPrugs7/MCGFeYc85ZvMAF8U14YfH93tD77CSL7rd7Gc41Cx3OQFfeil5HJL7ZSqpLfxa2m3QloVCAqGBIfmJ00ZVPUn6D4EuNpinw= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0502.namprd21.prod.outlook.com (10.172.122.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Sat, 10 Feb 2018 17:18:59 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Sat, 10 Feb 2018 17:18:59 +0000 From: Praveen Balasubramanian To: "Eggert, Lars" , Ian Swett CC: huitema , "Salz, Rich" , Eric Rescorla , "quic@ietf.org" Subject: RE: hardware offload (was: Packet number encryption) Thread-Topic: hardware offload (was: Packet number encryption) Thread-Index: AQHToeMqYmtt/wnF60OrwLUYIJRfoKOcmxoAgAEXK4CAAC7ggA== Date: Sat, 10 Feb 2018 17:18:59 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> <17971C0F-7BFB-4DCF-A9EE-3128FB180CF2@netapp.com> In-Reply-To: <17971C0F-7BFB-4DCF-A9EE-3128FB180CF2@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0502; 6:r4hWcP+DoWeNtDN7FKpURWPO9GJAe7s2e9LuH5r5Mo8OK1yPHB6w2tNNy+VnxvF/oC3p0cAOQzgHq/HNEyp9s0zHTnxF0A9jW7yS7slDCuhWSzHUVQN68GGVI756So5ytZIG53YwrRSb+7CdWjoMYZchMPvB7PsrTDryeRjoBiokaUYbFkGD+1EEmF0WbwkrAWQw93LTE2wTg/J5JVMEW31Bzj5TF2dNp3+KlL+oBFXHscWJW5IFeX9RMpvrROrAbCkSlT8tVt9I6V8oihZAPJdfYVrVQ3AqNgbcJ38HuaNAf9ZqwhmBDQfeXUyx9q7fLRXMNhVeJpLiN7jvXQMCxGqjYzPywhuiKnDhAGkyJwa+Yt+RW739iv3jXcfA4AHB; 5:3RZCPa/gNR8IoSaZv+Tl/imV8o0hOn9RzW6kPMWpOhgH8kkRbDL98RopRHno2PNsdgLhf4N4G0VYc5/zWIqopFOscCErNvlPpNCJb1NMvNZyZ/ByxCW7rQpRUOAnrwcuGe1eawe14UJZQUBg+cSUyHaDZoxJc8d+ivsf4Hh3TxY=; 24:esKg6bTcXEsf4vNl+P+rzZDTemBNs7KCiy532H1qE97YCF9Z3Pe01bOtyL9YHy6GDjrzetWpGPuVSZKypZ5dvYX2lQkBcq8pcc3PsQVJOks=; 7:oWqHwxjTePWSyBUZXil6SeHTCcrU5ahchMTes0iDg2+/j/+o82v+gZM4nQbLbogfSbsLBXl5WCA/hQLnfrb0TPDgL7R9EKkV2iG3pO2BqwiFNcWEHkNH7uvmlRYJgkb4u4uZaC5K4/01StCyGroQOt01rYQVzbL/B9HehveHsE925Q5iNcZz4DwdhHOg4zH7G5wA5ae+A4PfRz/F2NtTe1J+e/kV9fQVYJNgilJYIcmEUCYWrwjOBThCW/KsXbY2 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: dabba9cb-5b2f-46ac-3d3e-08d570aa5fa7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0502; x-ms-traffictypediagnostic: CY4PR21MB0502: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0502; BCL:0; PCL:0; RULEID:(3232008); SRVR:CY4PR21MB0502; x-forefront-prvs: 057906460E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(39860400002)(346002)(376002)(396003)(199004)(377424004)(189003)(81156014)(97736004)(3660700001)(110136005)(22452003)(54906003)(4001150100001)(2906002)(86362001)(5660300001)(8990500004)(55016002)(316002)(2950100002)(7736002)(3280700002)(74316002)(6116002)(790700001)(81166006)(19609705001)(8936002)(8676002)(10090500001)(2900100001)(106356001)(6506007)(102836004)(86612001)(33656002)(4326008)(53546011)(105586002)(5250100002)(10290500003)(6436002)(14454004)(478600001)(229853002)(99286004)(6306002)(76176011)(236005)(53936002)(9686003)(186003)(6346003)(7696005)(93886005)(54896002)(6246003)(25786009)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0502; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: /CeFBW9j81Ff1qVN9c6x51cIdioKFK2E7ZxoAQGFhZvCPMEd1+8Dgm0KDqRwCbn70M/lpyjL7g1Ri/jzbV3Wtw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB01334422F4AEE04A02A28066B6F10CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: dabba9cb-5b2f-46ac-3d3e-08d570aa5fa7 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2018 17:18:59.2465 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0502 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, 10 Feb 2018 17:19:05 -0000 --_000_CY4PR21MB01334422F4AEE04A02A28066B6F10CY4PR21MB0133namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >> I want to try to push things over to other cores for crypto There might be context switch costs and cache misses. I don't know if this = will be better than just doing it inline on current core. Run to completion= makes for easier to maintain implementation and no locks is great. Plus th= e overall CPU cost of network stack processing will remain the same and may= be even go up a tad bit. From: Eggert, Lars [mailto:lars@netapp.com] Sent: Saturday, February 10, 2018 6:26 AM To: Ian Swett Cc: huitema ; Salz, Rich ; Eric Resc= orla ; quic@ietf.org; Praveen Balasubramanian Subject: Re: hardware offload (was: Packet number encryption) On 2018-2-9, at 13:46, Ian Swett > wrote: Hardware acceleration of AES in modern CPUs is extremely good, so another a= pproach is to do the above in a userspace networking stack or the kernel an= d use the CPU's AES acceleration. If the networking code that was writing = into NIC memory had a deep understanding of QUIC, possibly it could do the = packet number encryption as a second pass? FWIW, this is exactly what I intend on doing with quant, which can sit on t= op of netmap. At the moment, I do the crypto on the same core as anything e= lse (so I can run-to-completion w/o locks), but eventually I want to try to= push things over to other cores for crypto. I'm also chatting with the Cambridge NetFPGA people to see what type of cry= pto (and segmentation offload they could provide that would tie in well wit= h a QUIC stack. Lars --_000_CY4PR21MB01334422F4AEE04A02A28066B6F10CY4PR21MB0133namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>> I want to try to push things over to other = cores for crypto

There might be context switch costs and cache misses= . I don’t know if this will be better than just doing it inline on cu= rrent core. Run to completion makes for easier to maintain implementation a= nd no locks is great. Plus the overall CPU cost of network stack processing will remain the same and maybe even go up= a tad bit.

 

From: Eggert, Lars [mailto:lars@netapp.com] <= br> Sent: Saturday, February 10, 2018 6:26 AM
To: Ian Swett <ianswett@google.com>
Cc: huitema <huitema@huitema.net>; Salz, Rich <rsalz@akamai= .com>; Eric Rescorla <ekr@rtfm.com>; quic@ietf.org; Praveen Balasu= bramanian <pravb@microsoft.com>
Subject: Re: hardware offload (was: Packet number encryption)

 

On 2018-2-9, at 13:46, Ian Swett <ianswett@google.com> wrote:

Hardware acceleration of AES in modern CPUs is extr= emely good, so another approach is to do the above in a userspace networkin= g stack or the kernel and use the CPU's AES acceleration.  If the networking code that was writing into NIC memory had a deep underst= anding of QUIC, possibly it could do the packet number encryption as a seco= nd pass?

 

FWIW, this is exactly what I intend on doing with qu= ant, which can sit on top of netmap. At the moment, I do the crypto on the = same core as anything else (so I can run-to-completion w/o locks), but even= tually I want to try to push things over to other cores for crypto.

 

I'm also chatting with the Cambridge NetFPGA people = to see what type of crypto (and segmentation offload they could provide tha= t would tie in well with a QUIC stack.

 

Lars

--_000_CY4PR21MB01334422F4AEE04A02A28066B6F10CY4PR21MB0133namp_-- From nobody Sat Feb 10 09:34:55 2018 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 1239B1276AF for ; Sat, 10 Feb 2018 09:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 4cW6RKOvXJaU for ; Sat, 10 Feb 2018 09:34:52 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FEB126B72 for ; Sat, 10 Feb 2018 09:34:52 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id A7244414C0 for ; Sat, 10 Feb 2018 18:34:50 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 8F79A120059 for ; Sat, 10 Feb 2018 18:34:50 +0100 (CET) Received: from lat6466.rd.francetelecom.fr (10.168.234.2) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 10 Feb 2018 18:34:50 +0100 Message-ID: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> Date: Sat, 10 Feb 2018 18:34:54 +0100 From: User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: "quic@ietf.org" Subject: Measurement bit(s) or not Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.2] 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, 10 Feb 2018 17:34:54 -0000 On 07/02/2018 14:34, Brian Trammell (IETF) wrote: > hi Jana, > >> 3. Some sequencing information -- a few bits of the packet number perhaps >> -- should be revealed (for monitoring. Number of bits TBD.) > > This is the crux of the argument. On one side we have the risk of misuse and > ossification (well, not ossification -- these bits are *meant* for the path > -- rather the risk that we'll figure out later that we specified the wrong > thing), on the other side we have the loss of visibility into how QUIC > traffic interacts with the network as compared to TCP, with a side question > of whether or not this visibility is really the transport layer's problem > despite the evolution the practice of diagnostics and troubleshooting using > TCP information. > > If we can come to agreement on this question, everything else falls into > place. I have my arguments here, but as you said, this subthread is not the > place for them. :) The crux indeed. So what about settling it first ? With the troubleshooting hat, I can only stress the need for measurement bits, for the benefit of everybody, since s**t happens, networks are imperfect, and nifty encapsulations-with-seqnum will simply not be where you need them. Now to the exact nature of these measurement bits: Thanks to the detailed exchanges on this thread, it is by now clear that a simple gapless counter, even nonzero-based and XORed, is not acceptable. The 4-bit SSN comes pretty close but is not enough when things go really wrong (and they will - and that's where we need the tool). Then Kazuho's square signal and Mikkel's Pi (or any other consensual self-synchronizing sequence) ramification came up. They are both appealing for their elegance and low complexity on QUIC endpoints. Beyond their quirks acknowledged here, here are a few considerations for troubleshooting: (1) Since reordering is less of a concern to QUIC than to TCP, it becomes a secondary goal. This is nice, because the square doesn't see it, and the self-synchronizing sequence will only tolerate a mild one, and never see its detail like cycle length etc. (2) There's of course a huge difference between them in complexity for the midpoint: square is trivial, Pi is hefty. Given these, a benevolent, troubleshooting-minded passive midpoint will clearly vote for the square. Now the obvious question is: is this acceptable, or deemed too easy for a Murphy, Inc. active middlebox to see upstream losses and benevolently wreak havoc by delaying packets ? _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Sat Feb 10 10:02:03 2018 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 6FF2C128896 for ; Sat, 10 Feb 2018 10:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, 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 pBmQKJfX-pTH for ; Sat, 10 Feb 2018 10:01:58 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 412A71200FC for ; Sat, 10 Feb 2018 10:01:58 -0800 (PST) Received: from [10.1.92.143] (unknown [148.252.128.223]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 56BFB1B00282; Sat, 10 Feb 2018 18:01:57 +0000 (GMT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Measurement bit(s) or not From: "Gorry (erg)" X-Mailer: iPhone Mail (15C202) In-Reply-To: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> Date: Sat, 10 Feb 2018 18:01:55 +0000 Cc: "quic@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> To: alexandre.ferrieux@orange.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: Sat, 10 Feb 2018 18:02:01 -0000 > On 10 Feb 2018, at 17:34, wrote: >=20 > On 07/02/2018 14:34, Brian Trammell (IETF) wrote: > > hi Jana, > > > >> 3. Some sequencing information -- a few bits of the packet number perha= ps > >> -- should be revealed (for monitoring. Number of bits TBD.) > > > > This is the crux of the argument. On one side we have the risk of misuse= and > > ossification (well, not ossification -- these bits are *meant* for the p= ath > > -- rather the risk that we'll figure out later that we specified the wro= ng > > thing), on the other side we have the loss of visibility into how QUIC > > traffic interacts with the network as compared to TCP, with a side quest= ion > > of whether or not this visibility is really the transport layer's proble= m > > despite the evolution the practice of diagnostics and troubleshooting us= ing > > TCP information. > > > > If we can come to agreement on this question, everything else falls into= > > place. I have my arguments here, but as you said, this subthread is not t= he > > place for them. :) > The crux indeed. So what about settling it first ? >=20 > With the troubleshooting hat, I can only stress the need for measurement b= its, for the benefit of everybody, since s**t happens, networks are imperfec= t, and nifty encapsulations-with-seqnum will simply not be where you need th= em. >=20 +1 ... at the time when this is most useful for troubleshooting, a lot may be h= appening that is not normal. > Now to the exact nature of these measurement bits: >=20 > Thanks to the detailed exchanges on this thread, it is by now clear that a= simple gapless counter, even nonzero-based and XORed, is not acceptable. Again +1 > The 4-bit SSN comes pretty close but is not enough when things go really w= rong (and they will - and that's where we need the tool). >=20 8 bits could be enough - and still would be les than 0.1% overhead. > Then Kazuho's square signal and Mikkel's Pi (or any other consensual self-= synchronizing sequence) ramification came up. They are both appealing for th= eir elegance and low complexity on QUIC endpoints. Beyond their quirks ackno= wledged here, here are a few considerations for troubleshooting: >=20 > (1) Since reordering is less of a concern to QUIC than to TCP, it becomes a= secondary goal. This is nice, because the square doesn't see it, and the se= lf-synchronizing sequence will only tolerate a mild one, and never see its d= etail like cycle length etc. Being able to observe that the network is doing this could still be good whe= n debugging network faults. >=20 > (2) There's of course a huge difference between them in complexity for the= midpoint: square is trivial, Pi is hefty. >=20 > Given these, a benevolent, troubleshooting-minded passive midpoint will cl= early vote for the square. Now the obvious question is: is this acceptable, o= r deemed too easy for a Murphy, Inc. active middlebox to see upstream losses= and benevolently wreak havoc by delaying packets ? >=20 No amount of encryption is going to actually prevent a middlebox/tunnel/lowe= r layer doing things - such as link retransmission. Gorry > __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confide= ntielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez rec= u ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged in= formation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and del= ete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been= modified, changed or falsified. > Thank you. From nobody Sat Feb 10 10:22:48 2018 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 E478512946D for ; Sat, 10 Feb 2018 10:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_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=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 MtQsac-v6398 for ; Sat, 10 Feb 2018 10:22:44 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0093.outbound.protection.outlook.com [104.47.36.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B07E812426E for ; Sat, 10 Feb 2018 10:22:44 -0800 (PST) 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=GP8n7j9ICg6T1B4m9CXCDUhC0D1eAg7LrvZexzR9ejY=; b=OQFPSqPFDnqouOG/jhkwwoSgxKEV7gwLY0e5g36lxRk7+a2+wg8TnQKoT1Oag3M3SGskICvNFch0U+KqlaJel2MeFHwEnc7F0gGPeQagnzhvmmuT5qS2gM2SCfVN0MZgvxZqBObOtLvu3uLyO6hf1V/FsmO3PF+y5NX8sCbJLWg= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0278.namprd21.prod.outlook.com (10.173.193.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.3; Sat, 10 Feb 2018 18:22:42 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::f4bd:bebf:7ea5:7dc5%6]) with mapi id 15.20.0506.011; Sat, 10 Feb 2018 18:22:42 +0000 From: Praveen Balasubramanian To: "Salz, Rich" CC: "quic@ietf.org" Subject: RE: Packet number encryption Thread-Topic: Packet number encryption Thread-Index: AQHTmW31V+0GAWpR/E2VqOCVLx9SYqOMgUQAgABeoYCAAAgUAIAAd3KAgAA8YgCAACPEAIAAAiYAgAOBloCAALfdgIAACBkAgAEGGACAANx9AIAAn5KAgAB7w4CAADUigIAADBeAgADUsaCAAGk3gIAAEEgAgACizACAADhiAIAAHkiAgAADUYCAACdFAIAAVRYAgAAUZQCAAA5oAIAAD4fQgABGjACAAAGHQIAACNQAgAAAqaCAAAeBgIAAC4qAgACi02CAAe6PgIAACzgAgAARh3CAAEwGwIAAjJeAgAA5dnCAAAb3gIAAF6YAgABLbACAAAD8AA== Date: Sat, 10 Feb 2018 18:22:42 +0000 Message-ID: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0278; 7:ykhC9aUp06AkvPHtfHcLg7q5fG17cs+nl9Ov/J7WVn4HlHzIetVkddIpbihAeuMlL5yItyOJwMFAEw3jM1XnIAUVgRRzdZWj6n3WDFH+jzOpVRJfGiZNgPCP+7537m6kmCC+kJt6vXwMgbEVNE74XylFrcP9Y3rjiHLN647+xx4HumNrbDfm10TRpUN6epDyVyDqVRyO6mUKhX0SYNYQtXnlbmOKS9NVIXOBSsZUiuyvjbahUjoC8OQwzSLLOkvn x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3e10b9b2-c3c6-4086-5973-08d570b3468e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0278; x-ms-traffictypediagnostic: CY4PR21MB0278: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(89211679590171)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR21MB0278; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0278; x-forefront-prvs: 057906460E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(396003)(39380400002)(376002)(199004)(189003)(25786009)(10290500003)(6116002)(6916009)(790700001)(8990500004)(7736002)(8936002)(4326008)(97736004)(22452003)(2950100002)(5660300001)(86362001)(33656002)(106356001)(7116003)(316002)(186003)(7696005)(2900100001)(478600001)(3280700002)(229853002)(81166006)(6246003)(59450400001)(55016002)(6306002)(99286004)(81156014)(74316002)(5250100002)(76176011)(53936002)(14454004)(3480700004)(8676002)(54896002)(68736007)(93886005)(6506007)(53546011)(9686003)(10090500001)(6346003)(86612001)(3660700001)(2906002)(102836004)(6436002)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0278; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: H0T4/zScaMxJ9bbS2ojjuhtSCNMRTJDsQun7yVoLThoTFCWYhgkfLa4M2nrrJ4BfvcX6wRSU4AeVrrJ+fcvc+g== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0133C5FB4961311E4C1523B5B6F10CY4PR21MB0133namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e10b9b2-c3c6-4086-5973-08d570b3468e X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Feb 2018 18:22:42.6265 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0278 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, 10 Feb 2018 18:22:47 -0000 --_000_CY4PR21MB0133C5FB4961311E4C1523B5B6F10CY4PR21MB0133namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gYSBwYWNrZXQgbnVtYmVyICpleGFjdGx5KiBtZWV0cyB0aGUgcmVxdWlyZW1lbnRzIG9mIGFu IGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGVkIG5vbmNlLiBOb3QgdXNpbmcgaXQgZm9yIHRoYXQgcHVy cG9zZSBpcyBiZWluZyB3YXN0ZWZ1bCBmb3IgYWJzb2x1dGVseSBubyBnb29kIHJlYXNvbi4NCkZv ciBiZXR0ZXIgb3Igd29yc2Ugd2UgaGF2ZSBjaG9zZW4gdG8gdGllIHRoZSB0cmFuc3BvcnQgdmVy eSB0aWdodGx5IHdpdGggVExTLiBUaGlzIG1lYW5zIGV4dHJhIHdvcmsgd2lsbCBiZSBuZWVkZWQg Zm9yIHVuZW5jcnlwdGVkIFFVSUMgb3IgUVVJQyBvdmVyIElQc2VjIGZvciBleGFtcGxlLiBDYXNl IGluIHBvaW50IHRyYW5zcG9ydCBwYXJhbWV0ZXJzIG5vdCBiZWluZyBpbiB0aGUgdHJhbnNwb3J0 IGhlYWRlciBidXQgcmF0aGVyIGluIHRoZSBUTFMgaGVhZGVyLiBJbiBIVFRQUyBvdmVyIFRDUCwg VExTIHdpbGwgdXNlIGl0cyBvd24gc2VxdWVuY2UgbnVtYmVyIGZvciBub25jZSBhbmQgVENQIHdp bGwgaGF2ZSBpdHMgb3duIHNlcXVlbmNlIG51bWJlci4gVGhpcyBpcyBhIGNsZWFyIHNlcGFyYXRp b24gb2YgY29uY2VybnMuIEZyb20gd2hhdCBJIGNhbiB0ZWxsLCBzaW5jZSBRVUlDIHVzZXMgaXRz IG93biBwYWNrZXQgZnJhbWluZyBhbmQgdGhlIFBOIGRvZXNu4oCZdCByZXBlYXQgd2UgaGF2ZSB0 cmllZCB0byBvcHRpbWl6ZSB0aGlzIGJ5IG92ZXJsb2FkaW5nIGl0IHdpdGggdGhlIG5vbmNlLg0K DQpUaGF0IHNhaWQgbm90aGluZyBwcmV2ZW50cyBhbiBpbXBsZW1lbnRhdGlvbiBmcm9tIHVzaW5n IHRoZSBwYWNrZXQgbnVtYmVyIGFzIHRoZSBub25jZS4gQnkgc2VwYXJhdGluZyBjb25jZXJucyBv bmUgY2FuIHBpY2sgd2hhdGV2ZXIgb25lIHdhbnRzIGZvciB0aGUgbm9uY2UsIHRoZSByZWNlaXZl ciBkb2VzbuKAmXQgY2FyZSBhYm91dCB0aGUgbm9uY2UgdmFsdWUgb3RoZXIgdGhhbiBmb3IgZGVj cnlwdGlvbiBpLmUuIG5vIGltcGFjdCBvbiB0cmFuc3BvcnQgbG9naWMuIFdlIGNhbiB1c2UgYSBW TEUgZmllbGQgb3Igb3RoZXIgbWV0aG9kcyB0byByZWR1Y2UgdGhlIGV4dHJhIHNwYWNlIG5lZWRl ZCBmb3IgdGhlIFBOLg0KDQo+PiBhbmQgdGhlbiBlbmNyeXB0aW5nIHRoZSBub25jZQ0KWW91IGRv buKAmXQgaGF2ZSB0byBidXQgeW91IGNhbiAuIFRoZSBvbmx5IGZ1bmN0aW9uYWwgcmVxdWlyZW1l bnQgZm9yIHRoZSBub25jZSBpcyBub24tcmVwZWF0YWJpbGl0eS4gRW5jcnlwdGlvbiBpcyBvbmx5 IGJlaW5nIGNvbnNpZGVyZWQgZm9yIG9zc2lmaWNhdGlvbiBhbmQgdW5saW5rYWJpbGl0eSBjb25j ZXJucy4gRm9yIGNvbm5lY3Rpb25zIHRoYXQgZG9u4oCZdCBjYXJlIGFib3V0IHVubGlua2FiaWxp dHkgKG5vIG1pZ3JhdGlvbiwgbm8gbXVsdGkgcGF0aCkgdGhlIG92ZXJoZWFkIGlzIG5vdCB3b3J0 aCBpdC4gT3NzaWZpY2F0aW9uIGNhbiBiZSBhdm9pZGVkIGJ5IGEgcmFuZG9tIGluaXRpYWwgdmFs dWUgYW5kIGp1bXBzIGluIGJldHdlZW4gc2luY2UgdGhpcyBpcyBhIGZvcm0gb2YgZ3JlYXNpbmcu DQoNCj4+IERvIHlvdSBoYXZlIGEgbm9uLWF1dGhlbnRpY2F0ZWQgY3J5cHRvIG1lY2hhbmlzbSB3 ZSBzaG91bGQgY29uc2lkZXI/DQpJIGFtIG5vdCBhIGNyeXB0byBleHBlcnQuIEkgZG9u4oCZdCBr bm93IHdoYXQgZnV0dXJlIGNyeXB0byB3aWxsIGxvb2sgbGlrZS4gTWFraW5nIHRoZSBub25jZSBm aWVsZCBvcHRpb25hbCBvciBsYXJnZXIgc2l6ZSB3aGVuIG5lZWRlZCAoYnV0IG5vdCB2YXJpYWJs ZSBmb3IgZ2l2ZW4gY29ubmVjdGlvbikgYWxsb3dzIHRoZSB0cmFuc3BvcnQgcHJvdG9jb2wgdG8g YmUgbW9yZSBmdXR1cmUgcHJvb2YuIEZvcmNpbmcgdGhlIFBOIHRvIGJlIHRoZSBub25jZSBtYWtl cyB0aGluZ3MgbW9yZSBpbmZsZXhpYmxlLiBJIGNhcmUgbXVjaCBsZXNzIGFib3V0IHRoZSBub25j ZSBnZXR0aW5nIG9zc2lmaWVkIGNvbXBhcmVkIHRvIHRoZSBQTi4NCg0KRnJvbTogU2FseiwgUmlj aCBbbWFpbHRvOnJzYWx6QGFrYW1haS5jb21dDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDksIDIw MTggMzozNyBQTQ0KVG86IFByYXZlZW4gQmFsYXN1YnJhbWFuaWFuIDxwcmF2YkBtaWNyb3NvZnQu Y29tPg0KQ2M6IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5 cHRpb24NCg0KPiBDbGVhciBzZXBhcmF0aW9uIG9mIGNvbmNlcm5zIHJlc3VsdHMgaWYgd2UgZG9u 4oCZdCBvdmVybG9hZCB0aGUgcGFja2V0IG51bWJlciBhcyB0aGUgbm9uY2UuIENvbm5lY3Rpb24g bWlncmF0aW9uIGFuZCBtdWx0aS1wYXRoIGFyZSBvcHRpb25hbCBmZWF0dXJlcyBhbmQgd2UgcGF5 IG5vIGV4dHJhIGNvbXB1dGUgY29zdCBmb3IgbW9zdCBjb25uZWN0aW9ucyB0aGF0IGFyZSBub3Qg aW1wYWN0ZWQgYnkgdW5sbmthYmlsaXR5LiBOb25jZSBmaWVsZCBiZWNvbWVzIG9wdGlvbmFsIGZv ciBjcnlwdG8gdGhhdCBkb2VzbuKAmXQgbmVlZCBpdCBhbmQgY2FuIGdyb3cgdG8gbGFyZ2VyIHNp emUgYXMgbmVlZGVkIGZvciBidWxrIHRyYW5zZmVycyB0byBwcmV2ZW50IGZyZXF1ZW50IGtleSBy b2xsb3ZlcnMgKHNheSBpbiBkYXRhY2VudGVyIHNjZW5hcmlvcykuDQoNCkRhdmlkIGFscmVhZHkg cmVwbGllZCBwcmV0dHkgZGVmaW5pdGl2ZWx5LCBidXQgZm9yIHRob3NlIG5vdCBvbiBoaXMgbGV2 ZWwg4oCmDQoNCkl0IHNlZW1zIGhpZ2hseSB1bmxpa2VseSB0aGF0IHdlIHdpbGwgd2FudCB0byB1 c2Ugbm9uLWF1dGhlbnRpY2F0ZWQgY3J5cHRvIOKAkyBpZS4sIEFFQUQgb3Igc2ltaWxhci4gIFRM UyAxLjMgaXMgYWxsIGFuZCBvbmx5IGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbi4gIFRoZSBkaWZm ZXJlbmNlIGluIGNvc3QgaXMgYSBmZXcgZXh0cmEgYnl0ZXMgb2YgZW5jcnlwdGlvbiwgYXMgb3Bw b3NlZCB0byBiaWdnZXIgcGFja2V0cyBmb3IgcGxhaW50ZXh0IGFuZCB0aGVuIGVuY3J5cHRpbmcg dGhlIG5vbmNlLCByaWdodD8gIFRoYXQgZGlmZmVyZW5jZSBzaG91bGQgYmUgaGFyZCB0byBub3Rp Y2UuDQoNCklmIHdlIGFzc3VtZSBpdOKAmXMgYWxsIGF1dGhlbnRpY2F0ZWQgY3J5cHRvLCBhbmQg dGhlcmVmb3JlIHdlIG5lZWQgYSBub25jZSwgdGhlbiBzZXBhcmF0aW9uIG9mIGNvbmNlcm5zIGJl Y29tZXMgYSBub24taXNzdWUuIEluIGZhY3QsIGFzIERhdmlkIHBvaW50ZWQgb3V0LCBhIHBhY2tl dCBudW1iZXIgKmV4YWN0bHkqIG1lZXRzIHRoZSByZXF1aXJlbWVudHMgb2YgYW4gYXV0aGVudGlj YXRlZCBlbmNyeXB0ZWQgbm9uY2UuIE5vdCB1c2luZyBpdCBmb3IgdGhhdCBwdXJwb3NlIGlzIGJl aW5nIHdhc3RlZnVsIGZvciBhYnNvbHV0ZWx5IG5vIGdvb2QgcmVhc29uLg0KDQpEbyB5b3UgaGF2 ZSBhIG5vbi1hdXRoZW50aWNhdGVkIGNyeXB0byBtZWNoYW5pc20gd2Ugc2hvdWxkIGNvbnNpZGVy Pw0K --_000_CY4PR21MB0133C5FB4961311E4C1523B5B6F10CY4PR21MB0133namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZndDsmZ3Q7IGEgcGFja2V0IG51bWJlciAqPGI+ZXhhY3RseTwvYj4qIG1lZXRz IHRoZSByZXF1aXJlbWVudHMgb2YgYW4gYXV0aGVudGljYXRlZCBlbmNyeXB0ZWQgbm9uY2UuIE5v dCB1c2luZyBpdCBmb3IgdGhhdCBwdXJwb3NlIGlzIGJlaW5nIHdhc3RlZnVsIGZvciBhYnNvbHV0 ZWx5IG5vIGdvb2QgcmVhc29uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Rm9yIGJldHRlciBvciB3b3JzZSB3ZSBoYXZlIGNob3NlbiB0byB0aWUgdGhlIHRyYW5zcG9ydCB2 ZXJ5IHRpZ2h0bHkgd2l0aCBUTFMuIFRoaXMgbWVhbnMgZXh0cmEgd29yayB3aWxsIGJlIG5lZWRl ZCBmb3IgdW5lbmNyeXB0ZWQgUVVJQyBvciBRVUlDIG92ZXIgSVBzZWMgZm9yIGV4YW1wbGUuIENh c2UgaW4gcG9pbnQgdHJhbnNwb3J0IHBhcmFtZXRlcnMgbm90IGJlaW5nIGluIHRoZSB0cmFuc3Bv cnQgaGVhZGVyDQogYnV0IHJhdGhlciBpbiB0aGUgVExTIGhlYWRlci4gSW4gSFRUUFMgb3ZlciBU Q1AsIFRMUyB3aWxsIHVzZSBpdHMgb3duIHNlcXVlbmNlIG51bWJlciBmb3Igbm9uY2UgYW5kIFRD UCB3aWxsIGhhdmUgaXRzIG93biBzZXF1ZW5jZSBudW1iZXIuIFRoaXMgaXMgYSBjbGVhciBzZXBh cmF0aW9uIG9mIGNvbmNlcm5zLiBGcm9tIHdoYXQgSSBjYW4gdGVsbCwgc2luY2UgUVVJQyB1c2Vz IGl0cyBvd24gcGFja2V0IGZyYW1pbmcgYW5kIHRoZSBQTiBkb2VzbuKAmXQNCiByZXBlYXQgd2Ug aGF2ZSB0cmllZCB0byBvcHRpbWl6ZSB0aGlzIGJ5IG92ZXJsb2FkaW5nIGl0IHdpdGggdGhlIG5v bmNlLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBzYWlkIG5vdGhpbmcgcHJldmVudHMg YW4gaW1wbGVtZW50YXRpb24gZnJvbSB1c2luZyB0aGUgcGFja2V0IG51bWJlciBhcyB0aGUgbm9u Y2UuIEJ5IHNlcGFyYXRpbmcgY29uY2VybnMgb25lIGNhbiBwaWNrIHdoYXRldmVyIG9uZSB3YW50 cyBmb3IgdGhlIG5vbmNlLCB0aGUgcmVjZWl2ZXIgZG9lc27igJl0IGNhcmUgYWJvdXQgdGhlIG5v bmNlIHZhbHVlIG90aGVyIHRoYW4gZm9yIGRlY3J5cHRpb24gaS5lLg0KIG5vIGltcGFjdCBvbiB0 cmFuc3BvcnQgbG9naWMuIFdlIGNhbiB1c2UgYSBWTEUgZmllbGQgb3Igb3RoZXIgbWV0aG9kcyB0 byByZWR1Y2UgdGhlIGV4dHJhIHNwYWNlIG5lZWRlZCBmb3IgdGhlIFBOLg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZndDsmZ3Q7IGFuZCB0aGVuIGVuY3J5cHRpbmcgdGhlIG5vbmNlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgZG9u4oCZdCBoYXZlIHRvIGJ1dCB5 b3UgY2FuIC4gVGhlIG9ubHkgPGk+ZnVuY3Rpb25hbDwvaT4gcmVxdWlyZW1lbnQgZm9yIHRoZSBu b25jZSBpcyBub24tcmVwZWF0YWJpbGl0eS4gRW5jcnlwdGlvbiBpcyBvbmx5IGJlaW5nIGNvbnNp ZGVyZWQgZm9yIG9zc2lmaWNhdGlvbiBhbmQgdW5saW5rYWJpbGl0eSBjb25jZXJucy4gRm9yIGNv bm5lY3Rpb25zIHRoYXQgZG9u4oCZdCBjYXJlIGFib3V0IHVubGlua2FiaWxpdHkNCiAobm8gbWln cmF0aW9uLCBubyBtdWx0aSBwYXRoKSB0aGUgb3ZlcmhlYWQgaXMgbm90IHdvcnRoIGl0LiBPc3Np ZmljYXRpb24gY2FuIGJlIGF2b2lkZWQgYnkgYSByYW5kb20gaW5pdGlhbCB2YWx1ZSBhbmQganVt cHMgaW4gYmV0d2VlbiBzaW5jZSB0aGlzIGlzIGEgZm9ybSBvZiBncmVhc2luZy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyZndDsgRG8geW91IGhhdmUgYSBub24tYXV0aGVudGljYXRlZCBj cnlwdG8gbWVjaGFuaXNtIHdlIHNob3VsZCBjb25zaWRlcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgYW0gbm90IGEgY3J5cHRvIGV4cGVydC4gSSBkb27igJl0IGtub3cg d2hhdCBmdXR1cmUgY3J5cHRvIHdpbGwgbG9vayBsaWtlLiBNYWtpbmcgdGhlIG5vbmNlIGZpZWxk IG9wdGlvbmFsIG9yIGxhcmdlciBzaXplIHdoZW4gbmVlZGVkIChidXQgbm90IHZhcmlhYmxlIGZv ciBnaXZlbiBjb25uZWN0aW9uKSBhbGxvd3MgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCB0byBiZSBt b3JlIGZ1dHVyZSBwcm9vZi4gRm9yY2luZw0KIHRoZSBQTiB0byBiZSB0aGUgbm9uY2UgbWFrZXMg dGhpbmdzIG1vcmUgaW5mbGV4aWJsZS4gSSBjYXJlIG11Y2ggbGVzcyBhYm91dCB0aGUgbm9uY2Ug Z2V0dGluZyBvc3NpZmllZCBjb21wYXJlZCB0byB0aGUgUE4uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gU2Fseiwg UmljaCBbbWFpbHRvOnJzYWx6QGFrYW1haS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IEZlYnJ1YXJ5IDksIDIwMTggMzozNyBQTTxicj4NCjxiPlRvOjwvYj4gUHJhdmVlbiBCYWxhc3Vi cmFtYW5pYW4gJmx0O3ByYXZiQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBxdWlj QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBQYWNrZXQgbnVtYmVyIGVuY3J5cHRp b248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWls T3JpZ2luYWxCb2R5Ij4mZ3Q7IENsZWFyIHNlcGFyYXRpb24gb2YgY29uY2VybnMgcmVzdWx0cyBp ZiB3ZSBkb27igJl0IG92ZXJsb2FkIHRoZSBwYWNrZXQgbnVtYmVyIGFzIHRoZSBub25jZS4gQ29u bmVjdGlvbiBtaWdyYXRpb24gYW5kIG11bHRpLXBhdGggYXJlIG9wdGlvbmFsIGZlYXR1cmVzIGFu ZCB3ZSBwYXkgbm8gZXh0cmEgY29tcHV0ZSBjb3N0IGZvciBtb3N0IGNvbm5lY3Rpb25zIHRoYXQN CiBhcmUgbm90IGltcGFjdGVkIGJ5IHVubG5rYWJpbGl0eS4gTm9uY2UgZmllbGQgYmVjb21lcyBv cHRpb25hbCBmb3IgY3J5cHRvIHRoYXQgZG9lc27igJl0IG5lZWQgaXQgYW5kIGNhbiBncm93IHRv IGxhcmdlciBzaXplIGFzIG5lZWRlZCBmb3IgYnVsayB0cmFuc2ZlcnMgdG8gcHJldmVudCBmcmVx dWVudCBrZXkgcm9sbG92ZXJzIChzYXkgaW4gZGF0YWNlbnRlciBzY2VuYXJpb3MpLg0KPG86cD48 L286cD48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29r bWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFs Qm9keSI+RGF2aWQgYWxyZWFkeSByZXBsaWVkIHByZXR0eSBkZWZpbml0aXZlbHksIGJ1dCBmb3Ig dGhvc2Ugbm90IG9uIGhpcyBsZXZlbCDigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5JdCBzZWVtcyBoaWdobHkg dW5saWtlbHkgdGhhdCB3ZSB3aWxsIHdhbnQgdG8gdXNlIG5vbi1hdXRoZW50aWNhdGVkIGNyeXB0 byDigJMgaWUuLCBBRUFEIG9yIHNpbWlsYXIuJm5ic3A7IFRMUyAxLjMgaXMgYWxsIGFuZCBvbmx5 IGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbi4mbmJzcDsgVGhlIGRpZmZlcmVuY2UgaW4gY29zdCBp cyBhIGZldyBleHRyYSBieXRlcw0KIG9mIGVuY3J5cHRpb24sIGFzIG9wcG9zZWQgdG8gYmlnZ2Vy IHBhY2tldHMgZm9yIHBsYWludGV4dCBhbmQgdGhlbiBlbmNyeXB0aW5nIHRoZSBub25jZSwgcmln aHQ/Jm5ic3A7IFRoYXQgZGlmZmVyZW5jZSBzaG91bGQgYmUgaGFyZCB0byBub3RpY2UuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdp bmFsQm9keSI+SWYgd2UgYXNzdW1lIGl04oCZcyBhbGwgYXV0aGVudGljYXRlZCBjcnlwdG8sIGFu ZCB0aGVyZWZvcmUgd2UgbmVlZCBhIG5vbmNlLCB0aGVuIHNlcGFyYXRpb24gb2YgY29uY2VybnMg YmVjb21lcyBhIG5vbi1pc3N1ZS4gSW4gZmFjdCwgYXMgRGF2aWQgcG9pbnRlZCBvdXQsIGEgcGFj a2V0IG51bWJlciAqPGI+ZXhhY3RseTwvYj4qIG1lZXRzDQogdGhlIHJlcXVpcmVtZW50cyBvZiBh biBhdXRoZW50aWNhdGVkIGVuY3J5cHRlZCBub25jZS4gTm90IHVzaW5nIGl0IGZvciB0aGF0IHB1 cnBvc2UgaXMgYmVpbmcgd2FzdGVmdWwgZm9yIGFic29sdXRlbHkgbm8gZ29vZCByZWFzb24uPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9y aWdpbmFsQm9keSI+RG8geW91IGhhdmUgYSBub24tYXV0aGVudGljYXRlZCBjcnlwdG8gbWVjaGFu aXNtIHdlIHNob3VsZCBjb25zaWRlcj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_CY4PR21MB0133C5FB4961311E4C1523B5B6F10CY4PR21MB0133namp_-- From nobody Sat Feb 10 11:44:43 2018 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 5E0B012DA22 for ; Sat, 10 Feb 2018 11:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, UNPARSEABLE_RELAY=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 fivLuN1tgfxG for ; Sat, 10 Feb 2018 11:44:40 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 6AC6812D77B for ; Sat, 10 Feb 2018 11:44:40 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id j21so2423955ita.1 for ; Sat, 10 Feb 2018 11:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=hef7Zex8XoMMTXklLqNJ6GVQjXzZsAY6sK/T6cXzHeQ=; b=TMRLiS2ukwxOmVWnZ7LU54UyLZi9vIjNS2RMIaeqZmcrPINjh0KZaSyz+ihqf5bqmt SJHY35Rz8CFHGwg2AUAQ/oHrful2IMSH8KFwi2BgaICcbahqr+1zULmrdEWWwbhwWwvR CPP3kVUxw7XRpeE8b60poGIJu8rWVCv6R7PAEttPYZSQwxBCVUTsKwusbgN6JsuXYMjl WzkssjUexbte5IDstUDK0dWFpg24NTRpcmLjuxiJFWDg6jfW/UQdRrTHVafx5eyYgMsy xYJ1LPMzUY01UDHRvkLI0kZ8zGEjcRUjofvvCmIFUJvwvU/PtffbYnbtWkp1Vf1UT5aX Y7lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=hef7Zex8XoMMTXklLqNJ6GVQjXzZsAY6sK/T6cXzHeQ=; b=HqnurqAb6RxKH19YPSrTM+AA5+VnOKSDmc5aDCEA69QIY8BWlOoGjOlmvS47JWEGup HHoAZ3h7jLDsHys3vrMA6YfbMF2i3772EdzcdCasvAYsfoPtoU981EFNUWl8QNAlRJcu a5l2iUQssLajHXsowULnMdWA+11AddSm042rHt1+eB1nsk9SX0nSjgV8YvjoeRU1Hc0Z 7KlbzHaiGAty4BxD46dGO6LM4qWuRamNDqJw1obQ0PSGIQTSDjnJwY1fx2F8Do1HYCdl eYf83EmfM/KZYATtMGWqDLf22lgxuvS0fArn79ZVIIi2LeD0jyavCSABB/rcKDbSD14v XbVw== X-Gm-Message-State: APf1xPCgdEpWZTZOC9r7WDHB2MaGVVbp7ZtqxrrmyYKFtkF8tdCviq4P vl+W1gx0sWzwC/zqwY4U6rEgKsqtKvxJU/dXU/0= X-Google-Smtp-Source: AH8x225FLyiWtwsoZq4KO3q81CsKydrrO/6PpScBSjybd6g8B+ZBCN+f7BF5GtJVEvZK+TNpHpaYMauyCnG4O6aJk2c= X-Received: by 10.36.10.207 with SMTP id 198mr8264271itw.42.1518291879828; Sat, 10 Feb 2018 11:44:39 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 10 Feb 2018 13:44:38 -0600 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> <533a0a2e-3a87-b55f-84ce-c52bc03cd81c@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 10 Feb 2018 13:44:38 -0600 Message-ID: Subject: RE: Packet number encryption To: "Salz, Rich" , Praveen Balasubramanian Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a1144b82829a12d0564e0e09f" 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, 10 Feb 2018 19:44:42 -0000 --001a1144b82829a12d0564e0e09f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I wrote up my previous suggestion to use segmented packet numbers with clear text nonce in an issue, and I added a comment where I propose a variation that encrypts the nonce, but this encryption is 16 times faster than the current packet number encryption scheme. In both cases there is no duplication of nonce and packet numbers because they are the same modulo path. https://github.com/quicwg/base-drafts/issues/1105 On 10 February 2018 at 19.22.50, Praveen Balasubramanian ( pravb@microsoft.com) wrote: >> a packet number **exactly** meets the requirements of an authenticated encrypted nonce. Not using it for that purpose is being wasteful for absolutely no good reason. For better or worse we have chosen to tie the transport very tightly with TLS. This means extra work will be needed for unencrypted QUIC or QUIC over IPsec for example. Case in point transport parameters not being in the transport header but rather in the TLS header. In HTTPS over TCP, TLS will use its own sequence number for nonce and TCP will have its own sequence number. This is a clear separation of concerns. From what I can tell, since QUIC uses its own packet framing and the PN doesn=E2=80=99t repeat we have = tried to optimize this by overloading it with the nonce. That said nothing prevents an implementation from using the packet number as the nonce. By separating concerns one can pick whatever one wants for the nonce, the receiver doesn=E2=80=99t care about the nonce value other th= an for decryption i.e. no impact on transport logic. We can use a VLE field or other methods to reduce the extra space needed for the PN. >> and then encrypting the nonce You don=E2=80=99t have to but you can . The only *functional* requirement f= or the nonce is non-repeatability. Encryption is only being considered for ossification and unlinkability concerns. For connections that don=E2=80=99t= care about unlinkability (no migration, no multi path) the overhead is not worth it. Ossification can be avoided by a random initial value and jumps in between since this is a form of greasing. >> Do you have a non-authenticated crypto mechanism we should consider? I am not a crypto expert. I don=E2=80=99t know what future crypto will look= like. Making the nonce field optional or larger size when needed (but not variable for given connection) allows the transport protocol to be more future proof. Forcing the PN to be the nonce makes things more inflexible. I care much less about the nonce getting ossified compared to the PN. *From:* Salz, Rich [mailto:rsalz@akamai.com] *Sent:* Friday, February 9, 2018 3:37 PM *To:* Praveen Balasubramanian *Cc:* quic@ietf.org *Subject:* Re: Packet number encryption > Clear separation of concerns results if we don=E2=80=99t overload the pac= ket number as the nonce. Connection migration and multi-path are optional features and we pay no extra compute cost for most connections that are not impacted by unlnkability. Nonce field becomes optional for crypto that doesn=E2=80=99t need it and can grow to larger size as needed for bulk tran= sfers to prevent frequent key rollovers (say in datacenter scenarios). David already replied pretty definitively, but for those not on his level = =E2=80=A6 It seems highly unlikely that we will want to use non-authenticated crypto =E2=80=93 ie., AEAD or similar. TLS 1.3 is all and only authenticated encr= yption. The difference in cost is a few extra bytes of encryption, as opposed to bigger packets for plaintext and then encrypting the nonce, right? That difference should be hard to notice. If we assume it=E2=80=99s all authenticated crypto, and therefore we need a= nonce, then separation of concerns becomes a non-issue. In fact, as David pointed out, a packet number **exactly** meets the requirements of an authenticated encrypted nonce. Not using it for that purpose is being wasteful for absolutely no good reason. Do you have a non-authenticated crypto mechanism we should consider? --001a1144b82829a12d0564e0e09f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I wrote up my previo= us suggestion to use segmented packet numbers with clear text nonce in an i= ssue, and I added a comment where I propose a variation that encrypts the n= once, but this encryption is 16 times faster than the current packet number= encryption scheme. In both cases there is no duplication of nonce and pack= et numbers because they are the same modulo path.

=



On 10 February 2018 at 19.22.50, Praveen Balasubramanian (<= a href=3D"mailto:pravb@microsoft.com">pravb@microsoft.com) wrote:

<= blockquote type=3D"cite" class=3D"clean_bq">

>> a packet number *exactly* meets the = requirements of an authenticated encrypted nonce. Not using it for that pur= pose is being wasteful for absolutely no good reason.

For better or worse we have chosen to tie the transp= ort very tightly with TLS. This means extra work will be needed for unencry= pted QUIC or QUIC over IPsec for example. Case in point transport parameter= s not being in the transport header but rather in the TLS header. In HTTPS over TCP, TLS will use its own sequ= ence number for nonce and TCP will have its own sequence number. This is a = clear separation of concerns. From what I can tell, since QUIC uses its own= packet framing and the PN doesn=E2=80=99t repeat we have tried to optimize this by overloading it with the nonce.

=C2=A0

That said nothing prevents an implementation from us= ing the packet number as the nonce. By separating concerns one can pick wha= tever one wants for the nonce, the receiver doesn=E2=80=99t care about the = nonce value other than for decryption i.e. no impact on transport logic. We can use a VLE field or other methods to r= educe the extra space needed for the PN.

=C2=A0

>> and then encrypting the nonce

You don=E2=80=99t have to but you can . The only = functional requirement for the nonce is non-repeatability. Encryption i= s only being considered for ossification and unlinkability concerns. For co= nnections that don=E2=80=99t care about unlinkability (no migration, no multi path) the overhead is not worth it. Ossification c= an be avoided by a random initial value and jumps in between since this is = a form of greasing.

=C2=A0

>> Do you have a non-authenticated crypto mech= anism we should consider?

I am not a crypto expert. I don=E2=80=99t know what = future crypto will look like. Making the nonce field optional or larger siz= e when needed (but not variable for given connection) allows the transport = protocol to be more future proof. Forcing the PN to be the nonce makes things more inflexible. I care much less abou= t the nonce getting ossified compared to the PN.

=C2=A0

From: Salz, Rich [mailto:rsalz@akamai.com]
Sent: Friday, February 9, 2018 3:37 PM
To: Praveen Balasubramanian <pravb@microsoft.com>
Cc: quic@ietf.org
Subject: Re: Packet number encryption

=C2=A0

> Clear separation = of concerns results if we don=E2=80=99t overload the packet number as the n= once. Connection migration and multi-path are optional features and we pay = no extra compute cost for most connections that are not impacted by unlnkability. Nonce field becomes optional for crypto = that doesn=E2=80=99t need it and can grow to larger size as needed for bulk= transfers to prevent frequent key rollovers (say in datacenter scenarios).

=C2= =A0

David= already replied pretty definitively, but for those not on his level =E2=80= =A6

=C2= =A0

It se= ems highly unlikely that we will want to use non-authenticated crypto =E2= =80=93 ie., AEAD or similar.=C2=A0 TLS 1.3 is all and only authenticated en= cryption.=C2=A0 The difference in cost is a few extra bytes of encryption, as opposed to bigger packets for plaintext and then encrypt= ing the nonce, right?=C2=A0 That difference should be hard to notice.

=C2= =A0

If we= assume it=E2=80=99s all authenticated crypto, and therefore we need a nonc= e, then separation of concerns becomes a non-issue. In fact, as David point= ed out, a packet number *exactly* meets the requirements of an authenticated encrypted nonce. Not using it for tha= t purpose is being wasteful for absolutely no good reason.

=C2= =A0

Do yo= u have a non-authenticated crypto mechanism we should consider?

 --001a1144b82829a12d0564e0e09f-- From nobody Sat Feb 10 13:41:47 2018 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 DE5A61270AE for ; Sat, 10 Feb 2018 13:41:46 -0800 (PST) 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, HTML_MESSAGE=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=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 wxoAETvMAm1a for ; Sat, 10 Feb 2018 13:41:45 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 758CE1267BB for ; Sat, 10 Feb 2018 13:41:45 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1ALbsZb007209; Sat, 10 Feb 2018 21:41:45 GMT 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=4BEhnCfBYwSPOzqCm6HxRdmiA4AZ80FKtCip8DOLiiA=; b=WcQF9JLGi/23iYM+K7IX8lF5pRzq++iwtTgYbib0X3AqDkEeH3Ff438tYkrH+cL5pCu3 0tM6S07ggtS1CTz6z7AKMNRx2NVHAQAEZveufVzBxbgQLYJ5VjMlP30uEvDTigDQj8j/ h+HnW7vxMXezJLVhQKxQTpsUY0RoLAk5+tCdfKKO4QnqrgdE9vcpPl3Q6rIARJSmz+dk LLNS9kZl15i0znV2vHPB5g8YJtaZE58WSyWiOmR+fiWo2LfMIDVRFBnohHL4A+MoFKzT WnA3lLSbYrmBKDebD6EX0FVvqoFly2pOMMLaJouSJ9WGFstTQmwauIaLYgC1nfGtH4IL Ig== Received: from prod-mail-ppoint3 ([96.6.114.86]) by mx0a-00190b01.pphosted.com with ESMTP id 2g1snkht4s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 10 Feb 2018 21:41:45 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1ALfZLg017535; Sat, 10 Feb 2018 16:41:44 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2g1vy112ax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sat, 10 Feb 2018 16:41:43 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 10 Feb 2018 16:41:42 -0500 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; Sat, 10 Feb 2018 16:41:42 -0500 From: "Lubashev, Igor" To: "quic@ietf.org" , "alexandre.ferrieux@orange.com" Subject: RE: Measurement bit(s) or not Thread-Topic: Measurement bit(s) or not Thread-Index: AQHTopV5Xk/Gq+i72kuhP7it8q6tzaOeKra0 Date: Sat, 10 Feb 2018 21:41:42 +0000 Message-ID: References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> In-Reply-To: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_aa7a56d01f0a41fe9ad0fd9e61c54c50usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-10_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802100286 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-10_10:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802100285 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, 10 Feb 2018 21:41:47 -0000 --_000_aa7a56d01f0a41fe9ad0fd9e61c54c50usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am a bit sceptical about the square. With TCP, packet trace shows loss of= any packet, except for SYN. The "square wave" whould show no loss at all f= or short connections (fewer than a "wavelength" of packets). Moreover, the = square wave can only detect loss after up to the wave length of subsequent = packets has been transmitted. If there is an application pause in transmiss= ion, loss may not become evident. Basically, a spin bit or a bit pattern (like a square wave) may help in tro= ubleshooting, but it will be more uncertain and hokey than what people come= to expect of tcp. We have be very clear in acknowledging it. -----Original Message----- From: alexandre.ferrieux@orange.com [alexandre.ferrieux@orange.com] Received: Saturday, 10 Feb 2018, 12:34PM To: quic@ietf.org [quic@ietf.org] Subject: Measurement bit(s) or not On 07/02/2018 14:34, Brian Trammell (IETF) wrote: > hi Jana, > >> 3. Some sequencing information -- a few bits of the packet number perha= ps >> -- should be revealed (for monitoring. Number of bits TBD.) > > This is the crux of the argument. On one side we have the risk of misuse= and > ossification (well, not ossification -- these bits are *meant* for the p= ath > -- rather the risk that we'll figure out later that we specified the wro= ng > thing), on the other side we have the loss of visibility into how QUIC > traffic interacts with the network as compared to TCP, with a side quest= ion > of whether or not this visibility is really the transport layer's proble= m > despite the evolution the practice of diagnostics and troubleshooting us= ing > TCP information. > > If we can come to agreement on this question, everything else falls into > place. I have my arguments here, but as you said, this subthread is not = the > place for them. :) The crux indeed. So what about settling it first ? With the troubleshooting hat, I can only stress the need for measurement bi= ts, for the benefit of everybody, since s**t happens, networks are imperfect, a= nd nifty encapsulations-with-seqnum will simply not be where you need them. Now to the exact nature of these measurement bits: Thanks to the detailed exchanges on this thread, it is by now clear that a simple gapless counter, even nonzero-based and XORed, is not acceptable. Th= e 4-bit SSN comes pretty close but is not enough when things go really wrong = (and they will - and that's where we need the tool). Then Kazuho's square signal and Mikkel's Pi (or any other consensual self-synchronizing sequence) ramification came up. They are both appealing = for their elegance and low complexity on QUIC endpoints. Beyond their quirks acknowledged here, here are a few considerations for troubleshooting: (1) Since reordering is less of a concern to QUIC than to TCP, it becomes= a secondary goal. This is nice, because the square doesn't see it, and the self-synchronizing sequence will only tolerate a mild one, and never see it= s detail like cycle length etc. (2) There's of course a huge difference between them in complexity for th= e midpoint: square is trivial, Pi is hefty. Given these, a benevolent, troubleshooting-minded passive midpoint will cle= arly vote for the square. Now the obvious question is: is this acceptable, or de= emed too easy for a Murphy, Inc. active middlebox to see upstream losses and benevolently wreak havoc by delaying packets ? ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_aa7a56d01f0a41fe9ad0fd9e61c54c50usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am a bit sceptical about the square. With TCP, packet tr= ace shows loss of any packet, except for SYN. The "square wave" w= hould show no loss at all for short connections (fewer than a "wavelength" of packets). Moreover, the square wav= e can only detect loss after up to the wave length of subsequent packets ha= s been transmitted. If there is an application pause in transmission, loss = may not become evident.

Basically, a spin bit or a bit pattern (like a square wave) may help in tro= ubleshooting, but it will be more uncertain and hokey than what people come= to expect of tcp. We have be very clear in acknowledging it.

-----Original Message-----
From: alexandre.ferrieux@orange.com [alexandre.ferrieux@orange.com]<= br> Received: Saturday, 10 Feb 2018, 12:34PM
To: quic@ietf.org [quic@ietf.org]
Subject: Measurement bit(s) or not

On 07/02/2018 14:34, Brian Trammell (IETF) wrote:<= br>  > hi Jana,
 >
 >> 3. Some sequencing information -- a few bits of the packet n= umber perhaps
 >> -- should be revealed (for monitoring. Number of bits TBD.)<= br>  >
 > This is the crux of the argument. On one side we have the risk o= f misuse and
 > ossification (well, not ossification -- these bits are *meant* f= or the path
 > -- rather the risk that we'll figure out later that we specified= the wrong
 > thing), on the other side we have the loss of visibility into ho= w QUIC
 > traffic interacts with the network as compared to TCP, with a si= de question
 > of whether or not this visibility is really the transport layer'= s problem
 > despite the evolution the practice of diagnostics and troublesho= oting using
 > TCP information.
 >
 > If we can come to agreement on this question, everything else fa= lls into
 > place. I have my arguments here, but as you said, this subthread= is not the
 > place for them. :)

The crux indeed. So what about settling it first ?

With the troubleshooting hat, I can only stress the need for measurement bi= ts,
for the benefit of everybody, since s**t happens, networks are imperfect, a= nd
nifty encapsulations-with-seqnum will simply not be where you need them.
Now to the exact nature of these measurement bits:

Thanks to the detailed exchanges on this thread, it is by now clear that a =
simple gapless counter, even nonzero-based and XORed, is not acceptable. Th= e
4-bit SSN comes pretty close but is not enough when things go really wrong = (and
they will - and that's where we need the tool).

Then Kazuho's square signal and Mikkel's Pi (or any other consensual
self-synchronizing sequence) ramification came up. They are both appealing = for
their elegance and low complexity on QUIC endpoints. Beyond their quirks acknowledged here, here are a few considerations for troubleshooting:

  (1) Since reordering is less of a concern to QUIC than to TCP, it be= comes a
secondary goal. This is nice, because the square doesn't see it, and the self-synchronizing sequence will only tolerate a mild one, and never see it= s
detail like cycle length etc.

  (2) There's of course a huge difference between them in complexity f= or the
midpoint: square is trivial, Pi is hefty.

Given these, a benevolent, troubleshooting-minded passive midpoint will cle= arly
vote for the square. Now the obvious question is: is this acceptable, or de= emed
too easy for a Murphy, Inc. active middlebox to see upstream losses and benevolently wreak havoc by delaying packets ?

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

 --_000_aa7a56d01f0a41fe9ad0fd9e61c54c50usma1exdag1mb5msgcorpak_-- From nobody Sat Feb 10 16:45:24 2018 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 AFFF9120454 for ; Sat, 10 Feb 2018 16:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, 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 (2048-bit key) header.d=mnot.net header.b=ix4yP9Rl; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=E5UEWm9R 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 EM6yU4QH8Fj5 for ; Sat, 10 Feb 2018 16:45:18 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDD91205F0 for ; Sat, 10 Feb 2018 16:45:18 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id F1AAD20BF5 for ; Sat, 10 Feb 2018 19:45:17 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Sat, 10 Feb 2018 19:45:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=oJADQUJVtINsUjGzx YVGBzStFEWCRQ/R7DMjnxzvf2I=; b=ix4yP9RldDuTxIMJKk+jpfxce4Z1PgmDR 9jiorMajrhFObTcmiazXBoSe7/FPycoyu+ZMzRocYXWXWuCLwEU0OfOtUKEEBiT4 dRSa7Sfv7HCDIVoPuRyLGCQ9yPw1pLKBTTDm3Bd4rfqDWPdQ0WbagBiCkqJphlX+ fyfRNk+bbk4MGLghnKBBRHjPZRzsnAq6OKpeKLWGcAYi136UI7+/Rn4TY5cRpX9+ 0OySJVSp6+sqhMKD93+lH2b6hRTR8q639djtEGdd2LdrFcomLemDGA8nYEXlhCXZ frTHb6w71NQG8OimKoN2PvoTUzP8A7/rDzpGWXzXLy+nyh1kG2Zzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=oJADQUJVtINsUjGzxYVGBzStFEWCRQ/R7DMjnxzvf2I=; b=E5UEWm9R ukcCtiQtVPEIn0ZTj/OHl3MPU2pcNoPyj9mVfBs8RaIZpWw6md0wQ1r0ZQ+imSDb IbNnIHTQPajTRD2Q+eS2CBTV67ZoslkKhXm0FyOl02C1f4GMQMTC6uF/AxilMFjf FrfVeYr2uWT8Y2uRahxaSLuFBcsHv8DQjRrl/1c1408os+AUrkEdujeNA50hqaq/ DU7VdhmNolrHyApw3pVuZp51zGgvcqhYl6piyZVsRVeZ/zzn+Ff6B+Z5zREb4PMI YKuauYciny34vCvfCpWKqzHZPZELnPIZMapsd+99nrZmp3sff7L+Dd2YpTDxZV+k Y+dN5Mtn9WQZdw== X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id 413777E46B for ; Sat, 10 Feb 2018 19:45:17 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 96F95C7FF1 for ; Sun, 11 Feb 2018 00:45:14 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============0035350199571664382==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180211004514.96F95C7FF1@cloud.mnot.net> Date: Sun, 11 Feb 2018 00:45:14 +0000 (UTC) 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, 11 Feb 2018 00:45:23 -0000 --===============0035350199571664382== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+8/-5/=F0=9F=92=AC40) 8 issues created: - Segmented Packet Numbers (by mikkelfj) https://github.com/quicwg/base-drafts/issues/1105 = - wrong MSS value in congestion avoidance phase (by yangchi) https://github.com/quicwg/base-drafts/issues/1102 = - Asymmetric Connection IDs (by ekr) https://github.com/quicwg/base-drafts/issues/1101 = - Push Stream Header duplication (by LPardue) https://github.com/quicwg/base-drafts/issues/1099 = - Stream error handling is ambiguously specified (by huitema) https://github.com/quicwg/base-drafts/issues/1098 = - Should path migration mimic an initial connection? (by huitema) https://github.com/quicwg/base-drafts/issues/1096 = - Clarify how frames are retransmitted (by mikkelfj) https://github.com/quicwg/base-drafts/issues/1095 = - Clarification: HRR which does not perform address validation (by tatsuh= iro-t) https://github.com/quicwg/base-drafts/issues/1094 = 10 issues received 40 new comments: - #1094 Clarification: HRR which does not perform address validation (17 = by kazuho, janaiyengar, MikeBishop, martinthomson, mcmanus, huitema, ianswe= tt) https://github.com/quicwg/base-drafts/issues/1094 [-tls] [design] = - #203 Connection migration should be indistinguishable from a new connec= tion (6 by kazuho, larseggert, huitema, mikkelfj) https://github.com/quicwg/base-drafts/issues/203 [-transport] [design] = [quicv2] = - #441 Priority grouping node ambiguity (6 by martinthomson, MikeBishop, = kazuho, ianswett) https://github.com/quicwg/base-drafts/issues/441 [-http] [design] = - #1101 Asymmetric Connection IDs (4 by hardie, ekr, mikkelfj) https://github.com/quicwg/base-drafts/issues/1101 = - #1105 Segmented Packet Numbers (2 by mikkelfj) https://github.com/quicwg/base-drafts/issues/1105 = - #296 GREASE and Version Negotiation Hint (1 by MikeBishop) https://github.com/quicwg/base-drafts/issues/296 [-http] [design] = - #879 RTT Measurement for HelloRetryRequest (1 by marten-seemann) https://github.com/quicwg/base-drafts/issues/879 [-transport] [design] = - #1096 Should path migration mimic an initial connection? (1 by ianswett) https://github.com/quicwg/base-drafts/issues/1096 = - #219 Increasing initial flow control window for streams (1 by MikeBisho= p) https://github.com/quicwg/base-drafts/issues/219 [-transport] [design] = - #1085 Handshake failure with Retry and multiple Initial packets (1 by m= arten-seemann) https://github.com/quicwg/base-drafts/issues/1085 [-tls] [design] = 5 issues closed: - Asymmetric Connection IDs https://github.com/quicwg/base-drafts/issues/= 1101 [-transport] [design] = - GREASE and Version Negotiation Hint https://github.com/quicwg/base-draf= ts/issues/296 [-http] [design] = - Guidance for port number use https://github.com/quicwg/base-drafts/issu= es/495 [-http] [-ops] [design] = - Avoid tracking bits in Alt-Svc quic=3D parameter https://github.com/qui= cwg/base-drafts/issues/1081 [-http] = - Should path migration mimic an initial connection? https://github.com/q= uicwg/base-drafts/issues/1096 = Pull requests ------------- * quicwg/base-drafts (+3/-3/=F0=9F=92=AC9) 3 pull requests submitted: - Fix the label length in the QHKDF-Expand example (by nharper) https://github.com/quicwg/base-drafts/pull/1104 = - Fix outdated function reference (by martinduke) https://github.com/quicwg/base-drafts/pull/1103 = - Extract request cancellation from GOAWAY (by MikeBishop) https://github.com/quicwg/base-drafts/pull/1100 = 3 pull requests received 9 new comments: - #1097 Alt-Svc quic=3D a list (6 by martinthomson, LPardue, MikeBishop) https://github.com/quicwg/base-drafts/pull/1097 [-http] = - #1100 Extract request cancellation from GOAWAY (2 by martinthomson, Mik= eBishop) https://github.com/quicwg/base-drafts/pull/1100 [-http] = - #257 do not normatively specify application delivery order (1 by MikeBi= shop) https://github.com/quicwg/base-drafts/pull/257 [-transport] [parked] = 3 pull requests merged: - Fix the label length in the QHKDF-Expand example https://github.com/quicwg/base-drafts/pull/1104 = - Fix outdated function reference https://github.com/quicwg/base-drafts/pull/1103 = - Alt-Svc quic=3D a list https://github.com/quicwg/base-drafts/pull/1097 = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============0035350199571664382== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday February 11, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+8/-5/=F0=9F=92=AC40)

8 issues created:

10 issues received 40 new comments:

5 issues closed:

Pull requests

quicwg/base-drafts (+3/-3/=F0=9F=92=AC9)

3 pull requests submitted:

3 pull requests received 9 new comments:

3 pull requests merged:

Repositories tracked by this digest:

--===============0035350199571664382==-- From nobody Sun Feb 11 08:51:33 2018 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 409EF124205 for ; Sun, 11 Feb 2018 08:51:32 -0800 (PST) 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 Dc6FLgx31bHl for ; Sun, 11 Feb 2018 08:51:29 -0800 (PST) Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::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 7E1221201F2 for ; Sun, 11 Feb 2018 08:51:29 -0800 (PST) Received: by mail-pl0-x232.google.com with SMTP id 36so3875140ple.13 for ; Sun, 11 Feb 2018 08:51:29 -0800 (PST) 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=q36zF6buQyCC5nQS2oAPU3WkalMD2iHn7YJJ7HxDarA=; b=kfAz+AuaiAs1qMY2ZuAYxzUF5FGvc/Ubo/VZ8v+2NEnlLWw1F8jUBTRMzOPONVUqMF oE2JHo/YjtJNbPiG+omr0yvLiICVd/fFYzZGDSa3+1WmupJUQQk/qLPQHrU6wpwbpyvq nLy+/lLDNBuqC2MqlT7jOh6WGm9GNrJd0/xh26mN4Wuhg3Y2DqpTlkD39EpidVUwfHhJ /75jzOB104nuFWMo/7c+OpycUed2C5RqLUEapGTpGtGnazEfIKQAB8acHTl/BTqOCbwV sYIXlW/8mfqr3ri17EVGpiQ13VLWvylyFYWbOuo60+XGQw0Oz47lunYNE9d1bGEp2nbh ap1g== 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=q36zF6buQyCC5nQS2oAPU3WkalMD2iHn7YJJ7HxDarA=; b=EWE0eCEoBiTR3f+LwbD0BIx2wGq+oBxrLaR1ePWdUJ/7LRWHzPD1wDUgq9AB2EwQS3 K0yps1rXUWjKhB/fygyhhGNLbAsye0WcmjteoId+HxQOFdLQBsBslRtgJihjOkhcVXWe RpwbIEfnfrnOfHf8z9+sJKY/waTx7AJF2sULtBK4CyuA2QaA77tFlh64bf8aJGQRGSvX BHv1orCUF6YJREbSdlcycxCOO1Yw6KyMValFRv+wzKtcTQ3Vk0SEeFeKJem0ZFnU9KCX YFDoFJ4qtMFFQJNlk0aTae3caXkozO95fsBctFGgFVtNw+5TSVtuOnwZbUkai34vtw36 oEnw== X-Gm-Message-State: APf1xPD4cTwa3WkJTrBu3n2qgeHj8MbLzws6GUhKCDY+2UQdGBr7fvhY aFw0GaEsqdM54xVZT60qrtG+Dk+6Xkqw1535x6OPLg== X-Google-Smtp-Source: AH8x224v9zC4SewEjBY7YK1xnU3wkzN1oZpdx4Mt4ikURTeX8yrgSWmRwC67fjVE3AQomf32s8ab+3SvSbnRId298Xg= X-Received: by 2002:a17:902:2bc5:: with SMTP id l63-v6mr8551767plb.108.1518367888783; Sun, 11 Feb 2018 08:51:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.156.11 with HTTP; Sun, 11 Feb 2018 08:51:28 -0800 (PST) From: Kazuho Oku Date: Mon, 12 Feb 2018 01:51:28 +0900 Message-ID: Subject: Fwd: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) To: IETF QUIC WG Cc: alexandre.ferrieux@orange.com 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, 11 Feb 2018 16:51:32 -0000 2018-02-11 2:34 GMT+09:00 : > Then Kazuho's square signal and Mikkel's Pi (or any other consensual > self-synchronizing sequence) ramification came up. They are both appealing > for their elegance and low complexity on QUIC endpoints. Beyond their quirks > acknowledged here, here are a few considerations for troubleshooting: > (snip) > Given these, a benevolent, troubleshooting-minded passive midpoint will > clearly vote for the square. Now the obvious question is: is this > acceptable, or deemed too easy for a Murphy, Inc. active middlebox to see > upstream losses and benevolently wreak havoc by delaying packets ? Thank you for raising the question. While I think that using square wave is a neat idea, I am not so sure if the wavelength is correct, or if it would continue to be correct for the lifetime of the transport protocol. I assume that other patterns that have been proposed (e.g., PI, random) share the same weakness. Therefore, I have written a proposal of a very different approach, which is the following I-D. Performance Metrics Subprotocol for QUIC https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/ The I-D proposes to add a subprotocol that is used between an on-path observer and the QUIC server to obtain the performance metrics. At the latency of 1 RTT, the subprotocol can observe accurate upstream loss/reorder rate, as well as SRTT / RTTVAR. I believe that it is not difficult to implement on the server-side (please refer to section 4). Client needs no change. Since the proposed approach does not hard-code any information for observation on the wire, the hard part of the design issue goes away. We can adjust what (and how) to observe independently from the QUIC transport. I think that this is not only a win in terms of design but also might have positive effect on moving the standardization process forward, since we would no longer be constrained by the discussion of what should be observable "on-the-wire." Privacy concern regarding observation becomes minor, since observation becomes "observable" and deniable by an endpoint. Although SRTT / RTTVAR is observable, I am not sure if it can be used to replace the Spin Bit proposal. It depends on how often and how fast an observer needs to see the metrics. Primary target of my proposal is to help diagnosing issues. Please let me know what you think. ---------- Forwarded message ---------- From: Date: 2018-02-12 1:43 GMT+09:00 Subject: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt To: Kazuho Oku A new version of I-D, draft-kazuho-quic-perf-metrics-00.txt has been successfully submitted by Kazuho Oku and posted to the IETF repository. Name: draft-kazuho-quic-perf-metrics Revision: 00 Title: Performance Metrics Subprotocol for QUIC Document date: 2018-02-12 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-kazuho-quic-perf-metrics-00.txt Status: https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/ Htmlized: https://tools.ietf.org/html/draft-kazuho-quic-perf-metrics-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-kazuho-quic-perf-metrics-00 Abstract: This memo proposes a subprotocol that can be used to query the performance metrics of a QUIC path. 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. The IETF Secretariat -- Kazuho Oku From nobody Sun Feb 11 10:05:47 2018 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 E2987124235 for ; Sun, 11 Feb 2018 10:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 QAfsTCj-OPtE for ; Sun, 11 Feb 2018 10:05:32 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 2FEF81200F1 for ; Sun, 11 Feb 2018 10:05:32 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id k131so4165088ith.4 for ; Sun, 11 Feb 2018 10:05:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=wCqU/yCm2P6T88HjlrYzEzyMVpCuAN1bN2i5fASNu9g=; b=tifR7/h/V6JTdwud2plwWVS9m49upA8TsmB0VLIWaXOSG2ep19Vp9cec1C5F+O5gox Fxf8oK7L+BM0wevWgP6ZBUL86zlZvfnWsN6C3QUDC+queU5ei9NErMrw3gzue644wiSs Th98UHXiMXr/dggd1iwpfFmfHkOot/oefSatVw0yNqLa5TMJyCIzmaGMXC9rePkY3W0t mk/2wUQcMBqiI6kkN3TxlazW4XccIViLHBOm7tOV25hPYqWh+OqIMUYvIzsyeU7NMZOQ g/Nvruj2iBr2ARN0lV3PcV0Sqq8z0A4mxmH26jO7tmfKtjLstneqfzt0EjWBMzhJiT8u 8qkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=wCqU/yCm2P6T88HjlrYzEzyMVpCuAN1bN2i5fASNu9g=; b=CDkISdsXxZP+N3hYro0bnYDktd0N0ekmnoekt8GXeegpYVZiuBHvzcJtx2lVvRQRio jOMECb+UoEQ4hCZRSdOOIj0IzBlPtSMVFil1DAhWXaFoyTiOuCJAZjiDfdhdW2YBPQoX 5JYyhU7LG7QJIiVTdHOW2Mar1OKDhfDpdcIMuOKHGR1PForKidueyyEWpDSXQkBijgVf pVD44on1HgwKhJ6WOXiPOKtRBYD4OcXd1YMQxxqe/kY/w7uo94RObHuFijoT0R1RQ1fv JQRwaeHISe9qAGCW8jr9eA9W8dALfFoaUtsmGhuweQ83+eDIg/sQKVjIdBfdL39rKaf2 +1xw== X-Gm-Message-State: APf1xPB0toNXuEy42QZc3w/3d3yU/GqKoPeJC6yeex0JWMjPxxtf91IV 1NrjDXhi8l1QqRfCo/FzbO7F9vqNK9SO00fhUtyKeA== X-Google-Smtp-Source: AH8x227Hv+v7MSquYNUIus0NQ070MQu7NvekwRWXp/oGQoBpR9F/dkP/Cmrrd6J1AxVRbzE4eqwcbHKMc8oqnEAMQeQ= X-Received: by 10.36.73.24 with SMTP id z24mr2536926ita.91.1518372331293; Sun, 11 Feb 2018 10:05:31 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 11 Feb 2018 10:05:29 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 11 Feb 2018 10:05:29 -0800 Message-ID: Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) To: IETF QUIC WG , Kazuho Oku Cc: alexandre.ferrieux@orange.com Content-Type: multipart/alternative; boundary="001a113520ee718ec10564f39b35" 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, 11 Feb 2018 18:05:46 -0000 --001a113520ee718ec10564f39b35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I need to read it more closely to understand the finer details, but my immediate reaction is that I do not like this at all. It appears to add unnecessary complication and there could be a host of hidden security issues. The basic fact that someone other than the endpoints can affect the traffic can lead to all sorts of issues and the information transmitted might be abused in a number of ways, for example to learn about the kind of traffic being sent, the internal layout of a subnetwork by leaking presence of other middleware, the OS and applications in use etc. I much prefer a simple no-nonsense solution over trying to handle protocol lifetime variations. The QUIC protocol could fix issues in new versions and until then a simple predictable signal should suffice, even if it isn=E2=80= =99t perfect. This also makes middleware simpler, since a signal is always present in a predictable manner. We could have some fractal square waves to deal by having a short repeating signal that periodically changes at different wave lengths, e.g. a a repeating 8 bit pattern where each bit is flipped at the period of the wave length it represents. That ought to be enough. The pattern repeats every 8 packets. The wave lengths could be 16, 32, 64, 128, 256, 512, 1024, 2048 so that same 8 bits are always transmitted twice before a bit changes which should help synchronise it. It might not be perfect, but it ought to be sufficient. I=E2=80=99m also starting to think that just exposing a sequential counter = per path is much simpler even if it leads to ossification - see segment packet number proposal https://github.com/quicwg/base-drafts/issues/1105 Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 11 February 2018 at 17.51.37, Kazuho Oku (kazuhooku@gmail.com) wrote: 2018-02-11 2:34 GMT+09:00 : > Then Kazuho's square signal and Mikkel's Pi (or any other consensual > self-synchronizing sequence) ramification came up. They are both appealing > for their elegance and low complexity on QUIC endpoints. Beyond their quirks > acknowledged here, here are a few considerations for troubleshooting: > (snip) > Given these, a benevolent, troubleshooting-minded passive midpoint will > clearly vote for the square. Now the obvious question is: is this > acceptable, or deemed too easy for a Murphy, Inc. active middlebox to see > upstream losses and benevolently wreak havoc by delaying packets ? Thank you for raising the question. While I think that using square wave is a neat idea, I am not so sure if the wavelength is correct, or if it would continue to be correct for the lifetime of the transport protocol. I assume that other patterns that have been proposed (e.g., PI, random) share the same weakness. Therefore, I have written a proposal of a very different approach, which is the following I-D. Performance Metrics Subprotocol for QUIC https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/ The I-D proposes to add a subprotocol that is used between an on-path observer and the QUIC server to obtain the performance metrics. At the latency of 1 RTT, the subprotocol can observe accurate upstream loss/reorder rate, as well as SRTT / RTTVAR. I believe that it is not difficult to implement on the server-side (please refer to section 4). Client needs no change. Since the proposed approach does not hard-code any information for observation on the wire, the hard part of the design issue goes away. We can adjust what (and how) to observe independently from the QUIC transport. I think that this is not only a win in terms of design but also might have positive effect on moving the standardization process forward, since we would no longer be constrained by the discussion of what should be observable "on-the-wire." Privacy concern regarding observation becomes minor, since observation becomes "observable" and deniable by an endpoint. Although SRTT / RTTVAR is observable, I am not sure if it can be used to replace the Spin Bit proposal. It depends on how often and how fast an observer needs to see the metrics. Primary target of my proposal is to help diagnosing issues. Please let me know what you think. ---------- Forwarded message ---------- From: Date: 2018-02-12 1:43 GMT+09:00 Subject: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt To: Kazuho Oku A new version of I-D, draft-kazuho-quic-perf-metrics-00.txt has been successfully submitted by Kazuho Oku and posted to the IETF repository. Name: draft-kazuho-quic-perf-metrics Revision: 00 Title: Performance Metrics Subprotocol for QUIC Document date: 2018-02-12 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/internet-drafts/draft-kazuho-quic-perf-metrics-00.txt Status: https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/ Htmlized: https://tools.ietf.org/html/draft-kazuho-quic-perf-metrics-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-kazuho-quic-perf-metrics-00 Abstract: This memo proposes a subprotocol that can be used to query the performance metrics of a QUIC path. 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. The IETF Secretariat --=20 Kazuho Oku --001a113520ee718ec10564f39b35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I need to read it mo= re closely to understand the finer details, but my immediate reaction is th= at I do not like this at all.

It appears to add unnecessary complication and there could be a ho= st of hidden security issues. The basic fact that someone other than the en= dpoints can affect the traffic can lead to all sorts of issues and the info= rmation transmitted might be abused in a number of ways, for example to lea= rn about the kind of traffic being sent, the internal layout of a subnetwor= k by leaking presence of other middleware, the OS and applications in use e= tc.

I much prefer a s= imple no-nonsense solution over trying to handle protocol lifetime variatio= ns. The QUIC protocol could fix issues in new versions and until then a sim= ple predictable signal should suffice, even if it isn=E2=80=99t perfect. Th= is also makes middleware simpler, since a signal is always present in a pre= dictable manner.

We c= ould have some fractal square waves to deal by having a short repeating sig= nal that periodically changes at different wave lengths, e.g. a a repeating= 8 bit pattern where each bit is flipped at the period of the wave length i= t represents. That ought to be enough. The pattern repeats every 8 packets.= The wave lengths could be 16, 32, 64, 128, =C2=A0256, 512, 1024, 2048 so t= hat same 8 bits are always transmitted twice before a bit changes which sho= uld help synchronise it. It might not be perfect, but it ought to be suffic= ient.

I=E2=80=99m als= o starting to think that just exposing a sequential counter per path is muc= h simpler even if it leads to ossification - see segment packet number prop= osal=C2=A0htt= ps://github.com/quicwg/base-drafts/issues/1105



Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

<= br>

On 11 February 2018 at 17.51.37, Kazuho Oku (kazuhooku@gmail.com) wrote:

2018-0= 2-11 2:34 GMT+09:00 <a= lexandre.ferrieux@orange.com>:
> Then Kazuho's square signal and Mikkel's Pi (or any other = consensual
> self-synchronizing sequence) ramification came up. They are both a= ppealing
> for their elegance and low complexity on QUIC endpoints. Beyond th= eir quirks
> acknowledged here, here are a few considerations for troubleshooti= ng:
> (snip)
> Given these, a benevolent, troubleshooting-minded passive midpoint= will
> clearly vote for the square. Now the obvious question is: is this
> acceptable, or deemed too easy for a Murphy, Inc. active middlebox= to see
> upstream losses and benevolently wreak havoc by delaying packets ?

Thank you for raising the question.

While I think that using square wave is a neat idea, I am not so sure
if the wavelength is correct, or if it would continue to be correct
for the lifetime of the transport protocol. I assume that other
patterns that have been proposed (e.g., PI, random) share the same
weakness.

Therefore, I have written a proposal of a very different approach,
which is the following I-D.

Performance Metrics Subprotocol for QUIC
https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/<= /a>

The I-D proposes to add a subprotocol that is used between an on-path
observer and the QUIC server to obtain the performance metrics. At the
latency of 1 RTT, the subprotocol can observe accurate upstream
loss/reorder rate, as well as SRTT / RTTVAR.

I believe that it is not difficult to implement on the server-side
(please refer to section 4). Client needs no change.

Since the proposed approach does not hard-code any information for
observation on the wire, the hard part of the design issue goes away.
We can adjust what (and how) to observe independently from the QUIC
transport. I think that this is not only a win in terms of design but
also might have positive effect on moving the standardization process
forward, since we would no longer be constrained by the discussion of
what should be observable "on-the-wire."

Privacy concern regarding observation becomes minor, since observation
becomes "observable" and deniable by an endpoint.

Although SRTT / RTTVAR is observable, I am not sure if it can be used
to replace the Spin Bit proposal. It depends on how often and how fast
an observer needs to see the metrics. Primary target of my proposal is
to help diagnosing issues.

Please let me know what you think.

---------- Forwarded message ----------
From: <internet-drafts@= ietf.org>
Date: 2018-02-12 1:43 GMT+09:00
Subject: New Version Notification for draft-kazuho-quic-perf-metrics-00= .txt
To: Kazuho Oku <kazuhooku@gma= il.com>



A new version of I-D, draft-kazuho-quic-perf-metrics-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name: draft-kazuho-quic-perf-metrics
Revision: 00
Title: Performance Metrics Subprotocol for QUIC
Document date: 2018-02-12
Group: Individual Submission
Pages: 8
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-quic-perf= -metrics-00.txt
Status: https://datatracker.ietf.org/doc/draft-kazuho-quic-pe= rf-metrics/
Htmlized: https://tools.ietf.org/html/draft-kazuho-quic-perf-metri= cs-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-quic-perf-m= etrics-00


Abstract:
This memo proposes a subprotocol that can be used to query the
performance metrics of a QUIC path.




Please note that it may take a couple of minutes from the time of submi= ssion
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat



-- =20
Kazuho Oku

--001a113520ee718ec10564f39b35-- From nobody Sun Feb 11 10:36:04 2018 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 98718126B72 for ; Sun, 11 Feb 2018 10:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 OArloPKeuBme for ; Sun, 11 Feb 2018 10:36:01 -0800 (PST) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0FF1243FE for ; Sun, 11 Feb 2018 10:36:01 -0800 (PST) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 0C52560A60; Sun, 11 Feb 2018 19:36:00 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id E01D5180065; Sun, 11 Feb 2018 19:35:59 +0100 (CET) Received: from lat6466.rd.francetelecom.fr (10.168.234.4) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 11 Feb 2018 19:35:59 +0100 Message-ID: <5700_1518374159_5A808D0F_5700_161_1_5A808D14.30503@orange.com> Date: Sun, 11 Feb 2018 19:36:04 +0100 From: User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Kazuho Oku CC: IETF QUIC WG Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.4] 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, 11 Feb 2018 18:36:02 -0000 On 11/02/2018 17:51, Kazuho Oku wrote: > 2018-02-11 2:34 GMT+09:00: >> Then Kazuho's square signal and Mikkel's Pi (or any other consensual >> self-synchronizing sequence) ramification came up. They are both appealing >> for their elegance and low complexity on QUIC endpoints. Beyond their quirks >> acknowledged here, here are a few considerations for troubleshooting: >> (snip) >> Given these, a benevolent, troubleshooting-minded passive midpoint will >> clearly vote for the square. Now the obvious question is: is this >> acceptable, or deemed too easy for a Murphy, Inc. active middlebox to see >> upstream losses and benevolently wreak havoc by delaying packets ? > > Thank you for raising the question. > > While I think that using square wave is a neat idea, I am not so sure > if the wavelength is correct, or if it would continue to be correct > for the lifetime of the transport protocol. I assume that other > patterns that have been proposed (e.g., PI, random) share the same > weakness. Again, these shortcomings have been acknowledged here, and could be addressed later, once the more general question I'm asking is settled: => Do "we", or do "we" not, want to disclose a signal that allows a midpoint observer to deduce: - both upstream and downstream half-RTTs (spin bit) - upstream losses (consensual sequence: square, Pi, fractal, whatever) Pros: manageability, troubleshooting Cons: some Murphy middlebox ossifying the Internet instead of dying in flames Once the answer is known and agreed upon, dedicated research on the best design for "measurement bits" will be timely. Not before. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Sun Feb 11 10:47:21 2018 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 C2AA21243FE for ; Sun, 11 Feb 2018 10:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 7w5Fzf7lNj_4 for ; Sun, 11 Feb 2018 10:47:18 -0800 (PST) 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 3C02F1200F1 for ; Sun, 11 Feb 2018 10:47:18 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id u12so4182596ite.0 for ; Sun, 11 Feb 2018 10:47:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=rcWMH9xJ0nt53kq9b8D044yEmbaaZA98rIL1cJyJMQM=; b=b+Vz+zGwUEPQlTBLvt9QHgiPpr5F7MaEo5AQX935uIOB2enkP/bjKU6Cy4N1ne7Qzr VeGIUHHADFNh86FoYMMcUPf566CDFfXnwPCn8sVPKm9HzIkCAapel5jnNOaH9ReeSj1/ Ax5godEgrf/45zJ/c+ovV36ZOx+z0Inxq6nLj5J9NXl83oy4uO0GPAOxPJQQ0xHGBmKw h96PgOuEmFdDGdn9ZCt984AF1Mg1Dy2ll5qGgu0QhCiV/v9Ow1UwVDIHrpsux7g6RLe6 bzQIFtIvqlsZZ727Y3WOWsKvVsCVIXJrKa4zLW8+sRaA5oIfq9aqQdROpBcwBB6A9kLT 2rIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=rcWMH9xJ0nt53kq9b8D044yEmbaaZA98rIL1cJyJMQM=; b=UXKIH4I2vQWvW9M0Y/WXgaKmQMk8D7dOogsIonk81Vk98nwjeUmKz5dy1DRMKCCMQd /FG/rDpAYyQJJQJoiBdl/H/OPinR7b8fnf3AHB/sRQHIGTgq0rcKl4EvxIGg3y06Z8kP 6XIz+Cl94zz8Fv2g9DhNZiVMym8Wb6N6FNtL4yo2KFnug8+iRBNihgHZQteMKzWeVJvh NsVnYt0KeWSZPwc+xpg9aY3HevKjsDnwVHzGqyXR9oNZ9REnSyCAi6KsujhePGOqj0tC L3umh5JQTE+D03AJCeJXiI7ghEaMBA5znwIM34ic/SSv95dCouFFGt9gPB+jOHYtJQaV uPlA== X-Gm-Message-State: APf1xPBhxx5LtuMg6P6dFHx4ib41abGStJRPuQeILgYtY/P35rfPBehP OZqR9EW8L8kPyGfJ5J7iX+9JprCvfsbwf4XezDY= X-Google-Smtp-Source: AH8x226Fpam+06O9fhax/hG/0UNVSwak16juFJJ5QK1/xCpgjJ6w+OJ3c9XwKjlHMwJng/bBx5BDUWKehoseInJvFVA= X-Received: by 10.36.46.23 with SMTP id i23mr2713657ita.55.1518374837596; Sun, 11 Feb 2018 10:47:17 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 11 Feb 2018 10:47:16 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <5700_1518374159_5A808D0F_5700_161_1_5A808D14.30503@orange.com> References: <5700_1518374159_5A808D0F_5700_161_1_5A808D14.30503@orange.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 11 Feb 2018 10:47:16 -0800 Message-ID: Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) To: alexandre.ferrieux@orange.com, Kazuho Oku Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114a9d82d4b5000564f43041" 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, 11 Feb 2018 18:47:21 -0000 --001a114a9d82d4b5000564f43041 Content-Type: text/plain; charset="UTF-8" Just to give a name to the fractal proposal: it is actually a grey code and these have a long history of use in coding theory https://en.wikipedia.org/wiki/Gray_code On 11 February 2018 at 19.36.06, alexandre.ferrieux@orange.com ( alexandre.ferrieux@orange.com) wrote: On 11/02/2018 17:51, Kazuho Oku wrote: > 2018-02-11 2:34 GMT+09:00: >> Then Kazuho's square signal and Mikkel's Pi (or any other consensual >> self-synchronizing sequence) ramification came up. They are both appealing >> for their elegance and low complexity on QUIC endpoints. Beyond their quirks >> acknowledged here, here are a few considerations for troubleshooting: >> (snip) >> Given these, a benevolent, troubleshooting-minded passive midpoint will >> clearly vote for the square. Now the obvious question is: is this >> acceptable, or deemed too easy for a Murphy, Inc. active middlebox to see >> upstream losses and benevolently wreak havoc by delaying packets ? > > Thank you for raising the question. > > While I think that using square wave is a neat idea, I am not so sure > if the wavelength is correct, or if it would continue to be correct > for the lifetime of the transport protocol. I assume that other > patterns that have been proposed (e.g., PI, random) share the same > weakness. Again, these shortcomings have been acknowledged here, and could be addressed later, once the more general question I'm asking is settled: => Do "we", or do "we" not, want to disclose a signal that allows a midpoint observer to deduce: - both upstream and downstream half-RTTs (spin bit) - upstream losses (consensual sequence: square, Pi, fractal, whatever) Pros: manageability, troubleshooting Cons: some Murphy middlebox ossifying the Internet instead of dying in flames Once the answer is known and agreed upon, dedicated research on the best design for "measurement bits" will be timely. Not before. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --001a114a9d82d4b5000564f43041 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Just to give a name = to the fractal proposal: it is actually a grey code and these have a long h= istory of use in coding theory



On 11 February 201= 8 at 19.36.06, alexandre.f= errieux@orange.com (al= exandre.ferrieux@orange.com) wrote:

On 11/02/2018 17:51, Kazuho Oku wr= ote:
> 2018-02-11 2:34 GMT+09:00<alexandre.ferrieux@orange.com>:
>> Then Kazuho's square signal and Mikkel's Pi (or any o= ther consensual
>> self-synchronizing sequence) ramification came up. They are b= oth appealing
>> for their elegance and low complexity on QUIC endpoints. Beyo= nd their quirks
>> acknowledged here, here are a few considerations for troubles= hooting:
>> (snip)
>> Given these, a benevolent, troubleshooting-minded passive mid= point will
>> clearly vote for the square. Now the obvious question is: is = this
>> acceptable, or deemed too easy for a Murphy, Inc. active midd= lebox to see
>> upstream losses and benevolently wreak havoc by delaying pack= ets ?
>
> Thank you for raising the question.
>
> While I think that using square wave is a neat idea, I am not so s= ure
> if the wavelength is correct, or if it would continue to be correc= t
> for the lifetime of the transport protocol. I assume that other
> patterns that have been proposed (e.g., PI, random) share the same
> weakness.

Again, these shortcomings have been acknowledged here, and could be add= ressed =20
later, once the more general question I'm asking is settled:

=3D> Do "we", or do "we" not, want to disclose= a signal that allows a midpoint =20
observer to deduce:

- both upstream and downstream half-RTTs (spin bit)
- upstream losses (consensual sequence: square, Pi, fractal, whatever)

Pros: manageability, troubleshooting
Cons: some Murphy middlebox ossifying the Internet instead of dying i= n flames

Once the answer is known and agreed upon, dedicated research on the bes= t design =20
for "measurement bits" will be timely. Not before.


_______________________________________________________________________= __________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations conf= identielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les mes= sages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme= ou falsifie. Merci.

This message and its attachments may contain confidential or privileged= information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and = delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have b= een modified, changed or falsified.
Thank you.

--001a114a9d82d4b5000564f43041-- From nobody Sun Feb 11 11:06:21 2018 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 CD3391243FE for ; Sun, 11 Feb 2018 11:06:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 8G9ia7ft08QG for ; Sun, 11 Feb 2018 11:06:16 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 E0DBA1242F5 for ; Sun, 11 Feb 2018 11:06:15 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id e1so4133540ita.0 for ; Sun, 11 Feb 2018 11:06:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=/Jea5rp05aJBHTzG352dP0NsBMXJmqYa1KsuaqUzgio=; b=MET6MAa5PzMXqQ4l9kJUNXmZ9u3mFv9AfVB0mk5yi6cOKObXbzl63DW9pDXy/+1Kqm ySR6ZAVQ3wUoEF2nQCHOhoqlMBX0eTNCQ8mGkNgvyr8UUEAJfEymFeVHqgXPwYWMdcgf y//DNHYy8bPx36/y+Wvqt8R5CyV3ADTzKLfdLKtrY6PxwqyYzQsY3LGrpPWMHVHTn8O8 rPAPKsy4aZn9e/CCd7TO5fl/DWmuhlGPtqmOUr2l5ILAupjRB4AcRj1jKOAiJZ446NGB JOC/jr2XsDJHel5YDoLl+CjAGfKhmkFrSJs/2j8JL5tvUrqu5T6rUH9Uf+Q1ng/mis5P Mefg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=/Jea5rp05aJBHTzG352dP0NsBMXJmqYa1KsuaqUzgio=; b=Nd1QVNOlz0UiQDkUVwiAkeApit0j/Ryk0RtVFudQ2PGg0/I3D+D1HMt05/nDJ9NI68 YeLTMe0DCQpeyNPPXDFjRqOGT2BvYAB2P4yhxOTMCpN3LT6jQgBmvkHtf/9sMDYJCu/u hDoLY0VMoQxdQp10x0V65Pt7T1V0QCQ/tcfe8f3Uj3SlhchlrD/KW8EJeRfSXcR/X3As fBTQmdzX1CIlLgK5zLn0BkDSMmR01fBkQc4RdyGqzTc5PkFPwN+Fwi/7n+HjOGCFB9jm rRJnSNoaH8WtaPj97e3iLJWfQRmXLZOngbfjn6epFbq4zryeHnLir19jdW9wn32yfK8S qUlA== X-Gm-Message-State: APf1xPDlmoY1lWg/GcMAYFefIkPPwK2RO6yQX90x36z9g3CbviBOHobM g2XRFmIOCnNwpxMdlrHVE7im5r9PNStnZGBwrznVdw== X-Google-Smtp-Source: AH8x227Xio00TYRTCU2LWV8MoQu6oV3DvStEATxpem3ukCV/4GQogWXJBGZ3wdlcpakpT0XGEcn7/UYwLMsBsMHt7wE= X-Received: by 10.36.46.23 with SMTP id i23mr2759302ita.55.1518375975278; Sun, 11 Feb 2018 11:06:15 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 11 Feb 2018 11:06:14 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 11 Feb 2018 11:06:14 -0800 Message-ID: Subject: RE: Measurement bit(s) or not To: "Lubashev, Igor" , "alexandre.ferrieux@orange.com" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a114a9d82a45b560564f47401" 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, 11 Feb 2018 19:06:19 -0000 --001a114a9d82a45b560564f47401 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I already wrote this elsewhere, but the mail topic was a bit off, and I think it might actually be a good alternative to the other approaches balancing the simplicity of the square without the problem of having to wait for the square half period to detect loss. It is a fractal pattern in the form of grey code. For example an 8 bit code that is transmitted one bit a time. Each bit represents a wave length and changes at half the wave length. To simplify synchronisation, the same 8 bit pattern could be transmitted twice before a bit changes. This would support half-periods of 16, 32, =E2=80=A6, 2048 packets. In addition, there is a lot of error correcting coding theory around this with noise analysis and maximum likelihood decoders. https://en.wikipedia.org/wiki/Gray_code https://en.wikipedia.org/wiki/Constellation_diagram The encoding is simple as per Wikipedia: /* * This function converts an unsigned binary * number to reflected binary Gray code. * * The operator >> is shift right. The operator ^ is exclusive or. */unsigned int binaryToGray(unsigned int num){ return num ^ (num >> 1);} /* * This function converts a reflected binary * Gray code number to a binary number. * Each Gray code bit is exclusive-ored with all * more significant bits. */unsigned int grayToBinary(unsigned int num){ unsigned int mask =3D num; while (mask !=3D 0) { mask =3D mask >> 1; num =3D num ^ mask; } return num;} /* * A more efficient version, for Gray codes of 32 or fewer bits. */unsigned int grayToBinary32(unsigned int num){ num =3D num ^ (num >> 16); num =3D num ^ (num >> 8); num =3D num ^ (num >> 4); num =3D num ^ (num >> 2); num =3D num ^ (num >> 1); return num;} On 10 February 2018 at 22.41.51, Lubashev, Igor (ilubashe@akamai.com) wrote= : I am a bit sceptical about the square. With TCP, packet trace shows loss of any packet, except for SYN. The "square wave" whould show no loss at all for short connections (fewer than a "wavelength" of packets). Moreover, the square wave can only detect loss after up to the wave length of subsequent packets has been transmitted. If there is an application pause in transmission, loss may not become evident. Basically, a spin bit or a bit pattern (like a square wave) may help in troubleshooting, but it will be more uncertain and hokey than what people come to expect of tcp. We have be very clear in acknowledging it. -----Original Message----- *From:* alexandre.ferrieux@orange.com [alexandre.ferrieux@orange.com] *Received:* Saturday, 10 Feb 2018, 12:34PM *To:* quic@ietf.org [quic@ietf.org] *Subject:* Measurement bit(s) or not On 07/02/2018 14:34, Brian Trammell (IETF) wrote: > hi Jana, > >> 3. Some sequencing information -- a few bits of the packet number perhaps >> -- should be revealed (for monitoring. Number of bits TBD.) > > This is the crux of the argument. On one side we have the risk of misuse and > ossification (well, not ossification -- these bits are *meant* for the path > -- rather the risk that we'll figure out later that we specified the wrong > thing), on the other side we have the loss of visibility into how QUIC > traffic interacts with the network as compared to TCP, with a side question > of whether or not this visibility is really the transport layer's proble= m > despite the evolution the practice of diagnostics and troubleshooting using > TCP information. > > If we can come to agreement on this question, everything else falls into > place. I have my arguments here, but as you said, this subthread is not the > place for them. :) The crux indeed. So what about settling it first ? With the troubleshooting hat, I can only stress the need for measurement bits, for the benefit of everybody, since s**t happens, networks are imperfect, and nifty encapsulations-with-seqnum will simply not be where you need them. Now to the exact nature of these measurement bits: Thanks to the detailed exchanges on this thread, it is by now clear that a simple gapless counter, even nonzero-based and XORed, is not acceptable. Th= e 4-bit SSN comes pretty close but is not enough when things go really wrong (and they will - and that's where we need the tool). Then Kazuho's square signal and Mikkel's Pi (or any other consensual self-synchronizing sequence) ramification came up. They are both appealing for their elegance and low complexity on QUIC endpoints. Beyond their quirks acknowledged here, here are a few considerations for troubleshooting: (1) Since reordering is less of a concern to QUIC than to TCP, it becomes a secondary goal. This is nice, because the square doesn't see it, and the self-synchronizing sequence will only tolerate a mild one, and never see it= s detail like cycle length etc. (2) There's of course a huge difference between them in complexity for th= e midpoint: square is trivial, Pi is hefty. Given these, a benevolent, troubleshooting-minded passive midpoint will clearly vote for the square. Now the obvious question is: is this acceptable, or deemed too easy for a Murphy, Inc. active middlebox to see upstream losses and benevolently wreak havoc by delaying packets ? ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --001a114a9d82a45b560564f47401 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I already wrote this= elsewhere, but the mail topic was a bit off, and I think it might actually= be a good alternative to the other approaches balancing the simplicity of = the square without the problem of having to wait for the square half period= to detect loss.

It is a fra= ctal pattern in the form of grey code. For example an 8 bit code that is tr= ansmitted one bit a time. Each bit represents a wave length and changes at = half the wave length. To simplify synchronisation, the same 8 bit pattern c= ould be transmitted twice before a bit changes. This would support half-per= iods of 16, 32, =E2=80=A6, 2048 packets.

In addition, there is a lot of error correcting coding theory around = this with noise analysis and maximum likelihood decoders.

<= div id=3D"bloop_customfont" style=3D"margin:0px">
The encoding is simple as per Wikipedia:<= /div>

/*
 * Thi=
s function converts an unsigned binary
 * num=
ber to reflected binary Gray code.
 *
 * The=
 operator >> is shift right. The operator ^ is exclusive or.
 */
unsigned int binaryToGray(unsigned int num)
{
    return<=
/span> num ^ (num=
 >> 1);
}

/*
 * Thi=
s function converts a reflected binary
 * Gra=
y code number to a binary number.
 * Eac=
h Gray code bit is exclusive-ored with all
 * mor=
e significant bits.
 */
unsigned int grayToBinary(unsigned int num)
{
    unsigned int mas=
k =3D num;
    while (mask !=3D 0)
    {
        mask =3D mask >> 1;
        num =3D num ^ mask;
    }
    return<=
/span> num;
}

/*
 * A m=
ore efficient version, for Gray codes of 32 or fewer bits.
 */
unsigned int grayToBinary32(unsigned int num<=
span class=3D"p">)
{
    num =3D num ^ (num >> 16);
    num =3D num ^ (num >> 8);
    num =3D num ^ (num >> 4);
    num =3D num ^ (num >> 2);
    num =3D num ^ (num >> 1);
    return<=
/span> num;
}


On 10 February 2018 at = 22.41.51, Lubashev, Igor (ilubashe@a= kamai.com) wrote:

I am a bit sceptical about the square. With TCP, packet trace shows loss of any packet, except for SYN. The "square wave" whould show no loss at all for short connections (fewer than a "wavelength" o= f packets). Moreover, the square wave can only detect loss after up to the wave length of subsequent packets has been transmitted. If there is an application pause in transmission, loss may not become evident.

Basically, a spin bit or a bit pattern (like a square wave) may help in troubleshooting, but it will be more uncertain and hokey than what people come to expect of tcp. We have be very clear in acknowledging it.

-----Original Message-----
From: alexandre.fer= rieux@orange.com [alexandre.ferrieux@orange= .com]
Received: Saturday, 10 Feb 2018, 12:34PM
To: quic@ietf.org [quic@ietf.org]
Subject: Measurement bit(s) or not

On= 07/02/2018 14:34, Brian Trammell (IETF) wrote:
=C2=A0> hi Jana,
=C2=A0>
=C2=A0>> 3. Some sequencing information -- a few bits of the packet number perhaps
=C2=A0>> -- should be revealed (for monitoring. Number of bits TBD.)
=C2=A0>
=C2=A0> This is the crux of the argument. On one side we have the risk of misuse and
=C2=A0> ossification (well, not ossification -- these bits are *meant* for the path
=C2=A0> -- rather the risk that we'll figure out later that we specified the wrong
=C2=A0> thing), on the other side we have the loss of visibility into how QUIC
=C2=A0> traffic interacts with the network as compared to TCP, with a side question
=C2=A0> of whether or not this visibility is really the transport layer's problem
=C2=A0> despite the evolution the practice of diagnostics and troubleshooting using
=C2=A0> TCP information.
=C2=A0>
=C2=A0> If we can come to agreement on this question, everything else falls into
=C2=A0> place. I have my arguments here, but as you said, this subthread is not the
=C2=A0> place for them. :)

The crux indeed. So what about settling it first ?

With the troubleshooting hat, I can only stress the need for measurement bits,
for the benefit of everybody, since s**t happens, networks are imperfect, and
nifty encapsulations-with-seqnum will simply not be where you need them.

Now to the exact nature of these measurement bits:

Thanks to the detailed exchanges on this thread, it is by now clear that a
simple gapless counter, even nonzero-based and XORed, is not acceptable. The
4-bit SSN comes pretty close but is not enough when things go really wrong (and
they will - and that's where we need the tool).

Then Kazuho's square signal and Mikkel's Pi (or any other consensual
self-synchronizing sequence) ramification came up. They are both appealing for
their elegance and low complexity on QUIC endpoints. Beyond their quirks
acknowledged here, here are a few considerations for troubleshooting:

=C2=A0 (1) Since reordering is less of a concern to QUIC than to TCP, it becomes a
secondary goal. This is nice, because the square doesn't see it, and the
self-synchronizing sequence will only tolerate a mild one, and never see its
detail like cycle length etc.

=C2=A0 (2) There's of course a huge difference between them in complexity for the
midpoint: square is trivial, Pi is hefty.

Given these, a benevolent, troubleshooting-minded passive midpoint will clearly
vote for the square. Now the obvious question is: is this acceptable, or deemed
too easy for a Murphy, Inc. active middlebox to see upstream losses and
benevolently wreak havoc by delaying packets ?

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--001a114a9d82a45b560564f47401-- From nobody Sun Feb 11 11:25:23 2018 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 DC9A2126DEE for ; Sun, 11 Feb 2018 11:25:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 EX9OrD3n25jH for ; Sun, 11 Feb 2018 11:25:16 -0800 (PST) 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 3FAD7126C22 for ; Sun, 11 Feb 2018 11:25:16 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id n206so4155227itg.1 for ; Sun, 11 Feb 2018 11:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=KIq2tzTEekOiDgBQsknQXrpSce0XyYO6PoWzl/DBbAE=; b=VPZJC6K0EML58ekWKCdlfWU/x06STg5t1D94eWfed+XTSgLKpvFNDwhFUn87M3EtA3 SYqkYVjKk0B+dPURR2JstuOqLcvURZJcuF/D5fLwN85j+H6OAKZsl23LKjCTdm9dYFrM UAycw8rcef5gqkEtZMCNukmv1SgzYvtft17G5G59Y+9qhAU18F2dUlQ4o/Yq4jC5ABMk aWritrtFcMdgB07zfhfjKOS7yQFWt6seub2h5Du8aVQGcxBnmaD9i7Oz1+PwLNrfdxGY 2hcvUH1TVj8Te69Z2PuqxgZxbQcGBLRvn8l3S3sulfeGpGTNECi2ARoR5gx+MxQRqUde tcJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=KIq2tzTEekOiDgBQsknQXrpSce0XyYO6PoWzl/DBbAE=; b=CCI31L4uvvRmjBnVGhug5hS6Qn6fcZHt39gVXMhqaQCSDhTeUJB/B2ucybVqODjrDV G6212WU6ziAJjPtbsHTUJtsMFRkiK//nLOYtysjU5nk+m+4gGb89PqfkOTGrexLAiDHP 364wJE57TUVZOAj7GuaSLDDjx800WCsqzELXt/+tUueMlob3viwLkLOPIS/5yforDNr1 f5Pv6BKQM/vwf0gKqJbW2EK9d9/0zWbGlZNvQ4pkWSGS8jKAf8GI7tg6yWYA1X1CjD4k 8exPYHjYv+x4udTovY9p5VAw6vFdglBbx1lR9+xojVJP+O40gzAxeBzYPayxnhchIqbm l7zw== X-Gm-Message-State: APf1xPBm/ZA4M0fU9wEckH+qNidsyp4QKYBxPzRvhZoLBU7pekTk9x3m vs8JpW200pRV4daPqdi043VbFfdu5LNHOy+97ydXhw== X-Google-Smtp-Source: AH8x225n6rMS0aZVEM5xAbApf4POZPdQ63PxXbz05g4S2nEa21AnoFJtZHJFmBgePws/OCGWb+wh5ucBlMSf4PZLyns= X-Received: by 10.36.10.207 with SMTP id 198mr2721440itw.42.1518377115642; Sun, 11 Feb 2018 11:25:15 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 11 Feb 2018 11:25:14 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 11 Feb 2018 11:25:14 -0800 Message-ID: Subject: RE: Measurement bit(s) or not To: "Lubashev, Igor" , "alexandre.ferrieux@orange.com" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a1144b8289ceec60564f4b813" 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, 11 Feb 2018 19:25:19 -0000 --001a1144b8289ceec60564f4b813 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Actually, since the half-period is 16*2048 so loss can be detected up to 32K packets, or typically 32MB worth of data. At the same time loss can be detected within the first 16 bytes by trivially comparing the first 8 bits with the next 8 bits. If these are not the same, something is off. But it is perfect because all bits could be zero. To improve on this, each transmitted bit could be spread over two packets, 0, 1 for sending a reset bit, and 1, 0 for sending a set bit. If we then drop repeating the 8 bit pattern, the shortest half-period remains at 16 packets since an 8-bit Gray code requires 16 packets. Now we can detect a single loss or swap already after two packets, although this is probably not interesting since reordering could happen already in multiple send queues. On 11 February 2018 at 20.06.14, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: I already wrote this elsewhere, but the mail topic was a bit off, and I think it might actually be a good alternative to the other approaches balancing the simplicity of the square without the problem of having to wait for the square half period to detect loss. It is a fractal pattern in the form of grey code. For example an 8 bit code that is transmitted one bit a time. Each bit represents a wave length and changes at half the wave length. To simplify synchronisation, the same 8 bit pattern could be transmitted twice before a bit changes. This would support half-periods of 16, 32, =E2=80=A6, 2048 packets. In addition, there is a lot of error correcting coding theory around this with noise analysis and maximum likelihood decoders. https://en.wikipedia.org/wiki/Gray_code https://en.wikipedia.org/wiki/Constellation_diagram The encoding is simple as per Wikipedia: /* * This function converts an unsigned binary * number to reflected binary Gray code. * * The operator >> is shift right. The operator ^ is exclusive or. */unsigned int binaryToGray(unsigned int num){ return num ^ (num >> 1);} /* * This function converts a reflected binary * Gray code number to a binary number. * Each Gray code bit is exclusive-ored with all * more significant bits. */unsigned int grayToBinary(unsigned int num){ unsigned int mask =3D num; while (mask !=3D 0) { mask =3D mask >> 1; num =3D num ^ mask; } return num;} /* * A more efficient version, for Gray codes of 32 or fewer bits. */unsigned int grayToBinary32(unsigned int num){ num =3D num ^ (num >> 16); num =3D num ^ (num >> 8); num =3D num ^ (num >> 4); num =3D num ^ (num >> 2); num =3D num ^ (num >> 1); return num;} On 10 February 2018 at 22.41.51, Lubashev, Igor (ilubashe@akamai.com) wrote= : I am a bit sceptical about the square. With TCP, packet trace shows loss of any packet, except for SYN. The "square wave" whould show no loss at all for short connections (fewer than a "wavelength" of packets). Moreover, the square wave can only detect loss after up to the wave length of subsequent packets has been transmitted. If there is an application pause in transmission, loss may not become evident. Basically, a spin bit or a bit pattern (like a square wave) may help in troubleshooting, but it will be more uncertain and hokey than what people come to expect of tcp. We have be very clear in acknowledging it. -----Original Message----- *From:* alexandre.ferrieux@orange.com [alexandre.ferrieux@orange.com] *Received:* Saturday, 10 Feb 2018, 12:34PM *To:* quic@ietf.org [quic@ietf.org] *Subject:* Measurement bit(s) or not On 07/02/2018 14:34, Brian Trammell (IETF) wrote: > hi Jana, > >> 3. Some sequencing information -- a few bits of the packet number perhaps >> -- should be revealed (for monitoring. Number of bits TBD.) > > This is the crux of the argument. On one side we have the risk of misuse and > ossification (well, not ossification -- these bits are *meant* for the path > -- rather the risk that we'll figure out later that we specified the wrong > thing), on the other side we have the loss of visibility into how QUIC > traffic interacts with the network as compared to TCP, with a side question > of whether or not this visibility is really the transport layer's proble= m > despite the evolution the practice of diagnostics and troubleshooting using > TCP information. > > If we can come to agreement on this question, everything else falls into > place. I have my arguments here, but as you said, this subthread is not the > place for them. :) The crux indeed. So what about settling it first ? With the troubleshooting hat, I can only stress the need for measurement bits, for the benefit of everybody, since s**t happens, networks are imperfect, and nifty encapsulations-with-seqnum will simply not be where you need them. Now to the exact nature of these measurement bits: Thanks to the detailed exchanges on this thread, it is by now clear that a simple gapless counter, even nonzero-based and XORed, is not acceptable. Th= e 4-bit SSN comes pretty close but is not enough when things go really wrong (and they will - and that's where we need the tool). Then Kazuho's square signal and Mikkel's Pi (or any other consensual self-synchronizing sequence) ramification came up. They are both appealing for their elegance and low complexity on QUIC endpoints. Beyond their quirks acknowledged here, here are a few considerations for troubleshooting: (1) Since reordering is less of a concern to QUIC than to TCP, it becomes a secondary goal. This is nice, because the square doesn't see it, and the self-synchronizing sequence will only tolerate a mild one, and never see it= s detail like cycle length etc. (2) There's of course a huge difference between them in complexity for th= e midpoint: square is trivial, Pi is hefty. Given these, a benevolent, troubleshooting-minded passive midpoint will clearly vote for the square. Now the obvious question is: is this acceptable, or deemed too easy for a Murphy, Inc. active middlebox to see upstream losses and benevolently wreak havoc by delaying packets ? ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --001a1144b8289ceec60564f4b813 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Actually, since the = half-period is 16*2048 so loss can be detected up to 32K packets, or typica= lly 32MB worth of data. At the same time loss can be detected within the fi= rst 16 bytes by trivially comparing the first 8 bits with the next 8 bits. = If these are not the same, something is off.

But it is perfect because all bits could be zero.

To improve on this, ea= ch transmitted bit could be spread over two packets, 0, 1 for sending a res= et bit, and 1, 0 for sending a set bit. If we then drop repeating the 8 bit= pattern, the shortest half-period remains at 16 packets since an 8-bit Gra= y code requires 16 packets.

Now we can detect a single= loss or swap already after two packets, although this is probably not inte= resting since reordering could happen already in multiple send queues.
<= p class=3D"airmail_on">On 11 February 2018 at 20.06.14, Mikkel Fahn=C3=B8e = J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

I already wrote this elsewhere, but the mail topic was a bit off, and I think it might actually be a good alternative to the other approaches balancing the simplicity of the square without the problem of having to wait for the square half period to detect loss.

It is a fractal pattern in the form of grey code. For example an 8 bit code that is transmitted one bit a time. Each bit represents a wave length and changes at half the wave length. To simplify synchronisation, the same 8 bit pattern could be transmitted twice before a bit changes. This would support half-periods of 16, 32, =E2=80=A6, 2048 packets.

In addition, there is a lot of error correcting coding theory around this with noise analysis and maximum likelihood decoders.

https://en.wikipedia.org/wiki/Gray_code

The encoding is simple as per Wikipedia:

/*
 * Thi=
s function converts an unsigned binary
 * num=
ber to reflected binary Gray code.
 *
 * The=
 operator >> is shift right. The operator ^ is exclusive or.
 */
unsigned int binaryToGray(unsigned int num)
{
    return<=
/span> num ^ (num=
 >> 1);
}

/*
 * Thi=
s function converts a reflected binary
 * Gra=
y code number to a binary number.
 * Eac=
h Gray code bit is exclusive-ored with all
 * mor=
e significant bits.
 */
unsigned int grayToBinary(unsigned int num)
{
    unsigned int mas=
k =3D num;
    while (mask !=3D 0)
    {
        mask =3D mask >> 1;
        num =3D num ^ mask;
    }
    return<=
/span> num;
}

/*
 * A m=
ore efficient version, for Gray codes of 32 or fewer bits.
 */
unsigned int grayToBinary32(unsigned int num<=
span class=3D"p">)
{
    num =3D num ^ (num >> 16);
    num =3D num ^ (num >> 8);
    num =3D num ^ (num >> 4);
    num =3D num ^ (num >> 2);
    num =3D num ^ (num >> 1);
    return<=
/span> num;
}


On 10 February 2018 at 22.41.51, Lubashev, Igor (ilubashe@akamai.com) wrote:

I am a bit sceptical about the square. With TCP, packet trace shows loss of any packet, except for SYN. The "square wave" whould show no loss at all for short connections (fewer than a "wavelength" o= f packets). Moreover, the square wave can only detect loss after up to the wave length of subsequent packets has been transmitted. If there is an application pause in transmission, loss may not become evident.

Basically, a spin bit or a bit pattern (like a square wave) may help in troubleshooting, but it will be more uncertain and hokey than what people come to expect of tcp. We have be very clear in acknowledging it.

-----Original Message-----
From: alexandre.fer= rieux@orange.com [alexandre.ferrieux@orange= .com]
Received: Saturday, 10 Feb 2018, 12:34PM
To: quic@ietf.org [quic@ietf.org]
Subject: Measurement bit(s) or not

On= 07/02/2018 14:34, Brian Trammell (IETF) wrote:
=C2=A0> hi Jana,
=C2=A0>
=C2=A0>> 3. Some sequencing information -- a few bits of the packet number perhaps
=C2=A0>> -- should be revealed (for monitoring. Number of bits TBD.)
=C2=A0>
=C2=A0> This is the crux of the argument. On one side we have the risk of misuse and
=C2=A0> ossification (well, not ossification -- these bits are *meant* for the path
=C2=A0> -- rather the risk that we'll figure out later that we specified the wrong
=C2=A0> thing), on the other side we have the loss of visibility into how QUIC
=C2=A0> traffic interacts with the network as compared to TCP, with a side question
=C2=A0> of whether or not this visibility is really the transport layer's problem
=C2=A0> despite the evolution the practice of diagnostics and troubleshooting using
=C2=A0> TCP information.
=C2=A0>
=C2=A0> If we can come to agreement on this question, everything else falls into
=C2=A0> place. I have my arguments here, but as you said, this subthread is not the
=C2=A0> place for them. :)

The crux indeed. So what about settling it first ?

With the troubleshooting hat, I can only stress the need for measurement bits,
for the benefit of everybody, since s**t happens, networks are imperfect, and
nifty encapsulations-with-seqnum will simply not be where you need them.

Now to the exact nature of these measurement bits:

Thanks to the detailed exchanges on this thread, it is by now clear that a
simple gapless counter, even nonzero-based and XORed, is not acceptable. The
4-bit SSN comes pretty close but is not enough when things go really wrong (and
they will - and that's where we need the tool).

Then Kazuho's square signal and Mikkel's Pi (or any other consensual
self-synchronizing sequence) ramification came up. They are both appealing for
their elegance and low complexity on QUIC endpoints. Beyond their quirks
acknowledged here, here are a few considerations for troubleshooting:

=C2=A0 (1) Since reordering is less of a concern to QUIC than to TCP, it becomes a
secondary goal. This is nice, because the square doesn't see it, and the
self-synchronizing sequence will only tolerate a mild one, and never see its
detail like cycle length etc.

=C2=A0 (2) There's of course a huge difference between them in complexity for the
midpoint: square is trivial, Pi is hefty.

Given these, a benevolent, troubleshooting-minded passive midpoint will clearly
vote for the square. Now the obvious question is: is this acceptable, or deemed
too easy for a Murphy, Inc. active middlebox to see upstream losses and
benevolently wreak havoc by delaying packets ?

___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

--001a1144b8289ceec60564f4b813-- From nobody Sun Feb 11 13:13:02 2018 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 DFFBD1271FD for ; Sun, 11 Feb 2018 13:13:00 -0800 (PST) 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 YK_uU81443n3 for ; Sun, 11 Feb 2018 13:12:59 -0800 (PST) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::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 E4BEF127078 for ; Sun, 11 Feb 2018 13:12:58 -0800 (PST) Received: by mail-pl0-x235.google.com with SMTP id o11so450973pls.2 for ; Sun, 11 Feb 2018 13:12:58 -0800 (PST) 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=uKuxUtj++t32xlUEHwtDxmXa064tjzOU7LdpLk08C8A=; b=WSYOsOtS0VBI+yDva+dXf0YeEyQc8vDEMvxJyvyJ9Z28Y3pIuPhRSkHAirs36l5ip/ k1NoSkZlQQcWNrnjgjsuaMzV5p3mMBcEGYLGQbc4VINu9QZ9k3mvZZQS5BrUOko3Vh2M /uTyjFk88NDzY1pNSw0vH5aap9zfjymZdMAs9NA1y6pXGR8OZtBnVRkr/SXzLCzCKsuP ypUN7mQ71c66umLKyJij5Xr5Bvvxt48WQKu3ZpsCaNO5YhaO5wWR2aQx0QAEFYQ95y+L JDXtuJWq0CVE8zAF5VSjoszTG5WeWFxyeNJo8jYZX882qvDhW6mjF/wppUdjGF0leDEf lFHw== 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=uKuxUtj++t32xlUEHwtDxmXa064tjzOU7LdpLk08C8A=; b=TL/sq3Dz/DBs1zT06Eg5WlFf38Hv2F4IrDrzXetiDy5/RO3cF2EPjWdt82VDW7H8nQ +EAjh+7nQPgXSXxG4osy8GAfswBACCai671bTLJIURPPGSp9RPOKPrHkIhQFRWaor3WJ 2rKdVmVot/095ScpIRndro7kTbZ5dBhUA57mdrUzwNWjnVNQXV6v/QkqzNh2mTzoDIWu oQaZvY+6D5PHSE18auo/4MrlcXBjgzG50C3Yd6lgDoPStm+AI+T/tbrUc7663mKV+OEd RtG4gJv+gqTA+brzb8I5E/xIjVKVGosNmhBlJCLhYNyxWvY12lgMmpk9nRZuY/h5bji/ 7fUA== X-Gm-Message-State: APf1xPBMcqqV6uxw6st+JtM3aFdYDtyzc/ocf6SiG/qQyTwUT9mh71IE Ps8Gqukq0jdLgALBjPtWFv2EQx2ttc9rruaiEG0= X-Google-Smtp-Source: AH8x224BV7EpvTIkT/yEPx0/HOgvxR0B3b0a1lSpVt8i7UAXGQgqpw6UpCxkzBVuPxlor5/dprQFAtdP5AhlLiahmBI= X-Received: by 2002:a17:902:2bc5:: with SMTP id l63-v6mr9005209plb.108.1518383578257; Sun, 11 Feb 2018 13:12:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.191.134 with HTTP; Sun, 11 Feb 2018 13:12:57 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Mon, 12 Feb 2018 06:12:57 +0900 Message-ID: Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG , Lili Peaudchien 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: Sun, 11 Feb 2018 21:13:01 -0000 Hi Mikkel, Thank you for the response. Please see my comments in-line. 2018-02-12 3:05 GMT+09:00 Mikkel Fahn=C3=B8e J=C3=B8rgensen : > I need to read it more closely to understand the finer details, but my > immediate reaction is that I do not like this at all. > > It appears to add unnecessary complication and there could be a host of > hidden security issues. The basic fact that someone other than the endpoi= nts > can affect the traffic can lead to all sorts of issues and the informatio= n > transmitted might be abused in a number of ways, for example to learn abo= ut > the kind of traffic being sent, the internal layout of a subnetwork by > leaking presence of other middleware, the OS and applications in use etc. That is generally true. But I am not sure why giving the option to the server to expose the values being listed (# of packets sent, lost, rtt, number of lost packets between the packets that the on-path device has received) is a concern. They are the stats that can be collected by observing a TCP connection. Note that in the proposed approach, the exposure only happens if the server wants to expose them, and the server can choose what to expose. I think that this is a good thing in terms of privacy concern, compared to unconditionally using some bits to expose information that can be collected by a passible observer. > > I much prefer a simple no-nonsense solution over trying to handle protoco= l > lifetime variations. The QUIC protocol could fix issues in new versions a= nd > until then a simple predictable signal should suffice, even if it isn=E2= =80=99t > perfect. I think that I have a different goal here. I want to provide network operators a good set of tools that they can use for diagnosing issues of QUIC v1. I do not want to see people not using QUIC due to the network operator not being diagnose and fix the issues. We might come up with a good signal encoded on each packet, as we define multiple versions of QUIC. But that means spending multiple years (if not multiple decades). I am not sure if I want to wait that long. That is the motive behind my proposal of using a subprotocol that can be optionally implemented by a server and an on-path observer, and that also can evolve independently from QUIC. > This also makes middleware simpler, since a signal is always > present in a predictable manner. > > We could have some fractal square waves to deal by having a short repeati= ng > signal that periodically changes at different wave lengths, e.g. a a > repeating 8 bit pattern where each bit is flipped at the period of the wa= ve > length it represents. That ought to be enough. The pattern repeats every = 8 > packets. The wave lengths could be 16, 32, 64, 128, 256, 512, 1024, 2048= so > that same 8 bits are always transmitted twice before a bit changes which > should help synchronise it. It might not be perfect, but it ought to be > sufficient. > > I=E2=80=99m also starting to think that just exposing a sequential counte= r per path > is much simpler even if it leads to ossification - see segment packet num= ber > proposal https://github.com/quicwg/base-drafts/issues/1105 > > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 11 February 2018 at 17.51.37, Kazuho Oku (kazuhooku@gmail.com) wrote: > > 2018-02-11 2:34 GMT+09:00 : >> Then Kazuho's square signal and Mikkel's Pi (or any other consensual >> self-synchronizing sequence) ramification came up. They are both appeali= ng >> for their elegance and low complexity on QUIC endpoints. Beyond their >> quirks >> acknowledged here, here are a few considerations for troubleshooting: >> (snip) >> Given these, a benevolent, troubleshooting-minded passive midpoint will >> clearly vote for the square. Now the obvious question is: is this >> acceptable, or deemed too easy for a Murphy, Inc. active middlebox to se= e >> upstream losses and benevolently wreak havoc by delaying packets ? > > Thank you for raising the question. > > While I think that using square wave is a neat idea, I am not so sure > if the wavelength is correct, or if it would continue to be correct > for the lifetime of the transport protocol. I assume that other > patterns that have been proposed (e.g., PI, random) share the same > weakness. > > Therefore, I have written a proposal of a very different approach, > which is the following I-D. > > Performance Metrics Subprotocol for QUIC > https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/ > > The I-D proposes to add a subprotocol that is used between an on-path > observer and the QUIC server to obtain the performance metrics. At the > latency of 1 RTT, the subprotocol can observe accurate upstream > loss/reorder rate, as well as SRTT / RTTVAR. > > I believe that it is not difficult to implement on the server-side > (please refer to section 4). Client needs no change. > > Since the proposed approach does not hard-code any information for > observation on the wire, the hard part of the design issue goes away. > We can adjust what (and how) to observe independently from the QUIC > transport. I think that this is not only a win in terms of design but > also might have positive effect on moving the standardization process > forward, since we would no longer be constrained by the discussion of > what should be observable "on-the-wire." > > Privacy concern regarding observation becomes minor, since observation > becomes "observable" and deniable by an endpoint. > > Although SRTT / RTTVAR is observable, I am not sure if it can be used > to replace the Spin Bit proposal. It depends on how often and how fast > an observer needs to see the metrics. Primary target of my proposal is > to help diagnosing issues. > > Please let me know what you think. > > ---------- Forwarded message ---------- > From: > Date: 2018-02-12 1:43 GMT+09:00 > Subject: New Version Notification for draft-kazuho-quic-perf-metrics-00.t= xt > To: Kazuho Oku > > > > A new version of I-D, draft-kazuho-quic-perf-metrics-00.txt > has been successfully submitted by Kazuho Oku and posted to the > IETF repository. > > Name: draft-kazuho-quic-perf-metrics > Revision: 00 > Title: Performance Metrics Subprotocol for QUIC > Document date: 2018-02-12 > Group: Individual Submission > Pages: 8 > URL: > https://www.ietf.org/internet-drafts/draft-kazuho-quic-perf-metrics-00.tx= t > Status: https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/ > Htmlized: https://tools.ietf.org/html/draft-kazuho-quic-perf-metrics-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-kazuho-quic-perf-metrics-00 > > > Abstract: > This memo proposes a subprotocol that can be used to query the > performance metrics of a QUIC path. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > -- > Kazuho Oku > --=20 Kazuho Oku From nobody Sun Feb 11 13:32:29 2018 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 F01871271FD for ; Sun, 11 Feb 2018 13:32:27 -0800 (PST) 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 ux52RVK1qWYn for ; Sun, 11 Feb 2018 13:32:26 -0800 (PST) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::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 1172B1200B9 for ; Sun, 11 Feb 2018 13:32:26 -0800 (PST) Received: by mail-pl0-x22b.google.com with SMTP id o11so465889pls.2 for ; Sun, 11 Feb 2018 13:32:26 -0800 (PST) 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=XDEMhAsctnaRYBGEb1P8x1x/fFonXRPsrtKbOVwry8E=; b=V3HVHhnIqN+K1s1tKeSfFpc+wC0yuVx8s+nkuqguAIQ2jQpRGrqO8fnWSWayF5EO7u oc2yrtAtUcZmmf4E+B11v2ToDgUVOB64yicSX6oQunE9DcujLerDowVH6irRSvPwj2oe sn6oCOUlNQxd4zIYBJT1A10YfD9Ze3MrBzcUMxXy5C695aGKk2obGPJ68W3KXidPSOEj lS05xwM7HUHiRx7M6+9F8zMOE/+MLWzgyvadPwFso/jAEryI8267kfkcuk+ksMmFPRa4 83yRoIqMpXf5stq2aWIE/Eeot5fGLPO51uF2/7Co4ZeGi8X9Fz94EAM0sMebF0sQhR8h qMyw== 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=XDEMhAsctnaRYBGEb1P8x1x/fFonXRPsrtKbOVwry8E=; b=hLyNvxDk3nAvseA9H1iZFxRnrEpdGRL+kS2ilG4U4JJbin5QnCvF+gp3BZlhUKyF6B HtHLWPg1HDb6nTyAU3yjYpfNe7IhivfcJAXxwuh/ZXHJvn6f3p1sJqjM2ye2yhfZufr/ 7khjiB3yzBVyfYXvMSWgQ+hbvRMEY8HE7f4azvy4CSIJTt8Uicv6Xj/ShGUGGs/Fg/y8 lTpH9UPyoSHXkWsuRpJpZsDZM62YiEM7WhQnuCTM3ejRujemM20xKm+gsLRnzxOyJYVe 6lRzeb8UM/6RBxFlRyMzekDgiUBTCSBVkfLYGL0bCqvVYttIQJ40LT2YqLbXdkhbdA3z SScw== X-Gm-Message-State: APf1xPCZbX1sNKIoTr0gCnhp77lP1w0BDZzjDyRn4NykODi5/UWjgFCE jWZuiPQQ14on3WBi8VztpIys4vYr4tT9gJNt7CI= X-Google-Smtp-Source: AH8x226I4E4E+TPrnMGDGgYNsYvkVClSkks1Pl9EI0YK/H9xuJx6NnkjU55zg4gn/ZzPqrxjPGRz1CD0FqCyahw6L+0= X-Received: by 2002:a17:902:529:: with SMTP id 38-v6mr630239plf.327.1518384745345; Sun, 11 Feb 2018 13:32:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.191.134 with HTTP; Sun, 11 Feb 2018 13:32:24 -0800 (PST) In-Reply-To: <5700_1518374159_5A808D0F_5700_161_1_5A808D14.30503@orange.com> References: <5700_1518374159_5A808D0F_5700_161_1_5A808D14.30503@orange.com> From: Kazuho Oku Date: Mon, 12 Feb 2018 06:32:24 +0900 Message-ID: Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) To: Lili Peaudchien 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: Sun, 11 Feb 2018 21:32:28 -0000 2018-02-12 3:36 GMT+09:00 : > On 11/02/2018 17:51, Kazuho Oku wrote: >> >> 2018-02-11 2:34 GMT+09:00: >>> >>> Then Kazuho's square signal and Mikkel's Pi (or any other consensual >>> self-synchronizing sequence) ramification came up. They are both >>> appealing >>> for their elegance and low complexity on QUIC endpoints. Beyond their >>> quirks >>> acknowledged here, here are a few considerations for troubleshooting: >>> (snip) >>> Given these, a benevolent, troubleshooting-minded passive midpoint will >>> clearly vote for the square. Now the obvious question is: is this >>> acceptable, or deemed too easy for a Murphy, Inc. active middlebox to >>> see >>> upstream losses and benevolently wreak havoc by delaying packets ? >> >> >> Thank you for raising the question. >> >> While I think that using square wave is a neat idea, I am not so sure >> if the wavelength is correct, or if it would continue to be correct >> for the lifetime of the transport protocol. I assume that other >> patterns that have been proposed (e.g., PI, random) share the same >> weakness. > > > Again, these shortcomings have been acknowledged here, and could be > addressed later, once the more general question I'm asking is settled: > > => Do "we", or do "we" not, want to disclose a signal that allows a > midpoint observer to deduce: > > - both upstream and downstream half-RTTs (spin bit) > - upstream losses (consensual sequence: square, Pi, fractal, > whatever) > > Pros: manageability, troubleshooting > Cons: some Murphy middlebox ossifying the Internet instead of dying in > flames > > Once the answer is known and agreed upon, dedicated research on the best > design for "measurement bits" will be timely. Not before. Hi Lili, thank you for your response. While I like the orderly approach that you propose, I might also argue that "if" we want to disclose a signal to observers might depend on "how" the signal looks like. And to me it seemed that, until now, we have shared a hidden premise that the observation is a passive action. But as I stated in my I-D, it is possible to define the observation scheme as a request-response protocol. The two (i.e. passive observation and use of request-response protocol to obtain the metrics) have very different characteristics; something that we might want to consider before making the decision. That it one of the reasons behind my submitting the I-D at this moment. > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > -- Kazuho Oku From nobody Sun Feb 11 13:50:10 2018 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 34D021200B9 for ; Sun, 11 Feb 2018 13:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 q5u-1gspUUjy for ; Sun, 11 Feb 2018 13:50:07 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 49812127599 for ; Sun, 11 Feb 2018 13:50:07 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id 72so15319034iom.10 for ; Sun, 11 Feb 2018 13:50:07 -0800 (PST) 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=mAdjzh73Ezc7DRfv58k9OqEQWIi7b0FSocU86WQkQyI=; b=CmI6mjRmsoeB7fy0xzbvm84mTkpJcJV7Bnm5V2iioQxQP8Y7WpJ4tvYyxkuHvZYnSW v+Vw7GYZty1MccF3m43zZwPvLZ0ZsELZy7LGMYviyVk+d9BWJeN63l7qvlDU2T2hIP1s t0yWQf4EjoOCfGoCUMzSmA1BlTqIdf1+moREgEVVxZIpFw2ESwYf4kz1ZuLoZJ8Zsp/K lLbAqTPgtpapAzjny3Z2wMmxgjTXTfjfCQhl0akHKNAGakUjFg9BmikkVgxMwgRIRhJV Ugg06taIXHJrk2Osw9CasHjKrKzcBp38BRahd5DD93dMpaJMxSbPmiJdyTJtPpUxBiyU pcQg== 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=mAdjzh73Ezc7DRfv58k9OqEQWIi7b0FSocU86WQkQyI=; b=dnI0Sd68sMJtUOMlj8keUCskZWldAA2VNTlQnX6xrTYUqtoOWAHZrHgPcDJQMiZvnn O/yZm+F0eyQ35lK8deO5narOyQ0vRFO5pwsQ6sJ13exOwwwiKnS38aJeW7cAeQjXltjI DhH3UFxu/C7kUlauwLIp9D829+s8e1G9oVYAJ46p2bNhZnBp+Rj+xp88pP/7gDe2F39Y ZJZwGx7x1zMBvzt7YBR1bgoIZUCBHlv6BTBCYmPWRmMa/fs4wGZbESZNOlAputLWqJ6G k3bu9a0y3KeirYVwUsC9ZStoSkHu6QCcEJij9oIdJ185D855Tv5ZQhTXoTujyk9b7VnJ x8dA== X-Gm-Message-State: APf1xPDYhni6Tq4o3OZ+qgZx0piF+GqD/DkFNLenkWzGTeLxyvEg2nyy 6Zc5iVrdrblS0W0995nJqHZOKAwW8faKQt9CgcqsfA== X-Google-Smtp-Source: AH8x226dLO64A+93HRlOk8gP/cbNg/QPM77H30HluoBI7KfNleN2JPA8itKQy6S0pUp0kVUxp5K5Hld3e7ETqLC8+nA= X-Received: by 10.107.141.207 with SMTP id p198mr10821464iod.204.1518385806351; Sun, 11 Feb 2018 13:50:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Sun, 11 Feb 2018 13:49:45 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Sun, 11 Feb 2018 16:49:45 -0500 Message-ID: Subject: Re: The Recovery Period To: Martin Thomson Cc: Jana Iyengar , Patrick McManus , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0621dc9f4a390564f6be1f" 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, 11 Feb 2018 21:50:09 -0000 --94eb2c0621dc9f4a390564f6be1f Content-Type: text/plain; charset="UTF-8" PR sent: https://github.com/quicwg/base-drafts/pull/1106 On Fri, Feb 9, 2018 at 5:20 PM, Martin Thomson wrote: > Ian already did. I think that putting that in the draft would be a good > idea. > > On Sat, Feb 10, 2018 at 9:03 AM, Jana Iyengar wrote: > > Suggest text if you think it can be made better! > > > > On Fri, Feb 9, 2018 at 12:24 PM, Patrick McManus > > wrote: > >> > >> you're right - its ok. I missed the "when a larger" part (reading it as > >> "when it is recovered"). > > > > > --94eb2c0621dc9f4a390564f6be1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Feb 9, 2018= at 5:20 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
Ian already did.=C2=A0 I think t= hat putting that in the draft would be a good idea.

On Sat, Feb 10, 2018 at 9:03 AM, Jana Iyengar <jri@google.com> wrote:
> Suggest text if you think it can be made better!
>
> On Fri, Feb 9, 2018 at 12:24 PM, Patrick McManus <pmcmanus@mozilla.com>
> wrote:
>>
>> you're right - its ok. I missed the "when a larger" = part (reading it as
>> "when it is recovered").
>
>

--94eb2c0621dc9f4a390564f6be1f-- From nobody Sun Feb 11 13:50:29 2018 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 E21F9127775 for ; Sun, 11 Feb 2018 13:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 QR2ILX9uHJdE for ; Sun, 11 Feb 2018 13:50:25 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EEA512773A for ; Sun, 11 Feb 2018 13:50:25 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id B2B7440F72; Sun, 11 Feb 2018 22:50:23 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 9776B120059; Sun, 11 Feb 2018 22:50:23 +0100 (CET) Received: from lat6466.rd.francetelecom.fr (10.168.234.6) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sun, 11 Feb 2018 22:50:23 +0100 Message-ID: <4192_1518385823_5A80BA9F_4192_25_1_5A80BAA4.5060303@orange.com> Date: Sun, 11 Feb 2018 22:50:28 +0100 From: Reply-To: Alexandre Ferrieux Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Kazuho Oku CC: IETF QUIC WG Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) References: <5700_1518374159_5A808D0F_5700_161_1_5A808D14.30503@orange.com> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.234.6] 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, 11 Feb 2018 21:50:27 -0000 On 11/02/2018 22:32, Kazuho Oku wrote: > 2018-02-12 3:36 GMT+09:00: >> >> => Do "we", or do "we" not, want to disclose a signal that allows a >> midpoint observer to deduce: >> >> - both upstream and downstream half-RTTs (spin bit) >> - upstream losses (consensual sequence: square, Pi, fractal, >> whatever) >> >> Pros: manageability, troubleshooting >> Cons: some Murphy middlebox ossifying the Internet instead of dying in >> flames >> >> Once the answer is known and agreed upon, dedicated research on the best >> design for "measurement bits" will be timely. Not before. > > While I like the orderly approach that you propose, I might also argue > that "if" we want to disclose a signal to observers might depend on > "how" the signal looks like. > > And to me it seemed that, until now, we have shared a hidden premise > that the observation is a passive action. > > But as I stated in my I-D, it is possible to define the observation > scheme as a request-response protocol. Well, from doing network troubleshooting every day, I can tell you that passive analysis is enormously superior to active one: - you (midpoint) may be too far and too untrusted from the server to request any debug info from it (which is wht your protocol is about) - you may not know in advance which connection will display the problem of interest, and hence need to request debug for many of them - the problem may occur early in the connection's life, and the debug request may come too late - this simply doesn't scale up: you cannot do stats unless you request really too much debug info (and may be flagged by the server) - the potential for threats coming through the debug request channel is unknown. For this reason, please let us first see what is acceptable for a passive measurement signal (including the spin bit). _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. From nobody Sun Feb 11 13:51:11 2018 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 09DC912773A for ; Sun, 11 Feb 2018 13:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 UHrZfUoFLJXe for ; Sun, 11 Feb 2018 13:51:08 -0800 (PST) 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 2880E127698 for ; Sun, 11 Feb 2018 13:51:08 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id g14so9118745iob.9 for ; Sun, 11 Feb 2018 13:51:08 -0800 (PST) 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=lg+ayfsysKP/syoeZiRjFlMB35YjJ4JoW0FTaDuGfW8=; b=AN25AlUCjvwbICg5TazEgG//PRowbQNoleuCl2/cq7+7eIUH9An5R4XnJUzfbVTq9h 5uLfhSPPu8oePYoFbNvCzE3dDCm6hkAneHMVvY0BmWRWxZS8dllM3GnpCCikLksscak9 mFzHKcjw6hp5JV16Ka/AFbaMiBB8AEOB/s4XbFMfgKCAbf5pq1hhajmQqvrgNuiglcEU 6fuKjOEN4znaFfmsrfcrNHxDl1q+n7k8yjDDJ5rO+9Egl1JZT5L2ZvzOmnxsg5k0SPuP uYmCQblESYd+bc9lbdVk/ylc64nvvbWVgSlHPFyLj9oPykJMjbRYVZzJr/KVOCoMaF9v GWCQ== 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=lg+ayfsysKP/syoeZiRjFlMB35YjJ4JoW0FTaDuGfW8=; b=TtTQ9g2IKgNZsRS7HIbWrQsF7u/dtuuZcsZieDeGXBH4xlfzwTdpd9DMw7x/ZJNLRp 1awpwKCtt4C0g6NHnS1ZDcB84virQsdgyiL09+6uMfk6UipSHmFEDrEQnZ7JWRt1Gkm4 vGLYzNvXe+Xol1OrlHWqo/3iYjGvSkvwjqsvofVjBClSmteVx1666A+H+VMfZHmg9+50 PO3D/Z3S5mlq7PxNfnckNxAP5Iv+5cznZsUdSwvr74j5sfGT451dinxyf1GB1QpCUHuk frTjGwh12x4E5s9IggA74ZHOWrEFDzT9a6jupiJJ1rRWjN+NqKe4lJSp3voPrIqZavc/ qwtw== X-Gm-Message-State: APf1xPBzChhNzvNnzBLJbcOVQ4ox+O/mrH1MQEDvOnHYGz9y1OI2QDNa n2JgGixScxeHKzeaEc/ECEmrftsXiQy3dDdziys2jQ== X-Google-Smtp-Source: AH8x226aK32p3RuN+dj3rJYU3NJc8YNwYLNtGB5y4GYYS94hOLB4iRk7Y/JR7i1ZO6BGwsz9By51RaLRGipiq3EJRKk= X-Received: by 10.107.89.11 with SMTP id n11mr11006149iob.154.1518385867304; Sun, 11 Feb 2018 13:51:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Sun, 11 Feb 2018 13:50:46 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Sun, 11 Feb 2018 16:50:46 -0500 Message-ID: Subject: Re: The Recovery Period To: Martin Thomson Cc: Jana Iyengar , Patrick McManus , IETF QUIC WG Content-Type: multipart/alternative; boundary="f4f5e80671984188060564f6c26c" 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, 11 Feb 2018 21:51:10 -0000 --f4f5e80671984188060564f6c26c Content-Type: text/plain; charset="UTF-8" And I should add, that in one case, there was a bug in the pseudocode where it should have been <= and instead was <. On Sun, Feb 11, 2018 at 4:49 PM, Ian Swett wrote: > PR sent: https://github.com/quicwg/base-drafts/pull/1106 > > On Fri, Feb 9, 2018 at 5:20 PM, Martin Thomson > wrote: > >> Ian already did. I think that putting that in the draft would be a good >> idea. >> >> On Sat, Feb 10, 2018 at 9:03 AM, Jana Iyengar wrote: >> > Suggest text if you think it can be made better! >> > >> > On Fri, Feb 9, 2018 at 12:24 PM, Patrick McManus >> > wrote: >> >> >> >> you're right - its ok. I missed the "when a larger" part (reading it as >> >> "when it is recovered"). >> > >> > >> > > --f4f5e80671984188060564f6c26c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And I should add, that in one case, there was a bug in the= pseudocode where it should have been <=3D and instead was <.

On Sun, Feb 11, 201= 8 at 4:49 PM, Ian Swett <ianswett@google.com> wrote:

On= Fri, Feb 9, 2018 at 5:20 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
Ian already di= d.=C2=A0 I think that putting that in the draft would be a good idea.

On Sat, Feb 10, 2018 at 9:03 AM, Jana Iyengar <jri@google.com> wrote:
> Suggest text if you think it can be made better!
>
> On Fri, Feb 9, 2018 at 12:24 PM, Patrick McManus <pmcmanus@mozilla.com>
> wrote:
>>
>> you're right - its ok. I missed the "when a larger" = part (reading it as
>> "when it is recovered").
>
>


--f4f5e80671984188060564f6c26c-- From nobody Sun Feb 11 13:51:26 2018 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 01BB1127869 for ; Sun, 11 Feb 2018 13:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=nokia.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 Tg7F2VU16Q6t for ; Sun, 11 Feb 2018 13:51:19 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0106.outbound.protection.outlook.com [104.47.1.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E0E5127698 for ; Sun, 11 Feb 2018 13:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yzdYG0UW02/vSSJbhI5dO1JrdqyvgpyAb70csc6Ax8o=; b=Hk4B6OAE97uiCiskKOkiQFfc4iHfZfMUXve9nURUd63X3pw7qcBn9ix1PYuqgiv2wp6IYJZEDPYWlotDgervkYApmuxW1p9xPsSTtpEziJ9n77lD3MklhILt3oOefeFsLupedCky5skDtiey+0GPe6BNS9USEp/alkDcvt7DTW8= Received: from DB3PR07MB0747.eurprd07.prod.outlook.com (10.160.53.12) by DB3PR07MB140.eurprd07.prod.outlook.com (10.242.132.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.11; Sun, 11 Feb 2018 21:51:15 +0000 Received: from DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::bd52:353a:7565:b057]) by DB3PR07MB0747.eurprd07.prod.outlook.com ([fe80::bd52:353a:7565:b057%14]) with mapi id 15.20.0506.011; Sun, 11 Feb 2018 21:51:14 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge)" To: Kazuho Oku , IETF QUIC WG CC: "alexandre.ferrieux@orange.com" , "Fossati, Thomas (Nokia - GB/Cambridge)" Subject: Re: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) Thread-Topic: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) Thread-Index: AQHTo1iVdorx6PCU9U6EovJPVMM98KOfvi2A Date: Sun, 11 Feb 2018 21:51:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.9.0.180116 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [88.111.126.116] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB3PR07MB140; 7:No4eXRXb9YcpziG+0yyBqY6rJR7NU/qWZlIGwiw0cwJd0DoYuMFviscppFvSV2SSdaok3DKP6BIO59twmO1HNDmJioukRzUpJIxf6egPXxZ1CXaXjCwslVtTrth90GehT8GriclChicd14WC5ubtid36qIW+KkaizCQ2bz+xO0L1Qr/G11rMf2TBfx8KWX1yGymxoJbKFVyQhBkj4ckw6TOqzJaIt2bLFkxN4IeqljW32Ks2IrcXLsf4d+c5wvmb x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(366004)(346002)(39860400002)(39380400002)(396003)(376002)(189003)(199004)(76104003)(68736007)(2906002)(3280700002)(3660700001)(5660300001)(3846002)(6116002)(106356001)(6486002)(2900100001)(4326008)(81166006)(86362001)(76176011)(8676002)(83716003)(8936002)(81156014)(107886003)(305945005)(7736002)(66066001)(5250100002)(39060400002)(105586002)(82746002)(14454004)(966005)(2950100002)(6512007)(25786009)(33656002)(561944003)(102836004)(26005)(53936002)(186003)(6246003)(6306002)(6506007)(53546011)(6436002)(83506002)(316002)(54906003)(229853002)(58126008)(478600001)(99286004)(110136005)(97736004)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR07MB140; H:DB3PR07MB0747.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 270baad3-4d41-4807-733f-08d571999254 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DB3PR07MB140; x-ms-traffictypediagnostic: DB3PR07MB140: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(120809045254105)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(11241501184)(806099)(944501161)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(6072148)(201708071742011); SRVR:DB3PR07MB140; BCL:0; PCL:0; RULEID:; SRVR:DB3PR07MB140; x-forefront-prvs: 058043A388 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: v0nsnulFjpAwu055oBVstTteZUIkTaKvglK1buKuzBz699m9n9N55VmxtpUAe/ab0EnuB+b6ogCBQHfncZjHrxF+1DSEMY/GTL40bzybAbvLCExHgjxoHd26v/ezf3Fu spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1177CCB8EF8AB3408487E9B062D95A39@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 270baad3-4d41-4807-733f-08d571999254 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Feb 2018 21:51:14.0173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR07MB140 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, 11 Feb 2018 21:51:25 -0000 T24gMTEvMDIvMjAxOCwgMTY6NTEsICJRVUlDIG9uIGJlaGFsZiBvZiBLYXp1aG8gT2t1IiA8cXVp Yy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBrYXp1aG9va3VAZ21haWwuY29tPiB3cm90 ZToNCj4gVGhlcmVmb3JlLCBJIGhhdmUgd3JpdHRlbiBhIHByb3Bvc2FsIG9mIGEgdmVyeSBkaWZm ZXJlbnQgYXBwcm9hY2gsDQo+IHdoaWNoIGlzIHRoZSBmb2xsb3dpbmcgSS1ELg0KPiANCj4gwqDC oMKgIFBlcmZvcm1hbmNlIE1ldHJpY3MgU3VicHJvdG9jb2wgZm9yIFFVSUMNCj4gwqDCoMKgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWthenVoby1xdWljLXBlcmYtbWV0 cmljcy8NCj4gDQo+IFRoZSBJLUQgcHJvcG9zZXMgdG8gYWRkIGEgc3VicHJvdG9jb2wgdGhhdCBp cyB1c2VkIGJldHdlZW4gYW4gb24tcGF0aA0KPiBvYnNlcnZlciBhbmQgdGhlIFFVSUMgc2VydmVy IHRvIG9idGFpbiB0aGUgcGVyZm9ybWFuY2UgbWV0cmljcy4gQXQgdGhlDQo+IGxhdGVuY3kgb2Yg MSBSVFQsIHRoZSBzdWJwcm90b2NvbCBjYW4gb2JzZXJ2ZSBhY2N1cmF0ZSB1cHN0cmVhbQ0KPiBs b3NzL3Jlb3JkZXIgcmF0ZSwgYXMgd2VsbCBhcyBTUlRUIC8gUlRUVkFSLg0KPiANCj4gSSBiZWxp ZXZlIHRoYXQgaXQgaXMgbm90IGRpZmZpY3VsdCB0byBpbXBsZW1lbnQgb24gdGhlIHNlcnZlci1z aWRlDQo+IChwbGVhc2UgcmVmZXIgdG8gc2VjdGlvbiA0KS4gQ2xpZW50IG5lZWRzIG5vIGNoYW5n ZS4NCj4gDQo+IFsuLi5dDQo+DQo+IFBsZWFzZSBsZXQgbWUga25vdyB3aGF0IHlvdSB0aGluay4N Cg0KSGkgS2F6dWhvDQoNClRoYW5rcyB2ZXJ5IG11Y2ggZm9yIHRha2luZyB0aGUgdGltZSB0byBh cnRpY3VsYXRlIHlvdXIgcHJvcG9zYWwuDQoNCkEgZmV3IG5vdGVzOg0KDQotIEl0IGxvb2tzIGxp a2UgYSBxdWl0ZSBzaWduaWZpY2FudCBEb1Mgc3VyZmFjZSAoYm90aCBzZXJ2ZXIgYW5kDQogIGNs aWVudC1zaWRlKSBpcyBlbmFibGVkIGJ5IGFjY2VwdGluZyBSRVFVRVNUcyBmcm9tIGFueW9uZS4N Cg0KLSBDb3VsZG4ndCB3ZSBleHBvc2UgdGhlIHNhbWUgaW5mbyB2aWEgYW4gYWxyZWFkeSBleGlz dGluZyBpbnRlcmZhY2UsDQogIGUuZy4gSVBGSVggLyBTTk1QPw0KDQotIElmIHRoaXMgaXMgbm90 IGEgcmVxdWlyZW1lbnQgZm9yIFFVSUMgZW5kcG9pbnRzLCB3aGF0IGRvIHlvdSB0aGluaw0KICBp cyB0aGUgaW5jZW50aXZlIGZvciBzZXJ2ZXJzIHRvIGNvb3BlcmF0ZT8NCg0KQ2hlZXJzDQoNCg== From nobody Sun Feb 11 22:12:00 2018 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 15AC7126CBF for ; Sun, 11 Feb 2018 22:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.231 X-Spam-Level: X-Spam-Status: No, score=-4.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Q7UarTO-Hwet for ; Sun, 11 Feb 2018 22:11:57 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 7C249124BE8 for ; Sun, 11 Feb 2018 22:11:57 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9285696A12E69 for ; Mon, 12 Feb 2018 06:11:53 +0000 (GMT) Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 12 Feb 2018 06:11:54 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.214]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0361.001; Mon, 12 Feb 2018 14:11:48 +0800 From: "Roni Even (A)" To: Alexandre Ferrieux , Kazuho Oku CC: IETF QUIC WG Subject: RE: Fwd: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) Thread-Topic: Fwd: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) Thread-Index: AQHTo1ifDKJ67wLPOUupXknaGG3UlaOfAYoAgAAxRACAAAUNAIABETaQ Date: Mon, 12 Feb 2018 06:11:47 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8639EA@DGGEMM506-MBX.china.huawei.com> References: <5700_1518374159_5A808D0F_5700_161_1_5A808D14.30503@orange.com> <4192_1518385823_5A80BA9F_4192_25_1_5A80BAA4.5060303@orange.com> In-Reply-To: <4192_1518385823_5A80BA9F_4192_25_1_5A80BAA4.5060303@orange.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.244] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected 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, 12 Feb 2018 06:11:59 -0000 +1 This is not monitoring it can serve to get the statistics of a call/sessio= n and this total session information is better served using for example SNM= P or similar management protocol and not QUIC Roni -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of alexandre.ferrieux@o= range.com Sent: Sunday, February 11, 2018 11:50 PM To: Kazuho Oku Cc: IETF QUIC WG Subject: Re: Fwd: New Version Notification for draft-kazuho-quic-perf-metri= cs-00.txt (Re: Measurement bit(s) or not) On 11/02/2018 22:32, Kazuho Oku wrote: > 2018-02-12 3:36 GMT+09:00: >> >> =3D> Do "we", or do "we" not, want to disclose a signal that allows=20 >> a midpoint observer to deduce: >> >> - both upstream and downstream half-RTTs (spin bit) >> - upstream losses (consensual sequence: square, Pi, fractal, >> whatever) >> >> Pros: manageability, troubleshooting >> Cons: some Murphy middlebox ossifying the Internet instead of dying=20 >> in flames >> >> Once the answer is known and agreed upon, dedicated research on the=20 >> best design for "measurement bits" will be timely. Not before. > > While I like the orderly approach that you propose, I might also argue=20 > that "if" we want to disclose a signal to observers might depend on=20 > "how" the signal looks like. > > And to me it seemed that, until now, we have shared a hidden premise=20 > that the observation is a passive action. > > But as I stated in my I-D, it is possible to define the observation=20 > scheme as a request-response protocol. Well, from doing network troubleshooting every day, I can tell you that pas= sive analysis is enormously superior to active one: - you (midpoint) may be too far and too untrusted from the server to requ= est any debug info from it (which is wht your protocol is about) - you may not know in advance which connection will display the problem o= f interest, and hence need to request debug for many of them - the problem may occur early in the connection's life, and the debug req= uest may come too late - this simply doesn't scale up: you cannot do stats unless you request re= ally too much debug info (and may be flagged by the server) - the potential for threats coming through the debug request channel is u= nknown. For this reason, please let us first see what is acceptable for a passive m= easurement signal (including the spin bit). ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Sun Feb 11 22:59:06 2018 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 C7F90124BE8 for ; Sun, 11 Feb 2018 22:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 khiSrQbHs-8C for ; Sun, 11 Feb 2018 22:59:04 -0800 (PST) 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 D88D4126E64 for ; Sun, 11 Feb 2018 22:59:03 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id l11so6064675ywh.2 for ; Sun, 11 Feb 2018 22:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=eOO+bnMh+KhK8/iIoXuNylgWZVT2X+OgYGHbG0Dex38=; b=kBx1sLawGS17UfHnl6jU3zqJJbYyndQDjvd89CVZFH3k/kA+7U+2AEk7ncto4XaN0h HcQ+BRJNhOtmr9GZOqqi/thK+yIx9SYumkG8Mw4n1mMDMTMwLTUZYO0qfYtNVywoN64n lZ+7lQWl9qYbrF0qwfc1/F6fO1sUfT0ZiX2VmGheGjUZFetuCbJFF7nthrEmVihtC2yu f0gpe0BaDVIb0U0bK3wg5gkVV47Pku8RmHse8eNOwGn1HXHpE/o+MeWXeokR4zI/t/D3 MN0hleUlFJdpgQNpvVMqV8f6H3sicPMRHWiUUv4PBNPRzx/YDgHY9N7JMrt2hZKDjB/a r9/g== 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=eOO+bnMh+KhK8/iIoXuNylgWZVT2X+OgYGHbG0Dex38=; b=CPLdbvqoYLn7t4vPfYaNnRiI4DLwFRS1ljQ3f4CsZNX5E7G7yEr6j1BGmkN7rjVHG6 LNyhHfxnmSQqS/VeXuKmFTwoZpT4JQwvLwlAiaIC2xisDAD8P1FNXdKlOK6u62xjqbm3 rSsL+G1DQ2c438LPHXidevY7UqGFKwCfrKEU62jinMXi3l/KIw2JFz9FlgN8uhXzCH5z mBJlmUMSqFzvuCzivu301GWeD5AWtnbl3YhU2YCIL2vhKF301PjAglLCTvK/qvelMtYP XHM3Ed3aBKK8vil0G6Ylxq7WJPUimooM9uJDqx8ZAc3UWBz5Tt22x7JuQgOEaw3eG4w6 Xh2A== X-Gm-Message-State: APf1xPBjLN9vdQPvj3NE2972AKLpAUI5sK2ZJn3oRkRkoHmHvbVTKZvK mrPkSF9iDGNygVBy8w5++2nKaY4S+GT3O078LNLR4ONdJuI= X-Google-Smtp-Source: AH8x224wnGggj93IU6FSiYUb6j/9MbaKrzHq+2ZzlTMMth24MWfTJ0a2eNE9LiuMnMnLVqanebS3egMRTDPCYCnHBtc= X-Received: by 10.37.104.13 with SMTP id d13mr6689321ybc.290.1518418742540; Sun, 11 Feb 2018 22:59:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.77 with HTTP; Sun, 11 Feb 2018 22:59:01 -0800 (PST) From: Jana Iyengar Date: Sun, 11 Feb 2018 22:59:01 -0800 Message-ID: Subject: Connection migration PR To: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403045c0020c583f00564fe6906" 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, 12 Feb 2018 06:59:06 -0000 --f403045c0020c583f00564fe6906 Content-Type: text/plain; charset="UTF-8" FYI: PR #1012 about connection migration. This PR replaces the existing connection migration mechanism in the draft with one that allows a client to probe from an alternate address before actually migrating to it. It also fixes a few holes in the current mechanism. I've done a rewrite based on the comments on the previous version and from the interim. The packet number skip behavior remains unchanged, but that's going to have to come out of the ongoing packet number encryption conversation. For the time being, I would like to leave that aspect untouched in this PR. FWIW, encrypting packet numbers makes it trivial to not track state across multiple connection IDs in series. It needs careful thought otherwise. I am also limiting the migration protocol to client migration since making the description symmetric adds sharp edges that need to be more carefully dealt with. I'm restricting the scope of this PR to the client/server use case that's most relevant for v1. --f403045c0020c583f00564fe6906 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI:=C2=A0PR #1012=C2=A0about connection migrat= ion.

This PR replaces the existing connection migr= ation mechanism in the draft with one that allows a client to probe from an= alternate address before actually migrating to it. It also fixes a few hol= es in the current mechanism.

I've done a rewrite based on the comments on the pre= vious version and from the interim. The packet number skip behavior remains= unchanged, but that's going to have to come out of the ongoing packet = number encryption conversation. For the time being, I would like to leave t= hat aspect untouched in this PR.

FWIW, encrypting packe= t numbers makes it trivial to not track state across multiple connection ID= s in series. It needs careful thought otherwise.

I am a= lso limiting the migration protocol to client migration since making the de= scription symmetric adds sharp edges that need to be more carefully dealt w= ith. I'm restricting the scope of this PR to the client/server use case= that's most relevant for v1.
--f403045c0020c583f00564fe6906-- From nobody Sun Feb 11 23:19:11 2018 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 87F2A124BE8 for ; Sun, 11 Feb 2018 23:19:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 5B8_iKkvwmvl for ; Sun, 11 Feb 2018 23:19:08 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::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 3FD311201F8 for ; Sun, 11 Feb 2018 23:19:08 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id d26so7416810qtk.10 for ; Sun, 11 Feb 2018 23:19:08 -0800 (PST) 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=uybSDUYcrd/7hQPq5DUdD9hTtEn29S20a50vk0AHiuk=; b=Yixayypg6TRhKvAtEnk/KqmOmfbofvBZu90xi2S2pf6H/l3SBa3D3lPzKkLuQJ8Zcl m2iE1IXGVmxUUV4JTssAdu7YC/0b54v3yBAUqqB8vAURMCEvSths+KmdjARcFGQUlHH4 sEIefih5xP60EsqsJpu7t61KoD20OQmLqqKwpFCqfwA5aiXvIfA5vhV5X2M4tWgv2xRM 7WrjOgqKF35P1kFfvsw9uQu95eImKcHd+V/fRYf8PFm8LKjUt2xHln3AbPNvEwvefyrp PTxBHw97C2108VrmOrXlk0xLPDK6m9UeCR14xihjVfRFV1erVUVsvXUgXOG7Gt0prp55 WX+g== 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=uybSDUYcrd/7hQPq5DUdD9hTtEn29S20a50vk0AHiuk=; b=AB7aQmxabfHQiRiHxjk0x7Xhta4Pu1pz7fBzHTXoXkxFvsNY/N4vfVjZ5I65z4Usfv 9kty0AaFxpGeq/+olfkdUyRcVi6DhXs1ZMeWqxFFzF81ZaXwjXIsxdDBBv6sJofzTNYk 7HZMN7Ec9f3v2xVZfTtvfXKN1++rMqD/8E7fsTP6C0d0PV6gH7biiKKmuUhzScDe5EuY clNo0UrD4p7048k3XUWa1LKEzW8F3wWMhOfTBp9mjpXHBqpCWMYhB/0gTE6MiEXw/O7S 0AHzcmiWIPTPfz+VzZfFkXAlygLKfpSF8XshiwcMdWSGUC+KjL2GIiPAmlJpMTQ8Mir2 pSDg== X-Gm-Message-State: APf1xPCGaFOL/Jc3FOlrEtRbkf0wcqbBIVYmSYCzNITgsygI3gil6NTx ENBdkvkIdMG5E+5nrkRLblAffj5qJUMJKciRUaPavQ== X-Google-Smtp-Source: AH8x2245gqdq+pErBHA0R1PHCojv1aTEJaRcBhkEW300SMWkAxWchHZ+HPol8BrWU20tWJaz+s4mzc062EztiiUJAak= X-Received: by 10.237.57.197 with SMTP id m63mr17217495qte.175.1518419947089; Sun, 11 Feb 2018 23:19:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.34.132 with HTTP; Sun, 11 Feb 2018 23:19:06 -0800 (PST) In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> From: Victor Vasiliev Date: Mon, 12 Feb 2018 02:19:06 -0500 Message-ID: Subject: Re: Packet number encryption To: Praveen Balasubramanian Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Marten Seemann , huitema Content-Type: multipart/alternative; boundary="001a113f4b1c91a6f80564feb10a" 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, 12 Feb 2018 07:19:10 -0000 --001a113f4b1c91a6f80564feb10a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have no idea how you get that number (by which I mean, I have a lot of guesses, but none of which are solid or useful here). I looked at the profiles of various workloads we're running in production, and I estimate that none of them would be impacted by PN encryption by worse than 0.1%. On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian < pravb@microsoft.com> wrote: > Makes sense. The 1%+ overhead I had quoted was in comparison to *full > protocol processing all the way from app to NIC*. This is with an > unoptimized early QUIC implementation and not fully optimized UDP/IP stac= k > (we have focused much much more on optimizing TCP in the past). After > software stack optimizations, the crypto share of the cost will only keep > going up for which we have no technique other than to offload when such > support is available in hardware and offload is way more challenging when > workload is hosted in VMs and containers. > > > > *From:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] > *Sent:* Saturday, February 10, 2018 3:36 AM > *To:* Victor Vasiliev > *Cc:* Praveen Balasubramanian ; quic@ietf.org; > Marten Seemann ; huitema > *Subject:* Re: Packet number encryption > > > > To put numbers into perspective using Intel 2015 data > > > > https://software.intel.com/en-us/articles/improving-openssl- > performance#_Toc416943490 > > > > > A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte or > 66 cycles total, or 22ns on a 3GHz core. > > > > For packet numbers we use the CBC encrypt numbers because here AES cannot > exploit block parallelism. > > Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz > setup that would amount to about 24ns overhead for packet encryption. > > > > Clearly it makes no sense that AES-GCM is faster than a single AES block > encryption, but these are only approximate numbers and CBC mode might hav= e > a little overhead, so we clamp packet numbers to 22ns. > > > > Taking the 98ns overhead by the Solarflare report we get a total > (simplified) processing time is 98ns non-crypto, 22ns for packet number, > and 22ns for AEAD totalling 142ns. So the packet number encryption overhe= ad > would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeepi= ng, > but that can be done in other cores or outside the latency critical windo= w. > > > > This does not take into account that AEAD operation may operate less than > optimal because the packet number must be extracted first. On the other > hand, it is also not a disastrous overhead if no good alternative can be > found. > > > > Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycles= in HW > for a single AES-128 block which would be 33ns per packet number in the > above example. > > > > On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen ( > mikkelfj@gmail.com) wrote: > > 98ns for 68 byte messages > > --001a113f4b1c91a6f80564feb10a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have no idea how you get that number (by which I mean, I= have a lot of guesses, but none of which are solid or useful here).=C2=A0 = I looked at the profiles of various workloads we're running in producti= on, and I estimate that none of them would be impacted by PN encryption by = worse than 0.1%.

On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian <pravb@mi= crosoft.com> wrote:

Makes sense. The 1%+ overhead I had quoted was in co= mparison to full protocol processing all the way from app to NIC. This is with a= n unoptimized early QUIC implementation and not fully optimized UDP/IP stac= k (we have focused much much more on optimizing TCP in the past). After sof= tware stack optimizations, the crypto share of the cost will only keep going up for which we have no technique o= ther than to offload when such support is available in hardware and offload= is way more challenging when workload is hosted in VMs and containers.<= /u>

=C2=A0

From: Mikkel Fahn=C3=B8e J= =C3=B8rgensen [mailto:mikkelfj@gmail.com]
Sent: Saturday, February 10, 2018 3:36 AM
To: Victor Vasiliev <vasilvv@google.com>
Cc: Praveen Balasubramanian <pravb@microsoft.com>; quic@ietf.org; Marten Seemann <martenseemann@gmail.com>; huitema <huitema@huitema.net>
Subject: Re: Packet number encryption

=C2=A0

To put numbers into perspective using Intel 2015 = data

=C2=A0

=C2=A0

A 64 byte message in AES-GCM AEAD in HW would use= 1.03 cycles per byte or 66 cycles total, or 22ns on a 3GHz core.=

=C2=A0

For packet numbers we use the CBC encrypt numbers= because here AES cannot exploit block parallelism.

Here we see 4.44 cycles/byte in HW or 71 cycles p= er block. With a 3GHz setup that would amount to about 24ns overhead for pa= cket encryption.

=C2=A0

Clearly it makes no sense that AES-GCM is faster = than a single AES block encryption, but these are only approximate numbers = and CBC mode might have a little overhead, so we clamp packet numbers to 22ns.

=C2=A0

Taking the 98ns overhead by the Solarflare report= we get a total (simplified) processing time is 98ns non-crypto, 22ns for p= acket number, and 22ns for AEAD totalling 142ns. So the packet number encryption overhead would be 22/(98+22)*100% =3D 18%.= The numbers ignore other QUIC bookkeeping, but that can be done in other c= ores or outside the latency critical window.

=C2=A0

This does not take into account that AEAD operati= on may operate less than optimal because the packet number must be extracte= d first. On the other hand, it is also not a disastrous overhead if no good alternative can be found.=C2=A0

=C2=A0

Earlier AES-NI I=E2=80=99ve seen from Intel doc s= uggests around 100cycles in HW for a single AES-128 block which would be 33= ns per packet number in the above example.

=C2=A0

On 10 February 2018 at 06.18= .25, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@gmail.com) wrote:

98ns for 68 byte messages<= /span>


--001a113f4b1c91a6f80564feb10a-- From nobody Mon Feb 12 00:13:41 2018 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 E91D5126CF6 for ; Mon, 12 Feb 2018 00:13:39 -0800 (PST) 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 dKPGVKXnP2xM for ; Mon, 12 Feb 2018 00:13:37 -0800 (PST) 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 915BE1201F8 for ; Mon, 12 Feb 2018 00:13:37 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id u1so7052922pgr.0 for ; Mon, 12 Feb 2018 00:13:37 -0800 (PST) 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=Af+YpMubetaRJunJdpWqZiRNEN+QsJ2VJkCrwWg43eA=; b=VAEGisFNilu2ePqOTehoaJFJ0nSLsBHRw7VFtRB9XX+0SzSJOu9T+0vPYFBkKz+koN +MgXIZW7T3aHIa9Gr5MCEqdQt1EiHp+1cJPCnVs8f/CHK6Zp/5ghH+ipHkpYBEqUmfqD BI+MB5/4FlcSgx9Loqt03f55PoiLhiqr31CggGWJuY/jVahTFIb7oHvQy7jAxecNPdZz pRcyQNuyoHxQ/kUxRmeuiaaUVHGsYOMYtzzu6y38fdPk88M0Z7NQp12by7yAkfLCIdqd ObkAWXDmAo9RPwl2UPFnNekRpqN8Nl6fiVomWi1C2iqDAXoMCcYm3sICrVPewpApfY+E Q2Qg== 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=Af+YpMubetaRJunJdpWqZiRNEN+QsJ2VJkCrwWg43eA=; b=li9l7W5/eTSoNOyO5M+lktLcR0wuTwUKCG4uAeC6b2QD4n54o6VPFI4Fhm18l0e3d6 coKD3ABBQiXQe8bNCoGJdYj9iyM6THSHDf1pDNn9hMRC5uu9+lQWXy7wfN83yQPgic2x mhPp5GJQk4mzTy6Jm9O0Q5aOcJRPpJzMhMssETtzE/Lx08ZI2RnBUjONPnFB/R000KhK eJ2zofxWDNCeHNlDZ2r9rRX0L3FYbufndqIkmVpvrb3tEK1pGfwdekUiKyhAZhynr2sQ yhqN1mVlZYUhuBh4il4zF+dmpK86iPFEsHsnnrSXRotLMowW68dNR4ncpc4frzJZqRhX Y3jA== X-Gm-Message-State: APf1xPAGtCCT2g22EngpxhCpnC3tYPpmxVF5DP1G4cDnxCxDGijz9Qpc FdJiiO3NPgnCc39JqePtangYTSxRVYhEIX/KEck= X-Google-Smtp-Source: AH8x225DXnZycKit5EDkIw8w7I36OCDW7Rak9dbLgPz5mn64vRVjZHZqsCAVZrTQf72VB2hxPTJXy7u9VJfGCguElTI= X-Received: by 10.101.97.209 with SMTP id j17mr8623159pgv.266.1518423217009; Mon, 12 Feb 2018 00:13:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.191.134 with HTTP; Mon, 12 Feb 2018 00:13:36 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Mon, 12 Feb 2018 17:13:36 +0900 Message-ID: Subject: Re: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) To: "Fossati, Thomas (Nokia - GB/Cambridge)" Cc: IETF QUIC WG , "alexandre.ferrieux@orange.com" 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: Mon, 12 Feb 2018 08:13:40 -0000 Hi Thomas, Thank you for your response. Please see my comments below. 2018-02-12 6:51 GMT+09:00 Fossati, Thomas (Nokia - GB/Cambridge) : > On 11/02/2018, 16:51, "QUIC on behalf of Kazuho Oku" wrote: >> Therefore, I have written a proposal of a very different approach, >> which is the following I-D. >> >> Performance Metrics Subprotocol for QUIC >> https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/ >> >> The I-D proposes to add a subprotocol that is used between an on-path >> observer and the QUIC server to obtain the performance metrics. At the >> latency of 1 RTT, the subprotocol can observe accurate upstream >> loss/reorder rate, as well as SRTT / RTTVAR. >> >> I believe that it is not difficult to implement on the server-side >> (please refer to section 4). Client needs no change. >> >> [...] >> >> Please let me know what you think. > > Hi Kazuho > > Thanks very much for taking the time to articulate your proposal. > > A few notes: > > - It looks like a quite significant DoS surface (both server and > client-side) is enabled by accepting REQUESTs from anyone. First, let me assert that only on-path devices that observe a QUIC packet used for that path can build a legitimate REQUEST. Regarding DoS surface, a server typically accepts packet from any address, so it is not an issue for the server in terms of bandwidth. Regarding computational cost, it would be much cheaper to process the REQUEST packet and send the response than to handle a handshake packet (which involves a public-key crypto). Therefore, I do not think that it would be an attractive attack surface in terms of computational cost. So the only aspect of this potentially being a DoS vector is the possibility of it being used to saturate the bandwidth from the server to the client. I agree that it is a concern and that the server should rate-limit how often it sends the RESPONSE packets. > - Couldn't we expose the same info via an already existing interface, > e.g. IPFIX / SNMP? We can expect higher chance of the feature being deployed, if it can be implemented solely by the QUIC server, and if it can be deployed without any additional hassles. Since the server with the knowledge of the packet number encryption key (which is required to calculate distances) is often located behind a load balancer, it makes sense to send the REQUEST packet with its destination address and Connection ID set to the values that would be found in a QUIC packet sent by a client. We can expect that a QUIC server is always capable to send a packet to the client. Therefore, it makes sense for a server to respond in the form of a QUIC packet sent to the client. > - If this is not a requirement for QUIC endpoints, what do you think > is the incentive for servers to cooperate? Let my first point out that any feature that is specific to observation becomes an optional feature, because endpoints do not need to implement them to be able to communicate. At the same time, I think that designing observation as something that can be implemented solely as part of the QUIC server and deployable without any other restriction gives us a higher chance of being it deployed, as I explained above. > > Cheers > -- Kazuho Oku From nobody Mon Feb 12 00:15:36 2018 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 9E6FE127011 for ; Mon, 12 Feb 2018 00:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 mztevBsg3wBA for ; Mon, 12 Feb 2018 00:15:30 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 0EB501201F8 for ; Mon, 12 Feb 2018 00:15:30 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id b66so5695793itd.5 for ; Mon, 12 Feb 2018 00:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=+cfT9MELYg8r/6T7YFNdQ/8RSCKk4yo3Op0AHh8Bc4I=; b=dpcO0WyxmBLyOzyvqKzWMnP1AbPFgEh2r99zYmVDplCvK4Bm2fJVBowtCxrwzr6g0r jitlBF01dBsgbM0Q+sb373E3XgBCKlLWm0leV95y4eRVP1PuEzzQHs7k8RVtiKri6ra+ frMwFuDEyJvvyp2MOdm8w2y4Tzf5r6obXCgxjsV8KCoDqbtL1EVF/vS9mdIH83Q3E1Wo N/nMLfv+j0p0REBZauOFAvKYkBEcyyMI39qETYwhNU4ovHjauvorL+d9sa+fk53F57qH h7aiS8h1xJJi14hUn/5H+GQBFK8OttI8PNAdMqOreqYZDb5WbH36eFCi784b4AJit/Ez X9Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=+cfT9MELYg8r/6T7YFNdQ/8RSCKk4yo3Op0AHh8Bc4I=; b=jPc7dyFBX9VT9qUU+pLP8hFMvPGYbUAHPWW1hfx0Hbafpr0bvbpORdCHupdK1/IvzM d2+fOUTWk96Tn3120zYY6lTo9ZLLk3eoGmmRuqhS82ERRGx/UyidFm0rEgq599lczAsE nBRKHM5mXX7qtDEo7FCo43l6dNDIE2gccm8x6eADReO0fJ7MIbF0ewZPY2+P5tamp4Xk FQ7KeXYCQ5057twcYtA/UlfKMly3ieMtj838lYzYtI5zxGDtaYji0jxQyNTYpIhuoTQ6 r13XF5YQZGMR+1WqCz9gXuy1+jdHABQOwSKd9mLKx4ZuTGgUUF8dKyESx7GQsELKO92O eKfg== X-Gm-Message-State: APf1xPAKVdtB4lJ1X+O5v3khoKymuhWABjx0O6KlVp0LLZ4aMTPyscmP 9jDWx9VKXZY5mAuAQaXAdhmG2RMMrbl7fJ/IRnI= X-Google-Smtp-Source: AH8x225ZCmTyDPq9mCUOf8lyQk3IzWn2UumGROts4vvq8CrOgEN5hI6x0yuwy57FxB8IQ+jwz+019xqQTBA0Ud4bx7s= X-Received: by 10.36.46.23 with SMTP id i23mr4504227ita.55.1518423329440; Mon, 12 Feb 2018 00:15:29 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Feb 2018 00:15:28 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 12 Feb 2018 00:15:28 -0800 Message-ID: Subject: Re: Packet number encryption To: Victor Vasiliev , Praveen Balasubramanian Cc: Marten Seemann , huitema , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a114a9d822b87020564ff7b8c" 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, 12 Feb 2018 08:15:33 -0000 --001a114a9d822b87020564ff7b8c Content-Type: text/plain; charset="UTF-8" Running the math with 0.1% PN encrypt overhead and an assumed 1200 byte packet size We get 66 cycles for PN encrypt (lower bound) and 66000 cycles for total processing. AEAD is 1200 * 1,03 = 1236 cycles. This means non-crypto processing is 66000 - 66 - 1236 = 64698 cycles. 1200/ On a 3GHz core this is 21566ns. The Solarflare 98 ns/68 bytes result scaled to 1200 bytes is 1729 ns, which suggests there is a theoretical 10x optimisation potential (which of course is not realistic in a large scale production environment). In packets per second this is 1e9/21566 packets/s = 46369pps With 1200 bytes / packet this is 55,64 MiB/s. This is roughly 1/2 Gbps which could be related to the network throughput including loss and retransmission, context switches, and cache effects. To compare with raw processing time, 55MiB/s is more than 10x slower than a JSON parser that I have. On 12 February 2018 at 08.19.07, Victor Vasiliev (vasilvv@google.com) wrote: I looked at the profiles of various workloads we're running in production, and I estimate that none of them would be impacted by PN encryption by worse than 0.1%. --001a114a9d822b87020564ff7b8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Running the math wit= h 0.1% PN encrypt overhead and an assumed 1200 byte packet size

We get 66 cycles for PN encrypt = (lower bound) and 66000 cycles for total processing. AEAD is 1200 * 1,03 = =3D 1236 cycles.
This means non-crypto processing is 66000 - 66 - 1236 =3D 64698 cycles.=
1200/
<= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:= 13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
On a 3GHz core this is 21= 566ns.
The So= larflare 98 ns/68 bytes result scaled to 1200 bytes is 1729 ns, which sugge= sts there is a theoretical 10x optimisation potential (which of course is n= ot realistic in a large scale production environment).

In packets per second this is 1e9/21566 p= ackets/s =3D 46369pps
With 1200 bytes / packet this is 55,64 MiB/s.

This is roughly 1/2 Gbps which could be r= elated to the network throughput including loss and retransmission, context= switches, and cache effects.

To compare with = raw processing time, 55MiB/s is more than 10x slower than a JSON parser tha= t I have.

=

On 12 February 2018 at 08.19.07, Victor Vasiliev (vasilvv@google.com) wrote:

=C2=A0I looked= at the profiles of various workloads we're running in production, and = I estimate that none of them would be impacted by PN encryption by worse th= an 0.1%.
 --001a114a9d822b87020564ff7b8c-- From nobody Mon Feb 12 00:23:56 2018 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 244B9126CF6 for ; Mon, 12 Feb 2018 00:23:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 wbnVcttd9ilL for ; Mon, 12 Feb 2018 00:23:54 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 DE3E71201F8 for ; Mon, 12 Feb 2018 00:23:53 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id f89so16403599ioj.4 for ; Mon, 12 Feb 2018 00:23:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=5MZ6kcDSKGM3NMIHJKx4e1+miDbsH7E6yRHgb0k0Nmg=; b=HyLQYq1a+39A3/nHD/Q6imSOsLe4AwgjmbBCT8Z47EMbvZ8FIFziPp8RLC+JvUFagX tb9i6YFy9QIWMVlQCjPE5aD9/l4nG8tmupjXS8iYy+7WZHtolox8Xz9+YaOhUNX/UNMF QyZ4TFibxHkuztDbSdN3PeWQzhfKQzyO7HEC1Z9gJCB73TXKzBug3GlWvIifvpYzIyaA KPpR8MZhJcHCguR+RzudlqTbJOtrnXCEOH9RqWMhY1hf5oElz8cS4auj4BsQ1CJ4qOZX Rg9inQKDOVwcWO4jasW7JLKmvcKR5cinkkyGO5msHOXu1Ppoqpra1nzJA8caMFFAOZbF rk2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=5MZ6kcDSKGM3NMIHJKx4e1+miDbsH7E6yRHgb0k0Nmg=; b=KL93/DZNjwJocliyQ2RLUPT05CprgwTnXLATNX/Kz4IKr4PqrpBt3wnxV4jHE8V/Oy fQiPq87zEsb2b6NA8ArLGuzLPkMwzrABHVpzVTcNUuWcrp7LXqlz6h/XJgZyLdw738NA DwF9wF8G6k9srWfHQbr/0er2QCchxO7h9QL27mUT6O6wjP7s3eaMX/PSWf6CsNcakGje J1fP+uGcAk/GK8B2Si2Sz3FXaoAaOzG0DPm50F+qslJoyUOfrAmnTKU9V/vG42MBGG5w iewwJii7ifjQDgZmNEtgLXTmZ0T8Nc/nJAUBVHP0sxndnPhQL04gdi6B4e8W+eq6LpzQ r4Jg== X-Gm-Message-State: APf1xPCZ/9rn10CDHL4GVZQ4FajACROsExSRcSKd5/nDhHGTrl5yC+Cu FzddJc7jpRW3EmVxxkz55NjKHzJgE7sxwhSVPhw= X-Google-Smtp-Source: AH8x224vbfaXWa9vtU2sU5+xUNk49TiEmBFyR0VGNCi2xJjEKld1jgsYjxcS/tODOUeKJ4y3im5nfbj+vihmrkM4TIk= X-Received: by 10.107.148.139 with SMTP id w133mr10998237iod.175.1518423833342; Mon, 12 Feb 2018 00:23:53 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Feb 2018 00:23:52 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 12 Feb 2018 00:23:52 -0800 Message-ID: Subject: Re: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) To: "Fossati, Thomas (Nokia - GB/Cambridge)" , Kazuho Oku Cc: "alexandre.ferrieux@orange.com" , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113fa9263477410564ff99cb" 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, 12 Feb 2018 08:23:55 -0000 --001a113fa9263477410564ff99cb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 12 February 2018 at 09.13.44, Kazuho Oku (kazuhooku@gmail.com) wrote: > - Couldn't we expose the same info via an already existing interface, > e.g. IPFIX / SNMP? We can expect higher chance of the feature being deployed, if it can be implemented solely by the QUIC server, and if it can be deployed without any additional hassles. The proposal could also be implemented as an application protocol on top of QUIC so network monitoring software could connect, authenticate and subscribe to data. This would with the security of QUIC instead of against it, and it could break some ground compared to ageing monitoring protocols that might have their own security issues. I=E2=80=99d be much more in favo= ur of such a solution. I don=E2=80=99t 2018 is the year to put more clear text on the wire, especi= ally not when to goal is to remove something as mundane as a sequential counter from clear text. In either case I would assume that it would not be an acceptable replacement for passive monitoring. --001a113fa9263477410564ff99cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 12 February 2018 = at 09.13.44, Kazuho Oku (kazuhooku@g= mail.com) wrote:
> - Couldn't w= e expose the same info via an already existing interface,=C2=A0
> e.g. IPFIX / SNMP?=C2=A0

We can expect higher chance of the feature be= ing deployed, if it can=C2=A0<= /span>
be implemented solely by the QUIC server, and if it can be de= ployed=C2=A0
w= ithout any additional hassles.=C2=A0<= /span>


The proposal cou= ld also be implemented as an application protocol on top of QUIC so network= monitoring software could connect, authenticate and subscribe to data. Thi= s would with the security of QUIC instead of against it, and it could break= some ground compared to ageing monitoring protocols that might have their = own security issues. I=E2=80=99d be much more in favour of such a solution.=

I don=E2=80=99t 2018 is the year to put more clear text on the wire,= especially not when to goal is to remove something as mundane as a sequent= ial counter from clear text.

In either case I would assume that it wo= uld not be an acceptable replacement for passive monitoring.

= --001a113fa9263477410564ff99cb-- From nobody Mon Feb 12 00:29:47 2018 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 D2A5F1241F8 for ; Mon, 12 Feb 2018 00:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 2G2GTshOtCTr for ; Mon, 12 Feb 2018 00:29:44 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 3B3C91201F8 for ; Mon, 12 Feb 2018 00:29:44 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id b66so5731705itd.5 for ; Mon, 12 Feb 2018 00:29:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=A4vwSSZf0ufUJJwKed/zz4ehjMaLNVo2E/hYihzQNZg=; b=pTR4e1RBUKqV+7QoF0xM6zwjer+jsSZx7jt0CaDltgsVMFljh/Rwj9H1K4XvsOiCfz QYqZFp9bIDvTuR7kCE8EyXVnAh5jrEJMNteG0K+djA2Jn7crd5pHvcFEUwy0XtlLiYCa N5zYfLFHa1ShrKNH6BRsFGwWQyuPGmAzcqHAn1Yte21o9pdU3O9gjC2DIfNYG6VYnSs2 g6WGgnvo9kDRof12yI1ov0ytnQs45AG8XChsAcKT4AcCga+1GTQbuUrzVIORQ0JBRmYL qFfQ7Cla+uquTsnAqJkYRjipYzcO2p3/5yED0OcYu8kZFmFb+ZZ5YKEtILorA5iK9BV/ tjbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=A4vwSSZf0ufUJJwKed/zz4ehjMaLNVo2E/hYihzQNZg=; b=lHHXcsEGD2q/DYpKb4Fnybf+DrWt6bb/CEUpVuiXdXa4aNAW4hxShirypFVKcRf/1m wRtTsKMvdRffcTd9QZXs4ncLBJukBLcYiE9MRmH+LnIi79l1o3QlsdmlsuX5E4jfsdYb 4zZCkg1Zr1JtsyMVO50PBVxWOcGck6QKTXeO0dBbg3oPIemFjI0JCO1016nXbBfTngwW 7PWYsADdpARY0XRTY3LRJOcFzQS1fzQLv1Ag/d6Ff9e9WQrYV/lkrCdsl4xv+SvjELTE OnGm2dP4WNWK1e89fCF+JfwmTN172zQ1kzPStEH0n/0EKAY8JBbiVmowvqke9IU2S+9S Fvbw== X-Gm-Message-State: APf1xPDDrbAvtmGlYP6SylBzwNHUs5/jQbsTBDNy79p6lgDvA/EIdTUt Us/T2msuoSrAEmM1bX5BlYKdFyI2m/Rvnv6JBbfs/d+N X-Google-Smtp-Source: AH8x224oS/K1egpZwXihs6GftvNcLlL/GwpWxOtoST8qa6o5QOKrmbnxvERnCs+OuHhwFKAm0QbihzutGigq6coNbU8= X-Received: by 10.36.73.24 with SMTP id z24mr4413324ita.91.1518424183704; Mon, 12 Feb 2018 00:29:43 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Feb 2018 00:29:43 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 12 Feb 2018 00:29:43 -0800 Message-ID: Subject: Re: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) To: Kazuho Oku , "Fossati, Thomas (Nokia - GB/Cambridge)" Cc: "alexandre.ferrieux@orange.com" , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113520ee1692410564ffae37" 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, 12 Feb 2018 08:29:46 -0000 --001a113520ee1692410564ffae37 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The proposal could also be implemented as an application protocol on top of QUIC A way to do this could be to post monitoring data on an MQTT message queue, especially if that queue is secured with QUIC. I=E2=80=99ve build applicati= on monitoring solutions in a similar manner and it works quite well. --001a113520ee1692410564ffae37 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

The proposal could als= o be implemented as an application protocol on top of QUIC

<= /span>

A way to do this could be to post monitoring da= ta on an MQTT message queue, especially if that queue is secured with QUIC.= I=E2=80=99ve build application monitoring solutions in a similar manner an= d it works quite well.

--001a113520ee1692410564ffae37-- From nobody Mon Feb 12 01:20:24 2018 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 5C0C0127011 for ; Mon, 12 Feb 2018 01:20:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 rVuBtT8h8O6p for ; Mon, 12 Feb 2018 01:20:20 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F260C120713 for ; Mon, 12 Feb 2018 01:20:18 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E89B6340D90; Mon, 12 Feb 2018 10:20:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.12381); Mon, 12 Feb 2018 10:20:15 +0100 (CET) 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; Mon, 12 Feb 2018 10:20:15 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 45075397; Mon, 12 Feb 2018 10:20:15 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-kazuho-quic-perf-metrics-00.txt (Re: Measurement bit(s) or not) From: "Brian Trammell (IETF)" In-Reply-To: Date: Mon, 12 Feb 2018 10:20:15 +0100 Cc: FERRIEUX Alexandre IMT/OLN , Kazuho Oku Content-Transfer-Encoding: quoted-printable Message-Id: <8EC2FC07-50B0-462E-87B4-35339604E04A@trammell.ch> 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, 12 Feb 2018 09:20:23 -0000 hi Kazuho, Many thanks for the draft. I've had a quick look at it. I like the = architecture it proposes -- hey, since the endpoints have full access to = all of these parameters, why not just ask them? -- but I'm afraid I = agree with the chorus of negative voices here that this raises too many = new issues to really be workable. We looked at something like this for PLUS -- a generic path-request = mechanism allowing a middlebox to ask an endpoint for a value -- and = decided to drop it from the proposal because the trust and DoS issues = were just too hairy. First, the mechanism adds up to 1RTT of delay, depending on the relative = position of the requesting device and the endpoint it wants to request = information from. Second, the reported metrics only have the resolution = available from the queried endpoint -- as we've seen in our work with = the spin bit, completely exposed signals don't suffer from this issue. = But most importantly, adding a hook for on path devices to query = endpoints adds significant complexity and attack surface, and seems = extremely difficult to secure against collaborating malicious devices = on-and-off-path. One nice thing about purely passive signals is that we know what the = information content is, we have a pretty good handle on how to restrict = their design to reduce the risk of additional endpoint fingerprinting, = and if we find the right tradeoff in endpoint complexity and measurement = fidelity, can get a lot of win for minimal implementation effort and = very little if any attack surface. I certainly think measurement and debugging approaches where both = servers and clients use existing mechanisms or extensions thereof (IPFIX = or something like Prometheus on the server side; extensions to JS APIs = for browsers or some other instrumentation on the client side) are a = useful part of diagnosing issues with QUIC traffic; indeed, = standardizing one or two of these would be a useful side project to = reduce the shock widespread QUIC deployment represents to the hosting = and web development communities. But neither scales very well to getting = information to other-than-client and other-than-server entities. Thanks, chsser, Brian > On 11 Feb 2018, at 17:51, Kazuho Oku wrote: >=20 > 2018-02-11 2:34 GMT+09:00 : >> Then Kazuho's square signal and Mikkel's Pi (or any other consensual >> self-synchronizing sequence) ramification came up. They are both = appealing >> for their elegance and low complexity on QUIC endpoints. Beyond their = quirks >> acknowledged here, here are a few considerations for troubleshooting: >> (snip) >> Given these, a benevolent, troubleshooting-minded passive midpoint = will >> clearly vote for the square. Now the obvious question is: is this >> acceptable, or deemed too easy for a Murphy, Inc. active middlebox to = see >> upstream losses and benevolently wreak havoc by delaying packets ? >=20 > Thank you for raising the question. >=20 > While I think that using square wave is a neat idea, I am not so sure > if the wavelength is correct, or if it would continue to be correct > for the lifetime of the transport protocol. I assume that other > patterns that have been proposed (e.g., PI, random) share the same > weakness. >=20 > Therefore, I have written a proposal of a very different approach, > which is the following I-D. >=20 > Performance Metrics Subprotocol for QUIC > https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/ >=20 > The I-D proposes to add a subprotocol that is used between an on-path > observer and the QUIC server to obtain the performance metrics. At the > latency of 1 RTT, the subprotocol can observe accurate upstream > loss/reorder rate, as well as SRTT / RTTVAR. >=20 > I believe that it is not difficult to implement on the server-side > (please refer to section 4). Client needs no change. >=20 > Since the proposed approach does not hard-code any information for > observation on the wire, the hard part of the design issue goes away. > We can adjust what (and how) to observe independently from the QUIC > transport. I think that this is not only a win in terms of design but > also might have positive effect on moving the standardization process > forward, since we would no longer be constrained by the discussion of > what should be observable "on-the-wire." >=20 > Privacy concern regarding observation becomes minor, since observation > becomes "observable" and deniable by an endpoint. >=20 > Although SRTT / RTTVAR is observable, I am not sure if it can be used > to replace the Spin Bit proposal. It depends on how often and how fast > an observer needs to see the metrics. Primary target of my proposal is > to help diagnosing issues. >=20 > Please let me know what you think. >=20 > ---------- Forwarded message ---------- > From: > Date: 2018-02-12 1:43 GMT+09:00 > Subject: New Version Notification for = draft-kazuho-quic-perf-metrics-00.txt > To: Kazuho Oku >=20 >=20 >=20 > A new version of I-D, draft-kazuho-quic-perf-metrics-00.txt > has been successfully submitted by Kazuho Oku and posted to the > IETF repository. >=20 > Name: draft-kazuho-quic-perf-metrics > Revision: 00 > Title: Performance Metrics Subprotocol for QUIC > Document date: 2018-02-12 > Group: Individual Submission > Pages: 8 > URL: > = https://www.ietf.org/internet-drafts/draft-kazuho-quic-perf-metrics-00.txt= > Status: = https://datatracker.ietf.org/doc/draft-kazuho-quic-perf-metrics/ > Htmlized: = https://tools.ietf.org/html/draft-kazuho-quic-perf-metrics-00 > Htmlized: > = https://datatracker.ietf.org/doc/html/draft-kazuho-quic-perf-metrics-00 >=20 >=20 > Abstract: > This memo proposes a subprotocol that can be used to query the > performance metrics of a QUIC path. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 >=20 > --=20 > Kazuho Oku >=20 From nobody Mon Feb 12 01:20:31 2018 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 074181270B4 for ; Mon, 12 Feb 2018 01:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 MaS-0vET10Rb for ; Mon, 12 Feb 2018 01:20:20 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D101241F5 for ; Mon, 12 Feb 2018 01:20:18 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C3190340DA4; Mon, 12 Feb 2018 10:20:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.13390); Mon, 12 Feb 2018 10:20:15 +0100 (CET) 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; Mon, 12 Feb 2018 10:20:15 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 45075392; Mon, 12 Feb 2018 10:20:15 +0100 From: "Brian Trammell (IETF)" Message-Id: <19F415EA-DC06-4FEE-8AFA-8A6EBEBB9AFA@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_D58A2912-B0AC-43D9-9A90-EAC9CE653A37"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Measurement bit(s) or not Date: Mon, 12 Feb 2018 10:20:14 +0100 In-Reply-To: Cc: "Lubashev, Igor" , "alexandre.ferrieux@orange.com" , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= To: "quic@ietf.org" References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> 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, 12 Feb 2018 09:20:25 -0000 --Apple-Mail=_D58A2912-B0AC-43D9-9A90-EAC9CE653A37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Mikkel, Igor, Alexandre, all, Engineering is fun, but let's step back a bit. :) It looks like we're exploring a space of proposals that have different = tradeoffs for the patterns of loss and reordering they can easily make = visible, tradeoffs for sender (endpoint) versus observer (midpoint) = complexity, and tradeoffs for fidelity versus overhead. In any case, it seems like it is possible to design a signal that would = be a vast improvement (from the measurement utility standpoint) over no = signal and no discernible pattern in the packet number that will fit in = bits scavenged from the Type field of the short header, i.e., the = bandwidth overhead will be *zero*, because otherwise in an encrypted-PN = world we just have to grease those bits anyway. Back to Alexandre's question: Do we want to do this? Rephrased: Is the passive measurability of loss, reordering (and, if we = consider the spin bit as one of the measurement bits, latency) of QUIC = important to us, or do we decide we can live with the negative pressure = a complete loss of visibility and an vast increase in diagnostic = complexity will place on deployment? Note, of course, that all the proposals we have so far represent a = decrease in visibility and an increase in complexity of measurement = compared to passive measurement of TCP. New tools will have to be = developed. But the loss of visibility is minimal compared to blackout, = and the deployability and feasibility of all of these is far, far better = than an SSLKEYLOGFILE-based debugging approach, especially in the = interdomain case. I've heard at least one dismissal of this whole space as being too = abstract to take seriously. (I'm not concerned, but maybe I've been = staring at network measurement both passive and active for too long to = know what's intuitive anymore.) Let me then suggest a way forward: I've announced a table at the London hackathon for "Transport = Measurability" (see = https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon), which we = intend to set up in the vicinity of QUIC. This was originally intended = as the "Spin Bit" table, and we (from ETH) will be there working on = scalable, open-source passive measurement tools both for the spin bit as = well as for the current TCP TSOPT and SEQ/ACK methodologies (as a basis = of comparison, mainly; at least in the case of the spin bit we so far = believe the explicit signal=C5=93 to have superior usability compared to = current TCP measurement). I suggest we expand the scope of table to hack = on various signals for loss and reordering, and to compare their = complexity and fidelity against the loss and reordering patterns we want = visibility into. One output of this work could be a (smaller) set of = suggestion(s) for which signal(s) to add, so that those who want to have = concrete proposals to evaluate can do so. Cheers, Brian > On 11 Feb 2018, at 20:25, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: >=20 > Actually, since the half-period is 16*2048 so loss can be detected up = to 32K packets, or typically 32MB worth of data. At the same time loss = can be detected within the first 16 bytes by trivially comparing the = first 8 bits with the next 8 bits. If these are not the same, something = is off. >=20 > But it is perfect because all bits could be zero. >=20 > To improve on this, each transmitted bit could be spread over two = packets, 0, 1 for sending a reset bit, and 1, 0 for sending a set bit. = If we then drop repeating the 8 bit pattern, the shortest half-period = remains at 16 packets since an 8-bit Gray code requires 16 packets. >=20 > Now we can detect a single loss or swap already after two packets, = although this is probably not interesting since reordering could happen = already in multiple send queues. > On 11 February 2018 at 20.06.14, Mikkel Fahn=C3=B8e J=C3=B8rgensen = (mikkelfj@gmail.com) wrote: >=20 >> I already wrote this elsewhere, but the mail topic was a bit off, and = I think it might actually be a good alternative to the other approaches = balancing the simplicity of the square without the problem of having to = wait for the square half period to detect loss. >>=20 >> It is a fractal pattern in the form of grey code. For example an 8 = bit code that is transmitted one bit a time. Each bit represents a wave = length and changes at half the wave length. To simplify synchronisation, = the same 8 bit pattern could be transmitted twice before a bit changes. = This would support half-periods of 16, 32, =E2=80=A6, 2048 packets. >>=20 >> In addition, there is a lot of error correcting coding theory around = this with noise analysis and maximum likelihood decoders. >>=20 >> https://en.wikipedia.org/wiki/Gray_code >> https://en.wikipedia.org/wiki/Constellation_diagram >>=20 >> The encoding is simple as per Wikipedia: >>=20 >> /* >> * This function converts an unsigned binary >> * number to reflected binary Gray code. >> * >> * The operator >> is shift right. The operator ^ is exclusive or. >> */ >> unsigned int binaryToGray(unsigned int num) >> { >>=20 >>=20 >> return num ^ (num >> 1); >> } >>=20 >>=20 >>=20 >> /* >> * This function converts a reflected binary >> * Gray code number to a binary number. >> * Each Gray code bit is exclusive-ored with all >> * more significant bits. >> */ >> unsigned int grayToBinary(unsigned int num) >> { >>=20 >>=20 >> unsigned int mask =3D num; >>=20 >>=20 >> while (mask !=3D 0) >>=20 >>=20 >> { >>=20 >>=20 >> mask =3D mask >> 1; >>=20 >>=20 >> num =3D num ^ mask; >>=20 >>=20 >> } >>=20 >>=20 >> return num; >> } >>=20 >>=20 >>=20 >> /* >> * A more efficient version, for Gray codes of 32 or fewer bits. >> */ >> unsigned int grayToBinary32(unsigned int num) >> { >>=20 >>=20 >> num =3D num ^ (num >> 16); >>=20 >>=20 >> num =3D num ^ (num >> 8); >>=20 >>=20 >> num =3D num ^ (num >> 4); >>=20 >>=20 >> num =3D num ^ (num >> 2); >>=20 >>=20 >> num =3D num ^ (num >> 1); >>=20 >>=20 >> return num; >> } >>=20 >>=20 >> On 10 February 2018 at 22.41.51, Lubashev, Igor (ilubashe@akamai.com) = wrote: >>=20 >>> I am a bit sceptical about the square. With TCP, packet trace shows = loss of any packet, except for SYN. The "square wave" whould show no = loss at all for short connections (fewer than a "wavelength" of = packets). Moreover, the square wave can only detect loss after up to the = wave length of subsequent packets has been transmitted. If there is an = application pause in transmission, loss may not become evident. >>>=20 >>> Basically, a spin bit or a bit pattern (like a square wave) may help = in troubleshooting, but it will be more uncertain and hokey than what = people come to expect of tcp. We have be very clear in acknowledging it. >>>=20 >>> -----Original Message----- >>> From: alexandre.ferrieux@orange.com [alexandre.ferrieux@orange.com] >>> Received: Saturday, 10 Feb 2018, 12:34PM >>> To: quic@ietf.org [quic@ietf.org] >>> Subject: Measurement bit(s) or not >>>=20 >>> On 07/02/2018 14:34, Brian Trammell (IETF) wrote: >>> > hi Jana, >>> > >>> >> 3. Some sequencing information -- a few bits of the packet = number perhaps >>> >> -- should be revealed (for monitoring. Number of bits TBD.) >>> > >>> > This is the crux of the argument. On one side we have the risk of = misuse and >>> > ossification (well, not ossification -- these bits are *meant* = for the path >>> > -- rather the risk that we'll figure out later that we specified = the wrong >>> > thing), on the other side we have the loss of visibility into how = QUIC >>> > traffic interacts with the network as compared to TCP, with a = side question >>> > of whether or not this visibility is really the transport layer's = problem >>> > despite the evolution the practice of diagnostics and = troubleshooting using >>> > TCP information. >>> > >>> > If we can come to agreement on this question, everything else = falls into >>> > place. I have my arguments here, but as you said, this subthread = is not the >>> > place for them. :) >>>=20 >>> The crux indeed. So what about settling it first ? >>>=20 >>> With the troubleshooting hat, I can only stress the need for = measurement bits, >>> for the benefit of everybody, since s**t happens, networks are = imperfect, and >>> nifty encapsulations-with-seqnum will simply not be where you need = them. >>>=20 >>> Now to the exact nature of these measurement bits: >>>=20 >>> Thanks to the detailed exchanges on this thread, it is by now clear = that a >>> simple gapless counter, even nonzero-based and XORed, is not = acceptable. The >>> 4-bit SSN comes pretty close but is not enough when things go really = wrong (and >>> they will - and that's where we need the tool). >>>=20 >>> Then Kazuho's square signal and Mikkel's Pi (or any other consensual >>> self-synchronizing sequence) ramification came up. They are both = appealing for >>> their elegance and low complexity on QUIC endpoints. Beyond their = quirks >>> acknowledged here, here are a few considerations for = troubleshooting: >>>=20 >>> (1) Since reordering is less of a concern to QUIC than to TCP, it = becomes a >>> secondary goal. This is nice, because the square doesn't see it, and = the >>> self-synchronizing sequence will only tolerate a mild one, and never = see its >>> detail like cycle length etc. >>>=20 >>> (2) There's of course a huge difference between them in complexity = for the >>> midpoint: square is trivial, Pi is hefty. >>>=20 >>> Given these, a benevolent, troubleshooting-minded passive midpoint = will clearly >>> vote for the square. Now the obvious question is: is this = acceptable, or deemed >>> too easy for a Murphy, Inc. active middlebox to see upstream losses = and >>> benevolently wreak havoc by delaying packets ? >>>=20 >>> = __________________________________________________________________________= _______________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc >>> pas etre diffuses, exploites ou copies sans autorisation. Si vous = avez recu ce message par erreur, veuillez le signaler >>> a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, >>> Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or = privileged information that may be protected by law; >>> they should not be distributed, used or copied without = authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. --Apple-Mail=_D58A2912-B0AC-43D9-9A90-EAC9CE653A37 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlqBXE4ACgkQihK3vwvq RqPFDxAAg/Xw/+KDfTUUpHH9TmZw8wlYGcYMJX8iwc2UkvlYc3rjMiLtug9Eh9Fp fOGOU8BJJkJ8YAiyEfAI1pJpK4142oEEczD0sU4QXzCfIf9XqfCbR5SKs1FD/mp4 9+Yt9P0CdIJ/vv188/ypyaHYd3gF2niIn1gHNoHeyhIMncOLWVYJYkCWpr5/yt3s SBR/wj9+PUh5V1QqSka9gRRPoeLm5dU9lk6APryJZ0fjNG6RQ7fqQSb5hEh+aep9 YfktpidNcZBb1i9fZBwS3pZHs+jUQDbJwQKxpVPaP6gvgTaCSD1HutrvG2hoxLKw 0hcjPNzT43NL78dLKD/1FNd6h/Kp5b8QgUzgidRM7CCwdKPLJLaz1J3WMsswhoVA o/oMxNoFZKMuZuwADpJBE4PKBd9W5eh4mFjmFIo9o+4eqHZSw5A0bqath3fq3njq e70Z2x6RJ/BS8nVMmN1CnZHtWE9WuK07IAQhKU2326kIP7y/WevVY2pjgXka2P4I LzyQ3N/W3cp3msj60JjO0qnG3uA53MI+yQg66lzc504h5ZrUZuAuxhK5onbUQrex oAcMIcTYO6/vjNizHqJUr6LfzGXDYLcuA/8jV3a3boPri9WC8F/SU7g4e3+WBo3c lADviizrUBm6aLibG8ibCLWrQr+aLerC+CkpMg6Abx7ToE7a0N4= =f2uy -----END PGP SIGNATURE----- --Apple-Mail=_D58A2912-B0AC-43D9-9A90-EAC9CE653A37-- From nobody Mon Feb 12 01:35:02 2018 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 DE8551270A0 for ; Mon, 12 Feb 2018 01:35:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 YAOEaUGDccZB for ; Mon, 12 Feb 2018 01:34:59 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::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 2937E120047 for ; Mon, 12 Feb 2018 01:34:59 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id i144so5920385ita.3 for ; Mon, 12 Feb 2018 01:34:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=1/0w7TLQwxWqqd+04RQ830aeUWQXDBkXD4XBE13ziZI=; b=Zg7ZCN+yCeJO8cjlvYY95nnww17Hl24mOrH7hSqHEt+X81gE1+uB9+pwbqsBTvohTK KvZ12aiLKyjD5heY7P2XMlMU0Uiz6nO/wEWVEZpNFwgB3xRVqnQkyv6oRMi1kfcXdPGH qUOF37l6XG7VymoesZRG4m51YFivqI1zJeCwwTV7SSBphyaEt+CQNtRbRJhOC9IBMc/p 8Rr5LAa+x9u1Dp6ivWBOSHpnjQaIxDLI7zqC5zcT40jfz0zm+gJ6e3IZbZNkQ+F+L1eX Ux04iXNqi7+ygRBM5xELCCdl/SGTjUUUPbIfxt+hzenjtCb+uZDWZIls53SG09ws338a yYbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=1/0w7TLQwxWqqd+04RQ830aeUWQXDBkXD4XBE13ziZI=; b=ekh83addkchvaihtKqRYyLTKMH4oaGiyo30+2enf5gXTGak+o9NYrq02ppNRbEiYDm EnHS1hggrziImuGRkQJ8bJafylzN3MGI4tZajb90h5QY83onk9tWQxhDO5BBEfx9Ygc8 ZRs7RpbgEFDgykRoZRqr9Qrl1uIHff1l8ixoWhi428V9FfWFq2Upmd15hN25iaGyB/8c uOONp6DADLfwLC9yB1+2wdN0qSj1fslQ8esf+mSQz5G4K6mwAIVybEvAoieMcHrR1Tou IsCMo9JTTrYbmmocsta2GMUAYysbKPdJiOfDzrXoHjMl5IYrMAQCuEMKlksMdFHBF35v 1CPQ== X-Gm-Message-State: APf1xPDSSYd0RKe3LHExWZdf1Dm2axKd9yxTNXHzno9uLRDOpMf2UI3y bhUkl+khukPs1lxpVtA5gqW3LTn2F1Fp66cNEXU= X-Google-Smtp-Source: AH8x2259xAZfSNKV/XdX51XGMXXHtp70wZ3dLm01hG06ie0rlpH3YdyBQjVcroWyEksjEYp494SVum9g67k0XrItB/s= X-Received: by 10.36.46.23 with SMTP id i23mr4715517ita.55.1518428098458; Mon, 12 Feb 2018 01:34:58 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Feb 2018 01:34:57 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <19F415EA-DC06-4FEE-8AFA-8A6EBEBB9AFA@trammell.ch> References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> <19F415EA-DC06-4FEE-8AFA-8A6EBEBB9AFA@trammell.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 12 Feb 2018 01:34:57 -0800 Message-ID: Subject: Re: Measurement bit(s) or not To: "Brian Trammell (IETF)" , "quic@ietf.org" Cc: "Lubashev, Igor" , "alexandre.ferrieux@orange.com" Content-Type: multipart/alternative; boundary="001a114a9d826cfa110565009711" 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, 12 Feb 2018 09:35:01 -0000 --001a114a9d826cfa110565009711 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On 12 February 2018 at 10.20.16, Brian Trammell (IETF) (ietf@trammell.ch) wrote: Do we want to do this? Rephrased: Is the passive measurability of loss, reordering (and, if we consider the spin bit as one of the measurement bits, latency) of QUIC important to us, or do we decide we can live with the negative pressure a complete loss of visibility and an vast increase in diagnostic complexity will place on deployment? Originally I did not care much, but I think there is self-interest in supporting some level of passive monitoring: External hostile agents that can drop packets are more easily exposed, hence monitoring is a deterrent. Traffic shaping by an internet provider might be exposed more easily. Internet providers might =E2=80=9Caccidentally=E2=80=9D misplace some netfl= ix packets. Routers that experience faulty paths can more readily route traffic towards higher fidelity path in terms of latency and loss. Omitting monitoring might just add tunnel headers increasing overhead. Clearly there is a privacy concern, and we should not expose unnecessary details. Packets could be sorted against the applications interest. But this can happen with tunnel headers. Latency cannot as easily be monitored without help, but it is not that difficult either: measure timing between packets and find a pause, then wait for traffic the other way. --001a114a9d826cfa110565009711 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On 12 February 2018 = at 10.20.16, Brian Trammell (IETF) (iet= f@trammell.ch) wrote:
Do we want to do= this?=C2=A0

Rephrased: Is the passive measura= bility of loss, reordering (and, if we consider the spin bit as one of the = measurement bits, latency) of QUIC important to us, or do we decide we can = live with the negative pressure a complete loss of visibility and an vast i= ncrease in diagnostic complexity will place on deployment?=C2=A0
Originally I did not care much, but I think there is self-interest in supp= orting some level of passive monitoring:

External hostile agents that= can drop packets are more easily exposed, hence monitoring is a deterrent.=

Traffic shaping by an internet provider might be exposed more easily= . Internet providers might =E2=80=9Caccidentally=E2=80=9D misplace some net= flix packets.

Routers that experience faulty paths can more readily r= oute traffic towards higher fidelity path in terms of latency and loss.

=

Omitting monitoring might just add tunnel headers increasing overhead.

Clearly there is a privacy concern, and we should not expose unnecessa= ry details. Packets could be sorted against the applications interest. But = this can happen with tunnel headers. Latency cannot as easily be monitored = without help, but it is not that difficult either: measure timing between p= ackets and find a pause, then wait for traffic the other way.

--001a114a9d826cfa110565009711-- From nobody Mon Feb 12 03:44:05 2018 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 1647B124D37 for ; Mon, 12 Feb 2018 03:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 f7hQCtARYxow for ; Mon, 12 Feb 2018 03:44:01 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e: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 239841201FA for ; Mon, 12 Feb 2018 03:44:01 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id g2so7341479pgn.7 for ; Mon, 12 Feb 2018 03:44:01 -0800 (PST) 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=EY0LtbjJTLaOFUwCrpUJOLVC+2UVQ1TKLgHx5rsjN3A=; b=sOgYmjIogdWMpGEOsnfcctg1jAtl6Uaj/Sf3t2wCv4lWt9L9KhQfvekz7dt0dAanPY TUcd/Xy8DYwEANdVDHYXvDr9LnqguG117yRwo9NHWpr/kmqBwM8o8+0jvDoTXbDnU4+E hhCIy0BBVgjrzmH53xuI+3kPEa5nnq7ISo0HPs6GDK1eZ7bx1fHFdqYEqON72CVGUAOY /Zg/7/rriBP99aLjUctnJwsUIdW8t1wuTZckfPAWRPSOcnTVBg/vKI0g6cgM1FLsu3ms 1kiTu5mTNfV7kneSeRudVmbRzHZStBJtuwaT/hYXfXc0KzwAmuYrOw1fF4yhSBzGNka4 Z+Uw== 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=EY0LtbjJTLaOFUwCrpUJOLVC+2UVQ1TKLgHx5rsjN3A=; b=I1k3LcKCrnh3j6O0+Hc16IRR8wPu/g2g3amu874OWkN8ilpmR1lp5VO6oB9aNTbyV6 hI+HIDwLmej2i9+LN+PC+OOkRhly/GxNmhsZwAk6dtBZwklJD0fbWFwU6lCLlDt/4RyE MWu/SKnL0GXqVPM+z1VoF0cJdgbt6zn6dpt1YEWwNvkOWOehUvWS28VrTU5iIlTYSnlN CYQHQdjfnzp+2PdMX+g9v2k1K32U1RLNLk/HMtRQOm6hQykXTRKAohvZnF9b++2MZcWR pXxsyzrRlPm5OXs26M9bEQy4GqwBT1+QVh3QfPNyHJUpxvO8bdKkpykL5Jv3djMoHZBY h8cg== X-Gm-Message-State: APf1xPCDSv3kBrhjEl57+8NXl1NbIl/24bTK4/ZT/x3oolBwRFk/Sz2z EQGqxO8RyNvI+vPkcKbCdUIWVxpDylPlgrInz5o= X-Google-Smtp-Source: AH8x224ZO5bgb+qpENozZT4oT0VBmamZOSUH6WoLYLdU8FdYtjTByqmheEx7oZoodjRYiEIq8vGdJiBoz6K4l7x9+lk= X-Received: by 10.99.125.29 with SMTP id y29mr7282187pgc.277.1518435840371; Mon, 12 Feb 2018 03:44:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.191.134 with HTTP; Mon, 12 Feb 2018 03:43:59 -0800 (PST) In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> From: Kazuho Oku Date: Mon, 12 Feb 2018 20:43:59 +0900 Message-ID: Subject: Re: Packet number encryption To: Victor Vasiliev Cc: Praveen Balasubramanian , Marten Seemann , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , huitema 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: Mon, 12 Feb 2018 11:44:03 -0000 Victor, Mikkel, thank you for the estimations. To me it seems that the estimated overhead of 0.1% seems like a natural number that we would see on production environment, where the average packet size is not small. I also agree that it would be worthwhile to look the case where small packets are exchanged. The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. One benchmark that might give us a more meaningful number is the DNS benchm= ark. https://www.knot-dns.cz/benchmark/ lists a benchmark of several authoritative DNS servers. The TLD benchmark and the Hosting (10k) benchmark gives us the rough estimation on how much PPS we can achieve when exchanging small packets. The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16 core (8x2) Intel Xeon processer running with HP enabled, when the fastest DNS server is being used. Running `openssl speed -evp` on a similar CPU gives me the following result= : $ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128 Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc's in = 3.00s This shows that 40M AES block operations can be run on a single core, per second, which in turn means that a server with 16 cores can perform 640M AES block operations per second (or 1,280M if HT is enabled and if AES is not the bottleneck). To summarize, if DNS had packet encryption, the overhead would be somewhere from 0.3% to 0.6%. Considering that, I would anticipate that the overhead of packet number encryption will be neglible even for short packet workloads. 2018-02-12 16:19 GMT+09:00 Victor Vasiliev : > I have no idea how you get that number (by which I mean, I have a lot of > guesses, but none of which are solid or useful here). I looked at the > profiles of various workloads we're running in production, and I estimate > that none of them would be impacted by PN encryption by worse than 0.1%. > > On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian > wrote: >> >> Makes sense. The 1%+ overhead I had quoted was in comparison to full >> protocol processing all the way from app to NIC. This is with an unoptim= ized >> early QUIC implementation and not fully optimized UDP/IP stack (we have >> focused much much more on optimizing TCP in the past). After software st= ack >> optimizations, the crypto share of the cost will only keep going up for >> which we have no technique other than to offload when such support is >> available in hardware and offload is way more challenging when workload = is >> hosted in VMs and containers. >> >> >> >> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] >> Sent: Saturday, February 10, 2018 3:36 AM >> To: Victor Vasiliev >> Cc: Praveen Balasubramanian ; quic@ietf.org; Marten >> Seemann ; huitema >> Subject: Re: Packet number encryption >> >> >> >> To put numbers into perspective using Intel 2015 data >> >> >> >> >> https://software.intel.com/en-us/articles/improving-openssl-performance#= _Toc416943490 >> >> >> >> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte o= r >> 66 cycles total, or 22ns on a 3GHz core. >> >> >> >> For packet numbers we use the CBC encrypt numbers because here AES canno= t >> exploit block parallelism. >> >> Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz >> setup that would amount to about 24ns overhead for packet encryption. >> >> >> >> Clearly it makes no sense that AES-GCM is faster than a single AES block >> encryption, but these are only approximate numbers and CBC mode might ha= ve a >> little overhead, so we clamp packet numbers to 22ns. >> >> >> >> Taking the 98ns overhead by the Solarflare report we get a total >> (simplified) processing time is 98ns non-crypto, 22ns for packet number,= and >> 22ns for AEAD totalling 142ns. So the packet number encryption overhead >> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeep= ing, >> but that can be done in other cores or outside the latency critical wind= ow. >> >> >> >> This does not take into account that AEAD operation may operate less tha= n >> optimal because the packet number must be extracted first. On the other >> hand, it is also not a disastrous overhead if no good alternative can be >> found. >> >> >> >> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycle= s in HW >> for a single AES-128 block which would be 33ns per packet number in the >> above example. >> >> >> >> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen >> (mikkelfj@gmail.com) wrote: >> >> 98ns for 68 byte messages > > --=20 Kazuho Oku From nobody Mon Feb 12 03:49:43 2018 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 5119F127601 for ; Mon, 12 Feb 2018 03:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 QFxV8smxCcIp for ; Mon, 12 Feb 2018 03:49:40 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 1BDE41275FD for ; Mon, 12 Feb 2018 03:49:40 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id z6so16916932iob.11 for ; Mon, 12 Feb 2018 03:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=haDI99DHgjXBCuglC1ec4f9UO3asqEyj5RGlt9D+4+I=; b=ZYeIdXI2hg3ti+ADDtrsZEg6g2X5zNrWE+9Phi7PnREO7W2Lhsew4iEZeisZnYppGA pnUpHdhoWYFp4EJJ52YrBnxL4jzDVHBj7wujv8qy6cb9dyyGnDwm1G1dGstHFTx6/TqE Czcqcubz72UrQAM5p5W80LWBtAhKL9JMiZZOuhiT7HrNg/V/iAs55qv/454vO0aaTbj6 orxG0GQ3d1tx9FkmVBqD7/NpmwLkJYFRTrGTe9oCGWbnAxLt/3Jyj72d00ohNTomVBKF 8Ng0K8JA5f/nl8KZJ+fRnA3K29RHWzrFjC/OekpNtOUUI0eBE6xi8xPOoqjkVZQLK2gw asAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=haDI99DHgjXBCuglC1ec4f9UO3asqEyj5RGlt9D+4+I=; b=gJ3Qxnx01NiS1L5iPYJY73EAdpkiFQGPwIiZ4WqiSaP/yBSf06fQzX3RM3/9dLJvCe NgVw98UsCiHHdjQ1beKle/M6e3fyz0Cktg6QP/UAfkQg/mhx5Pc95q6QLDbCG1D5QGVY 2kmZSVg5MWbh0xEv/oOJldOXBy0+ENlYXa22ZMzm+gTblA3e6USIIOEb8HSlAaNHhkcj 6HEX9KfPcwGeRF6SIgT/ry/JdXU2JKIDofR/6UbNdMsZQ1syAZLe0eorE0o8zUQ0o7jV tRSQdPsD71Z2CyKuqRZkZbYAfvdWjHkbpfrLgmTyESJamhY32ANYPC9jmEL2yc/tpUzS jI5Q== X-Gm-Message-State: APf1xPBblL3rXhFyiZUDwE4HaWj2ioafUHkv9K9EjsVLuTOXZCfjYR7j XnrNbFCkXs9UeHJviUlAfKP6xpZBXCqB71bG2Qc= X-Google-Smtp-Source: AH8x227HVvnLniBrwnkKtlUlJ4qx459P8hp+TIOsl9WdWRhXTtXRpkWoSXUh+B6StdTD2Hub1DHww9LrRPWZYV3nkh4= X-Received: by 10.107.20.200 with SMTP id 191mr13127695iou.239.1518436179348; Mon, 12 Feb 2018 03:49:39 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Feb 2018 03:49:38 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 12 Feb 2018 03:49:38 -0800 Message-ID: Subject: Re: Packet number encryption To: Victor Vasiliev , Kazuho Oku Cc: Praveen Balasubramanian , "quic@ietf.org" , Marten Seemann , huitema Content-Type: multipart/alternative; boundary="001a114fd4c815943a05650279f4" 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, 12 Feb 2018 11:49:42 -0000 --001a114fd4c815943a05650279f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I can add some more numbers here https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.= pl The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. HFT is the extreme case which is why the benchmark is interesting, not necessarily the use case itself. The same concern applies to how fast a distributed database can achieve consensus, which is something I do care about. On 12 February 2018 at 12.44.01, Kazuho Oku (kazuhooku@gmail.com) wrote: Victor, Mikkel, thank you for the estimations. To me it seems that the estimated overhead of 0.1% seems like a natural number that we would see on production environment, where the average packet size is not small. I also agree that it would be worthwhile to look the case where small packets are exchanged. The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. One benchmark that might give us a more meaningful number is the DNS benchmark. https://www.knot-dns.cz/benchmark/ lists a benchmark of several authoritative DNS servers. The TLD benchmark and the Hosting (10k) benchmark gives us the rough estimation on how much PPS we can achieve when exchanging small packets. The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16 core (8x2) Intel Xeon processer running with HP enabled, when the fastest DNS server is being used. Running `openssl speed -evp` on a similar CPU gives me the following result: $ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128 Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc's in 3.00s This shows that 40M AES block operations can be run on a single core, per second, which in turn means that a server with 16 cores can perform 640M AES block operations per second (or 1,280M if HT is enabled and if AES is not the bottleneck). To summarize, if DNS had packet encryption, the overhead would be somewhere from 0.3% to 0.6%. Considering that, I would anticipate that the overhead of packet number encryption will be neglible even for short packet workloads. 2018-02-12 16:19 GMT+09:00 Victor Vasiliev : > I have no idea how you get that number (by which I mean, I have a lot of > guesses, but none of which are solid or useful here). I looked at the > profiles of various workloads we're running in production, and I estimate > that none of them would be impacted by PN encryption by worse than 0.1%. > > On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian > wrote: >> >> Makes sense. The 1%+ overhead I had quoted was in comparison to full >> protocol processing all the way from app to NIC. This is with an unoptimized >> early QUIC implementation and not fully optimized UDP/IP stack (we have >> focused much much more on optimizing TCP in the past). After software stack >> optimizations, the crypto share of the cost will only keep going up for >> which we have no technique other than to offload when such support is >> available in hardware and offload is way more challenging when workload is >> hosted in VMs and containers. >> >> >> >> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] >> Sent: Saturday, February 10, 2018 3:36 AM >> To: Victor Vasiliev >> Cc: Praveen Balasubramanian ; quic@ietf.org; Marten >> Seemann ; huitema >> Subject: Re: Packet number encryption >> >> >> >> To put numbers into perspective using Intel 2015 data >> >> >> >> >> https://software.intel.com/en-us/articles/improving-openssl-performance#_To= c416943490 >> >> >> >> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte or >> 66 cycles total, or 22ns on a 3GHz core. >> >> >> >> For packet numbers we use the CBC encrypt numbers because here AES cannot >> exploit block parallelism. >> >> Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz >> setup that would amount to about 24ns overhead for packet encryption. >> >> >> >> Clearly it makes no sense that AES-GCM is faster than a single AES block >> encryption, but these are only approximate numbers and CBC mode might have a >> little overhead, so we clamp packet numbers to 22ns. >> >> >> >> Taking the 98ns overhead by the Solarflare report we get a total >> (simplified) processing time is 98ns non-crypto, 22ns for packet number, and >> 22ns for AEAD totalling 142ns. So the packet number encryption overhead >> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeeping, >> but that can be done in other cores or outside the latency critical window. >> >> >> >> This does not take into account that AEAD operation may operate less than >> optimal because the packet number must be extracted first. On the other >> hand, it is also not a disastrous overhead if no good alternative can be >> found. >> >> >> >> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycle= s in HW >> for a single AES-128 block which would be 33ns per packet number in the >> above example. >> >> >> >> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen >> (mikkelfj@gmail.com) wrote: >> >> 98ns for 68 byte messages > > --=20 Kazuho Oku --001a114fd4c815943a05650279f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I can add some more = numbers here

The = numbers deducted from Solarflare report is=C2=A0
interesting, however I = am not sure if that reflects the ordinary use=C2=A0
of a protocol; my un= derstanding is that HFT is exceptional.=C2=A0

HFT is t= he extreme case which is why the benchmark is interesting, not necessarily = the use case itself.

The same concern applies to how fast a distribut= ed database can achieve consensus, which is something I do care about.

=

On 12 February 2018 at 12.44.01, Kazuho Oku (kazuhooku@gmail.com) wrote:

Victo= r, Mikkel, thank you for the estimations.

To me it seems that the estimated overhead of 0.1% seems like a
natural number that we would see on production environment, where the
average packet size is not small.

I also agree that it would be worthwhile to look the case where small
packets are exchanged. The numbers deducted from Solarflare report is
interesting, however I am not sure if that reflects the ordinary use
of a protocol; my understanding is that HFT is exceptional.

One benchmark that might give us a more meaningful number is the DNS be= nchmark.

https://www.knot-dns.cz/= benchmark/ lists a benchmark of several
authoritative DNS servers. The TLD benchmark and the Hosting (10k)
benchmark gives us the rough estimation on how much PPS we can achieve
when exchanging small packets.

The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16
core (8x2) Intel Xeon processer running with HP enabled, when the
fastest DNS server is being used.

Running `openssl speed -evp` on a similar CPU gives me the following re= sult:

$ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128
Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc&#= 39;s in 3.00s

This shows that 40M AES block operations can be run on a single core,
per second, which in turn means that a server with 16 cores can
perform 640M AES block operations per second (or 1,280M if HT is
enabled and if AES is not the bottleneck).

To summarize, if DNS had packet encryption, the overhead would be
somewhere from 0.3% to 0.6%.

Considering that, I would anticipate that the overhead of packet
number encryption will be neglible even for short packet workloads.


2018-02-12 16:19 GMT+09:00 Victor Vasiliev <vasilvv@google.com>:
> I have no idea how you get that number (by which I mean, I have a = lot of
> guesses, but none of which are solid or useful here). I looked at= the
> profiles of various workloads we're running in production, and= I estimate
> that none of them would be impacted by PN encryption by worse than= 0.1%.
>
> On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian
> <pravb@microsoft.com= > wrote:
>>
>> Makes sense. The 1%+ overhead I had quoted was in comparison t= o full
>> protocol processing all the way from app to NIC. This is with = an unoptimized
>> early QUIC implementation and not fully optimized UDP/IP stack= (we have
>> focused much much more on optimizing TCP in the past). After s= oftware stack
>> optimizations, the crypto share of the cost will only keep goi= ng up for
>> which we have no technique other than to offload when such sup= port is
>> available in hardware and offload is way more challenging when= workload is
>> hosted in VMs and containers.
>>
>>
>>
>> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
>> Sent: Saturday, February 10, 2018 3:36 AM
>> To: Victor Vasiliev <= vasilvv@google.com>
>> Cc: Praveen Balasubramanian <pravb@microsoft.com>; quic= @ietf.org; Marten
>> Seemann <martens= eemann@gmail.com>; huitema <huitema@huitema.net>
>> Subject: Re: Packet number encryption
>>
>>
>>
>> To put numbers into perspective using Intel 2015 data
>>
>>
>>
>>
>> https://software.intel.com/en-us/articl= es/improving-openssl-performance#_Toc416943490
>>
>>
>>
>> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles = per byte or
>> 66 cycles total, or 22ns on a 3GHz core.
>>
>>
>>
>> For packet numbers we use the CBC encrypt numbers because here= AES cannot
>> exploit block parallelism.
>>
>> Here we see 4.44 cycles/byte in HW or 71 cycles per block. Wit= h a 3GHz
>> setup that would amount to about 24ns overhead for packet encr= yption.
>>
>>
>>
>> Clearly it makes no sense that AES-GCM is faster than a single= AES block
>> encryption, but these are only approximate numbers and CBC mod= e might have a
>> little overhead, so we clamp packet numbers to 22ns.
>>
>>
>>
>> Taking the 98ns overhead by the Solarflare report we get a tot= al
>> (simplified) processing time is 98ns non-crypto, 22ns for pack= et number, and
>> 22ns for AEAD totalling 142ns. So the packet number encryption= overhead
>> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUI= C bookkeeping,
>> but that can be done in other cores or outside the latency cri= tical window.
>>
>>
>>
>> This does not take into account that AEAD operation may operat= e less than
>> optimal because the packet number must be extracted first. On = the other
>> hand, it is also not a disastrous overhead if no good alternat= ive can be
>> found.
>>
>>
>>
>> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests aroun= d 100cycles in HW
>> for a single AES-128 block which would be 33ns per packet numb= er in the
>> above example.
>>
>>
>>
>> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rge= nsen
>> (mikkelfj@gmail.com)= wrote:
>>
>> 98ns for 68 byte messages
>
>



-- =20
Kazuho Oku
--001a114fd4c815943a05650279f4-- From nobody Mon Feb 12 03:56:43 2018 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 B2D4C12778E for ; Mon, 12 Feb 2018 03:56:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FORGED_MUA_MOZILLA=2.309, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 au9AO3XPpZrO for ; Mon, 12 Feb 2018 03:56:40 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9B61276AF for ; Mon, 12 Feb 2018 03:56:40 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id CB5A060602; Mon, 12 Feb 2018 12:56:38 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.3]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id AF5EF4006F; Mon, 12 Feb 2018 12:56:38 +0100 (CET) Received: from lat6466.rd.francetelecom.fr (10.168.234.6) by OPEXCLILM5D.corporate.adroot.infra.ftgroup (10.114.31.3) with Microsoft SMTP Server (TLS) id 14.3.382.0; Mon, 12 Feb 2018 12:56:38 +0100 Message-ID: <27669_1518436598_5A8180F6_27669_174_1_5A8180F8.6020705@orange.com> Date: Mon, 12 Feb 2018 12:56:40 +0100 From: Reply-To: Alexandre Ferrieux Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: "Brian Trammell (IETF)" CC: "quic@ietf.org" Subject: Re: Measurement bit(s) or not References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> <19F415EA-DC06-4FEE-8AFA-8A6EBEBB9AFA@trammell.ch> In-Reply-To: <19F415EA-DC06-4FEE-8AFA-8A6EBEBB9AFA@trammell.ch> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.168.234.6] 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, 12 Feb 2018 11:56:43 -0000 Hi Brian, We're clearly in violent agreement about both the potential to make intelli= gent use of this measurement nibble, and the desirability of *some* troubleshoot= ing helper. Thanks for proposing to include this discussion in the spin bit tab= le. As it turns out, we do have concrete illustrations to show there, on real networks and long distances. But beyond that, I'd like to "probe" this grou= p for a possible veto before digging further: while I have no doubt about an even= tual consensus among us "troubleshooters", I'm more worried by the other side of= the=20 board: people primarily concerned about ossification and linkability, to wh= om network debugging is at best a secondary goal. More precisely, as you accurately described, the position of the cursor of = both tradeoffs may display a kind of threshold for acceptability by them : - endpoint vs midpoint complexity: if the tool is too easy on the midpoint, active Murphies will come in ; at kind of entry barrier should be set -- ho= w high ? - fidelity: the coarser, or the more delayed, the better, since it preclude= s any real-time feedback loop like active Murphies do ; what is the minimum degradation that is needed ? On 12/02/2018 10:20, Brian Trammell (IETF) wrote: > hi Mikkel, Igor, Alexandre, all, > > Engineering is fun, but let's step back a bit. :) > > It looks like we're exploring a space of proposals that have different > tradeoffs for the patterns of loss and reordering they can easily make > visible, tradeoffs for sender (endpoint) versus observer (midpoint) > complexity, and tradeoffs for fidelity versus overhead. > > In any case, it seems like it is possible to design a signal that would b= e a > vast improvement (from the measurement utility standpoint) over no signal= and > no discernible pattern in the packet number that will fit in bits scaveng= ed > from the Type field of the short header, i.e., the bandwidth overhead wil= l be > *zero*, because otherwise in an encrypted-PN world we just have to grease > those bits anyway. > > Back to Alexandre's question: > > Do we want to do this? > > Rephrased: Is the passive measurability of loss, reordering (and, if we > consider the spin bit as one of the measurement bits, latency) of QUIC > important to us, or do we decide we can live with the negative pressure a > complete loss of visibility and an vast increase in diagnostic complexity > will place on deployment? > > Note, of course, that all the proposals we have so far represent a decrea= se > in visibility and an increase in complexity of measurement compared to > passive measurement of TCP. New tools will have to be developed. But the = loss > of visibility is minimal compared to blackout, and the deployability and > feasibility of all of these is far, far better than an SSLKEYLOGFILE-based > debugging approach, especially in the interdomain case. > > I've heard at least one dismissal of this whole space as being too abstra= ct > to take seriously. (I'm not concerned, but maybe I've been staring at net= work > measurement both passive and active for too long to know what's intuitive > anymore.) Let me then suggest a way forward: > > I've announced a table at the London hackathon for "Transport Measurabili= ty" > (see https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon), which we > intend to set up in the vicinity of QUIC. This was originally intended as= the > "Spin Bit" table, and we (from ETH) will be there working on scalable, > open-source passive measurement tools both for the spin bit as well as for > the current TCP TSOPT and SEQ/ACK methodologies (as a basis of comparison, > mainly; at least in the case of the spin bit we so far believe the explic= it > signal=9C to have superior usability compared to current TCP measurement)= . I > suggest we expand the scope of table to hack on various signals for loss = and > reordering, and to compare their complexity and fidelity against the loss= and > reordering patterns we want visibility into. One output of this work coul= d be > a (smaller) set of suggestion(s) for which signal(s) to add, so that those > who want to have concrete proposals to evaluate can do so. > > Cheers, > > Brian > > [...] >>>> >>>> -----Original Message----- From: alexandre.ferrieux@orange.com >>>> [alexandre.ferrieux@orange.com] Received: Saturday, 10 Feb 2018, >>>> 12:34PM To: quic@ietf.org [quic@ietf.org] Subject: Measurement bit(s) >>>> or not >>>> >>>> On 07/02/2018 14:34, Brian Trammell (IETF) wrote: >>>>> hi Jana, >>>>> >>>>>> 3. Some sequencing information -- a few bits of the packet number >>>>>> perhaps -- should be revealed (for monitoring. Number of bits >>>>>> TBD.) >>>>> >>>>> This is the crux of the argument. On one side we have the risk of >>>>> misuse and ossification (well, not ossification -- these bits are >>>>> *meant* for the path -- rather the risk that we'll figure out later >>>>> that we specified the wrong thing), on the other side we have the >>>>> loss of visibility into how QUIC traffic interacts with the network >>>>> as compared to TCP, with a side question of whether or not this >>>>> visibility is really the transport layer's problem despite the >>>>> evolution the practice of diagnostics and troubleshooting using TCP >>>>> information. >>>>> >>>>> If we can come to agreement on this question, everything else falls >>>>> into place. I have my arguments here, but as you said, this subthread >>>>> is not the place for them. :) >>>> >>>> The crux indeed. So what about settling it first ? >>>> >>>> With the troubleshooting hat, I can only stress the need for >>>> measurement bits, for the benefit of everybody, since s**t happens, >>>> networks are imperfect, and nifty encapsulations-with-seqnum will >>>> simply not be where you need them. >>>> >>>> Now to the exact nature of these measurement bits: >>>> >>>> Thanks to the detailed exchanges on this thread, it is by now clear >>>> that a simple gapless counter, even nonzero-based and XORed, is not >>>> acceptable. The 4-bit SSN comes pretty close but is not enough when >>>> things go really wrong (and they will - and that's where we need the >>>> tool). >>>> >>>> Then Kazuho's square signal and Mikkel's Pi (or any other consensual >>>> self-synchronizing sequence) ramification came up. They are both >>>> appealing for their elegance and low complexity on QUIC endpoints. >>>> Beyond their quirks acknowledged here, here are a few considerations >>>> for troubleshooting: >>>> >>>> (1) Since reordering is less of a concern to QUIC than to TCP, it >>>> becomes a secondary goal. This is nice, because the square doesn't see >>>> it, and the self-synchronizing sequence will only tolerate a mild one, >>>> and never see its detail like cycle length etc. >>>> >>>> (2) There's of course a huge difference between them in complexity for >>>> the midpoint: square is trivial, Pi is hefty. >>>> >>>> Given these, a benevolent, troubleshooting-minded passive midpoint will >>>> clearly vote for the square. Now the obvious question is: is this >>>> acceptable, or deemed too easy for a Murphy, Inc. active middlebox to >>>> see upstream losses and benevolently wreak havoc by delaying packets ? >>>> >>>> ______________________________________________________________________= ___________________________________________________ ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Feb 12 04:35:10 2018 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 AA6BC124E15 for ; Mon, 12 Feb 2018 04:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ZXSxjxW9b8gk for ; Mon, 12 Feb 2018 04:35:07 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA4121204DA for ; Mon, 12 Feb 2018 04:35:06 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id B5CB9340E47; Mon, 12 Feb 2018 13:35:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/6597.24373); Mon, 12 Feb 2018 13:35:03 +0100 (CET) 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; Mon, 12 Feb 2018 13:35:03 +0100 (CET) Received: from [195.176.111.11] (account ietf@trammell.ch HELO public-docking-cx-3449.ethz.ch) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 45100869; Mon, 12 Feb 2018 13:35:03 +0100 From: "Brian Trammell (IETF)" Message-Id: <5E9E3102-2F45-46D5-A5C2-7D63085F88F5@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_B57F3B4C-0CD6-4D4C-A114-F3B5ED1F4925"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Measurement bit(s) or not Date: Mon, 12 Feb 2018 13:35:02 +0100 In-Reply-To: <27669_1518436598_5A8180F6_27669_174_1_5A8180F8.6020705@orange.com> Cc: "quic@ietf.org" To: Alexandre Ferrieux References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> <19F415EA-DC06-4FEE-8AFA-8A6EBEBB9AFA@trammell.ch> <27669_1518436598_5A8180F6_27669_174_1_5A8180F8.6020705@orange.com> 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, 12 Feb 2018 12:35:09 -0000 --Apple-Mail=_B57F3B4C-0CD6-4D4C-A114-F3B5ED1F4925 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Alexandre, > On 12 Feb 2018, at 12:56, alexandre.ferrieux@orange.com wrote: >=20 > Hi Brian, >=20 > We're clearly in violent agreement about both the potential to make = intelligent > use of this measurement nibble, and the desirability of *some* = troubleshooting > helper. Thanks for proposing to include this discussion in the spin = bit table. >=20 > As it turns out, we do have concrete illustrations to show there, on = real > networks and long distances. But beyond that, I'd like to "probe" this = group for > a possible veto before digging further: while I have no doubt about an = eventual > consensus among us "troubleshooters", I'm more worried by the other = side of the board: people primarily concerned about ossification and = linkability, to whom > network debugging is at best a secondary goal. >=20 > More precisely, as you accurately described, the position of the = cursor of both > tradeoffs may display a kind of threshold for acceptability by them : >=20 > - endpoint vs midpoint complexity: if the tool is too easy on the = midpoint, > active Murphies will come in ; at kind of entry barrier should be set = -- how high ? >=20 > - fidelity: the coarser, or the more delayed, the better, since it = precludes any > real-time feedback loop like active Murphies do ; what is the minimum > degradation that is needed ? >=20 While our experience with TCP here provides ample, loud warning about = the dangers of letting the middle know too much, IMO these worries are a = little misplaced with QUIC. Two important things to note: (1) A middlebox that speaks TCP can modify the header without breaking = the connection, and it knows which ACK belongs with which packet. It has = a wide variety of actions available to it: it can delay or drop packets; = coalesce, delay, or even falsify ACKs; manipulate seq/ack and timestamps = (though I don't know of any that do the latter), and so on. A middlebox = that understands QUIC can only delay or drop a packet. (2) Nobody will buy (or build and deploy) middlebox that can't even = pretend to solve a problem. If we've designed QUIC such that selective = drop or delay of packets based only on path-observable latency and loss = will improve performance for anyone, we have done something horribly = wrong. In general, the cost of deriving a measurement from a signal should be = paid by the user of the measurement, not the endpoint generating the = signal (principle 3 from Principles for Measurability in Protocol Design = (https://arxiv.org/pdf/1612.02902.pdf) if you're playing along at home = :). This isn't meant to make it harder to mess something up, rather to = make it so easy to implement the signal at the endpoint that doing so = isn't seen as a negative tradeoff. Fidelity is a hard one. Some troubleshooting tasks turn on the pattern = of losses, which means you really want to know *which* packet was lost. = Again, knowing which packet was lost doesn't give a QUIC-understanding = measurement box as much freedom to get things wrong as the equivalent = TCP box. Cheers, Brian >=20 >=20 > On 12/02/2018 10:20, Brian Trammell (IETF) wrote: >> hi Mikkel, Igor, Alexandre, all, >>=20 >> Engineering is fun, but let's step back a bit. :) >>=20 >> It looks like we're exploring a space of proposals that have = different >> tradeoffs for the patterns of loss and reordering they can easily = make >> visible, tradeoffs for sender (endpoint) versus observer (midpoint) >> complexity, and tradeoffs for fidelity versus overhead. >>=20 >> In any case, it seems like it is possible to design a signal that = would be a >> vast improvement (from the measurement utility standpoint) over no = signal and >> no discernible pattern in the packet number that will fit in bits = scavenged >> from the Type field of the short header, i.e., the bandwidth overhead = will be >> *zero*, because otherwise in an encrypted-PN world we just have to = grease >> those bits anyway. >>=20 >> Back to Alexandre's question: >>=20 >> Do we want to do this? >>=20 >> Rephrased: Is the passive measurability of loss, reordering (and, if = we >> consider the spin bit as one of the measurement bits, latency) of = QUIC >> important to us, or do we decide we can live with the negative = pressure a >> complete loss of visibility and an vast increase in diagnostic = complexity >> will place on deployment? >>=20 >> Note, of course, that all the proposals we have so far represent a = decrease >> in visibility and an increase in complexity of measurement compared = to >> passive measurement of TCP. New tools will have to be developed. But = the loss >> of visibility is minimal compared to blackout, and the deployability = and >> feasibility of all of these is far, far better than an = SSLKEYLOGFILE-based >> debugging approach, especially in the interdomain case. >>=20 >> I've heard at least one dismissal of this whole space as being too = abstract >> to take seriously. (I'm not concerned, but maybe I've been staring at = network >> measurement both passive and active for too long to know what's = intuitive >> anymore.) Let me then suggest a way forward: >>=20 >> I've announced a table at the London hackathon for "Transport = Measurability" >> (see https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon), = which we >> intend to set up in the vicinity of QUIC. This was originally = intended as the >> "Spin Bit" table, and we (from ETH) will be there working on = scalable, >> open-source passive measurement tools both for the spin bit as well = as for >> the current TCP TSOPT and SEQ/ACK methodologies (as a basis of = comparison, >> mainly; at least in the case of the spin bit we so far believe the = explicit >> signal=C5=93 to have superior usability compared to current TCP = measurement). I >> suggest we expand the scope of table to hack on various signals for = loss and >> reordering, and to compare their complexity and fidelity against the = loss and >> reordering patterns we want visibility into. One output of this work = could be >> a (smaller) set of suggestion(s) for which signal(s) to add, so that = those >> who want to have concrete proposals to evaluate can do so. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> [...] >=20 >=20 >=20 >=20 >=20 >>>>>=20 >>>>> -----Original Message----- From: alexandre.ferrieux@orange.com >>>>> [alexandre.ferrieux@orange.com] Received: Saturday, 10 Feb 2018, >>>>> 12:34PM To: quic@ietf.org [quic@ietf.org] Subject: Measurement = bit(s) >>>>> or not >>>>>=20 >>>>> On 07/02/2018 14:34, Brian Trammell (IETF) wrote: >>>>>> hi Jana, >>>>>>=20 >>>>>>> 3. Some sequencing information -- a few bits of the packet = number >>>>>>> perhaps -- should be revealed (for monitoring. Number of bits >>>>>>> TBD.) >>>>>>=20 >>>>>> This is the crux of the argument. On one side we have the risk of >>>>>> misuse and ossification (well, not ossification -- these bits are >>>>>> *meant* for the path -- rather the risk that we'll figure out = later >>>>>> that we specified the wrong thing), on the other side we have the >>>>>> loss of visibility into how QUIC traffic interacts with the = network >>>>>> as compared to TCP, with a side question of whether or not this >>>>>> visibility is really the transport layer's problem despite the >>>>>> evolution the practice of diagnostics and troubleshooting using = TCP >>>>>> information. >>>>>>=20 >>>>>> If we can come to agreement on this question, everything else = falls >>>>>> into place. I have my arguments here, but as you said, this = subthread >>>>>> is not the place for them. :) >>>>>=20 >>>>> The crux indeed. So what about settling it first ? >>>>>=20 >>>>> With the troubleshooting hat, I can only stress the need for >>>>> measurement bits, for the benefit of everybody, since s**t = happens, >>>>> networks are imperfect, and nifty encapsulations-with-seqnum will >>>>> simply not be where you need them. >>>>>=20 >>>>> Now to the exact nature of these measurement bits: >>>>>=20 >>>>> Thanks to the detailed exchanges on this thread, it is by now = clear >>>>> that a simple gapless counter, even nonzero-based and XORed, is = not >>>>> acceptable. The 4-bit SSN comes pretty close but is not enough = when >>>>> things go really wrong (and they will - and that's where we need = the >>>>> tool). >>>>>=20 >>>>> Then Kazuho's square signal and Mikkel's Pi (or any other = consensual >>>>> self-synchronizing sequence) ramification came up. They are both >>>>> appealing for their elegance and low complexity on QUIC endpoints. >>>>> Beyond their quirks acknowledged here, here are a few = considerations >>>>> for troubleshooting: >>>>>=20 >>>>> (1) Since reordering is less of a concern to QUIC than to TCP, it >>>>> becomes a secondary goal. This is nice, because the square doesn't = see >>>>> it, and the self-synchronizing sequence will only tolerate a mild = one, >>>>> and never see its detail like cycle length etc. >>>>>=20 >>>>> (2) There's of course a huge difference between them in complexity = for >>>>> the midpoint: square is trivial, Pi is hefty. >>>>>=20 >>>>> Given these, a benevolent, troubleshooting-minded passive midpoint = will >>>>> clearly vote for the square. Now the obvious question is: is this >>>>> acceptable, or deemed too easy for a Murphy, Inc. active middlebox = to >>>>> see upstream losses and benevolently wreak havoc by delaying = packets ? >>>>>=20 >>>>> = __________________________________________________________________________= _______________________________________________ >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 --Apple-Mail=_B57F3B4C-0CD6-4D4C-A114-F3B5ED1F4925 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlqBifYACgkQihK3vwvq RqMrng//b7DbpI+patl7eOg6NNmSlA56CMkAM6ATpSmf3kDXaXTcoZfE3UFx+Ete E/NJCORR5v7imnZm/Nis/gA0dPf6t52eB3hG3sIqyhAa7JOtJgSExVVdVvBgfJR+ el+XMWnL0cPpE8IrlvjrWTwfSs1zZnAngCTL2hM1dPhhhBICp2cNUVOWgP5GADBX ScDoLIEfo/TLCGQHa3XFLUUfEojev7foKLkyQZ2k7mRPUd/lNKagQYJEuHmLhV4t TJDkzsciG0zTK1lyTdJ9PzZP7B8rlJdSSn6RLR0QaVqVXpAdmIPOq+1TCiwKdGeD iMNx9YtcPhWzsXLcWYGO3tOHm528R4lIgM2NzcS6thHAdpamtXYGOcyVEL48NK34 mNKOwVvDhB/ccZyOnh64sUKuPl/4iO62Y97GOHSvgF09us0XXC9+kkhS9dJpxa4j Fc/qb49OtmowrQZrzLhpEDGMgAYWhpXDx//1v2JSieKWOVz4z4ozzEoAA6lhS/sU gtSvZVuOXJEtpGSOoeCRGeq/L40/r7mspahQtIoJCFjRX+5+inNaavW2IS6+G2iU fLCIwgkbRwpyPvhFojomPnGonOHe0g0h9fcbkoUhdG+El0SlCiXUAk2QgsxWU7Z+ D7VcZd/+7H7CAT7lUZ9QmYqUmWKaL2uz7yZSKHE026KmQfRAGW0= =q2e0 -----END PGP SIGNATURE----- --Apple-Mail=_B57F3B4C-0CD6-4D4C-A114-F3B5ED1F4925-- From nobody Mon Feb 12 06:00:58 2018 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 5D594127873 for ; Mon, 12 Feb 2018 06:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, T_RP_MATCHES_RCVD=-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 Xoi_yVnIPGwn for ; Mon, 12 Feb 2018 06:00:53 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 7C777126BFD for ; Mon, 12 Feb 2018 06:00:53 -0800 (PST) Received: from [10.9.35.88] (unknown [185.69.144.152]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 83DA41B00067; Mon, 12 Feb 2018 14:00:03 +0000 (GMT) Content-Type: multipart/alternative; boundary=Apple-Mail-84123B3A-4B2E-4B1D-8D62-9953CC610CB8 Mime-Version: 1.0 (1.0) Subject: Re: Measurement bit(s) or not From: "Gorry (erg)" X-Mailer: iPhone Mail (15C202) In-Reply-To: <27669_1518436598_5A8180F6_27669_174_1_5A8180F8.6020705@orange.com> Date: Mon, 12 Feb 2018 15:00:02 +0100 Cc: "Brian Trammell (IETF)" , "quic@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: References: <1817_1518284090_5A7F2D3A_1817_79_1_5A7F2D3E.4050806@orange.com> <19F415EA-DC06-4FEE-8AFA-8A6EBEBB9AFA@trammell.ch> <27669_1518436598_5A8180F6_27669_174_1_5A8180F8.6020705@orange.com> To: Alexandre Ferrieux 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, 12 Feb 2018 14:00:57 -0000 --Apple-Mail-84123B3A-4B2E-4B1D-8D62-9953CC610CB8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Since this is now discussing issues that relate to any new protocol at the t= ransport layer, I would be interested in understanding the impacts on curren= t practice. I have written: draft-fairhurst-tsvwg-transport-encrypt-06 To explore some of these topics across a wider front than just QUIC. Thought= s welcome, Gorry=20 > On 12 Feb 2018, at 12:56, wrote: >=20 > Hi Brian, >=20 > We're clearly in violent agreement about both the potential to make intell= igent > use of this measurement nibble, and the desirability of *some* troubleshoo= ting > helper. Thanks for proposing to include this discussion in the spin bit ta= ble. >=20 > As it turns out, we do have concrete illustrations to show there, on real > networks and long distances. But beyond that, I'd like to "probe" this gro= up for > a possible veto before digging further: while I have no doubt about an eve= ntual > consensus among us "troubleshooters", I'm more worried by the other side o= f the board: people primarily concerned about ossification and linkability, t= o whom > network debugging is at best a secondary goal. >=20 > More precisely, as you accurately described, the position of the cursor of= both > tradeoffs may display a kind of threshold for acceptability by them : >=20 > - endpoint vs midpoint complexity: if the tool is too easy on the midpoint= , > active Murphies will come in ; at kind of entry barrier should be set -- h= ow high ? >=20 > - fidelity: the coarser, or the more delayed, the better, since it preclud= es any > real-time feedback loop like active Murphies do ; what is the minimum > degradation that is needed ? >=20 >=20 >=20 >=20 >> On 12/02/2018 10:20, Brian Trammell (IETF) wrote: >> hi Mikkel, Igor, Alexandre, all, >>=20 >> Engineering is fun, but let's step back a bit. :) >>=20 >> It looks like we're exploring a space of proposals that have different >> tradeoffs for the patterns of loss and reordering they can easily make >> visible, tradeoffs for sender (endpoint) versus observer (midpoint) >> complexity, and tradeoffs for fidelity versus overhead. >>=20 >> In any case, it seems like it is possible to design a signal that would b= e a >> vast improvement (from the measurement utility standpoint) over no signal= and >> no discernible pattern in the packet number that will fit in bits scaveng= ed >> from the Type field of the short header, i.e., the bandwidth overhead wil= l be >> *zero*, because otherwise in an encrypted-PN world we just have to grease= >> those bits anyway. >>=20 >> Back to Alexandre's question: >>=20 >> Do we want to do this? >>=20 >> Rephrased: Is the passive measurability of loss, reordering (and, if we >> consider the spin bit as one of the measurement bits, latency) of QUIC >> important to us, or do we decide we can live with the negative pressure a= >> complete loss of visibility and an vast increase in diagnostic complexity= >> will place on deployment? >>=20 >> Note, of course, that all the proposals we have so far represent a decrea= se >> in visibility and an increase in complexity of measurement compared to >> passive measurement of TCP. New tools will have to be developed. But the l= oss >> of visibility is minimal compared to blackout, and the deployability and >> feasibility of all of these is far, far better than an SSLKEYLOGFILE-base= d >> debugging approach, especially in the interdomain case. >>=20 >> I've heard at least one dismissal of this whole space as being too abstra= ct >> to take seriously. (I'm not concerned, but maybe I've been staring at net= work >> measurement both passive and active for too long to know what's intuitive= >> anymore.) Let me then suggest a way forward: >>=20 >> I've announced a table at the London hackathon for "Transport Measurabili= ty" >> (see https://trac.ietf.org/trac/ietf/meeting/wiki/101hackathon), which we= >> intend to set up in the vicinity of QUIC. This was originally intended as= the >> "Spin Bit" table, and we (from ETH) will be there working on scalable, >> open-source passive measurement tools both for the spin bit as well as fo= r >> the current TCP TSOPT and SEQ/ACK methodologies (as a basis of comparison= , >> mainly; at least in the case of the spin bit we so far believe the explic= it >> signal=C5=93 to have superior usability compared to current TCP measureme= nt). I >> suggest we expand the scope of table to hack on various signals for loss a= nd >> reordering, and to compare their complexity and fidelity against the loss= and >> reordering patterns we want visibility into. One output of this work coul= d be >> a (smaller) set of suggestion(s) for which signal(s) to add, so that thos= e >> who want to have concrete proposals to evaluate can do so. >>=20 >> Cheers, >>=20 >> Brian >>=20 >> [...] >=20 >=20 >=20 >=20 >=20 >>>>>=20 >>>>> -----Original Message----- From: alexandre.ferrieux@orange.com >>>>> [alexandre.ferrieux@orange.com] Received: Saturday, 10 Feb 2018, >>>>> 12:34PM To: quic@ietf.org [quic@ietf.org] Subject: Measurement bit(s) >>>>> or not >>>>>=20 >>>>>> On 07/02/2018 14:34, Brian Trammell (IETF) wrote: >>>>>> hi Jana, >>>>>>=20 >>>>>>> 3. Some sequencing information -- a few bits of the packet number >>>>>>> perhaps -- should be revealed (for monitoring. Number of bits >>>>>>> TBD.) >>>>>>=20 >>>>>> This is the crux of the argument. On one side we have the risk of >>>>>> misuse and ossification (well, not ossification -- these bits are >>>>>> *meant* for the path -- rather the risk that we'll figure out later >>>>>> that we specified the wrong thing), on the other side we have the >>>>>> loss of visibility into how QUIC traffic interacts with the network >>>>>> as compared to TCP, with a side question of whether or not this >>>>>> visibility is really the transport layer's problem despite the >>>>>> evolution the practice of diagnostics and troubleshooting using TCP >>>>>> information. >>>>>>=20 >>>>>> If we can come to agreement on this question, everything else falls >>>>>> into place. I have my arguments here, but as you said, this subthread= >>>>>> is not the place for them. :) >>>>>=20 >>>>> The crux indeed. So what about settling it first ? >>>>>=20 >>>>> With the troubleshooting hat, I can only stress the need for >>>>> measurement bits, for the benefit of everybody, since s**t happens, >>>>> networks are imperfect, and nifty encapsulations-with-seqnum will >>>>> simply not be where you need them. >>>>>=20 >>>>> Now to the exact nature of these measurement bits: >>>>>=20 >>>>> Thanks to the detailed exchanges on this thread, it is by now clear >>>>> that a simple gapless counter, even nonzero-based and XORed, is not >>>>> acceptable. The 4-bit SSN comes pretty close but is not enough when >>>>> things go really wrong (and they will - and that's where we need the >>>>> tool). >>>>>=20 >>>>> Then Kazuho's square signal and Mikkel's Pi (or any other consensual >>>>> self-synchronizing sequence) ramification came up. They are both >>>>> appealing for their elegance and low complexity on QUIC endpoints. >>>>> Beyond their quirks acknowledged here, here are a few considerations >>>>> for troubleshooting: >>>>>=20 >>>>> (1) Since reordering is less of a concern to QUIC than to TCP, it >>>>> becomes a secondary goal. This is nice, because the square doesn't see= >>>>> it, and the self-synchronizing sequence will only tolerate a mild one,= >>>>> and never see its detail like cycle length etc. >>>>>=20 >>>>> (2) There's of course a huge difference between them in complexity for= >>>>> the midpoint: square is trivial, Pi is hefty. >>>>>=20 >>>>> Given these, a benevolent, troubleshooting-minded passive midpoint wil= l >>>>> clearly vote for the square. Now the obvious question is: is this >>>>> acceptable, or deemed too easy for a Murphy, Inc. active middlebox to >>>>> see upstream losses and benevolently wreak havoc by delaying packets ?= >>>>>=20 >>>>> ______________________________________________________________________= ___________________________________________________ >=20 >=20 > __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations confide= ntielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez rec= u ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages e= lectroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou= falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged in= formation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and del= ete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been= modified, changed or falsified. > Thank you. --Apple-Mail-84123B3A-4B2E-4B1D-8D62-9953CC610CB8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Since this i= s now discussing issues that relate to any new protocol at the transport lay= er, I would be interested in understanding the impacts on current practice. I= have written:

draft-fairhurst-tsvwg-transport-encrypt-06


=
To explore some of these topics= across a wider front than just QUIC. Thoughts welcome,

Gorry 
Hi Brian,

We're clearly i= n violent agreement about both the potential to make intelligent
<= span>use of this measurement nibble, and the desirability of *some* troubles= hooting
helper. Thanks for proposing to include this discuss= ion in the spin bit table.

As it turns out,= we do have concrete illustrations to show there, on real
ne= tworks and long distances. But beyond that, I'd like to "probe" this group f= or
a possible veto before digging further: while I have no d= oubt about an eventual
consensus among us "troubleshooters",= I'm more worried by the other side of the board: people primarily concerned= about ossification and linkability, to whom
network debuggi= ng is at best a secondary goal.

More precis= ely, as you accurately described, the position of the cursor of both<= br>tradeoffs may display a kind of threshold for acceptability by them= :

- endpoint vs midpoint complexity: if th= e tool is too easy on the midpoint,
active Murphies will com= e in ; at kind of entry barrier should be set -- how high ?
=
- fidelity: the coarser, or the more delayed, the better, s= ince it precludes any
real-time feedback loop like active Mu= rphies do ; what is the minimum
degradation that is needed ?=



<= br>On 12/02/2018 10:20, Brian Trammell (IETF) wrote:
hi Mikkel, Igor, Alexandre, all,

Engineering is fun, but let's step back a bit. :)

It looks like we're exploring a space of proposals= that have different
= tradeoffs for the patterns of loss and reordering they can easily make
visible, tradeoffs for sen= der (endpoint) versus observer (midpoint)
complexity, and tradeoffs for fidelity versus overhead.=

In any case, it seems like it is possibl= e to design a signal that would be a
vast improvement (from the measurement utility standpoint) o= ver no signal and
no d= iscernible pattern in the packet number that will fit in bits scavenged
from the Type field of th= e short header, i.e., the bandwidth overhead will be
=
*zero*, because otherwise in an encrypted-PN= world we just have to grease
those bits anyway.

Back to Alexa= ndre's question:

Do we want to do this?

Rephrased: Is the passive measurability of= loss, reordering (and, if we
consider the spin bit as one of the measurement bits, latency) of Q= UIC
important to us, o= r do we decide we can live with the negative pressure a
complete loss of visibility and an vast i= ncrease in diagnostic complexity
will place on deployment?

Not= e, of course, that all the proposals we have so far represent a decrease
in visibility and an inc= rease in complexity of measurement compared to
passive measurement of TCP. New tools will have to= be developed. But the loss
of visibility is minimal compared to blackout, and the deployability a= nd
feasibility of all= of these is far, far better than an SSLKEYLOGFILE-based
debugging approach, especially in the in= terdomain case.

I've heard at least one d= ismissal of this whole space as being too abstract
to take seriously. (I'm not concerned, but may= be I've been staring at network
measurement both passive and active for too long to know what's i= ntuitive
anymore.) Le= t me then suggest a way forward:

I've ann= ounced a table at the London hackathon for "Transport Measurability"<= br>
(see https://trac.ietf.org/trac/ie= tf/meeting/wiki/101hackathon), which we
intend to set up in the vicinity of QUIC. This was or= iginally intended as the
"Spin Bit" table, and we (from ETH) will be there working on scalable,
open-source passive me= asurement tools both for the spin bit as well as for
=
the current TCP TSOPT and SEQ/ACK methodolog= ies (as a basis of comparison,
mainly; at least in the case of the spin bit we so far believe the= explicit
signal=C5=93= to have superior usability compared to current TCP measurement). I
suggest we expand the scope o= f table to hack on various signals for loss and
reordering, and to compare their complexity and f= idelity against the loss and
reordering patterns we want visibility into. One output of this work= could be
a (smaller)= set of suggestion(s) for which signal(s) to add, so that those
who want to have concrete proposa= ls to evaluate can do so.
<= span>
Cheers,<= br>

Brian

[...]






=
-----Original Message----- From: alexandre.ferrieux@orange.com
[alexandre.ferrieux@orange.com] Received: Saturday, 10 Feb 2018,
12:34PM To: quic@ietf.org [q= uic@ietf.org] Subject: Measurement bit(s)
or not

=
On 07/02/2018 14:34, Brian Trammell (IETF)= wrote:
hi Jana,

3. Some sequencing in= formation -- a few bits of the packet number
perhaps -- s= hould be revealed (for monitoring. Number of bits
TBD.)=
=

<= blockquote type=3D"cite">
This is the crux of= the argument. On one side we have the risk of
misuse and ossification (well, not ossificatio= n -- these bits are
*meant* for the path -- rather the risk that we'll figure out later
that we specified the w= rong thing), on the other side we have the
loss of visibility into how QUIC traffic interacts= with the network
as compared to TCP, with a side question of whether or not this
<= /blockquote>
visibility is really the tran= sport layer's problem despite the
evolution the practice of diagnostics and troubleshooting using= TCP
information.=
=

If we can come to agreement on t= his question, everything else falls
into place. I have my arguments here, but as you said, th= is subthread
<= /blockquote>
is no= t the place for them. :)
=

The crux indeed. So what about settling it first ?

With the troubleshooting hat, I can only stress the need f= or
measurement bits, for the benefit of everybody, since= s**t happens,
networks are imperfect, and nifty encapsu= lations-with-seqnum will
simply not be where you need th= em.

Now to the exact nature of thes= e measurement bits:

=
Thanks to the de= tailed exchanges on this thread, it is by now clear
<= /blockquote>
that a= simple gapless counter, even nonzero-based and XORed, is not
= acceptable. The 4-bit SSN comes pretty close but is not enough when
things go really wrong (and they will - and that's where w= e need the
<= blockquote type=3D"cite">tool).
=

Then Kazuho's square signal and Mikkel's Pi (or any other consensual
self-synchronizing sequence) ramification came up. They are bot= h
appealing for their elegance and low complexity on QUIC= endpoints.
=
Beyond their quirks acknowledged here, here a= re a few considerations
for troubleshooting:
<= /blockquote>

(1) Since reordering is less of a concern to Q= UIC than to TCP, it
becomes a secondary goal. This is nic= e, because the square doesn't see
it, and the self-synch= ronizing sequence will only tolerate a mild one,
and nev= er see its detail like cycle length etc.

= (2) There's of course a huge difference between them in complexity for=
the midpoint: square is trivial, Pi is hefty.

=
Given these, a benevolent, troubleshooting-m= inded passive midpoint will
clearly vote for the square.= Now the obvious question is: is this
=
acceptable, or dee= med too easy for a Murphy, Inc. active middlebox to
<= /blockquote>
see u= pstream losses and benevolently wreak havoc by delaying packets ?
=

<= blockquote type=3D"cite">_____________________________________________= ____________________________________________________________________________=
=

_________________________________________________= ________________________________________________________________________

Ce message et ses pieces jointes peuvent conte= nir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vou= s avez recu ce message par erreur, veuillez le signaler
a l'= expediteur et le detruire ainsi que les pieces jointes. Les messages electro= niques etant susceptibles d'alteration,
Orange decline toute= responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain co= nfidential or privileged information that may be protected by law;they should not be distributed, used or copied without authorisation.=
If you have received this email in error, please notify the= sender and delete this message and its attachments.
As emai= ls may be altered, Orange is not liable for messages that have been modified= , changed or falsified.
Thank you.
= --Apple-Mail-84123B3A-4B2E-4B1D-8D62-9953CC610CB8-- From nobody Mon Feb 12 07:26:30 2018 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 4941312D7E3 for ; Mon, 12 Feb 2018 07:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 SvGiT99NmoCy for ; Mon, 12 Feb 2018 07:26:26 -0800 (PST) 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 6D2BE12D0C3 for ; Mon, 12 Feb 2018 07:26:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zg8dr2TFwz15JYh; Mon, 12 Feb 2018 16:26:24 +0100 (CET) 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 5VNIluRSjmLe; Mon, 12 Feb 2018 16:26:22 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (i577BCE78.versanet.de [87.123.206.120]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 12 Feb 2018 16:26:22 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: ECN in QUIC connection migration From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 12 Feb 2018 16:26:21 +0100 Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" , "ekinnear@apple.com" , "Lubashev, Igor" , Ian Swett , QUIC WG , Christian Huitema Content-Transfer-Encoding: quoted-printable Message-Id: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> To: Ingemar Johansson S X-Mailer: Apple Mail (2.3445.5.20) 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, 12 Feb 2018 15:26:29 -0000 Hi Ingemar, two points.=20 I think it would be good to be as explicit as possible here, therefore I = would prefer if an endpoint that knows that it can not access the ECN IP = bits indicates this directly in the handshake. In this case no further = testing is needed. Further, the path testing itself is independent of QUIC and can be used = for any protocol. Moreover, it=E2=80=99s more complicated than just = testing ECT. I guess the general advice here is to remember which = codepoints were send and compare this to the feedback provided. If = discrepancies are observed that indicate that a middlebox has changed = these bits, all packets should be marked as no-ECT (while additional = testing MAY be performed at any later point in time). However, how = exactly this testing should look like, should not be specified in this = doc (but more generally). Mirja > Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S = : >=20 > Hi Eric, Koen + others > =20 > Thanks for the comments and the update. A question to the rest of the = audience, does the presented text explain sufficiently enough how ECN = works with connection migration ? > = https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-con= nection-migration > =20 > =20 > /Ingemar > =20 > =20 > From: De Schepper, Koen (Nokia - BE/Antwerp) = [mailto:koen.de_schepper@nokia-bell-labs.com]=20 > Sent: den 2 februari 2018 15:44 > To: ekinnear@apple.com; Ingemar Johansson S = > Cc: QUIC WG ; Ian Swett ; = Lubashev, Igor ; Christian Huitema = > Subject: RE: ECN in QUIC connection migration > =20 > Hi Ingemar, > =20 > I also read again through the document, and had following comments: > =20 > I replaced: > =E2=80=9CThe ACK_ECN frame is used to convey ACKs when the ECN = capability exchange concludes that ECN should be used for the given = connection.=E2=80=9D > Originally it sounds as if the counters are not echoed anymore if the = ECN capability check fails. I assume this was not the intention, but if = it is: First, we don=E2=80=99t have a protocol or decision point defined = when that condition is met (sender should let the receiver know in the = next packet), and second, I would always send the echo, as we might = =E2=80=9Ctry again later (with another ECT?)=E2=80=9D, or might decide = to use the ECN bits differently later. > =20 > I also changed the text around the connection migration, I think = before Eric reviewed it. I made it such that every new path creates a = new connection state with an initialized congestion control state and = ECN counters (at least ECN counters reset to 0s). Not sure if this = matches with the other sections in the QUIC draft. > =20 > I also had the thought whether it was really needed to have the 2 = cases. I agree we should simplify, by just starting over and doing the = check unconditionally whether it was successful or not in a previous = path. > =20 > Regards, > Koen. > =20 > From: ekinnear@apple.com [mailto:ekinnear@apple.com]=20 > Sent: Friday, February 2, 2018 12:02 AM > To: Ingemar Johansson S > Cc: QUIC WG ; Ian Swett ; = Lubashev, Igor ; Christian Huitema = ; De Schepper, Koen (Nokia - BE/Antwerp) = > Subject: Re: ECN in QUIC connection migration > =20 > Hi Ingemar,=20 > =20 > This generally looks good to me! > A few questions and observations:=20 > =20 > There are two unique cases: >=20 > =E2=80=A2 ECN capability check successful at initial = connection setup > =E2=80=A2 ECN capability check failed at initial = connection setup > =20 > Are these actually any different in terms of action taken by an = endpoint? > It seems like on the new network path the endpoint would go through = the same process of: (a) verify ECN capability and if successful to = whatever degree then (b) run the rest of the ECN machinery as = appropriate. > =20 > In other words, as long as you allow people to start using ECN upon = migration (in other words, to allow starting it after the initial = connection establishment), then the specifics for ECN with migration is = essentially one statement, which is =E2=80=9Cdo the ECN process on each = new network path that you use=E2=80=9D.=20 > =20 > Connection migration has impact on the number of reported CE marked = packets. A new connection state with new congestion control state and = ECN counters is instantiated at the sender and receiver. The ECN = counters MUST start from zero again. > =20 > This seems fine to me, it=E2=80=99s inline with the rest of the = congestion control/loss recovery state that also needs to be reset for = the new path.=20 > =20 > Given that each migration requires at least one exchange of packets at = the beginning (at the very least for address validation from the side of = the endpoint that didn=E2=80=99t migrate), it seems like that=E2=80=99s = an excellent moment to mark the packets and perform the ECN capability = detection. Those packets are also likely padded, etc. similar to initial = packets since they=E2=80=99re on a previously unused network path.=20 > =20 > I think the current proposed requirement of just using the =E2=80=9Cfirs= t=E2=80=9D packets and marking those is sufficient (and good to avoid = any requirement as to which frames are contained in those packets), = since we are always exchanging packets in both directions immediately = after migration.=20 > =20 > This has the added benefit such that any endpoint =E2=80=9Cprobing=E2=80= =9D possible network paths could include the bits necessary to detect = ECN capability on the path being probed, so it could even know before = migrating whether or not it would be able to use ECN on that new path.=20= > =20 > Thanks, > Eric > =20 > =20 > =20 >=20 > On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S = wrote: > =20 > Hi > I have written up different aspects of connection migration and how it = plays with ECN. > = https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-con= nection-migration > =20 > A caveat.. I am a bit unsure about the definition of connection = migration . My interpretation is that a client moves to a new IP address = due to e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is a = new connection instantiated at a connection migration ?=20 > =20 > /Ingemar > =20 > =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 > =20 > Ericsson Research > Network Protocols & E2E Performance > Labratoriegr=C3=A4nd 11 > 971 28, Lule=C3=A5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > =20 > You can't start a fire > Worrying 'bout your little world falling apart > Bruce Springsteen > =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 From nobody Mon Feb 12 07:42:12 2018 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 4650512D82E for ; Mon, 12 Feb 2018 07:42:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 lS2OIFS_JyG5 for ; Mon, 12 Feb 2018 07:42:07 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 39C6712D82F for ; Mon, 12 Feb 2018 07:42:07 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id p188so17678483ioe.12 for ; Mon, 12 Feb 2018 07:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=hETOOrRWhgoKHE4352QAwqFs+51OfSM6DjcjKRz9jgI=; b=SPihQTjpSq2jACfKQOc5mDHiv8MGIIZ4ztNLa4CFq4d2lmiExzul2NHEtNa900XHvt AHhQgtecgSeM0csv9VPKLkfiTClrw+MduW6+04c31fAwD+vkyuBsAsqWG6uIRto2Dt98 hH8mTB7ZOGj534Tm1ubE7YUewFBCkSiuSpfHjsFArLgiIuvX+u18GOgg0JqBEXetNokx S24Zj4U+Rq4r7BEMDbkFtwL8ho+Q++j9P1su5dJDMoe43VvdJpaMspttqOl2akeENQBY Ap/+DA8wFknEL90BAyy2zf6CcZ4hhiBnigOTrjBQ1IBpjTQfOK/XdLUVqkhLOETa18AD ReJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=hETOOrRWhgoKHE4352QAwqFs+51OfSM6DjcjKRz9jgI=; b=bcY2v2xvitxiyBCpjSLYR2p73U+PtgKKPpNMQCo9SFZu8xiQi01bMbvwW+31G08nu3 1yAAw9WH2VRATDOlxgEXpkTPKzpz6lPBvJKNRGJGhP8eys2zdw7mJ6OJBaKgW9GYqPBy IqC6KkzbW+OndDEhZ237IJDtueyOmkNyA/wtHRCqNjq9bmCEvou+1oveIZDynndXL1ty lZ1ilFy2Sf3J4wnYYxras73dpvG25UJ/6jd2q8aB3T9lVpL7QdWvI0ieqsBBr4isMnF6 ipXkB57s7AmjFc5yIatHtfm8woaHM66a1azF/kyS7DypjNkPOvKJZRxfIDjLETgzCA1S vIwQ== X-Gm-Message-State: APf1xPBvmLeuUItGisIZswUMDaN+8OuvCBmCwB+yE4ZpQjTJ/0rbK7Ri K8PkdtNvgD7oKt9lGzcZ6SK4AZP8FiupeYPL6as= X-Google-Smtp-Source: AH8x22645zDWk6bv2LPhd6cLaM7U2X3fAKS0dWi8biuJGHDgfrs92fD9bpiKZV8hvygAVRyvDjQI4sAUUALRMMl/L+4= X-Received: by 10.107.34.199 with SMTP id i190mr14139444ioi.297.1518450126578; Mon, 12 Feb 2018 07:42:06 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Feb 2018 07:42:05 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 12 Feb 2018 07:42:05 -0800 Message-ID: Subject: Re: ECN in QUIC connection migration To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Ingemar Johansson S Cc: Christian Huitema , "De Schepper, Koen (Nokia - BE/Antwerp)" , QUIC WG , Ian Swett , "ekinnear@apple.com" , "Lubashev, Igor" Content-Type: multipart/alternative; boundary="001a1140d9446776c2056505b856" 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, 12 Feb 2018 15:42:11 -0000 --001a1140d9446776c2056505b856 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I haven=E2=80=99t followed the ECN discussion very closely, but I miss a di= scussion of possible abuse scenarios and how to avoid them. On 12 February 2018 at 16.26.32, Mirja K=C3=BChlewind ( mirja.kuehlewind@tik.ee.ethz.ch) wrote: Hi Ingemar, two points. I think it would be good to be as explicit as possible here, therefore I would prefer if an endpoint that knows that it can not access the ECN IP bits indicates this directly in the handshake. In this case no further testing is needed. Further, the path testing itself is independent of QUIC and can be used for any protocol. Moreover, it=E2=80=99s more complicated than just testing ECT= . I guess the general advice here is to remember which codepoints were send and compare this to the feedback provided. If discrepancies are observed that indicate that a middlebox has changed these bits, all packets should be marked as no-ECT (while additional testing MAY be performed at any later point in time). However, how exactly this testing should look like, should not be specified in this doc (but more generally). Mirja > Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S < ingemar.s.johansson@ericsson.com>: > > Hi Eric, Koen + others > > Thanks for the comments and the update. A question to the rest of the audience, does the presented text explain sufficiently enough how ECN works with connection migration ? > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-conn= ection-migration > > > /Ingemar > > > From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto: koen.de_schepper@nokia-bell-labs.com] > Sent: den 2 februari 2018 15:44 > To: ekinnear@apple.com; Ingemar Johansson S < ingemar.s.johansson@ericsson.com> > Cc: QUIC WG ; Ian Swett ; Lubashev, Igor ; Christian Huitema > Subject: RE: ECN in QUIC connection migration > > Hi Ingemar, > > I also read again through the document, and had following comments: > > I replaced: > =E2=80=9CThe ACK_ECN frame is used to convey ACKs when the ECN capability exchange concludes that ECN should be used for the given connection.=E2=80= =9D > Originally it sounds as if the counters are not echoed anymore if the ECN capability check fails. I assume this was not the intention, but if it is: First, we don=E2=80=99t have a protocol or decision point defined when that condition is met (sender should let the receiver know in the next packet), and second, I would always send the echo, as we might =E2=80=9Ctry again la= ter (with another ECT?)=E2=80=9D, or might decide to use the ECN bits different= ly later. > > I also changed the text around the connection migration, I think before Eric reviewed it. I made it such that every new path creates a new connection state with an initialized congestion control state and ECN counters (at least ECN counters reset to 0s). Not sure if this matches with the other sections in the QUIC draft. > > I also had the thought whether it was really needed to have the 2 cases. I agree we should simplify, by just starting over and doing the check unconditionally whether it was successful or not in a previous path. > > Regards, > Koen. > > From: ekinnear@apple.com [mailto:ekinnear@apple.com] > Sent: Friday, February 2, 2018 12:02 AM > To: Ingemar Johansson S > Cc: QUIC WG ; Ian Swett ; Lubashev, Igor ; Christian Huitema ; De Schepper, Koen (Nokia - BE/Antwerp) > Subject: Re: ECN in QUIC connection migration > > Hi Ingemar, > > This generally looks good to me! > A few questions and observations: > > There are two unique cases: > > =E2=80=A2 ECN capability check successful at initial connection setup > =E2=80=A2 ECN capability check failed at initial connection setup > > Are these actually any different in terms of action taken by an endpoint? > It seems like on the new network path the endpoint would go through the same process of: (a) verify ECN capability and if successful to whatever degree then (b) run the rest of the ECN machinery as appropriate. > > In other words, as long as you allow people to start using ECN upon migration (in other words, to allow starting it after the initial connection establishment), then the specifics for ECN with migration is essentially one statement, which is =E2=80=9Cdo the ECN process on each new= network path that you use=E2=80=9D. > > Connection migration has impact on the number of reported CE marked packets. A new connection state with new congestion control state and ECN counters is instantiated at the sender and receiver. The ECN counters MUST start from zero again. > > This seems fine to me, it=E2=80=99s inline with the rest of the congestio= n control/loss recovery state that also needs to be reset for the new path. > > Given that each migration requires at least one exchange of packets at the beginning (at the very least for address validation from the side of the endpoint that didn=E2=80=99t migrate), it seems like that=E2=80=99s an = excellent moment to mark the packets and perform the ECN capability detection. Those packets are also likely padded, etc. similar to initial packets since they=E2=80=99= re on a previously unused network path. > > I think the current proposed requirement of just using the =E2=80=9Cfirst= =E2=80=9D packets and marking those is sufficient (and good to avoid any requirement as to which frames are contained in those packets), since we are always exchanging packets in both directions immediately after migration. > > This has the added benefit such that any endpoint =E2=80=9Cprobing=E2=80= =9D possible network paths could include the bits necessary to detect ECN capability on the path being probed, so it could even know before migrating whether or not it would be able to use ECN on that new path. > > Thanks, > Eric > > > > > On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > > Hi > I have written up different aspects of connection migration and how it plays with ECN. > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-conn= ection-migration > > A caveat.. I am a bit unsure about the definition of connection migration . My interpretation is that a client moves to a new IP address due to e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is a new connection instantiated at a connection migration ? > > /Ingemar > > =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 Research > Network Protocols & E2E Performance > Labratoriegr=C3=A4nd 11 > 971 28, Lule=C3=A5, Sweden > Phone +46-1071 43042 > SMS/MMS +46-73 078 3289 > ingemar.s.johansson@ericsson.com > www.ericsson.com > > You can't start a fire > Worrying 'bout your little world falling apart > Bruce Springsteen > =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 --001a1140d9446776c2056505b856 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I haven=E2=80=99t fo= llowed the ECN discussion very closely, but I miss a discussion of possible= abuse scenarios and how to avoid them.

O= n 12 February 2018 at 16.26.32, Mirja K=C3=BChlewind (mirja.kuehlewind@tik.ee.ethz.ch) wrote:

= Hi Ingemar,

two points. =20

I think it would be good to be as explicit as possible here, therefore = I would prefer if an endpoint that knows that it can not access the ECN IP = bits indicates this directly in the handshake. In this case no further test= ing is needed.

Further, the path testing itself is independent of QUIC and can be used= for any protocol. Moreover, it=E2=80=99s more complicated than just testin= g ECT. I guess the general advice here is to remember which codepoints were= send and compare this to the feedback provided. If discrepancies are obser= ved that indicate that a middlebox has changed these bits, all packets shou= ld be marked as no-ECT (while additional testing MAY be performed at any la= ter point in time). However, how exactly this testing should look like, sho= uld not be specified in this doc (but more generally).

Mirja


> Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S <ingemar.s.johansson@ericsson.com>:
> =20
> Hi Eric, Koen + others
> =20
> Thanks for the comments and the update. A question to the rest of = the audience, does the presented text explain sufficiently enough how ECN w= orks with connection migration ?
> https://github.com/quicwg/base-drafts= /wiki/ECN-in-QUIC#transport-draft-connection-migration
> =20
> =20
> /Ingemar
> =20
> =20
> From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto:koen.de_schepper@nokia-bell-labs= .com] =20
> Sent: den 2 februari 2018 15:44
> To: ekinnear@apple.com; = Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> Cc: QUIC WG <quic@ietf.org= >; Ian Swett <ianswett@google.= com>; Lubashev, Igor <ilub= ashe@akamai.com>; Christian Huitema <huitema@huitema.net>
> Subject: RE: ECN in QUIC connection migration
> =20
> Hi Ingemar,
> =20
> I also read again through the document, and had following comments= :
> =20
> I replaced:
> =E2=80=9CThe ACK_ECN frame is used to convey ACKs when the ECN cap= ability exchange concludes that ECN should be used for the given connection= .=E2=80=9D
> Originally it sounds as if the counters are not echoed anymore if = the ECN capability check fails. I assume this was not the intention, but if= it is: First, we don=E2=80=99t have a protocol or decision point defined w= hen that condition is met (sender should let the receiver know in the next = packet), and second, I would always send the echo, as we might =E2=80=9Ctry= again later (with another ECT?)=E2=80=9D, or might decide to use the ECN b= its differently later.
> =20
> I also changed the text around the connection migration, I think b= efore Eric reviewed it. I made it such that every new path creates a new co= nnection state with an initialized congestion control state and ECN counter= s (at least ECN counters reset to 0s). Not sure if this matches with the ot= her sections in the QUIC draft.
> =20
> I also had the thought whether it was really needed to have the 2 = cases. I agree we should simplify, by just starting over and doing the chec= k unconditionally whether it was successful or not in a previous path.
> =20
> Regards,
> Koen.
> =20
> From: ekinnear@apple.com= [mailto:ekinnear@apple.com] =20
> Sent: Friday, February 2, 2018 12:02 AM
> To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
> Cc: QUIC WG <quic@ietf.org= >; Ian Swett <ianswett@google.= com>; Lubashev, Igor <ilub= ashe@akamai.com>; Christian Huitema <huitema@huitema.net>; De Schepper, Koen (Nokia - BE/Antwe= rp) <koen.de_sch= epper@nokia-bell-labs.com>
> Subject: Re: ECN in QUIC connection migration
> =20
> Hi Ingemar, =20
> =20
> This generally looks good to me!
> A few questions and observations: =20
> =20
> There are two unique cases:
> =20
> =E2=80=A2 ECN capability check successful at initi= al connection setup
> =E2=80=A2 ECN capability check failed at initial c= onnection setup
> =20
> Are these actually any different in terms of action taken by an en= dpoint?
> It seems like on the new network path the endpoint would go throug= h the same process of: (a) verify ECN capability and if successful to whate= ver degree then (b) run the rest of the ECN machinery as appropriate.
> =20
> In other words, as long as you allow people to start using ECN upo= n migration (in other words, to allow starting it after the initial connect= ion establishment), then the specifics for ECN with migration is essentiall= y one statement, which is =E2=80=9Cdo the ECN process on each new network p= ath that you use=E2=80=9D. =20
> =20
> Connection migration has impact on the number of reported CE marke= d packets. A new connection state with new congestion control state and ECN= counters is instantiated at the sender and receiver. The ECN counters MUST= start from zero again.
> =20
> This seems fine to me, it=E2=80=99s inline with the rest of the co= ngestion control/loss recovery state that also needs to be reset for the ne= w path. =20
> =20
> Given that each migration requires at least one exchange of packet= s at the beginning (at the very least for address validation from the side = of the endpoint that didn=E2=80=99t migrate), it seems like that=E2=80=99s = an excellent moment to mark the packets and perform the ECN capability dete= ction. Those packets are also likely padded, etc. similar to initial packet= s since they=E2=80=99re on a previously unused network path. =20
> =20
> I think the current proposed requirement of just using the =E2=80= =9Cfirst=E2=80=9D packets and marking those is sufficient (and good to avoi= d any requirement as to which frames are contained in those packets), since= we are always exchanging packets in both directions immediately after migr= ation. =20
> =20
> This has the added benefit such that any endpoint =E2=80=9Cprobing= =E2=80=9D possible network paths could include the bits necessary to detect= ECN capability on the path being probed, so it could even know before migr= ating whether or not it would be able to use ECN on that new path. =20
> =20
> Thanks,
> Eric
> =20
> =20
> =20
> =20
> On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com&= gt; wrote:
> =20
> Hi
> I have written up different aspects of connection migration and ho= w it plays with ECN.
> https://github.com/quicwg/base-drafts= /wiki/ECN-in-QUIC#transport-draft-connection-migration
> =20
> A caveat.. I am a bit unsure about the definition of connection mi= gration . My interpretation is that a client moves to a new IP address due = to e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is a new con= nection instantiated at a connection migration ? =20
> =20
> /Ingemar
> =20
> =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
> =20
> Ericsson Research
> Network Protocols & E2E Performance
> Labratoriegr=C3=A4nd 11
> 971 28, Lule=C3=A5, Sweden
> Phone +46-1071 43042
> SMS/MMS +46-73 078 3289
> ingemar.s.joha= nsson@ericsson.com
> www.ericsson.com
> =20
> You can't start a fire
> Worrying 'bout your little world falling apart
> Bruce Springsteen
> =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

--001a1140d9446776c2056505b856-- From nobody Mon Feb 12 07:43:49 2018 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 5F55F12D82C for ; Mon, 12 Feb 2018 07:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 niUaYbJmQ0ij for ; Mon, 12 Feb 2018 07:43:45 -0800 (PST) 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 CD5AB12D82F for ; Mon, 12 Feb 2018 07:43:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zg91q3qFlz15K2H; Mon, 12 Feb 2018 16:43:43 +0100 (CET) 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 Du5bhlrAjOex; Mon, 12 Feb 2018 16:43:37 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (i577BCE78.versanet.de [87.123.206.120]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 12 Feb 2018 16:43:37 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: ECN in QUIC connection migration From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 12 Feb 2018 16:43:36 +0100 Cc: Ingemar Johansson S , Christian Huitema , "De Schepper, Koen (Nokia - BE/Antwerp)" , QUIC WG , Ian Swett , "ekinnear@apple.com" , "Lubashev, Igor" Content-Transfer-Encoding: quoted-printable Message-Id: <79E89348-6C18-42A7-B378-487E84E7FF31@tik.ee.ethz.ch> References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.5.20) 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, 12 Feb 2018 15:43:48 -0000 What do you mean by abuse scenarios? However, I would guess again that = this is not a quic specific discussion and should probably rather happen = in tsvwg which is the group that is maintain ECN in general. Mirja > Am 12.02.2018 um 16:42 schrieb Mikkel Fahn=C3=B8e J=C3=B8rgensen = : >=20 > I haven=E2=80=99t followed the ECN discussion very closely, but I miss = a discussion of possible abuse scenarios and how to avoid them. >=20 > On 12 February 2018 at 16.26.32, Mirja K=C3=BChlewind = (mirja.kuehlewind@tik.ee.ethz.ch) wrote: >=20 >> Hi Ingemar,=20 >>=20 >> two points. =20 >>=20 >> I think it would be good to be as explicit as possible here, = therefore I would prefer if an endpoint that knows that it can not = access the ECN IP bits indicates this directly in the handshake. In this = case no further testing is needed.=20 >>=20 >> Further, the path testing itself is independent of QUIC and can be = used for any protocol. Moreover, it=E2=80=99s more complicated than just = testing ECT. I guess the general advice here is to remember which = codepoints were send and compare this to the feedback provided. If = discrepancies are observed that indicate that a middlebox has changed = these bits, all packets should be marked as no-ECT (while additional = testing MAY be performed at any later point in time). However, how = exactly this testing should look like, should not be specified in this = doc (but more generally).=20 >>=20 >> Mirja=20 >>=20 >>=20 >> > Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S = :=20 >> > =20 >> > Hi Eric, Koen + others=20 >> > =20 >> > Thanks for the comments and the update. A question to the rest of = the audience, does the presented text explain sufficiently enough how = ECN works with connection migration ?=20 >> > = https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-con= nection-migration=20 >> > =20 >> > =20 >> > /Ingemar=20 >> > =20 >> > =20 >> > From: De Schepper, Koen (Nokia - BE/Antwerp) = [mailto:koen.de_schepper@nokia-bell-labs.com] =20 >> > Sent: den 2 februari 2018 15:44=20 >> > To: ekinnear@apple.com; Ingemar Johansson S = =20 >> > Cc: QUIC WG ; Ian Swett ; = Lubashev, Igor ; Christian Huitema = =20 >> > Subject: RE: ECN in QUIC connection migration=20 >> > =20 >> > Hi Ingemar,=20 >> > =20 >> > I also read again through the document, and had following comments:=20= >> > =20 >> > I replaced:=20 >> > =E2=80=9CThe ACK_ECN frame is used to convey ACKs when the ECN = capability exchange concludes that ECN should be used for the given = connection.=E2=80=9D=20 >> > Originally it sounds as if the counters are not echoed anymore if = the ECN capability check fails. I assume this was not the intention, but = if it is: First, we don=E2=80=99t have a protocol or decision point = defined when that condition is met (sender should let the receiver know = in the next packet), and second, I would always send the echo, as we = might =E2=80=9Ctry again later (with another ECT?)=E2=80=9D, or might = decide to use the ECN bits differently later.=20 >> > =20 >> > I also changed the text around the connection migration, I think = before Eric reviewed it. I made it such that every new path creates a = new connection state with an initialized congestion control state and = ECN counters (at least ECN counters reset to 0s). Not sure if this = matches with the other sections in the QUIC draft.=20 >> > =20 >> > I also had the thought whether it was really needed to have the 2 = cases. I agree we should simplify, by just starting over and doing the = check unconditionally whether it was successful or not in a previous = path.=20 >> > =20 >> > Regards,=20 >> > Koen.=20 >> > =20 >> > From: ekinnear@apple.com [mailto:ekinnear@apple.com] =20 >> > Sent: Friday, February 2, 2018 12:02 AM=20 >> > To: Ingemar Johansson S =20 >> > Cc: QUIC WG ; Ian Swett ; = Lubashev, Igor ; Christian Huitema = ; De Schepper, Koen (Nokia - BE/Antwerp) = =20 >> > Subject: Re: ECN in QUIC connection migration=20 >> > =20 >> > Hi Ingemar, =20 >> > =20 >> > This generally looks good to me!=20 >> > A few questions and observations: =20 >> > =20 >> > There are two unique cases:=20 >> > =20 >> > =E2=80=A2 ECN capability check successful at initial connection = setup=20 >> > =E2=80=A2 ECN capability check failed at initial connection setup=20= >> > =20 >> > Are these actually any different in terms of action taken by an = endpoint?=20 >> > It seems like on the new network path the endpoint would go through = the same process of: (a) verify ECN capability and if successful to = whatever degree then (b) run the rest of the ECN machinery as = appropriate.=20 >> > =20 >> > In other words, as long as you allow people to start using ECN upon = migration (in other words, to allow starting it after the initial = connection establishment), then the specifics for ECN with migration is = essentially one statement, which is =E2=80=9Cdo the ECN process on each = new network path that you use=E2=80=9D. =20 >> > =20 >> > Connection migration has impact on the number of reported CE marked = packets. A new connection state with new congestion control state and = ECN counters is instantiated at the sender and receiver. The ECN = counters MUST start from zero again.=20 >> > =20 >> > This seems fine to me, it=E2=80=99s inline with the rest of the = congestion control/loss recovery state that also needs to be reset for = the new path. =20 >> > =20 >> > Given that each migration requires at least one exchange of packets = at the beginning (at the very least for address validation from the side = of the endpoint that didn=E2=80=99t migrate), it seems like that=E2=80=99s= an excellent moment to mark the packets and perform the ECN capability = detection. Those packets are also likely padded, etc. similar to initial = packets since they=E2=80=99re on a previously unused network path. =20 >> > =20 >> > I think the current proposed requirement of just using the = =E2=80=9Cfirst=E2=80=9D packets and marking those is sufficient (and = good to avoid any requirement as to which frames are contained in those = packets), since we are always exchanging packets in both directions = immediately after migration. =20 >> > =20 >> > This has the added benefit such that any endpoint =E2=80=9Cprobing=E2= =80=9D possible network paths could include the bits necessary to detect = ECN capability on the path being probed, so it could even know before = migrating whether or not it would be able to use ECN on that new path. =20= >> > =20 >> > Thanks,=20 >> > Eric=20 >> > =20 >> > =20 >> > =20 >> > =20 >> > On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S = wrote:=20 >> > =20 >> > Hi=20 >> > I have written up different aspects of connection migration and how = it plays with ECN.=20 >> > = https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-con= nection-migration=20 >> > =20 >> > A caveat.. I am a bit unsure about the definition of connection = migration . My interpretation is that a client moves to a new IP address = due to e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is a = new connection instantiated at a connection migration ? =20 >> > =20 >> > /Ingemar=20 >> > =20 >> > =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=20 >> > Ingemar Johansson M.Sc.=20 >> > Master Researcher=20 >> > =20 >> > Ericsson Research=20 >> > Network Protocols & E2E Performance=20 >> > Labratoriegr=C3=A4nd 11=20 >> > 971 28, Lule=C3=A5, Sweden=20 >> > Phone +46-1071 43042=20 >> > SMS/MMS +46-73 078 3289=20 >> > ingemar.s.johansson@ericsson.com=20 >> > www.ericsson.com=20 >> > =20 >> > You can't start a fire=20 >> > Worrying 'bout your little world falling apart=20 >> > Bruce Springsteen=20 >> > =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 From nobody Mon Feb 12 07:55:07 2018 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 89B6312D838 for ; Mon, 12 Feb 2018 07:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 xs7J9hdFthPT for ; Mon, 12 Feb 2018 07:54:55 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 4730E12D830 for ; Mon, 12 Feb 2018 07:54:55 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id k80so6385373ioe.13 for ; Mon, 12 Feb 2018 07:54:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=SMVBz35ouAIIn8YBKg8L+5JyEIrF3NC9LrmJsAo5q8g=; b=lHEYB9fm6sQjv8Mx+VnSMfJPQJFejjRie5hfWXwtS0/dut1Rcke3uymNzoDF6ZptZC 8qG8OcE+iqDoghJRH6RuVxqPtbLOiXjoEkjDttFfEvLVLGzNfRoAvGw0iHywNEl/nFa0 +1YaGS5BzG3PbJNvRFCZuP3zaSsLe/7TWftta3IYmj3IL7mb6x8YnzNXQx4hOOECUs0w xdnqsPaptiBsbHQ0ZpZAk4AJO5iJnkb4SaUVed0JRVMnTWDdiZhWn46ZPMYuDdufzRoE UKNz5eFe3cAc47iL5zIHcMLUwRUW3W2xY8d1B7BZMlXDWEe4pP8K77+27CKuljwEfBs7 l9kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=SMVBz35ouAIIn8YBKg8L+5JyEIrF3NC9LrmJsAo5q8g=; b=kS97KAsJTlYKQffBDIHNat+G5cUm/rdLUPwZeEIf21qr9XG5/B+I16dVBZDqxD3Tjr DPopoSfQYbmjZfoLvxXtiXwueR6i/XNCYGX16moFc6/a5LfA+JrJocWQSa1KHjgPRlq+ /o+lzkIGU4pMbu8zKTeEC5PWwWFxG6+LsSZtVkVFYCt67y+5FkwyMu+XEg9uaNO1gTNm EpBb2nLA9L2DzVVB++FL2HKT0NOuYuEonq3cMMNuDJnjYbnMhrEZpiQeiEnHW+CgA20A sJwWICGY2CgfjwgMGtviPjlSxXG+6/1jwh5OI2twyB4VsMmWKEhR7zRV0QRPg9sEKqfu zing== X-Gm-Message-State: APf1xPCUUqbuM6ZAWLaC7tbIABFGkBpm+zfVALzPjMbdi1xGcK68EH7O ThNQi2R9Ih8ocO3eGtz/esHvUHtJntvjJEW+cSc= X-Google-Smtp-Source: AH8x225f+oBUJd2gcfhT893P6p9AYJCLUxnYumiatj72au6OKuhRhcXXFooqE19sZayqveyICWd6Uhz9EtMTPYxjTsM= X-Received: by 10.107.34.199 with SMTP id i190mr14189294ioi.297.1518450894275; Mon, 12 Feb 2018 07:54:54 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 12 Feb 2018 07:54:53 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <79E89348-6C18-42A7-B378-487E84E7FF31@tik.ee.ethz.ch> References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> <79E89348-6C18-42A7-B378-487E84E7FF31@tik.ee.ethz.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 12 Feb 2018 07:54:53 -0800 Message-ID: Subject: Re: ECN in QUIC connection migration To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: "ekinnear@apple.com" , QUIC WG , Ian Swett , Ingemar Johansson S , Christian Huitema , "De Schepper, Koen (Nokia - BE/Antwerp)" , "Lubashev, Igor" Content-Type: multipart/alternative; boundary="001a1140d94429bd04056505e633" 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, 12 Feb 2018 15:55:00 -0000 --001a1140d94429bd04056505e633 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t know enough about ECN to have a qualified opinion, but I me= an that, for example, someone on the path might make a false impression of the available bandwidth. It may be a general ECN discussion but I=E2=80=99d lik= e to know how it affects security of QUIC if made mandatory, just like there are other sections in QUIC transport on potential attacks to be aware of. http://web.cs.ucla.edu/~todd/research/sigcomm11.pdf http://ieeexplore.ieee.org/document/6993126/ Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 12 February 2018 at 16.43.43, Mirja K=C3=BChlewind ( mirja.kuehlewind@tik.ee.ethz.ch) wrote: What do you mean by abuse scenarios? However, I would guess again that this is not a quic specific discussion and should probably rather happen in tsvwg which is the group that is maintain ECN in general. Mirja > Am 12.02.2018 um 16:42 schrieb Mikkel Fahn=C3=B8e J=C3=B8rgensen : > > I haven=E2=80=99t followed the ECN discussion very closely, but I miss a discussion of possible abuse scenarios and how to avoid them. > > On 12 February 2018 at 16.26.32, Mirja K=C3=BChlewind ( mirja.kuehlewind@tik.ee.ethz.ch) wrote: > >> Hi Ingemar, >> >> two points. >> >> I think it would be good to be as explicit as possible here, therefore I would prefer if an endpoint that knows that it can not access the ECN IP bits indicates this directly in the handshake. In this case no further testing is needed. >> >> Further, the path testing itself is independent of QUIC and can be used for any protocol. Moreover, it=E2=80=99s more complicated than just testing= ECT. I guess the general advice here is to remember which codepoints were send and compare this to the feedback provided. If discrepancies are observed that indicate that a middlebox has changed these bits, all packets should be marked as no-ECT (while additional testing MAY be performed at any later point in time). However, how exactly this testing should look like, should not be specified in this doc (but more generally). >> >> Mirja >> >> >> > Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S < ingemar.s.johansson@ericsson.com>: >> > >> > Hi Eric, Koen + others >> > >> > Thanks for the comments and the update. A question to the rest of the audience, does the presented text explain sufficiently enough how ECN works with connection migration ? >> > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-conn= ection-migration >> > >> > >> > /Ingemar >> > >> > >> > From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto: koen.de_schepper@nokia-bell-labs.com] >> > Sent: den 2 februari 2018 15:44 >> > To: ekinnear@apple.com; Ingemar Johansson S < ingemar.s.johansson@ericsson.com> >> > Cc: QUIC WG ; Ian Swett ; Lubashev, Igor ; Christian Huitema >> > Subject: RE: ECN in QUIC connection migration >> > >> > Hi Ingemar, >> > >> > I also read again through the document, and had following comments: >> > >> > I replaced: >> > =E2=80=9CThe ACK_ECN frame is used to convey ACKs when the ECN capabil= ity exchange concludes that ECN should be used for the given connection.=E2=80= =9D >> > Originally it sounds as if the counters are not echoed anymore if the ECN capability check fails. I assume this was not the intention, but if it is: First, we don=E2=80=99t have a protocol or decision point defined when = that condition is met (sender should let the receiver know in the next packet), and second, I would always send the echo, as we might =E2=80=9Ctry again la= ter (with another ECT?)=E2=80=9D, or might decide to use the ECN bits different= ly later. >> > >> > I also changed the text around the connection migration, I think before Eric reviewed it. I made it such that every new path creates a new connection state with an initialized congestion control state and ECN counters (at least ECN counters reset to 0s). Not sure if this matches with the other sections in the QUIC draft. >> > >> > I also had the thought whether it was really needed to have the 2 cases. I agree we should simplify, by just starting over and doing the check unconditionally whether it was successful or not in a previous path. >> > >> > Regards, >> > Koen. >> > >> > From: ekinnear@apple.com [mailto:ekinnear@apple.com] >> > Sent: Friday, February 2, 2018 12:02 AM >> > To: Ingemar Johansson S >> > Cc: QUIC WG ; Ian Swett ; Lubashev, Igor ; Christian Huitema ; De Schepper, Koen (Nokia - BE/Antwerp) >> > Subject: Re: ECN in QUIC connection migration >> > >> > Hi Ingemar, >> > >> > This generally looks good to me! >> > A few questions and observations: >> > >> > There are two unique cases: >> > >> > =E2=80=A2 ECN capability check successful at initial connection setup >> > =E2=80=A2 ECN capability check failed at initial connection setup >> > >> > Are these actually any different in terms of action taken by an endpoint? >> > It seems like on the new network path the endpoint would go through the same process of: (a) verify ECN capability and if successful to whatever degree then (b) run the rest of the ECN machinery as appropriate. >> > >> > In other words, as long as you allow people to start using ECN upon migration (in other words, to allow starting it after the initial connection establishment), then the specifics for ECN with migration is essentially one statement, which is =E2=80=9Cdo the ECN process on each new= network path that you use=E2=80=9D. >> > >> > Connection migration has impact on the number of reported CE marked packets. A new connection state with new congestion control state and ECN counters is instantiated at the sender and receiver. The ECN counters MUST start from zero again. >> > >> > This seems fine to me, it=E2=80=99s inline with the rest of the conges= tion control/loss recovery state that also needs to be reset for the new path. >> > >> > Given that each migration requires at least one exchange of packets at the beginning (at the very least for address validation from the side of the endpoint that didn=E2=80=99t migrate), it seems like that=E2=80=99s an = excellent moment to mark the packets and perform the ECN capability detection. Those packets are also likely padded, etc. similar to initial packets since they=E2=80=99= re on a previously unused network path. >> > >> > I think the current proposed requirement of just using the =E2=80=9Cfi= rst=E2=80=9D packets and marking those is sufficient (and good to avoid any requirement as to which frames are contained in those packets), since we are always exchanging packets in both directions immediately after migration. >> > >> > This has the added benefit such that any endpoint =E2=80=9Cprobing=E2= =80=9D possible network paths could include the bits necessary to detect ECN capability on the path being probed, so it could even know before migrating whether or not it would be able to use ECN on that new path. >> > >> > Thanks, >> > Eric >> > >> > >> > >> > >> > On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: >> > >> > Hi >> > I have written up different aspects of connection migration and how it plays with ECN. >> > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-conn= ection-migration >> > >> > A caveat.. I am a bit unsure about the definition of connection migration . My interpretation is that a client moves to a new IP address due to e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is a new connection instantiated at a connection migration ? >> > >> > /Ingemar >> > >> > =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 Research >> > Network Protocols & E2E Performance >> > Labratoriegr=C3=A4nd 11 >> > 971 28, Lule=C3=A5, Sweden >> > Phone +46-1071 43042 >> > SMS/MMS +46-73 078 3289 >> > ingemar.s.johansson@ericsson.com >> > www.ericsson.com >> > >> > You can't start a fire >> > Worrying 'bout your little world falling apart >> > Bruce Springsteen >> > =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 --001a1140d94429bd04056505e633 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I don=E2=80=99t know= enough about ECN to have a qualified opinion, but I mean that, for example= , someone on the path might make a false impression of the available bandwi= dth. It may be a general ECN discussion but I=E2=80=99d like to know how it= affects security of QUIC if made mandatory, just like there are other sect= ions in QUIC transport on potential attacks to be aware of.



Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 12 February 2018 at 16.43.43, Mirja K=C3=BChlewind (mirja.kuehlewind@tik.ee.ethz.ch= ) wrote:

What do you mean by abuse scenarios? However, I would guess a= gain that this is not a quic specific discussion and should probably rather= happen in tsvwg which is the group that is maintain ECN in general.

Mirja


> Am 12.02.2018 um 16:42 schrieb Mikkel Fahn=C3=B8e J=C3=B8rgensen &= lt;mikkelfj@gmail.com>:
> =20
> I haven=E2=80=99t followed the ECN discussion very closely, but I = miss a discussion of possible abuse scenarios and how to avoid them.
> =20
> On 12 February 2018 at 16.26.32, Mirja K=C3=BChlewind (mirja.kuehlewind@tik.ee.ethz.ch= ) wrote:
> =20
>> Hi Ingemar, =20
>> =20
>> two points. =20
>> =20
>> I think it would be good to be as explicit as possible here, t= herefore I would prefer if an endpoint that knows that it can not access th= e ECN IP bits indicates this directly in the handshake. In this case no fur= ther testing is needed. =20
>> =20
>> Further, the path testing itself is independent of QUIC and ca= n be used for any protocol. Moreover, it=E2=80=99s more complicated than ju= st testing ECT. I guess the general advice here is to remember which codepo= ints were send and compare this to the feedback provided. If discrepancies = are observed that indicate that a middlebox has changed these bits, all pac= kets should be marked as no-ECT (while additional testing MAY be performed = at any later point in time). However, how exactly this testing should look = like, should not be specified in this doc (but more generally). =20
>> =20
>> Mirja =20
>> =20
>> =20
>> > Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S <ingemar.s.johansson@erics= son.com>: =20
>> > =20
>> > Hi Eric, Koen + others =20
>> > =20
>> > Thanks for the comments and the update. A question to the= rest of the audience, does the presented text explain sufficiently enough = how ECN works with connection migration ? =20
>> > https://github.com/quicwg/ba= se-drafts/wiki/ECN-in-QUIC#transport-draft-connection-migration =20
>> > =20
>> > =20
>> > /Ingemar =20
>> > =20
>> > =20
>> > From: De Schepper, Koen (Nokia - BE/Antwerp) [mailto:koen.de_schepper@nokia-= bell-labs.com] =20
>> > Sent: den 2 februari 2018 15:44 =20
>> > To: ekinnear@apple.= com; Ingemar Johansson S <ingemar.s.johansson@ericsson.com> =20
>> > Cc: QUIC WG <quic@iet= f.org>; Ian Swett <ianswet= t@google.com>; Lubashev, Igor <ilubashe@akamai.com>; Christian Huitema <huitema@huitema.net> =20
>> > Subject: RE: ECN in QUIC connection migration =20
>> > =20
>> > Hi Ingemar, =20
>> > =20
>> > I also read again through the document, and had following= comments: =20
>> > =20
>> > I replaced: =20
>> > =E2=80=9CThe ACK_ECN frame is used to convey ACKs when th= e ECN capability exchange concludes that ECN should be used for the given c= onnection.=E2=80=9D =20
>> > Originally it sounds as if the counters are not echoed an= ymore if the ECN capability check fails. I assume this was not the intentio= n, but if it is: First, we don=E2=80=99t have a protocol or decision point = defined when that condition is met (sender should let the receiver know in = the next packet), and second, I would always send the echo, as we might =E2= =80=9Ctry again later (with another ECT?)=E2=80=9D, or might decide to use = the ECN bits differently later. =20
>> > =20
>> > I also changed the text around the connection migration, = I think before Eric reviewed it. I made it such that every new path creates= a new connection state with an initialized congestion control state and EC= N counters (at least ECN counters reset to 0s). Not sure if this matches wi= th the other sections in the QUIC draft. =20
>> > =20
>> > I also had the thought whether it was really needed to ha= ve the 2 cases. I agree we should simplify, by just starting over and doing= the check unconditionally whether it was successful or not in a previous p= ath. =20
>> > =20
>> > Regards, =20
>> > Koen. =20
>> > =20
>> > From: ekinnear@appl= e.com [mailto:ekinnear@apple.com<= /a>] =20
>> > Sent: Friday, February 2, 2018 12:02 AM =20
>> > To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com> =20
>> > Cc: QUIC WG <quic@iet= f.org>; Ian Swett <ianswet= t@google.com>; Lubashev, Igor <ilubashe@akamai.com>; Christian Huitema <huitema@huitema.net>; De Schepper, Koen (Nokia -= BE/Antwerp) <ko= en.de_schepper@nokia-bell-labs.com> =20
>> > Subject: Re: ECN in QUIC connection migration =20
>> > =20
>> > Hi Ingemar, =20
>> > =20
>> > This generally looks good to me! =20
>> > A few questions and observations: =20
>> > =20
>> > There are two unique cases: =20
>> > =20
>> > =E2=80=A2 ECN capability check successful at initial conn= ection setup =20
>> > =E2=80=A2 ECN capability check failed at initial connecti= on setup =20
>> > =20
>> > Are these actually any different in terms of action taken= by an endpoint? =20
>> > It seems like on the new network path the endpoint would = go through the same process of: (a) verify ECN capability and if successful= to whatever degree then (b) run the rest of the ECN machinery as appropria= te. =20
>> > =20
>> > In other words, as long as you allow people to start usin= g ECN upon migration (in other words, to allow starting it after the initia= l connection establishment), then the specifics for ECN with migration is e= ssentially one statement, which is =E2=80=9Cdo the ECN process on each new = network path that you use=E2=80=9D. =20
>> > =20
>> > Connection migration has impact on the number of reported= CE marked packets. A new connection state with new congestion control stat= e and ECN counters is instantiated at the sender and receiver. The ECN coun= ters MUST start from zero again. =20
>> > =20
>> > This seems fine to me, it=E2=80=99s inline with the rest = of the congestion control/loss recovery state that also needs to be reset f= or the new path. =20
>> > =20
>> > Given that each migration requires at least one exchange = of packets at the beginning (at the very least for address validation from = the side of the endpoint that didn=E2=80=99t migrate), it seems like that= =E2=80=99s an excellent moment to mark the packets and perform the ECN capa= bility detection. Those packets are also likely padded, etc. similar to ini= tial packets since they=E2=80=99re on a previously unused network path. = =20
>> > =20
>> > I think the current proposed requirement of just using th= e =E2=80=9Cfirst=E2=80=9D packets and marking those is sufficient (and good= to avoid any requirement as to which frames are contained in those packets= ), since we are always exchanging packets in both directions immediately af= ter migration. =20
>> > =20
>> > This has the added benefit such that any endpoint =E2=80= =9Cprobing=E2=80=9D possible network paths could include the bits necessary= to detect ECN capability on the path being probed, so it could even know b= efore migrating whether or not it would be able to use ECN on that new path= . =20
>> > =20
>> > Thanks, =20
>> > Eric =20
>> > =20
>> > =20
>> > =20
>> > =20
>> > On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson= .com> wrote: =20
>> > =20
>> > Hi =20
>> > I have written up different aspects of connection migrati= on and how it plays with ECN. =20
>> > https://github.com/quicwg/ba= se-drafts/wiki/ECN-in-QUIC#transport-draft-connection-migration =20
>> > =20
>> > A caveat.. I am a bit unsure about the definition of conn= ection migration . My interpretation is that a client moves to a new IP add= ress due to e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is = a new connection instantiated at a connection migration ? =20
>> > =20
>> > /Ingemar =20
>> > =20
>> > =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 =20
>> > Ingemar Johansson M.Sc. =20
>> > Master Researcher =20
>> > =20
>> > Ericsson Research =20
>> > Network Protocols & E2E Performance =20
>> > Labratoriegr=C3=A4nd 11 =20
>> > 971 28, Lule=C3=A5, Sweden =20
>> > Phone +46-1071 43042 =20
>> > SMS/MMS +46-73 078 3289 =20
>> > ingem= ar.s.johansson@ericsson.com =20
>> > www.ericsson.com = =20
>> > =20
>> > You can't start a fire =20
>> > Worrying 'bout your little world falling apart =20
>> > Bruce Springsteen =20
>> > =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

--001a1140d94429bd04056505e633-- From nobody Mon Feb 12 08:05:08 2018 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 522D812D849 for ; Mon, 12 Feb 2018 08:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 kN2EqzboRBq0 for ; Mon, 12 Feb 2018 08:04:58 -0800 (PST) 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 38E4F12D84F for ; Mon, 12 Feb 2018 08:04:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zg9VJ6q6Kz15K2H; Mon, 12 Feb 2018 17:04:56 +0100 (CET) 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 60ajQfVEiZoV; Mon, 12 Feb 2018 17:04:55 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (i577BCE78.versanet.de [87.123.206.120]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Mon, 12 Feb 2018 17:04:55 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: ECN in QUIC connection migration From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Mon, 12 Feb 2018 17:04:53 +0100 Cc: "ekinnear@apple.com" , QUIC WG , Ian Swett , Ingemar Johansson S , Christian Huitema , "De Schepper, Koen (Nokia - BE/Antwerp)" , "Lubashev, Igor" Content-Transfer-Encoding: quoted-printable Message-Id: <5722AFB7-F680-4C65-93FE-2F6819A3E789@tik.ee.ethz.ch> References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> <79E89348-6C18-42A7-B378-487E84E7FF31@tik.ee.ethz.ch> To: =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Apple Mail (2.3445.5.20) 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, 12 Feb 2018 16:05:06 -0000 ECN is an explicit congestion signal that can be used to avoid loss. ECN = makes no assumption on how exactly the signal is generated but usually = you need some kind of active queue management. The ECN signal is then = used by the congestion controller at the sender, similar as loss or = other signals are used today. It is the network decision how and when to = signal congestion using ECN and the endpoints decision how to exactly = react to it. If the network sets ECN-CE even though there is no congestion it would = likely cause a reduction in sending of that flow but it can also just = drop some packets to achieve the same. However, as I said this is = nothing quic-specific and should be discussed on the tsvwg list instead. > Am 12.02.2018 um 16:54 schrieb Mikkel Fahn=C3=B8e J=C3=B8rgensen = : >=20 > I don=E2=80=99t know enough about ECN to have a qualified opinion, but = I mean that, for example, someone on the path might make a false = impression of the available bandwidth. It may be a general ECN = discussion but I=E2=80=99d like to know how it affects security of QUIC = if made mandatory, just like there are other sections in QUIC transport = on potential attacks to be aware of. >=20 > http://web.cs.ucla.edu/~todd/research/sigcomm11.pdf > http://ieeexplore.ieee.org/document/6993126/ >=20 >=20 > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen >=20 >=20 > On 12 February 2018 at 16.43.43, Mirja K=C3=BChlewind = (mirja.kuehlewind@tik.ee.ethz.ch) wrote: >=20 >> What do you mean by abuse scenarios? However, I would guess again = that this is not a quic specific discussion and should probably rather = happen in tsvwg which is the group that is maintain ECN in general.=20 >>=20 >> Mirja=20 >>=20 >>=20 >> > Am 12.02.2018 um 16:42 schrieb Mikkel Fahn=C3=B8e J=C3=B8rgensen = :=20 >> > =20 >> > I haven=E2=80=99t followed the ECN discussion very closely, but I = miss a discussion of possible abuse scenarios and how to avoid them.=20 >> > =20 >> > On 12 February 2018 at 16.26.32, Mirja K=C3=BChlewind = (mirja.kuehlewind@tik.ee.ethz.ch) wrote:=20 >> > =20 >> >> Hi Ingemar, =20 >> >> =20 >> >> two points. =20 >> >> =20 >> >> I think it would be good to be as explicit as possible here, = therefore I would prefer if an endpoint that knows that it can not = access the ECN IP bits indicates this directly in the handshake. In this = case no further testing is needed. =20 >> >> =20 >> >> Further, the path testing itself is independent of QUIC and can be = used for any protocol. Moreover, it=E2=80=99s more complicated than just = testing ECT. I guess the general advice here is to remember which = codepoints were send and compare this to the feedback provided. If = discrepancies are observed that indicate that a middlebox has changed = these bits, all packets should be marked as no-ECT (while additional = testing MAY be performed at any later point in time). However, how = exactly this testing should look like, should not be specified in this = doc (but more generally). =20 >> >> =20 >> >> Mirja =20 >> >> =20 >> >> =20 >> >> > Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S = : =20 >> >> > =20 >> >> > Hi Eric, Koen + others =20 >> >> > =20 >> >> > Thanks for the comments and the update. A question to the rest = of the audience, does the presented text explain sufficiently enough how = ECN works with connection migration ? =20 >> >> > = https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-con= nection-migration =20 >> >> > =20 >> >> > =20 >> >> > /Ingemar =20 >> >> > =20 >> >> > =20 >> >> > From: De Schepper, Koen (Nokia - BE/Antwerp) = [mailto:koen.de_schepper@nokia-bell-labs.com] =20 >> >> > Sent: den 2 februari 2018 15:44 =20 >> >> > To: ekinnear@apple.com; Ingemar Johansson S = =20 >> >> > Cc: QUIC WG ; Ian Swett ; = Lubashev, Igor ; Christian Huitema = =20 >> >> > Subject: RE: ECN in QUIC connection migration =20 >> >> > =20 >> >> > Hi Ingemar, =20 >> >> > =20 >> >> > I also read again through the document, and had following = comments: =20 >> >> > =20 >> >> > I replaced: =20 >> >> > =E2=80=9CThe ACK_ECN frame is used to convey ACKs when the ECN = capability exchange concludes that ECN should be used for the given = connection.=E2=80=9D =20 >> >> > Originally it sounds as if the counters are not echoed anymore = if the ECN capability check fails. I assume this was not the intention, = but if it is: First, we don=E2=80=99t have a protocol or decision point = defined when that condition is met (sender should let the receiver know = in the next packet), and second, I would always send the echo, as we = might =E2=80=9Ctry again later (with another ECT?)=E2=80=9D, or might = decide to use the ECN bits differently later. =20 >> >> > =20 >> >> > I also changed the text around the connection migration, I think = before Eric reviewed it. I made it such that every new path creates a = new connection state with an initialized congestion control state and = ECN counters (at least ECN counters reset to 0s). Not sure if this = matches with the other sections in the QUIC draft. =20 >> >> > =20 >> >> > I also had the thought whether it was really needed to have the = 2 cases. I agree we should simplify, by just starting over and doing the = check unconditionally whether it was successful or not in a previous = path. =20 >> >> > =20 >> >> > Regards, =20 >> >> > Koen. =20 >> >> > =20 >> >> > From: ekinnear@apple.com [mailto:ekinnear@apple.com] =20 >> >> > Sent: Friday, February 2, 2018 12:02 AM =20 >> >> > To: Ingemar Johansson S =20 >> >> > Cc: QUIC WG ; Ian Swett ; = Lubashev, Igor ; Christian Huitema = ; De Schepper, Koen (Nokia - BE/Antwerp) = =20 >> >> > Subject: Re: ECN in QUIC connection migration =20 >> >> > =20 >> >> > Hi Ingemar, =20 >> >> > =20 >> >> > This generally looks good to me! =20 >> >> > A few questions and observations: =20 >> >> > =20 >> >> > There are two unique cases: =20 >> >> > =20 >> >> > =E2=80=A2 ECN capability check successful at initial connection = setup =20 >> >> > =E2=80=A2 ECN capability check failed at initial connection = setup =20 >> >> > =20 >> >> > Are these actually any different in terms of action taken by an = endpoint? =20 >> >> > It seems like on the new network path the endpoint would go = through the same process of: (a) verify ECN capability and if successful = to whatever degree then (b) run the rest of the ECN machinery as = appropriate. =20 >> >> > =20 >> >> > In other words, as long as you allow people to start using ECN = upon migration (in other words, to allow starting it after the initial = connection establishment), then the specifics for ECN with migration is = essentially one statement, which is =E2=80=9Cdo the ECN process on each = new network path that you use=E2=80=9D. =20 >> >> > =20 >> >> > Connection migration has impact on the number of reported CE = marked packets. A new connection state with new congestion control state = and ECN counters is instantiated at the sender and receiver. The ECN = counters MUST start from zero again. =20 >> >> > =20 >> >> > This seems fine to me, it=E2=80=99s inline with the rest of the = congestion control/loss recovery state that also needs to be reset for = the new path. =20 >> >> > =20 >> >> > Given that each migration requires at least one exchange of = packets at the beginning (at the very least for address validation from = the side of the endpoint that didn=E2=80=99t migrate), it seems like = that=E2=80=99s an excellent moment to mark the packets and perform the = ECN capability detection. Those packets are also likely padded, etc. = similar to initial packets since they=E2=80=99re on a previously unused = network path. =20 >> >> > =20 >> >> > I think the current proposed requirement of just using the = =E2=80=9Cfirst=E2=80=9D packets and marking those is sufficient (and = good to avoid any requirement as to which frames are contained in those = packets), since we are always exchanging packets in both directions = immediately after migration. =20 >> >> > =20 >> >> > This has the added benefit such that any endpoint =E2=80=9Cprobing= =E2=80=9D possible network paths could include the bits necessary to = detect ECN capability on the path being probed, so it could even know = before migrating whether or not it would be able to use ECN on that new = path. =20 >> >> > =20 >> >> > Thanks, =20 >> >> > Eric =20 >> >> > =20 >> >> > =20 >> >> > =20 >> >> > =20 >> >> > On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S = wrote: =20 >> >> > =20 >> >> > Hi =20 >> >> > I have written up different aspects of connection migration and = how it plays with ECN. =20 >> >> > = https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport-draft-con= nection-migration =20 >> >> > =20 >> >> > A caveat.. I am a bit unsure about the definition of connection = migration . My interpretation is that a client moves to a new IP address = due to e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is a = new connection instantiated at a connection migration ? =20 >> >> > =20 >> >> > /Ingemar =20 >> >> > =20 >> >> > =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 =20 >> >> > Ingemar Johansson M.Sc. =20 >> >> > Master Researcher =20 >> >> > =20 >> >> > Ericsson Research =20 >> >> > Network Protocols & E2E Performance =20 >> >> > Labratoriegr=C3=A4nd 11 =20 >> >> > 971 28, Lule=C3=A5, Sweden =20 >> >> > Phone +46-1071 43042 =20 >> >> > SMS/MMS +46-73 078 3289 =20 >> >> > ingemar.s.johansson@ericsson.com =20 >> >> > www.ericsson.com =20 >> >> > =20 >> >> > You can't start a fire =20 >> >> > Worrying 'bout your little world falling apart =20 >> >> > Bruce Springsteen =20 >> >> > =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 From nobody Mon Feb 12 13:01:59 2018 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 9DE64127077 for ; Mon, 12 Feb 2018 13:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.com header.b=SCd94Ync; dkim=pass (1024-bit key) header.d=ericsson.com header.b=FODZoxL2 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 1Awk3vsZIz58 for ; Mon, 12 Feb 2018 13:01:54 -0800 (PST) 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 D6373126FDC for ; Mon, 12 Feb 2018 13:01:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518469312; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sW5JJH0ARn481hHTr5ncgq6PvPYhdDGQ/9HfM9f3SOQ=; b=SCd94YncpkS8dJykIOW2t3Z/vcRHFu+L/J81EHyqNs1dQK9g3SZKvzt79ZuzQT78 9sh+0SGkGgh0uUY92EyCCki14mwNkJUo7bZarPciEl2fbz7LvrG+lcrXB2SqteLb 8n3ihN5i2BUAsSt6CB2Cw9BJ8+BX7BA2AIxeB0IzB4k=; X-AuditID: c1b4fb3a-35fff700000067b4-09-5a8200bf7c66 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 73.96.26548.FB0028A5; Mon, 12 Feb 2018 22:01:52 +0100 (CET) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 12 Feb 2018 22:01:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sW5JJH0ARn481hHTr5ncgq6PvPYhdDGQ/9HfM9f3SOQ=; b=FODZoxL2UvmaycCt5tS1zkdN/Skqu5KuxoCHRRcJw9C4H46m/R5nKnIv/eYElGP6+p7noOJFnfAPjBCC0wHvg7Bux1Y2B1VTXRWTZGH3A/uvf18BMlyINPBrVIDzlKK6BuPgeo0I1WDH6HGds1G4tk1K0G40cswlGIZ7y8Stvzg= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3756.eurprd07.prod.outlook.com (52.133.7.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Mon, 12 Feb 2018 21:01:49 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::38e6:dea0:2f4f:715]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::38e6:dea0:2f4f:715%13]) with mapi id 15.20.0506.013; Mon, 12 Feb 2018 21:01:49 +0000 From: Ingemar Johansson S To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: "ekinnear@apple.com" , QUIC WG , "Ian Swett" , Christian Huitema , "De Schepper, Koen (Nokia - BE/Antwerp)" , "Lubashev, Igor" Subject: RE: ECN in QUIC connection migration Thread-Topic: ECN in QUIC connection migration Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25AAZWcAAAB/s3/ABUaWKkACnvEWAAACMq4AAAA2PAAAAZOKAAAoPNJA= Date: Mon, 12 Feb 2018 21:01:49 +0000 Message-ID: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> <79E89348-6C18-42A7-B378-487E84E7FF31@tik.ee.ethz.ch> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [83.226.2.151] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3756; 7:blLjCrAE2/nhxOrRz8ZB/tNzPfpzt4iqTf9FT3x43cz7CZo1otyLuX0PRbkeeC/JAlyyl0t3UJ2IerKeaa/N1u9IekFl0OBXeOencMWZeo3c0JflIY5/6FEpMK7olqXw8j5jgcf5i/VTFpnIFnj0XrTrzwrHPX/G8YOfIpY0TuZD3X8NLu37+0iREf2Z31wc0K5rNMghJ58rjlsuDa2WNqnudi85E9K7R7oydtx+OakjSHVtrgqS+yBEGU24Ghn9 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d4dbb949-1031-428b-35f8-08d5725bd5de x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3756; x-ms-traffictypediagnostic: HE1PR0702MB3756: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(158342451672863)(166708455590820)(192374486261705)(101472597685257)(85827821059158)(211936372134217)(202460600054446)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231101)(944501161)(10201501046)(6041288)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR0702MB3756; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3756; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(346002)(366004)(376002)(396003)(51914003)(199004)(189003)(53936002)(102836004)(2906002)(6436002)(106356001)(7736002)(105586002)(33656002)(186003)(68736007)(54906003)(6246003)(478600001)(99286004)(110136005)(229853002)(74316002)(9686003)(25786009)(4326008)(53386004)(8666007)(316002)(55016002)(236005)(6346003)(1680700002)(54896002)(26005)(6306002)(9326002)(93886005)(5250100002)(6506007)(3660700001)(76176011)(7696005)(8936002)(2900100001)(8676002)(53546011)(966005)(81156014)(81166006)(97736004)(2950100002)(19609705001)(5660300001)(3280700002)(790700001)(66066001)(3846002)(86362001)(6116002)(606006)(14454004)(59450400001)(39060400002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3756; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-microsoft-antispam-message-info: gnQlWzJML9Y2oNYZ4KFBCe8QP0sFUlP+Oa2PFcuNZAIXB99YIOykiFgoVmolEzhLVv5+zcUOmr+3xo5T7NQcaQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB36256C450721C7D223550AC1C2F70HE1PR0702MB3625_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d4dbb949-1031-428b-35f8-08d5725bd5de X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2018 21:01:49.7243 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3756 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHe885OzsuB69L8cGScmGY5SxLOISE3Wh+EAwKZUK69KTiZbJj klq0Zn3ImWiad2t4oTTENDWdYrp5SS26QhGpZJYX7KaVurJyngV++/3/z/95n+eBlyFlkyI3 Ji4phdMmqRPktIQqCbuv8ulep1ftMs2L2OxvR9n8i2Vidmm0XcTqdbdJtv9nDcFWLXSR7N07 BRSbbVwfyCjze42ksmVwkVa2l46IlcamM8o3xUOUsrp6iVDqf1bSyv6vP+gQRiUJiOYS4lI5 re/+SEns8uMuOtlcT5xtLNAhHXpaQ2QhBwbwXugeeEFnIQkjwxYEU2NXCUE8RPB5/N6qoPAc ASZDlz1WSIB1YJASxAcEVR1FpO0xGgdArXkB2QrOOB+BYe6G2CZInEfArHWOsqU2YB9o0Q+v djhjBUxnXxIJfAr+mq6s+hT2hLe5VSs+w0hxJDRZSGHaAwr6DJm0zXfAx2CsxNEWR9gdxhZG V58nsSu8mbhpvw5DdecTUmAXmH7/RyTwFhi5ZrSzOzy/aUACtxLwujtUYAW05H2y+8Fg/pIr su0AeAhBoW7G3rwTai0W+zAN5IwWUULoGYL2zAkkiHwSpq6/tKc2wej3y/bCKxru1vXRuUhR umZ1gTVQUdEptrEUO8FgyQRVunI1ibdDg8lXiHhAgeGdWGAvuFxeIV7rG5G4DrnwHM8nxvj5 KThtXBTPa5IUSVxKE1r5fj3Nv/a1oZ7JA2aEGSR3lM4uX1TJROpUPi3RjIAh5c7S35krljRa nZbOaTUR2jMJHG9GGxlK7io9eJpVyXCMOoWL57hkTvu/SjAObjq040vvsfYLJ2+F4qBG7Y1D ORFBHx+BxSM+Id25sbUp4ITToiVw3Ep4up2bCOfKhv15/xHv+mK/jOeLuVvveZU28JWhrXkO er3VSTLv6hJWkNe9OWu+MeqIrCOyR0Kmnk9jcMYBd27PvGUpOPzl8ZCp5sMWTd+MS3ny/rZt /hnDcoqPVe/2JrW8+h/SjwzuegMAAA== 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, 12 Feb 2018 21:01:57 -0000 --_000_HE1PR0702MB36256C450721C7D223550AC1C2F70HE1PR0702MB3625_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KSSB3b3VsZCBzYXkgdGhhdCB0aGUgd29ycmllcyBhYm91dCBlbmRwb2ludHMgY2hlYXRp bmcgYWJvdXQgRUNOIG1hcmtzIGNvbmdlc3Rpb24gYXJlIHJlYWwgb2xkLCB0aGV5IGhhdmUgYXQg bGVhc3QgYmVlbiB0aGVyZSBzaW5jZSBJIGJlZ2FuIHdvcmtpbmcgd2l0aCB0aGlzIG1vcmUgdGhh biAxMCB5ZWFycyBhZ28uDQpCdXQgeW91IGRvbuKAmXQgcmVhbGx5IG5lZWQgRUNOIHRvIGNoZWF0 LiBGcm9tIGEgc2VydmVyIHBlcnNwZWN0aXZlIHlvdSBjYW4gaW1wbGVtZW50IGEgVENQIGNvbmdl c3Rpb24gY29udHJvbCBtb2R1bGUgaW4gTGludXggdGhhdCBqdXN0IGxvY2tzIENXTkQgdG8gMTUw MCBzZWdtZW50cyBvciB3aGF0ZXZlciBhbmQgeW914oCZcmUgZG9uZS4gSW4gYSBUQ1AgcmVjZWl2 ZXIgSSBndWVzcyB5b3UgY2FuIGdlbmVyYXRlIGJvZ3VzIERTQUNLcyB0byBtYWtlIHRoZSBjb25n ZXN0aW9uIHdpbmRvdyByb2xsIGJhY2sgYWZ0ZXIgYSBmYXN0IHJldHJhbnNtaXQgb3IgPw0KUHJv YmxlbSB3aXRoIHRoaXMgaXMgb2YgY291cnNlIHRoYXQgeW91IGNhbm5vdCBjb21wbGV0ZWx5IHJ1 bGUgb3V0IHRoYXQgeW91IHNwb2lsIHlvdXIgb3duIGJvdHRsZW5lY2sgaW4gdGhlIHByb2Nlc3Ms IHNvIHRoZSBvdXRjb21lIG1heSB3ZWxsIGJlIHRoYXQgeW91IGFyZSBtb3JlIGxpa2Vsa3kgdG8g Y2F1c2UgbW9yZSBoYXJtIHRvIHlvdXJzZWxmIHRoYW4gdG8gb3RoZXJzLCBlc3BlY2lhbGx5IHdp dGggdG9kYXnigJlzIHRyYWZmaWMgcGF0dGVybnMgdGhhdCBpcyBhIG1peCBvZiBzaG9ydCBhbmQg bG9uZyBsaXZlZCBmbG93cy4NCg0KQW4gaW50ZXJlc3Rpbmcgc2lkZSBub3RlIGlzIHRoYXQgcGVv cGxlIGxpa2UgQm9iIEJyaXNjb2UgKGFuZCBNaXJqYSkgc3BlbmQgcXVpdGUgYW4gZWZmb3J0IHRv IGRldmlzZSBDb25FeCAoUkZDNjc4OSkgYXMgYW4gYW5zd2VyIHRvIGFsbCB0aGVzZSBjaGVhdGlu ZyBwcm9ibGVtcywgaXQgbmV2ZXIgZ2FpbmVkIHRyYWN0aW9uIHRob3VnaCwgYXQgbGVhc3Qgbm90 IHNvIGZhci4gQnV0IEkgbGlrZWQgdGhlIGlkZWEgYW5kIHN0aWxsIGxpa2UgaXQuDQoNCkJSDQov SW5nZW1hcg0KDQoNCkZyb206IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gW21haWx0bzptaWtr ZWxmakBnbWFpbC5jb21dDQpTZW50OiBkZW4gMTIgZmVicnVhcmkgMjAxOCAxNjo1NQ0KVG86IE1p cmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+DQpDYzogZWtp bm5lYXJAYXBwbGUuY29tOyBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgSWFuIFN3ZXR0IDxpYW5z d2V0dEBnb29nbGUuY29tPjsgSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3Nv bkBlcmljc3Nvbi5jb20+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD47 IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApIDxrb2VuLmRlX3NjaGVwcGVy QG5va2lhLWJlbGwtbGFicy5jb20+OyBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNv bT4NClN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQyBjb25uZWN0aW9uIG1pZ3JhdGlvbg0KDQpJIGRv buKAmXQga25vdyBlbm91Z2ggYWJvdXQgRUNOIHRvIGhhdmUgYSBxdWFsaWZpZWQgb3Bpbmlvbiwg YnV0IEkgbWVhbiB0aGF0LCBmb3IgZXhhbXBsZSwgc29tZW9uZSBvbiB0aGUgcGF0aCBtaWdodCBt YWtlIGEgZmFsc2UgaW1wcmVzc2lvbiBvZiB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aC4gSXQgbWF5 IGJlIGEgZ2VuZXJhbCBFQ04gZGlzY3Vzc2lvbiBidXQgSeKAmWQgbGlrZSB0byBrbm93IGhvdyBp dCBhZmZlY3RzIHNlY3VyaXR5IG9mIFFVSUMgaWYgbWFkZSBtYW5kYXRvcnksIGp1c3QgbGlrZSB0 aGVyZSBhcmUgb3RoZXIgc2VjdGlvbnMgaW4gUVVJQyB0cmFuc3BvcnQgb24gcG90ZW50aWFsIGF0 dGFja3MgdG8gYmUgYXdhcmUgb2YuDQoNCmh0dHA6Ly93ZWIuY3MudWNsYS5lZHUvfnRvZGQvcmVz ZWFyY2gvc2lnY29tbTExLnBkZg0KaHR0cDovL2llZWV4cGxvcmUuaWVlZS5vcmcvZG9jdW1lbnQv Njk5MzEyNi8NCg0KDQpLaW5kIFJlZ2FyZHMsDQpNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQoN Cg0KT24gMTIgRmVicnVhcnkgMjAxOCBhdCAxNi40My40MywgTWlyamEgS8O8aGxld2luZCAobWly amEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDxtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsu ZWUuZXRoei5jaD4pIHdyb3RlOg0KV2hhdCBkbyB5b3UgbWVhbiBieSBhYnVzZSBzY2VuYXJpb3M/ IEhvd2V2ZXIsIEkgd291bGQgZ3Vlc3MgYWdhaW4gdGhhdCB0aGlzIGlzIG5vdCBhIHF1aWMgc3Bl Y2lmaWMgZGlzY3Vzc2lvbiBhbmQgc2hvdWxkIHByb2JhYmx5IHJhdGhlciBoYXBwZW4gaW4gdHN2 d2cgd2hpY2ggaXMgdGhlIGdyb3VwIHRoYXQgaXMgbWFpbnRhaW4gRUNOIGluIGdlbmVyYWwuDQoN Ck1pcmphDQoNCg0KPiBBbSAxMi4wMi4yMDE4IHVtIDE2OjQyIHNjaHJpZWIgTWlra2VsIEZhaG7D uGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5j b20+PjoNCj4NCj4gSSBoYXZlbuKAmXQgZm9sbG93ZWQgdGhlIEVDTiBkaXNjdXNzaW9uIHZlcnkg Y2xvc2VseSwgYnV0IEkgbWlzcyBhIGRpc2N1c3Npb24gb2YgcG9zc2libGUgYWJ1c2Ugc2NlbmFy aW9zIGFuZCBob3cgdG8gYXZvaWQgdGhlbS4NCj4NCj4gT24gMTIgRmVicnVhcnkgMjAxOCBhdCAx Ni4yNi4zMiwgTWlyamEgS8O8aGxld2luZCAobWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5j aDxtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4pIHdyb3RlOg0KPg0KPj4g SGkgSW5nZW1hciwNCj4+DQo+PiB0d28gcG9pbnRzLg0KPj4NCj4+IEkgdGhpbmsgaXQgd291bGQg YmUgZ29vZCB0byBiZSBhcyBleHBsaWNpdCBhcyBwb3NzaWJsZSBoZXJlLCB0aGVyZWZvcmUgSSB3 b3VsZCBwcmVmZXIgaWYgYW4gZW5kcG9pbnQgdGhhdCBrbm93cyB0aGF0IGl0IGNhbiBub3QgYWNj ZXNzIHRoZSBFQ04gSVAgYml0cyBpbmRpY2F0ZXMgdGhpcyBkaXJlY3RseSBpbiB0aGUgaGFuZHNo YWtlLiBJbiB0aGlzIGNhc2Ugbm8gZnVydGhlciB0ZXN0aW5nIGlzIG5lZWRlZC4NCj4+DQo+PiBG dXJ0aGVyLCB0aGUgcGF0aCB0ZXN0aW5nIGl0c2VsZiBpcyBpbmRlcGVuZGVudCBvZiBRVUlDIGFu ZCBjYW4gYmUgdXNlZCBmb3IgYW55IHByb3RvY29sLiBNb3Jlb3ZlciwgaXTigJlzIG1vcmUgY29t cGxpY2F0ZWQgdGhhbiBqdXN0IHRlc3RpbmcgRUNULiBJIGd1ZXNzIHRoZSBnZW5lcmFsIGFkdmlj ZSBoZXJlIGlzIHRvIHJlbWVtYmVyIHdoaWNoIGNvZGVwb2ludHMgd2VyZSBzZW5kIGFuZCBjb21w YXJlIHRoaXMgdG8gdGhlIGZlZWRiYWNrIHByb3ZpZGVkLiBJZiBkaXNjcmVwYW5jaWVzIGFyZSBv YnNlcnZlZCB0aGF0IGluZGljYXRlIHRoYXQgYSBtaWRkbGVib3ggaGFzIGNoYW5nZWQgdGhlc2Ug Yml0cywgYWxsIHBhY2tldHMgc2hvdWxkIGJlIG1hcmtlZCBhcyBuby1FQ1QgKHdoaWxlIGFkZGl0 aW9uYWwgdGVzdGluZyBNQVkgYmUgcGVyZm9ybWVkIGF0IGFueSBsYXRlciBwb2ludCBpbiB0aW1l KS4gSG93ZXZlciwgaG93IGV4YWN0bHkgdGhpcyB0ZXN0aW5nIHNob3VsZCBsb29rIGxpa2UsIHNo b3VsZCBub3QgYmUgc3BlY2lmaWVkIGluIHRoaXMgZG9jIChidXQgbW9yZSBnZW5lcmFsbHkpLg0K Pj4NCj4+IE1pcmphDQo+Pg0KPj4NCj4+ID4gQW0gMDkuMDIuMjAxOCB1bSAwODozNCBzY2hyaWVi IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPG1h aWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+Og0KPj4gPg0KPj4gPiBIaSBF cmljLCBLb2VuICsgb3RoZXJzDQo+PiA+DQo+PiA+IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIGFu ZCB0aGUgdXBkYXRlLiBBIHF1ZXN0aW9uIHRvIHRoZSByZXN0IG9mIHRoZSBhdWRpZW5jZSwgZG9l cyB0aGUgcHJlc2VudGVkIHRleHQgZXhwbGFpbiBzdWZmaWNpZW50bHkgZW5vdWdoIGhvdyBFQ04g d29ya3Mgd2l0aCBjb25uZWN0aW9uIG1pZ3JhdGlvbiA/DQo+PiA+IGh0dHBzOi8vZ2l0aHViLmNv bS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraS9FQ04taW4tUVVJQyN0cmFuc3BvcnQtZHJhZnQtY29u bmVjdGlvbi1taWdyYXRpb24NCj4+ID4NCj4+ID4NCj4+ID4gL0luZ2VtYXINCj4+ID4NCj4+ID4N Cj4+ID4gRnJvbTogRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCkgW21haWx0 bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb208bWFpbHRvOmtvZW4uZGVfc2No ZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbT5dDQo+PiA+IFNlbnQ6IGRlbiAyIGZlYnJ1YXJpIDIw MTggMTU6NDQNCj4+ID4gVG86IGVraW5uZWFyQGFwcGxlLmNvbTxtYWlsdG86ZWtpbm5lYXJAYXBw bGUuY29tPjsgSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj4NCj4+ID4gQ2M6 IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PjsgSWFuIFN3ZXR0 IDxpYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPj47IEx1YmFz aGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29t Pj47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1h QGh1aXRlbWEubmV0Pj4NCj4+ID4gU3ViamVjdDogUkU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24g bWlncmF0aW9uDQo+PiA+DQo+PiA+IEhpIEluZ2VtYXIsDQo+PiA+DQo+PiA+IEkgYWxzbyByZWFk IGFnYWluIHRocm91Z2ggdGhlIGRvY3VtZW50LCBhbmQgaGFkIGZvbGxvd2luZyBjb21tZW50czoN Cj4+ID4NCj4+ID4gSSByZXBsYWNlZDoNCj4+ID4g4oCcVGhlIEFDS19FQ04gZnJhbWUgaXMgdXNl ZCB0byBjb252ZXkgQUNLcyB3aGVuIHRoZSBFQ04gY2FwYWJpbGl0eSBleGNoYW5nZSBjb25jbHVk ZXMgdGhhdCBFQ04gc2hvdWxkIGJlIHVzZWQgZm9yIHRoZSBnaXZlbiBjb25uZWN0aW9uLuKAnQ0K Pj4gPiBPcmlnaW5hbGx5IGl0IHNvdW5kcyBhcyBpZiB0aGUgY291bnRlcnMgYXJlIG5vdCBlY2hv ZWQgYW55bW9yZSBpZiB0aGUgRUNOIGNhcGFiaWxpdHkgY2hlY2sgZmFpbHMuIEkgYXNzdW1lIHRo aXMgd2FzIG5vdCB0aGUgaW50ZW50aW9uLCBidXQgaWYgaXQgaXM6IEZpcnN0LCB3ZSBkb27igJl0 IGhhdmUgYSBwcm90b2NvbCBvciBkZWNpc2lvbiBwb2ludCBkZWZpbmVkIHdoZW4gdGhhdCBjb25k aXRpb24gaXMgbWV0IChzZW5kZXIgc2hvdWxkIGxldCB0aGUgcmVjZWl2ZXIga25vdyBpbiB0aGUg bmV4dCBwYWNrZXQpLCBhbmQgc2Vjb25kLCBJIHdvdWxkIGFsd2F5cyBzZW5kIHRoZSBlY2hvLCBh cyB3ZSBtaWdodCDigJx0cnkgYWdhaW4gbGF0ZXIgKHdpdGggYW5vdGhlciBFQ1Q/KeKAnSwgb3Ig bWlnaHQgZGVjaWRlIHRvIHVzZSB0aGUgRUNOIGJpdHMgZGlmZmVyZW50bHkgbGF0ZXIuDQo+PiA+ DQo+PiA+IEkgYWxzbyBjaGFuZ2VkIHRoZSB0ZXh0IGFyb3VuZCB0aGUgY29ubmVjdGlvbiBtaWdy YXRpb24sIEkgdGhpbmsgYmVmb3JlIEVyaWMgcmV2aWV3ZWQgaXQuIEkgbWFkZSBpdCBzdWNoIHRo YXQgZXZlcnkgbmV3IHBhdGggY3JlYXRlcyBhIG5ldyBjb25uZWN0aW9uIHN0YXRlIHdpdGggYW4g aW5pdGlhbGl6ZWQgY29uZ2VzdGlvbiBjb250cm9sIHN0YXRlIGFuZCBFQ04gY291bnRlcnMgKGF0 IGxlYXN0IEVDTiBjb3VudGVycyByZXNldCB0byAwcykuIE5vdCBzdXJlIGlmIHRoaXMgbWF0Y2hl cyB3aXRoIHRoZSBvdGhlciBzZWN0aW9ucyBpbiB0aGUgUVVJQyBkcmFmdC4NCj4+ID4NCj4+ID4g SSBhbHNvIGhhZCB0aGUgdGhvdWdodCB3aGV0aGVyIGl0IHdhcyByZWFsbHkgbmVlZGVkIHRvIGhh dmUgdGhlIDIgY2FzZXMuIEkgYWdyZWUgd2Ugc2hvdWxkIHNpbXBsaWZ5LCBieSBqdXN0IHN0YXJ0 aW5nIG92ZXIgYW5kIGRvaW5nIHRoZSBjaGVjayB1bmNvbmRpdGlvbmFsbHkgd2hldGhlciBpdCB3 YXMgc3VjY2Vzc2Z1bCBvciBub3QgaW4gYSBwcmV2aW91cyBwYXRoLg0KPj4gPg0KPj4gPiBSZWdh cmRzLA0KPj4gPiBLb2VuLg0KPj4gPg0KPj4gPiBGcm9tOiBla2lubmVhckBhcHBsZS5jb208bWFp bHRvOmVraW5uZWFyQGFwcGxlLmNvbT4gW21haWx0bzpla2lubmVhckBhcHBsZS5jb208bWFpbHRv OmVraW5uZWFyQGFwcGxlLmNvbT5dDQo+PiA+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMiwgMjAx OCAxMjowMiBBTQ0KPj4gPiBUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFu c3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29t Pj4NCj4+ID4gQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+ PjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUu Y29tPj47IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNo ZUBha2FtYWkuY29tPj47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1h aWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj47IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJF L0FudHdlcnApIDxrb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb208bWFpbHRvOmtv ZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbT4+DQo+PiA+IFN1YmplY3Q6IFJlOiBF Q04gaW4gUVVJQyBjb25uZWN0aW9uIG1pZ3JhdGlvbg0KPj4gPg0KPj4gPiBIaSBJbmdlbWFyLA0K Pj4gPg0KPj4gPiBUaGlzIGdlbmVyYWxseSBsb29rcyBnb29kIHRvIG1lIQ0KPj4gPiBBIGZldyBx dWVzdGlvbnMgYW5kIG9ic2VydmF0aW9uczoNCj4+ID4NCj4+ID4gVGhlcmUgYXJlIHR3byB1bmlx dWUgY2FzZXM6DQo+PiA+DQo+PiA+IOKAoiBFQ04gY2FwYWJpbGl0eSBjaGVjayBzdWNjZXNzZnVs IGF0IGluaXRpYWwgY29ubmVjdGlvbiBzZXR1cA0KPj4gPiDigKIgRUNOIGNhcGFiaWxpdHkgY2hl Y2sgZmFpbGVkIGF0IGluaXRpYWwgY29ubmVjdGlvbiBzZXR1cA0KPj4gPg0KPj4gPiBBcmUgdGhl c2UgYWN0dWFsbHkgYW55IGRpZmZlcmVudCBpbiB0ZXJtcyBvZiBhY3Rpb24gdGFrZW4gYnkgYW4g ZW5kcG9pbnQ/DQo+PiA+IEl0IHNlZW1zIGxpa2Ugb24gdGhlIG5ldyBuZXR3b3JrIHBhdGggdGhl IGVuZHBvaW50IHdvdWxkIGdvIHRocm91Z2ggdGhlIHNhbWUgcHJvY2VzcyBvZjogKGEpIHZlcmlm eSBFQ04gY2FwYWJpbGl0eSBhbmQgaWYgc3VjY2Vzc2Z1bCB0byB3aGF0ZXZlciBkZWdyZWUgdGhl biAoYikgcnVuIHRoZSByZXN0IG9mIHRoZSBFQ04gbWFjaGluZXJ5IGFzIGFwcHJvcHJpYXRlLg0K Pj4gPg0KPj4gPiBJbiBvdGhlciB3b3JkcywgYXMgbG9uZyBhcyB5b3UgYWxsb3cgcGVvcGxlIHRv IHN0YXJ0IHVzaW5nIEVDTiB1cG9uIG1pZ3JhdGlvbiAoaW4gb3RoZXIgd29yZHMsIHRvIGFsbG93 IHN0YXJ0aW5nIGl0IGFmdGVyIHRoZSBpbml0aWFsIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudCks IHRoZW4gdGhlIHNwZWNpZmljcyBmb3IgRUNOIHdpdGggbWlncmF0aW9uIGlzIGVzc2VudGlhbGx5 IG9uZSBzdGF0ZW1lbnQsIHdoaWNoIGlzIOKAnGRvIHRoZSBFQ04gcHJvY2VzcyBvbiBlYWNoIG5l dyBuZXR3b3JrIHBhdGggdGhhdCB5b3UgdXNl4oCdLg0KPj4gPg0KPj4gPiBDb25uZWN0aW9uIG1p Z3JhdGlvbiBoYXMgaW1wYWN0IG9uIHRoZSBudW1iZXIgb2YgcmVwb3J0ZWQgQ0UgbWFya2VkIHBh Y2tldHMuIEEgbmV3IGNvbm5lY3Rpb24gc3RhdGUgd2l0aCBuZXcgY29uZ2VzdGlvbiBjb250cm9s IHN0YXRlIGFuZCBFQ04gY291bnRlcnMgaXMgaW5zdGFudGlhdGVkIGF0IHRoZSBzZW5kZXIgYW5k IHJlY2VpdmVyLiBUaGUgRUNOIGNvdW50ZXJzIE1VU1Qgc3RhcnQgZnJvbSB6ZXJvIGFnYWluLg0K Pj4gPg0KPj4gPiBUaGlzIHNlZW1zIGZpbmUgdG8gbWUsIGl04oCZcyBpbmxpbmUgd2l0aCB0aGUg cmVzdCBvZiB0aGUgY29uZ2VzdGlvbiBjb250cm9sL2xvc3MgcmVjb3Zlcnkgc3RhdGUgdGhhdCBh bHNvIG5lZWRzIHRvIGJlIHJlc2V0IGZvciB0aGUgbmV3IHBhdGguDQo+PiA+DQo+PiA+IEdpdmVu IHRoYXQgZWFjaCBtaWdyYXRpb24gcmVxdWlyZXMgYXQgbGVhc3Qgb25lIGV4Y2hhbmdlIG9mIHBh Y2tldHMgYXQgdGhlIGJlZ2lubmluZyAoYXQgdGhlIHZlcnkgbGVhc3QgZm9yIGFkZHJlc3MgdmFs aWRhdGlvbiBmcm9tIHRoZSBzaWRlIG9mIHRoZSBlbmRwb2ludCB0aGF0IGRpZG7igJl0IG1pZ3Jh dGUpLCBpdCBzZWVtcyBsaWtlIHRoYXTigJlzIGFuIGV4Y2VsbGVudCBtb21lbnQgdG8gbWFyayB0 aGUgcGFja2V0cyBhbmQgcGVyZm9ybSB0aGUgRUNOIGNhcGFiaWxpdHkgZGV0ZWN0aW9uLiBUaG9z ZSBwYWNrZXRzIGFyZSBhbHNvIGxpa2VseSBwYWRkZWQsIGV0Yy4gc2ltaWxhciB0byBpbml0aWFs IHBhY2tldHMgc2luY2UgdGhleeKAmXJlIG9uIGEgcHJldmlvdXNseSB1bnVzZWQgbmV0d29yayBw YXRoLg0KPj4gPg0KPj4gPiBJIHRoaW5rIHRoZSBjdXJyZW50IHByb3Bvc2VkIHJlcXVpcmVtZW50 IG9mIGp1c3QgdXNpbmcgdGhlIOKAnGZpcnN04oCdIHBhY2tldHMgYW5kIG1hcmtpbmcgdGhvc2Ug aXMgc3VmZmljaWVudCAoYW5kIGdvb2QgdG8gYXZvaWQgYW55IHJlcXVpcmVtZW50IGFzIHRvIHdo aWNoIGZyYW1lcyBhcmUgY29udGFpbmVkIGluIHRob3NlIHBhY2tldHMpLCBzaW5jZSB3ZSBhcmUg YWx3YXlzIGV4Y2hhbmdpbmcgcGFja2V0cyBpbiBib3RoIGRpcmVjdGlvbnMgaW1tZWRpYXRlbHkg YWZ0ZXIgbWlncmF0aW9uLg0KPj4gPg0KPj4gPiBUaGlzIGhhcyB0aGUgYWRkZWQgYmVuZWZpdCBz dWNoIHRoYXQgYW55IGVuZHBvaW50IOKAnHByb2JpbmfigJ0gcG9zc2libGUgbmV0d29yayBwYXRo cyBjb3VsZCBpbmNsdWRlIHRoZSBiaXRzIG5lY2Vzc2FyeSB0byBkZXRlY3QgRUNOIGNhcGFiaWxp dHkgb24gdGhlIHBhdGggYmVpbmcgcHJvYmVkLCBzbyBpdCBjb3VsZCBldmVuIGtub3cgYmVmb3Jl IG1pZ3JhdGluZyB3aGV0aGVyIG9yIG5vdCBpdCB3b3VsZCBiZSBhYmxlIHRvIHVzZSBFQ04gb24g dGhhdCBuZXcgcGF0aC4NCj4+ID4NCj4+ID4gVGhhbmtzLA0KPj4gPiBFcmljDQo+PiA+DQo+PiA+ DQo+PiA+DQo+PiA+DQo+PiA+IE9uIEZlYiAxLCAyMDE4LCBhdCAzOjA3IEFNLCBJbmdlbWFyIEpv aGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTxtYWlsdG86aW5nZW1h ci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+PiB3cm90ZToNCj4+ID4NCj4+ID4gSGkNCj4+ID4g SSBoYXZlIHdyaXR0ZW4gdXAgZGlmZmVyZW50IGFzcGVjdHMgb2YgY29ubmVjdGlvbiBtaWdyYXRp b24gYW5kIGhvdyBpdCBwbGF5cyB3aXRoIEVDTi4NCj4+ID4gaHR0cHM6Ly9naXRodWIuY29tL3F1 aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1RVUlDI3RyYW5zcG9ydC1kcmFmdC1jb25uZWN0 aW9uLW1pZ3JhdGlvbg0KPj4gPg0KPj4gPiBBIGNhdmVhdC4uIEkgYW0gYSBiaXQgdW5zdXJlIGFi b3V0IHRoZSBkZWZpbml0aW9uIG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uIC4gTXkgaW50ZXJwcmV0 YXRpb24gaXMgdGhhdCBhIGNsaWVudCBtb3ZlcyB0byBhIG5ldyBJUCBhZGRyZXNzIGR1ZSB0byBl LmcuIGEgTkFUIHJlYmluZCBvciBzd2l0Y2ggZnJvbSBXaUZpIHRvIGNlbGx1bGFyLCByaWdodCA/ LiBJcyBhIG5ldyBjb25uZWN0aW9uIGluc3RhbnRpYXRlZCBhdCBhIGNvbm5lY3Rpb24gbWlncmF0 aW9uID8NCj4+ID4NCj4+ID4gL0luZ2VtYXINCj4+ID4NCj4+ID4gPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KPj4gPiBJbmdlbWFyIEpvaGFuc3NvbiBNLlNjLg0KPj4gPiBNYXN0 ZXIgUmVzZWFyY2hlcg0KPj4gPg0KPj4gPiBFcmljc3NvbiBSZXNlYXJjaA0KPj4gPiBOZXR3b3Jr IFByb3RvY29scyAmIEUyRSBQZXJmb3JtYW5jZQ0KPj4gPiBMYWJyYXRvcmllZ3LDpG5kIDExDQo+ PiA+IDk3MSAyOCwgTHVsZcOlLCBTd2VkZW4NCj4+ID4gUGhvbmUgKzQ2LTEwNzEgNDMwNDINCj4+ ID4gU01TL01NUyArNDYtNzMgMDc4IDMyODkNCj4+ID4gaW5nZW1hci5zLmpvaGFuc3NvbkBlcmlj c3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0KPj4gPiB3 d3cuZXJpY3Nzb24uY29tPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tPg0KPj4gPg0KPj4gPiBZb3Ug Y2FuJ3Qgc3RhcnQgYSBmaXJlDQo+PiA+IFdvcnJ5aW5nICdib3V0IHlvdXIgbGl0dGxlIHdvcmxk IGZhbGxpbmcgYXBhcnQNCj4+ID4gQnJ1Y2UgU3ByaW5nc3RlZW4NCj4+ID4gPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0K --_000_HE1PR0702MB36256C450721C7D223550AC1C2F70HE1PR0702MB3625_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFp bG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFp bF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQg NzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBzYXkgdGhhdCB0aGUgd29y cmllcyBhYm91dCBlbmRwb2ludHMgY2hlYXRpbmcgYWJvdXQgRUNOIG1hcmtzIGNvbmdlc3Rpb24g YXJlIHJlYWwgb2xkLCB0aGV5IGhhdmUgYXQgbGVhc3QgYmVlbiB0aGVyZSBzaW5jZSBJIGJlZ2Fu IHdvcmtpbmcgd2l0aCB0aGlzIG1vcmUgdGhhbiAxMCB5ZWFycyBhZ28uDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB5b3UgZG9u4oCZdCByZWFsbHkgbmVlZCBFQ04g dG8gY2hlYXQuIEZyb20gYSBzZXJ2ZXIgcGVyc3BlY3RpdmUgeW91IGNhbiBpbXBsZW1lbnQgYSBU Q1AgY29uZ2VzdGlvbiBjb250cm9sIG1vZHVsZSBpbiBMaW51eCB0aGF0IGp1c3QgbG9ja3MgQ1dO RCB0byAxNTAwIHNlZ21lbnRzIG9yIHdoYXRldmVyIGFuZCB5b3XigJlyZSBkb25lLiBJbiBhIFRD UCByZWNlaXZlciBJIGd1ZXNzIHlvdSBjYW4gZ2VuZXJhdGUgYm9ndXMNCiBEU0FDS3MgdG8gbWFr ZSB0aGUgY29uZ2VzdGlvbiB3aW5kb3cgcm9sbCBiYWNrIGFmdGVyIGEgZmFzdCByZXRyYW5zbWl0 IG9yID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlByb2JsZW0gd2l0aCB0 aGlzIGlzIG9mIGNvdXJzZSB0aGF0IHlvdSBjYW5ub3QgY29tcGxldGVseSBydWxlIG91dCB0aGF0 IHlvdSBzcG9pbCB5b3VyIG93biBib3R0bGVuZWNrIGluIHRoZSBwcm9jZXNzLCBzbyB0aGUgb3V0 Y29tZSBtYXkgd2VsbCBiZSB0aGF0IHlvdSBhcmUgbW9yZSBsaWtlbGt5IHRvIGNhdXNlIG1vcmUg aGFybSB0byB5b3Vyc2VsZiB0aGFuIHRvIG90aGVycywgZXNwZWNpYWxseSB3aXRoIHRvZGF54oCZ cw0KIHRyYWZmaWMgcGF0dGVybnMgdGhhdCBpcyBhIG1peCBvZiBzaG9ydCBhbmQgbG9uZyBsaXZl ZCBmbG93cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW4gaW50ZXJlc3Rpbmcgc2lkZSBub3Rl IGlzIHRoYXQgcGVvcGxlIGxpa2UgQm9iIEJyaXNjb2UgKGFuZCBNaXJqYSkgc3BlbmQgcXVpdGUg YW4gZWZmb3J0IHRvIGRldmlzZSBDb25FeCAoUkZDNjc4OSkgYXMgYW4gYW5zd2VyIHRvIGFsbCB0 aGVzZSBjaGVhdGluZyBwcm9ibGVtcywgaXQgbmV2ZXIgZ2FpbmVkIHRyYWN0aW9uIHRob3VnaCwg YXQgbGVhc3Qgbm90IHNvIGZhci4gQnV0IEkgbGlrZWQgdGhlIGlkZWENCiBhbmQgc3RpbGwgbGlr ZSBpdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QlI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWlra2VsIEZh aG7DuGUgSsO4cmdlbnNlbiBbbWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBkZW4gMTIgZmVicnVhcmkgMjAxOCAxNjo1NTxicj4NCjxiPlRvOjwvYj4gTWlyamEg S8O8aGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCZndDs8YnI+DQo8 Yj5DYzo8L2I+IGVraW5uZWFyQGFwcGxlLmNvbTsgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZn dDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7IEluZ2VtYXIgSm9oYW5z c29uIFMgJmx0O2luZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0OzsgQ2hyaXN0aWFu IEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7OyBEZSBTY2hlcHBlciwgS29lbiAo Tm9raWEgLSBCRS9BbnR3ZXJwKSAmbHQ7a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMu Y29tJmd0OzsNCiBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvbuKAmXQga25vdyBlbm91Z2ggYWJvdXQg RUNOIHRvIGhhdmUgYSBxdWFsaWZpZWQgb3BpbmlvbiwgYnV0IEkgbWVhbiB0aGF0LCBmb3IgZXhh bXBsZSwgc29tZW9uZSBvbiB0aGUgcGF0aCBtaWdodCBtYWtlIGEgZmFsc2UgaW1wcmVzc2lvbiBv ZiB0aGUgYXZhaWxhYmxlIGJhbmR3aWR0aC4gSXQNCiBtYXkgYmUgYSBnZW5lcmFsIEVDTiBkaXNj dXNzaW9uIGJ1dCBJ4oCZZCBsaWtlIHRvIGtub3cgaG93IGl0IGFmZmVjdHMgc2VjdXJpdHkgb2Yg UVVJQyBpZiBtYWRlIG1hbmRhdG9yeSwganVzdCBsaWtlIHRoZXJlIGFyZSBvdGhlciBzZWN0aW9u cyBpbiBRVUlDIHRyYW5zcG9ydCBvbiBwb3RlbnRpYWwgYXR0YWNrcyB0byBiZSBhd2FyZSBvZi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cDovL3dlYi5j cy51Y2xhLmVkdS9+dG9kZC9yZXNlYXJjaC9zaWdjb21tMTEucGRmIj5odHRwOi8vd2ViLmNzLnVj bGEuZWR1L350b2RkL3Jlc2VhcmNoL3NpZ2NvbW0xMS5wZGY8L2E+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwOi8vaWVlZXhwbG9yZS5pZWVl Lm9yZy9kb2N1bWVudC82OTkzMTI2LyI+aHR0cDovL2llZWV4cGxvcmUuaWVlZS5vcmcvZG9jdW1l bnQvNjk5MzEyNi88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJi bG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IGlkPSJibG9vcF9zaWduXzE1MTg0NTAyNTczMzAwNTQxNDQiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LaW5kIFJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlra2VsIEZhaG7DuGUgSsO4cmdl bnNlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9ImFpcm1haWxvbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDEyIEZlYnJ1YXJ5IDIw MTggYXQgMTYuNDMuNDMsIE1pcmphIEvDvGhsZXdpbmQgKDxhIGhyZWY9Im1haWx0bzptaXJqYS5r dWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNo PC9hPikgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPldoYXQgZG8geW91IG1lYW4gYnkgYWJ1c2Ugc2NlbmFyaW9zPyBIb3dldmVyLCBJIHdv dWxkIGd1ZXNzIGFnYWluIHRoYXQgdGhpcyBpcyBub3QgYSBxdWljIHNwZWNpZmljIGRpc2N1c3Np b24gYW5kIHNob3VsZCBwcm9iYWJseSByYXRoZXIgaGFwcGVuDQogaW4gdHN2d2cgd2hpY2ggaXMg dGhlIGdyb3VwIHRoYXQgaXMgbWFpbnRhaW4gRUNOIGluIGdlbmVyYWwuIDxicj4NCjxicj4NCk1p cmphIDxicj4NCjxicj4NCjxicj4NCiZndDsgQW0gMTIuMDIuMjAxOCB1bSAxNjo0MiBzY2hyaWVi IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBn bWFpbC5jb20iPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7Og0KPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEkgaGF2ZW7igJl0IGZvbGxvd2VkIHRoZSBFQ04gZGlzY3Vzc2lvbiB2ZXJ5IGNsb3NlbHks IGJ1dCBJIG1pc3MgYSBkaXNjdXNzaW9uIG9mIHBvc3NpYmxlIGFidXNlIHNjZW5hcmlvcyBhbmQg aG93IHRvIGF2b2lkIHRoZW0uDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gMTIgRmVicnVhcnkg MjAxOCBhdCAxNi4yNi4zMiwgTWlyamEgS8O8aGxld2luZCAoPGEgaHJlZj0ibWFpbHRvOm1pcmph Lmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2giPm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHou Y2g8L2E+KSB3cm90ZToNCjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgSGkgSW5nZW1hciwgPGJy Pg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgdHdvIHBvaW50cy4gPGJyPg0KJmd0OyZndDsgPGJy Pg0KJmd0OyZndDsgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGJlIGFzIGV4cGxpY2l0IGFz IHBvc3NpYmxlIGhlcmUsIHRoZXJlZm9yZSBJIHdvdWxkIHByZWZlciBpZiBhbiBlbmRwb2ludCB0 aGF0IGtub3dzIHRoYXQgaXQgY2FuIG5vdCBhY2Nlc3MgdGhlIEVDTiBJUCBiaXRzIGluZGljYXRl cyB0aGlzIGRpcmVjdGx5IGluIHRoZSBoYW5kc2hha2UuIEluIHRoaXMgY2FzZSBubyBmdXJ0aGVy IHRlc3RpbmcgaXMgbmVlZGVkLg0KPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgRnVydGhl ciwgdGhlIHBhdGggdGVzdGluZyBpdHNlbGYgaXMgaW5kZXBlbmRlbnQgb2YgUVVJQyBhbmQgY2Fu IGJlIHVzZWQgZm9yIGFueSBwcm90b2NvbC4gTW9yZW92ZXIsIGl04oCZcyBtb3JlIGNvbXBsaWNh dGVkIHRoYW4ganVzdCB0ZXN0aW5nIEVDVC4gSSBndWVzcyB0aGUgZ2VuZXJhbCBhZHZpY2UgaGVy ZSBpcyB0byByZW1lbWJlciB3aGljaCBjb2RlcG9pbnRzIHdlcmUgc2VuZCBhbmQgY29tcGFyZSB0 aGlzIHRvIHRoZSBmZWVkYmFjayBwcm92aWRlZC4NCiBJZiBkaXNjcmVwYW5jaWVzIGFyZSBvYnNl cnZlZCB0aGF0IGluZGljYXRlIHRoYXQgYSBtaWRkbGVib3ggaGFzIGNoYW5nZWQgdGhlc2UgYml0 cywgYWxsIHBhY2tldHMgc2hvdWxkIGJlIG1hcmtlZCBhcyBuby1FQ1QgKHdoaWxlIGFkZGl0aW9u YWwgdGVzdGluZyBNQVkgYmUgcGVyZm9ybWVkIGF0IGFueSBsYXRlciBwb2ludCBpbiB0aW1lKS4g SG93ZXZlciwgaG93IGV4YWN0bHkgdGhpcyB0ZXN0aW5nIHNob3VsZCBsb29rIGxpa2UsIHNob3Vs ZCBub3QNCiBiZSBzcGVjaWZpZWQgaW4gdGhpcyBkb2MgKGJ1dCBtb3JlIGdlbmVyYWxseSkuIDxi cj4NCiZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IE1pcmphIDxicj4NCiZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDsgQW0gMDkuMDIuMjAxOCB1bSAwODozNCBzY2hyaWVi IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0OzxhIGhyZWY9Im1haWx0bzppbmdlbWFyLnMuam9oYW5z c29uQGVyaWNzc29uLmNvbSI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L2E+Jmd0 OzoNCjxicj4NCiZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsgJmd0OyBIaSBFcmljLCBLb2Vu ICYjNDM7IG90aGVycyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDsgVGhh bmtzIGZvciB0aGUgY29tbWVudHMgYW5kIHRoZSB1cGRhdGUuIEEgcXVlc3Rpb24gdG8gdGhlIHJl c3Qgb2YgdGhlIGF1ZGllbmNlLCBkb2VzIHRoZSBwcmVzZW50ZWQgdGV4dCBleHBsYWluIHN1ZmZp Y2llbnRseSBlbm91Z2ggaG93IEVDTiB3b3JrcyB3aXRoIGNvbm5lY3Rpb24gbWlncmF0aW9uID8N Cjxicj4NCiZndDsmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9i YXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1RVUlDI3RyYW5zcG9ydC1kcmFmdC1jb25uZWN0aW9uLW1p Z3JhdGlvbiI+DQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvRUNO LWluLVFVSUMjdHJhbnNwb3J0LWRyYWZ0LWNvbm5lY3Rpb24tbWlncmF0aW9uPC9hPg0KPGJyPg0K Jmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDsgL0lu Z2VtYXIgPGJyPg0KJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsm Z3Q7ICZndDsgRnJvbTogRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCkgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29t Ij5rb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb208L2E+XQ0KPGJyPg0KJmd0OyZn dDsgJmd0OyBTZW50OiBkZW4gMiBmZWJydWFyaSAyMDE4IDE1OjQ0IDxicj4NCiZndDsmZ3Q7ICZn dDsgVG86IDxhIGhyZWY9Im1haWx0bzpla2lubmVhckBhcHBsZS5jb20iPmVraW5uZWFyQGFwcGxl LmNvbTwvYT47IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0OzxhIGhyZWY9Im1haWx0bzppbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5j b208L2E+Jmd0Ow0KPGJyPg0KJmd0OyZndDsgJmd0OyBDYzogUVVJQyBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzsgSWFuIFN3ZXR0ICZs dDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSI+aWFuc3dldHRAZ29vZ2xlLmNv bTwvYT4mZ3Q7OyBMdWJhc2hldiwgSWdvciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFr YW1haS5jb20iPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OzsgQ2hyaXN0aWFuIEh1aXRlbWEg Jmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Ij5odWl0ZW1hQGh1aXRlbWEu bmV0PC9hPiZndDsNCjxicj4NCiZndDsmZ3Q7ICZndDsgU3ViamVjdDogUkU6IEVDTiBpbiBRVUlD IGNvbm5lY3Rpb24gbWlncmF0aW9uIDxicj4NCiZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsg Jmd0OyBIaSBJbmdlbWFyLCA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDsg SSBhbHNvIHJlYWQgYWdhaW4gdGhyb3VnaCB0aGUgZG9jdW1lbnQsIGFuZCBoYWQgZm9sbG93aW5n IGNvbW1lbnRzOiA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDsgSSByZXBs YWNlZDogPGJyPg0KJmd0OyZndDsgJmd0OyDigJxUaGUgQUNLX0VDTiBmcmFtZSBpcyB1c2VkIHRv IGNvbnZleSBBQ0tzIHdoZW4gdGhlIEVDTiBjYXBhYmlsaXR5IGV4Y2hhbmdlIGNvbmNsdWRlcyB0 aGF0IEVDTiBzaG91bGQgYmUgdXNlZCBmb3IgdGhlIGdpdmVuIGNvbm5lY3Rpb24u4oCdDQo8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7IE9yaWdpbmFsbHkgaXQgc291bmRzIGFzIGlmIHRoZSBjb3VudGVycyBh cmUgbm90IGVjaG9lZCBhbnltb3JlIGlmIHRoZSBFQ04gY2FwYWJpbGl0eSBjaGVjayBmYWlscy4g SSBhc3N1bWUgdGhpcyB3YXMgbm90IHRoZSBpbnRlbnRpb24sIGJ1dCBpZiBpdCBpczogRmlyc3Qs IHdlIGRvbuKAmXQgaGF2ZSBhIHByb3RvY29sIG9yIGRlY2lzaW9uIHBvaW50IGRlZmluZWQgd2hl biB0aGF0IGNvbmRpdGlvbiBpcyBtZXQgKHNlbmRlciBzaG91bGQgbGV0DQogdGhlIHJlY2VpdmVy IGtub3cgaW4gdGhlIG5leHQgcGFja2V0KSwgYW5kIHNlY29uZCwgSSB3b3VsZCBhbHdheXMgc2Vu ZCB0aGUgZWNobywgYXMgd2UgbWlnaHQg4oCcdHJ5IGFnYWluIGxhdGVyICh3aXRoIGFub3RoZXIg RUNUPynigJ0sIG9yIG1pZ2h0IGRlY2lkZSB0byB1c2UgdGhlIEVDTiBiaXRzIGRpZmZlcmVudGx5 IGxhdGVyLg0KPGJyPg0KJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEkgYWxzbyBj aGFuZ2VkIHRoZSB0ZXh0IGFyb3VuZCB0aGUgY29ubmVjdGlvbiBtaWdyYXRpb24sIEkgdGhpbmsg YmVmb3JlIEVyaWMgcmV2aWV3ZWQgaXQuIEkgbWFkZSBpdCBzdWNoIHRoYXQgZXZlcnkgbmV3IHBh dGggY3JlYXRlcyBhIG5ldyBjb25uZWN0aW9uIHN0YXRlIHdpdGggYW4gaW5pdGlhbGl6ZWQgY29u Z2VzdGlvbiBjb250cm9sIHN0YXRlIGFuZCBFQ04gY291bnRlcnMgKGF0IGxlYXN0IEVDTiBjb3Vu dGVycyByZXNldCB0byAwcykuDQogTm90IHN1cmUgaWYgdGhpcyBtYXRjaGVzIHdpdGggdGhlIG90 aGVyIHNlY3Rpb25zIGluIHRoZSBRVUlDIGRyYWZ0LiA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4N CiZndDsmZ3Q7ICZndDsgSSBhbHNvIGhhZCB0aGUgdGhvdWdodCB3aGV0aGVyIGl0IHdhcyByZWFs bHkgbmVlZGVkIHRvIGhhdmUgdGhlIDIgY2FzZXMuIEkgYWdyZWUgd2Ugc2hvdWxkIHNpbXBsaWZ5 LCBieSBqdXN0IHN0YXJ0aW5nIG92ZXIgYW5kIGRvaW5nIHRoZSBjaGVjayB1bmNvbmRpdGlvbmFs bHkgd2hldGhlciBpdCB3YXMgc3VjY2Vzc2Z1bCBvciBub3QgaW4gYSBwcmV2aW91cyBwYXRoLg0K PGJyPg0KJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFJlZ2FyZHMsIDxicj4NCiZn dDsmZ3Q7ICZndDsgS29lbi4gPGJyPg0KJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7 IEZyb206IDxhIGhyZWY9Im1haWx0bzpla2lubmVhckBhcHBsZS5jb20iPmVraW5uZWFyQGFwcGxl LmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86ZWtpbm5lYXJAYXBwbGUuY29tIj5la2lu bmVhckBhcHBsZS5jb208L2E+XQ0KPGJyPg0KJmd0OyZndDsgJmd0OyBTZW50OiBGcmlkYXksIEZl YnJ1YXJ5IDIsIDIwMTggMTI6MDIgQU0gPGJyPg0KJmd0OyZndDsgJmd0OyBUbzogSW5nZW1hciBK b2hhbnNzb24gUyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nz b24uY29tIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7DQo8YnI+DQom Z3Q7Jmd0OyAmZ3Q7IENjOiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9y ZyI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7OyBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzpp YW5zd2V0dEBnb29nbGUuY29tIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDs7IEx1YmFzaGV2 LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVA YWthbWFpLmNvbTwvYT4mZ3Q7OyBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRv Omh1aXRlbWFAaHVpdGVtYS5uZXQiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0OzsNCiBEZSBT Y2hlcHBlciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJwKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtv ZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbSI+a29lbi5kZV9zY2hlcHBlckBub2tp YS1iZWxsLWxhYnMuY29tPC9hPiZndDsNCjxicj4NCiZndDsmZ3Q7ICZndDsgU3ViamVjdDogUmU6 IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uIDxicj4NCiZndDsmZ3Q7ICZndDsgPGJy Pg0KJmd0OyZndDsgJmd0OyBIaSBJbmdlbWFyLCA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZn dDsmZ3Q7ICZndDsgVGhpcyBnZW5lcmFsbHkgbG9va3MgZ29vZCB0byBtZSEgPGJyPg0KJmd0OyZn dDsgJmd0OyBBIGZldyBxdWVzdGlvbnMgYW5kIG9ic2VydmF0aW9uczogPGJyPg0KJmd0OyZndDsg Jmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFRoZXJlIGFyZSB0d28gdW5pcXVlIGNhc2VzOiA8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDsg4oCiIEVDTiBjYXBhYmlsaXR5IGNo ZWNrIHN1Y2Nlc3NmdWwgYXQgaW5pdGlhbCBjb25uZWN0aW9uIHNldHVwIDxicj4NCiZndDsmZ3Q7 ICZndDsg4oCiIEVDTiBjYXBhYmlsaXR5IGNoZWNrIGZhaWxlZCBhdCBpbml0aWFsIGNvbm5lY3Rp b24gc2V0dXAgPGJyPg0KJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEFyZSB0aGVz ZSBhY3R1YWxseSBhbnkgZGlmZmVyZW50IGluIHRlcm1zIG9mIGFjdGlvbiB0YWtlbiBieSBhbiBl bmRwb2ludD8gPGJyPg0KJmd0OyZndDsgJmd0OyBJdCBzZWVtcyBsaWtlIG9uIHRoZSBuZXcgbmV0 d29yayBwYXRoIHRoZSBlbmRwb2ludCB3b3VsZCBnbyB0aHJvdWdoIHRoZSBzYW1lIHByb2Nlc3Mg b2Y6IChhKSB2ZXJpZnkgRUNOIGNhcGFiaWxpdHkgYW5kIGlmIHN1Y2Nlc3NmdWwgdG8gd2hhdGV2 ZXIgZGVncmVlIHRoZW4gKGIpIHJ1biB0aGUgcmVzdCBvZiB0aGUgRUNOIG1hY2hpbmVyeSBhcyBh cHByb3ByaWF0ZS4NCjxicj4NCiZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsgJmd0OyBJbiBv dGhlciB3b3JkcywgYXMgbG9uZyBhcyB5b3UgYWxsb3cgcGVvcGxlIHRvIHN0YXJ0IHVzaW5nIEVD TiB1cG9uIG1pZ3JhdGlvbiAoaW4gb3RoZXIgd29yZHMsIHRvIGFsbG93IHN0YXJ0aW5nIGl0IGFm dGVyIHRoZSBpbml0aWFsIGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudCksIHRoZW4gdGhlIHNwZWNp ZmljcyBmb3IgRUNOIHdpdGggbWlncmF0aW9uIGlzIGVzc2VudGlhbGx5IG9uZSBzdGF0ZW1lbnQs IHdoaWNoIGlzIOKAnGRvIHRoZSBFQ04NCiBwcm9jZXNzIG9uIGVhY2ggbmV3IG5ldHdvcmsgcGF0 aCB0aGF0IHlvdSB1c2XigJ0uIDxicj4NCiZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsgJmd0 OyBDb25uZWN0aW9uIG1pZ3JhdGlvbiBoYXMgaW1wYWN0IG9uIHRoZSBudW1iZXIgb2YgcmVwb3J0 ZWQgQ0UgbWFya2VkIHBhY2tldHMuIEEgbmV3IGNvbm5lY3Rpb24gc3RhdGUgd2l0aCBuZXcgY29u Z2VzdGlvbiBjb250cm9sIHN0YXRlIGFuZCBFQ04gY291bnRlcnMgaXMgaW5zdGFudGlhdGVkIGF0 IHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyLiBUaGUgRUNOIGNvdW50ZXJzIE1VU1Qgc3RhcnQgZnJv bSB6ZXJvIGFnYWluLg0KPGJyPg0KJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFRo aXMgc2VlbXMgZmluZSB0byBtZSwgaXTigJlzIGlubGluZSB3aXRoIHRoZSByZXN0IG9mIHRoZSBj b25nZXN0aW9uIGNvbnRyb2wvbG9zcyByZWNvdmVyeSBzdGF0ZSB0aGF0IGFsc28gbmVlZHMgdG8g YmUgcmVzZXQgZm9yIHRoZSBuZXcgcGF0aC4NCjxicj4NCiZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0 OyZndDsgJmd0OyBHaXZlbiB0aGF0IGVhY2ggbWlncmF0aW9uIHJlcXVpcmVzIGF0IGxlYXN0IG9u ZSBleGNoYW5nZSBvZiBwYWNrZXRzIGF0IHRoZSBiZWdpbm5pbmcgKGF0IHRoZSB2ZXJ5IGxlYXN0 IGZvciBhZGRyZXNzIHZhbGlkYXRpb24gZnJvbSB0aGUgc2lkZSBvZiB0aGUgZW5kcG9pbnQgdGhh dCBkaWRu4oCZdCBtaWdyYXRlKSwgaXQgc2VlbXMgbGlrZSB0aGF04oCZcyBhbiBleGNlbGxlbnQg bW9tZW50IHRvIG1hcmsgdGhlIHBhY2tldHMgYW5kIHBlcmZvcm0NCiB0aGUgRUNOIGNhcGFiaWxp dHkgZGV0ZWN0aW9uLiBUaG9zZSBwYWNrZXRzIGFyZSBhbHNvIGxpa2VseSBwYWRkZWQsIGV0Yy4g c2ltaWxhciB0byBpbml0aWFsIHBhY2tldHMgc2luY2UgdGhleeKAmXJlIG9uIGEgcHJldmlvdXNs eSB1bnVzZWQgbmV0d29yayBwYXRoLg0KPGJyPg0KJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0 OyAmZ3Q7IEkgdGhpbmsgdGhlIGN1cnJlbnQgcHJvcG9zZWQgcmVxdWlyZW1lbnQgb2YganVzdCB1 c2luZyB0aGUg4oCcZmlyc3TigJ0gcGFja2V0cyBhbmQgbWFya2luZyB0aG9zZSBpcyBzdWZmaWNp ZW50IChhbmQgZ29vZCB0byBhdm9pZCBhbnkgcmVxdWlyZW1lbnQgYXMgdG8gd2hpY2ggZnJhbWVz IGFyZSBjb250YWluZWQgaW4gdGhvc2UgcGFja2V0cyksIHNpbmNlIHdlIGFyZSBhbHdheXMgZXhj aGFuZ2luZyBwYWNrZXRzIGluIGJvdGggZGlyZWN0aW9ucw0KIGltbWVkaWF0ZWx5IGFmdGVyIG1p Z3JhdGlvbi4gPGJyPg0KJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IFRoaXMgaGFz IHRoZSBhZGRlZCBiZW5lZml0IHN1Y2ggdGhhdCBhbnkgZW5kcG9pbnQg4oCccHJvYmluZ+KAnSBw b3NzaWJsZSBuZXR3b3JrIHBhdGhzIGNvdWxkIGluY2x1ZGUgdGhlIGJpdHMgbmVjZXNzYXJ5IHRv IGRldGVjdCBFQ04gY2FwYWJpbGl0eSBvbiB0aGUgcGF0aCBiZWluZyBwcm9iZWQsIHNvIGl0IGNv dWxkIGV2ZW4ga25vdyBiZWZvcmUgbWlncmF0aW5nIHdoZXRoZXIgb3Igbm90IGl0IHdvdWxkIGJl IGFibGUgdG8gdXNlIEVDTiBvbg0KIHRoYXQgbmV3IHBhdGguIDxicj4NCiZndDsmZ3Q7ICZndDsg PGJyPg0KJmd0OyZndDsgJmd0OyBUaGFua3MsIDxicj4NCiZndDsmZ3Q7ICZndDsgRXJpYyA8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsgJmd0OyA8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDsgT24gRmViIDEsIDIwMTgsIGF0 IDM6MDcgQU0sIEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0OzxhIGhyZWY9Im1haWx0bzppbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5j b208L2E+Jmd0OyB3cm90ZToNCjxicj4NCiZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsgJmd0 OyBIaSA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEkgaGF2ZSB3cml0dGVuIHVwIGRpZmZlcmVudCBhc3Bl Y3RzIG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uIGFuZCBob3cgaXQgcGxheXMgd2l0aCBFQ04uDQo8 YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFz ZS1kcmFmdHMvd2lraS9FQ04taW4tUVVJQyN0cmFuc3BvcnQtZHJhZnQtY29ubmVjdGlvbi1taWdy YXRpb24iPg0KaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1p bi1RVUlDI3RyYW5zcG9ydC1kcmFmdC1jb25uZWN0aW9uLW1pZ3JhdGlvbjwvYT4NCjxicj4NCiZn dDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsgJmd0OyBBIGNhdmVhdC4uIEkgYW0gYSBiaXQgdW5z dXJlIGFib3V0IHRoZSBkZWZpbml0aW9uIG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uIC4gTXkgaW50 ZXJwcmV0YXRpb24gaXMgdGhhdCBhIGNsaWVudCBtb3ZlcyB0byBhIG5ldyBJUCBhZGRyZXNzIGR1 ZSB0byBlLmcuIGEgTkFUIHJlYmluZCBvciBzd2l0Y2ggZnJvbSBXaUZpIHRvIGNlbGx1bGFyLCBy aWdodCA/LiBJcyBhIG5ldyBjb25uZWN0aW9uIGluc3RhbnRpYXRlZCBhdCBhIGNvbm5lY3Rpb24N CiBtaWdyYXRpb24gPyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7ICZndDsgL0lu Z2VtYXIgPGJyPg0KJmd0OyZndDsgJmd0OyA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7ID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0gPGJyPg0KJmd0OyZndDsgJmd0OyBJbmdlbWFyIEpvaGFu c3NvbiBNLlNjLiA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IE1hc3RlciBSZXNlYXJjaGVyIDxicj4NCiZn dDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsgJmd0OyBFcmljc3NvbiBSZXNlYXJjaCA8YnI+DQom Z3Q7Jmd0OyAmZ3Q7IE5ldHdvcmsgUHJvdG9jb2xzICZhbXA7IEUyRSBQZXJmb3JtYW5jZSA8YnI+ DQomZ3Q7Jmd0OyAmZ3Q7IExhYnJhdG9yaWVncsOkbmQgMTEgPGJyPg0KJmd0OyZndDsgJmd0OyA5 NzEgMjgsIEx1bGXDpSwgU3dlZGVuIDxicj4NCiZndDsmZ3Q7ICZndDsgUGhvbmUgJiM0Mzs0Ni0x MDcxIDQzMDQyIDxicj4NCiZndDsmZ3Q7ICZndDsgU01TL01NUyAmIzQzOzQ2LTczIDA3OCAzMjg5 IDxicj4NCiZndDsmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25A ZXJpY3Nzb24uY29tIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT4NCjxicj4N CiZndDsmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cDovL3d3dy5lcmljc3Nvbi5jb20iPnd3dy5lcmlj c3Nvbi5jb208L2E+IDxicj4NCiZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsgJmd0OyBZb3Ug Y2FuJ3Qgc3RhcnQgYSBmaXJlIDxicj4NCiZndDsmZ3Q7ICZndDsgV29ycnlpbmcgJ2JvdXQgeW91 ciBsaXR0bGUgd29ybGQgZmFsbGluZyBhcGFydCA8YnI+DQomZ3Q7Jmd0OyAmZ3Q7IEJydWNlIFNw cmluZ3N0ZWVuIDxicj4NCiZndDsmZ3Q7ICZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_HE1PR0702MB36256C450721C7D223550AC1C2F70HE1PR0702MB3625_-- From nobody Mon Feb 12 13:12:04 2018 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 2207C12D94D for ; Mon, 12 Feb 2018 13:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.com header.b=ZjVf4t2I; dkim=pass (1024-bit key) header.d=ericsson.com header.b=A648h21w 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 jJEnlkPC-M6y for ; Mon, 12 Feb 2018 13:12:01 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 13825126FDC for ; Mon, 12 Feb 2018 13:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518469919; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=k4N+FTwF3dNDV+MaxFXbyy16Wnui2tdVpLP3GvdFhTg=; b=ZjVf4t2IVVDD0IzBv8feWMDm7YOg66IR+0bNzRhzCs/P4Zuoh1TRcUG54WopOxZF GLuvvtlSXmp9krtewjCnRevFBrjTiTmBqb2JqAO7k2RybEbImvS6piJAqT7Dqqgd 2pQJxJofpkTirMOMNJ92KwSwVvkrW8FDlzfF8oNT6NE=; X-AuditID: c1b4fb30-399ff70000004778-a3-5a82031eba77 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 54.FE.18296.E13028A5; Mon, 12 Feb 2018 22:11:59 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 12 Feb 2018 22:11:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k4N+FTwF3dNDV+MaxFXbyy16Wnui2tdVpLP3GvdFhTg=; b=A648h21w60DRWeFE/ALkeXq5dN0QkAVdr3YKrhHt8bzauTCB3GIUnytwRqbDwsE9ZOgpmSTkgzQgrjh35y7HTpZ/lD8gsdRnRJ0uWserJNPlthIyVEjlNd4aPAkc4mjN62XruO8J+9/+fP+ljKP+tDW9txMlQaeE8S4EIg7lPhs= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3705.eurprd07.prod.outlook.com (52.133.6.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Mon, 12 Feb 2018 21:11:56 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::38e6:dea0:2f4f:715]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::38e6:dea0:2f4f:715%13]) with mapi id 15.20.0506.013; Mon, 12 Feb 2018 21:11:56 +0000 From: Ingemar Johansson S To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: "De Schepper, Koen (Nokia - BE/Antwerp)" , "ekinnear@apple.com" , "Lubashev, Igor" , Ian Swett , QUIC WG , Christian Huitema Subject: RE: ECN in QUIC connection migration Thread-Topic: ECN in QUIC connection migration Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25AAZWcAAAB/s3/ABUaWKkACnvEWAAAvBcBA= Date: Mon, 12 Feb 2018 21:11:56 +0000 Message-ID: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [83.226.2.151] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3705; 7:glbuz5qk8i5CH2iLzsPgzCJenehGTXExeLR63c+/eMjUawkHX+csYT1uyFSKYPe+JtW2mK92er98YPpllORNuCPtA+0YO/1f17X2ySMJOmgufcqFMkr3UPjj3o8AjQhn4cVQ9OpIOPy54esm/jBW7EgRzM9J9s2IN8H9Ds8Huh2MZHpN/DmIT08PosXnWRiMPPLZjyw8kBlIGMaYhoXJGKGtjHSCO7mOJ/d5V/mb07prknt103D24+GfuCVncUsQ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7c96a01b-8481-44a0-eee5-08d5725d3f87 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3705; x-ms-traffictypediagnostic: HE1PR0702MB3705: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(211936372134217)(100405760836317)(202460600054446)(153496737603132)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(2400082)(944501161)(93006095)(93001095)(6041288)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0702MB3705; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3705; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(39380400002)(366004)(396003)(346002)(51914003)(189003)(199004)(13464003)(5660300001)(4326008)(7696005)(68736007)(106356001)(25786009)(5250100002)(478600001)(33656002)(93886005)(966005)(4743002)(105586002)(2900100001)(54906003)(99286004)(14454004)(316002)(3280700002)(3660700001)(26005)(102836004)(7736002)(305945005)(186003)(66066001)(76176011)(53546011)(6506007)(59450400001)(2906002)(53936002)(6246003)(15974865002)(97736004)(74316002)(6436002)(6306002)(9686003)(8666007)(55016002)(6916009)(81166006)(229853002)(2950100002)(8676002)(6116002)(86362001)(81156014)(3846002)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3705; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: v2K2OtXUuNE4jbZm8e2uQocxS2BlZdLbg+jt2LJaWmN6BoPZ4HMvHxYCmHZf3LUiJV++42AiTcLZsRjvC2j6VA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7c96a01b-8481-44a0-eee5-08d5725d3f87 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2018 21:11:56.4628 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3705 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGO/fe7V6txXEpvn5hjay03EwUVlloJC2pKIhIJXLpRcVPNh1Z CGr1hx/5XbolOGuaqVgNdSmGaSFqmFpQaqmYWqhE6swPzGrbXdB/v/d9nue857wchhS28JyZ 2MQUVpEojxfxbSn1JcNub3cyK8yn0UhL8xZPSksy79PS9fFWnjQro5aUdq9UE9Kn9aWUNE+7 NZCWlbzWkrLm3jW+TKtPlY2W91EynW6dkGWtPODLuhd+8s/RYbYBUWx8rIpVSI5F2Ma8aFJT yX3h155NltMZqCI0B9kwgP2gac5ImVmIXyHQrhzOQbYm7kEw36BD5oLCSwSs1qzzOaWMgHld AcUVMwjmCu9a8nwcAI+7Vk0RhrHHIWBcOm/2kLiIAHVbO2327MBiGBqp55vZHktAPzhEcHwW Pnb3IDNT2ANql8YsZwpwBAyN1SFu2DoBy5pbloANPg71b0stjLAbTKyOWwIkdoTR6UqCexwG XfsAybEDzE795nH+SFgaucPj+jthrFhrZTd4V5lrGQa4hYBNY7Y1LIbmou+I4zOgX261mvoQ GNSfaE44AGtVVVZOgp6RfIIzVSKoHxzgcUUFCX0d2XzO5Qrjy7dRIZJo/ru6xrQ/EnvCkzZr exeU5k7SGss67KBXPU1pEVWHHJSs8mpCtK+vmFXERiqVSYniRDZFj0y/qbNpw+c5mv0W1IUw g0TbBAV/MsOEPLlKmZbQhYAhRfaCXzdNLUGUPO06q0i6okiNZ5VdyIWhRI6C3lOCMCGOlqew cSybzCr+qQRj45yB7p1u9L84nO7nkKappOc3quNfqvznA8UVDPTsCV4sex9h2DhRqE0vlnjq bxi21xTMHlLp3I9e3hzuv5B2xJ7nltn/aN+M+8JIgCoouG6L9xCVv9/o5bnXteHHlPCNwDn1 y0nJVGlInJOhJHzgw9ecTkef0FAPOyfDxGd/l46HE2UiShkjP+hFKpTyv4yTBoNJAwAA 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, 12 Feb 2018 21:12:04 -0000 SGkgDQoNClBsZWFzZSBzZWUgaW5saW5lDQoNCkJSDQpJbmdlbWFyDQoNCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWlyamEgS8O8aGxld2luZCBbbWFpbHRvOm1pcmphLmt1 ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2hdDQo+IFNlbnQ6IGRlbiAxMiBmZWJydWFyaSAyMDE4IDE2 OjI2DQo+IFRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNz c29uLmNvbT4NCj4gQ2M6IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApIDxr b2VuLmRlX3NjaGVwcGVyQG5va2lhLQ0KPiBiZWxsLWxhYnMuY29tPjsgZWtpbm5lYXJAYXBwbGUu Y29tOyBMdWJhc2hldiwgSWdvcg0KPiA8aWx1YmFzaGVAYWthbWFpLmNvbT47IElhbiBTd2V0dCA8 aWFuc3dldHRAZ29vZ2xlLmNvbT47IFFVSUMgV0cNCj4gPHF1aWNAaWV0Zi5vcmc+OyBDaHJpc3Rp YW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4NCj4gU3ViamVjdDogUmU6IEVDTiBpbiBR VUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uDQo+IA0KPiBIaSBJbmdlbWFyLA0KPiANCj4gdHdvIHBv aW50cy4NCj4gDQo+IEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBiZSBhcyBleHBsaWNpdCBh cyBwb3NzaWJsZSBoZXJlLCB0aGVyZWZvcmUgSSB3b3VsZA0KPiBwcmVmZXIgaWYgYW4gZW5kcG9p bnQgdGhhdCBrbm93cyB0aGF0IGl0IGNhbiBub3QgYWNjZXNzIHRoZSBFQ04gSVAgYml0cw0KPiBp bmRpY2F0ZXMgdGhpcyBkaXJlY3RseSBpbiB0aGUgaGFuZHNoYWtlLiBJbiB0aGlzIGNhc2Ugbm8g ZnVydGhlciB0ZXN0aW5nIGlzDQo+IG5lZWRlZC4NCjxJSj4gWWVzLCB0aGlzIHdhcyB0aGUgb3Jp Z2luYWwgaWRlYSwgd2UgZGlzY3Vzc2VkIHRoaXMgYXQgdGhlIEVDTiBRVUlDIHNpZGUgbWVldGlu ZyB0aG91Z2ggYW5kIGFmdGVyd2FyZHMgYW5kIGFzIGZhciBhcyBJIHVuZGVyc3RhbmQgaXQsIHRo ZXJlIHdhcyBhIGNvbnNlbnN1cyB0aGF0IGl0IHdhcyB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVk LiBTbyB3ZSBzZWxlY3RlZCBhIG1ldGhvZCB3aGVyZSB3ZSBqdXN0IHZlcmlmeSB0aGF0IHRoZSBF Q1QoMCksRUNUKDEpLENFIGNvdW50ZXJzIGhhdmUgcmVhc29uYWJsZSB2YWx1ZXMuIElmIHRoYXQg aXMgbm90IHRoZSBjYXNlLCB0aGVuIGl0IGlzIGFuIGluZGljYXRpb24gdGhhdCBlaXRoZXIgdGhl IHBhdGggb3IgdGhlIGVuZHBvaW50cyBkbyBub3Qgc3VwcG9ydCBFQ04uIDwvSUo+DQoNCj4gDQo+ IEZ1cnRoZXIsIHRoZSBwYXRoIHRlc3RpbmcgaXRzZWxmIGlzIGluZGVwZW5kZW50IG9mIFFVSUMg YW5kIGNhbiBiZSB1c2VkIGZvcg0KPiBhbnkgcHJvdG9jb2wuIE1vcmVvdmVyLCBpdOKAmXMgbW9y ZSBjb21wbGljYXRlZCB0aGFuIGp1c3QgdGVzdGluZyBFQ1QuIEkgZ3Vlc3MNCj4gdGhlIGdlbmVy YWwgYWR2aWNlIGhlcmUgaXMgdG8gcmVtZW1iZXIgd2hpY2ggY29kZXBvaW50cyB3ZXJlIHNlbmQg YW5kDQo+IGNvbXBhcmUgdGhpcyB0byB0aGUgZmVlZGJhY2sgcHJvdmlkZWQuIElmIGRpc2NyZXBh bmNpZXMgYXJlIG9ic2VydmVkIHRoYXQNCj4gaW5kaWNhdGUgdGhhdCBhIG1pZGRsZWJveCBoYXMg Y2hhbmdlZCB0aGVzZSBiaXRzLCBhbGwgcGFja2V0cyBzaG91bGQgYmUNCj4gbWFya2VkIGFzIG5v LUVDVCAod2hpbGUgYWRkaXRpb25hbCB0ZXN0aW5nIE1BWSBiZSBwZXJmb3JtZWQgYXQgYW55IGxh dGVyDQo+IHBvaW50IGluIHRpbWUpLiBIb3dldmVyLCBob3cgZXhhY3RseSB0aGlzIHRlc3Rpbmcg c2hvdWxkIGxvb2sgbGlrZSwgc2hvdWxkIG5vdA0KPiBiZSBzcGVjaWZpZWQgaW4gdGhpcyBkb2Mg KGJ1dCBtb3JlIGdlbmVyYWxseSkuDQo8SUo+IEl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIGFjdHVh bCBwYXRoIHZlcmlmaWNhdGlvbiBjYW4gYmUgcHV0IGFzIGEgc2VwYXJhdGUgZG9jdW1lbnQsIG5v dCBzdXJlIGlmIHRoYXQgaXMgYWNjZXB0ZWQgYnkgdGhlIGdyb3VwIG9yIGl0IGlzIGRlc2lyZWQg d2l0aCBhIG1vcmUgZWxhYm9yYXRlIGRlc2NyaXB0aW9uIGRpcmVjdGx5IGluIHRoZSBRVUlDIGRy YWZ0cy4gQXMgcmVnYXJkcyB0byB2ZXJpZmljYXRpb24sIEkgZG8gYmVsaWV2ZSB0aGF0IHRoZSBw cm9wb3NlZCBjb3VudGVycyBzaG91bGQgYmUgYWJsZSB0byBkZXRlY3QgYmxlYWNoaW5nLCBhY2Np ZGVudGFsIHJlbWFya2luZyBmcm9tIEVDVCgwKSB0byBFQ1QoMSkgYW5kIGFsc28gY2FzZXMgd2hl cmUgcGFja2V0cyBhcmUgbm90IENFIG1hcmtlZCBhdCBhbGwgZGVzcGl0ZSBvdGhlciBzaWducyBv ZiBjb25nZXN0aW9uIDwvSUo+DQoNCg0KPiANCj4gTWlyamENCj4gDQo+IA0KPiA+IEFtIDA5LjAy LjIwMTggdW0gMDg6MzQgc2NocmllYiBJbmdlbWFyIEpvaGFuc3NvbiBTDQo+IDxpbmdlbWFyLnMu am9oYW5zc29uQGVyaWNzc29uLmNvbT46DQo+ID4NCj4gPiBIaSBFcmljLCBLb2VuICsgb3RoZXJz DQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSBjb21tZW50cyBhbmQgdGhlIHVwZGF0ZS4gQSBxdWVz dGlvbiB0byB0aGUgcmVzdCBvZiB0aGUNCj4gYXVkaWVuY2UsIGRvZXMgdGhlIHByZXNlbnRlZCB0 ZXh0IGV4cGxhaW4gc3VmZmljaWVudGx5IGVub3VnaCBob3cgRUNODQo+IHdvcmtzIHdpdGggY29u bmVjdGlvbiBtaWdyYXRpb24gPw0KPiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1k cmFmdHMvd2lraS9FQ04taW4tUVVJQyN0cmFuc3BvcnQtDQo+IGRyYWZ0LWNvbm5lY3Rpb24tbWln cmF0aW9uDQo+ID4NCj4gPg0KPiA+IC9JbmdlbWFyDQo+ID4NCj4gPg0KPiA+IEZyb206IERlIFNj aGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApDQo+IFttYWlsdG86a29lbi5kZV9zY2hl cHBlckBub2tpYS1iZWxsLWxhYnMuY29tXQ0KPiA+IFNlbnQ6IGRlbiAyIGZlYnJ1YXJpIDIwMTgg MTU6NDQNCj4gPiBUbzogZWtpbm5lYXJAYXBwbGUuY29tOyBJbmdlbWFyIEpvaGFuc3NvbiBTDQo+ IDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gPiBDYzogUVVJQyBXRyA8cXVp Y0BpZXRmLm9yZz47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47DQo+IEx1YmFzaGV2 LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgQ2hyaXN0aWFuIEh1aXRlbWENCj4gPGh1aXRl bWFAaHVpdGVtYS5uZXQ+DQo+ID4gU3ViamVjdDogUkU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24g bWlncmF0aW9uDQo+ID4NCj4gPiBIaSBJbmdlbWFyLA0KPiA+DQo+ID4gSSBhbHNvIHJlYWQgYWdh aW4gdGhyb3VnaCB0aGUgZG9jdW1lbnQsIGFuZCBoYWQgZm9sbG93aW5nIGNvbW1lbnRzOg0KPiA+ DQo+ID4gSSByZXBsYWNlZDoNCj4gPiDigJxUaGUgQUNLX0VDTiBmcmFtZSBpcyB1c2VkIHRvIGNv bnZleSBBQ0tzIHdoZW4gdGhlIEVDTiBjYXBhYmlsaXR5DQo+IGV4Y2hhbmdlIGNvbmNsdWRlcyB0 aGF0IEVDTiBzaG91bGQgYmUgdXNlZCBmb3IgdGhlIGdpdmVuIGNvbm5lY3Rpb24u4oCdDQo+ID4g T3JpZ2luYWxseSBpdCBzb3VuZHMgYXMgaWYgdGhlIGNvdW50ZXJzIGFyZSBub3QgZWNob2VkIGFu eW1vcmUgaWYgdGhlIEVDTg0KPiBjYXBhYmlsaXR5IGNoZWNrIGZhaWxzLiBJIGFzc3VtZSB0aGlz IHdhcyBub3QgdGhlIGludGVudGlvbiwgYnV0IGlmIGl0IGlzOiBGaXJzdCwgd2UNCj4gZG9u4oCZ dCBoYXZlIGEgcHJvdG9jb2wgb3IgZGVjaXNpb24gcG9pbnQgZGVmaW5lZCB3aGVuIHRoYXQgY29u ZGl0aW9uIGlzIG1ldA0KPiAoc2VuZGVyIHNob3VsZCBsZXQgdGhlIHJlY2VpdmVyIGtub3cgaW4g dGhlIG5leHQgcGFja2V0KSwgYW5kIHNlY29uZCwgSQ0KPiB3b3VsZCBhbHdheXMgc2VuZCB0aGUg ZWNobywgYXMgd2UgbWlnaHQg4oCcdHJ5IGFnYWluIGxhdGVyICh3aXRoIGFub3RoZXINCj4gRUNU PynigJ0sIG9yIG1pZ2h0IGRlY2lkZSB0byB1c2UgdGhlIEVDTiBiaXRzIGRpZmZlcmVudGx5IGxh dGVyLg0KPiA+DQo+ID4gSSBhbHNvIGNoYW5nZWQgdGhlIHRleHQgYXJvdW5kIHRoZSBjb25uZWN0 aW9uIG1pZ3JhdGlvbiwgSSB0aGluayBiZWZvcmUgRXJpYw0KPiByZXZpZXdlZCBpdC4gSSBtYWRl IGl0IHN1Y2ggdGhhdCBldmVyeSBuZXcgcGF0aCBjcmVhdGVzIGEgbmV3IGNvbm5lY3Rpb24NCj4g c3RhdGUgd2l0aCBhbiBpbml0aWFsaXplZCBjb25nZXN0aW9uIGNvbnRyb2wgc3RhdGUgYW5kIEVD TiBjb3VudGVycyAoYXQgbGVhc3QNCj4gRUNOIGNvdW50ZXJzIHJlc2V0IHRvIDBzKS4gTm90IHN1 cmUgaWYgdGhpcyBtYXRjaGVzIHdpdGggdGhlIG90aGVyIHNlY3Rpb25zIGluDQo+IHRoZSBRVUlD IGRyYWZ0Lg0KPiA+DQo+ID4gSSBhbHNvIGhhZCB0aGUgdGhvdWdodCB3aGV0aGVyIGl0IHdhcyBy ZWFsbHkgbmVlZGVkIHRvIGhhdmUgdGhlIDIgY2FzZXMuIEkNCj4gYWdyZWUgd2Ugc2hvdWxkIHNp bXBsaWZ5LCBieSBqdXN0IHN0YXJ0aW5nIG92ZXIgYW5kIGRvaW5nIHRoZSBjaGVjaw0KPiB1bmNv bmRpdGlvbmFsbHkgd2hldGhlciBpdCB3YXMgc3VjY2Vzc2Z1bCBvciBub3QgaW4gYSBwcmV2aW91 cyBwYXRoLg0KPiA+DQo+ID4gUmVnYXJkcywNCj4gPiBLb2VuLg0KPiA+DQo+ID4gRnJvbTogZWtp bm5lYXJAYXBwbGUuY29tIFttYWlsdG86ZWtpbm5lYXJAYXBwbGUuY29tXQ0KPiA+IFNlbnQ6IEZy aWRheSwgRmVicnVhcnkgMiwgMjAxOCAxMjowMiBBTQ0KPiA+IFRvOiBJbmdlbWFyIEpvaGFuc3Nv biBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gPiBDYzogUVVJQyBXRyA8 cXVpY0BpZXRmLm9yZz47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47DQo+IEx1YmFz aGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgQ2hyaXN0aWFuIEh1aXRlbWENCj4gPGh1 aXRlbWFAaHVpdGVtYS5uZXQ+OyBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJw KQ0KPiA8a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tPg0KPiA+IFN1YmplY3Q6 IFJlOiBFQ04gaW4gUVVJQyBjb25uZWN0aW9uIG1pZ3JhdGlvbg0KPiA+DQo+ID4gSGkgSW5nZW1h ciwNCj4gPg0KPiA+IFRoaXMgZ2VuZXJhbGx5IGxvb2tzIGdvb2QgdG8gbWUhDQo+ID4gQSBmZXcg cXVlc3Rpb25zIGFuZCBvYnNlcnZhdGlvbnM6DQo+ID4NCj4gPiBUaGVyZSBhcmUgdHdvIHVuaXF1 ZSBjYXNlczoNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICDigKIgRUNOIGNhcGFiaWxpdHkgY2hl Y2sgc3VjY2Vzc2Z1bCBhdCBpbml0aWFsIGNvbm5lY3Rpb24gc2V0dXANCj4gPiAgICAgICAgICAg ICAgICAg4oCiIEVDTiBjYXBhYmlsaXR5IGNoZWNrIGZhaWxlZCBhdCBpbml0aWFsIGNvbm5lY3Rp b24gc2V0dXANCj4gPg0KPiA+IEFyZSB0aGVzZSBhY3R1YWxseSBhbnkgZGlmZmVyZW50IGluIHRl cm1zIG9mIGFjdGlvbiB0YWtlbiBieSBhbiBlbmRwb2ludD8NCj4gPiBJdCBzZWVtcyBsaWtlIG9u IHRoZSBuZXcgbmV0d29yayBwYXRoIHRoZSBlbmRwb2ludCB3b3VsZCBnbyB0aHJvdWdoIHRoZQ0K PiBzYW1lIHByb2Nlc3Mgb2Y6IChhKSB2ZXJpZnkgRUNOIGNhcGFiaWxpdHkgYW5kIGlmIHN1Y2Nl c3NmdWwgdG8gd2hhdGV2ZXINCj4gZGVncmVlIHRoZW4gKGIpIHJ1biB0aGUgcmVzdCBvZiB0aGUg RUNOIG1hY2hpbmVyeSBhcyBhcHByb3ByaWF0ZS4NCj4gPg0KPiA+IEluIG90aGVyIHdvcmRzLCBh cyBsb25nIGFzIHlvdSBhbGxvdyBwZW9wbGUgdG8gc3RhcnQgdXNpbmcgRUNOIHVwb24NCj4gbWln cmF0aW9uIChpbiBvdGhlciB3b3JkcywgdG8gYWxsb3cgc3RhcnRpbmcgaXQgYWZ0ZXIgdGhlIGlu aXRpYWwgY29ubmVjdGlvbg0KPiBlc3RhYmxpc2htZW50KSwgdGhlbiB0aGUgc3BlY2lmaWNzIGZv ciBFQ04gd2l0aCBtaWdyYXRpb24gaXMgZXNzZW50aWFsbHkgb25lDQo+IHN0YXRlbWVudCwgd2hp Y2ggaXMg4oCcZG8gdGhlIEVDTiBwcm9jZXNzIG9uIGVhY2ggbmV3IG5ldHdvcmsgcGF0aCB0aGF0 IHlvdQ0KPiB1c2XigJ0uDQo+ID4NCj4gPiBDb25uZWN0aW9uIG1pZ3JhdGlvbiBoYXMgaW1wYWN0 IG9uIHRoZSBudW1iZXIgb2YgcmVwb3J0ZWQgQ0UgbWFya2VkDQo+IHBhY2tldHMuIEEgbmV3IGNv bm5lY3Rpb24gc3RhdGUgd2l0aCBuZXcgY29uZ2VzdGlvbiBjb250cm9sIHN0YXRlIGFuZCBFQ04N Cj4gY291bnRlcnMgaXMgaW5zdGFudGlhdGVkIGF0IHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVyLiBU aGUgRUNOIGNvdW50ZXJzIE1VU1QNCj4gc3RhcnQgZnJvbSB6ZXJvIGFnYWluLg0KPiA+DQo+ID4g VGhpcyBzZWVtcyBmaW5lIHRvIG1lLCBpdOKAmXMgaW5saW5lIHdpdGggdGhlIHJlc3Qgb2YgdGhl IGNvbmdlc3Rpb24NCj4gY29udHJvbC9sb3NzIHJlY292ZXJ5IHN0YXRlIHRoYXQgYWxzbyBuZWVk cyB0byBiZSByZXNldCBmb3IgdGhlIG5ldyBwYXRoLg0KPiA+DQo+ID4gR2l2ZW4gdGhhdCBlYWNo IG1pZ3JhdGlvbiByZXF1aXJlcyBhdCBsZWFzdCBvbmUgZXhjaGFuZ2Ugb2YgcGFja2V0cyBhdCB0 aGUNCj4gYmVnaW5uaW5nIChhdCB0aGUgdmVyeSBsZWFzdCBmb3IgYWRkcmVzcyB2YWxpZGF0aW9u IGZyb20gdGhlIHNpZGUgb2YgdGhlDQo+IGVuZHBvaW50IHRoYXQgZGlkbuKAmXQgbWlncmF0ZSks IGl0IHNlZW1zIGxpa2UgdGhhdOKAmXMgYW4gZXhjZWxsZW50IG1vbWVudCB0bw0KPiBtYXJrIHRo ZSBwYWNrZXRzIGFuZCBwZXJmb3JtIHRoZSBFQ04gY2FwYWJpbGl0eSBkZXRlY3Rpb24uIFRob3Nl IHBhY2tldHMNCj4gYXJlIGFsc28gbGlrZWx5IHBhZGRlZCwgZXRjLiBzaW1pbGFyIHRvIGluaXRp YWwgcGFja2V0cyBzaW5jZSB0aGV54oCZcmUgb24gYQ0KPiBwcmV2aW91c2x5IHVudXNlZCBuZXR3 b3JrIHBhdGguDQo+ID4NCj4gPiBJIHRoaW5rIHRoZSBjdXJyZW50IHByb3Bvc2VkIHJlcXVpcmVt ZW50IG9mIGp1c3QgdXNpbmcgdGhlIOKAnGZpcnN04oCdIHBhY2tldHMNCj4gYW5kIG1hcmtpbmcg dGhvc2UgaXMgc3VmZmljaWVudCAoYW5kIGdvb2QgdG8gYXZvaWQgYW55IHJlcXVpcmVtZW50IGFz IHRvDQo+IHdoaWNoIGZyYW1lcyBhcmUgY29udGFpbmVkIGluIHRob3NlIHBhY2tldHMpLCBzaW5j ZSB3ZSBhcmUgYWx3YXlzDQo+IGV4Y2hhbmdpbmcgcGFja2V0cyBpbiBib3RoIGRpcmVjdGlvbnMg aW1tZWRpYXRlbHkgYWZ0ZXIgbWlncmF0aW9uLg0KPiA+DQo+ID4gVGhpcyBoYXMgdGhlIGFkZGVk IGJlbmVmaXQgc3VjaCB0aGF0IGFueSBlbmRwb2ludCDigJxwcm9iaW5n4oCdIHBvc3NpYmxlDQo+ IG5ldHdvcmsgcGF0aHMgY291bGQgaW5jbHVkZSB0aGUgYml0cyBuZWNlc3NhcnkgdG8gZGV0ZWN0 IEVDTiBjYXBhYmlsaXR5IG9uDQo+IHRoZSBwYXRoIGJlaW5nIHByb2JlZCwgc28gaXQgY291bGQg ZXZlbiBrbm93IGJlZm9yZSBtaWdyYXRpbmcgd2hldGhlciBvcg0KPiBub3QgaXQgd291bGQgYmUg YWJsZSB0byB1c2UgRUNOIG9uIHRoYXQgbmV3IHBhdGguDQo+ID4NCj4gPiBUaGFua3MsDQo+ID4g RXJpYw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gRmViIDEsIDIwMTgsIGF0IDM6MDcgQU0s IEluZ2VtYXIgSm9oYW5zc29uIFMNCj4gPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29t PiB3cm90ZToNCj4gPg0KPiA+IEhpDQo+ID4gSSBoYXZlIHdyaXR0ZW4gdXAgZGlmZmVyZW50IGFz cGVjdHMgb2YgY29ubmVjdGlvbiBtaWdyYXRpb24gYW5kIGhvdyBpdA0KPiBwbGF5cyB3aXRoIEVD Ti4NCj4gPiBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvRUNOLWlu LVFVSUMjdHJhbnNwb3J0LQ0KPiBkcmFmdC1jb25uZWN0aW9uLW1pZ3JhdGlvbg0KPiA+DQo+ID4g QSBjYXZlYXQuLiBJIGFtIGEgYml0IHVuc3VyZSBhYm91dCB0aGUgZGVmaW5pdGlvbiBvZiBjb25u ZWN0aW9uIG1pZ3JhdGlvbiAuDQo+IE15IGludGVycHJldGF0aW9uIGlzIHRoYXQgYSBjbGllbnQg bW92ZXMgdG8gYSBuZXcgSVAgYWRkcmVzcyBkdWUgdG8gZS5nLiBhIE5BVA0KPiByZWJpbmQgb3Ig c3dpdGNoIGZyb20gV2lGaSB0byBjZWxsdWxhciwgcmlnaHQgPy4gSXMgYSBuZXcgY29ubmVjdGlv bg0KPiBpbnN0YW50aWF0ZWQgYXQgYSBjb25uZWN0aW9uIG1pZ3JhdGlvbiA/DQo+ID4NCj4gPiAv SW5nZW1hcg0KPiA+DQo+ID4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+ IEluZ2VtYXIgSm9oYW5zc29uICBNLlNjLg0KPiA+IE1hc3RlciBSZXNlYXJjaGVyDQo+ID4NCj4g PiBFcmljc3NvbiBSZXNlYXJjaA0KPiA+IE5ldHdvcmsgUHJvdG9jb2xzICYgRTJFIFBlcmZvcm1h bmNlDQo+ID4gTGFicmF0b3JpZWdyw6RuZCAxMQ0KPiA+IDk3MSAyOCwgTHVsZcOlLCBTd2VkZW4N Cj4gPiBQaG9uZSArNDYtMTA3MSA0MzA0Mg0KPiA+IFNNUy9NTVMgKzQ2LTczIDA3OCAzMjg5DQo+ ID4gaW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20NCj4gPiB3d3cuZXJpY3Nzb24uY29t DQo+ID4NCj4gPiAgICAgICAgICAgICAgICAgIFlvdSBjYW4ndCBzdGFydCBhIGZpcmUNCj4gPiAg IFdvcnJ5aW5nICdib3V0IHlvdXIgbGl0dGxlIHdvcmxkIGZhbGxpbmcgYXBhcnQNCj4gPiAgICAg ICAgICAgICAgICBCcnVjZSBTcHJpbmdzdGVlbg0KPiA+ID09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCg0K From nobody Mon Feb 12 14:11:08 2018 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 1693B126DC2 for ; Mon, 12 Feb 2018 14:11:07 -0800 (PST) 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, 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=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 JUiOJuV1BbrE for ; Mon, 12 Feb 2018 14:11:05 -0800 (PST) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::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 51D10126D74 for ; Mon, 12 Feb 2018 14:11:05 -0800 (PST) Received: by mail-wr0-x22c.google.com with SMTP id h9so16750342wre.12 for ; Mon, 12 Feb 2018 14:11:05 -0800 (PST) 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=pL5QdStt33EIVPxyv2DdPvtoxT14WldCaS+uX3n3FQM=; b=Y07vHTK9CqqBShOVz61vXcq2P0WGaJdiqnFVKCySzyjI+wFj4NZsPyWfo0iNODmtM6 aGx5FcLW3lnHabuDzGzAA6RA1znZlnd4RHtJMcTNP+WP1S2WCH/4/9Iu9FBYqUNgLKUc D7AVkELdZwsFTcx199t1SNakqoG65u8bSlj1EzmyVphJdbSIH27WKPUiR/wFRu2FK77p AvcYq9Y8BSfEyKf68XQNaqhEdI1pegzZnU01LJIxOKzsL9bp4ssHMNEqrsq7+VXEoVo3 Vi0biGN+Bn85XT1u9oBuX8oh/byCdwWKf7hhM5AurUYAUmBn/j7miebMAq5Kk05L8S8d MALw== 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=pL5QdStt33EIVPxyv2DdPvtoxT14WldCaS+uX3n3FQM=; b=EsiZVF8ia7/LleinAKOfiuRC1Ein9y2Uhe3Lh68FZ/MZ0g0JDqgBRrwP/rueYkrjFd ckjmAR1NNNDnkS1ooC9rdye0mS5PXqLVlQE7ccyTj8vgUwJtlEUPonjixWWSo3tXx9hL 2KIxN8o1gMAGCycI+fvULwPFzlcoksiu991XjfLO9mbvIL0H4p1guQHMFOrjf+RE/Q8Y /2PZmXVx39Mh5yz96p9GdVPik8zuS+YDisl7CCJQOY+OYTjku6+YFhXXy2GtsKPnvizH fnzOf6oasccY/H8/yKgfLVyzx7aiRoDMN9pQrfXYJlaB8P7je9Tzm3Kv1xETe+MEMVpJ vwRg== X-Gm-Message-State: APf1xPCHTpxqhdOUhLR7cl4fbMGJOAVjdfcxLX2Cv/xzZVf1TmfYBe0n nQGt/IbaIAWrUCWa+7n3rP50mfeRn3zQMX969h0PLaET X-Google-Smtp-Source: AH8x226M9Ic6VvYyK35f2DD3pxxeKeHHLeSYOGbp1EEXZ5+2mG890cAM0FxpfZxn1/jthhpLOapD98R022sqYeLLCxM= X-Received: by 10.223.186.197 with SMTP id w5mr12270507wrg.155.1518473463727; Mon, 12 Feb 2018 14:11:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.208.130 with HTTP; Mon, 12 Feb 2018 14:11:03 -0800 (PST) From: Martin Duke Date: Mon, 12 Feb 2018 14:11:03 -0800 Message-ID: Subject: draft-duke-quic-load-balancers-00.txt To: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e082468ec680ad505650b273a" 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, 12 Feb 2018 22:11:07 -0000 --089e082468ec680ad505650b273a Content-Type: text/plain; charset="UTF-8" Based on conversations in Melbourne, I posted a straw man for a standard way for load balancers and servers to coordinate on routable, unlinkable connection IDs. Datatracker: https://datatracker.ietf.org/doc/draft-duke-quic-load-balancers/ Github: https://github.com/martinduke/draft-duke-quic-load-balancers There's nothing earthshaking here: we use DTLS for authentication and encryption, and have a few very simple UDP messages to keep the conn IDs synced. The draft isn't very long. I'll incorporate variable length connection IDs, etc, when and if they enter the mainline. I'm certainly interested if this meets the needs of the people actively looking for a solution in this space. --089e082468ec680ad505650b273a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on conversations in Melbourne, I posted a straw man = for a standard way for load balancers and servers to coordinate on routable= , unlinkable connection IDs.

G= ithub:=C2=A0https://github.com/martinduke/draft-duke-quic-load-balancers<= /div>

There's nothing earthshaking here: we use DTLS= for authentication and encryption, and have a few very simple UDP messages= to keep the conn IDs synced. The draft isn't very long.

=
I'll incorporate variable length connection IDs, etc, when a= nd if they enter the mainline. I'm certainly interested if this meets t= he needs of the people actively looking for a solution in this space.
=



--089e082468ec680ad505650b273a-- From nobody Mon Feb 12 17:35:12 2018 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 8329512E034 for ; Mon, 12 Feb 2018 17:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, T_RP_MATCHES_RCVD=-0.01, 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 9vI7NX7XBmOc for ; Mon, 12 Feb 2018 17:35:08 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002: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 6D40112DB71 for ; Mon, 12 Feb 2018 17:35:08 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id b16so11291863ywh.12 for ; Mon, 12 Feb 2018 17:35:08 -0800 (PST) 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=+r0W+t+MQPmDAXUAePHzA4355x1r4Vw7QaB9Ktja0N4=; b=npNaJ9KCbvKzK6hKnV0m6OrGR0cplCTpXIEpfnR/8ZKtAir2Q/t92xv9EbLssPjYGo SivTpQIDZin5vN2/Mj0+PRV2GmLAMNerRevPx27TFREx8KRHwPExGe+XABCmZumXqwhu Djsa7wnhGVv6XzNh8Z0R/TDENLk8Nki14WX9bY8QI1FR3gZZvp2dws3ZL0EhBz7VRFbU D2y1g7bL+D7ucEsRUjbUsTBNmIk65z+5Q58k2ZdBjAyabGFdel8tOHyaj8e+oVJHQvO+ W7FNj1O0J7VtTbMzJownWgCuNjaTIAsNPsPUWz0HyN3Ph7A/GoWgiMQbrunD6CrBfVs7 CSsw== 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=+r0W+t+MQPmDAXUAePHzA4355x1r4Vw7QaB9Ktja0N4=; b=TETZUCkbfRuRdKtSBwcjf8IweiHAevW/nIRA6KieAsj3VwmspMzoxIosHayIGJJPJd PF4JAkyHBhQg3PSzbRyEIp0x6+ihOzwgcyEbIAp4AEJOSztojOOiVFOqeTBpGwNf0PDA vfH9Boa5j7OKuqnc1iyV1LOEJOFdNZdD0aK+TEIyMjGtSFiMI9AJoMIMiQ+L4pM1zhem 0unjTM4lRZvRdUygYdR2FqoNxCFQQW1oLBYic5fRjOGwipX/HeMoFKfpI0RbIlrqjUkG buWXi/3FfWjU7Olglz/wtHXVYJOZOgiUDh23m2wmKJQsbnwFVn+lNcVz0xTRtc6SN0fo kwYQ== X-Gm-Message-State: APf1xPATsndfZNuywC7T/Le+q/gsu4DiH0FUFjOLc4jvVme3c+iZbXUb oWuqb0VM+px+UA6C0tBym7s2F0klcQ7C1nYLq82CVg== X-Google-Smtp-Source: AH8x225GNf2GBEfwqdqkYnJ5cLX56Oka7yNKfiJW+phJ4nQhYLv59AzXWi+jgBUI1oWpp4Pct3/Ugg+N4gN90KStjUc= X-Received: by 10.37.174.33 with SMTP id a33mr8881935ybj.309.1518485707323; Mon, 12 Feb 2018 17:35:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.102.76 with HTTP; Mon, 12 Feb 2018 17:34:46 -0800 (PST) In-Reply-To: References: From: Erik Kline Date: Mon, 12 Feb 2018 17:34:46 -0800 Message-ID: Subject: Re: draft-duke-quic-load-balancers-00.txt To: Martin Duke Cc: IETF QUIC WG Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="f403045dc4de37172805650e0155" 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, 13 Feb 2018 01:35:10 -0000 --f403045dc4de37172805650e0155 Content-Type: text/plain; charset="UTF-8" I wasn't in Melbourne, but I'm curious: why not specify a protocol over QUIC itself? In my experience, load balancers maintain connections to ~essentially~ all the backends for which they balance. Could this protocol instead be mapped onto streams in a QUIC connection between LB and backend? If so, liveness via PING frames could be incorporated. For security purposes, IP Tries of whitelisted LB IPs and/or running this kind of thing over connections to backends on non-standard ports is something I know is done. On 12 February 2018 at 14:11, Martin Duke wrote: > Based on conversations in Melbourne, I posted a straw man for a standard way > for load balancers and servers to coordinate on routable, unlinkable > connection IDs. > > Datatracker: > https://datatracker.ietf.org/doc/draft-duke-quic-load-balancers/ > Github: https://github.com/martinduke/draft-duke-quic-load-balancers > > There's nothing earthshaking here: we use DTLS for authentication and > encryption, and have a few very simple UDP messages to keep the conn IDs > synced. The draft isn't very long. > > I'll incorporate variable length connection IDs, etc, when and if they enter > the mainline. I'm certainly interested if this meets the needs of the people > actively looking for a solution in this space. > > > --f403045dc4de37172805650e0155 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 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEXDCCA0SgAwIBAgIMKdwhX41Y35wFUjGFMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE3MDkxODA2MzcwOVoXDTE4MDMx NzA2MzcwOVowHjEcMBoGCSqGSIb3DQEJAQwNZWtAZ29vZ2xlLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAJy2TTLrLwR7RcglT55abZwzTLAQuVmbauaGZ7ISDwVYV8cPqfsX3aXc 919y4IdiY46RCm9gCcadSC5BIXHema75b6Go1xUnPOqqEItlA9D5h/5wnNhuYPL+oENW+qzlPIJn YuaY9+dkw9H89qAB72Ym3bCx3Uf3xMDsAxSZ1Ry9SZxZnjtlfN9kkKWXPeMLmb5PAaLfpL2Uy1P8 txlZzqpzH1sXjHlW1iuP76DxS7/9p+W3yTZTRW1f2q1UpvIGwb8M6rVwdZ4xGT7xsNtuq3piCwe/ zw8Vl36a+fiMl42R+DvRfmTKQ3fM9r8Kn7Ea7XtDPJxi7NObD5R+WNGOC5ECAwEAAaOCAWowggFm MBgGA1UdEQQRMA+BDWVrQGdvb2dsZS5jb20wUAYIKwYBBQUHAQEERDBCMEAGCCsGAQUFBzAChjRo dHRwOi8vc2VjdXJlLmdsb2JhbHNpZ24uY29tL2NhY2VydC9nc2h2c21pbWVjYTEuY3J0MB0GA1Ud DgQWBBTmP2l2sEQr/BnAyZ6R5p7YEJL/7TAfBgNVHSMEGDAWgBTLOBKwx5nAeJKMsyGV5vQmYsDg PzBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIGCCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9i YWxzaWduLmNvbS9yZXBvc2l0b3J5LzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vY3JsLmdsb2Jh bHNpZ24uY29tL2dzaHZzbWltZWNhMS5jcmwwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQWMBQGCCsG AQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQsFAAOCAQEADid0ytXB29OM7HLEeo9Ogp3a1JkP J1V8J82GEmP3ADxjwMJe2gPJ6jKRcpv/wS8s7/e2llbFIJlMrDIP6IEcDYnUfHLBINVCcl9D8AiB T7kNEz6O637UG/RdFCP9/C+Vh1kB1NfYNclTKlHj8Hzn7VlhUktCL3hbJkLA5+L5lOLMibTieryO trFBU3qzQo4G/2LtdmRJIp3B9bcL0KE/XQ2MJQIAAFN0YFkG8qs8gie1LbygrV5csjAjpH+KY4O/ f66H+gc3e+bG1vQtoq9Iu/IpM1Zy0F+P9/zOu8REfB7FrH6WT+sBUy7SUdN1FakV/clOL426MxnS kkWJA9H3tTGCAl4wggJaAgEBMFwwTDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExIjAgBgNVBAMTGUdsb2JhbFNpZ24gSFYgUy9NSU1FIENBIDECDCncIV+NWN+cBVIxhTAN BglghkgBZQMEAgEFAKCB1DAvBgkqhkiG9w0BCQQxIgQgtduHqugBW8HrvC4IOjG0yTO17RMHT9eU snYHjFJrpmIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwMjEz MDEzNTA3WjBpBgkqhkiG9w0BCQ8xXDBaMAsGCWCGSAFlAwQBKjALBglghkgBZQMEARYwCwYJYIZI AWUDBAECMAoGCCqGSIb3DQMHMAsGCSqGSIb3DQEBCjALBgkqhkiG9w0BAQcwCwYJYIZIAWUDBAIB MA0GCSqGSIb3DQEBAQUABIIBAAM7jOWNuILocuM9VwWgw0oB+dLri6aoQBiFZ90Xv2VusQfJbr6U R3gOcnUwnC2JvBch0Q6o1XGdP3bTjlUQfszsgxRoib5z/L10+F5iDYlOeMIemqu6O1iu7hrtsWqE apPuKZXGxIfQZ0IslaC5OYHOP4ZnD62WZup/CI2u3UEIBNO/tcb6S6K10luqYxbTA1be8swzvQBU thgPf1c79iRyZiV1+YF3anngSZPaaNkbhZRCGv2NuFS8tpugm+9jwXiQT8wETPZ8N0YCrNXk/7rg B3YI5WPHtozWu/G7xrLlijXMvegotJA1wtyoxEcsMkN5sTyLZ7WE5DFVAYBmrg8= --f403045dc4de37172805650e0155-- From nobody Tue Feb 13 04:29:39 2018 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 CFF9B1270A7 for ; Tue, 13 Feb 2018 04:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, 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 MEjIMS7loLqO for ; Tue, 13 Feb 2018 04:29:35 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512CB1201FA for ; Tue, 13 Feb 2018 04:29:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3zghgK34hDzMlXS; Tue, 13 Feb 2018 13:29:33 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id by7G-TEjRYRZ; Tue, 13 Feb 2018 13:29:31 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (mue-88-130-61-114.dsl.tropolys.de [88.130.61.114]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 13 Feb 2018 13:29:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: ECN in QUIC connection migration From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 13 Feb 2018 13:29:29 +0100 Cc: "De Schepper, Koen (Nokia - BE/Antwerp)" , "ekinnear@apple.com" , "Lubashev, Igor" , Ian Swett , QUIC WG , Christian Huitema Content-Transfer-Encoding: quoted-printable Message-Id: <5CC94D22-1375-40A2-8084-BA4A43F6FA94@tik.ee.ethz.ch> References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> To: Ingemar Johansson S X-Mailer: Apple Mail (2.3445.5.20) 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, 13 Feb 2018 12:29:39 -0000 Hi Ingemar, see below. > Am 12.02.2018 um 22:11 schrieb Ingemar Johansson S = : >=20 > Hi=20 >=20 > Please see inline >=20 > BR > Ingemar >=20 >> -----Original Message----- >> From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] >> Sent: den 12 februari 2018 16:26 >> To: Ingemar Johansson S >> Cc: De Schepper, Koen (Nokia - BE/Antwerp) > bell-labs.com>; ekinnear@apple.com; Lubashev, Igor >> ; Ian Swett ; QUIC WG >> ; Christian Huitema >> Subject: Re: ECN in QUIC connection migration >>=20 >> Hi Ingemar, >>=20 >> two points. >>=20 >> I think it would be good to be as explicit as possible here, = therefore I would >> prefer if an endpoint that knows that it can not access the ECN IP = bits >> indicates this directly in the handshake. In this case no further = testing is >> needed. > Yes, this was the original idea, we discussed this at the ECN = QUIC side meeting though and afterwards and as far as I understand it, = there was a consensus that it was unnecessarily complicated. So we = selected a method where we just verify that the ECT(0),ECT(1),CE = counters have reasonable values. If that is not the case, then it is an = indication that either the path or the endpoints do not support ECN. = I checked the minutes and could not really find a conclusion there. I = agree that there should be no negotiation in the handshake (both = endpoint need to implement the ECN logic as part of v1) but what would = be helpful is to let the other end know if you already know that you = never will be able to provide feedback because you can just not read the = bits in the IP header. That is not complicated at all. I think what we need to specify in v1 is a way to provide ECN feedback = (or indicate that this is not possible). However, we actually would not = need to say anything about how ECN should be used. That=E2=80=99s a = sender side decision. As long as you can get feedback, we are flexible = in how to use and test ECN in v1 or anytime later. Of course it would be = nice to provide some default recommendations with some easy fallback = logic but that's the part we can experiment with and change any time = without any need to change the protocol spec (as long as ECN feedback is = provided, when ECN is used by the sender). >=20 >>=20 >> Further, the path testing itself is independent of QUIC and can be = used for >> any protocol. Moreover, it=E2=80=99s more complicated than just = testing ECT. I guess >> the general advice here is to remember which codepoints were send and >> compare this to the feedback provided. If discrepancies are observed = that >> indicate that a middlebox has changed these bits, all packets should = be >> marked as no-ECT (while additional testing MAY be performed at any = later >> point in time). However, how exactly this testing should look like, = should not >> be specified in this doc (but more generally). > It is possible that the actual path verification can be put as a = separate document, not sure if that is accepted by the group or it is = desired with a more elaborate description directly in the QUIC drafts. = As regards to verification, I do believe that the proposed counters = should be able to detect bleaching, accidental remarking from ECT(0) to = ECT(1) and also cases where packets are not CE marked at all despite = other signs of congestion We tried to design a more elaborated testing scheme where we would send = 3 ECT0, the 3 ECT1, and the 3 CE (which we would of cause not count as a = congestion indication as the CE was set by the sender). However, this = was mostly to detect black-whaling which is probably less a concern than = re-marking. I think today the most common case it that the bits will be = set to zeros which is only a problem when there was some CE marking = previously on the path that then would get lost. Thus in this case it = would be recommend to not use ECN/not set packets as ECT at sender side. However, as I said above, we probably should make recommendation how to = use ECN by default but need to leave room for other usage/testing = schemes. But after all the receiver being not able to read the bits and = remarking on the path are to different things and should not be mixed = up. If the sender can not read the bits this is know a priori and there = is no ambiguity that needs to be tested. So why not signal it directly. = The question if the sender can write ECN does not need to be = communicated. There is no difference in the sender decided to not use = ECN or it just can not use it; in both cases it is not necessary to send = ECN feedback back. Only if a non-non-ECT is observed at the receiver, = ECN feedback needs to be provided. However, knowing that the receiver = can=E2=80=99t not provide feedback is important because in this case the = sender MUST not set the packets as ECT as it will not be able to react = to that signal. Testing the path in independent of that. Mirja >=20 >=20 >>=20 >> Mirja >>=20 >>=20 >>> Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S >> : >>>=20 >>> Hi Eric, Koen + others >>>=20 >>> Thanks for the comments and the update. A question to the rest of = the >> audience, does the presented text explain sufficiently enough how ECN >> works with connection migration ? >>> https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport- >> draft-connection-migration >>>=20 >>>=20 >>> /Ingemar >>>=20 >>>=20 >>> From: De Schepper, Koen (Nokia - BE/Antwerp) >> [mailto:koen.de_schepper@nokia-bell-labs.com] >>> Sent: den 2 februari 2018 15:44 >>> To: ekinnear@apple.com; Ingemar Johansson S >> >>> Cc: QUIC WG ; Ian Swett ; >> Lubashev, Igor ; Christian Huitema >> >>> Subject: RE: ECN in QUIC connection migration >>>=20 >>> Hi Ingemar, >>>=20 >>> I also read again through the document, and had following comments: >>>=20 >>> I replaced: >>> =E2=80=9CThe ACK_ECN frame is used to convey ACKs when the ECN = capability >> exchange concludes that ECN should be used for the given = connection.=E2=80=9D >>> Originally it sounds as if the counters are not echoed anymore if = the ECN >> capability check fails. I assume this was not the intention, but if = it is: First, we >> don=E2=80=99t have a protocol or decision point defined when that = condition is met >> (sender should let the receiver know in the next packet), and second, = I >> would always send the echo, as we might =E2=80=9Ctry again later = (with another >> ECT?)=E2=80=9D, or might decide to use the ECN bits differently = later. >>>=20 >>> I also changed the text around the connection migration, I think = before Eric >> reviewed it. I made it such that every new path creates a new = connection >> state with an initialized congestion control state and ECN counters = (at least >> ECN counters reset to 0s). Not sure if this matches with the other = sections in >> the QUIC draft. >>>=20 >>> I also had the thought whether it was really needed to have the 2 = cases. I >> agree we should simplify, by just starting over and doing the check >> unconditionally whether it was successful or not in a previous path. >>>=20 >>> Regards, >>> Koen. >>>=20 >>> From: ekinnear@apple.com [mailto:ekinnear@apple.com] >>> Sent: Friday, February 2, 2018 12:02 AM >>> To: Ingemar Johansson S >>> Cc: QUIC WG ; Ian Swett ; >> Lubashev, Igor ; Christian Huitema >> ; De Schepper, Koen (Nokia - BE/Antwerp) >> >>> Subject: Re: ECN in QUIC connection migration >>>=20 >>> Hi Ingemar, >>>=20 >>> This generally looks good to me! >>> A few questions and observations: >>>=20 >>> There are two unique cases: >>>=20 >>> =E2=80=A2 ECN capability check successful at initial = connection setup >>> =E2=80=A2 ECN capability check failed at initial = connection setup >>>=20 >>> Are these actually any different in terms of action taken by an = endpoint? >>> It seems like on the new network path the endpoint would go through = the >> same process of: (a) verify ECN capability and if successful to = whatever >> degree then (b) run the rest of the ECN machinery as appropriate. >>>=20 >>> In other words, as long as you allow people to start using ECN upon >> migration (in other words, to allow starting it after the initial = connection >> establishment), then the specifics for ECN with migration is = essentially one >> statement, which is =E2=80=9Cdo the ECN process on each new network = path that you >> use=E2=80=9D. >>>=20 >>> Connection migration has impact on the number of reported CE marked >> packets. A new connection state with new congestion control state and = ECN >> counters is instantiated at the sender and receiver. The ECN counters = MUST >> start from zero again. >>>=20 >>> This seems fine to me, it=E2=80=99s inline with the rest of the = congestion >> control/loss recovery state that also needs to be reset for the new = path. >>>=20 >>> Given that each migration requires at least one exchange of packets = at the >> beginning (at the very least for address validation from the side of = the >> endpoint that didn=E2=80=99t migrate), it seems like that=E2=80=99s = an excellent moment to >> mark the packets and perform the ECN capability detection. Those = packets >> are also likely padded, etc. similar to initial packets since = they=E2=80=99re on a >> previously unused network path. >>>=20 >>> I think the current proposed requirement of just using the = =E2=80=9Cfirst=E2=80=9D packets >> and marking those is sufficient (and good to avoid any requirement as = to >> which frames are contained in those packets), since we are always >> exchanging packets in both directions immediately after migration. >>>=20 >>> This has the added benefit such that any endpoint =E2=80=9Cprobing=E2=80= =9D possible >> network paths could include the bits necessary to detect ECN = capability on >> the path being probed, so it could even know before migrating whether = or >> not it would be able to use ECN on that new path. >>>=20 >>> Thanks, >>> Eric >>>=20 >>>=20 >>>=20 >>>=20 >>> On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S >> wrote: >>>=20 >>> Hi >>> I have written up different aspects of connection migration and how = it >> plays with ECN. >>> https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport- >> draft-connection-migration >>>=20 >>> A caveat.. I am a bit unsure about the definition of connection = migration . >> My interpretation is that a client moves to a new IP address due to = e.g. a NAT >> rebind or switch from WiFi to cellular, right ?. Is a new connection >> instantiated at a connection migration ? >>>=20 >>> /Ingemar >>>=20 >>> =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 >>>=20 >>> Ericsson Research >>> Network Protocols & E2E Performance >>> Labratoriegr=C3=A4nd 11 >>> 971 28, Lule=C3=A5, Sweden >>> Phone +46-1071 43042 >>> SMS/MMS +46-73 078 3289 >>> ingemar.s.johansson@ericsson.com >>> www.ericsson.com >>>=20 >>> You can't start a fire >>> Worrying 'bout your little world falling apart >>> Bruce Springsteen >>> =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 >=20 From nobody Tue Feb 13 13:55:04 2018 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 91A1D12711B for ; Tue, 13 Feb 2018 13:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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=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 gQgcC2dp23Jb for ; Tue, 13 Feb 2018 13:55:00 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 B85BD12D954 for ; Tue, 13 Feb 2018 13:55:00 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id z197so7428582qkb.6 for ; Tue, 13 Feb 2018 13:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=A+30DrWOuVmphAk86QPSVewnS3FFP0p/v56aM8nb130=; b=hypUcb/aNFSl1aicMHEgVpSpdeIlknw4eSCrqAbp7rPBgfPXW1NBjrm8W/6F2PLzqY ty9r7A3Zz5350ZKLWQpsIlff7hBnSzV47q85Qv4sA3fNzyKcjgANRq81z+d3n5YgjnpH oZE2nXToOorEsAp0IQrMvEkyAjpmkLOVmV5WQwjG613Twgsx3v6EiENLcaIWw2ngAKub oS/EJbfa/6Cz+XRyZ3GbJNtICp10vccFHVaB8z/8xZjQ+ilf9pbBqFBxd5yGzy07uL6g 46SINRM4vmxldqgAizOuQW+rnAorEjoSkkAg42pCr2cjV3P8Fp+ExhDL/9yQJw8Y382M 6biw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=A+30DrWOuVmphAk86QPSVewnS3FFP0p/v56aM8nb130=; b=XKUYSOeseTZSsk0lhdYGRSCd3HsYGbqqHhRJm2X56o4Eugq02eP0ObW0o4B3RWV8uV qa0WHDc6uhAEguJ6NJYL7ytkz6Y93osdJhowkdF7Fg+syH7LCPhUzQrpHH3qpddCYQbj N3HtJrfbORRs/rsILnhySFAZS/dJOIaMXpSMDspvSFuzq6fSgNsvAo7yZdR3edzRTIqo 6Vcf+t2qoUs0106KWiWS1fNIc42QVnDKxNlTlfxSNRSVkpgz7Hocn3ZR7eVTfVQSh0SY JQhsVbuN3N0+dLv6plTKgm+bzuIeseN7Z53mzZiergZK2czyQbHi/rLAjEK1HCw9WWjY ZbuA== X-Gm-Message-State: APf1xPAWmebWPjJ/PzaBFkOb/2w7SdQrBIdbGE1lUVCBAhO+68tZx9PG Aa9BtcatLpptBMIeo3Tr6x34Ew== X-Google-Smtp-Source: AH8x226+woLIR4ZmMJtpFo6eA+Xkl6kkmgRnLh0XVL1gKYlJFxYY5bo7EugCIG1ixNlcs7obJlnK+Q== X-Received: by 10.55.127.133 with SMTP id a127mr4203110qkd.231.1518558899844; Tue, 13 Feb 2018 13:54:59 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id o59sm3007161qte.36.2018.02.13.13.54.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Feb 2018 13:54:59 -0800 (PST) Date: Tue, 13 Feb 2018 16:54:54 -0500 From: Dmitri Tikhonov To: Erik Kline Cc: Martin Duke , IETF QUIC WG Subject: Re: draft-duke-quic-load-balancers-00.txt Message-ID: <20180213215453.GA6686@ubuntu-dmitri> Mail-Followup-To: Erik Kline , Martin Duke , IETF QUIC WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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, 13 Feb 2018 21:55:02 -0000 On Mon, Feb 12, 2018 at 05:34:46PM -0800, Erik Kline wrote: > I wasn't in Melbourne, but I'm curious: why not specify a protocol > over QUIC itself? +1: As I was reading the draft, I was wondering the same thing. - Dmitri. From nobody Tue Feb 13 19:49:13 2018 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 C44E512D961 for ; Tue, 13 Feb 2018 19:49:12 -0800 (PST) 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, 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=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 swP1UODSA1OV for ; Tue, 13 Feb 2018 19:49:11 -0800 (PST) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::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 9E3701200E5 for ; Tue, 13 Feb 2018 19:49:10 -0800 (PST) Received: by mail-wr0-x229.google.com with SMTP id m5so8690959wrg.1 for ; Tue, 13 Feb 2018 19:49:10 -0800 (PST) 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=Y6Av7IS9mGatCLRLFsHM3uQcgG+2eAOfWlTguGoqt2c=; b=Fwhb/dyXdmG/ZeBUtllW5tw9+5HXSrCY+rGXxc4dotFiNTgGADJff0Un7RknWEGy52 4Vp7qJajQ2D3UrFJBk5/39DWdNP6E0z3IwJgClOT5UuMDssWVmmjpl+Ek38qCtD0c7KI HQioBVlEqsGvxyJaOTUMYF5VqOBbJOTAgCdhEkK1sd/I6+hW5eqvcfLPoc5abduKv+dN 952GUTdX2immfah9x4Os/9FWm3srgK638LB4Ce/O9pKYfH46GduMLmbvP+alIUKQV/St eCygCnI6JfCNFVc6v3ZMVevnIgeyUFF+iyOJUgUWoyTXJBxjMj2hFHU0Exy5Bf1PAQTZ eDIA== 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=Y6Av7IS9mGatCLRLFsHM3uQcgG+2eAOfWlTguGoqt2c=; b=RzvG1v+RZWztZgZQNFCo1aD2nFiTowhS5UvKarXrY2WgDQYn6q69998GIP+aLpkMpk EldTeXqhMEYxZbmv1UwB0X5jXiC2ujZMyRY2QDV1BY4jY2AJHNHwNNANDq5m0ez94u1I BHykEH1wY4KlTEGq+dq1QBV4ynBjH2McjlSXSxyUQbSRfapGv5y1mMUTgY5i8Ugb1X+0 6hIi22AcSMy1xWbaaXauw9S5yfY+cUXt8CXbpuJ2Xf15AaZE5+FtQqw9pGmzaEvyYYt2 DqzU8b3ga+iNGv/CIIEf5BZVfhfYKtW/vPuV2tT9ycvn2TF/qEjyvBJ6yvKXmlKxxtMB NpHw== X-Gm-Message-State: APf1xPDYxOlCWOi5JJQe5C9Q/qvIHt8Oe5OEMBjlB7sYAI1Yj3QZ4wIP m/2fz5usjWKEOlbhDeit0HXAm+yTcyvrSaPlJSU= X-Google-Smtp-Source: AH8x2271i15ElsTOIlSIQ8wv0p6GRF7cb0FMPm4THVKYOPPI8GcyInQQCRUO7KqurzV+o4E9KwPsHAZfUWBU2nQAYwg= X-Received: by 10.223.156.135 with SMTP id d7mr3196306wre.184.1518580149076; Tue, 13 Feb 2018 19:49:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.160.211 with HTTP; Tue, 13 Feb 2018 19:49:08 -0800 (PST) In-Reply-To: <20180213215453.GA6686@ubuntu-dmitri> References: <20180213215453.GA6686@ubuntu-dmitri> From: Martin Duke Date: Tue, 13 Feb 2018 19:49:08 -0800 Message-ID: Subject: Re: draft-duke-quic-load-balancers-00.txt To: Erik Kline , Martin Duke , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403043a17a05949d3056523fed1" 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, 14 Feb 2018 03:49:13 -0000 --f403043a17a05949d3056523fed1 Content-Type: text/plain; charset="UTF-8" Oops, I didn't reply all. Repeated below: Hi Erik, That would certainly work. In TCP the load balancers we make have "monitors" that open up TCP connections periodically with servers to make sure they're there and functioning. My thought was that a full-fledged QUIC client implementation might be a little heavyweight for some of these devices. Certainly, if you have an existing Linux L4 load balancer and are looking to write some lightweight code to support QUIC, you probably already have the DTLS APIs you need there. But I am perfectly happy to go with the consensus here. On Tue, Feb 13, 2018 at 1:54 PM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Mon, Feb 12, 2018 at 05:34:46PM -0800, Erik Kline wrote: > > I wasn't in Melbourne, but I'm curious: why not specify a protocol > > over QUIC itself? > > +1: As I was reading the draft, I was wondering the same thing. > > - Dmitri. > --f403043a17a05949d3056523fed1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Oops, I didn't reply all. Repeated below:

Hi Erik,

That would certainly wo= rk. In TCP the load balancers we make have "monitors" that open u= p TCP connections periodically with servers to make sure they're there = and functioning.

My thought was that a full-fledged QUIC cli= ent implementation might be a little heavyweight for some of these devices.= Certainly, if you have an existing Linux L4 load balancer and are looking = to write some lightweight code to support QUIC, you probably already have t= he DTLS APIs you need there. But I am perfectly happy to go with the consen= sus here.


O= n Tue, Feb 13, 2018 at 1:54 PM, Dmitri Tikhonov <dtikhonov@lites= peedtech.com> wrote:
On Mon, Feb 12, 2018 at 05:34:46PM -0800, Erik Kline wrote:
> I wasn't in Melbourne, but I'm curious: why not specify a prot= ocol
> over QUIC itself?

+1: As I was reading the draft, I was wondering the same thing.

=C2=A0 - Dmitri.

--f403043a17a05949d3056523fed1-- From nobody Tue Feb 13 20:56:36 2018 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 089E2120227 for ; Tue, 13 Feb 2018 20:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 w6ug4jqvZSXP for ; Tue, 13 Feb 2018 20:56:33 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E991200E5 for ; Tue, 13 Feb 2018 20:56:32 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,510,1511856000"; d="asc'?scan'208";a="255891949" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx141-out.netapp.com with ESMTP; 13 Feb 2018 20:56:32 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Feb 2018 20:56:32 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 13 Feb 2018 20:56:32 -0800 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=YSxp3eI11msGVAYQ+CdTPAsjSjvhWgMTwEDmHWUhcB8=; b=jSSUlCx+z9mqAsI9ZfiFNJPw5bR0w6fYbWzFIOCuT5xhBc4RtfAT8FBuXU4f7sWFTIL46rIXOuEy1dcaJA5QqCwWSUV9oVX94aQN/UvoeI+bgI5OENcGtr248x2a/TVHyapbmmUL1IvQ1pdDTS2OL8WeXdyN40cBC6uWSLGVxPg= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB356.namprd06.prod.outlook.com (10.141.25.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Wed, 14 Feb 2018 04:56:29 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004%14]) with mapi id 15.20.0506.016; Wed, 14 Feb 2018 04:56:28 +0000 From: "Eggert, Lars" To: Mark Nottingham CC: QUIC WG Subject: Re: Call for Adoption: QCRAM Thread-Topic: Call for Adoption: QCRAM Thread-Index: AQHTnke+zT315wTyMUyZP87eQLP2MaOjY8eA Date: Wed, 14 Feb 2018 04:56:28 +0000 Message-ID: <9283D09A-4A84-4C94-B5CB-D74B25E38D8A@netapp.com> References: <6A834DB6-F2A5-4973-83CD-8AAA82945372@mnot.net> In-Reply-To: <6A834DB6-F2A5-4973-83CD-8AAA82945372@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:3600:8b01:e863:24ec:5f42:aca1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB356; 7:WBpyF8wSKA73MJ1IWePHPce88dDeD8k6Rmnd3Y+xYpCdQUtuVt5xxvZFhD4pl6FOTKCsb/2A/XsTcX1fshCHbxOrp/ei29j4pQfQzHR9cLC3M9IS/loAQEHuaqFtNI69VsXNX4GtRRehoYzk3sZt6x2XdPK6WbA4GyNA7d/+u5zXM3u0wjAe6cocW7uAR65rO9PsRDo8nCRLRqiU+172E5+J8jxZqkWPlmRUVvD8ZFwAWzmbTpXwiJGJLPbmDnek x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 061139a8-dd99-440f-cb62-08d573674f24 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB356; x-ms-traffictypediagnostic: BLUPR06MB356: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231101)(2400082)(944501161)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BLUPR06MB356; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB356; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(346002)(396003)(376002)(377424004)(199004)(189003)(2900100001)(6512007)(82746002)(6306002)(6486002)(76176011)(33656002)(4001150100001)(478600001)(6116002)(4326008)(105586002)(14454004)(966005)(6436002)(36756003)(305945005)(7736002)(50226002)(99936001)(99286004)(5250100002)(57306001)(229853002)(81166006)(5660300001)(3280700002)(8936002)(8676002)(316002)(81156014)(86362001)(68736007)(2906002)(106356001)(186003)(6916009)(6506007)(6246003)(97736004)(83716003)(3660700001)(102836004)(2950100002)(53936002)(25786009)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB356; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: WfngDvDuK7CQQ0l8G/n7HPDstElIdPB0x5ZGfpAXfC4UvN7jO0m+5wfkS8Qg6lb+QReM16qXf6nUHW5AX9Vx/A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_A0D0284F-C45D-4C14-98FA-7E21CC91646A"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 061139a8-dd99-440f-cb62-08d573674f24 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 04:56:28.5211 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB356 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, 14 Feb 2018 04:56:35 -0000 --Apple-Mail=_A0D0284F-C45D-4C14-98FA-7E21CC91646A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Having seen nothing but support, this document is adopted. Lars On 2018-2-5, at 7:07, Mark Nottingham wrote: >=20 > In Melbourne, there was strong support (with a small amount of = pushback which was discussed) for adopting QCRAM: >=20 > https://tools.ietf.org/html/draft-krasic-quic-qcram-04 >=20 > Any objections / concerns about doing so? Unless we hear otherwise, = we'll adopt at the end of the week. >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 --Apple-Mail=_A0D0284F-C45D-4C14-98FA-7E21CC91646A 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlqDwXsACgkQVLXDCb9w wVfYjw//S2wY3EM8kiFUyaq5br4hQNN/p6nsyoozyjfppymIToxARXTg1VioNSWD BeWqlpO4p85i0G6+Gcp6ZrhCntf9zhMgvgtK9sslOuguemb2Q2ynAC8fV8dwAwjZ S2DH3+b18L3Ak9Z8goIMQKjx7o/qqrvh9lTEb+PhRTkDJd9HdpgCxFLwhw4NMeoy sXpd+ZIfr9KNDysRwiBw4I+wD1FqpJu/+cpecDgnGwaupoZarHvPNiUlRr4llZK6 Gh/YvXMx8PJG0t2t9SpOkHSRIiwUDHPph3Xbttri8v1XMUWJZa08NSojH9B6CgnN tZ2dhC2efUYEoGu950CfqPXf0dAQiDH9YDU1wxtNm9OiXCc+cJLotzEre4ajHnMx 6MxiDEjJ4ZkT/x959HNBXulvnwbRWqh3qQal0rD1550/HD/vTCRuoGhCJkgs3xMe wfPAOFlfXpJCld67Np+df8VDfbyqlsbevLaiPOjrz/YH1lfRYZcHIefUq1AoSZJw iRmSvX47DtsrE5TOre4M0PPRbdDUhKvvlZcyjEflgMplmFsKJETMaIVbiO5deKS8 Rp1IBEYw//OYrzz2whJ+E19xYWmD0S+UvoL0gT/6XKscRgbrHBcWLZ2HtuCiApYt vXZ3XI8fx5vOEf42UTdxcXzvZn5JNH4V4zJpCrvucbaugx33/jg= =6NR3 -----END PGP SIGNATURE----- --Apple-Mail=_A0D0284F-C45D-4C14-98FA-7E21CC91646A-- From nobody Tue Feb 13 21:00:03 2018 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 D12A51242F7 for ; Tue, 13 Feb 2018 21:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 p_7p-h9SJWtQ for ; Tue, 13 Feb 2018 20:59:58 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A36E01200E5 for ; Tue, 13 Feb 2018 20:59:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,510,1511856000"; d="asc'?scan'208";a="237493418" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx142-out.netapp.com with ESMTP; 13 Feb 2018 20:59:57 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Feb 2018 20:59:57 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 13 Feb 2018 20:59:56 -0800 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 13 Feb 2018 20:59:57 -0800 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=5pnMGGS1WKjCWTyKUjgi0qgp6JZRRwbfqBoKhz12TEg=; b=QPSxzuNdPUsIaAEJOjzCf7lKX/6Mcclu7HGdAgClj7A+THXvrJqG2qHkbNPWw/f/ywXY/saec40+9iy/kBkpTtQylRUvwkog/gjzyY/+GNGMdIpyrAuRwQd3VyyRHuJc7mzWTrkCvuX3C+oOhObhE+fw03RyzYmB0D1NcIyUNAA= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB356.namprd06.prod.outlook.com (10.141.25.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Wed, 14 Feb 2018 04:59:55 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004%14]) with mapi id 15.20.0506.016; Wed, 14 Feb 2018 04:59:54 +0000 From: "Eggert, Lars" To: Mark Nottingham CC: QUIC WG Subject: Re: Call for Adoption: Invariants Thread-Topic: Call for Adoption: Invariants Thread-Index: AQHTnke3HW8OOTm0V0CAvkvPP5VKl6OjZL2A Date: Wed, 14 Feb 2018 04:59:54 +0000 Message-ID: <69FADC41-FEA6-4923-ACB6-1FC7C71BF987@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.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:3600:8b01:e863:24ec:5f42:aca1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB356; 7:Yw89uhNmta+nU6HU1ef3zkC+AVBrV5wjr1nGGfThs9d/7OeXHD5g7pFLkYa+X38XS0wCEnUgt3zxxFUESpx1ZvMj9iH26IU0HZlQFL3DOlCFNJcuTDHrd3lp9Gtw0pdPsgDBPfE7NeHc3GYTWBHV5ytjsgrawQtwIo4Vw7dY8zCPCIWewVA+lAKWcqELl3OblKl61VmBBB1B/qAw/i0q6dPX/MzKGTaDHWsqM6MvrQm8NPrfkOId1Xa3Rj7qWDb+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ac3e007b-abdd-4ad6-a43e-08d57367c9e3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB356; x-ms-traffictypediagnostic: BLUPR06MB356: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231101)(2400082)(944501161)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:BLUPR06MB356; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB356; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(346002)(396003)(376002)(377424004)(199004)(189003)(2900100001)(6512007)(82746002)(6306002)(6486002)(76176011)(33656002)(4001150100001)(478600001)(6116002)(4326008)(105586002)(14454004)(966005)(6436002)(36756003)(305945005)(7736002)(50226002)(99936001)(99286004)(5250100002)(57306001)(229853002)(81166006)(5660300001)(3280700002)(8936002)(8676002)(316002)(81156014)(86362001)(68736007)(2906002)(106356001)(186003)(6916009)(6506007)(6246003)(97736004)(83716003)(3660700001)(102836004)(2950100002)(53936002)(25786009)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB356; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: FRU8WBA9xkxif0TPxaQv5zJy1QZqJ7PiNhUT996uHT7g+erbD9ryChYhuMJ4/+lSD3KCvUCtYbLwuOl/e2DCig== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_E6CED4C9-4CC3-46E0-BC35-3FBE07A76D0F"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ac3e007b-abdd-4ad6-a43e-08d57367c9e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 04:59:54.6882 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB356 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, 14 Feb 2018 05:00:01 -0000 --Apple-Mail=_E6CED4C9-4CC3-46E0-BC35-3FBE07A76D0F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Having seen nothing but support, this document is adopted. Lars > On 2018-2-5, at 7:07, Mark Nottingham wrote: >=20 > At the Melbourne meeting, there was strong support for adopting = Martin's invariants draft: >=20 > https://tools.ietf.org/html/draft-thomson-quic-invariants-00 >=20 > Any objections / concerns about doing so? Unless we hear otherwise, = we'll adopt at the end of the week. >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 --Apple-Mail=_E6CED4C9-4CC3-46E0-BC35-3FBE07A76D0F 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlqDwkoACgkQVLXDCb9w wVf5Bg/7Bcwg2bTYVyV21QHq/ID8gVdJVXxllOvNgJU/rl0mvLSUn/EhPfWuUnh6 JS+Nh+Rt7jkFqK9HfOWEYBl7BOhnhMISLqGbnru9jgRrt1H96xmHzQmPd1PSnQ2D munEtJ/aTXPAl9dPmUYWTz5LgddTiP09Q8ntnT7JGvY6GtJLnDWwjXVGkzrfnAK1 wjZXNZU/jtY1++JxS/ttRC/QMyDcidKiiC14XrpgTw/73v5H50rrp/+gM7q8n5S7 ALvFR/3Lyx0xatr6klxQyuYbhIH2K+0LmnWoes8MMe2lmL2yD79leNbFKOYhAM5Z VVyd+mIjOHnhH6qFa8zgsGn9788gFt8VkT/mb1ntrp7nCmSQatdkoud+ICvAtQEr 3DxOeg4d+9OWIVA6/TDFlBDxJgxcIYK7oHD8wlGY8rlCYmUEmSjwlvIhwTdt1Ko3 67fXbIyNOD9HJyFjrCZe4ZM8pEbGhITzHc2IxAxDL5E/5RDCC8xg9C3aqXyJ0/r6 uA5fplS/qs7H+YW+USy2C4lGuRrnEa/CWVp4sXXjJZwH1P1JrRb9VILcYu+zojsx nw1jYNXiOliCZuia++5pekSX/0t4bzvtU2Gz6sYcfTDZAGf7wKbuwKaBinFDPQJQ W79MsEFGC23+p1mm29AmdKoQ68Opfx3rSmKOf/grLIgkalPcKz0= =yLBJ -----END PGP SIGNATURE----- --Apple-Mail=_E6CED4C9-4CC3-46E0-BC35-3FBE07A76D0F-- From nobody Tue Feb 13 22:39:08 2018 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 7D781124F57 for ; Tue, 13 Feb 2018 22:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, 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=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 4Px-xY6fqau5 for ; Tue, 13 Feb 2018 22:39:04 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 537E2124B17 for ; Tue, 13 Feb 2018 22:39:04 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1E6aq89011958; Wed, 14 Feb 2018 06:39:02 GMT 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=dMWWjZv8CEUPdJM1xoBVIXKOsavHGI6P6NqSMSGYQCY=; b=ea3lo95t0i+kofivDSN6C2iaOcFtvof0rXtlzPAP51ZKBAiJfnyu/RqUr2/9JoN0CH0l Rw2rqdRqMDrAPxyWj4T6yfHJJJW/1VS3kjwX5GecyLnFwt65anPGfWYBaEaqc3VLzB4q WtPmRCE0NwL0/ArUqMk2ViGTznT7NwWvWtQW4+ULIb9X9Dp2vNYOCt6Ql0wZJXvluiP1 kuJsnSNyKE4NjFdPJAt6fnNJIJ+uPRzmg8LRh8PI27CYaPUNw8hkX6xzAhPaNkZTUsxX 9RnnRKUmCo/AUn52nIVr4qfVUUdvq1OTw4H6GTv3Er2LoL2iFSudNw1wouLkGeUppPjL cg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2g48x00xm5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Feb 2018 06:39:02 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1E6aTZc023101; Wed, 14 Feb 2018 01:39:01 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2g1vy0452j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 14 Feb 2018 01:39:01 -0500 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; Wed, 14 Feb 2018 01:39:00 -0500 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; Wed, 14 Feb 2018 01:39:00 -0500 From: "Lubashev, Igor" To: Martin Duke , IETF QUIC WG Subject: RE: draft-duke-quic-load-balancers-00.txt Thread-Topic: draft-duke-quic-load-balancers-00.txt Thread-Index: AQHTpE5n5n3EqIWdaEi44FdaO/490KOjcQ+w Date: Wed, 14 Feb 2018 06:38:59 +0000 Message-ID: <4964f7cf3f1b4ddbbc7bf76595cf27c9@usma1ex-dag1mb5.msg.corp.akamai.com> References: 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.44.68] Content-Type: multipart/alternative; boundary="_000_4964f7cf3f1b4ddbbc7bf76595cf27c9usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-14_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802140078 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-14_01:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802140078 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, 14 Feb 2018 06:39:06 -0000 --_000_4964f7cf3f1b4ddbbc7bf76595cf27c9usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVsYXRpdmVseSBtaW5vciBuaXQ6DQoNCuKAnEEgcmVwcmVzZW50YXRpdmUgZW5jb2RpbmcgdGhh dCBtZWV0cyB0aGVzZSByZXF1aXJlbWVudHMgbWlnaHQNCiAgIGNvbmNhdGVuYXRlIHRoZSBzZXJ2 ZXIncyBJUHY0IGFkZHJlc3MgYW5kIGEgbW9ub3RvbmljYWxseSBpbmNyZWFzaW5nDQogICBzZXF1 ZW5jZSBudW1iZXIsIGFuZCB0aGVuIGVuY3J5cHQgdGhlIHJlc3VsdCB0byBvYnRhaW4gdGhlDQog ICBjb25uZWN0aW9uIElELuKAnQ0KDQpZb3UgbWF5IHdhbnQgdG8gY29uc2lkZXIgYSBub25jZSBh cyBhbiBpbnB1dCB0byB5b3VyIGNyeXB0byBmdW5jdGlvbiB0byBkZXRlY3QgYXR0YWNrcyB2aWEg Zm9yZ2VkIENJRHMuICBJbiBjYXNlIHRoZSBzYW1lIGJhY2tlbmQgc2VydmVyIG1heWJlIHVzZWQg Zm9yIG11bHRpcGxlIFZpcnR1YWwgSVBzLCB5b3UgbWF5IGFsc28gd2FudCB0byBpbmNsdWRlIHRo ZSBWaXJ0dWFsIElQIChhbmQgZGVzdGluYXRpb24gcG9ydCkgYXMgYW4gaW5wdXQgdG8gdGhlIGNy eXB0byBmdW5jdGlvbiB0byBpbmNyZWFzZSB0aGUgbnVtYmVyIG9mIHBvc3NpYmxlIHVuaXF1ZSBD SURzIGdlbmVyYXRlZCAoSVB2NCBhbmQgdGhlIG5vbmNlIG1heSBsZWF2ZSB5b3Ugd2l0aCBmZXcg ZXh0cmEgYml0cywgdW5sZXNzIDEyOC1iaXQgQ0lEIGlzIHVzZWQsIHNvIGZpbmQgZXh0cmEgYml0 cyB3aGVyZSB5b3UgY2FuKS4NCg0KDQpGcm9tOiBNYXJ0aW4gRHVrZSBbbWFpbHRvOm1hcnRpbi5o LmR1a2VAZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAxMiwgMjAxOCA1OjExIFBN DQpUbzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogZHJhZnQtZHVrZS1x dWljLWxvYWQtYmFsYW5jZXJzLTAwLnR4dA0KDQpCYXNlZCBvbiBjb252ZXJzYXRpb25zIGluIE1l bGJvdXJuZSwgSSBwb3N0ZWQgYSBzdHJhdyBtYW4gZm9yIGEgc3RhbmRhcmQgd2F5IGZvciBsb2Fk IGJhbGFuY2VycyBhbmQgc2VydmVycyB0byBjb29yZGluYXRlIG9uIHJvdXRhYmxlLCB1bmxpbmth YmxlIGNvbm5lY3Rpb24gSURzLg0KDQpEYXRhdHJhY2tlcjogaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZHVrZS1xdWljLWxvYWQtYmFsYW5jZXJzLzxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYu b3JnX2RvY19kcmFmdC0yRGR1a2UtMkRxdWljLTJEbG9hZC0yRGJhbGFuY2Vyc18mZD1Ed01GYVEm Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlq VVpkbl9tNTVLUG1sbyZtPVB0U2VZMElQQ3BTWmFIX2MySE54Yk1HUEZpSlZsZ3ktbzFhQ0tFbklf djgmcz1pcUJJTFQ3b0lyc2FmUWM3LUN3X2dtM0kwNDBKbXlJYnJsbkRBYzRiOXF3JmU9Pg0KR2l0 aHViOiBodHRwczovL2dpdGh1Yi5jb20vbWFydGluZHVrZS9kcmFmdC1kdWtlLXF1aWMtbG9hZC1i YWxhbmNlcnM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBz LTNBX19naXRodWIuY29tX21hcnRpbmR1a2VfZHJhZnQtMkRkdWtlLTJEcXVpYy0yRGxvYWQtMkRi YWxhbmNlcnMmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9RGpuM2JRNXVOSkRQ TV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyZtPVB0U2VZMElQQ3BTWmFIX2MySE54Yk1H UEZpSlZsZ3ktbzFhQ0tFbklfdjgmcz1SaUNmVU1QMjVvSm0tTC1lOXExdlZ6Z3Rrd25TbjdQMndk QzVRLTdCeUdNJmU9Pg0KDQpUaGVyZSdzIG5vdGhpbmcgZWFydGhzaGFraW5nIGhlcmU6IHdlIHVz ZSBEVExTIGZvciBhdXRoZW50aWNhdGlvbiBhbmQgZW5jcnlwdGlvbiwgYW5kIGhhdmUgYSBmZXcg dmVyeSBzaW1wbGUgVURQIG1lc3NhZ2VzIHRvIGtlZXAgdGhlIGNvbm4gSURzIHN5bmNlZC4gVGhl IGRyYWZ0IGlzbid0IHZlcnkgbG9uZy4NCg0KSSdsbCBpbmNvcnBvcmF0ZSB2YXJpYWJsZSBsZW5n dGggY29ubmVjdGlvbiBJRHMsIGV0Yywgd2hlbiBhbmQgaWYgdGhleSBlbnRlciB0aGUgbWFpbmxp bmUuIEknbSBjZXJ0YWlubHkgaW50ZXJlc3RlZCBpZiB0aGlzIG1lZXRzIHRoZSBuZWVkcyBvZiB0 aGUgcGVvcGxlIGFjdGl2ZWx5IGxvb2tpbmcgZm9yIGEgc29sdXRpb24gaW4gdGhpcyBzcGFjZS4N Cg0KDQoNCg== --_000_4964f7cf3f1b4ddbbc7bf76595cf27c9usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWxhdGl2ZWx5IG1pbm9yIG5pdDo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+4oCcQSByZXByZXNlbnRhdGl2ZSBlbmNvZGluZyB0aGF0IG1lZXRzIHRoZXNlIHJl cXVpcmVtZW50cyBtaWdodDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7IGNvbmNhdGVuYXRlIHRoZSBzZXJ2ZXIncyBJUHY0IGFkZHJlc3MgYW5kIGEgbW9u b3RvbmljYWxseSBpbmNyZWFzaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsmbmJzcDsgc2VxdWVuY2UgbnVtYmVyLCBhbmQgdGhlbiBlbmNyeXB0IHRoZSByZXN1 bHQgdG8gb2J0YWluIHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7Jm5ic3A7IGNvbm5lY3Rpb24gSUQu4oCdPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBt YXkgd2FudCB0byBjb25zaWRlciBhIG5vbmNlIGFzIGFuIGlucHV0IHRvIHlvdXIgY3J5cHRvIGZ1 bmN0aW9uIHRvIGRldGVjdCBhdHRhY2tzIHZpYSBmb3JnZWQgQ0lEcy4mbmJzcDsgSW4gY2FzZSB0 aGUgc2FtZSBiYWNrZW5kIHNlcnZlciBtYXliZSB1c2VkIGZvciBtdWx0aXBsZSBWaXJ0dWFsIElQ cywgeW91IG1heSBhbHNvIHdhbnQgdG8gaW5jbHVkZSB0aGUgVmlydHVhbCBJUCAoYW5kIGRlc3Rp bmF0aW9uIHBvcnQpDQogYXMgYW4gaW5wdXQgdG8gdGhlIGNyeXB0byBmdW5jdGlvbiB0byBpbmNy ZWFzZSB0aGUgbnVtYmVyIG9mIHBvc3NpYmxlIHVuaXF1ZSBDSURzIGdlbmVyYXRlZCAoSVB2NCBh bmQgdGhlIG5vbmNlIG1heSBsZWF2ZSB5b3Ugd2l0aCBmZXcgZXh0cmEgYml0cywgdW5sZXNzIDEy OC1iaXQgQ0lEIGlzIHVzZWQsIHNvIGZpbmQgZXh0cmEgYml0cyB3aGVyZSB5b3UgY2FuKS48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWFydGluIER1a2UgW21haWx0bzptYXJ0aW4uaC5kdWtlQGdt YWlsLmNvbV0gPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgRmVicnVhcnkgMTIsIDIwMTggNTox MSBQTTxicj4NCjxiPlRvOjwvYj4gSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBkcmFmdC1kdWtlLXF1aWMtbG9hZC1iYWxhbmNlcnMtMDAudHh0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYXNlZCBvbiBjb252ZXJzYXRpb25zIGlu IE1lbGJvdXJuZSwgSSBwb3N0ZWQgYSBzdHJhdyBtYW4gZm9yIGEgc3RhbmRhcmQgd2F5IGZvciBs b2FkIGJhbGFuY2VycyBhbmQgc2VydmVycyB0byBjb29yZGluYXRlIG9uIHJvdXRhYmxlLCB1bmxp bmthYmxlIGNvbm5lY3Rpb24gSURzLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGF0YXRyYWNrZXI6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19k b2NfZHJhZnQtMkRkdWtlLTJEcXVpYy0yRGxvYWQtMkRiYWxhbmNlcnNfJmFtcDtkPUR3TUZhUSZh bXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcx dHpjSXh5alVaZG5fbTU1S1BtbG8mYW1wO209UHRTZVkwSVBDcFNaYUhfYzJITnhiTUdQRmlKVmxn eS1vMWFDS0VuSV92OCZhbXA7cz1pcUJJTFQ3b0lyc2FmUWM3LUN3X2dtM0kwNDBKbXlJYnJsbkRB YzRiOXF3JmFtcDtlPSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZHVr ZS1xdWljLWxvYWQtYmFsYW5jZXJzLzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdGh1YjombmJzcDs8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fbWFydGlu ZHVrZV9kcmFmdC0yRGR1a2UtMkRxdWljLTJEbG9hZC0yRGJhbGFuY2VycyZhbXA7ZD1Ed01GYVEm YW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1dU5KRFBNXzJza2ZMM3JX MXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPVB0U2VZMElQQ3BTWmFIX2MySE54Yk1HUEZpSlZs Z3ktbzFhQ0tFbklfdjgmYW1wO3M9UmlDZlVNUDI1b0ptLUwtZTlxMXZWemd0a3duU243UDJ3ZEM1 US03QnlHTSZhbXA7ZT0iPmh0dHBzOi8vZ2l0aHViLmNvbS9tYXJ0aW5kdWtlL2RyYWZ0LWR1a2Ut cXVpYy1sb2FkLWJhbGFuY2VyczwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUncyBub3RoaW5nIGVhcnRoc2hha2luZyBoZXJlOiB3 ZSB1c2UgRFRMUyBmb3IgYXV0aGVudGljYXRpb24gYW5kIGVuY3J5cHRpb24sIGFuZCBoYXZlIGEg ZmV3IHZlcnkgc2ltcGxlIFVEUCBtZXNzYWdlcyB0byBrZWVwIHRoZSBjb25uIElEcyBzeW5jZWQu IFRoZSBkcmFmdCBpc24ndCB2ZXJ5IGxvbmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbGwgaW5jb3Jwb3JhdGUgdmFyaWFibGUgbGVuZ3Ro IGNvbm5lY3Rpb24gSURzLCBldGMsIHdoZW4gYW5kIGlmIHRoZXkgZW50ZXIgdGhlIG1haW5saW5l LiBJJ20gY2VydGFpbmx5IGludGVyZXN0ZWQgaWYgdGhpcyBtZWV0cyB0aGUgbmVlZHMgb2YgdGhl IHBlb3BsZSBhY3RpdmVseSBsb29raW5nIGZvciBhIHNvbHV0aW9uIGluIHRoaXMgc3BhY2UuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_4964f7cf3f1b4ddbbc7bf76595cf27c9usma1exdag1mb5msgcorpak_-- From nobody Wed Feb 14 01:16:34 2018 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 0CC19126D46 for ; Wed, 14 Feb 2018 01:16:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 DWS8vhI-NOhk for ; Wed, 14 Feb 2018 01:16:31 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::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 854B8128961 for ; Wed, 14 Feb 2018 01:16:24 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id f4so24450952ioh.8 for ; Wed, 14 Feb 2018 01:16:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=jxkKDwo7dwiVBfQfcADC7fM8dxMJA5OK7/6Trp42b1Y=; b=k+SC/36UazPOC00qJAl65LXp8mDlGFnYUtvTnUFKxa7BFejJhoj0Sj7jS1Dfm2F6Ie z+2k0GafNoOSh7N09lK3/5K1yMptsChCGMOn5F0tAiREBLZ7Igfr1YYkfSOOifVncbJT Qcfd2Rje3HtnFdFx9MjhCTp71+KQk0gfa4eIYPe1qwevX694ri73eTt8ryRP4YFgC8Sj p51/mZxJ3SOxf28FoYCeUPKvhlJvuV9atfP0L5nGVgH1Vw8qmj4LfrmS0OLksQc8ndB4 ni7PvFL7BlSzELkhAnoXZ3Qyu2EQjR7izbXCpY8SNra3OV37ATguJuEJlRAYMkpCSYT2 naKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=jxkKDwo7dwiVBfQfcADC7fM8dxMJA5OK7/6Trp42b1Y=; b=LkAPJWO9eTidvnxPF7PQ0fHGTqEX90smlqQuyli+/iaOsmBlkQJWtcL4MssrHL+BjN zT157k4ldh+loDjYGUoDIc9Wqss9eg9Sk5IMQ5rPVERGG+6lQ2JxKWmqux+iMa2HxxMw +V+cI2X/oZBUTJoH7/B6J2TSiDCz0PIWN7C2GhRSg9U6GeOei7GQrmLgekb8N1PxYQCi QGlSXDz94i1jwz8E8K0cYG9UOBt3P6h0Wlzbkym1onvr4sfg3/DQcEIfnDHd8ICmZ25r J2Bc9rBPMEqs1+eP4/iO/ScGpcZrwinlm3R2QX9DaziqBLr2iiGOqWSdtXJzHqSocwP7 9TuQ== X-Gm-Message-State: APf1xPA74H1QYgXqT+NVop08XGEShcxgDI6QUDkH+GoKXN+zR3EMZhLp EtlqZVJuzh38Ta2xqZm2qMlpaxEfkaz0R2fbY3g= X-Google-Smtp-Source: AH8x22447eD7DvA0TEeXhB3fPgL7BcrkBdF2xE/N2S7KqkJoQIYpXy1PYXWkNadVHbAWndUk/Bzbip+oaMqKQBJbgJw= X-Received: by 10.107.168.31 with SMTP id r31mr4543935ioe.16.1518599783916; Wed, 14 Feb 2018 01:16:23 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 14 Feb 2018 01:16:22 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <20180213215453.GA6686@ubuntu-dmitri> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 14 Feb 2018 01:16:22 -0800 Message-ID: Subject: Re: draft-duke-quic-load-balancers-00.txt To: Erik Kline , IETF QUIC WG , Martin Duke Content-Type: multipart/alternative; boundary="001a11427686ad2ba505652890a8" 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, 14 Feb 2018 09:16:33 -0000 --001a11427686ad2ba505652890a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was also wondering about why not using QUIC, but a load balancer does not need to understand QUIC to route QUIC, especially not with this protocol. But it complicates QUIC endpoints having to deal with another crypto transport mechanism. I don=E2=80=99t think the argument of keeping routers simpler is very stron= g - it may be true short term - but eventually routers will understand QUIC. A downside to using QUIC is that routers may stick to an old version of QUIC for a long time. One could imagine a set of central control servers providing CID=E2=80=99s = rather than the QUIC server itself - this would remove some of the versioning concern, but then bother router and QUIC server would have to connect to the central control system. This isn=E2=80=99t so different from a MQTT configuration and would simplify the configuration matrix. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 14 February 2018 at 04.49.17, Martin Duke (martin.h.duke@gmail.com) wrote: Oops, I didn't reply all. Repeated below: Hi Erik, That would certainly work. In TCP the load balancers we make have "monitors" that open up TCP connections periodically with servers to make sure they're there and functioning. My thought was that a full-fledged QUIC client implementation might be a little heavyweight for some of these devices. Certainly, if you have an existing Linux L4 load balancer and are looking to write some lightweight code to support QUIC, you probably already have the DTLS APIs you need there. But I am perfectly happy to go with the consensus here. On Tue, Feb 13, 2018 at 1:54 PM, Dmitri Tikhonov < dtikhonov@litespeedtech.com> wrote: > On Mon, Feb 12, 2018 at 05:34:46PM -0800, Erik Kline wrote: > > I wasn't in Melbourne, but I'm curious: why not specify a protocol > > over QUIC itself? > > +1: As I was reading the draft, I was wondering the same thing. > > - Dmitri. > --001a11427686ad2ba505652890a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I was also wondering= about why not using QUIC, but a load balancer does not need to understand = QUIC to route QUIC, especially not with this protocol.

But it complicates QUIC endpoints having = to deal with another crypto transport mechanism.
I don=E2=80=99t think the argument of k= eeping routers simpler is very strong - it may be true short term - but eve= ntually routers will understand QUIC.

A downside to using QUIC is that routers may stick to an o= ld version of QUIC for a long time.

One could imagine a set of central control = servers providing CID=E2=80=99s rather than the QUIC server itself - this w= ould remove some of the versioning concern, but then bother router and QUIC= server would have to connect to the central control system. This isn=E2=80= =99t so different from a MQTT configuration and would simplify the configur= ation matrix.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 14 February 2018 at 04.49.17, Martin Duke (martin.h.duke@gmail.com) wrote:

Oops, I didn't reply all. Repeated below:

Hi Erik,

That would certainly work. In TCP the load balancers we make have "monitors" that open up TCP connections periodically with servers to make sure they're there and functioning.

My thought was that a full-fledged QUIC client implementation might be a little heavyweight for some of these devices. Certainly, if you have an existing Linux L4 load balancer and are looking to write some lightweight code to support QUIC, you probably already have the DTLS APIs you need there. But I am perfectly happy to go with the consensus here.


On Tue, Feb 13, 2018 at 1:54 PM, Dmitri Tikhonov <dtikhonov@litespeedtech.com> wrote:
On Mon, Feb 12, 2018 at 05:34:46PM -0800, Erik Kline wrote:
> I wasn't in Melbourne, but I'm curious: why not specify a protocol
> over QUIC itself?

+1: As I was reading the draft, I was wondering the same thing.

=C2=A0 - Dmitri.

--001a11427686ad2ba505652890a8-- From nobody Wed Feb 14 05:08:41 2018 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 32159124234 for ; Wed, 14 Feb 2018 05:08:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.com header.b=LDNu61Kc; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kzYA95Rm 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 ybN5_Oxrf1Kt for ; Wed, 14 Feb 2018 05:08:35 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 110FA120454 for ; Wed, 14 Feb 2018 05:08:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518613713; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z9LK4WFgqhowzvjri4lqCcK+oeGo84PQ6cvI6bwsKWM=; b=LDNu61KcMPGvaN5hcVQnTiy86332eomounmX/OoaRSmrDPv/PeijZdMrMCGBoDly F4cpfeM4UXMEXPNNPf5+1s398r9rRacN/3d57UyPsy6ppY/muqXQESPGvqmNU6At 6DKh+ij4YbMzzXe3RmcnGo2QgTKBW3onFAcFmYw9YeI=; X-AuditID: c1b4fb30-799639c000004778-d4-5a8434d16c6c Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A1.90.18296.1D4348A5; Wed, 14 Feb 2018 14:08:33 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 14 Feb 2018 14:08:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YDwsar+J2JoCVZsFzqRZoe6uN21LycjFTTbmuX1vIVA=; b=kzYA95RmWzCz6vtNtibN+QFjhSR+eVHfnshbhqflyICs5aMnjxtrH6OMgnBF2A9c40dvomQ9g625jRgC0BAX0Vq2OMY2izeG45dt05CQbOkVPJ1fS69WsgIL7grnFsL+cZyOdzVLBpJ+IuytF1jf6DUdIjQkgzMCNtcycz5QP40= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3674.eurprd07.prod.outlook.com (52.133.6.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Wed, 14 Feb 2018 13:08:30 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::38e6:dea0:2f4f:715]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::38e6:dea0:2f4f:715%13]) with mapi id 15.20.0506.013; Wed, 14 Feb 2018 13:08:30 +0000 From: Ingemar Johansson S To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= CC: "De Schepper, Koen (Nokia - BE/Antwerp)" , "ekinnear@apple.com" , "Lubashev, Igor" , Ian Swett , QUIC WG , Christian Huitema , Ingemar Johansson S Subject: RE: ECN in QUIC connection migration Thread-Topic: ECN in QUIC connection migration Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25AAZWcAAAB/s3/ABUaWKkACnvEWAAAvBcBAAIFvbgAAzEkjA Date: Wed, 14 Feb 2018 13:08:30 +0000 Message-ID: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> <5CC94D22-1375-40A2-8084-BA4A43F6FA94@tik.ee.ethz.ch> In-Reply-To: <5CC94D22-1375-40A2-8084-BA4A43F6FA94@tik.ee.ethz.ch> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3674; 7:2aWvUr2qEVXAhG5nGUdMMSePcjrY6J3RZvScy85peYN6Pdn7VBwRU+LHmcKE9oj6ZqYUx0QcpHLtsuO6EOvPtCJ7IaS9p/WqkvIFlA//eBZl5dTvu3NzJewwaMNPbOh4WuvLnsu8YFR73fQLGJgU4ZucYMB8sz6N/hVmU/oCzNRkvYtk7zih4dG/MlmkXZHLTQlsT9g29ozk72wc3+R/Gu17UiI6DnXhDPfldP+aryhU5C9wLFqPLMZwaCc8gv60 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-ms-office365-filtering-correlation-id: 8243a48f-a230-40f4-7f9d-08d573ac0b75 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(49563074)(7193020); SRVR:HE1PR0702MB3674; x-ms-traffictypediagnostic: HE1PR0702MB3674: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(244540007438412)(166708455590820)(211936372134217)(100405760836317)(202460600054446)(153496737603132)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(944501161)(10201501046)(93006095)(93001095)(6041288)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:HE1PR0702MB3674; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3674; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39860400002)(396003)(39380400002)(189003)(199004)(51914003)(13464003)(186003)(81156014)(81166006)(8666007)(6436002)(2906002)(8676002)(106356001)(55016002)(3280700002)(6306002)(8936002)(9686003)(3660700001)(2900100001)(86362001)(74316002)(305945005)(7736002)(5250100002)(3846002)(6116002)(15974865002)(99936001)(53936002)(105586002)(33656002)(2950100002)(66066001)(6916009)(99286004)(97736004)(4743002)(25786009)(6506007)(5890100001)(54906003)(5660300001)(107886003)(478600001)(93886005)(4326008)(316002)(68736007)(59450400001)(14454004)(76176011)(53546011)(102836004)(6246003)(26005)(966005)(229853002)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3674; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CJZ+9GN9blbBWCu/4uR630Z8t53Or6kubgG9AWGiS726OPlXtif7tJAIXrExo/6R26oCk5sliXp8Zz7FSR0I/A== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/mixed; boundary="_002_HE1PR0702MB3625310E4FC43F4BCA7717EEC2F50HE1PR0702MB3625_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8243a48f-a230-40f4-7f9d-08d573ac0b75 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 13:08:30.5362 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3674 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHfc85285Wg7c124Nll1EfMpuWRoMksj60giIrKfalph5spLPO Uak+hFeq6cJKU7dY62J5KVNbqS0hZ4jLKNcFNCwvadoV3UoTy3I7C/r2e97/j+d5eHhpUvZb EELrDekMa9ClKIUSqnx/Y9xqd3SeNrJmSqEuHN+qvpBtEamn3jUL1DlZlaS6faKCUNfVFFPq QtucTSLNhcc2UnPP9VOosTVkaN6UPaE0169PEZqciatCTfvYD+EukVYSk8Sk6DMZNmLjQcmh Es+M6Ii3Fh0rcfejLGSqRkZE04CjwXp/sRFJaBluQ/C4+Tviiw4EDxxDQl9BYQ8BZwt6BXxS SkDthDegDc9qbRbKiMS0EMdAlXPS31eOt4PXE+dzSOwioNJdRfic+VgF7p4aoY/lOAIautwE 72vBa03wIYVXQGd1os+Q4oNQVm8n+VGnKZgq/Ub6AjHeDHfzu5GPEQ6Fvsl3/hVIrIA3Q5f9 owDLYcDdKeQ5GD6+nxHwfiJ4ekwC/n0p/HoxGHBC4cXlAsTzfQLsI/E8R4Gx6GHA3wHT1/r8 CwF+heBK6UWSD8Kh4pEtIKWByVhI8VIdAmdpOcEXVhIspq6AtQhmblVQRUhl/m9znvVgbM1D Zv8J5oGrfIgyz16GxCvhzoMIXlkGxQUDIp63QLnrHsnzejh/6W2AWxH0Dq/737chcTUK5hgu ITV57VoVw+oTOS7NoDIw6Q1o9iO22qcjm9DHkVgnwjRSzpXKF+ZpZQJdJnc81YmWz/YZrKvp QiGUIc3AKOXSqOe5Wpk0SXf8BMOmHWAzUhjOiRbSlFIhdW2TamU4WZfOHGaYIwz7LyVocUgW 0q0yNvfvebniU93Rt/J8y+jZyZavrQ5H7oHI3FMjCWOLPt+cq1rgfj1WWWG3PD1pvxYehFLi 9wlse5913Db1nAr6o4w1Z22y7iwiOEmMdLQxcxnruO3dMD4aZm1TTLQkmsOM+g+Tq5ZEdvY2 HWXPjGafuxH7R/xld73C0d3ryQtVUtwh3ZowkuV0fwF/qCJ3kAMAAA== 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, 14 Feb 2018 13:08:39 -0000 --_002_HE1PR0702MB3625310E4FC43F4BCA7717EEC2F50HE1PR0702MB3625_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KSSBhdHRhY2ggdGhlIG1pbnV0ZXMgZnJvbSB0aGUgc2lkZSBtZWV0aW5nIGluIFNpbmdh cG9yZSwgSSBiZWxpZXZlIHRoYXQgdGhleSB3ZXJlIG9ubHkgcG9zdGVkIG9uIHRoZSBlY24tcXVp YyBtYWlsaW5nIGxpc3Qg4pi5IC4NCg0KSSBhZ3JlZSB0aGF0IHRoZSBzZW5kZXIvcmVjZWl2ZWQg aXNzdWVzIGFyZSBwcm9iYWJseSBrbm93biBhLXByaW9yeSBhbmQgaWYgYSBzZW5kZXIgZG9lcyBr bm93IHRoYXQgaXRzIE9TIHN0YWNrIGRvZXMgbm90IGhhdmUgdGhlIG5lY2Vzc2FyeSBBUEkgc3Vw cG9ydCBmb3IgRUNOIHRoZW4gaXQgZG9lcyBub3QgbWFrZSBtdWNoIHNlbnNlIHRvIHRyeSBpdC4N Cg0KL0luZ2VtYXINCiAgDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog TWlyamEgS8O8aGxld2luZCBbbWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2hd DQo+IFNlbnQ6IGRlbiAxMyBmZWJydWFyaSAyMDE4IDEzOjI5DQo+IFRvOiBJbmdlbWFyIEpvaGFu c3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gQ2M6IERlIFNjaGVw cGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApIDxrb2VuLmRlX3NjaGVwcGVyQG5va2lhLQ0K PiBiZWxsLWxhYnMuY29tPjsgZWtpbm5lYXJAYXBwbGUuY29tOyBMdWJhc2hldiwgSWdvcg0KPiA8 aWx1YmFzaGVAYWthbWFpLmNvbT47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47IFFV SUMgV0cNCj4gPHF1aWNAaWV0Zi5vcmc+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0 ZW1hLm5ldD4NCj4gU3ViamVjdDogUmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9u DQo+IA0KPiBIaSBJbmdlbWFyLA0KPiANCj4gc2VlIGJlbG93Lg0KPiANCj4gPiBBbSAxMi4wMi4y MDE4IHVtIDIyOjExIHNjaHJpZWIgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA8aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb20+Og0KPiA+DQo+ID4gSGkNCj4gPg0KPiA+IFBsZWFzZSBzZWUg aW5saW5lDQo+ID4NCj4gPiBCUg0KPiA+IEluZ2VtYXINCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBNaXJqYSBLw7xobGV3aW5kIFttYWlsdG86bWlyamEu a3VlaGxld2luZEB0aWsuZWUuZXRoei5jaF0NCj4gPj4gU2VudDogZGVuIDEyIGZlYnJ1YXJpIDIw MTggMTY6MjYNCj4gPj4gVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNz b25AZXJpY3Nzb24uY29tPg0KPiA+PiBDYzogRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUv QW50d2VycCkgPGtvZW4uZGVfc2NoZXBwZXJAbm9raWEtDQo+ID4+IGJlbGwtbGFicy5jb20+OyBl a2lubmVhckBhcHBsZS5jb207IEx1YmFzaGV2LCBJZ29yDQo+ID4+IDxpbHViYXNoZUBha2FtYWku Y29tPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgUVVJQyBXRw0KPiA+PiA8cXVp Y0BpZXRmLm9yZz47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KPiA+ PiBTdWJqZWN0OiBSZTogRUNOIGluIFFVSUMgY29ubmVjdGlvbiBtaWdyYXRpb24NCj4gPj4NCj4g Pj4gSGkgSW5nZW1hciwNCj4gPj4NCj4gPj4gdHdvIHBvaW50cy4NCj4gPj4NCj4gPj4gSSB0aGlu ayBpdCB3b3VsZCBiZSBnb29kIHRvIGJlIGFzIGV4cGxpY2l0IGFzIHBvc3NpYmxlIGhlcmUsDQo+ ID4+IHRoZXJlZm9yZSBJIHdvdWxkIHByZWZlciBpZiBhbiBlbmRwb2ludCB0aGF0IGtub3dzIHRo YXQgaXQgY2FuIG5vdA0KPiA+PiBhY2Nlc3MgdGhlIEVDTiBJUCBiaXRzIGluZGljYXRlcyB0aGlz IGRpcmVjdGx5IGluIHRoZSBoYW5kc2hha2UuIEluDQo+ID4+IHRoaXMgY2FzZSBubyBmdXJ0aGVy IHRlc3RpbmcgaXMgbmVlZGVkLg0KPiA+IDxJSj4gWWVzLCB0aGlzIHdhcyB0aGUgb3JpZ2luYWwg aWRlYSwgd2UgZGlzY3Vzc2VkIHRoaXMgYXQgdGhlIEVDTg0KPiA+IFFVSUMgc2lkZSBtZWV0aW5n IHRob3VnaCBhbmQgYWZ0ZXJ3YXJkcyBhbmQgYXMgZmFyIGFzIEkgdW5kZXJzdGFuZCBpdCwNCj4g PiB0aGVyZSB3YXMgYSBjb25zZW5zdXMgdGhhdCBpdCB3YXMgdW5uZWNlc3NhcmlseSBjb21wbGlj YXRlZC4gU28gd2UNCj4gPiBzZWxlY3RlZCBhIG1ldGhvZCB3aGVyZSB3ZSBqdXN0IHZlcmlmeSB0 aGF0IHRoZSBFQ1QoMCksRUNUKDEpLENFDQo+ID4gY291bnRlcnMgaGF2ZSByZWFzb25hYmxlIHZh bHVlcy4gSWYgdGhhdCBpcyBub3QgdGhlIGNhc2UsIHRoZW4gaXQgaXMNCj4gPiBhbiBpbmRpY2F0 aW9uIHRoYXQgZWl0aGVyIHRoZSBwYXRoIG9yIHRoZSBlbmRwb2ludHMgZG8gbm90IHN1cHBvcnQN Cj4gPiBFQ04uIDwvSUo+DQo+IA0KPiBJIGNoZWNrZWQgdGhlIG1pbnV0ZXMgYW5kIGNvdWxkIG5v dCByZWFsbHkgZmluZCBhIGNvbmNsdXNpb24gdGhlcmUuIEkgYWdyZWUNCj4gdGhhdCB0aGVyZSBz aG91bGQgYmUgbm8gbmVnb3RpYXRpb24gaW4gdGhlIGhhbmRzaGFrZSAoYm90aCBlbmRwb2ludCBu ZWVkDQo+IHRvIGltcGxlbWVudCB0aGUgRUNOIGxvZ2ljIGFzIHBhcnQgb2YgdjEpIGJ1dCB3aGF0 IHdvdWxkIGJlIGhlbHBmdWwgaXMgdG8gbGV0DQo+IHRoZSBvdGhlciBlbmQga25vdyBpZiB5b3Ug YWxyZWFkeSBrbm93IHRoYXQgeW91IG5ldmVyIHdpbGwgYmUgYWJsZSB0bw0KPiBwcm92aWRlIGZl ZWRiYWNrIGJlY2F1c2UgeW91IGNhbiBqdXN0IG5vdCByZWFkIHRoZSBiaXRzIGluIHRoZSBJUCBo ZWFkZXIuDQo+IFRoYXQgaXMgbm90IGNvbXBsaWNhdGVkIGF0IGFsbC4NCj4gDQo+IEkgdGhpbmsg d2hhdCB3ZSBuZWVkIHRvIHNwZWNpZnkgaW4gdjEgaXMgYSB3YXkgdG8gcHJvdmlkZSBFQ04gZmVl ZGJhY2sgKG9yDQo+IGluZGljYXRlIHRoYXQgdGhpcyBpcyBub3QgcG9zc2libGUpLiBIb3dldmVy LCB3ZSBhY3R1YWxseSB3b3VsZCBub3QgbmVlZCB0bw0KPiBzYXkgYW55dGhpbmcgYWJvdXQgaG93 IEVDTiBzaG91bGQgYmUgdXNlZC4gVGhhdOKAmXMgYSBzZW5kZXIgc2lkZSBkZWNpc2lvbi4NCj4g QXMgbG9uZyBhcyB5b3UgY2FuIGdldCBmZWVkYmFjaywgd2UgYXJlIGZsZXhpYmxlIGluIGhvdyB0 byB1c2UgYW5kIHRlc3QgRUNOIGluDQo+IHYxIG9yIGFueXRpbWUgbGF0ZXIuIE9mIGNvdXJzZSBp dCB3b3VsZCBiZSBuaWNlIHRvIHByb3ZpZGUgc29tZSBkZWZhdWx0DQo+IHJlY29tbWVuZGF0aW9u cyB3aXRoIHNvbWUgZWFzeSBmYWxsYmFjayBsb2dpYyBidXQgdGhhdCdzIHRoZSBwYXJ0IHdlIGNh bg0KPiBleHBlcmltZW50IHdpdGggYW5kIGNoYW5nZSBhbnkgdGltZSB3aXRob3V0IGFueSBuZWVk IHRvIGNoYW5nZSB0aGUNCj4gcHJvdG9jb2wgc3BlYyAoYXMgbG9uZyBhcyBFQ04gZmVlZGJhY2sg aXMgcHJvdmlkZWQsIHdoZW4gRUNOIGlzIHVzZWQgYnkgdGhlDQo+IHNlbmRlcikuDQo+IA0KPiA+ DQo+ID4+DQo+ID4+IEZ1cnRoZXIsIHRoZSBwYXRoIHRlc3RpbmcgaXRzZWxmIGlzIGluZGVwZW5k ZW50IG9mIFFVSUMgYW5kIGNhbiBiZQ0KPiA+PiB1c2VkIGZvciBhbnkgcHJvdG9jb2wuIE1vcmVv dmVyLCBpdOKAmXMgbW9yZSBjb21wbGljYXRlZCB0aGFuIGp1c3QNCj4gPj4gdGVzdGluZyBFQ1Qu IEkgZ3Vlc3MgdGhlIGdlbmVyYWwgYWR2aWNlIGhlcmUgaXMgdG8gcmVtZW1iZXIgd2hpY2gNCj4g Pj4gY29kZXBvaW50cyB3ZXJlIHNlbmQgYW5kIGNvbXBhcmUgdGhpcyB0byB0aGUgZmVlZGJhY2sg cHJvdmlkZWQuIElmDQo+ID4+IGRpc2NyZXBhbmNpZXMgYXJlIG9ic2VydmVkIHRoYXQgaW5kaWNh dGUgdGhhdCBhIG1pZGRsZWJveCBoYXMgY2hhbmdlZA0KPiA+PiB0aGVzZSBiaXRzLCBhbGwgcGFj a2V0cyBzaG91bGQgYmUgbWFya2VkIGFzIG5vLUVDVCAod2hpbGUgYWRkaXRpb25hbA0KPiA+PiB0 ZXN0aW5nIE1BWSBiZSBwZXJmb3JtZWQgYXQgYW55IGxhdGVyIHBvaW50IGluIHRpbWUpLiBIb3dl dmVyLCBob3cNCj4gPj4gZXhhY3RseSB0aGlzIHRlc3Rpbmcgc2hvdWxkIGxvb2sgbGlrZSwgc2hv dWxkIG5vdCBiZSBzcGVjaWZpZWQgaW4gdGhpcyBkb2MNCj4gKGJ1dCBtb3JlIGdlbmVyYWxseSku DQo+ID4gPElKPiBJdCBpcyBwb3NzaWJsZSB0aGF0IHRoZSBhY3R1YWwgcGF0aCB2ZXJpZmljYXRp b24gY2FuIGJlIHB1dCBhcyBhDQo+ID4gc2VwYXJhdGUgZG9jdW1lbnQsIG5vdCBzdXJlIGlmIHRo YXQgaXMgYWNjZXB0ZWQgYnkgdGhlIGdyb3VwIG9yIGl0IGlzDQo+ID4gZGVzaXJlZCB3aXRoIGEg bW9yZSBlbGFib3JhdGUgZGVzY3JpcHRpb24gZGlyZWN0bHkgaW4gdGhlIFFVSUMgZHJhZnRzLg0K PiA+IEFzIHJlZ2FyZHMgdG8gdmVyaWZpY2F0aW9uLCBJIGRvIGJlbGlldmUgdGhhdCB0aGUgcHJv cG9zZWQgY291bnRlcnMNCj4gPiBzaG91bGQgYmUgYWJsZSB0byBkZXRlY3QgYmxlYWNoaW5nLCBh Y2NpZGVudGFsIHJlbWFya2luZyBmcm9tIEVDVCgwKQ0KPiA+IHRvIEVDVCgxKSBhbmQgYWxzbyBj YXNlcyB3aGVyZSBwYWNrZXRzIGFyZSBub3QgQ0UgbWFya2VkIGF0IGFsbA0KPiA+IGRlc3BpdGUg b3RoZXIgc2lnbnMgb2YgY29uZ2VzdGlvbiA8L0lKPg0KPiANCj4gV2UgdHJpZWQgdG8gZGVzaWdu IGEgbW9yZSBlbGFib3JhdGVkIHRlc3Rpbmcgc2NoZW1lIHdoZXJlIHdlIHdvdWxkIHNlbmQNCj4g MyBFQ1QwLCB0aGUgMyBFQ1QxLCBhbmQgdGhlIDMgQ0UgKHdoaWNoIHdlIHdvdWxkIG9mIGNhdXNl IG5vdCBjb3VudCBhcyBhDQo+IGNvbmdlc3Rpb24gaW5kaWNhdGlvbiBhcyB0aGUgQ0Ugd2FzIHNl dCBieSB0aGUgc2VuZGVyKS4gSG93ZXZlciwgdGhpcyB3YXMNCj4gbW9zdGx5IHRvIGRldGVjdCBi bGFjay13aGFsaW5nIHdoaWNoIGlzIHByb2JhYmx5IGxlc3MgYSBjb25jZXJuIHRoYW4gcmUtDQo+ IG1hcmtpbmcuIEkgdGhpbmsgdG9kYXkgdGhlIG1vc3QgY29tbW9uIGNhc2UgaXQgdGhhdCB0aGUg Yml0cyB3aWxsIGJlIHNldCB0bw0KPiB6ZXJvcyB3aGljaCBpcyBvbmx5IGEgcHJvYmxlbSB3aGVu IHRoZXJlIHdhcyBzb21lIENFIG1hcmtpbmcgcHJldmlvdXNseQ0KPiBvbiB0aGUgcGF0aCB0aGF0 IHRoZW4gd291bGQgZ2V0IGxvc3QuIFRodXMgaW4gdGhpcyBjYXNlIGl0IHdvdWxkIGJlDQo+IHJl Y29tbWVuZCB0byBub3QgdXNlIEVDTi9ub3Qgc2V0IHBhY2tldHMgYXMgRUNUIGF0IHNlbmRlciBz aWRlLg0KPiANCj4gSG93ZXZlciwgYXMgSSBzYWlkIGFib3ZlLCB3ZSBwcm9iYWJseSBzaG91bGQg bWFrZSByZWNvbW1lbmRhdGlvbiBob3cgdG8NCj4gdXNlIEVDTiBieSBkZWZhdWx0IGJ1dCBuZWVk IHRvIGxlYXZlIHJvb20gZm9yIG90aGVyIHVzYWdlL3Rlc3Rpbmcgc2NoZW1lcy4NCj4gQnV0IGFm dGVyIGFsbCB0aGUgcmVjZWl2ZXIgYmVpbmcgbm90IGFibGUgdG8gcmVhZCB0aGUgYml0cyBhbmQg cmVtYXJraW5nIG9uIHRoZQ0KPiBwYXRoIGFyZSB0byBkaWZmZXJlbnQgdGhpbmdzIGFuZCBzaG91 bGQgbm90IGJlIG1peGVkIHVwLiBJZiB0aGUgc2VuZGVyIGNhbg0KPiBub3QgcmVhZCB0aGUgYml0 cyB0aGlzIGlzIGtub3cgYSBwcmlvcmkgYW5kIHRoZXJlIGlzIG5vIGFtYmlndWl0eSB0aGF0IG5l ZWRzIHRvDQo+IGJlIHRlc3RlZC4gU28gd2h5IG5vdCBzaWduYWwgaXQgZGlyZWN0bHkuIFRoZSBx dWVzdGlvbiBpZiB0aGUgc2VuZGVyIGNhbiB3cml0ZQ0KPiBFQ04gZG9lcyBub3QgbmVlZCB0byBi ZSBjb21tdW5pY2F0ZWQuIFRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgaW4gdGhlDQo+IHNlbmRlciBk ZWNpZGVkIHRvIG5vdCB1c2UgRUNOIG9yIGl0IGp1c3QgY2FuIG5vdCB1c2UgaXQ7IGluIGJvdGgg Y2FzZXMgaXQgaXMgbm90DQo+IG5lY2Vzc2FyeSB0byBzZW5kIEVDTiBmZWVkYmFjayBiYWNrLiBP bmx5IGlmIGEgbm9uLW5vbi1FQ1QgaXMgb2JzZXJ2ZWQgYXQNCj4gdGhlIHJlY2VpdmVyLCBFQ04g ZmVlZGJhY2sgbmVlZHMgdG8gYmUgcHJvdmlkZWQuIEhvd2V2ZXIsIGtub3dpbmcgdGhhdA0KPiB0 aGUgcmVjZWl2ZXIgY2Fu4oCZdCBub3QgcHJvdmlkZSBmZWVkYmFjayBpcyBpbXBvcnRhbnQgYmVj YXVzZSBpbiB0aGlzIGNhc2UgdGhlDQo+IHNlbmRlciBNVVNUIG5vdCBzZXQgdGhlIHBhY2tldHMg YXMgRUNUIGFzIGl0IHdpbGwgbm90IGJlIGFibGUgdG8gcmVhY3QgdG8gdGhhdA0KPiBzaWduYWwu IFRlc3RpbmcgdGhlIHBhdGggaW4gaW5kZXBlbmRlbnQgb2YgdGhhdC4NCj4gDQo+IE1pcmphDQo+ IA0KPiANCj4gPg0KPiA+DQo+ID4+DQo+ID4+IE1pcmphDQo+ID4+DQo+ID4+DQo+ID4+PiBBbSAw OS4wMi4yMDE4IHVtIDA4OjM0IHNjaHJpZWIgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA+PiA8aW5n ZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+Og0KPiA+Pj4NCj4gPj4+IEhpIEVyaWMsIEtv ZW4gKyBvdGhlcnMNCj4gPj4+DQo+ID4+PiBUaGFua3MgZm9yIHRoZSBjb21tZW50cyBhbmQgdGhl IHVwZGF0ZS4gQSBxdWVzdGlvbiB0byB0aGUgcmVzdCBvZg0KPiA+Pj4gdGhlDQo+ID4+IGF1ZGll bmNlLCBkb2VzIHRoZSBwcmVzZW50ZWQgdGV4dCBleHBsYWluIHN1ZmZpY2llbnRseSBlbm91Z2gg aG93IEVDTg0KPiA+PiB3b3JrcyB3aXRoIGNvbm5lY3Rpb24gbWlncmF0aW9uID8NCj4gPj4+IGh0 dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraS9FQ04taW4tUVVJQyN0cmFu c3BvcnQtDQo+ID4+IGRyYWZ0LWNvbm5lY3Rpb24tbWlncmF0aW9uDQo+ID4+Pg0KPiA+Pj4NCj4g Pj4+IC9JbmdlbWFyDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IEZyb206IERlIFNjaGVwcGVyLCBLb2Vu IChOb2tpYSAtIEJFL0FudHdlcnApDQo+ID4+IFttYWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tp YS1iZWxsLWxhYnMuY29tXQ0KPiA+Pj4gU2VudDogZGVuIDIgZmVicnVhcmkgMjAxOCAxNTo0NA0K PiA+Pj4gVG86IGVraW5uZWFyQGFwcGxlLmNvbTsgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA+PiA8 aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+DQo+ID4+PiBDYzogUVVJQyBXRyA8cXVp Y0BpZXRmLm9yZz47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47DQo+ID4+IEx1YmFz aGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgQ2hyaXN0aWFuIEh1aXRlbWENCj4gPj4g PGh1aXRlbWFAaHVpdGVtYS5uZXQ+DQo+ID4+PiBTdWJqZWN0OiBSRTogRUNOIGluIFFVSUMgY29u bmVjdGlvbiBtaWdyYXRpb24NCj4gPj4+DQo+ID4+PiBIaSBJbmdlbWFyLA0KPiA+Pj4NCj4gPj4+ IEkgYWxzbyByZWFkIGFnYWluIHRocm91Z2ggdGhlIGRvY3VtZW50LCBhbmQgaGFkIGZvbGxvd2lu ZyBjb21tZW50czoNCj4gPj4+DQo+ID4+PiBJIHJlcGxhY2VkOg0KPiA+Pj4g4oCcVGhlIEFDS19F Q04gZnJhbWUgaXMgdXNlZCB0byBjb252ZXkgQUNLcyB3aGVuIHRoZSBFQ04gY2FwYWJpbGl0eQ0K PiA+PiBleGNoYW5nZSBjb25jbHVkZXMgdGhhdCBFQ04gc2hvdWxkIGJlIHVzZWQgZm9yIHRoZSBn aXZlbiBjb25uZWN0aW9uLuKAnQ0KPiA+Pj4gT3JpZ2luYWxseSBpdCBzb3VuZHMgYXMgaWYgdGhl IGNvdW50ZXJzIGFyZSBub3QgZWNob2VkIGFueW1vcmUgaWYNCj4gPj4+IHRoZSBFQ04NCj4gPj4g Y2FwYWJpbGl0eSBjaGVjayBmYWlscy4gSSBhc3N1bWUgdGhpcyB3YXMgbm90IHRoZSBpbnRlbnRp b24sIGJ1dCBpZg0KPiA+PiBpdCBpczogRmlyc3QsIHdlIGRvbuKAmXQgaGF2ZSBhIHByb3RvY29s IG9yIGRlY2lzaW9uIHBvaW50IGRlZmluZWQgd2hlbg0KPiA+PiB0aGF0IGNvbmRpdGlvbiBpcyBt ZXQgKHNlbmRlciBzaG91bGQgbGV0IHRoZSByZWNlaXZlciBrbm93IGluIHRoZQ0KPiA+PiBuZXh0 IHBhY2tldCksIGFuZCBzZWNvbmQsIEkgd291bGQgYWx3YXlzIHNlbmQgdGhlIGVjaG8sIGFzIHdl IG1pZ2h0DQo+ID4+IOKAnHRyeSBhZ2FpbiBsYXRlciAod2l0aCBhbm90aGVyIEVDVD8p4oCdLCBv ciBtaWdodCBkZWNpZGUgdG8gdXNlIHRoZSBFQ04gYml0cw0KPiBkaWZmZXJlbnRseSBsYXRlci4N Cj4gPj4+DQo+ID4+PiBJIGFsc28gY2hhbmdlZCB0aGUgdGV4dCBhcm91bmQgdGhlIGNvbm5lY3Rp b24gbWlncmF0aW9uLCBJIHRoaW5rDQo+ID4+PiBiZWZvcmUgRXJpYw0KPiA+PiByZXZpZXdlZCBp dC4gSSBtYWRlIGl0IHN1Y2ggdGhhdCBldmVyeSBuZXcgcGF0aCBjcmVhdGVzIGEgbmV3DQo+ID4+ IGNvbm5lY3Rpb24gc3RhdGUgd2l0aCBhbiBpbml0aWFsaXplZCBjb25nZXN0aW9uIGNvbnRyb2wg c3RhdGUgYW5kIEVDTg0KPiA+PiBjb3VudGVycyAoYXQgbGVhc3QgRUNOIGNvdW50ZXJzIHJlc2V0 IHRvIDBzKS4gTm90IHN1cmUgaWYgdGhpcw0KPiA+PiBtYXRjaGVzIHdpdGggdGhlIG90aGVyIHNl Y3Rpb25zIGluIHRoZSBRVUlDIGRyYWZ0Lg0KPiA+Pj4NCj4gPj4+IEkgYWxzbyBoYWQgdGhlIHRo b3VnaHQgd2hldGhlciBpdCB3YXMgcmVhbGx5IG5lZWRlZCB0byBoYXZlIHRoZSAyDQo+ID4+PiBj YXNlcy4gSQ0KPiA+PiBhZ3JlZSB3ZSBzaG91bGQgc2ltcGxpZnksIGJ5IGp1c3Qgc3RhcnRpbmcg b3ZlciBhbmQgZG9pbmcgdGhlIGNoZWNrDQo+ID4+IHVuY29uZGl0aW9uYWxseSB3aGV0aGVyIGl0 IHdhcyBzdWNjZXNzZnVsIG9yIG5vdCBpbiBhIHByZXZpb3VzIHBhdGguDQo+ID4+Pg0KPiA+Pj4g UmVnYXJkcywNCj4gPj4+IEtvZW4uDQo+ID4+Pg0KPiA+Pj4gRnJvbTogZWtpbm5lYXJAYXBwbGUu Y29tIFttYWlsdG86ZWtpbm5lYXJAYXBwbGUuY29tXQ0KPiA+Pj4gU2VudDogRnJpZGF5LCBGZWJy dWFyeSAyLCAyMDE4IDEyOjAyIEFNDQo+ID4+PiBUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5n ZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+DQo+ID4+PiBDYzogUVVJQyBXRyA8cXVpY0Bp ZXRmLm9yZz47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47DQo+ID4+IEx1YmFzaGV2 LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsgQ2hyaXN0aWFuIEh1aXRlbWENCj4gPj4gPGh1 aXRlbWFAaHVpdGVtYS5uZXQ+OyBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJw KQ0KPiA+PiA8a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tPg0KPiA+Pj4gU3Vi amVjdDogUmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uDQo+ID4+Pg0KPiA+Pj4g SGkgSW5nZW1hciwNCj4gPj4+DQo+ID4+PiBUaGlzIGdlbmVyYWxseSBsb29rcyBnb29kIHRvIG1l IQ0KPiA+Pj4gQSBmZXcgcXVlc3Rpb25zIGFuZCBvYnNlcnZhdGlvbnM6DQo+ID4+Pg0KPiA+Pj4g VGhlcmUgYXJlIHR3byB1bmlxdWUgY2FzZXM6DQo+ID4+Pg0KPiA+Pj4gICAgICAgICAgICAgICAg 4oCiIEVDTiBjYXBhYmlsaXR5IGNoZWNrIHN1Y2Nlc3NmdWwgYXQgaW5pdGlhbCBjb25uZWN0aW9u IHNldHVwDQo+ID4+PiAgICAgICAgICAgICAgICDigKIgRUNOIGNhcGFiaWxpdHkgY2hlY2sgZmFp bGVkIGF0IGluaXRpYWwgY29ubmVjdGlvbg0KPiA+Pj4gc2V0dXANCj4gPj4+DQo+ID4+PiBBcmUg dGhlc2UgYWN0dWFsbHkgYW55IGRpZmZlcmVudCBpbiB0ZXJtcyBvZiBhY3Rpb24gdGFrZW4gYnkg YW4gZW5kcG9pbnQ/DQo+ID4+PiBJdCBzZWVtcyBsaWtlIG9uIHRoZSBuZXcgbmV0d29yayBwYXRo IHRoZSBlbmRwb2ludCB3b3VsZCBnbyB0aHJvdWdoDQo+ID4+PiB0aGUNCj4gPj4gc2FtZSBwcm9j ZXNzIG9mOiAoYSkgdmVyaWZ5IEVDTiBjYXBhYmlsaXR5IGFuZCBpZiBzdWNjZXNzZnVsIHRvDQo+ ID4+IHdoYXRldmVyIGRlZ3JlZSB0aGVuIChiKSBydW4gdGhlIHJlc3Qgb2YgdGhlIEVDTiBtYWNo aW5lcnkgYXMNCj4gYXBwcm9wcmlhdGUuDQo+ID4+Pg0KPiA+Pj4gSW4gb3RoZXIgd29yZHMsIGFz IGxvbmcgYXMgeW91IGFsbG93IHBlb3BsZSB0byBzdGFydCB1c2luZyBFQ04gdXBvbg0KPiA+PiBt aWdyYXRpb24gKGluIG90aGVyIHdvcmRzLCB0byBhbGxvdyBzdGFydGluZyBpdCBhZnRlciB0aGUg aW5pdGlhbA0KPiA+PiBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQpLCB0aGVuIHRoZSBzcGVjaWZp Y3MgZm9yIEVDTiB3aXRoIG1pZ3JhdGlvbg0KPiA+PiBpcyBlc3NlbnRpYWxseSBvbmUgc3RhdGVt ZW50LCB3aGljaCBpcyDigJxkbyB0aGUgRUNOIHByb2Nlc3Mgb24gZWFjaA0KPiA+PiBuZXcgbmV0 d29yayBwYXRoIHRoYXQgeW91IHVzZeKAnS4NCj4gPj4+DQo+ID4+PiBDb25uZWN0aW9uIG1pZ3Jh dGlvbiBoYXMgaW1wYWN0IG9uIHRoZSBudW1iZXIgb2YgcmVwb3J0ZWQgQ0UgbWFya2VkDQo+ID4+ IHBhY2tldHMuIEEgbmV3IGNvbm5lY3Rpb24gc3RhdGUgd2l0aCBuZXcgY29uZ2VzdGlvbiBjb250 cm9sIHN0YXRlIGFuZA0KPiA+PiBFQ04gY291bnRlcnMgaXMgaW5zdGFudGlhdGVkIGF0IHRoZSBz ZW5kZXIgYW5kIHJlY2VpdmVyLiBUaGUgRUNODQo+ID4+IGNvdW50ZXJzIE1VU1Qgc3RhcnQgZnJv bSB6ZXJvIGFnYWluLg0KPiA+Pj4NCj4gPj4+IFRoaXMgc2VlbXMgZmluZSB0byBtZSwgaXTigJlz IGlubGluZSB3aXRoIHRoZSByZXN0IG9mIHRoZSBjb25nZXN0aW9uDQo+ID4+IGNvbnRyb2wvbG9z cyByZWNvdmVyeSBzdGF0ZSB0aGF0IGFsc28gbmVlZHMgdG8gYmUgcmVzZXQgZm9yIHRoZSBuZXcg cGF0aC4NCj4gPj4+DQo+ID4+PiBHaXZlbiB0aGF0IGVhY2ggbWlncmF0aW9uIHJlcXVpcmVzIGF0 IGxlYXN0IG9uZSBleGNoYW5nZSBvZiBwYWNrZXRzDQo+ID4+PiBhdCB0aGUNCj4gPj4gYmVnaW5u aW5nIChhdCB0aGUgdmVyeSBsZWFzdCBmb3IgYWRkcmVzcyB2YWxpZGF0aW9uIGZyb20gdGhlIHNp ZGUgb2YNCj4gPj4gdGhlIGVuZHBvaW50IHRoYXQgZGlkbuKAmXQgbWlncmF0ZSksIGl0IHNlZW1z IGxpa2UgdGhhdOKAmXMgYW4gZXhjZWxsZW50DQo+ID4+IG1vbWVudCB0byBtYXJrIHRoZSBwYWNr ZXRzIGFuZCBwZXJmb3JtIHRoZSBFQ04gY2FwYWJpbGl0eSBkZXRlY3Rpb24uDQo+ID4+IFRob3Nl IHBhY2tldHMgYXJlIGFsc28gbGlrZWx5IHBhZGRlZCwgZXRjLiBzaW1pbGFyIHRvIGluaXRpYWwg cGFja2V0cw0KPiA+PiBzaW5jZSB0aGV54oCZcmUgb24gYSBwcmV2aW91c2x5IHVudXNlZCBuZXR3 b3JrIHBhdGguDQo+ID4+Pg0KPiA+Pj4gSSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NlZCByZXF1 aXJlbWVudCBvZiBqdXN0IHVzaW5nIHRoZSDigJxmaXJzdOKAnQ0KPiA+Pj4gcGFja2V0cw0KPiA+ PiBhbmQgbWFya2luZyB0aG9zZSBpcyBzdWZmaWNpZW50IChhbmQgZ29vZCB0byBhdm9pZCBhbnkg cmVxdWlyZW1lbnQgYXMNCj4gPj4gdG8gd2hpY2ggZnJhbWVzIGFyZSBjb250YWluZWQgaW4gdGhv c2UgcGFja2V0cyksIHNpbmNlIHdlIGFyZSBhbHdheXMNCj4gPj4gZXhjaGFuZ2luZyBwYWNrZXRz IGluIGJvdGggZGlyZWN0aW9ucyBpbW1lZGlhdGVseSBhZnRlciBtaWdyYXRpb24uDQo+ID4+Pg0K PiA+Pj4gVGhpcyBoYXMgdGhlIGFkZGVkIGJlbmVmaXQgc3VjaCB0aGF0IGFueSBlbmRwb2ludCDi gJxwcm9iaW5n4oCdIHBvc3NpYmxlDQo+ID4+IG5ldHdvcmsgcGF0aHMgY291bGQgaW5jbHVkZSB0 aGUgYml0cyBuZWNlc3NhcnkgdG8gZGV0ZWN0IEVDTg0KPiA+PiBjYXBhYmlsaXR5IG9uIHRoZSBw YXRoIGJlaW5nIHByb2JlZCwgc28gaXQgY291bGQgZXZlbiBrbm93IGJlZm9yZQ0KPiA+PiBtaWdy YXRpbmcgd2hldGhlciBvciBub3QgaXQgd291bGQgYmUgYWJsZSB0byB1c2UgRUNOIG9uIHRoYXQg bmV3IHBhdGguDQo+ID4+Pg0KPiA+Pj4gVGhhbmtzLA0KPiA+Pj4gRXJpYw0KPiA+Pj4NCj4gPj4+ DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IE9uIEZlYiAxLCAyMDE4LCBhdCAzOjA3IEFNLCBJbmdlbWFy IEpvaGFuc3NvbiBTDQo+ID4+IDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4gd3Jv dGU6DQo+ID4+Pg0KPiA+Pj4gSGkNCj4gPj4+IEkgaGF2ZSB3cml0dGVuIHVwIGRpZmZlcmVudCBh c3BlY3RzIG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uIGFuZCBob3cNCj4gPj4+IGl0DQo+ID4+IHBs YXlzIHdpdGggRUNOLg0KPiA+Pj4gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0 cy93aWtpL0VDTi1pbi1RVUlDI3RyYW5zcG9ydC0NCj4gPj4gZHJhZnQtY29ubmVjdGlvbi1taWdy YXRpb24NCj4gPj4+DQo+ID4+PiBBIGNhdmVhdC4uIEkgYW0gYSBiaXQgdW5zdXJlIGFib3V0IHRo ZSBkZWZpbml0aW9uIG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uDQo+IC4NCj4gPj4gTXkgaW50ZXJw cmV0YXRpb24gaXMgdGhhdCBhIGNsaWVudCBtb3ZlcyB0byBhIG5ldyBJUCBhZGRyZXNzIGR1ZSB0 bw0KPiA+PiBlLmcuIGEgTkFUIHJlYmluZCBvciBzd2l0Y2ggZnJvbSBXaUZpIHRvIGNlbGx1bGFy LCByaWdodCA/LiBJcyBhIG5ldw0KPiA+PiBjb25uZWN0aW9uIGluc3RhbnRpYXRlZCBhdCBhIGNv bm5lY3Rpb24gbWlncmF0aW9uID8NCj4gPj4+DQo+ID4+PiAvSW5nZW1hcg0KPiA+Pj4NCj4gPj4+ ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPj4+IEluZ2VtYXIgSm9oYW5z c29uICBNLlNjLg0KPiA+Pj4gTWFzdGVyIFJlc2VhcmNoZXINCj4gPj4+DQo+ID4+PiBFcmljc3Nv biBSZXNlYXJjaA0KPiA+Pj4gTmV0d29yayBQcm90b2NvbHMgJiBFMkUgUGVyZm9ybWFuY2UNCj4g Pj4+IExhYnJhdG9yaWVncsOkbmQgMTENCj4gPj4+IDk3MSAyOCwgTHVsZcOlLCBTd2VkZW4NCj4g Pj4+IFBob25lICs0Ni0xMDcxIDQzMDQyDQo+ID4+PiBTTVMvTU1TICs0Ni03MyAwNzggMzI4OQ0K PiA+Pj4gaW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20NCj4gPj4+IHd3dy5lcmljc3Nv bi5jb20NCj4gPj4+DQo+ID4+PiAgICAgICAgICAgICAgICAgWW91IGNhbid0IHN0YXJ0IGEgZmly ZSAgV29ycnlpbmcgJ2JvdXQgeW91ciBsaXR0bGUNCj4gPj4+IHdvcmxkIGZhbGxpbmcgYXBhcnQN Cj4gPj4+ICAgICAgICAgICAgICAgQnJ1Y2UgU3ByaW5nc3RlZW4NCj4gPj4+ID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPg0KDQo= --_002_HE1PR0702MB3625310E4FC43F4BCA7717EEC2F50HE1PR0702MB3625_ Content-Type: text/plain; name="ECN-QUIC-side-meeting-20171116.txt" Content-Description: ECN-QUIC-side-meeting-20171116.txt Content-Disposition: attachment; filename="ECN-QUIC-side-meeting-20171116.txt"; size=3032; creation-date="Wed, 14 Feb 2018 12:52:30 GMT"; modification-date="Mon, 04 Dec 2017 08:02:45 GMT" Content-Transfer-Encoding: base64 RUNOLVFVSUMgc2lkZSBtZWV0aW5nIE5vdiAxNiAyMDE3DQpUaW1lIDogMTYuMDAtMTcuMDAgDQpM b2NhdGlvbiA6IEh1bGxldCBSb29tLCBJRVRGLTEwMCBTaW5nYXBvcmUNCk1lZXRpbmcgY2hhaXI6 IEluZ2VtYXIgSm9oYW5zc29uIA0KQXR0ZW5kZWVzIDogTGFycyBFZ2dlcnQsIEdvcnJ5IEZhaXJo dXJzdCwgQm9iIEJyaXNjb2UsIFN0dWFydCBDaGVzaGlyZSwgTWFnbnVzIFdlc3Rlcmx1bmQsIFNw ZW5jZXIgRGF3a2lucywgS29lbiBEZSBTY2hlcHBlciwgUm9uaSBFdmVuLCBNaXJqYSBL/GhsZXdp bmQgKGJyaWVmbHkpLCBEYXZpZCBTY2hpbmF6aSwgUHJhdmVlbiBCYWxhc3VicmFtYW5pYW4sIExl aWYgSGVkc3Ryb2VtLCBJZ29yIEx1YmFzaGV2LCBIdWF3ZWktdW5rbm93bg0KDQpNZWV0aW5nIG5v dGVzDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KVGhlIG5vdGUgd2VsbCB3YXMgcHJlc2VudGVkIHRvIGFsbCB0aGUgYXR0ZW5kZWVz Lg0KDQpTdW1tYXJ5Og0KIEEgZGVzaWduIHRlYW0gd2lsbCBiZSBmb3JtZWQgd2l0aCBhIGxpbWl0 ZWQgbnVtYmVyIG9mIHBlcnNvbnMgd2l0aCB0aGUgZm9sbG93aW5nIG9iamVjdGl2ZS4NCiArIFVw ZGF0ZSB0aGUgRUNOLVFVSUMgd2lraSBmb3IgUVVJQyB2MSB3aXRoIA0KICArIHNpbXBsaWZpZWQg RUNOIGNhcGFiaWxpdHkgZXhoYW5nZS4gVGhlIGNvYXJzZSBvdXRsaW5lIGlzIHRoYXQgZWFjaCBl bmRwb2ludCBzZXRzIA0KICAgIEVDVCgwKSBvciBFQ1QoMSkgaW4gdGhlIGZpcnN0IHBhY2tldCwg dGhlIHJlY2VpdmluZyBlbnBvaW50IHRoZW4gZWNob2VzIGJhY2sgdGhpcyANCiAgICBpbmZvcm1h dGlvbiBpbiBhIG5ldyBBQ0sgZnJhbWUgd2l0aCBFQ04gZmllbGQuIEJvdGggZW5kcG9pbnRzIGZv bGxvdyB0aGlzIHByb2NlZHVyZS4NCiAgKyBTdWJzZXF1ZW50IGRhdGEgYWZ0ZXIgRUNOIGNhcGFi aWxpdHkgZXhjaGFuZ2UgaXMgdHJhbnNtaXR0ZWQgd2l0aCBOb3QtRUNULiANCiAgICBUaGlzIG1l YW5zIHRoYXQgb25seSB0aGUgY2FwYWJpbGl0eSBleGNoYW5nZSBkb2VzIEVDTi4gDQogICAgRnVs bCBFQ04gaW1wbGVtZW5hdGlvbiBpcyBsZWZ0IGZvciBhIGZ1dHVpcmUgUVVJQyB2MS4xIG9yIHdo YXRldmVyLg0KICArIEFDSyBmcmFtZSB3aXRoIEVDTiBmaWVsZC4NCiAgKyBFQ04gd2lyZWxpbmUg c3BlYyAoaS5lIEFDSyBmcmFtZSB3aXRoIEVDTikgYW5kIGNhcGFiaWxpdHkgZXhjaGFuZ2UgaXMg bWFuZGF0b3J5IHRvIA0KICAgIGltcGxlbWVudCBpbiBRVUlDIHYxLjANCiAgKyBDb25uZWN0aW9u IG1pZ3JhdGlvbnMgYXNwZWN0cyBhcmUgZGVmaW5lZCwgdGhpcyBtZWFucyB0aGF0IEVDTiBjYXBh YmlsaXR5IA0KICAgIGV4Y2hhbmdlIHNob3VsZCBiZSBjYXJyaWVkIG91dCBhbHNvIGluIHRoZSBw aW5nL3BvbmcgYW5kIHJlc3BvbnNlIHRvIHBvbmcuDQogICsgUGVvcGxlIGluIGRlc2lnbiB0ZWFt IDogSW5nZW1hciBKb2hhbnNzb24gKyBXSE8gID8NCg0KICsgV2hlbiB3aWtpIHVwZGF0ZXMgYXJl IGZpbmFsaXplZC4gTW92ZSB0byBhIGRyYWZ0IGFuZCBoYXZlIGEgZmlyc3QgcmV2aWV3IChzdWdn ZXN0ZWQgbWlkIGRlY2VtYmVyKS4gDQoNCiArIEZpcnN0IGRyYWZ0IHN1Ym1pdHRlZCBpbiB0aW1l IGZvciBRVUlDIGludGVycmltIGluIE1lbGJvdXJuZSwgSmFuIDIzLTI1IDIwMTguIA0KICAgQXBw bGUgcGVyc29uIChzb3JyeSBtaXNzZWQgdGhlIG5hbWUpIG1heSBnbyB0byBNZWxib3VybmUgYW5k IGNhbiBjb25zaWRlciB0byBwcmVzZW50IGl0LiANCiAgIFN0dWFydCBvZmZlcmVkIHRvIGNoZWNr IHRoZSBwb3NzaWJpbGl0aWVzLg0KDQogKyBJZiBkZWxpdmVyeSBub3QgcG9zc2libGUgZm9yIE1l bGJvdXJuZSBtZWV0aW5nIHRoZW4gaXQgbXVzdCBiZSBwcmVzZW50ZWQgYXQgSUVURi0xMDEgaW4g TG9uZG9uLg0KDQogKyBGaXJzdCBkcmFmdCBzaG91bGQgYmUgc2ltcGxlLiBFYWNoIGFkZGVkIHBh Z2UgcmVkdWNlcyBhY2NlcHRhbmNlIHdpdGggMSUgKExhcnMgRWdnZXJ0KQ0KDQpPdGhlciBzdHVm ZjoNCiArIEVDTiBibGFjayBob2xlcyBhcmUgY29uc2lkZXJlZCB2ZXJ5IHJhcmUgdGhlc2UgZGF5 cywgbm8gYWRkaXRpb25hbCB3b3JrIA0KICAgc2hvdWxkIGJlIGRvbmUgdG8gaGFuZGxlIHRoaXMu IA0KICAgR29ycnkgbWVudGlvbmVkIHNvbWUgaGFwcHkgZXllYmFsbHMsIGl0IG5lZWRzIHRvIGJl IGJldHRlciBleHBsYWluZWQgd2hhdCB0aGlzIGltcGxpZXM/LiANCg0KICsgRUNOIGJsZWFjaGlu ZyBpcyBhIHJlYWwgcHJvYmxlbSB0aGF0IHdpbGwgaG9wZWZ1bGx5IGdvIGF3YXkgb3ZlciB0aW1l IGJ1dCB0aGlzIG11c3QgYmUgDQogICBoYW5kbGVkIGluIHRoZSBFQ04gY2FwYWJpbGl0eSBleGNo YW5nZS4NCg0KICsgVGhlIGVhcmxpZXIgcHJvcG9zZWQgRUNOIGNhcGFiaWxpdHkgZXhjaGFuZ2Ug aXMgcmVnYXJkZWQgYXMgb3Zlcmx5IGNvbXBsaWNhdGVkLCB0aGUgdXBkYXRlZCANCiAgIHZlcnNp b24gd2lsbCBiZSBtdWNoIG1vcmUgc2ltcGxlLg0KDQogKyBUaGUgRUNOIGZpZWxkIGluIHRoZSBB Q0sgZnJhbWUgaXMgbGlrZWx5IHRvbyBsYXJnZSB0byBiZSBhY2NlcHRlZCwgd29yayBpcyBuZWVk ZWQgdG8gDQogICBtYWtlIHRoaXMgbW9yZSBjb21wYWN0LiBJdCBpcyBoZXJlIGhlbHBmdWwgdGhh dCBBQ0tzIGFyZSBBQ0tlZCB0b28gYW5kIHRoYXQgZGVsdGFzIGNhbiANCiAgIGJlIGVuY29kZWQg c2FmZWx5LiAgDQoNCiArIEVDTiBhZnRlciBjYXBhYmlsaXR5IG5lZ290aWF0aW9uIGlzIGVuYWJs ZWQgYWZ0ZXIgdjEuMCwgdGhpcyB3aWxsIGFsc28gaW5jbHVkZSBhIA0KICAgc3BlY2lmaWNhdGlv biBvZiBhIEVDTiBjb25nZXN0aW9uIHJlc3BvbnNlLg0KDQogKyBUaW1lc3RhbXBzIChhY2NvcmRp bmcgdG8gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL1RpbWUtc3Rh bXBzLWluLVFVSUMgKSANCiAgIGFyZSBub3QgaW5jbHVkZWQgDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQo= --_002_HE1PR0702MB3625310E4FC43F4BCA7717EEC2F50HE1PR0702MB3625_-- From nobody Wed Feb 14 06:49:46 2018 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 22500127AD4 for ; Wed, 14 Feb 2018 06:49:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 sGaT9iL9XZrf for ; Wed, 14 Feb 2018 06:49:42 -0800 (PST) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458F9126BFD for ; Wed, 14 Feb 2018 06:49:42 -0800 (PST) Received: from BGB01XI1007.national.core.bbc.co.uk (bgb01xi1007.national.core.bbc.co.uk [10.161.14.21]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w1EEneMq029874 for ; Wed, 14 Feb 2018 14:49:40 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1007.national.core.bbc.co.uk ([10.161.14.21]) with mapi id 14.03.0361.001; Wed, 14 Feb 2018 14:49:40 +0000 From: Lucas Pardue To: QUIC WG Subject: Multipath Milestones Thread-Topic: Multipath Milestones Thread-Index: AdOlot2vk/mcXyftQ+aZnFxr8GlL1Q== Date: Wed, 14 Feb 2018 14:49:39 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.213] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23662.007 x-tm-as-result: No--16.584100-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEAbgb01xud1012_" 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, 14 Feb 2018 14:49:44 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEAbgb01xud1012_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, For fear of kicking a hornet's nest... This might be a bit pedantic but when the milestones were adjusted back in = December, the Multipath extension milestones were left as originally stated= (Nov '17, May '19). Is there any intention to modify these? The Nov '17 adoption has obviously = been missed and I'm wondering what I would tell someone less familiar with = the WG when they hypothetically asks me what that means. Kind regards Lucas --_000_7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEAbgb01xud1012_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

For fear of kicking a hornet’s nest…

 

This might be a bit pedantic but when the milestones= were adjusted back in December, the Multipath extension milestones were le= ft as originally stated (Nov ’17, May ’19).

 

Is there any intention to modify these? The Nov R= 17;17 adoption has obviously been missed and I’m wondering what I wou= ld tell someone less familiar with the WG when they hypothetically asks me = what that means.

 

Kind regards

Lucas

--_000_7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEAbgb01xud1012_-- From nobody Wed Feb 14 08:48:59 2018 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 672EC12D72F for ; Wed, 14 Feb 2018 08:48:57 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=nokia.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 R1GVlOkxIkD0 for ; Wed, 14 Feb 2018 08:48:53 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0137.outbound.protection.outlook.com [104.47.1.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B0812D0C3 for ; Wed, 14 Feb 2018 08:48:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OtmueFYSH7pzYyU52NmjiYhF1qvli3zIg0HVvaEr3mk=; b=erQ6JkCFcthaZ/njpnhv6Hz8c9stUkIuYfzv2ejPKlZLPu79nxNJb3znlny05nWbYv7Ev2RdVvzGnociXvA8g1SpcLwfsg7JdUq6VCnK6fJo7M8sbJlluzg+Vw747h299D/J7biWkwRQXxK2FI9cOO7SJvSFjm9tl73Kh7StGTY= Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com (10.169.137.7) by VI1PR0701MB1744.eurprd07.prod.outlook.com (10.167.196.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Wed, 14 Feb 2018 16:48:48 +0000 Received: from VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::2944:5a2:f1d1:c6f]) by VI1PR0701MB2126.eurprd07.prod.outlook.com ([fe80::2944:5a2:f1d1:c6f%15]) with mapi id 15.20.0506.013; Wed, 14 Feb 2018 16:48:48 +0000 From: "De Schepper, Koen (Nokia - BE/Antwerp)" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Ingemar Johansson S CC: "ekinnear@apple.com" , "Lubashev, Igor" , Ian Swett , QUIC WG , Christian Huitema , Ingemar Johansson S Subject: RE: ECN in QUIC connection migration Thread-Topic: ECN in QUIC connection migration Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25AAZWcAAAB/s3/ABUaWKkACnvEWAAAvBcBAAIFvbgAAzEkjAAAhG1T4= Date: Wed, 14 Feb 2018 16:48:48 +0000 Message-ID: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> <5CC94D22-1375-40A2-8084-BA4A43F6FA94@tik.ee.ethz.ch>, In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [52.164.212.219] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0701MB1744; 7:it/gj7ktTHLck+3ye/Ex7c5B91ZdMXhnzuICO8rFztDZn49ZSaxRdqVUwFY1R/e9JvD/DGN2X1pOwH9og/r9IQHblQbbNghPsqq3/zYtonQDzbjSW8JEVydqr+2+U0bjJ5uQRwfZ0+kxw3wosfqtLp+H1347+9fC5WJkqt1VOUOado8Mah0o3fOEuL6/f86oo7IVDVBFrJY0LE8mHdPhmOJNLKAJRvC/sGvMGD74hCwVsFrVO+wYpZ1G4EwWMbYR x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3aef28ed-0bb8-4c26-b6e1-08d573cad1fc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:VI1PR0701MB1744; x-ms-traffictypediagnostic: VI1PR0701MB1744: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(244540007438412)(166708455590820)(211936372134217)(100405760836317)(202460600054446)(153496737603132)(265313219721884)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3231101)(11241501184)(944501161)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:VI1PR0701MB1744; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB1744; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(376002)(346002)(396003)(366004)(51914003)(189003)(199004)(13464003)(4326008)(54896002)(6306002)(105586002)(45080400002)(53386004)(86362001)(99286004)(6246003)(4743002)(6116002)(3846002)(97736004)(478600001)(2900100001)(8666007)(9686003)(6436002)(1680700002)(316002)(236005)(54906003)(110136005)(93886005)(33656002)(26005)(8936002)(53936002)(55016002)(6346003)(14454004)(102836004)(966005)(186003)(66066001)(229853002)(5660300001)(53546011)(6506007)(2950100002)(3280700002)(59450400001)(2906002)(106356001)(8676002)(68736007)(81156014)(3660700001)(81166006)(606006)(76176011)(5250100002)(5890100001)(74316002)(7696005)(25786009)(7736002)(90052001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB1744; H:VI1PR0701MB2126.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: nokia-bell-labs.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=koen.de_schepper@nokia-bell-labs.com; x-microsoft-antispam-message-info: A+PIeOSCp1m6SP0EcJjEALRQooobAr9nnzJ3js5jaQo/tW+QkYRb7gpnz7xIT4/6YekpZUCz8GXH7szqP/vhWA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0701MB21268D5DE0F26BF9A54530F9B9F50VI1PR0701MB2126_" MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3aef28ed-0bb8-4c26-b6e1-08d573cad1fc X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 16:48:48.4818 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB1744 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, 14 Feb 2018 16:48:57 -0000 --_000_VI1PR0701MB21268D5DE0F26BF9A54530F9B9F50VI1PR0701MB2126_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlyamEsDQoNCldoeSB3b3VsZCB5b3UgbGlrZSB0byBzZWUgdGhlIGRpc3RpbmN0aW9uPw0K DQpJdCB3YXMgaW5kZWVkIGRlY2lkZWQgaW4gdGhlIHNpZGUgbWVldGluZyB0aGF0IHdlIHNob3Vs ZCBub3QgZm9yZXNlZSBleHRyYSBwcm90b2NvbCBjb21wbGV4aXR5IGZvciBzaWduYWxsaW5nIHRo YXQgdGhlIHJlY2VpdmVyIGNhbm5vdCByZWFkIHRoZSBlY24gYml0cy4NCg0KRm9yIG1lIHRoZSBy ZWFzb25zIHdlcmU6IEl0IGlzIG5vdCBhIGRlc2lyZWQgc2l0dWF0aW9uIHdoaWNoIHdpbGwgaG9w ZWZ1bGx5IGRpc2FwcGVhciBpbiB0aGUgZnV0dXJlLCBhbmQgSSBkb24ndCB0aGluayBpdCBpcyBz byB1c2VmdWwgZm9yIGEgc2VuZGVyIHRvIGtub3cuIFdlIG5vdyBhc3N1bWUgcmVhZGluZyAwMCBi aXRzIGFuZCBlY2hvIGFsbCBjb3VudGVycyB1bmluY3JlbWVudGVkIHdpdGggMCB2YWx1ZXMgaW4g dGhhdCBjYXNlLCBqdXN0IGFzIGlmIHRoZSBwYXRoIGJsZWFjaGVzIGl0LiBJZiB3ZSBtYWtlIGFu IGV4cGxpY2l0IHByb3RvY29sIGV4Y2hhbmdlIGZvciBpdCwgaXQgZmVlbHMgbGlrZSBpdCBpcyBh biBleHRyYSBmZWF0dXJlIDstKS4gQWxzbyBwZW9wbGUgbWlnaHQgc3RhcnQgbWFraW5nIHRoZWly IGNvbmdlc3Rpb24gY29udHJvbCBtb3JlIGNvbXBsZXggd2l0aCB1cCB0byAyIG1vcmUgY29uZGl0 aW9uYWwgcGFyYW1ldGVycyAoc2VuZGVyLWNhbm5vdC1zZXQtZWNuIGFuZCByZWNlaXZlci1jYW5u b3QtcmVhZC1lY24gYm9vbGVhbnMsIG5leHQgdG8gbm8tZWNuKS4gTm90IHRvIG1lbnRpb24gZXh0 cmEgaW50ZXJvcCB0ZXN0Y2FzZXMgd2l0aCBzdWNoIHNlbmRlcidzL3JlY2VpdmVyJ3MgZXh0cmEg ZnVuY3Rpb25hbGl0eS4NCg0KVG8gbWFrZSB5b3VyIGNvZGUgc2ltcGxlIGFuZCBwbGF0Zm9ybSBp bmRlcGVuZGVudCwgbm90IGJlaW5nIGFibGUgdG8gc2V0L3JlYWQgZWNobyBiaXRzIHNob3VsZCBi ZSBpbnZpc2libGUgdW50aWwgdGhlIHBvaW50IG9mIHRoZSBtaXNzaW5nIHNvY2tldCBBUEkgY2Fs bCwgd2hpY2ggd2lsbCBtb3N0IHByb2JhYmx5IGhhdmUgY29uZGl0aW9uYWwgY29tcGlsZXIgZGly ZWN0aXZlcyBwZXIgcGxhdGZvcm0gYXQgdGhhdCBwb2ludC4NCg0KU28gY29uY2x1c2lvbiB3YXM6 IEFueSBoaWdoZXIgbGF5ZXIgcHJvdG9jb2wgY29kZSBzaG91bGQgbm90IG1ha2UgYW55IGRpc3Rp bmN0aW9uIGJldHdlZW4gaG9zdCBpbmFiaWxpdHkgYW5kIHBhdGggYmxlYWNoaW5nLCBhbmQgd2Ug b25seSBoYXZlIGZ1bmN0aW9uYWxpdHkgZm9yIGdlbmVyYWwgImVuZDJlbmQgZWNuIGluYWJpbGl0 eSIuDQoNCkFncmVlZCB0aGF0IHRoZSByZWNlaXZlciBjb2RlIHNob3VsZCBiZSBpbmRlcGVuZGVu dCBmcm9tIGhvdyBlY24gaXMgdXNlZC4gVGhpcyBpcyB0aGUgY2FzZSBub3cuIEZvciB0aGUgcmVj ZWl2ZXIgd2Ugb25seSBpbmNyZW1lbnQgYW5kIGVjaG8gdGhlIGNvdW50ZXJzIGFsbCB0aGUgdGlt ZS4gVGhhdCdzIGl0LCB2ZXJ5IHNpbXBsZS4gT25seSB0aGUgc2VuZGVyIGRldGVybWluZXMgaG93 IGVjbiBjYXBhYmlsaXR5IGlzIGNoZWNrZWQgYW5kIGhvdyBlY24gaXMgdXNlZC4NCg0KTWF5YmUg YWxzbyBhIGdvb2QgcG9pbnQgdGhhdCB0aGUgY3VycmVudCBjYXBhYmlsaXR5IGNoZWNrIGlzIHRo ZSBtaW5pbWFsPz8gQW5kIG5lZWRzIHNvbWUgZXh0cmEgY2hlY2tzPw0KDQpSZWdhcmRzLA0KS29l bi4NCg0KDQpPdXRsb29rIHZvb3IgQW5kcm9pZDxodHRwczovL2FrYS5tcy9naGVpMzY+IGRvd25s b2FkZW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEluZ2VtYXIg Sm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0KU2VudDogV2Vk bmVzZGF5LCBGZWJydWFyeSAxNCwgMjAxOCAyOjA4OjMwIFBNDQpUbzogTWlyamEgS8O8aGxld2lu ZA0KQ2M6IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApOyBla2lubmVhckBh cHBsZS5jb207IEx1YmFzaGV2LCBJZ29yOyBJYW4gU3dldHQ7IFFVSUMgV0c7IENocmlzdGlhbiBI dWl0ZW1hOyBJbmdlbWFyIEpvaGFuc3NvbiBTDQpTdWJqZWN0OiBSRTogRUNOIGluIFFVSUMgY29u bmVjdGlvbiBtaWdyYXRpb24NCg0KSGkNCg0KSSBhdHRhY2ggdGhlIG1pbnV0ZXMgZnJvbSB0aGUg c2lkZSBtZWV0aW5nIGluIFNpbmdhcG9yZSwgSSBiZWxpZXZlIHRoYXQgdGhleSB3ZXJlIG9ubHkg cG9zdGVkIG9uIHRoZSBlY24tcXVpYyBtYWlsaW5nIGxpc3Qg4pi5IC4NCg0KSSBhZ3JlZSB0aGF0 IHRoZSBzZW5kZXIvcmVjZWl2ZWQgaXNzdWVzIGFyZSBwcm9iYWJseSBrbm93biBhLXByaW9yeSBh bmQgaWYgYSBzZW5kZXIgZG9lcyBrbm93IHRoYXQgaXRzIE9TIHN0YWNrIGRvZXMgbm90IGhhdmUg dGhlIG5lY2Vzc2FyeSBBUEkgc3VwcG9ydCBmb3IgRUNOIHRoZW4gaXQgZG9lcyBub3QgbWFrZSBt dWNoIHNlbnNlIHRvIHRyeSBpdC4NCg0KL0luZ2VtYXINCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IE1pcmphIEvDvGhsZXdpbmQgW21haWx0bzptaXJqYS5rdWVobGV3 aW5kQHRpay5lZS5ldGh6LmNoXQ0KPiBTZW50OiBkZW4gMTMgZmVicnVhcmkgMjAxOCAxMzoyOQ0K PiBUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5j b20+DQo+IENjOiBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJwKSA8a29lbi5k ZV9zY2hlcHBlckBub2tpYS0NCj4gYmVsbC1sYWJzLmNvbT47IGVraW5uZWFyQGFwcGxlLmNvbTsg THViYXNoZXYsIElnb3INCj4gPGlsdWJhc2hlQGFrYW1haS5jb20+OyBJYW4gU3dldHQgPGlhbnN3 ZXR0QGdvb2dsZS5jb20+OyBRVUlDIFdHDQo+IDxxdWljQGlldGYub3JnPjsgQ2hyaXN0aWFuIEh1 aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5uZXQ+DQo+IFN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQyBj b25uZWN0aW9uIG1pZ3JhdGlvbg0KPg0KPiBIaSBJbmdlbWFyLA0KPg0KPiBzZWUgYmVsb3cuDQo+ DQo+ID4gQW0gMTIuMDIuMjAxOCB1bSAyMjoxMSBzY2hyaWViIEluZ2VtYXIgSm9oYW5zc29uIFMN Cj4gPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPjoNCj4gPg0KPiA+IEhpDQo+ID4N Cj4gPiBQbGVhc2Ugc2VlIGlubGluZQ0KPiA+DQo+ID4gQlINCj4gPiBJbmdlbWFyDQo+ID4NCj4g Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPj4gRnJvbTogTWlyamEgS8O8aGxld2lu ZCBbbWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2hdDQo+ID4+IFNlbnQ6IGRl biAxMiBmZWJydWFyaSAyMDE4IDE2OjI2DQo+ID4+IFRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxp bmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gPj4gQ2M6IERlIFNjaGVwcGVyLCBL b2VuIChOb2tpYSAtIEJFL0FudHdlcnApIDxrb2VuLmRlX3NjaGVwcGVyQG5va2lhLQ0KPiA+PiBi ZWxsLWxhYnMuY29tPjsgZWtpbm5lYXJAYXBwbGUuY29tOyBMdWJhc2hldiwgSWdvcg0KPiA+PiA8 aWx1YmFzaGVAYWthbWFpLmNvbT47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47IFFV SUMgV0cNCj4gPj4gPHF1aWNAaWV0Zi5vcmc+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBo dWl0ZW1hLm5ldD4NCj4gPj4gU3ViamVjdDogUmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWln cmF0aW9uDQo+ID4+DQo+ID4+IEhpIEluZ2VtYXIsDQo+ID4+DQo+ID4+IHR3byBwb2ludHMuDQo+ ID4+DQo+ID4+IEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBiZSBhcyBleHBsaWNpdCBhcyBw b3NzaWJsZSBoZXJlLA0KPiA+PiB0aGVyZWZvcmUgSSB3b3VsZCBwcmVmZXIgaWYgYW4gZW5kcG9p bnQgdGhhdCBrbm93cyB0aGF0IGl0IGNhbiBub3QNCj4gPj4gYWNjZXNzIHRoZSBFQ04gSVAgYml0 cyBpbmRpY2F0ZXMgdGhpcyBkaXJlY3RseSBpbiB0aGUgaGFuZHNoYWtlLiBJbg0KPiA+PiB0aGlz IGNhc2Ugbm8gZnVydGhlciB0ZXN0aW5nIGlzIG5lZWRlZC4NCj4gPiA8SUo+IFllcywgdGhpcyB3 YXMgdGhlIG9yaWdpbmFsIGlkZWEsIHdlIGRpc2N1c3NlZCB0aGlzIGF0IHRoZSBFQ04NCj4gPiBR VUlDIHNpZGUgbWVldGluZyB0aG91Z2ggYW5kIGFmdGVyd2FyZHMgYW5kIGFzIGZhciBhcyBJIHVu ZGVyc3RhbmQgaXQsDQo+ID4gdGhlcmUgd2FzIGEgY29uc2Vuc3VzIHRoYXQgaXQgd2FzIHVubmVj ZXNzYXJpbHkgY29tcGxpY2F0ZWQuIFNvIHdlDQo+ID4gc2VsZWN0ZWQgYSBtZXRob2Qgd2hlcmUg d2UganVzdCB2ZXJpZnkgdGhhdCB0aGUgRUNUKDApLEVDVCgxKSxDRQ0KPiA+IGNvdW50ZXJzIGhh dmUgcmVhc29uYWJsZSB2YWx1ZXMuIElmIHRoYXQgaXMgbm90IHRoZSBjYXNlLCB0aGVuIGl0IGlz DQo+ID4gYW4gaW5kaWNhdGlvbiB0aGF0IGVpdGhlciB0aGUgcGF0aCBvciB0aGUgZW5kcG9pbnRz IGRvIG5vdCBzdXBwb3J0DQo+ID4gRUNOLiA8L0lKPg0KPg0KPiBJIGNoZWNrZWQgdGhlIG1pbnV0 ZXMgYW5kIGNvdWxkIG5vdCByZWFsbHkgZmluZCBhIGNvbmNsdXNpb24gdGhlcmUuIEkgYWdyZWUN Cj4gdGhhdCB0aGVyZSBzaG91bGQgYmUgbm8gbmVnb3RpYXRpb24gaW4gdGhlIGhhbmRzaGFrZSAo Ym90aCBlbmRwb2ludCBuZWVkDQo+IHRvIGltcGxlbWVudCB0aGUgRUNOIGxvZ2ljIGFzIHBhcnQg b2YgdjEpIGJ1dCB3aGF0IHdvdWxkIGJlIGhlbHBmdWwgaXMgdG8gbGV0DQo+IHRoZSBvdGhlciBl bmQga25vdyBpZiB5b3UgYWxyZWFkeSBrbm93IHRoYXQgeW91IG5ldmVyIHdpbGwgYmUgYWJsZSB0 bw0KPiBwcm92aWRlIGZlZWRiYWNrIGJlY2F1c2UgeW91IGNhbiBqdXN0IG5vdCByZWFkIHRoZSBi aXRzIGluIHRoZSBJUCBoZWFkZXIuDQo+IFRoYXQgaXMgbm90IGNvbXBsaWNhdGVkIGF0IGFsbC4N Cj4NCj4gSSB0aGluayB3aGF0IHdlIG5lZWQgdG8gc3BlY2lmeSBpbiB2MSBpcyBhIHdheSB0byBw cm92aWRlIEVDTiBmZWVkYmFjayAob3INCj4gaW5kaWNhdGUgdGhhdCB0aGlzIGlzIG5vdCBwb3Nz aWJsZSkuIEhvd2V2ZXIsIHdlIGFjdHVhbGx5IHdvdWxkIG5vdCBuZWVkIHRvDQo+IHNheSBhbnl0 aGluZyBhYm91dCBob3cgRUNOIHNob3VsZCBiZSB1c2VkLiBUaGF04oCZcyBhIHNlbmRlciBzaWRl IGRlY2lzaW9uLg0KPiBBcyBsb25nIGFzIHlvdSBjYW4gZ2V0IGZlZWRiYWNrLCB3ZSBhcmUgZmxl eGlibGUgaW4gaG93IHRvIHVzZSBhbmQgdGVzdCBFQ04gaW4NCj4gdjEgb3IgYW55dGltZSBsYXRl ci4gT2YgY291cnNlIGl0IHdvdWxkIGJlIG5pY2UgdG8gcHJvdmlkZSBzb21lIGRlZmF1bHQNCj4g cmVjb21tZW5kYXRpb25zIHdpdGggc29tZSBlYXN5IGZhbGxiYWNrIGxvZ2ljIGJ1dCB0aGF0J3Mg dGhlIHBhcnQgd2UgY2FuDQo+IGV4cGVyaW1lbnQgd2l0aCBhbmQgY2hhbmdlIGFueSB0aW1lIHdp dGhvdXQgYW55IG5lZWQgdG8gY2hhbmdlIHRoZQ0KPiBwcm90b2NvbCBzcGVjIChhcyBsb25nIGFz IEVDTiBmZWVkYmFjayBpcyBwcm92aWRlZCwgd2hlbiBFQ04gaXMgdXNlZCBieSB0aGUNCj4gc2Vu ZGVyKS4NCj4NCj4gPg0KPiA+Pg0KPiA+PiBGdXJ0aGVyLCB0aGUgcGF0aCB0ZXN0aW5nIGl0c2Vs ZiBpcyBpbmRlcGVuZGVudCBvZiBRVUlDIGFuZCBjYW4gYmUNCj4gPj4gdXNlZCBmb3IgYW55IHBy b3RvY29sLiBNb3Jlb3ZlciwgaXTigJlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBqdXN0DQo+ID4+ IHRlc3RpbmcgRUNULiBJIGd1ZXNzIHRoZSBnZW5lcmFsIGFkdmljZSBoZXJlIGlzIHRvIHJlbWVt YmVyIHdoaWNoDQo+ID4+IGNvZGVwb2ludHMgd2VyZSBzZW5kIGFuZCBjb21wYXJlIHRoaXMgdG8g dGhlIGZlZWRiYWNrIHByb3ZpZGVkLiBJZg0KPiA+PiBkaXNjcmVwYW5jaWVzIGFyZSBvYnNlcnZl ZCB0aGF0IGluZGljYXRlIHRoYXQgYSBtaWRkbGVib3ggaGFzIGNoYW5nZWQNCj4gPj4gdGhlc2Ug Yml0cywgYWxsIHBhY2tldHMgc2hvdWxkIGJlIG1hcmtlZCBhcyBuby1FQ1QgKHdoaWxlIGFkZGl0 aW9uYWwNCj4gPj4gdGVzdGluZyBNQVkgYmUgcGVyZm9ybWVkIGF0IGFueSBsYXRlciBwb2ludCBp biB0aW1lKS4gSG93ZXZlciwgaG93DQo+ID4+IGV4YWN0bHkgdGhpcyB0ZXN0aW5nIHNob3VsZCBs b29rIGxpa2UsIHNob3VsZCBub3QgYmUgc3BlY2lmaWVkIGluIHRoaXMgZG9jDQo+IChidXQgbW9y ZSBnZW5lcmFsbHkpLg0KPiA+IDxJSj4gSXQgaXMgcG9zc2libGUgdGhhdCB0aGUgYWN0dWFsIHBh dGggdmVyaWZpY2F0aW9uIGNhbiBiZSBwdXQgYXMgYQ0KPiA+IHNlcGFyYXRlIGRvY3VtZW50LCBu b3Qgc3VyZSBpZiB0aGF0IGlzIGFjY2VwdGVkIGJ5IHRoZSBncm91cCBvciBpdCBpcw0KPiA+IGRl c2lyZWQgd2l0aCBhIG1vcmUgZWxhYm9yYXRlIGRlc2NyaXB0aW9uIGRpcmVjdGx5IGluIHRoZSBR VUlDIGRyYWZ0cy4NCj4gPiBBcyByZWdhcmRzIHRvIHZlcmlmaWNhdGlvbiwgSSBkbyBiZWxpZXZl IHRoYXQgdGhlIHByb3Bvc2VkIGNvdW50ZXJzDQo+ID4gc2hvdWxkIGJlIGFibGUgdG8gZGV0ZWN0 IGJsZWFjaGluZywgYWNjaWRlbnRhbCByZW1hcmtpbmcgZnJvbSBFQ1QoMCkNCj4gPiB0byBFQ1Qo MSkgYW5kIGFsc28gY2FzZXMgd2hlcmUgcGFja2V0cyBhcmUgbm90IENFIG1hcmtlZCBhdCBhbGwN Cj4gPiBkZXNwaXRlIG90aGVyIHNpZ25zIG9mIGNvbmdlc3Rpb24gPC9JSj4NCj4NCj4gV2UgdHJp ZWQgdG8gZGVzaWduIGEgbW9yZSBlbGFib3JhdGVkIHRlc3Rpbmcgc2NoZW1lIHdoZXJlIHdlIHdv dWxkIHNlbmQNCj4gMyBFQ1QwLCB0aGUgMyBFQ1QxLCBhbmQgdGhlIDMgQ0UgKHdoaWNoIHdlIHdv dWxkIG9mIGNhdXNlIG5vdCBjb3VudCBhcyBhDQo+IGNvbmdlc3Rpb24gaW5kaWNhdGlvbiBhcyB0 aGUgQ0Ugd2FzIHNldCBieSB0aGUgc2VuZGVyKS4gSG93ZXZlciwgdGhpcyB3YXMNCj4gbW9zdGx5 IHRvIGRldGVjdCBibGFjay13aGFsaW5nIHdoaWNoIGlzIHByb2JhYmx5IGxlc3MgYSBjb25jZXJu IHRoYW4gcmUtDQo+IG1hcmtpbmcuIEkgdGhpbmsgdG9kYXkgdGhlIG1vc3QgY29tbW9uIGNhc2Ug aXQgdGhhdCB0aGUgYml0cyB3aWxsIGJlIHNldCB0bw0KPiB6ZXJvcyB3aGljaCBpcyBvbmx5IGEg cHJvYmxlbSB3aGVuIHRoZXJlIHdhcyBzb21lIENFIG1hcmtpbmcgcHJldmlvdXNseQ0KPiBvbiB0 aGUgcGF0aCB0aGF0IHRoZW4gd291bGQgZ2V0IGxvc3QuIFRodXMgaW4gdGhpcyBjYXNlIGl0IHdv dWxkIGJlDQo+IHJlY29tbWVuZCB0byBub3QgdXNlIEVDTi9ub3Qgc2V0IHBhY2tldHMgYXMgRUNU IGF0IHNlbmRlciBzaWRlLg0KPg0KPiBIb3dldmVyLCBhcyBJIHNhaWQgYWJvdmUsIHdlIHByb2Jh Ymx5IHNob3VsZCBtYWtlIHJlY29tbWVuZGF0aW9uIGhvdyB0bw0KPiB1c2UgRUNOIGJ5IGRlZmF1 bHQgYnV0IG5lZWQgdG8gbGVhdmUgcm9vbSBmb3Igb3RoZXIgdXNhZ2UvdGVzdGluZyBzY2hlbWVz Lg0KPiBCdXQgYWZ0ZXIgYWxsIHRoZSByZWNlaXZlciBiZWluZyBub3QgYWJsZSB0byByZWFkIHRo ZSBiaXRzIGFuZCByZW1hcmtpbmcgb24gdGhlDQo+IHBhdGggYXJlIHRvIGRpZmZlcmVudCB0aGlu Z3MgYW5kIHNob3VsZCBub3QgYmUgbWl4ZWQgdXAuIElmIHRoZSBzZW5kZXIgY2FuDQo+IG5vdCBy ZWFkIHRoZSBiaXRzIHRoaXMgaXMga25vdyBhIHByaW9yaSBhbmQgdGhlcmUgaXMgbm8gYW1iaWd1 aXR5IHRoYXQgbmVlZHMgdG8NCj4gYmUgdGVzdGVkLiBTbyB3aHkgbm90IHNpZ25hbCBpdCBkaXJl Y3RseS4gVGhlIHF1ZXN0aW9uIGlmIHRoZSBzZW5kZXIgY2FuIHdyaXRlDQo+IEVDTiBkb2VzIG5v dCBuZWVkIHRvIGJlIGNvbW11bmljYXRlZC4gVGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBpbiB0aGUN Cj4gc2VuZGVyIGRlY2lkZWQgdG8gbm90IHVzZSBFQ04gb3IgaXQganVzdCBjYW4gbm90IHVzZSBp dDsgaW4gYm90aCBjYXNlcyBpdCBpcyBub3QNCj4gbmVjZXNzYXJ5IHRvIHNlbmQgRUNOIGZlZWRi YWNrIGJhY2suIE9ubHkgaWYgYSBub24tbm9uLUVDVCBpcyBvYnNlcnZlZCBhdA0KPiB0aGUgcmVj ZWl2ZXIsIEVDTiBmZWVkYmFjayBuZWVkcyB0byBiZSBwcm92aWRlZC4gSG93ZXZlciwga25vd2lu ZyB0aGF0DQo+IHRoZSByZWNlaXZlciBjYW7igJl0IG5vdCBwcm92aWRlIGZlZWRiYWNrIGlzIGlt cG9ydGFudCBiZWNhdXNlIGluIHRoaXMgY2FzZSB0aGUNCj4gc2VuZGVyIE1VU1Qgbm90IHNldCB0 aGUgcGFja2V0cyBhcyBFQ1QgYXMgaXQgd2lsbCBub3QgYmUgYWJsZSB0byByZWFjdCB0byB0aGF0 DQo+IHNpZ25hbC4gVGVzdGluZyB0aGUgcGF0aCBpbiBpbmRlcGVuZGVudCBvZiB0aGF0Lg0KPg0K PiBNaXJqYQ0KPg0KPg0KPiA+DQo+ID4NCj4gPj4NCj4gPj4gTWlyamENCj4gPj4NCj4gPj4NCj4g Pj4+IEFtIDA5LjAyLjIwMTggdW0gMDg6MzQgc2NocmllYiBJbmdlbWFyIEpvaGFuc3NvbiBTDQo+ ID4+IDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT46DQo+ID4+Pg0KPiA+Pj4gSGkg RXJpYywgS29lbiArIG90aGVycw0KPiA+Pj4NCj4gPj4+IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRz IGFuZCB0aGUgdXBkYXRlLiBBIHF1ZXN0aW9uIHRvIHRoZSByZXN0IG9mDQo+ID4+PiB0aGUNCj4g Pj4gYXVkaWVuY2UsIGRvZXMgdGhlIHByZXNlbnRlZCB0ZXh0IGV4cGxhaW4gc3VmZmljaWVudGx5 IGVub3VnaCBob3cgRUNODQo+ID4+IHdvcmtzIHdpdGggY29ubmVjdGlvbiBtaWdyYXRpb24gPw0K PiA+Pj4gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1R VUlDI3RyYW5zcG9ydC0NCj4gPj4gZHJhZnQtY29ubmVjdGlvbi1taWdyYXRpb24NCj4gPj4+DQo+ ID4+Pg0KPiA+Pj4gL0luZ2VtYXINCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gRnJvbTogRGUgU2NoZXBw ZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCkNCj4gPj4gW21haWx0bzprb2VuLmRlX3NjaGVw cGVyQG5va2lhLWJlbGwtbGFicy5jb21dDQo+ID4+PiBTZW50OiBkZW4gMiBmZWJydWFyaSAyMDE4 IDE1OjQ0DQo+ID4+PiBUbzogZWtpbm5lYXJAYXBwbGUuY29tOyBJbmdlbWFyIEpvaGFuc3NvbiBT DQo+ID4+IDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gPj4+IENjOiBRVUlD IFdHIDxxdWljQGlldGYub3JnPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsNCj4g Pj4gTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+OyBDaHJpc3RpYW4gSHVpdGVt YQ0KPiA+PiA8aHVpdGVtYUBodWl0ZW1hLm5ldD4NCj4gPj4+IFN1YmplY3Q6IFJFOiBFQ04gaW4g UVVJQyBjb25uZWN0aW9uIG1pZ3JhdGlvbg0KPiA+Pj4NCj4gPj4+IEhpIEluZ2VtYXIsDQo+ID4+ Pg0KPiA+Pj4gSSBhbHNvIHJlYWQgYWdhaW4gdGhyb3VnaCB0aGUgZG9jdW1lbnQsIGFuZCBoYWQg Zm9sbG93aW5nIGNvbW1lbnRzOg0KPiA+Pj4NCj4gPj4+IEkgcmVwbGFjZWQ6DQo+ID4+PiDigJxU aGUgQUNLX0VDTiBmcmFtZSBpcyB1c2VkIHRvIGNvbnZleSBBQ0tzIHdoZW4gdGhlIEVDTiBjYXBh YmlsaXR5DQo+ID4+IGV4Y2hhbmdlIGNvbmNsdWRlcyB0aGF0IEVDTiBzaG91bGQgYmUgdXNlZCBm b3IgdGhlIGdpdmVuIGNvbm5lY3Rpb24u4oCdDQo+ID4+PiBPcmlnaW5hbGx5IGl0IHNvdW5kcyBh cyBpZiB0aGUgY291bnRlcnMgYXJlIG5vdCBlY2hvZWQgYW55bW9yZSBpZg0KPiA+Pj4gdGhlIEVD Tg0KPiA+PiBjYXBhYmlsaXR5IGNoZWNrIGZhaWxzLiBJIGFzc3VtZSB0aGlzIHdhcyBub3QgdGhl IGludGVudGlvbiwgYnV0IGlmDQo+ID4+IGl0IGlzOiBGaXJzdCwgd2UgZG9u4oCZdCBoYXZlIGEg cHJvdG9jb2wgb3IgZGVjaXNpb24gcG9pbnQgZGVmaW5lZCB3aGVuDQo+ID4+IHRoYXQgY29uZGl0 aW9uIGlzIG1ldCAoc2VuZGVyIHNob3VsZCBsZXQgdGhlIHJlY2VpdmVyIGtub3cgaW4gdGhlDQo+ ID4+IG5leHQgcGFja2V0KSwgYW5kIHNlY29uZCwgSSB3b3VsZCBhbHdheXMgc2VuZCB0aGUgZWNo bywgYXMgd2UgbWlnaHQNCj4gPj4g4oCcdHJ5IGFnYWluIGxhdGVyICh3aXRoIGFub3RoZXIgRUNU PynigJ0sIG9yIG1pZ2h0IGRlY2lkZSB0byB1c2UgdGhlIEVDTiBiaXRzDQo+IGRpZmZlcmVudGx5 IGxhdGVyLg0KPiA+Pj4NCj4gPj4+IEkgYWxzbyBjaGFuZ2VkIHRoZSB0ZXh0IGFyb3VuZCB0aGUg Y29ubmVjdGlvbiBtaWdyYXRpb24sIEkgdGhpbmsNCj4gPj4+IGJlZm9yZSBFcmljDQo+ID4+IHJl dmlld2VkIGl0LiBJIG1hZGUgaXQgc3VjaCB0aGF0IGV2ZXJ5IG5ldyBwYXRoIGNyZWF0ZXMgYSBu ZXcNCj4gPj4gY29ubmVjdGlvbiBzdGF0ZSB3aXRoIGFuIGluaXRpYWxpemVkIGNvbmdlc3Rpb24g Y29udHJvbCBzdGF0ZSBhbmQgRUNODQo+ID4+IGNvdW50ZXJzIChhdCBsZWFzdCBFQ04gY291bnRl cnMgcmVzZXQgdG8gMHMpLiBOb3Qgc3VyZSBpZiB0aGlzDQo+ID4+IG1hdGNoZXMgd2l0aCB0aGUg b3RoZXIgc2VjdGlvbnMgaW4gdGhlIFFVSUMgZHJhZnQuDQo+ID4+Pg0KPiA+Pj4gSSBhbHNvIGhh ZCB0aGUgdGhvdWdodCB3aGV0aGVyIGl0IHdhcyByZWFsbHkgbmVlZGVkIHRvIGhhdmUgdGhlIDIN Cj4gPj4+IGNhc2VzLiBJDQo+ID4+IGFncmVlIHdlIHNob3VsZCBzaW1wbGlmeSwgYnkganVzdCBz dGFydGluZyBvdmVyIGFuZCBkb2luZyB0aGUgY2hlY2sNCj4gPj4gdW5jb25kaXRpb25hbGx5IHdo ZXRoZXIgaXQgd2FzIHN1Y2Nlc3NmdWwgb3Igbm90IGluIGEgcHJldmlvdXMgcGF0aC4NCj4gPj4+ DQo+ID4+PiBSZWdhcmRzLA0KPiA+Pj4gS29lbi4NCj4gPj4+DQo+ID4+PiBGcm9tOiBla2lubmVh ckBhcHBsZS5jb20gW21haWx0bzpla2lubmVhckBhcHBsZS5jb21dDQo+ID4+PiBTZW50OiBGcmlk YXksIEZlYnJ1YXJ5IDIsIDIwMTggMTI6MDIgQU0NCj4gPj4+IFRvOiBJbmdlbWFyIEpvaGFuc3Nv biBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4gPj4+IENjOiBRVUlDIFdH IDxxdWljQGlldGYub3JnPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsNCj4gPj4g THViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+OyBDaHJpc3RpYW4gSHVpdGVtYQ0K PiA+PiA8aHVpdGVtYUBodWl0ZW1hLm5ldD47IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJF L0FudHdlcnApDQo+ID4+IDxrb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20+DQo+ ID4+PiBTdWJqZWN0OiBSZTogRUNOIGluIFFVSUMgY29ubmVjdGlvbiBtaWdyYXRpb24NCj4gPj4+ DQo+ID4+PiBIaSBJbmdlbWFyLA0KPiA+Pj4NCj4gPj4+IFRoaXMgZ2VuZXJhbGx5IGxvb2tzIGdv b2QgdG8gbWUhDQo+ID4+PiBBIGZldyBxdWVzdGlvbnMgYW5kIG9ic2VydmF0aW9uczoNCj4gPj4+ DQo+ID4+PiBUaGVyZSBhcmUgdHdvIHVuaXF1ZSBjYXNlczoNCj4gPj4+DQo+ID4+PiAgICAgICAg ICAgICAgICDigKIgRUNOIGNhcGFiaWxpdHkgY2hlY2sgc3VjY2Vzc2Z1bCBhdCBpbml0aWFsIGNv bm5lY3Rpb24gc2V0dXANCj4gPj4+ICAgICAgICAgICAgICAgIOKAoiBFQ04gY2FwYWJpbGl0eSBj aGVjayBmYWlsZWQgYXQgaW5pdGlhbCBjb25uZWN0aW9uDQo+ID4+PiBzZXR1cA0KPiA+Pj4NCj4g Pj4+IEFyZSB0aGVzZSBhY3R1YWxseSBhbnkgZGlmZmVyZW50IGluIHRlcm1zIG9mIGFjdGlvbiB0 YWtlbiBieSBhbiBlbmRwb2ludD8NCj4gPj4+IEl0IHNlZW1zIGxpa2Ugb24gdGhlIG5ldyBuZXR3 b3JrIHBhdGggdGhlIGVuZHBvaW50IHdvdWxkIGdvIHRocm91Z2gNCj4gPj4+IHRoZQ0KPiA+PiBz YW1lIHByb2Nlc3Mgb2Y6IChhKSB2ZXJpZnkgRUNOIGNhcGFiaWxpdHkgYW5kIGlmIHN1Y2Nlc3Nm dWwgdG8NCj4gPj4gd2hhdGV2ZXIgZGVncmVlIHRoZW4gKGIpIHJ1biB0aGUgcmVzdCBvZiB0aGUg RUNOIG1hY2hpbmVyeSBhcw0KPiBhcHByb3ByaWF0ZS4NCj4gPj4+DQo+ID4+PiBJbiBvdGhlciB3 b3JkcywgYXMgbG9uZyBhcyB5b3UgYWxsb3cgcGVvcGxlIHRvIHN0YXJ0IHVzaW5nIEVDTiB1cG9u DQo+ID4+IG1pZ3JhdGlvbiAoaW4gb3RoZXIgd29yZHMsIHRvIGFsbG93IHN0YXJ0aW5nIGl0IGFm dGVyIHRoZSBpbml0aWFsDQo+ID4+IGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudCksIHRoZW4gdGhl IHNwZWNpZmljcyBmb3IgRUNOIHdpdGggbWlncmF0aW9uDQo+ID4+IGlzIGVzc2VudGlhbGx5IG9u ZSBzdGF0ZW1lbnQsIHdoaWNoIGlzIOKAnGRvIHRoZSBFQ04gcHJvY2VzcyBvbiBlYWNoDQo+ID4+ IG5ldyBuZXR3b3JrIHBhdGggdGhhdCB5b3UgdXNl4oCdLg0KPiA+Pj4NCj4gPj4+IENvbm5lY3Rp b24gbWlncmF0aW9uIGhhcyBpbXBhY3Qgb24gdGhlIG51bWJlciBvZiByZXBvcnRlZCBDRSBtYXJr ZWQNCj4gPj4gcGFja2V0cy4gQSBuZXcgY29ubmVjdGlvbiBzdGF0ZSB3aXRoIG5ldyBjb25nZXN0 aW9uIGNvbnRyb2wgc3RhdGUgYW5kDQo+ID4+IEVDTiBjb3VudGVycyBpcyBpbnN0YW50aWF0ZWQg YXQgdGhlIHNlbmRlciBhbmQgcmVjZWl2ZXIuIFRoZSBFQ04NCj4gPj4gY291bnRlcnMgTVVTVCBz dGFydCBmcm9tIHplcm8gYWdhaW4uDQo+ID4+Pg0KPiA+Pj4gVGhpcyBzZWVtcyBmaW5lIHRvIG1l LCBpdOKAmXMgaW5saW5lIHdpdGggdGhlIHJlc3Qgb2YgdGhlIGNvbmdlc3Rpb24NCj4gPj4gY29u dHJvbC9sb3NzIHJlY292ZXJ5IHN0YXRlIHRoYXQgYWxzbyBuZWVkcyB0byBiZSByZXNldCBmb3Ig dGhlIG5ldyBwYXRoLg0KPiA+Pj4NCj4gPj4+IEdpdmVuIHRoYXQgZWFjaCBtaWdyYXRpb24gcmVx dWlyZXMgYXQgbGVhc3Qgb25lIGV4Y2hhbmdlIG9mIHBhY2tldHMNCj4gPj4+IGF0IHRoZQ0KPiA+ PiBiZWdpbm5pbmcgKGF0IHRoZSB2ZXJ5IGxlYXN0IGZvciBhZGRyZXNzIHZhbGlkYXRpb24gZnJv bSB0aGUgc2lkZSBvZg0KPiA+PiB0aGUgZW5kcG9pbnQgdGhhdCBkaWRu4oCZdCBtaWdyYXRlKSwg aXQgc2VlbXMgbGlrZSB0aGF04oCZcyBhbiBleGNlbGxlbnQNCj4gPj4gbW9tZW50IHRvIG1hcmsg dGhlIHBhY2tldHMgYW5kIHBlcmZvcm0gdGhlIEVDTiBjYXBhYmlsaXR5IGRldGVjdGlvbi4NCj4g Pj4gVGhvc2UgcGFja2V0cyBhcmUgYWxzbyBsaWtlbHkgcGFkZGVkLCBldGMuIHNpbWlsYXIgdG8g aW5pdGlhbCBwYWNrZXRzDQo+ID4+IHNpbmNlIHRoZXnigJlyZSBvbiBhIHByZXZpb3VzbHkgdW51 c2VkIG5ldHdvcmsgcGF0aC4NCj4gPj4+DQo+ID4+PiBJIHRoaW5rIHRoZSBjdXJyZW50IHByb3Bv c2VkIHJlcXVpcmVtZW50IG9mIGp1c3QgdXNpbmcgdGhlIOKAnGZpcnN04oCdDQo+ID4+PiBwYWNr ZXRzDQo+ID4+IGFuZCBtYXJraW5nIHRob3NlIGlzIHN1ZmZpY2llbnQgKGFuZCBnb29kIHRvIGF2 b2lkIGFueSByZXF1aXJlbWVudCBhcw0KPiA+PiB0byB3aGljaCBmcmFtZXMgYXJlIGNvbnRhaW5l ZCBpbiB0aG9zZSBwYWNrZXRzKSwgc2luY2Ugd2UgYXJlIGFsd2F5cw0KPiA+PiBleGNoYW5naW5n IHBhY2tldHMgaW4gYm90aCBkaXJlY3Rpb25zIGltbWVkaWF0ZWx5IGFmdGVyIG1pZ3JhdGlvbi4N Cj4gPj4+DQo+ID4+PiBUaGlzIGhhcyB0aGUgYWRkZWQgYmVuZWZpdCBzdWNoIHRoYXQgYW55IGVu ZHBvaW50IOKAnHByb2JpbmfigJ0gcG9zc2libGUNCj4gPj4gbmV0d29yayBwYXRocyBjb3VsZCBp bmNsdWRlIHRoZSBiaXRzIG5lY2Vzc2FyeSB0byBkZXRlY3QgRUNODQo+ID4+IGNhcGFiaWxpdHkg b24gdGhlIHBhdGggYmVpbmcgcHJvYmVkLCBzbyBpdCBjb3VsZCBldmVuIGtub3cgYmVmb3JlDQo+ ID4+IG1pZ3JhdGluZyB3aGV0aGVyIG9yIG5vdCBpdCB3b3VsZCBiZSBhYmxlIHRvIHVzZSBFQ04g b24gdGhhdCBuZXcgcGF0aC4NCj4gPj4+DQo+ID4+PiBUaGFua3MsDQo+ID4+PiBFcmljDQo+ID4+ Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gT24gRmViIDEsIDIwMTgsIGF0IDM6MDcgQU0s IEluZ2VtYXIgSm9oYW5zc29uIFMNCj4gPj4gPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24u Y29tPiB3cm90ZToNCj4gPj4+DQo+ID4+PiBIaQ0KPiA+Pj4gSSBoYXZlIHdyaXR0ZW4gdXAgZGlm ZmVyZW50IGFzcGVjdHMgb2YgY29ubmVjdGlvbiBtaWdyYXRpb24gYW5kIGhvdw0KPiA+Pj4gaXQN Cj4gPj4gcGxheXMgd2l0aCBFQ04uDQo+ID4+PiBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jh c2UtZHJhZnRzL3dpa2kvRUNOLWluLVFVSUMjdHJhbnNwb3J0LQ0KPiA+PiBkcmFmdC1jb25uZWN0 aW9uLW1pZ3JhdGlvbg0KPiA+Pj4NCj4gPj4+IEEgY2F2ZWF0Li4gSSBhbSBhIGJpdCB1bnN1cmUg YWJvdXQgdGhlIGRlZmluaXRpb24gb2YgY29ubmVjdGlvbiBtaWdyYXRpb24NCj4gLg0KPiA+PiBN eSBpbnRlcnByZXRhdGlvbiBpcyB0aGF0IGEgY2xpZW50IG1vdmVzIHRvIGEgbmV3IElQIGFkZHJl c3MgZHVlIHRvDQo+ID4+IGUuZy4gYSBOQVQgcmViaW5kIG9yIHN3aXRjaCBmcm9tIFdpRmkgdG8g Y2VsbHVsYXIsIHJpZ2h0ID8uIElzIGEgbmV3DQo+ID4+IGNvbm5lY3Rpb24gaW5zdGFudGlhdGVk IGF0IGEgY29ubmVjdGlvbiBtaWdyYXRpb24gPw0KPiA+Pj4NCj4gPj4+IC9JbmdlbWFyDQo+ID4+ Pg0KPiA+Pj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+Pj4gSW5nZW1h ciBKb2hhbnNzb24gIE0uU2MuDQo+ID4+PiBNYXN0ZXIgUmVzZWFyY2hlcg0KPiA+Pj4NCj4gPj4+ IEVyaWNzc29uIFJlc2VhcmNoDQo+ID4+PiBOZXR3b3JrIFByb3RvY29scyAmIEUyRSBQZXJmb3Jt YW5jZQ0KPiA+Pj4gTGFicmF0b3JpZWdyw6RuZCAxMQ0KPiA+Pj4gOTcxIDI4LCBMdWxlw6UsIFN3 ZWRlbg0KPiA+Pj4gUGhvbmUgKzQ2LTEwNzEgNDMwNDINCj4gPj4+IFNNUy9NTVMgKzQ2LTczIDA3 OCAzMjg5DQo+ID4+PiBpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbQ0KPiA+Pj4gd3d3 LmVyaWNzc29uLmNvbTxodHRwOi8vd3d3LmVyaWNzc29uLmNvbT4NCj4gPj4+DQo+ID4+PiAgICAg ICAgICAgICAgICAgWW91IGNhbid0IHN0YXJ0IGEgZmlyZSAgV29ycnlpbmcgJ2JvdXQgeW91ciBs aXR0bGUNCj4gPj4+IHdvcmxkIGZhbGxpbmcgYXBhcnQNCj4gPj4+ICAgICAgICAgICAgICAgQnJ1 Y2UgU3ByaW5nc3RlZW4NCj4gPj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0N Cj4gPg0KDQo= --_000_VI1PR0701MB21268D5DE0F26BF9A54530F9B9F50VI1PR0701MB2126_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHRleHQg LS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4tbGVmdDogMXB0OyBwYWRkaW5nLWxl ZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNvbGlkOyB9IC0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keT4NCjxkaXY+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImRpcmVjdGlvbjps dHI7IG1hcmdpbjowOyBwYWRkaW5nOjA7IGZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7IGZvbnQtc2l6 ZToxMXB0OyBjb2xvcjpibGFjayI+DQpIaSBNaXJqYSw8YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYg ZGlyPSJhdXRvIiBzdHlsZT0iZGlyZWN0aW9uOmx0cjsgbWFyZ2luOjA7IHBhZGRpbmc6MDsgZm9u dC1mYW1pbHk6c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGNvbG9yOmJsYWNrIj4NCldoeSB3 b3VsZCB5b3UgbGlrZSB0byBzZWUgdGhlIGRpc3RpbmN0aW9uPzxicj4NCjxicj4NCjwvZGl2Pg0K PGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJkaXJlY3Rpb246bHRyOyBtYXJnaW46MDsgcGFkZGluZzow OyBmb250LWZhbWlseTpzYW5zLXNlcmlmOyBmb250LXNpemU6MTFwdDsgY29sb3I6YmxhY2siPg0K SXQgd2FzIGluZGVlZCBkZWNpZGVkIGluIHRoZSBzaWRlIG1lZXRpbmcgdGhhdCB3ZSBzaG91bGQg bm90IGZvcmVzZWUgZXh0cmEgcHJvdG9jb2wgY29tcGxleGl0eSBmb3Igc2lnbmFsbGluZyB0aGF0 IHRoZSByZWNlaXZlciBjYW5ub3QgcmVhZCB0aGUgZWNuIGJpdHMuPGJyPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImRpcmVjdGlvbjpsdHI7IG1hcmdpbjowOyBwYWRkaW5n OjA7IGZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBjb2xvcjpibGFjayI+ DQpGb3IgbWUgdGhlIHJlYXNvbnMgd2VyZTogSXQgaXMgbm90IGEgZGVzaXJlZCBzaXR1YXRpb24g d2hpY2ggd2lsbCBob3BlZnVsbHkgZGlzYXBwZWFyIGluIHRoZSBmdXR1cmUsIGFuZCBJIGRvbid0 IHRoaW5rIGl0IGlzIHNvIHVzZWZ1bCBmb3IgYSBzZW5kZXIgdG8ga25vdy4gV2Ugbm93IGFzc3Vt ZSByZWFkaW5nIDAwIGJpdHMgYW5kIGVjaG8gYWxsIGNvdW50ZXJzIHVuaW5jcmVtZW50ZWQgd2l0 aCAwIHZhbHVlcyBpbiB0aGF0IGNhc2UsIGp1c3QgYXMNCiBpZiB0aGUgcGF0aCBibGVhY2hlcyBp dC4gSWYgd2UgbWFrZSBhbiBleHBsaWNpdCBwcm90b2NvbCBleGNoYW5nZSBmb3IgaXQsIGl0IGZl ZWxzIGxpa2UgaXQgaXMgYW4gZXh0cmEgZmVhdHVyZSA7LSkuIEFsc28gcGVvcGxlIG1pZ2h0IHN0 YXJ0IG1ha2luZyB0aGVpciBjb25nZXN0aW9uIGNvbnRyb2wgbW9yZSBjb21wbGV4IHdpdGggdXAg dG8gMiBtb3JlIGNvbmRpdGlvbmFsIHBhcmFtZXRlcnMgKHNlbmRlci1jYW5ub3Qtc2V0LWVjbiBh bmQgcmVjZWl2ZXItY2Fubm90LXJlYWQtZWNuDQogYm9vbGVhbnMsIG5leHQgdG8gbm8tZWNuKS4g Tm90IHRvIG1lbnRpb24gZXh0cmEgaW50ZXJvcCB0ZXN0Y2FzZXMgd2l0aCBzdWNoIHNlbmRlcidz L3JlY2VpdmVyJ3MgZXh0cmEgZnVuY3Rpb25hbGl0eS48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYg ZGlyPSJhdXRvIiBzdHlsZT0iZGlyZWN0aW9uOmx0cjsgbWFyZ2luOjA7IHBhZGRpbmc6MDsgZm9u dC1mYW1pbHk6c2Fucy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGNvbG9yOmJsYWNrIj4NClRvIG1h a2UgeW91ciBjb2RlIHNpbXBsZSBhbmQgcGxhdGZvcm0gaW5kZXBlbmRlbnQsIG5vdCBiZWluZyBh YmxlIHRvIHNldC9yZWFkIGVjaG8gYml0cyBzaG91bGQgYmUgaW52aXNpYmxlIHVudGlsIHRoZSBw b2ludCBvZiB0aGUgbWlzc2luZyBzb2NrZXQgQVBJIGNhbGwsIHdoaWNoIHdpbGwgbW9zdCBwcm9i YWJseSBoYXZlIGNvbmRpdGlvbmFsIGNvbXBpbGVyIGRpcmVjdGl2ZXMgcGVyIHBsYXRmb3JtIGF0 IHRoYXQgcG9pbnQuPGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImRp cmVjdGlvbjpsdHI7IG1hcmdpbjowOyBwYWRkaW5nOjA7IGZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7 IGZvbnQtc2l6ZToxMXB0OyBjb2xvcjpibGFjayI+DQpTbyBjb25jbHVzaW9uIHdhczogQW55IGhp Z2hlciBsYXllciBwcm90b2NvbCBjb2RlIHNob3VsZCBub3QgbWFrZSBhbnkgZGlzdGluY3Rpb24g YmV0d2VlbiBob3N0IGluYWJpbGl0eSBhbmQgcGF0aCBibGVhY2hpbmcsIGFuZCB3ZSBvbmx5IGhh dmUgZnVuY3Rpb25hbGl0eSBmb3IgZ2VuZXJhbCAmcXVvdDtlbmQyZW5kIGVjbiBpbmFiaWxpdHkm cXVvdDsuPGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImRpcmVjdGlv bjpsdHI7IG1hcmdpbjowOyBwYWRkaW5nOjA7IGZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7IGZvbnQt c2l6ZToxMXB0OyBjb2xvcjpibGFjayI+DQpBZ3JlZWQgdGhhdCB0aGUgcmVjZWl2ZXIgY29kZSBz aG91bGQgYmUgaW5kZXBlbmRlbnQgZnJvbSBob3cgZWNuIGlzIHVzZWQuIFRoaXMgaXMgdGhlIGNh c2Ugbm93LiBGb3IgdGhlIHJlY2VpdmVyIHdlIG9ubHkgaW5jcmVtZW50IGFuZCBlY2hvIHRoZSBj b3VudGVycyBhbGwgdGhlIHRpbWUuIFRoYXQncyBpdCwgdmVyeSBzaW1wbGUuIE9ubHkgdGhlIHNl bmRlciBkZXRlcm1pbmVzIGhvdyBlY24gY2FwYWJpbGl0eSBpcyBjaGVja2VkIGFuZCBob3cgZWNu DQogaXMgdXNlZC48YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0iZGly ZWN0aW9uOmx0cjsgbWFyZ2luOjA7IHBhZGRpbmc6MDsgZm9udC1mYW1pbHk6c2Fucy1zZXJpZjsg Zm9udC1zaXplOjExcHQ7IGNvbG9yOmJsYWNrIj4NCk1heWJlIGFsc28gYSBnb29kIHBvaW50IHRo YXQgdGhlIGN1cnJlbnQgY2FwYWJpbGl0eSBjaGVjayBpcyB0aGUgbWluaW1hbD8/IEFuZCBuZWVk cyBzb21lIGV4dHJhIGNoZWNrcz88YnI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgZGlyPSJhdXRvIiBz dHlsZT0iZGlyZWN0aW9uOmx0cjsgbWFyZ2luOjA7IHBhZGRpbmc6MDsgZm9udC1mYW1pbHk6c2Fu cy1zZXJpZjsgZm9udC1zaXplOjExcHQ7IGNvbG9yOmJsYWNrIj4NClJlZ2FyZHMsPGJyPg0KPC9k aXY+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9ImRpcmVjdGlvbjpsdHI7IG1hcmdpbjowOyBwYWRk aW5nOjA7IGZvbnQtZmFtaWx5OnNhbnMtc2VyaWY7IGZvbnQtc2l6ZToxMXB0OyBjb2xvcjpibGFj ayI+DQpLb2VuLjxicj4NCjxicj4NCjxicj4NCjwvZGl2Pg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxl PSJkaXJlY3Rpb246bHRyOyBtYXJnaW46MDsgcGFkZGluZzowOyBmb250LWZhbWlseTpzYW5zLXNl cmlmOyBmb250LXNpemU6MTFwdDsgY29sb3I6YmxhY2siPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxl PSJkaXJlY3Rpb246bHRyOyBtYXJnaW46MDsgcGFkZGluZzowOyBmb250LWZhbWlseTpzYW5zLXNl cmlmOyBmb250LXNpemU6MTFwdDsgY29sb3I6YmxhY2siPg0KPGEgaHJlZj0iaHR0cHM6Ly9ha2Eu bXMvZ2hlaTM2Ij5PdXRsb29rIHZvb3IgQW5kcm9pZDwvYT4gZG93bmxvYWRlbjwvZGl2Pg0KPGJy Pg0KPC9kaXY+DQo8aHIgdGFiaW5kZXg9Ii0xIiBzdHlsZT0iZGlzcGxheTppbmxpbmUtYmxvY2s7 IHdpZHRoOjk4JSI+DQo8ZGl2IGlkPSJ4X2RpdlJwbHlGd2RNc2ciIGRpcj0ibHRyIj48Zm9udCBm YWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIiBjb2xvcj0iIzAwMDAwMCIgc3R5bGU9ImZvbnQtc2l6 ZToxMXB0Ij48Yj5Gcm9tOjwvYj4gSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVi cnVhcnkgMTQsIDIwMTggMjowODozMCBQTTxicj4NCjxiPlRvOjwvYj4gTWlyamEgS8O8aGxld2lu ZDxicj4NCjxiPkNjOjwvYj4gRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCk7 IGVraW5uZWFyQGFwcGxlLmNvbTsgTHViYXNoZXYsIElnb3I7IElhbiBTd2V0dDsgUVVJQyBXRzsg Q2hyaXN0aWFuIEh1aXRlbWE7IEluZ2VtYXIgSm9oYW5zc29uIFM8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUkU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uIDwvZm9udD4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMXB0OyI+DQo8ZGl2IGNsYXNzPSJQbGFpblRleHQiPkhpPGJyPg0KPGJyPg0KSSBh dHRhY2ggdGhlIG1pbnV0ZXMgZnJvbSB0aGUgc2lkZSBtZWV0aW5nIGluIFNpbmdhcG9yZSwgSSBi ZWxpZXZlIHRoYXQgdGhleSB3ZXJlIG9ubHkgcG9zdGVkIG9uIHRoZSBlY24tcXVpYyBtYWlsaW5n IGxpc3Qg4pi5IC48YnI+DQo8YnI+DQpJIGFncmVlIHRoYXQgdGhlIHNlbmRlci9yZWNlaXZlZCBp c3N1ZXMgYXJlIHByb2JhYmx5IGtub3duIGEtcHJpb3J5IGFuZCBpZiBhIHNlbmRlciBkb2VzIGtu b3cgdGhhdCBpdHMgT1Mgc3RhY2sgZG9lcyBub3QgaGF2ZSB0aGUgbmVjZXNzYXJ5IEFQSSBzdXBw b3J0IGZvciBFQ04gdGhlbiBpdCBkb2VzIG5vdCBtYWtlIG11Y2ggc2Vuc2UgdG8gdHJ5IGl0Ljxi cj4NCjxicj4NCi9JbmdlbWFyPGJyPg0KJm5ic3A7IDxicj4NCjxicj4NCiZndDsgLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IE1pcmphIEvDvGhsZXdpbmQgWzxhIGhy ZWY9Im1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoIj5tYWlsdG86bWlyamEu a3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDwvYT5dPGJyPg0KJmd0OyBTZW50OiBkZW4gMTMgZmVi cnVhcmkgMjAxOCAxMzoyOTxicj4NCiZndDsgVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0O2lu Z2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0Ozxicj4NCiZndDsgQ2M6IERlIFNjaGVw cGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApICZsdDtrb2VuLmRlX3NjaGVwcGVyQG5va2lh LTxicj4NCiZndDsgYmVsbC1sYWJzLmNvbSZndDs7IGVraW5uZWFyQGFwcGxlLmNvbTsgTHViYXNo ZXYsIElnb3I8YnI+DQomZ3Q7ICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0OzsgSWFuIFN3ZXR0 ICZsdDtpYW5zd2V0dEBnb29nbGUuY29tJmd0OzsgUVVJQyBXRzxicj4NCiZndDsgJmx0O3F1aWNA aWV0Zi5vcmcmZ3Q7OyBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZn dDs8YnI+DQomZ3Q7IFN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQyBjb25uZWN0aW9uIG1pZ3JhdGlv bjxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSBJbmdlbWFyLDxicj4NCiZndDsgPGJyPg0KJmd0OyBz ZWUgYmVsb3cuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgQW0gMTIuMDIuMjAxOCB1bSAyMjox MSBzY2hyaWViIEluZ2VtYXIgSm9oYW5zc29uIFM8YnI+DQomZ3Q7ICZsdDtpbmdlbWFyLnMuam9o YW5zc29uQGVyaWNzc29uLmNvbSZndDs6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhp PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFBsZWFzZSBzZWUgaW5saW5lPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEJSPGJyPg0KJmd0OyAmZ3Q7IEluZ2VtYXI8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBGcm9tOiBNaXJqYSBLw7xobGV3aW5kIFs8YSBocmVmPSJtYWlsdG86bWly amEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCI+bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlr LmVlLmV0aHouY2g8L2E+XTxicj4NCiZndDsgJmd0OyZndDsgU2VudDogZGVuIDEyIGZlYnJ1YXJp IDIwMTggMTY6MjY8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTICZs dDtpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7 IENjOiBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJwKSAmbHQ7a29lbi5kZV9z Y2hlcHBlckBub2tpYS08YnI+DQomZ3Q7ICZndDsmZ3Q7IGJlbGwtbGFicy5jb20mZ3Q7OyBla2lu bmVhckBhcHBsZS5jb207IEx1YmFzaGV2LCBJZ29yPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbHQ7aWx1 YmFzaGVAYWthbWFpLmNvbSZndDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZn dDs7IFFVSUMgV0c8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZsdDtxdWljQGlldGYub3JnJmd0OzsgQ2hy aXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVtYS5uZXQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBTdWJqZWN0OiBSZTogRUNOIGluIFFVSUMgY29ubmVjdGlvbiBtaWdyYXRpb248YnI+DQom Z3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBIaSBJbmdlbWFyLDxicj4NCiZndDsgJmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IHR3byBwb2ludHMuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsgSSB0aGluayBpdCB3b3VsZCBiZSBnb29kIHRvIGJlIGFzIGV4cGxp Y2l0IGFzIHBvc3NpYmxlIGhlcmUsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGVyZWZvcmUgSSB3b3Vs ZCBwcmVmZXIgaWYgYW4gZW5kcG9pbnQgdGhhdCBrbm93cyB0aGF0IGl0IGNhbiBub3Q8YnI+DQom Z3Q7ICZndDsmZ3Q7IGFjY2VzcyB0aGUgRUNOIElQIGJpdHMgaW5kaWNhdGVzIHRoaXMgZGlyZWN0 bHkgaW4gdGhlIGhhbmRzaGFrZS4gSW48YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoaXMgY2FzZSBubyBm dXJ0aGVyIHRlc3RpbmcgaXMgbmVlZGVkLjxicj4NCiZndDsgJmd0OyAmbHQ7SUomZ3Q7IFllcywg dGhpcyB3YXMgdGhlIG9yaWdpbmFsIGlkZWEsIHdlIGRpc2N1c3NlZCB0aGlzIGF0IHRoZSBFQ048 YnI+DQomZ3Q7ICZndDsgUVVJQyBzaWRlIG1lZXRpbmcgdGhvdWdoIGFuZCBhZnRlcndhcmRzIGFu ZCBhcyBmYXIgYXMgSSB1bmRlcnN0YW5kIGl0LDxicj4NCiZndDsgJmd0OyB0aGVyZSB3YXMgYSBj b25zZW5zdXMgdGhhdCBpdCB3YXMgdW5uZWNlc3NhcmlseSBjb21wbGljYXRlZC4gU28gd2U8YnI+ DQomZ3Q7ICZndDsgc2VsZWN0ZWQgYSBtZXRob2Qgd2hlcmUgd2UganVzdCB2ZXJpZnkgdGhhdCB0 aGUgRUNUKDApLEVDVCgxKSxDRTxicj4NCiZndDsgJmd0OyBjb3VudGVycyBoYXZlIHJlYXNvbmFi bGUgdmFsdWVzLiBJZiB0aGF0IGlzIG5vdCB0aGUgY2FzZSwgdGhlbiBpdCBpczxicj4NCiZndDsg Jmd0OyBhbiBpbmRpY2F0aW9uIHRoYXQgZWl0aGVyIHRoZSBwYXRoIG9yIHRoZSBlbmRwb2ludHMg ZG8gbm90IHN1cHBvcnQ8YnI+DQomZ3Q7ICZndDsgRUNOLiAmbHQ7L0lKJmd0Ozxicj4NCiZndDsg PGJyPg0KJmd0OyBJIGNoZWNrZWQgdGhlIG1pbnV0ZXMgYW5kIGNvdWxkIG5vdCByZWFsbHkgZmlu ZCBhIGNvbmNsdXNpb24gdGhlcmUuIEkgYWdyZWU8YnI+DQomZ3Q7IHRoYXQgdGhlcmUgc2hvdWxk IGJlIG5vIG5lZ290aWF0aW9uIGluIHRoZSBoYW5kc2hha2UgKGJvdGggZW5kcG9pbnQgbmVlZDxi cj4NCiZndDsgdG8gaW1wbGVtZW50IHRoZSBFQ04gbG9naWMgYXMgcGFydCBvZiB2MSkgYnV0IHdo YXQgd291bGQgYmUgaGVscGZ1bCBpcyB0byBsZXQ8YnI+DQomZ3Q7IHRoZSBvdGhlciBlbmQga25v dyBpZiB5b3UgYWxyZWFkeSBrbm93IHRoYXQgeW91IG5ldmVyIHdpbGwgYmUgYWJsZSB0bzxicj4N CiZndDsgcHJvdmlkZSBmZWVkYmFjayBiZWNhdXNlIHlvdSBjYW4ganVzdCBub3QgcmVhZCB0aGUg Yml0cyBpbiB0aGUgSVAgaGVhZGVyLjxicj4NCiZndDsgVGhhdCBpcyBub3QgY29tcGxpY2F0ZWQg YXQgYWxsLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHRoaW5rIHdoYXQgd2UgbmVlZCB0byBzcGVj aWZ5IGluIHYxIGlzIGEgd2F5IHRvIHByb3ZpZGUgRUNOIGZlZWRiYWNrIChvcjxicj4NCiZndDsg aW5kaWNhdGUgdGhhdCB0aGlzIGlzIG5vdCBwb3NzaWJsZSkuIEhvd2V2ZXIsIHdlIGFjdHVhbGx5 IHdvdWxkIG5vdCBuZWVkIHRvPGJyPg0KJmd0OyBzYXkgYW55dGhpbmcgYWJvdXQgaG93IEVDTiBz aG91bGQgYmUgdXNlZC4gVGhhdOKAmXMgYSBzZW5kZXIgc2lkZSBkZWNpc2lvbi48YnI+DQomZ3Q7 IEFzIGxvbmcgYXMgeW91IGNhbiBnZXQgZmVlZGJhY2ssIHdlIGFyZSBmbGV4aWJsZSBpbiBob3cg dG8gdXNlIGFuZCB0ZXN0IEVDTiBpbjxicj4NCiZndDsgdjEgb3IgYW55dGltZSBsYXRlci4gT2Yg Y291cnNlIGl0IHdvdWxkIGJlIG5pY2UgdG8gcHJvdmlkZSBzb21lIGRlZmF1bHQ8YnI+DQomZ3Q7 IHJlY29tbWVuZGF0aW9ucyB3aXRoIHNvbWUgZWFzeSBmYWxsYmFjayBsb2dpYyBidXQgdGhhdCdz IHRoZSBwYXJ0IHdlIGNhbjxicj4NCiZndDsgZXhwZXJpbWVudCB3aXRoIGFuZCBjaGFuZ2UgYW55 IHRpbWUgd2l0aG91dCBhbnkgbmVlZCB0byBjaGFuZ2UgdGhlPGJyPg0KJmd0OyBwcm90b2NvbCBz cGVjIChhcyBsb25nIGFzIEVDTiBmZWVkYmFjayBpcyBwcm92aWRlZCwgd2hlbiBFQ04gaXMgdXNl ZCBieSB0aGU8YnI+DQomZ3Q7IHNlbmRlcikuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBGdXJ0aGVyLCB0aGUgcGF0aCB0ZXN0 aW5nIGl0c2VsZiBpcyBpbmRlcGVuZGVudCBvZiBRVUlDIGFuZCBjYW4gYmU8YnI+DQomZ3Q7ICZn dDsmZ3Q7IHVzZWQgZm9yIGFueSBwcm90b2NvbC4gTW9yZW92ZXIsIGl04oCZcyBtb3JlIGNvbXBs aWNhdGVkIHRoYW4ganVzdDxicj4NCiZndDsgJmd0OyZndDsgdGVzdGluZyBFQ1QuIEkgZ3Vlc3Mg dGhlIGdlbmVyYWwgYWR2aWNlIGhlcmUgaXMgdG8gcmVtZW1iZXIgd2hpY2g8YnI+DQomZ3Q7ICZn dDsmZ3Q7IGNvZGVwb2ludHMgd2VyZSBzZW5kIGFuZCBjb21wYXJlIHRoaXMgdG8gdGhlIGZlZWRi YWNrIHByb3ZpZGVkLiBJZjxicj4NCiZndDsgJmd0OyZndDsgZGlzY3JlcGFuY2llcyBhcmUgb2Jz ZXJ2ZWQgdGhhdCBpbmRpY2F0ZSB0aGF0IGEgbWlkZGxlYm94IGhhcyBjaGFuZ2VkPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyB0aGVzZSBiaXRzLCBhbGwgcGFja2V0cyBzaG91bGQgYmUgbWFya2VkIGFzIG5v LUVDVCAod2hpbGUgYWRkaXRpb25hbDxicj4NCiZndDsgJmd0OyZndDsgdGVzdGluZyBNQVkgYmUg cGVyZm9ybWVkIGF0IGFueSBsYXRlciBwb2ludCBpbiB0aW1lKS4gSG93ZXZlciwgaG93PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBleGFjdGx5IHRoaXMgdGVzdGluZyBzaG91bGQgbG9vayBsaWtlLCBzaG91 bGQgbm90IGJlIHNwZWNpZmllZCBpbiB0aGlzIGRvYzxicj4NCiZndDsgKGJ1dCBtb3JlIGdlbmVy YWxseSkuPGJyPg0KJmd0OyAmZ3Q7ICZsdDtJSiZndDsgSXQgaXMgcG9zc2libGUgdGhhdCB0aGUg YWN0dWFsIHBhdGggdmVyaWZpY2F0aW9uIGNhbiBiZSBwdXQgYXMgYTxicj4NCiZndDsgJmd0OyBz ZXBhcmF0ZSBkb2N1bWVudCwgbm90IHN1cmUgaWYgdGhhdCBpcyBhY2NlcHRlZCBieSB0aGUgZ3Jv dXAgb3IgaXQgaXM8YnI+DQomZ3Q7ICZndDsgZGVzaXJlZCB3aXRoIGEgbW9yZSBlbGFib3JhdGUg ZGVzY3JpcHRpb24gZGlyZWN0bHkgaW4gdGhlIFFVSUMgZHJhZnRzLjxicj4NCiZndDsgJmd0OyBB cyByZWdhcmRzIHRvIHZlcmlmaWNhdGlvbiwgSSBkbyBiZWxpZXZlIHRoYXQgdGhlIHByb3Bvc2Vk IGNvdW50ZXJzPGJyPg0KJmd0OyAmZ3Q7IHNob3VsZCBiZSBhYmxlIHRvIGRldGVjdCBibGVhY2hp bmcsIGFjY2lkZW50YWwgcmVtYXJraW5nIGZyb20gRUNUKDApPGJyPg0KJmd0OyAmZ3Q7IHRvIEVD VCgxKSBhbmQgYWxzbyBjYXNlcyB3aGVyZSBwYWNrZXRzIGFyZSBub3QgQ0UgbWFya2VkIGF0IGFs bDxicj4NCiZndDsgJmd0OyBkZXNwaXRlIG90aGVyIHNpZ25zIG9mIGNvbmdlc3Rpb24gJmx0Oy9J SiZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgV2UgdHJpZWQgdG8gZGVzaWduIGEgbW9yZSBlbGFi b3JhdGVkIHRlc3Rpbmcgc2NoZW1lIHdoZXJlIHdlIHdvdWxkIHNlbmQ8YnI+DQomZ3Q7IDMgRUNU MCwgdGhlIDMgRUNUMSwgYW5kIHRoZSAzIENFICh3aGljaCB3ZSB3b3VsZCBvZiBjYXVzZSBub3Qg Y291bnQgYXMgYTxicj4NCiZndDsgY29uZ2VzdGlvbiBpbmRpY2F0aW9uIGFzIHRoZSBDRSB3YXMg c2V0IGJ5IHRoZSBzZW5kZXIpLiBIb3dldmVyLCB0aGlzIHdhczxicj4NCiZndDsgbW9zdGx5IHRv IGRldGVjdCBibGFjay13aGFsaW5nIHdoaWNoIGlzIHByb2JhYmx5IGxlc3MgYSBjb25jZXJuIHRo YW4gcmUtPGJyPg0KJmd0OyBtYXJraW5nLiBJIHRoaW5rIHRvZGF5IHRoZSBtb3N0IGNvbW1vbiBj YXNlIGl0IHRoYXQgdGhlIGJpdHMgd2lsbCBiZSBzZXQgdG88YnI+DQomZ3Q7IHplcm9zIHdoaWNo IGlzIG9ubHkgYSBwcm9ibGVtIHdoZW4gdGhlcmUgd2FzIHNvbWUgQ0UgbWFya2luZyBwcmV2aW91 c2x5PGJyPg0KJmd0OyBvbiB0aGUgcGF0aCB0aGF0IHRoZW4gd291bGQgZ2V0IGxvc3QuIFRodXMg aW4gdGhpcyBjYXNlIGl0IHdvdWxkIGJlPGJyPg0KJmd0OyByZWNvbW1lbmQgdG8gbm90IHVzZSBF Q04vbm90IHNldCBwYWNrZXRzIGFzIEVDVCBhdCBzZW5kZXIgc2lkZS48YnI+DQomZ3Q7IDxicj4N CiZndDsgSG93ZXZlciwgYXMgSSBzYWlkIGFib3ZlLCB3ZSBwcm9iYWJseSBzaG91bGQgbWFrZSBy ZWNvbW1lbmRhdGlvbiBob3cgdG88YnI+DQomZ3Q7IHVzZSBFQ04gYnkgZGVmYXVsdCBidXQgbmVl ZCB0byBsZWF2ZSByb29tIGZvciBvdGhlciB1c2FnZS90ZXN0aW5nIHNjaGVtZXMuPGJyPg0KJmd0 OyBCdXQgYWZ0ZXIgYWxsIHRoZSByZWNlaXZlciBiZWluZyBub3QgYWJsZSB0byByZWFkIHRoZSBi aXRzIGFuZCByZW1hcmtpbmcgb24gdGhlPGJyPg0KJmd0OyBwYXRoIGFyZSB0byBkaWZmZXJlbnQg dGhpbmdzIGFuZCBzaG91bGQgbm90IGJlIG1peGVkIHVwLiBJZiB0aGUgc2VuZGVyIGNhbjxicj4N CiZndDsgbm90IHJlYWQgdGhlIGJpdHMgdGhpcyBpcyBrbm93IGEgcHJpb3JpIGFuZCB0aGVyZSBp cyBubyBhbWJpZ3VpdHkgdGhhdCBuZWVkcyB0bzxicj4NCiZndDsgYmUgdGVzdGVkLiBTbyB3aHkg bm90IHNpZ25hbCBpdCBkaXJlY3RseS4gVGhlIHF1ZXN0aW9uIGlmIHRoZSBzZW5kZXIgY2FuIHdy aXRlPGJyPg0KJmd0OyBFQ04gZG9lcyBub3QgbmVlZCB0byBiZSBjb21tdW5pY2F0ZWQuIFRoZXJl IGlzIG5vIGRpZmZlcmVuY2UgaW4gdGhlPGJyPg0KJmd0OyBzZW5kZXIgZGVjaWRlZCB0byBub3Qg dXNlIEVDTiBvciBpdCBqdXN0IGNhbiBub3QgdXNlIGl0OyBpbiBib3RoIGNhc2VzIGl0IGlzIG5v dDxicj4NCiZndDsgbmVjZXNzYXJ5IHRvIHNlbmQgRUNOIGZlZWRiYWNrIGJhY2suIE9ubHkgaWYg YSBub24tbm9uLUVDVCBpcyBvYnNlcnZlZCBhdDxicj4NCiZndDsgdGhlIHJlY2VpdmVyLCBFQ04g ZmVlZGJhY2sgbmVlZHMgdG8gYmUgcHJvdmlkZWQuIEhvd2V2ZXIsIGtub3dpbmcgdGhhdDxicj4N CiZndDsgdGhlIHJlY2VpdmVyIGNhbuKAmXQgbm90IHByb3ZpZGUgZmVlZGJhY2sgaXMgaW1wb3J0 YW50IGJlY2F1c2UgaW4gdGhpcyBjYXNlIHRoZTxicj4NCiZndDsgc2VuZGVyIE1VU1Qgbm90IHNl dCB0aGUgcGFja2V0cyBhcyBFQ1QgYXMgaXQgd2lsbCBub3QgYmUgYWJsZSB0byByZWFjdCB0byB0 aGF0PGJyPg0KJmd0OyBzaWduYWwuIFRlc3RpbmcgdGhlIHBhdGggaW4gaW5kZXBlbmRlbnQgb2Yg dGhhdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgTWlyamE8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsgTWlyamE8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IEFtIDA5LjAyLjIwMTggdW0gMDg6MzQgc2NocmllYiBJbmdlbWFy IEpvaGFuc3NvbiBTPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbHQ7aW5nZW1hci5zLmpvaGFuc3NvbkBl cmljc3Nvbi5jb20mZ3Q7Ojxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsgSGkgRXJpYywgS29lbiAmIzQzOyBvdGhlcnM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzIGFuZCB0aGUgdXBk YXRlLiBBIHF1ZXN0aW9uIHRvIHRoZSByZXN0IG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgdGhl PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhdWRpZW5jZSwgZG9lcyB0aGUgcHJlc2VudGVkIHRleHQgZXhw bGFpbiBzdWZmaWNpZW50bHkgZW5vdWdoIGhvdyBFQ048YnI+DQomZ3Q7ICZndDsmZ3Q7IHdvcmtz IHdpdGggY29ubmVjdGlvbiBtaWdyYXRpb24gPzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IDxhIGhy ZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraS9FQ04taW4tUVVJ QyN0cmFuc3BvcnQtIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lr aS9FQ04taW4tUVVJQyN0cmFuc3BvcnQtPC9hPjxicj4NCiZndDsgJmd0OyZndDsgZHJhZnQtY29u bmVjdGlvbi1taWdyYXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgL0luZ2VtYXI8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgRnJvbTog RGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCk8YnI+DQomZ3Q7ICZndDsmZ3Q7 IFs8YSBocmVmPSJtYWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tIj5t YWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tPC9hPl08YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBTZW50OiBkZW4gMiBmZWJydWFyaSAyMDE4IDE1OjQ0PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsgVG86IGVraW5uZWFyQGFwcGxlLmNvbTsgSW5nZW1hciBKb2hhbnNzb24gUzxi cj4NCiZndDsgJmd0OyZndDsgJmx0O2luZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IENjOiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0 OzsgSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29nbGUuY29tJmd0Ozs8YnI+DQomZ3Q7ICZndDsm Z3Q7IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0OzsgQ2hyaXN0aWFu IEh1aXRlbWE8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZsdDtodWl0ZW1hQGh1aXRlbWEubmV0Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJFOiBFQ04gaW4gUVVJQyBjb25uZWN0aW9u IG1pZ3JhdGlvbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg SGkgSW5nZW1hciw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 IEkgYWxzbyByZWFkIGFnYWluIHRocm91Z2ggdGhlIGRvY3VtZW50LCBhbmQgaGFkIGZvbGxvd2lu ZyBjb21tZW50czo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 IEkgcmVwbGFjZWQ6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg4oCcVGhlIEFDS19FQ04gZnJhbWUg aXMgdXNlZCB0byBjb252ZXkgQUNLcyB3aGVuIHRoZSBFQ04gY2FwYWJpbGl0eTxicj4NCiZndDsg Jmd0OyZndDsgZXhjaGFuZ2UgY29uY2x1ZGVzIHRoYXQgRUNOIHNob3VsZCBiZSB1c2VkIGZvciB0 aGUgZ2l2ZW4gY29ubmVjdGlvbi7igJ08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBPcmlnaW5hbGx5 IGl0IHNvdW5kcyBhcyBpZiB0aGUgY291bnRlcnMgYXJlIG5vdCBlY2hvZWQgYW55bW9yZSBpZjxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7IHRoZSBFQ048YnI+DQomZ3Q7ICZndDsmZ3Q7IGNhcGFiaWxp dHkgY2hlY2sgZmFpbHMuIEkgYXNzdW1lIHRoaXMgd2FzIG5vdCB0aGUgaW50ZW50aW9uLCBidXQg aWY8YnI+DQomZ3Q7ICZndDsmZ3Q7IGl0IGlzOiBGaXJzdCwgd2UgZG9u4oCZdCBoYXZlIGEgcHJv dG9jb2wgb3IgZGVjaXNpb24gcG9pbnQgZGVmaW5lZCB3aGVuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0 aGF0IGNvbmRpdGlvbiBpcyBtZXQgKHNlbmRlciBzaG91bGQgbGV0IHRoZSByZWNlaXZlciBrbm93 IGluIHRoZTxicj4NCiZndDsgJmd0OyZndDsgbmV4dCBwYWNrZXQpLCBhbmQgc2Vjb25kLCBJIHdv dWxkIGFsd2F5cyBzZW5kIHRoZSBlY2hvLCBhcyB3ZSBtaWdodDxicj4NCiZndDsgJmd0OyZndDsg 4oCcdHJ5IGFnYWluIGxhdGVyICh3aXRoIGFub3RoZXIgRUNUPynigJ0sIG9yIG1pZ2h0IGRlY2lk ZSB0byB1c2UgdGhlIEVDTiBiaXRzPGJyPg0KJmd0OyBkaWZmZXJlbnRseSBsYXRlci48YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEkgYWxzbyBjaGFuZ2VkIHRo ZSB0ZXh0IGFyb3VuZCB0aGUgY29ubmVjdGlvbiBtaWdyYXRpb24sIEkgdGhpbms8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBiZWZvcmUgRXJpYzxicj4NCiZndDsgJmd0OyZndDsgcmV2aWV3ZWQgaXQu IEkgbWFkZSBpdCBzdWNoIHRoYXQgZXZlcnkgbmV3IHBhdGggY3JlYXRlcyBhIG5ldzxicj4NCiZn dDsgJmd0OyZndDsgY29ubmVjdGlvbiBzdGF0ZSB3aXRoIGFuIGluaXRpYWxpemVkIGNvbmdlc3Rp b24gY29udHJvbCBzdGF0ZSBhbmQgRUNOPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBjb3VudGVycyAoYXQg bGVhc3QgRUNOIGNvdW50ZXJzIHJlc2V0IHRvIDBzKS4gTm90IHN1cmUgaWYgdGhpczxicj4NCiZn dDsgJmd0OyZndDsgbWF0Y2hlcyB3aXRoIHRoZSBvdGhlciBzZWN0aW9ucyBpbiB0aGUgUVVJQyBk cmFmdC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEkgYWxz byBoYWQgdGhlIHRob3VnaHQgd2hldGhlciBpdCB3YXMgcmVhbGx5IG5lZWRlZCB0byBoYXZlIHRo ZSAyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgY2FzZXMuIEk8YnI+DQomZ3Q7ICZndDsmZ3Q7IGFn cmVlIHdlIHNob3VsZCBzaW1wbGlmeSwgYnkganVzdCBzdGFydGluZyBvdmVyIGFuZCBkb2luZyB0 aGUgY2hlY2s8YnI+DQomZ3Q7ICZndDsmZ3Q7IHVuY29uZGl0aW9uYWxseSB3aGV0aGVyIGl0IHdh cyBzdWNjZXNzZnVsIG9yIG5vdCBpbiBhIHByZXZpb3VzIHBhdGguPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7IEtvZW4uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBG cm9tOiBla2lubmVhckBhcHBsZS5jb20gWzxhIGhyZWY9Im1haWx0bzpla2lubmVhckBhcHBsZS5j b20iPm1haWx0bzpla2lubmVhckBhcHBsZS5jb208L2E+XTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMiwgMjAxOCAxMjowMiBBTTxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7IFRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDtpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbSZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBDYzogUVVJQyBXRyAmbHQ7cXVp Y0BpZXRmLm9yZyZndDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZn dDs7IENocmlzdGlhbiBIdWl0ZW1hPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbHQ7aHVpdGVtYUBodWl0 ZW1hLm5ldCZndDs7IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyAmbHQ7a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tJmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQyBjb25uZWN0 aW9uIG1pZ3JhdGlvbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsgSGkgSW5nZW1hciw8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsm Z3Q7IFRoaXMgZ2VuZXJhbGx5IGxvb2tzIGdvb2QgdG8gbWUhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsgQSBmZXcgcXVlc3Rpb25zIGFuZCBvYnNlcnZhdGlvbnM6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGVyZSBhcmUgdHdvIHVuaXF1ZSBjYXNlczo8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAoiBFQ04gY2FwYWJpbGl0eSBjaGVjayBzdWNjZXNzZnVsIGF0 IGluaXRpYWwgY29ubmVjdGlvbiBzZXR1cDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAoiBFQ04gY2FwYWJpbGl0eSBjaGVjayBmYWlsZWQg YXQgaW5pdGlhbCBjb25uZWN0aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgc2V0dXA8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEFyZSB0aGVzZSBhY3R1YWxs eSBhbnkgZGlmZmVyZW50IGluIHRlcm1zIG9mIGFjdGlvbiB0YWtlbiBieSBhbiBlbmRwb2ludD88 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBJdCBzZWVtcyBsaWtlIG9uIHRoZSBuZXcgbmV0d29yayBw YXRoIHRoZSBlbmRwb2ludCB3b3VsZCBnbyB0aHJvdWdoPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg dGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBzYW1lIHByb2Nlc3Mgb2Y6IChhKSB2ZXJpZnkgRUNOIGNh cGFiaWxpdHkgYW5kIGlmIHN1Y2Nlc3NmdWwgdG88YnI+DQomZ3Q7ICZndDsmZ3Q7IHdoYXRldmVy IGRlZ3JlZSB0aGVuIChiKSBydW4gdGhlIHJlc3Qgb2YgdGhlIEVDTiBtYWNoaW5lcnkgYXM8YnI+ DQomZ3Q7IGFwcHJvcHJpYXRlLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgSW4gb3RoZXIgd29yZHMsIGFzIGxvbmcgYXMgeW91IGFsbG93IHBlb3BsZSB0byBz dGFydCB1c2luZyBFQ04gdXBvbjxicj4NCiZndDsgJmd0OyZndDsgbWlncmF0aW9uIChpbiBvdGhl ciB3b3JkcywgdG8gYWxsb3cgc3RhcnRpbmcgaXQgYWZ0ZXIgdGhlIGluaXRpYWw8YnI+DQomZ3Q7 ICZndDsmZ3Q7IGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudCksIHRoZW4gdGhlIHNwZWNpZmljcyBm b3IgRUNOIHdpdGggbWlncmF0aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpcyBlc3NlbnRpYWxseSBv bmUgc3RhdGVtZW50LCB3aGljaCBpcyDigJxkbyB0aGUgRUNOIHByb2Nlc3Mgb24gZWFjaDxicj4N CiZndDsgJmd0OyZndDsgbmV3IG5ldHdvcmsgcGF0aCB0aGF0IHlvdSB1c2XigJ0uPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBDb25uZWN0aW9uIG1pZ3JhdGlv biBoYXMgaW1wYWN0IG9uIHRoZSBudW1iZXIgb2YgcmVwb3J0ZWQgQ0UgbWFya2VkPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBwYWNrZXRzLiBBIG5ldyBjb25uZWN0aW9uIHN0YXRlIHdpdGggbmV3IGNvbmdl c3Rpb24gY29udHJvbCBzdGF0ZSBhbmQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IEVDTiBjb3VudGVycyBp cyBpbnN0YW50aWF0ZWQgYXQgdGhlIHNlbmRlciBhbmQgcmVjZWl2ZXIuIFRoZSBFQ048YnI+DQom Z3Q7ICZndDsmZ3Q7IGNvdW50ZXJzIE1VU1Qgc3RhcnQgZnJvbSB6ZXJvIGFnYWluLjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgVGhpcyBzZWVtcyBmaW5lIHRv IG1lLCBpdOKAmXMgaW5saW5lIHdpdGggdGhlIHJlc3Qgb2YgdGhlIGNvbmdlc3Rpb248YnI+DQom Z3Q7ICZndDsmZ3Q7IGNvbnRyb2wvbG9zcyByZWNvdmVyeSBzdGF0ZSB0aGF0IGFsc28gbmVlZHMg dG8gYmUgcmVzZXQgZm9yIHRoZSBuZXcgcGF0aC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IEdpdmVuIHRoYXQgZWFjaCBtaWdyYXRpb24gcmVxdWlyZXMgYXQg bGVhc3Qgb25lIGV4Y2hhbmdlIG9mIHBhY2tldHM8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBhdCB0 aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IGJlZ2lubmluZyAoYXQgdGhlIHZlcnkgbGVhc3QgZm9yIGFk ZHJlc3MgdmFsaWRhdGlvbiBmcm9tIHRoZSBzaWRlIG9mPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGUg ZW5kcG9pbnQgdGhhdCBkaWRu4oCZdCBtaWdyYXRlKSwgaXQgc2VlbXMgbGlrZSB0aGF04oCZcyBh biBleGNlbGxlbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IG1vbWVudCB0byBtYXJrIHRoZSBwYWNrZXRz IGFuZCBwZXJmb3JtIHRoZSBFQ04gY2FwYWJpbGl0eSBkZXRlY3Rpb24uPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBUaG9zZSBwYWNrZXRzIGFyZSBhbHNvIGxpa2VseSBwYWRkZWQsIGV0Yy4gc2ltaWxhciB0 byBpbml0aWFsIHBhY2tldHM8YnI+DQomZ3Q7ICZndDsmZ3Q7IHNpbmNlIHRoZXnigJlyZSBvbiBh IHByZXZpb3VzbHkgdW51c2VkIG5ldHdvcmsgcGF0aC48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7IEkgdGhpbmsgdGhlIGN1cnJlbnQgcHJvcG9zZWQgcmVxdWly ZW1lbnQgb2YganVzdCB1c2luZyB0aGUg4oCcZmlyc3TigJ08YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyBwYWNrZXRzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBhbmQgbWFya2luZyB0aG9zZSBpcyBzdWZmaWNp ZW50IChhbmQgZ29vZCB0byBhdm9pZCBhbnkgcmVxdWlyZW1lbnQgYXM8YnI+DQomZ3Q7ICZndDsm Z3Q7IHRvIHdoaWNoIGZyYW1lcyBhcmUgY29udGFpbmVkIGluIHRob3NlIHBhY2tldHMpLCBzaW5j ZSB3ZSBhcmUgYWx3YXlzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBleGNoYW5naW5nIHBhY2tldHMgaW4g Ym90aCBkaXJlY3Rpb25zIGltbWVkaWF0ZWx5IGFmdGVyIG1pZ3JhdGlvbi48YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IFRoaXMgaGFzIHRoZSBhZGRlZCBiZW5l Zml0IHN1Y2ggdGhhdCBhbnkgZW5kcG9pbnQg4oCccHJvYmluZ+KAnSBwb3NzaWJsZTxicj4NCiZn dDsgJmd0OyZndDsgbmV0d29yayBwYXRocyBjb3VsZCBpbmNsdWRlIHRoZSBiaXRzIG5lY2Vzc2Fy eSB0byBkZXRlY3QgRUNOPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBjYXBhYmlsaXR5IG9uIHRoZSBwYXRo IGJlaW5nIHByb2JlZCwgc28gaXQgY291bGQgZXZlbiBrbm93IGJlZm9yZTxicj4NCiZndDsgJmd0 OyZndDsgbWlncmF0aW5nIHdoZXRoZXIgb3Igbm90IGl0IHdvdWxkIGJlIGFibGUgdG8gdXNlIEVD TiBvbiB0aGF0IG5ldyBwYXRoLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEVyaWM8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IE9uIEZlYiAxLCAy MDE4LCBhdCAzOjA3IEFNLCBJbmdlbWFyIEpvaGFuc3NvbiBTPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAm bHQ7aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20mZ3Q7IHdyb3RlOjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSGk8YnI+DQomZ3Q7ICZndDsmZ3Q7 Jmd0OyBJIGhhdmUgd3JpdHRlbiB1cCBkaWZmZXJlbnQgYXNwZWN0cyBvZiBjb25uZWN0aW9uIG1p Z3JhdGlvbiBhbmQgaG93PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgaXQ8YnI+DQomZ3Q7ICZndDsm Z3Q7IHBsYXlzIHdpdGggRUNOLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IDxhIGhyZWY9Imh0dHBz Oi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraS9FQ04taW4tUVVJQyN0cmFuc3Bv cnQtIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraS9FQ04taW4t UVVJQyN0cmFuc3BvcnQtPC9hPjxicj4NCiZndDsgJmd0OyZndDsgZHJhZnQtY29ubmVjdGlvbi1t aWdyYXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEEg Y2F2ZWF0Li4gSSBhbSBhIGJpdCB1bnN1cmUgYWJvdXQgdGhlIGRlZmluaXRpb24gb2YgY29ubmVj dGlvbiBtaWdyYXRpb248YnI+DQomZ3Q7IC48YnI+DQomZ3Q7ICZndDsmZ3Q7IE15IGludGVycHJl dGF0aW9uIGlzIHRoYXQgYSBjbGllbnQgbW92ZXMgdG8gYSBuZXcgSVAgYWRkcmVzcyBkdWUgdG88 YnI+DQomZ3Q7ICZndDsmZ3Q7IGUuZy4gYSBOQVQgcmViaW5kIG9yIHN3aXRjaCBmcm9tIFdpRmkg dG8gY2VsbHVsYXIsIHJpZ2h0ID8uIElzIGEgbmV3PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBjb25uZWN0 aW9uIGluc3RhbnRpYXRlZCBhdCBhIGNvbm5lY3Rpb24gbWlncmF0aW9uID88YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IC9JbmdlbWFyPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgSW5nZW1hciBKb2hhbnNzb24mbmJzcDsg TS5TYy48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBNYXN0ZXIgUmVzZWFyY2hlcjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgRXJpY3Nzb24gUmVzZWFyY2g8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBOZXR3b3JrIFByb3RvY29scyAmYW1wOyBFMkUgUGVyZm9ybWFu Y2U8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBMYWJyYXRvcmllZ3LDpG5kIDExPGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsgOTcxIDI4LCBMdWxlw6UsIFN3ZWRlbjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 IFBob25lICYjNDM7NDYtMTA3MSA0MzA0Mjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IFNNUy9NTVMg JiM0Mzs0Ni03MyAwNzggMzI4OTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IGluZ2VtYXIucy5qb2hh bnNzb25AZXJpY3Nzb24uY29tPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cDov L3d3dy5lcmljc3Nvbi5jb20iPnd3dy5lcmljc3Nvbi5jb208L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBZb3UgY2FuJ3Qgc3RhcnQgYSBmaXJlJm5ic3A7IFdvcnJ5aW5nICdib3V0IHlv dXIgbGl0dGxlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgd29ybGQgZmFsbGluZyBhcGFydDxicj4N CiZndDsgJmd0OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJydWNlIFNwcmlu Z3N0ZWVuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PTxicj4NCiZndDsgJmd0Ozxicj4NCjxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_VI1PR0701MB21268D5DE0F26BF9A54530F9B9F50VI1PR0701MB2126_-- From nobody Wed Feb 14 11:14:31 2018 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 748E4124205 for ; Wed, 14 Feb 2018 11:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 TSaKWGU7pkZN for ; Wed, 14 Feb 2018 11:14:27 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DD112D84F for ; Wed, 14 Feb 2018 11:14:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,513,1511856000"; d="asc'?scan'208,217";a="241576197" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx144-out.netapp.com with ESMTP; 14 Feb 2018 11:14:24 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 14 Feb 2018 11:14:24 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 14 Feb 2018 11:14:23 -0800 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=IbQjmd8EpqGOYjmj2fN8EvLGDFEXcpxhJ0B4llFqWHQ=; b=IRZBSXuWUTVR4HxMtC+MchcqM1LzatzCQ2ivgFb8QAsrVuTK8O/9YP+BFdjwk/QMTbK4ctBZ+/NwAXbrhWWB/bnvUgzcBQMKplovXr4pMgVkNAkpxESBzKXyn39AqiAnLne3HevsIiMrThb3SODY6rISblBiGytTjaQI0Rk5Pko= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB897.namprd06.prod.outlook.com (10.141.207.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Wed, 14 Feb 2018 19:14:18 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004%14]) with mapi id 15.20.0506.019; Wed, 14 Feb 2018 19:14:17 +0000 From: "Eggert, Lars" To: Lucas Pardue CC: QUIC WG Subject: Re: Multipath Milestones Thread-Topic: Multipath Milestones Thread-Index: AdOlot2vk/mcXyftQ+aZnFxr8GlL1QAJSPAA Date: Wed, 14 Feb 2018 19:14:17 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:3600:8b01:5da1:de73:ee4e:194e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB897; 7:swBTiqmgs1d+IHSS6CedjoUzhz4+Uz218m8cNfk4cl3QwynuaXleqVeV2l3xD/vCsfPsn0yPS+t3VPWoq31ORwepqRWrJaCwO6Pvo/c56/3X3shx6Q9wpvAViWMy7npAu11P6GDAnpjrA0XmlLI77XmL8zIuDvgHIDQ390sm4zr9EeLsvArRcSDj0//Bru6i9CLT3y71GIrPzdRbhTURcTrHr05bKIOW7RXzXoB0BBJOemWMxVtXBZjiFrxd51ru x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 38f198c5-4d78-4ffb-d278-08d573df24f0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB897; x-ms-traffictypediagnostic: BLUPR06MB897: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(127952516941037); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(3231101)(944501161)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041288)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:BLUPR06MB897; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB897; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(39380400002)(376002)(366004)(396003)(346002)(377424004)(199004)(189003)(2906002)(4001150100001)(68736007)(99936001)(99286004)(6116002)(83716003)(3660700001)(6246003)(53936002)(6512007)(236005)(54896002)(316002)(33656002)(3280700002)(221733001)(86362001)(6486002)(229853002)(4326008)(6436002)(478600001)(102836004)(186003)(59450400001)(76176011)(53546011)(6506007)(25786009)(5250100002)(57306001)(8676002)(3480700004)(50226002)(7736002)(8936002)(81156014)(81166006)(82746002)(5660300001)(7116003)(2900100001)(105586002)(14454004)(6916009)(97736004)(36756003)(2950100002)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB897; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: VvUVgbE2p8E02++uzDDz3bNq8xfgjp65xazIDE6AW3X385qNtOIipw73hkaiZAGS/nq348dUlg6dks68hMXspw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_523EC0BA-2A89-4F67-BE51-E3CA19AAC856"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 38f198c5-4d78-4ffb-d278-08d573df24f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 19:14:17.5425 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB897 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, 14 Feb 2018 19:14:29 -0000 --Apple-Mail=_523EC0BA-2A89-4F67-BE51-E3CA19AAC856 Content-Type: multipart/alternative; boundary="Apple-Mail=_DD9B1698-5ACC-4936-8931-D5A95CDC9D45" --Apple-Mail=_DD9B1698-5ACC-4936-8931-D5A95CDC9D45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2018-2-14, at 15:49, Lucas Pardue wrote: > This might be a bit pedantic but when the milestones were adjusted = back in December, the Multipath extension milestones were left as = originally stated (Nov =E2=80=9917, May =E2=80=9919). >=20 > Is there any intention to modify these? The Nov =E2=80=9917 adoption = has obviously been missed and I=E2=80=99m wondering what I would tell = someone less familiar with the WG when they hypothetically asks me what = that means. yes, we need to update those milestones. I can't recall that we explicitly discussed this when we discussed = pushing the base-drafts milestones back. But to me personally, the = decision to focus all efforts on v1 - and multipath not being part of v1 = - implicitly meant that we'd not really start any real effort before the = base-drafts are shipped off to the IESG. In other words, WG adoption = would probably not happen before Nov 2018, and completion sometime in = 2019 (?). As I said, this is my personal interpretation - it would be good to know = if this is the WG consensus. Lars --Apple-Mail=_DD9B1698-5ACC-4936-8931-D5A95CDC9D45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On = 2018-2-14, at 15:49, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
This might be a bit pedantic but when the milestones were = adjusted back in December, the Multipath extension milestones were left = as originally stated (Nov =E2=80=9917, May =E2=80=9919).
 
Is there = any intention to modify these? The Nov =E2=80=9917 adoption has = obviously been missed and I=E2=80=99m wondering what I would tell = someone less familiar with the WG when they hypothetically asks me what = that means.

yes, we need to update those = milestones.

I can't recall that we = explicitly discussed this when we discussed pushing the base-drafts = milestones back. But to me personally, the decision to focus all efforts = on v1 - and multipath not being part of v1 - implicitly meant that we'd = not really start any real effort before the base-drafts are shipped off = to the IESG. In other words, WG adoption would probably not happen = before Nov 2018, and completion sometime in 2019 (?).

As I said, this is my personal interpretation - it = would be good to know if this is the WG consensus.

Lars
= --Apple-Mail=_DD9B1698-5ACC-4936-8931-D5A95CDC9D45-- --Apple-Mail=_523EC0BA-2A89-4F67-BE51-E3CA19AAC856 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlqEiogACgkQVLXDCb9w wVeCFA/+LgRC9hf7aRFVzNQy35VP2Fd035XIJZNXOpHkkWp2bivl2unrilmcWgXq hkXexKBLTVoGvRzwLt9g4Nn6HIwIGSC5fYHzppiJBWLWM2IHSDGQg+Z1T66iXHAW GB9Dm5PzHtF5lxn+SnOs9p6yRY+RnuiEiO3yPeZpxLNd9DcqhtSb3zDHlGYcHSC1 GO2W5UAhcBiJtk8GHIO6ZFWGjJZz2Oz/FybAOxwDUzr70qoLiWJjEYLrzFqxEZ7a F+YlWWbMRuANugCCVx7KyMErEc8etGpTkJYEea4ggdDqhBLqQ+trCtv7hMHaLP2O l+mq3gLNTxtlsfUY+le2lmhBF13rVydTatp83ZB2vCi7Ztvlq3ElLer9UMsygpUr I3dY9nEbiat1WBUS5gCnKzvpYLGgtZPTkkt1Kbd9dKGg/33IlG2OVbb+h377r6Om 6ObVWt37qrLpqzT9xk8riX21h0Xf7Yq7hGktULd1l0DeToWoV+qcjWEx0OCTUdbH 5sVpDH+vu+36zIIgQiqcb12PmPzkWTUAnSZBgZR2Uzu1kPV97wHvDLL7y6oPphuq DG38M7b+lZ3j3pl3SnABB+s/ec9Oo/qiYctJ4pHifLq8XktSgxtNql1DHl757ktK c1dz/NUsnY8f2WeQSiJudgJM2SegqUC5pvk+LmpGx1hmN/cBGVE= =g06s -----END PGP SIGNATURE----- --Apple-Mail=_523EC0BA-2A89-4F67-BE51-E3CA19AAC856-- From nobody Wed Feb 14 11:22:32 2018 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 1EA96127867 for ; Wed, 14 Feb 2018 11:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 8e8P88byftgH for ; Wed, 14 Feb 2018 11:22:28 -0800 (PST) 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 CB7DD124205 for ; Wed, 14 Feb 2018 11:22:27 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id 140so7324797iti.0 for ; Wed, 14 Feb 2018 11:22:27 -0800 (PST) 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=inuPmyNJfl+gaEox5anm1zYFbdPQEsq0ePCLNKMommg=; b=J70qu71OT2ms+/I6/RaQxoO/9QdtpEPlqZS4nIVj3W+FkLJj0X6BhOnnrofdXCi4TL GvDXH9QRUyI7zard34SQc/QSCyqSdULsylB31tERCLcuv3QbbS0cWtzDMmcfJQXMKPAW xzduInyqOn6p1B4guFeA3NkT2pfCSHMt+eWH04KILB5e+IwVD9sZDo0/GDLMu4DMBSHw fBpjFN/gX9lCoRpj8ezdEX+316vXjvXGw6fJngPO+rv8PvvGCPKXnrmIKvUKVMrAtZDI x7osc5gx4RrCQGmXc9SrzsXGUaMqv5PH0/FjT+lCiOuvWSAmVFmoA+NPJrN7p8mzda6d mI+Q== 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=inuPmyNJfl+gaEox5anm1zYFbdPQEsq0ePCLNKMommg=; b=f/YN4eC6sSNBCe6mLMSkZT9PoDFtgUnBP57IEx8MvmkX1liUm/VF3t4Gyl+CM6eMvH bDVwlzPdZFwxAoZ2cYw60f7PbQf1X0MM3EIVkRNsXpyfLoxeoOCbyPCrwN9YR2SUE0dQ vte7HwhmeOdHm7PL7rgMt/5+Fq/MzjmYVuQVfXSbVqJxnRschNGhCDDoQ9eySWHFdCdH Dh/2yzHyWCLE3VHD0l2a4JG6GX5975uTlL9lFzDx1l+XRmh6FIAel4SM4n1EH3KpnqTU J0fRp23h7hCwnECJKmBxFOb4AVI/k5F9bfM0ly9bjJw1NUWnBBa6fqp90dMeFWFJlLsf n3cQ== X-Gm-Message-State: APf1xPBeLJcgFrEVHTpnnrt8PXRaWEUtXMko1u/bsGC6JzEqJ6nzcrAm loSkzOtNDbg8PiXcEPaqYBRIzmADWXYCyl7IxGL12A== X-Google-Smtp-Source: AH8x22400zH1sIqWhphwFQMgRUL5a+WDXsbcChB4GB+0kqYvuVOsAM72stKN/Am4jWfRR3/Lhh9SQV8FU9RFProcA90= X-Received: by 10.36.121.5 with SMTP id z5mr56779itc.146.1518636146753; Wed, 14 Feb 2018 11:22:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Wed, 14 Feb 2018 11:22:06 -0800 (PST) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> From: Ian Swett Date: Wed, 14 Feb 2018 14:22:06 -0500 Message-ID: Subject: Re: Multipath Milestones To: "Eggert, Lars" Cc: Lucas Pardue , QUIC WG Content-Type: multipart/alternative; boundary="001a114abbba12aa0a0565310802" 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, 14 Feb 2018 19:22:30 -0000 --001a114abbba12aa0a0565310802 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lars, that was my interpretation as well. I think the right path forward is for those particularly interested in multipath to experiment with QUIC extensions inside v1, once the extension mechanism is defined. Once some experimentation has happened, we'll be in a better place to have an informed discussion about some of the points Christian raised in his multipath requirements draft: https://tools.ietf.org/html/draft-huitema-quic-mpath-req-01 The recent text being added about Connection Migration should lay some of the groundwork for adding second paths. https://github.com/ quicwg/base-drafts/pull/1012 On Wed, Feb 14, 2018 at 2:14 PM, Eggert, Lars wrote: > Hi, > > On 2018-2-14, at 15:49, Lucas Pardue wrote: > > This might be a bit pedantic but when the milestones were adjusted back i= n > December, the Multipath extension milestones were left as originally stat= ed > (Nov =E2=80=9917, May =E2=80=9919). > > Is there any intention to modify these? The Nov =E2=80=9917 adoption has = obviously > been missed and I=E2=80=99m wondering what I would tell someone less fami= liar with > the WG when they hypothetically asks me what that means. > > > yes, we need to update those milestones. > > I can't recall that we explicitly discussed this when we discussed pushin= g > the base-drafts milestones back. But to me personally, the decision to > focus all efforts on v1 - and multipath not being part of v1 - implicitly > meant that we'd not really start any real effort before the base-drafts a= re > shipped off to the IESG. In other words, WG adoption would probably not > happen before Nov 2018, and completion sometime in 2019 (?). > > As I said, this is my personal interpretation - it would be good to know > if this is the WG consensus. > > Lars > --001a114abbba12aa0a0565310802 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lars, that was my interpretation as well.

I think the right path forward is for those particularly interested in m= ultipath to experiment with QUIC extensions inside v1, once the extension m= echanism is defined.=C2=A0 Once some experimentation has happened, we'l= l be in a better place to have an informed discussion about some of the poi= nts Christian raised in his multipath requirements draft:=C2=A0https://tools.ietf.org/html/draft-huitema-quic-mpath-req-01


On Wed, Feb 14, 2018 at 2:14 PM= , Eggert, Lars <lars@netapp.com> wrote:
Hi,

On 2018-2-14, at 15:49, Lucas Pardue <<= a href=3D"mailto:Lucas.Pardue@bbc.co.uk" target=3D"_blank">Lucas.Pardue@bbc= .co.uk> wrote:
This might be a bit pedantic but= when the milestones were adjusted back in December, the Multipath extensio= n milestones were left as originally stated (Nov =E2=80=9917, May =E2=80=99= 19).
=C2=A0
Is there any intention to modify these? The Nov =E2=80=9917 a= doption has obviously been missed and I=E2=80=99m wondering what I would te= ll someone less familiar with the WG when they hypothetically asks me what = that means.

yes, = we need to update those milestones.

I can't re= call that we explicitly discussed this when we discussed pushing the base-d= rafts milestones back. But to me personally, the decision to focus all effo= rts on v1 - and multipath not being part of v1 - implicitly meant that we&#= 39;d not really start any real effort before the base-drafts are shipped of= f to the IESG. In other words, WG adoption would probably not happen before= Nov 2018, and completion sometime in 2019 (?).

As= I said, this is my personal interpretation - it would be good to know if t= his is the WG consensus.

Lars

--001a114abbba12aa0a0565310802-- From nobody Wed Feb 14 13:33:23 2018 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 851FE126DED for ; Wed, 14 Feb 2018 13:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EoPcBX2NtXHa for ; Wed, 14 Feb 2018 13:33:19 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 599CC126C0F for ; Wed, 14 Feb 2018 13:33:19 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id b16so15799108ywh.12 for ; Wed, 14 Feb 2018 13:33:19 -0800 (PST) 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=Xy2y/yKQdtCSsOZc+Mw8NFUS1QBCUnhj8rU5gMBjN3Q=; b=JvvJmIS/JY2qwDftlVEL6ReOCZo7b+WFTNzYT0+AjYniwdzW1ykDH6Buz5V5/t3AhP yPP+Ek4DxZe9yUsxuSEJUAJ7Ainx7C9r8OEFdjkULBji/atPVwR5wEPW6vTgrK9IZwHV HqpXy8WWU2Z0XicFqAQvSP5SGFBr3hoOI6bbXRgSVwplwjx+aDJE6M17FCGALBlPjPbb uRJ0EvY2WFPjw5nGbPHNPGVou1hymqmL3oTI2WP8LON+fDCz5g8H6AKC7Hhm4uPSbrRt y4GSuvod3TS6Y0IviXX/FEjHHT4szYJSmljPYzQxaNr/U49okTe2rvCRxI5vPZLo9QF8 jtkw== 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=Xy2y/yKQdtCSsOZc+Mw8NFUS1QBCUnhj8rU5gMBjN3Q=; b=L3wDS7Q1L6Py4EDhiHRLhzkMvJMrV1VqB6YXWVSdSdUVyjPodo90Hl2TOfG335sf70 elDQQQFHeU5TmRNNEa7cLvZbJCIuJWrwsyTEl7ic/XGCx4hcyYgxa3HW+cAiZUhs6Jms WI9dOVCkzE03TW+nEqwt46/R1TUl2q8Agxy51YE5DP8nSd8BDne8AO6+/7jJYqehDvD3 29A+s2wYHHlTwHcw+GIpB6NzgKqzhH+5TAobM1G1vbKNw0DvFq8PXiinjejBqbsZwE2O BLP5+iSQ7yn6claqSGaNmbPzmcb/1UaPk072+byK0Ry3Eyce+TXCAHISdWQ/gmnXhbaT ntLQ== X-Gm-Message-State: APf1xPCoP0gSTbYExPY65WGV9qyL/3+3A7r4RWAxB/XJekhkzryCL1FR F+e6aQq4ZSYRsvQQEVQAhPVVousz2yPeqvTgAVXYYw== X-Google-Smtp-Source: AH8x225cUU8To940ORMm0zGcnd5/fsuEvfPkAr7yjWvBVMvclF3nWLaS21B1V9icRLIVpJcQ5oEy3Eew0UGcK9jekcY= X-Received: by 10.37.104.13 with SMTP id d13mr512504ybc.290.1518643998004; Wed, 14 Feb 2018 13:33:18 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:9012:0:0:0:0:0 with HTTP; Wed, 14 Feb 2018 13:33:17 -0800 (PST) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> From: Jana Iyengar Date: Wed, 14 Feb 2018 13:33:17 -0800 Message-ID: Subject: Re: Multipath Milestones To: Ian Swett Cc: "Eggert, Lars" , Lucas Pardue , QUIC WG Content-Type: multipart/alternative; boundary="f403045c00200b5360056532dc90" 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, 14 Feb 2018 21:33:21 -0000 --f403045c00200b5360056532dc90 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I agree with Lars and Ian, and I presume this was left out inadvertently. Lars: maybe the chairs could come up with a "fix" to the milestones and do a consensus call? On Wed, Feb 14, 2018 at 11:22 AM, Ian Swett wrote: > Lars, that was my interpretation as well. > > I think the right path forward is for those particularly interested in > multipath to experiment with QUIC extensions inside v1, once the extensio= n > mechanism is defined. Once some experimentation has happened, we'll be i= n > a better place to have an informed discussion about some of the points > Christian raised in his multipath requirements draft: > https://tools.ietf.org/html/draft-huitema-quic-mpath-req-01 > > The recent text being added about Connection Migration should lay some of > the groundwork for adding second paths. https://github.com/quic > wg/base-drafts/pull/1012 > > On Wed, Feb 14, 2018 at 2:14 PM, Eggert, Lars wrote: > >> Hi, >> >> On 2018-2-14, at 15:49, Lucas Pardue wrote: >> >> This might be a bit pedantic but when the milestones were adjusted back >> in December, the Multipath extension milestones were left as originally >> stated (Nov =E2=80=9917, May =E2=80=9919). >> >> Is there any intention to modify these? The Nov =E2=80=9917 adoption has >> obviously been missed and I=E2=80=99m wondering what I would tell someon= e less >> familiar with the WG when they hypothetically asks me what that means. >> >> >> yes, we need to update those milestones. >> >> I can't recall that we explicitly discussed this when we discussed >> pushing the base-drafts milestones back. But to me personally, the decis= ion >> to focus all efforts on v1 - and multipath not being part of v1 - >> implicitly meant that we'd not really start any real effort before the >> base-drafts are shipped off to the IESG. In other words, WG adoption wou= ld >> probably not happen before Nov 2018, and completion sometime in 2019 (?)= . >> >> As I said, this is my personal interpretation - it would be good to know >> if this is the WG consensus. >> >> Lars >> > > --f403045c00200b5360056532dc90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Lars and Ian, and I presume this was left out= inadvertently.

Lars: maybe the chairs could come up wit= h a "fix" to the milestones and do a consensus call?
<= div class=3D"gmail_extra">
On Wed, Feb 14, 20= 18 at 11:22 AM, Ian Swett <ianswett@google.com> wrote:
=
Lars, that was my interpret= ation as well.

I think the right path forward is for tho= se particularly interested in multipath to experiment with QUIC extensions = inside v1, once the extension mechanism is defined.=C2=A0 Once some experim= entation has happened, we'll be in a better place to have an informed d= iscussion about some of the points Christian raised in his multipath requir= ements draft:=C2=A0https://tools.ietf.org/html/draft-hu= itema-quic-mpath-req-01

The recent text b= eing added about Connection Migration should lay some of the groundwork for= adding second paths.=C2=A0https://github.com/quicwg/base-drafts/pu= ll/1012

On Wed, Feb 14, 2018 at 2:14 PM, Eggert, Lars <lars@n= etapp.com> wrote:
Hi,

=
On 2018-2-14, at 15:49, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:<= br>
This might be a bit pedantic but when the milestones w= ere adjusted back in December, the Multipath extension milestones were left= as originally stated (Nov =E2=80=9917, May =E2=80=9919).
=C2=A0
Is there any intention to modify these? The Nov =E2=80=9917 a= doption has obviously been missed and I=E2=80=99m wondering what I would te= ll someone less familiar with the WG when they hypothetically asks me what = that means.

yes, = we need to update those milestones.

I can't re= call that we explicitly discussed this when we discussed pushing the base-d= rafts milestones back. But to me personally, the decision to focus all effo= rts on v1 - and multipath not being part of v1 - implicitly meant that we&#= 39;d not really start any real effort before the base-drafts are shipped of= f to the IESG. In other words, WG adoption would probably not happen before= Nov 2018, and completion sometime in 2019 (?).

As= I said, this is my personal interpretation - it would be good to know if t= his is the WG consensus.

Lars
<= /font>


--f403045c00200b5360056532dc90-- From nobody Wed Feb 14 13:42:48 2018 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 F266B126CD8 for ; Wed, 14 Feb 2018 13:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 Gr8OumXYylXo for ; Wed, 14 Feb 2018 13:42:45 -0800 (PST) Received: from mailout1.cwwtf.bbc.co.uk (mailout1.cwwtf.bbc.co.uk [132.185.160.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB6C12426E for ; Wed, 14 Feb 2018 13:42:44 -0800 (PST) Received: from BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) by mailout1.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w1ELggj0027711; Wed, 14 Feb 2018 21:42:42 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1006.national.core.bbc.co.uk ([10.184.50.56]) with mapi id 14.03.0361.001; Wed, 14 Feb 2018 21:42:42 +0000 From: Lucas Pardue To: Ian Swett CC: "Eggert, Lars" , QUIC WG Subject: RE: Multipath Milestones Thread-Topic: Multipath Milestones Thread-Index: AdOlot2vk/mcXyftQ+aZnFxr8GlL1QAJSPAAAABGCQAABJTfgAAAK9VB Date: Wed, 14 Feb 2018 21:42:41 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0D46@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.213] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.200.1013-23664.002 x-tm-as-result: No--28.158500-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="Windows-1252" 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, 14 Feb 2018 21:42:47 -0000 Yes I think Ian summarised things well. >From my own perspective, changing milestone dates to , etc would give a more honest reflection of current status= . Not sure if the datatracker allows such a thing. Regards Lucas ________________________________________ From: Jana Iyengar [jri@google.com] Sent: 14 February 2018 21:33 To: Ian Swett Cc: Eggert, Lars; Lucas Pardue; QUIC WG Subject: Re: Multipath Milestones I agree with Lars and Ian, and I presume this was left out inadvertently. Lars: maybe the chairs could come up with a "fix" to the milestones and do = a consensus call? On Wed, Feb 14, 2018 at 11:22 AM, Ian Swett > wrote: Lars, that was my interpretation as well. I think the right path forward is for those particularly interested in mult= ipath to experiment with QUIC extensions inside v1, once the extension mech= anism is defined. Once some experimentation has happened, we'll be in a be= tter place to have an informed discussion about some of the points Christia= n raised in his multipath requirements draft: https://tools.ietf.org/html/d= raft-huitema-quic-mpath-req-01 The recent text being added about Connection Migration should lay some of t= he groundwork for adding second paths. https://github.com/quicwg/base-draft= s/pull/1012 On Wed, Feb 14, 2018 at 2:14 PM, Eggert, Lars > wrote: Hi, On 2018-2-14, at 15:49, Lucas Pardue > wrote: This might be a bit pedantic but when the milestones were adjusted back in = December, the Multipath extension milestones were left as originally stated= (Nov =9217, May =9219). Is there any intention to modify these? The Nov =9217 adoption has obviousl= y been missed and I=92m wondering what I would tell someone less familiar w= ith the WG when they hypothetically asks me what that means. yes, we need to update those milestones. I can't recall that we explicitly discussed this when we discussed pushing = the base-drafts milestones back. But to me personally, the decision to focu= s all efforts on v1 - and multipath not being part of v1 - implicitly meant= that we'd not really start any real effort before the base-drafts are ship= ped off to the IESG. In other words, WG adoption would probably not happen = before Nov 2018, and completion sometime in 2019 (?). As I said, this is my personal interpretation - it would be good to know if= this is the WG consensus. Lars ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From nobody Wed Feb 14 16:37:11 2018 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 5D87D127735 for ; Wed, 14 Feb 2018 16:37:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 3X_KD12ssJ_R for ; Wed, 14 Feb 2018 16:37:07 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB68012711A for ; Wed, 14 Feb 2018 16:37:07 -0800 (PST) Received: from mail.amsl.com (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTPS id 2C8F11CAE4A for ; Wed, 14 Feb 2018 16:36:36 -0800 (PST) Received: from mail-it0-f52.google.com (mail-it0-f52.google.com [209.85.214.52]) by c8a.amsl.com (Postfix) with ESMTPSA id 0AD421CAE3D for ; Wed, 14 Feb 2018 16:36:36 -0800 (PST) Received: by mail-it0-f52.google.com with SMTP id 140so8013394iti.0 for ; Wed, 14 Feb 2018 16:37:07 -0800 (PST) X-Gm-Message-State: APf1xPAbviZHZcZgLZ5xoxvcFBdSPzFtRIIjB87mJZ5+v/cgjzqgqhel 9oI5e1kJX/OEJTM4vcduFV47vQNIeuHWNP7zOr8= X-Google-Smtp-Source: AH8x2255IFbDCZgZ1xzTg/S6PmAIMLp6TTFiEOGXWYb2+hAdKgv4ZhtDJmUm60vxiZZUWOOltlZkbKsrmD+3tWk7IW4= X-Received: by 10.36.132.76 with SMTP id h73mr1175453itd.110.1518655027210; Wed, 14 Feb 2018 16:37:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.2.1.68 with HTTP; Wed, 14 Feb 2018 16:36:46 -0800 (PST) From: Glen Date: Wed, 14 Feb 2018 16:36:46 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Possible missed messages on this list To: quic@ietf.org Content-Type: multipart/alternative; boundary="001a113b93086f11d90565356d26" 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, 15 Feb 2018 00:37:09 -0000 --001a113b93086f11d90565356d26 Content-Type: text/plain; charset="UTF-8" Possible missed messages on this list Dear list participants - An upgrade to the IETF's custom mail processing software today resulted in some delivery failures for *some* messages to *some* recipients on this list, over the past 3 hours. We invite you to check the mail archives for this list, at: https://mailarchive.ietf.org/arch/search/?email_list=quic to ensure that you have received all the relevant messages for this list today. We apologize for the inconvenience. Glen -- Glen Barney IT Director AMS (IETF Secretariat) --001a113b93086f11d90565356d26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Possible missed messages on this list

Dear list participants -
An upgrade to the IETF's custom mail processing software today resulted i= n some delivery failures for *some* messages to *some* recipients on this list, over the past 3 hours.

We invite you to check the mail archiv= es for this list, at:

https://mailarchive.ietf.org/arch/search/?email_l= ist=3Dquic

to ensure that you have received all the relevant mes= sages for this list today.

We apologize for the inconvenience.
Glen
--
Glen Barney
IT Director
AMS (IETF Secretariat)

--001a113b93086f11d90565356d26-- From nobody Thu Feb 15 00:08:51 2018 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 E0646124B17 for ; Thu, 15 Feb 2018 00:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EQy7pOsYbGqA for ; Thu, 15 Feb 2018 00:08:47 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E49C124B18 for ; Thu, 15 Feb 2018 00:08:47 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,516,1511856000"; d="asc'?scan'208,217";a="256149620" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx141-out.netapp.com with ESMTP; 15 Feb 2018 00:08:46 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 15 Feb 2018 00:08:46 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Thu, 15 Feb 2018 00:08:46 -0800 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=8i4ICHl2J/uB+KiaFVkh78DQBKyqdOQ/9EKb57+y/s4=; b=kS15QrKdrCUaWEHnAidi7kJ1Pz3826/vVHehieY3PYZvNqJ0crjqE/kgxCxWDOy6Z2E9Brm7I2OeBqn9ENMVjaS8smLlh2Qk3lfYuyn1tG/M3vMNNFtT3XZ1pcxfV8QzHCNiAQ9sHP2WHr5lcj8cLQSX/Yym61xQmr/kWMVZZF4= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB595.namprd06.prod.outlook.com (10.141.206.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Thu, 15 Feb 2018 08:08:42 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004%14]) with mapi id 15.20.0506.019; Thu, 15 Feb 2018 08:08:42 +0000 From: "Eggert, Lars" To: Lucas Pardue CC: Ian Swett , QUIC WG Subject: Re: Multipath Milestones Thread-Topic: Multipath Milestones Thread-Index: AdOlot2vk/mcXyftQ+aZnFxr8GlL1QAJSPAAAABGCQAABJTfgAAAK9VBABYFFoA= Date: Thu, 15 Feb 2018 08:08:42 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A3BAE0D46@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0D46@bgb01xud1012> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB595; 7:jGJJOdHuSIETqE3DU38J0o/BqWZgNh5C0a5147SuhgMI5WFZ/1D/fUcYm6LRErWhsn8L8RDoTZkK147cgWv/IX6l+vbkP0ZLERizeFD4/oTVg7Dczw5hIFUltkBrC7Tj00ru3rdMM2EFxbyWwyrLXZ36lU55gfJLDtNTOLgM0+UA3EFjix22HD1p3VE3GYhavm3drWIvDS7LwMFcS6gS/SXNc/oSblB8SKgDmHEcsZ41JCgFFv4HDmCuSB9AQ4X9 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 13d8be78-f0cb-4de0-c02c-08d5744b53ec x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB595; x-ms-traffictypediagnostic: BLUPR06MB595: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(127952516941037); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(3231101)(944501161)(6055026)(6041288)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BLUPR06MB595; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB595; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(376002)(39380400002)(39860400002)(199004)(189003)(377424004)(45074003)(3280700002)(6506007)(99936001)(186003)(59450400001)(53546011)(102836004)(26005)(68736007)(7736002)(83716003)(86362001)(2900100001)(2906002)(4001150100001)(3660700001)(6116002)(3846002)(97736004)(5250100002)(2950100002)(105586002)(229853002)(6916009)(25786009)(33656002)(14454004)(82746002)(106356001)(4326008)(66066001)(478600001)(53936002)(221733001)(6246003)(93886005)(236005)(54906003)(81166006)(57306001)(99286004)(6512007)(6436002)(5660300001)(81156014)(3480700004)(76176011)(8676002)(8936002)(7116003)(54896002)(50226002)(36756003)(6486002)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB595; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: lzVgbk74xeMHHv+zt7tkvWLpvufhwvx52sv+csDAMt0V0tPixVyklKLKctYGUGG8SisBeat9NmyToTcjUBFqIQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_E125B246-AAB8-4A41-B055-21477BD72332"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 13d8be78-f0cb-4de0-c02c-08d5744b53ec X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2018 08:08:42.1718 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB595 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, 15 Feb 2018 08:08:50 -0000 --Apple-Mail=_E125B246-AAB8-4A41-B055-21477BD72332 Content-Type: multipart/alternative; boundary="Apple-Mail=_A36623A4-1ED4-4423-A66C-EAEE88FA9C90" --Apple-Mail=_A36623A4-1ED4-4423-A66C-EAEE88FA9C90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2018-2-14, at 22:42, Lucas Pardue wrote: > =46rom my own perspective, changing milestone dates to , = etc would give a more honest reflection = of current status. Not sure if the datatracker allows such a thing. Unfortunately, it doesn't. It needs a date, I can delete a milestone, or = mark as completed. My suggestion would be to move the "adoption" milestone to Nov 2018, and = the completion milestone to July 2019. Do people think we can ship v2 by = then? Lars --Apple-Mail=_A36623A4-1ED4-4423-A66C-EAEE88FA9C90 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 2018-2-14, at 22:42, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
=46rom my own perspective, changing = milestone dates to <TBD>, <suspended until further notice> = etc would give a more honest reflection of current status. Not sure if = the datatracker allows such a thing.

Unfortunately, it doesn't. It needs a date, I can delete a = milestone, or mark as completed.

My suggestion would be to move the = "adoption" milestone to Nov 2018, and the completion milestone to July = 2019. Do people think we can ship v2 by then?

Lars
= --Apple-Mail=_A36623A4-1ED4-4423-A66C-EAEE88FA9C90-- --Apple-Mail=_E125B246-AAB8-4A41-B055-21477BD72332 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlqFQAkACgkQVLXDCb9w wVds/RAAvAil8Vg9exoMPj5Xiw7jLAbaoeeHhOhTc2rOml/vzzM+5mMoQ1fPLdzJ IttyV+iouGHZueWxlppu/Yw3SX7NHpE2sgUXvTBabng4/WuqrNw52DSHps2i2Mdz 8umddZZxMDZ++q/Mkg1uMmRTfE3epiTDn8grX8MaTSqT1Si28Y9VUd53+i1IIndk clODfOwc5pXch6Tbnl8JJ+6zZEAPTkmOutJbB3wwLj519DNhJw5gDEb+lVGSmdzG v6qrPr6mFGGnH6HUePW57qwJCCJQRQyoJXnyuq2WiFUBNVvkpaxxIvgmHC8Z57dh Bk4cicJDwEoMX61Yc2t+nY/4c4YrK1jv70UHYfgwFSqJQTP+TXKKlAGFIyFnulwt bJyHAPrxV3ywATcRZ8cnqGpUd5LWj9T11i3yUukFz+KzWgr0kO8gKuALY9BeTfKT ZxTYb0ys5FK9H53737gUpERE8X0EKFn4N/5CHnACON8dWyIenuwTcTfktdf075yi uOVJU4Kz4udPCnB0uBPRRSiM9t39TBkE/7i/BYI/cIHCnNVo3dheMbx5ZlADTB21 9W+Qdpe/g7pK+gYjBCVgAHITjIwyngecBkiV1Zny4SFYZvWtQo+3mP9cDxZErYP3 Zu4FnDnrv7+Opuw3edaUVWYs4gfMg0qtjjTWZLQNJrKg22YdBIc= =9U65 -----END PGP SIGNATURE----- --Apple-Mail=_E125B246-AAB8-4A41-B055-21477BD72332-- From nobody Thu Feb 15 16:44:14 2018 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 BA911126C22 for ; Thu, 15 Feb 2018 16:44:12 -0800 (PST) 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, 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=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 CAn6leSSyhhm for ; Thu, 15 Feb 2018 16:44:11 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::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 E5D89124235 for ; Thu, 15 Feb 2018 16:44:10 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id h74so375075wme.5 for ; Thu, 15 Feb 2018 16:44:10 -0800 (PST) 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=9zJ/vxDv5kOdRE3Rfr586w5EKJcPvyfIh22uBFWuiLc=; b=ofcMvp0pFjSxg/HlYH7NGxKPyLVBzbUddSjsWri+QBYtYREvf/la0FjtT0BsgKjBA+ 0bn1CmdHF+kQYmjeL/qyAzM0orHLtBFBaJtynn24lTzEtiKRvT5TqvJwBZ+KS5sPAdGD XO2KWhqFmGK/j9qW/UyqhMtQRYqEWyeGpqI/m0YEnzegALYiq+eqGsszZgXubXSkDu77 EuVtTN7VyQdRcAteyuqcT7t6+32ylPvpsjfHuIdYgD5Mlh+DwEPvKJdIrMH9axm/z6p8 IVgZ8jrEvBtWqa8siF4mY6cBb/qmvNDWgorDB6pYdCKNVqrKl63yuybhKoYT3fPpbd5o Jxog== 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=9zJ/vxDv5kOdRE3Rfr586w5EKJcPvyfIh22uBFWuiLc=; b=q5D/8+526REdvLhlsNCAOh2P56Mcv5nRLDcL99vkxIBkqzuN2tuFNEbkjNXLJhdGvx nBfevRYUO7uaq/D7792f8/eGzDUS3jzff3zsAqXfgIWuaw+PAOoFq28y+6iRwtCcRrpU HRL2dXdHyF2rShtlZxEDuCJQroewn/i3jRi/mEXHCYOvHWlGKQWux7ejKAL3NNdjileo 5YY7kx0ZG4Zd+c5K9nKBH3UR3ZAbQwG+5b8QMVA384OgBKKoCsC3WXomlgjoGL5/epB/ yythe4yQMhjDyOy+FtIsmE0p2zx/a7PREFi4Ms1mise9rHgSJ7vvYFmaS70hYajJBJTH uQCA== X-Gm-Message-State: APf1xPDdVQgj/zHEwgzYvFeCh2iDFGMCv64YHDT/Ufq1dB52OmNXeJSI KdgtkZS7QOrU8URXZ/jB9MFnBWajlKm7lbPkib0= X-Google-Smtp-Source: AH8x226Es4gJwG6O6yZlXKGRKPGW+a7vd4QpCzgBbB19IOCPBopeuFFkIuVAxX01mQNQCoUr/gABHRukjLMVwBXRmks= X-Received: by 10.28.124.8 with SMTP id x8mr263850wmc.147.1518741849478; Thu, 15 Feb 2018 16:44:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.195.139 with HTTP; Thu, 15 Feb 2018 16:44:09 -0800 (PST) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A3BAE0D46@bgb01xud1012> From: Jana Iyengar Date: Thu, 15 Feb 2018 16:44:09 -0800 Message-ID: Subject: Re: Multipath Milestones To: "Eggert, Lars" Cc: Lucas Pardue , Ian Swett , QUIC WG Content-Type: multipart/alternative; boundary="089e082d00f87199f3056549a4f5" 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, 16 Feb 2018 00:44:13 -0000 --089e082d00f87199f3056549a4f5 Content-Type: text/plain; charset="UTF-8" Depends on what v2 is. I'd like to ship some v2 by then, but that may not include multipath... that's a conversation we need to have with more details about strategy and so on. This is perhaps a can of worms to open in London? As I remember it, multipath was on the charter because we wanted to signal that we were going to work on it, just not yet. If we are agreed on doing it after v1, I wonder if it makes most sense now to simply remove it from the charter and re-litigate it when we create a charter for post-v1 work. On Thu, Feb 15, 2018 at 12:08 AM, Eggert, Lars wrote: > On 2018-2-14, at 22:42, Lucas Pardue wrote: > > From my own perspective, changing milestone dates to , until further notice> etc would give a more honest reflection of current > status. Not sure if the datatracker allows such a thing. > > > Unfortunately, it doesn't. It needs a date, I can delete a milestone, or > mark as completed. > > My suggestion would be to move the "adoption" milestone to Nov 2018, and > the completion milestone to July 2019. Do people think we can ship v2 by > then? > > Lars > --089e082d00f87199f3056549a4f5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Depends on what v2 is. I'd like to ship some v2 by the= n, but that may not include multipath... that's a conversation we need = to have with more details about strategy and so on. This is perhaps a can o= f worms to open in London?

As I remember it, multipath w= as on the charter because we wanted to signal that we were going to work on= it, just not yet. If we are agreed on doing it after v1, I wonder if it ma= kes most sense now to simply remove it from the charter and re-litigate it = when we create a charter for post-v1 work.=C2=A0

On Thu, Feb 15, 2018 at 12:08 AM= , Eggert, Lars <lars@netapp.com> wrote:
On 2018-2-14, at 22:42, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
From m= y own perspective, changing milestone dates to <TBD>, <suspended u= ntil further notice> etc would give a more honest reflection of current = status. Not sure if the datatracker allows such a thing.

Unfortunately, it doesn't. It needs a date, I = can delete a milestone, or mark as completed.

My s= uggestion would be to move the "adoption" milestone to Nov 2018, = and the completion milestone to July 2019. Do people think we can ship v2 b= y then?

=
Lars

--089e082d00f87199f3056549a4f5-- From nobody Thu Feb 15 16:50:30 2018 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 BD0D4124235 for ; Thu, 15 Feb 2018 16:50:28 -0800 (PST) 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 ca42_Ht7QDFS for ; Thu, 15 Feb 2018 16:50:27 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 DFE381201FA for ; Thu, 15 Feb 2018 16:50:26 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id y4so1075389oix.2 for ; Thu, 15 Feb 2018 16:50:26 -0800 (PST) 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=G7PW3fRyQS0E6nVe//CczouEA76RKXpb79baupF3Lq0=; b=gA5PvuZOxHtG51Fac7NiZ+hUaZpZA4ji/dNsi3ouRXDyXM2Kv3PKBP2Nm2ekqJyC4/ XSQ4Mlow5Z7o7xIOzwI8DT51k8t7d4WYYuan6OkCXXQA05Kp+beAJWBCoqyXODAcxfsd GHVkCStZb8eKdAVnNxqSCF+MVJeuLe70gnRgs6A7pzKW6lSIdOK2fpcAiy6d+nIDTmsA u0pwV4YIE13XiOxNnG85WARnMIVDNLXElTOIwKW6V+r2oXTuAitQhNy8MM9p7pqwdSmY JSECUaybm/lm5Dxu6zMzBby1Mf0uJ5/M6tBC7kEm4O7XN3zhC//yNGN7gbbbQvMGrpKL FWVQ== 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=G7PW3fRyQS0E6nVe//CczouEA76RKXpb79baupF3Lq0=; b=d0rCMMUEx+QO8OEE4Kz3wvFeaZ+CrKxZyCV4ofhem09yT6ztuojIb8o6PgGdCGt8ZB elfmZoNo286yg+ZDHUXSzQsgMDwtzYVG1RRPdJN6zXvFC1CCgS0/hpn2jkoqG1cWm4+D YAnAUl1SvXYqNB4JbdUq2H8V/pXBen1g5R4kccM24RRWG7j3zkQVEegGVDkhpJgS4O8G iC8e8tdMNtgD4QFLC+9qsiBIDeb4I3SgiYqQifjGanftMs9L+5zjLQ+fsjo0KnWMWJOC 3aIYFaSIl4ba8V5aBvkAS0pvyLBhD3vx7SkmpEeMiBMHNbZUNwmQ7ckI069GJVn/HHkI 4+pw== X-Gm-Message-State: APf1xPDpR+/KYBpv4zjWBYB2mC+A1/JymJOGoon1niTVX54AciJKNxmM sAC7p0WndcjDzCf5oQFyWfEKQ45QXowJcB/MA3E= X-Google-Smtp-Source: AH8x226d3Zv+3CbzybUttf3glimTF1ksnbZ+R56UAIeYZaZJAzrolRRygZxvVtk0F4I/28Tubl3/A7MTaUVwKKEDwMo= X-Received: by 10.202.3.139 with SMTP id 133mr3249742oid.313.1518742226016; Thu, 15 Feb 2018 16:50:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Thu, 15 Feb 2018 16:50:25 -0800 (PST) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A3BAE0D46@bgb01xud1012> From: Martin Thomson Date: Fri, 16 Feb 2018 11:50:25 +1100 Message-ID: Subject: Re: Multipath Milestones To: Jana Iyengar Cc: "Eggert, Lars" , Lucas Pardue , Ian Swett , 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, 16 Feb 2018 00:50:29 -0000 I don't have a lot of interest in spending too much time on procedural issues. An unrealistic milestone is only a problem if you think that it is. I'm more interested in executing on the plan (shipping). Let's talk about v2 when it is time to work on v2. I'm aware that this might be very soon after v1, but I think that talking v2 in London might be a little premature. On Fri, Feb 16, 2018 at 11:44 AM, Jana Iyengar wrote: > Depends on what v2 is. I'd like to ship some v2 by then, but that may not > include multipath... that's a conversation we need to have with more details > about strategy and so on. This is perhaps a can of worms to open in London? > > As I remember it, multipath was on the charter because we wanted to signal > that we were going to work on it, just not yet. If we are agreed on doing it > after v1, I wonder if it makes most sense now to simply remove it from the > charter and re-litigate it when we create a charter for post-v1 work. > > On Thu, Feb 15, 2018 at 12:08 AM, Eggert, Lars wrote: >> >> On 2018-2-14, at 22:42, Lucas Pardue wrote: >> >> From my own perspective, changing milestone dates to , > until further notice> etc would give a more honest reflection of current >> status. Not sure if the datatracker allows such a thing. >> >> >> Unfortunately, it doesn't. It needs a date, I can delete a milestone, or >> mark as completed. >> >> My suggestion would be to move the "adoption" milestone to Nov 2018, and >> the completion milestone to July 2019. Do people think we can ship v2 by >> then? >> >> Lars > > From nobody Thu Feb 15 16:53:18 2018 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 660AD1201FA for ; Thu, 15 Feb 2018 16:53:17 -0800 (PST) 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, 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=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 0bVcNIKu5KvN for ; Thu, 15 Feb 2018 16:53:15 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 20559126C22 for ; Thu, 15 Feb 2018 16:53:15 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id b21so397680wme.4 for ; Thu, 15 Feb 2018 16:53:15 -0800 (PST) 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=nOPgcZqlAei0I3Mm8SGPH3nM8mOOUPqKStXry2jRt44=; b=hp3IsC8Xw6Ncko9UaIAI4CxGRYePtXObsGQQMM1+nQlj0wdCNEH892eIwyuk/8DOwJ L45BmUGguLcAv3hNWA1Q+j219sqA3GWwA0YuqfCYmp58naYDNV7YYCWT63ApvTiUipzl MdqhdT2cJLPTN//p5mHMPzC2EKjDwSbtpy3X3t+biELb58UtYozcIUNdaANMtDg6rYqa 30ir5OkjkuxZBpOp+oB6t0wdTrfx9ApGXHoTw4X4mVMvL7uvxbvufdknb0DW/HlCCy/T XgIMLhGklqQ+O3zlSBKswSMp9qK+SsiqTC4kYHYLeAKE+vpr1bk+ycaQvZMvY16z3YTJ 5hcw== 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=nOPgcZqlAei0I3Mm8SGPH3nM8mOOUPqKStXry2jRt44=; b=A4MFDqFEU+Y7/uPMVRBQvDPZAOwHg5cMVWwHXn5ivOYuv/M/dN3CVN2vzUHpRbdSdV pwTdTv2VPM5jMLuydBXmMikTJSUN93+gLIqJdDaUK4azsPh4GrOqy6o0JINIZIRhd7Ek rxbpqeBoiF0rYNE1GBljD/hba+5fLQjkGwh1bgqXlkoytvzPz8IZZ0rGHv9jkZwcShUR 3B2JKIH3KAnvSfXnLApjITO9piebLkU/g+xVp6gQ16KTjyKNBDdCHwj6SyHT4KQit2xo ZN9hBi6kbnqh42gUd8ll+TxpZ0xbOAYercQTRGzggq8m2jPfCvxfb18/ruM8HBa/klAZ 4Oqw== X-Gm-Message-State: APf1xPBFcrni1ijjatnj50ViQikPPQZijWRmnNhvHWVRBrYdBK7UOres k9PEp5jMdheTAMkGUZFdzTUyB23KMVZ6ptQfJixbBQ== X-Google-Smtp-Source: AH8x224TndbfYU0HSAtAa/7O/n2hcq+BqiOYNXUzyxXDxiw9fC5sN1HhqaCfYohU7mFUt9oThSdqWJRCUvOPrw1Yj3M= X-Received: by 10.28.124.8 with SMTP id x8mr273062wmc.147.1518742393685; Thu, 15 Feb 2018 16:53:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.195.139 with HTTP; Thu, 15 Feb 2018 16:53:13 -0800 (PST) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A3BAE0D46@bgb01xud1012> From: Jana Iyengar Date: Thu, 15 Feb 2018 16:53:13 -0800 Message-ID: Subject: Re: Multipath Milestones To: Martin Thomson Cc: "Eggert, Lars" , Lucas Pardue , Ian Swett , QUIC WG Content-Type: multipart/alternative; boundary="089e082d00f8e18d5b056549c493" 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, 16 Feb 2018 00:53:17 -0000 --089e082d00f8e18d5b056549c493 Content-Type: text/plain; charset="UTF-8" I agree with all that, except multipath is > v1, and it is on the list of milestones. I'd be in favor of removing it entirely from the list of milestones. On Thu, Feb 15, 2018 at 4:50 PM, Martin Thomson wrote: > I don't have a lot of interest in spending too much time on procedural > issues. An unrealistic milestone is only a problem if you think that > it is. I'm more interested in executing on the plan (shipping). > > Let's talk about v2 when it is time to work on v2. I'm aware that > this might be very soon after v1, but I think that talking v2 in > London might be a little premature. > > On Fri, Feb 16, 2018 at 11:44 AM, Jana Iyengar wrote: > > Depends on what v2 is. I'd like to ship some v2 by then, but that may not > > include multipath... that's a conversation we need to have with more > details > > about strategy and so on. This is perhaps a can of worms to open in > London? > > > > As I remember it, multipath was on the charter because we wanted to > signal > > that we were going to work on it, just not yet. If we are agreed on > doing it > > after v1, I wonder if it makes most sense now to simply remove it from > the > > charter and re-litigate it when we create a charter for post-v1 work. > > > > On Thu, Feb 15, 2018 at 12:08 AM, Eggert, Lars wrote: > >> > >> On 2018-2-14, at 22:42, Lucas Pardue wrote: > >> > >> From my own perspective, changing milestone dates to , >> until further notice> etc would give a more honest reflection of current > >> status. Not sure if the datatracker allows such a thing. > >> > >> > >> Unfortunately, it doesn't. It needs a date, I can delete a milestone, or > >> mark as completed. > >> > >> My suggestion would be to move the "adoption" milestone to Nov 2018, and > >> the completion milestone to July 2019. Do people think we can ship v2 by > >> then? > >> > >> Lars > > > > > --089e082d00f8e18d5b056549c493 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with all that, except multipath is > v1, and it= is on the list of milestones. I'd be in favor of removing it entirely = from the list of milestones.

On Thu, Feb 15, 2018 at 4:50 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I don't have a lot of interest in spending too much time on proce= dural
issues.=C2=A0 An unrealistic milestone is only a problem if you think that<= br> it is.=C2=A0 I'm more interested in executing on the plan (shipping).
Let's talk about v2 when it is time to work on v2.=C2=A0 I'm aware = that
this might be very soon after v1, but I think that talking v2 in
London might be a little premature.

On Fri, Feb 16, 2018 at 11:44 AM, Jana Iyengar <jri.ietf@gmail.com> wrote:
> Depends on what v2 is. I'd like to ship some v2 by then, but that = may not
> include multipath... that's a conversation we need to have with mo= re details
> about strategy and so on. This is perhaps a can of worms to open in Lo= ndon?
>
> As I remember it, multipath was on the charter because we wanted to si= gnal
> that we were going to work on it, just not yet. If we are agreed on do= ing it
> after v1, I wonder if it makes most sense now to simply remove it from= the
> charter and re-litigate it when we create a charter for post-v1 work.<= br> >
> On Thu, Feb 15, 2018 at 12:08 AM, Eggert, Lars <lars@netapp.com> wrote:
>>
>> On 2018-2-14, at 22:42, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
>>
>> From my own perspective, changing milestone dates to <TBD>, = <suspended
>> until further notice> etc would give a more honest reflection o= f current
>> status. Not sure if the datatracker allows such a thing.
>>
>>
>> Unfortunately, it doesn't. It needs a date, I can delete a mil= estone, or
>> mark as completed.
>>
>> My suggestion would be to move the "adoption" milestone = to Nov 2018, and
>> the completion milestone to July 2019. Do people think we can ship= v2 by
>> then?
>>
>> Lars
>
>

--089e082d00f8e18d5b056549c493-- From nobody Fri Feb 16 05:11:13 2018 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 77C5D127337 for ; Fri, 16 Feb 2018 05:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 bVlqr1Wf-KiX for ; Fri, 16 Feb 2018 05:11:09 -0800 (PST) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E089127286 for ; Fri, 16 Feb 2018 05:11:09 -0800 (PST) Received: from [130.104.228.12] (1o0-328.dhcp.info.ucl.ac.be [130.104.228.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: qdeconinck@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 1E84667DAC2; Fri, 16 Feb 2018 14:10:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1518786659; bh=iLyR+byp7dY4EYL0hjIrPXgpqiWuR+rchUsD3AlcCK8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=FqHRCAree8XtO10/f56BiaBneJCJKo2cch5Z729Sxcgu2onGBm4PY4azkRGJRZTE6 0yUIHhoKL3vhWRc803lHKCG7u3SiKh9Qb/F+V192SpnB8uty/m8A9D1pznqqDS+mN8 9kX1WkZrsursgtOXSCy5FAKjG8/RiEWnQ5uTBb50= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.3-beta2 at smtp-4.sipr-dc.ucl.ac.be Subject: Re: Multipath Milestones To: Ian Swett , "Eggert, Lars" Cc: Lucas Pardue , QUIC WG References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> From: Quentin De Coninck Message-ID: Date: Fri, 16 Feb 2018 14:10:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CBB83CD749352F532172DA6C" Content-Language: en-US X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 1E84667DAC2.A2D05 X-SGSI-MailScanner: Found to be clean X-SGSI-From: quentin.deconinck@uclouvain.be X-SGSI-Spam-Status: No 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, 16 Feb 2018 13:11:12 -0000 This is a multi-part message in MIME format. --------------CBB83CD749352F532172DA6C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello, Le 14/02/18 à 20:22, Ian Swett a écrit : > I think the right path forward is for those particularly interested in > multipath to experiment with QUIC extensions inside v1, once the > extension mechanism is defined.  Once some experimentation has > happened, we'll be in a better place to have an informed discussion > about some of the points Christian raised in his multipath > requirements draft: > https://tools.ietf.org/html/draft-huitema-quic-mpath-req-01 > I totally agree that experimenting is key. That's why we implemented the multipath extensions that we proposed last year in https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/ This document has evolved and we'll release a new version before the London IETF to take into account various comments received. In parallel with that, we are finalizing an iOS application that uses multipath QUIC to evaluate how this works in the wild. This application will perform various measurements to analyze the benefits of multipath. If you have ideas, feel free to contact me offline. If there is interest, I might be able to report some results with multipath QUIC in the wild at the London IETF. Quentin --------------CBB83CD749352F532172DA6C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello,

Le 14/02/18 à 20:22, Ian Swett a écrit :
I think the right path forward is for those particularly interested in multipath to experiment with QUIC extensions inside v1, once the extension mechanism is defined.  Once some experimentation has happened, we'll be in a better place to have an informed discussion about some of the points Christian raised in his multipath requirements draft: https://tools.ietf.org/html/draft-huitema-quic-mpath-req-01

I totally agree that experimenting is key. That's why we implemented the multipath extensions that we proposed last year in https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/

This document has evolved and we'll release a new version before the London IETF to take into account various comments received. In parallel with that, we are finalizing an iOS application that uses multipath QUIC to evaluate how this works in the wild. This application will perform various measurements to analyze the benefits of multipath. If you have ideas, feel free to contact me offline. If there is interest, I might be able to report some results with multipath QUIC in the wild at the London IETF.

Quentin --------------CBB83CD749352F532172DA6C-- From nobody Fri Feb 16 05:30:20 2018 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 16E9C127023 for ; Fri, 16 Feb 2018 05:30:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 oly_U0f8_l_7 for ; Fri, 16 Feb 2018 05:30:16 -0800 (PST) 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 8E27F120047 for ; Fri, 16 Feb 2018 05:30:16 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id m11so4115196iob.2 for ; Fri, 16 Feb 2018 05:30:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=+bA5gd8xki+ddvFtAQOmQNOpMgeg3myQoyYMkCd1+z0=; b=XPHK5QDnqr9K5+iOvuQ31oRFIdGzKfkZZMpDGjyJt18dDPyJOPcCS3VKbNTVjoGurm rh6dIl1zTr8C+H5nkIlu3Z5+gPqaykEeLmkuGdgtt+xrfzwRXNQQ+33sdMFVp0z8ldnI Kgp11C29slBUlOd27H1IGCm6+xCKr6ZTSXyl0l3aboY1T1ctcqySWJ/guop6vYa7x2GZ bhBGycTFCmKy1rR33vbu9pGy6JkZYh6oZrBm1vzDxcUJ6QDYdRu30u0qdFBQsRSUImFi IrYD2u2swyY9efJ7/7Bi3P+y+a6aSb3mOniISHMOO3Z8aO+VF3CzfXeB2nFGgaeC82I5 w47g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=+bA5gd8xki+ddvFtAQOmQNOpMgeg3myQoyYMkCd1+z0=; b=DCSQKbkWSDgRFdlhJ5Gk4OgYm5hm7qN7vpqjd/mHRwSeWkuJ92qK6Zu/1YmPUSNP3t Cx9rM+DoR6wAir1+k87rKkXpAWQvnr1i7k+2WqmFSwmwP5trQ9emthr9JrRUFCSo2fGH x9y2250dBTYZ9OKXXXlGjwXxMD+KAnCz7QmSFnjCxtRvPLKxFAD1U4bEWhF96clIi2c6 K86Ue87jrXIJe27lJ6oXRPaFXle30rX5qaEtZxKwYxaVGpjnYNy0BTzzVihSLWM0D3dn 2mYQifzdmn1RSKlpZIyn1e6Rgim+zXZ9t0aqnY3d92qy7F+/YMe+qYm13krGHoG+ncR0 7SyA== X-Gm-Message-State: APf1xPCL+iLaOzwX74loewxABQuJpgLTSPZR4X1hpI/mAB2Bpx1xC9Cl qkfPdlPrFF4UqOxn73t3I5vOE++Ny9lSvqjAskE= X-Google-Smtp-Source: AH8x227mxvMUtN2nlPTcVa0a9OYWbgN2pSGOwZIYUvzxMhkmEOM3CI/uwFZzqgG+YRvntNAA7dK12C5q645xNWx4ZjE= X-Received: by 10.107.150.18 with SMTP id y18mr7903477iod.70.1518787815939; Fri, 16 Feb 2018 05:30:15 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 16 Feb 2018 13:30:15 +0000 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BAE0BEA@bgb01xud1012> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 16 Feb 2018 13:30:15 +0000 Message-ID: Subject: Re: Multipath Milestones To: "Eggert, Lars" , Quentin De Coninck , Ian Swett Cc: Lucas Pardue , QUIC WG Content-Type: multipart/alternative; boundary="001a114043bc422d620565545847" 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, 16 Feb 2018 13:30:19 -0000 --001a114043bc422d620565545847 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I briefly skimmed the multi path proposal and one thing that comes to mind is the limit of 256 paths. I think there could be much more than 256 paths and that path ID=E2=80=99s = could be varint encoded. A single address could have multiple paths over time, key migration could be tied to paths, although two paths may still share a key. Path swapping could potentially be used to protect against optimistic ACK attack. I wrote an issue on segmented packet numbers: https://github.com/quicwg/base-drafts/issues/1105 here the objective is to avoid the packet number encryption and to provide simpler per path loss management, but it overlaps with multi-path. I wonder how much the current design actually needs to change in order to support multi-path if using segmented packet numbers. There is already PATH_CHALLENGE. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 16 February 2018 at 14.11.17, Quentin De Coninck ( quentin.deconinck@uclouvain.be) wrote: Hello, Le 14/02/18 =C3=A0 20:22, Ian Swett a =C3=A9crit : I think the right path forward is for those particularly interested in multipath to experiment with QUIC extensions inside v1, once the extension mechanism is defined. Once some experimentation has happened, we'll be in a better place to have an informed discussion about some of the points Christian raised in his multipath requirements draft: https://tools.ietf.org/html/draft-huitema-quic-mpath-req-01 I totally agree that experimenting is key. That's why we implemented the multipath extensions that we proposed last year in https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/ This document has evolved and we'll release a new version before the London IETF to take into account various comments received. In parallel with that, we are finalizing an iOS application that uses multipath QUIC to evaluate how this works in the wild. This application will perform various measurements to analyze the benefits of multipath. If you have ideas, feel free to contact me offline. If there is interest, I might be able to report some results with multipath QUIC in the wild at the London IETF. Quentin --001a114043bc422d620565545847 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I briefly skimmed th= e multi path proposal and one thing that comes to mind is the limit of 256 = paths.
I thin= k there could be much more than 256 paths and that path ID=E2=80=99s could = be varint encoded. A single address could have multiple paths over time, ke= y migration could be tied to paths, although two paths may still share a ke= y. Path swapping could potentially be used to protect against optimistic AC= K attack. I wrote an issue on segmented packet numbers:=C2=A0https://github.com/quicwg/b= ase-drafts/issues/1105=C2=A0here the objective is to avoid the packet n= umber encryption and to provide simpler per path loss management, but it ov= erlaps with multi-path. I wonder how much the current design actually needs= to change in order to support multi-path if using segmented packet numbers= . There is already PATH_CHALLENGE.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 16 February 2018 at 14.11.17, Quentin De Coninck (quentin.deconinck@uclouvain= .be) wrote:

Hello,

Le 14/02/18 =C3=A0 20:22, Ian Swett a =C3=A9crit=C2=A0:
I think the right path forward is for those particularly interested in multipath to experiment with QUIC extensions inside v1, once the extension mechanism is defined.=C2=A0 Once some experimentation has happened, we'll be in a better place to have an informed discussion about some of the points Christian raised in his multipath requirements draft:=C2=A0https://tools.ietf.org/html/dr= aft-huitema-quic-mpath-req-01

I totally agree that experimenting is key. That's why we implemented the multipath extensions that we proposed last year in https://datatracker.ietf.org/doc/draft-de= coninck-multipath-quic/

This document has evolved and we'll release a new version before the London IETF to take into account various comments received. In parallel with that, we are finalizing an iOS application that uses multipath QUIC to evaluate how this works in the wild. This application will perform various measurements to analyze the benefits of multipath. If you have ideas, feel free to contact me offline. If there is interest, I might be able to report some results with multipath QUIC in the wild at the London IETF.

Quentin
--001a114043bc422d620565545847-- From nobody Fri Feb 16 09:01:59 2018 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 77B5C129C6A for ; Fri, 16 Feb 2018 09:01:58 -0800 (PST) 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 7sijMtAW5hAW for ; Fri, 16 Feb 2018 09:01:55 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002: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 840A112D893 for ; Fri, 16 Feb 2018 09:01:55 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id o1-v6so797567ybk.10 for ; Fri, 16 Feb 2018 09:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=QP+YoJnoxBMGauvmmciWEZIy+u4ssxpP4Bo9oKVsfII=; b=1CofVnCTkwXqiT9qd6jMnZjbGX3lk+hkZ+LKXLCxpOJlShixkT1ICi/UfqQVOYLQ8I vpkD2jVEnIUMCRh/rk4dZSf1Tf8+CYn3StozeSVjgKJGh/19kVyXnJFGdR3byOwcNoQs asISZ/YVjBHxxNkSynYooCiIddCH6NBkQdWoRYip5MgTXUJdSMttcDxarF/ybrCvFJNx S17cJCkzJhn9kg6Xan/iNrPUbg6zxQWDht/HpSyMDwRvHZvJ8/Pl7j9DEUjr5uWT4YJT IfIF6Nx3Vh7r46HpJ1y4HxjahHTfNG5tfk5VXqgj5JJ9k6zGu/NKW0h5rY24X3DONP8y 9XSw== 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=QP+YoJnoxBMGauvmmciWEZIy+u4ssxpP4Bo9oKVsfII=; b=gE0q3mwSC0GtR1JIb31Y40QyYDnEhgQFvMJF5Ik7n0xhZc6HGyyZiZOVm4vx+iJMTH Ie+WLGZi6CkBqnv3CNvDfGMH7r0Q3vZ6DSBU0G+nRu2dMH4HqSWU5ikn+Zgo4ZWsJmVh HJsRHltEWTt3/5n3f80L7ngGo2GvGVsfSs6KcKstolynIm4Ae5gMT5sKt1OvpERIMZP7 x172DTkgcprB4dQxWxfBnbWfJl8prPxpEVuwx3Yj2QSsWEg+C2euGTAv8CfRAZQrhBfl QdsmPMY/oSITMiMs+UQgFwgKGkRru0d9bFprelVdaIhqlTI9+AwSiy3NB+O+cm5g7ulm MbNg== X-Gm-Message-State: APf1xPApRqxzIz/pIoBDRDJ1/B8ilqR/pDbgjEna97SNmJn00Zqv5Oxv EQmBkAvEijsPKI/RbjPc3HRMC62InItss3OkHa2ln4Y+jrw= X-Google-Smtp-Source: AH8x226hoAQ5U6ioz5LUu7IzVvL3Up0YOwh/bgoTWC73eHmOLf5ked54miTCNn96j5Q+5h7R4/cD+k4HeICzZKR51mo= X-Received: by 10.37.129.193 with SMTP id n1mr5132377ybm.413.1518800513984; Fri, 16 Feb 2018 09:01:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.114.10 with HTTP; Fri, 16 Feb 2018 09:01:13 -0800 (PST) From: Eric Rescorla Date: Fri, 16 Feb 2018 09:01:13 -0800 Message-ID: Subject: Asymmetric CIDs To: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e08264fa41f02d00565574dc5" 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, 16 Feb 2018 17:01:59 -0000 --089e08264fa41f02d00565574dc5 Content-Type: text/plain; charset="UTF-8" Hi folks, After a bunch of discussion, the CID task force came down to rough consensus that asymmetric conn IDs were probably the right direction (CID task force members, please feel free to voice dissent here). Here's a complete writeup of what I think would be needed for asymmetric connection IDs. It's not a PR, because I think something self-contained is cleaner. Note that if we adopt this direction, we would be sacrificing public reset under some conditions (see previous emails to the list) and we would need to decide if it was worth keeping at all. OVERVIEW The basic idea is that each side gets to dictate the connection IDs that are used to send to it. During the handshake, you establish those CIDs and then each side can issue new CIDs during the connection. The main advantage of this is that it allows for symmetric topologies in which the client is also behind some kind of stateless LB/router rather than just the server. See Issue #1091 for more info on this. The overall handshake looks something like this: Client Server Initial [CID=XXX] {recv-CID=YYY} ----------------> <-------------- Cleartext [CID=YYY] {recv-CID=ZZZ} Cleartext [CID=ZZZ], {recv-CID=YYY} -------------> <-------------------------- Short header [CID=YYY] Short header [CID=ZZZ] --------------------------> The client's initial CID (XXX) is special, and either consists of (a) a randomly chosen dummy CID. Proposal: require this to be 8 bytes or at least a minimum. This should be the same for all Initial packets in a connection (unless a stateless reject is received, as below). (b) a CID which it received from the server in a stateless reject All the server's packets are sent with the client's receive CID (YYY) and all subsequent client packets are sent with the server's receive CID (ZZZ). The general rule is that you should send with the connection ID that you most recently received (where recently is defined as highest PN). Note: I believe it's safe to just use the sending CID as the mixin for the KDF, but I haven't thought this entirely through yet. Finally, you can send NEW_CONNECTION_ID in either direction to provide a new connection ID for the other side to use. The general assumption is that you can do this at any time, just as with current QUIC, and that any time you send to a new remote 3-tuple you should change CIDs if you can. Note that this means that endpoints should try to make sure that the other side has spare CIDs in case they need to migrate. WIRE ENCODING As we discussed in the meeting the short header should just have an implicit length CID. This gives us the following short header: +-+-+-+-+-+-+-+-+ |0|C|K| Type (5)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + [Connection ID (*)] + <- change from 64 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (8/16/32) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Protected Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that we may also be able to dispense with the C bit, if each side just gets to say "send me this CID exactly", why do we want to say "here is my CID but you can omit it". We have several options about the long header. The first question is where recv-CIDs go. In previous versions I suggested putting them in transport parameters, or elsewhere in the TLS handshake, and that might still be viable, though it has some drawbacks [0], so the other alternative is to put both CIDs in in the long header. This would look something like: +-+-+-+-+-+-+-+-+ |1| Type (7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DCID-Length | | +-+-+-+-+-+-+-+-+ Dst Connection ID (*) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SCID-Length | | +-+-+-+-+-+-+-+-+ Src Connection ID (*) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The semantics here are that the first value is the CID you want to send to and the second one is the value you want used to send to you (I've inverted these to keep the order the same as short header). Two notes about this encoding: 1. I think we agreed that we didn't want arbitrary length CIDs up to 255 bytes, and yet we have room in this length byte. I propose we limit it to 31 bytes and then grease the remaining 3 bits [1]. 2. Because the client sends its CID first, there's no way to get the current QUIC semantics of the server just dictates the CID. I propose we fix that by defining a special sentinel CID (all 1s, all 0s, whatever) of whatever our maximum length is that means "just use your own CID". We can endlessly bikeshed on this structure. Finally, we will need to update NEW_CONNECTION_ID to allow a variable length CID. This would look like this: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence (i) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CID-Length | | +-+-+-+-+-+-+-+-+ Connection ID (*) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Stateless Reset Token (128) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [0] However, in the transport parameters design, if the server's handshake gets reordered, the client might need to send some ACKs with the initial CID. However, we've agreed that the client's IP address has to be stable, so this isn't a problem. Alternately, you could change C->S CIDs in the short header if that was easier. [1] An alternative would be to have a sparse range (e.g., you can express 0-7 and then 8-22 by 2s, assuming I have counted correctly) and then we could pack both lengths into a single byte. As I said, lots of opportunities for bikeshedding here. --089e08264fa41f02d00565574dc5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

After a bunch of d= iscussion, the CID task force came down to rough
consensus that a= symmetric conn IDs were probably the right
direction (CID task fo= rce members, please feel free to voice dissent
here). Here's = a complete writeup of what I think would be needed
for asymmetric= connection IDs. It's not a PR, because I think
something sel= f-contained is cleaner.

Note that if we adopt this= direction, we would be sacrificing
public reset under some condi= tions (see previous emails to the
list) and we would need to deci= de if it was worth keeping at all.


= OVERVIEW
The basic idea is that each side gets to dictate the con= nection IDs
that are used to send to it. During the handshake, yo= u establish those
CIDs and then each side can issue new CIDs duri= ng the connection.=C2=A0 The
main advantage of this is that it al= lows for symmetric topologies in which
the client is also behind = some kind of stateless LB/router rather than
just the server. See= Issue #1091 for more info on this.


The overall handshake looks something like this:

= Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server

Initial [CID=3DXXX] {recv-CID=3DYYY} ----------------&= gt;
<-------------- Cleartext [CID=3DYYY] {recv-CID=3DZZZ}
Cleartext [CID=3DZZZ], {recv-CID=3DYYY} ------------->
= <-------------------------- Short header [CID=3DYYY]
Short hea= der [CID=3DZZZ] -------------------------->

The client's initial CID (XXX) is special, and either consi= sts of

=C2=A0 =C2=A0 (a) a randomly chosen dummy C= ID. Proposal: require this to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 8 by= tes or at least a minimum. This should be the same
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 for all Initial packets in a connection (unless a stateless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reject is received, as below).
=C2=A0 =C2=A0 (b) a CID which it received from the server in a stateless= reject

All the server's packets are sent with= the client's receive CID (YYY)
and all subsequent client pac= kets are sent with the server's receive
CID (ZZZ). The genera= l rule is that you should send with the
connection ID that you mo= st recently received (where recently
is defined as highest PN).

Note: I believe it's safe to just use the sendi= ng CID as the mixin
for the KDF, but I haven't thought this e= ntirely through yet.

Finally, you can send NEW_CON= NECTION_ID in either direction to provide
a new connection ID for= the other side to use. The general assumption
is that you can do= this at any time, just as with current QUIC, and
that any time y= ou send to a new remote 3-tuple you should change CIDs
if you can= . Note that this means that endpoints should try to make
sure tha= t the other side has spare CIDs in case they need to migrate.

WIRE ENCODING
As we discussed in the m= eeting the short header should just have
an implicit length CID. = This gives us the following short header:

=C2=A0 = =C2=A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|0|C|K| Type (5)|
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Connection ID (= *)]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+=C2=A0 <- change from 64
=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
=C2=A0 =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 Number (8/16/32)=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Protected Payload (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note= that we may also be able to dispense with the C bit, if each
sid= e just gets to say "send me this CID exactly", why do we want
to say "here is my CID but you can omit it".

We have several options about the long header. T= he first question
is where recv-CIDs go. In previous versions I s= uggested putting
them in transport parameters, or elsewhere in th= e TLS handshake,
and that might still be viable, though it has so= me drawbacks [0],
so the other alternative is to put both CIDs in= in the long header.
This would look something like:
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|1|=C2= =A0 =C2=A0Type (7)=C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 DCI= D-Length=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-= +=C2=A0 =C2=A0Dst Connection ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /div>
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 SCID-Length=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0Src Connec= tion ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Version (32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet Number (32)=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Payload (*)=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+

The semantics here are that the first value is= the CID you want to
send to and the second one is the value you = want used to send to you
(I've inverted these to keep the ord= er the same as short header).

Two notes about this= encoding:

1. I think we agreed that we didn't= want arbitrary length CIDs up to
255 bytes, and yet we have room= in this length byte. I propose we
limit it to 31 bytes and then = grease the remaining 3 bits [1].

2. Because the cl= ient sends its CID first, there's no way to get the
current Q= UIC semantics of the server just dictates the CID.=C2=A0 I propose
we fix that by defining a special sentinel CID (all 1s, all 0s,
whatever) of whatever our maximum length is that means "just use your=
own CID".

We can endlessly bikeshe= d on this structure.


Finally, we wi= ll need to update NEW_CONNECTION_ID to allow a variable
length CI= D. This would look like this:

=C2=A0 =C2=A0 0=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2= =A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<= /div>
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sequence (i)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 CID-Length=C2=A0 =C2=A0= |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0= =C2=A0 =C2=A0Connection ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stateless Reset Token (128)=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2= =A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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] However, in = the transport parameters design, if the server's
handshake ge= ts reordered, the client might need to send some ACKs with
the in= itial CID. However, we've agreed that the client's IP address
=
has to be stable, so this isn't a problem. Alternately, you could<= /div>
change C->S CIDs in the short header if that was easier.
=

[1] An alternative would be to have a sparse range (e.g= ., you can
express 0-7 and then 8-22 by 2s, assuming I have count= ed correctly)
and then we could pack both lengths into a single b= yte. As I said,
lots of opportunities for bikeshedding here.

--089e08264fa41f02d00565574dc5-- From nobody Fri Feb 16 09:26:25 2018 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 29E3D1270FC for ; Fri, 16 Feb 2018 09:26:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 lKhqhf9whOS8 for ; Fri, 16 Feb 2018 09:26:20 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 6FADF124C27 for ; Fri, 16 Feb 2018 09:26:20 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id p204so2591795itc.4 for ; Fri, 16 Feb 2018 09:26:20 -0800 (PST) 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=rXDu5dbxBDMMqCpHdFmpLlulITIxJmg3BBtDVS0JvOk=; b=XQkAGaHxKbKo/fju6Ge1hlq4QlM+CpRDHKOJSZtnlWOkTdPGZKzp8E8+m52Xhn5xD7 IhaRd3pkyMEKpUwyV305mYnE7VsZCbfcONibMcVo4uM9HSl9fXE5Y3Lu4zbi0qhIkUom 43EkMRSSqzGzR6Nw5xePKdLpylXYwNdGKeWEVV0r2ZK2T1MlYoQ8AImU/dJY2APflGLO Yw1LmVaCOW4EPEp4M9jMo3wVapbrf8IOrrHIHmffafzmEm5PiZw1FAKy3fPG4jLWFyRu Lw73t0SvRQfqlkBJO8cOWijF+VQEnl6pQi04YfCpufXotGP+/28oOCsjy/FRtqad04Ye /KdQ== 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=rXDu5dbxBDMMqCpHdFmpLlulITIxJmg3BBtDVS0JvOk=; b=o18NU54UI5Srs1UFwRbYHyZGAx2BYW5MfMdPgKtG86cW48/gPqXKXH0Kubek+itmUo NPy8Q0BrZzTFvrSnI4IKTXUlGrir65IFrhjN8iD55ItaNxGcnnmU1uvB3u5q6OhLY+E/ Yds5rR41lPwakZDpDVbW9wKXUzXPi7VRa6zWK7KTflwea7vFT+TpPE/c34zj4F1X71b8 XUG+7APXD081DKyLK4UtqpuawUYwdIcBA5NKcTxLUPT+AkDA2xDJSrx7yUwNSedJyMCC v5X1Y1d5DMDLPbtNkel5iQMiF4xqsljmUapndzaPXuicbApO2WVBZn5teblsIaZRLUrg kxVQ== X-Gm-Message-State: APf1xPBlRcG/B2wTHbve7dsqAtKs1sEx7WhW6AoaF9A+yT2V/vKhLxo5 k56buPtkbTKVF1MoPa6krWl5n7e2OGHE8B7IKG9Ilg== X-Google-Smtp-Source: AH8x227xbvDgQclbU5ERU38iWVUttkiMgJu7Uuf/PmfvPyhDnWt9Loyb6AXVgIm8FukoAEBJ1rv1/zG4mDFBpqhSZtM= X-Received: by 10.36.121.5 with SMTP id z5mr8973485itc.146.1518801979392; Fri, 16 Feb 2018 09:26:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Fri, 16 Feb 2018 09:25:58 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Fri, 16 Feb 2018 12:25:58 -0500 Message-ID: Subject: Re: Asymmetric CIDs To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114abbba7839b2056557a458" 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, 16 Feb 2018 17:26:24 -0000 --001a114abbba7839b2056557a458 Content-Type: text/plain; charset="UTF-8" Thanks for the excellent summary EKR. I like this design and think the breakage of stateless reset in certain cases is acceptable, since it only applies if both sides must have their preferred connection ID present in order to route correctly, which is a use case that's impossible in the status quo. I have not come up with any other downsides. On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla wrote: > Hi folks, > > After a bunch of discussion, the CID task force came down to rough > consensus that asymmetric conn IDs were probably the right > direction (CID task force members, please feel free to voice dissent > here). Here's a complete writeup of what I think would be needed > for asymmetric connection IDs. It's not a PR, because I think > something self-contained is cleaner. > > Note that if we adopt this direction, we would be sacrificing > public reset under some conditions (see previous emails to the > list) and we would need to decide if it was worth keeping at all. > > > OVERVIEW > The basic idea is that each side gets to dictate the connection IDs > that are used to send to it. During the handshake, you establish those > CIDs and then each side can issue new CIDs during the connection. The > main advantage of this is that it allows for symmetric topologies in which > the client is also behind some kind of stateless LB/router rather than > just the server. See Issue #1091 for more info on this. > > > The overall handshake looks something like this: > > Client Server > > Initial [CID=XXX] {recv-CID=YYY} ----------------> > <-------------- Cleartext [CID=YYY] {recv-CID=ZZZ} > Cleartext [CID=ZZZ], {recv-CID=YYY} -------------> > <-------------------------- Short header [CID=YYY] > Short header [CID=ZZZ] --------------------------> > > > The client's initial CID (XXX) is special, and either consists of > > (a) a randomly chosen dummy CID. Proposal: require this to be > 8 bytes or at least a minimum. This should be the same > for all Initial packets in a connection (unless a stateless > reject is received, as below). > (b) a CID which it received from the server in a stateless reject > > All the server's packets are sent with the client's receive CID (YYY) > and all subsequent client packets are sent with the server's receive > CID (ZZZ). The general rule is that you should send with the > connection ID that you most recently received (where recently > is defined as highest PN). > > Note: I believe it's safe to just use the sending CID as the mixin > for the KDF, but I haven't thought this entirely through yet. > > Finally, you can send NEW_CONNECTION_ID in either direction to provide > a new connection ID for the other side to use. The general assumption > is that you can do this at any time, just as with current QUIC, and > that any time you send to a new remote 3-tuple you should change CIDs > if you can. Note that this means that endpoints should try to make > sure that the other side has spare CIDs in case they need to migrate. > > > WIRE ENCODING > As we discussed in the meeting the short header should just have > an implicit length CID. This gives us the following short header: > > +-+-+-+-+-+-+-+-+ > |0|C|K| Type (5)| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + [Connection ID (*)] + <- > change from 64 > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number (8/16/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Protected Payload (*) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note that we may also be able to dispense with the C bit, if each > side just gets to say "send me this CID exactly", why do we want > to say "here is my CID but you can omit it". > > > We have several options about the long header. The first question > is where recv-CIDs go. In previous versions I suggested putting > them in transport parameters, or elsewhere in the TLS handshake, > and that might still be viable, though it has some drawbacks [0], > so the other alternative is to put both CIDs in in the long header. > This would look something like: > > +-+-+-+-+-+-+-+-+ > |1| Type (7) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DCID-Length | | > +-+-+-+-+-+-+-+-+ Dst Connection ID (*) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SCID-Length | | > +-+-+-+-+-+-+-+-+ Src Connection ID (*) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version (32) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number (32) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload (*) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The semantics here are that the first value is the CID you want to > send to and the second one is the value you want used to send to you > (I've inverted these to keep the order the same as short header). > > Two notes about this encoding: > > 1. I think we agreed that we didn't want arbitrary length CIDs up to > 255 bytes, and yet we have room in this length byte. I propose we > limit it to 31 bytes and then grease the remaining 3 bits [1]. > > 2. Because the client sends its CID first, there's no way to get the > current QUIC semantics of the server just dictates the CID. I propose > we fix that by defining a special sentinel CID (all 1s, all 0s, > whatever) of whatever our maximum length is that means "just use your > own CID". > > We can endlessly bikeshed on this structure. > > > Finally, we will need to update NEW_CONNECTION_ID to allow a variable > length CID. This would look like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence (i) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | CID-Length | | > +-+-+-+-+-+-+-+-+ Connection ID (*) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Stateless Reset Token (128) + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > [0] However, in the transport parameters design, if the server's > handshake gets reordered, the client might need to send some ACKs with > the initial CID. However, we've agreed that the client's IP address > has to be stable, so this isn't a problem. Alternately, you could > change C->S CIDs in the short header if that was easier. > > [1] An alternative would be to have a sparse range (e.g., you can > express 0-7 and then 8-22 by 2s, assuming I have counted correctly) > and then we could pack both lengths into a single byte. As I said, > lots of opportunities for bikeshedding here. > > --001a114abbba7839b2056557a458 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the excellent summary EKR.=C2=A0 I like this de= sign and think the breakage of stateless reset in certain cases is acceptab= le, since it only applies if both sides must have their preferred connectio= n ID present in order to route correctly, which is a use case that's im= possible in the status quo.=C2=A0 I have not come up with any other downsid= es.

On Fri, = Feb 16, 2018 at 12:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
=
Hi folks,
After a bunch of discussion, the CID task force came down to r= ough
consensus that asymmetric conn IDs were probably the right
direction (CID task force members, please feel free to voice disse= nt
here). Here's a complete writeup of what I think would be = needed
for asymmetric connection IDs. It's not a PR, because = I think
something self-contained is cleaner.

=
Note that if we adopt this direction, we would be sacrificing
public reset under some conditions (see previous emails to the
= list) and we would need to decide if it was worth keeping at all.


OVERVIEW
The basic idea is that ea= ch side gets to dictate the connection IDs
that are used to send = to it. During the handshake, you establish those
CIDs and then ea= ch side can issue new CIDs during the connection.=C2=A0 The
main = advantage of this is that it allows for symmetric topologies in which
=
the client is also behind some kind of stateless LB/router rather than=
just the server. See Issue #1091 for more info on this.


The overall handshake looks something like = this:

Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Server

Initial [CID=3DXXX] {r= ecv-CID=3DYYY} ---------------->
<-------------- Cleartext = [CID=3DYYY] {recv-CID=3DZZZ}
Cleartext [CID=3DZZZ], {recv-CID=3DY= YY} ------------->
<-------------------------- Short header= [CID=3DYYY]
Short header [CID=3DZZZ] --------------------------&= gt;


The client's initial CID (X= XX) is special, and either consists of

=C2=A0 =C2= =A0 (a) a randomly chosen dummy CID. Proposal: require this to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 8 bytes or at least a minimum. This should be = the same
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for all Initial packets in a= connection (unless a stateless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 rejec= t is received, as below).
=C2=A0 =C2=A0 (b) a CID which it receiv= ed from the server in a stateless reject

All the s= erver's packets are sent with the client's receive CID (YYY)
<= div>and all subsequent client packets are sent with the server's receiv= e
CID (ZZZ). The general rule is that you should send with the
connection ID that you most recently received (where recently
=
is defined as highest PN).

Note: I believe it= 's safe to just use the sending CID as the mixin
for the KDF,= but I haven't thought this entirely through yet.

<= div>Finally, you can send NEW_CONNECTION_ID in either direction to provide<= /div>
a new connection ID for the other side to use. The general assump= tion
is that you can do this at any time, just as with current QU= IC, and
that any time you send to a new remote 3-tuple you should= change CIDs
if you can. Note that this means that endpoints shou= ld try to make
sure that the other side has spare CIDs in case th= ey need to migrate.


WIRE ENCODING
As we discussed in the meeting the short header should just have
an implicit length CID. This gives us the following short header:<= /div>

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+
=C2=A0 = =C2=A0|0|C|K| Type (5)|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /div>
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0[Connection ID (*)]=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 <- change= from 64
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2= =A0 =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 Number (8/16/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= wbr>-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pr= otected Payload (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that= we may also be able to dispense with the C bit, if each
side jus= t gets to say "send me this CID exactly", why do we want
to say "here is my CID but you can omit it".


We have several options about the long header. The fi= rst question
is where recv-CIDs go. In previous versions I sugges= ted putting
them in transport parameters, or elsewhere in the TLS= handshake,
and that might still be viable, though it has some dr= awbacks [0],
so the other alternative is to put both CIDs in in t= he long header.
This would look something like:

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|1|=C2=A0 =C2= =A0Type (7)=C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 = DCID-Length=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-= +-+-+=C2=A0 =C2=A0Dst Connection ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 SCID-Length=C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 = =C2=A0Src Connection ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Version (32)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet= Number (32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Payload (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The semantics here are that the first value is the CID you want to
send to and the second one is the value you want used to send to yo= u
(I've inverted these to keep the order the same as short he= ader).

Two notes about this encoding:
1. I think we agreed that we didn't want arbitrary length = CIDs up to
255 bytes, and yet we have room in this length byte. I= propose we
limit it to 31 bytes and then grease the remaining 3 = bits [1].

2. Because the client sends its CID firs= t, there's no way to get the
current QUIC semantics of the se= rver just dictates the CID.=C2=A0 I propose
we fix that by defini= ng a special sentinel CID (all 1s, all 0s,
whatever) of whatever = our maximum length is that means "just use your
own CID"= ;.

We can endlessly bikeshed on this structure.


Finally, we will need to update NEW_C= ONNECTION_ID to allow a variable
length CID. This would look like= this:

=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 0 1 2 3 4 5 6 7= 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sequence (i)=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 CID-Length=C2=A0 =C2=A0|=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0 =C2=A0= =C2=A0Connection ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stateless Reset Token (128)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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]= However, in the transport parameters design, if the server's
handshake gets reordered, the client might need to send some ACKs with
the initial CID. However, we've agreed that the client's IP = address
has to be stable, so this isn't a problem. Alternatel= y, you could
change C->S CIDs in the short header if that was = easier.

[1] An alternative would be to have a spar= se range (e.g., you can
express 0-7 and then 8-22 by 2s, assuming= I have counted correctly)
and then we could pack both lengths in= to a single byte. As I said,
lots of opportunities for bikesheddi= ng here.


--001a114abbba7839b2056557a458-- From nobody Fri Feb 16 09:43:35 2018 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 2E76A126CB6 for ; Fri, 16 Feb 2018 09:43:34 -0800 (PST) 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, 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 dpbDtlAphhL6 for ; Fri, 16 Feb 2018 09:43:31 -0800 (PST) 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 4D329124C27 for ; Fri, 16 Feb 2018 09:43:31 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1GHgDuR008364; Fri, 16 Feb 2018 17:43:30 GMT 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=nRoR85xBsZSkpcezZP0MldnBjWDsFLOUVHGrdOIpAAM=; b=U1ZvD2F7jRupN2rXcwpXx+cSf4cgERbukraFR+/YxdwvejvNE+0lHsqRDuxKsiAzT7F0 BoS/VIMaOxzcMu7MFR9uGhMVgJ6VDBfRBf775YmxzhIg8hk7TObcksXfiYdfAbhfhxCe /99xmm6ktmlrVvhG/1s8Xma/gmdTdHtwPYFy2YlKYBqr63fmA7HoAA0u32zBlTgwa+lD 9UicbBalV6z5qvjQFzMkXg3oQXQQFcOjCZBYTuzAV/duKxuYXch6NlyhN3/rxV0ZhiNy CtKyN2EwYVS8XOI0tMMKsEANmZwtDfnnVDXbL1Qyh4QyXq8M3RJTUmwxYfxHr7IB1xS/ BA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2g63c40386-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Feb 2018 17:43:29 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1GHf6u0024478; Fri, 16 Feb 2018 12:43:29 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2g1vy0d6rg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 16 Feb 2018 12:43:28 -0500 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; Fri, 16 Feb 2018 12:43:28 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 16 Feb 2018 12:43:27 -0500 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; Fri, 16 Feb 2018 12:43:27 -0500 From: "Lubashev, Igor" To: Eric Rescorla , IETF QUIC WG Subject: RE: Asymmetric CIDs Thread-Topic: Asymmetric CIDs Thread-Index: AQHTp0fggIXU4KVY8ESyFyVlkYzgVKOnRTcw Date: Fri, 16 Feb 2018 17:43:27 +0000 Message-ID: <7286e675a5c944e08d80e38c314eb103@usma1ex-dag1mb5.msg.corp.akamai.com> References: 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.39] Content-Type: multipart/alternative; boundary="_000_7286e675a5c944e08d80e38c314eb103usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-16_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=908 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802160211 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-16_06:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=856 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802160211 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, 16 Feb 2018 17:43:34 -0000 --_000_7286e675a5c944e08d80e38c314eb103usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgd3JpdGUgdXAuDQoNCihJIHRob3VnaHQgdGhlIENJRCB0YXNrIGZvcmNl IHdhcyB0byBkaXNjdXNzIENJRCBsZW5ndGggYW5kIGl0cyBlbmNvZGluZywgYnV0IHRoaXMgaXMg bXVjaCBiaWdnZXIuKQ0KDQpJIHdhbnQgdG8gcG9pbnQgb3V0IHRoYXQgYXN5bSBDSUQgaXMgc2Fj cmlmaWNpbmcgbm90IG9ubHkgcHVibGljIHJlc2V0IChzb21ldGltZXMpIGJ1dCBhbHNvIHRoZSBh YmlsaXR5IHRvIHJvdXRlIElDTVAgKCYgSUNNUHY2KSBFcnJvciBwYWNrZXRzIGJhY2sgdG8gdGhl IHNlcnZlci4NCg0KVGhlIGlzc3VlIHdpdGggdGhlIHByb3Bvc2VkIHNob3J0LWhlYWRlciBlbmNv ZGluZyBpcyB0aGF0IGl0IG1ha2VzIHBhY2tldCBudW1iZXJzIHVzZWxlc3MgZm9yIG5ldHdvcmsg dHJvdWJsZXNob290aW5nLCBzaW5jZSB0aGV5IGFyZSBsb2NhdGVkIGF0IGFuIHVucHJlZGljdGFi bGUgb2Zmc2V0LCB1bmxlc3MgeW914oCZdmUgc2VlbiB0aGUgbmVnb3RpYXRpb24gYW5kIHJlbWVt YmVyZWQgQ0lEIGxlbmd0aHMgZm9yIGVhY2ggY29ubmVjdGlvbi4NCg0KUC5TLg0KICBUaGUgaXNz dWUgIyBzZWVtcyBpbmNvcnJlY3QuICBBcmUgeW91IHJlZmVycmluZyB0byBpc3N1ZSAjNzQ1Pw0K DQoNCkZyb206IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dDQpTZW50OiBGcmlk YXksIEZlYnJ1YXJ5IDE2LCAyMDE4IDEyOjAxIFBNDQpUbzogSUVURiBRVUlDIFdHIDxxdWljQGll dGYub3JnPg0KU3ViamVjdDogQXN5bW1ldHJpYyBDSURzDQoNCkhpIGZvbGtzLA0KDQpBZnRlciBh IGJ1bmNoIG9mIGRpc2N1c3Npb24sIHRoZSBDSUQgdGFzayBmb3JjZSBjYW1lIGRvd24gdG8gcm91 Z2gNCmNvbnNlbnN1cyB0aGF0IGFzeW1tZXRyaWMgY29ubiBJRHMgd2VyZSBwcm9iYWJseSB0aGUg cmlnaHQNCmRpcmVjdGlvbiAoQ0lEIHRhc2sgZm9yY2UgbWVtYmVycywgcGxlYXNlIGZlZWwgZnJl ZSB0byB2b2ljZSBkaXNzZW50DQpoZXJlKS4gSGVyZSdzIGEgY29tcGxldGUgd3JpdGV1cCBvZiB3 aGF0IEkgdGhpbmsgd291bGQgYmUgbmVlZGVkDQpmb3IgYXN5bW1ldHJpYyBjb25uZWN0aW9uIElE cy4gSXQncyBub3QgYSBQUiwgYmVjYXVzZSBJIHRoaW5rDQpzb21ldGhpbmcgc2VsZi1jb250YWlu ZWQgaXMgY2xlYW5lci4NCg0KTm90ZSB0aGF0IGlmIHdlIGFkb3B0IHRoaXMgZGlyZWN0aW9uLCB3 ZSB3b3VsZCBiZSBzYWNyaWZpY2luZw0KcHVibGljIHJlc2V0IHVuZGVyIHNvbWUgY29uZGl0aW9u cyAoc2VlIHByZXZpb3VzIGVtYWlscyB0byB0aGUNCmxpc3QpIGFuZCB3ZSB3b3VsZCBuZWVkIHRv IGRlY2lkZSBpZiBpdCB3YXMgd29ydGgga2VlcGluZyBhdCBhbGwuDQoNCg0KT1ZFUlZJRVcNClRo ZSBiYXNpYyBpZGVhIGlzIHRoYXQgZWFjaCBzaWRlIGdldHMgdG8gZGljdGF0ZSB0aGUgY29ubmVj dGlvbiBJRHMNCnRoYXQgYXJlIHVzZWQgdG8gc2VuZCB0byBpdC4gRHVyaW5nIHRoZSBoYW5kc2hh a2UsIHlvdSBlc3RhYmxpc2ggdGhvc2UNCkNJRHMgYW5kIHRoZW4gZWFjaCBzaWRlIGNhbiBpc3N1 ZSBuZXcgQ0lEcyBkdXJpbmcgdGhlIGNvbm5lY3Rpb24uICBUaGUNCm1haW4gYWR2YW50YWdlIG9m IHRoaXMgaXMgdGhhdCBpdCBhbGxvd3MgZm9yIHN5bW1ldHJpYyB0b3BvbG9naWVzIGluIHdoaWNo DQp0aGUgY2xpZW50IGlzIGFsc28gYmVoaW5kIHNvbWUga2luZCBvZiBzdGF0ZWxlc3MgTEIvcm91 dGVyIHJhdGhlciB0aGFuDQpqdXN0IHRoZSBzZXJ2ZXIuIFNlZSBJc3N1ZSAjMTA5MSBmb3IgbW9y ZSBpbmZvIG9uIHRoaXMuDQoNCg0KVGhlIG92ZXJhbGwgaGFuZHNoYWtlIGxvb2tzIHNvbWV0aGlu ZyBsaWtlIHRoaXM6DQoNCkNsaWVudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgU2VydmVyDQoNCkluaXRpYWwgW0NJRD1YWFhdIHtyZWN2LUNJRD1ZWVl9IC0tLS0tLS0tLS0t LS0tLS0+DQo8LS0tLS0tLS0tLS0tLS0gQ2xlYXJ0ZXh0IFtDSUQ9WVlZXSB7cmVjdi1DSUQ9Wlpa fQ0KQ2xlYXJ0ZXh0IFtDSUQ9WlpaXSwge3JlY3YtQ0lEPVlZWX0gLS0tLS0tLS0tLS0tLT4NCjwt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSBTaG9ydCBoZWFkZXIgW0NJRD1ZWVldDQpTaG9ydCBo ZWFkZXIgW0NJRD1aWlpdIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPg0KDQoNClRoZSBjbGll bnQncyBpbml0aWFsIENJRCAoWFhYKSBpcyBzcGVjaWFsLCBhbmQgZWl0aGVyIGNvbnNpc3RzIG9m DQoNCiAgICAoYSkgYSByYW5kb21seSBjaG9zZW4gZHVtbXkgQ0lELiBQcm9wb3NhbDogcmVxdWly ZSB0aGlzIHRvIGJlDQogICAgICAgIDggYnl0ZXMgb3IgYXQgbGVhc3QgYSBtaW5pbXVtLiBUaGlz IHNob3VsZCBiZSB0aGUgc2FtZQ0KICAgICAgICBmb3IgYWxsIEluaXRpYWwgcGFja2V0cyBpbiBh IGNvbm5lY3Rpb24gKHVubGVzcyBhIHN0YXRlbGVzcw0KICAgICAgICByZWplY3QgaXMgcmVjZWl2 ZWQsIGFzIGJlbG93KS4NCiAgICAoYikgYSBDSUQgd2hpY2ggaXQgcmVjZWl2ZWQgZnJvbSB0aGUg c2VydmVyIGluIGEgc3RhdGVsZXNzIHJlamVjdA0KDQpBbGwgdGhlIHNlcnZlcidzIHBhY2tldHMg YXJlIHNlbnQgd2l0aCB0aGUgY2xpZW50J3MgcmVjZWl2ZSBDSUQgKFlZWSkNCmFuZCBhbGwgc3Vi c2VxdWVudCBjbGllbnQgcGFja2V0cyBhcmUgc2VudCB3aXRoIHRoZSBzZXJ2ZXIncyByZWNlaXZl DQpDSUQgKFpaWikuIFRoZSBnZW5lcmFsIHJ1bGUgaXMgdGhhdCB5b3Ugc2hvdWxkIHNlbmQgd2l0 aCB0aGUNCmNvbm5lY3Rpb24gSUQgdGhhdCB5b3UgbW9zdCByZWNlbnRseSByZWNlaXZlZCAod2hl cmUgcmVjZW50bHkNCmlzIGRlZmluZWQgYXMgaGlnaGVzdCBQTikuDQoNCk5vdGU6IEkgYmVsaWV2 ZSBpdCdzIHNhZmUgdG8ganVzdCB1c2UgdGhlIHNlbmRpbmcgQ0lEIGFzIHRoZSBtaXhpbg0KZm9y IHRoZSBLREYsIGJ1dCBJIGhhdmVuJ3QgdGhvdWdodCB0aGlzIGVudGlyZWx5IHRocm91Z2ggeWV0 Lg0KDQpGaW5hbGx5LCB5b3UgY2FuIHNlbmQgTkVXX0NPTk5FQ1RJT05fSUQgaW4gZWl0aGVyIGRp cmVjdGlvbiB0byBwcm92aWRlDQphIG5ldyBjb25uZWN0aW9uIElEIGZvciB0aGUgb3RoZXIgc2lk ZSB0byB1c2UuIFRoZSBnZW5lcmFsIGFzc3VtcHRpb24NCmlzIHRoYXQgeW91IGNhbiBkbyB0aGlz IGF0IGFueSB0aW1lLCBqdXN0IGFzIHdpdGggY3VycmVudCBRVUlDLCBhbmQNCnRoYXQgYW55IHRp bWUgeW91IHNlbmQgdG8gYSBuZXcgcmVtb3RlIDMtdHVwbGUgeW91IHNob3VsZCBjaGFuZ2UgQ0lE cw0KaWYgeW91IGNhbi4gTm90ZSB0aGF0IHRoaXMgbWVhbnMgdGhhdCBlbmRwb2ludHMgc2hvdWxk IHRyeSB0byBtYWtlDQpzdXJlIHRoYXQgdGhlIG90aGVyIHNpZGUgaGFzIHNwYXJlIENJRHMgaW4g Y2FzZSB0aGV5IG5lZWQgdG8gbWlncmF0ZS4NCg0KDQpXSVJFIEVOQ09ESU5HDQpBcyB3ZSBkaXNj dXNzZWQgaW4gdGhlIG1lZXRpbmcgdGhlIHNob3J0IGhlYWRlciBzaG91bGQganVzdCBoYXZlDQph biBpbXBsaWNpdCBsZW5ndGggQ0lELiBUaGlzIGdpdmVzIHVzIHRoZSBmb2xsb3dpbmcgc2hvcnQg aGVhZGVyOg0KDQogICArLSstKy0rLSstKy0rLSstKw0KICAgfDB8Q3xLfCBUeXBlICg1KXwNCiAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KICAgKyAgICAgICAgICAgICAgICAgICAgIFtDb25uZWN0 aW9uIElEICgqKV0gICAgICAgICAgICAgICAgICAgICAgICsgIDwtIGNoYW5nZSBmcm9tIDY0DQog ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgUGFja2V0 IE51bWJlciAoOC8xNi8zMikgICAgICAgICAgICAgICAgLi4uDQogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAg ICAgICAgICAgICAgICAgICAgIFByb3RlY3RlZCBQYXlsb2FkICgqKSAgICAgICAgICAgICAgICAg ICAuLi4NCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQoNCk5vdGUgdGhhdCB3ZSBtYXkgYWxzbyBiZSBhYmxlIHRvIGRp c3BlbnNlIHdpdGggdGhlIEMgYml0LCBpZiBlYWNoDQpzaWRlIGp1c3QgZ2V0cyB0byBzYXkgInNl bmQgbWUgdGhpcyBDSUQgZXhhY3RseSIsIHdoeSBkbyB3ZSB3YW50DQp0byBzYXkgImhlcmUgaXMg bXkgQ0lEIGJ1dCB5b3UgY2FuIG9taXQgaXQiLg0KDQoNCldlIGhhdmUgc2V2ZXJhbCBvcHRpb25z IGFib3V0IHRoZSBsb25nIGhlYWRlci4gVGhlIGZpcnN0IHF1ZXN0aW9uDQppcyB3aGVyZSByZWN2 LUNJRHMgZ28uIEluIHByZXZpb3VzIHZlcnNpb25zIEkgc3VnZ2VzdGVkIHB1dHRpbmcNCnRoZW0g aW4gdHJhbnNwb3J0IHBhcmFtZXRlcnMsIG9yIGVsc2V3aGVyZSBpbiB0aGUgVExTIGhhbmRzaGFr ZSwNCmFuZCB0aGF0IG1pZ2h0IHN0aWxsIGJlIHZpYWJsZSwgdGhvdWdoIGl0IGhhcyBzb21lIGRy YXdiYWNrcyBbMF0sDQpzbyB0aGUgb3RoZXIgYWx0ZXJuYXRpdmUgaXMgdG8gcHV0IGJvdGggQ0lE cyBpbiBpbiB0aGUgbG9uZyBoZWFkZXIuDQpUaGlzIHdvdWxkIGxvb2sgc29tZXRoaW5nIGxpa2U6 DQoNCiAgICstKy0rLSstKy0rLSstKy0rDQogICB8MXwgICBUeXBlICg3KSAgfA0KICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgIHwgIERDSUQtTGVuZ3RoICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKyAgIERzdCBDb25uZWN0aW9uIElE ICgqKSAgICAgICAgICAgICAgICAgICAgICAgKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQog ICB8ICBTQ0lELUxlbmd0aCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSsgICBTcmMgQ29ubmVjdGlvbiBJRCAoKikg ICAgICAgICAgICAgICAgICAgICAgICsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICBWZXJzaW9uICgzMikgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICBQYWNrZXQgTnVt YmVyICgzMikgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgIFBheWxvYWQgKCopICAgICAgICAgICAgICAgICAgICAgICAgLi4u DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KDQpUaGUgc2VtYW50aWNzIGhlcmUgYXJlIHRoYXQgdGhlIGZpcnN0IHZh bHVlIGlzIHRoZSBDSUQgeW91IHdhbnQgdG8NCnNlbmQgdG8gYW5kIHRoZSBzZWNvbmQgb25lIGlz IHRoZSB2YWx1ZSB5b3Ugd2FudCB1c2VkIHRvIHNlbmQgdG8geW91DQooSSd2ZSBpbnZlcnRlZCB0 aGVzZSB0byBrZWVwIHRoZSBvcmRlciB0aGUgc2FtZSBhcyBzaG9ydCBoZWFkZXIpLg0KDQpUd28g bm90ZXMgYWJvdXQgdGhpcyBlbmNvZGluZzoNCg0KMS4gSSB0aGluayB3ZSBhZ3JlZWQgdGhhdCB3 ZSBkaWRuJ3Qgd2FudCBhcmJpdHJhcnkgbGVuZ3RoIENJRHMgdXAgdG8NCjI1NSBieXRlcywgYW5k IHlldCB3ZSBoYXZlIHJvb20gaW4gdGhpcyBsZW5ndGggYnl0ZS4gSSBwcm9wb3NlIHdlDQpsaW1p dCBpdCB0byAzMSBieXRlcyBhbmQgdGhlbiBncmVhc2UgdGhlIHJlbWFpbmluZyAzIGJpdHMgWzFd Lg0KDQoyLiBCZWNhdXNlIHRoZSBjbGllbnQgc2VuZHMgaXRzIENJRCBmaXJzdCwgdGhlcmUncyBu byB3YXkgdG8gZ2V0IHRoZQ0KY3VycmVudCBRVUlDIHNlbWFudGljcyBvZiB0aGUgc2VydmVyIGp1 c3QgZGljdGF0ZXMgdGhlIENJRC4gIEkgcHJvcG9zZQ0Kd2UgZml4IHRoYXQgYnkgZGVmaW5pbmcg YSBzcGVjaWFsIHNlbnRpbmVsIENJRCAoYWxsIDFzLCBhbGwgMHMsDQp3aGF0ZXZlcikgb2Ygd2hh dGV2ZXIgb3VyIG1heGltdW0gbGVuZ3RoIGlzIHRoYXQgbWVhbnMgImp1c3QgdXNlIHlvdXINCm93 biBDSUQiLg0KDQpXZSBjYW4gZW5kbGVzc2x5IGJpa2VzaGVkIG9uIHRoaXMgc3RydWN0dXJlLg0K DQoNCkZpbmFsbHksIHdlIHdpbGwgbmVlZCB0byB1cGRhdGUgTkVXX0NPTk5FQ1RJT05fSUQgdG8g YWxsb3cgYSB2YXJpYWJsZQ0KbGVuZ3RoIENJRC4gVGhpcyB3b3VsZCBsb29rIGxpa2UgdGhpczoN Cg0KICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDMNCiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAg ICAgICAgICAgICBTZXF1ZW5jZSAoaSkgICAgICAgICAgICAgICAgICAgICAgIC4uLg0KICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCiAgIHwgIENJRC1MZW5ndGggICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKyAgICAgICBDb25uZWN0aW9u IElEICgqKSAgICAgICAgICAgICAgICAgICAgICAgKw0KICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfA0KICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICArICAgICAgICAgICAg ICAgICAgIFN0YXRlbGVzcyBSZXNldCBUb2tlbiAoMTI4KSAgICAgICAgICAgICAgICAgKw0KICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICArDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KDQoNClsw XSBIb3dldmVyLCBpbiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnMgZGVzaWduLCBpZiB0aGUgc2Vy dmVyJ3MNCmhhbmRzaGFrZSBnZXRzIHJlb3JkZXJlZCwgdGhlIGNsaWVudCBtaWdodCBuZWVkIHRv IHNlbmQgc29tZSBBQ0tzIHdpdGgNCnRoZSBpbml0aWFsIENJRC4gSG93ZXZlciwgd2UndmUgYWdy ZWVkIHRoYXQgdGhlIGNsaWVudCdzIElQIGFkZHJlc3MNCmhhcyB0byBiZSBzdGFibGUsIHNvIHRo aXMgaXNuJ3QgYSBwcm9ibGVtLiBBbHRlcm5hdGVseSwgeW91IGNvdWxkDQpjaGFuZ2UgQy0+UyBD SURzIGluIHRoZSBzaG9ydCBoZWFkZXIgaWYgdGhhdCB3YXMgZWFzaWVyLg0KDQpbMV0gQW4gYWx0 ZXJuYXRpdmUgd291bGQgYmUgdG8gaGF2ZSBhIHNwYXJzZSByYW5nZSAoZS5nLiwgeW91IGNhbg0K ZXhwcmVzcyAwLTcgYW5kIHRoZW4gOC0yMiBieSAycywgYXNzdW1pbmcgSSBoYXZlIGNvdW50ZWQg Y29ycmVjdGx5KQ0KYW5kIHRoZW4gd2UgY291bGQgcGFjayBib3RoIGxlbmd0aHMgaW50byBhIHNp bmdsZSBieXRlLiBBcyBJIHNhaWQsDQpsb3RzIG9mIG9wcG9ydHVuaXRpZXMgZm9yIGJpa2VzaGVk ZGluZyBoZXJlLg0KDQo= --_000_7286e675a5c944e08d80e38c314eb103usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rcyBmb3IgdGhlIHdyaXRlIHVwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4o SSB0aG91Z2h0IHRoZSBDSUQgdGFzayBmb3JjZSB3YXMgdG8gZGlzY3VzcyBDSUQgbGVuZ3RoIGFu ZCBpdHMgZW5jb2RpbmcsIGJ1dCB0aGlzIGlzIG11Y2ggYmlnZ2VyLik8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSB3YW50IHRvIHBvaW50IG91dCB0aGF0IGFzeW0gQ0lEIGlzIHNhY3JpZmljaW5n IG5vdCBvbmx5IHB1YmxpYyByZXNldCAoc29tZXRpbWVzKSBidXQgYWxzbyB0aGUgYWJpbGl0eSB0 byByb3V0ZSBJQ01QICgmYW1wOyBJQ01QdjYpIEVycm9yIHBhY2tldHMgYmFjayB0byB0aGUgc2Vy dmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaXNzdWUgd2l0aCB0aGUgcHJvcG9zZWQg c2hvcnQtaGVhZGVyIGVuY29kaW5nIGlzIHRoYXQgaXQgbWFrZXMgcGFja2V0IG51bWJlcnMgdXNl bGVzcyBmb3IgbmV0d29yayB0cm91Ymxlc2hvb3RpbmcsIHNpbmNlIHRoZXkgYXJlIGxvY2F0ZWQg YXQgYW4gdW5wcmVkaWN0YWJsZSBvZmZzZXQsIHVubGVzcyB5b3XigJl2ZSBzZWVuIHRoZSBuZWdv dGlhdGlvbiBhbmQgcmVtZW1iZXJlZCBDSUQgbGVuZ3RocyBmb3INCiBlYWNoIGNvbm5lY3Rpb24u PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlAuUy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyBUaGUgaXNzdWUgIyBzZWVtcyBpbmNvcnJlY3QuJm5ic3A7IEFyZSB5 b3UgcmVmZXJyaW5nIHRvIGlzc3VlICM3NDU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEVyaWMg UmVzY29ybGEgW21haWx0bzpla3JAcnRmbS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IEZlYnJ1YXJ5IDE2LCAyMDE4IDEyOjAxIFBNPGJyPg0KPGI+VG86PC9iPiBJRVRGIFFVSUMgV0cg Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IEFzeW1tZXRyaWMgQ0lE czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGZvbGtzLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZnRlciBhIGJ1 bmNoIG9mIGRpc2N1c3Npb24sIHRoZSBDSUQgdGFzayBmb3JjZSBjYW1lIGRvd24gdG8gcm91Z2g8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNvbnNl bnN1cyB0aGF0IGFzeW1tZXRyaWMgY29ubiBJRHMgd2VyZSBwcm9iYWJseSB0aGUgcmlnaHQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmRpcmVjdGlv biAoQ0lEIHRhc2sgZm9yY2UgbWVtYmVycywgcGxlYXNlIGZlZWwgZnJlZSB0byB2b2ljZSBkaXNz ZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5o ZXJlKS4gSGVyZSdzIGEgY29tcGxldGUgd3JpdGV1cCBvZiB3aGF0IEkgdGhpbmsgd291bGQgYmUg bmVlZGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5mb3IgYXN5bW1ldHJpYyBjb25uZWN0aW9uIElEcy4gSXQncyBub3QgYSBQUiwgYmVjYXVzZSBJ IHRoaW5rPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5zb21ldGhpbmcgc2VsZi1jb250YWluZWQgaXMgY2xlYW5lci48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZSB0aGF0IGlmIHdlIGFkb3B0 IHRoaXMgZGlyZWN0aW9uLCB3ZSB3b3VsZCBiZSBzYWNyaWZpY2luZzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cHVibGljIHJlc2V0IHVuZGVyIHNv bWUgY29uZGl0aW9ucyAoc2VlIHByZXZpb3VzIGVtYWlscyB0byB0aGU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxpc3QpIGFuZCB3ZSB3b3VsZCBu ZWVkIHRvIGRlY2lkZSBpZiBpdCB3YXMgd29ydGgga2VlcGluZyBhdCBhbGwuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T1ZFUlZJRVc8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBiYXNp YyBpZGVhIGlzIHRoYXQgZWFjaCBzaWRlIGdldHMgdG8gZGljdGF0ZSB0aGUgY29ubmVjdGlvbiBJ RHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRo YXQgYXJlIHVzZWQgdG8gc2VuZCB0byBpdC4gRHVyaW5nIHRoZSBoYW5kc2hha2UsIHlvdSBlc3Rh Ymxpc2ggdGhvc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkNJRHMgYW5kIHRoZW4gZWFjaCBzaWRlIGNhbiBpc3N1ZSBuZXcgQ0lEcyBkdXJpbmcg dGhlIGNvbm5lY3Rpb24uJm5ic3A7IFRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+bWFpbiBhZHZhbnRhZ2Ugb2YgdGhpcyBpcyB0aGF0IGl0IGFs bG93cyBmb3Igc3ltbWV0cmljIHRvcG9sb2dpZXMgaW4gd2hpY2g8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBjbGllbnQgaXMgYWxzbyBiZWhp bmQgc29tZSBraW5kIG9mIHN0YXRlbGVzcyBMQi9yb3V0ZXIgcmF0aGVyIHRoYW48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmp1c3QgdGhlIHNlcnZl ci4gU2VlIElzc3VlICMxMDkxIGZvciBtb3JlIGluZm8gb24gdGhpcy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgb3ZlcmFsbCBoYW5k c2hha2UgbG9va3Mgc29tZXRoaW5nIGxpa2UgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xpZW50Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFNl cnZlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Jbml0aWFsIFtDSUQ9WFhYXSB7cmVjdi1DSUQ9WVlZfSAtLS0tLS0tLS0tLS0tLS0tJmd0Ozxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0Oy0t LS0tLS0tLS0tLS0tIENsZWFydGV4dCBbQ0lEPVlZWV0ge3JlY3YtQ0lEPVpaWn08bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNsZWFydGV4dCBbQ0lE PVpaWl0sIHtyZWN2LUNJRD1ZWVl9IC0tLS0tLS0tLS0tLS0mZ3Q7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gU2hvcnQgaGVhZGVyIFtDSUQ9WVlZXTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2hvcnQgaGVhZGVyIFtDSUQ9WlpaXSAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY2xpZW50J3MgaW5pdGlhbCBDSUQgKFhYWCkgaXMg c3BlY2lhbCwgYW5kIGVpdGhlciBjb25zaXN0cyBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IChhKSBhIHJhbmRvbWx5 IGNob3NlbiBkdW1teSBDSUQuIFByb3Bvc2FsOiByZXF1aXJlIHRoaXMgdG8gYmU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyA4IGJ5dGVzIG9yIGF0IGxlYXN0IGEgbWluaW11bS4gVGhpcyBzaG91bGQg YmUgdGhlIHNhbWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmb3IgYWxsIEluaXRpYWwgcGFja2V0 cyBpbiBhIGNvbm5lY3Rpb24gKHVubGVzcyBhIHN0YXRlbGVzczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHJlamVjdCBpcyByZWNlaXZlZCwgYXMgYmVsb3cpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAoYikgYSBDSUQgd2hp Y2ggaXQgcmVjZWl2ZWQgZnJvbSB0aGUgc2VydmVyIGluIGEgc3RhdGVsZXNzIHJlamVjdDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbGwgdGhl IHNlcnZlcidzIHBhY2tldHMgYXJlIHNlbnQgd2l0aCB0aGUgY2xpZW50J3MgcmVjZWl2ZSBDSUQg KFlZWSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmFuZCBhbGwgc3Vic2VxdWVudCBjbGllbnQgcGFja2V0cyBhcmUgc2VudCB3aXRoIHRoZSBzZXJ2 ZXIncyByZWNlaXZlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5DSUQgKFpaWikuIFRoZSBnZW5lcmFsIHJ1bGUgaXMgdGhhdCB5b3Ugc2hvdWxkIHNl bmQgd2l0aCB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmNvbm5lY3Rpb24gSUQgdGhhdCB5b3UgbW9zdCByZWNlbnRseSByZWNlaXZlZCAod2hl cmUgcmVjZW50bHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmlzIGRlZmluZWQgYXMgaGlnaGVzdCBQTikuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vdGU6IEkgYmVsaWV2ZSBpdCdzIHNhZmUg dG8ganVzdCB1c2UgdGhlIHNlbmRpbmcgQ0lEIGFzIHRoZSBtaXhpbjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zm9yIHRoZSBLREYsIGJ1dCBJIGhh dmVuJ3QgdGhvdWdodCB0aGlzIGVudGlyZWx5IHRocm91Z2ggeWV0LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaW5hbGx5LCB5b3UgY2FuIHNl bmQgTkVXX0NPTk5FQ1RJT05fSUQgaW4gZWl0aGVyIGRpcmVjdGlvbiB0byBwcm92aWRlPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIG5ldyBjb25u ZWN0aW9uIElEIGZvciB0aGUgb3RoZXIgc2lkZSB0byB1c2UuIFRoZSBnZW5lcmFsIGFzc3VtcHRp b248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlz IHRoYXQgeW91IGNhbiBkbyB0aGlzIGF0IGFueSB0aW1lLCBqdXN0IGFzIHdpdGggY3VycmVudCBR VUlDLCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnRoYXQgYW55IHRpbWUgeW91IHNlbmQgdG8gYSBuZXcgcmVtb3RlIDMtdHVwbGUgeW91IHNo b3VsZCBjaGFuZ2UgQ0lEczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+aWYgeW91IGNhbi4gTm90ZSB0aGF0IHRoaXMgbWVhbnMgdGhhdCBlbmRwb2lu dHMgc2hvdWxkIHRyeSB0byBtYWtlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5zdXJlIHRoYXQgdGhlIG90aGVyIHNpZGUgaGFzIHNwYXJlIENJRHMg aW4gY2FzZSB0aGV5IG5lZWQgdG8gbWlncmF0ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XSVJFIEVOQ09ESU5HPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyB3ZSBkaXNjdXNzZWQgaW4g dGhlIG1lZXRpbmcgdGhlIHNob3J0IGhlYWRlciBzaG91bGQganVzdCBoYXZlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbiBpbXBsaWNpdCBsZW5n dGggQ0lELiBUaGlzIGdpdmVzIHVzIHRoZSBmb2xsb3dpbmcgc2hvcnQgaGVhZGVyOjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDt8MHxDfEt8IFR5cGUgKDUpfDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7JiM0MzsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7W0Nvbm5lY3Rpb24gSUQg KCopXSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzsmbmJzcDsgJmx0Oy0gY2hhbmdlIGZy b20gNjQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3w8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3wm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFBhY2tldCBOdW1iZXIgKDgvMTYvMzIpJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAuLi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UHJvdGVj dGVkIFBheWxvYWQgKCopJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Li4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Tm90ZSB0aGF0IHdlIG1heSBhbHNvIGJlIGFibGUgdG8gZGlzcGVuc2Ugd2l0aCB0aGUg QyBiaXQsIGlmIGVhY2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnNpZGUganVzdCBnZXRzIHRvIHNheSAmcXVvdDtzZW5kIG1lIHRoaXMgQ0lEIGV4 YWN0bHkmcXVvdDssIHdoeSBkbyB3ZSB3YW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byBzYXkgJnF1b3Q7aGVyZSBpcyBteSBDSUQgYnV0IHlv dSBjYW4gb21pdCBpdCZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBoYXZlIHNldmVyYWwgb3B0aW9ucyBhYm91dCB0aGUgbG9u ZyBoZWFkZXIuIFRoZSBmaXJzdCBxdWVzdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXMgd2hlcmUgcmVjdi1DSURzIGdvLiBJbiBwcmV2aW91 cyB2ZXJzaW9ucyBJIHN1Z2dlc3RlZCBwdXR0aW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGVtIGluIHRyYW5zcG9ydCBwYXJhbWV0ZXJzLCBv ciBlbHNld2hlcmUgaW4gdGhlIFRMUyBoYW5kc2hha2UsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbmQgdGhhdCBtaWdodCBzdGlsbCBiZSB2aWFi bGUsIHRob3VnaCBpdCBoYXMgc29tZSBkcmF3YmFja3MgWzBdLDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c28gdGhlIG90aGVyIGFsdGVybmF0aXZl IGlzIHRvIHB1dCBib3RoIENJRHMgaW4gaW4gdGhlIGxvbmcgaGVhZGVyLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB3b3VsZCBsb29rIHNv bWV0aGluZyBsaWtlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt8MXwmbmJzcDsgJm5ic3A7VHlwZSAoNykmbmJz cDsgfDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7fCZuYnNwOyBE Q0lELUxlbmd0aCZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzsmbmJzcDsgJm5ic3A7RHN0IENvbm5lY3Rpb24gSUQgKCopJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7fCZuYnNwOyBTQ0lELUxlbmd0aCZuYnNwOyB8Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzsmbmJzcDsg Jm5ic3A7U3JjIENvbm5lY3Rpb24gSUQgKCopJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQz OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7fCZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1ZlcnNpb24gKDMyKSZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQYWNrZXQgTnVtYmVyICgzMikmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw O3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUGF5bG9hZCAoKikmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUg c2VtYW50aWNzIGhlcmUgYXJlIHRoYXQgdGhlIGZpcnN0IHZhbHVlIGlzIHRoZSBDSUQgeW91IHdh bnQgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnNlbmQgdG8gYW5kIHRoZSBzZWNvbmQgb25lIGlzIHRoZSB2YWx1ZSB5b3Ugd2FudCB1c2VkIHRv IHNlbmQgdG8geW91PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4oSSd2ZSBpbnZlcnRlZCB0aGVzZSB0byBrZWVwIHRoZSBvcmRlciB0aGUgc2FtZSBh cyBzaG9ydCBoZWFkZXIpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Ud28gbm90ZXMgYWJvdXQgdGhpcyBlbmNvZGluZzo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MS4gSSB0aGluayB3ZSBh Z3JlZWQgdGhhdCB3ZSBkaWRuJ3Qgd2FudCBhcmJpdHJhcnkgbGVuZ3RoIENJRHMgdXAgdG88bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjI1NSBieXRl cywgYW5kIHlldCB3ZSBoYXZlIHJvb20gaW4gdGhpcyBsZW5ndGggYnl0ZS4gSSBwcm9wb3NlIHdl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5saW1p dCBpdCB0byAzMSBieXRlcyBhbmQgdGhlbiBncmVhc2UgdGhlIHJlbWFpbmluZyAzIGJpdHMgWzFd LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4y LiBCZWNhdXNlIHRoZSBjbGllbnQgc2VuZHMgaXRzIENJRCBmaXJzdCwgdGhlcmUncyBubyB3YXkg dG8gZ2V0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Y3VycmVudCBRVUlDIHNlbWFudGljcyBvZiB0aGUgc2VydmVyIGp1c3QgZGljdGF0ZXMg dGhlIENJRC4mbmJzcDsgSSBwcm9wb3NlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj53ZSBmaXggdGhhdCBieSBkZWZpbmluZyBhIHNwZWNpYWwgc2Vu dGluZWwgQ0lEIChhbGwgMXMsIGFsbCAwcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPndoYXRldmVyKSBvZiB3aGF0ZXZlciBvdXIgbWF4aW11bSBs ZW5ndGggaXMgdGhhdCBtZWFucyAmcXVvdDtqdXN0IHVzZSB5b3VyPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vd24gQ0lEJnF1b3Q7LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBjYW4gZW5k bGVzc2x5IGJpa2VzaGVkIG9uIHRoaXMgc3RydWN0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpbmFsbHksIHdlIHdpbGwgbmVlZCB0 byB1cGRhdGUgTkVXX0NPTk5FQ1RJT05fSUQgdG8gYWxsb3cgYSB2YXJpYWJsZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bGVuZ3RoIENJRC4gVGhp cyB3b3VsZCBsb29rIGxpa2UgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAwJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOzImbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDszPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0 IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBT ZXF1ZW5jZSAoaSkmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy4uLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7fCZuYnNwOyBDSUQtTGVuZ3RoJm5ic3A7ICZuYnNw O3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0Nvbm5lY3Rpb24gSUQgKCopJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O1N0YXRlbGVzcyBSZXNldCBUb2tlbiAoMTI4KSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQz OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQz OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMF0gSG93ZXZlciwg aW4gdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGRlc2lnbiwgaWYgdGhlIHNlcnZlcidzPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5oYW5kc2hha2Ug Z2V0cyByZW9yZGVyZWQsIHRoZSBjbGllbnQgbWlnaHQgbmVlZCB0byBzZW5kIHNvbWUgQUNLcyB3 aXRoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50 aGUgaW5pdGlhbCBDSUQuIEhvd2V2ZXIsIHdlJ3ZlIGFncmVlZCB0aGF0IHRoZSBjbGllbnQncyBJ UCBhZGRyZXNzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5oYXMgdG8gYmUgc3RhYmxlLCBzbyB0aGlzIGlzbid0IGEgcHJvYmxlbS4gQWx0ZXJuYXRl bHksIHlvdSBjb3VsZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Y2hhbmdlIEMtJmd0O1MgQ0lEcyBpbiB0aGUgc2hvcnQgaGVhZGVyIGlmIHRoYXQg d2FzIGVhc2llci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WzFdIEFuIGFsdGVybmF0aXZlIHdvdWxkIGJlIHRvIGhhdmUgYSBzcGFyc2UgcmFu Z2UgKGUuZy4sIHlvdSBjYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPmV4cHJlc3MgMC03IGFuZCB0aGVuIDgtMjIgYnkgMnMsIGFzc3VtaW5nIEkg aGF2ZSBjb3VudGVkIGNvcnJlY3RseSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmFuZCB0aGVuIHdlIGNvdWxkIHBhY2sgYm90aCBsZW5ndGhzIGlu dG8gYSBzaW5nbGUgYnl0ZS4gQXMgSSBzYWlkLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bG90cyBvZiBvcHBvcnR1bml0aWVzIGZvciBiaWtlc2hl ZGRpbmcgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_7286e675a5c944e08d80e38c314eb103usma1exdag1mb5msgcorpak_-- From nobody Fri Feb 16 09:49:43 2018 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 61917124C27 for ; Fri, 16 Feb 2018 09:49:41 -0800 (PST) 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, 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=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 rxSwh3jOyGS0 for ; Fri, 16 Feb 2018 09:49:35 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 E49271200C1 for ; Fri, 16 Feb 2018 09:49:34 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id f18so3408449otf.6 for ; Fri, 16 Feb 2018 09:49:34 -0800 (PST) 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=Qfw8BoXrk48M4poXYGrzWKWMjc+OwDpH2nGdT737daw=; b=Jf3hrOAziYYRA988Pk17Q8pBB7dAGgGx3+NhdfKECsNTt/Rz1nox6ZIn1eZT/29fDB RrsQq2VMotiTN+i/DegqtlQityicEGJ82VM7Hp6h5WWkCsoHF7UyhwXR2HwtamCtC8n9 i3y474ELiLy8d0VSpwzbJ05aPsCB/4J/54mqqlFq+5RjYLtooes4uG1fHRHFLz+5gfaR E6FXxH3F54eDwNIi6UvC/g9/aUAtpvBk7g4GcrB/tiBZHBFWxAU9d3SwnKkGxFd3NXKf 2CYIkrTcjrS28AIs18bPBRcLhcIpncOjDpt64nZjCqec4VX7bl13//bk7BwJkPs401Bz A3xg== 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=Qfw8BoXrk48M4poXYGrzWKWMjc+OwDpH2nGdT737daw=; b=Z6d5tViJ4RP/qplcAs9nM39tSPUzlfRGY8L/TIlABlXabzDhQ4dLI3Zy7M9v1ND7f4 i8iBoj/gteiCiFJKcptm3pArvQVGqFL/mi1wEr6RzqEl5VlRT/ekZJf5LlNkayHgR0ew TRYJXFX4yZenY4N440RvWzLepHOai97xP3hWfOq8g96t4dOapuTzSlT38kQ41fG7eYcw Lx1zu8Yw3vtjJ8UQk6EJhpSB9IQBtht4IboVAkwezmUkDnZWYFRsV/V5BSEjybqI2/07 LxFHOqKywAf00LOW1IfHjLdRo7KZpFMWN5GgrbkrfxMMKPtq7Zch+8QSKubz7h5jwSlf 8QVA== X-Gm-Message-State: APf1xPCvBKepLYX4RecxBR7PdIDrVpu9vmk/LjasKX3AtT2Sz5CrHHi0 ktQNg/XgHBw5b1K2dNBhA4u72OUkyEHjyRSba7M= X-Google-Smtp-Source: AH8x224di82HWdIWkh2jJSyOb03TEoSpiX1A0aVLls77as0fNVJ3Gg4qWwWXtheTk7uNzHttyFpYI8hGNX5lJX6thX8= X-Received: by 10.157.24.14 with SMTP id b14mr5457906ote.195.1518803373921; Fri, 16 Feb 2018 09:49:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.3.71 with HTTP; Fri, 16 Feb 2018 09:49:03 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Fri, 16 Feb 2018 09:49:03 -0800 Message-ID: Subject: Re: Asymmetric CIDs To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a113dc276961a28056557f7c0" 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, 16 Feb 2018 17:49:41 -0000 --001a113dc276961a28056557f7c0 Content-Type: text/plain; charset="UTF-8" Thanks for the write-up, some questions in-line. On Fri, Feb 16, 2018 at 9:01 AM, Eric Rescorla wrote: > Hi folks, > > After a bunch of discussion, the CID task force came down to rough > consensus that asymmetric conn IDs were probably the right > direction (CID task force members, please feel free to voice dissent > here). Here's a complete writeup of what I think would be needed > for asymmetric connection IDs. It's not a PR, because I think > something self-contained is cleaner. > > Note that if we adopt this direction, we would be sacrificing > public reset under some conditions (see previous emails to the > list) and we would need to decide if it was worth keeping at all. > > > OVERVIEW > The basic idea is that each side gets to dictate the connection IDs > that are used to send to it. During the handshake, you establish those > CIDs and then each side can issue new CIDs during the connection. The > main advantage of this is that it allows for symmetric topologies in which > the client is also behind some kind of stateless LB/router rather than > just the server. See Issue #1091 for more info on this. > > > The overall handshake looks something like this: > > Client Server > > Initial [CID=XXX] {recv-CID=YYY} ----------------> > <-------------- Cleartext [CID=YYY] {recv-CID=ZZZ} > Cleartext [CID=ZZZ], {recv-CID=YYY} -------------> > <-------------------------- Short header [CID=YYY] > Short header [CID=ZZZ] --------------------------> > > > The client's initial CID (XXX) is special, and either consists of > > (a) a randomly chosen dummy CID. Proposal: require this to be > 8 bytes or at least a minimum. This should be the same > for all Initial packets in a connection (unless a stateless > reject is received, as below). > (b) a CID which it received from the server in a stateless reject > > All the server's packets are sent with the client's receive CID (YYY) > and all subsequent client packets are sent with the server's receive > CID (ZZZ). The general rule is that you should send with the > connection ID that you most recently received (where recently > is defined as highest PN). > > Note: I believe it's safe to just use the sending CID as the mixin > for the KDF, but I haven't thought this entirely through yet. > For the client, is this the dummy randomly generated Initial CID? If not randomly generated appropriately, is there a risk here that the KDF isn't as strong (see my concern in a previous email)? > > Finally, you can send NEW_CONNECTION_ID in either direction to provide > a new connection ID for the other side to use. The general assumption > is that you can do this at any time, just as with current QUIC, and > that any time you send to a new remote 3-tuple you should change CIDs > if you can. Note that this means that endpoints should try to make > sure that the other side has spare CIDs in case they need to migrate. > Is there any sense in which you can "go back" to a previously used CID, or are they burned once a new one is used? The situation I'm thinking of is a variant of the parking lot problem--if someone goes in and out of range of a WiFi service for which they have a current DHCP lease, they can alternate between Cellular and WiFi without actually changing origin IP. Can they go back to a previously used CID in that case? My intuition is that this should be no, but the implication is that the stack of spare CIDs may need to be larger as a result; if we did allow it, then the minimum number of spare CIDs is a simple function of the number of available network interfaces. We could either estimate that and pick a number or ask each side to state how many spare CIDs they'd prefer (knowing they may get fewer). > > WIRE ENCODING > As we discussed in the meeting the short header should just have > an implicit length CID. This gives us the following short header: > > +-+-+-+-+-+-+-+-+ > |0|C|K| Type (5)| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + [Connection ID (*)] + <- > change from 64 > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number (8/16/32) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Protected Payload (*) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Note that we may also be able to dispense with the C bit, if each > side just gets to say "send me this CID exactly", why do we want > to say "here is my CID but you can omit it". > > > We have several options about the long header. The first question > is where recv-CIDs go. In previous versions I suggested putting > them in transport parameters, or elsewhere in the TLS handshake, > and that might still be viable, though it has some drawbacks [0], > so the other alternative is to put both CIDs in in the long header. > This would look something like: > > +-+-+-+-+-+-+-+-+ > |1| Type (7) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | DCID-Length | | > +-+-+-+-+-+-+-+-+ Dst Connection ID (*) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | SCID-Length | | > +-+-+-+-+-+-+-+-+ Src Connection ID (*) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version (32) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number (32) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload (*) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The semantics here are that the first value is the CID you want to > send to and the second one is the value you want used to send to you > (I've inverted these to keep the order the same as short header). > > Two notes about this encoding: > > 1. I think we agreed that we didn't want arbitrary length CIDs up to > 255 bytes, and yet we have room in this length byte. I propose we > limit it to 31 bytes and then grease the remaining 3 bits [1]. > > 2. Because the client sends its CID first, there's no way to get the > current QUIC semantics of the server just dictates the CID. I propose > we fix that by defining a special sentinel CID (all 1s, all 0s, > whatever) of whatever our maximum length is that means "just use your > own CID". > > We can endlessly bikeshed on this structure. > > Well, it's only worth painting if there are bikes coming in. I'm not sure at this point what having the server dictate both sides of this gives you in a structure that presumes they are asymmetric. > Finally, we will need to update NEW_CONNECTION_ID to allow a variable > length CID. This would look like this: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Sequence (i) ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | CID-Length | | > +-+-+-+-+-+-+-+-+ Connection ID (*) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + + > | | > + Stateless Reset Token (128) + > | | > + + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Ted > > > [0] However, in the transport parameters design, if the server's > handshake gets reordered, the client might need to send some ACKs with > the initial CID. However, we've agreed that the client's IP address > has to be stable, so this isn't a problem. Alternately, you could > change C->S CIDs in the short header if that was easier. > > [1] An alternative would be to have a sparse range (e.g., you can > express 0-7 and then 8-22 by 2s, assuming I have counted correctly) > and then we could pack both lengths into a single byte. As I said, > lots of opportunities for bikeshedding here. > > --001a113dc276961a28056557f7c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the write-up, some questions in-line.

On Fri, Feb 16, 2018 at= 9:01 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

Aft= er a bunch of discussion, the CID task force came down to rough
c= onsensus that asymmetric conn IDs were probably the right
directi= on (CID task force members, please feel free to voice dissent
her= e). Here's a complete writeup of what I think would be needed
for asymmetric connection IDs. It's not a PR, because I think
something self-contained is cleaner.

Note that i= f we adopt this direction, we would be sacrificing
public reset u= nder some conditions (see previous emails to the
list) and we wou= ld need to decide if it was worth keeping at all.

=
OVERVIEW
The basic idea is that each side gets to = dictate the connection IDs
that are used to send to it. During th= e handshake, you establish those
CIDs and then each side can issu= e new CIDs during the connection.=C2=A0 The
main advantage of thi= s is that it allows for symmetric topologies in which
the client = is also behind some kind of stateless LB/router rather than
just = the server. See Issue #1091 for more info on this.


The overall handshake looks something like this:
=
Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Server

Initial [CID=3DXXX] {recv-CID=3DYYY}= ---------------->
<-------------- Cleartext [CID=3DYYY] {r= ecv-CID=3DZZZ}
Cleartext [CID=3DZZZ], {recv-CID=3DYYY} ----------= --->
<-------------------------- Short header [CID=3DYYY]
Short header [CID=3DZZZ] -------------------------->
=

The client's initial CID (XXX) is special= , and either consists of

=C2=A0 =C2=A0 (a) a rando= mly chosen dummy CID. Proposal: require this to be
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 8 bytes or at least a minimum. This should be the same
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 for all Initial packets in a connection (un= less a stateless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reject is received, = as below).
=C2=A0 =C2=A0 (b) a CID which it received from the ser= ver in a stateless reject

All the server's pac= kets are sent with the client's receive CID (YYY)
and all sub= sequent client packets are sent with the server's receive
CID= (ZZZ). The general rule is that you should send with the
connect= ion ID that you most recently received (where recently
is defined= as highest PN).

Note: I believe it's safe to = just use the sending CID as the mixin
for the KDF, but I haven= 9;t thought this entirely through yet.

For the client, is this the dummy randomly generated Initial CID?

If not randomly generated appropriately, is the= re a risk here that the KDF isn't as strong (see my concern in a previo= us email)?
=C2=A0

Finally, you can send NEW_CONNECTION_ID in ei= ther direction to provide
a new connection ID for the other side = to use. The general assumption
is that you can do this at any tim= e, just as with current QUIC, and
that any time you send to a new= remote 3-tuple you should change CIDs
if you can. Note that this= means that endpoints should try to make
sure that the other side= has spare CIDs in case they need to migrate.
=
Is there any sense in which you can "go back" to a= previously used CID, or are they burned once a new one is used?=C2=A0 The = situation I'm thinking of is a variant of the parking lot problem--if s= omeone goes in and out of range of a WiFi service for which they have a cur= rent DHCP lease, they can alternate between Cellular and WiFi without actua= lly changing origin IP.=C2=A0 Can they go back to a previously used CID in = that case?=C2=A0 My intuition is that this should be no, but the implicatio= n is that the stack of spare CIDs may need to be larger as a result; if we = did allow it, then the=C2=A0 minimum number of spare CIDs is a simple funct= ion of the number of available network interfaces.=C2=A0 We could either es= timate that and pick a number or ask each side to state how many spare CIDs= they'd prefer (knowing they may get fewer).
=C2=A0
=C2=A0
<= /div>

WIRE ENCODING
As we discussed in the mee= ting the short header should just have
an implicit length CID. Th= is gives us the following short header:

=C2=A0 =C2= =A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|0|C|K| Type (5)|
=C2= =A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= wbr>-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Connecti= on ID (*)]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+=C2=A0 <- change from 64
=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =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 Number (8/16= /32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Protected Payload (*)=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2= =A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= wbr>-+-+-+

Note that we may also be able to dispen= se with the C bit, if each
side just gets to say "send me th= is CID exactly", why do we want
to say "here is my CID = but you can omit it".


We have = several options about the long header. The first question
is wher= e recv-CIDs go. In previous versions I suggested putting
them in = transport parameters, or elsewhere in the TLS handshake,
and that= might still be viable, though it has some drawbacks [0],
so the = other alternative is to put both CIDs in in the long header.
This= would look something like:

=C2=A0 =C2=A0+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|1|=C2=A0 =C2=A0Type (7)=C2=A0 |
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 DCID-Length=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0Dst Connec= tion ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 SCID-Length=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0Src Connection ID (*)=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Version (32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet Number (32)=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Payload (*)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+

The semantics here= are that the first value is the CID you want to
send to and the = second one is the value you want used to send to you
(I've in= verted these to keep the order the same as short header).

Two notes about this encoding:

1. I think = we agreed that we didn't want arbitrary length CIDs up to
255= bytes, and yet we have room in this length byte. I propose we
li= mit it to 31 bytes and then grease the remaining 3 bits [1].

=
2. Because the client sends its CID first, there's no way to= get the
current QUIC semantics of the server just dictates the C= ID.=C2=A0 I propose
we fix that by defining a special sentinel CI= D (all 1s, all 0s,
whatever) of whatever our maximum length is th= at means "just use your
own CID".

<= /div>
We can endlessly bikeshed on this s= tructure.

Well, it's only w= orth painting if there are bikes coming in. I'm not sure at this point = what having the server dictate both sides of this gives you in a structure = that presumes they are asymmetric.=C2=A0


Final= ly, we will need to update NEW_CONNECTION_ID to allow a variable
= length CID. This would look like this:

=C2=A0 =C2= =A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Seque= nce (i)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0= CID-Length=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+= -+-+-+-+-+-+=C2=A0 =C2=A0 =C2=A0 =C2=A0Connection ID (*)=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= wbr>-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /div>
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 = =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Stateless Reset Token (128)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+<= /div>
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Ted
=C2=A0


=
[0] However, in the transport parameters design, if the server&#= 39;s
handshake gets reordered, the client might need to send some= ACKs with
the initial CID. However, we've agreed that the cl= ient's IP address
has to be stable, so this isn't a probl= em. Alternately, you could
change C->S CIDs in the short heade= r if that was easier.

[1] An alternative would be = to have a sparse range (e.g., you can
express 0-7 and then 8-22 b= y 2s, assuming I have counted correctly)
and then we could pack b= oth lengths into a single byte. As I said,
lots of opportunities = for bikeshedding here.


--001a113dc276961a28056557f7c0-- From nobody Fri Feb 16 09:52:50 2018 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 A9BD1124C27 for ; Fri, 16 Feb 2018 09:52:48 -0800 (PST) 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 jM9vScvYnQ28 for ; Fri, 16 Feb 2018 09:52:46 -0800 (PST) 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 AC4B11200C1 for ; Fri, 16 Feb 2018 09:52:45 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id k87so4595976wmi.0 for ; Fri, 16 Feb 2018 09:52:45 -0800 (PST) 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=VnwlaxtUpMXMTnWTkXteQwV01THz6bLQrYszky1NbAk=; b=SkZCOKjW2OVjFpPJftC7Di3mCJgZxUr2Tl8ajGBFfCQfPEYzD9TAHFp1OAjIiUzo3I lSrVYaOglutYv/F90Y14DR9PC5O0MspTCEso5HZTOFbOakWe+KD2su648ZMmaOu55WH0 PMgPmR/ljQ8llxvgxN/M18EQkLeC1r/+ExVyDXysnVqISYJo8ubn5xda3XDzE2iQL5kP vwIBkobz+6jthUyhfhtZHTf/Iv5smJ8QzHJjmbzW1hlL7cqTRCSm0QjAbsP0ItMtJhdJ W1FRu58biqRc8BfBAhl3106czwCcmhoSwWFefEib6bEGSRIe41FgtA8tpzJ5s28SY4Qp 2tmQ== 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=VnwlaxtUpMXMTnWTkXteQwV01THz6bLQrYszky1NbAk=; b=M+k1h884MCBLm64SXDzd3CQN7sBF/QPmHTfhuILXWY6xH9IV2IM/V3ciCHanz6rvsH ULeFbNJoqYYSIl05lWQc1TFrNVWBcAlkKS5ii3yhX1Re2Q0Th7vm9rlbJ5Jjj7Sw/L6d i57X9ASUE5NfTqinN81t8/3I/QWiZ+5yiQK9egwkKjEQUC4488piHp2E9yeip1N/Z5E2 sy2ZFWI0InahU/Q2xB5N9OrpHIBcYQE1ELDDkvpZ5fXgDSFn0keArVxuGwnIj1Xqb0dU CD3gCb9aKVaBZYXeO993Sz4z5NwEAfT2ofG4iFM8ArwalDu2/JLaSKJ/DHmWqJear10p FJKg== X-Gm-Message-State: APf1xPAm2AogyV3I8P5Ix8OaxcnXpwit20LGEGsqWpXlxyqDwzsm9OLj H1teYrvQ9ZRhtkwYusWg/RK+dKhfJk47IAdDK6o= X-Google-Smtp-Source: AH8x226ngEqS+VVP5lPsPqGRzOh9VsqxWfiekfaoJZHY9veRe2LYYFt9KwLoL+hRTKG5St4Re1Xr7qNx+QfIdT5tSxg= X-Received: by 10.28.66.77 with SMTP id p74mr5293035wma.115.1518803564039; Fri, 16 Feb 2018 09:52:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.166.71 with HTTP; Fri, 16 Feb 2018 09:52:43 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Fri, 16 Feb 2018 09:52:43 -0800 Message-ID: Subject: Re: Asymmetric CIDs To: Ian Swett Cc: Eric Rescorla , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0742eceb133c0565580252" 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, 16 Feb 2018 17:52:49 -0000 --94eb2c0742eceb133c0565580252 Content-Type: text/plain; charset="UTF-8" Thanks for writing this up, ekr. This incorporates many of the suggestions I made in objection to this project (perhaps coincidentally) and I like it a lot. Advantages of this: - In the common case where most of the data is server->client, clients can get away with shorter Conn IDs to reduce overhead. - Omit-conn-id just becomes a case where length = 0. Does this sidestep some of Google's transition issues? - If a client sends NEW_CONNECTION_ID, that indicates an intention to migrate, and is a good cue for the server to send the same. We should add a SHOULD to specify this behavior. I must be missing something, however, regarding implicit CIDs. If there's a NAT rebinding, how is the server supposed to extract the CID? Furthermore, this obviates the entire concept of using Connection ID for routing; it's not obviously a savings to store CID length in a table vs. just storing the destination server. Lastly, if we encode the length somewhere that seems to solve the Stateless Reset issue. On Fri, Feb 16, 2018 at 9:25 AM, Ian Swett wrote: > Thanks for the excellent summary EKR. I like this design and think the > breakage of stateless reset in certain cases is acceptable, since it only > applies if both sides must have their preferred connection ID present in > order to route correctly, which is a use case that's impossible in the > status quo. I have not come up with any other downsides. > > On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla wrote: > >> Hi folks, >> >> After a bunch of discussion, the CID task force came down to rough >> consensus that asymmetric conn IDs were probably the right >> direction (CID task force members, please feel free to voice dissent >> here). Here's a complete writeup of what I think would be needed >> for asymmetric connection IDs. It's not a PR, because I think >> something self-contained is cleaner. >> >> Note that if we adopt this direction, we would be sacrificing >> public reset under some conditions (see previous emails to the >> list) and we would need to decide if it was worth keeping at all. >> >> >> OVERVIEW >> The basic idea is that each side gets to dictate the connection IDs >> that are used to send to it. During the handshake, you establish those >> CIDs and then each side can issue new CIDs during the connection. The >> main advantage of this is that it allows for symmetric topologies in which >> the client is also behind some kind of stateless LB/router rather than >> just the server. See Issue #1091 for more info on this. >> >> >> The overall handshake looks something like this: >> >> Client Server >> >> Initial [CID=XXX] {recv-CID=YYY} ----------------> >> <-------------- Cleartext [CID=YYY] {recv-CID=ZZZ} >> Cleartext [CID=ZZZ], {recv-CID=YYY} -------------> >> <-------------------------- Short header [CID=YYY] >> Short header [CID=ZZZ] --------------------------> >> >> >> The client's initial CID (XXX) is special, and either consists of >> >> (a) a randomly chosen dummy CID. Proposal: require this to be >> 8 bytes or at least a minimum. This should be the same >> for all Initial packets in a connection (unless a stateless >> reject is received, as below). >> (b) a CID which it received from the server in a stateless reject >> >> All the server's packets are sent with the client's receive CID (YYY) >> and all subsequent client packets are sent with the server's receive >> CID (ZZZ). The general rule is that you should send with the >> connection ID that you most recently received (where recently >> is defined as highest PN). >> >> Note: I believe it's safe to just use the sending CID as the mixin >> for the KDF, but I haven't thought this entirely through yet. >> >> Finally, you can send NEW_CONNECTION_ID in either direction to provide >> a new connection ID for the other side to use. The general assumption >> is that you can do this at any time, just as with current QUIC, and >> that any time you send to a new remote 3-tuple you should change CIDs >> if you can. Note that this means that endpoints should try to make >> sure that the other side has spare CIDs in case they need to migrate. >> >> >> WIRE ENCODING >> As we discussed in the meeting the short header should just have >> an implicit length CID. This gives us the following short header: >> >> +-+-+-+-+-+-+-+-+ >> |0|C|K| Type (5)| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + [Connection ID (*)] + <- >> change from 64 >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Packet Number (8/16/32) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Protected Payload (*) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Note that we may also be able to dispense with the C bit, if each >> side just gets to say "send me this CID exactly", why do we want >> to say "here is my CID but you can omit it". >> >> >> We have several options about the long header. The first question >> is where recv-CIDs go. In previous versions I suggested putting >> them in transport parameters, or elsewhere in the TLS handshake, >> and that might still be viable, though it has some drawbacks [0], >> so the other alternative is to put both CIDs in in the long header. >> This would look something like: >> >> +-+-+-+-+-+-+-+-+ >> |1| Type (7) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | DCID-Length | | >> +-+-+-+-+-+-+-+-+ Dst Connection ID (*) + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SCID-Length | | >> +-+-+-+-+-+-+-+-+ Src Connection ID (*) + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Version (32) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Packet Number (32) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload (*) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> The semantics here are that the first value is the CID you want to >> send to and the second one is the value you want used to send to you >> (I've inverted these to keep the order the same as short header). >> >> Two notes about this encoding: >> >> 1. I think we agreed that we didn't want arbitrary length CIDs up to >> 255 bytes, and yet we have room in this length byte. I propose we >> limit it to 31 bytes and then grease the remaining 3 bits [1]. >> >> 2. Because the client sends its CID first, there's no way to get the >> current QUIC semantics of the server just dictates the CID. I propose >> we fix that by defining a special sentinel CID (all 1s, all 0s, >> whatever) of whatever our maximum length is that means "just use your >> own CID". >> >> We can endlessly bikeshed on this structure. >> >> >> Finally, we will need to update NEW_CONNECTION_ID to allow a variable >> length CID. This would look like this: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence (i) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | CID-Length | | >> +-+-+-+-+-+-+-+-+ Connection ID (*) + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + + >> | | >> + Stateless Reset Token (128) + >> | | >> + + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> [0] However, in the transport parameters design, if the server's >> handshake gets reordered, the client might need to send some ACKs with >> the initial CID. However, we've agreed that the client's IP address >> has to be stable, so this isn't a problem. Alternately, you could >> change C->S CIDs in the short header if that was easier. >> >> [1] An alternative would be to have a sparse range (e.g., you can >> express 0-7 and then 8-22 by 2s, assuming I have counted correctly) >> and then we could pack both lengths into a single byte. As I said, >> lots of opportunities for bikeshedding here. >> >> > --94eb2c0742eceb133c0565580252 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for writing this up, ekr. This incorporates many of= the suggestions I made in objection to this project (perhaps coincidentall= y) and I like it a lot.

Advantages of this:
- = In the common case where most of the data is server->client, clients can= get away with shorter Conn IDs to reduce overhead.
- Omit-conn-i= d just becomes a case where length =3D 0. Does this sidestep some of Google= 's transition issues?
- If a client sends NEW_CONNECTION_ID, = that indicates an intention to migrate, and is a good cue for the server to= send the same. We should add a SHOULD to specify this behavior.
=
I must be missing something, however, regarding implicit CID= s.

If there's a NAT rebinding, how is the serv= er supposed to extract the CID? Furthermore, this obviates the entire conce= pt of using Connection ID for routing; it's not obviously a savings to = store CID length in a table vs. just storing the destination server.
<= div>
Lastly, if we encode the length somewhere that seems to = solve the Stateless Reset issue.


On Fri, Feb 16, 2018 at 9:25 AM, = Ian Swett <ianswett@google.com> wrote:
Thanks for the excellent summary EKR.=C2=A0= I like this design and think the breakage of stateless reset in certain ca= ses is acceptable, since it only applies if both sides must have their pref= erred connection ID present in order to route correctly, which is a use cas= e that's impossible in the status quo.=C2=A0 I have not come up with an= y other downsides.

On Fri, Feb 16, 2018 at 12:= 01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

Afte= r a bunch of discussion, the CID task force came down to rough
co= nsensus that asymmetric conn IDs were probably the right
directio= n (CID task force members, please feel free to voice dissent
here= ). Here's a complete writeup of what I think would be needed
= for asymmetric connection IDs. It's not a PR, because I think
something self-contained is cleaner.

Note that if= we adopt this direction, we would be sacrificing
public reset un= der some conditions (see previous emails to the
list) and we woul= d need to decide if it was worth keeping at all.

<= br>
OVERVIEW
The basic idea is that each side gets to d= ictate the connection IDs
that are used to send to it. During the= handshake, you establish those
CIDs and then each side can issue= new CIDs during the connection.=C2=A0 The
main advantage of this= is that it allows for symmetric topologies in which
the client i= s also behind some kind of stateless LB/router rather than
just t= he server. See Issue #1091 for more info on this.

=
The overall handshake looks something like this:
<= br>
Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Server

Initial [CID=3DXXX] {recv-CID=3DYYY} --= -------------->
<-------------- Cleartext [CID=3DYYY] {recv= -CID=3DZZZ}
Cleartext [CID=3DZZZ], {recv-CID=3DYYY} -------------= >
<-------------------------- Short header [CID=3DYYY]
Short header [CID=3DZZZ] -------------------------->

The client's initial CID (XXX) is special, a= nd either consists of

=C2=A0 =C2=A0 (a) a randomly= chosen dummy CID. Proposal: require this to be
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 8 bytes or at least a minimum. This should be the same
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for all Initial packets in a connection (unles= s a stateless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reject is received, as = below).
=C2=A0 =C2=A0 (b) a CID which it received from the server= in a stateless reject

All the server's packet= s are sent with the client's receive CID (YYY)
and all subseq= uent client packets are sent with the server's receive
CID (Z= ZZ). The general rule is that you should send with the
connection= ID that you most recently received (where recently
is defined as= highest PN).

Note: I believe it's safe to jus= t use the sending CID as the mixin
for the KDF, but I haven't= thought this entirely through yet.

Finally, you c= an send NEW_CONNECTION_ID in either direction to provide
a new co= nnection ID for the other side to use. The general assumption
is = that you can do this at any time, just as with current QUIC, and
= that any time you send to a new remote 3-tuple you should change CIDs
=
if you can. Note that this means that endpoints should try to make
sure that the other side has spare CIDs in case they need to migrate= .


WIRE ENCODING
As we dis= cussed in the meeting the short header should just have
an implic= it length CID. This gives us the following short header:

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|0|C|K| Type (= 5)|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 = =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Connection ID (*)]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 <- change from 64
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packe= t Number (8/16/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .= ..
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Protected Payload (*)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+

Note that we may also be abl= e to dispense with the C bit, if each
side just gets to say "= ;send me this CID exactly", why do we want
to say "here= is my CID but you can omit it".


We have several options about the long header. The first question
<= div>is where recv-CIDs go. In previous versions I suggested putting
them in transport parameters, or elsewhere in the TLS handshake,
and that might still be viable, though it has some drawbacks [0],
<= div>so the other alternative is to put both CIDs in in the long header.
This would look something like:

=C2=A0 =C2= =A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|1|=C2=A0 =C2=A0Type (7)=C2=A0 = |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 DCID-Length=C2=A0 = |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0= Dst Connection ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2= =A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= wbr>-+-+-+
=C2=A0 =C2=A0|=C2=A0 SCID-Length=C2=A0 |=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0Src Connection= ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Version (32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet Number (32)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Payload (*)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The semanti= cs here are that the first value is the CID you want to
send to a= nd the second one is the value you want used to send to you
(I= 9;ve inverted these to keep the order the same as short header).
=
Two notes about this encoding:

1. I= think we agreed that we didn't want arbitrary length CIDs up to
<= div>255 bytes, and yet we have room in this length byte. I propose we
=
limit it to 31 bytes and then grease the remaining 3 bits [1].

2. Because the client sends its CID first, there's no= way to get the
current QUIC semantics of the server just dictate= s the CID.=C2=A0 I propose
we fix that by defining a special sent= inel CID (all 1s, all 0s,
whatever) of whatever our maximum lengt= h is that means "just use your
own CID".

=
We can endlessly bikeshed on this structure.


Finally, we will need to update NEW_CONNECTION_ID to a= llow a variable
length CID. This would look like this:
=
=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Sequence (i)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 CID-Length=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /div>
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0 =C2=A0 =C2=A0Connecti= on ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Stateless Reset Token (128)=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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] However, in the t= ransport parameters design, if the server's
handshake gets re= ordered, the client might need to send some ACKs with
the initial= CID. However, we've agreed that the client's IP address
= has to be stable, so this isn't a problem. Alternately, you could
=
change C->S CIDs in the short header if that was easier.
=
[1] An alternative would be to have a sparse range (e.g., yo= u can
express 0-7 and then 8-22 by 2s, assuming I have counted co= rrectly)
and then we could pack both lengths into a single byte. = As I said,
lots of opportunities for bikeshedding here.



--94eb2c0742eceb133c0565580252-- From nobody Fri Feb 16 10:15:36 2018 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 581FA1200C1 for ; Fri, 16 Feb 2018 10:15:35 -0800 (PST) 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 C7dbbQIj4Gf4 for ; Fri, 16 Feb 2018 10:15:32 -0800 (PST) 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 A0383129515 for ; Fri, 16 Feb 2018 10:15:31 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1emkXd-0003bG-Q1 for quic@ietf.org; Fri, 16 Feb 2018 19:15:29 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1emkXS-0006sa-Oi for quic@ietf.org; Fri, 16 Feb 2018 13:15:20 -0500 Received: (qmail 17637 invoked from network); 16 Feb 2018 18:15:06 -0000 Received: from unknown (HELO [192.168.1.102]) (Authenticated-user:_huitema@huitema.net@[172.56.42.15]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Feb 2018 18:14:59 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-5360B801-F24E-4074-BD1C-633DD2DBA600 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15D60) In-Reply-To: Date: Fri, 16 Feb 2018 08:14:57 -1000 Cc: Ian Swett , Eric Rescorla , IETF QUIC WG Content-Transfer-Encoding: 7bit Message-Id: References: To: Martin Duke Subject: Re: Asymmetric CIDs X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.42) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5g1VrvYOmBIHi52D440i0wp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVivJRpx5P6MruxD1GllRPlX87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBy0LkIcQZ+RRGzUcmNZyDXh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYg8fO0sqTNbFIxwq5nK+B tNm4YXH+1fMTrNbJKTtzvwOdxCO5CCKrpBmx6d8NosRZXrsVnlgJAwCslL3Wle4MwAfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4Da Q6mrvkz1ms5n2i5GFAoJSGG/BQd7r2NVEaNhWos5pnlmhjstJS63RQEec9TqGd8ccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtkqah8tX/yBccUywZq2FP6SBi6owqeb+h1kbxIVWYdC7N1zg 8T9ahw4hquQDupK1jleqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g== 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: Fri, 16 Feb 2018 18:15:35 -0000 --Apple-Mail-5360B801-F24E-4074-BD1C-633DD2DBA600 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I like the concept, but I would like to understand how we avoid linkability o= n migration. -- Christian Huitema=20 > On Feb 16, 2018, at 7:52 AM, Martin Duke wrote: >=20 > Thanks for writing this up, ekr. This incorporates many of the suggestions= I made in objection to this project (perhaps coincidentally) and I like it a= lot. >=20 > Advantages of this: > - In the common case where most of the data is server->client, clients can= get away with shorter Conn IDs to reduce overhead. > - Omit-conn-id just becomes a case where length =3D 0. Does this sidestep s= ome of Google's transition issues? > - If a client sends NEW_CONNECTION_ID, that indicates an intention to migr= ate, and is a good cue for the server to send the same. We should add a SHOU= LD to specify this behavior. >=20 > I must be missing something, however, regarding implicit CIDs. >=20 > If there's a NAT rebinding, how is the server supposed to extract the CID?= Furthermore, this obviates the entire concept of using Connection ID for ro= uting; it's not obviously a savings to store CID length in a table vs. just s= toring the destination server. >=20 > Lastly, if we encode the length somewhere that seems to solve the Stateles= s Reset issue. >=20 >=20 >> On Fri, Feb 16, 2018 at 9:25 AM, Ian Swett wrote: >> Thanks for the excellent summary EKR. I like this design and think the b= reakage of stateless reset in certain cases is acceptable, since it only app= lies if both sides must have their preferred connection ID present in order t= o route correctly, which is a use case that's impossible in the status quo. = I have not come up with any other downsides. >>=20 >>> On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla wrote: >>> Hi folks, >>>=20 >>> After a bunch of discussion, the CID task force came down to rough >>> consensus that asymmetric conn IDs were probably the right >>> direction (CID task force members, please feel free to voice dissent >>> here). Here's a complete writeup of what I think would be needed >>> for asymmetric connection IDs. It's not a PR, because I think >>> something self-contained is cleaner. >>>=20 >>> Note that if we adopt this direction, we would be sacrificing >>> public reset under some conditions (see previous emails to the >>> list) and we would need to decide if it was worth keeping at all. >>>=20 >>>=20 >>> OVERVIEW >>> The basic idea is that each side gets to dictate the connection IDs >>> that are used to send to it. During the handshake, you establish those >>> CIDs and then each side can issue new CIDs during the connection. The >>> main advantage of this is that it allows for symmetric topologies in whi= ch >>> the client is also behind some kind of stateless LB/router rather than >>> just the server. See Issue #1091 for more info on this. >>>=20 >>>=20 >>> The overall handshake looks something like this: >>>=20 >>> Client Server >>>=20 >>> Initial [CID=3DXXX] {recv-CID=3DYYY} ----------------> >>> <-------------- Cleartext [CID=3DYYY] {recv-CID=3DZZZ} >>> Cleartext [CID=3DZZZ], {recv-CID=3DYYY} -------------> >>> <-------------------------- Short header [CID=3DYYY] >>> Short header [CID=3DZZZ] --------------------------> >>>=20 >>>=20 >>> The client's initial CID (XXX) is special, and either consists of >>>=20 >>> (a) a randomly chosen dummy CID. Proposal: require this to be >>> 8 bytes or at least a minimum. This should be the same >>> for all Initial packets in a connection (unless a stateless >>> reject is received, as below). >>> (b) a CID which it received from the server in a stateless reject >>>=20 >>> All the server's packets are sent with the client's receive CID (YYY) >>> and all subsequent client packets are sent with the server's receive >>> CID (ZZZ). The general rule is that you should send with the >>> connection ID that you most recently received (where recently >>> is defined as highest PN). >>>=20 >>> Note: I believe it's safe to just use the sending CID as the mixin >>> for the KDF, but I haven't thought this entirely through yet. >>>=20 >>> Finally, you can send NEW_CONNECTION_ID in either direction to provide >>> a new connection ID for the other side to use. The general assumption >>> is that you can do this at any time, just as with current QUIC, and >>> that any time you send to a new remote 3-tuple you should change CIDs >>> if you can. Note that this means that endpoints should try to make >>> sure that the other side has spare CIDs in case they need to migrate. >>>=20 >>>=20 >>> WIRE ENCODING >>> As we discussed in the meeting the short header should just have >>> an implicit length CID. This gives us the following short header: >>>=20 >>> +-+-+-+-+-+-+-+-+ >>> |0|C|K| Type (5)| >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> + [Connection ID (*)] + <-= change from 64 >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Packet Number (8/16/32) ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Protected Payload (*) ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> Note that we may also be able to dispense with the C bit, if each >>> side just gets to say "send me this CID exactly", why do we want >>> to say "here is my CID but you can omit it". >>>=20 >>>=20 >>> We have several options about the long header. The first question >>> is where recv-CIDs go. In previous versions I suggested putting >>> them in transport parameters, or elsewhere in the TLS handshake, >>> and that might still be viable, though it has some drawbacks [0], >>> so the other alternative is to put both CIDs in in the long header. >>> This would look something like: >>>=20 >>> +-+-+-+-+-+-+-+-+ >>> |1| Type (7) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | DCID-Length | | >>> +-+-+-+-+-+-+-+-+ Dst Connection ID (*) + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | SCID-Length | | >>> +-+-+-+-+-+-+-+-+ Src Connection ID (*) + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Version (32) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Packet Number (32) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Payload (*) ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>> The semantics here are that the first value is the CID you want to >>> send to and the second one is the value you want used to send to you >>> (I've inverted these to keep the order the same as short header). >>>=20 >>> Two notes about this encoding: >>>=20 >>> 1. I think we agreed that we didn't want arbitrary length CIDs up to >>> 255 bytes, and yet we have room in this length byte. I propose we >>> limit it to 31 bytes and then grease the remaining 3 bits [1]. >>>=20 >>> 2. Because the client sends its CID first, there's no way to get the >>> current QUIC semantics of the server just dictates the CID. I propose >>> we fix that by defining a special sentinel CID (all 1s, all 0s, >>> whatever) of whatever our maximum length is that means "just use your >>> own CID". >>>=20 >>> We can endlessly bikeshed on this structure. >>>=20 >>>=20 >>> Finally, we will need to update NEW_CONNECTION_ID to allow a variable >>> length CID. This would look like this: >>>=20 >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Sequence (i) ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | CID-Length | | >>> +-+-+-+-+-+-+-+-+ Connection ID (*) + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> + + >>> | | >>> + Stateless Reset Token (128) + >>> | | >>> + + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>=20 >>>=20 >>>=20 >>> [0] However, in the transport parameters design, if the server's >>> handshake gets reordered, the client might need to send some ACKs with >>> the initial CID. However, we've agreed that the client's IP address >>> has to be stable, so this isn't a problem. Alternately, you could >>> change C->S CIDs in the short header if that was easier. >>>=20 >>> [1] An alternative would be to have a sparse range (e.g., you can >>> express 0-7 and then 8-22 by 2s, assuming I have counted correctly) >>> and then we could pack both lengths into a single byte. As I said, >>> lots of opportunities for bikeshedding here. >>>=20 >>=20 >=20 --Apple-Mail-5360B801-F24E-4074-BD1C-633DD2DBA600 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I like the concept, but I would like to und= erstand how we avoid linkability on migration.

-- Christian Huitema 

On Feb 16, 2018, at 7:52 A= M, Martin Duke <martin.h.duke@= gmail.com> wrote:

Thanks for writing this up, ekr. This incorporates many of the sug= gestions I made in objection to this project (perhaps coincidentally) and I l= ike it a lot.

Advantages of this:
- In the comm= on case where most of the data is server->client, clients can get away wi= th shorter Conn IDs to reduce overhead.
- Omit-conn-id just become= s a case where length =3D 0. Does this sidestep some of Google's transition i= ssues?
- If a client sends NEW_CONNECTION_ID, that indicates an in= tention to migrate, and is a good cue for the server to send the same. We sh= ould add a SHOULD to specify this behavior.

I must b= e missing something, however, regarding implicit CIDs.

<= div>If there's a NAT rebinding, how is the server supposed to extract the CI= D? Furthermore, this obviates the entire concept of using Connection ID for r= outing; it's not obviously a savings to store CID length in a table vs. just= storing the destination server.

Lastly, if we enco= de the length somewhere that seems to solve the Stateless Reset issue.
=


On Fri, Feb 16, 2018 at 9:25 AM, Ian Swett <ianswett@google.com> wrote:
Thanks for th= e excellent summary EKR.  I like this design and think the breakage of s= tateless reset in certain cases is acceptable, since it only applies if both= sides must have their preferred connection ID present in order to route cor= rectly, which is a use case that's impossible in the status quo.  I hav= e not come up with any other downsides.

On Fri, Fe= b 16, 2018 at 12:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

After a bunch of discussion, the CID task force came down to rough
consensus that asymmetric conn IDs were probably the right
direction (CID task force members, please feel free to voice dissent
<= div>here). Here's a complete writeup of what I think would be needed
for asymmetric connection IDs. It's not a PR, because I think
s= omething self-contained is cleaner.

Note that if we= adopt this direction, we would be sacrificing
public reset under s= ome conditions (see previous emails to the
list) and we would need= to decide if it was worth keeping at all.


OVERVIEW
The basic idea is that each side gets to dictate t= he connection IDs
that are used to send to it. During the handshak= e, you establish those
CIDs and then each side can issue new CIDs d= uring the connection.  The
main advantage of this is that it a= llows for symmetric topologies in which
the client is also behind s= ome kind of stateless LB/router rather than
just the server. See I= ssue #1091 for more info on this.


Th= e overall handshake looks something like this:

Clie= nt                    &nbs= p;                 Server
=
Initial [CID=3DXXX] {recv-CID=3DYYY} ---------------->
<-------------- Cleartext [CID=3DYYY] {recv-CID=3DZZZ}
C= leartext [CID=3DZZZ], {recv-CID=3DYYY} ------------->
<-----= --------------------- Short header [CID=3DYYY]
Short header [CID=3D= ZZZ] -------------------------->


= The client's initial CID (XXX) is special, and either consists of
=
    (a) a randomly chosen dummy CID. Proposal: requ= ire this to be
        8 bytes or at least a m= inimum. This should be the same
        for al= l Initial packets in a connection (unless a stateless
   = ;     reject is received, as below).
    (b) a= CID which it received from the server in a stateless reject

<= /div>
All the server's packets are sent with the client's receive CID (Y= YY)
and all subsequent client packets are sent with the server's r= eceive
CID (ZZZ). The general rule is that you should send with th= e
connection ID that you most recently received (where recently
is defined as highest PN).

Note: I believe i= t's safe to just use the sending CID as the mixin
for the KDF, but= I haven't thought this entirely through yet.

Final= ly, you can send NEW_CONNECTION_ID in either direction to provide
= a new connection ID for the other side to use. The general assumption
<= div>is that you can do this at any time, just as with current QUIC, and
that any time you send to a new remote 3-tuple you should change CIDs<= /div>
if you can. Note that this means that endpoints should try to make=
sure that the other side has spare CIDs in case they need to migr= ate.


WIRE ENCODING
As we d= iscussed in the meeting the short header should just have
an impli= cit length CID. This gives us the following short header:

   +-+-+-+-+-+-+-+-+
   |0|C|K| Type (5= )|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
   |       = ;                     &nbs= p;                     &nb= sp;            |
   + = ;                    [Conn= ection ID (*)]                 =      +  <- change from 64
   |&n= bsp;                     &= nbsp;                     &= nbsp;                  |
<= div>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
   |          &= nbsp;           Packet Number (8/16/32)   = ;             ...
   +-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
   |                &= nbsp;    Protected Payload (*)          &= nbsp;        ...
   +-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that we may also be able to dispense with the C bit, if each
side just gets to say "send me this CID exactly", why do we want
to say "here is my CID but you can omit it".


We have several options about the long header. The first qu= estion
is where recv-CIDs go. In previous versions I suggested put= ting
them in transport parameters, or elsewhere in the TLS handsha= ke,
and that might still be viable, though it has some drawbacks [= 0],
so the other alternative is to put both CIDs in in the long he= ader.
This would look something like:

&nb= sp;  +-+-+-+-+-+-+-+-+
   |1|   Type (7)&= nbsp; |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+
   |  DCID-Length&nb= sp; |                    &= nbsp;                     &= nbsp;    |
   +-+-+-+-+-+-+-+-+   Ds= t Connection ID (*)                &= nbsp;      +
   |      &nb= sp;                     &n= bsp;                     &= nbsp;            |
   +-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  SCID-Length  |        &n= bsp;                     &= nbsp;                |
&nb= sp;  +-+-+-+-+-+-+-+-+   Src Connection ID (*)    &= nbsp;                  +
<= div>   |                &n= bsp;                     &= nbsp;                     &= nbsp;  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    &= nbsp;                    V= ersion (32)                  &n= bsp;       |
   +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |&= nbsp;                     &= nbsp;Packet Number (32)              &nbs= p;       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |&nb= sp;                     &n= bsp;   Payload (*)              &nbs= p;         ...
   +-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The semantics here are that the first value is the CID you want to
send to and the second one is the value you want used to send to you=
(I've inverted these to keep the order the same as short header).=

Two notes about this encoding:

1. I think we agreed that we didn't want arbitrary length CIDs up to
255 bytes, and yet we have room in this length byte. I propose we
limit it to 31 bytes and then grease the remaining 3 bits [1].

2. Because the client sends its CID first, there's no w= ay to get the
current QUIC semantics of the server just dictates t= he CID.  I propose
we fix that by defining a special sentinel= CID (all 1s, all 0s,
whatever) of whatever our maximum length is t= hat means "just use your
own CID".

We can= endlessly bikeshed on this structure.


Finally, we will need to update NEW_CONNECTION_ID to allow a variable
length CID. This would look like this:

 = ;   0                  &nb= sp;1                   2&n= bsp;                  3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+
   |      &nb= sp;                   Sequence (= i)                    &nbs= p;  ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  CID-Lengt= h   |                 = ;                     &nbs= p;        |
   +-+-+-+-+-+-+-+-+&nbs= p;      Connection ID (*)          &= nbsp;            +
   |&nb= sp;                     &n= bsp;                     &= nbsp;                  |
<= div>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
   |          &= nbsp;                     &= nbsp;                     &= nbsp;        |
   +    &nb= sp;                     &n= bsp;                     &= nbsp;              +
  &nb= sp;|                    &n= bsp;                     &= nbsp;                    |=
   +              &n= bsp;    Stateless Reset Token (128)        &nb= sp;        +
   |     = ;                     &nbs= p;                     &nb= sp;              |
   = ;+                    &nbs= p;                     &nb= sp;                    +
   |              &nbs= p;                     &nb= sp;                     &n= bsp;    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



[0] However, in the transport parameters design, if th= e server's
handshake gets reordered, the client might need to send= some ACKs with
the initial CID. However, we've agreed that the cl= ient's IP address
has to be stable, so this isn't a problem. Alter= nately, you could
change C->S CIDs in the short header if that w= as easier.

[1] An alternative would be to have a sp= arse range (e.g., you can
express 0-7 and then 8-22 by 2s, assumin= g I have counted correctly)
and then we could pack both lengths in= to a single byte. As I said,
lots of opportunities for bikesheddin= g here.



= --Apple-Mail-5360B801-F24E-4074-BD1C-633DD2DBA600-- From nobody Fri Feb 16 10:26:26 2018 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 6FF88129C6E for ; Fri, 16 Feb 2018 10:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (1024-bit key) header.d=fb.com header.b=fxpkJMl5; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Wz6EoKDD 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 DkwBaeTVeKM1 for ; Fri, 16 Feb 2018 10:26:22 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 6324A1200C1 for ; Fri, 16 Feb 2018 10:26:22 -0800 (PST) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1GIE8K6000834; Fri, 16 Feb 2018 10:26:13 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=fRh/x9tX9JURrcoHQwzNOJLRL5JY9RBQOceyhEZVLY4=; b=fxpkJMl5ho+KGrk6U3EuszUWncWBBH1Pv7t/axaoAS4ktZcKCqj6LmtT+Lp+nB0F3Yc9 F6CIbA0Qb3WXCqgyhUSb1UCj1oGDXRgd3CZTx/RNpeF+hd+3ILGGsyUnXOIxE9RvG6Kf 3ba2Hsi9Tt26WkWazEjXE6XCQ0ksq3ihQnU= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2g604csus6-16 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Feb 2018 10:26:13 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.23) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 16 Feb 2018 10:25:59 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fRh/x9tX9JURrcoHQwzNOJLRL5JY9RBQOceyhEZVLY4=; b=Wz6EoKDDGDMfOQfZRPNufo0JKho1txW9zPD3mKfWJ4YqZNyZ+UBdxmUlXuY21yagb98SrN6YRAHXRUUrlPYc0KBaggRtXdfiAlGwwNKVgG9h+i4pIwru/G3IwODUhusWsiA+MjD9vZu1SvFSTBXLJymuZz0HexpvSUO5uyUawNY= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0231.namprd15.prod.outlook.com (10.163.64.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 18:25:56 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0506.020; Fri, 16 Feb 2018 18:25:56 +0000 From: Roberto Peon To: Christian Huitema , Martin Duke CC: Ian Swett , IETF QUIC WG , "Eric Rescorla" Subject: Re: Asymmetric CIDs Thread-Topic: Asymmetric CIDs Thread-Index: AQHTp0fsUiwRXYubE0qEd47QbEYhNqOnR9oAgAAHeYCAAAY3gP//fPSA Date: Fri, 16 Feb 2018 18:25:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::7:3472] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0231; 7:SQGokSvikeFz6X30KkdsoNA1D2SUQCOihG2oQJW8PB0YuDVD61mg0HBQ4fKIaAcpRutNGO5+GH+JVjq0G4vgnoiRateEyfwbjcH7XRRKVuSDoIkC+JZHCm8hKgVDgumUr3+SxZd3Oi035kCILwI31PwYOQALxoy0vIFR/DH0SGAIaoAuDRnjMnl9tWvFmSdK6BQrvQu5Fg7CElSRWhWUv7Q69qg4WaBtMUC0RRq2IpFSLMW48QF5Vd4P6g5LBxt3; 20:5E7EFi478xsi7MnGGKyCSwJp501zs/+NG6Nm8mmc/zyOlrDY5oSKeQNhwWfATgvM8wZrn6i9mWIMeJWn5SfV2uuDTpe91qndx1UStRlCUeiU4OAmihwt2wAXrOYHImO6y1uAkBV5MttAdnHi2HOwDBAtiA1e70/jg+vg8o3Pq04= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e8b4306d-6902-4560-39be-08d5756ab885 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0231; x-ms-traffictypediagnostic: BY2PR15MB0231: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(85827821059158)(211936372134217)(100405760836317)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231101)(11241501184)(944501161)(6041288)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BY2PR15MB0231; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0231; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(346002)(39860400002)(376002)(396003)(189003)(199004)(51914003)(76176011)(82746002)(6116002)(102836004)(53936002)(3660700001)(2900100001)(236005)(6306002)(6512007)(54896002)(106356001)(6246003)(54906003)(99286004)(221733001)(110136005)(186003)(316002)(77096007)(68736007)(2906002)(7116003)(6436002)(93886005)(3480700004)(5660300001)(86362001)(83716003)(8936002)(7736002)(478600001)(36756003)(6486002)(53546011)(229853002)(3280700002)(2950100002)(105586002)(25786009)(33656002)(59450400001)(81166006)(81156014)(561944003)(8676002)(14454004)(39060400002)(97736004)(6506007)(4326008)(21314002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0231; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 0VhfvY6VNHQul5Qw7ChAbVPfSfz8SoQFVBwagTeOQ2LRxGutipYQwvFtep25ZS9RUFl+h4tSmnZkmMF+XmoRTA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_D7E469CDB9D841ED8F5C9933DCBA90E6fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e8b4306d-6902-4560-39be-08d5756ab885 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 18:25:56.4577 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0231 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-16_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 16 Feb 2018 18:26:25 -0000 --_000_D7E469CDB9D841ED8F5C9933DCBA90E6fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Kysgd2hhdCBDaHJpc3RpYW4gc2F5cy4NClRoZSBmYWN0IHRoYXQgaXQgbm93IHRha2VzIHR3byBp bXBsZW1lbnRhdGlvbnMgdG8gcHJldmVudCBsaW5rYWJpbGl0eSAoZWl0aGVyIHNpZGUgbWVzc2Vz IGl0IHVwLCBhbmQgdGhhdCBoYWxmLXBhdGggaXMgZXhwb3NlZCwgbGlrZWx5IHJlbmRlcmluZyBp dCBhbGwgZXhwb3NlZCkgaXMgYSBiaXQgc2FkLg0KLT1SDQoNCg0KRnJvbTogUVVJQyA8cXVpYy1i b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQ2hyaXN0aWFuIEh1aXRlbWEgPGh1aXRlbWFA aHVpdGVtYS5uZXQ+DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDE2LCAyMDE4IGF0IDEwOjE2IEFN DQpUbzogTWFydGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPg0KQ2M6IElhbiBTd2V0 dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT4sIElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4sIEVy aWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NClN1YmplY3Q6IFJlOiBBc3ltbWV0cmljIENJRHMN Cg0KSSBsaWtlIHRoZSBjb25jZXB0LCBidXQgSSB3b3VsZCBsaWtlIHRvIHVuZGVyc3RhbmQgaG93 IHdlIGF2b2lkIGxpbmthYmlsaXR5IG9uIG1pZ3JhdGlvbi4NCi0tIENocmlzdGlhbiBIdWl0ZW1h DQoNCk9uIEZlYiAxNiwgMjAxOCwgYXQgNzo1MiBBTSwgTWFydGluIER1a2UgPG1hcnRpbi5oLmR1 a2VAZ21haWwuY29tPG1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhh bmtzIGZvciB3cml0aW5nIHRoaXMgdXAsIGVrci4gVGhpcyBpbmNvcnBvcmF0ZXMgbWFueSBvZiB0 aGUgc3VnZ2VzdGlvbnMgSSBtYWRlIGluIG9iamVjdGlvbiB0byB0aGlzIHByb2plY3QgKHBlcmhh cHMgY29pbmNpZGVudGFsbHkpIGFuZCBJIGxpa2UgaXQgYSBsb3QuDQoNCkFkdmFudGFnZXMgb2Yg dGhpczoNCi0gSW4gdGhlIGNvbW1vbiBjYXNlIHdoZXJlIG1vc3Qgb2YgdGhlIGRhdGEgaXMgc2Vy dmVyLT5jbGllbnQsIGNsaWVudHMgY2FuIGdldCBhd2F5IHdpdGggc2hvcnRlciBDb25uIElEcyB0 byByZWR1Y2Ugb3ZlcmhlYWQuDQotIE9taXQtY29ubi1pZCBqdXN0IGJlY29tZXMgYSBjYXNlIHdo ZXJlIGxlbmd0aCA9IDAuIERvZXMgdGhpcyBzaWRlc3RlcCBzb21lIG9mIEdvb2dsZSdzIHRyYW5z aXRpb24gaXNzdWVzPw0KLSBJZiBhIGNsaWVudCBzZW5kcyBORVdfQ09OTkVDVElPTl9JRCwgdGhh dCBpbmRpY2F0ZXMgYW4gaW50ZW50aW9uIHRvIG1pZ3JhdGUsIGFuZCBpcyBhIGdvb2QgY3VlIGZv ciB0aGUgc2VydmVyIHRvIHNlbmQgdGhlIHNhbWUuIFdlIHNob3VsZCBhZGQgYSBTSE9VTEQgdG8g c3BlY2lmeSB0aGlzIGJlaGF2aW9yLg0KDQpJIG11c3QgYmUgbWlzc2luZyBzb21ldGhpbmcsIGhv d2V2ZXIsIHJlZ2FyZGluZyBpbXBsaWNpdCBDSURzLg0KDQpJZiB0aGVyZSdzIGEgTkFUIHJlYmlu ZGluZywgaG93IGlzIHRoZSBzZXJ2ZXIgc3VwcG9zZWQgdG8gZXh0cmFjdCB0aGUgQ0lEPyBGdXJ0 aGVybW9yZSwgdGhpcyBvYnZpYXRlcyB0aGUgZW50aXJlIGNvbmNlcHQgb2YgdXNpbmcgQ29ubmVj dGlvbiBJRCBmb3Igcm91dGluZzsgaXQncyBub3Qgb2J2aW91c2x5IGEgc2F2aW5ncyB0byBzdG9y ZSBDSUQgbGVuZ3RoIGluIGEgdGFibGUgdnMuIGp1c3Qgc3RvcmluZyB0aGUgZGVzdGluYXRpb24g c2VydmVyLg0KDQpMYXN0bHksIGlmIHdlIGVuY29kZSB0aGUgbGVuZ3RoIHNvbWV3aGVyZSB0aGF0 IHNlZW1zIHRvIHNvbHZlIHRoZSBTdGF0ZWxlc3MgUmVzZXQgaXNzdWUuDQoNCg0KT24gRnJpLCBG ZWIgMTYsIDIwMTggYXQgOToyNSBBTSwgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPG1h aWx0bzppYW5zd2V0dEBnb29nbGUuY29tPj4gd3JvdGU6DQpUaGFua3MgZm9yIHRoZSBleGNlbGxl bnQgc3VtbWFyeSBFS1IuICBJIGxpa2UgdGhpcyBkZXNpZ24gYW5kIHRoaW5rIHRoZSBicmVha2Fn ZSBvZiBzdGF0ZWxlc3MgcmVzZXQgaW4gY2VydGFpbiBjYXNlcyBpcyBhY2NlcHRhYmxlLCBzaW5j ZSBpdCBvbmx5IGFwcGxpZXMgaWYgYm90aCBzaWRlcyBtdXN0IGhhdmUgdGhlaXIgcHJlZmVycmVk IGNvbm5lY3Rpb24gSUQgcHJlc2VudCBpbiBvcmRlciB0byByb3V0ZSBjb3JyZWN0bHksIHdoaWNo IGlzIGEgdXNlIGNhc2UgdGhhdCdzIGltcG9zc2libGUgaW4gdGhlIHN0YXR1cyBxdW8uICBJIGhh dmUgbm90IGNvbWUgdXAgd2l0aCBhbnkgb3RoZXIgZG93bnNpZGVzLg0KDQpPbiBGcmksIEZlYiAx NiwgMjAxOCBhdCAxMjowMSBQTSwgRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPG1haWx0bzpl a3JAcnRmbS5jb20+PiB3cm90ZToNCkhpIGZvbGtzLA0KDQpBZnRlciBhIGJ1bmNoIG9mIGRpc2N1 c3Npb24sIHRoZSBDSUQgdGFzayBmb3JjZSBjYW1lIGRvd24gdG8gcm91Z2gNCmNvbnNlbnN1cyB0 aGF0IGFzeW1tZXRyaWMgY29ubiBJRHMgd2VyZSBwcm9iYWJseSB0aGUgcmlnaHQNCmRpcmVjdGlv biAoQ0lEIHRhc2sgZm9yY2UgbWVtYmVycywgcGxlYXNlIGZlZWwgZnJlZSB0byB2b2ljZSBkaXNz ZW50DQpoZXJlKS4gSGVyZSdzIGEgY29tcGxldGUgd3JpdGV1cCBvZiB3aGF0IEkgdGhpbmsgd291 bGQgYmUgbmVlZGVkDQpmb3IgYXN5bW1ldHJpYyBjb25uZWN0aW9uIElEcy4gSXQncyBub3QgYSBQ UiwgYmVjYXVzZSBJIHRoaW5rDQpzb21ldGhpbmcgc2VsZi1jb250YWluZWQgaXMgY2xlYW5lci4N Cg0KTm90ZSB0aGF0IGlmIHdlIGFkb3B0IHRoaXMgZGlyZWN0aW9uLCB3ZSB3b3VsZCBiZSBzYWNy aWZpY2luZw0KcHVibGljIHJlc2V0IHVuZGVyIHNvbWUgY29uZGl0aW9ucyAoc2VlIHByZXZpb3Vz IGVtYWlscyB0byB0aGUNCmxpc3QpIGFuZCB3ZSB3b3VsZCBuZWVkIHRvIGRlY2lkZSBpZiBpdCB3 YXMgd29ydGgga2VlcGluZyBhdCBhbGwuDQoNCg0KT1ZFUlZJRVcNClRoZSBiYXNpYyBpZGVhIGlz IHRoYXQgZWFjaCBzaWRlIGdldHMgdG8gZGljdGF0ZSB0aGUgY29ubmVjdGlvbiBJRHMNCnRoYXQg YXJlIHVzZWQgdG8gc2VuZCB0byBpdC4gRHVyaW5nIHRoZSBoYW5kc2hha2UsIHlvdSBlc3RhYmxp c2ggdGhvc2UNCkNJRHMgYW5kIHRoZW4gZWFjaCBzaWRlIGNhbiBpc3N1ZSBuZXcgQ0lEcyBkdXJp bmcgdGhlIGNvbm5lY3Rpb24uICBUaGUNCm1haW4gYWR2YW50YWdlIG9mIHRoaXMgaXMgdGhhdCBp dCBhbGxvd3MgZm9yIHN5bW1ldHJpYyB0b3BvbG9naWVzIGluIHdoaWNoDQp0aGUgY2xpZW50IGlz IGFsc28gYmVoaW5kIHNvbWUga2luZCBvZiBzdGF0ZWxlc3MgTEIvcm91dGVyIHJhdGhlciB0aGFu DQpqdXN0IHRoZSBzZXJ2ZXIuIFNlZSBJc3N1ZSAjMTA5MSBmb3IgbW9yZSBpbmZvIG9uIHRoaXMu DQoNCg0KVGhlIG92ZXJhbGwgaGFuZHNoYWtlIGxvb2tzIHNvbWV0aGluZyBsaWtlIHRoaXM6DQoN CkNsaWVudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU2VydmVyDQoNCklu aXRpYWwgW0NJRD1YWFhdIHtyZWN2LUNJRD1ZWVl9IC0tLS0tLS0tLS0tLS0tLS0+DQo8LS0tLS0t LS0tLS0tLS0gQ2xlYXJ0ZXh0IFtDSUQ9WVlZXSB7cmVjdi1DSUQ9WlpafQ0KQ2xlYXJ0ZXh0IFtD SUQ9WlpaXSwge3JlY3YtQ0lEPVlZWX0gLS0tLS0tLS0tLS0tLT4NCjwtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSBTaG9ydCBoZWFkZXIgW0NJRD1ZWVldDQpTaG9ydCBoZWFkZXIgW0NJRD1aWlpd IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPg0KDQoNClRoZSBjbGllbnQncyBpbml0aWFsIENJ RCAoWFhYKSBpcyBzcGVjaWFsLCBhbmQgZWl0aGVyIGNvbnNpc3RzIG9mDQoNCiAgICAoYSkgYSBy YW5kb21seSBjaG9zZW4gZHVtbXkgQ0lELiBQcm9wb3NhbDogcmVxdWlyZSB0aGlzIHRvIGJlDQog ICAgICAgIDggYnl0ZXMgb3IgYXQgbGVhc3QgYSBtaW5pbXVtLiBUaGlzIHNob3VsZCBiZSB0aGUg c2FtZQ0KICAgICAgICBmb3IgYWxsIEluaXRpYWwgcGFja2V0cyBpbiBhIGNvbm5lY3Rpb24gKHVu bGVzcyBhIHN0YXRlbGVzcw0KICAgICAgICByZWplY3QgaXMgcmVjZWl2ZWQsIGFzIGJlbG93KS4N CiAgICAoYikgYSBDSUQgd2hpY2ggaXQgcmVjZWl2ZWQgZnJvbSB0aGUgc2VydmVyIGluIGEgc3Rh dGVsZXNzIHJlamVjdA0KDQpBbGwgdGhlIHNlcnZlcidzIHBhY2tldHMgYXJlIHNlbnQgd2l0aCB0 aGUgY2xpZW50J3MgcmVjZWl2ZSBDSUQgKFlZWSkNCmFuZCBhbGwgc3Vic2VxdWVudCBjbGllbnQg cGFja2V0cyBhcmUgc2VudCB3aXRoIHRoZSBzZXJ2ZXIncyByZWNlaXZlDQpDSUQgKFpaWikuIFRo ZSBnZW5lcmFsIHJ1bGUgaXMgdGhhdCB5b3Ugc2hvdWxkIHNlbmQgd2l0aCB0aGUNCmNvbm5lY3Rp b24gSUQgdGhhdCB5b3UgbW9zdCByZWNlbnRseSByZWNlaXZlZCAod2hlcmUgcmVjZW50bHkNCmlz IGRlZmluZWQgYXMgaGlnaGVzdCBQTikuDQoNCk5vdGU6IEkgYmVsaWV2ZSBpdCdzIHNhZmUgdG8g anVzdCB1c2UgdGhlIHNlbmRpbmcgQ0lEIGFzIHRoZSBtaXhpbg0KZm9yIHRoZSBLREYsIGJ1dCBJ IGhhdmVuJ3QgdGhvdWdodCB0aGlzIGVudGlyZWx5IHRocm91Z2ggeWV0Lg0KDQpGaW5hbGx5LCB5 b3UgY2FuIHNlbmQgTkVXX0NPTk5FQ1RJT05fSUQgaW4gZWl0aGVyIGRpcmVjdGlvbiB0byBwcm92 aWRlDQphIG5ldyBjb25uZWN0aW9uIElEIGZvciB0aGUgb3RoZXIgc2lkZSB0byB1c2UuIFRoZSBn ZW5lcmFsIGFzc3VtcHRpb24NCmlzIHRoYXQgeW91IGNhbiBkbyB0aGlzIGF0IGFueSB0aW1lLCBq dXN0IGFzIHdpdGggY3VycmVudCBRVUlDLCBhbmQNCnRoYXQgYW55IHRpbWUgeW91IHNlbmQgdG8g YSBuZXcgcmVtb3RlIDMtdHVwbGUgeW91IHNob3VsZCBjaGFuZ2UgQ0lEcw0KaWYgeW91IGNhbi4g Tm90ZSB0aGF0IHRoaXMgbWVhbnMgdGhhdCBlbmRwb2ludHMgc2hvdWxkIHRyeSB0byBtYWtlDQpz dXJlIHRoYXQgdGhlIG90aGVyIHNpZGUgaGFzIHNwYXJlIENJRHMgaW4gY2FzZSB0aGV5IG5lZWQg dG8gbWlncmF0ZS4NCg0KDQpXSVJFIEVOQ09ESU5HDQpBcyB3ZSBkaXNjdXNzZWQgaW4gdGhlIG1l ZXRpbmcgdGhlIHNob3J0IGhlYWRlciBzaG91bGQganVzdCBoYXZlDQphbiBpbXBsaWNpdCBsZW5n dGggQ0lELiBUaGlzIGdpdmVzIHVzIHRoZSBmb2xsb3dpbmcgc2hvcnQgaGVhZGVyOg0KDQogICAr LSstKy0rLSstKy0rLSstKw0KICAgfDB8Q3xLfCBUeXBlICg1KXwNCiAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KICAgKyAgICAgICAgICAgICAgICAgICAgIFtDb25uZWN0aW9uIElEICgqKV0gICAg ICAgICAgICAgICAgICAgICAgICsgIDwtIGNoYW5nZSBmcm9tIDY0DQogICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgUGFja2V0IE51bWJlciAoOC8xNi8z MikgICAgICAgICAgICAgICAgLi4uDQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAg ICAgIFByb3RlY3RlZCBQYXlsb2FkICgqKSAgICAgICAgICAgICAgICAgICAuLi4NCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQoNCk5vdGUgdGhhdCB3ZSBtYXkgYWxzbyBiZSBhYmxlIHRvIGRpc3BlbnNlIHdpdGggdGhl IEMgYml0LCBpZiBlYWNoDQpzaWRlIGp1c3QgZ2V0cyB0byBzYXkgInNlbmQgbWUgdGhpcyBDSUQg ZXhhY3RseSIsIHdoeSBkbyB3ZSB3YW50DQp0byBzYXkgImhlcmUgaXMgbXkgQ0lEIGJ1dCB5b3Ug Y2FuIG9taXQgaXQiLg0KDQoNCldlIGhhdmUgc2V2ZXJhbCBvcHRpb25zIGFib3V0IHRoZSBsb25n IGhlYWRlci4gVGhlIGZpcnN0IHF1ZXN0aW9uDQppcyB3aGVyZSByZWN2LUNJRHMgZ28uIEluIHBy ZXZpb3VzIHZlcnNpb25zIEkgc3VnZ2VzdGVkIHB1dHRpbmcNCnRoZW0gaW4gdHJhbnNwb3J0IHBh cmFtZXRlcnMsIG9yIGVsc2V3aGVyZSBpbiB0aGUgVExTIGhhbmRzaGFrZSwNCmFuZCB0aGF0IG1p Z2h0IHN0aWxsIGJlIHZpYWJsZSwgdGhvdWdoIGl0IGhhcyBzb21lIGRyYXdiYWNrcyBbMF0sDQpz byB0aGUgb3RoZXIgYWx0ZXJuYXRpdmUgaXMgdG8gcHV0IGJvdGggQ0lEcyBpbiBpbiB0aGUgbG9u ZyBoZWFkZXIuDQpUaGlzIHdvdWxkIGxvb2sgc29tZXRoaW5nIGxpa2U6DQoNCiAgICstKy0rLSst Ky0rLSstKy0rDQogICB8MXwgICBUeXBlICg3KSAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgIERDSUQt TGVuZ3RoICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICArLSstKy0rLSstKy0rLSstKyAgIERzdCBDb25uZWN0aW9uIElEICgqKSAgICAgICAgICAg ICAgICAgICAgICAgKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICBTQ0lELUxlbmd0 aCAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAg Ky0rLSstKy0rLSstKy0rLSsgICBTcmMgQ29ubmVjdGlvbiBJRCAoKikgICAgICAgICAgICAgICAg ICAgICAgICsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICBWZXJzaW9uICgzMikgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICBQYWNrZXQgTnVtYmVyICgzMikgICAgICAg ICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgIFBheWxvYWQgKCopICAgICAgICAgICAgICAgICAgICAgICAgLi4uDQogICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K DQpUaGUgc2VtYW50aWNzIGhlcmUgYXJlIHRoYXQgdGhlIGZpcnN0IHZhbHVlIGlzIHRoZSBDSUQg eW91IHdhbnQgdG8NCnNlbmQgdG8gYW5kIHRoZSBzZWNvbmQgb25lIGlzIHRoZSB2YWx1ZSB5b3Ug d2FudCB1c2VkIHRvIHNlbmQgdG8geW91DQooSSd2ZSBpbnZlcnRlZCB0aGVzZSB0byBrZWVwIHRo ZSBvcmRlciB0aGUgc2FtZSBhcyBzaG9ydCBoZWFkZXIpLg0KDQpUd28gbm90ZXMgYWJvdXQgdGhp cyBlbmNvZGluZzoNCg0KMS4gSSB0aGluayB3ZSBhZ3JlZWQgdGhhdCB3ZSBkaWRuJ3Qgd2FudCBh cmJpdHJhcnkgbGVuZ3RoIENJRHMgdXAgdG8NCjI1NSBieXRlcywgYW5kIHlldCB3ZSBoYXZlIHJv b20gaW4gdGhpcyBsZW5ndGggYnl0ZS4gSSBwcm9wb3NlIHdlDQpsaW1pdCBpdCB0byAzMSBieXRl cyBhbmQgdGhlbiBncmVhc2UgdGhlIHJlbWFpbmluZyAzIGJpdHMgWzFdLg0KDQoyLiBCZWNhdXNl IHRoZSBjbGllbnQgc2VuZHMgaXRzIENJRCBmaXJzdCwgdGhlcmUncyBubyB3YXkgdG8gZ2V0IHRo ZQ0KY3VycmVudCBRVUlDIHNlbWFudGljcyBvZiB0aGUgc2VydmVyIGp1c3QgZGljdGF0ZXMgdGhl IENJRC4gIEkgcHJvcG9zZQ0Kd2UgZml4IHRoYXQgYnkgZGVmaW5pbmcgYSBzcGVjaWFsIHNlbnRp bmVsIENJRCAoYWxsIDFzLCBhbGwgMHMsDQp3aGF0ZXZlcikgb2Ygd2hhdGV2ZXIgb3VyIG1heGlt dW0gbGVuZ3RoIGlzIHRoYXQgbWVhbnMgImp1c3QgdXNlIHlvdXINCm93biBDSUQiLg0KDQpXZSBj YW4gZW5kbGVzc2x5IGJpa2VzaGVkIG9uIHRoaXMgc3RydWN0dXJlLg0KDQoNCkZpbmFsbHksIHdl IHdpbGwgbmVlZCB0byB1cGRhdGUgTkVXX0NPTk5FQ1RJT05fSUQgdG8gYWxsb3cgYSB2YXJpYWJs ZQ0KbGVuZ3RoIENJRC4gVGhpcyB3b3VsZCBsb29rIGxpa2UgdGhpczoNCg0KICAgIDAgICAgICAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAg ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDENCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBTZXF1 ZW5jZSAoaSkgICAgICAgICAgICAgICAgICAgICAgIC4uLg0KICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwgIENJ RC1MZW5ndGggICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICArLSstKy0rLSstKy0rLSstKyAgICAgICBDb25uZWN0aW9uIElEICgqKSAgICAgICAg ICAgICAgICAgICAgICAgKw0KICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICsNCiAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8DQogICArICAgICAgICAgICAgICAgICAgIFN0YXRlbGVz cyBSZXNldCBUb2tlbiAoMTI4KSAgICAgICAgICAgICAgICAgKw0KICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArDQogICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCg0KDQoNClswXSBIb3dldmVyLCBpbiB0 aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnMgZGVzaWduLCBpZiB0aGUgc2VydmVyJ3MNCmhhbmRzaGFr ZSBnZXRzIHJlb3JkZXJlZCwgdGhlIGNsaWVudCBtaWdodCBuZWVkIHRvIHNlbmQgc29tZSBBQ0tz IHdpdGgNCnRoZSBpbml0aWFsIENJRC4gSG93ZXZlciwgd2UndmUgYWdyZWVkIHRoYXQgdGhlIGNs aWVudCdzIElQIGFkZHJlc3MNCmhhcyB0byBiZSBzdGFibGUsIHNvIHRoaXMgaXNuJ3QgYSBwcm9i bGVtLiBBbHRlcm5hdGVseSwgeW91IGNvdWxkDQpjaGFuZ2UgQy0+UyBDSURzIGluIHRoZSBzaG9y dCBoZWFkZXIgaWYgdGhhdCB3YXMgZWFzaWVyLg0KDQpbMV0gQW4gYWx0ZXJuYXRpdmUgd291bGQg YmUgdG8gaGF2ZSBhIHNwYXJzZSByYW5nZSAoZS5nLiwgeW91IGNhbg0KZXhwcmVzcyAwLTcgYW5k IHRoZW4gOC0yMiBieSAycywgYXNzdW1pbmcgSSBoYXZlIGNvdW50ZWQgY29ycmVjdGx5KQ0KYW5k IHRoZW4gd2UgY291bGQgcGFjayBib3RoIGxlbmd0aHMgaW50byBhIHNpbmdsZSBieXRlLiBBcyBJ IHNhaWQsDQpsb3RzIG9mIG9wcG9ydHVuaXRpZXMgZm9yIGJpa2VzaGVkZGluZyBoZXJlLg0KDQoN Cg0K --_000_D7E469CDB9D841ED8F5C9933DCBA90E6fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: <6216E7C87BEB6746BC15B7EA402BC7DD@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOyYjNDM7IHdoYXQgQ2hyaXN0aWFu IHNheXMuPGJyPg0KVGhlIGZhY3QgdGhhdCBpdCBub3cgdGFrZXMgdHdvIGltcGxlbWVudGF0aW9u cyB0byBwcmV2ZW50IGxpbmthYmlsaXR5IChlaXRoZXIgc2lkZSBtZXNzZXMgaXQgdXAsIGFuZCB0 aGF0IGhhbGYtcGF0aCBpcyBleHBvc2VkLCBsaWtlbHkgcmVuZGVyaW5nIGl0IGFsbCBleHBvc2Vk KSBpcyBhIGJpdCBzYWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tPVI8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYu b3JnJmd0OyBvbiBiZWhhbGYgb2YgQ2hyaXN0aWFuIEh1aXRlbWEgJmx0O2h1aXRlbWFAaHVpdGVt YS5uZXQmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgRmVicnVhcnkgMTYsIDIwMTggYXQg MTA6MTYgQU08YnI+DQo8Yj5UbzogPC9iPk1hcnRpbiBEdWtlICZsdDttYXJ0aW4uaC5kdWtlQGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPklhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29vZ2xl LmNvbSZndDssIElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDssIEVyaWMgUmVzY29y bGEgJmx0O2VrckBydGZtLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IEFzeW1tZXRy aWMgQ0lEczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgbGlrZSB0aGUgY29uY2VwdCwgYnV0 IEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIGhvdyB3ZSBhdm9pZCBsaW5rYWJpbGl0eSBvbiBt aWdyYXRpb24uPG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gQ2hyaXN0aWFuIEh1aXRlbWEmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGJyPg0KT24gRmViIDE2LCAyMDE4LCBhdCA3OjUyIEFNLCBNYXJ0aW4g RHVrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tIj5tYXJ0aW4u aC5kdWtlQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB3cml0aW5nIHRo aXMgdXAsIGVrci4gVGhpcyBpbmNvcnBvcmF0ZXMgbWFueSBvZiB0aGUgc3VnZ2VzdGlvbnMgSSBt YWRlIGluIG9iamVjdGlvbiB0byB0aGlzIHByb2plY3QgKHBlcmhhcHMgY29pbmNpZGVudGFsbHkp IGFuZCBJIGxpa2UgaXQgYSBsb3QuDQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFkdmFudGFnZXMgb2YgdGhpczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gSW4gdGhlIGNvbW1vbiBjYXNlIHdoZXJlIG1v c3Qgb2YgdGhlIGRhdGEgaXMgc2VydmVyLSZndDtjbGllbnQsIGNsaWVudHMgY2FuIGdldCBhd2F5 IHdpdGggc2hvcnRlciBDb25uIElEcyB0byByZWR1Y2Ugb3ZlcmhlYWQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIE9taXQtY29ubi1pZCBqdXN0 IGJlY29tZXMgYSBjYXNlIHdoZXJlIGxlbmd0aCA9IDAuIERvZXMgdGhpcyBzaWRlc3RlcCBzb21l IG9mIEdvb2dsZSdzIHRyYW5zaXRpb24gaXNzdWVzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJZiBhIGNsaWVudCBzZW5kcyBORVdfQ09OTkVD VElPTl9JRCwgdGhhdCBpbmRpY2F0ZXMgYW4gaW50ZW50aW9uIHRvIG1pZ3JhdGUsIGFuZCBpcyBh IGdvb2QgY3VlIGZvciB0aGUgc2VydmVyIHRvIHNlbmQgdGhlIHNhbWUuIFdlIHNob3VsZCBhZGQg YSBTSE9VTEQgdG8gc3BlY2lmeSB0aGlzIGJlaGF2aW9yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIG11c3QgYmUgbWlzc2luZyBzb21ldGhp bmcsIGhvd2V2ZXIsIHJlZ2FyZGluZyBpbXBsaWNpdCBDSURzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGVyZSdzIGEgTkFUIHJlYmlu ZGluZywgaG93IGlzIHRoZSBzZXJ2ZXIgc3VwcG9zZWQgdG8gZXh0cmFjdCB0aGUgQ0lEPyBGdXJ0 aGVybW9yZSwgdGhpcyBvYnZpYXRlcyB0aGUgZW50aXJlIGNvbmNlcHQgb2YgdXNpbmcgQ29ubmVj dGlvbiBJRCBmb3Igcm91dGluZzsgaXQncyBub3Qgb2J2aW91c2x5IGEgc2F2aW5ncyB0byBzdG9y ZSBDSUQgbGVuZ3RoIGluIGEgdGFibGUgdnMuIGp1c3Qgc3RvcmluZyB0aGUNCiBkZXN0aW5hdGlv biBzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkxhc3RseSwgaWYgd2UgZW5jb2RlIHRoZSBsZW5ndGggc29tZXdoZXJlIHRoYXQgc2Vl bXMgdG8gc29sdmUgdGhlIFN0YXRlbGVzcyBSZXNldCBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiAxNiwgMjAx OCBhdCA5OjI1IEFNLCBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29n bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MgZm9yIHRoZSBleGNlbGxlbnQgc3VtbWFyeSBFS1IuJm5ic3A7IEkgbGlrZSB0aGlz IGRlc2lnbiBhbmQgdGhpbmsgdGhlIGJyZWFrYWdlIG9mIHN0YXRlbGVzcyByZXNldCBpbiBjZXJ0 YWluIGNhc2VzIGlzIGFjY2VwdGFibGUsIHNpbmNlIGl0IG9ubHkgYXBwbGllcyBpZiBib3RoIHNp ZGVzIG11c3QgaGF2ZSB0aGVpciBwcmVmZXJyZWQgY29ubmVjdGlvbiBJRCBwcmVzZW50IGluIG9y ZGVyIHRvIHJvdXRlIGNvcnJlY3RseSwNCiB3aGljaCBpcyBhIHVzZSBjYXNlIHRoYXQncyBpbXBv c3NpYmxlIGluIHRoZSBzdGF0dXMgcXVvLiZuYnNwOyBJIGhhdmUgbm90IGNvbWUgdXAgd2l0aCBh bnkgb3RoZXIgZG93bnNpZGVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEZlYiAxNiwgMjAxOCBhdCAxMjowMSBQTSwg RXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgZm9sa3MsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFmdGVyIGEg YnVuY2ggb2YgZGlzY3Vzc2lvbiwgdGhlIENJRCB0YXNrIGZvcmNlIGNhbWUgZG93biB0byByb3Vn aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Y29u c2Vuc3VzIHRoYXQgYXN5bW1ldHJpYyBjb25uIElEcyB3ZXJlIHByb2JhYmx5IHRoZSByaWdodDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ZGlyZWN0 aW9uIChDSUQgdGFzayBmb3JjZSBtZW1iZXJzLCBwbGVhc2UgZmVlbCBmcmVlIHRvIHZvaWNlIGRp c3NlbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmhlcmUpLiBIZXJlJ3MgYSBjb21wbGV0ZSB3cml0ZXVwIG9mIHdoYXQgSSB0aGluayB3b3VsZCBi ZSBuZWVkZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmZvciBhc3ltbWV0cmljIGNvbm5lY3Rpb24gSURzLiBJdCdzIG5vdCBhIFBSLCBiZWNhdXNl IEkgdGhpbms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnNvbWV0aGluZyBzZWxmLWNvbnRhaW5lZCBpcyBjbGVhbmVyLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3RlIHRoYXQgaWYgd2UgYWRv cHQgdGhpcyBkaXJlY3Rpb24sIHdlIHdvdWxkIGJlIHNhY3JpZmljaW5nPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5wdWJsaWMgcmVzZXQgdW5kZXIg c29tZSBjb25kaXRpb25zIChzZWUgcHJldmlvdXMgZW1haWxzIHRvIHRoZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bGlzdCkgYW5kIHdlIHdvdWxk IG5lZWQgdG8gZGVjaWRlIGlmIGl0IHdhcyB3b3J0aCBrZWVwaW5nIGF0IGFsbC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PVkVSVklFVzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGJh c2ljIGlkZWEgaXMgdGhhdCBlYWNoIHNpZGUgZ2V0cyB0byBkaWN0YXRlIHRoZSBjb25uZWN0aW9u IElEczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ dGhhdCBhcmUgdXNlZCB0byBzZW5kIHRvIGl0LiBEdXJpbmcgdGhlIGhhbmRzaGFrZSwgeW91IGVz dGFibGlzaCB0aG9zZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Q0lEcyBhbmQgdGhlbiBlYWNoIHNpZGUgY2FuIGlzc3VlIG5ldyBDSURzIGR1cmlu ZyB0aGUgY29ubmVjdGlvbi4mbmJzcDsgVGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5tYWluIGFkdmFudGFnZSBvZiB0aGlzIGlzIHRoYXQgaXQg YWxsb3dzIGZvciBzeW1tZXRyaWMgdG9wb2xvZ2llcyBpbiB3aGljaDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIGNsaWVudCBpcyBhbHNvIGJl aGluZCBzb21lIGtpbmQgb2Ygc3RhdGVsZXNzIExCL3JvdXRlciByYXRoZXIgdGhhbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+anVzdCB0aGUgc2Vy dmVyLiBTZWUgSXNzdWUgIzEwOTEgZm9yIG1vcmUgaW5mbyBvbiB0aGlzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBvdmVyYWxsIGhh bmRzaGFrZSBsb29rcyBzb21ldGhpbmcgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DbGllbnQmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg U2VydmVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluaXRpYWwgW0NJRD1YWFhdIHtyZWN2LUNJRD1ZWVl9IC0tLS0tLS0tLS0tLS0tLS0mZ3Q7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbHQ7 LS0tLS0tLS0tLS0tLS0gQ2xlYXJ0ZXh0IFtDSUQ9WVlZXSB7cmVjdi1DSUQ9WlpafTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xlYXJ0ZXh0IFtD SUQ9WlpaXSwge3JlY3YtQ0lEPVlZWX0gLS0tLS0tLS0tLS0tLSZndDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZsdDstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSBTaG9ydCBoZWFkZXIgW0NJRD1ZWVldPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaG9ydCBoZWFkZXIgW0NJRD1aWlpdIC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tJmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjbGllbnQncyBpbml0aWFsIENJRCAoWFhYKSBp cyBzcGVjaWFsLCBhbmQgZWl0aGVyIGNvbnNpc3RzIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgKGEpIGEgcmFuZG9t bHkgY2hvc2VuIGR1bW15IENJRC4gUHJvcG9zYWw6IHJlcXVpcmUgdGhpcyB0byBiZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IDggYnl0ZXMgb3IgYXQgbGVhc3QgYSBtaW5pbXVtLiBUaGlzIHNob3Vs ZCBiZSB0aGUgc2FtZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvciBhbGwgSW5pdGlhbCBwYWNr ZXRzIGluIGEgY29ubmVjdGlvbiAodW5sZXNzIGEgc3RhdGVsZXNzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgcmVqZWN0IGlzIHJlY2VpdmVkLCBhcyBiZWxvdykuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IChiKSBhIENJRCB3 aGljaCBpdCByZWNlaXZlZCBmcm9tIHRoZSBzZXJ2ZXIgaW4gYSBzdGF0ZWxlc3MgcmVqZWN0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbCB0 aGUgc2VydmVyJ3MgcGFja2V0cyBhcmUgc2VudCB3aXRoIHRoZSBjbGllbnQncyByZWNlaXZlIENJ RCAoWVlZKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+YW5kIGFsbCBzdWJzZXF1ZW50IGNsaWVudCBwYWNrZXRzIGFyZSBzZW50IHdpdGggdGhlIHNl cnZlcidzIHJlY2VpdmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkNJRCAoWlpaKS4gVGhlIGdlbmVyYWwgcnVsZSBpcyB0aGF0IHlvdSBzaG91bGQg c2VuZCB3aXRoIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Y29ubmVjdGlvbiBJRCB0aGF0IHlvdSBtb3N0IHJlY2VudGx5IHJlY2VpdmVkICh3 aGVyZSByZWNlbnRseTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+aXMgZGVmaW5lZCBhcyBoaWdoZXN0IFBOKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90ZTogSSBiZWxpZXZlIGl0J3Mgc2Fm ZSB0byBqdXN0IHVzZSB0aGUgc2VuZGluZyBDSUQgYXMgdGhlIG1peGluPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5mb3IgdGhlIEtERiwgYnV0IEkg aGF2ZW4ndCB0aG91Z2h0IHRoaXMgZW50aXJlbHkgdGhyb3VnaCB5ZXQuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpbmFsbHksIHlvdSBjYW4g c2VuZCBORVdfQ09OTkVDVElPTl9JRCBpbiBlaXRoZXIgZGlyZWN0aW9uIHRvIHByb3ZpZGU8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmEgbmV3IGNv bm5lY3Rpb24gSUQgZm9yIHRoZSBvdGhlciBzaWRlIHRvIHVzZS4gVGhlIGdlbmVyYWwgYXNzdW1w dGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ aXMgdGhhdCB5b3UgY2FuIGRvIHRoaXMgYXQgYW55IHRpbWUsIGp1c3QgYXMgd2l0aCBjdXJyZW50 IFFVSUMsIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+dGhhdCBhbnkgdGltZSB5b3Ugc2VuZCB0byBhIG5ldyByZW1vdGUgMy10dXBsZSB5b3Ug c2hvdWxkIGNoYW5nZSBDSURzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5pZiB5b3UgY2FuLiBOb3RlIHRoYXQgdGhpcyBtZWFucyB0aGF0IGVuZHBv aW50cyBzaG91bGQgdHJ5IHRvIG1ha2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPnN1cmUgdGhhdCB0aGUgb3RoZXIgc2lkZSBoYXMgc3BhcmUgQ0lE cyBpbiBjYXNlIHRoZXkgbmVlZCB0byBtaWdyYXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldJUkUgRU5DT0RJTkc8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHdlIGRpc2N1c3NlZCBp biB0aGUgbWVldGluZyB0aGUgc2hvcnQgaGVhZGVyIHNob3VsZCBqdXN0IGhhdmU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuIGltcGxpY2l0IGxl bmd0aCBDSUQuIFRoaXMgZ2l2ZXMgdXMgdGhlIGZvbGxvd2luZyBzaG9ydCBoZWFkZXI6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwO3wwfEN8S3wgVHlwZSAoNSl8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO3w8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtbQ29ubmVjdGlvbiBJ RCAoKildJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOyZuYnNwOyAmbHQ7LSBjaGFuZ2Ug ZnJvbSA2NDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgUGFja2V0IE51bWJlciAoOC8xNi8zMikmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC4uLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQcm90 ZWN0ZWQgUGF5bG9hZCAoKikmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Ob3RlIHRoYXQgd2UgbWF5IGFsc28gYmUgYWJsZSB0byBkaXNwZW5zZSB3aXRoIHRo ZSBDIGJpdCwgaWYgZWFjaDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+c2lkZSBqdXN0IGdldHMgdG8gc2F5ICZxdW90O3NlbmQgbWUgdGhpcyBDSUQg ZXhhY3RseSZxdW90Oywgd2h5IGRvIHdlIHdhbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIHNheSAmcXVvdDtoZXJlIGlzIG15IENJRCBidXQg eW91IGNhbiBvbWl0IGl0JnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGhhdmUgc2V2ZXJhbCBvcHRpb25zIGFib3V0IHRoZSBs b25nIGhlYWRlci4gVGhlIGZpcnN0IHF1ZXN0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pcyB3aGVyZSByZWN2LUNJRHMgZ28uIEluIHByZXZp b3VzIHZlcnNpb25zIEkgc3VnZ2VzdGVkIHB1dHRpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZW0gaW4gdHJhbnNwb3J0IHBhcmFtZXRlcnMs IG9yIGVsc2V3aGVyZSBpbiB0aGUgVExTIGhhbmRzaGFrZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCB0aGF0IG1pZ2h0IHN0aWxsIGJlIHZp YWJsZSwgdGhvdWdoIGl0IGhhcyBzb21lIGRyYXdiYWNrcyBbMF0sPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zbyB0aGUgb3RoZXIgYWx0ZXJuYXRp dmUgaXMgdG8gcHV0IGJvdGggQ0lEcyBpbiBpbiB0aGUgbG9uZyBoZWFkZXIuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHdvdWxkIGxvb2sg c29tZXRoaW5nIGxpa2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3wxfCZuYnNwOyAmbmJzcDtUeXBlICg3KSZu YnNwOyB8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt8Jm5ic3A7 IERDSUQtTGVuZ3RoJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3w8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOyZuYnNwOyAmbmJzcDtEc3QgQ29ubmVjdGlvbiBJRCAoKikm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt8Jm5ic3A7IFNDSUQtTGVuZ3RoJm5ic3A7IHwmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsm IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOyZuYnNw OyAmbmJzcDtTcmMgQ29ubmVjdGlvbiBJRCAoKikmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj NDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt8Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VmVyc2lvbiAoMzIpJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1BhY2tldCBOdW1iZXIgKDMyKSZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgfDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i c3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQYXlsb2FkICgqKSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IC4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBzZW1hbnRpY3MgaGVyZSBhcmUgdGhhdCB0aGUgZmlyc3QgdmFsdWUgaXMgdGhlIENJRCB5b3Ug d2FudCB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+c2VuZCB0byBhbmQgdGhlIHNlY29uZCBvbmUgaXMgdGhlIHZhbHVlIHlvdSB3YW50IHVzZWQg dG8gc2VuZCB0byB5b3U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPihJJ3ZlIGludmVydGVkIHRoZXNlIHRvIGtlZXAgdGhlIG9yZGVyIHRoZSBzYW1l IGFzIHNob3J0IGhlYWRlcikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlR3byBub3RlcyBhYm91dCB0aGlzIGVuY29kaW5nOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4xLiBJIHRoaW5rIHdl IGFncmVlZCB0aGF0IHdlIGRpZG4ndCB3YW50IGFyYml0cmFyeSBsZW5ndGggQ0lEcyB1cCB0bzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MjU1IGJ5 dGVzLCBhbmQgeWV0IHdlIGhhdmUgcm9vbSBpbiB0aGlzIGxlbmd0aCBieXRlLiBJIHByb3Bvc2Ug d2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmxp bWl0IGl0IHRvIDMxIGJ5dGVzIGFuZCB0aGVuIGdyZWFzZSB0aGUgcmVtYWluaW5nIDMgYml0cyBb MV0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjIuIEJlY2F1c2UgdGhlIGNsaWVudCBzZW5kcyBpdHMgQ0lEIGZpcnN0LCB0aGVyZSdzIG5vIHdh eSB0byBnZXQgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5jdXJyZW50IFFVSUMgc2VtYW50aWNzIG9mIHRoZSBzZXJ2ZXIganVzdCBkaWN0YXRl cyB0aGUgQ0lELiZuYnNwOyBJIHByb3Bvc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPndlIGZpeCB0aGF0IGJ5IGRlZmluaW5nIGEgc3BlY2lhbCBz ZW50aW5lbCBDSUQgKGFsbCAxcywgYWxsIDBzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2hhdGV2ZXIpIG9mIHdoYXRldmVyIG91ciBtYXhpbXVt IGxlbmd0aCBpcyB0aGF0IG1lYW5zICZxdW90O2p1c3QgdXNlIHlvdXI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm93biBDSUQmcXVvdDsuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGNhbiBl bmRsZXNzbHkgYmlrZXNoZWQgb24gdGhpcyBzdHJ1Y3R1cmUuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RmluYWxseSwgd2Ugd2lsbCBuZWVk IHRvIHVwZGF0ZSBORVdfQ09OTkVDVElPTl9JRCB0byBhbGxvdyBhIHZhcmlhYmxlPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5sZW5ndGggQ0lELiBU aGlzIHdvdWxkIGxvb2sgbGlrZSB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IDAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsxJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7MiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFNlcXVlbmNlIChpKSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Li4uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt8Jm5ic3A7IENJRC1MZW5ndGgmbmJzcDsgJm5i c3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 fDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwOyYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q29ubmVjdGlvbiBJRCAoKikmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0Mzs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO3w8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmIzQzOyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYjNDM7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7U3RhdGVsZXNzIFJlc2V0IFRva2VuICgxMjgpJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3wmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyYj NDM7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYj NDM7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlswXSBIb3dldmVy LCBpbiB0aGUgdHJhbnNwb3J0IHBhcmFtZXRlcnMgZGVzaWduLCBpZiB0aGUgc2VydmVyJ3M8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmhhbmRzaGFr ZSBnZXRzIHJlb3JkZXJlZCwgdGhlIGNsaWVudCBtaWdodCBuZWVkIHRvIHNlbmQgc29tZSBBQ0tz IHdpdGg8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnRoZSBpbml0aWFsIENJRC4gSG93ZXZlciwgd2UndmUgYWdyZWVkIHRoYXQgdGhlIGNsaWVudCdz IElQIGFkZHJlc3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmhhcyB0byBiZSBzdGFibGUsIHNvIHRoaXMgaXNuJ3QgYSBwcm9ibGVtLiBBbHRlcm5h dGVseSwgeW91IGNvdWxkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5jaGFuZ2UgQy0mZ3Q7UyBDSURzIGluIHRoZSBzaG9ydCBoZWFkZXIgaWYgdGhh dCB3YXMgZWFzaWVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5bMV0gQW4gYWx0ZXJuYXRpdmUgd291bGQgYmUgdG8gaGF2ZSBhIHNwYXJzZSBy YW5nZSAoZS5nLiwgeW91IGNhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+ZXhwcmVzcyAwLTcgYW5kIHRoZW4gOC0yMiBieSAycywgYXNzdW1pbmcg SSBoYXZlIGNvdW50ZWQgY29ycmVjdGx5KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIHRoZW4gd2UgY291bGQgcGFjayBib3RoIGxlbmd0aHMg aW50byBhIHNpbmdsZSBieXRlLiBBcyBJIHNhaWQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5sb3RzIG9mIG9wcG9ydHVuaXRpZXMgZm9yIGJpa2Vz aGVkZGluZyBoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_D7E469CDB9D841ED8F5C9933DCBA90E6fbcom_-- From nobody Fri Feb 16 10:39:44 2018 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 E474E12AF84 for ; Fri, 16 Feb 2018 10:39:40 -0800 (PST) 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 3at6pu8hykGU for ; Fri, 16 Feb 2018 10:39:37 -0800 (PST) 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 07B17126C2F for ; Fri, 16 Feb 2018 10:39:37 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id v196so1850959ywc.6 for ; Fri, 16 Feb 2018 10:39:36 -0800 (PST) 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=P2mpIPTBeE0DnW0gpUhsF+b2O7dJrq33jUCHFZM0mX4=; b=rOxTX6NnSZJkHmW7RlhbHwDoWZQSgWkONKJ4vMbqtJyNEuuL9rR5ZQePCtjosCqQGD RktVOOqknP6EU+BoVtKLo6mtprUj6gGuj4qWoiFalUIy771tEdE33Xp9e0lizd8RaKs2 GZK4JcI0BqG4pXDCfyfG5g8exSkP0wqMO4OvxIA+sYe++14Lf8bViBPwe01UP80iXppV fOW/QWiX/8UF7nAXILScEPWrp1AE7g65npOtaSgJQiifUO62tKS3A/iS0mOELHMgZMfF 9hWBXQdwVyeZ22NKBKXFkng6L0kCkcRIN4RNddfw5GoVztzUQiLp7hYOYmb0aNU/wCzY jK6g== 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=P2mpIPTBeE0DnW0gpUhsF+b2O7dJrq33jUCHFZM0mX4=; b=UIN9/Rz2IDYUFeRr+xZCrBlvbziIjO3FBA0tYhEmBzbM5WgkzpFhzUjx+zTI4Tz78g KskbgEncvXIlG1pDEbq3hMNWyeXLO2ceGpSxEvumvwG1+UkfNEjCC1vAW6my+Hb3p+AP g9hrofE4n8D9pDE1qszj4aTixElI/ZEcvDjmbAZgjP8iJ6sjD1BTndJCr6SV7depojI4 fyagUpvTeomOZA5Npn8Rl63sd5cwYU+1YXNCt10AuaRYOUM7eJMbPsdAa73dHcVuwORO kGC2PymNX2GayS8OcjdaM5koOjHbu8z95jxZg2p3y5DtBiwXHbRp1H4veaK14ucq8VMt 124g== X-Gm-Message-State: APf1xPAXLdbLIJuIpGUV/Ld8+hmqat7k/Tg68nlOyiIn68+5fRvgnXEz m10XPDeU/Afv3aDlqfYhKpt1i5Z5QTLql29vZWIYbkoK X-Google-Smtp-Source: AH8x2279OeBV421TCFBbsVLUZQ8bgFkEbca8n3loUwDz3rYMuz/1eNR4Lik9bi46PS5MFw1RvoaL/u666/NTrVredFE= X-Received: by 10.13.246.65 with SMTP id g62mr5583629ywf.47.1518806376086; Fri, 16 Feb 2018 10:39:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.114.10 with HTTP; Fri, 16 Feb 2018 10:38:55 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 16 Feb 2018 10:38:55 -0800 Message-ID: Subject: Re: Asymmetric CIDs To: Martin Duke Cc: Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c03548487955f056558aab4" 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, 16 Feb 2018 18:39:41 -0000 --94eb2c03548487955f056558aab4 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 16, 2018 at 9:52 AM, Martin Duke wrote: > Thanks for writing this up, ekr. This incorporates many of the suggestions > I made in objection to this project (perhaps coincidentally) and I like it > a lot. > > Advantages of this: > - In the common case where most of the data is server->client, clients can > get away with shorter Conn IDs to reduce overhead. > - Omit-conn-id just becomes a case where length = 0. Does this sidestep > some of Google's transition issues? > - If a client sends NEW_CONNECTION_ID, that indicates an intention to > migrate, and is a good cue for the server to send the same. We should add a > SHOULD to specify this behavior. > > I must be missing something, however, regarding implicit CIDs. > > If there's a NAT rebinding, how is the server supposed to extract the CID? > The assumption is that the server either: (a) always uses the same CID length (b) has a structured CID which starts with the length. But that we don't need to mandate which one in the protoocl > Furthermore, this obviates the entire concept of using Connection ID for > routing; it's not obviously a savings to store CID length in a table vs. > just storing the destination server. > I don't think you hae to do this, but maybe I am confused. See above and tell me if you think I'm wrong -Ekr > Lastly, if we encode the length somewhere that seems to solve the > Stateless Reset issue. > > > On Fri, Feb 16, 2018 at 9:25 AM, Ian Swett wrote: > >> Thanks for the excellent summary EKR. I like this design and think the >> breakage of stateless reset in certain cases is acceptable, since it only >> applies if both sides must have their preferred connection ID present in >> order to route correctly, which is a use case that's impossible in the >> status quo. I have not come up with any other downsides. >> >> On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla wrote: >> >>> Hi folks, >>> >>> After a bunch of discussion, the CID task force came down to rough >>> consensus that asymmetric conn IDs were probably the right >>> direction (CID task force members, please feel free to voice dissent >>> here). Here's a complete writeup of what I think would be needed >>> for asymmetric connection IDs. It's not a PR, because I think >>> something self-contained is cleaner. >>> >>> Note that if we adopt this direction, we would be sacrificing >>> public reset under some conditions (see previous emails to the >>> list) and we would need to decide if it was worth keeping at all. >>> >>> >>> OVERVIEW >>> The basic idea is that each side gets to dictate the connection IDs >>> that are used to send to it. During the handshake, you establish those >>> CIDs and then each side can issue new CIDs during the connection. The >>> main advantage of this is that it allows for symmetric topologies in >>> which >>> the client is also behind some kind of stateless LB/router rather than >>> just the server. See Issue #1091 for more info on this. >>> >>> >>> The overall handshake looks something like this: >>> >>> Client Server >>> >>> Initial [CID=XXX] {recv-CID=YYY} ----------------> >>> <-------------- Cleartext [CID=YYY] {recv-CID=ZZZ} >>> Cleartext [CID=ZZZ], {recv-CID=YYY} -------------> >>> <-------------------------- Short header [CID=YYY] >>> Short header [CID=ZZZ] --------------------------> >>> >>> >>> The client's initial CID (XXX) is special, and either consists of >>> >>> (a) a randomly chosen dummy CID. Proposal: require this to be >>> 8 bytes or at least a minimum. This should be the same >>> for all Initial packets in a connection (unless a stateless >>> reject is received, as below). >>> (b) a CID which it received from the server in a stateless reject >>> >>> All the server's packets are sent with the client's receive CID (YYY) >>> and all subsequent client packets are sent with the server's receive >>> CID (ZZZ). The general rule is that you should send with the >>> connection ID that you most recently received (where recently >>> is defined as highest PN). >>> >>> Note: I believe it's safe to just use the sending CID as the mixin >>> for the KDF, but I haven't thought this entirely through yet. >>> >>> Finally, you can send NEW_CONNECTION_ID in either direction to provide >>> a new connection ID for the other side to use. The general assumption >>> is that you can do this at any time, just as with current QUIC, and >>> that any time you send to a new remote 3-tuple you should change CIDs >>> if you can. Note that this means that endpoints should try to make >>> sure that the other side has spare CIDs in case they need to migrate. >>> >>> >>> WIRE ENCODING >>> As we discussed in the meeting the short header should just have >>> an implicit length CID. This gives us the following short header: >>> >>> +-+-+-+-+-+-+-+-+ >>> |0|C|K| Type (5)| >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> + [Connection ID (*)] + <- >>> change from 64 >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Packet Number (8/16/32) ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Protected Payload (*) ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> Note that we may also be able to dispense with the C bit, if each >>> side just gets to say "send me this CID exactly", why do we want >>> to say "here is my CID but you can omit it". >>> >>> >>> We have several options about the long header. The first question >>> is where recv-CIDs go. In previous versions I suggested putting >>> them in transport parameters, or elsewhere in the TLS handshake, >>> and that might still be viable, though it has some drawbacks [0], >>> so the other alternative is to put both CIDs in in the long header. >>> This would look something like: >>> >>> +-+-+-+-+-+-+-+-+ >>> |1| Type (7) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | DCID-Length | | >>> +-+-+-+-+-+-+-+-+ Dst Connection ID (*) + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | SCID-Length | | >>> +-+-+-+-+-+-+-+-+ Src Connection ID (*) + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Version (32) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Packet Number (32) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Payload (*) ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> The semantics here are that the first value is the CID you want to >>> send to and the second one is the value you want used to send to you >>> (I've inverted these to keep the order the same as short header). >>> >>> Two notes about this encoding: >>> >>> 1. I think we agreed that we didn't want arbitrary length CIDs up to >>> 255 bytes, and yet we have room in this length byte. I propose we >>> limit it to 31 bytes and then grease the remaining 3 bits [1]. >>> >>> 2. Because the client sends its CID first, there's no way to get the >>> current QUIC semantics of the server just dictates the CID. I propose >>> we fix that by defining a special sentinel CID (all 1s, all 0s, >>> whatever) of whatever our maximum length is that means "just use your >>> own CID". >>> >>> We can endlessly bikeshed on this structure. >>> >>> >>> Finally, we will need to update NEW_CONNECTION_ID to allow a variable >>> length CID. This would look like this: >>> >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Sequence (i) ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | CID-Length | | >>> +-+-+-+-+-+-+-+-+ Connection ID (*) + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> + + >>> | | >>> + Stateless Reset Token (128) + >>> | | >>> + + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> >>> >>> >>> [0] However, in the transport parameters design, if the server's >>> handshake gets reordered, the client might need to send some ACKs with >>> the initial CID. However, we've agreed that the client's IP address >>> has to be stable, so this isn't a problem. Alternately, you could >>> change C->S CIDs in the short header if that was easier. >>> >>> [1] An alternative would be to have a sparse range (e.g., you can >>> express 0-7 and then 8-22 by 2s, assuming I have counted correctly) >>> and then we could pack both lengths into a single byte. As I said, >>> lots of opportunities for bikeshedding here. >>> >>> >> > --94eb2c03548487955f056558aab4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 16, 2018 at 9:52 AM, Martin Duke <martin.h.duke@gmai= l.com> wrote:
Thanks for writing this up, ekr. This incorporates many of the suggesti= ons I made in objection to this project (perhaps coincidentally) and I like= it a lot.

Advantages of this:
- In the common= case where most of the data is server->client, clients can get away wit= h shorter Conn IDs to reduce overhead.
- Omit-conn-id just become= s a case where length =3D 0. Does this sidestep some of Google's transi= tion issues?
- If a client sends NEW_CONNECTION_ID, that indicate= s an intention to migrate, and is a good cue for the server to send the sam= e. We should add a SHOULD to specify this behavior.

I must be missing something, however, regarding implicit CIDs.
=
If there's a NAT rebinding, how is the server supposed t= o extract the CID?

The assumpt= ion is that the server either:

(a) always uses the= same CID length
(b) has a structured CID which starts with the l= ength.

But that we don't need to mandate which= one in the protoocl
=C2=A0
<= div dir=3D"ltr">
Furthermore, this obviates the entire concept of using= Connection ID for routing; it's not obviously a savings to store CID l= ength in a table vs. just storing the destination server.

I don't think you hae to do this, but maybe = I am confused. See above and tell me if you think I'm wrong
<= br>
-Ekr


Lastly, if we encode the length somewhere t= hat seems to solve the Stateless Reset issue.


On Fri, Feb 16, 2018 at 9:25 AM, Ian Swett <ianswett= @google.com> wrote:
Thanks for the excellent summary EKR.=C2=A0 I like this design an= d think the breakage of stateless reset in certain cases is acceptable, sin= ce it only applies if both sides must have their preferred connection ID pr= esent in order to route correctly, which is a use case that's impossibl= e in the status quo.=C2=A0 I have not come up with any other downsides.

On Fri= , Feb 16, 2018 at 12:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,
=
After a bunch of discussion, the CID task force came down to= rough
consensus that asymmetric conn IDs were probably the right=
direction (CID task force members, please feel free to voice dis= sent
here). Here's a complete writeup of what I think would b= e needed
for asymmetric connection IDs. It's not a PR, becaus= e I think
something self-contained is cleaner.

Note that if we adopt this direction, we would be sacrificing
<= div>public reset under some conditions (see previous emails to the
list) and we would need to decide if it was worth keeping at all.


OVERVIEW
The basic idea is that = each side gets to dictate the connection IDs
that are used to sen= d to it. During the handshake, you establish those
CIDs and then = each side can issue new CIDs during the connection.=C2=A0 The
mai= n advantage of this is that it allows for symmetric topologies in which
the client is also behind some kind of stateless LB/router rather th= an
just the server. See Issue #1091 for more info on this.
<= div>

The overall handshake looks something lik= e this:

Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Server

Initial [CID=3DXXX= ] {recv-CID=3DYYY} ---------------->
<-------------- Cleart= ext [CID=3DYYY] {recv-CID=3DZZZ}
Cleartext [CID=3DZZZ], {recv-CID= =3DYYY} ------------->
<-------------------------- Short he= ader [CID=3DYYY]
Short header [CID=3DZZZ] -----------------------= --->


The client's initial CI= D (XXX) is special, and either consists of

=C2=A0 = =C2=A0 (a) a randomly chosen dummy CID. Proposal: require this to be
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 8 bytes or at least a minimum. This should = be the same
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for all Initial packets i= n a connection (unless a stateless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 re= ject is received, as below).
=C2=A0 =C2=A0 (b) a CID which it rec= eived from the server in a stateless reject

All th= e server's packets are sent with the client's receive CID (YYY)
and all subsequent client packets are sent with the server's rec= eive
CID (ZZZ). The general rule is that you should send with the=
connection ID that you most recently received (where recently
is defined as highest PN).

Note: I believe= it's safe to just use the sending CID as the mixin
for the K= DF, but I haven't thought this entirely through yet.

Finally, you can send NEW_CONNECTION_ID in either direction to provi= de
a new connection ID for the other side to use. The general ass= umption
is that you can do this at any time, just as with current= QUIC, and
that any time you send to a new remote 3-tuple you sho= uld change CIDs
if you can. Note that this means that endpoints s= hould try to make
sure that the other side has spare CIDs in case= they need to migrate.


WIRE ENCODIN= G
As we discussed in the meeting the short header should just hav= e
an implicit length CID. This gives us the following short heade= r:

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+
=C2=A0= =C2=A0|0|C|K| Type (5)|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Connection ID (*)]=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+=C2=A0 <- ch= ange from 64
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =C2=A0 =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 Number (8/16/32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Protected Payload (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

No= te that we may also be able to dispense with the C bit, if each
s= ide just gets to say "send me this CID exactly", why do we want
to say "here is my CID but you can omit it".
<= br>

We have several options about the long header.= The first question
is where recv-CIDs go. In previous versions I= suggested putting
them in transport parameters, or elsewhere in = the TLS handshake,
and that might still be viable, though it has = some drawbacks [0],
so the other alternative is to put both CIDs = in in the long header.
This would look something like:
=
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|1|=C2= =A0 =C2=A0Type (7)=C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|= =C2=A0 DCID-Length=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+= -+-+-+-+-+-+=C2=A0 =C2=A0Dst Connection ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 = =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 SCID-Len= gth=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+= =C2=A0 =C2=A0Src Connection ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Version (32)=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pa= cket Number (32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Payload (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<= /div>
The semantics here are that the first value is the CID you want t= o
send to and the second one is the value you want used to send t= o you
(I've inverted these to keep the order the same as shor= t header).

Two notes about this encoding:

1. I think we agreed that we didn't want arbitrary len= gth CIDs up to
255 bytes, and yet we have room in this length byt= e. I propose we
limit it to 31 bytes and then grease the remainin= g 3 bits [1].

2. Because the client sends its CID = first, there's no way to get the
current QUIC semantics of th= e server just dictates the CID.=C2=A0 I propose
we fix that by de= fining a special sentinel CID (all 1s, all 0s,
whatever) of whate= ver our maximum length is that means "just use your
own CID&= quot;.

We can endlessly bikeshed on this structure= .


Finally, we will need to update N= EW_CONNECTION_ID to allow a variable
length CID. This would look = like this:

=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 0 1 2 3 4 5= 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0 =C2= =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Sequence (i)=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 CID-Length=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0= =C2=A0 =C2=A0Connection ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+<= /div>
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Stateless Reset Token (128)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /div>
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+



<= div>[0] However, in the transport parameters design, if the server's
handshake gets reordered, the client might need to send some ACKs w= ith
the initial CID. However, we've agreed that the client= 9;s IP address
has to be stable, so this isn't a problem. Alt= ernately, you could
change C->S CIDs in the short header if th= at was easier.

[1] An alternative would be to have= a sparse range (e.g., you can
express 0-7 and then 8-22 by 2s, a= ssuming I have counted correctly)
and then we could pack both len= gths into a single byte. As I said,
lots of opportunities for bik= eshedding here.




--94eb2c03548487955f056558aab4-- From nobody Fri Feb 16 11:08:23 2018 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 ABE79126CE8 for ; Fri, 16 Feb 2018 11:08:20 -0800 (PST) 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 APA3NA7KixHZ for ; Fri, 16 Feb 2018 11:08:17 -0800 (PST) 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 0773E1242EA for ; Fri, 16 Feb 2018 11:08:17 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id v10so4848447wmh.5 for ; Fri, 16 Feb 2018 11:08:16 -0800 (PST) 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=sfynGCG6HYxUFCd7B+updcrDHv0hGnDjDBvB8w9I7uk=; b=YLb6rTdLaW0OQfwRlXHa5DSli6EIX1NjF5dS8zT4few7Ekm3BqhZ/NRyNxIhGM3Du/ iBSxzVL9bC3zLMka5GvbDD/j5gnyOn+kqd2MFuaBtBieHZvuCLUymMzBk2IuHROCO8br tnTdZT9PfoX+A3UGGKHsRAow8jxY9IAzO9ZjksoT+ZExAm75VBOCzrxJ7Y/MCwFzLEct KHMZRTNERIJ2YihT8IF0iKRQkvx1fouvvCb9JrPuIvbGkn4BVvCS4uMTod/k1UEx8BM5 x+dGY3+03uNn9hDUIYp2LSGy0w9bWa50a3RtPbiqBNXTDOw9glZo9xK1B+CByKroSoGz vf/w== 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=sfynGCG6HYxUFCd7B+updcrDHv0hGnDjDBvB8w9I7uk=; b=YIL9gd4Aurzwr0H31DqfgUWI6u57E4rvngXLbqETdRwzUFyrQzYkBhgnZjSDVKZUpM LzoOxvznbarRi+jNXqkvq1mTU7VcHB5hY4vW2owoW4JKlGOuIW3+7KgkUu+y8cvTaRsy d1iUGGYFUsA3F12s5RbG7NSemQkWhQ1dzLmkfrce2fKCI1hrNzET4cgCX0A6nCf9jrr4 FK3GiKP/wHezC1BoYZK8iSGuUWpEblvND1LsY3qDCSPs8xIagVuh2tuePBALyKGlwsrT nTHTORfWf0/i2K/wBJo5Ifb51VbAAm6+mCcEC8/vB+rQBhmKoTMa6zv8mvAd9Va0Inlg eHLQ== X-Gm-Message-State: APf1xPDqr1Htt8xAVxP/mo6gJfKQct3e0ivZiIhF1TEC4koJeaNXjHUQ WexzDBC985WI7K35DXuN/b1QIGUQFvIoP5GPWHo= X-Google-Smtp-Source: AH8x2270YDamO0Xu56CEtAW9swiY7JNIDiS5roLGW/Ou6FkrIs687Ec6gWcnCFfc31ha/3TuMOxX7mRhM8d90nMyxRg= X-Received: by 10.28.173.130 with SMTP id w124mr5240281wme.18.1518808095434; Fri, 16 Feb 2018 11:08:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.166.71 with HTTP; Fri, 16 Feb 2018 11:08:14 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Fri, 16 Feb 2018 11:08:14 -0800 Message-ID: Subject: Re: Asymmetric CIDs To: Eric Rescorla Cc: Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1144309e02ad9205655911b0" 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, 16 Feb 2018 19:08:21 -0000 --001a1144309e02ad9205655911b0 Content-Type: text/plain; charset="UTF-8" That sounds workable to me. Thanks for clarifying. However, if this is the case then how is Stateless Reset broken? If a load balancer is encoding different lengths in the CID, that introduces additional overhead to a LB/Server communication protocol as I've drafted. It's solvable but annoying. On Fri, Feb 16, 2018 at 10:38 AM, Eric Rescorla wrote: > > > On Fri, Feb 16, 2018 at 9:52 AM, Martin Duke > wrote: > >> Thanks for writing this up, ekr. This incorporates many of the >> suggestions I made in objection to this project (perhaps coincidentally) >> and I like it a lot. >> >> Advantages of this: >> - In the common case where most of the data is server->client, clients >> can get away with shorter Conn IDs to reduce overhead. >> - Omit-conn-id just becomes a case where length = 0. Does this sidestep >> some of Google's transition issues? >> - If a client sends NEW_CONNECTION_ID, that indicates an intention to >> migrate, and is a good cue for the server to send the same. We should add a >> SHOULD to specify this behavior. >> >> I must be missing something, however, regarding implicit CIDs. >> >> If there's a NAT rebinding, how is the server supposed to extract the >> CID? >> > > The assumption is that the server either: > > (a) always uses the same CID length > (b) has a structured CID which starts with the length. > > But that we don't need to mandate which one in the protoocl > > >> Furthermore, this obviates the entire concept of using Connection ID for >> routing; it's not obviously a savings to store CID length in a table vs. >> just storing the destination server. >> > > I don't think you hae to do this, but maybe I am confused. See above and > tell me if you think I'm wrong > > -Ekr > > >> Lastly, if we encode the length somewhere that seems to solve the >> Stateless Reset issue. >> >> >> On Fri, Feb 16, 2018 at 9:25 AM, Ian Swett wrote: >> >>> Thanks for the excellent summary EKR. I like this design and think the >>> breakage of stateless reset in certain cases is acceptable, since it only >>> applies if both sides must have their preferred connection ID present in >>> order to route correctly, which is a use case that's impossible in the >>> status quo. I have not come up with any other downsides. >>> >>> On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla wrote: >>> >>>> Hi folks, >>>> >>>> After a bunch of discussion, the CID task force came down to rough >>>> consensus that asymmetric conn IDs were probably the right >>>> direction (CID task force members, please feel free to voice dissent >>>> here). Here's a complete writeup of what I think would be needed >>>> for asymmetric connection IDs. It's not a PR, because I think >>>> something self-contained is cleaner. >>>> >>>> Note that if we adopt this direction, we would be sacrificing >>>> public reset under some conditions (see previous emails to the >>>> list) and we would need to decide if it was worth keeping at all. >>>> >>>> >>>> OVERVIEW >>>> The basic idea is that each side gets to dictate the connection IDs >>>> that are used to send to it. During the handshake, you establish those >>>> CIDs and then each side can issue new CIDs during the connection. The >>>> main advantage of this is that it allows for symmetric topologies in >>>> which >>>> the client is also behind some kind of stateless LB/router rather than >>>> just the server. See Issue #1091 for more info on this. >>>> >>>> >>>> The overall handshake looks something like this: >>>> >>>> Client Server >>>> >>>> Initial [CID=XXX] {recv-CID=YYY} ----------------> >>>> <-------------- Cleartext [CID=YYY] {recv-CID=ZZZ} >>>> Cleartext [CID=ZZZ], {recv-CID=YYY} -------------> >>>> <-------------------------- Short header [CID=YYY] >>>> Short header [CID=ZZZ] --------------------------> >>>> >>>> >>>> The client's initial CID (XXX) is special, and either consists of >>>> >>>> (a) a randomly chosen dummy CID. Proposal: require this to be >>>> 8 bytes or at least a minimum. This should be the same >>>> for all Initial packets in a connection (unless a stateless >>>> reject is received, as below). >>>> (b) a CID which it received from the server in a stateless reject >>>> >>>> All the server's packets are sent with the client's receive CID (YYY) >>>> and all subsequent client packets are sent with the server's receive >>>> CID (ZZZ). The general rule is that you should send with the >>>> connection ID that you most recently received (where recently >>>> is defined as highest PN). >>>> >>>> Note: I believe it's safe to just use the sending CID as the mixin >>>> for the KDF, but I haven't thought this entirely through yet. >>>> >>>> Finally, you can send NEW_CONNECTION_ID in either direction to provide >>>> a new connection ID for the other side to use. The general assumption >>>> is that you can do this at any time, just as with current QUIC, and >>>> that any time you send to a new remote 3-tuple you should change CIDs >>>> if you can. Note that this means that endpoints should try to make >>>> sure that the other side has spare CIDs in case they need to migrate. >>>> >>>> >>>> WIRE ENCODING >>>> As we discussed in the meeting the short header should just have >>>> an implicit length CID. This gives us the following short header: >>>> >>>> +-+-+-+-+-+-+-+-+ >>>> |0|C|K| Type (5)| >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> + [Connection ID (*)] + >>>> <- change from 64 >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Packet Number (8/16/32) ... >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Protected Payload (*) ... >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> Note that we may also be able to dispense with the C bit, if each >>>> side just gets to say "send me this CID exactly", why do we want >>>> to say "here is my CID but you can omit it". >>>> >>>> >>>> We have several options about the long header. The first question >>>> is where recv-CIDs go. In previous versions I suggested putting >>>> them in transport parameters, or elsewhere in the TLS handshake, >>>> and that might still be viable, though it has some drawbacks [0], >>>> so the other alternative is to put both CIDs in in the long header. >>>> This would look something like: >>>> >>>> +-+-+-+-+-+-+-+-+ >>>> |1| Type (7) | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | DCID-Length | | >>>> +-+-+-+-+-+-+-+-+ Dst Connection ID (*) + >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | SCID-Length | | >>>> +-+-+-+-+-+-+-+-+ Src Connection ID (*) + >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Version (32) | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Packet Number (32) | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Payload (*) ... >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> The semantics here are that the first value is the CID you want to >>>> send to and the second one is the value you want used to send to you >>>> (I've inverted these to keep the order the same as short header). >>>> >>>> Two notes about this encoding: >>>> >>>> 1. I think we agreed that we didn't want arbitrary length CIDs up to >>>> 255 bytes, and yet we have room in this length byte. I propose we >>>> limit it to 31 bytes and then grease the remaining 3 bits [1]. >>>> >>>> 2. Because the client sends its CID first, there's no way to get the >>>> current QUIC semantics of the server just dictates the CID. I propose >>>> we fix that by defining a special sentinel CID (all 1s, all 0s, >>>> whatever) of whatever our maximum length is that means "just use your >>>> own CID". >>>> >>>> We can endlessly bikeshed on this structure. >>>> >>>> >>>> Finally, we will need to update NEW_CONNECTION_ID to allow a variable >>>> length CID. This would look like this: >>>> >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Sequence (i) ... >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | CID-Length | | >>>> +-+-+-+-+-+-+-+-+ Connection ID (*) + >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> + + >>>> | | >>>> + Stateless Reset Token (128) + >>>> | | >>>> + + >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> >>>> >>>> >>>> [0] However, in the transport parameters design, if the server's >>>> handshake gets reordered, the client might need to send some ACKs with >>>> the initial CID. However, we've agreed that the client's IP address >>>> has to be stable, so this isn't a problem. Alternately, you could >>>> change C->S CIDs in the short header if that was easier. >>>> >>>> [1] An alternative would be to have a sparse range (e.g., you can >>>> express 0-7 and then 8-22 by 2s, assuming I have counted correctly) >>>> and then we could pack both lengths into a single byte. As I said, >>>> lots of opportunities for bikeshedding here. >>>> >>>> >>> >> > --001a1144309e02ad9205655911b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

That sounds workable to me. Thanks for clarifying. How= ever, if this is the case then how is Stateless Reset broken?

If a load balancer is encoding different lengths in the CID, that int= roduces additional overhead to a LB/Server communication protocol as I'= ve drafted. It's solvable but annoying.

<= div class=3D"gmail_extra">
On Fri, Feb 16, 20= 18 at 10:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Fri, Feb 16, 2018 at 9:52 AM, = Martin Duke <martin.h.duke@gmail.com> wrote:
Thanks for writing this up, ekr. = This incorporates many of the suggestions I made in objection to this proje= ct (perhaps coincidentally) and I like it a lot.

Advanta= ges of this:
- In the common case where most of the data is serve= r->client, clients can get away with shorter Conn IDs to reduce overhead= .
- Omit-conn-id just becomes a case where length =3D 0. Does thi= s sidestep some of Google's transition issues?
- If a client = sends NEW_CONNECTION_ID, that indicates an intention to migrate, and is a g= ood cue for the server to send the same. We should add a SHOULD to specify = this behavior.

I must be missing something, howeve= r, regarding implicit CIDs.

If there's a NAT r= ebinding, how is the server supposed to extract the CID?

The assumption is that the server either:=

(a) always uses the same CID length
(b)= has a structured CID which starts with the length.

But that we don't need to mandate which one in the protoocl
=C2=A0
Furthermore, this obviates the entire concept of using Connection I= D for routing; it's not obviously a savings to store CID length in a ta= ble vs. just storing the destination server.
<= br>
I don't think you hae to do this, but maybe I am c= onfused. See above and tell me if you think I'm wrong

-Ekr


Lastly, if we encode the= length somewhere that seems to solve the Stateless Reset issue.
=

On Fri, Feb 16, 2018 at 9:25 AM, Ian Swett <ianswett@google.com<= /a>> wrote:
Th= anks for the excellent summary EKR.=C2=A0 I like this design and think the = breakage of stateless reset in certain cases is acceptable, since it only a= pplies if both sides must have their preferred connection ID present in ord= er to route correctly, which is a use case that's impossible in the sta= tus quo.=C2=A0 I have not come up with any other downsides.

<= div class=3D"gmail_quote">On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla <= span dir=3D"ltr"><ekr@= rtfm.com> wrote:
Hi folks,

After a bunch of discussio= n, the CID task force came down to rough
consensus that asymmetri= c conn IDs were probably the right
direction (CID task force memb= ers, please feel free to voice dissent
here). Here's a comple= te writeup of what I think would be needed
for asymmetric connect= ion IDs. It's not a PR, because I think
something self-contai= ned is cleaner.

Note that if we adopt this directi= on, we would be sacrificing
public reset under some conditions (s= ee previous emails to the
list) and we would need to decide if it= was worth keeping at all.


OVERVIEW=
The basic idea is that each side gets to dictate the connection = IDs
that are used to send to it. During the handshake, you establ= ish those
CIDs and then each side can issue new CIDs during the c= onnection.=C2=A0 The
main advantage of this is that it allows for= symmetric topologies in which
the client is also behind some kin= d of stateless LB/router rather than
just the server. See Issue #= 1091 for more info on this.


The ove= rall handshake looks something like this:

Client= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server

Initial [CID=3DXXX] {recv-CID=3DYYY} ----------------><= /div>
<-------------- Cleartext [CID=3DYYY] {recv-CID=3DZZZ}
Cleartext [CID=3DZZZ], {recv-CID=3DYYY} ------------->
<= -------------------------- Short header [CID=3DYYY]
Short header = [CID=3DZZZ] -------------------------->


The client's initial CID (XXX) is special, and either consists = of

=C2=A0 =C2=A0 (a) a randomly chosen dummy CID. = Proposal: require this to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 8 bytes = or at least a minimum. This should be the same
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 for all Initial packets in a connection (unless a stateless
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reject is received, as below).
= =C2=A0 =C2=A0 (b) a CID which it received from the server in a stateless re= ject

All the server's packets are sent with th= e client's receive CID (YYY)
and all subsequent client packet= s are sent with the server's receive
CID (ZZZ). The general r= ule is that you should send with the
connection ID that you most = recently received (where recently
is defined as highest PN).

Note: I believe it's safe to just use the sending = CID as the mixin
for the KDF, but I haven't thought this enti= rely through yet.

Finally, you can send NEW_CONNEC= TION_ID in either direction to provide
a new connection ID for th= e other side to use. The general assumption
is that you can do th= is at any time, just as with current QUIC, and
that any time you = send to a new remote 3-tuple you should change CIDs
if you can. N= ote that this means that endpoints should try to make
sure that t= he other side has spare CIDs in case they need to migrate.


WIRE ENCODING
As we discussed in the meet= ing the short header should just have
an implicit length CID. Thi= s gives us the following short header:

=C2=A0 =C2= =A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|0|C|K| Type (5)|
=C2= =A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= wbr>-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Connecti= on ID (*)]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+=C2=A0 <- change from 64
=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =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 Number (8/16= /32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Protected Payload (*)=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2= =A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= wbr>-+-+-+

Note that we may also be able to dispen= se with the C bit, if each
side just gets to say "send me th= is CID exactly", why do we want
to say "here is my CID = but you can omit it".


We have = several options about the long header. The first question
is wher= e recv-CIDs go. In previous versions I suggested putting
them in = transport parameters, or elsewhere in the TLS handshake,
and that= might still be viable, though it has some drawbacks [0],
so the = other alternative is to put both CIDs in in the long header.
This= would look something like:

=C2=A0 =C2=A0+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|1|=C2=A0 =C2=A0Type (7)=C2=A0 |
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 DCID-Length=C2=A0 |=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0Dst Connec= tion ID (*)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 SCID-Length=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0Src Connection ID (*)=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Version (32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 = =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet Number (32)=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= =C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Payload (*)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+

The semantics here= are that the first value is the CID you want to
send to and the = second one is the value you want used to send to you
(I've in= verted these to keep the order the same as short header).

Two notes about this encoding:

1. I think = we agreed that we didn't want arbitrary length CIDs up to
255= bytes, and yet we have room in this length byte. I propose we
li= mit it to 31 bytes and then grease the remaining 3 bits [1].

=
2. Because the client sends its CID first, there's no way to= get the
current QUIC semantics of the server just dictates the C= ID.=C2=A0 I propose
we fix that by defining a special sentinel CI= D (all 1s, all 0s,
whatever) of whatever our maximum length is th= at means "just use your
own CID".

<= div>We can endlessly bikeshed on this structure.

<= br>
Finally, we will need to update NEW_CONNECTION_ID to allow a = variable
length CID. This would look like this:

=C2=A0 =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A03
=C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9= 0 1 2 3 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Sequence (i)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 CID-Length=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0 =C2=A0 =C2=A0Connection ID (= *)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /div>
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Stateless Reset Token (128)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
= =C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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] However, in the tran= sport parameters design, if the server's
handshake gets reord= ered, the client might need to send some ACKs with
the initial CI= D. However, we've agreed that the client's IP address
has= to be stable, so this isn't a problem. Alternately, you could
change C->S CIDs in the short header if that was easier.
[1] An alternative would be to have a sparse range (e.g., you c= an
express 0-7 and then 8-22 by 2s, assuming I have counted corre= ctly)
and then we could pack both lengths into a single byte. As = I said,
lots of opportunities for bikeshedding here.




--001a1144309e02ad9205655911b0-- From nobody Fri Feb 16 11:32:29 2018 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 4B57B120727 for ; Fri, 16 Feb 2018 11:32:26 -0800 (PST) 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 GYclK70ClzxP for ; Fri, 16 Feb 2018 11:32:23 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002: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 43C761200C1 for ; Fri, 16 Feb 2018 11:32:23 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id s79-v6so951354ybs.0 for ; Fri, 16 Feb 2018 11:32:23 -0800 (PST) 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=upSGvM2SO/Hb+qoZDXdZY6x3j+g4hJfl20EPfe8b99M=; b=hryLl/prl7YNmlRJKuzvsxNfl8kLIDclThPRQC/TSmb/TwwwANk6pfVz8C8Am5DBe4 LA7CffnUVYlILwtG4VBvI9zH9yAyKlSCGIz9MxjhiCahSuzIOKYK0zvc0ijznjaz0vf8 Ygw/njnlvFcusbyAWNbkV/Vit9nAt8QYTj7tJUHegFR/ApZOxXF30EBHpdkSGfayhkIG Eg8FJx9xd86ltel6Z5MSZpFX5n1BzZGM6sDGCyuSN+IaYISYHbGNcREzOGoKvcqnKSzv Zs/fZv1VYaLdLXk1G0Z37PAUJu0FlSQ+RJIiRGUi3p20unTa7dfzjo8/BkAqIxQGWchW YAxg== 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=upSGvM2SO/Hb+qoZDXdZY6x3j+g4hJfl20EPfe8b99M=; b=ucgyi92d0B4LEt6rH2o7B7sKs6g5yvj7I5gFm50ESjA2Z47syd8mApdFqAIp6w51cA reZXj/QaFeRj3D6DBRO94QYZ6UOZRGcZadXyb4zfSWJ8SCOg4ZB8iywxUSbE5qyn7zQI 4sDS4sSCj1lfBmBVLTX6BpqRGMX2lNNeBdkVYgLySgpWxiollpIkIdRIBd9xVvlOpOyX uySVXSqzOuSiJ7dEywv05niUb5KSjNCgqmhnDjgbnrhg9Hjs/MjTVmthG8ZcakCOf6He a5P4WumnePw77t4gzce2/wAEP/0tE0qXGwu8MKFBj0fW0BInB4siN7S5uUOOIv1ZtuF4 9yeQ== X-Gm-Message-State: APf1xPD/R4tqVYKJmuU04T/HNczghqewehBQ79H6aH54Acf98QrxhSj+ k9GcahajalTck2zAQe1efFjt7xsOBsMU2UXxd3Tlcg== X-Google-Smtp-Source: AH8x227aPEDTe4PMjXeRT4y4di13X5PBa7mckr8BVt88KtJOqcC9Wsvcj/woOGM3DZB1hJXtBsGYtNV+JMoOQslYPHM= X-Received: by 10.37.228.134 with SMTP id b128mr5516840ybh.474.1518809542340; Fri, 16 Feb 2018 11:32:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.114.10 with HTTP; Fri, 16 Feb 2018 11:31:41 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 16 Feb 2018 11:31:41 -0800 Message-ID: Subject: Re: Asymmetric CIDs To: Martin Duke Cc: Ian Swett , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114bb0ac40fbf80565596732" 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, 16 Feb 2018 19:32:26 -0000 --001a114bb0ac40fbf80565596732 Content-Type: text/plain; charset="UTF-8" On Fri, Feb 16, 2018 at 11:08 AM, Martin Duke wrote: > > That sounds workable to me. Thanks for clarifying. However, if this is the > case then how is Stateless Reset broken? > The server knows it's CID (from the offending packet) but doesn't know the client's CID (because it's statelsss), so when it sends SR, there's a chance it gets misrouted at the client. -Ekr > > If a load balancer is encoding different lengths in the CID, that > introduces additional overhead to a LB/Server communication protocol as > I've drafted. It's solvable but annoying. > > > On Fri, Feb 16, 2018 at 10:38 AM, Eric Rescorla wrote: > >> >> >> On Fri, Feb 16, 2018 at 9:52 AM, Martin Duke >> wrote: >> >>> Thanks for writing this up, ekr. This incorporates many of the >>> suggestions I made in objection to this project (perhaps coincidentally) >>> and I like it a lot. >>> >>> Advantages of this: >>> - In the common case where most of the data is server->client, clients >>> can get away with shorter Conn IDs to reduce overhead. >>> - Omit-conn-id just becomes a case where length = 0. Does this sidestep >>> some of Google's transition issues? >>> - If a client sends NEW_CONNECTION_ID, that indicates an intention to >>> migrate, and is a good cue for the server to send the same. We should add a >>> SHOULD to specify this behavior. >>> >>> I must be missing something, however, regarding implicit CIDs. >>> >>> If there's a NAT rebinding, how is the server supposed to extract the >>> CID? >>> >> >> The assumption is that the server either: >> >> (a) always uses the same CID length >> (b) has a structured CID which starts with the length. >> >> But that we don't need to mandate which one in the protoocl >> >> >>> Furthermore, this obviates the entire concept of using Connection ID for >>> routing; it's not obviously a savings to store CID length in a table vs. >>> just storing the destination server. >>> >> >> I don't think you hae to do this, but maybe I am confused. See above and >> tell me if you think I'm wrong >> >> -Ekr >> >> >>> Lastly, if we encode the length somewhere that seems to solve the >>> Stateless Reset issue. >>> >>> >>> On Fri, Feb 16, 2018 at 9:25 AM, Ian Swett wrote: >>> >>>> Thanks for the excellent summary EKR. I like this design and think the >>>> breakage of stateless reset in certain cases is acceptable, since it only >>>> applies if both sides must have their preferred connection ID present in >>>> order to route correctly, which is a use case that's impossible in the >>>> status quo. I have not come up with any other downsides. >>>> >>>> On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla wrote: >>>> >>>>> Hi folks, >>>>> >>>>> After a bunch of discussion, the CID task force came down to rough >>>>> consensus that asymmetric conn IDs were probably the right >>>>> direction (CID task force members, please feel free to voice dissent >>>>> here). Here's a complete writeup of what I think would be needed >>>>> for asymmetric connection IDs. It's not a PR, because I think >>>>> something self-contained is cleaner. >>>>> >>>>> Note that if we adopt this direction, we would be sacrificing >>>>> public reset under some conditions (see previous emails to the >>>>> list) and we would need to decide if it was worth keeping at all. >>>>> >>>>> >>>>> OVERVIEW >>>>> The basic idea is that each side gets to dictate the connection IDs >>>>> that are used to send to it. During the handshake, you establish those >>>>> CIDs and then each side can issue new CIDs during the connection. The >>>>> main advantage of this is that it allows for symmetric topologies in >>>>> which >>>>> the client is also behind some kind of stateless LB/router rather than >>>>> just the server. See Issue #1091 for more info on this. >>>>> >>>>> >>>>> The overall handshake looks something like this: >>>>> >>>>> Client Server >>>>> >>>>> Initial [CID=XXX] {recv-CID=YYY} ----------------> >>>>> <-------------- Cleartext [CID=YYY] {recv-CID=ZZZ} >>>>> Cleartext [CID=ZZZ], {recv-CID=YYY} -------------> >>>>> <-------------------------- Short header [CID=YYY] >>>>> Short header [CID=ZZZ] --------------------------> >>>>> >>>>> >>>>> The client's initial CID (XXX) is special, and either consists of >>>>> >>>>> (a) a randomly chosen dummy CID. Proposal: require this to be >>>>> 8 bytes or at least a minimum. This should be the same >>>>> for all Initial packets in a connection (unless a stateless >>>>> reject is received, as below). >>>>> (b) a CID which it received from the server in a stateless reject >>>>> >>>>> All the server's packets are sent with the client's receive CID (YYY) >>>>> and all subsequent client packets are sent with the server's receive >>>>> CID (ZZZ). The general rule is that you should send with the >>>>> connection ID that you most recently received (where recently >>>>> is defined as highest PN). >>>>> >>>>> Note: I believe it's safe to just use the sending CID as the mixin >>>>> for the KDF, but I haven't thought this entirely through yet. >>>>> >>>>> Finally, you can send NEW_CONNECTION_ID in either direction to provide >>>>> a new connection ID for the other side to use. The general assumption >>>>> is that you can do this at any time, just as with current QUIC, and >>>>> that any time you send to a new remote 3-tuple you should change CIDs >>>>> if you can. Note that this means that endpoints should try to make >>>>> sure that the other side has spare CIDs in case they need to migrate. >>>>> >>>>> >>>>> WIRE ENCODING >>>>> As we discussed in the meeting the short header should just have >>>>> an implicit length CID. This gives us the following short header: >>>>> >>>>> +-+-+-+-+-+-+-+-+ >>>>> |0|C|K| Type (5)| >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | | >>>>> + [Connection ID (*)] + >>>>> <- change from 64 >>>>> | | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Packet Number (8/16/32) ... >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Protected Payload (*) ... >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> Note that we may also be able to dispense with the C bit, if each >>>>> side just gets to say "send me this CID exactly", why do we want >>>>> to say "here is my CID but you can omit it". >>>>> >>>>> >>>>> We have several options about the long header. The first question >>>>> is where recv-CIDs go. In previous versions I suggested putting >>>>> them in transport parameters, or elsewhere in the TLS handshake, >>>>> and that might still be viable, though it has some drawbacks [0], >>>>> so the other alternative is to put both CIDs in in the long header. >>>>> This would look something like: >>>>> >>>>> +-+-+-+-+-+-+-+-+ >>>>> |1| Type (7) | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | DCID-Length | | >>>>> +-+-+-+-+-+-+-+-+ Dst Connection ID (*) + >>>>> | | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | SCID-Length | | >>>>> +-+-+-+-+-+-+-+-+ Src Connection ID (*) + >>>>> | | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Version (32) | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Packet Number (32) | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Payload (*) ... >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> The semantics here are that the first value is the CID you want to >>>>> send to and the second one is the value you want used to send to you >>>>> (I've inverted these to keep the order the same as short header). >>>>> >>>>> Two notes about this encoding: >>>>> >>>>> 1. I think we agreed that we didn't want arbitrary length CIDs up to >>>>> 255 bytes, and yet we have room in this length byte. I propose we >>>>> limit it to 31 bytes and then grease the remaining 3 bits [1]. >>>>> >>>>> 2. Because the client sends its CID first, there's no way to get the >>>>> current QUIC semantics of the server just dictates the CID. I propose >>>>> we fix that by defining a special sentinel CID (all 1s, all 0s, >>>>> whatever) of whatever our maximum length is that means "just use your >>>>> own CID". >>>>> >>>>> We can endlessly bikeshed on this structure. >>>>> >>>>> >>>>> Finally, we will need to update NEW_CONNECTION_ID to allow a variable >>>>> length CID. This would look like this: >>>>> >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Sequence (i) ... >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | CID-Length | | >>>>> +-+-+-+-+-+-+-+-+ Connection ID (*) + >>>>> | | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | | >>>>> + + >>>>> | | >>>>> + Stateless Reset Token (128) + >>>>> | | >>>>> + + >>>>> | | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> >>>>> >>>>> >>>>> [0] However, in the transport parameters design, if the server's >>>>> handshake gets reordered, the client might need to send some ACKs with >>>>> the initial CID. However, we've agreed that the client's IP address >>>>> has to be stable, so this isn't a problem. Alternately, you could >>>>> change C->S CIDs in the short header if that was easier. >>>>> >>>>> [1] An alternative would be to have a sparse range (e.g., you can >>>>> express 0-7 and then 8-22 by 2s, assuming I have counted correctly) >>>>> and then we could pack both lengths into a single byte. As I said, >>>>> lots of opportunities for bikeshedding here. >>>>> >>>>> >>>> >>> >> > --001a114bb0ac40fbf80565596732 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 16, 2018 at 11:08 AM, Martin Duke <martin.h.duke@gma= il.com> wrote:

That sounds workable to me. Thanks for clarifying. However, if thi= s is the case then how is Stateless Reset broken?
The server knows it's CID (from the offending packet) but = doesn't know the client's CID (because it's statelsss), so when= it sends SR, there's a chance it gets misrouted at the client.

-Ekr
=C2=A0

If a load balancer is encoding differ= ent lengths in the CID, that introduces additional overhead to a LB/Server = communication protocol as I've drafted. It's solvable but annoying.=


On Fri, Feb 16, 2018 = at 10:38 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Fri, Feb 16, 2018 at 9:52 AM, Martin Duke <martin.h.duke@gmail.com> wrote:
Thanks for writing this up, ekr. This incorpora= tes many of the suggestions I made in objection to this project (perhaps co= incidentally) and I like it a lot.

Advantages of this:
- In the common case where most of the data is server->client, = clients can get away with shorter Conn IDs to reduce overhead.
- = Omit-conn-id just becomes a case where length =3D 0. Does this sidestep som= e of Google's transition issues?
- If a client sends NEW_CONN= ECTION_ID, that indicates an intention to migrate, and is a good cue for th= e server to send the same. We should add a SHOULD to specify this behavior.=

I must be missing something, however, regarding i= mplicit CIDs.

If there's a NAT rebinding, how = is the server supposed to extract the CID?
The assumption is that the server either:
(a) always uses the same CID length
(b) has a structu= red CID which starts with the length.

But that we = don't need to mandate which one in the protoocl
=C2=A0<= /div>
Furthermore, this= obviates the entire concept of using Connection ID for routing; it's n= ot obviously a savings to store CID length in a table vs. just storing the = destination server.

I do= n't think you hae to do this, but maybe I am confused. See above and te= ll me if you think I'm wrong

-Ekr


Lastly, if we encode the length= somewhere that seems to solve the Stateless Reset issue.


On Fri, Feb 16, 2018 at 9:25 AM, I= an Swett <ianswett@google.com> wrote:
Thanks for the excellent summary EKR.=C2=A0 = I like this design and think the breakage of stateless reset in certain cas= es is acceptable, since it only applies if both sides must have their prefe= rred connection ID present in order to route correctly, which is a use case= that's impossible in the status quo.=C2=A0 I have not come up with any= other downsides.

On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla <ekr@rt= fm.com> wrote:
Hi folks,

After a bunch of discussion, t= he CID task force came down to rough
consensus that asymmetric co= nn IDs were probably the right
direction (CID task force members,= please feel free to voice dissent
here). Here's a complete w= riteup of what I think would be needed
for asymmetric connection = IDs. It's not a PR, because I think
something self-contained = is cleaner.

Note that if we adopt this direction, = we would be sacrificing
public reset under some conditions (see p= revious emails to the
list) and we would need to decide if it was= worth keeping at all.


OVERVIEW
The basic idea is that each side gets to dictate the connection IDs<= /div>
that are used to send to it. During the handshake, you establish = those
CIDs and then each side can issue new CIDs during the conne= ction.=C2=A0 The
main advantage of this is that it allows for sym= metric topologies in which
the client is also behind some kind of= stateless LB/router rather than
just the server. See Issue #1091= for more info on this.


The overall= handshake looks something like this:

Client=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Server

<= /div>
Initial [CID=3DXXX] {recv-CID=3DYYY} ---------------->
<-------------- Cleartext [CID=3DYYY] {recv-CID=3DZZZ}
Clea= rtext [CID=3DZZZ], {recv-CID=3DYYY} ------------->
<-------= ------------------- Short header [CID=3DYYY]
Short header [CID=3D= ZZZ] -------------------------->


The client's initial CID (XXX) is special, and either consists of

=C2=A0 =C2=A0 (a) a randomly chosen dummy CID. Proposa= l: require this to be
=C2=A0 =C2=A0 =C2=A0 =C2=A0 8 bytes or at l= east a minimum. This should be the same
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 for all Initial packets in a connection (unless a stateless
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 reject is received, as below).
=C2=A0= =C2=A0 (b) a CID which it received from the server in a stateless reject

All the server's packets are sent with the clie= nt's receive CID (YYY)
and all subsequent client packets are = sent with the server's receive
CID (ZZZ). The general rule is= that you should send with the
connection ID that you most recent= ly received (where recently
is defined as highest PN).
=
Note: I believe it's safe to just use the sending CID as= the mixin
for the KDF, but I haven't thought this entirely t= hrough yet.

Finally, you can send NEW_CONNECTION_I= D in either direction to provide
a new connection ID for the othe= r side to use. The general assumption
is that you can do this at = any time, just as with current QUIC, and
that any time you send t= o a new remote 3-tuple you should change CIDs
if you can. Note th= at this means that endpoints should try to make
sure that the oth= er side has spare CIDs in case they need to migrate.


WIRE ENCODING
As we discussed in the meeting th= e short header should just have
an implicit length CID. This give= s us the following short header:

=C2=A0 =C2=A0+-+-= +-+-+-+-+-+-+
=C2=A0 =C2=A0|0|C|K| Type (5)|
=C2=A0 =C2= =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Connection ID (= *)]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0+=C2=A0 <- change from 64
=C2=A0 =C2=A0|=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+
=C2=A0 =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 Number (8/16/32)=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2= =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Protected Payload (*)=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

Note that we may also be able to dispense with th= e C bit, if each
side just gets to say "send me this CID exa= ctly", why do we want
to say "here is my CID but you ca= n omit it".


We have several op= tions about the long header. The first question
is where recv-CID= s go. In previous versions I suggested putting
them in transport = parameters, or elsewhere in the TLS handshake,
and that might sti= ll be viable, though it has some drawbacks [0],
so the other alte= rnative is to put both CIDs in in the long header.
This would loo= k something like:

=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|1|=C2=A0 =C2=A0Type (7)=C2=A0 |
=C2=A0 =C2= =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+
=C2=A0 =C2=A0|=C2=A0 DCID-Length=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /div>
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0Dst Connection ID (*)= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
= =C2=A0 =C2=A0|=C2=A0 SCID-Length=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2= =A0 =C2=A0+-+-+-+-+-+-+-+-+=C2=A0 =C2=A0Src Connection ID (*)=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= wbr>-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Version (32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet Number (32)=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /div>
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Payload (*)=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+

The semantics here are that the fi= rst value is the CID you want to
send to and the second one is th= e value you want used to send to you
(I've inverted these to = keep the order the same as short header).

Two note= s about this encoding:

1. I think we agreed that w= e didn't want arbitrary length CIDs up to
255 bytes, and yet = we have room in this length byte. I propose we
limit it to 31 byt= es and then grease the remaining 3 bits [1].

2. Be= cause the client sends its CID first, there's no way to get the
current QUIC semantics of the server just dictates the CID.=C2=A0 I prop= ose
we fix that by defining a special sentinel CID (all 1s, all 0= s,
whatever) of whatever our maximum length is that means "j= ust use your
own CID".

We can endle= ssly bikeshed on this structure.


Fi= nally, we will need to update NEW_CONNECTION_ID to allow a variable
length CID. This would look like this:

=C2=A0 = =C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A0 =C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7= 8 9 0 1
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 S= equence (i)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2= =A0 CID-Length=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-= +-+-+-+-+-+-+-+=C2=A0 =C2=A0 =C2=A0 =C2=A0Connection ID (*)=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= wbr>-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=C2=A0 =C2=A0|=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= /div>
=C2=A0 =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 = =C2=A0+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Stateless Reset Token (128)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0+
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0+=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+<= /div>
=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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] However, in the transport parameters d= esign, if the server's
handshake gets reordered, the client m= ight need to send some ACKs with
the initial CID. However, we'= ;ve agreed that the client's IP address
has to be stable, so = this isn't a problem. Alternately, you could
change C->S C= IDs in the short header if that was easier.

[1] An= alternative would be to have a sparse range (e.g., you can
expre= ss 0-7 and then 8-22 by 2s, assuming I have counted correctly)
an= d then we could pack both lengths into a single byte. As I said,
= lots of opportunities for bikeshedding here.






--001a114bb0ac40fbf80565596732-- From nobody Fri Feb 16 14:10:38 2018 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 4E2CB1200F1 for ; Fri, 16 Feb 2018 14:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KyhElnG28KYj for ; Fri, 16 Feb 2018 14:10:35 -0800 (PST) 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 145EA12008A for ; Fri, 16 Feb 2018 14:10:35 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1emoD9-0001MG-Ki for quic@ietf.org; Fri, 16 Feb 2018 23:10:32 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1emoD3-0006Zt-2g for quic@ietf.org; Fri, 16 Feb 2018 17:10:29 -0500 Received: (qmail 27664 invoked from network); 16 Feb 2018 22:10:22 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.15]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Feb 2018 22:10:22 -0000 To: Roberto Peon , Martin Duke Cc: Ian Swett , IETF QUIC WG , Eric Rescorla References: From: Christian Huitema Message-ID: <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> Date: Fri, 16 Feb 2018 14:10:04 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------12AF80F802C4B4267D03B2AD" Content-Language: en-US Subject: Re: Asymmetric CIDs X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.24) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ncpEkrEtdEgkZbOKdC6dWp602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVizblJ3W8r5WS83P3m1qokdc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBIHx9JssK7pObMLBvND2dCPvRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0ClKHhIXfDbmhz3DoftFSAfVIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM81CaOu2xwDQxDsUgSvK+nIDy+yhRvBV7fdCR4x+Vz4 E4FIt+dZfSoAQwUdaubYy98KL9XPdPGScVe8FmIoRTyA3ll/MP5CnqUbQTCeIeRykmj55Nl155o2 Oe/0FuVZZmVzxAG+DjqL5QSEyTpqxgd+hoJiRUJS+7Nru8G8qObMBABriH3x3J15D78KylFpBEO/ SWpFaZhl6XgNy1goGNwkD/7Rwl5fb+U9Gl2IOh9znujQvrMxarlENT5/SCJnk5HQ+XNr4QUyZNz0 uLvRKYxZQqF/LoUsSniF4plClx3amZu7g1G85g3tpmOSnw4/exoERpFEqF2lExBUp1VMiBudqf56 vTMbt2qnAITT5tZcBzF9mE6flINXEXJL2r3PrBjLoydbuOy1i9SfmYgxBbq3mdySlZou9qHIGOZD EEo7O+Pd3ebmKuucUVzXcVqfEwQXQ+sESjyASrM/THMyWUoiolU4x0KD113J1SYnBP2uKg== 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: Fri, 16 Feb 2018 22:10:37 -0000 This is a multi-part message in MIME format. --------------12AF80F802C4B4267D03B2AD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To be explicit, I am concerned by the following scenario: 1) Client sends a PATH CHALLENGE to server from a new client address with never-seen-before connection ID, obtained previously in NEW CONNECTION ID frame from server 2) Server respond by sending reply to new address with previously-negotiated-and-used CID of client. 3) Instant linkage. The key is of course that the server picks a different CID to respond to the migration, normally in a NEW CONNECTION ID frame. On 2/16/2018 10:25 AM, Roberto Peon wrote: > > ++ what Christian says. > The fact that it now takes two implementations to prevent linkability > (either side messes it up, and that half-path is exposed, likely > rendering it all exposed) is a bit sad. > > -=3DR > > =C2=A0 > > =C2=A0 > > *From: *QUIC on behalf of Christian Huitema > > *Date: *Friday, February 16, 2018 at 10:16 AM > *To: *Martin Duke > *Cc: *Ian Swett , IETF QUIC WG , > Eric Rescorla > *Subject: *Re: Asymmetric CIDs > > =C2=A0 > > I like the concept, but I would like to understand how we avoid > linkability on migration. > > -- Christian Huitema=C2=A0 > --------------12AF80F802C4B4267D03B2AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

To be explicit, I am concerned by the following scenario:

1) Client sends a PATH CHALLENGE to server from a new client address with never-seen-before connection ID, obtained previously in NEW CONNECTION ID frame from server

2) Server respond by sending reply to new address with previously-negotiated-and-used CID of client.

3) Instant linkage.

The key is of course that the server picks a different CID to respond to the migration, normally in a NEW CONNECTION ID frame.


On 2/16/2018 10:25 AM, Roberto Peon wrote:

++ what Christian says.
The fact that it now takes two implementations to prevent linkability (either side messes it up, and that half-path is exposed, likely rendering it all exposed) is a bit sad.

-=R

 

 

From: QUIC <quic-bounces@ietf.org> on behalf of Christian Huitema <huitema@huitema.net>
Date: Friday, February 16, 2018 at 10:16 AM
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Ian Swett <ianswett@google.com>, IETF QUIC WG <quic@ietf.org>, Eric Rescorla <ekr@rtfm.com>
Subject: Re: Asymmetric CIDs

 

I like the concept, but I would like to understand how we avoid linkability on migration.

-- Christian Huitema 


--------------12AF80F802C4B4267D03B2AD-- From nobody Fri Feb 16 14:17:16 2018 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 7B0CF1241F3 for ; Fri, 16 Feb 2018 14:17:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, 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=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 lt-0U2sH2brD for ; Fri, 16 Feb 2018 14:17:12 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0113.outbound.protection.outlook.com [104.47.38.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88A91200F1 for ; Fri, 16 Feb 2018 14:17:12 -0800 (PST) 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=WiCM/beiEd2apuve4nsgOoJnvqD0IlVRUMZ1aS/2c2U=; b=jc7Dfpmu/IeuqrE2Ca2nACRodOsWp8vNy2GqTsf3qSuJCNv2huqn38OGJaWq7jIYQxpLxMAiURs2cRvHhuPzgQNiKDuWAZ/zRQXKAM2ZZyZPoxtkvUjngA/X24/CoR+nN9/anu2zyjiS4jFyw+08dGhB4XU0moayb0z2xs8Ct7E= Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0755.namprd21.prod.outlook.com (10.173.204.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.2; Fri, 16 Feb 2018 22:17:10 +0000 Received: from BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) by BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) with mapi id 15.20.0527.012; Fri, 16 Feb 2018 22:17:10 +0000 From: Nick Banks To: huitema , Roberto Peon , Martin Duke CC: Ian Swett , IETF QUIC WG , Eric Rescorla Subject: RE: Asymmetric CIDs Thread-Topic: Asymmetric CIDs Thread-Index: AQHTp0fnTbZXlaWDCkCz6gDW7l/HjKOnR9oAgAAHeYCAAAY3gIAAAxEAgAA+nwCAAAGy8A== Date: Fri, 16 Feb 2018 22:17:10 +0000 Message-ID: References: <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> In-Reply-To: <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-02-16T22:17:08.8374342Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:4::4a5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0755; 7:19sBvR2YTsKNlo4+/FJ52snSxHRc90wL4RDlNnl94V8p0zjSuFcg2rgGd8r5z9AtcaMRM9fG1p4vrO3UmQjk0EUuK64hYWHTxlRNq4OoBPRTVrzWCW5LB3ODFXsRUPfOCb5vOLvtYApI1VExWpwtY0i2/UcnMF1eJUsttSKeawK/Rizw5F9N3AzJM0q0Lu0GiRIrgiKp3wHhE7soeiFckROZ62iQqEyrU+wEiVpb6PVTkE7sP9yOsKn9ta5uEip7 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ec3a0f61-efab-4154-1faa-08d5758b0608 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:BN6PR21MB0755; x-ms-traffictypediagnostic: BN6PR21MB0755: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(85827821059158)(67672495146484)(211936372134217)(153496737603132)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001040)(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231125)(944501161)(52105033)(6055026)(61426038)(61427038)(6041288)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:BN6PR21MB0755; BCL:0; PCL:0; RULEID:; SRVR:BN6PR21MB0755; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(346002)(376002)(39860400002)(39380400002)(189003)(199004)(3480700004)(3280700002)(3660700001)(68736007)(93886005)(97736004)(6116002)(5660300001)(229853002)(2900100001)(4326008)(105586002)(25786009)(478600001)(790700001)(10290500003)(86612001)(86362001)(6346003)(76176011)(77096007)(102836004)(14454004)(53546011)(6506007)(2906002)(39060400002)(10090500001)(186003)(6246003)(53936002)(8990500004)(54906003)(110136005)(22452003)(99286004)(221733001)(7696005)(236005)(6436002)(9686003)(54896002)(55016002)(6306002)(316002)(7736002)(2950100002)(8676002)(81156014)(81166006)(8936002)(7116003)(33656002)(106356001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0755; H:BN6PR21MB0178.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-message-info: eKOKzl/FD8fnwWfBaYY0mm6oLm273hXO1PfFASArbBx2OrFEEJTClAxOdStt7Cc2t+87Mo+FpVPonpcmx87+KQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB0178395DC04C19D991436525B3CB0BN6PR21MB0178namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec3a0f61-efab-4154-1faa-08d5758b0608 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 22:17:10.3491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0755 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, 16 Feb 2018 22:17:15 -0000 --_000_BN6PR21MB0178395DC04C19D991436525B3CB0BN6PR21MB0178namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyaGFwcyB0aGUgY2xpZW50IHNob3VsZCBzZW5kIGEgTkVXX0NPTk5FQ1RJT05fSUQgd2l0aCB0 aGUgUEFUSF9DSEFMTEVOR0UgYW5kIHJlcXVpcmUgdGhlIHNlcnZlciB0byB1c2UgdGhhdCB0byBy ZXNwb25kLg0KDQotIE5pY2sNCg0KRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3JnPiBP biBCZWhhbGYgT2YgQ2hyaXN0aWFuIEh1aXRlbWENClNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMTYs IDIwMTggMjoxMCBQTQ0KVG86IFJvYmVydG8gUGVvbiA8ZmVuaXhAZmIuY29tPjsgTWFydGluIER1 a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dldHRAZ29v Z2xlLmNvbT47IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IEVyaWMgUmVzY29ybGEgPGVr ckBydGZtLmNvbT4NClN1YmplY3Q6IFJlOiBBc3ltbWV0cmljIENJRHMNCg0KDQpUbyBiZSBleHBs aWNpdCwgSSBhbSBjb25jZXJuZWQgYnkgdGhlIGZvbGxvd2luZyBzY2VuYXJpbzoNCg0KMSkgQ2xp ZW50IHNlbmRzIGEgUEFUSCBDSEFMTEVOR0UgdG8gc2VydmVyIGZyb20gYSBuZXcgY2xpZW50IGFk ZHJlc3Mgd2l0aCBuZXZlci1zZWVuLWJlZm9yZSBjb25uZWN0aW9uIElELCBvYnRhaW5lZCBwcmV2 aW91c2x5IGluIE5FVyBDT05ORUNUSU9OIElEIGZyYW1lIGZyb20gc2VydmVyDQoNCjIpIFNlcnZl ciByZXNwb25kIGJ5IHNlbmRpbmcgcmVwbHkgdG8gbmV3IGFkZHJlc3Mgd2l0aCBwcmV2aW91c2x5 LW5lZ290aWF0ZWQtYW5kLXVzZWQgQ0lEIG9mIGNsaWVudC4NCg0KMykgSW5zdGFudCBsaW5rYWdl Lg0KDQpUaGUga2V5IGlzIG9mIGNvdXJzZSB0aGF0IHRoZSBzZXJ2ZXIgcGlja3MgYSBkaWZmZXJl bnQgQ0lEIHRvIHJlc3BvbmQgdG8gdGhlIG1pZ3JhdGlvbiwgbm9ybWFsbHkgaW4gYSBORVcgQ09O TkVDVElPTiBJRCBmcmFtZS4NCg0KT24gMi8xNi8yMDE4IDEwOjI1IEFNLCBSb2JlcnRvIFBlb24g d3JvdGU6DQorKyB3aGF0IENocmlzdGlhbiBzYXlzLg0KVGhlIGZhY3QgdGhhdCBpdCBub3cgdGFr ZXMgdHdvIGltcGxlbWVudGF0aW9ucyB0byBwcmV2ZW50IGxpbmthYmlsaXR5IChlaXRoZXIgc2lk ZSBtZXNzZXMgaXQgdXAsIGFuZCB0aGF0IGhhbGYtcGF0aCBpcyBleHBvc2VkLCBsaWtlbHkgcmVu ZGVyaW5nIGl0IGFsbCBleHBvc2VkKSBpcyBhIGJpdCBzYWQuDQotPVINCg0KDQpGcm9tOiBRVUlD IDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+IG9u IGJlaGFsZiBvZiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVtYUBodWl0ZW1hLm5ldD48bWFpbHRv Omh1aXRlbWFAaHVpdGVtYS5uZXQ+DQpEYXRlOiBGcmlkYXksIEZlYnJ1YXJ5IDE2LCAyMDE4IGF0 IDEwOjE2IEFNDQpUbzogTWFydGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPjxtYWls dG86bWFydGluLmguZHVrZUBnbWFpbC5jb20+DQpDYzogSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29n bGUuY29tPjxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4sIElFVEYgUVVJQyBXRyA8cXVpY0Bp ZXRmLm9yZz48bWFpbHRvOnF1aWNAaWV0Zi5vcmc+LCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5j b20+PG1haWx0bzpla3JAcnRmbS5jb20+DQpTdWJqZWN0OiBSZTogQXN5bW1ldHJpYyBDSURzDQoN CkkgbGlrZSB0aGUgY29uY2VwdCwgYnV0IEkgd291bGQgbGlrZSB0byB1bmRlcnN0YW5kIGhvdyB3 ZSBhdm9pZCBsaW5rYWJpbGl0eSBvbiBtaWdyYXRpb24uDQotLSBDaHJpc3RpYW4gSHVpdGVtYQ0K DQo= --_000_BN6PR21MB0178395DC04C19D991436525B3CB0BN6PR21MB0178namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOmJs YWNrO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4 dCI+UGVyaGFwcyB0aGUgY2xpZW50IHNob3VsZCBzZW5kIGEgTkVXX0NPTk5FQ1RJT05fSUQgd2l0 aCB0aGUgUEFUSF9DSEFMTEVOR0UgYW5kIHJlcXVpcmUgdGhlIHNlcnZlciB0byB1c2UgdGhhdCB0 byByZXNwb25kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+LSBO aWNrPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOndpbmRvd3RleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJj b2xvcjp3aW5kb3d0ZXh0Ij4gUVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+ T24gQmVoYWxmIE9mIDwvYj5DaHJpc3RpYW4gSHVpdGVtYTxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEZlYnJ1YXJ5IDE2LCAyMDE4IDI6MTAgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvYmVydG8gUGVv biAmbHQ7ZmVuaXhAZmIuY29tJmd0OzsgTWFydGluIER1a2UgJmx0O21hcnRpbi5oLmR1a2VAZ21h aWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gSWFuIFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29nbGUu Y29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0OzsgRXJpYyBSZXNjb3Js YSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQXN5bW1ldHJp YyBDSURzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHA+VG8gYmUgZXhwbGljaXQsIEkgYW0g Y29uY2VybmVkIGJ5IHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86PG86cD48L286cD48L3A+DQo8cD4x KSBDbGllbnQgc2VuZHMgYSBQQVRIIENIQUxMRU5HRSB0byBzZXJ2ZXIgZnJvbSBhIG5ldyBjbGll bnQgYWRkcmVzcyB3aXRoIG5ldmVyLXNlZW4tYmVmb3JlIGNvbm5lY3Rpb24gSUQsIG9idGFpbmVk IHByZXZpb3VzbHkgaW4gTkVXIENPTk5FQ1RJT04gSUQgZnJhbWUgZnJvbSBzZXJ2ZXI8bzpwPjwv bzpwPjwvcD4NCjxwPjIpIFNlcnZlciByZXNwb25kIGJ5IHNlbmRpbmcgcmVwbHkgdG8gbmV3IGFk ZHJlc3Mgd2l0aCBwcmV2aW91c2x5LW5lZ290aWF0ZWQtYW5kLXVzZWQgQ0lEIG9mIGNsaWVudC48 bzpwPjwvbzpwPjwvcD4NCjxwPjMpIEluc3RhbnQgbGlua2FnZS48bzpwPjwvbzpwPjwvcD4NCjxw PlRoZSBrZXkgaXMgb2YgY291cnNlIHRoYXQgdGhlIHNlcnZlciBwaWNrcyBhIGRpZmZlcmVudCBD SUQgdG8gcmVzcG9uZCB0byB0aGUgbWlncmF0aW9uLCBub3JtYWxseSBpbiBhIE5FVyBDT05ORUNU SU9OIElEIGZyYW1lLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyLzE2LzIw MTggMTA6MjUgQU0sIFJvYmVydG8gUGVvbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiYjNDM7JiM0Mzsgd2hhdCBDaHJpc3RpYW4gc2F5cy48 YnI+DQpUaGUgZmFjdCB0aGF0IGl0IG5vdyB0YWtlcyB0d28gaW1wbGVtZW50YXRpb25zIHRvIHBy ZXZlbnQgbGlua2FiaWxpdHkgKGVpdGhlciBzaWRlIG1lc3NlcyBpdCB1cCwgYW5kIHRoYXQgaGFs Zi1wYXRoIGlzIGV4cG9zZWQsIGxpa2VseSByZW5kZXJpbmcgaXQgYWxsIGV4cG9zZWQpIGlzIGEg Yml0IHNhZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LT1SPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5RVUlDIDxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPg0KJmx0 O3F1aWMtYm91bmNlc0BpZXRmLm9yZyZndDs8L2E+IG9uIGJlaGFsZiBvZiBDaHJpc3RpYW4gSHVp dGVtYSA8YSBocmVmPSJtYWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+DQombHQ7aHVpdGVtYUBo dWl0ZW1hLm5ldCZndDs8L2E+PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgRmVicnVhcnkgMTYs IDIwMTggYXQgMTA6MTYgQU08YnI+DQo8Yj5UbzogPC9iPk1hcnRpbiBEdWtlIDxhIGhyZWY9Im1h aWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSI+Jmx0O21hcnRpbi5oLmR1a2VAZ21haWwuY29t Jmd0OzwvYT48YnI+DQo8Yj5DYzogPC9iPklhbiBTd2V0dCA8YSBocmVmPSJtYWlsdG86aWFuc3dl dHRAZ29vZ2xlLmNvbSI+Jmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7PC9hPiwgSUVURiBRVUlD IFdHDQo8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+Jmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7 PC9hPiwgRXJpYyBSZXNjb3JsYSA8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj4NCiZsdDtl a3JAcnRmbS5jb20mZ3Q7PC9hPjxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogQXN5bW1ldHJpYyBD SURzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5J IGxpa2UgdGhlIGNvbmNlcHQsIGJ1dCBJIHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBob3cgd2Ug YXZvaWQgbGlua2FiaWxpdHkgb24gbWlncmF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0i QXBwbGVNYWlsU2lnbmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LS0gQ2hyaXN0aWFu IEh1aXRlbWEmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_BN6PR21MB0178395DC04C19D991436525B3CB0BN6PR21MB0178namp_-- From nobody Fri Feb 16 14:45:28 2018 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 43B2912008A for ; Fri, 16 Feb 2018 14:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 xIJq8bevMkba for ; Fri, 16 Feb 2018 14:45:24 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 9895C1243FE for ; Fri, 16 Feb 2018 14:45:24 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id 72so5698331iom.10 for ; Fri, 16 Feb 2018 14:45:24 -0800 (PST) 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=r79g4ggi+k92QhRYIdyfGN43PvRXSKASCNaHB2UBV5Y=; b=F3kmLu4vydS/2eiyF2oS8pAbscEQ6+Jf4pnygeAQTRYtKdacdhgpBHx2VazX1oQMG/ cNtBFeIl+UndcZZcC9jD+7qVvv7pEoe9Fg4m/5KRFMT93//uuHZGLbq5I1esRB97sZ0X MgwwOEPmA9ZGuDcxfpEl7VGsDYHb2tl5l1FcJp+XaIcLFW6so3fZ7ightFQlTpV52uU4 xQsbSeVb/pxOjvKeTZai0lNaOEZWYe/4GSkkAEW4X/+qWYxbn76UUJSj2bpOVhKkJHpc X86vCKDIC+QScWmAXvK9qQf+7eFEITJpIZpy9avpe69J3YgaJabTku2CFCoizrz+n2Gj t5eg== 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=r79g4ggi+k92QhRYIdyfGN43PvRXSKASCNaHB2UBV5Y=; b=aWHDr7aFusKC+w/M16A2eOMQws0XEqGhUnO8dF25IQTu081k4LjAzig5V7pLnbnj7/ ls8wXFCm4dB68JqeNB5dsDPUOL3VhdK/Hb20B6OjcM/f0aFqqy45rQC45yY2w/5ObRWa awl9eTaRegBrvE1vVTVcD3IZOML/+vSgzgcRaFzel/ozN4yqGOMl7cQJxh4s85qlggGa zvDmBrZuS3orrhEMDlUIH8k2omd5ILUr7j4TbnmrBioGOaHcZl4apQec+fcef7ukc4kA sBH8A1VK5h875aTRSVTwQj+RlSs6aSNaQeEyZXIck4uCqt6HaQ3K7Fuo8ZO9RtQgjddO ksbw== X-Gm-Message-State: APf1xPAdtCGsBfP7UHCi7NYNh74h9nV78yqPB61p0ubOTgLydIPqI9HA Y4JQUqy6t+8CpkfZNnzXR1RmzQwW8DNhmbSt33k3ng== X-Google-Smtp-Source: AH8x224he77bOox9fuCHi81rH3vXVM337eb6TN6gHHL+/R2phcxEw8WAniFl2Josm0UORMRZAU9xfJhtQxOgLUs5Jzs= X-Received: by 10.107.131.82 with SMTP id f79mr10315786iod.102.1518821123582; Fri, 16 Feb 2018 14:45:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.4 with HTTP; Fri, 16 Feb 2018 14:45:02 -0800 (PST) In-Reply-To: References: <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> From: Ian Swett Date: Fri, 16 Feb 2018 17:45:02 -0500 Message-ID: Subject: Re: Asymmetric CIDs To: Nick Banks Cc: huitema , Roberto Peon , Martin Duke , IETF QUIC WG , Eric Rescorla Content-Type: multipart/alternative; boundary="001a113fb9268cf19905655c19f1" 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, 16 Feb 2018 22:45:26 -0000 --001a113fb9268cf19905655c19f1 Content-Type: text/plain; charset="UTF-8" I agree that could be a concern, but I think it's no more difficult to solve than the status quo. It just means both sides need to have more connection IDs, not just one side. Nick's solution is a good suggestion, but one can also imagine cases when other connection IDs have previously been made available. In practice, for most of the cases we're discussing, I'm expecting the connection ID from server to client will be 0 bytes in length, making this a non-issue. --001a113fb9268cf19905655c19f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree that could be a concern, but I think it's= no more difficult to solve than the status quo.=C2=A0 It just means both s= ides need to have more connection IDs, not just one side.

Nick's solution is a good suggestion, but one can also imagine cases= when other connection IDs have previously been made available.

In practice, for most of the cases we're discussing, I'm ex= pecting the connection ID from server to client will be 0 bytes in length, = making this a non-issue.
--001a113fb9268cf19905655c19f1-- From nobody Fri Feb 16 14:56:32 2018 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 29C1A126D85 for ; Fri, 16 Feb 2018 14:56:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (1024-bit key) header.d=fb.com header.b=edMtlqLZ; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=XQOELeWr 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 2cCjdB3nCFI1 for ; Fri, 16 Feb 2018 14:56:28 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 61FB5124207 for ; Fri, 16 Feb 2018 14:56:28 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1GMo3k4016627; Fri, 16 Feb 2018 14:56:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=M5lrOwdObjaYRoxSKgASi5q7wlCrdvlNSyqyDBH+ROI=; b=edMtlqLZpRi1MZzpYPfYn02bajccuEwJUX8JhvOtZRiiiU7lFoDzcacUcikB4LnHnzzc xjpY18KUjixUXMoe4CA8hvpvQJxTE2WcvKWU1H5Lz6tjyVbJn+Pwq3QH82vJ5QySTPqn Mv8CWen+9gydU5d8UN12+SX9mT+qQvOhTfg= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2g66ht8ph5-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Feb 2018 14:56:20 -0800 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.17) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 16 Feb 2018 14:56:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=M5lrOwdObjaYRoxSKgASi5q7wlCrdvlNSyqyDBH+ROI=; b=XQOELeWrALhnmCp3qLHfRfzxdW+TUp55Q1bMcLczJCgZ8QJ4umQurU5aT3bzlE6qH/vyS3pG1/kRC2MS788c3vLrDWOjDteyVyom5y/SdnjEZkbkUDsXrUSlZ/yK7Fp+kO7lUHwUIdDMncwHYzQfukKU1P51h0ZbY5xQxPpAIzA= Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.164.171.11) by BY2PR15MB0214.namprd15.prod.outlook.com (10.163.64.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Fri, 16 Feb 2018 22:56:13 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.20.0506.020; Fri, 16 Feb 2018 22:56:13 +0000 From: Roberto Peon To: Ian Swett , Nick Banks CC: huitema , Martin Duke , IETF QUIC WG , Eric Rescorla Subject: Re: Asymmetric CIDs Thread-Topic: Asymmetric CIDs Thread-Index: AQHTp0fsUiwRXYubE0qEd47QbEYhNqOnR9oAgAAHeYCAAAY3gP//fPSAgADEvACAAAH8AIAAB8kAgAADISc= Date: Fri, 16 Feb 2018 22:56:13 +0000 Message-ID: References: <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:35ac] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR15MB0214; 7:/MXpwz2xSN7wLNdYtiuGA5K5ycbj0ynrAU0HrwP0DOy5aIXfln6DEGZWRLYvGQlADMlps67KcQ81VOYagvguuSqtAAHOdqr+5zYT/wSlbDubWA7kXs3abqkHDhGDmavBh9IDHtAng4ftLeJAaSGKW/ZkwsOci1ndrCIocSahKDOqq60EV0pTwt8BsAb3neqe1UHXzbGXePHBx8L3YHKVG+w1A1ld24LBS1du+InL1Yuyk4fLQXjK4/CD/lUmIel/; 20:WtL2KPEg25+WPvaytaufA4Ty4fCW7nxUuPiW4QRCOUQdxh3972U9YDypFAebGorjZzXV8rCx3PBwNa6KsSnaP1TC/otv5wxtxwUXqIk+7G+XhS5tCUXQ39dydyQ1LFQbBEGZRvBGSxLv6eREfB+Ie9+yoYjRTigf++gxRZ7pkKc= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 881c3b78-5a09-49ca-2461-08d575907acc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:BY2PR15MB0214; x-ms-traffictypediagnostic: BY2PR15MB0214: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(85827821059158)(67672495146484)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3231101)(11241501184)(944501161)(3002001)(6041288)(20161123562045)(20161123560045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BY2PR15MB0214; BCL:0; PCL:0; RULEID:; SRVR:BY2PR15MB0214; x-forefront-prvs: 0585417D7B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39860400002)(346002)(376002)(39380400002)(189003)(199004)(7736002)(5660300001)(6436002)(7116003)(86362001)(105586002)(45080400002)(8676002)(478600001)(54906003)(93886005)(8666007)(81156014)(97736004)(53546011)(102836004)(14454004)(186003)(81166006)(110136005)(106356001)(77096007)(74316002)(3480700004)(8936002)(229853002)(3660700001)(6116002)(25786009)(6246003)(4326008)(33656002)(221733001)(1511001)(6506007)(53936002)(55016002)(316002)(68736007)(9686003)(2950100002)(3280700002)(76176011)(39060400002)(54896002)(99286004)(7696005)(2900100001)(2906002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR15MB0214; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: mH+/m0UtESHhRgxSrI/pa9hygHy6HsL0lNoPVdlIqF+B0K4Toh8929rHR6OfNCLoPNpsG9UwU7A5eO8DBDSPwg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR15MB077577E4358F9922047685A8CDCB0BY2PR15MB0775namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 881c3b78-5a09-49ca-2461-08d575907acc X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2018 22:56:13.7013 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR15MB0214 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-16_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 16 Feb 2018 22:56:30 -0000 --_000_BY2PR15MB077577E4358F9922047685A8CDCB0BY2PR15MB0775namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That would make multipath hard/interesting. I expect non-zero length (-> client) CIDs when multipath is not theoretical= . -=3DR Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- From: Ian Swett Date: 2/16/18 2:45 PM (GMT-08:00) To: Nick Banks Cc: huitema , Roberto Peon , Martin Duke= , IETF QUIC WG , Eric Rescorla Subject: Re: Asymmetric CIDs I agree that could be a concern, but I think it's no more difficult to solv= e than the status quo. It just means both sides need to have more connecti= on IDs, not just one side. Nick's solution is a good suggestion, but one can also imagine cases when o= ther connection IDs have previously been made available. In practice, for most of the cases we're discussing, I'm expecting the conn= ection ID from server to client will be 0 bytes in length, making this a no= n-issue. --_000_BY2PR15MB077577E4358F9922047685A8CDCB0BY2PR15MB0775namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
That would make multipath hard/interesting.

I expect non-zero length (-> client) CIDs when multipath is not the= oretical.
-=3DR

Sent via the Samsu= ng Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: Ian Swett <ianswett@google.com>
Date: 2/16/18 2:45 PM (GMT-08:00)
To: Nick Banks <nibanks@microsoft.com>
Cc: huitema <huitema@huitema.net>, Roberto Peon <fenix@fb.com= >, Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ie= tf.org>, Eric Rescorla <ekr@rtfm.com>
Subject: Re: Asymmetric CIDs

I agree that could be a concern, but I think it's no more difficult to= solve than the status quo.  It just means both sides need to have mor= e connection IDs, not just one side.

Nick's solution is a good suggestion, but one can also imagine cases when o= ther connection IDs have previously been made available.

In practice, for most of the cases we're discussing, I'm expecting the= connection ID from server to client will be 0 bytes in length, making this= a non-issue.
--_000_BY2PR15MB077577E4358F9922047685A8CDCB0BY2PR15MB0775namp_-- From nobody Fri Feb 16 16:22:51 2018 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 63836124234 for ; Fri, 16 Feb 2018 16:22:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 oEL8NXycfosJ for ; Fri, 16 Feb 2018 16:22:48 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 E08F91200C1 for ; Fri, 16 Feb 2018 16:22:47 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id z6so5875584iob.11 for ; Fri, 16 Feb 2018 16:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=H5SJnDGxpJt98O1ztRdqJAX209uF8gQ4vdJM7tckrZA=; b=Ki2/T6fETpvRFlB20PonsfJ037vNrTVsvOXhiTrTNU/AFsOZ98/vTmz6+8mXEkcZNw 6/cKwMGCqpAQHg48ZEz3T00oAbnhfYHxBkh8234BLcA8uKpa0gFfpwITE5K13PB4cJTn i6Y4A7DJu1vDK2Ok4RQjFi6ht1T/4pjheaJ/6DDUR1uGhV6HaD7IwbOQV/P4TCekqIOO LT/L68+pi6ddHvZ1wZFn725VmdVSI+uLjtQiQDeZkYunofgmeHGxxx08FTuYmm9ruV8v mq8fpZulnj+gGYj+52SWkPWsSjVf9b+UyqsgG9sfJXCWSKN5W87rqVBiDTHxNUZe8EON rEcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=H5SJnDGxpJt98O1ztRdqJAX209uF8gQ4vdJM7tckrZA=; b=MD5LHG40oUilYJEVl2Ox0N/3EVC+v4Ba6Sr7hkeDraxSiOf8Bj1EG9pNCJXjhb4b9z c8q9ygVj/7k3b1vGn9loOv1i39HvRhCMlgGA+1oKimIOQwFd70fo6RV01KDgDnVSl2M/ tzyuv9ROD9o5br4geQWd71QTQVOYEi8eLfHMW4+rqM1QsjxbXovuVRrCzjJOTlhY81vl zVy+0SuftVBhcvGznZtOh+YwTnXDFAbvIxAOzoQ+DtrXQfJ4P4Si5PQ9dHjcZbEW4tFS TfDXJ7O5UpPWhnxf5xobHWKmfDg22gRo8F2XoEh2W8YCI55qcfuUVEFCHpSmBgXlof/O tvwg== X-Gm-Message-State: APf1xPCkdvRobTTsKurq3HZ+fYY/6FP3sT0P4uiALb4XC+v1v7IaMYLN PeJbTcVX+wXjb+NnkOzwQP8lQACrCOqb/BUqDHw= X-Google-Smtp-Source: AH8x2256FzF4jyfeiMxIDDLuAPFy6x8t4bid8NBhqhlUQ7mXFNYJLNQ1TIiw3eVeIb581ysXU9OQBW2Q40IURo8usO0= X-Received: by 10.107.146.215 with SMTP id u206mr9662246iod.96.1518826967291; Fri, 16 Feb 2018 16:22:47 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 16 Feb 2018 16:22:46 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 16 Feb 2018 16:22:46 -0800 Message-ID: Subject: Re: Asymmetric CIDs To: Nick Banks , Roberto Peon , Ian Swett Cc: Eric Rescorla , IETF QUIC WG , Martin Duke , huitema Content-Type: multipart/alternative; boundary="001a114f7e84dc6e6e05655d7555" 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, 17 Feb 2018 00:22:50 -0000 --001a114f7e84dc6e6e05655d7555 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This looks good to me. Path migration might involve CID validation so a connection shuts down if a single endpoint messes up linkage. The stateless reset has been discussed - problem with routing to peer (I don=E2=80=99t recall if reset can go both ways, but I think is is currently= only server to client ATM) with ACID it would be more relevant to also discuss opposite reset because the use case would/could be p2p servers. I think perhaps getting rid of reset would be good. As an alternative a PATH_CHALLENGE or a PING could be used if one endpoint thinks the other end is a tad silent. The sub protocol for updating router CID could also be extended to filter out noisy clients by cancelling a CID that is not in use= . The stateless retry concern has not been discussed in this thread, I suppose. It is mentioned in the ACID issue: https://github.com/quicwg/base-drafts/issues/1089 Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 16 February 2018 at 23.56.35, Roberto Peon (fenix@fb.com) wrote: That would make multipath hard/interesting. I expect non-zero length (-> client) CIDs when multipath is not theoretical= . -=3DR Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- From: Ian Swett Date: 2/16/18 2:45 PM (GMT-08:00) To: Nick Banks Cc: huitema , Roberto Peon , Martin Duke , IETF QUIC WG , Eric Rescorla < ekr@rtfm.com> Subject: Re: Asymmetric CIDs I agree that could be a concern, but I think it's no more difficult to solve than the status quo. It just means both sides need to have more connection IDs, not just one side. Nick's solution is a good suggestion, but one can also imagine cases when other connection IDs have previously been made available. In practice, for most of the cases we're discussing, I'm expecting the connection ID from server to client will be 0 bytes in length, making this a non-issue. --001a114f7e84dc6e6e05655d7555 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = This looks good to m= e.

=
Path migration mig= ht involve CID validation so a connection shuts down if a single endpoint m= esses up linkage.

The= stateless reset has been discussed - problem with routing to peer (I don= =E2=80=99t recall if reset can go both ways, but I think is is currently on= ly server to client ATM) with ACID it would be more relevant to also discus= s opposite reset because the use case would/could be p2p servers.

I think perhaps getting rid of= reset would be good. As an alternative a PATH_CHALLENGE or a PING could be= used if one endpoint thinks the other end is a tad silent. The sub protoco= l for updating router CID could also be extended to filter out noisy client= s by cancelling a CID that is not in use.

The stateless retry concern has not been discussed i= n this thread, I suppose. It is mentioned in the ACID issue:=C2=A0

<= br>

Kind Regards,=
Mikkel Fahn= =C3=B8e J=C3=B8rgensen


On 1= 6 February 2018 at 23.56.35, Roberto Peon (= fenix@fb.com) wrote:

<= span>
That would make multipath hard/interesting.

I expect non-zero length (-> client) CIDs when multipath is not theoretical.
-=3DR

Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: Ian Swett <ianswett@go= ogle.com>
Date: 2/16/18 2:45 PM (GMT-08:00)
To: Nick Banks <nibanks@mi= crosoft.com>
Cc: huitema <huitema@huitema= .net>, Roberto Peon <fenix@fb.com>, Martin Duke <<= a href=3D"mailto:martin.h.duke@gmail.com">martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>, Er= ic Rescorla <ekr@rtfm.com>
Subject: Re: Asymmetric CIDs

I agree that could be a concern, but I think it's no more difficult to solve than the status quo.=C2=A0 It just means both sides need to have more connection IDs, not just one side.

Nick's solution is a good suggestion, but one can also imagine cases when other connection IDs have previously been made available.

In practice, for most of the cases we're discussing, I'm expecting the connection ID from server to client will be 0 bytes in length, making this a non-issue.
--001a114f7e84dc6e6e05655d7555-- From nobody Sat Feb 17 00:12:14 2018 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 05F5D12025C for ; Sat, 17 Feb 2018 00:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eooPqyRIk02h for ; Sat, 17 Feb 2018 00:12:11 -0800 (PST) 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 F27601200E5 for ; Sat, 17 Feb 2018 00:12:10 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx26.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1emxbM-0008Vt-I5 for quic@ietf.org; Sat, 17 Feb 2018 09:12:09 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1emxbJ-0003Zo-Jq for quic@ietf.org; Sat, 17 Feb 2018 03:12:06 -0500 Received: (qmail 14536 invoked from network); 17 Feb 2018 08:12:04 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.15]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Feb 2018 08:12:04 -0000 To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , Nick Banks , Roberto Peon , Ian Swett Cc: Eric Rescorla , IETF QUIC WG , Martin Duke References: <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> From: Christian Huitema Message-ID: <9dfed68d-851d-d1aa-8559-92a42b7c923e@huitema.net> Date: Sat, 17 Feb 2018 00:12:02 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C068D5E77F8C156120A97080" Content-Language: en-US Subject: Re: Asymmetric CIDs X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.57) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5os7TBGZoTAL3fQZfkAOmVl602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi23aYmfXg7s6pVf9WD7ZaWM7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBy0LkIcQZ+RRGzUcmNZyDXh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYg8fO0sqTNbFIxwq5nK+B tNm4YXH+1fMTrNbJKTtzvwPl5YmPKOW53PX48RxyAL8AeEryWDFh6OMgZL2eLBxw4AfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4Cp b4mi9wLRe0dO1qfOpsb8SGG/BQd7r2NVEaNhWos5ptTilnCILaTRj+RmJnkgHAAccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtqMfDzEXpr5sTuNVuzYBPE2Bi6owqeb+h1kbxIVWYdC7uVGB tJ1DsK23UcLYdhI56Feqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g== 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: Sat, 17 Feb 2018 08:12:13 -0000 This is a multi-part message in MIME format. --------------C068D5E77F8C156120A97080 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/16/2018 4:22 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > This looks good to me. > > Path migration might involve CID validation so a connection shuts down > if a single endpoint messes up linkage. "Implement migration correctly, or the connection will break on migration." That may work if the QUIC stack wants to actually make migration work. And I suppose that a stack that does not care about migration would simply not provide "NEW CONNECTION ID" in the first place. If one peer sends data with a CID, the responder needs to also select a new asymmetric CID in the replies, and must not send a reply if no such new asymmetric CID is available -- with suitable exception for 0-length CID. This requires that a new asymmetric CID is available, and as Nick suggested this can be made foolproof by sending a NEW CID frame in the migration packets. My point is mostly that iwhen we write the asymmetric CID PR, we must actually specify the migration behavior. -- Christian Huitema --------------C068D5E77F8C156120A97080 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2/16/2018 4:22 PM, Mikkel Fahnøe Jørgensen wrote:

This looks good to me.

Path migration might involve CID validation so a connection shuts down if a single endpoint messes up linkage.

"Implement migration correctly, or the connection will break on migration." That may work if the QUIC stack wants to actually make migration work. And I suppose that a stack that does not care about migration would simply not provide "NEW CONNECTION ID" in the first place. If one peer sends data with a CID, the responder needs to also select a new asymmetric CID in the replies, and must not send a reply if no such new asymmetric CID is available -- with suitable exception for 0-length CID. This requires that a new asymmetric CID is available, and as Nick suggested this can be made foolproof by sending a NEW CID frame in the migration packets.

My point is mostly that iwhen we write the asymmetric CID PR, we must actually specify the migration behavior.

-- Christian Huitema
--------------C068D5E77F8C156120A97080-- From nobody Sat Feb 17 16:45:22 2018 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 28184124B0A for ; Sat, 17 Feb 2018 16:45:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=mnot.net header.b=RXhMzp8G; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fadTGvon 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 7jlcJ1ct2L4V for ; Sat, 17 Feb 2018 16:45:18 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3566B124234 for ; Sat, 17 Feb 2018 16:45:18 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9D80520BC8 for ; Sat, 17 Feb 2018 19:45:17 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute4.internal (MEProxy); Sat, 17 Feb 2018 19:45:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=waKVOaqPdBKPZwlln oY0Vgn5Dlcd97gNwP57VjRAXL0=; b=RXhMzp8GOYPw6bgUP0kMDvgiZsje8xNRT +TUdRHUnQXA+9lG4jXOHcGhT6814i2qntlQ+keluqfCfp8r53pN2kgttmj4+SHG4 1Ascl6BpiwC4RalbDxdDJJukS5Akbh3706LUho4ru8ZVpjlNEpIoAnJm+TDVEC2h ldfnjuKhf0wbxZ8POqDWnf6SP8lZQsBOSuWHzXqYpe/pycadntYkKNh1lyusTnvq zEio8gWbjRLwA6+7L5XmkaxFmMvYGLs0BHMr4t16eAp/okeVwoADjsweDlSioziK L/PH0G+QQtMDOJdxenJV5XkiBYK76Cl/fgZpuu4Po7UTF9ExFSPVA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=waKVOaqPdBKPZwllnoY0Vgn5Dlcd97gNwP57VjRAXL0=; b=fadTGvon 4N6X35Z3UImGZp2Dp59C6io1ooZXtmAFhTIav1jKPeTAJmbWEj1Rwrc/PK2cpN9S smLuJrzKJ7jE9fbdI3uqp4dy3Nh330iyMhk/bVI4SGftzJW2Afv24mwxmbz23tYc JqBWRf5dqmTgywk98rdGO6p4e2qRkgn056NDaDBfeU1c0cqbifBYnvowU0fwU5Y9 ZwYUe9pNqzB8+pZzNcC0eEV7+CHMdRqsC0WaKMeKyyd9nKZ0d9cmqScDtokvLM8N e5ZvL5+093Gx+X64XwL1fYBB9VqZyElkDxmPYInvvARjPBwMmLEJ96g4kCbl4+ME Kgbpv/eKujWIpQ== X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id E4CFB24547 for ; Sat, 17 Feb 2018 19:45:16 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 4AB6AC03EE for ; Sun, 18 Feb 2018 00:45:14 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============3030128415837924970==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180218004514.4AB6AC03EE@cloud.mnot.net> Date: Sun, 18 Feb 2018 00:45:14 +0000 (UTC) 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, 18 Feb 2018 00:45:21 -0000 --===============3030128415837924970== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+2/-2/=F0=9F=92=AC2) 2 issues created: - text on retry and connection id (by mcmanus) https://github.com/quicwg/base-drafts/issues/1118 = - Server responses to multiple Initial packets (by martinthomson) https://github.com/quicwg/base-drafts/issues/1115 [-transport] [design] = 1 issues received 2 new comments: - #1115 Server responses to multiple Initial packets (2 by huitema, mikke= lfj) https://github.com/quicwg/base-drafts/issues/1115 [-transport] [design] = 2 issues closed: - Cancellation of requests with (partial) responses https://github.com/qu= icwg/base-drafts/issues/756 [-http] [design] [has-proposal] = - When to send Version Negotiation https://github.com/quicwg/base-drafts/= issues/1038 [-transport] [design] = Pull requests ------------- * quicwg/base-drafts (+10/-7/=F0=9F=92=AC10) 10 pull requests submitted: - Added reference to stateless reset (by martinduke) https://github.com/quicwg/base-drafts/pull/1116 = - Simplify QCRAM abstract (by LPardue) https://github.com/quicwg/base-drafts/pull/1114 = - Add QCRAM links to README (by LPardue) https://github.com/quicwg/base-drafts/pull/1113 = - qcram: section reference format (by reschke) https://github.com/quicwg/base-drafts/pull/1112 = - qcram: consistent formatting of range (by reschke) https://github.com/quicwg/base-drafts/pull/1111 = - qcram: make boilerplate consistent (by reschke) https://github.com/quicwg/base-drafts/pull/1110 = - Invariants (by martinthomson) https://github.com/quicwg/base-drafts/pull/1109 = - Adopted QCRAM draft (by afrind) https://github.com/quicwg/base-drafts/pull/1108 = - Frame types that are Protocol Violations (by martinduke) https://github.com/quicwg/base-drafts/pull/1107 = - Define InRecovery() (by ianswett) https://github.com/quicwg/base-drafts/pull/1106 = 5 pull requests received 10 new comments: - #1108 Adopted QCRAM draft (5 by larseggert, martinthomson, janaiyengar,= krasic, MikeBishop) https://github.com/quicwg/base-drafts/pull/1108 = - #1114 Simplify QCRAM abstract (2 by martinthomson, LPardue) https://github.com/quicwg/base-drafts/pull/1114 = - #1039 Rewrite text about Version Negotiation (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1039 = - #1012 A more complete connection migration (1 by janaiyengar) https://github.com/quicwg/base-drafts/pull/1012 = - #1053 Rework packetization section (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1053 [-transport] = 7 pull requests merged: - Extract request cancellation from GOAWAY https://github.com/quicwg/base-drafts/pull/1100 [-http] [merge-imminent= ] = - Rewrite text about Version Negotiation https://github.com/quicwg/base-drafts/pull/1039 = - Add QCRAM links to README https://github.com/quicwg/base-drafts/pull/1113 = - Adopted QCRAM draft https://github.com/quicwg/base-drafts/pull/1108 = - Rework packetization section https://github.com/quicwg/base-drafts/pull/1053 [-transport] [merge-imm= inent] = - Define InRecovery() https://github.com/quicwg/base-drafts/pull/1106 = - Frame types that are Protocol Violations https://github.com/quicwg/base-drafts/pull/1107 = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============3030128415837924970== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday February 18, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+2/-2/=F0=9F=92=AC2)

2 issues created:

1 issues received 2 new comments:

2 issues closed:

Pull requests

quicwg/base-drafts (+10/-7/=F0=9F=92=AC10)

10 pull requests submitted:

5 pull requests received 10 new comments:

7 pull requests merged:

Repositories tracked by this digest:

--===============3030128415837924970==-- From nobody Sun Feb 18 07:48:30 2018 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 0A984126C0F for ; Sun, 18 Feb 2018 07:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 8bNhJqQKrnDm for ; Sun, 18 Feb 2018 07:48:27 -0800 (PST) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 B11C8126B6E for ; Sun, 18 Feb 2018 07:48:27 -0800 (PST) Received: by mail-pf0-x22c.google.com with SMTP id i3so1229493pfe.5 for ; Sun, 18 Feb 2018 07:48:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=q7YdlC3VcC2joKXGwruBrKq5o9qtHfBYJalw8l1dqi8=; b=tAkicdDY+tawJz/d85CrOQ8F12azeessXTrLXoRdl9fK7shrTHMjYt1xrU+0tRUiRC +sVY77XtUZ74d5OFVlQkh3z+IPa0iQThMbOGrx7JwpW2ACfC3K79i22ZZw5qzGcmrKhI 2dP+1RnizojY4xpjEQJeACnWlbusLCq0whQhyZOxJCH2tTme5nfaYgKSvF/BvrW6ZWw8 7VXhPjJIyMQg8Mam38Hih2qx7BWHGLxmCSWSTrPyNaqtq33aJR34j4cTAvNTQSnjnZEc CGjP+/Mx8CO/KAJ1ikfkLaaKNlswwaPmlKww2W7SGj01MoPbqPlMymSPzG+MY7CLUufQ J5Pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=q7YdlC3VcC2joKXGwruBrKq5o9qtHfBYJalw8l1dqi8=; b=ZE+KDIJ8NL+3uuz1wu9KApqSIZmGhBgIW7brfIYsGpHusWsj94IH4A7ihFFWdPSz3t z0gHx6WN3DYxqxR3JxFkKuLP4IRDrVBZ0nIsqcPYvlkqffiHG9vYgkLxV9sXAmEFIbLr a4CCgpmi7z+Yu+5y17mTuHdTDof461Vs8xOfp1kuyl4AZRdWMgcbOxd3NuihxsBVkR6L TUa3EXWOQgQtujGAx0twRxICkfru95Agb8exPRzICytQNc2xq3fpWpUqFKuw2fHazvvk PuBq7907FtPl52Q2ijWpJLAoCp6GzpVFYZNcMkYmGw4Ecn9mmqe+J207dCBx1QSdEpFZ appw== X-Gm-Message-State: APf1xPArtfWfO9wc0NxNqIo7g7gBlvDvz1xsaUW+WMYdG332YZoYxqF7 psaC6TQZixv1aRk6bAT+1sk= X-Google-Smtp-Source: AH8x226ZIxAa63uobg3vFTJWs8YyADIlfdtavSpIiO1rjAwWWU7wVMVclA35j6/s0MzH6tlJzDKPwA== X-Received: by 10.98.160.90 with SMTP id r87mr10552554pfe.151.1518968907133; Sun, 18 Feb 2018 07:48:27 -0800 (PST) Received: from Justins-MacBook-Pro.local (ik1-330-25108.vs.sakura.ne.jp. [153.126.188.112]) by smtp.gmail.com with ESMTPSA id k3sm1165213pgn.27.2018.02.18.07.48.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 07:48:26 -0800 (PST) Subject: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) From: Lingmo Zhu To: Kazuho Oku , alexandre.ferrieux@orange.com, Christian Huitema Cc: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "quic@ietf.org" , Martin Thomson References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> Message-ID: <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> Date: Sun, 18 Feb 2018 23:48:21 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US 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: Sun, 18 Feb 2018 15:48:29 -0000 Hi all After some discussion with Kazuho and thanks to his help, I want to propose that for Version Negotiation handling, "a client MAY wait for a handshake packet after receiving a Version Negotiation packet". The attack utilizing fake Version Negotiation is too cheap and easy to be performed (due to no encryption exists) and would be harmful (even stopping the establishment of connections) so should be mitigated. The attack that means to make the client abort QUIC connection could be easily performed with small footprint but also could be mitigated by simply ignoring those unacceptable Version Negotiation packets in my rough experiment (if could be called so). Some possible approaches might be considered: * A timer could be set after Initial packet sent (might be combined with one used for re-transmit) for waiting ServerHello. If a Version Negotiation is received but totally unacceptable, just ignore it. If the received Version Negotiation is acceptable, it could be considered after the timeout instead of handled immediately. If a fake packet with ServerHello received, it should be rejected by TLS so not considered here. * When a Version Negotiation is received, instead of handling it within the same connection, handle it as another connection and remain the original connection context. If then the ServerHello packet is received, the new connection context could be dropped and the original connection would be used following up. This approach might be more difficult to be implemented than the previous one. The approaches above are both covered by the statement to be proposed but not exhaustive. This should be a handling for client side so server side would have no modification. Due to different implementations of different clients, it could not be ensure that those approaches are simple enough to be applied but those malicious Version Negotiation packets should be properly handled. Also, the scenario where fake Version Negotiation packets are triggered by each outgoing QUIC (Initial) packet should also be considered. For why those Version Negotiation attack would be utilized by malware, I think they could pretend as server side problem then attract less attention. If simply dropping packet or faking ICMP host unreachable are utilized, it would be considered as an issue on route configuration so more likely a client-side problem thus more attention. Lingmo Zhu From nobody Sun Feb 18 08:11:03 2018 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 9CEC812420B for ; Sun, 18 Feb 2018 08:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 waYScCCRgf4y for ; Sun, 18 Feb 2018 08:11:00 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 1199C120047 for ; Sun, 18 Feb 2018 08:11:00 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id t22so8933970iob.3 for ; Sun, 18 Feb 2018 08:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=RQUP86xrX0q2ejrv/grJHPYBGWl77RMaYQBcaZMrT3w=; b=DYPPQmse/Fe4sBiiF1Vvt//PVCkf0lHGSLPd/HU0O4JOcbtHUQzmwmXrYE3cbxu+7R nA/x6h4VtssVQzwJVX1GLZ/q4VfmyNY+w5Uvo+qwZ0/tW25flsxswgWuqYyet9JfmopX LAeknAcU4NXlCEiNpfdptLqZUD2gCc4zUGUdklhyfSo3juXtQD9qAiKuWROf7ciNhmJt DJ+6EVH0dn9vJHdO82DAstT2XJIVIP4U70C2gbHR6eeSYok7IFh4o0dQiPQXuxdrSNw7 yypaejWlqJMPA9rpE0J9LqJsN4QxYxNMdZ/JneyB1jZw8WIFRIcuP/gevosssGl/onYt unEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=RQUP86xrX0q2ejrv/grJHPYBGWl77RMaYQBcaZMrT3w=; b=QZlsOx1ldbX+0SO3kpNPzrod5k+kcfeq+LFYYePS4+JjKgiycWJWmGllnOiTORJMY1 wbx0vmj/eAnZJIn8nwCXz8iZT+DTQxM58I1h/WxSB4FGRauGCnGxpj0uT8T82QxGeyqd /mxTI31S9OTe3XF0eWt/ek4xekhk/NVm3rScv4UG1Byx+51vw+7G1qKlUYVO08l9HxEZ 8HiSMI8KfGflkgefzKLaU1HMZd3olo3cfczKsircqnsFKS9nt7Vk00ErG0+60EIlTn6P 2Pry6U0eipRr5kCXRCHUnzqUqLZSdCvjN1ZyHjncnFyoQ96rm27AKkpdlCc0V8L2y3qx C/4g== X-Gm-Message-State: APf1xPAO5eP6ecQ2uBdX/+nPSXURYnUTxuwCpYcQO1g1ZCxRUSxeCoPP nuCnJeAjt/w62949G019MAcEqKuVf1yL9bJ0jn2JeQ== X-Google-Smtp-Source: AH8x227F/SO/1VLkI448EKDx6kRMKVRBlE7hza0HLriUAlPFWUdDv2vYU4XMhnAHTJxluuSPF4e5vUQPDayFnvfe5RQ= X-Received: by 10.107.17.20 with SMTP id z20mr16589782ioi.274.1518970259366; Sun, 18 Feb 2018 08:10:59 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 18 Feb 2018 08:10:58 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 18 Feb 2018 08:10:58 -0800 Message-ID: Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) To: Kazuho Oku , Christian Huitema , alexandre.ferrieux@orange.com, Lingmo Zhu Cc: Martin Thomson , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a113eda8abbed4105657ed2de" 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, 18 Feb 2018 16:11:01 -0000 --001a113eda8abbed4105657ed2de Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was very close to proposing dropping the version negotation packet in favor of having the client offering multiple versions in the initial ClientHello. It would also save a roundtrip if negotiating. However, I realized that it would probably tie the version negotiation to the TLS handshake which is not a very good idea. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 18 February 2018 at 16.48.27, Lingmo Zhu (zlm2006@gmail.com) wrote: Hi all After some discussion with Kazuho and thanks to his help, I want to propose that for Version Negotiation handling, "a client MAY wait for a handshake packet after receiving a Version Negotiation packet". The attack utilizing fake Version Negotiation is too cheap and easy to be performed (due to no encryption exists) and would be harmful (even stopping the establishment of connections) so should be mitigated. The attack that means to make the client abort QUIC connection could be easily performed with small footprint but also could be mitigated by simply ignoring those unacceptable Version Negotiation packets in my rough experiment (if could be called so). Some possible approaches might be considered: * A timer could be set after Initial packet sent (might be combined with one used for re-transmit) for waiting ServerHello. If a Version Negotiation is received but totally unacceptable, just ignore it. If the received Version Negotiation is acceptable, it could be considered after the timeout instead of handled immediately. If a fake packet with ServerHello received, it should be rejected by TLS so not considered here. * When a Version Negotiation is received, instead of handling it within the same connection, handle it as another connection and remain the original connection context. If then the ServerHello packet is received, the new connection context could be dropped and the original connection would be used following up. This approach might be more difficult to be implemented than the previous one. The approaches above are both covered by the statement to be proposed but not exhaustive. This should be a handling for client side so server side would have no modification. Due to different implementations of different clients, it could not be ensure that those approaches are simple enough to be applied but those malicious Version Negotiation packets should be properly handled. Also, the scenario where fake Version Negotiation packets are triggered by each outgoing QUIC (Initial) packet should also be considered. For why those Version Negotiation attack would be utilized by malware, I think they could pretend as server side problem then attract less attention. If simply dropping packet or faking ICMP host unreachable are utilized, it would be considered as an issue on route configuration so more likely a client-side problem thus more attention. Lingmo Zhu --001a113eda8abbed4105657ed2de Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I was very close to = proposing dropping the version negotation packet in favor of having the cli= ent offering multiple versions in the initial ClientHello. It would also sa= ve a roundtrip if negotiating.

However, I realized that it would probably tie the version negoti= ation to the TLS handshake which is not a very good idea.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgense= n


On 18 February 2018 at 16= .48.27, Lingmo Zhu (zlm2006@gmail.com<= /a>) wrote:

Hi all

After some discussion with Kazuho and thanks to his help, I want to
propose that for Version Negotiation handling, "a client MAY wait = for a
handshake packet after receiving a Version Negotiation packet".

The attack utilizing fake Version Negotiation is too cheap and easy to
be performed (due to no encryption exists) and would be harmful (even
stopping the establishment of connections) so should be mitigated. The
attack that means to make the client abort QUIC connection could be
easily performed with small footprint but also could be mitigated by
simply ignoring those unacceptable Version Negotiation packets in my
rough experiment (if could be called so). Some possible approaches migh= t
be considered:

* A timer could be set after Initial packet sent (might be combined wit= h
one used for re-transmit) for waiting ServerHello. If a Version
Negotiation is received but totally unacceptable, just ignore it. If th= e
received Version Negotiation is acceptable, it could be considered afte= r
the timeout instead of handled immediately. If a fake packet with
ServerHello received, it should be rejected by TLS so not considered
here.

* When a Version Negotiation is received, instead of handling it within
the same connection, handle it as another connection and remain the
original connection context. If then the ServerHello packet is received= ,
the new connection context could be dropped and the original connection
would be used following up. This approach might be more difficult to be
implemented than the previous one.

The approaches above are both covered by the statement to be proposed = =20
but not exhaustive. This should be a handling for client side so server
side would have no modification. Due to different implementations of
different clients, it could not be ensure that those approaches are
simple enough to be applied but those malicious Version Negotiation
packets should be properly handled. Also, the scenario where fake
Version Negotiation packets are triggered by each outgoing QUIC
(Initial) packet should also be considered.

For why those Version Negotiation attack would be utilized by malware, = I
think they could pretend as server side problem then attract less
attention. If simply dropping packet or faking ICMP host unreachable ar= e
utilized, it would be considered as an issue on route configuration so
more likely a client-side problem thus more attention.

Lingmo Zhu
--001a113eda8abbed4105657ed2de-- From nobody Sun Feb 18 09:26:29 2018 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 C6D691204DA for ; Sun, 18 Feb 2018 09:26:27 -0800 (PST) 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 o2nQb-Ia2y3H for ; Sun, 18 Feb 2018 09:26:26 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 C7DF21201F2 for ; Sun, 18 Feb 2018 09:26:25 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id g14so9688751qti.2 for ; Sun, 18 Feb 2018 09:26:25 -0800 (PST) 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=Eo/czmVKulZk2VbMS1ZZcaoUapZz8M4FD0bR+Vuxwek=; b=MZ9zBSglkflOsfnx9oEqBQ6Sq2Irz04zBCgT+g1xMqUhZo5Ws5D+uUDibEtjTDUZ3X k6TklaiDZKubGvOpAdZeScI2uJqK0HNM52JP/hA6CCavmdnCtFf1FZ8nxLZZfmHfJWeH hQdwfbXtuP2Qi4378+hHkXMTJsV4Xea4U9T567l6S0jkXwsLuGd9jCJ7ecdJ75Cv2DXr hdJyfBEQ+Orok5mE+mpqU7waI3Vo5QeRi/MV6eSJbusgKgmh1KjISkN1H1IFc3XYL4M9 BOfWZ+WoGRbvqEpqFeoW16GNzXY+zAoUaFJQ8khueYU+v8lj3B9vHXSKdYUpUHUr7nJT wQbw== 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=Eo/czmVKulZk2VbMS1ZZcaoUapZz8M4FD0bR+Vuxwek=; b=KBIuO+l+8PvXc3Iovz99pjvPI1RoaCSA4/3FjAoOslc2bux95GXAD4fDuqDYAsrvcl 2utIz31F3fVj5P5UKpJ5YYMh09uQgivP6jbQYtc90ssXH7ki7Ia8j6Nw9/oFi0+IBtkf N8CLWT415xFK6Un4s0g+Vr/nEx+I8okZiZvACiNXSPKOai7ZWaWiM13i2Brdl1lKnuOM NL+gfIqBY11N4TM3zHu5LqV6IzeZ92GVZNgY3BCcXz/Qhqo5rw6xohI7vd61vFYFYK6K xBCwVcAtvnAn0wd6e/aDS+B/ERuvN4QRFqmIGJbHXB7gGtLHuvIsP/o/jezm6saPK6ir s1OA== X-Gm-Message-State: APf1xPB0Xh5j7dTbfAbGPp8JkYisLfAJvE8lP5cP03ba3q3l1RM0OG62 4gkeCY4vDoxibkMnmZUGnK6j9n6HIXN93BU7/odnFA== X-Google-Smtp-Source: AH8x2260xS/AD2mfFkKRn892ngYYoLPlTVwJP4ZtwyrUNKZpKBeIvDDcZZfW/7PlT3QKJ7C9DLe9BfQMldTXHHdtQak= X-Received: by 10.200.13.9 with SMTP id q9mr20976920qti.133.1518974784782; Sun, 18 Feb 2018 09:26:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Sun, 18 Feb 2018 09:25:44 -0800 (PST) In-Reply-To: <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> From: Eric Rescorla Date: Sun, 18 Feb 2018 09:25:44 -0800 Message-ID: Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) To: Lingmo Zhu Cc: Kazuho Oku , alexandre.ferrieux@orange.com, Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Martin Thomson Content-Type: multipart/alternative; boundary="089e0822b6a4785c2105657fe006" 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, 18 Feb 2018 17:26:28 -0000 --089e0822b6a4785c2105657fe006 Content-Type: text/plain; charset="UTF-8" On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu wrote: > Hi all > > After some discussion with Kazuho and thanks to his help, I want to > propose that for Version Negotiation handling, "a client MAY wait for a > handshake packet after receiving a Version Negotiation packet". > Can you describe the precise attack you are concerned about? The VN packet contains the client's randomly chosen CID, so only an on-path attacker can forge a VN, but such an attacker can also generate a bogus ServerHello or other messages that would cause the QUIC negotiation to fail. -Ekr > > --089e0822b6a4785c2105657fe006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu <zlm2006@gmail.com>= wrote:
Hi all

After some discussion with Kazuho and thanks to his help, I want to
propose that for Version Negotiation handling, "a client MAY wait for = a
handshake packet after receiving a Version Negotiation packet".

Can you describe the precise attack you are c= oncerned about? The VN packet
contains the client's randomly = chosen CID, so only an on-path attacker can
forge a VN, but such = an attacker can also generate a bogus ServerHello or
other messag= es that would cause the QUIC negotiation to fail.

= -Ekr
=C2=A0

=
--089e0822b6a4785c2105657fe006-- From nobody Sun Feb 18 16:30:47 2018 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 AAFC512702E for ; Sun, 18 Feb 2018 16:30:45 -0800 (PST) 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 Ued57NNqzjOh for ; Sun, 18 Feb 2018 16:30:44 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::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 079FC126FDC for ; Sun, 18 Feb 2018 16:30:43 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id t185so947876oif.6 for ; Sun, 18 Feb 2018 16:30:43 -0800 (PST) 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=DS0/K0N9sdib4Ki8AfbYgCmVJKjOEJ4MG9THVBH+12c=; b=OkkS8tV2be61uvaNiOAfo0doNLZM/N4tbEhTV3hwD0H04UjYmROnh3osUZgtQ3o4Bk EeijZVJ/1V3Efw8f8cc0V7f9tvjFEohQt5qXOpCjx5l2IYZciR0dllLnItima70ERd3C Wd8XpXbCCH1a2w/bueF6hiivNysBPGr2fc67k6SjC+1Fd7fJ1sVwOejprrlsMfrJjt6m 9gOqs9guI1wSSKjsW2qPxAQs6WCN9UY+xQipFuxcrWuSMah130A1dRy9s9wpxSyPrbBz iq8KSYAalV7A6MMQMoqODirAwm/E9JbFfdnaKZsRgQnQHkIqkJgmt4r9ZE9Srm0lunc6 GrVA== 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=DS0/K0N9sdib4Ki8AfbYgCmVJKjOEJ4MG9THVBH+12c=; b=Qd6n4Pi/qhltpTc2ZZ4lqhB4WWbkY3tQEqHwWp619V3s2+CTTtbUNtiK18tTdV3mF8 4/ntgX0EfuWpjwjG/n8lBdQNUZ3DugW8VKFpKUzzHma9KxR1J4hrNdEV4tqRUN+EVLC+ zBCYqMUOWrUacKzjwBEOXhD3YkG8luIuxziWCxKESqVBfyCQuIu0r5U09BPUl/j07hh9 jYTN00YxzLdbhC/HwleXix0z4I7OOlWDANorPxK/b6qH1DRkY0HREhinQaFVRV75ceU8 2oxYmhh0RHqOtG6jI2KdzOLdodPiwxxHjvb/Sx3LYfZMZoUOtdSZScp5v+BqlVlVu7/H 0yTQ== X-Gm-Message-State: APf1xPAtH4VmQldWsardRWXdeP0mGdq6pTNPPDpBbp61CleJJvhJyNPX GuzCdVd+u/o5Gag9oaHUy+DqP9XOxmQJgc393II= X-Google-Smtp-Source: AH8x2268XkSeqihJ0wS7pNAu4Z/pNM0fwhPuKFBuV+b3SoX/gbr+Ja3uK1QnM25WPm0lq5HB/vQDdVfFPdyeJRT1qUo= X-Received: by 10.202.94.196 with SMTP id s187mr8728231oib.144.1519000243082; Sun, 18 Feb 2018 16:30:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.52.196 with HTTP; Sun, 18 Feb 2018 16:30:42 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 19 Feb 2018 11:30:42 +1100 Message-ID: Subject: Re: Asymmetric CIDs To: Ian Swett Cc: Eric Rescorla , 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: Mon, 19 Feb 2018 00:30:46 -0000 The breakage of a stateless reset is limited. It is only a problem for clients that use - and depend on - connection IDs. A stateless reset will not carry the client-selected connection ID. It will appear - to the network - to be a change in connection ID. If we change connection IDs occasionally for other reasons, then this won't be a significant problem. The main problem is in ensuring that the packet arrives at the right place at the client. However, it is possible that we can suggest routing based on address tuple over short timescales at clients. In that case, the reset might still arrive at the right place. That, or exceptional processing for unrouteable packets. BTW, I like ekr's idea of making the number space for connection IDs sparse. A (short-ish) fixed limit is necessary to ensure that the stateless reset can be constructed such that it appears plausible and that means at least overhead + max(connection ID) + AEAD expansion + an ACK frame. Would also add the idea of a minimum size for connection IDs. A one octet connection ID has awful linkability properties that are pretty much irredeemable. You can get 8-22 with single octet steps if you are willing to make 1-7 invalid. On Sat, Feb 17, 2018 at 4:25 AM, Ian Swett wrote: > Thanks for the excellent summary EKR. I like this design and think the > breakage of stateless reset in certain cases is acceptable, since it only > applies if both sides must have their preferred connection ID present in > order to route correctly, which is a use case that's impossible in the > status quo. I have not come up with any other downsides. > > On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla wrote: >> >> Hi folks, >> >> After a bunch of discussion, the CID task force came down to rough >> consensus that asymmetric conn IDs were probably the right >> direction (CID task force members, please feel free to voice dissent >> here). Here's a complete writeup of what I think would be needed >> for asymmetric connection IDs. It's not a PR, because I think >> something self-contained is cleaner. >> >> Note that if we adopt this direction, we would be sacrificing >> public reset under some conditions (see previous emails to the >> list) and we would need to decide if it was worth keeping at all. >> >> >> OVERVIEW >> The basic idea is that each side gets to dictate the connection IDs >> that are used to send to it. During the handshake, you establish those >> CIDs and then each side can issue new CIDs during the connection. The >> main advantage of this is that it allows for symmetric topologies in which >> the client is also behind some kind of stateless LB/router rather than >> just the server. See Issue #1091 for more info on this. >> >> >> The overall handshake looks something like this: >> >> Client Server >> >> Initial [CID=XXX] {recv-CID=YYY} ----------------> >> <-------------- Cleartext [CID=YYY] {recv-CID=ZZZ} >> Cleartext [CID=ZZZ], {recv-CID=YYY} -------------> >> <-------------------------- Short header [CID=YYY] >> Short header [CID=ZZZ] --------------------------> >> >> >> The client's initial CID (XXX) is special, and either consists of >> >> (a) a randomly chosen dummy CID. Proposal: require this to be >> 8 bytes or at least a minimum. This should be the same >> for all Initial packets in a connection (unless a stateless >> reject is received, as below). >> (b) a CID which it received from the server in a stateless reject >> >> All the server's packets are sent with the client's receive CID (YYY) >> and all subsequent client packets are sent with the server's receive >> CID (ZZZ). The general rule is that you should send with the >> connection ID that you most recently received (where recently >> is defined as highest PN). >> >> Note: I believe it's safe to just use the sending CID as the mixin >> for the KDF, but I haven't thought this entirely through yet. >> >> Finally, you can send NEW_CONNECTION_ID in either direction to provide >> a new connection ID for the other side to use. The general assumption >> is that you can do this at any time, just as with current QUIC, and >> that any time you send to a new remote 3-tuple you should change CIDs >> if you can. Note that this means that endpoints should try to make >> sure that the other side has spare CIDs in case they need to migrate. >> >> >> WIRE ENCODING >> As we discussed in the meeting the short header should just have >> an implicit length CID. This gives us the following short header: >> >> +-+-+-+-+-+-+-+-+ >> |0|C|K| Type (5)| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + [Connection ID (*)] + <- >> change from 64 >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Packet Number (8/16/32) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Protected Payload (*) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Note that we may also be able to dispense with the C bit, if each >> side just gets to say "send me this CID exactly", why do we want >> to say "here is my CID but you can omit it". >> >> >> We have several options about the long header. The first question >> is where recv-CIDs go. In previous versions I suggested putting >> them in transport parameters, or elsewhere in the TLS handshake, >> and that might still be viable, though it has some drawbacks [0], >> so the other alternative is to put both CIDs in in the long header. >> This would look something like: >> >> +-+-+-+-+-+-+-+-+ >> |1| Type (7) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | DCID-Length | | >> +-+-+-+-+-+-+-+-+ Dst Connection ID (*) + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SCID-Length | | >> +-+-+-+-+-+-+-+-+ Src Connection ID (*) + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Version (32) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Packet Number (32) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload (*) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> The semantics here are that the first value is the CID you want to >> send to and the second one is the value you want used to send to you >> (I've inverted these to keep the order the same as short header). >> >> Two notes about this encoding: >> >> 1. I think we agreed that we didn't want arbitrary length CIDs up to >> 255 bytes, and yet we have room in this length byte. I propose we >> limit it to 31 bytes and then grease the remaining 3 bits [1]. >> >> 2. Because the client sends its CID first, there's no way to get the >> current QUIC semantics of the server just dictates the CID. I propose >> we fix that by defining a special sentinel CID (all 1s, all 0s, >> whatever) of whatever our maximum length is that means "just use your >> own CID". >> >> We can endlessly bikeshed on this structure. >> >> >> Finally, we will need to update NEW_CONNECTION_ID to allow a variable >> length CID. This would look like this: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence (i) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | CID-Length | | >> +-+-+-+-+-+-+-+-+ Connection ID (*) + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + + >> | | >> + Stateless Reset Token (128) + >> | | >> + + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> [0] However, in the transport parameters design, if the server's >> handshake gets reordered, the client might need to send some ACKs with >> the initial CID. However, we've agreed that the client's IP address >> has to be stable, so this isn't a problem. Alternately, you could >> change C->S CIDs in the short header if that was easier. >> >> [1] An alternative would be to have a sparse range (e.g., you can >> express 0-7 and then 8-22 by 2s, assuming I have counted correctly) >> and then we could pack both lengths into a single byte. As I said, >> lots of opportunities for bikeshedding here. >> > From nobody Sun Feb 18 18:10:49 2018 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 0D827127076 for ; Sun, 18 Feb 2018 18:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 2h8nPuZU9UKF for ; Sun, 18 Feb 2018 18:10:47 -0800 (PST) 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 52967126FDC for ; Sun, 18 Feb 2018 18:10:47 -0800 (PST) Received: by mail-pf0-x22b.google.com with SMTP id j24so640911pff.12 for ; Sun, 18 Feb 2018 18:10:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sYaQq025cKswDc6N/ODTI7c3ctJzNIKquiqZKKT4QSE=; b=fFuKzhzKlXctDc983q8v7zMfgVypOPcKhChPtKlIhtMXBsvVPj/EMelFG5UzF0TDED xnsv9NdH/R1XPIwuZS6LwoxkxeKe1lGTpEdUgQjVfGwCEdJwgX61csDEhuA3fZBZsEdB 6AqTAkZTjJGQ7rGElkuhueqt1fnMDDspG+6xXtvV4Al8yJL9m4SDhOagrNM9CkFEABVF ipEdUbktQ65Gf3ox6KFBSg4xJke8cq5Llgkz/MJeIRPKjpgdsG/15uO6wqe20qt2/e15 LrjUqrSS0CEAF8ZyhUAog272ku49V8HSX01woG0odgnGnT+WVFY3i4i13XJC+cTzMtQd 5QSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sYaQq025cKswDc6N/ODTI7c3ctJzNIKquiqZKKT4QSE=; b=OXf3jvxTuIUeieXTNTLhJaHlgnU5W02Cia7qUzzBi9D8MQH8TypTY2jKU58ho39NuV 2jkQULvfWcRrsGtJxsvRRlRqrvAtZCtCl+O2GdQSgzVSn775FdaCZNMyDepa/3o/QVih q2SWKJcv2Ap5k7G2lDXADmGrlDeC7DWBDykvpztVbUlMQcdSXtcXiO7f2t5oIXbIMcGO Pq/z1JjS3F9GGaOabsVqqXdKIgUb4+mkCwcISaF5zH4/VAhBmwkZiKbwCMOpAGkWwkbh 3yc7zVMkjPmr+xYwtu3Tt9rkY5Li49aolNMscVN6cOeuCcp9ni9s4EenTkPH/zqmMX4V 8ekA== X-Gm-Message-State: APf1xPD7/Ri/sFJ97eS5HVIpqCCM64LlGwKhpGJvWPEF1SyHBqmHyvze tBcJ0jcRsA9iwUCdvnxTowQ= X-Google-Smtp-Source: AH8x2266+ivbwtF2TkiGO8H4o0IsC+AER7yaNJJXiu11IGbGXE1bIuWbSWWs7Uq0j/FvZVgHvvvWeA== X-Received: by 10.101.82.198 with SMTP id z6mr2684597pgp.41.1519006246645; Sun, 18 Feb 2018 18:10:46 -0800 (PST) Received: from Justins-MacBook-Pro.local (ik1-330-25108.vs.sakura.ne.jp. [153.126.188.112]) by smtp.gmail.com with ESMTPSA id 64sm24976691pgj.39.2018.02.18.18.10.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 18:10:46 -0800 (PST) Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) To: Eric Rescorla Cc: Kazuho Oku , alexandre.ferrieux@orange.com, Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "quic@ietf.org" , Martin Thomson References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> From: Lingmo Zhu Message-ID: Date: Mon, 19 Feb 2018 10:10:40 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US 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: Mon, 19 Feb 2018 02:10:48 -0000 On 2018/02/19 1:25, Eric Rescorla wrote: > > > On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu > wrote: > > Hi all > > After some discussion with Kazuho and thanks to his help, I want to > propose that for Version Negotiation handling, "a client MAY wait for a > handshake packet after receiving a Version Negotiation packet". > > > Can you describe the precise attack you are concerned about? The VN packet > contains the client's randomly chosen CID, so only an on-path attacker can > forge a VN, but such an attacker can also generate a bogus ServerHello or > other messages that would cause the QUIC negotiation to fail. > > -Ekr > > It's an attack that generates VN packets with no acceptable version, on path. Of course such an attacker can generate other messages to interfere QUIC but utilizing VN packets needs no knowledge other than CID and no encryption, or only CID needs to be changed from a template. If other cleartext packet with wrong or no AEAD encryption described for the TLS handshake would be just ignored, those other messages should at least be encrypted, which costs much more and more complex to be implemented. Lingmo Zhu From nobody Sun Feb 18 18:56:30 2018 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 829111270A3 for ; Sun, 18 Feb 2018 18:56:28 -0800 (PST) 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 GYlAjbf1Ni_J for ; Sun, 18 Feb 2018 18:56:27 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::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 1D2A212708C for ; Sun, 18 Feb 2018 18:56:27 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id d14so10645887qtg.1 for ; Sun, 18 Feb 2018 18:56:27 -0800 (PST) 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=fA1RwFyL26GuD0/pQrUmqBDX77AkJIwMURrW3SXNDMg=; b=H1CC6GrmKVy39/FrbRii26ctGcZZyeYr3VJ3AQ9IHrtEN4/LVKAZ3B41qLsnq5UGi2 bdEFgQhLYCojIQZuiV8MqRU8gGHy7rpo5mDcWfClmfj4uISlLsjN6u1wIQkyp7DPCLs8 N2OQN+odjuX97S+T7LG0z58az9yfgXAuhDc21xmeRc9PgYuTXWjTo4prxUjHE6pFY7Ky XWVo86/ySO34in38qe8Q7DXc46gbxK9sLzqZ1kw64V1XSbLNAol585eENAfVsiwo1/zM 1pAKVQKe/voNfWF92d0Y65YR1B2jP81Yo2oCBefmY0mxcaDBVdGguBIzn086JcEr5E9Z fa7g== 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=fA1RwFyL26GuD0/pQrUmqBDX77AkJIwMURrW3SXNDMg=; b=BehyM3CVkAIST+JvN5ldubVSiJXZev4KLUjtb6qjOXLBb33yJMhJFgKk5/yS3nFGlX ijq2mrJGvtobQy6QZr6wM1r6p1Z7ds9tQ3uhjkIpl47tw2P1YOl6gOYQnVtSAO9I5N3q IngSFLX2X1R3/W6hJGAzrhXC72Bh28oFM9poMLhRnVScmSJ12HSupCYbyHVZMCsNLY+W JYEMmBvSSQ7uPcj/rOEkroyEfxL7T2blBKilK49/99kvRGnRSb1+JpCanqYFI/9OtQE0 +ExTH9OGaY2Swy5MSvUPh/d1MMrELvJq8EuSzCk4HGf1h7ASls6zXKLYduHjTFD1Ojw9 KT8w== X-Gm-Message-State: APf1xPB/wee6Md0O/HnMA3aDNJNMahUsgjR79/wqn68AZqH/0OhinVAk cWGvQOpnoIpAZe7FkaI2Exm03kcJJheiVtmXUPFAew== X-Google-Smtp-Source: AH8x226lg/fMwDgimEl+O+eQ3EBTOwFT/GDp36clpU5HnjPLPy3O56KtypwuZDw5/mRHBk64JGtTqdqIEhdqULI9OVo= X-Received: by 10.237.61.112 with SMTP id h45mr22274011qtf.225.1519008986103; Sun, 18 Feb 2018 18:56:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Sun, 18 Feb 2018 18:55:45 -0800 (PST) In-Reply-To: References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> From: Eric Rescorla Date: Sun, 18 Feb 2018 18:55:45 -0800 Message-ID: Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) To: Lingmo Zhu Cc: Kazuho Oku , alexandre.ferrieux@orange.com, Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Martin Thomson Content-Type: multipart/alternative; boundary="001a113520e007183a056587d7fe" 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, 19 Feb 2018 02:56:28 -0000 --001a113520e007183a056587d7fe Content-Type: text/plain; charset="UTF-8" On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu wrote: > > > On 2018/02/19 1:25, Eric Rescorla wrote: > >> >> >> On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu > zlm2006@gmail.com>> wrote: >> >> Hi all >> >> After some discussion with Kazuho and thanks to his help, I want to >> propose that for Version Negotiation handling, "a client MAY wait for >> a >> handshake packet after receiving a Version Negotiation packet". >> >> >> Can you describe the precise attack you are concerned about? The VN packet >> contains the client's randomly chosen CID, so only an on-path attacker can >> forge a VN, but such an attacker can also generate a bogus ServerHello or >> other messages that would cause the QUIC negotiation to fail. >> >> -Ekr >> >> >> > It's an attack that generates VN packets with no acceptable version, on > path. Of course such an attacker can generate other messages to interfere > QUIC but utilizing VN packets needs no knowledge other than CID and no > encryption, or only CID needs to be changed from a template. If other > cleartext packet with wrong or no AEAD encryption described for the TLS > handshake would be just ignored, those other messages should at least be > encrypted, which costs much more and more complex to be implemented. Thanks for the explanation. I don't consider this a significant difference in attacker capabilities. -Ekr > > Lingmo Zhu > --001a113520e007183a056587d7fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu <zlm2006@gmail.com>= wrote:


On 2018/02/19 1:25, Eric Rescorla wrote:


On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu <zlm2006@gmail.com <mailto:zlm2006@gmail.com>> wrot= e:

=C2=A0 =C2=A0 Hi all

=C2=A0 =C2=A0 After some discussion with Kazuho and thanks to his help, I w= ant to
=C2=A0 =C2=A0 propose that for Version Negotiation handling, "a client= MAY wait for a
=C2=A0 =C2=A0 handshake packet after receiving a Version Negotiation packet= ".


Can you describe the precise attack you are concerned about? The VN packet<= br> contains the client's randomly chosen CID, so only an on-path attacker = can
forge a VN, but such an attacker can also generate a bogus ServerHello or other messages that would cause the QUIC negotiation to fail.

-Ekr



 It's an attack that generates VN packets with no acceptable version, on= path. Of course such an attacker can generate other messages to interfere = QUIC but utilizing VN packets needs no knowledge other than CID and no encr= yption, or only CID needs to be changed from a template. If other cleartext= packet with wrong or no AEAD encryption described for the TLS handshake wo= uld be just ignored, those other messages should at least be encrypted, whi= ch costs much more and more complex to be implemented.
Thanks for the explanation. I don't consider this a signifi= cant difference in attacker capabilities.

-Ekr



Lingmo Zhu

--001a113520e007183a056587d7fe-- From nobody Sun Feb 18 19:41:51 2018 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 4D7741201FA for ; Sun, 18 Feb 2018 19:41:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (1024-bit key) header.d=fb.com header.b=Xg6vPdzC; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=TYt2qr5r 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 G-ZC_qT-b4if for ; Sun, 18 Feb 2018 19:41:48 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 DBBC21200C1 for ; Sun, 18 Feb 2018 19:41:48 -0800 (PST) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1J3dsjU023904; Sun, 18 Feb 2018 19:41:41 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=IhjPBoXVyFZEUWuJhXWD3K3YlpmLD9+kzDCETcXRBps=; b=Xg6vPdzCWyjIkM7ynhZ/5DA6ADDzn9G1cwqt0qlqMsovcaI1AjkA/upWLU0RVHhJXRr0 qTF31T3NVeVi2GSqSwtTr7ugPUOV5wSQ5piM0FetPHzAIYE/ZebdFo30Mzt7n9deQIFp Sp486q/IvyBVZxPN4X/TAtxW+vA5M6xkGzg= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2g7a3ycu5p-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 18 Feb 2018 19:41:41 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.15) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 18 Feb 2018 19:41:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IhjPBoXVyFZEUWuJhXWD3K3YlpmLD9+kzDCETcXRBps=; b=TYt2qr5roIiGcfxVgbHhIT4FLfVI6ds+iUJhZ4Op6kgYTuPA0qrKbYiFxWVFU8lpDNNIBz3+fyLZ3HP2vkFN3hVfnddD9GQBxeBzd7Tlw6JJRNfEh0ZveDlDvDwjZrmC8na+edf/VnT9g6TidsbJVAREwd/6aD3+zsM/RSkdv8U= Received: from MWHPR15MB1821.namprd15.prod.outlook.com (10.174.255.137) by MWHPR15MB1584.namprd15.prod.outlook.com (10.173.235.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Mon, 19 Feb 2018 03:41:18 +0000 Received: from MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::b054:d63c:f848:809d]) by MWHPR15MB1821.namprd15.prod.outlook.com ([fe80::b054:d63c:f848:809d%17]) with mapi id 15.20.0506.023; Mon, 19 Feb 2018 03:41:18 +0000 From: Subodh Iyengar To: Eric Rescorla , Lingmo Zhu CC: "alexandre.ferrieux@orange.com" , Christian Huitema , =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= , "quic@ietf.org" , Martin Thomson , Kazuho Oku Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) Thread-Topic: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) Thread-Index: AQHTqM/yy1tJknD/DUC51fVp8eT3K6OqaWMAgACSqgCAAAyZgIAADCUC Date: Mon, 19 Feb 2018 03:41:18 +0000 Message-ID: References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:180::e2a7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1584; 7:n0vvNzj4B+oryPVtrAMhg1DWU5qnYZPEw8yvRsoTg+yL9TVmRZYDjjMbfaxM1csUfItYX0W7CkM2b8vB3TflS+ySZ19ltuLZq3p/yKFDXKn0USPJsX7Xd8cw/MW2zUBjyLBGeXxs0shihjFXd4fKncwnkABQsXiJaeRzKiCXnoGKun3ghb4IqzwjrZSXXTZJYPp0xygYsguf2eJFX7vnoHpri8oLXVnFhh5Bvscz1QmZ008MLYbKfUohJbHVV9gW; 20:8k5l5LlC8WWE6rxU0thBT+S8OsU5KdUgxM6D1okjcDcUrejTW8kQJZkDUTDjMl3xL+FnsMOJH0DCK70EQUBB1YJCnKxl3xwtY7PxVHlWChmH83/ldppzjIzfNUhLU0kB783VPCH0VGhBY7uamxQNvrEckTZCWetKCYKad17V+/w= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: df4661ab-3c91-4487-834e-08d5774aa2ce x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR15MB1584; x-ms-traffictypediagnostic: MWHPR15MB1584: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231101)(11241501184)(944501161)(3002001)(6041288)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:MWHPR15MB1584; BCL:0; PCL:0; RULEID:; SRVR:MWHPR15MB1584; x-forefront-prvs: 0588B2BD96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(346002)(366004)(39380400002)(189003)(199004)(51914003)(53754006)(2950100002)(5250100002)(2900100001)(33656002)(6606003)(5660300001)(478600001)(55016002)(2906002)(14454004)(6246003)(54896002)(53936002)(236005)(97736004)(9686003)(6116002)(106356001)(229853002)(6436002)(19627405001)(186003)(86362001)(316002)(99286004)(68736007)(4326008)(3660700001)(7696005)(93886005)(25786009)(8676002)(8936002)(110136005)(81156014)(76176011)(54906003)(81166006)(105586002)(3280700002)(39060400002)(74316002)(102836004)(6506007)(7736002)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1584; H:MWHPR15MB1821.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: x8ErYOkRenKHosTuofrDS8ddn9HT24w/PJ6zKKmV0Ewz84ZER0paQrZsMpfY+mVBBRTjAi6iXxctqQ0yaBpTlK08Y0K/TS+IYjDsiM6BHRP7OUZzpLdVJz+Gal+o/KwFemQS869pJ9K6WMN2Oi3Mj33RSeIs3i5swFE+p81PGpQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB182101493383DBBDD889B6C7B6C80MWHPR15MB1821namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: df4661ab-3c91-4487-834e-08d5774aa2ce X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2018 03:41:18.4271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1584 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_02:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe 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, 19 Feb 2018 03:41:50 -0000 --_000_MWHPR15MB182101493383DBBDD889B6C7B6C80MWHPR15MB1821namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > It's an attack that generates VN packets with no acceptable version, on p= ath. Of course such an attacker can generate other messages to interfere QU= IC but utilizing VN packets needs no knowledge other than CID and no encryp= tion, or only CID needs to be changed from a template. If other cleartext p= acket with wrong or no AEAD encryption described for the TLS handshake woul= d be just ignored, those other messages should at least be encrypted, which= costs much more and more complex to be implemented. I agree with ekr, a TLS alert is similar and does not require knowledge of = any state, knowledge of the cid gives you the ability to craft a packet tha= t will be accepted by the client (even Handshake packets). Subodh ________________________________ From: QUIC on behalf of Eric Rescorla Sent: Sunday, February 18, 2018 6:55:45 PM To: Lingmo Zhu Cc: alexandre.ferrieux@orange.com; Christian Huitema; Mikkel Fahn=F8e J=F8r= gensen; quic@ietf.org; Martin Thomson; Kazuho Oku Subject: Re: Malicious Version Negotiation Handling (Was: Questions about V= ersion Negotiation Concerning Possible Handshake Interruption) On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu > wrote: On 2018/02/19 1:25, Eric Rescorla wrote: On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu >> wrote: Hi all After some discussion with Kazuho and thanks to his help, I want to propose that for Version Negotiation handling, "a client MAY wait for a handshake packet after receiving a Version Negotiation packet". Can you describe the precise attack you are concerned about? The VN packet contains the client's randomly chosen CID, so only an on-path attacker can forge a VN, but such an attacker can also generate a bogus ServerHello or other messages that would cause the QUIC negotiation to fail. -Ekr It's an attack that generates VN packets with no acceptable version, on pat= h. Of course such an attacker can generate other messages to interfere QUIC= but utilizing VN packets needs no knowledge other than CID and no encrypti= on, or only CID needs to be changed from a template. If other cleartext pac= ket with wrong or no AEAD encryption described for the TLS handshake would = be just ignored, those other messages should at least be encrypted, which c= osts much more and more complex to be implemented. Thanks for the explanation. I don't consider this a significant difference = in attacker capabilities. -Ekr Lingmo Zhu --_000_MWHPR15MB182101493383DBBDD889B6C7B6C80MWHPR15MB1821namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


> It's an attack that generates VN packets with no acceptable version, o= n path. Of course such an attacker can generate other messages to interfere= QUIC but utilizing VN packets needs no knowledge other than CID and no enc= ryption, or only CID needs to be changed from a template. If other cleartext packet with wrong or no AEAD encryptio= n described for the TLS handshake would be just ignored, those other messag= es should at least be encrypted, which costs much more and more complex to = be implemented.

I agree with ekr, a TLS alert is similar and does not require knowledge of = any state, knowledge of the cid gives you the ability to craft a packet tha= t will be accepted by the client (even Handshake packets).


Subodh

From: QUIC <quic-bounces= @ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
Sent: Sunday, February 18, 2018 6:55:45 PM
To: Lingmo Zhu
Cc: alexandre.ferrieux@orange.com; Christian Huitema; Mikkel Fahn=F8= e J=F8rgensen; quic@ietf.org; Martin Thomson; Kazuho Oku
Subject: Re: Malicious Version Negotiation Handling (Was: Questions = about Version Negotiation Concerning Possible Handshake Interruption)
 


On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu <zlm2006@gmail.co= m> wrote:


On 2018/02/19 1:25, Eric Rescorla wrote:


On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu <zlm2006@gmail.com <mailto:zlm2006@gmail.com>> wrot= e:

    Hi all

    After some discussion with Kazuho and thanks to his help, I w= ant to
    propose that for Version Negotiation handling, "a client= MAY wait for a
    handshake packet after receiving a Version Negotiation packet= ".


Can you describe the precise attack you are concerned about? The VN packet<= br> contains the client's randomly chosen CID, so only an on-path attacker can<= br> forge a VN, but such an attacker can also generate a bogus ServerHello or other messages that would cause the QUIC negotiation to fail.

-Ekr



It's an attack that generates VN packets with no acceptable version,= on path. Of course such an attacker can generate other messages to interfe= re QUIC but utilizing VN packets needs no knowledge other than CID and no e= ncryption, or only CID needs to be changed from a template. If other cleartext packet with wrong or no AEA= D encryption described for the TLS handshake would be just ignored, those o= ther messages should at least be encrypted, which costs much more and more = complex to be implemented.

Thanks for the explanation. I don't consider this a significant differ= ence in attacker capabilities.

-Ekr



Lingmo Zhu

--_000_MWHPR15MB182101493383DBBDD889B6C7B6C80MWHPR15MB1821namp_-- From nobody Sun Feb 18 20:35:06 2018 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 11F191270AC for ; Sun, 18 Feb 2018 20:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 yo7F9EQHcxi0 for ; Sun, 18 Feb 2018 20:35:03 -0800 (PST) Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::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 B6D9A1201FA for ; Sun, 18 Feb 2018 20:35:03 -0800 (PST) Received: by mail-pl0-x233.google.com with SMTP id w21so5022484plp.11 for ; Sun, 18 Feb 2018 20:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=dE6OjE3JnC17a3y/Jm0ziwA4fGSbSbf5mehDkHXZXVE=; b=KvdirFOsYkCyUWia1sWg1WE0/AonIuOTQjSi0muI8FdQWcrIQXvSAC4fgYRLWAJvFQ 18BrFWiab45KaTIokil0e6bUJjE0g8d1iVuUFYd6SRBH26ELw2UBzixyE4JzUC8Gm2Nv 3DtBc3/g2PP5x4EI26TDVB0aGAEw/Qr5FkxErpi+p555TClUFZgdist0iLBRG9jqqY/+ JIVOQE8lghKoxdyBL6JopzKIVuIF4Op3Eg5hu4Oz18f22tZAkgSx0APNuTDOxI08F0XK id6RWAEJADx2uSf3q1Su8emD8uNRtiCTUwvQst/SMT79YxAPytQjnGvgN6n0ox+RY+Gt S8zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=dE6OjE3JnC17a3y/Jm0ziwA4fGSbSbf5mehDkHXZXVE=; b=huApL7GRwaFT07tovXNKcyasNVfT9j/0IOnHK78iA8DwOIc9d0j1HtLPF7exGwcSTx 7oFfafeWb4sw7UhUvYuzfmUqcDy7ItWtimW34y83iNEmlgADBSLTK3+mgB3KnwAoB5+8 m7BRKqUm+nqkUjkPlLsuGYY0QqAHeLOOSCtQm2iPVFBniaG9Sib2jIwuqJcsNULEsLNP vboxTpR20qj+2xT1bVGy1kAlwH9jEiMfdcb3Fq4dKcHz4ueJM0QG1xls4z030fBA0KiG K5kKzsIqxl8Se77Vj1tqVJhkk4X2AQne82qdqdcyFfe1cHzveaC+YzxDhx3bXT7V9kOo RyGw== X-Gm-Message-State: APf1xPA+LU0BYgD4KYf1A72wDwCt9wVykg/JFBV/snbdNv/5smgBS0ja QCEbuNsy+321gOsUoO+eV50= X-Google-Smtp-Source: AH8x224M/ig7Am5ptgUy09MFsgN2Wtc9ye15RCzFFzs3C/Lh2eN/Nq25OYPS8iDbjE0KKPy5+2fvBA== X-Received: by 2002:a17:902:6849:: with SMTP id f9-v6mr13345977pln.113.1519014903092; Sun, 18 Feb 2018 20:35:03 -0800 (PST) Received: from Justins-MacBook-Pro.local (ik1-330-25108.vs.sakura.ne.jp. [153.126.188.112]) by smtp.gmail.com with ESMTPSA id h3sm13726140pgf.26.2018.02.18.20.34.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Feb 2018 20:35:02 -0800 (PST) Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) To: Subodh Iyengar , Eric Rescorla Cc: "alexandre.ferrieux@orange.com" , Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "quic@ietf.org" , Martin Thomson , Kazuho Oku References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> From: Lingmo Zhu Message-ID: Date: Mon, 19 Feb 2018 12:34:56 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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, 19 Feb 2018 04:35:05 -0000 Thank you for your comments and explanations. IMHO VN packet handling is part of QUIC transport which is independent with any specific TLS version, though attacks targeting TLS handshake could get similar result. I understand that we could never win against on-path attackers. But I just wonder if we should consider about that or how far we could. Lingmo Zhu On 2018/02/19 11:41, Subodh Iyengar wrote: > > > It's an attack that generates VN packets with no acceptable version, > on path. Of course such an attacker can generate other messages to > interfere QUIC but utilizing VN packets needs no knowledge other than > CID and no encryption, or only CID needs to be changed from a template. > If other cleartext packet with wrong or no AEAD encryption described for > the TLS handshake would be just ignored, those other messages should at > least be encrypted, which costs much more and more complex to be > implemented. > > I agree with ekr, a TLS alert is similar and does not require knowledge > of any state, knowledge of the cid gives you the ability to craft a > packet that will be accepted by the client (even Handshake packets). > > > Subodh > > ------------------------------------------------------------------------ > *From:* QUIC on behalf of Eric Rescorla > > *Sent:* Sunday, February 18, 2018 6:55:45 PM > *To:* Lingmo Zhu > *Cc:* alexandre.ferrieux@orange.com; Christian Huitema; Mikkel Fahnøe > Jørgensen; quic@ietf.org; Martin Thomson; Kazuho Oku > *Subject:* Re: Malicious Version Negotiation Handling (Was: Questions > about Version Negotiation Concerning Possible Handshake Interruption) > > > On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu > wrote: > > > > On 2018/02/19 1:25, Eric Rescorla wrote: > > > > On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu >> wrote: > >     Hi all > >     After some discussion with Kazuho and thanks to his help, I > want to >     propose that for Version Negotiation handling, "a client > MAY wait for a >     handshake packet after receiving a Version Negotiation packet". > > > Can you describe the precise attack you are concerned about? The > VN packet > contains the client's randomly chosen CID, so only an on-path > attacker can > forge a VN, but such an attacker can also generate a bogus > ServerHello or > other messages that would cause the QUIC negotiation to fail. > > -Ekr > > > > It's an attack that generates VN packets with no acceptable version, > on path. Of course such an attacker can generate other messages to > interfere QUIC but utilizing VN packets needs no knowledge other > than CID and no encryption, or only CID needs to be changed from a > template. If other cleartext packet with wrong or no AEAD encryption > described for the TLS handshake would be just ignored, those other > messages should at least be encrypted, which costs much more and > more complex to be implemented. > > > Thanks for the explanation. I don't consider this a significant > difference in attacker capabilities. > > -Ekr > > > > Lingmo Zhu > > From nobody Sun Feb 18 20:42:21 2018 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 9E4E11201FA for ; Sun, 18 Feb 2018 20:42:19 -0800 (PST) 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 qhjSesShdvsT for ; Sun, 18 Feb 2018 20:42:18 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 BC19612711A for ; Sun, 18 Feb 2018 20:42:17 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id k25so10795123qtj.9 for ; Sun, 18 Feb 2018 20:42:17 -0800 (PST) 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=1gVXiZZT4HzA4Z9JmFBZJBzhkMxTti0k9Ain7J78lIg=; b=ORp/e4rEUsMhnsZjINDAoTdUNG1qmV4YFCkgwwfrxpqJhLlDgBTOE6vBUw40/mcl9q B7+i1Ip6Ri2QTrf8b1vTZgWzHRgUoHAZHpRA5QKl7zd7nWBU9I4jHNOJe8794KpgB5JK 8FrYGu7ZaHH562PMpyGiJDE29r2Qf+hoYO+pP1x7IavfoQhqgRl5VNBrv0xg8N+4KDoH V76wT10JiqvAa9gpooyAj50SJdy7kqDHL5cnburWJ/MRDeK1p54zeAiqwE9zV1AZexYj WSbclbKq3bf8L48EDqx4EP6j4SLsEfpQgUzGfudnn8Hy31giNUQuM5wDWdA1JwCVKIYe la3A== 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=1gVXiZZT4HzA4Z9JmFBZJBzhkMxTti0k9Ain7J78lIg=; b=tgx9JYc0amJAXzr0k5bHv8H4giab8HU2Q0fFSdsDe7/RCthRsspLVAjVhOKN32dANb MfL0K8Rdy/8FJ/aoPb5A0EOLNQz97PBq9x0AvnijxoU5EmJ/t6c6YhnSC2Kt89orCsmX OwpAOTrvUUL+LaXHAMQrxtzFxUFnpBeGk0AC6/LgdIS7B9WoJZrSRwMCXAK851tThfoe 4MoHqSyQQA++bjnmKzLQnnEfYC0cxd0DaWdd8mAjk3O14J4+CHLzpuXns0ozJUpeM/zh fFo3uty5qq/GNj2VbWL3rG2tZQ+EfXEL+cbPM59iCTIJWTe4Vs3UISlMrSahInli7sgY YFfQ== X-Gm-Message-State: APf1xPCdipsX2o4q06b8o4OaZtclQnmgSGZsNdW0Xhrm7VK7xdd1hI7j FuWlpg7ubVkNhIEkECw3SbuzDOIHeb6yTKO1oXAUeA== X-Google-Smtp-Source: AH8x224JrEo/k7asfjDbQAEBAC7anDnSDXrQ+BzL6yXVg0Dry+/5eefEVsP8M1Dkl2p/8vXg8IfpxD89MA4yrSYrFV8= X-Received: by 10.200.42.168 with SMTP id b37mr22807614qta.321.1519015336652; Sun, 18 Feb 2018 20:42:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Sun, 18 Feb 2018 20:41:36 -0800 (PST) In-Reply-To: References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> From: Eric Rescorla Date: Sun, 18 Feb 2018 20:41:36 -0800 Message-ID: Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) To: Lingmo Zhu Cc: Subodh Iyengar , "alexandre.ferrieux@orange.com" , Christian Huitema , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Martin Thomson , Kazuho Oku Content-Type: multipart/alternative; boundary="001a113a7dd08cc7e3056589511f" 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, 19 Feb 2018 04:42:19 -0000 --001a113a7dd08cc7e3056589511f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't think increasing the on-path attacker's marginal difficulty from not requiring any crypto to requiring simple crypto in order to mount a DoS attack is worth changing the protocol for. -Ekr On Sun, Feb 18, 2018 at 8:34 PM, Lingmo Zhu wrote: > Thank you for your comments and explanations. IMHO VN packet handling is > part of QUIC transport which is independent with any specific TLS version= , > though attacks targeting TLS handshake could get similar result. > > I understand that we could never win against on-path attackers. But I jus= t > wonder if we should consider about that or how far we could. > > Lingmo Zhu > > On 2018/02/19 11:41, Subodh Iyengar wrote: > >> >> > It's an attack that generates VN packets with no acceptable version, >> on path. Of course such an attacker can generate other messages to >> interfere QUIC but utilizing VN packets needs no knowledge other than CI= D >> and no encryption, or only CID needs to be changed from a template. If >> other cleartext packet with wrong or no AEAD encryption described for th= e >> TLS handshake would be just ignored, those other messages should at leas= t >> be encrypted, which costs much more and more complex to be implemented. >> >> I agree with ekr, a TLS alert is similar and does not require knowledge >> of any state, knowledge of the cid gives you the ability to craft a pack= et >> that will be accepted by the client (even Handshake packets). >> >> >> Subodh >> >> ------------------------------------------------------------------------ >> *From:* QUIC on behalf of Eric Rescorla < >> ekr@rtfm.com> >> *Sent:* Sunday, February 18, 2018 6:55:45 PM >> *To:* Lingmo Zhu >> *Cc:* alexandre.ferrieux@orange.com; Christian Huitema; Mikkel Fahn=C3= =B8e >> J=C3=B8rgensen; quic@ietf.org; Martin Thomson; Kazuho Oku >> *Subject:* Re: Malicious Version Negotiation Handling (Was: Questions >> about Version Negotiation Concerning Possible Handshake Interruption) >> >> >> On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu > zlm2006@gmail.com>> wrote: >> >> >> >> On 2018/02/19 1:25, Eric Rescorla wrote: >> >> >> >> On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu > > >> >> wrote: >> >> Hi all >> >> After some discussion with Kazuho and thanks to his help, I >> want to >> propose that for Version Negotiation handling, "a client >> MAY wait for a >> handshake packet after receiving a Version Negotiation >> packet". >> >> >> Can you describe the precise attack you are concerned about? The >> VN packet >> contains the client's randomly chosen CID, so only an on-path >> attacker can >> forge a VN, but such an attacker can also generate a bogus >> ServerHello or >> other messages that would cause the QUIC negotiation to fail. >> >> -Ekr >> >> >> >> It's an attack that generates VN packets with no acceptable version, >> on path. Of course such an attacker can generate other messages to >> interfere QUIC but utilizing VN packets needs no knowledge other >> than CID and no encryption, or only CID needs to be changed from a >> template. If other cleartext packet with wrong or no AEAD encryption >> described for the TLS handshake would be just ignored, those other >> messages should at least be encrypted, which costs much more and >> more complex to be implemented. >> >> >> Thanks for the explanation. I don't consider this a significant >> difference in attacker capabilities. >> >> -Ekr >> >> >> >> Lingmo Zhu >> >> >> --001a113a7dd08cc7e3056589511f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't think increasing the on-path attacker's ma= rginal difficulty from not requiring any crypto to requiring simple crypto = in order to mount a DoS attack is worth changing the protocol for.

=
-Ekr


On Sun, Feb 18, 2018 at 8:34 PM, Lingmo Zhu <zlm2= 006@gmail.com> wrote:
Thank= you for your comments and explanations. IMHO VN packet handling is part of= QUIC transport which is independent with any specific TLS version, though = attacks targeting TLS handshake could get similar result.

I understand that we could never win against on-path attackers. But I just = wonder if we should consider about that or how far we could.

Lingmo Zhu

On 2018/02/19 11:41, Subodh Iyengar wrote:

=C2=A0> It's an attack that generates VN packets with no acceptable = version, on path. Of course such an attacker can generate other messages to= interfere QUIC but utilizing VN packets needs no knowledge other than CID = and no encryption, or only CID needs to be changed from a template. If othe= r cleartext packet with wrong or no AEAD encryption described for the TLS h= andshake would be just ignored, those other messages should at least be enc= rypted, which costs much more and more complex to be implemented.

I agree with ekr, a TLS alert is similar and does not require knowledge of = any state, knowledge of the cid gives you the ability to craft a packet tha= t will be accepted by the client (even Handshake packets).


Subodh

 -----------------------------------------------------------------= -------
*From:* QUIC <quic-bounces@ietf.org> on behalf of Eric Rescorla <ekr@rtfm.com>
*Sent:* Sunday, February 18, 2018 6:55:45 PM
*To:* Lingmo Zhu
*Cc:* al= exandre.ferrieux@orange.com; Christian Huitema; Mikkel Fahn=C3=B8e J=C3= =B8rgensen; quic@ietf.or= g; Martin Thomson; Kazuho Oku
*Subject:* Re: Malicious Version Negotiation Handling (Was: Questions about= Version Negotiation Concerning Possible Handshake Interruption)


On Sun, Feb 18, 2018 at 6:10 PM, Lingmo Zhu <zlm2006@gmail.com <mailto:zlm2006@gmail.com>> wrot= e:



=C2=A0 =C2=A0 On 2018/02/19 1:25, Eric Rescorla wrote:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 On Sun, Feb 18, 2018 at 7:48 AM, Lingmo Zhu <= ;zlm2006@gmail.com
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:zlm2006@gmail.com> <mailto:zlm2006@gmail.com

=C2=A0 =C2=A0 =C2=A0 =C2=A0 <mailto:zlm2006@gmail.com>>> wrote:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 Hi all

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 After some discussion with = Kazuho and thanks to his help, I
=C2=A0 =C2=A0 =C2=A0 =C2=A0 want to
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 propose that for Version Ne= gotiation handling, "a client
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MAY wait for a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 handshake packet after rece= iving a Version Negotiation packet".


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Can you describe the precise attack you are con= cerned about? The
=C2=A0 =C2=A0 =C2=A0 =C2=A0 VN packet
=C2=A0 =C2=A0 =C2=A0 =C2=A0 contains the client's randomly chosen CID, = so only an on-path
=C2=A0 =C2=A0 =C2=A0 =C2=A0 attacker can
=C2=A0 =C2=A0 =C2=A0 =C2=A0 forge a VN, but such an attacker can also gener= ate a bogus
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ServerHello or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 other messages that would cause the QUIC negoti= ation to fail.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -Ekr



=C2=A0 =C2=A0 It's an attack that generates VN packets with no acceptab= le version,
=C2=A0 =C2=A0 on path. Of course such an attacker can generate other messag= es to
=C2=A0 =C2=A0 interfere QUIC but utilizing VN packets needs no knowledge ot= her
=C2=A0 =C2=A0 than CID and no encryption, or only CID needs to be changed f= rom a
=C2=A0 =C2=A0 template. If other cleartext packet with wrong or no AEAD enc= ryption
=C2=A0 =C2=A0 described for the TLS handshake would be just ignored, those = other
=C2=A0 =C2=A0 messages should at least be encrypted, which costs much more = and
=C2=A0 =C2=A0 more complex to be implemented.


Thanks for the explanation. I don't consider this a significant differe= nce in attacker capabilities.

-Ekr



=C2=A0 =C2=A0 Lingmo Zhu



--001a113a7dd08cc7e3056589511f-- From nobody Sun Feb 18 20:49:38 2018 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 CCAE512711A for ; Sun, 18 Feb 2018 20:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXEbcaCq9G1T for ; Sun, 18 Feb 2018 20:49:36 -0800 (PST) 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 3A0B41201FA for ; Sun, 18 Feb 2018 20:49:36 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1endOP-0002gQ-IA for quic@ietf.org; Mon, 19 Feb 2018 05:49:34 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1endOL-0003if-RM for quic@ietf.org; Sun, 18 Feb 2018 23:49:30 -0500 Received: (qmail 15739 invoked from network); 19 Feb 2018 04:49:29 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.184]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Feb 2018 04:49:29 -0000 To: quic@ietf.org References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> From: Christian Huitema Message-ID: <7317339e-3b4a-bf03-5624-e0d81f5c8a2c@huitema.net> Date: Sun, 18 Feb 2018 20:49:24 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.60) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5k8cc+0QaAHBx/LLXRnjrI1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVi9dljkJhM8zlg7/e1ZqbQ3M7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB+FWCyy3VMwU/Tu6lpkyLYh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYZsb471zK7fbW8hSVMoqp pS0tFl0bR3sce73Q9OxrVmUKTJV3uvxSzcg5tzcc78AIyWXkWx9Oc6FsxfRE8LUCq9m1LR/Rkhms gi1bNni1Nx10xK5dOvm4pbg8CBiJcsFLIaKLZaIWHErhz1UEr981hLCx4eCSemGsHMs75OfoLqeq 613YX/JpkaqfAljBKlD3pyI1J519bLUrM3neslGWzg/CXrvYZfaN8BpCoaqUuMDouROe77KOt1v8 CMoiiVQVf/qOH8le3Zo2iD646pXyZ/CbKTDA0CdqvvZLVqfbRAUKcZIuviiTlhP5iKsKcxHR/WRb dco3pKNX9x7s84ASzjoUd/Fji/4E0A1Wfl7CNnoniG/Mx18wh299NVDnPvmw8t3Xj/LzZ5s/OJg1 L2asZ1FPmtYUPwECbZov76lmox9FrrkXXOH9yk2+X2eiUHXZfks5suSVIgIg9uJ3gfzn7g== 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: Mon, 19 Feb 2018 04:49:38 -0000 On 2/18/2018 8:41 PM, Eric Rescorla wrote: > I don't think increasing the on-path attacker's marginal difficulty > from not requiring any crypto to requiring simple crypto in order to > mount a DoS attack is worth changing the protocol for. Changing the protocol, probably not. But Lingmo's suggestion is one of the several steps that we could take against hardening against a man on the side attack. And it is a very simple one: if you receive a VN that does not contain any acceptable option, just ignore it. If this was legit, the connection will actually break after a short timer. If it was not, the next received message will be a Server Hello, and the connection will progress. Sounds like a reasonable trade-off. -- Christian Huitema From nobody Sun Feb 18 20:55:03 2018 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 673D312711A for ; Sun, 18 Feb 2018 20:55:02 -0800 (PST) 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 mEu9sG9qKbuw for ; Sun, 18 Feb 2018 20:54:59 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 AB0771201FA for ; Sun, 18 Feb 2018 20:54:59 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id h129so10812846qke.8 for ; Sun, 18 Feb 2018 20:54:59 -0800 (PST) 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=McQcMQXdGLLwVM7/hIcuf+cFn9iTJf/fVdqGXCkJVZU=; b=aeH1jGpodqqoirQ+lVJ+oWKANxPk3vMVO/fhENOBcZAXuAcGH5hBsQLSH8b0KxkNAZ 4gXvYrdS+TdqKvfDgAdURKh3fiGtW3LXiUkOKTFfCzvfACQL1ih/a4YqxVYV5lV/iYS/ 9yc8f1eDE45vlBq1a4g6JeYDm3wdh2FKulIoHtmldeuhliLK3/sXFMiYt7d7QidCQdKY tuW49hswR8CmrfINcQddNOIrx0dPpcDYkSnXQoNvFQR1chNiAIyg9bMCLaUF8/XFO7VT e9zvTpM0GBZYdy0bCVmFR4jrSzuat/lwIqCNjA6Gx2JqNSEOOUQFPe1pQ1WSvBKXeBmX FzJw== 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=McQcMQXdGLLwVM7/hIcuf+cFn9iTJf/fVdqGXCkJVZU=; b=espMzd8mQV/Kg/gOmrfE9uLyCg3VUjZrFYZfc6qEqUz/q7YBsqsd2Uxob2IHRtK5ab aa+U7bdjMi5vuXi8Z4DYqzB3Q88WySL9VXgYH26J3+dMREOJGQ9E/rZnBiDIY8RdXs5u 2fBPZ/qJH1il7cAfZEI7yvzDhcKX0n+sCGfLOl8oicUKnB3+BmAcCRDZMaDl5Ue8iNQ1 IKCPR1TTdbdWP8vq1nC3Z9tD9gHj874zcBRByHXpKmL4Zliewcbezr7cnpaaEdB2xLEL cKHX7G0hNBujH4j2q1EwvDx3PhgpRpFipW4A5o2EMUZ78sdZLSQOthlu3dHorP2/s5oM PikQ== X-Gm-Message-State: APf1xPC+OLnUGAWppiTDWVzVDPQFvGSHBFqZv/qyi+KEAvKBNg6qd3zS GGWMuKDvs3RJub9rYC32UyXgZXXDkjjcgi7Vj1ZMQx5Q X-Google-Smtp-Source: AH8x224bZggSG7dUuS0YAgVIH54cCFA+GpHttNFxiyPrP8sxtWoeWaaj2WtK4Mntjq4qRipx+X9HdfNdFJsh6rUch+k= X-Received: by 10.55.118.6 with SMTP id r6mr10427042qkc.211.1519016098714; Sun, 18 Feb 2018 20:54:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Sun, 18 Feb 2018 20:54:18 -0800 (PST) In-Reply-To: <7317339e-3b4a-bf03-5624-e0d81f5c8a2c@huitema.net> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> <7317339e-3b4a-bf03-5624-e0d81f5c8a2c@huitema.net> From: Eric Rescorla Date: Sun, 18 Feb 2018 20:54:18 -0800 Message-ID: Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) To: Christian Huitema Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c062738f8ece70565897ebb" 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, 19 Feb 2018 04:55:02 -0000 --94eb2c062738f8ece70565897ebb Content-Type: text/plain; charset="UTF-8" On Sun, Feb 18, 2018 at 8:49 PM, Christian Huitema wrote: > On 2/18/2018 8:41 PM, Eric Rescorla wrote: > > > I don't think increasing the on-path attacker's marginal difficulty > > from not requiring any crypto to requiring simple crypto in order to > > mount a DoS attack is worth changing the protocol for. > > Changing the protocol, probably not. But Lingmo's suggestion is one of > the several steps that we could take against hardening against a man on > the side attack. And it is a very simple one: if you receive a VN that > does not contain any acceptable option, just ignore it. If this was > legit, the connection will actually break after a short timer. If it was > not, the next received message will be a Server Hello, and the > connection will progress. Sounds like a reasonable trade-off. > I think it's fine if people do this. I don't think it's worth requiring in the spec given the existence of other trivial man-on-the-side attacks. -Ekr > -- Christian Huitema > > > --94eb2c062738f8ece70565897ebb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Feb 18, 2018 at 8:49 PM, Christian Huitema &l= t;huitema@huitema.= net> wrote:
On 2/18/2018 8:41 PM, Eric Rescorla wrote:

> I don't think increasing the on-path attacker's marginal diffi= culty
> from not requiring any crypto to requiring simple crypto in order to > mount a DoS attack is worth changing the protocol for.

Changing the protocol, probably not. But Lingmo's suggestion is = one of
the several steps that we could take against hardening against a man on
the side attack. And it is a very simple one: if you receive a VN that
does not contain any acceptable option, just ignore it. If this was
legit, the connection will actually break after a short timer. If it was not, the next received message will be a Server Hello, and the
connection will progress. Sounds like a reasonable trade-off.

I think it's fine if people do this. I don't= think it's worth requiring in the spec given the existence of other tr= ivial man-on-the-side attacks.

-Ekr

=

-- Christian Huitema



--94eb2c062738f8ece70565897ebb-- From nobody Mon Feb 19 05:26:49 2018 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 E209412783A for ; Mon, 19 Feb 2018 05:26:47 -0800 (PST) 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, 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 KvJYHlMQVdF3 for ; Mon, 19 Feb 2018 05:26:46 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 B89C71242F7 for ; Mon, 19 Feb 2018 05:26:46 -0800 (PST) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1JDQfbZ029798; Mon, 19 Feb 2018 13:26:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=alzQaKE0EXPgKe+h0SoEhsiKYus3DDdep5oGHr5IqnE=; b=I/j6FWDK+i4/QIfBKnTiuj5CbmJvWbdMB5VQxUX15Z/yVGpXIO+0GiRr7UArWd56Pjtf pQT8v8cO8uvpEdVz/ofViJxh1h1lIairThJkjqHGCFGPZ9pvJdrjq6a7kYdpZEATiT26 1DUayx3/t4tCwNE4Pbww0K/gL4WBhiWIioYmvAmPh1zhqzuFuMij3ylEDijXtSAz7r4s VYF0xWRV4n8C7MA0nee6OrcaX2dTO//aGV0fB+EWX3yKrt0STjpVu525yIIHDw1mv1de spbWCQ7a6TTIDi03p63z8rO0v9aJNKb1omwOP+MF+C5HBdl+Jqg4b8ViAD+lNsfOBYQ3 9w== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2g6chqeheu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 13:26:40 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w1JDQ7Gw000538; Mon, 19 Feb 2018 08:26:39 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2g6gky5g43-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 19 Feb 2018 08:26:39 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb6.msg.corp.akamai.com (172.27.123.54) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Feb 2018 05:26:38 -0800 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 19 Feb 2018 08:26:38 -0500 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; Mon, 19 Feb 2018 08:26:38 -0500 From: "Lubashev, Igor" To: "ekr@rtfm.com" , "huitema@huitema.net" CC: "quic@ietf.org" Subject: RE: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) Thread-Topic: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) Thread-Index: AQHTqM/vqBxMeas2KEOHAIur8pl8/aOqvTUAgACSqgCAAAyYgIAADLoAgAAO/ACAAAHdAIAAAi4AgAABXwCAADtTFQ== Date: Mon, 19 Feb 2018 13:26:37 +0000 Message-ID: <6ec913dc5ecd494eb951ac716e87d40e@usma1ex-dag1mb5.msg.corp.akamai.com> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> <7317339e-3b4a-bf03-5624-e0d81f5c8a2c@huitema.net>, 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 Content-Type: multipart/alternative; boundary="_000_6ec913dc5ecd494eb951ac716e87d40eusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190168 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-19_06:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802190168 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, 19 Feb 2018 13:26:48 -0000 --_000_6ec913dc5ecd494eb951ac716e87d40eusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For clients that have a tcp fallback, this kind of an attack mitigation wou= ld need to be done together with some happy eyeballs race. Otherwise, waiti= ng for a timeout on VN has a real performance cost to the user in case ther= e is no attack happening. So if this kind of an artificial delay in VN is m= entioned, starting the fallback would need to be mentioned as well. All thi= s seems like it could belong to an optimization/applicability/happy-eyeball= s-for-QUIC draft, if it belongs anywhere at all, but not the transport draf= t. -----Original Message----- From: Eric Rescorla [ekr@rtfm.com] Received: Sunday, 18 Feb 2018, 11:55PM To: Christian Huitema [huitema@huitema.net] CC: IETF QUIC WG [quic@ietf.org] Subject: Re: Malicious Version Negotiation Handling (Was: Questions about V= ersion Negotiation Concerning Possible Handshake Interruption) On Sun, Feb 18, 2018 at 8:49 PM, Christian Huitema > wrote: On 2/18/2018 8:41 PM, Eric Rescorla wrote: > I don't think increasing the on-path attacker's marginal difficulty > from not requiring any crypto to requiring simple crypto in order to > mount a DoS attack is worth changing the protocol for. Changing the protocol, probably not. But Lingmo's suggestion is one of the several steps that we could take against hardening against a man on the side attack. And it is a very simple one: if you receive a VN that does not contain any acceptable option, just ignore it. If this was legit, the connection will actually break after a short timer. If it was not, the next received message will be a Server Hello, and the connection will progress. Sounds like a reasonable trade-off. I think it's fine if people do this. I don't think it's worth requiring in = the spec given the existence of other trivial man-on-the-side attacks. -Ekr -- Christian Huitema --_000_6ec913dc5ecd494eb951ac716e87d40eusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable For clients that have a tcp fallback, this kind of an atta= ck mitigation would need to be done together with some happy eyeballs race.= Otherwise, waiting for a timeout on VN has a real performance cost to the user in case there is no attack h= appening. So if this kind of an artificial delay in VN is mentioned, starti= ng the fallback would need to be mentioned as well. All this seems like it = could belong to an optimization/applicability/happy-eyeballs-for-QUIC draft, if it belongs anywhere at all, but not the transport draft.

-----Original Message-----
From: Eric Rescorla [ekr@rtfm.com]
Received: Sunday, 18 Feb 2018, 11:55PM
To: Christian Huitema [huitema@huitema.net]
CC: IETF QUIC WG [quic@ietf.org]
Subject: Re: Malicious Version Negotiation Handling (Was: Questions = about Version Negotiation Concerning Possible Handshake Interruption)


On Sun, Feb 18, 2018 at 8:49 PM, Christian Huite= ma <huitema@huitem= a.net> wrote:
On 2/18/2018 8:41 PM, Eric Rescorla wrote:

> I don't think increasing the on-path attacker's marginal difficulty > from not requiring any crypto to requiring simple crypto in order to > mount a DoS attack is worth changing the protocol for.

Changing the protocol, probably not. But Lingmo's suggestion is one = of
the several steps that we could take against hardening against a man on
the side attack. And it is a very simple one: if you receive a VN that
does not contain any acceptable option, just ignore it. If this was
legit, the connection will actually break after a short timer. If it was not, the next received message will be a Server Hello, and the
connection will progress. Sounds like a reasonable trade-off.

I think it's fine if people do this. I don't think it's worth requirin= g in the spec given the existence of other trivial man-on-the-side attacks.=

-Ekr


-- Christian Huitema



--_000_6ec913dc5ecd494eb951ac716e87d40eusma1exdag1mb5msgcorpak_-- From nobody Mon Feb 19 10:32:44 2018 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 3BAEA1241F5 for ; Mon, 19 Feb 2018 10:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 7RkQHMW8m2m7 for ; Mon, 19 Feb 2018 10:32:40 -0800 (PST) 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 122111204DA for ; Mon, 19 Feb 2018 10:32:33 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1enqEN-0003hz-Gn for quic@ietf.org; Mon, 19 Feb 2018 19:32:06 +0100 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1enqDo-0006EP-TC for quic@ietf.org; Mon, 19 Feb 2018 13:32:00 -0500 Received: (qmail 20556 invoked from network); 19 Feb 2018 18:31:12 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.184]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 19 Feb 2018 18:31:12 -0000 To: "Lubashev, Igor" , "ekr@rtfm.com" Cc: "quic@ietf.org" References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> <7317339e-3b4a-bf03-5624-e0d81f5c8a2c@huitema.net> <6ec913dc5ecd494eb951ac716e87d40e@usma1ex-dag1mb5.msg.corp.akamai.com> From: Christian Huitema Message-ID: <459f4622-bab0-6bdc-8b6c-70e87a0efb97@huitema.net> Date: Mon, 19 Feb 2018 10:31:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <6ec913dc5ecd494eb951ac716e87d40e@usma1ex-dag1mb5.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------2C53FF6901939EBE7B4369EE" Content-Language: en-US Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) X-Originating-IP: 168.144.250.215 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5kbCOyFOHL+iFp4v0H3avfl602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViA6kGGzCqTJNYKxbdT4O/7M7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBiuj1YIZWyGteeTEbAD/lb/vRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0ClKHhIXfDbmhz3DoftFSAfVIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM81CaOu2xwDQxDsUgSvK+nII1IRruUYLOgUnyoTu5lV X1MKVprlQYwN+KHznEQNFP2q+fqyhVlKtogd+v1OOmusOlXPRgr0HlWOaBZW5KERUQfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4CT J7q4QftjYVRI4vivMj6DSGG/BQd7r2NVEaNhWos5pmiO/Py3rZ14nYVGG72TZSAccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtt1Lx8F1uBisuhh9Eb2drX2Bi6owqeb+h1kbxIVWYdC7mWfB wRrxmI1OlqTCPsUGPVeqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g== 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: Mon, 19 Feb 2018 18:32:42 -0000 This is a multi-part message in MIME format. --------------2C53FF6901939EBE7B4369EE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2/19/2018 5:26 AM, Lubashev, Igor wrote: > For clients that have a tcp fallback, this kind of an attack > mitigation would need to be done together with some happy eyeballs > race. Otherwise, waiting for a timeout on VN has a real performance > cost to the user in case there is no attack happening. So if this kind > of an artificial delay in VN is mentioned, starting the fallback would > need to be mentioned as well. All this seems like it could belong to > an optimization/applicability/happy-eyeballs-for-QUIC draft, if it > belongs anywhere at all, but not the transport draft. That's reasonable. Several people have expressed concerns about man-on-the-side attacks. We have heard various proposals for hardening the initial handshake. The typical concern is an adversary "that taps optic fiber at an internet distribution node", to use Mikkel's words, although we may also be concerned by an on-link attacker in an Ethernet or Wi-Fi network. The adversary gets a copy of packets, parses them, and finds a pattern that triggers an attack. The adversary then sends a forged packet to one end of the connection or another, with a goal of causing either a connection failure or a security downgrade. Lingmo Zhu is concerned with a specific variant of this attack, sending a forged version negotiation packet. I think that's a valid concern, but only one of many. We should be equally concerned with forged stateless reset packets, or forged handshake packets: anything that happens before protection is negotiated can be forged.=A0 I would support writing a draf= t that enumerates these attacks, and proposes plausible defenses. -- Christian Huitema --=20 --------------2C53FF6901939EBE7B4369EE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 2/19/2018 5:26 AM, Lubashev, Igor wrote:

For clients that have a tcp fallback, this kind of an attack mitigation would need to be done together with some happy eyeballs race. Otherwise, waiting for a timeout on VN has a real performance cost to the user in case there is no attack happening. So if this kind of an artificial delay in VN is mentioned, starting the fallback would need to be mentioned as well. All this seems like it could belong to an optimization/applicability/happy-eyeballs-for-QUIC draft, if it belongs anywhere at all, but not the transport draft.

That's reasonable. Several people have expressed concerns about man-on-the-side attacks. We have heard various proposals for hardening the initial handshake. The typical concern is an adversary "that taps optic fiber at an internet distribution node", to use Mikkel's words, although we may also be concerned by an on-link attacker in an Ethernet or Wi-Fi network. The adversary gets a copy of packets, parses them, and finds a pattern that triggers an attack. The adversary then sends a forged packet to one end of the connection or another, with a goal of causing either a connection failure or a security downgrade.

Lingmo Zhu is concerned with a specific variant of this attack, sending a forged version negotiation packet. I think that's a valid concern, but only one of many. We should be equally concerned with forged stateless reset packets, or forged handshake packets: anything that happens before protection is negotiated can be forged. I would support writing a draft that enumerates these attacks, and proposes plausible defenses.

-- Christian Huitema

--
--------------2C53FF6901939EBE7B4369EE-- From nobody Mon Feb 19 10:42:15 2018 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 1E28B1241F5 for ; Mon, 19 Feb 2018 10:42:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 m35L2n2gCkqs for ; Mon, 19 Feb 2018 10:42:11 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 C30A51204DA for ; Mon, 19 Feb 2018 10:42:11 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id a203so3269940itd.1 for ; Mon, 19 Feb 2018 10:42:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=/ZS1bh1tUAZn+Dt0FqZInOH9SvSZenkEzDtsluNCsds=; b=uis2c13kX0lGz1LPnmE9cEXLRT//+RAAtYReimuGLaR+iytg0M5GiXmx4P+5FvCYBe Fre795BXGYI5V7w8Nba6WSBB3O6bf5v/xWDMyU44dMKWGXMOazhU2zZ15C69TNH6jlD1 AuDlq6ASeQ7N956SuuvWl/aNIAUMrad9HaOHRYKOr/S/QXf7yKhzcU/QY3oyOUb6yy4r SOammZtWSu9SfPT1Ft4aeSRiJyR/nLsuFKyARc/yTKbuS8/vxDovE9lbfExTyGwhjnHw ZlvvjKfjQDdfEqSDj9gCydZO5/JII7gKRCOTt5WDWZ5tdmeYCgBKlv1hLgWGGgFOhZCS WdSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=/ZS1bh1tUAZn+Dt0FqZInOH9SvSZenkEzDtsluNCsds=; b=HgqWluHtZrk4wlUGTrrGFDNPICvSchOIZXf8aCkOjPz1brqs0xVkINt2LyH+qlpH+4 RDEBsys8c4ZNB5AC0X0tcr55Q8TnGyJ9rXxg19m1Sch5yl1EjSGhUjKDwkiCLNnj4fym TRle2SQRD+xz5jB7nY7wwo2c5P+Ic9CeylCip+IROSKjozkaXYEejTP1uZqdJnGcBwcT L5VQ7sr/QzSYiT9fqZKFCcJ3Ry/l3KObQ4E3+5kIe1qfsIlmAeCTL2xmQq2SMeLXURVT bJhxdwO5i/qY1WVjg57N8ViCg1eVWLOU12UKBe87TqlB+uNoRXw8gd8Z5G/W5bRF7HIM YeWw== X-Gm-Message-State: APf1xPBa94P1I8Zm1vMuUnnHIXCg/ctb4Hv704g0867HKGfpvmzJQ/AL JO5XmAoxoQ1hyTAxrXH2/rM0rSvDzNt2m9Ph7sc= X-Google-Smtp-Source: AH8x2265FElEVy0OGeOi8gbITR7w5fvMBk40c4Vt5AKFrKaFu6e9ZD7r7tD9NChCvn+/dR+yMu+AlcImYsj/t9nRVfc= X-Received: by 10.36.123.198 with SMTP id q189mr21428532itc.118.1519065731159; Mon, 19 Feb 2018 10:42:11 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 19 Feb 2018 10:42:10 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <459f4622-bab0-6bdc-8b6c-70e87a0efb97@huitema.net> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> <7317339e-3b4a-bf03-5624-e0d81f5c8a2c@huitema.net> <6ec913dc5ecd494eb951ac716e87d40e@usma1ex-dag1mb5.msg.corp.akamai.com> <459f4622-bab0-6bdc-8b6c-70e87a0efb97@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 19 Feb 2018 10:42:10 -0800 Message-ID: Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) To: "Lubashev, Igor" , Christian Huitema , "ekr@rtfm.com" Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a114760b24bdd300565950db3" 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, 19 Feb 2018 18:42:13 -0000 --001a114760b24bdd300565950db3 Content-Type: text/plain; charset="UTF-8" Two factor hasn't been mentioned at all - and at first sight it might seem a bit off. However, considering the availability of both auth apps and Fido HW authentication devices, this could be built into the early handshake as an option. On 19 February 2018 at 19.32.46, Christian Huitema (huitema@huitema.net) wrote: On 2/19/2018 5:26 AM, Lubashev, Igor wrote: For clients that have a tcp fallback, this kind of an attack mitigation would need to be done together with some happy eyeballs race. Otherwise, waiting for a timeout on VN has a real performance cost to the user in case there is no attack happening. So if this kind of an artificial delay in VN is mentioned, starting the fallback would need to be mentioned as well. All this seems like it could belong to an optimization/applicability/happy-eyeballs-for-QUIC draft, if it belongs anywhere at all, but not the transport draft. That's reasonable. Several people have expressed concerns about man-on-the-side attacks. We have heard various proposals for hardening the initial handshake. The typical concern is an adversary "that taps optic fiber at an internet distribution node", to use Mikkel's words, although we may also be concerned by an on-link attacker in an Ethernet or Wi-Fi network. The adversary gets a copy of packets, parses them, and finds a pattern that triggers an attack. The adversary then sends a forged packet to one end of the connection or another, with a goal of causing either a connection failure or a security downgrade. Lingmo Zhu is concerned with a specific variant of this attack, sending a forged version negotiation packet. I think that's a valid concern, but only one of many. We should be equally concerned with forged stateless reset packets, or forged handshake packets: anything that happens before protection is negotiated can be forged. I would support writing a draft that enumerates these attacks, and proposes plausible defenses. -- Christian Huitema -- --001a114760b24bdd300565950db3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Two factor hasn'= t been mentioned at all - and at first sight it might seem a bit off.=

However, considering the = availability of both auth apps and Fido HW authentication devices, this cou= ld be built into the early handshake as an option.


On 19 February 2018 at 19.32.46, Christian Huitema (huitema@huitema.net) wrote:

On 2/19/2018 5:26 AM, Lubashev, Igor wrote:

For clients that have a tcp fallback, this kind of an attack mitigation would need to be done together with some happy eyeballs race. Otherwise, waiting for a timeout on VN has a real performance cost to the user in case there is no attack happening. So if this kind of an artificial delay in VN is mentioned, starting the fallback would need to be mentioned as well. All this seems like it could belong to an optimization/applicability/happy-eyeballs-for-QUIC draft, if it belongs anywhere at all, but not the transport draft.

That's reasonable. Several people have expressed concerns about man-on-the-side attacks. We have heard various proposals for hardening the initial handshake. The typical concern is an adversary "that taps optic fiber at an internet distribution node"= ;, to use Mikkel's words, although we may also be concerned by an on-link attacker in an Ethernet or Wi-Fi network. The adversary gets a copy of packets, parses them, and finds a pattern that triggers an attack. The adversary then sends a forged packet to one end of the connection or another, with a goal of causing either a connection failure or a security downgrade.

Lingmo Zhu is concerned with a specific variant of this attack, sending a forged version negotiation packet. I think that's a valid concern, but only one of many. We should be equally concerned with forged stateless reset packets, or forged handshake packets: anything that happens before protection is negotiated can be forged.=C2=A0 I would support writing a draft that enumerates these attacks, and proposes plausible defenses.

-- Christian Huitema

--
--001a114760b24bdd300565950db3-- From nobody Mon Feb 19 11:07:35 2018 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 EE6A7127873 for ; Mon, 19 Feb 2018 11:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 JARRr3dNeY07 for ; Mon, 19 Feb 2018 11:07:26 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 76878127735 for ; Mon, 19 Feb 2018 11:07:26 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id z6so12331837iob.11 for ; Mon, 19 Feb 2018 11:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=qfki32fstucBNTuOLxUW8clKhqDRbfTp+WoJSm+Sp9Q=; b=HH6R2B6mpfzluJ5g4V/J8j3mR6/JnwrTlsbW6neEqPzY2IAtiaM2THO62j0ZFP5TRQ gthvJBsi1rT5fY601M2sV3+gvgAKcebmBylOpZCCOgYglhoKUDIfQ6v+ov8NeXDBshEt AbGg9wmomAcAXsnGN6nsd713GG/cvQKWefC0OsQpSgjx04k3953W0oP5yiMSOENBy0X6 OHtwVI0BeUBRCINZxX034Wtm+UdknNAUlYpSbIkpQWTdD+X9VDU/sFHtPXTU/qL308ao t4zgtykNsDnnlGVU7zvFIArb0mZOGLWsCpsNfD3Jk1f1Hun6IzWaUZY/7uX7aGbqz+A6 IJFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=qfki32fstucBNTuOLxUW8clKhqDRbfTp+WoJSm+Sp9Q=; b=A4dFHXXcX4xRspoHY7gkEEZrVpJ3Flphkx8T+GFWMHup3ZXM24DlrSdWlYwjw7KZj0 SAWpbloWB6HI3KL6Ed8Q8EEoI07wwY2Lb42hu32UZYfjoAkj1FyaGOBqWnoLTD+5M6IV c/OsGft1QWuKbSxYiCh4n4pw95pt/7pbJTTIzFxMrlwGyGXpvgT8NQ8eVXsYO0QVLgHc oAShH1xO8OWEAVbjpJttsyRr+kxq3oeDhkvRkUSOQuWhKp+J+47OYiMzGDkTgOQ70l9s /h7ucgNMb5Vx6yApduZvYUhA6Rclgg1OXWQJqZJsdhtwwd8m7jVfVlAhAtQcGcXlawDl e+qQ== X-Gm-Message-State: APf1xPCF9b94hkEcjAuEOTDgtDYa07llMM03DSRbzBUyYmF+OtpxOBzz CJ16c57qkAqcPs/MC9hPYRcZ1E+2JglWynhTIL5rKw== X-Google-Smtp-Source: AH8x2254kz3PDmhZu7SolgyA0Kc7bUso41EqX9+Gl3425h6a3t1VSftDEb/RwF+xqENCBlgcLDrWXUx9yNLNbLMyrFc= X-Received: by 10.107.212.7 with SMTP id l7mr2296824iog.70.1519067245679; Mon, 19 Feb 2018 11:07:25 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 19 Feb 2018 11:07:24 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 19 Feb 2018 11:07:24 -0800 Message-ID: Subject: Re: Asymmetric CIDs To: Martin Thomson , Ian Swett Cc: Eric Rescorla , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403043d0f88919b6b05659567ef" 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, 19 Feb 2018 19:07:33 -0000 --f403043d0f88919b6b05659567ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t want to shoot down ACID at all, but if a stateless reset is intended to be invisible (not sure why? ossification?, hardly replay?) then it cannot reflect the clients CID because it would light up like a Christmas tree simply because the CID is the same in both directions, unless CID=E2=80=99s are somehow encrypted which would be hard for stateles= s reset. On the other hand, if the reset is intentionally visible, then peer routers could attempt to match the reverse routing path, or do some internal broadcasting find and terminate the relevant destination. Resets should exponentially back off, but that binds state which could be exploited to a degree. Resets could enter a strange ping pong pattern, especially when not routed correctly: B sends reset to A, A does not understand reset and sends a reset to B to silence A, which in turn sends a reset to A. A and B is cluster, so there could be many endpoint in each so back-off would not kick in. As I said before, I=E2=80=99d prefer clients to stop sending when peer is n= ot responding. If a reset is to work, the other end needs to cooperate anyway. Routers could drop packets of unwanted CID=E2=80=99s. This would also handl= e cases where peer receives packets and ACK=E2=80=99s but the return path is broken (eventually timeout will kill, but it could happen faster with a challenge)= . Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 19 February 2018 at 01.30.50, Martin Thomson (martin.thomson@gmail.com) wrote: The breakage of a stateless reset is limited. It is only a problem for clients that use - and depend on - connection IDs. A stateless reset will not carry the client-selected connection ID. It will appear - to the network - to be a change in connection ID. If we change connection IDs occasionally for other reasons, then this won't be a significant problem. The main problem is in ensuring that the packet arrives at the right place at the client. However, it is possible that we can suggest routing based on address tuple over short timescales at clients. In that case, the reset might still arrive at the right place. That, or exceptional processing for unrouteable packets. BTW, I like ekr's idea of making the number space for connection IDs sparse. A (short-ish) fixed limit is necessary to ensure that the stateless reset can be constructed such that it appears plausible and that means at least overhead + max(connection ID) + AEAD expansion + an ACK frame. Would also add the idea of a minimum size for connection IDs. A one octet connection ID has awful linkability properties that are pretty much irredeemable. You can get 8-22 with single octet steps if you are willing to make 1-7 invalid. On Sat, Feb 17, 2018 at 4:25 AM, Ian Swett wrote: > Thanks for the excellent summary EKR. I like this design and think the > breakage of stateless reset in certain cases is acceptable, since it only > applies if both sides must have their preferred connection ID present in > order to route correctly, which is a use case that's impossible in the > status quo. I have not come up with any other downsides. > > On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla wrote: >> >> Hi folks, >> >> After a bunch of discussion, the CID task force came down to rough >> consensus that asymmetric conn IDs were probably the right >> direction (CID task force members, please feel free to voice dissent >> here). Here's a complete writeup of what I think would be needed >> for asymmetric connection IDs. It's not a PR, because I think >> something self-contained is cleaner. >> >> Note that if we adopt this direction, we would be sacrificing >> public reset under some conditions (see previous emails to the >> list) and we would need to decide if it was worth keeping at all. >> >> >> OVERVIEW >> The basic idea is that each side gets to dictate the connection IDs >> that are used to send to it. During the handshake, you establish those >> CIDs and then each side can issue new CIDs during the connection. The >> main advantage of this is that it allows for symmetric topologies in which >> the client is also behind some kind of stateless LB/router rather than >> just the server. See Issue #1091 for more info on this. >> >> >> The overall handshake looks something like this: >> >> Client Server >> >> Initial [CID=3DXXX] {recv-CID=3DYYY} ----------------> >> <-------------- Cleartext [CID=3DYYY] {recv-CID=3DZZZ} >> Cleartext [CID=3DZZZ], {recv-CID=3DYYY} -------------> >> <-------------------------- Short header [CID=3DYYY] >> Short header [CID=3DZZZ] --------------------------> >> >> >> The client's initial CID (XXX) is special, and either consists of >> >> (a) a randomly chosen dummy CID. Proposal: require this to be >> 8 bytes or at least a minimum. This should be the same >> for all Initial packets in a connection (unless a stateless >> reject is received, as below). >> (b) a CID which it received from the server in a stateless reject >> >> All the server's packets are sent with the client's receive CID (YYY) >> and all subsequent client packets are sent with the server's receive >> CID (ZZZ). The general rule is that you should send with the >> connection ID that you most recently received (where recently >> is defined as highest PN). >> >> Note: I believe it's safe to just use the sending CID as the mixin >> for the KDF, but I haven't thought this entirely through yet. >> >> Finally, you can send NEW_CONNECTION_ID in either direction to provide >> a new connection ID for the other side to use. The general assumption >> is that you can do this at any time, just as with current QUIC, and >> that any time you send to a new remote 3-tuple you should change CIDs >> if you can. Note that this means that endpoints should try to make >> sure that the other side has spare CIDs in case they need to migrate. >> >> >> WIRE ENCODING >> As we discussed in the meeting the short header should just have >> an implicit length CID. This gives us the following short header: >> >> +-+-+-+-+-+-+-+-+ >> |0|C|K| Type (5)| >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + [Connection ID (*)] + <- >> change from 64 >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Packet Number (8/16/32) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Protected Payload (*) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> Note that we may also be able to dispense with the C bit, if each >> side just gets to say "send me this CID exactly", why do we want >> to say "here is my CID but you can omit it". >> >> >> We have several options about the long header. The first question >> is where recv-CIDs go. In previous versions I suggested putting >> them in transport parameters, or elsewhere in the TLS handshake, >> and that might still be viable, though it has some drawbacks [0], >> so the other alternative is to put both CIDs in in the long header. >> This would look something like: >> >> +-+-+-+-+-+-+-+-+ >> |1| Type (7) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | DCID-Length | | >> +-+-+-+-+-+-+-+-+ Dst Connection ID (*) + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | SCID-Length | | >> +-+-+-+-+-+-+-+-+ Src Connection ID (*) + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Version (32) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Packet Number (32) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload (*) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> The semantics here are that the first value is the CID you want to >> send to and the second one is the value you want used to send to you >> (I've inverted these to keep the order the same as short header). >> >> Two notes about this encoding: >> >> 1. I think we agreed that we didn't want arbitrary length CIDs up to >> 255 bytes, and yet we have room in this length byte. I propose we >> limit it to 31 bytes and then grease the remaining 3 bits [1]. >> >> 2. Because the client sends its CID first, there's no way to get the >> current QUIC semantics of the server just dictates the CID. I propose >> we fix that by defining a special sentinel CID (all 1s, all 0s, >> whatever) of whatever our maximum length is that means "just use your >> own CID". >> >> We can endlessly bikeshed on this structure. >> >> >> Finally, we will need to update NEW_CONNECTION_ID to allow a variable >> length CID. This would look like this: >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Sequence (i) ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | CID-Length | | >> +-+-+-+-+-+-+-+-+ Connection ID (*) + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + + >> | | >> + Stateless Reset Token (128) + >> | | >> + + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> >> [0] However, in the transport parameters design, if the server's >> handshake gets reordered, the client might need to send some ACKs with >> the initial CID. However, we've agreed that the client's IP address >> has to be stable, so this isn't a problem. Alternately, you could >> change C->S CIDs in the short header if that was easier. >> >> [1] An alternative would be to have a sparse range (e.g., you can >> express 0-7 and then 8-22 by 2s, assuming I have counted correctly) >> and then we could pack both lengths into a single byte. As I said, >> lots of opportunities for bikeshedding here. >> > --f403043d0f88919b6b05659567ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I don=E2=80=99t want= to shoot down ACID at all, but if a stateless reset is intended to be invi= sible (not sure why? ossification?, hardly replay?) then it cannot reflect = the clients CID because it would light up like a Christmas tree simply beca= use the CID is the same in both directions, unless CID=E2=80=99s are someho= w encrypted which would be hard for stateless reset.=C2=A0

On the other hand, if the reset is in= tentionally visible, then peer routers could attempt to match the reverse r= outing path, or do some internal broadcasting find and terminate the releva= nt destination.

Reset= s should exponentially back off, but that binds state which could be exploi= ted to a degree.

Rese= ts could enter a strange ping pong pattern, especially when not routed corr= ectly: B sends reset to A, A does not understand reset and sends a reset to= B to silence A, which in turn sends a reset to A.

A and B is cluster, so there could be many en= dpoint in each so back-off would not kick in.

As I said before, I=E2=80=99d prefer clients to st= op sending when peer is not responding. If a reset is to work, the other en= d needs to cooperate anyway. Routers could drop packets of unwanted CID=E2= =80=99s. This would also handle cases where peer receives packets and ACK= =E2=80=99s but the return path is broken (eventually timeout will kill, but= it could happen faster with a challenge).

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

=

On 19 February 2018 at 01.30.50, Martin = Thomson (martin.thomson@gmail.c= om) wrote:

=
The breakage of a stateless reset is limited. It is only a= problem
for clients that use - and depend on - connection IDs.

A stateless reset will not carry the client-selected connection ID.
It will appear - to the network - to be a change in connection ID. If
we change connection IDs occasionally for other reasons, then this
won't be a significant problem.

The main problem is in ensuring that the packet arrives at the right
place at the client. However, it is possible that we can suggest
routing based on address tuple over short timescales at clients. In
that case, the reset might still arrive at the right place. That, or
exceptional processing for unrouteable packets.

BTW, I like ekr's idea of making the number space for connection ID= s
sparse. A (short-ish) fixed limit is necessary to ensure that the
stateless reset can be constructed such that it appears plausible and
that means at least overhead + max(connection ID) + AEAD expansion +
an ACK frame.

Would also add the idea of a minimum size for connection IDs. A one
octet connection ID has awful linkability properties that are pretty
much irredeemable. You can get 8-22 with single octet steps if you
are willing to make 1-7 invalid.


On Sat, Feb 17, 2018 at 4:25 AM, Ian Swett <ianswett@google.com> wrote:
> Thanks for the excellent summary EKR. I like this design and thin= k the
> breakage of stateless reset in certain cases is acceptable, since = it only
> applies if both sides must have their preferred connection ID pres= ent in
> order to route correctly, which is a use case that's impossibl= e in the
> status quo. I have not come up with any other downsides.
>
> On Fri, Feb 16, 2018 at 12:01 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> Hi folks,
>>
>> After a bunch of discussion, the CID task force came down to r= ough
>> consensus that asymmetric conn IDs were probably the right
>> direction (CID task force members, please feel free to voice d= issent
>> here). Here's a complete writeup of what I think would be = needed
>> for asymmetric connection IDs. It's not a PR, because I th= ink
>> something self-contained is cleaner.
>>
>> Note that if we adopt this direction, we would be sacrificing
>> public reset under some conditions (see previous emails to the
>> list) and we would need to decide if it was worth keeping at a= ll.
>>
>>
>> OVERVIEW
>> The basic idea is that each side gets to dictate the connectio= n IDs
>> that are used to send to it. During the handshake, you establi= sh those
>> CIDs and then each side can issue new CIDs during the connecti= on. The
>> main advantage of this is that it allows for symmetric topolog= ies in which
>> the client is also behind some kind of stateless LB/router rat= her than
>> just the server. See Issue #1091 for more info on this.
>>
>>
>> The overall handshake looks something like this:
>>
>> Client Server
>>
>> Initial [CID=3DXXX] {recv-CID=3DYYY} ---------------->
>> <-------------- Cleartext [CID=3DYYY] {recv-CID=3DZZZ}
>> Cleartext [CID=3DZZZ], {recv-CID=3DYYY} ------------->
>> <-------------------------- Short header [CID=3DYYY]
>> Short header [CID=3DZZZ] -------------------------->
>>
>>
>> The client's initial CID (XXX) is special, and either cons= ists of
>>
>> (a) a randomly chosen dummy CID. Proposal: require this to= be
>> 8 bytes or at least a minimum. This should be the same
>> for all Initial packets in a connection (unless a stat= eless
>> reject is received, as below).
>> (b) a CID which it received from the server in a stateless= reject
>>
>> All the server's packets are sent with the client's re= ceive CID (YYY)
>> and all subsequent client packets are sent with the server'= ;s receive
>> CID (ZZZ). The general rule is that you should send with the
>> connection ID that you most recently received (where recently
>> is defined as highest PN).
>>
>> Note: I believe it's safe to just use the sending CID as t= he mixin
>> for the KDF, but I haven't thought this entirely through y= et.
>>
>> Finally, you can send NEW_CONNECTION_ID in either direction to= provide
>> a new connection ID for the other side to use. The general ass= umption
>> is that you can do this at any time, just as with current QUIC= , and
>> that any time you send to a new remote 3-tuple you should chan= ge CIDs
>> if you can. Note that this means that endpoints should try to = make
>> sure that the other side has spare CIDs in case they need to m= igrate.
>>
>>
>> WIRE ENCODING
>> As we discussed in the meeting the short header should just ha= ve
>> an implicit length CID. This gives us the following short head= er:
>>
>> +-+-+-+-+-+-+-+-+
>> |0|C|K| Type (5)|
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | = |
>> + [Connection ID (*)] = + <-
>> change from 64
>> | = |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | Packet Number (8/16/32) = ...
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | Protected Payload (*) = ...
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>>
>> Note that we may also be able to dispense with the C bit, if e= ach
>> side just gets to say "send me this CID exactly", wh= y do we want
>> to say "here is my CID but you can omit it".
>>
>>
>> We have several options about the long header. The first quest= ion
>> is where recv-CIDs go. In previous versions I suggested puttin= g
>> them in transport parameters, or elsewhere in the TLS handshak= e,
>> and that might still be viable, though it has some drawbacks [= 0],
>> so the other alternative is to put both CIDs in in the long he= ader.
>> This would look something like:
>>
>> +-+-+-+-+-+-+-+-+
>> |1| Type (7) |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | DCID-Length | = |
>> +-+-+-+-+-+-+-+-+ Dst Connection ID (*) = +
>> | = |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | SCID-Length | = |
>> +-+-+-+-+-+-+-+-+ Src Connection ID (*) = +
>> | = |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | Version (32) = |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | Packet Number (32) = |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | Payload (*) = ...
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>>
>> The semantics here are that the first value is the CID you wan= t to
>> send to and the second one is the value you want used to send = to you
>> (I've inverted these to keep the order the same as short h= eader).
>>
>> Two notes about this encoding:
>>
>> 1. I think we agreed that we didn't want arbitrary length = CIDs up to
>> 255 bytes, and yet we have room in this length byte. I propose= we
>> limit it to 31 bytes and then grease the remaining 3 bits [1].
>>
>> 2. Because the client sends its CID first, there's no way = to get the
>> current QUIC semantics of the server just dictates the CID. I= propose
>> we fix that by defining a special sentinel CID (all 1s, all 0s= ,
>> whatever) of whatever our maximum length is that means "j= ust use your
>> own CID".
>>
>> We can endlessly bikeshed on this structure.
>>
>>
>> Finally, we will need to update NEW_CONNECTION_ID to allow a v= ariable
>> length CID. This would look like this:
>>
>> 0 1 2 = 3
>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 = 9 0 1
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | Sequence (i) = ...
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | CID-Length | = |
>> +-+-+-+-+-+-+-+-+ Connection ID (*) = +
>> | = |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>> | = |
>> + = +
>> | = |
>> + Stateless Reset Token (128) = +
>> | = |
>> + = +
>> | = |
>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
>>
>>
>>
>> [0] However, in the transport parameters design, if the server= 's
>> handshake gets reordered, the client might need to send some A= CKs with
>> the initial CID. However, we've agreed that the client'= ;s IP address
>> has to be stable, so this isn't a problem. Alternately, yo= u could
>> change C->S CIDs in the short header if that was easier.
>>
>> [1] An alternative would be to have a sparse range (e.g., you = can
>> express 0-7 and then 8-22 by 2s, assuming I have counted corre= ctly)
>> and then we could pack both lengths into a single byte. As I s= aid,
>> lots of opportunities for bikeshedding here.
>>
>

--f403043d0f88919b6b05659567ef-- From nobody Mon Feb 19 22:56:31 2018 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 2E24B126DC2 for ; Mon, 19 Feb 2018 22:56:30 -0800 (PST) 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 weczR3E9qZrm for ; Mon, 19 Feb 2018 22:56:29 -0800 (PST) Received: from mail-pl0-x22f.google.com (mail-pl0-x22f.google.com [IPv6:2607:f8b0:400e:c01::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 03909124235 for ; Mon, 19 Feb 2018 22:56:29 -0800 (PST) Received: by mail-pl0-x22f.google.com with SMTP id p5so6963431plo.12 for ; Mon, 19 Feb 2018 22:56:28 -0800 (PST) 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=AZ9GXsl7M3zKTpZlgOzUBtWJ/d5YpTTDaAVyjtwReCI=; b=n91ALvRozBebyDKSzoXgN6ZGJNIjelH2cVzDs/kuY01FpG046pSORklzzf/ks7sAgJ WLHP95GU1ebnWFe89KlgExYhkmKdKehAdmuiqkK+JFoWuHYr1qc1PPvL84A1MBHwQe3M KN/qyZARxXDRV6mrnSt1WIw4RBBQU9l3vlPYMr6tUL82+1op4sVD4y9iiWoggHUDeQJs pawUQoUkkO4Lqpx2ARZPyj776IRhFAC57ULDqu7b2D8T8P0cXNBojmKB+0ZMPIf7QxHl N0rlSZKCQ3RwPoCGp6bHWBcCxJkT5FVkV5jTm867ERPcdm6vo4oRynZJQZ83LUu466Cr VLPw== 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=AZ9GXsl7M3zKTpZlgOzUBtWJ/d5YpTTDaAVyjtwReCI=; b=URVxtr2LX7zaBzSCih0iI3kKf/8CBpFpdnRgV+yZXbKYxIBA3Ms1hAn5pPLmpdvIug Mn4PDfKO2TrQRiUBEBoAYoaKVBp0X9Nv71zX7NFZg0YSvhTxbtI1EDwU7yWy5Pql9+VH aiMxZ5B+gswXbviTLUBjKj8d1g7u//GLfiOrpaGPp1zNwDE9xS9bbuYv6Y69nrzxryi/ rEbfXt/FZDlabQ7eqpTlaNnYfWniJne/MQDniNWmLBGghOdO1kRthhx+zhP49ffjlGMt 4/8/02htXCmRxhXTNYSHtfLeQAXEUBieKl6GDPqEn8PcTItpOu6k+bZdDACC5oFZYPcL OYZw== X-Gm-Message-State: APf1xPC4mrOKcp02IJXabe2idS/h3t4xG6OfSw1IZPaGGLRjKGOlkcym 52pAonJXXUzpe+PSsr6/Gjhrj4yjVXL0yGK79QY= X-Google-Smtp-Source: AH8x224g+CpyVNwT39qfdlTc02tx8XMAUV1oQ53ep7Dt4V8eiWnxMde5VczXEJItUNewdw0Y2o6jdVMYWHicYy48V8Y= X-Received: by 2002:a17:902:6e8c:: with SMTP id v12-v6mr16474230plk.424.1519109788521; Mon, 19 Feb 2018 22:56:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.189.151 with HTTP; Mon, 19 Feb 2018 22:56:28 -0800 (PST) In-Reply-To: References: <4282f0ed-1b0e-3b18-598f-4385481ebd86@huitema.net> From: Kazuho Oku Date: Tue, 20 Feb 2018 15:56:28 +0900 Message-ID: Subject: Re: Asymmetric CIDs To: Ian Swett Cc: Nick Banks , Eric Rescorla , IETF QUIC WG , huitema , Roberto Peon , Martin Duke 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, 20 Feb 2018 06:56:30 -0000 2018-02-17 7:45 GMT+09:00 Ian Swett : > I agree that could be a concern, but I think it's no more difficult to solve > than the status quo. It just means both sides need to have more connection > IDs, not just one side. > > Nick's solution is a good suggestion, but one can also imagine cases when > other connection IDs have previously been made available. Another approach will be to use the first N octets of the stateless reset token (provided by the server) as the connection ID. For example, if the stateless reset token is 00 01 02 03 04 ... 7f, and if the length of the CID is 4 octets, the server will use 00 01 02 03 as the CID and 04..7f as the payload of a stateless reset. > In practice, for most of the cases we're discussing, I'm expecting the > connection ID from server to client will be 0 bytes in length, making this a > non-issue. Agreed. -- Kazuho Oku From nobody Tue Feb 20 03:53:25 2018 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 0CEF012711D for ; Tue, 20 Feb 2018 03:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 tLxD5OHhQkFw for ; Tue, 20 Feb 2018 03:53:22 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 CED9212706D for ; Tue, 20 Feb 2018 03:53:21 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id y190-v6so1964386yba.12 for ; Tue, 20 Feb 2018 03:53:21 -0800 (PST) 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=baU8Df4Tpl5E0o/m4bUr3I07qCXvKXW8E4apEi0k6/w=; b=NWX4TWbWf4TFsDaWimlO2MI+fVyeqM9dcXqte5jJ3jWBm+AthkB2m4LoEO8rQcjnrW DpdrQW8mFat5XuXMnXeFN4RdJCXL31IQ0i4jq3iOeTzC5vqCBIgs0yRKHhn0BEmRoUnY DIhuVvbXr2dwvUYOvhXuNYqdl0lXNe2K3YOuuEewVzmNqhteAHbQ4kvnbNRQADpiN5oJ kmmFnXEGiHEuo99x56TKhJaeSW7GQr6sA6iVxAVNKvlq0ZFC34XSMB7wuCTh+jIM/3pQ tusY6qxdZOy8ICkMsVAH4K8kJTXjobUCtoZVEavpVV2yl2p1XY9mRLZwVBCTYGh/Xjv8 UNMw== 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=baU8Df4Tpl5E0o/m4bUr3I07qCXvKXW8E4apEi0k6/w=; b=n/E499f2C71YUHI9hISZNxJnY36bbFR5+9w7ArAypdA06sJDgOMFkLxn+rNHcKzeeO Skhn0RyqG0ROfLHRNW7kTM/eDgfXG14d0PKqB+KmybNbR83U9AruUhlYgnXiL9Hibcog De787ueBt/l2r102gH4CRi9kgAdCmUVoKO7tCuMZ6kD6Rj54H5p2zBLpmfsLBiGSrD5H k4l7Ukv3FaNKkYIwPrneid4pJsCcwvrlPcbgFcxFk3gwrQULNNCDzX+b8nAVfTXMEkIs Sn4xAvtKCYj6sF8XAvbAaPYAmgeTekjf17jokzUW8av1HAi5I6FFZqNd0CyUgSRVTeaY EcGg== X-Gm-Message-State: APf1xPDRoTw6PnJoN7x9eNtVQtS2ZD1v4eNCriBX1DnRWoZrDwBWHrfU 1UtFYDweB92lOwmM3Ku6DA5ol2d8F5y15kGA35I= X-Google-Smtp-Source: AH8x225GIFFrKcdfWiv30/gs0FtxZJme3K1SHzx4UyYDVnmi7LEurRvVmKQbIzjVHm9VEbJpDcbd3b4RJlc14mBVljo= X-Received: by 10.37.99.194 with SMTP id x185mr12501963ybb.471.1519127600852; Tue, 20 Feb 2018 03:53:20 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a25:15c9:0:0:0:0:0 with HTTP; Tue, 20 Feb 2018 03:53:20 -0800 (PST) In-Reply-To: <6ec913dc5ecd494eb951ac716e87d40e@usma1ex-dag1mb5.msg.corp.akamai.com> References: <1d386744-c46a-842a-b172-24e290e03668@gmail.com> <3d558827-f2a7-877c-e00a-d6a22ef241c5@gmail.com> <142211e0-c7c9-642f-69ef-5f0d722b77cc@gmail.com> <529ac475-5291-2b2e-acf9-05efe720d584@huitema.net> <6937_1518251684_5A7EAEA4_6937_191_1_5A7EAEA5.2000605@orange.com> <835e5014-3306-e7ac-fed0-3c90320551a9@gmail.com> <7317339e-3b4a-bf03-5624-e0d81f5c8a2c@huitema.net> <6ec913dc5ecd494eb951ac716e87d40e@usma1ex-dag1mb5.msg.corp.akamai.com> From: Spencer Dawkins at IETF Date: Tue, 20 Feb 2018 06:53:20 -0500 Message-ID: Subject: Re: Malicious Version Negotiation Handling (Was: Questions about Version Negotiation Concerning Possible Handshake Interruption) To: "Lubashev, Igor" Cc: "ekr@rtfm.com" , "huitema@huitema.net" , "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a11c148660473b10565a375e1" 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, 20 Feb 2018 11:53:24 -0000 --001a11c148660473b10565a375e1 Content-Type: text/plain; charset="UTF-8" Replying with no hats ... On Mon, Feb 19, 2018 at 8:26 AM, Lubashev, Igor wrote: > For clients that have a tcp fallback, this kind of an attack mitigation > would need to be done together with some happy eyeballs race. Otherwise, > waiting for a timeout on VN has a real performance cost to the user in case > there is no attack happening. > I don't understand this. Is your thinking that the attacker would send a forged VN packet AND drop the server's response? If so, that does make sense, but if that's not part of the scenario, I don't know why the client wouldn't drop the forged "no acceptable version numbers" packet and accept the server's packet, at roughly the same point in time where there would have accepted the server's packet if there was no attack. Are we talking about the same thing? (To be clear, I don't have an opinion about what the working group decides, but I do want to understand what's being discussed) Thanks, Spencer > So if this kind of an artificial delay in VN is mentioned, starting the > fallback would need to be mentioned as well. All this seems like it could > belong to an optimization/applicability/happy-eyeballs-for-QUIC draft, if > it belongs anywhere at all, but not the transport draft. > > > -----Original Message----- > *From:* Eric Rescorla [ekr@rtfm.com] > *Received:* Sunday, 18 Feb 2018, 11:55PM > *To:* Christian Huitema [huitema@huitema.net] > *CC:* IETF QUIC WG [quic@ietf.org] > *Subject:* Re: Malicious Version Negotiation Handling (Was: Questions > about Version Negotiation Concerning Possible Handshake Interruption) > > > > On Sun, Feb 18, 2018 at 8:49 PM, Christian Huitema > wrote: > >> On 2/18/2018 8:41 PM, Eric Rescorla wrote: >> >> > I don't think increasing the on-path attacker's marginal difficulty >> > from not requiring any crypto to requiring simple crypto in order to >> > mount a DoS attack is worth changing the protocol for. >> >> Changing the protocol, probably not. But Lingmo's suggestion is one of >> the several steps that we could take against hardening against a man on >> the side attack. And it is a very simple one: if you receive a VN that >> does not contain any acceptable option, just ignore it. If this was >> legit, the connection will actually break after a short timer. If it was >> not, the next received message will be a Server Hello, and the >> connection will progress. Sounds like a reasonable trade-off. >> > > I think it's fine if people do this. I don't think it's worth requiring in > the spec given the existence of other trivial man-on-the-side attacks. > > -Ekr > > >> -- Christian Huitema >> >> >> > --001a11c148660473b10565a375e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Replying with no hats ...

On Mon, Feb 19, 2018 at 8:26 AM, Lubashev, Igor <ilubashe@akamai.com> wrote:
For clients that have a tcp fallback, this kind of an attack= mitigation would need to be done together with some happy eyeballs race. O= therwise, waiting for a timeout on VN has a real performance cost to the user in case there is no attack h= appening.

I don't underst= and this. Is your thinking that the attacker would send a forged VN packet = AND drop the server's response?=C2=A0

If so, t= hat does make sense, but if that's not part of the scenario, I don'= t know why the client wouldn't drop the forged "no acceptable vers= ion numbers" packet and accept the server's packet, at roughly the= same point in time where there would have accepted the server's packet= if there was no attack.

Are we talking about the = same thing?=C2=A0

(To be clear, I don't have a= n opinion about what the working group decides, but I do want to understand= what's being discussed)

Thanks,
Spencer
=C2=A0
So if this kind of an artificial delay in VN is mentioned= , starting the fallback would need to be mentioned as well. All this seems = like it could belong to an optimization/applicability/happy-eyeballs-f= or-QUIC draft, if it belongs anywhere at all, but not the transport draft.


-----Original Message-----
From: Eric Rescorla [ekr@rtfm.com]
Received: Sunday, 18 Feb 2018, 11:55PM
To: Christian Huitema [huitema@huitema.net]
CC: IETF QUIC WG [quic@ietf.org]
Subject: Re: Malicious Version Negotiation Handling (Was: Questions = about Version Negotiation Concerning Possible Handshake Interruption)



On Sun, Feb 18, 2018 at 8:49 PM, Christian Huite= ma <huitema@huitem= a.net> wrote:
On 2/18/2018 8:41 PM, Eric Rescorla wrote:

> I don't think increasing the on-path attacker's marginal diffi= culty
> from not requiring any crypto to requiring simple crypto in order to > mount a DoS attack is worth changing the protocol for.

Changing the protocol, probably not. But Lingmo's suggestion is = one of
the several steps that we could take against hardening against a man on
the side attack. And it is a very simple one: if you receive a VN that
does not contain any acceptable option, just ignore it. If this was
legit, the connection will actually break after a short timer. If it was not, the next received message will be a Server Hello, and the
connection will progress. Sounds like a reasonable trade-off.

I think it's fine if people do this. I don't think it's wo= rth requiring in the spec given the existence of other trivial man-on-the-s= ide attacks.

-Ekr


-- Christian Huitema




--001a11c148660473b10565a375e1-- From nobody Tue Feb 20 14:20:58 2018 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 A0447126579; Tue, 20 Feb 2018 14:20:52 -0800 (PST) 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-qcram-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151916525260.9811.18307160669233724920@ietfa.amsl.com> Date: Tue, 20 Feb 2018 14:20:52 -0800 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: Tue, 20 Feb 2018 22:20:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Header Compression for HTTP over QUIC Authors : Charles 'Buck' Krasic Mike Bishop Alan Frindell Filename : draft-ietf-quic-qcram-00.txt Pages : 11 Date : 2018-02-20 Abstract: The design of the core QUIC transport subsumes many HTTP/2 features, prominent among them stream multiplexing. A key advantage of the QUIC transport is stream multiplexing free of head-of-line (HoL) blocking between streams. In HTTP/2, multiplexed streams can suffer HoL blocking due to TCP. If HTTP/2's HPACK is used for header compression, HTTP/QUIC is still vulnerable to HoL blocking, because of HPACK's assumption of in-order delivery. This draft defines QCRAM, a variation of HPACK and mechanisms in the HTTP/QUIC mapping that allow the flexibility to avoid header-compression-induced HoL blocking. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-qcram/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-qcram-00 https://datatracker.ietf.org/doc/html/draft-ietf-quic-qcram-00 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 Tue Feb 20 17:00:44 2018 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 0008B12E85B for ; Tue, 20 Feb 2018 17:00:43 -0800 (PST) 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 klGv2bF-tTo0 for ; Tue, 20 Feb 2018 17:00:41 -0800 (PST) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 8022A12E76A for ; Tue, 20 Feb 2018 17:00:41 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id j79so7182507oib.12 for ; Tue, 20 Feb 2018 17:00:41 -0800 (PST) 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=g7SDyM16WyO73EwKlJIvSD+LahM1YPm7aSdPp9US938=; b=PFpsQhgD2R9C6T5iW3kIjekattVuJAMuof0Ami2LzUN2kRb0Z1r9SRYcmKCajxBqTE G3YyQTPaZX21kwXj35Fd81dslMuoDb2y8udoNMqOJPvP7wh9oOegwHCKZc15DKyRLYiz 7oE2q/bFjelm9nnvEzQ6b4u2ac0EYCJxkmyNTcte5ICH7uVnPLUjhykFmWYw974AKrY6 vhJ0cR0eONCWBChNKYH4YRV00cql+nA3BERBWuODPAqVVnQk/lsw4oKQePoteP+CL7IE G9AyzYxIp5aX4Wnjf0VxjKwz75c3rnks3FjzuNt/UN/5K3UmIHrO3Y9IK0C+qs02FgVv Iv7g== 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=g7SDyM16WyO73EwKlJIvSD+LahM1YPm7aSdPp9US938=; b=lmD1FHweLcM9+dhyN2hdEIS9tY/fF9/qeD1KZBNX64U2KgjrneCHXl5jF58qovHExY rA1oHJGt9v9vl7ho9ctCRMsdA+wW6i8wMquQoFKYsS6iAiOsZJs42rAFAoLBpGeuf78l 8LRWq4TAGPfMohtj0MpHeoFIqd0qtjRimxoSwr+79eAuoK0+FCI9DkpFQTGFXqo/meDp QkidPvf7LL3Ooy+PFdM0mbxk8gGm7CDApZx1ZyB2xzc3mDd4KIsaH32B6CQmCIKYqIYA IKS+yrAbxErXRP2yYKkVcM0Bxo8fQY0psHD46NaPu+a6KX2f/8fGq3gdYb6iQlpfsYeG NwtQ== X-Gm-Message-State: APf1xPCjt+WPnGXZLsHclyviArmntJH2YcOT2P8TwRoPqw9o4PjOAcuA oYOBAwxMK22LHjLwdrahqAfh3eqoT8HZ5GsR0rTdBw== X-Google-Smtp-Source: AG47ELsQZhYpcBJMBx3awtzAFdE5Asc03daYBhbDJ4ioV/T4gWAo+2dh5IHEDd9uMA70dBgAEamaqMosRj5p5wVnTgo= X-Received: by 10.202.94.196 with SMTP id s187mr983470oib.144.1519174840462; Tue, 20 Feb 2018 17:00:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Tue, 20 Feb 2018 17:00:40 -0800 (PST) From: Martin Thomson Date: Wed, 21 Feb 2018 12:00:40 +1100 Message-ID: Subject: Who wants -10 drafts? 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, 21 Feb 2018 01:00:44 -0000 I know, I know, you are probably still struggling your way through interop with -09, but the editors want to know if people want a set of drafts that reference the newly added QCRAM and invariants docs. There would be no change to interop targets. We were originally hoping to include fixes to the bigger open issues, but those seem unlikely to resolve in time for the March 5 draft submission cutoff. And now there might be some people who want to try out hq-10 now that it has a plausible header compression story. From nobody Tue Feb 20 17:36:13 2018 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 A82DC120227 for ; Tue, 20 Feb 2018 17:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.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 yKWdCxvyP3ge for ; Tue, 20 Feb 2018 17:36:11 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (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 9193D1200F1 for ; Tue, 20 Feb 2018 17:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1519176971; x=2383090571; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=tKPlA2ZH5hbX5+Y446ktQViHO6jZd6mKDBpysumMK2c=; b=3vNaWFZAitgXPOa83tiJPBv8JJoAn7QpibNIZHUwihDmW2ALv6cCMAhHomuce6wc Rua5QaP0LNS+ypQrmzDR1UX0twgbjBd/KKEXtLVKC/MF625sFc4u4mvx1Jk1OxN6 HIcMp7oB+UZYOMyAtRDPcqq45MNctWKIckLEDtJ4pL18V9A+dAeUidnBvtosB7+/ ZTdB3OSEkMzIjySOHaPGbRvH+DfHpDYR5F7ClcAmgVOYw7F2Wpy7mjKJaFRkTkNl Pm+41bYEQM51AleDUOvnDOqiVZ04vhOPTgKKkImDCfOB58X7dGEfhCcDzk+jRWT+ H/cYIpzy1JHYXZSiXB3o0Q==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id F3.CC.13704.B0DCC8A5; Tue, 20 Feb 2018 17:36:11 -0800 (PST) X-AuditID: 11973e13-ee5ff70000003588-a3-5a8ccd0bc1f3 Received: from nwk-mmpp-sz09.apple.com (nwk-mmpp-sz09.apple.com [17.128.115.80]) by relay8.apple.com (Apple SCV relay) with SMTP id 17.AF.10701.B0DCC8A5; Tue, 20 Feb 2018 17:36:11 -0800 (PST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.192.155.216] by nwk-mmpp-sz09.apple.com (Oracle Communications Messaging Server 8.0.2.2.20180130 64bit (built Jan 30 2018)) with ESMTPSA id <0P4H00DKD8GAS270@nwk-mmpp-sz09.apple.com>; Tue, 20 Feb 2018 17:36:11 -0800 (PST) Sender: rpaulo@apple.com Subject: Re: Who wants -10 drafts? From: Rui Paulo In-reply-to: Date: Tue, 20 Feb 2018 17:36:10 -0800 Cc: QUIC WG Content-transfer-encoding: quoted-printable Message-id: <4A74CD08-00C9-451A-80E8-E6AD7F644DED@apple.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.3445.6.14) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUi2FCYpst9tifKoOEBn8W1M/8YLXoWcDsw eeycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGY3du9kK7rNX/GlYzdjA2M3WxcjBISFgIrHr ZUEXIxeHkMAaJomOWb/Yuxg5weLXWt+xQCQOMkp0npjDCJLgFRCU+DH5HgtIM7OAusSUKbkQ Nd8YJaas3c8KUiMsICGx/+RDdghbSWLJo9lMIDYbkP2s7wQ7SC+nQLDElV92IGEWAVWJB9M+ sYDYzALSEmcnrYWytSWevLvACrHWRuL0/yY2EFtIIEDi2p8LYONFBHQlFp19AHWzksSWxv+s IPdICPxkldg9YwrzBEbhWUjOnoVw9iwkKxYwMq9iFMpNzMzRzcwz1UssKMhJ1UvOz93ECArq 6XbCOxhPr7I6xCjAwajEw2uh0xMlxJpYVlyZe4hRmoNFSZzXbydQSCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUA2PMXfFnd2cHpl9cGaf/O/j0r8nm2ukT+8P/6vpseOqxNCVxts68Z6e/LnH6 Ye/WbHX3ts8qb+srBUGLZU33LNvfcrs3cs+h/6lMq8UME+fz8Aeztx78rlPQIBl25oXF7huc Z80eF09tkf98y4cxTaxvbllX3lSF+tgXgZzcPy7wFk++9SE/ZYISS3FGoqEWc1FxIgAJ0Bim SwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUi2FAcoMt9tifK4Hg3j8W1M/8YLXoWcDsw eeycdZfdY8mSn0wBTFFcNimpOZllqUX6dglcGY3du9kK7rNX/GlYzdjA2M3WxcjJISFgInGt 9R1LFyMXh5DAQUaJzhNzGEESvAKCEj8m3wNKcHAwC6hLTJmSC1HzjVFiytr9rCA1wgISEvtP PmSHsJUkljyazQRiswHZz/pOsIP0cgoES1z5ZQcSZhFQlXgw7RMLiM0sIC1xdtJaKFtb4sm7 C6wQa20kTv9vArtNSCBA4tqfC2DjRQR0JRadfcAOcbOSxJbG/6wTGAVmIbl0FsKls5BMXcDI vIpRoCg1J7HSQi+xoCAnVS85P3cTIzgMC9N2MDYttzrEKMDBqMTDa6HTEyXEmlhWXJl7iFGC g1lJhPfy9+4oId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz+e4GqBdITS1KzU1MLUotgskwcnFIN jD12y1dM7vSXbZsp0PNS+H/9hQbxP732d+JX811YGiR788p9pzMTvyqJSuh3qPzhqg1n1rnL X7f0eUs++wf9sIU3blg57ZR5/PuAfeHFxr/v1JbrLOwLE1zxNcJZ7+M5xasWhZdv75ZonbNv v+anp4VsgaJ3Pk7891tDO1I4RGjnXv1dMuKda5RYijMSDbWYi4oTATmNg8Q/AgAA 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, 21 Feb 2018 01:36:13 -0000 On Feb 20, 2018, at 17:00, Martin Thomson = wrote: >=20 > I know, I know, you are probably still struggling your way through > interop with -09, but the editors want to know if people want a set of > drafts that reference the newly added QCRAM and invariants docs. I wouldn=E2=80=99t mind and I think a published draft is reviewed by = more people. > There would be no change to interop targets. >=20 > We were originally hoping to include fixes to the bigger open issues, > but those seem unlikely to resolve in time for the March 5 draft > submission cutoff. And now there might be some people who want to try > out hq-10 now that it has a plausible header compression story. For the purposes of the interop, I believe we were still doing HTTP 0.9. = Has that changed? I=E2=80=99m not sure how many people will take advantage of hq-10 = interop but I don=E2=80=99t see any harm in publishing -10 drafts. =E2=80=94 Rui Paulo From nobody Tue Feb 20 18:08:50 2018 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 13407120227 for ; Tue, 20 Feb 2018 18:08:48 -0800 (PST) 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 OKpjpTY-hUoX for ; Tue, 20 Feb 2018 18:08:45 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::22a]) (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 EC87F1200F1 for ; Tue, 20 Feb 2018 18:08:44 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id q12so115525otg.10 for ; Tue, 20 Feb 2018 18:08:44 -0800 (PST) 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=zMbOgNbrBvZiN8Vm9imXj0ZgT7u+xdq/wGdh+PNvGBU=; b=G53/NEskFEeSyQn3s28/AThOPUH63DvZw73jD+rAc8fbV4E3TAYyffhCtXTQsrc1Um /q3bqeSPn61MuzaTBA2xOESgA+B1S7gVlm3BrsnAn/KUaQjuxoir8cPC1F+bC5SrFYk/ j3V3rbRXJPYMT6Ysyocvag0Mi5CYtSmLVb7xC2Kjgznl6fuN76S9gF8LHProHCVO2jDN 8dG72+XUF04/CK6gNzbkxxXwtopl8JFa/LTPrXdia5NwhQEMAH2YfEf5uy3+WMLdgz9L jMnRgpk28MEM6yY7sQRGGGXTfKRyeitSRv0w3PrEOpUoBED4CyEyUjnptrlQPB3xayoA uXag== 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=zMbOgNbrBvZiN8Vm9imXj0ZgT7u+xdq/wGdh+PNvGBU=; b=sr7MYqxWdrOEdQ1orGpAEw0BU1P5SA/ABcWNGMI7ABJ5aLyuPd0XJXn1W3GC2atIYA lthejZpKEd5EvPWwvZSlU/mznbL5Cx7RXSeTdVI+Fg9UKXTncnmQmlUZHy7yP9zU47IH 1Vk2EDboc+tawpA+snZhBfwL27NF+kl+fqJ8wHBkQJpNEVZLOdX3hHjne3pXaU0YtVr/ yP09A1KqMj88ZCJHvWNVVjaOyq22mqOGBNCJ0d8sfKyRx65HRZub0ftJmeZv1GJH78/0 BW5yFPTqRpB0DHP67UTr5iSQz8UDtN8dyYkb2hr7RkQwWjCoCEthg0WlmoNha+Z8a8La c+8Q== X-Gm-Message-State: APf1xPDMwf5YQGRTNTPNAmt1We70tjRMt/E4V+Uv1GJIVLHtuUSmppIY uCbbgrRc3Xum7jXXERywDpEkMRVr9MZXVw3bH7k= X-Google-Smtp-Source: AG47ELvjVf3oRsKlIjqlM/F7h01uYhT1qABdTTBFzQJnTX60TJnrBskjw/hCOrp60HlR3hPHJeKR2alwtsvi0oIpCz8= X-Received: by 10.157.12.229 with SMTP id o34mr1308471otd.352.1519178923787; Tue, 20 Feb 2018 18:08:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Tue, 20 Feb 2018 18:08:42 -0800 (PST) In-Reply-To: <4A74CD08-00C9-451A-80E8-E6AD7F644DED@apple.com> References: <4A74CD08-00C9-451A-80E8-E6AD7F644DED@apple.com> From: Martin Thomson Date: Wed, 21 Feb 2018 13:08:42 +1100 Message-ID: Subject: Re: Who wants -10 drafts? To: Rui Paulo 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, 21 Feb 2018 02:08:48 -0000 On Wed, Feb 21, 2018 at 12:36 PM, Rui Paulo wrote: > For the purposes of the interop, I believe we were still doing HTTP 0.9. = Has that changed? Yes, interop is QUIC -09 and HTTP 0.9 (no relation). > I=E2=80=99m not sure how many people will take advantage of hq-10 interop= but I don=E2=80=99t see any harm in publishing -10 drafts. I might, but whether that is possible will depend on a great many things. Nor do I think my own implementation matters much in determining this. From nobody Tue Feb 20 19:06:58 2018 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 007A9127869 for ; Tue, 20 Feb 2018 19:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 m7CFZ_3HhQMF for ; Tue, 20 Feb 2018 19:06:55 -0800 (PST) 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 2DE61124D68 for ; Tue, 20 Feb 2018 19:06:55 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx44.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1eoKk8-0003KR-Qv for quic@ietf.org; Wed, 21 Feb 2018 04:06:53 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eoKk5-00006q-AD for quic@ietf.org; Tue, 20 Feb 2018 22:06:51 -0500 Received: (qmail 26975 invoked from network); 21 Feb 2018 03:06:47 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.184]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Feb 2018 03:06:47 -0000 To: Martin Thomson , Rui Paulo Cc: QUIC WG References: <4A74CD08-00C9-451A-80E8-E6AD7F644DED@apple.com> From: Christian Huitema Message-ID: <09090022-d773-bde5-afe8-48535f02693a@huitema.net> Date: Tue, 20 Feb 2018 19:06:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------60EC88D1D0ADA80CC31F00EE" Content-Language: en-US Subject: Re: Who wants -10 drafts? X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.48) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jK+IXDo0c4ZbkkE6FnxHh9602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViqLqRkFGUaeeRMHRkTZb1zc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pB+FWCyy3VMwU/Tu6lpkyLYh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYZsb471zK7fbW8hSVMoqp pS0tFl0bR3sce73Q9OxrVmW8qt58sjfcrtp3jANJdxJ17LOKnTajLBlbnpYTTzDXX9m1LR/Rkhms gi1bNni1Nx10xK5dOvm4pbg8CBiJcsFLIaKLZaIWHErhz1UEr981hLCx4eCSemGsHMs75OfoLqcm 7I3bwInONPnB4uC7QfcgpyI1J519bLUrM3neslGWzosDwfIvvMsVZUpPp4sK3qDouROe77KOt1v8 CMoiiVQVf/qOH8le3Zo2iD646pXyZ+L6wWgmpZk5jRsdv2uoK5oKcZIuviiTlhP5iKsKcxHRbTmK Jq2ms5fD0VtmD1NhTzoUd/Fji/4E0A1Wfl7CNnoniG/Mx18wh299NVDnPvmw8t3Xj/LzZ5s/OJg1 L2asZ1FPmtYUPwECbZov76lmox9FrrkXXOH9yk2+X2eiUHXZfks5suSVIgIg9uJ3gfzn7g== 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, 21 Feb 2018 03:06:57 -0000 This is a multi-part message in MIME format. --------------60EC88D1D0ADA80CC31F00EE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 2/20/2018 6:08 PM, Martin Thomson wrote: > On Wed, Feb 21, 2018 at 12:36 PM, Rui Paulo wrote: >> For the purposes of the interop, I believe we were still doing HTTP 0.9. Has that changed? > Yes, interop is QUIC -09 and HTTP 0.9 (no relation). > >> I’m not sure how many people will take advantage of hq-10 interop but I don’t see any harm in publishing -10 drafts. > I might, but whether that is possible will depend on a great many > things. Nor do I think my own implementation matters much in > determining this. I understand that at some point we must start moving up the stack and test the HTTP mappings. I am not anywhere close to ready with that, because I am not starting with an HTTP 2 implementation. If it is what is takes to test the transport, I will do one, or port one. But no way I can do that in the next 8 days. -- Christian Huitema --------------60EC88D1D0ADA80CC31F00EE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2/20/2018 6:08 PM, Martin Thomson wrote:

On Wed, Feb 21, 2018 at 12:36 PM, Rui Paulo <rpaulo@apple.com> wrote:

For the purposes of the interop, I believe we were still doing HTTP 0.9.  Has that changed?

Yes, interop is QUIC -09 and HTTP 0.9 (no relation).


I’m not sure how many people will take advantage of hq-10 interop but I don’t see any harm in publishing -10 drafts.

I might, but whether that is possible will depend on a great many
things.  Nor do I think my own implementation matters much in
determining this.

I understand that at some point we must start moving up the stack and test the HTTP mappings. I am not anywhere close to ready with that, because I am not starting with an HTTP 2 implementation. If it is what is takes to test the transport, I will do one, or port one. But no way I can do that in the next 8 days.

-- Christian Huitema
--------------60EC88D1D0ADA80CC31F00EE-- From nobody Tue Feb 20 19:37:00 2018 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 A99341243FE for ; Tue, 20 Feb 2018 19:36:58 -0800 (PST) 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 PpdJY0V0NK2o for ; Tue, 20 Feb 2018 19:36:57 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 0680A124234 for ; Tue, 20 Feb 2018 19:36:57 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id c19so349027qtm.7 for ; Tue, 20 Feb 2018 19:36:56 -0800 (PST) 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=qRy6BvQw4nDpPFdIcEDozSyaDm0IIPbIJkwJimhVxQQ=; b=RS6lUmYu0H30PhzO/VF0YDYiObCZ7vDwGvFyRL9ns9NA+Jg0I+DBVuv2ymR7DAoQ7G CPbSaCJXaquhL2d0ARde1h95qwM6gRm3XTWCtHp/MaCpo7cda1XAh9YC/Rb2rtk+y8ZK mPtX0Q2jxvDuyR2UHgK5Prv8Fgh2NijuG4aXgTNV8siSFQLa1gnLxvUwMD/m+oEeR6Bm c+qQM7s5a5YUSSKstK3zPb9bRx7JYSZkZoQF5FkqElDZXib+RVoLs3GrOdwrM0F8WVVX vrSP39VEfuLh4vA6r1XxBPcAcikI6803ScWBZVyZQh+HSRXd90IzvaHHxPW1DRGNRFSK FW/Q== 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=qRy6BvQw4nDpPFdIcEDozSyaDm0IIPbIJkwJimhVxQQ=; b=QVAMGdNERfspXtWBPPU7SBaBAB1VhfNP2QDnhxhNg1o6Y/0zkyWMNB9A8G91aNDstm P3oEtwGkoPIyAmYpvm3X8CD9Aw0/kBBegHY/37PmWFct9YyIxM4Gpf2fJQLXzeNleUY/ 7myoc5I5Bd1/Q1zmQdyd+6MqQGxqyhrzoMjS0oCtIabl7AJvByeseS2X4rEutsOB5B8r 6VFTvTZanAzqiuRMMOCWivrapoNoctUMjYxtAsIXUGQV2yX/VXv7lntqI0roxmXQNx8P RioZdT7KkjEtE3+6rOd4XYnVPb7dwxiFXSwo+BeYB9nwkIHq9VsysrN96ojWvy/ZWtE+ KUlA== X-Gm-Message-State: APf1xPACgUPXVArlGSLqQXud+pYpUWxRPvAGW2X4RQzbiERaOej8L8bd sJNC26eQWRZF7FSOjyF0F9WFQmR6rfqe2T4UBk+8Bw== X-Google-Smtp-Source: AH8x2256kcr8TR7dLX0Rwdvb7DhfajqpJF1AZnqrARDY3N8GFQhSjmqDDFZ9p23dvNDUaVGjQFmMeIeU2lRxdO1Pv8c= X-Received: by 10.237.56.34 with SMTP id j31mr3221508qte.208.1519184216116; Tue, 20 Feb 2018 19:36:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Tue, 20 Feb 2018 19:36:15 -0800 (PST) In-Reply-To: <09090022-d773-bde5-afe8-48535f02693a@huitema.net> References: <4A74CD08-00C9-451A-80E8-E6AD7F644DED@apple.com> <09090022-d773-bde5-afe8-48535f02693a@huitema.net> From: Eric Rescorla Date: Tue, 20 Feb 2018 19:36:15 -0800 Message-ID: Subject: Re: Who wants -10 drafts? To: Christian Huitema Cc: Martin Thomson , Rui Paulo , QUIC WG Content-Type: multipart/alternative; boundary="001a113b7f188ce7480565b0a3fd" 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, 21 Feb 2018 03:36:59 -0000 --001a113b7f188ce7480565b0a3fd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would be very sad if we needed the H2 implementation to test QUIC. That seems like it would be bad for layering. -Ekr On Tue, Feb 20, 2018 at 7:06 PM, Christian Huitema wrote: > On 2/20/2018 6:08 PM, Martin Thomson wrote: > > On Wed, Feb 21, 2018 at 12:36 PM, Rui Paulo wrote: > > For the purposes of the interop, I believe we were still doing HTTP 0.9. = Has that changed? > > Yes, interop is QUIC -09 and HTTP 0.9 (no relation). > > > I=E2=80=99m not sure how many people will take advantage of hq-10 interop= but I don=E2=80=99t see any harm in publishing -10 drafts. > > I might, but whether that is possible will depend on a great many > things. Nor do I think my own implementation matters much in > determining this. > > > I understand that at some point we must start moving up the stack and tes= t > the HTTP mappings. I am not anywhere close to ready with that, because I = am > not starting with an HTTP 2 implementation. If it is what is takes to tes= t > the transport, I will do one, or port one. But no way I can do that in th= e > next 8 days. > > -- Christian Huitema > --001a113b7f188ce7480565b0a3fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would be very sad if we needed the H2 implementation to = test QUIC. That seems like it would be bad for layering.

-Ekr


On Tue, Feb 20, 2018 at 7:06 PM, Christian Huitema <hui= tema@huitema.net> wrote:
=20 =20 =20

On 2/20/2018 6:08 PM, Martin Thomson wrote:

On Wed, Feb 21, 2018 at 12:36 PM, Rui Paulo <rpaulo@apple.com> wrote:

For the purposes of the interop, I believe we were still doi=
ng HTTP 0.9.  Has that changed?

Yes, interop is QUIC -09 and HTTP 0.9 (no relation).


I=E2=80=99m not sure how many people will take advantage of =
hq-10 interop but I don=E2=80=99t see any harm in publishing -10 drafts.

I might, but whether that is possible will depend on a great m=
any
things.  Nor do I think my own implementation matters much in
determining this.

I understand that at some point we must start moving up the stack and test the HTTP mappings. I am not anywhere close to ready with that, because I am not starting with an HTTP 2 implementation. If it is what is takes to test the transport, I will do one, or port one. But no way I can do that in the next 8 days.

-- Christian Huitema

--001a113b7f188ce7480565b0a3fd-- From nobody Tue Feb 20 19:45:08 2018 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 0C9F9124234 for ; Tue, 20 Feb 2018 19:45:06 -0800 (PST) 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 9DtLq0QIOlIJ for ; Tue, 20 Feb 2018 19:45:04 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 30BC01243FE for ; Tue, 20 Feb 2018 19:45:04 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id 41so259918otd.13 for ; Tue, 20 Feb 2018 19:45:04 -0800 (PST) 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=WwOEic92sa8niiZ4skoxVRZcyDZ+qGL+gIkl1svUXnw=; b=WPxWFo0KVQ0+1whqj1HOYTdHooI1LTmw+Dx7nhF/jY+5Pz6SKpDf3n/ogKB9is4n76 dYNETXhlk5u9w9ESXhPVRT1TxQmEo7IayrMzMwI+qmcpq38wwU9c9RyYpVp9K2pJ81cf WANFHvE0+v7xAzwW+tQreTpuxItIfL1bomP32MJYhoNtP56WyBhPuLzM7Q9pItOVTtoj B37nP6URhGTW3GZYrNR9pNclkWZyYVC0gM+e2ZV5meY9f5vZBhyxABfUQcI+Flh9HPyy K+osJPtlw1fcCjn1e3MWP2EQaaBuh0yDKQdUpeqQIriu2NWctb4Y3xQkLmuqFl0VtZT4 l6Mw== 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=WwOEic92sa8niiZ4skoxVRZcyDZ+qGL+gIkl1svUXnw=; b=knemEn4y9VKQaSsKo5bU4lv7lxUYqxi+hyUUN4tc/xqoqifSod5j7b2GuCRv38mJLR zH+pVqrc6qg7lLup6CdY4LTuW4KwXO7573v0PGSJroOUWCmWz1GRYlU2z9QuUNszmeqC f13fnJ+5OT0wsmLq9M2Prd3kg9cGIxnpchr0pItN/rQoTP4oaC6gRsLd5lpVC3/e/ELj IK+aY9BkogHBPVxkAqyINDVkDbHzuCPOPru2lZF0995PmzuxHfXCTXmSA0YTA+u2iRcX 9qkgH5AqPTIky2brEqF1Wx9mbSB8HWAGZScJDLL4rQyrer7VbEW8bHp4BM8YWQfayBsD fm4Q== X-Gm-Message-State: APf1xPDDuiBjdWFT+9/+GCT69ezpMlSsQ8iE7d2TEwXYJ0MKIMbCABXd o2oU4UnZL5hI4DTaFSnsj2fj5EX53Y7DA1l7oGo= X-Google-Smtp-Source: AH8x2245+rUYgYwCMs0M6Nr+jYb88bFUg730sPgswBJGb9YFlQLnLGWpQzUkReI/EMOZx6am/CI0WHq0e/YDXcyS+Xo= X-Received: by 10.157.14.163 with SMTP id 32mr1277437otj.396.1519184703269; Tue, 20 Feb 2018 19:45:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Tue, 20 Feb 2018 19:45:02 -0800 (PST) In-Reply-To: References: <4A74CD08-00C9-451A-80E8-E6AD7F644DED@apple.com> <09090022-d773-bde5-afe8-48535f02693a@huitema.net> From: Martin Thomson Date: Wed, 21 Feb 2018 14:45:02 +1100 Message-ID: Subject: Re: Who wants -10 drafts? To: Eric Rescorla Cc: Christian Huitema , Rui Paulo , 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, 21 Feb 2018 03:45:06 -0000 No risk of that. Some people are looking to take the next step and get some experience with a non-toy upper layer. I agree that for the group as a whole, that step is a little way away just yet. On Wed, Feb 21, 2018 at 2:36 PM, Eric Rescorla wrote: > I would be very sad if we needed the H2 implementation to test QUIC. That > seems like it would be bad for layering. > > -Ekr > > > On Tue, Feb 20, 2018 at 7:06 PM, Christian Huitema > wrote: >> >> On 2/20/2018 6:08 PM, Martin Thomson wrote: >> >> On Wed, Feb 21, 2018 at 12:36 PM, Rui Paulo wrote: >> >> For the purposes of the interop, I believe we were still doing HTTP 0.9. >> Has that changed? >> >> Yes, interop is QUIC -09 and HTTP 0.9 (no relation). >> >> I=E2=80=99m not sure how many people will take advantage of hq-10 intero= p but I >> don=E2=80=99t see any harm in publishing -10 drafts. >> >> I might, but whether that is possible will depend on a great many >> things. Nor do I think my own implementation matters much in >> determining this. >> >> >> I understand that at some point we must start moving up the stack and te= st >> the HTTP mappings. I am not anywhere close to ready with that, because I= am >> not starting with an HTTP 2 implementation. If it is what is takes to te= st >> the transport, I will do one, or port one. But no way I can do that in t= he >> next 8 days. >> >> -- Christian Huitema > > From nobody Tue Feb 20 23:49:16 2018 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 00A3112D7EA for ; Tue, 20 Feb 2018 23:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1nKnX9a0Mypn for ; Tue, 20 Feb 2018 23:49:13 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [IPv6:2620:10a:4005:8000:2306::c]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2AB7124235 for ; Tue, 20 Feb 2018 23:49:13 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.46,543,1511856000"; d="asc'?scan'208";a="244234829" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx143-out.netapp.com with ESMTP; 20 Feb 2018 23:49:13 -0800 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 20 Feb 2018 23:49:13 -0800 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 20 Feb 2018 23:49:12 -0800 Received: from NAM03-DM3-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.1320.4 via Frontend Transport; Tue, 20 Feb 2018 23:49:12 -0800 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=3aTvVmznIJTsYxm+gBA7bFaPCXvWncxEx13/LsnPhyY=; b=WmkSWNjB/5AoaArkVW3HJZGVrXBxeUTJRRip9vop53rIKD9/MU3uk65V9Q79mwDLupgRB61pEuztwL4V9/NiaCMPOej4anjNjmcV4vQVYIkn+Wu2BPS1kfWqTUvQnx24CwjDRGFhtgBp4xvq9yTQdCoTe67lok8Dhq77Xxpl/oE= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB658.namprd06.prod.outlook.com (10.141.208.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 21 Feb 2018 07:49:10 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004%14]) with mapi id 15.20.0527.017; Wed, 21 Feb 2018 07:49:09 +0000 From: "Eggert, Lars" To: Martin Thomson CC: QUIC WG Subject: Re: Who wants -10 drafts? Thread-Topic: Who wants -10 drafts? Thread-Index: AQHTqq+AfzlJBVfGa0GuzbpUaZ6xUKOue4kA Date: Wed, 21 Feb 2018 07:49:09 +0000 Message-ID: <4D8795E9-7B63-40E3-9603-E4792B549983@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.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB658; 6:/CZ9T/ly824PltsRwqYsiQPkLS8of/P22MK+pGD0EHlDigMwIWTOw43+lMe3QuHbSMiSTXbhhHfToXZZxvO0GViklb8YD1TTe+74904O4Ne8+5oTBh1NOV21iQKfk5PzWVv/o8IBucW2xrPkO+1oU5rLZNG38c/M7oIOSoUaasGm0h1P/RlnWAq5dslFs04goZ5AdCwtbUx6EbnyhC3C9QfiFqWK60pimvzdG9OttB4/iBqfkIk1onyxRpq2qjAOAZ2uLJXEv4jWQ7Vp2f9fU6OMAzQuJMEYs3RNA9eLnU+BuEqq/ggO0SE4Cqp61ngQEJ+CsHVsDwbTiqfwHXHuWkOpWhbGQgdUPsg/1g7kyFTIX8+pIJVlVCHbNOX30QKk; 5:ECfK+wm06PMh1H55EDBQuWiQacEy/h6A62wjCRSzgfUZvqbiN5geEAUKEyo392TnbfhNZrV7lMBcp9lSeOr6Fi/xLgnGnQFLJF8njBuBDhuJ8n/0PO+82teQ03/TXXSOLaxMZzjbWAg0cnU4DptipZnjWpPBiXYPwb5hmcXNIZY=; 24:VgeVpECcCsj0B+7547OmUPM5DnONOpaTWaL8VNhyHioQxUh778qiuqerF9f3kH3vsCReBe4htfHhAvFJtnmLQIZNU7DSkK118WkGsCQsxqM=; 7:jA5JU6pZFV9cfZt52XFcIG6lrrcJKiLPNeD45Fq1GrwpqRJkVbAZ1qvBY+qjyEgfYhLblWM0OOH3BfEC6mGwEQL2OsLoi5Ri65YWr4CTH8kjKFCSeldlUaGOM0TLBMeaQ0W0+d6NC+860Rd7GoU9JRpYSrt1pNYgxSdUtzM8GTB/t/LGapg3TBpJ+glKzH7TrBBX3FOcWWPYSia4j0vIx+nAkN5v6l5wsoCPWH9qqIhvtcCJ5MZveuuZFcYXW08m x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 62614304-9764-4eb2-2b9a-08d578ff97b2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB658; x-ms-traffictypediagnostic: BLUPR06MB658: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001064)(102415395)(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231101)(944501161)(10201501046)(6055026)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:BLUPR06MB658; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB658; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(39380400002)(346002)(396003)(377424004)(189003)(199004)(81166006)(81156014)(3846002)(8936002)(8676002)(6116002)(5250100002)(68736007)(50226002)(36756003)(99286004)(83716003)(229853002)(2950100002)(6916009)(3280700002)(3660700001)(106356001)(33656002)(2906002)(76176011)(39060400002)(99936001)(6246003)(6506007)(478600001)(26005)(14454004)(316002)(105586002)(102836004)(6436002)(53546011)(86362001)(66066001)(5660300001)(7116003)(2900100001)(53936002)(25786009)(82746002)(6486002)(4326008)(57306001)(7736002)(6512007)(97736004)(305945005)(4001150100001)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB658; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: BtOwgTIHDDwgkbenrgzOuiOXwBFSElDwuZWA3j4jVcfl0cDZKsplubC1Zp9Nq4XaApxLju8BBof5AmmQNRb8U4NiL20oRuwKeqo0GIwNwV/uD1gGodg2Ga4SPM9bosyqz1dJUITF/7AfNevyfjjzRi9PtA+O3mJXQ4RhFQWX25g= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_2EE0322B-D81F-4072-B7CF-3A5428662255"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 62614304-9764-4eb2-2b9a-08d578ff97b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2018 07:49:09.8572 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB658 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, 21 Feb 2018 07:49:15 -0000 --Apple-Mail=_2EE0322B-D81F-4072-B7CF-3A5428662255 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2018-2-21, at 2:00, Martin Thomson wrote: >=20 > I know, I know, you are probably still struggling your way through > interop with -09, but the editors want to know if people want a set of > drafts that reference the newly added QCRAM and invariants docs. >=20 > There would be no change to interop targets. chair hat off, as an implementer: As long as we can agree to stay with = 09 (aka 4th implementation draft) for London, I don't care. Lars --Apple-Mail=_2EE0322B-D81F-4072-B7CF-3A5428662255 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlqNJHQACgkQVLXDCb9w wVc7DhAAiuReiSPnacVNPfclPQ1vW+p9GwT/bQNZthNTmpDMgdsRPiEYJNTJ1cdW LWmddzSWN+gAWEFYjF8i9dAq2elgjnO8DgrVfNTgz3yykrSQswnEm+7h7Fd0ohTz I9UlQRTbGcS0l6kdCpD9SUecxH5zUiCn5AkYfmhGEsiRzlMrnzoNcR188x91/D6w CmGdIUIp65+qisStnI/UDil7yqeRVj+7pca7vmdQMGLv8+reE+oXaD2Nu9jTY/WW K+fKS+Wggwy1tykmmrNt8Wr8jo3l2L2wuTaBLjYJiCRnkPW7OH5PyquTZY/dXSSz fmvnhPaUEBr//kqWUlZ3vHtEvMl7/UTu2EV4Q8xqFm6pzDz39GC1WvaX9tEsMagJ Ak1yJAaZyvgEAABVyoMKsA4oss8mF2UEIlACr68O/7r2+wOgykknF/AML+dAWwdR ec2+CPr6ukD2yvwOx7dFEB7qodndTbCfM2XM7ObpwN9mdK6sA+YrnsW1m1kgDqug BvYyQKEBmWx4EhruyTi7EEPbhqbgB8pSNzLd45/tPO5ZkWazHWxHL8aySNpATByu wsvsI5cEVzpKcF4plpwc3YGACEjn3euHG48o04+jia3fnXkx2FsUHwv9Fa1MDFsu 9Ajg1x84D179ggYieUruWIOavq7RazgdWW+B3fcxCMuAmR0NUxM= =De2u -----END PGP SIGNATURE----- --Apple-Mail=_2EE0322B-D81F-4072-B7CF-3A5428662255-- From nobody Wed Feb 21 04:42:19 2018 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 2ABCF127077 for ; Wed, 21 Feb 2018 04:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 1gQA4iT5EOHc for ; Wed, 21 Feb 2018 04:42:14 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 64F251200FC for ; Wed, 21 Feb 2018 04:42:14 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id a75so2071002itd.0 for ; Wed, 21 Feb 2018 04:42:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=VIJsiHdptXF45OwmXfTN9GX2aC8TxUf6p2Wlu6sed64=; b=IOmdzu7FxepexCpRdtRUWyv5tuxyjJEkBNiAQdK2e/wteTwcR/yAzQJDgQaS1ZxO5j xwxQbI0GOhSAV3LAoTXInQLkX/llKRuhN4nGXNX+tjvD8Lfh4C5P6uPmSWFo0xeImxEY xyewGEvk+DMnZg8Spm9WwKAaqBQ8ELe3zVO3Hw/KlTDLv384gLNkYTINEMgKm67bUPiZ TMp9l7JGmtZtp/oqsSv4RbGx2WIY3HK5I/ZIZdkKSu1jRWzGhJ31ndzebgoLBmOtRXO2 OhOBgL8OQjIEdMfDkNebtRYw6QWK6SObTat07hRIfZWCirCnMV72UhUpryhoPdtWHWXF WA/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=VIJsiHdptXF45OwmXfTN9GX2aC8TxUf6p2Wlu6sed64=; b=cUWq940I1pT7upLhAIj43Ac2LUaNQGGpZeIt1ho3AdMf2duF/nrWTGb12mxdiU6vc1 bsTb1FBx5f0xL+e63nB13ZRejDgl4i05Cr5IMvJBqlCEa0k/6WE2MhI0H9c0fa4CsMa7 rtw/p6YwHK5kyDvs3f6IsxSDGyOFstdWVwDgNGP6M3f5xM2v0rjk/te7259fbZyADjcp J3SDkVbrawD4DdZE65HN/tyHjVqONuYbFpn2gpoxS78hxexEEODqVurXzkU5UTpQZDca whPfXhhOxPHcP+sGl/x6Z4INGOpW175CZGX4LMnlE7lGySJBPHI8QdwD1JWZlFrVVQ5U SyVA== X-Gm-Message-State: APf1xPC4tj3OWcuIJSKW916dRSH1CMqmGzSvvn5rWv7isxfthGkBx+yI xbaaxqO+m4f4wS9gWuAnOa7zO3AHnMTMoCZJmg8= X-Google-Smtp-Source: AH8x227KrRuXI0l95b6VyXL2TZaXJHriJbMAnaGRMf7K4WQ53DCvXCGZYzefK0L24CR29R2K8jeVez4UIcLKy2fplH8= X-Received: by 10.36.222.134 with SMTP id d128mr3200282itg.150.1519216933618; Wed, 21 Feb 2018 04:42:13 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Feb 2018 07:42:12 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 21 Feb 2018 07:42:12 -0500 Message-ID: Subject: Re: Packet number encryption To: Victor Vasiliev , Kazuho Oku Cc: Praveen Balasubramanian , "quic@ietf.org" , Marten Seemann , huitema Content-Type: multipart/alternative; boundary="94eb2c05d0c2aa4a480565b841c4" 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, 21 Feb 2018 12:42:17 -0000 --94eb2c05d0c2aa4a480565b841c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maybe I=E2=80=99m missing something (such as exactly how TLS/QUIC maps encr= yption headers to packets: https://tools.ietf.org/html/draft-ietf-quic-tls-08#section-5.3 but it appears that the packet number encryption / linkage discussion is focused entirely on AES-GCM. The CCM mode which is part of TLS 1.3 has a header of 16 octets that includes a nonce. This nonce would appear to the packet number. https://tools.ietf.org/html/rfc3610 In summary: CCM has the unencrypted form H, LA, A, PA, LM, M, PM, T where H is a 16 octets header including nonce, LA is a length or the authenticated data A, LM is the length of the plain text data M, PA and PM is 0-padding up to block length, and T is tag of up to 16 octets. Some fields optional depending on first octet (flag) in H. T is computed as a chain of AES encryptions. Encryption is applied to LM, M, PM, T in CTR mode. (I suppose there is also padding after A). CCM is relevant to devices that have AES acceleration but no CLMUL instruction for GHASH needed by efficient AES-GCM implementations. E.g. ESP32 microcontrollers: https://www.ietf.org/mail-archive/web/tls/current/msg22495.html Of course the CCM header could partly or fully be removed if the authenticated data and encrypted data lengths can be implied otherwise, or part of it could be encrypted. On 12 February 2018 at 12.49.38, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: I can add some more numbers here https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.= pl The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. HFT is the extreme case which is why the benchmark is interesting, not necessarily the use case itself. The same concern applies to how fast a distributed database can achieve consensus, which is something I do care about. On 12 February 2018 at 12.44.01, Kazuho Oku (kazuhooku@gmail.com) wrote: Victor, Mikkel, thank you for the estimations. To me it seems that the estimated overhead of 0.1% seems like a natural number that we would see on production environment, where the average packet size is not small. I also agree that it would be worthwhile to look the case where small packets are exchanged. The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. One benchmark that might give us a more meaningful number is the DNS benchmark. https://www.knot-dns.cz/benchmark/ lists a benchmark of several authoritative DNS servers. The TLD benchmark and the Hosting (10k) benchmark gives us the rough estimation on how much PPS we can achieve when exchanging small packets. The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16 core (8x2) Intel Xeon processer running with HP enabled, when the fastest DNS server is being used. Running `openssl speed -evp` on a similar CPU gives me the following result= : $ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128 Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc's in 3.00= s This shows that 40M AES block operations can be run on a single core, per second, which in turn means that a server with 16 cores can perform 640M AES block operations per second (or 1,280M if HT is enabled and if AES is not the bottleneck). To summarize, if DNS had packet encryption, the overhead would be somewhere from 0.3% to 0.6%. Considering that, I would anticipate that the overhead of packet number encryption will be neglible even for short packet workloads. 2018-02-12 16:19 GMT+09:00 Victor Vasiliev : > I have no idea how you get that number (by which I mean, I have a lot of > guesses, but none of which are solid or useful here). I looked at the > profiles of various workloads we're running in production, and I estimate > that none of them would be impacted by PN encryption by worse than 0.1%. > > On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian > wrote: >> >> Makes sense. The 1%+ overhead I had quoted was in comparison to full >> protocol processing all the way from app to NIC. This is with an unoptimized >> early QUIC implementation and not fully optimized UDP/IP stack (we have >> focused much much more on optimizing TCP in the past). After software stack >> optimizations, the crypto share of the cost will only keep going up for >> which we have no technique other than to offload when such support is >> available in hardware and offload is way more challenging when workload is >> hosted in VMs and containers. >> >> >> >> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] >> Sent: Saturday, February 10, 2018 3:36 AM >> To: Victor Vasiliev >> Cc: Praveen Balasubramanian ; quic@ietf.org; Marten >> Seemann ; huitema >> Subject: Re: Packet number encryption >> >> >> >> To put numbers into perspective using Intel 2015 data >> >> >> >> >> https://software.intel.com/en-us/articles/improving-openssl-performance#_To= c416943490 >> >> >> >> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte o= r >> 66 cycles total, or 22ns on a 3GHz core. >> >> >> >> For packet numbers we use the CBC encrypt numbers because here AES canno= t >> exploit block parallelism. >> >> Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz >> setup that would amount to about 24ns overhead for packet encryption. >> >> >> >> Clearly it makes no sense that AES-GCM is faster than a single AES block >> encryption, but these are only approximate numbers and CBC mode might have a >> little overhead, so we clamp packet numbers to 22ns. >> >> >> >> Taking the 98ns overhead by the Solarflare report we get a total >> (simplified) processing time is 98ns non-crypto, 22ns for packet number, and >> 22ns for AEAD totalling 142ns. So the packet number encryption overhead >> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeeping, >> but that can be done in other cores or outside the latency critical window. >> >> >> >> This does not take into account that AEAD operation may operate less tha= n >> optimal because the packet number must be extracted first. On the other >> hand, it is also not a disastrous overhead if no good alternative can be >> found. >> >> >> >> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycle= s in HW >> for a single AES-128 block which would be 33ns per packet number in the >> above example. >> >> >> >> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen >> (mikkelfj@gmail.com) wrote: >> >> 98ns for 68 byte messages > > -- Kazuho Oku --94eb2c05d0c2aa4a480565b841c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Maybe I=E2=80=99m mi= ssing something (such as exactly how TLS/QUIC maps encryption headers to pa= ckets:=C2=A0https://tools.ietf.org/html/draft-ietf-quic-tls-08#section-5.3<= /a>

but it appears th= at the packet number encryption / linkage discussion is focused entirely on= AES-GCM.
The CCM mod= e which is part of TLS 1.3 has a header of 16 octets that includes a nonce.= This nonce would appear to the packet number.


In summary: CCM has the unencrypted form H, LA, A, PA, LM= , M, PM, T where H is a 16 octets header including nonce, LA is a length or= the authenticated data A, LM is the length of the plain text data M, PA an= d PM is 0-padding up to block length, and T is tag of up to 16 octets. Some= fields optional depending on first octet (flag) in H. T is computed as a c= hain of AES encryptions. Encryption is applied to LM, M, PM, T in CTR mode.= (I suppose there is also padding after A).

CCM is relevant to devices that have AES acceleratio= n but no CLMUL instruction for GHASH needed by efficient AES-GCM implementa= tions. E.g. ESP32 microcontrollers:
=C2=A0
Of= course the CCM header could partly or fully be removed if the authenticate= d data and encrypted data lengths can be implied otherwise, or part of it c= ould be encrypted.


<= /div>

On 12 February 2018 at 12.49.38, Mikkel F= ahn=C3=B8e J=C3=B8rgensen (mikkelfj@g= mail.com) wrote:

I can add some more numbers here

The numbers deducted from Solarflare report is=C2=A0
interesting, however I am not sure if that reflects the ordinary use=C2=A0
of a protocol; my understanding is that HFT is exceptional.=C2=A0

HFT is the extreme case which is why the benchmark is interesting, not necessarily the use case itself.

The same concern applies to how fast a distributed database can achieve consensus, which is something I do care about.


On 12 February 2018 at 12.44.01, Kazuho Oku (kazuhooku@gmail.com) wrote:

Victor, Mikkel, thank you for the estimations.

To me it seems that the estimated overhead of 0.1% seems like a
natural number that we would see on production environment, where the
average packet size is not small.

I also agree that it would be worthwhile to look the case where small
packets are exchanged. The numbers deducted from Solarflare report is
interesting, however I am not sure if that reflects the ordinary use
of a protocol; my understanding is that HFT is exceptional.

One benchmark that might give us a more meaningful number is the DNS benchmark.

https://www.knot-dns.cz/benc= hmark/ lists a benchmark of several
authoritative DNS servers. The TLD benchmark and the Hosting (10k)
benchmark gives us the rough estimation on how much PPS we can achieve
when exchanging small packets.

The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16
core (8x2) Intel Xeon processer running with HP enabled, when the
fastest DNS server is being used.

Running `openssl speed -evp` on a similar CPU gives me the following result:

$ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128
Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc's in 3.00s

This shows that 40M AES block operations can be run on a single core,
per second, which in turn means that a server with 16 cores can
perform 640M AES block operations per second (or 1,280M if HT is
enabled and if AES is not the bottleneck).

To summarize, if DNS had packet encryption, the overhead would be
somewhere from 0.3% to 0.6%.

Considering that, I would anticipate that the overhead of packet
number encryption will be neglible even for short packet workloads.


2018-02-12 16:19 GMT+09:00 Victor Vasiliev <vasilvv@google.com>:
> I have no idea how you get that number (by which I mean, I have a lot of
> guesses, but none of which are solid or useful here). I looked at the
> profiles of various workloads we're running in production, and I estimate
> that none of them would be impacted by PN encryption by worse than 0.1%.
>
> On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian
> <pravb@microsoft.com>= wrote:
>>
>> Makes sense. The 1%+ overhead I had quoted was in comparison to full
>> protocol processing all the way from app to NIC. This is with an unoptimized
>> early QUIC implementation and not fully optimized UDP/IP stack (we have
>> focused much much more on optimizing TCP in the past). After software stack
>> optimizations, the crypto share of the cost will only keep going up for
>> which we have no technique other than to offload when such support is
>> available in hardware and offload is way more challenging when workload is
>> hosted in VMs and containers.
>>
>>
>>
>> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
>> Sent: Saturday, February 10, 2018 3:36 AM
>> To: Victor Vasiliev <vasi= lvv@google.com>
>> Cc: Praveen Balasubramanian <pravb@microsoft.com>; quic@ietf.org; Marten
>> Seemann <martenseema= nn@gmail.com>; huitema <huitema@huitema.net>
>> Subject: Re: Packet number encryption
>>
>>
>>
>> To put numbers into perspective using Intel 2015 data
>>
>>
>>
>>
>> https://software.intel.com/en-us/articles/improving-= openssl-performance#_Toc416943490
>>
>>
>>
>> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte or
>> 66 cycles total, or 22ns on a 3GHz core.
>>
>>
>>
>> For packet numbers we use the CBC encrypt numbers because here AES cannot
>> exploit block parallelism.
>>
>> Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz
>> setup that would amount to about 24ns overhead for packet encryption.
>>
>>
>>
>> Clearly it makes no sense that AES-GCM is faster than a single AES block
>> encryption, but these are only approximate numbers and CBC mode might have a
>> little overhead, so we clamp packet numbers to 22ns.
>>
>>
>>
>> Taking the 98ns overhead by the Solarflare report we get a total
>> (simplified) processing time is 98ns non-crypto, 22ns for packet number, and
>> 22ns for AEAD totalling 142ns. So the packet number encryption overhead
>> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeeping,
>> but that can be done in other cores or outside the latency critical window.
>>
>>
>>
>> This does not take into account that AEAD operation may operate less than
>> optimal because the packet number must be extracted first. On the other
>> hand, it is also not a disastrous overhead if no good alternative can be
>> found.
>>
>>
>>
>> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycles in HW
>> for a single AES-128 block which would be 33ns per packet number in the
>> above example.
>>
>>
>>
>> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen
>> (mikkelfj@gmail.com) wro= te:
>>
>> 98ns for 68 byte messages
>
>



--
Kazuho Oku
--94eb2c05d0c2aa4a480565b841c4-- From nobody Wed Feb 21 05:53:36 2018 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 10756127077 for ; Wed, 21 Feb 2018 05:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 UNQbw_m1fCHD for ; Wed, 21 Feb 2018 05:53:27 -0800 (PST) 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 85994126DEE for ; Wed, 21 Feb 2018 05:53:27 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id e4so2181195iob.8 for ; Wed, 21 Feb 2018 05:53:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=uQQ3SiYrDKYXQccw7LU0eksVIazcD5Lh4h6bbKQSPaA=; b=DOsyZINXTmUKOdaTY1noWOr6d+ayOxubBQX/InbXiux/m9zMILOZl5Ess1yK1ox2g4 3jRUGrud1VMoF0wrTqNotYlYUu9d4lG4fC/sedAXYW9F6/b2Zyj2/i5Vfa/3v5kGD5vC 5xh+eSIFY9ic+sEQWCn6ba1gYh1rw7BsfO+UDYdmy3f68hQvUxWYVZdsXSOZwFsgW5I5 SqFsV1dSvsQPZoVQNcZ2mR2klFKt2W+appmGqX+Qa6ydZmhxRVzQfLKfUNMBOkl/foxj AaKxjLgIpnt9J2ynLzJrfHRNAByluac6AfoGmhuJfidUn1YXLUpXfpMTJAEdUx+7869M rrvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=uQQ3SiYrDKYXQccw7LU0eksVIazcD5Lh4h6bbKQSPaA=; b=puegmt7+QmiY2ZooIMcUsAxfW6AQjBTmLyfCWGnj2iss4RkPu6QRx97SPshA+KXrxz EtJr0ZkVbSpLICRHKPFxyaKw0RPzJTQO63alp+aH04RaqTVhaIlgimwwPjOJpJkmS2tH jPHUMdhD/68TyKDDaKDq/iiu6Tq6lmuWvbeUWIps2kEcgyoFPGPicEcLrWzjwhO8rieo fikBot6XRGEQkkNRJrdUTtKeb1g1xRiXIBxBzyr2TfYLZxX9cP/lN+a9zo/8ZhTgoa1M At1buBo6mLgbFdrSF21hgnifV6L8q9MAqtohJNacmgY2VxSyuDRgU8k0l+ZRhOwvRIZt rolQ== X-Gm-Message-State: APf1xPAN2yHp39yuWDaJsRBoV9a9vlOWKbkqJQfgSRyGM/BDxxYiw8Em xwEBp/6a6JX7Tlt/XfUKcEJkJjR9SiuAQYv74hQ= X-Google-Smtp-Source: AG47ELuAtvXZp/ESCWyl7CNezzwavKv922a8U8PWFqzarm9jl4S6v/N2QKMI1WPUGkb9kPa1AaIvzYeTLsCjRadsQxA= X-Received: by 10.107.33.72 with SMTP id h69mr4010464ioh.209.1519221203825; Wed, 21 Feb 2018 05:53:23 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Feb 2018 08:53:23 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 21 Feb 2018 08:53:22 -0500 Message-ID: Subject: Re: Packet number encryption To: Victor Vasiliev , Kazuho Oku Cc: Praveen Balasubramanian , "quic@ietf.org" , Marten Seemann , huitema Content-Type: multipart/alternative; boundary="001a1140f5e6307ff30565b940c3" 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, 21 Feb 2018 13:53:35 -0000 --001a1140f5e6307ff30565b940c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I suppose that CCM is not a major concern since the nonce would be computed from the encrypted packet number and thus not reveal anything surprising. It does, however, add a fair bit of overhead: 16 bytes of CCM header including nonce and length data. 0 padded authenticated data so the packet header will consume 16 octets. This includes the now redundant encrypted packet number. At the is a 0-15 octet padding which on might be 7.5 octets on average, or 0 if the packet is filled perfectly, and of course the 16 octet auth tag. This means that CCM mode will use at least 3x16 octets and addition to encrypted payload and UDP headers. It would probably be easy to remove 32 octets of that overhead, but it would require special adaptation of CCM for QUIC that might not be worthwhile - as we wait for devices that include GCM hardware support. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 21 February 2018 at 13.42.12, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: Maybe I=E2=80=99m missing something (such as exactly how TLS/QUIC maps encr= yption headers to packets: https://tools.ietf.org/html/draft-ietf-quic-tls-08#section-5.3 but it appears that the packet number encryption / linkage discussion is focused entirely on AES-GCM. The CCM mode which is part of TLS 1.3 has a header of 16 octets that includes a nonce. This nonce would appear to the packet number. https://tools.ietf.org/html/rfc3610 In summary: CCM has the unencrypted form H, LA, A, PA, LM, M, PM, T where H is a 16 octets header including nonce, LA is a length or the authenticated data A, LM is the length of the plain text data M, PA and PM is 0-padding up to block length, and T is tag of up to 16 octets. Some fields optional depending on first octet (flag) in H. T is computed as a chain of AES encryptions. Encryption is applied to LM, M, PM, T in CTR mode. (I suppose there is also padding after A). CCM is relevant to devices that have AES acceleration but no CLMUL instruction for GHASH needed by efficient AES-GCM implementations. E.g. ESP32 microcontrollers: https://www.ietf.org/mail-archive/web/tls/current/msg22495.html Of course the CCM header could partly or fully be removed if the authenticated data and encrypted data lengths can be implied otherwise, or part of it could be encrypted. On 12 February 2018 at 12.49.38, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: I can add some more numbers here https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.= pl The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. HFT is the extreme case which is why the benchmark is interesting, not necessarily the use case itself. The same concern applies to how fast a distributed database can achieve consensus, which is something I do care about. On 12 February 2018 at 12.44.01, Kazuho Oku (kazuhooku@gmail.com) wrote: Victor, Mikkel, thank you for the estimations. To me it seems that the estimated overhead of 0.1% seems like a natural number that we would see on production environment, where the average packet size is not small. I also agree that it would be worthwhile to look the case where small packets are exchanged. The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. One benchmark that might give us a more meaningful number is the DNS benchmark. https://www.knot-dns.cz/benchmark/ lists a benchmark of several authoritative DNS servers. The TLD benchmark and the Hosting (10k) benchmark gives us the rough estimation on how much PPS we can achieve when exchanging small packets. The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16 core (8x2) Intel Xeon processer running with HP enabled, when the fastest DNS server is being used. Running `openssl speed -evp` on a similar CPU gives me the following result= : $ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128 Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc's in 3.00= s This shows that 40M AES block operations can be run on a single core, per second, which in turn means that a server with 16 cores can perform 640M AES block operations per second (or 1,280M if HT is enabled and if AES is not the bottleneck). To summarize, if DNS had packet encryption, the overhead would be somewhere from 0.3% to 0.6%. Considering that, I would anticipate that the overhead of packet number encryption will be neglible even for short packet workloads. 2018-02-12 16:19 GMT+09:00 Victor Vasiliev : > I have no idea how you get that number (by which I mean, I have a lot of > guesses, but none of which are solid or useful here). I looked at the > profiles of various workloads we're running in production, and I estimate > that none of them would be impacted by PN encryption by worse than 0.1%. > > On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian > wrote: >> >> Makes sense. The 1%+ overhead I had quoted was in comparison to full >> protocol processing all the way from app to NIC. This is with an unoptimized >> early QUIC implementation and not fully optimized UDP/IP stack (we have >> focused much much more on optimizing TCP in the past). After software stack >> optimizations, the crypto share of the cost will only keep going up for >> which we have no technique other than to offload when such support is >> available in hardware and offload is way more challenging when workload is >> hosted in VMs and containers. >> >> >> >> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] >> Sent: Saturday, February 10, 2018 3:36 AM >> To: Victor Vasiliev >> Cc: Praveen Balasubramanian ; quic@ietf.org; Marten >> Seemann ; huitema >> Subject: Re: Packet number encryption >> >> >> >> To put numbers into perspective using Intel 2015 data >> >> >> >> >> https://software.intel.com/en-us/articles/improving-openssl-performance#_To= c416943490 >> >> >> >> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte o= r >> 66 cycles total, or 22ns on a 3GHz core. >> >> >> >> For packet numbers we use the CBC encrypt numbers because here AES canno= t >> exploit block parallelism. >> >> Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz >> setup that would amount to about 24ns overhead for packet encryption. >> >> >> >> Clearly it makes no sense that AES-GCM is faster than a single AES block >> encryption, but these are only approximate numbers and CBC mode might have a >> little overhead, so we clamp packet numbers to 22ns. >> >> >> >> Taking the 98ns overhead by the Solarflare report we get a total >> (simplified) processing time is 98ns non-crypto, 22ns for packet number, and >> 22ns for AEAD totalling 142ns. So the packet number encryption overhead >> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeeping, >> but that can be done in other cores or outside the latency critical window. >> >> >> >> This does not take into account that AEAD operation may operate less tha= n >> optimal because the packet number must be extracted first. On the other >> hand, it is also not a disastrous overhead if no good alternative can be >> found. >> >> >> >> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycle= s in HW >> for a single AES-128 block which would be 33ns per packet number in the >> above example. >> >> >> >> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen >> (mikkelfj@gmail.com) wrote: >> >> 98ns for 68 byte messages > > -- Kazuho Oku --001a1140f5e6307ff30565b940c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I suppose that CCM i= s not a major concern since the nonce would be computed from the encrypted = packet number and thus not reveal anything surprising. It does, however, ad= d a fair bit of overhead:

16 bytes of CCM header including nonce and length data. 0 padded authe= nticated data so the packet header will consume 16 octets. This includes th= e now redundant encrypted packet number. At the is a 0-15 octet padding whi= ch on might be 7.5 octets on average, or 0 if the packet is filled perfectl= y, and of course the 16 octet auth tag.

This means that CCM mode will use at least 3x16 octets a= nd addition to encrypted payload and UDP headers.

It would probably be easy to remove 32 octets = of that overhead, but it would require special adaptation of CCM for QUIC t= hat might not be worthwhile - as we wait for devices that include GCM hardw= are support.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 21 February 2018 at 13.42.12, Mikkel Fahn=C3=B8e J= =C3=B8rgensen (mikkelfj@gmail.com= ) wrote:

Maybe I=E2=80=99m missing something (such as exactly how TLS/QUIC maps encryption headers to packets:=C2=A0https://tools.ietf.org/html/draft-ietf-= quic-tls-08#section-5.3

but it appears that the packet number encryption / linkage discussion is focused entirely on AES-GCM.

The CCM mode which is part of TLS 1.3 has a header of 16 octets that includes a nonce. This nonce would appear to the packet number.


In summary: CCM has the unencrypted form H, LA, A, PA, LM, M, PM, T where H is a 16 octets header including nonce, LA is a length or the authenticated data A, LM is the length of the plain text data M, PA and PM is 0-padding up to block length, and T is tag of up to 16 octets. Some fields optional depending on first octet (flag) in H. T is computed as a chain of AES encryptions. Encryption is applied to LM, M, PM, T in CTR mode. (I suppose there is also padding after A).

CCM is relevant to devices that have AES acceleration but no CLMUL instruction for GHASH needed by efficient AES-GCM implementations. E.g. ESP32 microcontrollers:
=C2=A0
Of course the CCM header could partly or fully be removed if the authenticated data and encrypted data lengths can be implied otherwise, or part of it could be encrypted.



On 12 February 2018 at 12.49.38, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@= gmail.com) wrote:

I can add some more numbers here

The numbers deducted from Solarflare report is=C2=A0
interesting, however I am not sure if that reflects the ordinary use=C2=A0
of a protocol; my understanding is that HFT is exceptional.=C2=A0

HFT is the extreme case which is why the benchmark is interesting, not necessarily the use case itself.

The same concern applies to how fast a distributed database can achieve consensus, which is something I do care about.

On 12 February 2018 at 12.44.01, Kazuho Oku (kazuhooku@gmail.com) wrote:

Victor, Mikkel, thank you for the estimations.

To me it seems that the estimated overhead of 0.1% seems like a
natural number that we would see on production environment, where the
average packet size is not small.

I also agree that it would be worthwhile to look the case where small
packets are exchanged. The numbers deducted from Solarflare report is
interesting, however I am not sure if that reflects the ordinary use
of a protocol; my understanding is that HFT is exceptional.

One benchmark that might give us a more meaningful number is the DNS benchmark.

https://www.knot-dns.cz/benc= hmark/ lists a benchmark of several
authoritative DNS servers. The TLD benchmark and the Hosting (10k)
benchmark gives us the rough estimation on how much PPS we can achieve
when exchanging small packets.

The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16
core (8x2) Intel Xeon processer running with HP enabled, when the
fastest DNS server is being used.

Running `openssl speed -evp` on a similar CPU gives me the following result:

$ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128
Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc's in 3.00s

This shows that 40M AES block operations can be run on a single core,
per second, which in turn means that a server with 16 cores can
perform 640M AES block operations per second (or 1,280M if HT is
enabled and if AES is not the bottleneck).

To summarize, if DNS had packet encryption, the overhead would be
somewhere from 0.3% to 0.6%.

Considering that, I would anticipate that the overhead of packet
number encryption will be neglible even for short packet workloads.


2018-02-12 16:19 GMT+09:00 Victor Vasiliev <vasilvv@google.com>:
> I have no idea how you get that number (by which I mean, I have a lot of
> guesses, but none of which are solid or useful here). I looked at the
> profiles of various workloads we're running in production, and I estimate
> that none of them would be impacted by PN encryption by worse than 0.1%.
>
> On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian
> <pravb@microsoft.com>= wrote:
>>
>> Makes sense. The 1%+ overhead I had quoted was in comparison to full
>> protocol processing all the way from app to NIC. This is with an unoptimized
>> early QUIC implementation and not fully optimized UDP/IP stack (we have
>> focused much much more on optimizing TCP in the past). After software stack
>> optimizations, the crypto share of the cost will only keep going up for
>> which we have no technique other than to offload when such support is
>> available in hardware and offload is way more challenging when workload is
>> hosted in VMs and containers.
>>
>>
>>
>> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
>> Sent: Saturday, February 10, 2018 3:36 AM
>> To: Victor Vasiliev <vasi= lvv@google.com>
>> Cc: Praveen Balasubramanian <pravb@microsoft.com>; quic@ietf.org; Marten
>> Seemann <martenseema= nn@gmail.com>; huitema <huitema@huitema.net>
>> Subject: Re: Packet number encryption
>>
>>
>>
>> To put numbers into perspective using Intel 2015 data
>>
>>
>>
>>
>> https://software.intel.com/en-us/articles/improving-= openssl-performance#_Toc416943490
>>
>>
>>
>> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte or
>> 66 cycles total, or 22ns on a 3GHz core.
>>
>>
>>
>> For packet numbers we use the CBC encrypt numbers because here AES cannot
>> exploit block parallelism.
>>
>> Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz
>> setup that would amount to about 24ns overhead for packet encryption.
>>
>>
>>
>> Clearly it makes no sense that AES-GCM is faster than a single AES block
>> encryption, but these are only approximate numbers and CBC mode might have a
>> little overhead, so we clamp packet numbers to 22ns.
>>
>>
>>
>> Taking the 98ns overhead by the Solarflare report we get a total
>> (simplified) processing time is 98ns non-crypto, 22ns for packet number, and
>> 22ns for AEAD totalling 142ns. So the packet number encryption overhead
>> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeeping,
>> but that can be done in other cores or outside the latency critical window.
>>
>>
>>
>> This does not take into account that AEAD operation may operate less than
>> optimal because the packet number must be extracted first. On the other
>> hand, it is also not a disastrous overhead if no good alternative can be
>> found.
>>
>>
>>
>> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycles in HW
>> for a single AES-128 block which would be 33ns per packet number in the
>> above example.
>>
>>
>>
>> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen
>> (mikkelfj@gmail.com) wro= te:
>>
>> 98ns for 68 byte messages
>
>



--
Kazuho Oku
--001a1140f5e6307ff30565b940c3-- From nobody Wed Feb 21 06:09:21 2018 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 38EF0127077 for ; Wed, 21 Feb 2018 06:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 NGI_cZdRshMI for ; Wed, 21 Feb 2018 06:09:18 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 C3D16126D05 for ; Wed, 21 Feb 2018 06:09:17 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id w63so2325359ita.3 for ; Wed, 21 Feb 2018 06:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=P+kBBm93uMSQ51xMsnZLA3IZAQesbnwfenFJB9wsg3o=; b=fzrFyWhvmnjXmyTzv8yUxUoZ7Ag6BpuWxxhsl0gxsHa8JIE/zELP23BfGYkjfkivch 14JfFHL7881ExX4ag0XCRiI3HbEBBstMzKi9jIUsbaDSnZ7N5yyULXZC2D1hp09DTorF XKaLPvbMzl5gb3Rl8mD+A0UUju/8GNAX/wCUQtTGhRZDHuEgrWZvcc8QWeoaDUIMSe1R vW72WCE9GlRKygs1XX/tn9t5qUwZ74BGDPHyMVGX3WIVm0yQQx3sOWH0jgNYN6riDdif ycEABtjUE9ry4/vTuGuNBu02VKaCn8Dk5B1E3GxrJv63hCNmue9P3ascEtv7vm3mUAI3 CDiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=P+kBBm93uMSQ51xMsnZLA3IZAQesbnwfenFJB9wsg3o=; b=Sa7xwPtlBS9R7kgP1Nqtb4ffo6YiiKGCxw0zG3r+xRRy510Olk0co9gtns/Ql29wA4 Xv+Vj8FLrmy8SjwrAwlv01WxCGTkAwJjt642S8ifZAmyXglzhoIge4y0X6dUxCyvTenj CK0VMRTCNJob+UOeDp8aTeYy1+EV8UuV6LehoLtIKfmIKTAY4GEdzLJffhK7kRYb91yo OOxTF97NatNqYvNG8zjY3OgyhkW9BVbCJc586PBo+jmhpIIr6c8CG4gvDjJw2mgirXS9 DS6us4cuMDOwkgzc8RDJYPuxMqgZ1qcloNJDlUIExkf1hb3f+PHEq/++im4luCWIxLVm 0KAA== X-Gm-Message-State: APf1xPC0uF8t7AsAb1P+VqvNSAT699+LogQujDAAFBXH086d4KLhI4B/ SrKwYmH6KC0ICmS0zTlm915qnaZMUdxcgRjvctE= X-Google-Smtp-Source: AH8x224XnKRSYuYgwE5VAafk4MHYb0OOYzb4a+ttDPCDQOs2nPsfMZ5lRrva16hI0rfs5V3catMZenQD2E++frZVWtw= X-Received: by 10.36.69.30 with SMTP id y30mr3288850ita.39.1519222157021; Wed, 21 Feb 2018 06:09:17 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Feb 2018 09:09:16 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 21 Feb 2018 09:09:16 -0500 Message-ID: Subject: Re: Packet number encryption To: Victor Vasiliev , Kazuho Oku Cc: Praveen Balasubramanian , "quic@ietf.org" , Marten Seemann , huitema Content-Type: multipart/alternative; boundary="001a11c149140118590565b9791d" 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, 21 Feb 2018 14:09:20 -0000 --001a11c149140118590565b9791d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If the encrypted packet number is truncated, e.g. wrapping after 4 octets, it would not be possible to use the encrypted packet number as a nonce unless it is acceptable to use that octets that follow, which could be hard to justify. The alternative is to either a) have full length packet numbers, b) renegotiate keys before wrap, c) drop the CCM header and compute it based on the decrypted packet number - which saves space as discussed below, but which also interferes with plain TLS CCM operation. As I have argued before, it might be simpler to simply have a 32-bit sequential counter and restrict it to a single path, then user the upper implicit bits for a path identifier (segmented packet numbers). In this case there is no encryption overhead and the CCM nonce is trivially available. The only remaining question is if the packet number should be redundant in both the QUIC header and the CCM header. This could further be generalised by moving the packet number out of the QUIC and into an AEAD specific header field - but that of course impacts monitoring and ossification. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 21 February 2018 at 14.53.23, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: I suppose that CCM is not a major concern since the nonce would be computed from the encrypted packet number and thus not reveal anything surprising. It does, however, add a fair bit of overhead: 16 bytes of CCM header including nonce and length data. 0 padded authenticated data so the packet header will consume 16 octets. This includes the now redundant encrypted packet number. At the is a 0-15 octet padding which on might be 7.5 octets on average, or 0 if the packet is filled perfectly, and of course the 16 octet auth tag. This means that CCM mode will use at least 3x16 octets and addition to encrypted payload and UDP headers. It would probably be easy to remove 32 octets of that overhead, but it would require special adaptation of CCM for QUIC that might not be worthwhile - as we wait for devices that include GCM hardware support. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 21 February 2018 at 13.42.12, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: Maybe I=E2=80=99m missing something (such as exactly how TLS/QUIC maps encr= yption headers to packets: https://tools.ietf.org/html/draft-ietf-quic-tls-08#section-5.3 but it appears that the packet number encryption / linkage discussion is focused entirely on AES-GCM. The CCM mode which is part of TLS 1.3 has a header of 16 octets that includes a nonce. This nonce would appear to the packet number. https://tools.ietf.org/html/rfc3610 In summary: CCM has the unencrypted form H, LA, A, PA, LM, M, PM, T where H is a 16 octets header including nonce, LA is a length or the authenticated data A, LM is the length of the plain text data M, PA and PM is 0-padding up to block length, and T is tag of up to 16 octets. Some fields optional depending on first octet (flag) in H. T is computed as a chain of AES encryptions. Encryption is applied to LM, M, PM, T in CTR mode. (I suppose there is also padding after A). CCM is relevant to devices that have AES acceleration but no CLMUL instruction for GHASH needed by efficient AES-GCM implementations. E.g. ESP32 microcontrollers: https://www.ietf.org/mail-archive/web/tls/current/msg22495.html Of course the CCM header could partly or fully be removed if the authenticated data and encrypted data lengths can be implied otherwise, or part of it could be encrypted. On 12 February 2018 at 12.49.38, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: I can add some more numbers here https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.= pl The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. HFT is the extreme case which is why the benchmark is interesting, not necessarily the use case itself. The same concern applies to how fast a distributed database can achieve consensus, which is something I do care about. On 12 February 2018 at 12.44.01, Kazuho Oku (kazuhooku@gmail.com) wrote: Victor, Mikkel, thank you for the estimations. To me it seems that the estimated overhead of 0.1% seems like a natural number that we would see on production environment, where the average packet size is not small. I also agree that it would be worthwhile to look the case where small packets are exchanged. The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. One benchmark that might give us a more meaningful number is the DNS benchmark. https://www.knot-dns.cz/benchmark/ lists a benchmark of several authoritative DNS servers. The TLD benchmark and the Hosting (10k) benchmark gives us the rough estimation on how much PPS we can achieve when exchanging small packets. The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16 core (8x2) Intel Xeon processer running with HP enabled, when the fastest DNS server is being used. Running `openssl speed -evp` on a similar CPU gives me the following result= : $ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128 Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc's in 3.00= s This shows that 40M AES block operations can be run on a single core, per second, which in turn means that a server with 16 cores can perform 640M AES block operations per second (or 1,280M if HT is enabled and if AES is not the bottleneck). To summarize, if DNS had packet encryption, the overhead would be somewhere from 0.3% to 0.6%. Considering that, I would anticipate that the overhead of packet number encryption will be neglible even for short packet workloads. 2018-02-12 16:19 GMT+09:00 Victor Vasiliev : > I have no idea how you get that number (by which I mean, I have a lot of > guesses, but none of which are solid or useful here). I looked at the > profiles of various workloads we're running in production, and I estimate > that none of them would be impacted by PN encryption by worse than 0.1%. > > On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian > wrote: >> >> Makes sense. The 1%+ overhead I had quoted was in comparison to full >> protocol processing all the way from app to NIC. This is with an unoptimized >> early QUIC implementation and not fully optimized UDP/IP stack (we have >> focused much much more on optimizing TCP in the past). After software stack >> optimizations, the crypto share of the cost will only keep going up for >> which we have no technique other than to offload when such support is >> available in hardware and offload is way more challenging when workload is >> hosted in VMs and containers. >> >> >> >> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] >> Sent: Saturday, February 10, 2018 3:36 AM >> To: Victor Vasiliev >> Cc: Praveen Balasubramanian ; quic@ietf.org; Marten >> Seemann ; huitema >> Subject: Re: Packet number encryption >> >> >> >> To put numbers into perspective using Intel 2015 data >> >> >> >> >> https://software.intel.com/en-us/articles/improving-openssl-performance#_To= c416943490 >> >> >> >> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte o= r >> 66 cycles total, or 22ns on a 3GHz core. >> >> >> >> For packet numbers we use the CBC encrypt numbers because here AES canno= t >> exploit block parallelism. >> >> Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz >> setup that would amount to about 24ns overhead for packet encryption. >> >> >> >> Clearly it makes no sense that AES-GCM is faster than a single AES block >> encryption, but these are only approximate numbers and CBC mode might have a >> little overhead, so we clamp packet numbers to 22ns. >> >> >> >> Taking the 98ns overhead by the Solarflare report we get a total >> (simplified) processing time is 98ns non-crypto, 22ns for packet number, and >> 22ns for AEAD totalling 142ns. So the packet number encryption overhead >> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeeping, >> but that can be done in other cores or outside the latency critical window. >> >> >> >> This does not take into account that AEAD operation may operate less tha= n >> optimal because the packet number must be extracted first. On the other >> hand, it is also not a disastrous overhead if no good alternative can be >> found. >> >> >> >> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycle= s in HW >> for a single AES-128 block which would be 33ns per packet number in the >> above example. >> >> >> >> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen >> (mikkelfj@gmail.com) wrote: >> >> 98ns for 68 byte messages > > -- Kazuho Oku --001a11c149140118590565b9791d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = If the encrypted pac= ket number is truncated, e.g. wrapping after 4 octets, it would not be poss= ible to use the encrypted packet number as a nonce unless it is acceptable = to use that octets that follow, which could be hard to justify. The alterna= tive is to either a) have full length packet numbers, b) renegotiate keys b= efore wrap, c) drop the CCM header and compute it based on the decrypted pa= cket number - which saves space as discussed below, but which also interfer= es with plain TLS CCM operation.

As I have argued= before, it might be simpler to simply have a 32-bit sequential counter and= restrict it to a single path, then user the upper implicit bits for a path= identifier (segmented packet numbers). In this case there is no encryption= overhead and the CCM nonce is trivially available. The only remaining ques= tion is if the packet number should be redundant in both the QUIC header an= d the CCM header. This could further be generalised by moving the packet nu= mber out of the QUIC and into an AEAD specific header field - but that of c= ourse impacts monitoring and ossification.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

<= /div>

On 21 February 2018 at 14.53.23, Mikkel F= ahn=C3=B8e J=C3=B8rgensen (mikkelfj@g= mail.com) wrote:

I suppose that CCM is not a major concern since the nonce would be computed from the encrypted packet number and thus not reveal anything surprising. It does, however, add a fair bit of overhead:

16 bytes of CCM header including nonce and length data. 0 padded authenticated data so the packet header will consume 16 octets. This includes the now redundant encrypted packet number. At the is a 0-15 octet padding which on might be 7.5 octets on average, or 0 if the packet is filled perfectly, and of course the 16 octet auth tag.

This means that CCM mode will use at least 3x16 octets and addition to encrypted payload and UDP headers.

It would probably be easy to remove 32 octets of that overhead, but it would require special adaptation of CCM for QUIC that might not be worthwhile - as we wait for devices that include GCM hardware support.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 21 February 2018 at 13.42.12, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@= gmail.com) wrote:

Maybe I=E2=80=99m missing something (such as exactly how TLS/QUIC maps encryption headers to packets:=C2=A0https://tools.ietf.org/html/draft-= ietf-quic-tls-08#section-5.3

but it appears that the packet number encryption / linkage discussion is focused entirely on AES-GCM.

The CCM mode which is part of TLS 1.3 has a header of 16 octets that includes a nonce. This nonce would appear to the packet number.


In summary: CCM has the unencrypted form H, LA, A, PA, LM, M, PM, T where H is a 16 octets header including nonce, LA is a length or the authenticated data A, LM is the length of the plain text data M, PA and PM is 0-padding up to block length, and T is tag of up to 16 octets. Some fields optional depending on first octet (flag) in H. T is computed as a chain of AES encryptions. Encryption is applied to LM, M, PM, T in CTR mode. (I suppose there is also padding after A).

CCM is relevant to devices that have AES acceleration but no CLMUL instruction for GHASH needed by efficient AES-GCM implementations. E.g. ESP32 microcontrollers:
=C2=A0
Of course the CCM header could partly or fully be removed if the authenticated data and encrypted data lengths can be implied otherwise, or part of it could be encrypted.

On 12 February 2018 at 12.49.38, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@= gmail.com) wrote:

I can add some more numbers here

The numbers deducted from Solarflare report is=C2=A0
interesting, however I am not sure if that reflects the ordinary use=C2=A0
of a protocol; my understanding is that HFT is exceptional.=C2=A0

HFT is the extreme case which is why the benchmark is interesting, not necessarily the use case itself.

The same concern applies to how fast a distributed database can achieve consensus, which is something I do care about.

On 12 February 2018 at 12.44.01, Kazuho Oku (kazuhooku@gmail.com) wrote:

Victor, Mikkel, thank you for the estimations.

To me it seems that the estimated overhead of 0.1% seems like a
natural number that we would see on production environment, where the
average packet size is not small.

I also agree that it would be worthwhile to look the case where small
packets are exchanged. The numbers deducted from Solarflare report is
interesting, however I am not sure if that reflects the ordinary use
of a protocol; my understanding is that HFT is exceptional.

One benchmark that might give us a more meaningful number is the DNS benchmark.

https://www.knot-dns.cz/benc= hmark/ lists a benchmark of several
authoritative DNS servers. The TLD benchmark and the Hosting (10k)
benchmark gives us the rough estimation on how much PPS we can achieve
when exchanging small packets.

The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16
core (8x2) Intel Xeon processer running with HP enabled, when the
fastest DNS server is being used.

Running `openssl speed -evp` on a similar CPU gives me the following result:

$ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128
Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc's in 3.00s

This shows that 40M AES block operations can be run on a single core,
per second, which in turn means that a server with 16 cores can
perform 640M AES block operations per second (or 1,280M if HT is
enabled and if AES is not the bottleneck).

To summarize, if DNS had packet encryption, the overhead would be
somewhere from 0.3% to 0.6%.

Considering that, I would anticipate that the overhead of packet
number encryption will be neglible even for short packet workloads.


2018-02-12 16:19 GMT+09:00 Victor Vasiliev <vasilvv@google.com>:
> I have no idea how you get that number (by which I mean, I have a lot of
> guesses, but none of which are solid or useful here). I looked at the
> profiles of various workloads we're running in production, and I estimate
> that none of them would be impacted by PN encryption by worse than 0.1%.
>
> On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian
> <pravb@microsoft.com>= wrote:
>>
>> Makes sense. The 1%+ overhead I had quoted was in comparison to full
>> protocol processing all the way from app to NIC. This is with an unoptimized
>> early QUIC implementation and not fully optimized UDP/IP stack (we have
>> focused much much more on optimizing TCP in the past). After software stack
>> optimizations, the crypto share of the cost will only keep going up for
>> which we have no technique other than to offload when such support is
>> available in hardware and offload is way more challenging when workload is
>> hosted in VMs and containers.
>>
>>
>>
>> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
>> Sent: Saturday, February 10, 2018 3:36 AM
>> To: Victor Vasiliev <vasi= lvv@google.com>
>> Cc: Praveen Balasubramanian <pravb@microsoft.com>; quic@ietf.org; Marten
>> Seemann <martenseema= nn@gmail.com>; huitema <huitema@huitema.net>
>> Subject: Re: Packet number encryption
>>
>>
>>
>> To put numbers into perspective using Intel 2015 data
>>
>>
>>
>>
>> https://software.intel.com/en-us/articles/improving-= openssl-performance#_Toc416943490
>>
>>
>>
>> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte or
>> 66 cycles total, or 22ns on a 3GHz core.
>>
>>
>>
>> For packet numbers we use the CBC encrypt numbers because here AES cannot
>> exploit block parallelism.
>>
>> Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz
>> setup that would amount to about 24ns overhead for packet encryption.
>>
>>
>>
>> Clearly it makes no sense that AES-GCM is faster than a single AES block
>> encryption, but these are only approximate numbers and CBC mode might have a
>> little overhead, so we clamp packet numbers to 22ns.
>>
>>
>>
>> Taking the 98ns overhead by the Solarflare report we get a total
>> (simplified) processing time is 98ns non-crypto, 22ns for packet number, and
>> 22ns for AEAD totalling 142ns. So the packet number encryption overhead
>> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeeping,
>> but that can be done in other cores or outside the latency critical window.
>>
>>
>>
>> This does not take into account that AEAD operation may operate less than
>> optimal because the packet number must be extracted first. On the other
>> hand, it is also not a disastrous overhead if no good alternative can be
>> found.
>>
>>
>>
>> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycles in HW
>> for a single AES-128 block which would be 33ns per packet number in the
>> above example.
>>
>>
>>
>> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen
>> (mikkelfj@gmail.com) wro= te:
>>
>> 98ns for 68 byte messages
>
>



--
Kazuho Oku
--001a11c149140118590565b9791d-- From nobody Wed Feb 21 06:13:47 2018 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 7187712D77C for ; Wed, 21 Feb 2018 06:13:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no 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 56AtC7Qe78et for ; Wed, 21 Feb 2018 06:13:38 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 A60D812D77A for ; Wed, 21 Feb 2018 06:13:38 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id t22so2267858iob.3 for ; Wed, 21 Feb 2018 06:13:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=OcN8vHYp6O/dDOAeNgwBNKPCRL32i+i71HuCYJA6sps=; b=Oc/GguV6L+1DxmsK7INjt+89Cw5xO/qZnvWWNl/c1ZDadO51n5KQySCpsgVAZp7CHq wTqUj3KBhrFsexLILRJ6jqPsgFB/hkbeLSXnVlX9RhzLsEiMM3OJIV8nxsz4X+8U7p1M ovnJbno90bHwAL26wLAg5OwB78R/ARhJ4Cnb3BjwYVHNiRUuxduSzkRBU14yypxBW+Ky Zh26G/8jLm1e5GyPNVtTZzY0f7jI33N0iCD8vCVnveZ93PQ1tGyC8Pz5P1BSBTwhjqEE GTCtnLOZzj+V4UpRqno+DajAElFHNmyn7vcSDcuHToqLJ/DITA28n5x2q+LFPEHp3LMv Uefg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=OcN8vHYp6O/dDOAeNgwBNKPCRL32i+i71HuCYJA6sps=; b=WboO+K0J53s101OdgpVjuW07L5LWCBU1XY3l98NHF6NcRzX2G8nzGlVNH0JU/S7GDQ 2vW2t0gMtPmYnqCaUUnF1n41+IHQBnX+PMpygz/sQechutNOFJjCgbHG3Xi3UAeI2UYQ BXsTnuV5MWWpU3No7Fs+AIWrUw2Vz2oDUOPTrYz9xl+7CH0vi/cw6IKtA/FivmHeASJ9 112feocgYE5WCtRZwJ3DuEBhI+0a3o+Z8kII9beuwmwwFwvLm8B+Z8j3+v6rxGhtaZov tbgxTGDNvUau+bjij768OBQ2Ffvb2+MdcAxKEq0hOCnK7DxUAgIimYZ0Rh3NkhlnPsoB do/Q== X-Gm-Message-State: APf1xPAQbSVOt1/h1LCW1+5S5O7F0YYn/Uxnh7wvlKRmQI4fBvsm/V6R uzIbzh/KPVQT4AD+jTUc+zmWUI+6Tbz+C7wLqwg= X-Google-Smtp-Source: AH8x224eo7ViFsFYzcKkRGU9p/g72dOGywOZFQXVuvvZ8/HQVA7G8JcguqKgSaEmpL9c4no92AHXobKYg/xYz4dyuEQ= X-Received: by 10.107.159.148 with SMTP id i142mr4361765ioe.36.1519222417943; Wed, 21 Feb 2018 06:13:37 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Feb 2018 09:13:37 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <2102BDC2-62C0-4A76-8ADE-8167437E2D07@trammell.ch> <8e833029-68b5-2787-3897-a0f7818a259f@tik.ee.ethz.ch> <1de39727-eeec-0e7a-1e8b-5ed50433c5bd@cs.tcd.ie> <119b3276-5799-1cc3-8982-7479171bbf27@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 21 Feb 2018 09:13:37 -0500 Message-ID: Subject: Re: Packet number encryption To: Victor Vasiliev , Kazuho Oku Cc: Praveen Balasubramanian , "quic@ietf.org" , Marten Seemann , huitema Content-Type: multipart/alternative; boundary="001a1140fe228e791b0565b98871" 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, 21 Feb 2018 14:13:41 -0000 --001a1140fe228e791b0565b98871 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sorry for the mail flux, but using encrypted packet numbers as nonce would not even be possible with the current proposal, because the nonce must be known before the packet number is encrypted. On 21 February 2018 at 15.09.16, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: If the encrypted packet number is truncated, e.g. wrapping after 4 octets, it would not be possible to use the encrypted packet number as a nonce unless it is acceptable to use that octets that follow, which could be hard to justify. The alternative is to either a) have full length packet numbers, b) renegotiate keys before wrap, c) drop the CCM header and compute it based on the decrypted packet number - which saves space as discussed below, but which also interferes with plain TLS CCM operation. As I have argued before, it might be simpler to simply have a 32-bit sequential counter and restrict it to a single path, then user the upper implicit bits for a path identifier (segmented packet numbers). In this case there is no encryption overhead and the CCM nonce is trivially available. The only remaining question is if the packet number should be redundant in both the QUIC header and the CCM header. This could further be generalised by moving the packet number out of the QUIC and into an AEAD specific header field - but that of course impacts monitoring and ossification. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 21 February 2018 at 14.53.23, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: I suppose that CCM is not a major concern since the nonce would be computed from the encrypted packet number and thus not reveal anything surprising. It does, however, add a fair bit of overhead: 16 bytes of CCM header including nonce and length data. 0 padded authenticated data so the packet header will consume 16 octets. This includes the now redundant encrypted packet number. At the is a 0-15 octet padding which on might be 7.5 octets on average, or 0 if the packet is filled perfectly, and of course the 16 octet auth tag. This means that CCM mode will use at least 3x16 octets and addition to encrypted payload and UDP headers. It would probably be easy to remove 32 octets of that overhead, but it would require special adaptation of CCM for QUIC that might not be worthwhile - as we wait for devices that include GCM hardware support. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 21 February 2018 at 13.42.12, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: Maybe I=E2=80=99m missing something (such as exactly how TLS/QUIC maps encr= yption headers to packets: https://tools.ietf.org/html/draft-ietf-quic-tls-08#section-5.3 but it appears that the packet number encryption / linkage discussion is focused entirely on AES-GCM. The CCM mode which is part of TLS 1.3 has a header of 16 octets that includes a nonce. This nonce would appear to the packet number. https://tools.ietf.org/html/rfc3610 In summary: CCM has the unencrypted form H, LA, A, PA, LM, M, PM, T where H is a 16 octets header including nonce, LA is a length or the authenticated data A, LM is the length of the plain text data M, PA and PM is 0-padding up to block length, and T is tag of up to 16 octets. Some fields optional depending on first octet (flag) in H. T is computed as a chain of AES encryptions. Encryption is applied to LM, M, PM, T in CTR mode. (I suppose there is also padding after A). CCM is relevant to devices that have AES acceleration but no CLMUL instruction for GHASH needed by efficient AES-GCM implementations. E.g. ESP32 microcontrollers: https://www.ietf.org/mail-archive/web/tls/current/msg22495.html Of course the CCM header could partly or fully be removed if the authenticated data and encrypted data lengths can be implied otherwise, or part of it could be encrypted. On 12 February 2018 at 12.49.38, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: I can add some more numbers here https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aesni-x86_64.= pl The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. HFT is the extreme case which is why the benchmark is interesting, not necessarily the use case itself. The same concern applies to how fast a distributed database can achieve consensus, which is something I do care about. On 12 February 2018 at 12.44.01, Kazuho Oku (kazuhooku@gmail.com) wrote: Victor, Mikkel, thank you for the estimations. To me it seems that the estimated overhead of 0.1% seems like a natural number that we would see on production environment, where the average packet size is not small. I also agree that it would be worthwhile to look the case where small packets are exchanged. The numbers deducted from Solarflare report is interesting, however I am not sure if that reflects the ordinary use of a protocol; my understanding is that HFT is exceptional. One benchmark that might give us a more meaningful number is the DNS benchmark. https://www.knot-dns.cz/benchmark/ lists a benchmark of several authoritative DNS servers. The TLD benchmark and the Hosting (10k) benchmark gives us the rough estimation on how much PPS we can achieve when exchanging small packets. The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16 core (8x2) Intel Xeon processer running with HP enabled, when the fastest DNS server is being used. Running `openssl speed -evp` on a similar CPU gives me the following result= : $ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128 Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc's in 3.00= s This shows that 40M AES block operations can be run on a single core, per second, which in turn means that a server with 16 cores can perform 640M AES block operations per second (or 1,280M if HT is enabled and if AES is not the bottleneck). To summarize, if DNS had packet encryption, the overhead would be somewhere from 0.3% to 0.6%. Considering that, I would anticipate that the overhead of packet number encryption will be neglible even for short packet workloads. 2018-02-12 16:19 GMT+09:00 Victor Vasiliev : > I have no idea how you get that number (by which I mean, I have a lot of > guesses, but none of which are solid or useful here). I looked at the > profiles of various workloads we're running in production, and I estimate > that none of them would be impacted by PN encryption by worse than 0.1%. > > On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian > wrote: >> >> Makes sense. The 1%+ overhead I had quoted was in comparison to full >> protocol processing all the way from app to NIC. This is with an unoptimized >> early QUIC implementation and not fully optimized UDP/IP stack (we have >> focused much much more on optimizing TCP in the past). After software stack >> optimizations, the crypto share of the cost will only keep going up for >> which we have no technique other than to offload when such support is >> available in hardware and offload is way more challenging when workload is >> hosted in VMs and containers. >> >> >> >> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com] >> Sent: Saturday, February 10, 2018 3:36 AM >> To: Victor Vasiliev >> Cc: Praveen Balasubramanian ; quic@ietf.org; Marten >> Seemann ; huitema >> Subject: Re: Packet number encryption >> >> >> >> To put numbers into perspective using Intel 2015 data >> >> >> >> >> https://software.intel.com/en-us/articles/improving-openssl-performance#_To= c416943490 >> >> >> >> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte o= r >> 66 cycles total, or 22ns on a 3GHz core. >> >> >> >> For packet numbers we use the CBC encrypt numbers because here AES canno= t >> exploit block parallelism. >> >> Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz >> setup that would amount to about 24ns overhead for packet encryption. >> >> >> >> Clearly it makes no sense that AES-GCM is faster than a single AES block >> encryption, but these are only approximate numbers and CBC mode might have a >> little overhead, so we clamp packet numbers to 22ns. >> >> >> >> Taking the 98ns overhead by the Solarflare report we get a total >> (simplified) processing time is 98ns non-crypto, 22ns for packet number, and >> 22ns for AEAD totalling 142ns. So the packet number encryption overhead >> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeeping, >> but that can be done in other cores or outside the latency critical window. >> >> >> >> This does not take into account that AEAD operation may operate less tha= n >> optimal because the packet number must be extracted first. On the other >> hand, it is also not a disastrous overhead if no good alternative can be >> found. >> >> >> >> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycle= s in HW >> for a single AES-128 block which would be 33ns per packet number in the >> above example. >> >> >> >> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen >> (mikkelfj@gmail.com) wrote: >> >> 98ns for 68 byte messages > > -- Kazuho Oku --001a1140fe228e791b0565b98871 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Sorry for the mail f= lux,
but usin= g encrypted packet numbers as nonce would not even be possible with the cur= rent proposal, because the nonce must be known before the packet number is = encrypted.



On 21 February 2018 at 15.09.16, Mikk= el Fahn=C3=B8e J=C3=B8rgensen (mikkel= fj@gmail.com) wrote:

<= span>
=
If the encrypted packet number is truncated, e.g. wrapping after 4 octets, it would not be possible to use the encrypted packet number as a nonce unless it is acceptable to use that octets that follow, which could be hard to justify. The alternative is to either a) have full length packet numbers, b) renegotiate keys before wrap, c) drop the CCM header and compute it based on the decrypted packet number - which saves space as discussed below, but which also interferes with plain TLS CCM operation.

As I have argued before, it might be simpler to simply have a 32-bit sequential counter and restrict it to a single path, then user the upper implicit bits for a path identifier (segmented packet numbers). In this case there is no encryption overhead and the CCM nonce is trivially available. The only remaining question is if the packet number should be redundant in both the QUIC header and the CCM header. This could further be generalised by moving the packet number out of the QUIC and into an AEAD specific header field - but that of course impacts monitoring and ossification.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 21 February 2018 at 14.53.23, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@= gmail.com) wrote:

I suppose that CCM is not a major concern since the nonce would be computed from the encrypted packet number and thus not reveal anything surprising. It does, however, add a fair bit of overhead:

16 bytes of CCM header including nonce and length data. 0 padded authenticated data so the packet header will consume 16 octets. This includes the now redundant encrypted packet number. At the is a 0-15 octet padding which on might be 7.5 octets on average, or 0 if the packet is filled perfectly, and of course the 16 octet auth tag.

This means that CCM mode will use at least 3x16 octets and addition to encrypted payload and UDP headers.

It would probably be easy to remove 32 octets of that overhead, but it would require special adaptation of CCM for QUIC that might not be worthwhile - as we wait for devices that include GCM hardware support.
Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

On 21 February 2018 at 13.42.12, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@= gmail.com) wrote:

Maybe I=E2=80=99m missing something (such as exactly how TLS/QUIC maps encryption headers to packets:=C2=A0https://tools.ietf.org/ht= ml/draft-ietf-quic-tls-08#section-5.3

but it appears that the packet number encryption / linkage discussion is focused entirely on AES-GCM.

The CCM mode which is part of TLS 1.3 has a header of 16 octets that includes a nonce. This nonce would appear to the packet number.


In summary: CCM has the unencrypted form H, LA, A, PA, LM, M, PM, T where H is a 16 octets header including nonce, LA is a length or the authenticated data A, LM is the length of the plain text data M, PA and PM is 0-padding up to block length, and T is tag of up to 16 octets. Some fields optional depending on first octet (flag) in H. T is computed as a chain of AES encryptions. Encryption is applied to LM, M, PM, T in CTR mode. (I suppose there is also padding after A).

CCM is relevant to devices that have AES acceleration but no CLMUL instruction for GHASH needed by efficient AES-GCM implementations. E.g. ESP32 microcontrollers:
=C2=A0
Of course the CCM header could partly or fully be removed if the authenticated data and encrypted data lengths can be implied otherwise, or part of it could be encrypted.

On 12 February 2018 at 12.49.38, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj@= gmail.com) wrote:

I can add some more numbers here

The numbers deducted from Solarflare report is=C2=A0
interesting, however I am not sure if that reflects the ordinary use=C2=A0
of a protocol; my understanding is that HFT is exceptional.=C2=A0

HFT is the extreme case which is why the benchmark is interesting, not necessarily the use case itself.

The same concern applies to how fast a distributed database can achieve consensus, which is something I do care about.

On 12 February 2018 at 12.44.01, Kazuho Oku (kazuhooku@gmail.com) wrote:

Victor, Mikkel, thank you for the estimations.

To me it seems that the estimated overhead of 0.1% seems like a
natural number that we would see on production environment, where the
average packet size is not small.

I also agree that it would be worthwhile to look the case where small
packets are exchanged. The numbers deducted from Solarflare report is
interesting, however I am not sure if that reflects the ordinary use
of a protocol; my understanding is that HFT is exceptional.

One benchmark that might give us a more meaningful number is the DNS benchmark.

https://www.knot-dns.cz/benc= hmark/ lists a benchmark of several
authoritative DNS servers. The TLD benchmark and the Hosting (10k)
benchmark gives us the rough estimation on how much PPS we can achieve
when exchanging small packets.

The numbers we see on the benchmark is roughly 2M RPS (4M pps) on a 16
core (8x2) Intel Xeon processer running with HP enabled, when the
fastest DNS server is being used.

Running `openssl speed -evp` on a similar CPU gives me the following result:

$ /usr/local/openssl-1.1.0/bin/openssl speed -evp aes128
Doing aes-128-cbc for 3s on 16 size blocks: 133387877 aes-128-cbc's in 3.00s

This shows that 40M AES block operations can be run on a single core,
per second, which in turn means that a server with 16 cores can
perform 640M AES block operations per second (or 1,280M if HT is
enabled and if AES is not the bottleneck).

To summarize, if DNS had packet encryption, the overhead would be
somewhere from 0.3% to 0.6%.

Considering that, I would anticipate that the overhead of packet
number encryption will be neglible even for short packet workloads.


2018-02-12 16:19 GMT+09:00 Victor Vasiliev <vasilvv@google.com>:
> I have no idea how you get that number (by which I mean, I have a lot of
> guesses, but none of which are solid or useful here). I looked at the
> profiles of various workloads we're running in production, and I estimate
> that none of them would be impacted by PN encryption by worse than 0.1%.
>
> On Sat, Feb 10, 2018 at 12:12 PM, Praveen Balasubramanian
> <pravb@microsoft.com>= wrote:
>>
>> Makes sense. The 1%+ overhead I had quoted was in comparison to full
>> protocol processing all the way from app to NIC. This is with an unoptimized
>> early QUIC implementation and not fully optimized UDP/IP stack (we have
>> focused much much more on optimizing TCP in the past). After software stack
>> optimizations, the crypto share of the cost will only keep going up for
>> which we have no technique other than to offload when such support is
>> available in hardware and offload is way more challenging when workload is
>> hosted in VMs and containers.
>>
>>
>>
>> From: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mailto:mikkelfj@gmail.com]
>> Sent: Saturday, February 10, 2018 3:36 AM
>> To: Victor Vasiliev <vasi= lvv@google.com>
>> Cc: Praveen Balasubramanian <pravb@microsoft.com>; quic@ietf.org; Marten
>> Seemann <martenseema= nn@gmail.com>; huitema <huitema@huitema.net>
>> Subject: Re: Packet number encryption
>>
>>
>>
>> To put numbers into perspective using Intel 2015 data
>>
>>
>>
>>
>> https://software.intel.com/en-us/articles/improving-= openssl-performance#_Toc416943490
>>
>>
>>
>> A 64 byte message in AES-GCM AEAD in HW would use 1.03 cycles per byte or
>> 66 cycles total, or 22ns on a 3GHz core.
>>
>>
>>
>> For packet numbers we use the CBC encrypt numbers because here AES cannot
>> exploit block parallelism.
>>
>> Here we see 4.44 cycles/byte in HW or 71 cycles per block. With a 3GHz
>> setup that would amount to about 24ns overhead for packet encryption.
>>
>>
>>
>> Clearly it makes no sense that AES-GCM is faster than a single AES block
>> encryption, but these are only approximate numbers and CBC mode might have a
>> little overhead, so we clamp packet numbers to 22ns.
>>
>>
>>
>> Taking the 98ns overhead by the Solarflare report we get a total
>> (simplified) processing time is 98ns non-crypto, 22ns for packet number, and
>> 22ns for AEAD totalling 142ns. So the packet number encryption overhead
>> would be 22/(98+22)*100% =3D 18%. The numbers ignore other QUIC bookkeeping,
>> but that can be done in other cores or outside the latency critical window.
>>
>>
>>
>> This does not take into account that AEAD operation may operate less than
>> optimal because the packet number must be extracted first. On the other
>> hand, it is also not a disastrous overhead if no good alternative can be
>> found.
>>
>>
>>
>> Earlier AES-NI I=E2=80=99ve seen from Intel doc suggests around 100cycles in HW
>> for a single AES-128 block which would be 33ns per packet number in the
>> above example.
>>
>>
>>
>> On 10 February 2018 at 06.18.25, Mikkel Fahn=C3=B8e J=C3=B8rgensen
>> (mikkelfj@gmail.com) wro= te:
>>
>> 98ns for 68 byte messages
>
>



--
Kazuho Oku
--001a1140fe228e791b0565b98871-- From nobody Wed Feb 21 06:37:50 2018 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 5AB541270AB for ; Wed, 21 Feb 2018 06:37:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H4=-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 (1024-bit key) header.d=ericsson.com header.b=Q/a6jbB1; dkim=pass (1024-bit key) header.d=ericsson.com header.b=F49bfyG+ 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 qIU7oReIQFAL for ; Wed, 21 Feb 2018 06:37:45 -0800 (PST) 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 BD37D127077 for ; Wed, 21 Feb 2018 06:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519223862; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=S4SJzBt6qHZ1nuNbrb/LnMCIVPUa8+xMoA/9drPtCtE=; b=Q/a6jbB1cWoA3yK0Zr4vAV8O0TPb40wh4ju4hdXOLEC3Cw4JutRzbBFJaCtvWt0P vgTH3l8NChrWCUwmnVq8gkRvoUzkmJL6iuYUQQj6HwDmii0rb6RbC662ZQWzGufv Qvzzylqyk3RtfeVOuXoZyDRLTkSpan1/wonw/g3RZi4=; X-AuditID: c1b4fb3a-35fff700000067b4-39-5a8d84367042 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 42.2D.26548.6348D8A5; Wed, 21 Feb 2018 15:37:42 +0100 (CET) Received: from ESESBMR503.ericsson.se (153.88.183.135) by ESESSHC018.ericsson.se (153.88.183.72) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 21 Feb 2018 15:37:42 +0100 Received: from ESESBMB505.ericsson.se (153.88.183.172) by ESESBMR503.ericsson.se (153.88.183.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Wed, 21 Feb 2018 15:37:42 +0100 Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Wed, 21 Feb 2018 15:37:41 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=S4SJzBt6qHZ1nuNbrb/LnMCIVPUa8+xMoA/9drPtCtE=; b=F49bfyG+rxFlEQe7YdE0lNrAvm9D2+kSt1Ylib9Vay9wdkFCcEadncMU3f2JmINJnkIUPmNSrhew12mQP34tuyz+oPnpi6uKPMNnpWxNBwIRJYAtEVQ/JKlBTg+4sC342SRybwLqGkg+LeuY8hnzkc5nfr4vxMgg/me/FttlJn4= Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com (52.133.6.23) by HE1PR0702MB3691.eurprd07.prod.outlook.com (52.133.6.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Wed, 21 Feb 2018 14:37:40 +0000 Received: from HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::2ca4:c7f5:8d2a:f180]) by HE1PR0702MB3625.eurprd07.prod.outlook.com ([fe80::2ca4:c7f5:8d2a:f180%2]) with mapi id 15.20.0527.012; Wed, 21 Feb 2018 14:37:40 +0000 From: Ingemar Johansson S To: "De Schepper, Koen (Nokia - BE/Antwerp)" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , QUIC WG CC: "ekinnear@apple.com" , "Lubashev, Igor" , Ian Swett , Christian Huitema , Ingemar Johansson S Subject: RE: ECN in QUIC connection migration Thread-Topic: ECN in QUIC connection migration Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25AAZWcAAAB/s3/ABUaWKkACnvEWAAAvBcBAAIFvbgAAzEkjAAAhG1T4BW03A0A== Date: Wed, 21 Feb 2018 14:37:40 +0000 Message-ID: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> <5CC94D22-1375-40A2-8084-BA4A43F6FA94@tik.ee.ethz.ch>, In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR0702MB3691; 7:7WMMa/XFWFmrMtkw51C5wYh9UgDHLynAPA1UHGjHYgXcvp1WbXMgjQc6o9Q2xpnKKyx9t0VJwdYxAFFI79+GYmO7TJdp9ZrfBs2+3y9wFC8XfrAX2Q6Uf6U1Mul6RIJGBUjqn1PPcIxR6ibYUPxZDSxWg9m98N941hbBTCd/HBSuvsl2/NsM/vtKvGklg6XgVqf4DIeLzmjSZvdsx+lsh0uD3t2YDTymRo2hlNKddwrJ8BzAzMmis8shRbugE/8S x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(366004)(39860400002)(396003)(39380400002)(346002)(376002)(51914003)(199004)(189003)(13464003)(54906003)(53546011)(99286004)(5660300001)(86362001)(81166006)(5250100002)(8936002)(8676002)(5890100001)(97736004)(81156014)(105586002)(6506007)(186003)(59450400001)(102836004)(316002)(106356001)(4743002)(9326002)(110136005)(26005)(76176011)(45080400002)(66066001)(33656002)(9686003)(54896002)(6306002)(55016002)(8666007)(68736007)(7696005)(236005)(6436002)(478600001)(229853002)(53936002)(7736002)(107886003)(2906002)(3846002)(3660700001)(6116002)(2950100002)(19609705001)(74316002)(790700001)(6246003)(53386004)(2900100001)(4326008)(966005)(14454004)(3280700002)(606006)(25786009)(1680700002)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0702MB3691; H:HE1PR0702MB3625.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 0d928296-386f-4d40-a844-08d57938a8e3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:HE1PR0702MB3691; x-ms-traffictypediagnostic: HE1PR0702MB3691: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(244540007438412)(166708455590820)(211936372134217)(100405760836317)(202460600054446)(153496737603132)(21748063052155)(265313219721884); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001068)(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231101)(944501161)(6041288)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR0702MB3691; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0702MB3691; x-forefront-prvs: 0590BBCCBC received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 3kGpuvAeiIrreRvpV7sCx2RBzBFeNjtflfM+E87aJ9Wo7Hadg+IP0TbNDxfadXFFyw2k7QVWyEgXnMCZmOpBmUT5+fO9C33k4BcoNTfeAjOYQAaqidvAJ7CZVlXVaWfIypL+CZUGTflPvO6Gy0+ShVpFoiu+d7q4TV2Ek1W+9Yo= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0702MB36252D23A798375FE12607FBC2CE0HE1PR0702MB3625_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0d928296-386f-4d40-a844-08d57938a8e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2018 14:37:40.0789 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0702MB3691 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01SaUiTYRzveY/tdTV68sA/hqUjK8UjLWSUWQbpmxFEX6xF6dLXI0/2OstK 0OyQ6UhyiWnpkIlXUMyjLEGctlIk0yhyHlmKYh8yR2qSRNveBX77Xf/r4WFI1ynai0nLyuVU WcoMmUhCPTz7nA0Kv6VV7HvSEi4vW4qRVxTViOVrU120/GZhEyk3rzQQ8metOkpept98VMxW 9OtJtmPgt4jVG9WspWqQYg2GNYK9uVIvYs0/l0WnxQpJRBKXkZbHqUIiEySpbUVLdI71M3n1 x/I6KkRDQ6QGuTCAD8D0dC/SIAnjivsQ1E40UwJpR1Az3EAKZBWBzvLJGWsgYLqlkbYTClsJ 0BW9c8buEzDXUexsMIdgqKWTto8R4QhoNq066t3xCwTf51+J7ITE4wgqF3SUPeWGg2FkrFVk x+44BIzvRwgNYmz4Mkzo/e0yhf3A/KHUEZfiBGidfe4c3U7DZJcJ2Q0XrIT1ko+OPgh7w5fV KUcBiT3BMltHCIdjMHQPOx/BAxZm/tJCPhGsY1pa0H1gffSbSMDeMFpX6rgAcCcBfzr6xYKx HzTl3bRg3BXDwlN7irGRUzCsvybogwgGJ0udkwOhZ34WCTgbtG09ZDnaV71hQQFnQ2PlJFXt uHQbDDyctWHGpvvD05chQsQXdKVfxQLeC7cfPRZv1PVI3II8eI7nM1PCwoI5VVoiz2dnBWdx uUZk+3W97X8OvkC981EmhBkk2yIdKNAqXGllHp+faULAkDJ36dsEmyRNUuZf41TZ8Sp1Bseb 0HaGknlKjyXLFa44RZnLpXNcDqf67xKMi1chOnHSOy5iKiBoUaHdERsfWJ9x+DqbvnXmguJO 1xHzvYroHV9DfSY/l+zquxRaVfsk+Rcev/janOnvnrmkv9GTKp0eiDuUZCjvvlHUuHi8z7cg hrbu8fuyFhZZM3T4bs2nspVN1nO7jZKA6FXLGR+1aWdibLM6nTn/JqqpUuNWHP7gioziU5Wh AaSKV/4Dn3LYrHEDAAA= 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, 21 Feb 2018 14:37:49 -0000 --_000_HE1PR0702MB36252D23A798375FE12607FBC2CE0HE1PR0702MB3625_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KVHJ5aW5nIHRvIHBpY2sgdXAgdGhpcyB0aHJlYWQgYWdhaW4uDQoNCkRvIHdlIGhhdmUg c29tZSBraW5kIG9mIG1pbmltYWwgY29uc2Vuc3VzIGFyb3VuZCB0aGUgcHJvcG9zZWQgRUNOIGZ1 bmN0aW9uYWxpdHkgaW4gUVVJQyA/DQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJh ZnRzL3dpa2kvRUNOLWluLVFVSUMjc3VnZ2VzdGVkLWFkZGl0aW9ucy10by10by1iZWNvbWUtcmZj cw0KDQovSW5nZW1hcg0KDQoNCkZyb206IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0Fu dHdlcnApIFttYWlsdG86a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tXQ0KU2Vu dDogZGVuIDE0IGZlYnJ1YXJpIDIwMTggMTc6NDkNClRvOiBNaXJqYSBLw7xobGV3aW5kIDxtaXJq YS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPjsgSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1h ci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+DQpDYzogZWtpbm5lYXJAYXBwbGUuY29tOyBMdWJh c2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29v Z2xlLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBDaHJpc3RpYW4gSHVpdGVtYSA8aHVp dGVtYUBodWl0ZW1hLm5ldD47IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNz b25AZXJpY3Nzb24uY29tPg0KU3ViamVjdDogUkU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWln cmF0aW9uDQoNCkhpIE1pcmphLA0KV2h5IHdvdWxkIHlvdSBsaWtlIHRvIHNlZSB0aGUgZGlzdGlu Y3Rpb24/DQpJdCB3YXMgaW5kZWVkIGRlY2lkZWQgaW4gdGhlIHNpZGUgbWVldGluZyB0aGF0IHdl IHNob3VsZCBub3QgZm9yZXNlZSBleHRyYSBwcm90b2NvbCBjb21wbGV4aXR5IGZvciBzaWduYWxs aW5nIHRoYXQgdGhlIHJlY2VpdmVyIGNhbm5vdCByZWFkIHRoZSBlY24gYml0cy4NCkZvciBtZSB0 aGUgcmVhc29ucyB3ZXJlOiBJdCBpcyBub3QgYSBkZXNpcmVkIHNpdHVhdGlvbiB3aGljaCB3aWxs IGhvcGVmdWxseSBkaXNhcHBlYXIgaW4gdGhlIGZ1dHVyZSwgYW5kIEkgZG9uJ3QgdGhpbmsgaXQg aXMgc28gdXNlZnVsIGZvciBhIHNlbmRlciB0byBrbm93LiBXZSBub3cgYXNzdW1lIHJlYWRpbmcg MDAgYml0cyBhbmQgZWNobyBhbGwgY291bnRlcnMgdW5pbmNyZW1lbnRlZCB3aXRoIDAgdmFsdWVz IGluIHRoYXQgY2FzZSwganVzdCBhcyBpZiB0aGUgcGF0aCBibGVhY2hlcyBpdC4gSWYgd2UgbWFr ZSBhbiBleHBsaWNpdCBwcm90b2NvbCBleGNoYW5nZSBmb3IgaXQsIGl0IGZlZWxzIGxpa2UgaXQg aXMgYW4gZXh0cmEgZmVhdHVyZSA7LSkuIEFsc28gcGVvcGxlIG1pZ2h0IHN0YXJ0IG1ha2luZyB0 aGVpciBjb25nZXN0aW9uIGNvbnRyb2wgbW9yZSBjb21wbGV4IHdpdGggdXAgdG8gMiBtb3JlIGNv bmRpdGlvbmFsIHBhcmFtZXRlcnMgKHNlbmRlci1jYW5ub3Qtc2V0LWVjbiBhbmQgcmVjZWl2ZXIt Y2Fubm90LXJlYWQtZWNuIGJvb2xlYW5zLCBuZXh0IHRvIG5vLWVjbikuIE5vdCB0byBtZW50aW9u IGV4dHJhIGludGVyb3AgdGVzdGNhc2VzIHdpdGggc3VjaCBzZW5kZXIncy9yZWNlaXZlcidzIGV4 dHJhIGZ1bmN0aW9uYWxpdHkuDQpUbyBtYWtlIHlvdXIgY29kZSBzaW1wbGUgYW5kIHBsYXRmb3Jt IGluZGVwZW5kZW50LCBub3QgYmVpbmcgYWJsZSB0byBzZXQvcmVhZCBlY2hvIGJpdHMgc2hvdWxk IGJlIGludmlzaWJsZSB1bnRpbCB0aGUgcG9pbnQgb2YgdGhlIG1pc3Npbmcgc29ja2V0IEFQSSBj YWxsLCB3aGljaCB3aWxsIG1vc3QgcHJvYmFibHkgaGF2ZSBjb25kaXRpb25hbCBjb21waWxlciBk aXJlY3RpdmVzIHBlciBwbGF0Zm9ybSBhdCB0aGF0IHBvaW50Lg0KU28gY29uY2x1c2lvbiB3YXM6 IEFueSBoaWdoZXIgbGF5ZXIgcHJvdG9jb2wgY29kZSBzaG91bGQgbm90IG1ha2UgYW55IGRpc3Rp bmN0aW9uIGJldHdlZW4gaG9zdCBpbmFiaWxpdHkgYW5kIHBhdGggYmxlYWNoaW5nLCBhbmQgd2Ug b25seSBoYXZlIGZ1bmN0aW9uYWxpdHkgZm9yIGdlbmVyYWwgImVuZDJlbmQgZWNuIGluYWJpbGl0 eSIuDQpBZ3JlZWQgdGhhdCB0aGUgcmVjZWl2ZXIgY29kZSBzaG91bGQgYmUgaW5kZXBlbmRlbnQg ZnJvbSBob3cgZWNuIGlzIHVzZWQuIFRoaXMgaXMgdGhlIGNhc2Ugbm93LiBGb3IgdGhlIHJlY2Vp dmVyIHdlIG9ubHkgaW5jcmVtZW50IGFuZCBlY2hvIHRoZSBjb3VudGVycyBhbGwgdGhlIHRpbWUu IFRoYXQncyBpdCwgdmVyeSBzaW1wbGUuIE9ubHkgdGhlIHNlbmRlciBkZXRlcm1pbmVzIGhvdyBl Y24gY2FwYWJpbGl0eSBpcyBjaGVja2VkIGFuZCBob3cgZWNuIGlzIHVzZWQuDQpNYXliZSBhbHNv IGEgZ29vZCBwb2ludCB0aGF0IHRoZSBjdXJyZW50IGNhcGFiaWxpdHkgY2hlY2sgaXMgdGhlIG1p bmltYWw/PyBBbmQgbmVlZHMgc29tZSBleHRyYSBjaGVja3M/DQpSZWdhcmRzLA0KS29lbi4NCg0K T3V0bG9vayB2b29yIEFuZHJvaWQ8aHR0cHM6Ly9ha2EubXMvZ2hlaTM2PiBkb3dubG9hZGVuDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBJbmdlbWFyIEpvaGFuc3Nv biBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTxtYWlsdG86aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb20+Pg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNCwgMjAx OCAyOjA4OjMwIFBNDQpUbzogTWlyamEgS8O8aGxld2luZA0KQ2M6IERlIFNjaGVwcGVyLCBLb2Vu IChOb2tpYSAtIEJFL0FudHdlcnApOyBla2lubmVhckBhcHBsZS5jb208bWFpbHRvOmVraW5uZWFy QGFwcGxlLmNvbT47IEx1YmFzaGV2LCBJZ29yOyBJYW4gU3dldHQ7IFFVSUMgV0c7IENocmlzdGlh biBIdWl0ZW1hOyBJbmdlbWFyIEpvaGFuc3NvbiBTDQpTdWJqZWN0OiBSRTogRUNOIGluIFFVSUMg Y29ubmVjdGlvbiBtaWdyYXRpb24NCg0KSGkNCg0KSSBhdHRhY2ggdGhlIG1pbnV0ZXMgZnJvbSB0 aGUgc2lkZSBtZWV0aW5nIGluIFNpbmdhcG9yZSwgSSBiZWxpZXZlIHRoYXQgdGhleSB3ZXJlIG9u bHkgcG9zdGVkIG9uIHRoZSBlY24tcXVpYyBtYWlsaW5nIGxpc3Qg4pi5IC4NCg0KSSBhZ3JlZSB0 aGF0IHRoZSBzZW5kZXIvcmVjZWl2ZWQgaXNzdWVzIGFyZSBwcm9iYWJseSBrbm93biBhLXByaW9y eSBhbmQgaWYgYSBzZW5kZXIgZG9lcyBrbm93IHRoYXQgaXRzIE9TIHN0YWNrIGRvZXMgbm90IGhh dmUgdGhlIG5lY2Vzc2FyeSBBUEkgc3VwcG9ydCBmb3IgRUNOIHRoZW4gaXQgZG9lcyBub3QgbWFr ZSBtdWNoIHNlbnNlIHRvIHRyeSBpdC4NCg0KL0luZ2VtYXINCg0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IE1pcmphIEvDvGhsZXdpbmQgW21haWx0bzptaXJqYS5rdWVo bGV3aW5kQHRpay5lZS5ldGh6LmNoXQ0KPiBTZW50OiBkZW4gMTMgZmVicnVhcmkgMjAxOCAxMzoy OQ0KPiBUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj4NCj4gQ2M6IERl IFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApIDxrb2VuLmRlX3NjaGVwcGVyQG5v a2lhLQ0KPG1haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLSUwYj4+IGJlbGwtbGFicy5jb20+ OyBla2lubmVhckBhcHBsZS5jb208bWFpbHRvOmVraW5uZWFyQGFwcGxlLmNvbT47IEx1YmFzaGV2 LCBJZ29yDQo+IDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29t Pj47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xl LmNvbT4+OyBRVUlDIFdHDQo+IDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj47 IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1 aXRlbWEubmV0Pj4NCj4gU3ViamVjdDogUmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0 aW9uDQo+DQo+IEhpIEluZ2VtYXIsDQo+DQo+IHNlZSBiZWxvdy4NCj4NCj4gPiBBbSAxMi4wMi4y MDE4IHVtIDIyOjExIHNjaHJpZWIgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA8aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24u Y29tPj46DQo+ID4NCj4gPiBIaQ0KPiA+DQo+ID4gUGxlYXNlIHNlZSBpbmxpbmUNCj4gPg0KPiA+ IEJSDQo+ID4gSW5nZW1hcg0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+IEZyb206IE1pcmphIEvDvGhsZXdpbmQgW21haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5l ZS5ldGh6LmNoXQ0KPiA+PiBTZW50OiBkZW4gMTIgZmVicnVhcmkgMjAxOCAxNjoyNg0KPiA+PiBU bzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208 bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj4NCj4gPj4gQ2M6IERlIFNj aGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApIDxrb2VuLmRlX3NjaGVwcGVyQG5va2lh LQ0KPG1haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLSUwYj4+ID4+IGJlbGwtbGFicy5jb20+ OyBla2lubmVhckBhcHBsZS5jb208bWFpbHRvOmVraW5uZWFyQGFwcGxlLmNvbT47IEx1YmFzaGV2 LCBJZ29yDQo+ID4+IDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWku Y29tPj47IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29v Z2xlLmNvbT4+OyBRVUlDIFdHDQo+ID4+IDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYu b3JnPj47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0 ZW1hQGh1aXRlbWEubmV0Pj4NCj4gPj4gU3ViamVjdDogUmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rp b24gbWlncmF0aW9uDQo+ID4+DQo+ID4+IEhpIEluZ2VtYXIsDQo+ID4+DQo+ID4+IHR3byBwb2lu dHMuDQo+ID4+DQo+ID4+IEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBiZSBhcyBleHBsaWNp dCBhcyBwb3NzaWJsZSBoZXJlLA0KPiA+PiB0aGVyZWZvcmUgSSB3b3VsZCBwcmVmZXIgaWYgYW4g ZW5kcG9pbnQgdGhhdCBrbm93cyB0aGF0IGl0IGNhbiBub3QNCj4gPj4gYWNjZXNzIHRoZSBFQ04g SVAgYml0cyBpbmRpY2F0ZXMgdGhpcyBkaXJlY3RseSBpbiB0aGUgaGFuZHNoYWtlLiBJbg0KPiA+ PiB0aGlzIGNhc2Ugbm8gZnVydGhlciB0ZXN0aW5nIGlzIG5lZWRlZC4NCj4gPiA8SUo+IFllcywg dGhpcyB3YXMgdGhlIG9yaWdpbmFsIGlkZWEsIHdlIGRpc2N1c3NlZCB0aGlzIGF0IHRoZSBFQ04N Cj4gPiBRVUlDIHNpZGUgbWVldGluZyB0aG91Z2ggYW5kIGFmdGVyd2FyZHMgYW5kIGFzIGZhciBh cyBJIHVuZGVyc3RhbmQgaXQsDQo+ID4gdGhlcmUgd2FzIGEgY29uc2Vuc3VzIHRoYXQgaXQgd2Fz IHVubmVjZXNzYXJpbHkgY29tcGxpY2F0ZWQuIFNvIHdlDQo+ID4gc2VsZWN0ZWQgYSBtZXRob2Qg d2hlcmUgd2UganVzdCB2ZXJpZnkgdGhhdCB0aGUgRUNUKDApLEVDVCgxKSxDRQ0KPiA+IGNvdW50 ZXJzIGhhdmUgcmVhc29uYWJsZSB2YWx1ZXMuIElmIHRoYXQgaXMgbm90IHRoZSBjYXNlLCB0aGVu IGl0IGlzDQo+ID4gYW4gaW5kaWNhdGlvbiB0aGF0IGVpdGhlciB0aGUgcGF0aCBvciB0aGUgZW5k cG9pbnRzIGRvIG5vdCBzdXBwb3J0DQo+ID4gRUNOLiA8L0lKPg0KPg0KPiBJIGNoZWNrZWQgdGhl IG1pbnV0ZXMgYW5kIGNvdWxkIG5vdCByZWFsbHkgZmluZCBhIGNvbmNsdXNpb24gdGhlcmUuIEkg YWdyZWUNCj4gdGhhdCB0aGVyZSBzaG91bGQgYmUgbm8gbmVnb3RpYXRpb24gaW4gdGhlIGhhbmRz aGFrZSAoYm90aCBlbmRwb2ludCBuZWVkDQo+IHRvIGltcGxlbWVudCB0aGUgRUNOIGxvZ2ljIGFz IHBhcnQgb2YgdjEpIGJ1dCB3aGF0IHdvdWxkIGJlIGhlbHBmdWwgaXMgdG8gbGV0DQo+IHRoZSBv dGhlciBlbmQga25vdyBpZiB5b3UgYWxyZWFkeSBrbm93IHRoYXQgeW91IG5ldmVyIHdpbGwgYmUg YWJsZSB0bw0KPiBwcm92aWRlIGZlZWRiYWNrIGJlY2F1c2UgeW91IGNhbiBqdXN0IG5vdCByZWFk IHRoZSBiaXRzIGluIHRoZSBJUCBoZWFkZXIuDQo+IFRoYXQgaXMgbm90IGNvbXBsaWNhdGVkIGF0 IGFsbC4NCj4NCj4gSSB0aGluayB3aGF0IHdlIG5lZWQgdG8gc3BlY2lmeSBpbiB2MSBpcyBhIHdh eSB0byBwcm92aWRlIEVDTiBmZWVkYmFjayAob3INCj4gaW5kaWNhdGUgdGhhdCB0aGlzIGlzIG5v dCBwb3NzaWJsZSkuIEhvd2V2ZXIsIHdlIGFjdHVhbGx5IHdvdWxkIG5vdCBuZWVkIHRvDQo+IHNh eSBhbnl0aGluZyBhYm91dCBob3cgRUNOIHNob3VsZCBiZSB1c2VkLiBUaGF04oCZcyBhIHNlbmRl ciBzaWRlIGRlY2lzaW9uLg0KPiBBcyBsb25nIGFzIHlvdSBjYW4gZ2V0IGZlZWRiYWNrLCB3ZSBh cmUgZmxleGlibGUgaW4gaG93IHRvIHVzZSBhbmQgdGVzdCBFQ04gaW4NCj4gdjEgb3IgYW55dGlt ZSBsYXRlci4gT2YgY291cnNlIGl0IHdvdWxkIGJlIG5pY2UgdG8gcHJvdmlkZSBzb21lIGRlZmF1 bHQNCj4gcmVjb21tZW5kYXRpb25zIHdpdGggc29tZSBlYXN5IGZhbGxiYWNrIGxvZ2ljIGJ1dCB0 aGF0J3MgdGhlIHBhcnQgd2UgY2FuDQo+IGV4cGVyaW1lbnQgd2l0aCBhbmQgY2hhbmdlIGFueSB0 aW1lIHdpdGhvdXQgYW55IG5lZWQgdG8gY2hhbmdlIHRoZQ0KPiBwcm90b2NvbCBzcGVjIChhcyBs b25nIGFzIEVDTiBmZWVkYmFjayBpcyBwcm92aWRlZCwgd2hlbiBFQ04gaXMgdXNlZCBieSB0aGUN Cj4gc2VuZGVyKS4NCj4NCj4gPg0KPiA+Pg0KPiA+PiBGdXJ0aGVyLCB0aGUgcGF0aCB0ZXN0aW5n IGl0c2VsZiBpcyBpbmRlcGVuZGVudCBvZiBRVUlDIGFuZCBjYW4gYmUNCj4gPj4gdXNlZCBmb3Ig YW55IHByb3RvY29sLiBNb3Jlb3ZlciwgaXTigJlzIG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBqdXN0 DQo+ID4+IHRlc3RpbmcgRUNULiBJIGd1ZXNzIHRoZSBnZW5lcmFsIGFkdmljZSBoZXJlIGlzIHRv IHJlbWVtYmVyIHdoaWNoDQo+ID4+IGNvZGVwb2ludHMgd2VyZSBzZW5kIGFuZCBjb21wYXJlIHRo aXMgdG8gdGhlIGZlZWRiYWNrIHByb3ZpZGVkLiBJZg0KPiA+PiBkaXNjcmVwYW5jaWVzIGFyZSBv YnNlcnZlZCB0aGF0IGluZGljYXRlIHRoYXQgYSBtaWRkbGVib3ggaGFzIGNoYW5nZWQNCj4gPj4g dGhlc2UgYml0cywgYWxsIHBhY2tldHMgc2hvdWxkIGJlIG1hcmtlZCBhcyBuby1FQ1QgKHdoaWxl IGFkZGl0aW9uYWwNCj4gPj4gdGVzdGluZyBNQVkgYmUgcGVyZm9ybWVkIGF0IGFueSBsYXRlciBw b2ludCBpbiB0aW1lKS4gSG93ZXZlciwgaG93DQo+ID4+IGV4YWN0bHkgdGhpcyB0ZXN0aW5nIHNo b3VsZCBsb29rIGxpa2UsIHNob3VsZCBub3QgYmUgc3BlY2lmaWVkIGluIHRoaXMgZG9jDQo+IChi dXQgbW9yZSBnZW5lcmFsbHkpLg0KPiA+IDxJSj4gSXQgaXMgcG9zc2libGUgdGhhdCB0aGUgYWN0 dWFsIHBhdGggdmVyaWZpY2F0aW9uIGNhbiBiZSBwdXQgYXMgYQ0KPiA+IHNlcGFyYXRlIGRvY3Vt ZW50LCBub3Qgc3VyZSBpZiB0aGF0IGlzIGFjY2VwdGVkIGJ5IHRoZSBncm91cCBvciBpdCBpcw0K PiA+IGRlc2lyZWQgd2l0aCBhIG1vcmUgZWxhYm9yYXRlIGRlc2NyaXB0aW9uIGRpcmVjdGx5IGlu IHRoZSBRVUlDIGRyYWZ0cy4NCj4gPiBBcyByZWdhcmRzIHRvIHZlcmlmaWNhdGlvbiwgSSBkbyBi ZWxpZXZlIHRoYXQgdGhlIHByb3Bvc2VkIGNvdW50ZXJzDQo+ID4gc2hvdWxkIGJlIGFibGUgdG8g ZGV0ZWN0IGJsZWFjaGluZywgYWNjaWRlbnRhbCByZW1hcmtpbmcgZnJvbSBFQ1QoMCkNCj4gPiB0 byBFQ1QoMSkgYW5kIGFsc28gY2FzZXMgd2hlcmUgcGFja2V0cyBhcmUgbm90IENFIG1hcmtlZCBh dCBhbGwNCj4gPiBkZXNwaXRlIG90aGVyIHNpZ25zIG9mIGNvbmdlc3Rpb24gPC9JSj4NCj4NCj4g V2UgdHJpZWQgdG8gZGVzaWduIGEgbW9yZSBlbGFib3JhdGVkIHRlc3Rpbmcgc2NoZW1lIHdoZXJl IHdlIHdvdWxkIHNlbmQNCj4gMyBFQ1QwLCB0aGUgMyBFQ1QxLCBhbmQgdGhlIDMgQ0UgKHdoaWNo IHdlIHdvdWxkIG9mIGNhdXNlIG5vdCBjb3VudCBhcyBhDQo+IGNvbmdlc3Rpb24gaW5kaWNhdGlv biBhcyB0aGUgQ0Ugd2FzIHNldCBieSB0aGUgc2VuZGVyKS4gSG93ZXZlciwgdGhpcyB3YXMNCj4g bW9zdGx5IHRvIGRldGVjdCBibGFjay13aGFsaW5nIHdoaWNoIGlzIHByb2JhYmx5IGxlc3MgYSBj b25jZXJuIHRoYW4gcmUtDQo+IG1hcmtpbmcuIEkgdGhpbmsgdG9kYXkgdGhlIG1vc3QgY29tbW9u IGNhc2UgaXQgdGhhdCB0aGUgYml0cyB3aWxsIGJlIHNldCB0bw0KPiB6ZXJvcyB3aGljaCBpcyBv bmx5IGEgcHJvYmxlbSB3aGVuIHRoZXJlIHdhcyBzb21lIENFIG1hcmtpbmcgcHJldmlvdXNseQ0K PiBvbiB0aGUgcGF0aCB0aGF0IHRoZW4gd291bGQgZ2V0IGxvc3QuIFRodXMgaW4gdGhpcyBjYXNl IGl0IHdvdWxkIGJlDQo+IHJlY29tbWVuZCB0byBub3QgdXNlIEVDTi9ub3Qgc2V0IHBhY2tldHMg YXMgRUNUIGF0IHNlbmRlciBzaWRlLg0KPg0KPiBIb3dldmVyLCBhcyBJIHNhaWQgYWJvdmUsIHdl IHByb2JhYmx5IHNob3VsZCBtYWtlIHJlY29tbWVuZGF0aW9uIGhvdyB0bw0KPiB1c2UgRUNOIGJ5 IGRlZmF1bHQgYnV0IG5lZWQgdG8gbGVhdmUgcm9vbSBmb3Igb3RoZXIgdXNhZ2UvdGVzdGluZyBz Y2hlbWVzLg0KPiBCdXQgYWZ0ZXIgYWxsIHRoZSByZWNlaXZlciBiZWluZyBub3QgYWJsZSB0byBy ZWFkIHRoZSBiaXRzIGFuZCByZW1hcmtpbmcgb24gdGhlDQo+IHBhdGggYXJlIHRvIGRpZmZlcmVu dCB0aGluZ3MgYW5kIHNob3VsZCBub3QgYmUgbWl4ZWQgdXAuIElmIHRoZSBzZW5kZXIgY2FuDQo+ IG5vdCByZWFkIHRoZSBiaXRzIHRoaXMgaXMga25vdyBhIHByaW9yaSBhbmQgdGhlcmUgaXMgbm8g YW1iaWd1aXR5IHRoYXQgbmVlZHMgdG8NCj4gYmUgdGVzdGVkLiBTbyB3aHkgbm90IHNpZ25hbCBp dCBkaXJlY3RseS4gVGhlIHF1ZXN0aW9uIGlmIHRoZSBzZW5kZXIgY2FuIHdyaXRlDQo+IEVDTiBk b2VzIG5vdCBuZWVkIHRvIGJlIGNvbW11bmljYXRlZC4gVGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBp biB0aGUNCj4gc2VuZGVyIGRlY2lkZWQgdG8gbm90IHVzZSBFQ04gb3IgaXQganVzdCBjYW4gbm90 IHVzZSBpdDsgaW4gYm90aCBjYXNlcyBpdCBpcyBub3QNCj4gbmVjZXNzYXJ5IHRvIHNlbmQgRUNO IGZlZWRiYWNrIGJhY2suIE9ubHkgaWYgYSBub24tbm9uLUVDVCBpcyBvYnNlcnZlZCBhdA0KPiB0 aGUgcmVjZWl2ZXIsIEVDTiBmZWVkYmFjayBuZWVkcyB0byBiZSBwcm92aWRlZC4gSG93ZXZlciwg a25vd2luZyB0aGF0DQo+IHRoZSByZWNlaXZlciBjYW7igJl0IG5vdCBwcm92aWRlIGZlZWRiYWNr IGlzIGltcG9ydGFudCBiZWNhdXNlIGluIHRoaXMgY2FzZSB0aGUNCj4gc2VuZGVyIE1VU1Qgbm90 IHNldCB0aGUgcGFja2V0cyBhcyBFQ1QgYXMgaXQgd2lsbCBub3QgYmUgYWJsZSB0byByZWFjdCB0 byB0aGF0DQo+IHNpZ25hbC4gVGVzdGluZyB0aGUgcGF0aCBpbiBpbmRlcGVuZGVudCBvZiB0aGF0 Lg0KPg0KPiBNaXJqYQ0KPg0KPg0KPiA+DQo+ID4NCj4gPj4NCj4gPj4gTWlyamENCj4gPj4NCj4g Pj4NCj4gPj4+IEFtIDA5LjAyLjIwMTggdW0gMDg6MzQgc2NocmllYiBJbmdlbWFyIEpvaGFuc3Nv biBTDQo+ID4+IDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTxtYWlsdG86aW5nZW1h ci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+PjoNCj4gPj4+DQo+ID4+PiBIaSBFcmljLCBLb2Vu ICsgb3RoZXJzDQo+ID4+Pg0KPiA+Pj4gVGhhbmtzIGZvciB0aGUgY29tbWVudHMgYW5kIHRoZSB1 cGRhdGUuIEEgcXVlc3Rpb24gdG8gdGhlIHJlc3Qgb2YNCj4gPj4+IHRoZQ0KPiA+PiBhdWRpZW5j ZSwgZG9lcyB0aGUgcHJlc2VudGVkIHRleHQgZXhwbGFpbiBzdWZmaWNpZW50bHkgZW5vdWdoIGhv dyBFQ04NCj4gPj4gd29ya3Mgd2l0aCBjb25uZWN0aW9uIG1pZ3JhdGlvbiA/DQo+ID4+PiBodHRw czovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvRUNOLWluLVFVSUMjdHJhbnNw b3J0LQ0KPiA+PiBkcmFmdC1jb25uZWN0aW9uLW1pZ3JhdGlvbg0KPiA+Pj4NCj4gPj4+DQo+ID4+ PiAvSW5nZW1hcg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBGcm9tOiBEZSBTY2hlcHBlciwgS29lbiAo Tm9raWEgLSBCRS9BbnR3ZXJwKQ0KPiA+PiBbbWFpbHRvOmtvZW4uZGVfc2NoZXBwZXJAbm9raWEt YmVsbC1sYWJzLmNvbV0NCj4gPj4+IFNlbnQ6IGRlbiAyIGZlYnJ1YXJpIDIwMTggMTU6NDQNCj4g Pj4+IFRvOiBla2lubmVhckBhcHBsZS5jb208bWFpbHRvOmVraW5uZWFyQGFwcGxlLmNvbT47IElu Z2VtYXIgSm9oYW5zc29uIFMNCj4gPj4gPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29t PG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+DQo+ID4+PiBDYzogUVVJ QyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBJYW4gU3dldHQgPGlh bnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PjsNCj4gPj4gTHVi YXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5j b20+PjsgQ2hyaXN0aWFuIEh1aXRlbWENCj4gPj4gPGh1aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRv Omh1aXRlbWFAaHVpdGVtYS5uZXQ+Pg0KPiA+Pj4gU3ViamVjdDogUkU6IEVDTiBpbiBRVUlDIGNv bm5lY3Rpb24gbWlncmF0aW9uDQo+ID4+Pg0KPiA+Pj4gSGkgSW5nZW1hciwNCj4gPj4+DQo+ID4+ PiBJIGFsc28gcmVhZCBhZ2FpbiB0aHJvdWdoIHRoZSBkb2N1bWVudCwgYW5kIGhhZCBmb2xsb3dp bmcgY29tbWVudHM6DQo+ID4+Pg0KPiA+Pj4gSSByZXBsYWNlZDoNCj4gPj4+IOKAnFRoZSBBQ0tf RUNOIGZyYW1lIGlzIHVzZWQgdG8gY29udmV5IEFDS3Mgd2hlbiB0aGUgRUNOIGNhcGFiaWxpdHkN Cj4gPj4gZXhjaGFuZ2UgY29uY2x1ZGVzIHRoYXQgRUNOIHNob3VsZCBiZSB1c2VkIGZvciB0aGUg Z2l2ZW4gY29ubmVjdGlvbi7igJ0NCj4gPj4+IE9yaWdpbmFsbHkgaXQgc291bmRzIGFzIGlmIHRo ZSBjb3VudGVycyBhcmUgbm90IGVjaG9lZCBhbnltb3JlIGlmDQo+ID4+PiB0aGUgRUNODQo+ID4+ IGNhcGFiaWxpdHkgY2hlY2sgZmFpbHMuIEkgYXNzdW1lIHRoaXMgd2FzIG5vdCB0aGUgaW50ZW50 aW9uLCBidXQgaWYNCj4gPj4gaXQgaXM6IEZpcnN0LCB3ZSBkb27igJl0IGhhdmUgYSBwcm90b2Nv bCBvciBkZWNpc2lvbiBwb2ludCBkZWZpbmVkIHdoZW4NCj4gPj4gdGhhdCBjb25kaXRpb24gaXMg bWV0IChzZW5kZXIgc2hvdWxkIGxldCB0aGUgcmVjZWl2ZXIga25vdyBpbiB0aGUNCj4gPj4gbmV4 dCBwYWNrZXQpLCBhbmQgc2Vjb25kLCBJIHdvdWxkIGFsd2F5cyBzZW5kIHRoZSBlY2hvLCBhcyB3 ZSBtaWdodA0KPiA+PiDigJx0cnkgYWdhaW4gbGF0ZXIgKHdpdGggYW5vdGhlciBFQ1Q/KeKAnSwg b3IgbWlnaHQgZGVjaWRlIHRvIHVzZSB0aGUgRUNOIGJpdHMNCj4gZGlmZmVyZW50bHkgbGF0ZXIu DQo+ID4+Pg0KPiA+Pj4gSSBhbHNvIGNoYW5nZWQgdGhlIHRleHQgYXJvdW5kIHRoZSBjb25uZWN0 aW9uIG1pZ3JhdGlvbiwgSSB0aGluaw0KPiA+Pj4gYmVmb3JlIEVyaWMNCj4gPj4gcmV2aWV3ZWQg aXQuIEkgbWFkZSBpdCBzdWNoIHRoYXQgZXZlcnkgbmV3IHBhdGggY3JlYXRlcyBhIG5ldw0KPiA+ PiBjb25uZWN0aW9uIHN0YXRlIHdpdGggYW4gaW5pdGlhbGl6ZWQgY29uZ2VzdGlvbiBjb250cm9s IHN0YXRlIGFuZCBFQ04NCj4gPj4gY291bnRlcnMgKGF0IGxlYXN0IEVDTiBjb3VudGVycyByZXNl dCB0byAwcykuIE5vdCBzdXJlIGlmIHRoaXMNCj4gPj4gbWF0Y2hlcyB3aXRoIHRoZSBvdGhlciBz ZWN0aW9ucyBpbiB0aGUgUVVJQyBkcmFmdC4NCj4gPj4+DQo+ID4+PiBJIGFsc28gaGFkIHRoZSB0 aG91Z2h0IHdoZXRoZXIgaXQgd2FzIHJlYWxseSBuZWVkZWQgdG8gaGF2ZSB0aGUgMg0KPiA+Pj4g Y2FzZXMuIEkNCj4gPj4gYWdyZWUgd2Ugc2hvdWxkIHNpbXBsaWZ5LCBieSBqdXN0IHN0YXJ0aW5n IG92ZXIgYW5kIGRvaW5nIHRoZSBjaGVjaw0KPiA+PiB1bmNvbmRpdGlvbmFsbHkgd2hldGhlciBp dCB3YXMgc3VjY2Vzc2Z1bCBvciBub3QgaW4gYSBwcmV2aW91cyBwYXRoLg0KPiA+Pj4NCj4gPj4+ IFJlZ2FyZHMsDQo+ID4+PiBLb2VuLg0KPiA+Pj4NCj4gPj4+IEZyb206IGVraW5uZWFyQGFwcGxl LmNvbTxtYWlsdG86ZWtpbm5lYXJAYXBwbGUuY29tPiBbbWFpbHRvOmVraW5uZWFyQGFwcGxlLmNv bV0NCj4gPj4+IFNlbnQ6IEZyaWRheSwgRmVicnVhcnkgMiwgMjAxOCAxMjowMiBBTQ0KPiA+Pj4g VG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29t PG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+DQo+ID4+PiBDYzogUVVJ QyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBJYW4gU3dldHQgPGlh bnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PjsNCj4gPj4gTHVi YXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5j b20+PjsgQ2hyaXN0aWFuIEh1aXRlbWENCj4gPj4gPGh1aXRlbWFAaHVpdGVtYS5uZXQ8bWFpbHRv Omh1aXRlbWFAaHVpdGVtYS5uZXQ+PjsgRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50 d2VycCkNCj4gPj4gPGtvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbTxtYWlsdG86 a29lbi5kZV9zY2hlcHBlckBub2tpYS1iZWxsLWxhYnMuY29tPj4NCj4gPj4+IFN1YmplY3Q6IFJl OiBFQ04gaW4gUVVJQyBjb25uZWN0aW9uIG1pZ3JhdGlvbg0KPiA+Pj4NCj4gPj4+IEhpIEluZ2Vt YXIsDQo+ID4+Pg0KPiA+Pj4gVGhpcyBnZW5lcmFsbHkgbG9va3MgZ29vZCB0byBtZSENCj4gPj4+ IEEgZmV3IHF1ZXN0aW9ucyBhbmQgb2JzZXJ2YXRpb25zOg0KPiA+Pj4NCj4gPj4+IFRoZXJlIGFy ZSB0d28gdW5pcXVlIGNhc2VzOg0KPiA+Pj4NCj4gPj4+ICAgICAgICAgICAgICAgIOKAoiBFQ04g Y2FwYWJpbGl0eSBjaGVjayBzdWNjZXNzZnVsIGF0IGluaXRpYWwgY29ubmVjdGlvbiBzZXR1cA0K PiA+Pj4gICAgICAgICAgICAgICAg4oCiIEVDTiBjYXBhYmlsaXR5IGNoZWNrIGZhaWxlZCBhdCBp bml0aWFsIGNvbm5lY3Rpb24NCj4gPj4+IHNldHVwDQo+ID4+Pg0KPiA+Pj4gQXJlIHRoZXNlIGFj dHVhbGx5IGFueSBkaWZmZXJlbnQgaW4gdGVybXMgb2YgYWN0aW9uIHRha2VuIGJ5IGFuIGVuZHBv aW50Pw0KPiA+Pj4gSXQgc2VlbXMgbGlrZSBvbiB0aGUgbmV3IG5ldHdvcmsgcGF0aCB0aGUgZW5k cG9pbnQgd291bGQgZ28gdGhyb3VnaA0KPiA+Pj4gdGhlDQo+ID4+IHNhbWUgcHJvY2VzcyBvZjog KGEpIHZlcmlmeSBFQ04gY2FwYWJpbGl0eSBhbmQgaWYgc3VjY2Vzc2Z1bCB0bw0KPiA+PiB3aGF0 ZXZlciBkZWdyZWUgdGhlbiAoYikgcnVuIHRoZSByZXN0IG9mIHRoZSBFQ04gbWFjaGluZXJ5IGFz DQo+IGFwcHJvcHJpYXRlLg0KPiA+Pj4NCj4gPj4+IEluIG90aGVyIHdvcmRzLCBhcyBsb25nIGFz IHlvdSBhbGxvdyBwZW9wbGUgdG8gc3RhcnQgdXNpbmcgRUNOIHVwb24NCj4gPj4gbWlncmF0aW9u IChpbiBvdGhlciB3b3JkcywgdG8gYWxsb3cgc3RhcnRpbmcgaXQgYWZ0ZXIgdGhlIGluaXRpYWwN Cj4gPj4gY29ubmVjdGlvbiBlc3RhYmxpc2htZW50KSwgdGhlbiB0aGUgc3BlY2lmaWNzIGZvciBF Q04gd2l0aCBtaWdyYXRpb24NCj4gPj4gaXMgZXNzZW50aWFsbHkgb25lIHN0YXRlbWVudCwgd2hp Y2ggaXMg4oCcZG8gdGhlIEVDTiBwcm9jZXNzIG9uIGVhY2gNCj4gPj4gbmV3IG5ldHdvcmsgcGF0 aCB0aGF0IHlvdSB1c2XigJ0uDQo+ID4+Pg0KPiA+Pj4gQ29ubmVjdGlvbiBtaWdyYXRpb24gaGFz IGltcGFjdCBvbiB0aGUgbnVtYmVyIG9mIHJlcG9ydGVkIENFIG1hcmtlZA0KPiA+PiBwYWNrZXRz LiBBIG5ldyBjb25uZWN0aW9uIHN0YXRlIHdpdGggbmV3IGNvbmdlc3Rpb24gY29udHJvbCBzdGF0 ZSBhbmQNCj4gPj4gRUNOIGNvdW50ZXJzIGlzIGluc3RhbnRpYXRlZCBhdCB0aGUgc2VuZGVyIGFu ZCByZWNlaXZlci4gVGhlIEVDTg0KPiA+PiBjb3VudGVycyBNVVNUIHN0YXJ0IGZyb20gemVybyBh Z2Fpbi4NCj4gPj4+DQo+ID4+PiBUaGlzIHNlZW1zIGZpbmUgdG8gbWUsIGl04oCZcyBpbmxpbmUg d2l0aCB0aGUgcmVzdCBvZiB0aGUgY29uZ2VzdGlvbg0KPiA+PiBjb250cm9sL2xvc3MgcmVjb3Zl cnkgc3RhdGUgdGhhdCBhbHNvIG5lZWRzIHRvIGJlIHJlc2V0IGZvciB0aGUgbmV3IHBhdGguDQo+ ID4+Pg0KPiA+Pj4gR2l2ZW4gdGhhdCBlYWNoIG1pZ3JhdGlvbiByZXF1aXJlcyBhdCBsZWFzdCBv bmUgZXhjaGFuZ2Ugb2YgcGFja2V0cw0KPiA+Pj4gYXQgdGhlDQo+ID4+IGJlZ2lubmluZyAoYXQg dGhlIHZlcnkgbGVhc3QgZm9yIGFkZHJlc3MgdmFsaWRhdGlvbiBmcm9tIHRoZSBzaWRlIG9mDQo+ ID4+IHRoZSBlbmRwb2ludCB0aGF0IGRpZG7igJl0IG1pZ3JhdGUpLCBpdCBzZWVtcyBsaWtlIHRo YXTigJlzIGFuIGV4Y2VsbGVudA0KPiA+PiBtb21lbnQgdG8gbWFyayB0aGUgcGFja2V0cyBhbmQg cGVyZm9ybSB0aGUgRUNOIGNhcGFiaWxpdHkgZGV0ZWN0aW9uLg0KPiA+PiBUaG9zZSBwYWNrZXRz IGFyZSBhbHNvIGxpa2VseSBwYWRkZWQsIGV0Yy4gc2ltaWxhciB0byBpbml0aWFsIHBhY2tldHMN Cj4gPj4gc2luY2UgdGhleeKAmXJlIG9uIGEgcHJldmlvdXNseSB1bnVzZWQgbmV0d29yayBwYXRo Lg0KPiA+Pj4NCj4gPj4+IEkgdGhpbmsgdGhlIGN1cnJlbnQgcHJvcG9zZWQgcmVxdWlyZW1lbnQg b2YganVzdCB1c2luZyB0aGUg4oCcZmlyc3TigJ0NCj4gPj4+IHBhY2tldHMNCj4gPj4gYW5kIG1h cmtpbmcgdGhvc2UgaXMgc3VmZmljaWVudCAoYW5kIGdvb2QgdG8gYXZvaWQgYW55IHJlcXVpcmVt ZW50IGFzDQo+ID4+IHRvIHdoaWNoIGZyYW1lcyBhcmUgY29udGFpbmVkIGluIHRob3NlIHBhY2tl dHMpLCBzaW5jZSB3ZSBhcmUgYWx3YXlzDQo+ID4+IGV4Y2hhbmdpbmcgcGFja2V0cyBpbiBib3Ro IGRpcmVjdGlvbnMgaW1tZWRpYXRlbHkgYWZ0ZXIgbWlncmF0aW9uLg0KPiA+Pj4NCj4gPj4+IFRo aXMgaGFzIHRoZSBhZGRlZCBiZW5lZml0IHN1Y2ggdGhhdCBhbnkgZW5kcG9pbnQg4oCccHJvYmlu Z+KAnSBwb3NzaWJsZQ0KPiA+PiBuZXR3b3JrIHBhdGhzIGNvdWxkIGluY2x1ZGUgdGhlIGJpdHMg bmVjZXNzYXJ5IHRvIGRldGVjdCBFQ04NCj4gPj4gY2FwYWJpbGl0eSBvbiB0aGUgcGF0aCBiZWlu ZyBwcm9iZWQsIHNvIGl0IGNvdWxkIGV2ZW4ga25vdyBiZWZvcmUNCj4gPj4gbWlncmF0aW5nIHdo ZXRoZXIgb3Igbm90IGl0IHdvdWxkIGJlIGFibGUgdG8gdXNlIEVDTiBvbiB0aGF0IG5ldyBwYXRo Lg0KPiA+Pj4NCj4gPj4+IFRoYW5rcywNCj4gPj4+IEVyaWMNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4N Cj4gPj4+DQo+ID4+PiBPbiBGZWIgMSwgMjAxOCwgYXQgMzowNyBBTSwgSW5nZW1hciBKb2hhbnNz b24gUw0KPiA+PiA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2Vt YXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gSGkNCj4g Pj4+IEkgaGF2ZSB3cml0dGVuIHVwIGRpZmZlcmVudCBhc3BlY3RzIG9mIGNvbm5lY3Rpb24gbWln cmF0aW9uIGFuZCBob3cNCj4gPj4+IGl0DQo+ID4+IHBsYXlzIHdpdGggRUNOLg0KPiA+Pj4gaHR0 cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1RVUlDI3RyYW5z cG9ydC0NCj4gPj4gZHJhZnQtY29ubmVjdGlvbi1taWdyYXRpb24NCj4gPj4+DQo+ID4+PiBBIGNh dmVhdC4uIEkgYW0gYSBiaXQgdW5zdXJlIGFib3V0IHRoZSBkZWZpbml0aW9uIG9mIGNvbm5lY3Rp b24gbWlncmF0aW9uDQo+IC4NCj4gPj4gTXkgaW50ZXJwcmV0YXRpb24gaXMgdGhhdCBhIGNsaWVu dCBtb3ZlcyB0byBhIG5ldyBJUCBhZGRyZXNzIGR1ZSB0bw0KPiA+PiBlLmcuIGEgTkFUIHJlYmlu ZCBvciBzd2l0Y2ggZnJvbSBXaUZpIHRvIGNlbGx1bGFyLCByaWdodCA/LiBJcyBhIG5ldw0KPiA+ PiBjb25uZWN0aW9uIGluc3RhbnRpYXRlZCBhdCBhIGNvbm5lY3Rpb24gbWlncmF0aW9uID8NCj4g Pj4+DQo+ID4+PiAvSW5nZW1hcg0KPiA+Pj4NCj4gPj4+ID09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCj4gPj4+IEluZ2VtYXIgSm9oYW5zc29uICBNLlNjLg0KPiA+Pj4gTWFzdGVy IFJlc2VhcmNoZXINCj4gPj4+DQo+ID4+PiBFcmljc3NvbiBSZXNlYXJjaA0KPiA+Pj4gTmV0d29y ayBQcm90b2NvbHMgJiBFMkUgUGVyZm9ybWFuY2UNCj4gPj4+IExhYnJhdG9yaWVncsOkbmQgMTEN Cj4gPj4+IDk3MSAyOCwgTHVsZcOlLCBTd2VkZW4NCj4gPj4+IFBob25lICs0Ni0xMDcxIDQzMDQy DQo+ID4+PiBTTVMvTU1TICs0Ni03MyAwNzggMzI4OQ0KPiA+Pj4gaW5nZW1hci5zLmpvaGFuc3Nv bkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0K PiA+Pj4gd3d3LmVyaWNzc29uLmNvbTxodHRwOi8vd3d3LmVyaWNzc29uLmNvbT4NCj4gPj4+DQo+ ID4+PiAgICAgICAgICAgICAgICAgWW91IGNhbid0IHN0YXJ0IGEgZmlyZSAgV29ycnlpbmcgJ2Jv dXQgeW91ciBsaXR0bGUNCj4gPj4+IHdvcmxkIGZhbGxpbmcgYXBhcnQNCj4gPj4+ICAgICAgICAg ICAgICAgQnJ1Y2UgU3ByaW5nc3RlZW4NCj4gPj4+ID09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0NCj4gPg0K --_000_HE1PR0702MB36252D23A798375FE12607FBC2CE0HE1PR0702MB3625_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJ IEVtb2ppIjt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5lbWFpbHF1b3RlLCBsaS5l bWFpbHF1b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHF1b3RlOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJYm9yZGVyOm5vbmU7DQoJ cGFkZGluZzowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ucnlpbmcg dG8gcGljayB1cCB0aGlzIHRocmVhZCBhZ2Fpbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG8g d2UgaGF2ZSBzb21lIGtpbmQgb2YgbWluaW1hbCBjb25zZW5zdXMgYXJvdW5kIHRoZSBwcm9wb3Nl ZCBFQ04gZnVuY3Rpb25hbGl0eSBpbiBRVUlDID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMv d2lraS9FQ04taW4tUVVJQyNzdWdnZXN0ZWQtYWRkaXRpb25zLXRvLXRvLWJlY29tZS1yZmNzIj5o dHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvRUNOLWluLVFVSUMjc3Vn Z2VzdGVkLWFkZGl0aW9ucy10by10by1iZWNvbWUtcmZjczwvYT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+L0luZ2VtYXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBEZSBTY2hlcHBlciwgS29l biAoTm9raWEgLSBCRS9BbnR3ZXJwKSBbbWFpbHRvOmtvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVs bC1sYWJzLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMTQgZmVicnVhcmkgMjAxOCAxNzo0 OTxicj4NCjxiPlRvOjwvYj4gTWlyamEgS8O8aGxld2luZCAmbHQ7bWlyamEua3VlaGxld2luZEB0 aWsuZWUuZXRoei5jaCZndDs7IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0O2luZ2VtYXIucy5qb2hh bnNzb25AZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gZWtpbm5lYXJAYXBwbGUuY29t OyBMdWJhc2hldiwgSWdvciAmbHQ7aWx1YmFzaGVAYWthbWFpLmNvbSZndDs7IElhbiBTd2V0dCAm bHQ7aWFuc3dldHRAZ29vZ2xlLmNvbSZndDs7IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7 OyBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7aHVpdGVtYUBodWl0ZW1hLm5ldCZndDs7IEluZ2VtYXIg Sm9oYW5zc29uIFMgJmx0O2luZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSRTogRUNOIGluIFFVSUMgY29ubmVjdGlvbiBtaWdyYXRpb24gPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhpIE1pcmphLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPldoeSB3b3VsZCB5b3UgbGlrZSB0byBzZWUgdGhl IGRpc3RpbmN0aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkl0 IHdhcyBpbmRlZWQgZGVjaWRlZCBpbiB0aGUgc2lkZSBtZWV0aW5nIHRoYXQgd2Ugc2hvdWxkIG5v dCBmb3Jlc2VlIGV4dHJhIHByb3RvY29sIGNvbXBsZXhpdHkgZm9yIHNpZ25hbGxpbmcgdGhhdCB0 aGUgcmVjZWl2ZXIgY2Fubm90IHJlYWQgdGhlIGVjbiBiaXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkZvciBtZSB0aGUgcmVhc29ucyB3ZXJlOiBJdCBpcyBub3Qg YSBkZXNpcmVkIHNpdHVhdGlvbiB3aGljaCB3aWxsIGhvcGVmdWxseSBkaXNhcHBlYXIgaW4gdGhl IGZ1dHVyZSwgYW5kIEkgZG9uJ3QgdGhpbmsgaXQgaXMgc28gdXNlZnVsIGZvciBhIHNlbmRlciB0 bw0KIGtub3cuIFdlIG5vdyBhc3N1bWUgcmVhZGluZyAwMCBiaXRzIGFuZCBlY2hvIGFsbCBjb3Vu dGVycyB1bmluY3JlbWVudGVkIHdpdGggMCB2YWx1ZXMgaW4gdGhhdCBjYXNlLCBqdXN0IGFzIGlm IHRoZSBwYXRoIGJsZWFjaGVzIGl0LiBJZiB3ZSBtYWtlIGFuIGV4cGxpY2l0IHByb3RvY29sIGV4 Y2hhbmdlIGZvciBpdCwgaXQgZmVlbHMgbGlrZSBpdCBpcyBhbiBleHRyYSBmZWF0dXJlIDstKS4g QWxzbyBwZW9wbGUgbWlnaHQgc3RhcnQgbWFraW5nIHRoZWlyDQogY29uZ2VzdGlvbiBjb250cm9s IG1vcmUgY29tcGxleCB3aXRoIHVwIHRvIDIgbW9yZSBjb25kaXRpb25hbCBwYXJhbWV0ZXJzIChz ZW5kZXItY2Fubm90LXNldC1lY24gYW5kIHJlY2VpdmVyLWNhbm5vdC1yZWFkLWVjbiBib29sZWFu cywgbmV4dCB0byBuby1lY24pLiBOb3QgdG8gbWVudGlvbiBleHRyYSBpbnRlcm9wIHRlc3RjYXNl cyB3aXRoIHN1Y2ggc2VuZGVyJ3MvcmVjZWl2ZXIncyBleHRyYSBmdW5jdGlvbmFsaXR5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRvIG1ha2UgeW91ciBjb2RlIHNp bXBsZSBhbmQgcGxhdGZvcm0gaW5kZXBlbmRlbnQsIG5vdCBiZWluZyBhYmxlIHRvIHNldC9yZWFk IGVjaG8gYml0cyBzaG91bGQgYmUgaW52aXNpYmxlIHVudGlsIHRoZSBwb2ludCBvZiB0aGUgbWlz c2luZyBzb2NrZXQgQVBJDQogY2FsbCwgd2hpY2ggd2lsbCBtb3N0IHByb2JhYmx5IGhhdmUgY29u ZGl0aW9uYWwgY29tcGlsZXIgZGlyZWN0aXZlcyBwZXIgcGxhdGZvcm0gYXQgdGhhdCBwb2ludC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5TbyBjb25jbHVzaW9uIHdh czogQW55IGhpZ2hlciBsYXllciBwcm90b2NvbCBjb2RlIHNob3VsZCBub3QgbWFrZSBhbnkgZGlz dGluY3Rpb24gYmV0d2VlbiBob3N0IGluYWJpbGl0eSBhbmQgcGF0aCBibGVhY2hpbmcsIGFuZCB3 ZSBvbmx5IGhhdmUgZnVuY3Rpb25hbGl0eQ0KIGZvciBnZW5lcmFsICZxdW90O2VuZDJlbmQgZWNu IGluYWJpbGl0eSZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5BZ3JlZWQgdGhhdCB0aGUgcmVjZWl2ZXIgY29kZSBzaG91bGQgYmUgaW5kZXBlbmRlbnQgZnJv bSBob3cgZWNuIGlzIHVzZWQuIFRoaXMgaXMgdGhlIGNhc2Ugbm93LiBGb3IgdGhlIHJlY2VpdmVy IHdlIG9ubHkgaW5jcmVtZW50IGFuZCBlY2hvIHRoZSBjb3VudGVycw0KIGFsbCB0aGUgdGltZS4g VGhhdCdzIGl0LCB2ZXJ5IHNpbXBsZS4gT25seSB0aGUgc2VuZGVyIGRldGVybWluZXMgaG93IGVj biBjYXBhYmlsaXR5IGlzIGNoZWNrZWQgYW5kIGhvdyBlY24gaXMgdXNlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5NYXliZSBhbHNvIGEgZ29vZCBwb2ludCB0aGF0 IHRoZSBjdXJyZW50IGNhcGFiaWxpdHkgY2hlY2sgaXMgdGhlIG1pbmltYWw/PyBBbmQgbmVlZHMg c29tZSBleHRyYSBjaGVja3M/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+S29lbi48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjxhIGhyZWY9Imh0dHBzOi8vYWthLm1zL2doZWkzNiI+T3V0bG9vayB2b29yIEFuZHJvaWQ8 L2E+IGRvd25sb2FkZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9InRleHQtYWxpZ246 Y2VudGVyIj4NCjxociBzaXplPSIyIiB3aWR0aD0iOTglIiBhbGlnbj0iY2VudGVyIj4NCjwvZGl2 Pg0KPGRpdiBpZD0ieF9kaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0OzxhIGhyZWY9Im1haWx0bzppbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5j b208L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE0LCAyMDE4 IDI6MDg6MzAgUE08YnI+DQo8Yj5Ubzo8L2I+IE1pcmphIEvDvGhsZXdpbmQ8YnI+DQo8Yj5DYzo8 L2I+IERlIFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApOyA8YSBocmVmPSJtYWls dG86ZWtpbm5lYXJAYXBwbGUuY29tIj4NCmVraW5uZWFyQGFwcGxlLmNvbTwvYT47IEx1YmFzaGV2 LCBJZ29yOyBJYW4gU3dldHQ7IFFVSUMgV0c7IENocmlzdGlhbiBIdWl0ZW1hOyBJbmdlbWFyIEpv aGFuc3NvbiBTPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBFQ04gaW4gUVVJQyBjb25uZWN0aW9u IG1pZ3JhdGlvbiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaTxi cj4NCjxicj4NCkkgYXR0YWNoIHRoZSBtaW51dGVzIGZyb20gdGhlIHNpZGUgbWVldGluZyBpbiBT aW5nYXBvcmUsIEkgYmVsaWV2ZSB0aGF0IHRoZXkgd2VyZSBvbmx5IHBvc3RlZCBvbiB0aGUgZWNu LXF1aWMgbWFpbGluZyBsaXN0DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2Ug VUkgRW1vamkmcXVvdDssc2Fucy1zZXJpZiI+4pi5PC9zcGFuPiAuPGJyPg0KPGJyPg0KSSBhZ3Jl ZSB0aGF0IHRoZSBzZW5kZXIvcmVjZWl2ZWQgaXNzdWVzIGFyZSBwcm9iYWJseSBrbm93biBhLXBy aW9yeSBhbmQgaWYgYSBzZW5kZXIgZG9lcyBrbm93IHRoYXQgaXRzIE9TIHN0YWNrIGRvZXMgbm90 IGhhdmUgdGhlIG5lY2Vzc2FyeSBBUEkgc3VwcG9ydCBmb3IgRUNOIHRoZW4gaXQgZG9lcyBub3Qg bWFrZSBtdWNoIHNlbnNlIHRvIHRyeSBpdC48YnI+DQo8YnI+DQovSW5nZW1hcjxicj4NCiZuYnNw OyA8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBG cm9tOiBNaXJqYSBLw7xobGV3aW5kIFs8YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEB0 aWsuZWUuZXRoei5jaCI+bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+ XTxicj4NCiZndDsgU2VudDogZGVuIDEzIGZlYnJ1YXJpIDIwMTggMTM6Mjk8YnI+DQomZ3Q7IFRv OiBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDs8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFu c3NvbkBlcmljc3Nvbi5jb20iPmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPC9hPiZn dDs8YnI+DQomZ3Q7IENjOiBEZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJwKSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmtvZW4uZGVfc2NoZXBwZXJAbm9raWEtJTBiIj5rb2VuLmRlX3Nj aGVwcGVyQG5va2lhLTxicj4NCjwvYT4mZ3Q7IGJlbGwtbGFicy5jb20mZ3Q7OyA8YSBocmVmPSJt YWlsdG86ZWtpbm5lYXJAYXBwbGUuY29tIj5la2lubmVhckBhcHBsZS5jb208L2E+OyBMdWJhc2hl diwgSWdvcjxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29t Ij5pbHViYXNoZUBha2FtYWkuY29tPC9hPiZndDs7IElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0OzsgUVVJ QyBXRzxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGll dGYub3JnPC9hPiZndDs7IENocmlzdGlhbiBIdWl0ZW1hICZsdDs8YSBocmVmPSJtYWlsdG86aHVp dGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7PGJyPg0KJmd0OyBT dWJqZWN0OiBSZTogRUNOIGluIFFVSUMgY29ubmVjdGlvbiBtaWdyYXRpb248YnI+DQomZ3Q7IDxi cj4NCiZndDsgSGkgSW5nZW1hciw8YnI+DQomZ3Q7IDxicj4NCiZndDsgc2VlIGJlbG93Ljxicj4N CiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFtIDEyLjAyLjIwMTggdW0gMjI6MTEgc2NocmllYiBJbmdl bWFyIEpvaGFuc3NvbiBTPGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5q b2hhbnNzb25AZXJpY3Nzb24uY29tIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwv YT4mZ3Q7Ojxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBIaTxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBQbGVhc2Ugc2VlIGlubGluZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBCUjxicj4NCiZndDsgJmd0OyBJbmdlbWFyPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgJmd0OyZndDsgRnJv bTogTWlyamEgS8O8aGxld2luZCBbPGEgaHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlr LmVlLmV0aHouY2giPm1haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPC9hPl08 YnI+DQomZ3Q7ICZndDsmZ3Q7IFNlbnQ6IGRlbiAxMiBmZWJydWFyaSAyMDE4IDE2OjI2PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyBUbzogSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj5pbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBDYzogRGUgU2NoZXBwZXIsIEtv ZW4gKE5va2lhIC0gQkUvQW50d2VycCkgJmx0OzxhIGhyZWY9Im1haWx0bzprb2VuLmRlX3NjaGVw cGVyQG5va2lhLSUwYiI+a29lbi5kZV9zY2hlcHBlckBub2tpYS08YnI+DQo8L2E+Jmd0OyAmZ3Q7 Jmd0OyBiZWxsLWxhYnMuY29tJmd0OzsgPGEgaHJlZj0ibWFpbHRvOmVraW5uZWFyQGFwcGxlLmNv bSI+ZWtpbm5lYXJAYXBwbGUuY29tPC9hPjsgTHViYXNoZXYsIElnb3I8YnI+DQomZ3Q7ICZndDsm Z3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVAYWth bWFpLmNvbTwvYT4mZ3Q7OyBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBn b29nbGUuY29tIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDs7IFFVSUMgV0c8YnI+DQomZ3Q7 ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9y ZzwvYT4mZ3Q7OyBDaHJpc3RpYW4gSHVpdGVtYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmh1aXRlbWFA aHVpdGVtYS5uZXQiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZn dDsgU3ViamVjdDogUmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uPGJyPg0KJmd0 OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgSGkgSW5nZW1hciw8YnI+DQomZ3Q7ICZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0d28gcG9pbnRzLjxicj4NCiZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7IEkgdGhpbmsgaXQgd291bGQgYmUgZ29vZCB0byBiZSBhcyBleHBsaWNp dCBhcyBwb3NzaWJsZSBoZXJlLDxicj4NCiZndDsgJmd0OyZndDsgdGhlcmVmb3JlIEkgd291bGQg cHJlZmVyIGlmIGFuIGVuZHBvaW50IHRoYXQga25vd3MgdGhhdCBpdCBjYW4gbm90PGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBhY2Nlc3MgdGhlIEVDTiBJUCBiaXRzIGluZGljYXRlcyB0aGlzIGRpcmVjdGx5 IGluIHRoZSBoYW5kc2hha2UuIEluPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB0aGlzIGNhc2Ugbm8gZnVy dGhlciB0ZXN0aW5nIGlzIG5lZWRlZC48YnI+DQomZ3Q7ICZndDsgJmx0O0lKJmd0OyBZZXMsIHRo aXMgd2FzIHRoZSBvcmlnaW5hbCBpZGVhLCB3ZSBkaXNjdXNzZWQgdGhpcyBhdCB0aGUgRUNOPGJy Pg0KJmd0OyAmZ3Q7IFFVSUMgc2lkZSBtZWV0aW5nIHRob3VnaCBhbmQgYWZ0ZXJ3YXJkcyBhbmQg YXMgZmFyIGFzIEkgdW5kZXJzdGFuZCBpdCw8YnI+DQomZ3Q7ICZndDsgdGhlcmUgd2FzIGEgY29u c2Vuc3VzIHRoYXQgaXQgd2FzIHVubmVjZXNzYXJpbHkgY29tcGxpY2F0ZWQuIFNvIHdlPGJyPg0K Jmd0OyAmZ3Q7IHNlbGVjdGVkIGEgbWV0aG9kIHdoZXJlIHdlIGp1c3QgdmVyaWZ5IHRoYXQgdGhl IEVDVCgwKSxFQ1QoMSksQ0U8YnI+DQomZ3Q7ICZndDsgY291bnRlcnMgaGF2ZSByZWFzb25hYmxl IHZhbHVlcy4gSWYgdGhhdCBpcyBub3QgdGhlIGNhc2UsIHRoZW4gaXQgaXM8YnI+DQomZ3Q7ICZn dDsgYW4gaW5kaWNhdGlvbiB0aGF0IGVpdGhlciB0aGUgcGF0aCBvciB0aGUgZW5kcG9pbnRzIGRv IG5vdCBzdXBwb3J0PGJyPg0KJmd0OyAmZ3Q7IEVDTi4gJmx0Oy9JSiZndDs8YnI+DQomZ3Q7IDxi cj4NCiZndDsgSSBjaGVja2VkIHRoZSBtaW51dGVzIGFuZCBjb3VsZCBub3QgcmVhbGx5IGZpbmQg YSBjb25jbHVzaW9uIHRoZXJlLiBJIGFncmVlPGJyPg0KJmd0OyB0aGF0IHRoZXJlIHNob3VsZCBi ZSBubyBuZWdvdGlhdGlvbiBpbiB0aGUgaGFuZHNoYWtlIChib3RoIGVuZHBvaW50IG5lZWQ8YnI+ DQomZ3Q7IHRvIGltcGxlbWVudCB0aGUgRUNOIGxvZ2ljIGFzIHBhcnQgb2YgdjEpIGJ1dCB3aGF0 IHdvdWxkIGJlIGhlbHBmdWwgaXMgdG8gbGV0PGJyPg0KJmd0OyB0aGUgb3RoZXIgZW5kIGtub3cg aWYgeW91IGFscmVhZHkga25vdyB0aGF0IHlvdSBuZXZlciB3aWxsIGJlIGFibGUgdG88YnI+DQom Z3Q7IHByb3ZpZGUgZmVlZGJhY2sgYmVjYXVzZSB5b3UgY2FuIGp1c3Qgbm90IHJlYWQgdGhlIGJp dHMgaW4gdGhlIElQIGhlYWRlci48YnI+DQomZ3Q7IFRoYXQgaXMgbm90IGNvbXBsaWNhdGVkIGF0 IGFsbC48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayB3aGF0IHdlIG5lZWQgdG8gc3BlY2lm eSBpbiB2MSBpcyBhIHdheSB0byBwcm92aWRlIEVDTiBmZWVkYmFjayAob3I8YnI+DQomZ3Q7IGlu ZGljYXRlIHRoYXQgdGhpcyBpcyBub3QgcG9zc2libGUpLiBIb3dldmVyLCB3ZSBhY3R1YWxseSB3 b3VsZCBub3QgbmVlZCB0bzxicj4NCiZndDsgc2F5IGFueXRoaW5nIGFib3V0IGhvdyBFQ04gc2hv dWxkIGJlIHVzZWQuIFRoYXTigJlzIGEgc2VuZGVyIHNpZGUgZGVjaXNpb24uPGJyPg0KJmd0OyBB cyBsb25nIGFzIHlvdSBjYW4gZ2V0IGZlZWRiYWNrLCB3ZSBhcmUgZmxleGlibGUgaW4gaG93IHRv IHVzZSBhbmQgdGVzdCBFQ04gaW48YnI+DQomZ3Q7IHYxIG9yIGFueXRpbWUgbGF0ZXIuIE9mIGNv dXJzZSBpdCB3b3VsZCBiZSBuaWNlIHRvIHByb3ZpZGUgc29tZSBkZWZhdWx0PGJyPg0KJmd0OyBy ZWNvbW1lbmRhdGlvbnMgd2l0aCBzb21lIGVhc3kgZmFsbGJhY2sgbG9naWMgYnV0IHRoYXQncyB0 aGUgcGFydCB3ZSBjYW48YnI+DQomZ3Q7IGV4cGVyaW1lbnQgd2l0aCBhbmQgY2hhbmdlIGFueSB0 aW1lIHdpdGhvdXQgYW55IG5lZWQgdG8gY2hhbmdlIHRoZTxicj4NCiZndDsgcHJvdG9jb2wgc3Bl YyAoYXMgbG9uZyBhcyBFQ04gZmVlZGJhY2sgaXMgcHJvdmlkZWQsIHdoZW4gRUNOIGlzIHVzZWQg YnkgdGhlPGJyPg0KJmd0OyBzZW5kZXIpLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgRnVydGhlciwgdGhlIHBhdGggdGVzdGlu ZyBpdHNlbGYgaXMgaW5kZXBlbmRlbnQgb2YgUVVJQyBhbmQgY2FuIGJlPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyB1c2VkIGZvciBhbnkgcHJvdG9jb2wuIE1vcmVvdmVyLCBpdOKAmXMgbW9yZSBjb21wbGlj YXRlZCB0aGFuIGp1c3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IHRlc3RpbmcgRUNULiBJIGd1ZXNzIHRo ZSBnZW5lcmFsIGFkdmljZSBoZXJlIGlzIHRvIHJlbWVtYmVyIHdoaWNoPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBjb2RlcG9pbnRzIHdlcmUgc2VuZCBhbmQgY29tcGFyZSB0aGlzIHRvIHRoZSBmZWVkYmFj ayBwcm92aWRlZC4gSWY8YnI+DQomZ3Q7ICZndDsmZ3Q7IGRpc2NyZXBhbmNpZXMgYXJlIG9ic2Vy dmVkIHRoYXQgaW5kaWNhdGUgdGhhdCBhIG1pZGRsZWJveCBoYXMgY2hhbmdlZDxicj4NCiZndDsg Jmd0OyZndDsgdGhlc2UgYml0cywgYWxsIHBhY2tldHMgc2hvdWxkIGJlIG1hcmtlZCBhcyBuby1F Q1QgKHdoaWxlIGFkZGl0aW9uYWw8YnI+DQomZ3Q7ICZndDsmZ3Q7IHRlc3RpbmcgTUFZIGJlIHBl cmZvcm1lZCBhdCBhbnkgbGF0ZXIgcG9pbnQgaW4gdGltZSkuIEhvd2V2ZXIsIGhvdzxicj4NCiZn dDsgJmd0OyZndDsgZXhhY3RseSB0aGlzIHRlc3Rpbmcgc2hvdWxkIGxvb2sgbGlrZSwgc2hvdWxk IG5vdCBiZSBzcGVjaWZpZWQgaW4gdGhpcyBkb2M8YnI+DQomZ3Q7IChidXQgbW9yZSBnZW5lcmFs bHkpLjxicj4NCiZndDsgJmd0OyAmbHQ7SUomZ3Q7IEl0IGlzIHBvc3NpYmxlIHRoYXQgdGhlIGFj dHVhbCBwYXRoIHZlcmlmaWNhdGlvbiBjYW4gYmUgcHV0IGFzIGE8YnI+DQomZ3Q7ICZndDsgc2Vw YXJhdGUgZG9jdW1lbnQsIG5vdCBzdXJlIGlmIHRoYXQgaXMgYWNjZXB0ZWQgYnkgdGhlIGdyb3Vw IG9yIGl0IGlzPGJyPg0KJmd0OyAmZ3Q7IGRlc2lyZWQgd2l0aCBhIG1vcmUgZWxhYm9yYXRlIGRl c2NyaXB0aW9uIGRpcmVjdGx5IGluIHRoZSBRVUlDIGRyYWZ0cy48YnI+DQomZ3Q7ICZndDsgQXMg cmVnYXJkcyB0byB2ZXJpZmljYXRpb24sIEkgZG8gYmVsaWV2ZSB0aGF0IHRoZSBwcm9wb3NlZCBj b3VudGVyczxicj4NCiZndDsgJmd0OyBzaG91bGQgYmUgYWJsZSB0byBkZXRlY3QgYmxlYWNoaW5n LCBhY2NpZGVudGFsIHJlbWFya2luZyBmcm9tIEVDVCgwKTxicj4NCiZndDsgJmd0OyB0byBFQ1Qo MSkgYW5kIGFsc28gY2FzZXMgd2hlcmUgcGFja2V0cyBhcmUgbm90IENFIG1hcmtlZCBhdCBhbGw8 YnI+DQomZ3Q7ICZndDsgZGVzcGl0ZSBvdGhlciBzaWducyBvZiBjb25nZXN0aW9uICZsdDsvSUom Z3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlIHRyaWVkIHRvIGRlc2lnbiBhIG1vcmUgZWxhYm9y YXRlZCB0ZXN0aW5nIHNjaGVtZSB3aGVyZSB3ZSB3b3VsZCBzZW5kPGJyPg0KJmd0OyAzIEVDVDAs IHRoZSAzIEVDVDEsIGFuZCB0aGUgMyBDRSAod2hpY2ggd2Ugd291bGQgb2YgY2F1c2Ugbm90IGNv dW50IGFzIGE8YnI+DQomZ3Q7IGNvbmdlc3Rpb24gaW5kaWNhdGlvbiBhcyB0aGUgQ0Ugd2FzIHNl dCBieSB0aGUgc2VuZGVyKS4gSG93ZXZlciwgdGhpcyB3YXM8YnI+DQomZ3Q7IG1vc3RseSB0byBk ZXRlY3QgYmxhY2std2hhbGluZyB3aGljaCBpcyBwcm9iYWJseSBsZXNzIGEgY29uY2VybiB0aGFu IHJlLTxicj4NCiZndDsgbWFya2luZy4gSSB0aGluayB0b2RheSB0aGUgbW9zdCBjb21tb24gY2Fz ZSBpdCB0aGF0IHRoZSBiaXRzIHdpbGwgYmUgc2V0IHRvPGJyPg0KJmd0OyB6ZXJvcyB3aGljaCBp cyBvbmx5IGEgcHJvYmxlbSB3aGVuIHRoZXJlIHdhcyBzb21lIENFIG1hcmtpbmcgcHJldmlvdXNs eTxicj4NCiZndDsgb24gdGhlIHBhdGggdGhhdCB0aGVuIHdvdWxkIGdldCBsb3N0LiBUaHVzIGlu IHRoaXMgY2FzZSBpdCB3b3VsZCBiZTxicj4NCiZndDsgcmVjb21tZW5kIHRvIG5vdCB1c2UgRUNO L25vdCBzZXQgcGFja2V0cyBhcyBFQ1QgYXQgc2VuZGVyIHNpZGUuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEhvd2V2ZXIsIGFzIEkgc2FpZCBhYm92ZSwgd2UgcHJvYmFibHkgc2hvdWxkIG1ha2UgcmVj b21tZW5kYXRpb24gaG93IHRvPGJyPg0KJmd0OyB1c2UgRUNOIGJ5IGRlZmF1bHQgYnV0IG5lZWQg dG8gbGVhdmUgcm9vbSBmb3Igb3RoZXIgdXNhZ2UvdGVzdGluZyBzY2hlbWVzLjxicj4NCiZndDsg QnV0IGFmdGVyIGFsbCB0aGUgcmVjZWl2ZXIgYmVpbmcgbm90IGFibGUgdG8gcmVhZCB0aGUgYml0 cyBhbmQgcmVtYXJraW5nIG9uIHRoZTxicj4NCiZndDsgcGF0aCBhcmUgdG8gZGlmZmVyZW50IHRo aW5ncyBhbmQgc2hvdWxkIG5vdCBiZSBtaXhlZCB1cC4gSWYgdGhlIHNlbmRlciBjYW48YnI+DQom Z3Q7IG5vdCByZWFkIHRoZSBiaXRzIHRoaXMgaXMga25vdyBhIHByaW9yaSBhbmQgdGhlcmUgaXMg bm8gYW1iaWd1aXR5IHRoYXQgbmVlZHMgdG88YnI+DQomZ3Q7IGJlIHRlc3RlZC4gU28gd2h5IG5v dCBzaWduYWwgaXQgZGlyZWN0bHkuIFRoZSBxdWVzdGlvbiBpZiB0aGUgc2VuZGVyIGNhbiB3cml0 ZTxicj4NCiZndDsgRUNOIGRvZXMgbm90IG5lZWQgdG8gYmUgY29tbXVuaWNhdGVkLiBUaGVyZSBp cyBubyBkaWZmZXJlbmNlIGluIHRoZTxicj4NCiZndDsgc2VuZGVyIGRlY2lkZWQgdG8gbm90IHVz ZSBFQ04gb3IgaXQganVzdCBjYW4gbm90IHVzZSBpdDsgaW4gYm90aCBjYXNlcyBpdCBpcyBub3Q8 YnI+DQomZ3Q7IG5lY2Vzc2FyeSB0byBzZW5kIEVDTiBmZWVkYmFjayBiYWNrLiBPbmx5IGlmIGEg bm9uLW5vbi1FQ1QgaXMgb2JzZXJ2ZWQgYXQ8YnI+DQomZ3Q7IHRoZSByZWNlaXZlciwgRUNOIGZl ZWRiYWNrIG5lZWRzIHRvIGJlIHByb3ZpZGVkLiBIb3dldmVyLCBrbm93aW5nIHRoYXQ8YnI+DQom Z3Q7IHRoZSByZWNlaXZlciBjYW7igJl0IG5vdCBwcm92aWRlIGZlZWRiYWNrIGlzIGltcG9ydGFu dCBiZWNhdXNlIGluIHRoaXMgY2FzZSB0aGU8YnI+DQomZ3Q7IHNlbmRlciBNVVNUIG5vdCBzZXQg dGhlIHBhY2tldHMgYXMgRUNUIGFzIGl0IHdpbGwgbm90IGJlIGFibGUgdG8gcmVhY3QgdG8gdGhh dDxicj4NCiZndDsgc2lnbmFsLiBUZXN0aW5nIHRoZSBwYXRoIGluIGluZGVwZW5kZW50IG9mIHRo YXQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1pcmphPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsmZ3Q7IE1pcmphPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyBBbSAwOS4wMi4yMDE4IHVtIDA4OjM0IHNjaHJpZWIgSW5nZW1hciBK b2hhbnNzb24gUzxicj4NCiZndDsgJmd0OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzppbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5j b208L2E+Jmd0Ozo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 IEhpIEVyaWMsIEtvZW4gJiM0Mzsgb3RoZXJzPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyBUaGFua3MgZm9yIHRoZSBjb21tZW50cyBhbmQgdGhlIHVwZGF0ZS4g QSBxdWVzdGlvbiB0byB0aGUgcmVzdCBvZjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IHRoZTxicj4N CiZndDsgJmd0OyZndDsgYXVkaWVuY2UsIGRvZXMgdGhlIHByZXNlbnRlZCB0ZXh0IGV4cGxhaW4g c3VmZmljaWVudGx5IGVub3VnaCBob3cgRUNOPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB3b3JrcyB3aXRo IGNvbm5lY3Rpb24gbWlncmF0aW9uID88YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJo dHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvRUNOLWluLVFVSUMjdHJh bnNwb3J0LSI+DQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvRUNO LWluLVFVSUMjdHJhbnNwb3J0LTwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7IGRyYWZ0LWNvbm5lY3Rp b24tbWlncmF0aW9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IC9JbmdlbWFyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEZyb206IERlIFNj aGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBbPGEg aHJlZj0ibWFpbHRvOmtvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbSI+bWFpbHRv OmtvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbTwvYT5dPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgU2VudDogZGVuIDIgZmVicnVhcmkgMjAxOCAxNTo0NDxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86ZWtpbm5lYXJAYXBwbGUuY29tIj5la2lubmVhckBh cHBsZS5jb208L2E+OyBJbmdlbWFyIEpvaGFuc3NvbiBTPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj5pbmdlbWFy LnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsg Q2M6IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYu b3JnPC9hPiZndDs7IElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2ds ZS5jb20iPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0Ozs8YnI+DQomZ3Q7ICZndDsmZ3Q7IEx1 YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1 YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7OyBDaHJpc3RpYW4gSHVpdGVtYTxicj4NCiZndDsgJmd0 OyZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Ij5odWl0ZW1hQGh1 aXRlbWEubmV0PC9hPiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSRTogRUNO IGluIFFVSUMgY29ubmVjdGlvbiBtaWdyYXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJmd0OyZndDsmZ3Q7IEhpIEluZ2VtYXIsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBJIGFsc28gcmVhZCBhZ2FpbiB0aHJvdWdoIHRoZSBkb2N1bWVu dCwgYW5kIGhhZCBmb2xsb3dpbmcgY29tbWVudHM6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBJIHJlcGxhY2VkOjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IOKA nFRoZSBBQ0tfRUNOIGZyYW1lIGlzIHVzZWQgdG8gY29udmV5IEFDS3Mgd2hlbiB0aGUgRUNOIGNh cGFiaWxpdHk8YnI+DQomZ3Q7ICZndDsmZ3Q7IGV4Y2hhbmdlIGNvbmNsdWRlcyB0aGF0IEVDTiBz aG91bGQgYmUgdXNlZCBmb3IgdGhlIGdpdmVuIGNvbm5lY3Rpb24u4oCdPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgT3JpZ2luYWxseSBpdCBzb3VuZHMgYXMgaWYgdGhlIGNvdW50ZXJzIGFyZSBub3Qg ZWNob2VkIGFueW1vcmUgaWY8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGUgRUNOPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyBjYXBhYmlsaXR5IGNoZWNrIGZhaWxzLiBJIGFzc3VtZSB0aGlzIHdhcyBub3Qg dGhlIGludGVudGlvbiwgYnV0IGlmPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpdCBpczogRmlyc3QsIHdl IGRvbuKAmXQgaGF2ZSBhIHByb3RvY29sIG9yIGRlY2lzaW9uIHBvaW50IGRlZmluZWQgd2hlbjxi cj4NCiZndDsgJmd0OyZndDsgdGhhdCBjb25kaXRpb24gaXMgbWV0IChzZW5kZXIgc2hvdWxkIGxl dCB0aGUgcmVjZWl2ZXIga25vdyBpbiB0aGU8YnI+DQomZ3Q7ICZndDsmZ3Q7IG5leHQgcGFja2V0 KSwgYW5kIHNlY29uZCwgSSB3b3VsZCBhbHdheXMgc2VuZCB0aGUgZWNobywgYXMgd2UgbWlnaHQ8 YnI+DQomZ3Q7ICZndDsmZ3Q7IOKAnHRyeSBhZ2FpbiBsYXRlciAod2l0aCBhbm90aGVyIEVDVD8p 4oCdLCBvciBtaWdodCBkZWNpZGUgdG8gdXNlIHRoZSBFQ04gYml0czxicj4NCiZndDsgZGlmZmVy ZW50bHkgbGF0ZXIuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyBJIGFsc28gY2hhbmdlZCB0aGUgdGV4dCBhcm91bmQgdGhlIGNvbm5lY3Rpb24gbWlncmF0aW9u LCBJIHRoaW5rPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgYmVmb3JlIEVyaWM8YnI+DQomZ3Q7ICZn dDsmZ3Q7IHJldmlld2VkIGl0LiBJIG1hZGUgaXQgc3VjaCB0aGF0IGV2ZXJ5IG5ldyBwYXRoIGNy ZWF0ZXMgYSBuZXc8YnI+DQomZ3Q7ICZndDsmZ3Q7IGNvbm5lY3Rpb24gc3RhdGUgd2l0aCBhbiBp bml0aWFsaXplZCBjb25nZXN0aW9uIGNvbnRyb2wgc3RhdGUgYW5kIEVDTjxicj4NCiZndDsgJmd0 OyZndDsgY291bnRlcnMgKGF0IGxlYXN0IEVDTiBjb3VudGVycyByZXNldCB0byAwcykuIE5vdCBz dXJlIGlmIHRoaXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IG1hdGNoZXMgd2l0aCB0aGUgb3RoZXIgc2Vj dGlvbnMgaW4gdGhlIFFVSUMgZHJhZnQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBJIGFsc28gaGFkIHRoZSB0aG91Z2h0IHdoZXRoZXIgaXQgd2FzIHJlYWxs eSBuZWVkZWQgdG8gaGF2ZSB0aGUgMjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IGNhc2VzLiBJPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBhZ3JlZSB3ZSBzaG91bGQgc2ltcGxpZnksIGJ5IGp1c3Qgc3RhcnRp bmcgb3ZlciBhbmQgZG9pbmcgdGhlIGNoZWNrPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB1bmNvbmRpdGlv bmFsbHkgd2hldGhlciBpdCB3YXMgc3VjY2Vzc2Z1bCBvciBub3QgaW4gYSBwcmV2aW91cyBwYXRo Ljxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgUmVnYXJkcyw8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBLb2VuLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmVraW5uZWFyQGFwcGxlLmNv bSI+ZWtpbm5lYXJAYXBwbGUuY29tPC9hPiBbPGEgaHJlZj0ibWFpbHRvOmVraW5uZWFyQGFwcGxl LmNvbSI+bWFpbHRvOmVraW5uZWFyQGFwcGxlLmNvbTwvYT5dPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDsgU2VudDogRnJpZGF5LCBGZWJydWFyeSAyLCAyMDE4IDEyOjAyIEFNPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0OzxhIGhyZWY9Im1haWx0bzppbmdl bWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSI+aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb208L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IENjOiBRVUlDIFdHICZsdDs8YSBo cmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7OyBJYW4gU3dl dHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIj5pYW5zd2V0dEBnb29n bGUuY29tPC9hPiZndDs7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBMdWJhc2hldiwgSWdvciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20iPmlsdWJhc2hlQGFrYW1haS5jb208L2E+ Jmd0OzsgQ2hyaXN0aWFuIEh1aXRlbWE8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86aHVpdGVtYUBodWl0ZW1hLm5ldCI+aHVpdGVtYUBodWl0ZW1hLm5ldDwvYT4mZ3Q7OyBE ZSBTY2hlcHBlciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJwKTxicj4NCiZndDsgJmd0OyZndDsg Jmx0OzxhIGhyZWY9Im1haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20i PmtvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9u PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBIaSBJbmdlbWFy LDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgVGhpcyBnZW5l cmFsbHkgbG9va3MgZ29vZCB0byBtZSE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBBIGZldyBxdWVz dGlvbnMgYW5kIG9ic2VydmF0aW9uczo8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7IFRoZXJlIGFyZSB0d28gdW5pcXVlIGNhc2VzOjxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsg4oCiIEVDTiBjYXBhYmlsaXR5IGNoZWNrIHN1Y2Nlc3NmdWwgYXQgaW5pdGlhbCBjb25u ZWN0aW9uIHNldHVwPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsg4oCiIEVDTiBjYXBhYmlsaXR5IGNoZWNrIGZhaWxlZCBhdCBpbml0aWFsIGNv bm5lY3Rpb248YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBzZXR1cDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgQXJlIHRoZXNlIGFjdHVhbGx5IGFueSBkaWZmZXJl bnQgaW4gdGVybXMgb2YgYWN0aW9uIHRha2VuIGJ5IGFuIGVuZHBvaW50Pzxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7IEl0IHNlZW1zIGxpa2Ugb24gdGhlIG5ldyBuZXR3b3JrIHBhdGggdGhlIGVuZHBv aW50IHdvdWxkIGdvIHRocm91Z2g8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyB0aGU8YnI+DQomZ3Q7 ICZndDsmZ3Q7IHNhbWUgcHJvY2VzcyBvZjogKGEpIHZlcmlmeSBFQ04gY2FwYWJpbGl0eSBhbmQg aWYgc3VjY2Vzc2Z1bCB0bzxicj4NCiZndDsgJmd0OyZndDsgd2hhdGV2ZXIgZGVncmVlIHRoZW4g KGIpIHJ1biB0aGUgcmVzdCBvZiB0aGUgRUNOIG1hY2hpbmVyeSBhczxicj4NCiZndDsgYXBwcm9w cmlhdGUuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBJbiBv dGhlciB3b3JkcywgYXMgbG9uZyBhcyB5b3UgYWxsb3cgcGVvcGxlIHRvIHN0YXJ0IHVzaW5nIEVD TiB1cG9uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBtaWdyYXRpb24gKGluIG90aGVyIHdvcmRzLCB0byBh bGxvdyBzdGFydGluZyBpdCBhZnRlciB0aGUgaW5pdGlhbDxicj4NCiZndDsgJmd0OyZndDsgY29u bmVjdGlvbiBlc3RhYmxpc2htZW50KSwgdGhlbiB0aGUgc3BlY2lmaWNzIGZvciBFQ04gd2l0aCBt aWdyYXRpb248YnI+DQomZ3Q7ICZndDsmZ3Q7IGlzIGVzc2VudGlhbGx5IG9uZSBzdGF0ZW1lbnQs IHdoaWNoIGlzIOKAnGRvIHRoZSBFQ04gcHJvY2VzcyBvbiBlYWNoPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBuZXcgbmV0d29yayBwYXRoIHRoYXQgeW91IHVzZeKAnS48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IENvbm5lY3Rpb24gbWlncmF0aW9uIGhhcyBpbXBhY3Qg b24gdGhlIG51bWJlciBvZiByZXBvcnRlZCBDRSBtYXJrZWQ8YnI+DQomZ3Q7ICZndDsmZ3Q7IHBh Y2tldHMuIEEgbmV3IGNvbm5lY3Rpb24gc3RhdGUgd2l0aCBuZXcgY29uZ2VzdGlvbiBjb250cm9s IHN0YXRlIGFuZDxicj4NCiZndDsgJmd0OyZndDsgRUNOIGNvdW50ZXJzIGlzIGluc3RhbnRpYXRl ZCBhdCB0aGUgc2VuZGVyIGFuZCByZWNlaXZlci4gVGhlIEVDTjxicj4NCiZndDsgJmd0OyZndDsg Y291bnRlcnMgTVVTVCBzdGFydCBmcm9tIHplcm8gYWdhaW4uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGlzIHNlZW1zIGZpbmUgdG8gbWUsIGl04oCZcyBp bmxpbmUgd2l0aCB0aGUgcmVzdCBvZiB0aGUgY29uZ2VzdGlvbjxicj4NCiZndDsgJmd0OyZndDsg Y29udHJvbC9sb3NzIHJlY292ZXJ5IHN0YXRlIHRoYXQgYWxzbyBuZWVkcyB0byBiZSByZXNldCBm b3IgdGhlIG5ldyBwYXRoLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0 OyZndDsgR2l2ZW4gdGhhdCBlYWNoIG1pZ3JhdGlvbiByZXF1aXJlcyBhdCBsZWFzdCBvbmUgZXhj aGFuZ2Ugb2YgcGFja2V0czxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IGF0IHRoZTxicj4NCiZndDsg Jmd0OyZndDsgYmVnaW5uaW5nIChhdCB0aGUgdmVyeSBsZWFzdCBmb3IgYWRkcmVzcyB2YWxpZGF0 aW9uIGZyb20gdGhlIHNpZGUgb2Y8YnI+DQomZ3Q7ICZndDsmZ3Q7IHRoZSBlbmRwb2ludCB0aGF0 IGRpZG7igJl0IG1pZ3JhdGUpLCBpdCBzZWVtcyBsaWtlIHRoYXTigJlzIGFuIGV4Y2VsbGVudDxi cj4NCiZndDsgJmd0OyZndDsgbW9tZW50IHRvIG1hcmsgdGhlIHBhY2tldHMgYW5kIHBlcmZvcm0g dGhlIEVDTiBjYXBhYmlsaXR5IGRldGVjdGlvbi48YnI+DQomZ3Q7ICZndDsmZ3Q7IFRob3NlIHBh Y2tldHMgYXJlIGFsc28gbGlrZWx5IHBhZGRlZCwgZXRjLiBzaW1pbGFyIHRvIGluaXRpYWwgcGFj a2V0czxicj4NCiZndDsgJmd0OyZndDsgc2luY2UgdGhleeKAmXJlIG9uIGEgcHJldmlvdXNseSB1 bnVzZWQgbmV0d29yayBwYXRoLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsgSSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NlZCByZXF1aXJlbWVudCBvZiBqdXN0 IHVzaW5nIHRoZSDigJxmaXJzdOKAnTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IHBhY2tldHM8YnI+ DQomZ3Q7ICZndDsmZ3Q7IGFuZCBtYXJraW5nIHRob3NlIGlzIHN1ZmZpY2llbnQgKGFuZCBnb29k IHRvIGF2b2lkIGFueSByZXF1aXJlbWVudCBhczxicj4NCiZndDsgJmd0OyZndDsgdG8gd2hpY2gg ZnJhbWVzIGFyZSBjb250YWluZWQgaW4gdGhvc2UgcGFja2V0cyksIHNpbmNlIHdlIGFyZSBhbHdh eXM8YnI+DQomZ3Q7ICZndDsmZ3Q7IGV4Y2hhbmdpbmcgcGFja2V0cyBpbiBib3RoIGRpcmVjdGlv bnMgaW1tZWRpYXRlbHkgYWZ0ZXIgbWlncmF0aW9uLjxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsgVGhpcyBoYXMgdGhlIGFkZGVkIGJlbmVmaXQgc3VjaCB0aGF0 IGFueSBlbmRwb2ludCDigJxwcm9iaW5n4oCdIHBvc3NpYmxlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBu ZXR3b3JrIHBhdGhzIGNvdWxkIGluY2x1ZGUgdGhlIGJpdHMgbmVjZXNzYXJ5IHRvIGRldGVjdCBF Q048YnI+DQomZ3Q7ICZndDsmZ3Q7IGNhcGFiaWxpdHkgb24gdGhlIHBhdGggYmVpbmcgcHJvYmVk LCBzbyBpdCBjb3VsZCBldmVuIGtub3cgYmVmb3JlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBtaWdyYXRp bmcgd2hldGhlciBvciBub3QgaXQgd291bGQgYmUgYWJsZSB0byB1c2UgRUNOIG9uIHRoYXQgbmV3 IHBhdGguPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBUaGFu a3MsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgRXJpYzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgT24gRmViIDEsIDIwMTgsIGF0IDM6MDcg QU0sIEluZ2VtYXIgSm9oYW5zc29uIFM8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20iPmluZ2VtYXIucy5qb2hhbnNz b25AZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBIaTxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IEkgaGF2ZSB3cml0 dGVuIHVwIGRpZmZlcmVudCBhc3BlY3RzIG9mIGNvbm5lY3Rpb24gbWlncmF0aW9uIGFuZCBob3c8 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBpdDxicj4NCiZndDsgJmd0OyZndDsgcGxheXMgd2l0aCBF Q04uPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3F1 aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1RVUlDI3RyYW5zcG9ydC0iPg0KaHR0cHM6Ly9n aXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1RVUlDI3RyYW5zcG9ydC08 L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBkcmFmdC1jb25uZWN0aW9uLW1pZ3JhdGlvbjxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgQSBjYXZlYXQuLiBJIGFtIGEg Yml0IHVuc3VyZSBhYm91dCB0aGUgZGVmaW5pdGlvbiBvZiBjb25uZWN0aW9uIG1pZ3JhdGlvbjxi cj4NCiZndDsgLjxicj4NCiZndDsgJmd0OyZndDsgTXkgaW50ZXJwcmV0YXRpb24gaXMgdGhhdCBh IGNsaWVudCBtb3ZlcyB0byBhIG5ldyBJUCBhZGRyZXNzIGR1ZSB0bzxicj4NCiZndDsgJmd0OyZn dDsgZS5nLiBhIE5BVCByZWJpbmQgb3Igc3dpdGNoIGZyb20gV2lGaSB0byBjZWxsdWxhciwgcmln aHQgPy4gSXMgYSBuZXc8YnI+DQomZ3Q7ICZndDsmZ3Q7IGNvbm5lY3Rpb24gaW5zdGFudGlhdGVk IGF0IGEgY29ubmVjdGlvbiBtaWdyYXRpb24gPzxicj4NCiZndDsgJmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyZndDsgL0luZ2VtYXI8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZndDsmZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyBJbmdlbWFyIEpvaGFuc3NvbiZuYnNwOyBNLlNjLjxicj4NCiZndDsg Jmd0OyZndDsmZ3Q7IE1hc3RlciBSZXNlYXJjaGVyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBFcmljc3NvbiBSZXNlYXJjaDxicj4NCiZndDsgJmd0OyZndDsm Z3Q7IE5ldHdvcmsgUHJvdG9jb2xzICZhbXA7IEUyRSBQZXJmb3JtYW5jZTxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7IExhYnJhdG9yaWVncsOkbmQgMTE8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA5NzEg MjgsIEx1bGXDpSwgU3dlZGVuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgUGhvbmUgJiM0Mzs0Ni0x MDcxIDQzMDQyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgU01TL01NUyAmIzQzOzQ2LTczIDA3OCAz Mjg5PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hh bnNzb25AZXJpY3Nzb24uY29tIj5pbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvYT48 YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJodHRwOi8vd3d3LmVyaWNzc29uLmNvbSI+ d3d3LmVyaWNzc29uLmNvbTwvYT48YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFlvdSBjYW4n dCBzdGFydCBhIGZpcmUmbmJzcDsgV29ycnlpbmcgJ2JvdXQgeW91ciBsaXR0bGU8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyB3b3JsZCBmYWxsaW5nIGFwYXJ0PGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQnJ1Y2UgU3ByaW5nc3RlZW48YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyAm Z3Q7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_HE1PR0702MB36252D23A798375FE12607FBC2CE0HE1PR0702MB3625_-- From nobody Wed Feb 21 08:40:22 2018 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 866B912D872 for ; Wed, 21 Feb 2018 08:40:20 -0800 (PST) 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 eBti5qq-Od4O for ; Wed, 21 Feb 2018 08:40:17 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 98FD412E894 for ; Wed, 21 Feb 2018 08:40:07 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id t126so1312459vkb.11 for ; Wed, 21 Feb 2018 08:40:07 -0800 (PST) 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=q7InYHrBt00CU1Vcj9gLy6r+Axby6i/lO6d9gMOyEvk=; b=DVt/aQF8m7MP+wtUeZPqAiNRytXXbN2H/kt/SqpMB44nPYNsVhUpSl5dLe0H96Aa7k 2if0xH70E6wO3/UPkwIHz1PLL23z0DoijC3QoHJ0xWP6ybADSHEMqkt92DNfTsypvuM1 Htm5SRkK4GuO9/AR/DdeLJ0ilDgMTCeLgS6bBeUwwnRcIVPPW21TVrmcbQkToJKXFuW0 v6VzyxxE7hkTwW4cFoOULOMRiEFem8IocFAeIlrMuWSW5uNqRxieDCOKdqFiFl6A+XG8 zmK5EKgnSV6Vm+5NNhF9xqTKpHTqTFq/brczLCPYXA7XhAPvrExe9gBQRIVGQwIrKTIQ 28zA== 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=q7InYHrBt00CU1Vcj9gLy6r+Axby6i/lO6d9gMOyEvk=; b=W8EZ1/fKYwcG2BxtIE7CBBA62QlDCh1a5lIY0yiR4DnLfgZIsV1SAJbbThQxQrind6 D1Wxtdvx5yWAFWsL6ZWsOGPVWTDMTGWPB9QSM14/Y/fIAEHwdbwzyQvX2QySW74UKilP 2p4TeSef0qVvla9mUj8cJ6QnPfPUFp0VbQtlnRB03z/TcL7DbBmo7eWtqxOeeFNHDGr3 bgWrYgrg8fgKPuOftOq3cEIVmi1cWXN/i4Fq/fJ+7y3hWPtWLIygajpMsptxDQ8EsA3t CyCYUOCG1IP6YGbtKjPzWjwxKphp8jATdw85abSpGWK5xhWYR2FOmnhirYoEWqDQgmZE ZL6w== X-Gm-Message-State: APf1xPCajUW9Lekz+XMZQkSs01QrlqSW3zZLThWy8Hpe6YYPiMkv1ucg CC+K3w449iuIRfoS2KWypg7kOwI9XJy9rI7gj6ZuAg== X-Google-Smtp-Source: AH8x225PV7HG1o8fGk5dO9hkGNypCrwDxFLktkAaaz/TdXzLEi/mSsM1NHpvPS8t2Pp0kICvEysPYevdocBEtsD+e7I= X-Received: by 10.31.161.70 with SMTP id k67mr2795917vke.82.1519231206220; Wed, 21 Feb 2018 08:40:06 -0800 (PST) MIME-Version: 1.0 From: Marten Seemann Date: Wed, 21 Feb 2018 16:39:55 +0000 Message-ID: Subject: handling a QUIC accept backlog To: QUIC WG Content-Type: multipart/alternative; boundary="001a1143fc2660e9e60565bb944d" 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, 21 Feb 2018 16:40:20 -0000 --001a1143fc2660e9e60565bb944d Content-Type: text/plain; charset="UTF-8" When using a socket API for a QUIC server, it can happen that there are more incoming connections than the server can accepts at that moment. I imagine that a server will implement some sort of queue containing connections that have the handshake completed. Do we need any guidance on what should happen when that queue is full? There are multiple ways how a server could handle this situation: - Drop all Initial packets. - Send a CONNECTION_CLOSE as a response to an Initial. - Reply with Retries to Initial packets, but drop Handshake packets. - Something more sophisticated? Should we write anything about this in the spec, or is this something that implementations have to figure out for themselves without any guidance? --001a1143fc2660e9e60565bb944d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

When using a socket API for a QUIC server, it c= an happen that there are more incoming connections than the server can acce= pts at that moment. I imagine that a server will implement some sort of que= ue containing connections that have the handshake completed. Do we need any= guidance on what should happen when that queue is full?

There are multiple ways how a server could hand= le this situation:

  • Drop all Initial packets.
  • Send a CONNECTION_CLOSE as a response to an I= nitial.
  • Reply with Retries to Initial packets, but dr= op Handshake packets.
  • Something more sophisticated?

Should we write anything about this in the spec= , or is this something that implementations have to figure out for themselv= es without any guidance?

--001a1143fc2660e9e60565bb944d-- From nobody Wed Feb 21 08:57:56 2018 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 EE2E21274D2 for ; Wed, 21 Feb 2018 08:57:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-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 (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 hD-xnW2E-kKz for ; Wed, 21 Feb 2018 08:57:52 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0090.outbound.protection.outlook.com [104.47.41.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD9B31242F7 for ; Wed, 21 Feb 2018 08:57:52 -0800 (PST) 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=tX7jUNN6CqwJt5DoqqVvyuufI5Pmowh1wfziFwyaL28=; b=YHYtNlfvzPVNJ1Pz35yfiK10TMWml/Mcmd/dVfvmqKXu7q9vxLJWgIZ1hi11YBKjip4DF6l999bD4KKCqpYZyZnI18OUDXbD72DLauqSPcROWxT5549kyujJd06CuXphNakAym6EMVxG8UbOSZrn5cyvPcz0vAgNQn47/eX+ErA= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0136.namprd21.prod.outlook.com (10.173.189.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.1; Wed, 21 Feb 2018 16:57:49 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::9df5:45b9:854a:4f16]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::9df5:45b9:854a:4f16%9]) with mapi id 15.20.0548.005; Wed, 21 Feb 2018 16:57:49 +0000 From: Praveen Balasubramanian To: Martin Thomson , Eric Rescorla CC: QUIC WG , huitema , Rui Paulo Subject: RE: Who wants -10 drafts? Thread-Topic: Who wants -10 drafts? Thread-Index: AQHTqq9pFWWj36FI5ka87b8k6wuBwqOuE1QAgAAJFwCAABAzgIAACEOAgAACdACAANw10A== Date: Wed, 21 Feb 2018 16:57:49 +0000 Message-ID: References: <4A74CD08-00C9-451A-80E8-E6AD7F644DED@apple.com> <09090022-d773-bde5-afe8-48535f02693a@huitema.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0136; 6:FCj7L8/G0bfpjewKdlRFx+Zh/03V4LH38trgkE/PZ8opeWaLHXqmpKva75SIm7rszNxB/XurnIas/63unWbrZZ6uh4MfpfDfdxN1OL7bL3TdGOxmbPkzjd7jamrdDuwO2c++hb8y938QWYA3w1KnXlf1UNZ2UeBy0sGqQQDMe5c1O5Snd8CGjpQlXsm4U/K5MYfLrKhcV1W8BUD4kSoZ7LfyV42nGBb43TcvkyB2Dx8nPqqh/unzCw/lWixSifnKdKDZ3Z4Ky2K5DASDK/LvKtrtzDATHRYIi7albzsH0wFLyFJTbAm1Xs1b6IUDHzBHmFRflJnXjwkrab+h7hICGPUvKjgDtSYFnUdSxIZQOQuKHsXXvoUUf353hAqlTb09; 5:ZJLAz9e9o644AcgdshQO0uzpDpIrUtmdbunqcwgXvQxJzL8Ki53p1nBMu+Wg3S/ioSHQIdhAdSgWuCXbB0U0DofgR0Yxl2Xap7T01lbnvI93vr5be12gYGaCoDkpoTfomDxYLsr6oY040Dka1bP5GZUesSAp4/nKSaDDGkcmBmc=; 24:ggDBRX0t9YKOLsXFfdM7xKEzQswecZTy4/OAp8clFeaj6XR3R1icVVQSC3cE5VW6a47Jl3EvIyXFfBq5niKWsBJ3UlC9nUM+cpR0XT+SMy0=; 7:q/iEc9ITPwQ7NohWXg5FOngHyqOs2gX5qPcObfL9YmKjlfOlbcr+til6TtwXI8cfy2MmRq04NiVVur6JnBXWVf/IiOv6dgulhGDSMwgJ609avoTNYswmZUF6zi4uvLnIJ6rWA8x+ZrJWXw12/jKH95ZKi5Pb7lf5iTY5s2OROtw+ynktQIfT25pozsH1A0evUWC3Yv/KPuZ8WMRIdYjc8eaq0gm+DJcSpBMqT7zaHpNY4GsBVp4Ka51VhYgZU7iy x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: a559f780-45e6-44d5-4fa6-08d5794c3d6f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0136; x-ms-traffictypediagnostic: CY4PR21MB0136: x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(80524489315369)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001069)(61425038)(6040501)(2401047)(8121501046)(5005006)(3002001)(3231158)(944501161)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR21MB0136; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0136; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(39380400002)(396003)(366004)(199004)(189003)(13464003)(5250100002)(99286004)(22452003)(39060400002)(10290500003)(8990500004)(25786009)(478600001)(4326008)(86612001)(6116002)(6506007)(53546011)(59450400001)(8936002)(6346003)(14454004)(93886005)(2906002)(7736002)(229853002)(76176011)(7696005)(2950100002)(102836004)(186003)(10090500001)(3660700001)(55016002)(6246003)(8666007)(7116003)(305945005)(97736004)(6436002)(81156014)(105586002)(74316002)(8676002)(5660300001)(106356001)(33656002)(86362001)(110136005)(68736007)(9686003)(3280700002)(316002)(2900100001)(53936002)(54906003)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0136; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: Yh756PJ5TNA5NbVWUm/1284TTctIYbpUkvqaKj2fusWDopZPuyGPUzS27lTgpMPmjpJCsMe9f8kvbZoM1k/R4oSTzg7r3ph6/81IqnQLyZbom8GJG0WgttoUMcJ522Hum4oE2tZswwd59aEouHaUfAoEvbSH5wkEltWw16Tnc/Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: a559f780-45e6-44d5-4fa6-08d5794c3d6f X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2018 16:57:49.7036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0136 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, 21 Feb 2018 16:57:55 -0000 SXQgd291bGQgYmUgbmljZSB0byBwcm92aWRlIGFuIEVUQSBmb3Igd2hlbiBIMiBvdmVyIFFVSUMg aW50ZXJvcCB0ZXN0aW5nIHdpbGwgYmVnaW4uIExldCdzIHBsZWFzZSBjb250aW51ZSBIMC45IG92 ZXIgUVVJQyB0ZXN0aW5nIHRocm91Z2hvdXQgYWxsIGludGVyb3AgZXZlbnRzIHNvIHRoYXQgY29y ZSB0cmFuc3BvcnQgZnVuY3Rpb25hbGl0eSBpcyB0ZXN0ZWQgaW5kZXBlbmRlbnRseS4gDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFRob21zb24NClNlbnQ6IFR1ZXNkYXksIEZl YnJ1YXJ5IDIwLCAyMDE4IDc6NDUgUE0NClRvOiBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+ DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IGh1aXRlbWEgPGh1aXRlbWFAaHVpdGVtYS5u ZXQ+OyBSdWkgUGF1bG8gPHJwYXVsb0BhcHBsZS5jb20+DQpTdWJqZWN0OiBSZTogV2hvIHdhbnRz IC0xMCBkcmFmdHM/DQoNCk5vIHJpc2sgb2YgdGhhdC4NCg0KU29tZSBwZW9wbGUgYXJlIGxvb2tp bmcgdG8gdGFrZSB0aGUgbmV4dCBzdGVwIGFuZCBnZXQgc29tZSBleHBlcmllbmNlIHdpdGggYSBu b24tdG95IHVwcGVyIGxheWVyLiAgSSBhZ3JlZSB0aGF0IGZvciB0aGUgZ3JvdXAgYXMgYSB3aG9s ZSwgdGhhdCBzdGVwIGlzIGEgbGl0dGxlIHdheSBhd2F5IGp1c3QgeWV0Lg0KDQpPbiBXZWQsIEZl YiAyMSwgMjAxOCBhdCAyOjM2IFBNLCBFcmljIFJlc2NvcmxhIDxla3JAcnRmbS5jb20+IHdyb3Rl Og0KPiBJIHdvdWxkIGJlIHZlcnkgc2FkIGlmIHdlIG5lZWRlZCB0aGUgSDIgaW1wbGVtZW50YXRp b24gdG8gdGVzdCBRVUlDLiANCj4gVGhhdCBzZWVtcyBsaWtlIGl0IHdvdWxkIGJlIGJhZCBmb3Ig bGF5ZXJpbmcuDQo+DQo+IC1Fa3INCj4NCj4NCj4gT24gVHVlLCBGZWIgMjAsIDIwMTggYXQgNzow NiBQTSwgQ2hyaXN0aWFuIEh1aXRlbWEgDQo+IDxodWl0ZW1hQGh1aXRlbWEubmV0Pg0KPiB3cm90 ZToNCj4+DQo+PiBPbiAyLzIwLzIwMTggNjowOCBQTSwgTWFydGluIFRob21zb24gd3JvdGU6DQo+ Pg0KPj4gT24gV2VkLCBGZWIgMjEsIDIwMTggYXQgMTI6MzYgUE0sIFJ1aSBQYXVsbyA8cnBhdWxv QGFwcGxlLmNvbT4gd3JvdGU6DQo+Pg0KPj4gRm9yIHRoZSBwdXJwb3NlcyBvZiB0aGUgaW50ZXJv cCwgSSBiZWxpZXZlIHdlIHdlcmUgc3RpbGwgZG9pbmcgSFRUUCAwLjkuDQo+PiBIYXMgdGhhdCBj aGFuZ2VkPw0KPj4NCj4+IFllcywgaW50ZXJvcCBpcyBRVUlDIC0wOSBhbmQgSFRUUCAwLjkgKG5v IHJlbGF0aW9uKS4NCj4+DQo+PiBJ4oCZbSBub3Qgc3VyZSBob3cgbWFueSBwZW9wbGUgd2lsbCB0 YWtlIGFkdmFudGFnZSBvZiBocS0xMCBpbnRlcm9wIGJ1dCANCj4+IEkgZG9u4oCZdCBzZWUgYW55 IGhhcm0gaW4gcHVibGlzaGluZyAtMTAgZHJhZnRzLg0KPj4NCj4+IEkgbWlnaHQsIGJ1dCB3aGV0 aGVyIHRoYXQgaXMgcG9zc2libGUgd2lsbCBkZXBlbmQgb24gYSBncmVhdCBtYW55IA0KPj4gdGhp bmdzLiAgTm9yIGRvIEkgdGhpbmsgbXkgb3duIGltcGxlbWVudGF0aW9uIG1hdHRlcnMgbXVjaCBp biANCj4+IGRldGVybWluaW5nIHRoaXMuDQo+Pg0KPj4NCj4+IEkgdW5kZXJzdGFuZCB0aGF0IGF0 IHNvbWUgcG9pbnQgd2UgbXVzdCBzdGFydCBtb3ZpbmcgdXAgdGhlIHN0YWNrIGFuZCANCj4+IHRl c3QgdGhlIEhUVFAgbWFwcGluZ3MuIEkgYW0gbm90IGFueXdoZXJlIGNsb3NlIHRvIHJlYWR5IHdp dGggdGhhdCwgDQo+PiBiZWNhdXNlIEkgYW0gbm90IHN0YXJ0aW5nIHdpdGggYW4gSFRUUCAyIGlt cGxlbWVudGF0aW9uLiBJZiBpdCBpcyANCj4+IHdoYXQgaXMgdGFrZXMgdG8gdGVzdCB0aGUgdHJh bnNwb3J0LCBJIHdpbGwgZG8gb25lLCBvciBwb3J0IG9uZS4gQnV0IA0KPj4gbm8gd2F5IEkgY2Fu IGRvIHRoYXQgaW4gdGhlIG5leHQgOCBkYXlzLg0KPj4NCj4+IC0tIENocmlzdGlhbiBIdWl0ZW1h DQo+DQo+DQoNCg== From nobody Wed Feb 21 08:58:26 2018 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 DF3B112D87C for ; Wed, 21 Feb 2018 08:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 K1uk0pUKoUp2 for ; Wed, 21 Feb 2018 08:58:20 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 04E8512D875 for ; Wed, 21 Feb 2018 08:58:20 -0800 (PST) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 6B9EE1B00067; Wed, 21 Feb 2018 16:57:37 +0000 (GMT) Message-ID: <5A8DA500.2070101@erg.abdn.ac.uk> Date: Wed, 21 Feb 2018 16:57:36 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Ingemar Johansson S CC: "De Schepper, Koen (Nokia - BE/Antwerp)" , =?UTF-8?B?TWlyamEgS8O8aGxld2luZA==?= , QUIC WG , Christian Huitema , Ian Swett , "Lubashev, Igor" , "ekinnear@apple.com" Subject: Re: ECN in QUIC connection migration References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> <5CC94D22-1375-40A2-8084-BA4A43F6FA94@tik.ee.ethz.ch>, In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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, 21 Feb 2018 16:58:25 -0000 So I worked carefully through the text. Most of what I saw looked sound - well done! At places the language looked inconsistent with either other parts of the document or with other RFCs. I updated the wiki to resulve thses issues. Hoepfully the new text is more close to what we need, Gorry On 21/02/2018, 14:37, Ingemar Johansson S wrote: > > Hi > > Trying to pick up this thread again. > > Do we have some kind of minimal consensus around the proposed ECN > functionality in QUIC ? > > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#suggested-additions-to-to-become-rfcs > > /Ingemar > > *From:* De Schepper, Koen (Nokia - BE/Antwerp) > [mailto:koen.de_schepper@nokia-bell-labs.com] > *Sent:* den 14 februari 2018 17:49 > *To:* Mirja Kühlewind ; Ingemar > Johansson S > *Cc:* ekinnear@apple.com; Lubashev, Igor ; Ian > Swett ; QUIC WG ; Christian > Huitema ; Ingemar Johansson S > > *Subject:* RE: ECN in QUIC connection migration > > Hi Mirja, > > Why would you like to see the distinction? > > It was indeed decided in the side meeting that we should not foresee > extra protocol complexity for signalling that the receiver cannot read > the ecn bits. > > For me the reasons were: It is not a desired situation which will > hopefully disappear in the future, and I don't think it is so useful > for a sender to know. We now assume reading 00 bits and echo all > counters unincremented with 0 values in that case, just as if the path > bleaches it. If we make an explicit protocol exchange for it, it feels > like it is an extra feature ;-). Also people might start making their > congestion control more complex with up to 2 more conditional > parameters (sender-cannot-set-ecn and receiver-cannot-read-ecn > booleans, next to no-ecn). Not to mention extra interop testcases with > such sender's/receiver's extra functionality. > > To make your code simple and platform independent, not being able to > set/read echo bits should be invisible until the point of the missing > socket API call, which will most probably have conditional compiler > directives per platform at that point. > > So conclusion was: Any higher layer protocol code should not make any > distinction between host inability and path bleaching, and we only > have functionality for general "end2end ecn inability". > > Agreed that the receiver code should be independent from how ecn is > used. This is the case now. For the receiver we only increment and > echo the counters all the time. That's it, very simple. Only the > sender determines how ecn capability is checked and how ecn is used. > > Maybe also a good point that the current capability check is the > minimal?? And needs some extra checks? > > Regards, > > Koen. > > Outlook voor Android downloaden > > ------------------------------------------------------------------------ > > *From:*Ingemar Johansson S > > *Sent:* Wednesday, February 14, 2018 2:08:30 PM > *To:* Mirja Kühlewind > *Cc:* De Schepper, Koen (Nokia - BE/Antwerp); ekinnear@apple.com > ; Lubashev, Igor; Ian Swett; QUIC WG; > Christian Huitema; Ingemar Johansson S > *Subject:* RE: ECN in QUIC connection migration > > Hi > > I attach the minutes from the side meeting in Singapore, I believe > that they were only posted on the ecn-quic mailing list ☹ . > > I agree that the sender/received issues are probably known a-priory > and if a sender does know that its OS stack does not have the > necessary API support for ECN then it does not make much sense to try it. > > /Ingemar > > > > -----Original Message----- > > From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] > > Sent: den 13 februari 2018 13:29 > > To: Ingemar Johansson S > > > Cc: De Schepper, Koen (Nokia - BE/Antwerp) > bell-labs.com>; > ekinnear@apple.com ; Lubashev, Igor > > >; Ian Swett > >; QUIC WG > > >; Christian Huitema > > > > Subject: Re: ECN in QUIC connection migration > > > > Hi Ingemar, > > > > see below. > > > > > Am 12.02.2018 um 22:11 schrieb Ingemar Johansson S > > >: > > > > > > Hi > > > > > > Please see inline > > > > > > BR > > > Ingemar > > > > > >> -----Original Message----- > > >> From: Mirja Kühlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] > > >> Sent: den 12 februari 2018 16:26 > > >> To: Ingemar Johansson S > > > >> Cc: De Schepper, Koen (Nokia - BE/Antwerp) > >> bell-labs.com>; > ekinnear@apple.com ; Lubashev, Igor > > >> >; Ian Swett > >; QUIC WG > > >> >; Christian Huitema > > > > >> Subject: Re: ECN in QUIC connection migration > > >> > > >> Hi Ingemar, > > >> > > >> two points. > > >> > > >> I think it would be good to be as explicit as possible here, > > >> therefore I would prefer if an endpoint that knows that it can not > > >> access the ECN IP bits indicates this directly in the handshake. In > > >> this case no further testing is needed. > > > Yes, this was the original idea, we discussed this at the ECN > > > QUIC side meeting though and afterwards and as far as I understand it, > > > there was a consensus that it was unnecessarily complicated. So we > > > selected a method where we just verify that the ECT(0),ECT(1),CE > > > counters have reasonable values. If that is not the case, then it is > > > an indication that either the path or the endpoints do not support > > > ECN. > > > > I checked the minutes and could not really find a conclusion there. > I agree > > that there should be no negotiation in the handshake (both endpoint need > > to implement the ECN logic as part of v1) but what would be helpful > is to let > > the other end know if you already know that you never will be able to > > provide feedback because you can just not read the bits in the IP > header. > > That is not complicated at all. > > > > I think what we need to specify in v1 is a way to provide ECN > feedback (or > > indicate that this is not possible). However, we actually would not > need to > > say anything about how ECN should be used. That’s a sender side > decision. > > As long as you can get feedback, we are flexible in how to use and > test ECN in > > v1 or anytime later. Of course it would be nice to provide some default > > recommendations with some easy fallback logic but that's the part we can > > experiment with and change any time without any need to change the > > protocol spec (as long as ECN feedback is provided, when ECN is used > by the > > sender). > > > > > > > >> > > >> Further, the path testing itself is independent of QUIC and can be > > >> used for any protocol. Moreover, it’s more complicated than just > > >> testing ECT. I guess the general advice here is to remember which > > >> codepoints were send and compare this to the feedback provided. If > > >> discrepancies are observed that indicate that a middlebox has changed > > >> these bits, all packets should be marked as no-ECT (while additional > > >> testing MAY be performed at any later point in time). However, how > > >> exactly this testing should look like, should not be specified in > this doc > > (but more generally). > > > It is possible that the actual path verification can be put as a > > > separate document, not sure if that is accepted by the group or it is > > > desired with a more elaborate description directly in the QUIC drafts. > > > As regards to verification, I do believe that the proposed counters > > > should be able to detect bleaching, accidental remarking from ECT(0) > > > to ECT(1) and also cases where packets are not CE marked at all > > > despite other signs of congestion > > > > We tried to design a more elaborated testing scheme where we would send > > 3 ECT0, the 3 ECT1, and the 3 CE (which we would of cause not count as a > > congestion indication as the CE was set by the sender). However, > this was > > mostly to detect black-whaling which is probably less a concern than re- > > marking. I think today the most common case it that the bits will be > set to > > zeros which is only a problem when there was some CE marking previously > > on the path that then would get lost. Thus in this case it would be > > recommend to not use ECN/not set packets as ECT at sender side. > > > > However, as I said above, we probably should make recommendation how to > > use ECN by default but need to leave room for other usage/testing > schemes. > > But after all the receiver being not able to read the bits and > remarking on the > > path are to different things and should not be mixed up. If the > sender can > > not read the bits this is know a priori and there is no ambiguity > that needs to > > be tested. So why not signal it directly. The question if the sender > can write > > ECN does not need to be communicated. There is no difference in the > > sender decided to not use ECN or it just can not use it; in both > cases it is not > > necessary to send ECN feedback back. Only if a non-non-ECT is > observed at > > the receiver, ECN feedback needs to be provided. However, knowing that > > the receiver can’t not provide feedback is important because in this > case the > > sender MUST not set the packets as ECT as it will not be able to > react to that > > signal. Testing the path in independent of that. > > > > Mirja > > > > > > > > > > > > >> > > >> Mirja > > >> > > >> > > >>> Am 09.02.2018 um 08:34 schrieb Ingemar Johansson S > > >> >: > > >>> > > >>> Hi Eric, Koen + others > > >>> > > >>> Thanks for the comments and the update. A question to the rest of > > >>> the > > >> audience, does the presented text explain sufficiently enough how ECN > > >> works with connection migration ? > > >>> https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport- > > >> draft-connection-migration > > >>> > > >>> > > >>> /Ingemar > > >>> > > >>> > > >>> From: De Schepper, Koen (Nokia - BE/Antwerp) > > >> [mailto:koen.de_schepper@nokia-bell-labs.com] > > >>> Sent: den 2 februari 2018 15:44 > > >>> To: ekinnear@apple.com ; Ingemar > Johansson S > > >> > > > >>> Cc: QUIC WG >; Ian Swett > >; > > >> Lubashev, Igor >; Christian Huitema > > >> > > > >>> Subject: RE: ECN in QUIC connection migration > > >>> > > >>> Hi Ingemar, > > >>> > > >>> I also read again through the document, and had following comments: > > >>> > > >>> I replaced: > > >>> “The ACK_ECN frame is used to convey ACKs when the ECN capability > > >> exchange concludes that ECN should be used for the given connection.” > > >>> Originally it sounds as if the counters are not echoed anymore if > > >>> the ECN > > >> capability check fails. I assume this was not the intention, but if > > >> it is: First, we don’t have a protocol or decision point defined when > > >> that condition is met (sender should let the receiver know in the > > >> next packet), and second, I would always send the echo, as we might > > >> “try again later (with another ECT?)”, or might decide to use the > ECN bits > > differently later. > > >>> > > >>> I also changed the text around the connection migration, I think > > >>> before Eric > > >> reviewed it. I made it such that every new path creates a new > > >> connection state with an initialized congestion control state and ECN > > >> counters (at least ECN counters reset to 0s). Not sure if this > > >> matches with the other sections in the QUIC draft. > > >>> > > >>> I also had the thought whether it was really needed to have the 2 > > >>> cases. I > > >> agree we should simplify, by just starting over and doing the check > > >> unconditionally whether it was successful or not in a previous path. > > >>> > > >>> Regards, > > >>> Koen. > > >>> > > >>> From: ekinnear@apple.com > [mailto:ekinnear@apple.com] > > >>> Sent: Friday, February 2, 2018 12:02 AM > > >>> To: Ingemar Johansson S > > > >>> Cc: QUIC WG >; Ian Swett > >; > > >> Lubashev, Igor >; Christian Huitema > > >> >; De Schepper, > Koen (Nokia - BE/Antwerp) > > >> > > > >>> Subject: Re: ECN in QUIC connection migration > > >>> > > >>> Hi Ingemar, > > >>> > > >>> This generally looks good to me! > > >>> A few questions and observations: > > >>> > > >>> There are two unique cases: > > >>> > > >>> • ECN capability check successful at initial > connection setup > > >>> • ECN capability check failed at initial connection > > >>> setup > > >>> > > >>> Are these actually any different in terms of action taken by an > endpoint? > > >>> It seems like on the new network path the endpoint would go through > > >>> the > > >> same process of: (a) verify ECN capability and if successful to > > >> whatever degree then (b) run the rest of the ECN machinery as > > appropriate. > > >>> > > >>> In other words, as long as you allow people to start using ECN upon > > >> migration (in other words, to allow starting it after the initial > > >> connection establishment), then the specifics for ECN with migration > > >> is essentially one statement, which is “do the ECN process on each > > >> new network path that you use”. > > >>> > > >>> Connection migration has impact on the number of reported CE marked > > >> packets. A new connection state with new congestion control state and > > >> ECN counters is instantiated at the sender and receiver. The ECN > > >> counters MUST start from zero again. > > >>> > > >>> This seems fine to me, it’s inline with the rest of the congestion > > >> control/loss recovery state that also needs to be reset for the > new path. > > >>> > > >>> Given that each migration requires at least one exchange of packets > > >>> at the > > >> beginning (at the very least for address validation from the side of > > >> the endpoint that didn’t migrate), it seems like that’s an excellent > > >> moment to mark the packets and perform the ECN capability detection. > > >> Those packets are also likely padded, etc. similar to initial packets > > >> since they’re on a previously unused network path. > > >>> > > >>> I think the current proposed requirement of just using the “first” > > >>> packets > > >> and marking those is sufficient (and good to avoid any requirement as > > >> to which frames are contained in those packets), since we are always > > >> exchanging packets in both directions immediately after migration. > > >>> > > >>> This has the added benefit such that any endpoint “probing” possible > > >> network paths could include the bits necessary to detect ECN > > >> capability on the path being probed, so it could even know before > > >> migrating whether or not it would be able to use ECN on that new > path. > > >>> > > >>> Thanks, > > >>> Eric > > >>> > > >>> > > >>> > > >>> > > >>> On Feb 1, 2018, at 3:07 AM, Ingemar Johansson S > > >> > wrote: > > >>> > > >>> Hi > > >>> I have written up different aspects of connection migration and how > > >>> it > > >> plays with ECN. > > >>> https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC#transport- > > >> draft-connection-migration > > >>> > > >>> A caveat.. I am a bit unsure about the definition of connection > migration > > . > > >> My interpretation is that a client moves to a new IP address due to > > >> e.g. a NAT rebind or switch from WiFi to cellular, right ?. Is a new > > >> connection instantiated at a connection migration ? > > >>> > > >>> /Ingemar > > >>> > > >>> ================================== > > >>> Ingemar Johansson M.Sc. > > >>> Master Researcher > > >>> > > >>> Ericsson Research > > >>> Network Protocols & E2E Performance > > >>> Labratoriegränd 11 > > >>> 971 28, Luleå, Sweden > > >>> Phone +46-1071 43042 > > >>> SMS/MMS +46-73 078 3289 > > >>> ingemar.s.johansson@ericsson.com > > > >>> www.ericsson.com > > >>> > > >>> You can't start a fire Worrying 'bout your little > > >>> world falling apart > > >>> Bruce Springsteen > > >>> ================================== > > > > From nobody Wed Feb 21 10:13:16 2018 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 232AF12D890 for ; Wed, 21 Feb 2018 10:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-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 2nIFoq4pDX_g for ; Wed, 21 Feb 2018 10:13:13 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36DC812D887 for ; Wed, 21 Feb 2018 10:13:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3zmlw75Cm5zMmrF; Wed, 21 Feb 2018 19:13:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZ1yQXrj5KVK; Wed, 21 Feb 2018 19:13:10 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.220.145] (178-83-155-34.dynamic.hispeed.ch [178.83.155.34]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 21 Feb 2018 19:13:10 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: handling a QUIC accept backlog From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 21 Feb 2018 19:13:10 +0100 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch> References: To: Marten Seemann X-Mailer: Apple Mail (2.3445.5.20) 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, 21 Feb 2018 18:13:15 -0000 Hi Martin, I think that could fit well in the applicability doc. If people agree, = please go ahead and file an issue or a PR. As a general note, both the applicability and the manageability = statements are outdated, as things are so much in move still and = therefore we didn=E2=80=99t put effort in to sync up with every = revision. As soon as things (especially around the wire image and = handshake) have settle a bit more, we will do an update. Mirja > Am 21.02.2018 um 17:39 schrieb Marten Seemann = : >=20 > When using a socket API for a QUIC server, it can happen that there = are more incoming connections than the server can accepts at that = moment. I imagine that a server will implement some sort of queue = containing connections that have the handshake completed. Do we need any = guidance on what should happen when that queue is full? >=20 > There are multiple ways how a server could handle this situation: >=20 > =E2=80=A2 Drop all Initial packets. > =E2=80=A2 Send a CONNECTION_CLOSE as a response to an Initial. > =E2=80=A2 Reply with Retries to Initial packets, but drop = Handshake packets. > =E2=80=A2 Something more sophisticated? > Should we write anything about this in the spec, or is this something = that implementations have to figure out for themselves without any = guidance? >=20 From nobody Wed Feb 21 11:45:39 2018 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 A902312DA3F for ; Wed, 21 Feb 2018 11:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_H2=-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 ofrVq6LL1cYI for ; Wed, 21 Feb 2018 11:45:35 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0096.outbound.protection.outlook.com [104.47.38.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 8A5C312DA25 for ; Wed, 21 Feb 2018 11:45:35 -0800 (PST) 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=DWk4nPZmb5xlVuTgoxpaBcygJc5q9TiGwS7Ty5Jvb7g=; b=ijI8OpSHOwrIch+wS0WCAqorv2+6jJJEtEcanmXL6PqBmcD5eGtScE40+oorx0g3aPuCTNJJ4heOIgng8ak4L8iXU8LKgrWYHo8UV0up3fKnnJNoT7tLMErBaC3dsvPSyGPtRgSCFdgWC6YsBeiw1uhNrzl16vMYHHCAIsyjfqQ= Received: from CY4PR21MB0133.namprd21.prod.outlook.com (10.173.189.15) by CY4PR21MB0775.namprd21.prod.outlook.com (10.173.192.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.1; Wed, 21 Feb 2018 19:45:33 +0000 Received: from CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::9df5:45b9:854a:4f16]) by CY4PR21MB0133.namprd21.prod.outlook.com ([fe80::9df5:45b9:854a:4f16%9]) with mapi id 15.20.0548.005; Wed, 21 Feb 2018 19:45:33 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Marten Seemann CC: QUIC WG Subject: RE: handling a QUIC accept backlog Thread-Topic: handling a QUIC accept backlog Thread-Index: AQHTqzKuknd4i4lDqEaeH45SGqZBy6OvKN0AgAANCZA= Date: Wed, 21 Feb 2018 19:45:33 +0000 Message-ID: References: <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch> In-Reply-To: <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:5::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0775; 7:+7v86HlH+LIdssEmwAx1iYAAABe+WpXbm4fY0Y3qN7vA+ryugQe72qLmp8gaJTwzfQoiHahTcJpjUQmKN+904QGku0AeF5+KCdhREuDj1aVVHIN25NZM+VYAg/4ly7qUNwvB0va9Sa6dwTSnFpcbKvkZEYq6KfufM/Lv18em78Mk/qmo3pTuHWxOPaOgI2/OaF0MCdQWnpmXQdlgevRf4GWdmZdNj0t6K2wMT+gcXP9XKgYxy4rb6gjbRKaw+HlN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6177d8ce-0f1f-47b1-b638-08d57963abfa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:CY4PR21MB0775; x-ms-traffictypediagnostic: CY4PR21MB0775: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001070)(61425038)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231158)(944501161)(52105067)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR21MB0775; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0775; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(396003)(366004)(376002)(346002)(51444003)(199004)(189003)(13464003)(57704003)(229853002)(10290500003)(478600001)(25786009)(9686003)(3660700001)(39060400002)(102836004)(53546011)(6506007)(55016002)(8936002)(6436002)(59450400001)(76176011)(68736007)(2950100002)(4326008)(6346003)(305945005)(14454004)(33656002)(53936002)(7736002)(74316002)(99286004)(6116002)(2900100001)(7696005)(81156014)(81166006)(97736004)(10090500001)(86362001)(22452003)(6246003)(3280700002)(316002)(8676002)(86612001)(8990500004)(186003)(2906002)(110136005)(106356001)(105586002)(5660300001)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0775; H:CY4PR21MB0133.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-message-info: zo8+LG7vMvTYQTggUCzralnGRWwQSwMxpO+Oy4HGVm/Hcxktwlf6TWn5s1kQZJ233OPKI5RRoArH1nHiqzK7pQ5NeNH+sZQdZWsWORMRiEl5bBjRSrM9yP/l2YEgWZLE7RUpX3/GL9bJSaQPm0qDhe+MuTWf+LHdq57CSVLDV4k= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6177d8ce-0f1f-47b1-b638-08d57963abfa X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2018 19:45:33.6069 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0775 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, 21 Feb 2018 19:45:38 -0000 VGhpcyBpcyBzb21ld2hhdCByZWxhdGVkIHRvIERvUyBhdHRhY2sgbWl0aWdhdGlvbiBhbmQgY291 bGQgZ28gaW50byDigJxTZWN1cml0eSBhbmQgUHJpdmFjeSBDb25zaWRlcmF0aW9uc+KAnSBzZWN0 aW9uIG9mIGVpdGhlciB0aGUgdHJhbnNwb3J0IG9yIHRoZSBhcHBsaWNhYmlsaXR5IGRyYWZ0IHdp dGggc29tZSByZWNvbW1lbmRhdGlvbiBvbiB0aGUgYXR0YWNrIHZlY3RvcnMgYW5kIG1pdGlnYXRp b25zLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUVVJQyBbbWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pcmphIEvDvGhsZXdpbmQNClNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMjEsIDIwMTggMTA6MTMgQU0NClRvOiBNYXJ0ZW4gU2VlbWFu biA8bWFydGVuc2VlbWFubkBnbWFpbC5jb20+DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBoYW5kbGluZyBhIFFVSUMgYWNjZXB0IGJhY2tsb2cNCg0KSGkgTWFydGlu LA0KDQpJIHRoaW5rIHRoYXQgY291bGQgZml0IHdlbGwgaW4gdGhlIGFwcGxpY2FiaWxpdHkgZG9j LiBJZiBwZW9wbGUgYWdyZWUsIHBsZWFzZSBnbyBhaGVhZCBhbmQgZmlsZSBhbiBpc3N1ZSBvciBh IFBSLg0KDQpBcyBhIGdlbmVyYWwgbm90ZSwgYm90aCB0aGUgYXBwbGljYWJpbGl0eSBhbmQgdGhl IG1hbmFnZWFiaWxpdHkgc3RhdGVtZW50cyBhcmUgb3V0ZGF0ZWQsIGFzIHRoaW5ncyBhcmUgc28g bXVjaCBpbiBtb3ZlIHN0aWxsIGFuZCB0aGVyZWZvcmUgd2UgZGlkbuKAmXQgcHV0IGVmZm9ydCBp biB0byBzeW5jIHVwIHdpdGggZXZlcnkgcmV2aXNpb24uIEFzIHNvb24gYXMgdGhpbmdzIChlc3Bl Y2lhbGx5IGFyb3VuZCB0aGUgd2lyZSBpbWFnZSBhbmQgaGFuZHNoYWtlKSBoYXZlIHNldHRsZSBh IGJpdCBtb3JlLCB3ZSB3aWxsIGRvIGFuIHVwZGF0ZS4NCg0KTWlyamENCg0KDQoNCj4gQW0gMjEu MDIuMjAxOCB1bSAxNzozOSBzY2hyaWViIE1hcnRlbiBTZWVtYW5uIDxtYXJ0ZW5zZWVtYW5uQGdt YWlsLmNvbT46DQo+IA0KPiBXaGVuIHVzaW5nIGEgc29ja2V0IEFQSSBmb3IgYSBRVUlDIHNlcnZl ciwgaXQgY2FuIGhhcHBlbiB0aGF0IHRoZXJlIGFyZSBtb3JlIGluY29taW5nIGNvbm5lY3Rpb25z IHRoYW4gdGhlIHNlcnZlciBjYW4gYWNjZXB0cyBhdCB0aGF0IG1vbWVudC4gSSBpbWFnaW5lIHRo YXQgYSBzZXJ2ZXIgd2lsbCBpbXBsZW1lbnQgc29tZSBzb3J0IG9mIHF1ZXVlIGNvbnRhaW5pbmcg Y29ubmVjdGlvbnMgdGhhdCBoYXZlIHRoZSBoYW5kc2hha2UgY29tcGxldGVkLiBEbyB3ZSBuZWVk IGFueSBndWlkYW5jZSBvbiB3aGF0IHNob3VsZCBoYXBwZW4gd2hlbiB0aGF0IHF1ZXVlIGlzIGZ1 bGw/DQo+IA0KPiBUaGVyZSBhcmUgbXVsdGlwbGUgd2F5cyBob3cgYSBzZXJ2ZXIgY291bGQgaGFu ZGxlIHRoaXMgc2l0dWF0aW9uOg0KPiANCj4gCeKAoiBEcm9wIGFsbCBJbml0aWFsIHBhY2tldHMu DQo+IAnigKIgU2VuZCBhIENPTk5FQ1RJT05fQ0xPU0UgYXMgYSByZXNwb25zZSB0byBhbiBJbml0 aWFsLg0KPiAJ4oCiIFJlcGx5IHdpdGggUmV0cmllcyB0byBJbml0aWFsIHBhY2tldHMsIGJ1dCBk cm9wIEhhbmRzaGFrZSBwYWNrZXRzLg0KPiAJ4oCiIFNvbWV0aGluZyBtb3JlIHNvcGhpc3RpY2F0 ZWQ/DQo+IFNob3VsZCB3ZSB3cml0ZSBhbnl0aGluZyBhYm91dCB0aGlzIGluIHRoZSBzcGVjLCBv ciBpcyB0aGlzIHNvbWV0aGluZyB0aGF0IGltcGxlbWVudGF0aW9ucyBoYXZlIHRvIGZpZ3VyZSBv dXQgZm9yIHRoZW1zZWx2ZXMgd2l0aG91dCBhbnkgZ3VpZGFuY2U/DQo+IA0KDQo= From nobody Wed Feb 21 12:15:58 2018 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 D0D621201F2 for ; Wed, 21 Feb 2018 12:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 KNRU0aov_VPa for ; Wed, 21 Feb 2018 12:15:52 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 A4E4412D94A for ; Wed, 21 Feb 2018 12:15:52 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id o9so3620014itc.1 for ; Wed, 21 Feb 2018 12:15:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=SZamusqWT4pv49T+Z+KLUssz2E0utWUTr4bi8WPJ15g=; b=WpHpt8vcASzPTsaB3RGRJ6KfHsUf7oOFQ8EBEAoHxa5zSNP/bRLuP8aRwau+RSeW5H W2U8LRAe3yrEzAr2/Y9LyIwXL6Y3qgznReKeHpEzdxnbweZ6YboH46k/Jp4m1J7yZcYT nVjf5P7qyms8/BKOVD5vSBO3e0lnvWybyDuKfrtcUgrfJq22ByXZo7cy0ActY8+ijlGD Y8r7hG7KUKsoOX3eNS254Bp5yReOg1CZCnB9Hl7BE0dlHqxpzxwjoWcso4Dy8MnzTBJj +1u+5KlzDSbzDekjyqZXF4BzJWqMfnAcHdGssdto5altmlRmvXCi5N/PYRzvX0V6RlIR 3LTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=SZamusqWT4pv49T+Z+KLUssz2E0utWUTr4bi8WPJ15g=; b=jny9A4eB7TAiwG9er9UQY57+L9Ki4J93x+3ANblm9I5zK4IlTYd6dLhILRClKmO1PT PUZcRATDLD4TFCzYmqcLZKEHuohuNyRm+v5e3Oj/2paDT+xO38NGpxtYLCZuFieiXNRc 9fXgk0INihHiDCQZhwI7Tx2zP8EoDvgtc9v23u8QVttTrr0XYRLx4Blt0hnwS+xGWwJ1 BthFfcAUuwsMYB+TWpy+WaG/FwnbZC9rYzQwk1dRenjRqy2YaF3MD24AH1NnU113dWch 43aXPUdmhps5eK2iZ0zjzZ03Ua6/hb+jw/WTWyXFA2qqZioIl0kbNtaz3X+B/5LeTKBE F78Q== X-Gm-Message-State: APf1xPCu5C8VvQmXqmve7qWbLQL1lEvIqfTV2Z4G5N+cHZ4nyaWmAVrL 0du/WwOZTJ3kOec/8UB4Dd/xULVcTKxTIy+uVyI= X-Google-Smtp-Source: AH8x226iV/5Cppg2CnnOqSAmnCtWbiqgqWP7U2gmFo6k0ZBsBsMd7lf3LY+U8iwYctegCcPleE7Fb55s/lYQiFo0n78= X-Received: by 10.36.123.198 with SMTP id q189mr5040169itc.118.1519244151979; Wed, 21 Feb 2018 12:15:51 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 21 Feb 2018 15:15:51 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 21 Feb 2018 15:15:51 -0500 Message-ID: Subject: RE: handling a QUIC accept backlog To: Marten Seemann , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Praveen Balasubramanian Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a114760b20190d70565be98b4" 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, 21 Feb 2018 20:15:56 -0000 --001a114760b20190d70565be98b4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is also the argument for HTTP 500 Server Busy - could be protocol specific. But load balancer might also want to know when routing encrypted data. LB signals could also happen through the CID sub protocol - helping load balancers might otherwise also help DoS attackers? It could also be an ECN signal + drop. Unless we really want to help load balancers, I agree it is more an applicability thing. On 21 February 2018 at 20.45.42, Praveen Balasubramanian ( pravb@microsoft.com) wrote: This is somewhat related to DoS attack mitigation and could go into =E2=80=9CSecurity and Privacy Considerations=E2=80=9D section of either the= transport or the applicability draft with some recommendation on the attack vectors and mitigations. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mirja K=C3=BChlewind Sent: Wednesday, February 21, 2018 10:13 AM To: Marten Seemann Cc: QUIC WG Subject: Re: handling a QUIC accept backlog Hi Martin, I think that could fit well in the applicability doc. If people agree, please go ahead and file an issue or a PR. As a general note, both the applicability and the manageability statements are outdated, as things are so much in move still and therefore we didn=E2= =80=99t put effort in to sync up with every revision. As soon as things (especially around the wire image and handshake) have settle a bit more, we will do an update. Mirja > Am 21.02.2018 um 17:39 schrieb Marten Seemann : > > When using a socket API for a QUIC server, it can happen that there are more incoming connections than the server can accepts at that moment. I imagine that a server will implement some sort of queue containing connections that have the handshake completed. Do we need any guidance on what should happen when that queue is full? > > There are multiple ways how a server could handle this situation: > > =E2=80=A2 Drop all Initial packets. > =E2=80=A2 Send a CONNECTION_CLOSE as a response to an Initial. > =E2=80=A2 Reply with Retries to Initial packets, but drop Handshake packe= ts. > =E2=80=A2 Something more sophisticated? > Should we write anything about this in the spec, or is this something that implementations have to figure out for themselves without any guidance? > --001a114760b20190d70565be98b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = There is also the ar= gument for HTTP 500 Server Busy - could be protocol specific.
But load balancer might a= lso want to know when routing encrypted data.
LB signals could also happen through the CID sub protocol -
<= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:= 13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">helping load balanc= ers might otherwise also help DoS attackers?
It could also be an ECN signal + drop.

Unless we really want to = help load balancers, I agree it is more an applicability thing.

On 21 February 2018 at 20.45.42, Praveen Balasubramanian (pravb@microsoft.com) wrote:

This is so= mewhat related to DoS attack mitigation and could go into =E2=80=9CSecurity= and Privacy Considerations=E2=80=9D section of either the transport or the= applicability draft with some recommendation on the attack vectors and mit= igations.

-----Original Message-----
From: QUIC [mailto:quic-bounce= s@ietf.org] On Behalf Of Mirja K=C3=BChlewind
Sent: Wednesday, February 21, 2018 10:13 AM
To: Marten Seemann <marte= nseemann@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Subject: Re: handling a QUIC accept backlog

Hi Martin,

I think that could fit well in the applicability doc. If people agree, = please go ahead and file an issue or a PR.

As a general note, both the applicability and the manageability stateme= nts are outdated, as things are so much in move still and therefore we didn= =E2=80=99t put effort in to sync up with every revision. As soon as things = (especially around the wire image and handshake) have settle a bit more, we= will do an update.

Mirja



> Am 21.02.2018 um 17:39 schrieb Marten Seemann <martenseemann@gmail.com>:
> =20
> When using a socket API for a QUIC server, it can happen that ther= e are more incoming connections than the server can accepts at that moment.= I imagine that a server will implement some sort of queue containing conne= ctions that have the handshake completed. Do we need any guidance on what s= hould happen when that queue is full?
> =20
> There are multiple ways how a server could handle this situation:
> =20
> =E2=80=A2 Drop all Initial packets.
> =E2=80=A2 Send a CONNECTION_CLOSE as a response to an Initial.
> =E2=80=A2 Reply with Retries to Initial packets, but drop Handsha= ke packets.
> =E2=80=A2 Something more sophisticated?
> Should we write anything about this in the spec, or is this someth= ing that implementations have to figure out for themselves without any guid= ance?
> =20

--001a114760b20190d70565be98b4-- From nobody Wed Feb 21 15:50:48 2018 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 91080120724 for ; Wed, 21 Feb 2018 15:50:46 -0800 (PST) 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 Cqi98lqUUZ6H for ; Wed, 21 Feb 2018 15:50:44 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::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 901C91200E5 for ; Wed, 21 Feb 2018 15:50:44 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id k7so2387018otj.0 for ; Wed, 21 Feb 2018 15:50:44 -0800 (PST) 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=96dN6jIeYnt/mYmSEhqukualw/Mal7qBJXFKjmM+pO0=; b=rmJRFiDEr+YCovphZzBHs9ti+4rKYWgMA6wqSl4rj90aXHaO8J9WmZ4smyiua3wPQB WaFSSWoqRBvoTtAcOKw0E9bz1RvmuFc5fqsiL+PgJ7IHNXduUWmBA1F3u2/GdAFiDtFO O7OPchuemhsJOSilBJ1B3cXkMpiswNdZ8C5x3vOZn+qi9JxB/F4RMC8ndalg18mSgEGf /M+Pw6L8SRDLrxhONUzeDc19cZa0mziJe3zX7YJSyb0K7ZYkr29YKwKFqS/+Ccmtg1LF fyZFHuHMIkxX8W+b6ZWCXBtNpZKG2oh80TlJm9IRPGLlucEulYniKI5R5Jq4XnHnm4Dz M3mQ== 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=96dN6jIeYnt/mYmSEhqukualw/Mal7qBJXFKjmM+pO0=; b=kwg6G50Delb4neYiUdPcoRZXC7rOnP+3JhTdIRyfRnewoIy5dCyZN6eFSmh81RctIo CSKcUm/wNYf3PoYgus4fjzokDT6Raxic4IayfNTSO9jW9HTcfTevaACdM+B0eDSa/DdT fGK6C069+xuAq5WocWuZTqLfmQSh29ADQoPTCs5fqT8XkkVGd0a6cgJrk4uFccBLsaQ/ fNvWyQ0k7fLAoNKDIj/NnwZ2XbWyAJooh3BIZlb65Z8/6eLXtqUAHeSuuK8OGYCHJJqW cXOQedJVFLhsNc0cFi6mafpMxW0CUjJ3FMND26GhiiW/FyBXyrY2SOya8XfyVWG+EWTy tASA== X-Gm-Message-State: APf1xPA36bWvk3qC6J0nSpMsRrqkVUkCFeb8qJ7Y6VRSHvYkkLLWdHaz E8KTn8+gIhmBDCAOwXm00ycpna3wm3lQSpV8rgI= X-Google-Smtp-Source: AH8x227n04LDUxknBrWgREDW611jofpu0FnV8R23RZNw66NYr05YD8gZW50oImH31Q6CDTdgYCLEJtsIUqjwXvwDgWg= X-Received: by 10.157.0.74 with SMTP id 68mr3563421ota.392.1519257043795; Wed, 21 Feb 2018 15:50:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Wed, 21 Feb 2018 15:50:43 -0800 (PST) In-Reply-To: <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch> References: <0467B015-09FC-456D-BB6F-29B5F308C4E4@tik.ee.ethz.ch> From: Martin Thomson Date: Thu, 22 Feb 2018 10:50:43 +1100 Message-ID: Subject: Re: handling a QUIC accept backlog To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Marten Seemann , 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, 21 Feb 2018 23:50:46 -0000 Marten's question is a design one, I think. But as an operational practice, some additional documentation elsewhere could help. I don't think that I had any expectation, but it seems like a good idea to have some way that a server can signal "not now". That increases DoS risk (to the other discussion this week), but I think that in terms of our agreed principle on trying to stop that sort of attack, we shouldn't worry too much about that right now. Dropping Initial packets works. It's probably something to do in the extreme case. CONNECTION_CLOSE is probably better (better yet if we had an "I'm overloaded" code, PR wanted). Retry doesn't really work unless you think an extra round trip will cool things down enough. If you get to the point of receiving Handshake, then CONNECTION_CLOSE is all you really have, but you probably want to avoid doing that (because you already sunk a ton of effort into the first round of Handshake messages). Note that a server with too many connections can (and probably should) use HTTP Alternative Services to shed load, but that won't necessarily help in the short term. On Thu, Feb 22, 2018 at 5:13 AM, Mirja K=C3=BChlewind wrote: > Hi Martin, > > I think that could fit well in the applicability doc. If people agree, pl= ease go ahead and file an issue or a PR. > > As a general note, both the applicability and the manageability statement= s are outdated, as things are so much in move still and therefore we didn= =E2=80=99t put effort in to sync up with every revision. As soon as things = (especially around the wire image and handshake) have settle a bit more, we= will do an update. > > Mirja > > > >> Am 21.02.2018 um 17:39 schrieb Marten Seemann : >> >> When using a socket API for a QUIC server, it can happen that there are = more incoming connections than the server can accepts at that moment. I ima= gine that a server will implement some sort of queue containing connections= that have the handshake completed. Do we need any guidance on what should = happen when that queue is full? >> >> There are multiple ways how a server could handle this situation: >> >> =E2=80=A2 Drop all Initial packets. >> =E2=80=A2 Send a CONNECTION_CLOSE as a response to an Initial. >> =E2=80=A2 Reply with Retries to Initial packets, but drop Handshak= e packets. >> =E2=80=A2 Something more sophisticated? >> Should we write anything about this in the spec, or is this something th= at implementations have to figure out for themselves without any guidance? >> > From nobody Thu Feb 22 02:51:29 2018 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 58BF912E8F1 for ; Thu, 22 Feb 2018 02:51:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Subject: Milestones changed for quic WG X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151929668736.21080.9385114678872666065.idtracker@ietfa.amsl.com> Date: Thu, 22 Feb 2018 02:51:27 -0800 From: IETF Secretariat 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: Thu, 22 Feb 2018 10:51:27 -0000 Changed milestone "Core Protocol document to IESG", added draft-ietf-quic-transport to milestone. Changed milestone "Loss detection and Congestion Control document to IESG", added draft-ietf-quic-recovery to milestone. Changed milestone "TLS 1.3 Mapping document to IESG", added draft-ietf-quic-tls to milestone. Changed milestone "HTTP/2 mapping document to IESG", added draft-ietf-quic-http to milestone. Changed milestone "QUIC Applicability and Manageability Statement to IESG", added draft-ietf-quic-applicability to milestone. URL: https://datatracker.ietf.org/wg/quic/about/ From nobody Thu Feb 22 05:33:21 2018 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 01FB912EAC0 for ; Thu, 22 Feb 2018 05:33:19 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Subject: Milestones changed for quic WG X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151930639900.21173.7760399806579883260.idtracker@ietfa.amsl.com> Date: Thu, 22 Feb 2018 05:33:19 -0800 From: IETF Secretariat 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: Thu, 22 Feb 2018 13:33:19 -0000 Changed milestone "Working group adoption of Header Compression for HTTP over QUIC", set state to active from review, accepting new milestone. Changed milestone "Working group adoption of Version-Independent Properties of QUIC", set state to active from review, accepting new milestone. Changed milestone "Version-Independent Properties of QUIC to IESG", set state to active from review, accepting new milestone. Changed milestone "Header Compression for HTTP over QUIC to IESG", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/quic/about/ From nobody Thu Feb 22 07:14:07 2018 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 60A30127522 for ; Thu, 22 Feb 2018 07:14:06 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: Subject: Milestones changed for quic WG X-Test-IDTracker: no X-IETF-IDTracker: 6.72.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151931244639.8132.4442532409278924393.idtracker@ietfa.amsl.com> Date: Thu, 22 Feb 2018 07:14:06 -0800 From: IETF Secretariat 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: Thu, 22 Feb 2018 15:14:06 -0000 Changed milestone "QUIC Applicability and Manageability Statement to IESG", added draft-ietf-quic-manageability to milestone. URL: https://datatracker.ietf.org/wg/quic/about/ From nobody Sat Feb 24 16:45:23 2018 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 D40411243F6 for ; Sat, 24 Feb 2018 16:45:22 -0800 (PST) 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, 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=RfLLy0Mk; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VKUmi4+L 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 6bsl7jVziDc6 for ; Sat, 24 Feb 2018 16:45:20 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA1E120713 for ; Sat, 24 Feb 2018 16:45:20 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7E05A20C90 for ; Sat, 24 Feb 2018 19:45:19 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Sat, 24 Feb 2018 19:45:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:subject:to :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=zUe3arZrRVL14OwFt RKAnaHcuK1S4jQ8I/QWGdPfcAw=; b=RfLLy0Mk+19Eg+wCpEwEgGx++RgDUthah zEf9FbUn2+cEDHyWnrZAW8eULv9xEYjqGk8JSkPGO/IH4sLBdnyRvZQtEu4JZsVB LSioE0x5luRO9BK7V2dTqsD/EBdcbf3wo+MR/HdQWQIOros2aNYfcaAvJXiIkhlO z60Zj2cQOWvUqbrVOw1idLFB1YPDHWH5Td5Dv14jc4NGwMkEj/Du1l766lZ8QuTL GiF2967kRUk3Bl9c5JabKk6vJxDR6WsBW6E2a1VnaGF5jlqkx/BwzEui+G56yYS9 EVifcOoFyxGBLtIAUS9h4BPMlueGn4NJp2GDn9m8aQBqpeRKAvyaw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; bh=zUe3arZrRVL14OwFtRKAnaHcuK1S4jQ8I/QWGdPfcAw=; b=VKUmi4+L E5VRiQTF//TfzBAdShgr3z5VnuNoOiY34dUPxyCORlbYvxe/HslhLk2M+Yk/P/RA F9xPlKjYDw3rifnJuQa7gaVY4TYRSKT/E0D8yUm3cZ+tTMURzWq9hfxFR7ND1ku9 4KReqYwFkByoz4u3vv1X11XU0ADBrIJqMnpeM5D6Yeav/9oVJ5mf84NwsmHYbSCW Z3PzQblCDcdQ8/NkI9mPVH+XKSGlzMYFtuTz6vBplgameRXK9Z7hmzSR5p0jZ50a GgAMLnz0LyIHnF29+f54ppzbAoDIYz1nag1FJjb8nyz7zxproU5RbpXrKcmCWdIf +Fr4gtOinugzrA== X-ME-Sender: Received: from cloud.mnot.net (cloud.mnot.net [119.9.43.241]) by mail.messagingengine.com (Postfix) with ESMTPA id BD52B7E12E for ; Sat, 24 Feb 2018 19:45:18 -0500 (EST) Received: from cloud.mnot.net (localhost [127.0.0.1]) by cloud.mnot.net (Postfix) with ESMTP id 16F50C27D7 for ; Sun, 25 Feb 2018 00:45:16 +0000 (UTC) Content-Type: multipart/alternative; boundary="===============1639984626942533518==" MIME-Version: 1.0 From: =?utf-8?q?Github_Notifications?= To: quic@ietf.org Subject: Weekly github digest (QUIC Working Group Specifications) Message-Id: <20180225004516.16F50C27D7@cloud.mnot.net> Date: Sun, 25 Feb 2018 00:45:16 +0000 (UTC) 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, 25 Feb 2018 00:45:23 -0000 --===============1639984626942533518== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * quicwg/base-drafts (+7/-4/=F0=9F=92=AC31) 7 issues created: - QCRAM encoding requires two passes (by afrind) https://github.com/quicwg/base-drafts/issues/1138 [-qcram] [design] = - qcram document title should include the term "QCRAM" (by reschke) https://github.com/quicwg/base-drafts/issues/1133 = - qcram acks (by reschke) https://github.com/quicwg/base-drafts/issues/1132 = - Remove BLOCKING flag and Depends (by martinthomson) https://github.com/quicwg/base-drafts/issues/1125 [-qcram] [design] = - Base in header table updates (by martinthomson) https://github.com/quicwg/base-drafts/issues/1124 [-qcram] [design] = - Framing QCRAM payloads (by martinthomson) https://github.com/quicwg/base-drafts/issues/1122 [-http] [-qcram] = - RST_STREAM vs PROTOCOL_ERROR (by mikkelfj) https://github.com/quicwg/base-drafts/issues/1119 = 10 issues received 31 new comments: - #1128 Duplication can use different indexing (8 by martinthomson, LPard= ue, afrind, mikkelfj) https://github.com/quicwg/base-drafts/issues/1128 [-qcram] [design] = - #1121 Separate QCRAM streams (7 by martinthomson, LPardue, afrind, Mike= Bishop) https://github.com/quicwg/base-drafts/issues/1121 [-http] [-qcram] [des= ign] = - #1125 Remove BLOCKING flag and Depends (6 by martinthomson, afrind, Mik= eBishop) https://github.com/quicwg/base-drafts/issues/1125 [-qcram] [design] = - #1118 text on retry and connection id (3 by martinthomson, mcmanus) https://github.com/quicwg/base-drafts/issues/1118 = - #1127 The 32 octet overhead (2 by martinthomson, afrind) https://github.com/quicwg/base-drafts/issues/1127 [-qcram] [design] = - #1124 Base in header table updates (1 by afrind) https://github.com/quicwg/base-drafts/issues/1124 [-qcram] [design] = - #1095 Clarify how frames are retransmitted (1 by mikkelfj) https://github.com/quicwg/base-drafts/issues/1095 = - #1105 Segmented Packet Numbers (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1105 = - #910 Applications and Stream IDs (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/910 [-http] [-transport] [= design] = - #1092 Gapless Optimitisk ACK Attack Mitigation (1 by martinthomson) https://github.com/quicwg/base-drafts/issues/1092 = 4 issues closed: - Gapless Optimitisk ACK Attack Mitigation https://github.com/quicwg/base= -drafts/issues/1092 = - Segmented Packet Numbers https://github.com/quicwg/base-drafts/issues/1= 105 = - HPACK relies on in-order delivery https://github.com/quicwg/base-drafts= /issues/228 [-http] [design] = - Clarify how frames are retransmitted https://github.com/quicwg/base-dra= fts/issues/1095 = Pull requests ------------- * quicwg/base-drafts (+6/-9/=F0=9F=92=AC9) 6 pull requests submitted: - Generating Acknowledgements (by ianswett) https://github.com/quicwg/base-drafts/pull/1139 = - add an error code for rejecting new connections (by marten-seemann) https://github.com/quicwg/base-drafts/pull/1137 = - Tls error (by huitema) https://github.com/quicwg/base-drafts/pull/1135 = - qcram: remove authors from acknowledgements (by afrind) https://github.com/quicwg/base-drafts/pull/1134 = - qcram: move acks to appendix and make it unnumbered (by reschke) https://github.com/quicwg/base-drafts/pull/1131 = - use the 0x8 short header bit for demultiplexing gQUIC (by marten-seeman= n) https://github.com/quicwg/base-drafts/pull/1120 = 7 pull requests received 9 new comments: - #1120 use the 0x8 short header bit for demultiplexing gQUIC (2 by marti= nthomson, csperkins) https://github.com/quicwg/base-drafts/pull/1120 = - #1135 Tls error (2 by martinthomson, huitema) https://github.com/quicwg/base-drafts/pull/1135 = - #1134 qcram: remove authors from acknowledgements (1 by martinthomson) https://github.com/quicwg/base-drafts/pull/1134 = - #1111 qcram: consistent formatting of range (1 by afrind) https://github.com/quicwg/base-drafts/pull/1111 = - #1114 Simplify QCRAM abstract (1 by LPardue) https://github.com/quicwg/base-drafts/pull/1114 = - #1117 Integrate QCRAM (1 by afrind) https://github.com/quicwg/base-drafts/pull/1117 [-http] = - #1109 Invariants (1 by mnot) https://github.com/quicwg/base-drafts/pull/1109 = 9 pull requests merged: - qcram: remove authors from acknowledgements https://github.com/quicwg/base-drafts/pull/1134 = - Tls error https://github.com/quicwg/base-drafts/pull/1135 = - qcram: consistent formatting of range https://github.com/quicwg/base-drafts/pull/1111 = - qcram: section reference format https://github.com/quicwg/base-drafts/pull/1112 = - qcram: move acks to appendix and make it unnumbered https://github.com/quicwg/base-drafts/pull/1131 = - Simplify QCRAM abstract https://github.com/quicwg/base-drafts/pull/1114 = - qcram: make boilerplate consistent https://github.com/quicwg/base-drafts/pull/1110 = - Integrate QCRAM https://github.com/quicwg/base-drafts/pull/1117 [-http] = - Invariants https://github.com/quicwg/base-drafts/pull/1109 = Repositories tracked by this digest: ----------------------------------- * https://github.com/quicwg/base-drafts --===============1639984626942533518== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (QUIC Working Group Specifications)

Sunday February 25, 2018

Events without label "editorial"

Issues

quicwg/base-drafts (+7/-4/=F0=9F=92=AC31)

7 issues created:

10 issues received 31 new comments:

4 issues closed:

Pull requests

quicwg/base-drafts (+6/-9/=F0=9F=92=AC9)

6 pull requests submitted:

7 pull requests received 9 new comments:

9 pull requests merged:

Repositories tracked by this digest:

--===============1639984626942533518==-- From nobody Sun Feb 25 06:26:07 2018 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 24113126C25 for ; Sun, 25 Feb 2018 06:26:06 -0800 (PST) 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, 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=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 aJowZdGFVdKf for ; Sun, 25 Feb 2018 06:26:04 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 5D4AD120227 for ; Sun, 25 Feb 2018 06:26:04 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id n48so8881104uae.13 for ; Sun, 25 Feb 2018 06:26:04 -0800 (PST) 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=cF9cvKcwb3BYncLcqPm3fTQNh0/PR9fsPNmEHIi/mCc=; b=Z//jmTk22AdRh7Wse7SFBgvrj2ue7+I3JFppo/EBUfSDukzfE6YJnUY7Q4hW5aAT3w 2bi7tS3IH4z5bpLX12Wy49V3MLsI40as1/BffCW29/3hXNMFsaIo6wYrGzKXQRFPNCM0 UoyYvaZ6lVbXHVzNmzadNkDaHCKn2qLcSqyZyCYNlv9RH43E+ZiH1UxCVYzUNqIrj3jG v/1j/+J/ZloNdmug8X03xkI4g+N5ThHR0PUfRwX1vxvy74Iyjw4awUgK3YCR8U9TPK06 +iozba4lz2InzkojcRFZjpgzEs/SgImD+nq+o8MCVxWAuLY2j9CjfK5ll8id6fNRFakN M1iQ== 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=cF9cvKcwb3BYncLcqPm3fTQNh0/PR9fsPNmEHIi/mCc=; b=ovQHH+mctu0jBTMfbjwATWY1JE0a9nV6bOE08SHb0F9/7y4AG0hpT9RYrIMiEAND7G 28bj4aJhr0wTJXFcDvbtDDD0keJGe/9M/5LA/+JswJ56fkt5khaxtKFUGtQycHkpkVsK lumwqzr6Z6xVeQWuSmpJh+S2RGUKbCL8SBgGN8VeVdIdziRoqHwwlHEw2LRpwsC23edn FBRet7GGYY9ijc2Pg2GRZlYQ7nUs2WVvzGe+TRYfoaT9kY18FaRFLEDNVgiFDBiNoP9G 16vu97rY9fYNWUECG2UWDhiwzQ1YhXXSfwkTEvuayAbxeLRyhkNBCsWZO6cY5eyPzkFA nnCg== X-Gm-Message-State: APf1xPCh0enolV3PLrnpXSKjG1t/w6VgnIKz5495W9EJ5S6zF/5fneUZ RD6XrRuUlQh9d6Nt+MXZEFYq+VM3p9kYmYpOnHLV8A== X-Google-Smtp-Source: AG47ELubiQ/8pB83azarjAnXi9+E6gjkMADzt15kqELKragKDvbSvdeoEmWuePJS6qV0A5cyWG1NmIgRYzyC23ChcJ0= X-Received: by 10.176.23.238 with SMTP id p46mr6010793uaf.134.1519568762799; Sun, 25 Feb 2018 06:26:02 -0800 (PST) MIME-Version: 1.0 From: Marten Seemann Date: Sun, 25 Feb 2018 14:25:52 +0000 Message-ID: Subject: Unrecoverable loss pattern To: QUIC WG Content-Type: multipart/alternative; boundary="f403043c6cb8518c2b05660a2c42" 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, 25 Feb 2018 14:26:06 -0000 --f403043c6cb8518c2b05660a2c42 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99ve been playing around with QUIC loss recovery and in my tests I= =E2=80=99m encountering one specific loss pattern which it seems impossible to recover from. It's pretty rare, because there are a couple of conditions that must be fulfilled for it to occur: 1. Client and server perform the handshake, no packets are lost so far. Client and server both arrive at the CONNECTED state, and the server receives all ACKs for handshake packets it sent. The client receives ACKs for all handshake packets except for the one containing the FINISHED message is lost (the packet containing the ACK for the FINISHED is lost). 2. The client starts using 1-RTT keys, and it sends two packets: First, a packet only containing an ACK, and then a packet containing stream data (e.g. a request). The request packet is then lost. 3. The server receives the ACK in the 1-RTT packet, and it stops accepting unencrypted packets according to 6.1.2 of the TLS draft. It doesn=E2=80=99t generate an ACK in response, since the packet only contained an ACK. 4. The client is now missing acknowledgements for two packets: the (unencrypted) packet containing the FINISHED message, and the (1-RTT) packet containing the request. It runs its loss recovery algorithm ( *OnLossDetectionAlarm*), and since there is one outstanding handshake packet, it retransmit all outstanding handshake packets. Now we=E2=80=99ve run into a situation we can=E2=80=99t recover from: The s= erver won=E2=80=99t even open packet sent as a retransmission (since these packets are unencrypted, and arrive after it already received a 1-RTT packet), and the client will never retransmit the request packet. Furthermore, the server won't send any other packets, since it's just waiting for a request from the client. I think the solution for this is to also retransmit 1-RTT packets in a case like this. Can we just apply the normal retransmission rules in *OnLossDetectionAlarm*, even if there are still handshake packets outstanding? --f403043c6cb8518c2b05660a2c42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I=E2=80=99ve been playing around with QUIC loss recov= ery and in my tests I=E2=80=99m encountering one specific loss pattern whic= h it seems impossible to recover from. It's pretty rare, because there = are a couple of conditions that must be fulfilled for it to occur:

1. Client and server perform the handshake, no packets are= lost so far. Client and server both arrive at the CONNECTED state, and the= server receives all ACKs for handshake packets it sent. The client receive= s ACKs for all handshake packets except for the one containing the FINISHED= message is lost (the packet containing the ACK for the FINISHED is lost).<= /div>
2. The client starts using 1-RTT keys, and it sends two packets: = First, a packet only containing an ACK, and then a packet containing stream= data (e.g. a request). The request packet is then lost.
3. The s= erver receives the ACK in the 1-RTT packet, and it stops accepting unencryp= ted packets according to 6.1.2 of the TLS draft. It doesn=E2=80=99t generat= e an ACK in response, since the packet only contained an ACK.
4. = The client is now missing acknowledgements for two packets: the (unencrypte= d) packet containing the FINISHED message, and the (1-RTT) packet containin= g the request. It runs its loss recovery algorithm (OnLossDetectionAlarm= ), and since there is one outstanding handshake packet, it retransmit a= ll outstanding handshake packets.

Now we=E2=80=99v= e run into a situation we can=E2=80=99t recover from: The server won=E2=80= =99t even open packet sent as a retransmission (since these packets are une= ncrypted, and arrive after it already received a 1-RTT packet), and the cli= ent will never retransmit the request packet. Furthermore, the server won&#= 39;t send any other packets, since it's just waiting for a request from= the client.

I think the solution for this is to a= lso retransmit 1-RTT packets in a case like this. Can we just apply the nor= mal retransmission rules in=C2=A0OnLossDetectionAlarm, even if there= are still handshake packets outstanding?


--f403043c6cb8518c2b05660a2c42-- From nobody Sun Feb 25 08:52:06 2018 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 F0A24126CF9 for ; Sun, 25 Feb 2018 08:52:05 -0800 (PST) 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, RCVD_IN_MSPIKE_H2=-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 h7vQ1qgvieXg for ; Sun, 25 Feb 2018 08:52:04 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5BE1201FA for ; Sun, 25 Feb 2018 08:52:03 -0800 (PST) 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=lMDh2McJtPl9Gk060gyyuKe9BZ1MQswrbxPh8BowHc4=; b=Eh+JPgt4/Qp4SUYAuIPoEPQVrzRDXN7UVrOrSCPynkX/XHzWzKA9ROKdxrQBSfGv9ODgi6Jgp4B77YBfQ41CoE17TNdAJjJnWwRE7r/dBLlJ9W2g6sm1TKAKKHBdZVyVpuJWeG+Ym3eNS3GFovZtaFcvxEeR08/kOO2k9zZ12KQ= Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0787.namprd21.prod.outlook.com (10.175.132.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.2; Sun, 25 Feb 2018 16:52:02 +0000 Received: from BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) by BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) with mapi id 15.20.0567.002; Sun, 25 Feb 2018 16:52:02 +0000 From: Nick Banks To: Marten Seemann , QUIC WG Subject: RE: Unrecoverable loss pattern Thread-Topic: Unrecoverable loss pattern Thread-Index: AQHTrkSWFslkSBt3zkyfQlKulmkzQqO1VDuw Date: Sun, 25 Feb 2018 16:52:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-02-25T16:51:59.9820395Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:b::7ae] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0787; 7:0pOK0qkJ5LWZra9EsmalKNq0BEoLkuNZEG8Y22Dro4XSJX/21VbfEYbSeBH/mJLd8gglDHmJzG6vTLTkJ+HlCve/yt5TwQvdDRx9/voIwwtVQCMqBrjLA+c9CcukOEdwlctm0YYSJaaT7nNiRmNBNEy/hxWqgmg/JK7lxEhGnA4Oh0jBcqMDRhULivS6Hn/zf+Xp+gW35Qwx/eUzavf0wGDAI+7SeVqr5kcPLQhV1oEjT/cAnylTN7Am8b/FmO/Y x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 6ef0e3ca-fda5-4b5d-47ab-08d57c7017db x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:BN6PR21MB0787; x-ms-traffictypediagnostic: BN6PR21MB0787: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(8121501046)(5005006)(3231220)(944501187)(52105095)(10201501046)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:BN6PR21MB0787; BCL:0; PCL:0; RULEID:; SRVR:BN6PR21MB0787; x-forefront-prvs: 05947791E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(366004)(376002)(39380400002)(396003)(39860400002)(199004)(189003)(7116003)(14454004)(5660300001)(186003)(39060400002)(8676002)(2950100002)(86362001)(86612001)(102836004)(6436002)(55016002)(106356001)(110136005)(6246003)(53936002)(6306002)(54896002)(10290500003)(77096007)(478600001)(59450400001)(7736002)(9686003)(74316002)(53546011)(6506007)(8990500004)(105586002)(6116002)(790700001)(6346003)(10090500001)(68736007)(2906002)(99286004)(97736004)(316002)(7696005)(229853002)(76176011)(81166006)(3660700001)(22452003)(81156014)(2900100001)(3280700002)(3480700004)(33656002)(25786009)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0787; H:BN6PR21MB0178.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-message-info: YQO9lR566T37a+6vgPqFDKKSfw1dlIfHj7z5wYbO8eeObqOFZvsVdTc5xx7uLP4iwqSKBtduuN25wl5A1Kk19a17UnH/lshAbJnxD+Qm+25Q+ePvPEzfunvBRcdNtOUY+4M+Wta6+SQAVxAR2GubUkCM7PzW7ZhkLI7411FywXM= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB0178F0351B568A8EBCED2979B3C20BN6PR21MB0178namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6ef0e3ca-fda5-4b5d-47ab-08d57c7017db X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2018 16:52:02.0752 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0787 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, 25 Feb 2018 16:52:06 -0000 --_000_BN6PR21MB0178F0351B568A8EBCED2979B3C20BN6PR21MB0178namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyaGFwcyA2LjEuMiBzaG91bGQgYmUgY2hhbmdlZCBqdXN0IHRvIHNheSB0aGUgc2VydmVyIG11 c3QgY29udGludWUgdG8gcHJvY2VzcyB1bnByb3RlY3RlZCBwYWNrZXRzIHVudGlsIGFsbCB0aGUg aGFuZHNoYWtlIHBhY2tldHMgYXJlIHJlY2VpdmVkLCBhbmQgcmVtb3ZlIHRoZSBwYXJ0IGFib3V0 IHJlY2VpdmluZyBhbiBBQ0sgdGhhdCBhY2tub3dsZWRnZXMgaXRzIGhhbmRzaGFrZSBtZXNzYWdl cz8NCg0KLSBOaWNrDQoNCkZyb206IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIE1hcnRlbiBTZWVtYW5uDQpTZW50OiBTdW5kYXksIEZlYnJ1YXJ5IDI1LCAyMDE4IDY6 MjYgQU0NClRvOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogVW5yZWNvdmVyYWJs ZSBsb3NzIHBhdHRlcm4NCg0KSeKAmXZlIGJlZW4gcGxheWluZyBhcm91bmQgd2l0aCBRVUlDIGxv c3MgcmVjb3ZlcnkgYW5kIGluIG15IHRlc3RzIEnigJltIGVuY291bnRlcmluZyBvbmUgc3BlY2lm aWMgbG9zcyBwYXR0ZXJuIHdoaWNoIGl0IHNlZW1zIGltcG9zc2libGUgdG8gcmVjb3ZlciBmcm9t LiBJdCdzIHByZXR0eSByYXJlLCBiZWNhdXNlIHRoZXJlIGFyZSBhIGNvdXBsZSBvZiBjb25kaXRp b25zIHRoYXQgbXVzdCBiZSBmdWxmaWxsZWQgZm9yIGl0IHRvIG9jY3VyOg0KDQoxLiBDbGllbnQg YW5kIHNlcnZlciBwZXJmb3JtIHRoZSBoYW5kc2hha2UsIG5vIHBhY2tldHMgYXJlIGxvc3Qgc28g ZmFyLiBDbGllbnQgYW5kIHNlcnZlciBib3RoIGFycml2ZSBhdCB0aGUgQ09OTkVDVEVEIHN0YXRl LCBhbmQgdGhlIHNlcnZlciByZWNlaXZlcyBhbGwgQUNLcyBmb3IgaGFuZHNoYWtlIHBhY2tldHMg aXQgc2VudC4gVGhlIGNsaWVudCByZWNlaXZlcyBBQ0tzIGZvciBhbGwgaGFuZHNoYWtlIHBhY2tl dHMgZXhjZXB0IGZvciB0aGUgb25lIGNvbnRhaW5pbmcgdGhlIEZJTklTSEVEIG1lc3NhZ2UgaXMg bG9zdCAodGhlIHBhY2tldCBjb250YWluaW5nIHRoZSBBQ0sgZm9yIHRoZSBGSU5JU0hFRCBpcyBs b3N0KS4NCjIuIFRoZSBjbGllbnQgc3RhcnRzIHVzaW5nIDEtUlRUIGtleXMsIGFuZCBpdCBzZW5k cyB0d28gcGFja2V0czogRmlyc3QsIGEgcGFja2V0IG9ubHkgY29udGFpbmluZyBhbiBBQ0ssIGFu ZCB0aGVuIGEgcGFja2V0IGNvbnRhaW5pbmcgc3RyZWFtIGRhdGEgKGUuZy4gYSByZXF1ZXN0KS4g VGhlIHJlcXVlc3QgcGFja2V0IGlzIHRoZW4gbG9zdC4NCjMuIFRoZSBzZXJ2ZXIgcmVjZWl2ZXMg dGhlIEFDSyBpbiB0aGUgMS1SVFQgcGFja2V0LCBhbmQgaXQgc3RvcHMgYWNjZXB0aW5nIHVuZW5j cnlwdGVkIHBhY2tldHMgYWNjb3JkaW5nIHRvIDYuMS4yIG9mIHRoZSBUTFMgZHJhZnQuIEl0IGRv ZXNu4oCZdCBnZW5lcmF0ZSBhbiBBQ0sgaW4gcmVzcG9uc2UsIHNpbmNlIHRoZSBwYWNrZXQgb25s eSBjb250YWluZWQgYW4gQUNLLg0KNC4gVGhlIGNsaWVudCBpcyBub3cgbWlzc2luZyBhY2tub3ds ZWRnZW1lbnRzIGZvciB0d28gcGFja2V0czogdGhlICh1bmVuY3J5cHRlZCkgcGFja2V0IGNvbnRh aW5pbmcgdGhlIEZJTklTSEVEIG1lc3NhZ2UsIGFuZCB0aGUgKDEtUlRUKSBwYWNrZXQgY29udGFp bmluZyB0aGUgcmVxdWVzdC4gSXQgcnVucyBpdHMgbG9zcyByZWNvdmVyeSBhbGdvcml0aG0gKE9u TG9zc0RldGVjdGlvbkFsYXJtKSwgYW5kIHNpbmNlIHRoZXJlIGlzIG9uZSBvdXRzdGFuZGluZyBo YW5kc2hha2UgcGFja2V0LCBpdCByZXRyYW5zbWl0IGFsbCBvdXRzdGFuZGluZyBoYW5kc2hha2Ug cGFja2V0cy4NCg0KTm93IHdl4oCZdmUgcnVuIGludG8gYSBzaXR1YXRpb24gd2UgY2Fu4oCZdCBy ZWNvdmVyIGZyb206IFRoZSBzZXJ2ZXIgd29u4oCZdCBldmVuIG9wZW4gcGFja2V0IHNlbnQgYXMg YSByZXRyYW5zbWlzc2lvbiAoc2luY2UgdGhlc2UgcGFja2V0cyBhcmUgdW5lbmNyeXB0ZWQsIGFu ZCBhcnJpdmUgYWZ0ZXIgaXQgYWxyZWFkeSByZWNlaXZlZCBhIDEtUlRUIHBhY2tldCksIGFuZCB0 aGUgY2xpZW50IHdpbGwgbmV2ZXIgcmV0cmFuc21pdCB0aGUgcmVxdWVzdCBwYWNrZXQuIEZ1cnRo ZXJtb3JlLCB0aGUgc2VydmVyIHdvbid0IHNlbmQgYW55IG90aGVyIHBhY2tldHMsIHNpbmNlIGl0 J3MganVzdCB3YWl0aW5nIGZvciBhIHJlcXVlc3QgZnJvbSB0aGUgY2xpZW50Lg0KDQpJIHRoaW5r IHRoZSBzb2x1dGlvbiBmb3IgdGhpcyBpcyB0byBhbHNvIHJldHJhbnNtaXQgMS1SVFQgcGFja2V0 cyBpbiBhIGNhc2UgbGlrZSB0aGlzLiBDYW4gd2UganVzdCBhcHBseSB0aGUgbm9ybWFsIHJldHJh bnNtaXNzaW9uIHJ1bGVzIGluIE9uTG9zc0RldGVjdGlvbkFsYXJtLCBldmVuIGlmIHRoZXJlIGFy ZSBzdGlsbCBoYW5kc2hha2UgcGFja2V0cyBvdXRzdGFuZGluZz8NCg0K --_000_BN6PR21MB0178F0351B568A8EBCED2979B3C20BN6PR21MB0178namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlBlcmhhcHMgNi4xLjIgc2hvdWxkIGJlIGNoYW5nZWQganVzdCB0byBzYXkgdGhlIHNl cnZlciBtdXN0IGNvbnRpbnVlIHRvIHByb2Nlc3MgdW5wcm90ZWN0ZWQgcGFja2V0cyB1bnRpbCBh bGwgdGhlIGhhbmRzaGFrZSBwYWNrZXRzIGFyZSByZWNlaXZlZCwgYW5kIHJlbW92ZSB0aGUgcGFy dCBhYm91dCByZWNlaXZpbmcgYW4gQUNLIHRoYXQgYWNrbm93bGVkZ2VzIGl0cyBoYW5kc2hha2Ug bWVzc2FnZXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gTmljazxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyA8 Yj5PbiBCZWhhbGYgT2YgPC9iPg0KTWFydGVuIFNlZW1hbm48YnI+DQo8Yj5TZW50OjwvYj4gU3Vu ZGF5LCBGZWJydWFyeSAyNSwgMjAxOCA2OjI2IEFNPGJyPg0KPGI+VG86PC9iPiBRVUlDIFdHICZs dDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBVbnJlY292ZXJhYmxlIGxv c3MgcGF0dGVybjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPknigJl2ZSBi ZWVuIHBsYXlpbmcgYXJvdW5kIHdpdGggUVVJQyBsb3NzIHJlY292ZXJ5IGFuZCBpbiBteSB0ZXN0 cyBJ4oCZbSBlbmNvdW50ZXJpbmcgb25lIHNwZWNpZmljIGxvc3MgcGF0dGVybiB3aGljaCBpdCBz ZWVtcyBpbXBvc3NpYmxlIHRvIHJlY292ZXIgZnJvbS4gSXQncyBwcmV0dHkgcmFyZSwgYmVjYXVz ZSB0aGVyZSBhcmUgYSBjb3VwbGUgb2YgY29uZGl0aW9ucyB0aGF0IG11c3QgYmUgZnVsZmlsbGVk IGZvcg0KIGl0IHRvIG9jY3VyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4xLiBDbGllbnQgYW5kIHNlcnZlciBwZXJmb3JtIHRoZSBoYW5kc2hh a2UsIG5vIHBhY2tldHMgYXJlIGxvc3Qgc28gZmFyLiBDbGllbnQgYW5kIHNlcnZlciBib3RoIGFy cml2ZSBhdCB0aGUgQ09OTkVDVEVEIHN0YXRlLCBhbmQgdGhlIHNlcnZlciByZWNlaXZlcyBhbGwg QUNLcyBmb3IgaGFuZHNoYWtlIHBhY2tldHMgaXQgc2VudC4gVGhlIGNsaWVudCByZWNlaXZlcyBB Q0tzIGZvciBhbGwgaGFuZHNoYWtlIHBhY2tldHMNCiBleGNlcHQgZm9yIHRoZSBvbmUgY29udGFp bmluZyB0aGUgRklOSVNIRUQgbWVzc2FnZSBpcyBsb3N0ICh0aGUgcGFja2V0IGNvbnRhaW5pbmcg dGhlIEFDSyBmb3IgdGhlIEZJTklTSEVEIGlzIGxvc3QpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gVGhlIGNsaWVudCBzdGFydHMgdXNpbmcg MS1SVFQga2V5cywgYW5kIGl0IHNlbmRzIHR3byBwYWNrZXRzOiBGaXJzdCwgYSBwYWNrZXQgb25s eSBjb250YWluaW5nIGFuIEFDSywgYW5kIHRoZW4gYSBwYWNrZXQgY29udGFpbmluZyBzdHJlYW0g ZGF0YSAoZS5nLiBhIHJlcXVlc3QpLiBUaGUgcmVxdWVzdCBwYWNrZXQgaXMgdGhlbiBsb3N0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+My4gVGhl IHNlcnZlciByZWNlaXZlcyB0aGUgQUNLIGluIHRoZSAxLVJUVCBwYWNrZXQsIGFuZCBpdCBzdG9w cyBhY2NlcHRpbmcgdW5lbmNyeXB0ZWQgcGFja2V0cyBhY2NvcmRpbmcgdG8gNi4xLjIgb2YgdGhl IFRMUyBkcmFmdC4gSXQgZG9lc27igJl0IGdlbmVyYXRlIGFuIEFDSyBpbiByZXNwb25zZSwgc2lu Y2UgdGhlIHBhY2tldCBvbmx5IGNvbnRhaW5lZCBhbiBBQ0suPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40LiBUaGUgY2xpZW50IGlzIG5vdyBtaXNz aW5nIGFja25vd2xlZGdlbWVudHMgZm9yIHR3byBwYWNrZXRzOiB0aGUgKHVuZW5jcnlwdGVkKSBw YWNrZXQgY29udGFpbmluZyB0aGUgRklOSVNIRUQgbWVzc2FnZSwgYW5kIHRoZSAoMS1SVFQpIHBh Y2tldCBjb250YWluaW5nIHRoZSByZXF1ZXN0LiBJdCBydW5zIGl0cyBsb3NzIHJlY292ZXJ5IGFs Z29yaXRobSAoPGk+T25Mb3NzRGV0ZWN0aW9uQWxhcm08L2k+KSwgYW5kDQogc2luY2UgdGhlcmUg aXMgb25lIG91dHN0YW5kaW5nIGhhbmRzaGFrZSBwYWNrZXQsIGl0IHJldHJhbnNtaXQgYWxsIG91 dHN0YW5kaW5nIGhhbmRzaGFrZSBwYWNrZXRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3cgd2XigJl2ZSBydW4gaW50byBhIHNpdHVhdGlv biB3ZSBjYW7igJl0IHJlY292ZXIgZnJvbTogVGhlIHNlcnZlciB3b27igJl0IGV2ZW4gb3BlbiBw YWNrZXQgc2VudCBhcyBhIHJldHJhbnNtaXNzaW9uIChzaW5jZSB0aGVzZSBwYWNrZXRzIGFyZSB1 bmVuY3J5cHRlZCwgYW5kIGFycml2ZSBhZnRlciBpdCBhbHJlYWR5IHJlY2VpdmVkIGEgMS1SVFQg cGFja2V0KSwgYW5kIHRoZSBjbGllbnQgd2lsbCBuZXZlciByZXRyYW5zbWl0DQogdGhlIHJlcXVl c3QgcGFja2V0LiBGdXJ0aGVybW9yZSwgdGhlIHNlcnZlciB3b24ndCBzZW5kIGFueSBvdGhlciBw YWNrZXRzLCBzaW5jZSBpdCdzIGp1c3Qgd2FpdGluZyBmb3IgYSByZXF1ZXN0IGZyb20gdGhlIGNs aWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSB0aGluayB0aGUgc29sdXRpb24gZm9yIHRoaXMgaXMgdG8gYWxzbyByZXRyYW5zbWl0IDEt UlRUIHBhY2tldHMgaW4gYSBjYXNlIGxpa2UgdGhpcy4gQ2FuIHdlIGp1c3QgYXBwbHkgdGhlIG5v cm1hbCByZXRyYW5zbWlzc2lvbiBydWxlcyBpbiZuYnNwOzxpPk9uTG9zc0RldGVjdGlvbkFsYXJt PC9pPiwgZXZlbiBpZiB0aGVyZSBhcmUgc3RpbGwgaGFuZHNoYWtlIHBhY2tldHMgb3V0c3RhbmRp bmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR21MB0178F0351B568A8EBCED2979B3C20BN6PR21MB0178namp_-- From nobody Sun Feb 25 09:02:19 2018 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 6C773126CF9 for ; Sun, 25 Feb 2018 09:02:17 -0800 (PST) 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, 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=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 KnXMPtDjZBYY for ; Sun, 25 Feb 2018 09:02:15 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 49E6E120726 for ; Sun, 25 Feb 2018 09:02:15 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id m43so9040541uah.1 for ; Sun, 25 Feb 2018 09:02:15 -0800 (PST) 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=ZbTv0YU/8FTQEjx5BjPPOHq03JeACv/EkE9y81uL5uI=; b=VOQxaQ34/URTpq4sq0xFH+leF0ESiiQ6ratsFPc45wMG/VlsWkK6nnedFtEB/iVZ0W RxufRclCmKYtCAQEbdM9xoCqeBP+SPYRK+JvbD0/zu/dY25RJ+dq6N9iry/p4KB40r/A oH2Mcyn6Feo7ssPeMPay+Hb3Qxm+w7TLWRcAAPp9g4SZ8PzahJf1TVzYXSzp32Tnni1i ea/Zfmr6mNNB2RIRs2Shbg2VdCo1ZjM4C7mZInksdJBsF2B8K9GFz1Z/9Qw+RrYHJra2 tlZspySkeSDXZBvVgXLyw3ufsSlAIYekceCE1AGu5lSjryyp5Zu/YQvzE72mWIi0Q+xt fPdw== 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=ZbTv0YU/8FTQEjx5BjPPOHq03JeACv/EkE9y81uL5uI=; b=tkHHtRPqkIVN4K+Y2SGtB3KkP4+rJed5xZMMnyMn1BBwSKUUKHAfotl+WltNqqMt/1 XEpb1RI/L2zJf3bYvnCnITxJPz5dFxxzkDht8My9qqqev5aoLf1YxcqQoshNqsy7pVzz oBVj3D6QMwVEp0TA+kondfj8xxESRXog1BMKlbgLtn0OqT59CB7NGZC8jTV8tvFyYZVf 9p93f50FfV1IxhiuC/Sf9NooJ+BETZvGmu0fIkGliqZArHavs4eoYKRudRcbV+0Y0UIg soBV/3mvtHEW7PAYRirlur0dqXgJp7E003vLfcsf6wrLqR4CbVzxbYi8vC/kKza2z4V1 HzXA== X-Gm-Message-State: APf1xPCSo4qy7kb0D2/Hr2J5oqNu39poZveJOXfZORVr+Uk7y8X5RaZz mcuZvqk5BIYEhU+RK/cLdxneEoVCf8QVnlsC+Sc= X-Google-Smtp-Source: AG47ELvYla+Bpbal9seK/d0Uw178TEqsVZafnTU3qkYf+C69jlej/mwNuAbYkNwOctYikQJ/onpZ5AuA4Wp7yDkNIhA= X-Received: by 10.159.47.12 with SMTP id x12mr2992854uaj.114.1519578133835; Sun, 25 Feb 2018 09:02:13 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marten Seemann Date: Sun, 25 Feb 2018 17:02:03 +0000 Message-ID: Subject: Re: Unrecoverable loss pattern To: Nick Banks Cc: QUIC WG Content-Type: multipart/alternative; boundary="089e082508e0e0371005660c5ac1" 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, 25 Feb 2018 17:02:17 -0000 --089e082508e0e0371005660c5ac1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don=E2=80=99t think this will fix the problem. All handshake packets (sen= t by the server) were received by the client and acknowledged (in the first 1-RTT packet sent by the client). On Mon 26. Feb 2018 at 00:52, Nick Banks wrote: > Perhaps 6.1.2 should be changed just to say the server must continue to > process unprotected packets until all the handshake packets are received, > and remove the part about receiving an ACK that acknowledges its handshak= e > messages? > > > > - Nick > > > > *From:* QUIC *On Behalf Of * Marten Seemann > *Sent:* Sunday, February 25, 2018 6:26 AM > *To:* QUIC WG > *Subject:* Unrecoverable loss pattern > > > > I=E2=80=99ve been playing around with QUIC loss recovery and in my tests = I=E2=80=99m > encountering one specific loss pattern which it seems impossible to recov= er > from. It's pretty rare, because there are a couple of conditions that mus= t > be fulfilled for it to occur: > > > > 1. Client and server perform the handshake, no packets are lost so far. > Client and server both arrive at the CONNECTED state, and the server > receives all ACKs for handshake packets it sent. The client receives ACKs > for all handshake packets except for the one containing the FINISHED > message is lost (the packet containing the ACK for the FINISHED is lost). > > 2. The client starts using 1-RTT keys, and it sends two packets: First, a > packet only containing an ACK, and then a packet containing stream data > (e.g. a request). The request packet is then lost. > > 3. The server receives the ACK in the 1-RTT packet, and it stops acceptin= g > unencrypted packets according to 6.1.2 of the TLS draft. It doesn=E2=80= =99t > generate an ACK in response, since the packet only contained an ACK. > > 4. The client is now missing acknowledgements for two packets: the > (unencrypted) packet containing the FINISHED message, and the (1-RTT) > packet containing the request. It runs its loss recovery algorithm ( > *OnLossDetectionAlarm*), and since there is one outstanding handshake > packet, it retransmit all outstanding handshake packets. > > > > Now we=E2=80=99ve run into a situation we can=E2=80=99t recover from: The= server won=E2=80=99t > even open packet sent as a retransmission (since these packets are > unencrypted, and arrive after it already received a 1-RTT packet), and th= e > client will never retransmit the request packet. Furthermore, the server > won't send any other packets, since it's just waiting for a request from > the client. > > > > I think the solution for this is to also retransmit 1-RTT packets in a > case like this. Can we just apply the normal retransmission rules in > *OnLossDetectionAlarm*, even if there are still handshake packets > outstanding? > > > --089e082508e0e0371005660c5ac1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don=E2=80=99t think this will fix the problem. All hands= hake packets (sent by the server) were received by the client and acknowled= ged (in the first 1-RTT packet sent by the client).

On Mon 26. Feb 2018 at 00:52, Nick Banks <nibanks@microsoft.com> wrote:

Perhaps 6.1.2 should be changed just to say the serv= er must continue to process unprotected packets until all the handshake pac= kets are received, and remove the part about receiving an ACK that acknowle= dges its handshake messages?

=C2=A0

- Nick

=C2=A0

From: QUIC <quic-bounces@ietf.org> On Behalf Of = Marten Seemann
Sent: Sunday, February 25, 2018 6:26 AM
To: QUIC WG <q= uic@ietf.org>
Subject: Unrecoverable loss pattern

=C2=A0

I=E2=80=99ve been playing around with QUIC loss reco= very and in my tests I=E2=80=99m encountering one specific loss pattern whi= ch it seems impossible to recover from. It's pretty rare, because there= are a couple of conditions that must be fulfilled for it to occur:

=C2=A0

1. Client and server perform the handshake, no packe= ts are lost so far. Client and server both arrive at the CONNECTED state, a= nd the server receives all ACKs for handshake packets it sent. The client r= eceives ACKs for all handshake packets except for the one containing the FINISHED message is lost (the packet con= taining the ACK for the FINISHED is lost).

2. The client starts using 1-RTT keys, and it sends = two packets: First, a packet only containing an ACK, and then a packet cont= aining stream data (e.g. a request). The request packet is then lost.

3. The server receives the ACK in the 1-RTT packet, = and it stops accepting unencrypted packets according to 6.1.2 of the TLS dr= aft. It doesn=E2=80=99t generate an ACK in response, since the packet only = contained an ACK.

4. The client is now missing acknowledgements for tw= o packets: the (unencrypted) packet containing the FINISHED message, and th= e (1-RTT) packet containing the request. It runs its loss recovery algorith= m (OnLossDetectionAlarm), and since there is one outstanding handshake packet, it retransmit all outstan= ding handshake packets.

=C2=A0

Now we=E2=80=99ve run into a situation we can=E2=80= =99t recover from: The server won=E2=80=99t even open packet sent as a retr= ansmission (since these packets are unencrypted, and arrive after it alread= y received a 1-RTT packet), and the client will never retransmit the request packet. Furthermore, the server won't send any other packe= ts, since it's just waiting for a request from the client.

=C2=A0

I think the solution for this is to also retransmit = 1-RTT packets in a case like this. Can we just apply the normal retransmiss= ion rules in=C2=A0OnLossDetectionAlarm, even if there are still hand= shake packets outstanding?

=C2=A0<= /p>

--089e082508e0e0371005660c5ac1-- From nobody Sun Feb 25 09:51:50 2018 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 8B3481270AE for ; Sun, 25 Feb 2018 09:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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_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 (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 mldQzA-ApRSQ for ; Sun, 25 Feb 2018 09:51:46 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0093.outbound.protection.outlook.com [104.47.36.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2026A126D05 for ; Sun, 25 Feb 2018 09:51:46 -0800 (PST) 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=FogxcXkF6e85ZRUAKVl4MjUqez4Q9WsU1m/83Jho9SI=; b=FxIqW6Mmt4f/3XT0WwqYOEOCkxcmV6GFQbiLJqgbkbS2eXPrbAh8oS6G6RW6qBmkqNPSanAd4rbZ6R4x2YbhfJmr+Rok+ECEOm8sWhJpMAUtIipvXSQCZJ6owvXSQVS/wHKVHaeKAXhYQ93/M+61fe8UE9W3+Wi1ThIFixrScmY= Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0771.namprd21.prod.outlook.com (10.173.204.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.2; Sun, 25 Feb 2018 17:51:44 +0000 Received: from BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) by BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) with mapi id 15.20.0567.002; Sun, 25 Feb 2018 17:51:44 +0000 From: Nick Banks To: Marten Seemann CC: QUIC WG Subject: RE: Unrecoverable loss pattern Thread-Topic: Unrecoverable loss pattern Thread-Index: AQHTrkSWFslkSBt3zkyfQlKulmkzQqO1VDuwgAAD8oCAAAzPLQ== Date: Sun, 25 Feb 2018 17:51:44 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.56.240.35] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0771; 7:ogOPW2nO4ecZ4MV9S6YLvptNCrqxYbPsvQlR2ArLuy9Ezp0xVYlQGK21U2pdIUM8imW+o0+wLqevrzzaFXZwpit8Ctq7figRHTr70Brq0WLlzVSNaJXC4D7UsghJDUY/xVbtGF4CFSWFIcYfl/r6KZKG48C/AiLRlVZWO1QcGap9Aq3/FlYDoVdqNcytutbQO3b/twaAbAPnTvb3crOpQ7frrH96f/klATCQ5CUvd62FzSZVj6Ybd7bpeu5Nx69d x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8af45be8-7565-4ec2-87bf-08d57c786f48 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:BN6PR21MB0771; x-ms-traffictypediagnostic: BN6PR21MB0771: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(89211679590171)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231220)(944501187)(52105095)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR21MB0771; BCL:0; PCL:0; RULEID:; SRVR:BN6PR21MB0771; x-forefront-prvs: 05947791E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39860400002)(396003)(346002)(39380400002)(199004)(189003)(54896002)(9686003)(33656002)(106356001)(55016002)(6436002)(316002)(6346003)(26005)(14454004)(102836004)(2900100001)(186003)(1411001)(77096007)(7696005)(22452003)(66066001)(236005)(76176011)(478600001)(6246003)(7116003)(6506007)(53546011)(5660300001)(99286004)(59450400001)(8936002)(229853002)(3480700004)(25786009)(86362001)(68736007)(7736002)(81156014)(105586002)(86612001)(10290500003)(8676002)(81166006)(6916009)(74316002)(53936002)(10090500001)(97736004)(2950100002)(8990500004)(3846002)(3280700002)(4326008)(2906002)(3660700001)(39060400002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0771; H:BN6PR21MB0178.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-message-info: HMbF9fiBeZkkol8+Kj8DgExCymRH3NpO8Gt3zz7XFSCeEQdcSGC5hvZqP8rpE0ZKoqjJ9uMs9z+e+jear//A6dC+NGNisFPKNunT/BD/fYqCKfkuHvA1U/biRHLdb9JvLFmsgdhmyqtKRNIqf2Uf9fbrA+pEIxNN4f1A6F46Pu8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR21MB017882F0266B8C6F39475D28B3C20BN6PR21MB0178namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8af45be8-7565-4ec2-87bf-08d57c786f48 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2018 17:51:44.7112 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0771 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, 25 Feb 2018 17:51:48 -0000 --_000_BN6PR21MB017882F0266B8C6F39475D28B3C20BN6PR21MB0178namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Why not? Since the server didn=92t get the last handshake packet, it will c= ontinue to process unprotected packets. So, when the client retransmits the= last handshake message in an unprotected packet, the server processes it. = Then everything should continue as usual. Sent from my Windows 10 phone [HxS - 15254 - 16.0.9029.2104] ________________________________ From: Marten Seemann Sent: Sunday, February 25, 2018 9:02:03 AM To: Nick Banks Cc: QUIC WG Subject: Re: Unrecoverable loss pattern I don=92t think this will fix the problem. All handshake packets (sent by t= he server) were received by the client and acknowledged (in the first 1-RTT= packet sent by the client). On Mon 26. Feb 2018 at 00:52, Nick Banks > wrote: Perhaps 6.1.2 should be changed just to say the server must continue to pro= cess unprotected packets until all the handshake packets are received, and = remove the part about receiving an ACK that acknowledges its handshake mess= ages? - Nick From: QUIC > On Behalf = Of Marten Seemann Sent: Sunday, February 25, 2018 6:26 AM To: QUIC WG > Subject: Unrecoverable loss pattern I=92ve been playing around with QUIC loss recovery and in my tests I=92m en= countering one specific loss pattern which it seems impossible to recover f= rom. It's pretty rare, because there are a couple of conditions that must b= e fulfilled for it to occur: 1. Client and server perform the handshake, no packets are lost so far. Cli= ent and server both arrive at the CONNECTED state, and the server receives = all ACKs for handshake packets it sent. The client receives ACKs for all ha= ndshake packets except for the one containing the FINISHED message is lost = (the packet containing the ACK for the FINISHED is lost). 2. The client starts using 1-RTT keys, and it sends two packets: First, a p= acket only containing an ACK, and then a packet containing stream data (e.g= . a request). The request packet is then lost. 3. The server receives the ACK in the 1-RTT packet, and it stops accepting = unencrypted packets according to 6.1.2 of the TLS draft. It doesn=92t gener= ate an ACK in response, since the packet only contained an ACK. 4. The client is now missing acknowledgements for two packets: the (unencry= pted) packet containing the FINISHED message, and the (1-RTT) packet contai= ning the request. It runs its loss recovery algorithm (OnLossDetectionAlarm= ), and since there is one outstanding handshake packet, it retransmit all o= utstanding handshake packets. Now we=92ve run into a situation we can=92t recover from: The server won=92= t even open packet sent as a retransmission (since these packets are unencr= ypted, and arrive after it already received a 1-RTT packet), and the client= will never retransmit the request packet. Furthermore, the server won't se= nd any other packets, since it's just waiting for a request from the client= . I think the solution for this is to also retransmit 1-RTT packets in a case= like this. Can we just apply the normal retransmission rules in OnLossDete= ctionAlarm, even if there are still handshake packets outstanding? --_000_BN6PR21MB017882F0266B8C6F39475D28B3C20BN6PR21MB0178namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Why not? Since the server didn=92t get the last hand= shake packet, it will continue to process unprotected packets. So, when the= client retransmits the last handshake message in an unprotected packet, th= e server processes it. Then everything should continue as usual.

 

Sent from my Windows 10 phone

[HxS - 15254 - 16.0.9029.2104]

 

From: Marten Seemann <ma= rtenseemann@gmail.com>
Sent: Sunday, February 25, 2018 9:02:03 AM
To: Nick Banks
Cc: QUIC WG
Subject: Re: Unrecoverable loss pattern
 
I don=92t think this will fix the problem. All handshake p= ackets (sent by the server) were received by the client and acknowledged (i= n the first 1-RTT packet sent by the client).
On Mon 26. Feb 2018 at 00:52, Nick Banks <nibanks@microsoft.com> wrote:

Perhaps 6.1.2 should be changed just to say the serv= er must continue to process unprotected packets until all the handshake pac= kets are received, and remove the part about receiving an ACK that acknowle= dges its handshake messages?

 

- Nick

 

From: QUIC <quic-bounces@ietf.org> On Behalf Of Marten Seemann
Sent: Sunday, February 25, 2018 6:26 AM
To: QUIC WG <q= uic@ietf.org>
Subject: Unrecoverable loss pattern

 

I=92ve been playing around with QUIC loss recovery a= nd in my tests I=92m encountering one specific loss pattern which it seems = impossible to recover from. It's pretty rare, because there are a couple of= conditions that must be fulfilled for it to occur:

 

1. Client and server perform the handshake, no packe= ts are lost so far. Client and server both arrive at the CONNECTED state, a= nd the server receives all ACKs for handshake packets it sent. The client r= eceives ACKs for all handshake packets except for the one containing the FINISHED message is lost (the packet con= taining the ACK for the FINISHED is lost).

2. The client starts using 1-RTT keys, and it sends = two packets: First, a packet only containing an ACK, and then a packet cont= aining stream data (e.g. a request). The request packet is then lost.

3. The server receives the ACK in the 1-RTT packet, = and it stops accepting unencrypted packets according to 6.1.2 of the TLS dr= aft. It doesn=92t generate an ACK in response, since the packet only contai= ned an ACK.

4. The client is now missing acknowledgements for tw= o packets: the (unencrypted) packet containing the FINISHED message, and th= e (1-RTT) packet containing the request. It runs its loss recovery algorith= m (OnLossDetectionAlarm), and since there is one outstanding handshake packet, it retransmit all outstan= ding handshake packets.

 

Now we=92ve run into a situation we can=92t recover = from: The server won=92t even open packet sent as a retransmission (since t= hese packets are unencrypted, and arrive after it already received a 1-RTT = packet), and the client will never retransmit the request packet. Furthermore, the server won't send any other packets, = since it's just waiting for a request from the client.

 

I think the solution for this is to also retransmit = 1-RTT packets in a case like this. Can we just apply the normal retransmiss= ion rules in OnLossDetectionAlarm, even if there are still hand= shake packets outstanding?

 <= /p>

--_000_BN6PR21MB017882F0266B8C6F39475D28B3C20BN6PR21MB0178namp_-- From nobody Sun Feb 25 10:08:36 2018 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 BF37E1270A0 for ; Sun, 25 Feb 2018 10:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, 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 (1024-bit key) header.d=ericsson.com header.b=fxb3guW/; dkim=pass (1024-bit key) header.d=ericsson.com header.b=Omttk3Az 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 0yQi8__utEZ9 for ; Sun, 25 Feb 2018 10:08:31 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 136DE126CC7 for ; Sun, 25 Feb 2018 10:08:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519582109; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=BVo28zU5HY7HZSPyupZqbxX4yQYhMqBaFFYFmj6Vd4w=; b=fxb3guW/L6tcA1ygYlu1KmUMM3yA0rY491/UqnvONcPwD4Zg5B220nYWg1EtxRw5 q/FBC0qSPPzSgtGOkm38Wz0PCUsu6Vk7xRbjgyZ6HvF/47zfy4CgPAMdsj/CPiF7 5i5iBHqERtzaLMItCelTy3DXlwHZ05uxsumSZVLFYC4=; X-AuditID: c1b4fb25-083ff70000002d5f-7b-5a92fb9c831c Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 13.4A.11615.C9BF29A5; Sun, 25 Feb 2018 19:08:29 +0100 (CET) Received: from ESESBMR502.ericsson.se (153.88.183.134) by ESESSHC016.ericsson.se (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sun, 25 Feb 2018 19:08:28 +0100 Received: from ESESSMB503.ericsson.se (153.88.183.164) by ESESBMR502.ericsson.se (153.88.183.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Sun, 25 Feb 2018 19:08:28 +0100 Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Sun, 25 Feb 2018 19:08:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BVo28zU5HY7HZSPyupZqbxX4yQYhMqBaFFYFmj6Vd4w=; b=Omttk3Azackqzx9YE+jxdcVcchE1g/FRBRkvvfGPkm5uACFFuD4+o7dQW1DXn0ejHLvp2U0J6E4Eeyn1gGSMtEcenoUDjYL6tUXPsS4chJIoITi3EwBtxIe2Qt0TMehQSMe4cb8GT6+7v75FvXYMyLpZiSmhOPotvL2Addl/49Y= Received: from AM6PR0702MB3624.eurprd07.prod.outlook.com (52.133.24.26) by AM6PR0702MB3814.eurprd07.prod.outlook.com (52.133.25.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.6; Sun, 25 Feb 2018 18:08:26 +0000 Received: from AM6PR0702MB3624.eurprd07.prod.outlook.com ([fe80::5933:848b:d25b:504a]) by AM6PR0702MB3624.eurprd07.prod.outlook.com ([fe80::5933:848b:d25b:504a%3]) with mapi id 15.20.0548.011; Sun, 25 Feb 2018 18:08:26 +0000 From: Ingemar Johansson S To: "gorry@erg.abdn.ac.uk" CC: "De Schepper, Koen (Nokia - BE/Antwerp)" , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , QUIC WG , Christian Huitema , Ian Swett , "Lubashev, Igor" , "ekinnear@apple.com" Subject: RE: ECN in QUIC connection migration Thread-Topic: ECN in QUIC connection migration Thread-Index: AdObSzPyOy5d4GB2SeSGz4shYev25AAZWcAAAB/s3/ABUaWKkACnvEWAAAvBcBAAIFvbgAAzEkjAAAhG1T4BW03A0AAFCx0AAMuR0qA= Date: Sun, 25 Feb 2018 18:08:26 +0000 Message-ID: References: <639A6936-34F2-4C27-973A-EEAE878677FA@apple.com> <5CC94D22-1375-40A2-8084-BA4A43F6FA94@tik.ee.ethz.ch>, <5A8DA500.2070101@erg.abdn.ac.uk> In-Reply-To: <5A8DA500.2070101@erg.abdn.ac.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.93] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM6PR0702MB3814; 7:j5Gkai0pkZh3ze8ein7FoFfPrmnVeJO6dgo+0v/3DN2ILscPbKCNyFIrdc2DAY4ZdD4L1ATplfr4TwRrAom/U7zjnHmJoAdTPF0dBoHz4YrqzRXRYdyLkC4Nkb9fQaAcircXEfw1K+ucAiLiycA28NHwpbvN/m7/C16L8jwIMjmCs/d5XjwAAoNjnFh5F35h77K8K4WuCcO+BWrvQI2XuNYQFdcxpkQ+BegESBgTq77NfHOwW0c6yWGkLwPwX5S/ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b1dadd10-73c7-439e-cb74-08d57c7ac45c x-microsoft-antispam: UriScan:(130329453890623); BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:AM6PR0702MB3814; x-ms-traffictypediagnostic: AM6PR0702MB3814: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(80524489315369)(244540007438412)(166708455590820)(211936372134217)(100405760836317)(202460600054446)(153496737603132)(130329453890623)(265313219721884); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231220)(944501161)(52105095)(3002001)(6041288)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:AM6PR0702MB3814; BCL:0; PCL:0; RULEID:; SRVR:AM6PR0702MB3814; x-forefront-prvs: 05947791E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(366004)(376002)(39380400002)(39860400002)(13464003)(51914003)(199004)(189003)(53936002)(3280700002)(81166006)(6436002)(1730700003)(6116002)(3846002)(8936002)(81156014)(45080400002)(229853002)(5890100001)(54906003)(2501003)(2906002)(55016002)(6306002)(68736007)(53946003)(9686003)(296002)(316002)(186003)(26005)(6246003)(8676002)(99286004)(15974865002)(5640700003)(3660700001)(8666007)(76176011)(97736004)(7696005)(966005)(93886005)(59450400001)(105586002)(6506007)(33656002)(53546011)(478600001)(86362001)(25786009)(14454004)(5660300001)(102836004)(5250100002)(7736002)(106356001)(66066001)(2351001)(74316002)(305945005)(6916009)(2900100001)(2950100002)(4326008); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR0702MB3814; H:AM6PR0702MB3624.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 1snFOr/0/mGkjMKCcZhN6nm9pWk027GrAZF9EyjC9Zqr6oXEdJQ8Hr28sTfj2h4CT5C3diDulW6v6D4s27bBpPKPUWEu3B8JqdrwSx+RRLmGyumzs5dhfjYPRk57NrgWxQQu+BFKQY2lASXYxiR+oZVlMKdcwXhYEpa+uNjmKSw= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b1dadd10-73c7-439e-cb74-08d57c7ac45c X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2018 18:08:26.3813 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR0702MB3814 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHOffe3V21xWkqPiRiriSy1KyESWK6PrgPRWVRMRBdelFJp2wq ZVAqYjinaZqvhUu3Xsy0TPMttSyMNCyWEk6xTJFe1Hy3ZWi7XoO+/Z/n+f3P/zyHw5DidsFW JkaVyKpVylgJbUuVnm2Sed5aua7Y2/FTJNXNBkt/ZJYjaUFauVBqGWkRSNNT75HS7iUjIX30 oJCS6vR2gYy84JWelDe++UXLdfNfCbm+PkluLumh5AaDhZCnL1XS8u6ZRfo4o7D1j2RjY5JZ tXdAuG30l4U2KmFiAF3IrTILU9G990iLbBjAByCtVktrkS0jxi8RrAwXCfmiAYEu00TxxTKC GmMPwVnE2EhA/1tXbkDhOQK+303b8BcQ0HlnaKOYQLBYXCrkLDT2h/tdy9ZEIeOAfaAjhENI PEhAe5tlHbHHntCY3kty2gF7wTddhkCLGKtOhs+vY7g2hd2h+uEMxbVFOBxys8L5pHoaakf7 BBxjY7XqWi3ruyHsAp+WRyhOk9gJzOMVBL8zBsOzdySvHeHb2KqA5yNgbjBnPRbwNvg0qOAR FzBVZCMuC/BTAvKytEJ+4AWN+VMb73gUKqaNNA8NIbhWeoPiD9oDpio1L+MhR+/BIyYERUNN ZB7yKfvvemVWjMS7oK7Vm2+7QWH2qJDTIrwF3pSOU3pEVSNHDas5Fxe1b78Xq46J0GjiVV4q NrEeWT/Vi4YV92b0YTKoC2EGSTaJbGavK8QCZbLmYlwXAoaUOIjMKdaWKFJ5MYVVx4epk2JZ TRdyZiiJk+im/VWFGEcpE9nzLJvAqv9NCcZmayqSyUyndn40OG52ayj53KIKczSL/xxwDdlh 9D1y5vHryoO9zrV9bXcPBWQ8D5pwbnDyK5Y1y8aCtk8tnjZ1PjE6Ha9cu3mlw7L6J3ShLr8/ 4jadFIemh8eNupMnfI+NXwpVxhEDFSm7/de8RYFzVM1Sid0kaXGJCm777XB43q/JcFlCaaKV Ph6kWqP8C9eJ6h9QAwAA 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, 25 Feb 2018 18:08:35 -0000 VGhhbmsgZm9yIHRoZSByZXZpZXcuIFRoZXJlIGFyZSBzdGlsbCBhIGZldyBtYXR0ZXJzIHRoYXQg YXJlIHVuY2xlYXIgaW4gdGhlIHRleHQsIHRoZXNlIGFyZSBoaWdobGlnaHRlZCB3aXRoIFtFRCBu b3RlLi4uLl0uIEJ1dCBJIGRvIGJlbGlldmUgdGhhdCB0aGUgcHJvcG9zZWQgdGV4dCBpcyBhIGdv b2QgZmlyc3Qgc3RhcnQgYW5kIHNob3VsZCBiZSBwb3NzaWJsZSB0byBwdWxsIHJlcXVlc3QgaW50 byB0aGUgcmVsZXZhbnQgZHJhZnRzIGluIGEgbm90IHRvbyBkaXN0YW50IGZ1dHVyZS4NCg0KL0lu Z2VtYXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHb3JyeSBGYWly aHVyc3QgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51a10NCj4gU2VudDogZGVuIDIxIGZlYnJ1 YXJpIDIwMTggMTc6NTgNCj4gVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hh bnNzb25AZXJpY3Nzb24uY29tPg0KPiBDYzogRGUgU2NoZXBwZXIsIEtvZW4gKE5va2lhIC0gQkUv QW50d2VycCkgPGtvZW4uZGVfc2NoZXBwZXJAbm9raWEtDQo+IGJlbGwtbGFicy5jb20+OyBNaXJq YSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPjsgUVVJQw0KPiBX RyA8cXVpY0BpZXRmLm9yZz47IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0 PjsgSWFuIFN3ZXR0DQo+IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgTHViYXNoZXYsIElnb3IgPGls dWJhc2hlQGFrYW1haS5jb20+Ow0KPiBla2lubmVhckBhcHBsZS5jb20NCj4gU3ViamVjdDogUmU6 IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uDQo+IA0KPiBTbyBJIHdvcmtlZCBjYXJl ZnVsbHkgdGhyb3VnaCB0aGUgdGV4dC4gTW9zdCBvZiB3aGF0IEkgc2F3IGxvb2tlZCBzb3VuZA0K PiAtIHdlbGwgZG9uZSENCj4gDQo+IEF0IHBsYWNlcyB0aGUgbGFuZ3VhZ2UgbG9va2VkIGluY29u c2lzdGVudCB3aXRoIGVpdGhlciBvdGhlciBwYXJ0cyBvZiB0aGUNCj4gZG9jdW1lbnQgb3Igd2l0 aCBvdGhlciBSRkNzLiBJIHVwZGF0ZWQgdGhlIHdpa2kgdG8gcmVzdWx2ZSB0aHNlcyBpc3N1ZXMu DQo+IEhvZXBmdWxseSB0aGUgbmV3IHRleHQgaXMgbW9yZSBjbG9zZSB0byB3aGF0IHdlIG5lZWQs DQo+IA0KPiBHb3JyeQ0KPiANCj4gT24gMjEvMDIvMjAxOCwgMTQ6MzcsIEluZ2VtYXIgSm9oYW5z c29uIFMgd3JvdGU6DQo+ID4NCj4gPiBIaQ0KPiA+DQo+ID4gVHJ5aW5nIHRvIHBpY2sgdXAgdGhp cyB0aHJlYWQgYWdhaW4uDQo+ID4NCj4gPiBEbyB3ZSBoYXZlIHNvbWUga2luZCBvZiBtaW5pbWFs IGNvbnNlbnN1cyBhcm91bmQgdGhlIHByb3Bvc2VkIEVDTg0KPiA+IGZ1bmN0aW9uYWxpdHkgaW4g UVVJQyA/DQo+ID4NCj4gPiBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dp a2kvRUNOLWluLVFVSUMjc3VnZ2VzdGVkLQ0KPiBhZGRpdA0KPiA+IGlvbnMtdG8tdG8tYmVjb21l LXJmY3MNCj4gPg0KPiA+IC9JbmdlbWFyDQo+ID4NCj4gPiAqRnJvbToqIERlIFNjaGVwcGVyLCBL b2VuIChOb2tpYSAtIEJFL0FudHdlcnApDQo+ID4gW21haWx0bzprb2VuLmRlX3NjaGVwcGVyQG5v a2lhLWJlbGwtbGFicy5jb21dDQo+ID4gKlNlbnQ6KiBkZW4gMTQgZmVicnVhcmkgMjAxOCAxNzo0 OQ0KPiA+ICpUbzoqIE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0 aHouY2g+OyBJbmdlbWFyDQo+ID4gSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJp Y3Nzb24uY29tPg0KPiA+ICpDYzoqIGVraW5uZWFyQGFwcGxlLmNvbTsgTHViYXNoZXYsIElnb3Ig PGlsdWJhc2hlQGFrYW1haS5jb20+OyBJYW4NCj4gPiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNv bT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBDaHJpc3RpYW4NCj4gPiBIdWl0ZW1hIDxodWl0 ZW1hQGh1aXRlbWEubmV0PjsgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA+IDxpbmdlbWFyLnMuam9o YW5zc29uQGVyaWNzc29uLmNvbT4NCj4gPiAqU3ViamVjdDoqIFJFOiBFQ04gaW4gUVVJQyBjb25u ZWN0aW9uIG1pZ3JhdGlvbg0KPiA+DQo+ID4gSGkgTWlyamEsDQo+ID4NCj4gPiBXaHkgd291bGQg eW91IGxpa2UgdG8gc2VlIHRoZSBkaXN0aW5jdGlvbj8NCj4gPg0KPiA+IEl0IHdhcyBpbmRlZWQg ZGVjaWRlZCBpbiB0aGUgc2lkZSBtZWV0aW5nIHRoYXQgd2Ugc2hvdWxkIG5vdCBmb3Jlc2VlDQo+ ID4gZXh0cmEgcHJvdG9jb2wgY29tcGxleGl0eSBmb3Igc2lnbmFsbGluZyB0aGF0IHRoZSByZWNl aXZlciBjYW5ub3QgcmVhZA0KPiA+IHRoZSBlY24gYml0cy4NCj4gPg0KPiA+IEZvciBtZSB0aGUg cmVhc29ucyB3ZXJlOiBJdCBpcyBub3QgYSBkZXNpcmVkIHNpdHVhdGlvbiB3aGljaCB3aWxsDQo+ ID4gaG9wZWZ1bGx5IGRpc2FwcGVhciBpbiB0aGUgZnV0dXJlLCBhbmQgSSBkb24ndCB0aGluayBp dCBpcyBzbyB1c2VmdWwNCj4gPiBmb3IgYSBzZW5kZXIgdG8ga25vdy4gV2Ugbm93IGFzc3VtZSBy ZWFkaW5nIDAwIGJpdHMgYW5kIGVjaG8gYWxsDQo+ID4gY291bnRlcnMgdW5pbmNyZW1lbnRlZCB3 aXRoIDAgdmFsdWVzIGluIHRoYXQgY2FzZSwganVzdCBhcyBpZiB0aGUgcGF0aA0KPiA+IGJsZWFj aGVzIGl0LiBJZiB3ZSBtYWtlIGFuIGV4cGxpY2l0IHByb3RvY29sIGV4Y2hhbmdlIGZvciBpdCwg aXQgZmVlbHMNCj4gPiBsaWtlIGl0IGlzIGFuIGV4dHJhIGZlYXR1cmUgOy0pLiBBbHNvIHBlb3Bs ZSBtaWdodCBzdGFydCBtYWtpbmcgdGhlaXINCj4gPiBjb25nZXN0aW9uIGNvbnRyb2wgbW9yZSBj b21wbGV4IHdpdGggdXAgdG8gMiBtb3JlIGNvbmRpdGlvbmFsDQo+ID4gcGFyYW1ldGVycyAoc2Vu ZGVyLWNhbm5vdC1zZXQtZWNuIGFuZCByZWNlaXZlci1jYW5ub3QtcmVhZC1lY24NCj4gPiBib29s ZWFucywgbmV4dCB0byBuby1lY24pLiBOb3QgdG8gbWVudGlvbiBleHRyYSBpbnRlcm9wIHRlc3Rj YXNlcyB3aXRoDQo+ID4gc3VjaCBzZW5kZXIncy9yZWNlaXZlcidzIGV4dHJhIGZ1bmN0aW9uYWxp dHkuDQo+ID4NCj4gPiBUbyBtYWtlIHlvdXIgY29kZSBzaW1wbGUgYW5kIHBsYXRmb3JtIGluZGVw ZW5kZW50LCBub3QgYmVpbmcgYWJsZSB0bw0KPiA+IHNldC9yZWFkIGVjaG8gYml0cyBzaG91bGQg YmUgaW52aXNpYmxlIHVudGlsIHRoZSBwb2ludCBvZiB0aGUgbWlzc2luZw0KPiA+IHNvY2tldCBB UEkgY2FsbCwgd2hpY2ggd2lsbCBtb3N0IHByb2JhYmx5IGhhdmUgY29uZGl0aW9uYWwgY29tcGls ZXINCj4gPiBkaXJlY3RpdmVzIHBlciBwbGF0Zm9ybSBhdCB0aGF0IHBvaW50Lg0KPiA+DQo+ID4g U28gY29uY2x1c2lvbiB3YXM6IEFueSBoaWdoZXIgbGF5ZXIgcHJvdG9jb2wgY29kZSBzaG91bGQg bm90IG1ha2UgYW55DQo+ID4gZGlzdGluY3Rpb24gYmV0d2VlbiBob3N0IGluYWJpbGl0eSBhbmQg cGF0aCBibGVhY2hpbmcsIGFuZCB3ZSBvbmx5DQo+ID4gaGF2ZSBmdW5jdGlvbmFsaXR5IGZvciBn ZW5lcmFsICJlbmQyZW5kIGVjbiBpbmFiaWxpdHkiLg0KPiA+DQo+ID4gQWdyZWVkIHRoYXQgdGhl IHJlY2VpdmVyIGNvZGUgc2hvdWxkIGJlIGluZGVwZW5kZW50IGZyb20gaG93IGVjbiBpcw0KPiA+ IHVzZWQuIFRoaXMgaXMgdGhlIGNhc2Ugbm93LiBGb3IgdGhlIHJlY2VpdmVyIHdlIG9ubHkgaW5j cmVtZW50IGFuZA0KPiA+IGVjaG8gdGhlIGNvdW50ZXJzIGFsbCB0aGUgdGltZS4gVGhhdCdzIGl0 LCB2ZXJ5IHNpbXBsZS4gT25seSB0aGUNCj4gPiBzZW5kZXIgZGV0ZXJtaW5lcyBob3cgZWNuIGNh cGFiaWxpdHkgaXMgY2hlY2tlZCBhbmQgaG93IGVjbiBpcyB1c2VkLg0KPiA+DQo+ID4gTWF5YmUg YWxzbyBhIGdvb2QgcG9pbnQgdGhhdCB0aGUgY3VycmVudCBjYXBhYmlsaXR5IGNoZWNrIGlzIHRo ZQ0KPiA+IG1pbmltYWw/PyBBbmQgbmVlZHMgc29tZSBleHRyYSBjaGVja3M/DQo+ID4NCj4gPiBS ZWdhcmRzLA0KPiA+DQo+ID4gS29lbi4NCj4gPg0KPiA+IE91dGxvb2sgdm9vciBBbmRyb2lkIDxo dHRwczovL2FrYS5tcy9naGVpMzY+IGRvd25sb2FkZW4NCj4gPg0KPiA+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiAtLQ0KPiA+DQo+ID4gKkZyb206KkluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5q b2hhbnNzb25AZXJpY3Nzb24uY29tDQo+ID4gPG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbT4+DQo+ID4gKlNlbnQ6KiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE0LCAyMDE4IDI6 MDg6MzAgUE0NCj4gPiAqVG86KiBNaXJqYSBLw7xobGV3aW5kDQo+ID4gKkNjOiogRGUgU2NoZXBw ZXIsIEtvZW4gKE5va2lhIC0gQkUvQW50d2VycCk7IGVraW5uZWFyQGFwcGxlLmNvbQ0KPiA+IDxt YWlsdG86ZWtpbm5lYXJAYXBwbGUuY29tPjsgTHViYXNoZXYsIElnb3I7IElhbiBTd2V0dDsgUVVJ QyBXRzsNCj4gPiBDaHJpc3RpYW4gSHVpdGVtYTsgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA+ICpT dWJqZWN0OiogUkU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uDQo+ID4NCj4gPiBI aQ0KPiA+DQo+ID4gSSBhdHRhY2ggdGhlIG1pbnV0ZXMgZnJvbSB0aGUgc2lkZSBtZWV0aW5nIGlu IFNpbmdhcG9yZSwgSSBiZWxpZXZlDQo+ID4gdGhhdCB0aGV5IHdlcmUgb25seSBwb3N0ZWQgb24g dGhlIGVjbi1xdWljIG1haWxpbmcgbGlzdCDimLkgLg0KPiA+DQo+ID4gSSBhZ3JlZSB0aGF0IHRo ZSBzZW5kZXIvcmVjZWl2ZWQgaXNzdWVzIGFyZSBwcm9iYWJseSBrbm93biBhLXByaW9yeQ0KPiA+ IGFuZCBpZiBhIHNlbmRlciBkb2VzIGtub3cgdGhhdCBpdHMgT1Mgc3RhY2sgZG9lcyBub3QgaGF2 ZSB0aGUNCj4gPiBuZWNlc3NhcnkgQVBJIHN1cHBvcnQgZm9yIEVDTiB0aGVuIGl0IGRvZXMgbm90 IG1ha2UgbXVjaCBzZW5zZSB0byB0cnkgaXQuDQo+ID4NCj4gPiAvSW5nZW1hcg0KPiA+DQo+ID4N Cj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9tOiBNaXJqYSBLw7xo bGV3aW5kIFttYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaF0NCj4gPiA+IFNl bnQ6IGRlbiAxMyBmZWJydWFyaSAyMDE4IDEzOjI5DQo+ID4gPiBUbzogSW5nZW1hciBKb2hhbnNz b24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20NCj4gPiA8bWFpbHRvOmluZ2Vt YXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPj4NCj4gPiA+IENjOiBEZSBTY2hlcHBlciwgS29l biAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0KPiA8a29lbi5kZV9zY2hlcHBlckBub2tpYS0NCj4gPiA8 bWFpbHRvOmtvZW4uZGVfc2NoZXBwZXJAbm9raWEtJTBiPj4gYmVsbC1sYWJzLmNvbT47DQo+ID4g ZWtpbm5lYXJAYXBwbGUuY29tIDxtYWlsdG86ZWtpbm5lYXJAYXBwbGUuY29tPjsgTHViYXNoZXYs IElnb3INCj4gPiA+IDxpbHViYXNoZUBha2FtYWkuY29tIDxtYWlsdG86aWx1YmFzaGVAYWthbWFp LmNvbT4+OyBJYW4gU3dldHQNCj4gPiA8aWFuc3dldHRAZ29vZ2xlLmNvbSA8bWFpbHRvOmlhbnN3 ZXR0QGdvb2dsZS5jb20+PjsgUVVJQyBXRw0KPiA+ID4gPHF1aWNAaWV0Zi5vcmcgPG1haWx0bzpx dWljQGlldGYub3JnPj47IENocmlzdGlhbiBIdWl0ZW1hDQo+ID4gPGh1aXRlbWFAaHVpdGVtYS5u ZXQgPG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj4NCj4gPiA+IFN1YmplY3Q6IFJlOiBFQ04g aW4gUVVJQyBjb25uZWN0aW9uIG1pZ3JhdGlvbg0KPiA+ID4NCj4gPiA+IEhpIEluZ2VtYXIsDQo+ ID4gPg0KPiA+ID4gc2VlIGJlbG93Lg0KPiA+ID4NCj4gPiA+ID4gQW0gMTIuMDIuMjAxOCB1bSAy MjoxMSBzY2hyaWViIEluZ2VtYXIgSm9oYW5zc29uIFMNCj4gPiA+IDxpbmdlbWFyLnMuam9oYW5z c29uQGVyaWNzc29uLmNvbQ0KPiA+IDxtYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb20+PjoNCj4gPiA+ID4NCj4gPiA+ID4gSGkNCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIHNl ZSBpbmxpbmUNCj4gPiA+ID4NCj4gPiA+ID4gQlINCj4gPiA+ID4gSW5nZW1hcg0KPiA+ID4gPg0K PiA+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4+IEZyb206IE1pcmph IEvDvGhsZXdpbmQgW21haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoXQ0KPiA+ ID4gPj4gU2VudDogZGVuIDEyIGZlYnJ1YXJpIDIwMTggMTY6MjYNCj4gPiA+ID4+IFRvOiBJbmdl bWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbQ0KPiA+IDxt YWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+Pg0KPiA+ID4gPj4gQ2M6IERl IFNjaGVwcGVyLCBLb2VuIChOb2tpYSAtIEJFL0FudHdlcnApDQo+ID4gPiA+PiA8a29lbi5kZV9z Y2hlcHBlckBub2tpYS0NCj4gPiA8bWFpbHRvOmtvZW4uZGVfc2NoZXBwZXJAbm9raWEtJTBiPj4g Pj4gYmVsbC1sYWJzLmNvbT47DQo+ID4gZWtpbm5lYXJAYXBwbGUuY29tIDxtYWlsdG86ZWtpbm5l YXJAYXBwbGUuY29tPjsgTHViYXNoZXYsIElnb3INCj4gPiA+ID4+IDxpbHViYXNoZUBha2FtYWku Y29tIDxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+OyBJYW4gU3dldHQNCj4gPiA8aWFuc3dl dHRAZ29vZ2xlLmNvbSA8bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PjsgUVVJQyBXRw0KPiA+ ID4gPj4gPHF1aWNAaWV0Zi5vcmcgPG1haWx0bzpxdWljQGlldGYub3JnPj47IENocmlzdGlhbiBI dWl0ZW1hDQo+ID4gPGh1aXRlbWFAaHVpdGVtYS5uZXQgPG1haWx0bzpodWl0ZW1hQGh1aXRlbWEu bmV0Pj4NCj4gPiA+ID4+IFN1YmplY3Q6IFJlOiBFQ04gaW4gUVVJQyBjb25uZWN0aW9uIG1pZ3Jh dGlvbg0KPiA+ID4gPj4NCj4gPiA+ID4+IEhpIEluZ2VtYXIsDQo+ID4gPiA+Pg0KPiA+ID4gPj4g dHdvIHBvaW50cy4NCj4gPiA+ID4+DQo+ID4gPiA+PiBJIHRoaW5rIGl0IHdvdWxkIGJlIGdvb2Qg dG8gYmUgYXMgZXhwbGljaXQgYXMgcG9zc2libGUgaGVyZSwNCj4gPiA+ID4+IHRoZXJlZm9yZSBJ IHdvdWxkIHByZWZlciBpZiBhbiBlbmRwb2ludCB0aGF0IGtub3dzIHRoYXQgaXQgY2FuDQo+ID4g PiA+PiBub3QgYWNjZXNzIHRoZSBFQ04gSVAgYml0cyBpbmRpY2F0ZXMgdGhpcyBkaXJlY3RseSBp biB0aGUNCj4gPiA+ID4+IGhhbmRzaGFrZS4gSW4gdGhpcyBjYXNlIG5vIGZ1cnRoZXIgdGVzdGlu ZyBpcyBuZWVkZWQuDQo+ID4gPiA+IDxJSj4gWWVzLCB0aGlzIHdhcyB0aGUgb3JpZ2luYWwgaWRl YSwgd2UgZGlzY3Vzc2VkIHRoaXMgYXQgdGhlIEVDTg0KPiA+ID4gPiBRVUlDIHNpZGUgbWVldGlu ZyB0aG91Z2ggYW5kIGFmdGVyd2FyZHMgYW5kIGFzIGZhciBhcyBJIHVuZGVyc3RhbmQNCj4gPiA+ ID4gaXQsIHRoZXJlIHdhcyBhIGNvbnNlbnN1cyB0aGF0IGl0IHdhcyB1bm5lY2Vzc2FyaWx5IGNv bXBsaWNhdGVkLg0KPiA+ID4gPiBTbyB3ZSBzZWxlY3RlZCBhIG1ldGhvZCB3aGVyZSB3ZSBqdXN0 IHZlcmlmeSB0aGF0IHRoZQ0KPiA+ID4gPiBFQ1QoMCksRUNUKDEpLENFIGNvdW50ZXJzIGhhdmUg cmVhc29uYWJsZSB2YWx1ZXMuIElmIHRoYXQgaXMgbm90DQo+ID4gPiA+IHRoZSBjYXNlLCB0aGVu IGl0IGlzIGFuIGluZGljYXRpb24gdGhhdCBlaXRoZXIgdGhlIHBhdGggb3IgdGhlDQo+ID4gPiA+ IGVuZHBvaW50cyBkbyBub3Qgc3VwcG9ydCBFQ04uIDwvSUo+DQo+ID4gPg0KPiA+ID4gSSBjaGVj a2VkIHRoZSBtaW51dGVzIGFuZCBjb3VsZCBub3QgcmVhbGx5IGZpbmQgYSBjb25jbHVzaW9uIHRo ZXJlLg0KPiA+IEkgYWdyZWUNCj4gPiA+IHRoYXQgdGhlcmUgc2hvdWxkIGJlIG5vIG5lZ290aWF0 aW9uIGluIHRoZSBoYW5kc2hha2UgKGJvdGggZW5kcG9pbnQNCj4gPiA+IG5lZWQgdG8gaW1wbGVt ZW50IHRoZSBFQ04gbG9naWMgYXMgcGFydCBvZiB2MSkgYnV0IHdoYXQgd291bGQgYmUNCj4gPiA+ IGhlbHBmdWwNCj4gPiBpcyB0byBsZXQNCj4gPiA+IHRoZSBvdGhlciBlbmQga25vdyBpZiB5b3Ug YWxyZWFkeSBrbm93IHRoYXQgeW91IG5ldmVyIHdpbGwgYmUgYWJsZQ0KPiA+ID4gdG8gcHJvdmlk ZSBmZWVkYmFjayBiZWNhdXNlIHlvdSBjYW4ganVzdCBub3QgcmVhZCB0aGUgYml0cyBpbiB0aGUg SVANCj4gPiBoZWFkZXIuDQo+ID4gPiBUaGF0IGlzIG5vdCBjb21wbGljYXRlZCBhdCBhbGwuDQo+ ID4gPg0KPiA+ID4gSSB0aGluayB3aGF0IHdlIG5lZWQgdG8gc3BlY2lmeSBpbiB2MSBpcyBhIHdh eSB0byBwcm92aWRlIEVDTg0KPiA+IGZlZWRiYWNrIChvcg0KPiA+ID4gaW5kaWNhdGUgdGhhdCB0 aGlzIGlzIG5vdCBwb3NzaWJsZSkuIEhvd2V2ZXIsIHdlIGFjdHVhbGx5IHdvdWxkIG5vdA0KPiA+ IG5lZWQgdG8NCj4gPiA+IHNheSBhbnl0aGluZyBhYm91dCBob3cgRUNOIHNob3VsZCBiZSB1c2Vk LiBUaGF04oCZcyBhIHNlbmRlciBzaWRlDQo+ID4gZGVjaXNpb24uDQo+ID4gPiBBcyBsb25nIGFz IHlvdSBjYW4gZ2V0IGZlZWRiYWNrLCB3ZSBhcmUgZmxleGlibGUgaW4gaG93IHRvIHVzZSBhbmQN Cj4gPiB0ZXN0IEVDTiBpbg0KPiA+ID4gdjEgb3IgYW55dGltZSBsYXRlci4gT2YgY291cnNlIGl0 IHdvdWxkIGJlIG5pY2UgdG8gcHJvdmlkZSBzb21lDQo+ID4gPiBkZWZhdWx0IHJlY29tbWVuZGF0 aW9ucyB3aXRoIHNvbWUgZWFzeSBmYWxsYmFjayBsb2dpYyBidXQgdGhhdCdzIHRoZQ0KPiA+ID4g cGFydCB3ZSBjYW4gZXhwZXJpbWVudCB3aXRoIGFuZCBjaGFuZ2UgYW55IHRpbWUgd2l0aG91dCBh bnkgbmVlZCB0bw0KPiA+ID4gY2hhbmdlIHRoZSBwcm90b2NvbCBzcGVjIChhcyBsb25nIGFzIEVD TiBmZWVkYmFjayBpcyBwcm92aWRlZCwgd2hlbg0KPiA+ID4gRUNOIGlzIHVzZWQNCj4gPiBieSB0 aGUNCj4gPiA+IHNlbmRlcikuDQo+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPj4NCj4gPiA+ID4+IEZ1 cnRoZXIsIHRoZSBwYXRoIHRlc3RpbmcgaXRzZWxmIGlzIGluZGVwZW5kZW50IG9mIFFVSUMgYW5k IGNhbg0KPiA+ID4gPj4gYmUgdXNlZCBmb3IgYW55IHByb3RvY29sLiBNb3Jlb3ZlciwgaXTigJlz IG1vcmUgY29tcGxpY2F0ZWQgdGhhbg0KPiA+ID4gPj4ganVzdCB0ZXN0aW5nIEVDVC4gSSBndWVz cyB0aGUgZ2VuZXJhbCBhZHZpY2UgaGVyZSBpcyB0byByZW1lbWJlcg0KPiA+ID4gPj4gd2hpY2gg Y29kZXBvaW50cyB3ZXJlIHNlbmQgYW5kIGNvbXBhcmUgdGhpcyB0byB0aGUgZmVlZGJhY2sNCj4g PiA+ID4+IHByb3ZpZGVkLiBJZiBkaXNjcmVwYW5jaWVzIGFyZSBvYnNlcnZlZCB0aGF0IGluZGlj YXRlIHRoYXQgYQ0KPiA+ID4gPj4gbWlkZGxlYm94IGhhcyBjaGFuZ2VkIHRoZXNlIGJpdHMsIGFs bCBwYWNrZXRzIHNob3VsZCBiZSBtYXJrZWQgYXMNCj4gPiA+ID4+IG5vLUVDVCAod2hpbGUgYWRk aXRpb25hbCB0ZXN0aW5nIE1BWSBiZSBwZXJmb3JtZWQgYXQgYW55IGxhdGVyDQo+ID4gPiA+PiBw b2ludCBpbiB0aW1lKS4gSG93ZXZlciwgaG93IGV4YWN0bHkgdGhpcyB0ZXN0aW5nIHNob3VsZCBs b29rDQo+ID4gPiA+PiBsaWtlLCBzaG91bGQgbm90IGJlIHNwZWNpZmllZCBpbg0KPiA+IHRoaXMg ZG9jDQo+ID4gPiAoYnV0IG1vcmUgZ2VuZXJhbGx5KS4NCj4gPiA+ID4gPElKPiBJdCBpcyBwb3Nz aWJsZSB0aGF0IHRoZSBhY3R1YWwgcGF0aCB2ZXJpZmljYXRpb24gY2FuIGJlIHB1dA0KPiA+ID4g PiBhcyBhIHNlcGFyYXRlIGRvY3VtZW50LCBub3Qgc3VyZSBpZiB0aGF0IGlzIGFjY2VwdGVkIGJ5 IHRoZSBncm91cA0KPiA+ID4gPiBvciBpdCBpcyBkZXNpcmVkIHdpdGggYSBtb3JlIGVsYWJvcmF0 ZSBkZXNjcmlwdGlvbiBkaXJlY3RseSBpbiB0aGUgUVVJQw0KPiBkcmFmdHMuDQo+ID4gPiA+IEFz IHJlZ2FyZHMgdG8gdmVyaWZpY2F0aW9uLCBJIGRvIGJlbGlldmUgdGhhdCB0aGUgcHJvcG9zZWQN Cj4gPiA+ID4gY291bnRlcnMgc2hvdWxkIGJlIGFibGUgdG8gZGV0ZWN0IGJsZWFjaGluZywgYWNj aWRlbnRhbCByZW1hcmtpbmcNCj4gPiA+ID4gZnJvbSBFQ1QoMCkgdG8gRUNUKDEpIGFuZCBhbHNv IGNhc2VzIHdoZXJlIHBhY2tldHMgYXJlIG5vdCBDRQ0KPiA+ID4gPiBtYXJrZWQgYXQgYWxsIGRl c3BpdGUgb3RoZXIgc2lnbnMgb2YgY29uZ2VzdGlvbiA8L0lKPg0KPiA+ID4NCj4gPiA+IFdlIHRy aWVkIHRvIGRlc2lnbiBhIG1vcmUgZWxhYm9yYXRlZCB0ZXN0aW5nIHNjaGVtZSB3aGVyZSB3ZSB3 b3VsZA0KPiA+ID4gc2VuZA0KPiA+ID4gMyBFQ1QwLCB0aGUgMyBFQ1QxLCBhbmQgdGhlIDMgQ0Ug KHdoaWNoIHdlIHdvdWxkIG9mIGNhdXNlIG5vdCBjb3VudA0KPiA+ID4gYXMgYSBjb25nZXN0aW9u IGluZGljYXRpb24gYXMgdGhlIENFIHdhcyBzZXQgYnkgdGhlIHNlbmRlcikuDQo+ID4gPiBIb3dl dmVyLA0KPiA+IHRoaXMgd2FzDQo+ID4gPiBtb3N0bHkgdG8gZGV0ZWN0IGJsYWNrLXdoYWxpbmcg d2hpY2ggaXMgcHJvYmFibHkgbGVzcyBhIGNvbmNlcm4gdGhhbg0KPiA+ID4gcmUtIG1hcmtpbmcu IEkgdGhpbmsgdG9kYXkgdGhlIG1vc3QgY29tbW9uIGNhc2UgaXQgdGhhdCB0aGUgYml0cw0KPiA+ ID4gd2lsbCBiZQ0KPiA+IHNldCB0bw0KPiA+ID4gemVyb3Mgd2hpY2ggaXMgb25seSBhIHByb2Js ZW0gd2hlbiB0aGVyZSB3YXMgc29tZSBDRSBtYXJraW5nDQo+ID4gPiBwcmV2aW91c2x5IG9uIHRo ZSBwYXRoIHRoYXQgdGhlbiB3b3VsZCBnZXQgbG9zdC4gVGh1cyBpbiB0aGlzIGNhc2UNCj4gPiA+ IGl0IHdvdWxkIGJlIHJlY29tbWVuZCB0byBub3QgdXNlIEVDTi9ub3Qgc2V0IHBhY2tldHMgYXMg RUNUIGF0IHNlbmRlcg0KPiBzaWRlLg0KPiA+ID4NCj4gPiA+IEhvd2V2ZXIsIGFzIEkgc2FpZCBh Ym92ZSwgd2UgcHJvYmFibHkgc2hvdWxkIG1ha2UgcmVjb21tZW5kYXRpb24NCj4gaG93DQo+ID4g PiB0byB1c2UgRUNOIGJ5IGRlZmF1bHQgYnV0IG5lZWQgdG8gbGVhdmUgcm9vbSBmb3Igb3RoZXIg dXNhZ2UvdGVzdGluZw0KPiA+IHNjaGVtZXMuDQo+ID4gPiBCdXQgYWZ0ZXIgYWxsIHRoZSByZWNl aXZlciBiZWluZyBub3QgYWJsZSB0byByZWFkIHRoZSBiaXRzIGFuZA0KPiA+IHJlbWFya2luZyBv biB0aGUNCj4gPiA+IHBhdGggYXJlIHRvIGRpZmZlcmVudCB0aGluZ3MgYW5kIHNob3VsZCBub3Qg YmUgbWl4ZWQgdXAuIElmIHRoZQ0KPiA+IHNlbmRlciBjYW4NCj4gPiA+IG5vdCByZWFkIHRoZSBi aXRzIHRoaXMgaXMga25vdyBhIHByaW9yaSBhbmQgdGhlcmUgaXMgbm8gYW1iaWd1aXR5DQo+ID4g dGhhdCBuZWVkcyB0bw0KPiA+ID4gYmUgdGVzdGVkLiBTbyB3aHkgbm90IHNpZ25hbCBpdCBkaXJl Y3RseS4gVGhlIHF1ZXN0aW9uIGlmIHRoZSBzZW5kZXINCj4gPiBjYW4gd3JpdGUNCj4gPiA+IEVD TiBkb2VzIG5vdCBuZWVkIHRvIGJlIGNvbW11bmljYXRlZC4gVGhlcmUgaXMgbm8gZGlmZmVyZW5j ZSBpbiB0aGUNCj4gPiA+IHNlbmRlciBkZWNpZGVkIHRvIG5vdCB1c2UgRUNOIG9yIGl0IGp1c3Qg Y2FuIG5vdCB1c2UgaXQ7IGluIGJvdGgNCj4gPiBjYXNlcyBpdCBpcyBub3QNCj4gPiA+IG5lY2Vz c2FyeSB0byBzZW5kIEVDTiBmZWVkYmFjayBiYWNrLiBPbmx5IGlmIGEgbm9uLW5vbi1FQ1QgaXMN Cj4gPiBvYnNlcnZlZCBhdA0KPiA+ID4gdGhlIHJlY2VpdmVyLCBFQ04gZmVlZGJhY2sgbmVlZHMg dG8gYmUgcHJvdmlkZWQuIEhvd2V2ZXIsIGtub3dpbmcNCj4gPiA+IHRoYXQgdGhlIHJlY2VpdmVy IGNhbuKAmXQgbm90IHByb3ZpZGUgZmVlZGJhY2sgaXMgaW1wb3J0YW50IGJlY2F1c2UgaW4NCj4g PiA+IHRoaXMNCj4gPiBjYXNlIHRoZQ0KPiA+ID4gc2VuZGVyIE1VU1Qgbm90IHNldCB0aGUgcGFj a2V0cyBhcyBFQ1QgYXMgaXQgd2lsbCBub3QgYmUgYWJsZSB0bw0KPiA+IHJlYWN0IHRvIHRoYXQN Cj4gPiA+IHNpZ25hbC4gVGVzdGluZyB0aGUgcGF0aCBpbiBpbmRlcGVuZGVudCBvZiB0aGF0Lg0K PiA+ID4NCj4gPiA+IE1pcmphDQo+ID4gPg0KPiA+ID4NCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ ID4+DQo+ID4gPiA+PiBNaXJqYQ0KPiA+ID4gPj4NCj4gPiA+ID4+DQo+ID4gPiA+Pj4gQW0gMDku MDIuMjAxOCB1bSAwODozNCBzY2hyaWViIEluZ2VtYXIgSm9oYW5zc29uIFMNCj4gPiA+ID4+IDxp bmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbQ0KPiA+IDxtYWlsdG86aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb20+PjoNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IEhpIEVyaWMsIEtv ZW4gKyBvdGhlcnMNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IFRoYW5rcyBmb3IgdGhlIGNvbW1lbnRz IGFuZCB0aGUgdXBkYXRlLiBBIHF1ZXN0aW9uIHRvIHRoZSByZXN0DQo+ID4gPiA+Pj4gb2YgdGhl DQo+ID4gPiA+PiBhdWRpZW5jZSwgZG9lcyB0aGUgcHJlc2VudGVkIHRleHQgZXhwbGFpbiBzdWZm aWNpZW50bHkgZW5vdWdoIGhvdw0KPiA+ID4gPj4gRUNOIHdvcmtzIHdpdGggY29ubmVjdGlvbiBt aWdyYXRpb24gPw0KPiA+ID4gPj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFm dHMvd2lraS9FQ04taW4tUVVJQyN0cmFuc3BvcnQNCj4gPiA+ID4+PiAtDQo+ID4gPiA+PiBkcmFm dC1jb25uZWN0aW9uLW1pZ3JhdGlvbg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiAv SW5nZW1hcg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBGcm9tOiBEZSBTY2hlcHBl ciwgS29lbiAoTm9raWEgLSBCRS9BbnR3ZXJwKQ0KPiA+ID4gPj4gW21haWx0bzprb2VuLmRlX3Nj aGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb21dDQo+ID4gPiA+Pj4gU2VudDogZGVuIDIgZmVicnVh cmkgMjAxOCAxNTo0NA0KPiA+ID4gPj4+IFRvOiBla2lubmVhckBhcHBsZS5jb20gPG1haWx0bzpl a2lubmVhckBhcHBsZS5jb20+OyBJbmdlbWFyDQo+ID4gSm9oYW5zc29uIFMNCj4gPiA+ID4+IDxp bmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbQ0KPiA+IDxtYWlsdG86aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb20+Pg0KPiA+ID4gPj4+IENjOiBRVUlDIFdHIDxxdWljQGlldGYu b3JnIDxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBJYW4gU3dldHQNCj4gPiA8aWFuc3dldHRAZ29v Z2xlLmNvbSA8bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PjsNCj4gPiA+ID4+IEx1YmFzaGV2 LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tDQo+ID4gPG1haWx0bzppbHViYXNoZUBha2FtYWku Y29tPj47IENocmlzdGlhbiBIdWl0ZW1hDQo+ID4gPiA+PiA8aHVpdGVtYUBodWl0ZW1hLm5ldCA8 bWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXQ+Pg0KPiA+ID4gPj4+IFN1YmplY3Q6IFJFOiBFQ04g aW4gUVVJQyBjb25uZWN0aW9uIG1pZ3JhdGlvbg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gSGkgSW5n ZW1hciwNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IEkgYWxzbyByZWFkIGFnYWluIHRocm91Z2ggdGhl IGRvY3VtZW50LCBhbmQgaGFkIGZvbGxvd2luZw0KPiBjb21tZW50czoNCj4gPiA+ID4+Pg0KPiA+ ID4gPj4+IEkgcmVwbGFjZWQ6DQo+ID4gPiA+Pj4g4oCcVGhlIEFDS19FQ04gZnJhbWUgaXMgdXNl ZCB0byBjb252ZXkgQUNLcyB3aGVuIHRoZSBFQ04NCj4gPiA+ID4+PiBjYXBhYmlsaXR5DQo+ID4g PiA+PiBleGNoYW5nZSBjb25jbHVkZXMgdGhhdCBFQ04gc2hvdWxkIGJlIHVzZWQgZm9yIHRoZSBn aXZlbg0KPiBjb25uZWN0aW9uLuKAnQ0KPiA+ID4gPj4+IE9yaWdpbmFsbHkgaXQgc291bmRzIGFz IGlmIHRoZSBjb3VudGVycyBhcmUgbm90IGVjaG9lZCBhbnltb3JlDQo+ID4gPiA+Pj4gaWYgdGhl IEVDTg0KPiA+ID4gPj4gY2FwYWJpbGl0eSBjaGVjayBmYWlscy4gSSBhc3N1bWUgdGhpcyB3YXMg bm90IHRoZSBpbnRlbnRpb24sIGJ1dA0KPiA+ID4gPj4gaWYgaXQgaXM6IEZpcnN0LCB3ZSBkb27i gJl0IGhhdmUgYSBwcm90b2NvbCBvciBkZWNpc2lvbiBwb2ludA0KPiA+ID4gPj4gZGVmaW5lZCB3 aGVuIHRoYXQgY29uZGl0aW9uIGlzIG1ldCAoc2VuZGVyIHNob3VsZCBsZXQgdGhlDQo+ID4gPiA+ PiByZWNlaXZlciBrbm93IGluIHRoZSBuZXh0IHBhY2tldCksIGFuZCBzZWNvbmQsIEkgd291bGQg YWx3YXlzDQo+ID4gPiA+PiBzZW5kIHRoZSBlY2hvLCBhcyB3ZSBtaWdodCDigJx0cnkgYWdhaW4g bGF0ZXIgKHdpdGggYW5vdGhlciBFQ1Q/KeKAnSwNCj4gPiA+ID4+IG9yIG1pZ2h0IGRlY2lkZSB0 byB1c2UgdGhlDQo+ID4gRUNOIGJpdHMNCj4gPiA+IGRpZmZlcmVudGx5IGxhdGVyLg0KPiA+ID4g Pj4+DQo+ID4gPiA+Pj4gSSBhbHNvIGNoYW5nZWQgdGhlIHRleHQgYXJvdW5kIHRoZSBjb25uZWN0 aW9uIG1pZ3JhdGlvbiwgSSB0aGluaw0KPiA+ID4gPj4+IGJlZm9yZSBFcmljDQo+ID4gPiA+PiBy ZXZpZXdlZCBpdC4gSSBtYWRlIGl0IHN1Y2ggdGhhdCBldmVyeSBuZXcgcGF0aCBjcmVhdGVzIGEg bmV3DQo+ID4gPiA+PiBjb25uZWN0aW9uIHN0YXRlIHdpdGggYW4gaW5pdGlhbGl6ZWQgY29uZ2Vz dGlvbiBjb250cm9sIHN0YXRlIGFuZA0KPiA+ID4gPj4gRUNOIGNvdW50ZXJzIChhdCBsZWFzdCBF Q04gY291bnRlcnMgcmVzZXQgdG8gMHMpLiBOb3Qgc3VyZSBpZg0KPiA+ID4gPj4gdGhpcyBtYXRj aGVzIHdpdGggdGhlIG90aGVyIHNlY3Rpb25zIGluIHRoZSBRVUlDIGRyYWZ0Lg0KPiA+ID4gPj4+ DQo+ID4gPiA+Pj4gSSBhbHNvIGhhZCB0aGUgdGhvdWdodCB3aGV0aGVyIGl0IHdhcyByZWFsbHkg bmVlZGVkIHRvIGhhdmUgdGhlDQo+ID4gPiA+Pj4gMiBjYXNlcy4gSQ0KPiA+ID4gPj4gYWdyZWUg d2Ugc2hvdWxkIHNpbXBsaWZ5LCBieSBqdXN0IHN0YXJ0aW5nIG92ZXIgYW5kIGRvaW5nIHRoZQ0K PiA+ID4gPj4gY2hlY2sgdW5jb25kaXRpb25hbGx5IHdoZXRoZXIgaXQgd2FzIHN1Y2Nlc3NmdWwg b3Igbm90IGluIGEgcHJldmlvdXMNCj4gcGF0aC4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IFJlZ2Fy ZHMsDQo+ID4gPiA+Pj4gS29lbi4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IEZyb206IGVraW5uZWFy QGFwcGxlLmNvbSA8bWFpbHRvOmVraW5uZWFyQGFwcGxlLmNvbT4NCj4gPiBbbWFpbHRvOmVraW5u ZWFyQGFwcGxlLmNvbV0NCj4gPiA+ID4+PiBTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDIsIDIwMTgg MTI6MDIgQU0NCj4gPiA+ID4+PiBUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb20NCj4gPiA8bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJp Y3Nzb24uY29tPj4NCj4gPiA+ID4+PiBDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZyA8bWFpbHRv OnF1aWNAaWV0Zi5vcmc+PjsgSWFuIFN3ZXR0DQo+ID4gPGlhbnN3ZXR0QGdvb2dsZS5jb20gPG1h aWx0bzppYW5zd2V0dEBnb29nbGUuY29tPj47DQo+ID4gPiA+PiBMdWJhc2hldiwgSWdvciA8aWx1 YmFzaGVAYWthbWFpLmNvbQ0KPiA+IDxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+OyBDaHJp c3RpYW4gSHVpdGVtYQ0KPiA+ID4gPj4gPGh1aXRlbWFAaHVpdGVtYS5uZXQgPG1haWx0bzpodWl0 ZW1hQGh1aXRlbWEubmV0Pj47IERlDQo+IFNjaGVwcGVyLA0KPiA+IEtvZW4gKE5va2lhIC0gQkUv QW50d2VycCkNCj4gPiA+ID4+IDxrb2VuLmRlX3NjaGVwcGVyQG5va2lhLWJlbGwtbGFicy5jb20N Cj4gPiA8bWFpbHRvOmtvZW4uZGVfc2NoZXBwZXJAbm9raWEtYmVsbC1sYWJzLmNvbT4+DQo+ID4g PiA+Pj4gU3ViamVjdDogUmU6IEVDTiBpbiBRVUlDIGNvbm5lY3Rpb24gbWlncmF0aW9uDQo+ID4g PiA+Pj4NCj4gPiA+ID4+PiBIaSBJbmdlbWFyLA0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gVGhpcyBn ZW5lcmFsbHkgbG9va3MgZ29vZCB0byBtZSENCj4gPiA+ID4+PiBBIGZldyBxdWVzdGlvbnMgYW5k IG9ic2VydmF0aW9uczoNCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IFRoZXJlIGFyZSB0d28gdW5pcXVl IGNhc2VzOg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gICAgICAgICAgICAgICAg4oCiIEVDTiBjYXBh YmlsaXR5IGNoZWNrIHN1Y2Nlc3NmdWwgYXQgaW5pdGlhbA0KPiA+IGNvbm5lY3Rpb24gc2V0dXAN Cj4gPiA+ID4+PiAgICAgICAgICAgICAgICDigKIgRUNOIGNhcGFiaWxpdHkgY2hlY2sgZmFpbGVk IGF0IGluaXRpYWwNCj4gPiA+ID4+PiBjb25uZWN0aW9uIHNldHVwDQo+ID4gPiA+Pj4NCj4gPiA+ ID4+PiBBcmUgdGhlc2UgYWN0dWFsbHkgYW55IGRpZmZlcmVudCBpbiB0ZXJtcyBvZiBhY3Rpb24g dGFrZW4gYnkgYW4NCj4gPiBlbmRwb2ludD8NCj4gPiA+ID4+PiBJdCBzZWVtcyBsaWtlIG9uIHRo ZSBuZXcgbmV0d29yayBwYXRoIHRoZSBlbmRwb2ludCB3b3VsZCBnbw0KPiA+ID4gPj4+IHRocm91 Z2ggdGhlDQo+ID4gPiA+PiBzYW1lIHByb2Nlc3Mgb2Y6IChhKSB2ZXJpZnkgRUNOIGNhcGFiaWxp dHkgYW5kIGlmIHN1Y2Nlc3NmdWwgdG8NCj4gPiA+ID4+IHdoYXRldmVyIGRlZ3JlZSB0aGVuIChi KSBydW4gdGhlIHJlc3Qgb2YgdGhlIEVDTiBtYWNoaW5lcnkgYXMNCj4gPiA+IGFwcHJvcHJpYXRl Lg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gSW4gb3RoZXIgd29yZHMsIGFzIGxvbmcgYXMgeW91IGFs bG93IHBlb3BsZSB0byBzdGFydCB1c2luZyBFQ04NCj4gPiA+ID4+PiB1cG9uDQo+ID4gPiA+PiBt aWdyYXRpb24gKGluIG90aGVyIHdvcmRzLCB0byBhbGxvdyBzdGFydGluZyBpdCBhZnRlciB0aGUg aW5pdGlhbA0KPiA+ID4gPj4gY29ubmVjdGlvbiBlc3RhYmxpc2htZW50KSwgdGhlbiB0aGUgc3Bl Y2lmaWNzIGZvciBFQ04gd2l0aA0KPiA+ID4gPj4gbWlncmF0aW9uIGlzIGVzc2VudGlhbGx5IG9u ZSBzdGF0ZW1lbnQsIHdoaWNoIGlzIOKAnGRvIHRoZSBFQ04NCj4gPiA+ID4+IHByb2Nlc3Mgb24g ZWFjaCBuZXcgbmV0d29yayBwYXRoIHRoYXQgeW91IHVzZeKAnS4NCj4gPiA+ID4+Pg0KPiA+ID4g Pj4+IENvbm5lY3Rpb24gbWlncmF0aW9uIGhhcyBpbXBhY3Qgb24gdGhlIG51bWJlciBvZiByZXBv cnRlZCBDRQ0KPiA+ID4gPj4+IG1hcmtlZA0KPiA+ID4gPj4gcGFja2V0cy4gQSBuZXcgY29ubmVj dGlvbiBzdGF0ZSB3aXRoIG5ldyBjb25nZXN0aW9uIGNvbnRyb2wgc3RhdGUNCj4gPiA+ID4+IGFu ZCBFQ04gY291bnRlcnMgaXMgaW5zdGFudGlhdGVkIGF0IHRoZSBzZW5kZXIgYW5kIHJlY2VpdmVy LiBUaGUNCj4gPiA+ID4+IEVDTiBjb3VudGVycyBNVVNUIHN0YXJ0IGZyb20gemVybyBhZ2Fpbi4N Cj4gPiA+ID4+Pg0KPiA+ID4gPj4+IFRoaXMgc2VlbXMgZmluZSB0byBtZSwgaXTigJlzIGlubGlu ZSB3aXRoIHRoZSByZXN0IG9mIHRoZQ0KPiA+ID4gPj4+IGNvbmdlc3Rpb24NCj4gPiA+ID4+IGNv bnRyb2wvbG9zcyByZWNvdmVyeSBzdGF0ZSB0aGF0IGFsc28gbmVlZHMgdG8gYmUgcmVzZXQgZm9y IHRoZQ0KPiA+IG5ldyBwYXRoLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gR2l2ZW4gdGhhdCBlYWNo IG1pZ3JhdGlvbiByZXF1aXJlcyBhdCBsZWFzdCBvbmUgZXhjaGFuZ2Ugb2YNCj4gPiA+ID4+PiBw YWNrZXRzIGF0IHRoZQ0KPiA+ID4gPj4gYmVnaW5uaW5nIChhdCB0aGUgdmVyeSBsZWFzdCBmb3Ig YWRkcmVzcyB2YWxpZGF0aW9uIGZyb20gdGhlIHNpZGUNCj4gPiA+ID4+IG9mIHRoZSBlbmRwb2lu dCB0aGF0IGRpZG7igJl0IG1pZ3JhdGUpLCBpdCBzZWVtcyBsaWtlIHRoYXTigJlzIGFuDQo+ID4g PiA+PiBleGNlbGxlbnQgbW9tZW50IHRvIG1hcmsgdGhlIHBhY2tldHMgYW5kIHBlcmZvcm0gdGhl IEVDTiBjYXBhYmlsaXR5DQo+IGRldGVjdGlvbi4NCj4gPiA+ID4+IFRob3NlIHBhY2tldHMgYXJl IGFsc28gbGlrZWx5IHBhZGRlZCwgZXRjLiBzaW1pbGFyIHRvIGluaXRpYWwNCj4gPiA+ID4+IHBh Y2tldHMgc2luY2UgdGhleeKAmXJlIG9uIGEgcHJldmlvdXNseSB1bnVzZWQgbmV0d29yayBwYXRo Lg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gSSB0aGluayB0aGUgY3VycmVudCBwcm9wb3NlZCByZXF1 aXJlbWVudCBvZiBqdXN0IHVzaW5nIHRoZSDigJxmaXJzdOKAnQ0KPiA+ID4gPj4+IHBhY2tldHMN Cj4gPiA+ID4+IGFuZCBtYXJraW5nIHRob3NlIGlzIHN1ZmZpY2llbnQgKGFuZCBnb29kIHRvIGF2 b2lkIGFueQ0KPiA+ID4gPj4gcmVxdWlyZW1lbnQgYXMgdG8gd2hpY2ggZnJhbWVzIGFyZSBjb250 YWluZWQgaW4gdGhvc2UgcGFja2V0cyksDQo+ID4gPiA+PiBzaW5jZSB3ZSBhcmUgYWx3YXlzIGV4 Y2hhbmdpbmcgcGFja2V0cyBpbiBib3RoIGRpcmVjdGlvbnMNCj4gaW1tZWRpYXRlbHkgYWZ0ZXIg bWlncmF0aW9uLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gVGhpcyBoYXMgdGhlIGFkZGVkIGJlbmVm aXQgc3VjaCB0aGF0IGFueSBlbmRwb2ludCDigJxwcm9iaW5n4oCdDQo+ID4gPiA+Pj4gcG9zc2li bGUNCj4gPiA+ID4+IG5ldHdvcmsgcGF0aHMgY291bGQgaW5jbHVkZSB0aGUgYml0cyBuZWNlc3Nh cnkgdG8gZGV0ZWN0IEVDTg0KPiA+ID4gPj4gY2FwYWJpbGl0eSBvbiB0aGUgcGF0aCBiZWluZyBw cm9iZWQsIHNvIGl0IGNvdWxkIGV2ZW4ga25vdyBiZWZvcmUNCj4gPiA+ID4+IG1pZ3JhdGluZyB3 aGV0aGVyIG9yIG5vdCBpdCB3b3VsZCBiZSBhYmxlIHRvIHVzZSBFQ04gb24gdGhhdCBuZXcNCj4g PiBwYXRoLg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4gVGhhbmtzLA0KPiA+ID4gPj4+IEVyaWMNCj4g PiA+ID4+Pg0KPiA+ID4gPj4+DQo+ID4gPiA+Pj4NCj4gPiA+ID4+Pg0KPiA+ID4gPj4+IE9uIEZl YiAxLCAyMDE4LCBhdCAzOjA3IEFNLCBJbmdlbWFyIEpvaGFuc3NvbiBTDQo+ID4gPiA+PiA8aW5n ZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20NCj4gPiA8bWFpbHRvOmluZ2VtYXIucy5qb2hh bnNzb25AZXJpY3Nzb24uY29tPj4gd3JvdGU6DQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBIaQ0KPiA+ ID4gPj4+IEkgaGF2ZSB3cml0dGVuIHVwIGRpZmZlcmVudCBhc3BlY3RzIG9mIGNvbm5lY3Rpb24g bWlncmF0aW9uIGFuZA0KPiA+ID4gPj4+IGhvdyBpdA0KPiA+ID4gPj4gcGxheXMgd2l0aCBFQ04u DQo+ID4gPiA+Pj4gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VD Ti1pbi1RVUlDI3RyYW5zcG9ydA0KPiA+ID4gPj4+IC0NCj4gPiA+ID4+IGRyYWZ0LWNvbm5lY3Rp b24tbWlncmF0aW9uDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiBBIGNhdmVhdC4uIEkgYW0gYSBiaXQg dW5zdXJlIGFib3V0IHRoZSBkZWZpbml0aW9uIG9mIGNvbm5lY3Rpb24NCj4gPiBtaWdyYXRpb24N Cj4gPiA+IC4NCj4gPiA+ID4+IE15IGludGVycHJldGF0aW9uIGlzIHRoYXQgYSBjbGllbnQgbW92 ZXMgdG8gYSBuZXcgSVAgYWRkcmVzcyBkdWUNCj4gPiA+ID4+IHRvIGUuZy4gYSBOQVQgcmViaW5k IG9yIHN3aXRjaCBmcm9tIFdpRmkgdG8gY2VsbHVsYXIsIHJpZ2h0ID8uIElzDQo+ID4gPiA+PiBh IG5ldyBjb25uZWN0aW9uIGluc3RhbnRpYXRlZCBhdCBhIGNvbm5lY3Rpb24gbWlncmF0aW9uID8N Cj4gPiA+ID4+Pg0KPiA+ID4gPj4+IC9JbmdlbWFyDQo+ID4gPiA+Pj4NCj4gPiA+ID4+PiA9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4gPiA+Pj4gSW5nZW1hciBKb2hhbnNz b24gIE0uU2MuDQo+ID4gPiA+Pj4gTWFzdGVyIFJlc2VhcmNoZXINCj4gPiA+ID4+Pg0KPiA+ID4g Pj4+IEVyaWNzc29uIFJlc2VhcmNoDQo+ID4gPiA+Pj4gTmV0d29yayBQcm90b2NvbHMgJiBFMkUg UGVyZm9ybWFuY2UgTGFicmF0b3JpZWdyw6RuZCAxMQ0KPiA+ID4gPj4+IDk3MSAyOCwgTHVsZcOl LCBTd2VkZW4NCj4gPiA+ID4+PiBQaG9uZSArNDYtMTA3MSA0MzA0Mg0KPiA+ID4gPj4+IFNNUy9N TVMgKzQ2LTczIDA3OCAzMjg5DQo+ID4gPiA+Pj4gaW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb20NCj4gPiA8bWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0KPiA+ ID4gPj4+IHd3dy5lcmljc3Nvbi5jb20gPGh0dHA6Ly93d3cuZXJpY3Nzb24uY29tPg0KPiA+ID4g Pj4+DQo+ID4gPiA+Pj4gICAgICAgICAgICAgICAgIFlvdSBjYW4ndCBzdGFydCBhIGZpcmUgIFdv cnJ5aW5nICdib3V0IHlvdXINCj4gPiA+ID4+PiBsaXR0bGUgd29ybGQgZmFsbGluZyBhcGFydA0K PiA+ID4gPj4+ICAgICAgICAgICAgICAgQnJ1Y2UgU3ByaW5nc3RlZW4NCj4gPiA+ID4+PiA9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+ID4gPiA+DQo+ID4NCg0K From nobody Sun Feb 25 14:47:43 2018 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 2147E124D68 for ; Sun, 25 Feb 2018 14:47:42 -0800 (PST) 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 TsgqiX5ntG3z for ; Sun, 25 Feb 2018 14:47:40 -0800 (PST) Received: from mail-ot0-x230.google.com (mail-ot0-x230.google.com [IPv6:2607:f8b0:4003:c0f::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 A38E2124BAC for ; Sun, 25 Feb 2018 14:47:40 -0800 (PST) Received: by mail-ot0-x230.google.com with SMTP id y11so2483344otg.0 for ; Sun, 25 Feb 2018 14:47:40 -0800 (PST) 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=XPWFmEucyLsqHnSqOolfjShFliguL2ehv7GUS9OKDlg=; b=soWuFBMhOqT+ftTzBVPYh0GPnDPkXIV3+ZZSkUvJm8iPwdlNblMsL+OIyOaQfKuKsh HMurpL2H3C8dX6vTdjaB7yVl2tP8B4lFOFixaMciKDDIQ7OlzqqHsWn6+GlQyseTIv0v konxUpyGu1NNjVS64MxlizhYIxzJotelFAOuaILHq5vk3ZK2iZkGwA9+0kzZpkGlVRur 4jvDOXbPba2NtOWz0KGC1yQTMKrwvGwWFnv8cxOUzZdRatUPsm3ZkFKWjh9yMch/LLaf QsJE1O3F60k1wOgaNYZOJ8ZDkJi4kCzQCVp57awuZpt5X3cTA2QOpR9SSLh2boWhche2 IXZg== 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=XPWFmEucyLsqHnSqOolfjShFliguL2ehv7GUS9OKDlg=; b=nZ+1lcF5abwrGS747HTFFg/dCrr0H5wAM+UrbBcsywPFLCquypZdorqAbAVcKB9Hva vVMCJFbxpmTPevkVoN9IPjHdWICKN/vCbtUQeweeo8BuYU96sHB6XMgKV8hAGw2B/8iT W94zpvYro8Mk8aOluNlZ8oJtkLkXOf5wVaKra456MzbWEpgpB+u30yjXcCoOroedKWmc xOfcRgNRvOdBxpn7lxeV0KxLfB6qZ/WGaIMD68SjR8DkfOETWUchujRuEXW4gREcx1dv paTwKVa23pKI7A8JR6V9pK9U1bG0CRBpK6G3eKfTz1nbG8XrqXLa1b+ohJWTPeadEPPE uGag== X-Gm-Message-State: APf1xPCWgVO8OikfrEVRNNmMhUc/0MKBxCwR/emHJPAm5w/LcpQZGfC2 WMu/vJJp03FhgAgMQYktWIjUe7y0ZnOzALqxlLk= X-Google-Smtp-Source: AG47ELsipv9HWy8HbX30FNXhqZWfoSHWpoluTItWXmbh0ib8FUDmthZuvAfBreAuvUdNlaIJcFe3pXZwupWYf8Fb61A= X-Received: by 10.157.12.229 with SMTP id o34mr6642966otd.352.1519598859949; Sun, 25 Feb 2018 14:47:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Sun, 25 Feb 2018 14:47:39 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 26 Feb 2018 09:47:39 +1100 Message-ID: Subject: Re: Unrecoverable loss pattern To: Marten Seemann 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: Sun, 25 Feb 2018 22:47:42 -0000 I assume that this is the language you refer to: A server MUST process ACK frames in unprotected packets until the TLS handshake is reported as complete, or it receives an ACK frame in a protected packet that acknowledges all of its handshake messages. That talks about ACK frames, not Finished. On Mon, Feb 26, 2018 at 1:25 AM, Marten Seemann w= rote: > I=E2=80=99ve been playing around with QUIC loss recovery and in my tests = I=E2=80=99m > encountering one specific loss pattern which it seems impossible to recov= er > from. It's pretty rare, because there are a couple of conditions that mus= t > be fulfilled for it to occur: > > 1. Client and server perform the handshake, no packets are lost so far. > Client and server both arrive at the CONNECTED state, and the server > receives all ACKs for handshake packets it sent. The client receives ACKs > for all handshake packets except for the one containing the FINISHED mess= age > is lost (the packet containing the ACK for the FINISHED is lost). > 2. The client starts using 1-RTT keys, and it sends two packets: First, a > packet only containing an ACK, and then a packet containing stream data > (e.g. a request). The request packet is then lost. > 3. The server receives the ACK in the 1-RTT packet, and it stops acceptin= g > unencrypted packets according to 6.1.2 of the TLS draft. It doesn=E2=80= =99t generate > an ACK in response, since the packet only contained an ACK. > 4. The client is now missing acknowledgements for two packets: the > (unencrypted) packet containing the FINISHED message, and the (1-RTT) pac= ket > containing the request. It runs its loss recovery algorithm > (OnLossDetectionAlarm), and since there is one outstanding handshake pack= et, > it retransmit all outstanding handshake packets. > > Now we=E2=80=99ve run into a situation we can=E2=80=99t recover from: The= server won=E2=80=99t even > open packet sent as a retransmission (since these packets are unencrypted= , > and arrive after it already received a 1-RTT packet), and the client will > never retransmit the request packet. Furthermore, the server won't send a= ny > other packets, since it's just waiting for a request from the client. > > I think the solution for this is to also retransmit 1-RTT packets in a ca= se > like this. Can we just apply the normal retransmission rules in > OnLossDetectionAlarm, even if there are still handshake packets outstandi= ng? > > From nobody Sun Feb 25 16:59:00 2018 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 08D17127337 for ; Sun, 25 Feb 2018 16:58:59 -0800 (PST) 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, 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=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 HlLjmLsM2OsG for ; Sun, 25 Feb 2018 16:58:57 -0800 (PST) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 0C8AC127275 for ; Sun, 25 Feb 2018 16:58:57 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id n48so9437761uae.13 for ; Sun, 25 Feb 2018 16:58:56 -0800 (PST) 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=hVv/jm7o0BTqQhQdDiQ/INVhUyFsv8m5m9nkAckF8sU=; b=bHohZH2AfFSJUqQNhcR6Ecsb8EhWJ2h3dQOJ0wj9QFCsk9/wPIR1AKZ+lb4bvb1Asi MTxLCyIY2ItJt7EW9gHpEBTF0Tuz6cFVv+DYv40lAHhv87n5xjyNtfchwTXE2V+PPyge X5Aq4E5t5miWGKk6Vc7r3ctVsH+xTkx5K3lop3j+AuPiQCsXypwM0aoXnTJbsQreDerl Avn94EchcMaMOSqBKo0+QS0xQgv8qxZedxlOpnDNBByfzwLr4hfZ2OhfwQTmSOYK1pIJ 0u4oBvIqblhVr4ktV1zo9O3rYDnz0iV/6EVLv0+H7udbMjyo60POfIZsZDw52vLBWcFj qLDw== 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=hVv/jm7o0BTqQhQdDiQ/INVhUyFsv8m5m9nkAckF8sU=; b=aWgRU1UMxOd40L6pyGbGSPtr0S60ZoDyq7E/YhooCAOftUo+xJDZ2w9CTCYTiAkReg jV2zNlTUXipIvAzzcIcHwRPklNY43Pfs4pqDYp25b/NeKygxMMXdK/OfxMILrByXQxIQ Cm1LA1kWuLLBDj0Hbc6vAYtQbpqRPORJqKV1nO54tu01Du3th2F2JQ8RX8+AQkpRmNQd gFaD28wSxnLRYhQC2DLkkLK1E9HCCVc0mqkQmt81L6oKCCKRF9Rpen7yUT0yaezsVwmT kMoiYqvvXFNVvAV8D9hxfglQt0scnhhAgazdLrfxh1r33Ydn1f/Me0AH23nyvabMFhbU itdg== X-Gm-Message-State: APf1xPAmoDEVGHOFE/BfIIMaFOaz42O7/RNj1InnZYPFhVc4oSHKBXiz igV6tgP3q7SIJpBmm/IAdODqvoRD3BAmPUoBd04= X-Google-Smtp-Source: AG47ELsyrG8nzXO7pj3Rco7SfaGO85S6rJ7wCc4gqNI3s+ia/u3WDT3MQSFOOw1mT6LFs4dqGedjfu8Wfqmv31y2+KE= X-Received: by 10.176.23.238 with SMTP id p46mr7027434uaf.134.1519606735832; Sun, 25 Feb 2018 16:58:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Marten Seemann Date: Mon, 26 Feb 2018 00:58:45 +0000 Message-ID: Subject: Re: Unrecoverable loss pattern To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="f403043c6cb8b00ce205661303cf" 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, 26 Feb 2018 00:58:59 -0000 --f403043c6cb8b00ce205661303cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable @Nick: The server did get all handshake packets, please see 1. in my description. It's the server's ACK for the FINISHED message that is lost, not the FINISHED message itself. @Martin: Yes, it is, but I don't think there's anything problematic about the language in this paragraph. Since the server received ACKs for all the handshake messages it sent, it makes sense to not open unencrypted packets any more. On Mon, Feb 26, 2018 at 6:47 AM Martin Thomson wrote: > I assume that this is the language you refer to: > > A server MUST process ACK frames in unprotected packets > until the TLS handshake is reported as complete, or it receives an > ACK frame in a protected packet that acknowledges all of its > handshake messages. > > That talks about ACK frames, not Finished. > > On Mon, Feb 26, 2018 at 1:25 AM, Marten Seemann > wrote: > > I=E2=80=99ve been playing around with QUIC loss recovery and in my test= s I=E2=80=99m > > encountering one specific loss pattern which it seems impossible to > recover > > from. It's pretty rare, because there are a couple of conditions that > must > > be fulfilled for it to occur: > > > > 1. Client and server perform the handshake, no packets are lost so far. > > Client and server both arrive at the CONNECTED state, and the server > > receives all ACKs for handshake packets it sent. The client receives AC= Ks > > for all handshake packets except for the one containing the FINISHED > message > > is lost (the packet containing the ACK for the FINISHED is lost). > > 2. The client starts using 1-RTT keys, and it sends two packets: First,= a > > packet only containing an ACK, and then a packet containing stream data > > (e.g. a request). The request packet is then lost. > > 3. The server receives the ACK in the 1-RTT packet, and it stops > accepting > > unencrypted packets according to 6.1.2 of the TLS draft. It doesn=E2=80= =99t > generate > > an ACK in response, since the packet only contained an ACK. > > 4. The client is now missing acknowledgements for two packets: the > > (unencrypted) packet containing the FINISHED message, and the (1-RTT) > packet > > containing the request. It runs its loss recovery algorithm > > (OnLossDetectionAlarm), and since there is one outstanding handshake > packet, > > it retransmit all outstanding handshake packets. > > > > Now we=E2=80=99ve run into a situation we can=E2=80=99t recover from: T= he server won=E2=80=99t > even > > open packet sent as a retransmission (since these packets are > unencrypted, > > and arrive after it already received a 1-RTT packet), and the client wi= ll > > never retransmit the request packet. Furthermore, the server won't send > any > > other packets, since it's just waiting for a request from the client. > > > > I think the solution for this is to also retransmit 1-RTT packets in a > case > > like this. Can we just apply the normal retransmission rules in > > OnLossDetectionAlarm, even if there are still handshake packets > outstanding? > > > > > --f403043c6cb8b00ce205661303cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
@Nick: The server did get = all handshake packets, please see 1. in my description. It's the server= 's ACK for the FINISHED message that is lost, not the FINISHED message = itself.
@Martin: Yes, it is, but = I don't think there's anything problematic about the language in th= is paragraph. Since the server received ACKs for all the handshake messages= it sent, it makes sense to not open unencrypted packets any more.
On Mon, Feb 26, 2018 at= 6:47 AM Martin Thomson <martin.thomson@gmail.com> wrote:
I assume that this is the language you refer to:

=C2=A0 =C2=A0A server MUST process ACK frames in unprotected packets
=C2=A0 =C2=A0until the TLS handshake is reported as complete, or it receive= s an
=C2=A0 =C2=A0ACK frame in a protected packet that acknowledges all of its =C2=A0 =C2=A0handshake messages.

That talks about ACK frames, not Finished.

On Mon, Feb 26, 2018 at 1:25 AM, Marten Seemann <martenseemann@gmail.com> wrote= :
> I=E2=80=99ve been playing around with QUIC loss recovery and in my tes= ts I=E2=80=99m
> encountering one specific loss pattern which it seems impossible to re= cover
> from. It's pretty rare, because there are a couple of conditions t= hat must
> be fulfilled for it to occur:
>
> 1. Client and server perform the handshake, no packets are lost so far= .
> Client and server both arrive at the CONNECTED state, and the server > receives all ACKs for handshake packets it sent. The client receives A= CKs
> for all handshake packets except for the one containing the FINISHED m= essage
> is lost (the packet containing the ACK for the FINISHED is lost).
> 2. The client starts using 1-RTT keys, and it sends two packets: First= , a
> packet only containing an ACK, and then a packet containing stream dat= a
> (e.g. a request). The request packet is then lost.
> 3. The server receives the ACK in the 1-RTT packet, and it stops accep= ting
> unencrypted packets according to 6.1.2 of the TLS draft. It doesn=E2= =80=99t generate
> an ACK in response, since the packet only contained an ACK.
> 4. The client is now missing acknowledgements for two packets: the
> (unencrypted) packet containing the FINISHED message, and the (1-RTT) = packet
> containing the request. It runs its loss recovery algorithm
> (OnLossDetectionAlarm), and since there is one outstanding handshake p= acket,
> it retransmit all outstanding handshake packets.
>
> Now we=E2=80=99ve run into a situation we can=E2=80=99t recover from: = The server won=E2=80=99t even
> open packet sent as a retransmission (since these packets are unencryp= ted,
> and arrive after it already received a 1-RTT packet), and the client w= ill
> never retransmit the request packet. Furthermore, the server won't= send any
> other packets, since it's just waiting for a request from the clie= nt.
>
> I think the solution for this is to also retransmit 1-RTT packets in a= case
> like this. Can we just apply the normal retransmission rules in
> OnLossDetectionAlarm, even if there are still handshake packets outsta= nding?
>
>
--f403043c6cb8b00ce205661303cf-- From nobody Sun Feb 25 17:20:14 2018 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 3096E127342 for ; Sun, 25 Feb 2018 17:20:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dKJxTeDkeXVZ for ; Sun, 25 Feb 2018 17:20:10 -0800 (PST) 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 7034F127275 for ; Sun, 25 Feb 2018 17:20:09 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eq7SX-0003bC-DW for quic@ietf.org; Mon, 26 Feb 2018 02:20:06 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eq7SP-000834-Rt for quic@ietf.org; Sun, 25 Feb 2018 20:20:01 -0500 Received: (qmail 14928 invoked from network); 26 Feb 2018 01:19:55 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.158]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Feb 2018 01:19:55 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> Date: Sun, 25 Feb 2018 17:19:52 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DECB6CD3F32DDBD8B2F0FD86" Content-Language: en-US Subject: Re: Unrecoverable loss pattern X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ged1JwBGrDWcAnK04Awqb1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViy65yv2CxhMjFzyLlDHN6887i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBiuj1YIZWyGteeTEbAD/lb/vRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0ClKHhIXfDbmhz3DoftFSAfVIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM81CaOu2xwDQxDsUgSvK+nII1IRruUYLOgUnyoTu5lV X1MKVprlQYwN+KHznEQNFP39x9CAjlzRZaienerOS9C0xK1xc9LrTkd4h33gwBLx3gfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4Da Q6mrvkz1ms5n2i5GFAoJSGG/BQd7r2NVEaNhWos5pvROZI5izAILJU7ATFpkuBoccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtkqah8tX/yBccUywZq2FP6SBi6owqeb+h1kbxIVWYdC7N1zg 8T9ahw4hquQDupK1jleqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g== 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: Mon, 26 Feb 2018 01:20:12 -0000 This is a multi-part message in MIME format. --------------DECB6CD3F32DDBD8B2F0FD86 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/25/2018 4:58 PM, Marten Seemann wrote: > @Nick: The server did get all handshake packets, please see 1. in my > description. It's the server's ACK for the FINISHED message that is > lost, not the FINISHED message itself. > @Martin: Yes, it is, but I don't think there's anything problematic > about the language in this paragraph. Since the server received ACKs > for all the handshake messages it sent, it makes sense to not open > unencrypted packets any more. See https://github.com/quicwg/base-drafts/issues/829 and https://github.com/quicwg/base-drafts/issues/1018 for=C2=A0 discussion of= related issues. Picoquic manages these issues by handling "ACK of ACK". Normally, it will send ACK frames that acknowledge all packets received so far, potentially with a long list of ACK ranges. So if an ACK is lost, the next ACK will repeat the information that it carried. The list is only pruned when an "ACK of ACK" is received. In your example, if the FINISHED message is not acknowledged, the client will retransmit the stream zero data containing the FINISHED message in a new Handshake packet. The server will have to send an ACK of that packet, and the ACK range will also cover the previous packet. There is no problem for sending that ACK. You cannot acknowledge a protected packet in a clear text message, but nothing prevents you from acknowledging clear text packets in protected messages. -- Christian Huitema --------------DECB6CD3F32DDBD8B2F0FD86 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 2/25/2018 4:58 PM, Marten Seemann wrote:

@Nick: The server did get all handshake packets, please see 1. in my description. It's the server's ACK for the FINISHED message that is lost, not the FINISHED message itself.
@Martin: Yes, it is, but I don't think there's anything problematic about the language in this paragraph. Since the server received ACKs for all the handshake messages it sent, it makes sense to not open unencrypted packets any more.

See https://github.com/quicwg/base-drafts/issues/829 and https://github.com/quicwg/base-drafts/issues/1018 for  discussion of related issues.

Picoquic manages these issues by handling "ACK of ACK". Normally, it will send ACK frames that acknowledge all packets received so far, potentially with a long list of ACK ranges. So if an ACK is lost, the next ACK will repeat the information that it carried. The list is only pruned when an "ACK of ACK" is received.

In your example, if the FINISHED message is not acknowledged, the client will retransmit the stream zero data containing the FINISHED message in a new Handshake packet. The server will have to send an ACK of that packet, and the ACK range will also cover the previous packet. There is no problem for sending that ACK. You cannot acknowledge a protected packet in a clear text message, but nothing prevents you from acknowledging clear text packets in protected messages.

-- Christian Huitema
--------------DECB6CD3F32DDBD8B2F0FD86-- From nobody Sun Feb 25 17:31:07 2018 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 83719127275 for ; Sun, 25 Feb 2018 17:31:05 -0800 (PST) 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 fak7t_x5aqRM for ; Sun, 25 Feb 2018 17:31:03 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 4C9051271FD for ; Sun, 25 Feb 2018 17:31:03 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id k187so8830809vke.12 for ; Sun, 25 Feb 2018 17:31:03 -0800 (PST) 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=HL3XhoyVHJ/eTKRAqXBsF2yCh+sEifHNIkFMGgjYU6g=; b=EFoiHFVJNLf1fljBnGEEymI/vkZpyM8AiRS0B8mgGPFxzhMi6vvzaYqXBujg431g/S y8oMoUP23dRGNFVLvKhx987qbG2gLnG1DWRwk8BllobLOhvnW71dhx9rKs1Bhyb6KhiG iqY+eMuVtQ3iq/8mlvDEXeTYRnrLRVu+89OBdaCpISY9PBNg9gwr3/G3W4Yjb0Zlrcp0 F/0BeFCoEwfkjLDS2tk/n518jyS+VFM/qN/Q/sLjgfVELL2Z6khkCj0jad5MSIlJt19t 1npQHrlm+lQsT7MW5X62Z6q+cG0tzuZaZZokYEkl200qqrjC30Ox/WNC2hs/V008nEr8 LZMQ== 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=HL3XhoyVHJ/eTKRAqXBsF2yCh+sEifHNIkFMGgjYU6g=; b=eVVQlBlcz8U9W9QkWzcgAm2SqgFuWh4vg3vZJOoMmYgdK+yvOp4ya/9R+IrZVQciB+ zYsQAPZg18FY49wdqmOm1SCLUtaODapCHU9B+mHamn//LGO0Y+N3aWZsHmjly6xlhisg Ql5bdjynQnRM9zV+mU+siNZm71vFAO52FtleDbTtyrhiFZ+yFcJ1Q3Nx8l+QIrwWooVJ T7jbSbwQVgsXhhGTFTxwFfc9YsQuGAPDSKN3hF3slWi7WIMpER8+t28YnLSwYXQAVXNh F0Ums5UBP9rdS+q+jQcFNYiPtGqBhnJwepIL/vuN4xt9cx83nHR83H1TYXiNgk9Q7NGQ BZCw== X-Gm-Message-State: APf1xPAdRL50wgDqf8n51Eg0pp2Pk9CeZ8zrTpK1pb7JSSRXmYrYgQ9c wNmvWdnfH6OO/zvkiOYRVlV/I5ivcpZn1cdXRtQ= X-Google-Smtp-Source: AG47ELu5cAFcLDtL+acghDZBf1imwSy9Cxogdzja/I2474PPD9x0VPD3DFxfq0v1szxjHRrnfC69hmyWCc3EzJDFKyg= X-Received: by 10.31.215.65 with SMTP id o62mr6427vkg.152.1519608661985; Sun, 25 Feb 2018 17:31:01 -0800 (PST) MIME-Version: 1.0 References: <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> In-Reply-To: <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> From: Marten Seemann Date: Mon, 26 Feb 2018 01:30:51 +0000 Message-ID: Subject: Re: Unrecoverable loss pattern To: Christian Huitema Cc: quic@ietf.org Content-Type: multipart/alternative; boundary="94eb2c07d90a7ecee405661376f1" 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, 26 Feb 2018 01:31:05 -0000 --94eb2c07d90a7ecee405661376f1 Content-Type: text/plain; charset="UTF-8" The problem is that the server will not open the unencrypted packet containing the retransmission of the FINISHED, since it already completed the handshake AND received ACKs for all its handshake packets. We *could* fix this problem by making the server accept unencrypted packets indefinitely, but this comes with a whole range of problems of man-on-the-side attacks. On Mon, Feb 26, 2018 at 9:20 AM Christian Huitema wrote: > On 2/25/2018 4:58 PM, Marten Seemann wrote: > > @Nick: The server did get all handshake packets, please see 1. in my > description. It's the server's ACK for the FINISHED message that is lost, > not the FINISHED message itself. > @Martin: Yes, it is, but I don't think there's anything problematic about > the language in this paragraph. Since the server received ACKs for all the > handshake messages it sent, it makes sense to not open unencrypted packets > any more. > > > See https://github.com/quicwg/base-drafts/issues/829 and > https://github.com/quicwg/base-drafts/issues/1018 for discussion of > related issues. > > Picoquic manages these issues by handling "ACK of ACK". Normally, it will > send ACK frames that acknowledge all packets received so far, potentially > with a long list of ACK ranges. So if an ACK is lost, the next ACK will > repeat the information that it carried. The list is only pruned when an > "ACK of ACK" is received. > > In your example, if the FINISHED message is not acknowledged, the client > will retransmit the stream zero data containing the FINISHED message in a > new Handshake packet. The server will have to send an ACK of that packet, > and the ACK range will also cover the previous packet. There is no problem > for sending that ACK. You cannot acknowledge a protected packet in a clear > text message, but nothing prevents you from acknowledging clear text > packets in protected messages. > > > -- Christian Huitema > --94eb2c07d90a7ecee405661376f1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The problem is that the server will not open the unencrypt= ed packet containing the retransmission of the FINISHED, since it already c= ompleted the handshake AND received ACKs for all its handshake packets. We = *could* fix this problem by making the server accept unencrypted packets in= definitely, but this comes with a whole range of problems of man-on-the-sid= e attacks.

On Mon, Feb= 26, 2018 at 9:20 AM Christian Huitema <huitema@huitema.net> wrote:

On 2/25/2018 4:58 PM, Marten Seemann wrote:

@Nick: The se= rver did get all handshake packets, please see 1. in my description. It's the server's= ACK for the FINISHED message that is lost, not the FINISHED message itself.
@Martin: Yes, it is, but I don't think there's anything problematic about the langua= ge in this paragraph. Since the server received ACKs for all the handshake messages it sent, it makes sense to not open unencrypted packets any more.

See https://gi= thub.com/quicwg/base-drafts/issues/829 and https://githu= b.com/quicwg/base-drafts/issues/1018 for=C2=A0 discussion of related issues.

Picoquic manages these issues by handling "ACK of ACK". Norma= lly, it will send ACK frames that acknowledge all packets received so far, potentially with a long list of ACK ranges. So if an ACK is lost, the next ACK will repeat the information that it carried. The list is only pruned when an "ACK of ACK" is received.

In your example, if the FINISHED message is not acknowledged, the client will retransmit the stream zero data containing the FINISHED message in a new Handshake packet. The server will have to send an ACK of that packet, and the ACK range will also cover the previous packet. There is no problem for sending that ACK. You cannot acknowledge a protected packet in a clear text message, but nothing prevents you from acknowledging clear text packets in protected messages.


-- Christian Huitema
--94eb2c07d90a7ecee405661376f1-- From nobody Sun Feb 25 18:07:51 2018 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 96017127342 for ; Sun, 25 Feb 2018 18:07:49 -0800 (PST) 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 al0BoSjzirAA for ; Sun, 25 Feb 2018 18:07:47 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 AE96A127275 for ; Sun, 25 Feb 2018 18:07:47 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id m22so2766373otf.10 for ; Sun, 25 Feb 2018 18:07:47 -0800 (PST) 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=lAm0oN6JolVpyeXe0AIugoleDFFzBolSgW9Oj+2/ELQ=; b=r6D4al14YTkgcsE9ns21/zqR/eLJ2Z1tOt5zPPQy2z7Kfx0bytVoyMPqORdPW2IPOE 45dXzkSftCqxVCs5V4c1xGDOf47QAbKyZ/trsxPxSb+F2Zkz+zYRiRilFNRwg9A9Stm9 BgCD0EsLkaEANxwPP6Xu62VjGicpqoNlisW9ALJRU4HFolsYOTSNE4bvD89uGunGkmYC 5eb1q55evt5bNdT2GFJff8ZKen1DclUX6ym8VWDQb+bpFoWIsWLFhBI9SO3EXHpEZuE5 cBugf7lqgx/cBM7DCpSG2i65sib3wECAbqZufNSiJcBda8qED9sthxhPQ6iVCMPgz3QW wbPQ== 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=lAm0oN6JolVpyeXe0AIugoleDFFzBolSgW9Oj+2/ELQ=; b=QTBdimNosiWzm5Lk9ALaLQpp393jSMyHGmXaL7SjjMU/JWscUF9kmvsZ54ixCmPTLi bWYX2iZ9vnZmmoOiRR5slf+mG1/72wo6leNcJbfE8H/O+xbvXvU9BuOdIV53V2U8JUSS VcJv1FWy0J29LIQbnzDMPidpqWVLAy6NO9HjLAM5BDA9ClLDVSdKphJWGMP+v8s3RHiP uSDLEmJRX+YdEsrY3rykBurvHmneGebqd3ejZkK+Cpc3FTAnISrr+SltLesJg+065Ruv 4yjUgdWvv55v1+VN3SpLaOoM/PyUt7oziS+iL5knkZh3kOtSZEFJrDrMTNb2arWrr7Dj tCXg== X-Gm-Message-State: APf1xPCGthMGwdAxDb1BMDU0wb5w0tiJP7F0V916ew2m/RS4gjWcXQPn C87iN0HdjBnwbFvMpt40NgmlZhTI4jVn4NUWjKQ= X-Google-Smtp-Source: AH8x226SfO78dTaEGrIqvC/cvQB/CoH9VMyOIvc0Ms3vwcFygLWdOe3GbBJiBZcrYRTfUno4xL/sh7/44gZfxNS/Hvw= X-Received: by 10.157.53.10 with SMTP id o10mr6260609otc.283.1519610866777; Sun, 25 Feb 2018 18:07:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Sun, 25 Feb 2018 18:07:46 -0800 (PST) In-Reply-To: References: <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> From: Martin Thomson Date: Mon, 26 Feb 2018 13:07:46 +1100 Message-ID: Subject: Re: Unrecoverable loss pattern To: Marten Seemann Cc: Christian Huitema , 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: Mon, 26 Feb 2018 02:07:49 -0000 Yes, this is a real issue. It arises because the packet that would normally trigger loss detection for the request packet (the ACK for the Finished) never gets sent because the server believes the client to be quiescent. The server believes that because it discards the cleartext packets that it receives. Client sends ...., Finished, ACK, Y. Then Y is lost. Server acknowledges up to Finished, but this acknowledgment is lost. Client detects loss of the Finished. It does this on a timer, because if the server was sending data, the client would receive the ACK for the Finished and things would work out. If the handshake wasn't special, the client would send Finished again using the 1-RTT keys, and this wouldn't be a problem. But in this case it resends Finished in a new packet and the server throws that away. The client never does TLP or RTO for Y. See for that algorithm. The general case is a little worrying: as long as the Finished is outstanding, the client will not repair loss from other packets (see ). You might consider this failing to be a result of trying to compose the various timers into a single alarm. This wouldn't be a problem if the RTO and TLP for ordinary packets proceeded as normal. One extra timer during the handshake isn't that much additional burden. But maybe there is a more elegant solution. On Mon, Feb 26, 2018 at 12:30 PM, Marten Seemann wrote: > The problem is that the server will not open the unencrypted packet > containing the retransmission of the FINISHED, since it already completed > the handshake AND received ACKs for all its handshake packets. We *could* > fix this problem by making the server accept unencrypted packets > indefinitely, but this comes with a whole range of problems of > man-on-the-side attacks. > > On Mon, Feb 26, 2018 at 9:20 AM Christian Huitema > wrote: >> >> On 2/25/2018 4:58 PM, Marten Seemann wrote: >> >> @Nick: The server did get all handshake packets, please see 1. in my >> description. It's the server's ACK for the FINISHED message that is lost, >> not the FINISHED message itself. >> @Martin: Yes, it is, but I don't think there's anything problematic about >> the language in this paragraph. Since the server received ACKs for all the >> handshake messages it sent, it makes sense to not open unencrypted packets >> any more. >> >> >> See https://github.com/quicwg/base-drafts/issues/829 and >> https://github.com/quicwg/base-drafts/issues/1018 for discussion of related >> issues. >> >> Picoquic manages these issues by handling "ACK of ACK". Normally, it will >> send ACK frames that acknowledge all packets received so far, potentially >> with a long list of ACK ranges. So if an ACK is lost, the next ACK will >> repeat the information that it carried. The list is only pruned when an "ACK >> of ACK" is received. >> >> In your example, if the FINISHED message is not acknowledged, the client >> will retransmit the stream zero data containing the FINISHED message in a >> new Handshake packet. The server will have to send an ACK of that packet, >> and the ACK range will also cover the previous packet. There is no problem >> for sending that ACK. You cannot acknowledge a protected packet in a clear >> text message, but nothing prevents you from acknowledging clear text packets >> in protected messages. >> >> >> -- Christian Huitema From nobody Sun Feb 25 23:29:01 2018 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 DDD95120721 for ; Sun, 25 Feb 2018 23:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tv6v43KPu-Rn for ; Sun, 25 Feb 2018 23:28:58 -0800 (PST) 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 0688F1201F2 for ; Sun, 25 Feb 2018 23:28:58 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eqDDT-0003Zq-6A for quic@ietf.org; Mon, 26 Feb 2018 08:28:56 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eqDDM-0004Me-Ls for quic@ietf.org; Mon, 26 Feb 2018 02:28:53 -0500 Received: (qmail 9725 invoked from network); 26 Feb 2018 07:28:45 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.158]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Feb 2018 07:28:45 -0000 To: Martin Thomson , Marten Seemann Cc: QUIC WG References: <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> From: Christian Huitema Message-ID: Date: Sun, 25 Feb 2018 23:28:43 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Unrecoverable loss pattern X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5gJNvufdQwOoW5kBtSJ7JOB602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVirkV7J0Wi+NzbTtnelSqDO87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBiuj1YIZWyGteeTEbAD/lb/vRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0ClKHhIXfDbmhz3DoftFSAfVIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM81CaOu2xwDQxDsUgSvK+nII1IRruUYLOgUnyoTu5lV X1MKVprlQYwN+KHznEQNFP2RJjTwYR9fdVd4GNOGh/gxw/SqpkOks8V3qTQf2nUD3wfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4Cp b4mi9wLRe0dO1qfOpsb8SGG/BQd7r2NVEaNhWos5pmr/mO1KyGAqOt7Rk+SRRRYccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtqMfDzEXpr5sTuNVuzYBPE2Bi6owqeb+h1kbxIVWYdC7uVGB tJ1DsK23UcLYdhI56Feqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g== 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: Mon, 26 Feb 2018 07:29:00 -0000 On 2/25/2018 6:07 PM, Martin Thomson wrote: > Yes, this is a real issue. It arises because the packet that would > normally trigger loss detection for the request packet (the ACK for > the Finished) never gets sent because the server believes the client > to be quiescent. The server believes that because it discards the > cleartext packets that it receives. We debated that with issue #1018 (https://github.com/quicwg/base-drafts/issues/1018). At the time, we saw two options: 1) Allow the "finished" message to be transmitted in 1-RTT protected packets. This was nixed because it seems to interfere with the formal proofs of TLS 1.3. 2) Allow the server to accept retransmission of handshake packets intermixed with 1-RTT protected packet. Clearly, this open a DOS attack, as third parties can now inject such packets, consume packet numbers, and possibly cause good data to be dropped. I was not aware that the spec pushed a third alternative, to mandate that the server to just drop handshake packets after receiving the first copy of the finished message. As Marten says, that puts the client in a bad position if the first ACK is lost and the server is silent after that= =2E The solution might be to send a "Finished received" frame in the protected data flow, and require an ACK for that frame. That way, the problem would really be solved. -- Christian Huitema From nobody Sun Feb 25 23:33:53 2018 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 496AE12D0C3 for ; Sun, 25 Feb 2018 23:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 aHmFojBg9BUs for ; Sun, 25 Feb 2018 23:33:50 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 063CE1201F2 for ; Sun, 25 Feb 2018 23:33:50 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id k79so6964510ita.2 for ; Sun, 25 Feb 2018 23:33:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=3R9BkG5vKynbVM1+NJTHmz6L7ONRJ+KPP8f5UbZAteo=; b=tuREYK2xEk/7uQfYOa7gz5FgqajnOdI8CNYmiVB5W95fxzaLqA7wOXVeGPKYcETRtl lpx+ggW/H/Xd75aPQxfG2HXkKtezRWpP3ibYDjmZ9ucXrS60NqZHY3h+O58C5WlsOKuA CFi3vKZ0tpJ51z2VoqAsmDbQb4zEwmkawBx0twAtYiX/LegbQReKUjP7xLY9iDjqBoW3 un+gmg6jfGZptvlHnhy59ZeXogmWHNYVVrLCsG2vVBCJqkEP1ixobliWbHvgRB+ox19j G7koLh9ZQCM1LxtmkYLMT3id6MNkC3GOKPld0HvCdIM6aPpfROIwVKdxftMvPRnLFPYo reuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=3R9BkG5vKynbVM1+NJTHmz6L7ONRJ+KPP8f5UbZAteo=; b=PVOX0aO0ovCIEX4FHi9ac2mLUqRqKRUXetrbv8lyPTKxZcjCKKbIgk9frGzSap0hVV hQoejjVdfT9yNrCxNE0+znysqa+xJLvH8iWnKKndO9z0bT/mZsdoGKBMSop94ZWyvVp/ h4qhhvSIf5fr+qWU1Mz7+1BHaxaCQHf8UEnOW6YVP/Y51DQmxboOSnq4jiOS+i18XzBg j6FR2y9WNTtepx20S3sdWvkpuQVQULE8sJkkL3EXJ8Ni5M0BJ3V45AnM4qP6R5eVeHsr abjEZjiP+tbKy+bwhrDqWy0depdsWkg6v294leqsREuUyexnBJIaeSFyH/iSi83XNXxl e1ZQ== X-Gm-Message-State: APf1xPBVGWI6QU1UYGRq1FTCJs79E0BzoCvdQ0jA51P4Iq2Arn7azYio wabMs35iVPj1R5ZTJHEQUpcbzchHS3WKNZ8qcUg= X-Google-Smtp-Source: AG47ELsmDtL5PL+7h2plFyUhR1XYSzugzueKBK7pZ+H68PAB+chLXxI8NHSPCw7bTjzZmvMTZBhJOxGJpM+ihrzlf7U= X-Received: by 10.36.222.134 with SMTP id d128mr12205949itg.150.1519630429412; Sun, 25 Feb 2018 23:33:49 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 26 Feb 2018 02:33:48 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 26 Feb 2018 02:33:48 -0500 Message-ID: Subject: Re: Unrecoverable loss pattern To: Martin Thomson , Christian Huitema , Marten Seemann Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c05d0c2ef62fe05661887ee" 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, 26 Feb 2018 07:33:51 -0000 --94eb2c05d0c2ef62fe05661887ee Content-Type: text/plain; charset="UTF-8" > The solution might be to send a "Finished received" frame in the protected data flow, and require an ACK for that frame. That way, the problem would really be solved. That is sort of a handshake of the handshake, but I like the idea. Could that somehow extend to 0-RTT as a more general concept? --94eb2c05d0c2ef62fe05661887ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = > The soluti= on might be to send a "Finished received" frame in the=C2=A0
protected data flow, and require an ACK for that frame. That way,= the=C2=A0
problem would really be solved.=C2=A0

That is sort of a handshake of the handshake, but I like th= e idea.
Could that somehow extend to 0-R= TT as a more general concept?
--94eb2c05d0c2ef62fe05661887ee-- From nobody Sun Feb 25 23:37:01 2018 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 146DD12D0C3 for ; Sun, 25 Feb 2018 23:37:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 J251SNgzTxn7 for ; Sun, 25 Feb 2018 23:36:58 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (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 8B481120721 for ; Sun, 25 Feb 2018 23:36:58 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id h23so5593090iob.11 for ; Sun, 25 Feb 2018 23:36:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=lSNJCvLAvkmMsxX1L6lCT8EWG2SPn3ldHi4fLGD+TLE=; b=YTNwFUiuPPjLYZiOTTqfF0+b5KvToB0iAATtQPEpqU2suRCkm6RDj8s/2oN56sRzN3 FpwdBqz6/fl4wBwBtvc8MXJem0B73sP6G4ln9pXx+8IylChVHpY9lLqBKcSOW9367KXk Ee9mVDbR9U+ue2wqphD6qmmURX/7QYA9ML57RaIFHvGMsOl0hBZwh37wgHS0G6h4DLV1 +j5KrJ4dFlLkX6OJJdYvVUoa0emJXgiZgcmnIIabxc1fPTIm1qKInhQMeekT6PRphcCc TAM1nuwn1kAQfEbSAVgMnYUZo5IDC8Wjd1Ws6mtkRWz5UMjDC74MDxwRm+0v1GZ16YXn Y5Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=lSNJCvLAvkmMsxX1L6lCT8EWG2SPn3ldHi4fLGD+TLE=; b=Cv5E3uhy+no/JMKxcVoZYCq0i1f53pj5fICkzw28CJ93o48Y8e0hGZoyovTUh0XWSl ffPMiM7q/vtlJjvvFF9KNspQJWyaVu9xexVSL0ws9btmB4rLnXnxAxECXae8FThZcfsD WviRlZGpc4XvjLGS/92CTk8FH5QtzH4qtueqYKk5evCTg4ofWBVeQkAtcFAU4wvx7SuX +Xw4Nu5ALmey0EWgidzD2d7EdeiTpakWG56xvaW2PWGZ/Ap+bcKIUln/A+XUP+8y5YUZ rQh7uNUNtrg6x9mmgHLWh53TtcxwDUdSVttyuPBglt4sWPhBX9aFgb0725nL5dUL/ehW Ws9w== X-Gm-Message-State: APf1xPC4KMfsIxcKYe169vrLI6i1xoLoQsbs+pDv0/J9L53j6zn4BOiM H8EaqhqEzWAMu+n79q7tJtOhR0rGdwzYH/+rdcU= X-Google-Smtp-Source: AG47ELuNFwr4I6HiI6nE4GdB1NSMgONeuGjtg6YcdqGw1FkjaQJDVCZuDBmlQhYBa8AiG/Aw8up12Rp55YB2jc/kY0Q= X-Received: by 10.107.17.20 with SMTP id z20mr10995909ioi.274.1519630617801; Sun, 25 Feb 2018 23:36:57 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 26 Feb 2018 02:36:57 -0500 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 26 Feb 2018 02:36:57 -0500 Message-ID: Subject: Re: Unrecoverable loss pattern To: Martin Thomson , Christian Huitema , Marten Seemann Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a113eda8a29fc4f0566189312" 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, 26 Feb 2018 07:37:00 -0000 --001a113eda8a29fc4f0566189312 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Another thing: The concept might be more general handover in path-migration, multi-path, visible path specific sequence numbers, and rekeying. Rather than having 7 or so different constructs, there might be an underlying principle called handoff? Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 26 February 2018 at 08.33.48, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelf= j@gmail.com) wrote: > The solution might be to send a "Finished received" frame in the protected data flow, and require an ACK for that frame. That way, the problem would really be solved. That is sort of a handshake of the handshake, but I like the idea. Could that somehow extend to 0-RTT as a more general concept? --001a113eda8a29fc4f0566189312 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Another thing:
=

The concept might be more= general handover in path-migration, multi-path, visible path specific sequ= ence numbers, and rekeying.
Rather than having 7 or so different constructs, there might= be an underlying principle called handoff?

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 26 February 2018 at 08.33.48, Mikkel= Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote:

> The solution might be to send a "Finished received" frame in the=C2=A0
protected data flow, and require an ACK for that frame. That way, the=C2=A0
problem would really be solved.=C2=A0

That is sort of a handshake of the handshake, but I like the idea.
Could that somehow extend to 0-RTT as a more general concept?
--001a113eda8a29fc4f0566189312-- From nobody Mon Feb 26 00:51:49 2018 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 2B26712D777 for ; Mon, 26 Feb 2018 00:51:41 -0800 (PST) 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 JLOEA5v_6FSf for ; Mon, 26 Feb 2018 00:51:38 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 893CE1273B1 for ; Mon, 26 Feb 2018 00:51:38 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id n74so12490863ota.1 for ; Mon, 26 Feb 2018 00:51:38 -0800 (PST) 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=ZHGiY/waMgn0THSDhZiE6hWNRwrrEBpaZqmFHefppuk=; b=SLoJFYM2VaPOGiWkbeN4ytn5XpOY2lLGsAzTsZG46OK0PpxMaZRqcSGPzkS61/QwbP hxY9q4U/KQXsaEu0/0KzFdDh8PE0nn8d3ZJ03n8hwV3J2bdhnGzFKZ2nTmmD5P48XFm9 aUbp17WCBvPxYcp7RFdBLjgNp0TXKGZ3iCf7D0JcE9M3nj6RJbV4Kf7hkbOAVwFgOahr GiFsPb28phH0Y2JsffEYaVbjaxjjDlUA63TKnm3UDtq2HMpFLWuAI8GectZ4LsILwGei Sme152dZDExmCGIfa0v0KR0Lit/4ptOfqsFHAbTvGR5QkYiYqNH+OEsWF6dsNRPuRdrz MTNw== 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=ZHGiY/waMgn0THSDhZiE6hWNRwrrEBpaZqmFHefppuk=; b=dmR21wr5RhWz2BfnL1Kv0VTUCM3j4nlIyj/uxJ7P//Y9Hi0JLSfQOQFRFbJM1DMwg4 kfC2/7vDh/XbQNTFe2cNvPMlB/LCNiEoo7IGQlkCaKseGXMwWDVqOBZG2fYt5ZIcT8W9 RWCIYQDbc7pK16sPFd1RDGk3PF2G6MLLaxDtejW3TVYIc3KjnlN2+yabMwAM/ZE+kkwh vRi7XG7LS3bwXAwGPbFOCcPrIlwWkh8cgD6d1jZzdzcSTiES19QDk2HvcYnMo2YOL/hK uYU8s7HTVf6gHP2CJlp9cL1jCWWsEDey6tzAjHB3FBjCcz5YNKpO9WtA7/+SAFF1+Wd3 bwdQ== X-Gm-Message-State: APf1xPDpu8T5iqP61GU/vudt5Cno9WKeMKsmS2dGIP3r50Dv2w1WsWd3 H9jHVt+qjCQR6lAihfHAUy1f3ZHUx/3k0El8U7Y= X-Google-Smtp-Source: AG47ELuLwBdqVlgYdmfVeukYYpw3KAxwk9ar+u29Lt/LwIvwhBkBPj9UeDhgogNFZtU7Xlv8dufhH/zXJHTDxGnt91k= X-Received: by 10.157.73.3 with SMTP id e3mr7407901otf.15.1519635097779; Mon, 26 Feb 2018 00:51:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Mon, 26 Feb 2018 00:51:37 -0800 (PST) In-Reply-To: References: <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> From: Martin Thomson Date: Mon, 26 Feb 2018 19:51:37 +1100 Message-ID: Subject: Re: Unrecoverable loss pattern To: Christian Huitema Cc: Marten Seemann , 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: Mon, 26 Feb 2018 08:51:41 -0000 The issue in #1018 (as I understood it) was the fact that Finished could be protected (and thereby authenticated), but it was not. Not having it protected makes it vulnerable to all sorts of attack. This is different, it's not an attack, it's just an unfortunate interaction between the loss recovery algorithms and the TLS mapping. Other than running multiple timers as I suggested, you could also force the server to respond to cleartext packets with a repeat of its ACK. It doesn't even have to look at what it received, it just plays out the last ACK. That's what we do in our DTLS 1.3 implementation. It works. The trick there is that once you have an ACK for the ACKs that acknowledge the handshake you stop the special behaviour. On Mon, Feb 26, 2018 at 6:28 PM, Christian Huitema wrote: > On 2/25/2018 6:07 PM, Martin Thomson wrote: > >> Yes, this is a real issue. It arises because the packet that would >> normally trigger loss detection for the request packet (the ACK for >> the Finished) never gets sent because the server believes the client >> to be quiescent. The server believes that because it discards the >> cleartext packets that it receives. > We debated that with issue #1018 > (https://github.com/quicwg/base-drafts/issues/1018). At the time, we saw > two options: > > 1) Allow the "finished" message to be transmitted in 1-RTT protected > packets. This was nixed because it seems to interfere with the formal > proofs of TLS 1.3. > > 2) Allow the server to accept retransmission of handshake packets > intermixed with 1-RTT protected packet. Clearly, this open a DOS attack, > as third parties can now inject such packets, consume packet numbers, > and possibly cause good data to be dropped. > > I was not aware that the spec pushed a third alternative, to mandate > that the server to just drop handshake packets after receiving the first > copy of the finished message. As Marten says, that puts the client in a > bad position if the first ACK is lost and the server is silent after that. > > The solution might be to send a "Finished received" frame in the > protected data flow, and require an ACK for that frame. That way, the > problem would really be solved. > > -- Christian Huitema > > > > > > > > From nobody Mon Feb 26 10:45:36 2018 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 DF387126C3D for ; Mon, 26 Feb 2018 10:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CONn5gEeuPKc for ; Mon, 26 Feb 2018 10:45:33 -0800 (PST) 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 54F6F124D6C for ; Mon, 26 Feb 2018 10:45:33 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx64.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eqNmF-000AvM-4v for quic@ietf.org; Mon, 26 Feb 2018 19:45:31 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eqNlh-0004NW-Le for quic@ietf.org; Mon, 26 Feb 2018 13:45:29 -0500 Received: (qmail 23306 invoked from network); 26 Feb 2018 18:44:55 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.158]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Feb 2018 18:44:55 -0000 To: Martin Thomson Cc: Marten Seemann , QUIC WG References: <059bc7c6-a8cb-c46b-c971-333b9051c222@huitema.net> From: Christian Huitema Message-ID: <9d646ca7-2c95-62fd-206f-10ec6ce4cd5d@huitema.net> Date: Mon, 26 Feb 2018 10:44:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Unrecoverable loss pattern X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.17) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5gXivFKqF+MRRSOkXJxbbal602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViW4Iybcz83Dow0ZgaOTB9U87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBmePYa3CQqb9L6x2mHOMrWx/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYJlgC/j6gnFfUz8cFIW+v ZP5XHG7O1tYu81mRrWwAsv7c/F7BDvT0aUBvAh6gJldfpXIull5ERhEWeEevzAF7zmj55Nl155o2 Oe/0FuVZZmVzxAG+DjqL5QSEyTpqxgd+hoJiRUJS+7Nru8G8qObMBABriH3x3J15D78KylFpBENq HXIoSsvffuCdDqwWbJR1D/7Rwl5fb+U9Gl2IOh9znuhk/x9yoQRTGrDa4+HCd27Q+XNr4QUyZNz0 uLvRKYxZQqF/LoUsSniF4plClx3amRbl6gc+xGfFxqO6pPmlSScERpFEqF2lExBUp1VMiBudJzjv VlSk5R4XVB7M44lU2DF9mE6flINXEXJL2r3PrBjLoydbuOy1i9SfmYgxBbq3mdySlZou9qHIGOZD EEo7O+Pd3ebmKuucUVzXcVqfEwQXQ+sESjyASrM/THMyWUoiolU4x0KD113J1SYnBP2uKg== 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: Mon, 26 Feb 2018 18:45:35 -0000 On 2/26/2018 12:51 AM, Martin Thomson wrote: > The issue in #1018 (as I understood it) was the fact that Finished > could be protected (and thereby authenticated), but it was not. Not > having it protected makes it vulnerable to all sorts of attack. > > This is different, it's not an attack, it's just an unfortunate > interaction between the loss recovery algorithms and the TLS mapping. Actually, the issue was that allowing Finished to be repeated in clear text allows for a DOS attack on the server. The spec changed to ignore handshake packets after Finished is received once. That closes the DOS issue, but it opens the "ACK of Finished" issue. =C2=A0 > > Other than running multiple timers as I suggested, you could also > force the server to respond to cleartext packets with a repeat of its > ACK. It doesn't even have to look at what it received, it just plays > out the last ACK. That's what we do in our DTLS 1.3 implementation. > It works. The trick there is that once you have an ACK for the ACKs > that acknowledge the handshake you stop the special behaviour. > That was actually the first solution I thought off. That works too, but there are two downsides. First, you get a "twitch trigger" -- send an handshake packet, get the server to send an ACK. Not a very big deal, but slightly annoying. Second, it relies not only on implementing ACK of ACK, but also on triggering a special behavior for the ACK of the ACK of the last handshake packet. Many implementations do ACK of ACK management, but grafting a special case in that path is a bit tricky. That was my thought process before proposing a simple one byte "handshake complete" frame. The special frame is easier to integrate in the receive processing. -- Christian Huitema From nobody Mon Feb 26 11:20:00 2018 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 5ECA2126FDC for ; Mon, 26 Feb 2018 11:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqFvinxwzYwf for ; Mon, 26 Feb 2018 11:19:58 -0800 (PST) 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 306BB1201FA for ; Mon, 26 Feb 2018 11:19:58 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx67.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1eqOJY-0005xm-17 for quic@ietf.org; Mon, 26 Feb 2018 20:19:56 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eqOJW-0005NF-Ea for quic@ietf.org; Mon, 26 Feb 2018 14:19:54 -0500 Received: (qmail 9287 invoked from network); 26 Feb 2018 19:19:52 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.158]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Feb 2018 19:19:51 -0000 To: "quic@ietf.org" From: Christian Huitema Message-ID: Date: Mon, 26 Feb 2018 11:19:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Testing the proposed PRs in a timely fashion X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.40) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5s6u1PX9BwxTEc11EbBO15F602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVip7LSPJv0i7JPwkqZn2+tcc7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBuUr1xlTzNqsfVzHDPFP8hh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQYJlgC/j6gnFfUz8cFIW+v ZB5btsadfchUITsjrjSy+YfZcnC6amb7oYrKMGWBANsq9imZCTTmEbjsVIUQ9BcLkGj55Nl155o2 Oe/0FuVZZmVzxAG+DjqL5QSEyTpqxgd+hoJiRUJS+7Nru8G8qObMBABriH3x3J15D78KylFpBEO3 L31QGIB1LDs8uX49JL/WD/7Rwl5fb+U9Gl2IOh9znm1zHJmm0/PLoOlxR1+OAUfQ+XNr4QUyZNz0 uLvRKYxZQqF/LoUsSniF4plClx3amRqst++uVh7EY1whY32n5NIERpFEqF2lExBUp1VMiBudg69n bk9spkrwWQBuzVxSHzF9mE6flINXEXJL2r3PrBjLoydbuOy1i9SfmYgxBbq3mdySlZou9qHIGOZD EEo7O+Pd3ebmKuucUVzXcVqfEwQXQ+sESjyASrM/THMyWUoiolU4x0KD113J1SYnBP2uKg== 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: Mon, 26 Feb 2018 19:19:59 -0000 There are a couple of PR in the queue that could bring big changes to transport implementations: the proposed changes in the Connection ID from 8 to 17 bytes; the proposed encryption of packet numbers; the extension mechanism; and the proposed redefinition of the migration mechanism. Such changes are very likely to require interop testing, both to verify that the specs work as proposed, and to find and correct implementation bugs. That will take time. I am also worried that if we check in all these PR at once, we will destabilize the implementations. My proposal is to pick some but not all of these PR and integrate them in the next iteration of the transport draft, so we can start interop testing. If I had to start somewhere, I would start with the path migration PR. It seems close to ready, it requires significant coding, and it replaces the PING/PONG mechanism that we would rather forget and not implement. Path migration also requires some testing infrastructure, such as opening multiple sockets on the client and migrating the connection from one to the other. Not hard to do, but requires some time to get it right, so the sooner we start the better. What do other developers think? -- Christian Huitema From nobody Mon Feb 26 14:57:31 2018 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 A89D1124BE8 for ; Mon, 26 Feb 2018 14:57:28 -0800 (PST) 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 qBYNOGfCGZSN for ; Mon, 26 Feb 2018 14:57:26 -0800 (PST) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 B4B12124B18 for ; Mon, 26 Feb 2018 14:57:26 -0800 (PST) Received: by mail-oi0-x233.google.com with SMTP id u73so6960473oie.3 for ; Mon, 26 Feb 2018 14:57:26 -0800 (PST) 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=HaD+J7wc91abnhBC9wPbDFwZKatvmO/7PbU36LuynHc=; b=qyUlNL2wEGyimLlEr8X3zwsq41Vm+bonLTI1oPPZZnBNG/1nbXZDOF5YhHVfCZhQHq V4dhXAfHh5UvqVysOEx1JPQhFAXHS+amKZDBRvR2a2UZsapgZd1XYnMut38PqNQK2Lxo Cyorjiv698uYiaM4czatLsii6/KA8SU14Ikocz13bDJgmjd7Bnpqr4p6GN++eB6wX7tM 8ni3R97NdAvut0KfPmm5OyZE4/pqQcb7J43DExfh6CL+rRvm/gE8yrH7VDXEnlvYrW59 MrFkHCNJTO4Ox8e/fcshEAfBSNDJeHePL447j2uI9O9G4EGGseAyoRPr0ECY3T7duInn +dSA== 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=HaD+J7wc91abnhBC9wPbDFwZKatvmO/7PbU36LuynHc=; b=XPHMqd35DPf58ZL7RtoiSoBlA6bJRSGRT2noYH8OPApJE7AQadQdk/RPqsN8TRmew2 Hbo+2+lR6D7MgN/yJSZ4xJJxQn8sdQd5dKaTBYZmgyyN/6Z6pXCJVTPQet/CIKloL6FY NW1EcxE1Y7fajCupv8jvPuEXUQ840gPUzfALp57jGsCiU/2P4UqeKQaQMwXJSdswwWZJ JWBG7j80RDh5LAIf67WkN/tuKwCLYf2TEiQT53kToZsVI4pg1P2cGRSLM3JAuhJ0/ea2 JbLUcN9Xee7ACSkk8R88If1NwmkgIpyMPIgbiF2RJKRaQ8hG6CnGvbbChXeAwRJvmIe0 riJg== X-Gm-Message-State: APf1xPDW9JXCKZYPp2DHQaEvYMhy3Zrb61c+CPWJE60xJ9RIoKk0ATIX al5X0qzrjQmZzA6D6/4/F1b12qVntgV75KKehcVPuw== X-Google-Smtp-Source: AG47ELtF07cwLBzhEfjFl3Qx6pYuEJAOsptG/pB+W3naNQAn936agaviX0I+pBlZ4zlX7p8oeCVapEPL0wkHhkjyJ7Q= X-Received: by 10.202.84.132 with SMTP id i126mr7308147oib.295.1519685845686; Mon, 26 Feb 2018 14:57:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Mon, 26 Feb 2018 14:57:25 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 27 Feb 2018 09:57:25 +1100 Message-ID: Subject: Re: Testing the proposed PRs in a timely fashion To: Christian Huitema Cc: "quic@ietf.org" 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: Mon, 26 Feb 2018 22:57:29 -0000 The 17-byte thing seems unlikely to be adopted. Based on the outcome of the design team discussion, a double connection ID mechanism is more likely. As for merging, I think that we are close to merging the migration PR. It's mostly editorial issues that are holding it back now. On Tue, Feb 27, 2018 at 6:19 AM, Christian Huitema wrote: > There are a couple of PR in the queue that could bring big changes to > transport implementations: the proposed changes in the Connection ID > from 8 to 17 bytes; the proposed encryption of packet numbers; the > extension mechanism; and the proposed redefinition of the migration > mechanism. Such changes are very likely to require interop testing, both > to verify that the specs work as proposed, and to find and correct > implementation bugs. That will take time. I am also worried that if we > check in all these PR at once, we will destabilize the implementations. > > My proposal is to pick some but not all of these PR and integrate them > in the next iteration of the transport draft, so we can start interop > testing. If I had to start somewhere, I would start with the path > migration PR. It seems close to ready, it requires significant coding, > and it replaces the PING/PONG mechanism that we would rather forget and > not implement. Path migration also requires some testing infrastructure, > such as opening multiple sockets on the client and migrating the > connection from one to the other. Not hard to do, but requires some time > to get it right, so the sooner we start the better. > > What do other developers think? > > -- Christian Huitema > > From nobody Mon Feb 26 15:52:23 2018 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 BD019124235 for ; Mon, 26 Feb 2018 15:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34F8bRHc2ocs for ; Mon, 26 Feb 2018 15:52:21 -0800 (PST) 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 515481201F8 for ; Mon, 26 Feb 2018 15:52:17 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx3.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eqSYg-0007eW-Q1 for quic@ietf.org; Tue, 27 Feb 2018 00:51:52 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eqSY9-0004RW-V8 for quic@ietf.org; Mon, 26 Feb 2018 18:51:48 -0500 Received: (qmail 15892 invoked from network); 26 Feb 2018 23:50:57 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.158]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Feb 2018 23:50:56 -0000 To: Martin Thomson Cc: "quic@ietf.org" References: From: Christian Huitema Message-ID: Date: Mon, 26 Feb 2018 15:50:52 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Testing the proposed PRs in a timely fashion X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.40) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ifFSE0NBluyKg/MqXHP++l602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVidNkAw/hfnCrJncrgZuEEr87i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBiuj1YIZWyGteeTEbAD/lb/vRa7MR4hgRIg8N 1QlY4G7x1YBTEs55LirRLgpsvCFtid7SQi4NE/job5y2wAN3GZxznd8NXwc/vKJtfZaXo5QAJAfA 9MMVcQ9WVjD1q+Rbd9IPG/DQ2p+GU04sTuYFs91jhnM/Mbva2XLV/LIEzaKyLm0zESXAkIAT8ZKA DvsGI5uh86ZVnyOrYkLMWyEaRt9fxN2oReTDHAyOynaY0ClKHhIXfDbmhz3DoftFSAfVIRFsicyJ MEhQFtD8PLoiniWmsFByBoXAuCZEyg59LM81CaOu2xwDQxDsUgSvK+nII1IRruUYLOgUnyoTu5lV X1MKVprlQYwN+KHznEQNFP3OZTvgiCjhIZF4Y76uWrdlx3STuqJ0TIH+SWjiF9Q0pQfG/OGabeQO D+JyvmSUpW+ZQTl/k5oRlt1ErWfaEWxe22o4BNBy+bVfxj88zI41K1O7B0jvACHkMSS0WCQUO4D1 rYsclUPWfsYbR8/iz5oiSGG/BQd7r2NVEaNhWos5pl2H4dyBB98UmiRmBFCitykccBIk1Sag4dKi qCrF8eZZeNMTAWyxeqt3BjCO03tBtixP5LFurlz8Yikuq9Id3lmBi6owqeb+h1kbxIVWYdC7ygC2 BNoAMaYuKRPezBphPleqv/VOJZnHunWcIBzbsDrLaeA4pl20N4bgeYf9w8whIRFsicyJMEhQFtD8 PLoinpgjWjpMfsxmWdg884icSQEZwRvSfvkJh2VafuDhMcA1uHlEIbR8fMtAowK0FL525g== 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: Mon, 26 Feb 2018 23:52:23 -0000 On 2/26/2018 2:57 PM, Martin Thomson wrote: > The 17-byte thing seems unlikely to be adopted. Based on the outcome > of the design team discussion, a double connection ID mechanism is > more likely. Yes. But then moving to double connection ID of variable length is also going to require serious development and testing effort. To evaluate that, I changed the "connection_id" type in Picoquic from uint64_t to an opaque type. This was not simple, since the connection ID is used pretty much every where, not just in protocol code but also in logging code, test code, and of course test vectors. And doing that caused a couple regression bugs, which I only found weeks later. Of course I am sure that other developers can do it better, but still, they will need time to work it out.=C2=A0 If we want to be done in November, we may want to t= est that kind of stuff sooner rather than later. > As for merging, I think that we are close to merging the migration PR. > It's mostly editorial issues that are holding it back now. Cool. Do you think we could have that spec merged before the London meeting? Or should we start preparing for interop days in April and May? -- Christian Huitema From nobody Mon Feb 26 16:05:30 2018 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 CCC1A12D94D for ; Mon, 26 Feb 2018 16:05:28 -0800 (PST) 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 9LY_0z6u3SNS for ; Mon, 26 Feb 2018 16:05:27 -0800 (PST) Received: from mail-ot0-x22f.google.com (mail-ot0-x22f.google.com [IPv6:2607:f8b0:4003:c0f::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 5756C1201F8 for ; Mon, 26 Feb 2018 16:05:27 -0800 (PST) Received: by mail-ot0-x22f.google.com with SMTP id w38so2174182ota.8 for ; Mon, 26 Feb 2018 16:05:27 -0800 (PST) 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=FQcF4GokBEeQvGDg8MwQiM897zH4Y90g+0K90A5YecI=; b=G57xKM6+rHEJQkdws//Ae8C5RqvaN0Hj9jfUD1lzUAIuH6umdjjL32XuAcjBsMZgwd vgBEM2cn5W/bDCogblUdj0g3nzfmTH+O0ZRG2+uwkG86eI7xu8AvyH0U00PdLbz9HCxD HO930ka4hS5mU9QJQDBzSuA0Xa0wOJ4ru3aE00sPHq3D3WHYGYUfzN0k7j7IPUlQMvXn mQAbDSRwOG4GffFzB/pi0iXolry4nOiehTewja3LaEMgoDj5Q0Kbl0fUwOf+EjtJXtbE UMjHCqyIs2ElXaI4nqOb97dMXkTGDqI/YJ2GAn1dWSXo4fgo2Z/Mauw2NaQoS3lvvrVC stSw== 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=FQcF4GokBEeQvGDg8MwQiM897zH4Y90g+0K90A5YecI=; b=ASHYpjZxl/E9B+vydJ9gwdnMLzqZAXDSiA7/4gz+73u80yYlfkChZu+v+t9NnqmKN7 Ce1IidnypSkQkybRwq7iE9GDG7I8/80RPFACVDB/NW8HiXgwQ/XW9b6u6ALrVR+ais4n iVdjKLwnPvu223ilJBzlZwDZzESqXdPMVq9fpF8lKq53WwhZgtc2zQTsrJuiNaLpVjvY H06pAx8TBKOEfTpqZpeWWgX/B+olPYezwtZv/p33sM8i0+Uo4W+Y7sTdV/Y7Ly4K9rqw REFRGVSGAZq2WhmpS/V3eV9Su8c/vPmUsjLRjhEHsHnEbdCMmHbEFm0Tcl1ooayhZQRJ PC7g== X-Gm-Message-State: APf1xPDorlicMaxG/PZK/L6zKZ/w2p1rgSUlg3M7p89reUl12r9HhW6z 0Obr17NIVAWKzzoISX8K5l+la5yEYtMZM6lptYU= X-Google-Smtp-Source: AG47ELsDHv1on9IBcWFjj/ScRJZvBHGOO6ILLszSci7zutIjhd0fsS+wPuXSvJzBgQREM1lhVTsvWw5Jncly7stJxic= X-Received: by 10.157.64.181 with SMTP id n50mr9330889ote.241.1519689926364; Mon, 26 Feb 2018 16:05:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.16.85 with HTTP; Mon, 26 Feb 2018 16:05:25 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 27 Feb 2018 11:05:25 +1100 Message-ID: Subject: Re: Testing the proposed PRs in a timely fashion To: Christian Huitema Cc: "quic@ietf.org" 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, 27 Feb 2018 00:05:29 -0000 On Tue, Feb 27, 2018 at 10:50 AM, Christian Huitema wrote: > Cool. Do you think we could have that spec merged before the London > meeting? Or should we start preparing for interop days in April and May? I hope so. That depends a little on Jana though. I've been holding -10 for it, because it seems like a good thing to put into something more concrete. I would prepare for more interop days no matter what. I'm not yet confident that we're at the point of people deploying code and until that happens, these events are what we've got. From nobody Tue Feb 27 13:57:10 2018 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 D1B3912E05C for ; Tue, 27 Feb 2018 13:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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_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 VRLLrHZyv3kb for ; Tue, 27 Feb 2018 13:57:08 -0800 (PST) Received: from mail-wr0-x242.google.com (mail-wr0-x242.google.com [IPv6:2a00:1450:400c:c0c::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 DF23912E045 for ; Tue, 27 Feb 2018 13:56:50 -0800 (PST) Received: by mail-wr0-x242.google.com with SMTP id m5so341055wrg.1 for ; Tue, 27 Feb 2018 13:56:50 -0800 (PST) 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=t0JsPNQzWG6BkjciHvglL4w5oI7PjMKafqEJooXtaAA=; b=iYYkG3WJv15jA25uhpE7DJgtKRkwnUIiORuz++5NgLn0kofrn8l47WTsS6sWvQ/SzO c1tRgWNqYXKqAIAcAeWB5YvFrrse8McSMBDUg1myzbvJvJ7QwaTKJI6IWERfGVx2oiZU 3OCR1yKInMzXszz6L65NfBECoyXYOU+msdAwILbRZq+LCE1QhZ46O7zWXn4mqCD7P9jI VTTnv5RZgDG8nMo8ze92xmFLTDtRmiM1yuxnHFGrEQkQziBrG+FdTIA848u/KKqA50xq QucB++wQFq9Dez9SiLywhmHAxyW7bCen7wmoTfEPGmmjdSbhZANG51hlJ3bpQgrmjrwO 56uA== 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=t0JsPNQzWG6BkjciHvglL4w5oI7PjMKafqEJooXtaAA=; b=X5kwAdop7kiF3/OvLyfqklPzImF2LWNXByQrd4/DG5+z6EG9wtYVshB9wDzE1kpHIs 9BdVPaZcgcHHJF4RWaWVjMxSxhliM5DJ7xzVxn2wztPkQrasmURwHV51XBokVLkfn72w Jipd15EDdVlxrmQe6FX3DUA+U8Hi9bHO6oByWdhGmxmKZM21NKHmU6/ddf1MVNamw78d 62QNSZI3cMNMcbvSIYkrsBgfitvzmVm3WrXg9JyPfYYDBnGDv2A/U76egrHEHDK3Hiy2 1rB++ENoz179biPHEvj4KL0Fpj400QPVARGyC4qOmzM4TqGwq1jGVtmTSYdyVmL7+wiG ftbA== X-Gm-Message-State: APf1xPB1NpqUSydBet3Gn84ufJkmHkNJ6969Vv3QeO0A6rOb/fWYIHVs ZCWBBKrhRyfG+R+atJBCohR/DQvaMSMrXDMo7whSFQ== X-Google-Smtp-Source: AH8x225+xNc1o0R7q727SSKy/kVkZasf2mZMnzkkhBA0oKnWezCkKqzLjazmrYU4PBgiuw29daT+9zlDZ1ph8rgFOWU= X-Received: by 10.223.163.85 with SMTP id d21mr13886196wrb.105.1519768609486; Tue, 27 Feb 2018 13:56:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.195.139 with HTTP; Tue, 27 Feb 2018 13:56:49 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 27 Feb 2018 13:56:49 -0800 Message-ID: Subject: Re: Testing the proposed PRs in a timely fashion To: Martin Thomson Cc: Christian Huitema , "quic@ietf.org" Content-Type: multipart/alternative; boundary="f403045f14e81bfc35056638b4c6" 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, 27 Feb 2018 21:57:10 -0000 --f403045f14e81bfc35056638b4c6 Content-Type: text/plain; charset="UTF-8" On Mon, Feb 26, 2018 at 4:05 PM, Martin Thomson wrote: > On Tue, Feb 27, 2018 at 10:50 AM, Christian Huitema > wrote: > > Cool. Do you think we could have that spec merged before the London > > meeting? Or should we start preparing for interop days in April and May? > > I hope so. That depends a little on Jana though. I've been holding > -10 for it, because it seems like a good thing to put into something > more concrete. > I've been in a bit of a lull the past week, but climbing out of it now. I am hoping to address comments on the PR today, and I think there's enough momentum in the wg to get it to merge soon. That said ... I would prepare for more interop days no matter what. I'm not yet > confident that we're at the point of people deploying code and until > that happens, these events are what we've got. > ... I agree with this. We have a number of moving pieces, and -10 isn't the end of it. The more interops we have, the faster we move towards spec maturity, which we sorely need. --f403045f14e81bfc35056638b4c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Feb 26, 2018 at 4:05 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On Tue, Feb 27, 2018 at 10:50 AM, Christian Huitema <huitema@huitema.net> wrote:
> Cool. Do you think we could have that spec merged before the London > meeting? Or should we start preparing for interop days in April and Ma= y?

I hope so.=C2=A0 That depends a little on Jana though.=C2=A0 I'v= e been holding
-10 for it, because it seems like a good thing to put into something
more concrete.

I've been in a bit o= f a lull the past week, but climbing out of it now. I am hoping to address = comments on the PR today, and I think there's enough momentum in the wg= to get it to merge soon. That said ...


=
I would prepare for more interop days no matter what.=C2=A0 I'm not yet=
confident that we're at the point of people deploying code and until that happens, these events are what we've got.
... I agree with this. We have a number of moving pieces, and -= 10 isn't the end of it. The more interops we have, the faster we move t= owards spec maturity, which we sorely need.

--f403045f14e81bfc35056638b4c6-- From nobody Tue Feb 27 15:13:02 2018 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 DB77A12EA93; Tue, 27 Feb 2018 15:11:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: quic@ietf.org, spencerdawkins.ietf@gmail.com Subject: quic - Requested sessions have been scheduled for IETF 101 X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977306989.5200.290103883990076105.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:09 -0800 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: Tue, 27 Feb 2018 23:11:10 -0000 Dear Lars Eggert, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. quic Session 1 (2:30:00) Thursday, Morning Session I 0930-1200 Room Name: Sandringham size: 300 --------------------------------------------- quic Session 2 (2:30:00) Monday, Afternoon Session I 1330-1530 Room Name: Sandringham size: 300 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2.5 Hours Number of Attendees: 200 Conflicts to Avoid: First Priority: tsvarea tsvwg tcpm iccrg httpbis tls dispatch Second Priority: mptcp saag Third Priority: irtfopen maprg People who must be present: Sean Turner Mark Nottingham Patrick R. McManus Jana Iyengar Martin Thomson Spencer Dawkins Lars Eggert Mike Bishop Ian Swett Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: Two consecutive days early in the week, if possible; 2 hour slot(s) fine too, if that makes it easier. --------------------------------------------------------- From nobody Tue Feb 27 21:20:37 2018 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 0705912D95A; Tue, 27 Feb 2018 21:20:31 -0800 (PST) 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-invariants-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151979523099.5187.635064098167976716@ietfa.amsl.com> Date: Tue, 27 Feb 2018 21:20:31 -0800 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: Wed, 28 Feb 2018 05:20:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : Version-Independent Properties of QUIC Author : Martin Thomson Filename : draft-ietf-quic-invariants-00.txt Pages : 9 Date : 2018-02-27 Abstract: This document defines the properties of the QUIC transport protocol that are expected to remain unchanged over time as new versions of the protocol are developed. 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 [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/-invariants [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-invariants/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-invariants-00 https://datatracker.ietf.org/doc/html/draft-ietf-quic-invariants-00 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 Wed Feb 28 00:11:49 2018 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 2606512DA51 for ; Wed, 28 Feb 2018 00:11:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 cHWz09zTloou for ; Wed, 28 Feb 2018 00:11:45 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 AB37912DA50 for ; Wed, 28 Feb 2018 00:11:45 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id w63so2467412ita.3 for ; Wed, 28 Feb 2018 00:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=KmK2xwwhKXPnls2bmmZmdNumGB75WwD6ebe713zUKeg=; b=AR5mDC8xWkgrA3+7g02oyufmF0e0irzMsmGbwpEZyXI3lyM+odvsoC0CAqiSDK1mA4 p6wDa/aUH2hG2rJaIzZQzsjWlEU9M1dsNGLujzU7ewxdir9rc03FrSDZs1/X2foE5qgm k5UYDM+Oo3O59QN43qb+fQPpYF/mI37yQTBjGyo3ZOhJIWGmUhE5vnDmElaUk5kQ9wrU WitQz2NhiLB8cvTzznGU0PiTSn8EJJfNfjkmXDTwRkw3Fppk6b6leYmzbXC2d/NoenOn gK4ORKKz7SV/U2PINyv/yh9j9frQtHW9omT6d9xRgfD6l+zOg7Y3Idw4tFFoIorlJZhK dDbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=KmK2xwwhKXPnls2bmmZmdNumGB75WwD6ebe713zUKeg=; b=YIkRTnlNZu3PAAaSn07Gh4JC+lfYUzzuyTPhd/Kq+sVGr/AjrZHoIn44AHt1KC84KE Pjx/Feh0Z2zXv1Pp8/hmt9bYiSsHbmB2MzRuEzKSK3O3oOhhNj+fOvqyE5wkj8mTDv6e 5ecPzmJ1v8rjmCzzMtA4nTHUrplVWftoGIDK6NAix7rf3tQVhjS/RPQp2MvyyzuTrigH KCwfQOYL5bZ7tCxayYFj8HnMBCw5c774VxTBYrWFucELPQCDWL5hlRWB4bIoCqrhQSWx cgaPyklFRXNrxEZzg48nbyjpdcDeciMsCm4rGyS7hSOL9OtQ7LIx12YHt9VCihq7Wdoa EL9g== X-Gm-Message-State: APf1xPAizdvZ0VFFBpF3yGda7NXJvCgpC5UGX8mgJPY0gRjfZ2QxztW+ /Jdi4r1s9EibovXUO1MvPboJFEeJPXiAydy1Qe+A/w== X-Google-Smtp-Source: AG47ELtevt1KCZ6uTCorav8GsFFIQ8+0a/zaUKLGAWptV9Ffv5NxGP4NjNNfmw+hUMd1AFYqV7wpgUYJM9O8ixMzdUc= X-Received: by 10.36.90.212 with SMTP id v203mr754635ita.150.1519805504930; Wed, 28 Feb 2018 00:11:44 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Feb 2018 00:11:43 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 28 Feb 2018 00:11:43 -0800 Message-ID: Subject: Space for Packet Metadata To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1143b9b03fc70e0566414bad" 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, 28 Feb 2018 08:11:47 -0000 --001a1143b9b03fc70e0566414bad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Would it make sense to reserve space for additional metadata by reducing the required initial packet size to, say 1000 octets in order to allow for a smaller PMTU than the actual PMTU? This could simplify tunnelling and monitoring, and also other cases where multiple servers cooperate on handling a single connection. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --001a1143b9b03fc70e0566414bad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Would it make sense = to reserve space for additional metadata by reducing the required initial p= acket size to, say 1000 octets in order to allow for a smaller PMTU than th= e actual PMTU?
This c= ould simplify tunnelling and monitoring, and also other cases where multipl= e servers cooperate on handling a single connection.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen
--001a1143b9b03fc70e0566414bad-- From nobody Wed Feb 28 06:08:09 2018 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 5EC9312D7F8 for ; Wed, 28 Feb 2018 06:08:07 -0800 (PST) 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 rwS2Hbp7PaQy for ; Wed, 28 Feb 2018 06:08:06 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::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 10C4912DA4C for ; Wed, 28 Feb 2018 06:08:00 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id s198so3074220qke.5 for ; Wed, 28 Feb 2018 06:08:00 -0800 (PST) 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=Q3j0TB6DIO/CFEPjPJressV4WNtwC2lsV/UqXfd8uZ0=; b=o8DwclpSK7JzNNolZK3B1W19OxvGlw9Rr6fxkFIK9W2sEIZGKOX2FID8nZhkL5worB X8ZO9by/XbJmOAYqHxOxHjEhjtMuNbJD2dWRjQXcw8sSJGhVMyb+iSZIAx6Eth3uvtZr LnBHJkgjIBrxFih99HtDk73ael/O6n4GVYn5yF+0DBdV+y4Ej+BXBtqeB3S46FivXph7 Ck+xzVowSRxpdcUSkTMIoDzF55W+uHN3jk0dsE/7o8sk7wU5AAKvMnt3PatowhfA3j1L G8b7cvKz5UN62vKl/r/bvg+wu6/Yky3GM0FS5I8Sy/grJT6jP2pFa+qNEI85WR049z6T 7i6Q== 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=Q3j0TB6DIO/CFEPjPJressV4WNtwC2lsV/UqXfd8uZ0=; b=mULR4y2LCrT7oXWFp7MSzdBqyHFGan4GxZDuIuVcnvWtv8WpnXS3xMvIalKc/jhjs3 qYjfDxcVB+R4NNmulwfrrE+eZe5TU9dIutIQJJktUxeQtf7d10OKFwNPpxwjyftVOc+u kaC80hPCqJt+CO/WZ8ejPAR70PwvnH0DgwPA40xXwNkrs000zrG7jeB3RPZpFUTnACqj W8adEzM37TMDdDvUhLWnC0AV2W9h+EEG6VyWRr45diXwaySXcWGkkvK5sfNpTIM98v/C /e9JlQ09v/XD1XOWBndGa+qo13vPGJ7zEZLxs1/JHPb5RDsS96bkMDT1BaZTyzKgbcEZ JZ6A== X-Gm-Message-State: APf1xPCPjXLPsH4CsdJ61u55cRhBWDUOaQoYIV2XY8fUNonAMex8+yJf QQn2BdJmVXixb9WY9HI6gZ6dHWQXylH5vtMFlh3Sm2vl X-Google-Smtp-Source: AG47ELsFHiEOOoOrSj0CgQWhWBfVp7OSr+S2Oegue0XTreVVtDIzacG2+bO4lnv+icsi/g6OIoI/tO6joodwvUSaDfE= X-Received: by 10.55.9.135 with SMTP id 129mr26914880qkj.221.1519826879114; Wed, 28 Feb 2018 06:07:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.37.176 with HTTP; Wed, 28 Feb 2018 06:07:18 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 28 Feb 2018 06:07:18 -0800 Message-ID: Subject: Re: Space for Packet Metadata To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11487b8c400b52056646451f" 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, 28 Feb 2018 14:08:07 -0000 --001a11487b8c400b52056646451f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 28, 2018 at 12:11 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < mikkelfj@gmail.com> wrote: > Would it make sense to reserve space for additional metadata by reducing > the required initial packet size to, say 1000 octets in order to allow fo= r > a smaller PMTU than the actual PMTU? > > This could simplify tunnelling and monitoring, and also other cases where > multiple servers cooperate on handling a single connection. > How do you imagine those servers would use this space? -Ekr > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > --001a11487b8c400b52056646451f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 28, 2018 at 12:11 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkel= fj@gmail.com> wrote:
Would it make= sense to reserve space for additional metadata by reducing the required in= itial packet size to, say 1000 octets in order to allow for a smaller PMTU = than the actual PMTU?

This could simplify tunnelling a= nd monitoring, and also other cases where multiple servers cooperate on han= dling a single connection.

How = do you imagine those servers would use this space?

-Ekr


Kind Regar= ds,
Mikkel F= ahn=C3=B8e J=C3=B8rgensen


--001a11487b8c400b52056646451f-- From nobody Wed Feb 28 06:34:23 2018 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 CB9EA12D7E8 for ; Wed, 28 Feb 2018 06:34:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 h9k0RbX7XZv7 for ; Wed, 28 Feb 2018 06:34:20 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::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 DE6C9129C5D for ; Wed, 28 Feb 2018 06:34:19 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id k135so3699655ite.2 for ; Wed, 28 Feb 2018 06:34:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ooOqQT4riOBG5Pe8SCWrFMlw0nIjmDcZs76KVvqQa34=; b=n/DHUuR7kKNleeb5BxLjCo+cR6qEl1kAGFLK3XxT0qMFEJCusLQoVNAJyyrlbjQgrz fJ+2CtkcHsOaU0Iz/6W6XAOkxWddyR/VMYiLNaNV22sUV2Mt67tMnL8eOh8Fb8NtF5YI H7ZU3c5x+5o3TdMMZIKBFV22W4bgGjnlObLohMFijTIUhAiEETojyDMRUhypmz3d3RNZ OMGuIJAo9vHhO5ohBukPLiowOJa8rDFF9v35NS9DHh4AhT2iLRHViP3KB3YX1cpTeVuV Xw2+S//GlD1KOrBVJgePH/XwAzRQ3eOkoWmV4NH3C3tVD4a9c+Y5OgDqgjOZkXDV01CA VLkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ooOqQT4riOBG5Pe8SCWrFMlw0nIjmDcZs76KVvqQa34=; b=JZ+dPXJObYbz8qAwf+BfclkjZmhpABDlGg/jexKM681Rc+7F6woxo4znx84PsDIWaz guBWgy1tMw2MtCS68UBasiMnkJa9p5+cawc+1y6Vkw2Ytp968zmeo400nLHnXlHvxsmb qpdcCDQdG86C7fomCV66jj3W/6BiA1fXpLk1KhmtllGok/gcmS626uKpKfSmtU3S9DaJ XPUESSUR6A356oXSJoj+db03KzYH04ZZKoM9RwbJJmzmmRJdBxSsyExp4Vg3NZSLUUJS fFXzLqqpahNU9edbiVn8rmGdqU0YPciGcd0kuokzI2GCc+mkbrpphqUJ/+G3AWgh2+AJ ZQwQ== X-Gm-Message-State: APf1xPCyn6SSv2R6+WZm9rnx/Tu/pDoXUNWPtoyiyisFXGuenu5+zzn2 dJ5MRHAuHfOF+8ZIIzDxt9U6BE72QfklOLwPanI= X-Google-Smtp-Source: AG47ELsZ425Ygp2qPkfJVEw/cQm83tbl8QXftRJjChxwz4KkdAqB6j5NjUn0V53l3V4zV6m2TIkR4gcaK5D07EJZTA4= X-Received: by 10.36.90.212 with SMTP id v203mr1978613ita.150.1519828459213; Wed, 28 Feb 2018 06:34:19 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Feb 2018 06:34:18 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 28 Feb 2018 06:34:18 -0800 Message-ID: Subject: Re: Space for Packet Metadata To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1143b9b06e562a056646a3d2" 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, 28 Feb 2018 14:34:22 -0000 --001a1143b9b06e562a056646a3d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > This could simplify tunnelling and monitoring, and also other cases where > multiple servers cooperate on handling a single connection. > How do you imagine those servers would use this space? One example is forming a consensus across servers handling connections from multiple clients concurrently. A current leader receives the packet and either just signs it, or verifies the content first, then forwards the packet to n - 1 other servers in different datacenters (depending on protocol). Once enough signatures have been collected, the packet is accepted and processed, adding an ordering across all connections. If a server is compromised, it can=E2=80=99t do something with the packet the ot= her server haven=E2=80=99t already authorised. In some protocols each additiona= l server would add to the previous signature thus requiring quite a few signatures to ensure consensus. It is of great value to have these signatures in a single packet because it provides atomic read guarantees. This can easily consume 80 or more bytes. Obviously there is a lot more to it than that, and it can be done after unwrapping QUIC and via secure point to point communication, but that would be less efficient and you might have difficulty proving the content originated from a given client without even more signatures, and the client might have to be involved in the protocol. It only works, it you keep enough servers safe, or course: https://www.vox.com/world/2017/6/13/15791744/russia-election-39-states-hack= -putin-trump-sessions This is just one example, but any time a backend needs to coordinate, extra space might be useful. Another example could be a virtual routing token added at the end of the packet. --001a1143b9b06e562a056646a3d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =

This could simplify tunnelling and monitoring, and also oth= er cases where multiple servers cooperate on handling a single connection.<= /div>

How do you imagine those server= s would use this space?

One example is forming a consensus across servers handling con= nections from multiple clients concurrently. A current leader receives the = packet and either just signs it, or verifies the content first, then forwar= ds the packet to n - 1 other servers in different datacenters (depending on= protocol). Once enough signatures have been collected, the packet is accep= ted and processed, adding an ordering across all connections. If a server i= s compromised, it can=E2=80=99t do something with the packet the other serv= er haven=E2=80=99t already authorised. In some protocols each additional se= rver would add to the previous signature thus requiring quite a few signatu= res to ensure consensus. It is of great value to have these signatures in a= single packet because it provides atomic read guarantees. This can easily = consume 80 or more bytes.

Obviously there is a lot more to it than th= at, and it can be done after unwrapping QUIC and via secure point to point = communication, but that would be less efficient and you might have difficul= ty proving the content originated from a given client without even more sig= natures, and the client might have to be involved in the protocol.

It= only works, it you keep enough servers safe, or course:

https://www.vox.com/world/2017/6/13/15791744/russia-e= lection-39-states-hack-putin-trump-sessions

This is just one exam= ple, but any time a backend needs to coordinate, extra space might be usefu= l. Another example could be a virtual routing token added at the end of the= packet.

<= div>
--001a1143b9b06e562a056646a3d2-- From nobody Wed Feb 28 06:58:48 2018 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 8885512EAF9 for ; Wed, 28 Feb 2018 06:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 qCl_N7RX4ijw for ; Wed, 28 Feb 2018 06:58:46 -0800 (PST) Received: from mx61.netapp.com (mx61.netapp.com [IPv6:2620:10a:4003:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C77212EB0C for ; Wed, 28 Feb 2018 06:58:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,406,1515484800"; d="asc'?scan'208";a="14502296" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx61-out.netapp.com with ESMTP; 28 Feb 2018 06:58:37 -0800 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 28 Feb 2018 06:58:15 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 28 Feb 2018 06:58:15 -0800 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=aSrmvu+alVm5lJuCUwXU7QSt+3S26DwaZ6DINDlRTZM=; b=o3BCHcpMXNRhmc81tUxyBh+GCnDpDF50wEHjHHqGoY+G4qPOMxSYt9u4vF3IZmRZ/IQ5VlJzbCKg6t40+QBlqx3dfWBitJ3SHcOfMUObIsEtvT+x9RJgG2hEps9JzUazs8xEhAgXKCreaNIv6eTg1CeE2y7hmuMARGJZ9sk07lM= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB481.namprd06.prod.outlook.com (10.141.203.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Wed, 28 Feb 2018 14:58:12 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004%14]) with mapi id 15.20.0548.013; Wed, 28 Feb 2018 14:58:11 +0000 From: "Eggert, Lars" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: IETF QUIC WG Subject: Re: Space for Packet Metadata Thread-Topic: Space for Packet Metadata Thread-Index: AQHTsGvskv2Pnqzz/UGWODiG1gaITqO56EAA Date: Wed, 28 Feb 2018 14:58:11 +0000 Message-ID: <96577B0E-502B-4723-9A9B-63D8B365D5AA@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.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:360d:b01:a035:c8c2:34a2:c0de] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB481; 7:sWgjL+gOuHBSCp8VmWw+kDrk6ZEKTfM7t+FQakgiOR7DsRxmipXvSiNNTGOC05UuYkgn5YKKTp1br9lzEdTIeE4sbJ4o/SmNPKjXDXh4vDE4tp93nBJUDNjzhfxzLP32Ow+ZuwOdKAaTzYfR7S2GJ+i4H/zSpFtwCoSqH55FZ4ipD5ZcT0Dgb328EES3fbxlcZkR1ePH7ilZKo1448vPYZq8D07xFDrQjkoLRWwSvd0QNK2pn0lPgshX9WL6W14Y x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3f128a2b-beab-492f-2549-08d57ebbaffe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB481; x-ms-traffictypediagnostic: BLUPR06MB481: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(72170088055959)(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231220)(944501217)(52105095)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BLUPR06MB481; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB481; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(39380400002)(346002)(39860400002)(396003)(377424004)(199004)(189003)(33656002)(7736002)(5660300001)(3280700002)(2906002)(53936002)(4001150100001)(106356001)(97736004)(8676002)(316002)(6486002)(6436002)(478600001)(6512007)(305945005)(57306001)(86362001)(68736007)(6116002)(39060400002)(99286004)(6246003)(53546011)(8936002)(6506007)(186003)(14454004)(82746002)(3480700004)(99936001)(25786009)(1411001)(50226002)(4326008)(59450400001)(6916009)(5250100002)(81156014)(2950100002)(105586002)(81166006)(83716003)(229853002)(3660700001)(2900100001)(36756003)(102836004)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB481; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: WNu1+HRyZuadJV4Kqdyh4E+KkSrY+IullYYzsgOuug9amMSOGIIpA2qmvCFRNRi67BtwTQmwKGneVRCuPpKcj5j7ytpJ7HZm7vn0A7x3KX4o1ph4EZB9yjTl4plHUU2VIVA3+i4Q0iLsEEJvN1yLgwJsISjwhduQUoSL0+ZNDXg= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_B7A1A176-9133-4A61-A53D-1716BDCB323C"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3f128a2b-beab-492f-2549-08d57ebbaffe X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 14:58:11.8508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB481 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, 28 Feb 2018 14:58:47 -0000 --Apple-Mail=_B7A1A176-9133-4A61-A53D-1716BDCB323C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2018-2-28, at 9:11, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: >=20 > Would it make sense to reserve space for additional metadata by = reducing the required initial packet size to, say 1000 octets in order = to allow for a smaller PMTU than the actual PMTU? >=20 > This could simplify tunnelling and monitoring, and also other cases = where multiple servers cooperate on handling a single connection. any such servers can already "reserve" such space by not forwarding = packets that exceed whatever limit they want to enforce - this is how = PMTUD works. Lars --Apple-Mail=_B7A1A176-9133-4A61-A53D-1716BDCB323C 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlqWw4IACgkQVLXDCb9w wVexPxAAkkbFPSRJn6gQ0QUrMP3RqI+6PHX3YynlTRDdjgHxbLV5Wb7b1QJ+Rsry gVm26i3B1SUnZUwo55JQX5WHW8D6Jn6wYulch+5R0awAfwLMxbuth9ldiksKVOfo MCSKb3hlzRhsqvhWH4Y9i5bh01gv0t8QAgCF0JOQdwbN1l5yabz4Hj0wqtiXUyaA 5Kur1rZowxdzUy+eIjUlHfWnHtE3uk2f/CRqGKRcE92YCYEjjVlBgQJov1ukOlhy in1F/S2e6izJH11ws7aRG46Yy954rkwEs8dkJ70Hci/gXeLUjhRUw/0W2G2CbedE G7KmeOaZ7gq9OErE/pgS206yvM/dJ89PuW+UlpKrnKJY6IBqDLa2DhiifWHk+toU xqlFOzi3M3YPWsbZ2vY8tpqf283T/GV/7QWyKJZVh4C7baXciE/Pt5mQtr0FIGzF Nf26Yxdq+3H8P8l9aSHUUhqs0IonvxOk2aAVfhhuXc6FSf5NaUqR50OxhCosEUl5 T2BDqLQW0ToboL+iMlSCE9TcW1hoXV7QCqzdlm5R9YilDwh+BIWHq0QIzVbOkK9z dzGCFpGhL9XFbSbHZ4Q/B1q3tW6g4Zw9uyw+ajdWPJviZByuwUDUaJ4pAKvzlhIR uacrq5ctObDTVJKdJ9sjW/Dk2mz2JHEGfS7sHILvn6EBeJ24s1U= =6HFg -----END PGP SIGNATURE----- --Apple-Mail=_B7A1A176-9133-4A61-A53D-1716BDCB323C-- From nobody Wed Feb 28 07:03:46 2018 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 BBEC5127599 for ; Wed, 28 Feb 2018 07:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 i-PAWv564P0C for ; Wed, 28 Feb 2018 07:03:43 -0800 (PST) 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 51E3D126E01 for ; Wed, 28 Feb 2018 07:03:43 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id d71so3525532iog.4 for ; Wed, 28 Feb 2018 07:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=fo+sb/AAYtkapBsNWim/gT/PEB/4CasFAMYnUVZybjU=; b=TcQwHotFRNRcT2apZtH3HJveeD8/AZcCsE2aspHmvkZDXsFQDk7HVZ2a37IPrxFTKW vtYcGZtNeykZPt0wquYZkY/gBP8VpPd/YR0D9gD06pxUTf1mmvVezwjq3eShgxn95Lpb tNIajneaOytZdKZk1qH0uJ55JB+qpbVI5wlKD5RHYG/WnZDVG/4Ai5+pD/qdq5Tq7h3v ZnCX4OTaeoHvK+aazhAxmzVXlo11ATqrsnRgA4oAnetkyYpIkWBjfH7RiNFd1YM3Ihro Tx0+Knir1YioYTyqvvO9Z4KjWI0bfhlIboGE6/tG8RQxIeLPs6ZnsP3AKT7sdpeSv0vl hQ0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=fo+sb/AAYtkapBsNWim/gT/PEB/4CasFAMYnUVZybjU=; b=GA5T/hEU91qEOMTKP981JNcin7hMXN6TPWboymHtnXswehUqv9uv2y2Z+tpgEmZOKN 4eENMFrNOiGIoTnc8lSvtOU8IkUHJBltcqExYcR3JTcqbPWOFbeL36r83Y4bP/LcTR9h /jsmu4T99yYLjXW6eaWPrDYVZ+JXfKVsqI+AJLGZOL4rQwzlsasdEDDQDab+xC7sC6Xj trhQZKDD+MIJr02jhSWOzHUdLy3zBuwSYlSP1FAacySVzSMuLWgBzxBABfF/ifdkPCh7 MlHV2ElZ6SglbQNlSgHY71XoeBur+BdY8hLyZ/dtJNgGjesp1eCtzW59vkNSI+tYwlzY AmzQ== X-Gm-Message-State: APf1xPCGjve3a1BxkLU6d0nXJUz0FZXNTbmAOHS5ZWvMSdoeUOs5L6M7 WtMGDTITB80j5/pwv5quJzUXZqUywP21VmNmvscRHw== X-Google-Smtp-Source: AH8x2242/a5dCUB1f/wplde2Toi41awcnJ7E1S6msmm+gN9xxLBAMXnmxMzBC8d4waDqOrH5vnlWWRf2gloKR5RO7Rk= X-Received: by 10.107.33.72 with SMTP id h69mr19688999ioh.209.1519830222578; Wed, 28 Feb 2018 07:03:42 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Feb 2018 07:03:41 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.com> References: <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.com> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 28 Feb 2018 07:03:41 -0800 Message-ID: Subject: Re: Space for Packet Metadata To: "Eggert, Lars" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1140f5e6892cdd0566470c43" 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, 28 Feb 2018 15:03:45 -0000 --001a1140f5e6892cdd0566470c43 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, but can it go below 1200? It seems the handshake aims to squeeze up near the minimum guaranteed (required) PMTU and QUIC implementations would probably not expect to maintain a connection that drops below PMTU 1200. I=E2=80=99m not saying it can=E2=80=99t work, rather I'm asking because I d= on=E2=80=99t think so. On 28 February 2018 at 15.58.39, Eggert, Lars (lars@netapp.com) wrote: any such servers can already "reserve" such space by not forwarding packets that exceed whatever limit they want to enforce - this is how PMTUD works. --001a1140f5e6892cdd0566470c43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Yes, but can it go b= elow 1200? It seems the handshake aims to squeeze up near the minimum guara= nteed (required) PMTU and QUIC implementations would probably not expect to= maintain a connection that drops below PMTU 1200.

I=E2=80=99m not saying it can=E2=80=99t work,= rather I'm asking because I don=E2=80=99t think so.

On 28 February 2018 at 15.58.39, Eggert, Lars (lars@netapp.com) wrote:

any such s= ervers can already "reserve" such space by not forwarding packets= that exceed whatever limit they want to enforce - this is how PMTUD works.= =C2=A0
--001a1140f5e6892cdd0566470c43-- From nobody Wed Feb 28 07:19:43 2018 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 94DE412D94B for ; Wed, 28 Feb 2018 07:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 s1h0E_iN46TB for ; Wed, 28 Feb 2018 07:19:26 -0800 (PST) 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 39D2312EB23 for ; Wed, 28 Feb 2018 07:19:26 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx62.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1er3Vm-000Ajl-4M for quic@ietf.org; Wed, 28 Feb 2018 16:19:18 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1er3Vh-0005HL-Dy for quic@ietf.org; Wed, 28 Feb 2018 10:19:16 -0500 Received: (qmail 20294 invoked from network); 28 Feb 2018 15:19:11 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.158]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Feb 2018 15:19:11 -0000 To: =?UTF-8?Q?Mikkel_Fahn=c3=b8e_J=c3=b8rgensen?= , "Eggert, Lars" Cc: IETF QUIC WG References: <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.com> From: Christian Huitema Message-ID: Date: Wed, 28 Feb 2018 07:19:09 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CCFEB3DDE7B2DA685D29C32A" Content-Language: en-US Subject: Re: Space for Packet Metadata X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5h88zKHxrliKrY8XNzN5pO1602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiViXpz0dH/WxyU/dajMfNk5Zs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBCnY1T4UEFfy74vbELeG6IB/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjSYb8Ll5Ew7esaVIVXxqL4mdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3upW940lL8kAcN44/h+EKQY5T+fsIz86TG72Lx5ZI1p INh8UHPssUrY3MbbkBcNcJO9YzGWVp9p+Opk9w8BAh9BxI/M6J4yAZL75BrNNq2wthpBOi7IfT+J o+6tsQI5W/ewkYi/XXej6UeAUN96sXI71lsFqhWb3P21BZ9jlHPbPCpCZDzbriLb09ArJ34XSivy hX2xfGWtxArAagg2yIWQOB6kNh2xMmXEi/DfgKmivtduw1uWwE7LyoeeLDBQmE9c9aUV1oY4fX3W 5eOCNA395VKQZZ28EUZBFBO/fNvHx7hwG59VyR4YOQV4JnKL5mXuymSkQySlRRw9754xJI2l7TrO wPFJd4XqI4y6kTdZJ/Tgs5pdKJpNpy9rpzw+UwWR2z7Rjs3BT1o4+6YSC6IfVgW9/bktU41htiJ8 fk7NkCSgONC3rqaXJrYXVXXByjf4baeCkx0hN8MDgAhE+CBnCUTZMc2PfI2VFTu1YYhfjg== 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, 28 Feb 2018 15:19:29 -0000 This is a multi-part message in MIME format. --------------CCFEB3DDE7B2DA685D29C32A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 2/28/2018 7:03 AM, Mikkel Fahnøe Jørgensen wrote: > Yes, but can it go below 1200? It seems the handshake aims to squeeze > up near the minimum guaranteed (required) PMTU and QUIC > implementations would probably not expect to maintain a connection > that drops below PMTU 1200. > > I’m not saying it can’t work, rather I'm asking because I don’t think so. > > On 28 February 2018 at 15.58.39, Eggert, Lars (lars@netapp.com > ) wrote: > >> any such servers can already "reserve" such space by not forwarding >> packets that exceed whatever limit they want to enforce - this is how >> PMTUD works.  What Lars said. If networks want to play game with extra forwarding overhead, they have to ensure that they can tunnel a min MTU packet, i.e. 1280 bytes. Which is not a problem since the local MTU is generally 1536 bytes, and there is no practical reason to have more than 200 bytes of overhead. -- Christian Huitema --------------CCFEB3DDE7B2DA685D29C32A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 2/28/2018 7:03 AM, Mikkel Fahnøe Jørgensen wrote:
Yes, but can it go below 1200? It seems the handshake aims to squeeze up near the minimum guaranteed (required) PMTU and QUIC implementations would probably not expect to maintain a connection that drops below PMTU 1200.

I’m not saying it can’t work, rather I'm asking because I don’t think so.

On 28 February 2018 at 15.58.39, Eggert, Lars (lars@netapp.com) wrote:

any such servers can already "reserve" such space by not forwarding packets that exceed whatever limit they want to enforce - this is how PMTUD works. 

What Lars said. If networks want to play game with extra forwarding overhead, they have to ensure that they can tunnel a min MTU packet, i.e. 1280 bytes. Which is not a problem since the local MTU is generally 1536 bytes, and there is no practical reason to have more than 200 bytes of overhead.

-- Christian Huitema
--------------CCFEB3DDE7B2DA685D29C32A-- From nobody Wed Feb 28 07:20:42 2018 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 24B8712EB1A for ; Wed, 28 Feb 2018 07:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 WKTi7WiJXVkT for ; Wed, 28 Feb 2018 07:20:40 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05ADE12EB19 for ; Wed, 28 Feb 2018 07:20:40 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.47,406,1515484800"; d="asc'?scan'208";a="240232021" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx142-out.netapp.com with ESMTP; 28 Feb 2018 07:12:41 -0800 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 28 Feb 2018 07:12:31 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 28 Feb 2018 07:12:32 -0800 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=L4A8J7+TlNpLqUQes5WdPvfEFZvEutWebFNKnqVBfvI=; b=kma2dgKWiCCqLd2HsGZjBWC0xMqUoJOEgw9Y2jtmecjyW7B9af0K2x6zfJIA4uHOBzIPbdM3olilTGjoe8CmwHWhme09mmDSnvenF/qpTPGpgXUCJgD4AjBaW3a4jYIsfQNKYuo0lC6H1swEr5ItauTP/1XQ/DrnArBqKOSSny0= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1731.namprd06.prod.outlook.com (10.162.224.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Wed, 28 Feb 2018 15:12:29 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004]) by BLUPR06MB1764.namprd06.prod.outlook.com ([fe80::14b2:cbc0:3674:e004%14]) with mapi id 15.20.0548.013; Wed, 28 Feb 2018 15:12:29 +0000 From: "Eggert, Lars" To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: IETF QUIC WG Subject: Re: Space for Packet Metadata Thread-Topic: Space for Packet Metadata Thread-Index: AQHTsGvskv2Pnqzz/UGWODiG1gaITqO56EAAgAABi4CAAAJ0AA== Date: Wed, 28 Feb 2018 15:12:29 +0000 Message-ID: References: <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.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.3445.5.20) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:360d:b01:a035:c8c2:34a2:c0de] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1731; 7:pexAgdq2MUq9e/YNDyczmNd0XswTriVupMD262qNmlgJBQspUbG/W6g4kJJs3lLJVPGPmUYxLZfYq9WyCIpAxZ1OWMHSXsY9w0d4aASj7J966yq/8ubnQLhczK/R4642M4uRGxTieBpSLcNtfNGzcLi6xADmnn5sOzCWRyhgO5r3qfFszHwF6abtQXIgSHQaTEGLQ2RFMIz7b9dZxRB4mqzgVEHUo3b8iIOP7IsD65WMU7fwl8NIIefKKHx6uKuK x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6d954b1c-6425-42bd-1da5-08d57ebdaf48 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(49563074)(7193020); SRVR:BLUPR06MB1731; x-ms-traffictypediagnostic: BLUPR06MB1731: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(102415395)(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(3231220)(944501217)(6055026)(6041288)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:BLUPR06MB1731; BCL:0; PCL:0; RULEID:; SRVR:BLUPR06MB1731; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(346002)(39860400002)(39380400002)(377424004)(189003)(199004)(316002)(6506007)(53546011)(14454004)(102836004)(76176011)(186003)(53936002)(97736004)(4001150100001)(8676002)(8936002)(81156014)(3480700004)(478600001)(99286004)(68736007)(25786009)(82746002)(39060400002)(6916009)(6512007)(2950100002)(229853002)(6436002)(6486002)(5660300001)(81166006)(1411001)(4326008)(105586002)(106356001)(83716003)(6246003)(86362001)(3660700001)(33656002)(305945005)(7736002)(5250100002)(6116002)(2906002)(50226002)(3280700002)(2900100001)(99936001)(57306001)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1731; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: CssimExxRF0w120AnJTHWb7AnpiKfq7XfhP8E3HNaW4FDAzH2pkrSZyr+myjJ5C+3hEZz765pGR7jmI0O+hcaRXwUc3U4af/KqhDn/RB9vE2/6ciT763JPIwDcuqmBmKTbnDX/K6yITD6zDBtsx53puqFtjfzr4i0mwtoKojOgE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_F10C63DD-60D5-4FDB-8BC2-D0F1A5698700"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6d954b1c-6425-42bd-1da5-08d57ebdaf48 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 15:12:29.5575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1731 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, 28 Feb 2018 15:20:41 -0000 --Apple-Mail=_F10C63DD-60D5-4FDB-8BC2-D0F1A5698700 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 2018-2-28, at 16:03, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: > Yes, but can it go below 1200? It seems the handshake aims to squeeze = up near the minimum guaranteed (required) PMTU and QUIC implementations = would probably not expect to maintain a connection that drops below PMTU = 1200. The minimum IPv4 MTU is 576, so I'd expect QUIC stacks to probe as least = that low. Lars --Apple-Mail=_F10C63DD-60D5-4FDB-8BC2-D0F1A5698700 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlqWxtwACgkQVLXDCb9w wVfGMBAA0oV4ttou0tp77elbd5jX8JNKXN/rBKN2COXyBzL08N7LIiTnWKIY0eqt uJqSfxnIyN7MyuUU9PsBX9D/xKagHLbJKdMiRC46NxvTyo+3mxcb9qXNv23efAu6 6sN9J9eRutz9vnZnh9cvZVUN6NJQfxXa02H9Uv1bPu0FKHVmbZ+TftQs0gLfq++X hkL9WRujJsAQZvkjg4acWXwarzWlKp5HZ/Vw5/obU+Uq79Wtgwym3i8Odxe3Pr0V c/FZxMv5kttOsGOi+oLPg4tiB9men1zRf2GOfwYi/uMmGINvLhSQ/yoBkAi2eoPn 6ruY+UZqHZIQctEhX2DYWiCsffrhUag1h9gk3Y8t4/mPlBvVH9eEF9pmAxuEcsPG g9gXBj4Jr+GAuZLvZqhhhrR9IsO93wa7qStM0KJxbUTHN1Uh0DlE5sfIyDusY/F9 TYzNWT/SrScU/fQiQhC9ShNGhtHQC8uOjDCD3+jzetDhV7h1aZjEZlRLE6O5odnm M+U0ombzDD9UewZD66EnJ+q02/hGcIxxIIqEXLhMmbHoQQcSNPht0nOs2OCpngAp ppilWZZBMw9CHRMNP8CPP7yjceVla/w7cSTdBdJVE6e++p8lc/iJEzk3MDuft+5N ilpV/m60QtbW6VqOMCfmaXR/u2wwp5RDHC62CHhPTdnvn7in9qg= =6o0l -----END PGP SIGNATURE----- --Apple-Mail=_F10C63DD-60D5-4FDB-8BC2-D0F1A5698700-- From nobody Wed Feb 28 07:30:29 2018 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 0775312D94B for ; Wed, 28 Feb 2018 07:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_H2=-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 fGid_xUk7fwr for ; Wed, 28 Feb 2018 07:30:25 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0112.outbound.protection.outlook.com [104.47.36.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C8F12D88F for ; Wed, 28 Feb 2018 07:30:25 -0800 (PST) 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=ZIti8agxQKI3tbwpTAf98vMbgCIJP8Hr1GLg3XWbYO4=; b=QJB6w6mM0dL6BfQk2kZm2Dr5ekwtnoGpVrfMZ2GO7/SioKLjMkQDzCK0JGceOmnfviZu5MQK2GMjgq5aP9mcs287t96/+C/Ln3+SnytULfrg+gFna7AVTvq80mkbRbQtxV4brqDWxSAXkdvX81RcUJi/fi+QMK8o1NUlryoiz+I= Received: from DM5PR2101MB0901.namprd21.prod.outlook.com (52.132.132.158) by DM5PR2101MB0934.namprd21.prod.outlook.com (52.132.131.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.2; Wed, 28 Feb 2018 15:30:23 +0000 Received: from DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9d7c:b4dd:491b:8eed]) by DM5PR2101MB0901.namprd21.prod.outlook.com ([fe80::9d7c:b4dd:491b:8eed%2]) with mapi id 15.20.0567.006; Wed, 28 Feb 2018 15:30:23 +0000 From: Nick Banks To: "Eggert, Lars" , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: IETF QUIC WG Subject: RE: Space for Packet Metadata Thread-Topic: Space for Packet Metadata Thread-Index: AQHTsGvRMp9GK9zAp0uoJUE8y9Y2PKO56EKAgAABiYCAAAJ2gIAABMiw Date: Wed, 28 Feb 2018 15:30:23 +0000 Message-ID: References: <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2018-02-28T15:30:21.9795573Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:b::1d5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR2101MB0934; 7:WC4z2ojQy/hm74/UaYlyXcUrO3WVo/nnFiZyDlOCDN6LO7magKNgf+XP2OK7vCZqJWiaFAeh0zAkgNWL85QDtsUlzpllvKjtCoAMkM73Euqw381e2AMMZI6BUWLGb8c2ehD9I6y903q/xqsi4SAjbRbwPwfTU/jCaUiiBkC/CUBJkgcfiRCPgidKqsK3llD9GTfDbnVgkr6Yfw6PKB0c9MAmPJxXuXgJkHfQz6OTRYp+Qs9sgLC5Nbj3z4S45iGD x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4880506c-e2c6-4ad1-6ade-08d57ec02f52 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:DM5PR2101MB0934; x-ms-traffictypediagnostic: DM5PR2101MB0934: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231220)(944501217)(52105095)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR2101MB0934; BCL:0; PCL:0; RULEID:; SRVR:DM5PR2101MB0934; x-forefront-prvs: 0597911EE1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(346002)(39380400002)(376002)(366004)(189003)(377424004)(199004)(13464003)(3280700002)(10290500003)(81166006)(8936002)(229853002)(8990500004)(86362001)(81156014)(68736007)(74316002)(186003)(39060400002)(93886005)(305945005)(14454004)(4001150100001)(2900100001)(478600001)(105586002)(3480700004)(2950100002)(3660700001)(33656002)(8676002)(4326008)(6436002)(97736004)(5660300001)(25786009)(7736002)(5250100002)(110136005)(22452003)(53546011)(102836004)(6246003)(59450400001)(10090500001)(6346003)(53936002)(9686003)(99286004)(7696005)(76176011)(86612001)(55016002)(316002)(2906002)(106356001)(6116002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR2101MB0934; H:DM5PR2101MB0901.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-message-info: VHrjnyCwFEeMZVq7VwW/OZKzkL8F/1xamyWrleO01DnGDxRaP21RlYiWFMwGLCo4wGQuJ63tvqbktUZ6ViiL1AqEM/hoPA55GMotyCApGvE1GHiiKRPJxcXs4at7/G29BMx8QIEpB7ntzCh9ufG0KET7JJfLLlufYTF+CbgjdGE= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4880506c-e2c6-4ad1-6ade-08d57ec02f52 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 15:30:23.4138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR2101MB0934 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, 28 Feb 2018 15:30:27 -0000 QWNjb3JkaW5nIHRvIHNwZWMsIFFVSUMgcmVxdWlyZXMgYXQgbGVhc3QgMTI4MCAoZnJvbSA5LjQp Og0KDQoiUVVJQyBkZXBlbmRzIG9uIHRoZSBuZXR3b3JrIHBhdGggc3VwcG9ydGluZyBhIE1UVSBv ZiBhdCBsZWFzdCAxMjgwIG9jdGV0cy4gVGhpcyBpcyB0aGUgSVB2NiBtaW5pbXVtIE1UVSBhbmQg dGhlcmVmb3JlIGFsc28gc3VwcG9ydGVkIGJ5IG1vc3QgbW9kZXJuIElQdjQgbmV0d29ya3MuIEFu IGVuZHBvaW50IE1VU1QgTk9UIHJlZHVjZSBpdHMgTVRVIGJlbG93IHRoaXMgbnVtYmVyLCBldmVu IGlmIGl0IHJlY2VpdmVzIHNpZ25hbHMgdGhhdCBpbmRpY2F0ZSBhIHNtYWxsZXIgbGltaXQgbWln aHQgZXhpc3QuJw0KDQotIE5pY2sNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFFVSUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEVnZ2VydCwgTGFycw0K U2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAyOCwgMjAxOCA3OjEyIEFNDQpUbzogTWlra2VsIEZh aG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPg0KQ2M6IElFVEYgUVVJQyBXRyA8 cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBTcGFjZSBmb3IgUGFja2V0IE1ldGFkYXRhDQoN Ck9uIDIwMTgtMi0yOCwgYXQgMTY6MDMsIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tl bGZqQGdtYWlsLmNvbT4gd3JvdGU6DQo+IFllcywgYnV0IGNhbiBpdCBnbyBiZWxvdyAxMjAwPyBJ dCBzZWVtcyB0aGUgaGFuZHNoYWtlIGFpbXMgdG8gc3F1ZWV6ZSB1cCBuZWFyIHRoZSBtaW5pbXVt IGd1YXJhbnRlZWQgKHJlcXVpcmVkKSBQTVRVIGFuZCBRVUlDIGltcGxlbWVudGF0aW9ucyB3b3Vs ZCBwcm9iYWJseSBub3QgZXhwZWN0IHRvIG1haW50YWluIGEgY29ubmVjdGlvbiB0aGF0IGRyb3Bz IGJlbG93IFBNVFUgMTIwMC4NCg0KVGhlIG1pbmltdW0gSVB2NCBNVFUgaXMgNTc2LCBzbyBJJ2Qg ZXhwZWN0IFFVSUMgc3RhY2tzIHRvIHByb2JlIGFzIGxlYXN0IHRoYXQgbG93Lg0KDQpMYXJzDQo= From nobody Wed Feb 28 07:55:12 2018 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 2E92B12EB22 for ; Wed, 28 Feb 2018 07:55:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-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 fwSt409b9SUg for ; Wed, 28 Feb 2018 07:55:07 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9825B12EB18 for ; Wed, 28 Feb 2018 07:55:07 -0800 (PST) Received: from [IPv6:2003:cd:6bf1:8000:903f:9f02:36d3:5f06] (p200300CD6BF18000903F9F0236D35F06.dip0.t-ipconnect.de [IPv6:2003:cd:6bf1:8000:903f:9f02:36d3:5f06]) (Authenticated sender: lurchi) by mail-n.franken.de (Postfix) with ESMTPSA id CE46F721E280C; Wed, 28 Feb 2018 16:55:03 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: Space for Packet Metadata From: Michael Tuexen In-Reply-To: Date: Wed, 28 Feb 2018 16:55:02 +0100 Cc: "Eggert, Lars" , =?utf-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <5DB55652-7509-4026-B678-30EACFEB6380@lurchi.franken.de> References: <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.com> To: Nick Banks X-Mailer: Apple Mail (2.3445.5.20) 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, 28 Feb 2018 15:55:10 -0000 > On Feb 28, 2018, at 4:30 PM, Nick Banks wrote: >=20 > According to spec, QUIC requires at least 1280 (from 9.4): >=20 > "QUIC depends on the network path supporting a MTU of at least 1280 = octets. This is the IPv6 minimum MTU and therefore also supported by = most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below = this number, even if it receives signals that indicate a smaller limit = might exist.' When discussing safe MTU values for WebRTC, 1280 for IPv6 was = acceptable, but not for IPv4. After a discussion, the suggested value for IPv4 was 1200. See https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 Not sure what changed in between... Best regards Michael >=20 > - Nick >=20 > -----Original Message----- > From: QUIC On Behalf Of Eggert, Lars > Sent: Wednesday, February 28, 2018 7:12 AM > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen > Cc: IETF QUIC WG > Subject: Re: Space for Packet Metadata >=20 > On 2018-2-28, at 16:03, Mikkel Fahn=C3=B8e J=C3=B8rgensen = wrote: >> Yes, but can it go below 1200? It seems the handshake aims to squeeze = up near the minimum guaranteed (required) PMTU and QUIC implementations = would probably not expect to maintain a connection that drops below PMTU = 1200. >=20 > The minimum IPv4 MTU is 576, so I'd expect QUIC stacks to probe as = least that low. >=20 > Lars From nobody Wed Feb 28 08:04:39 2018 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 C632312D0C3 for ; Wed, 28 Feb 2018 08:04:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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, UNPARSEABLE_RELAY=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 7Y6F3YXqOuTa for ; Wed, 28 Feb 2018 08:04:36 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::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 B0955124B17 for ; Wed, 28 Feb 2018 08:04:36 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id l187so4112488ith.4 for ; Wed, 28 Feb 2018 08:04:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=6ZTCBxyKbsDQPamsFyjyNXArr0pi3zO2SFjD7elK/uQ=; b=qmMJnc7gR3VF0k6pUhJiTzsC7ejqKMSlfrTlIJj19OStLE9JNvxPZ8HNrnYQz4ZWHO DH3SY0VnmOE4lfcLTh1Wao/+S5WDBqmoqgxx6bG7j8d8SDVsV4p6bqvKnMhRDs98GIPu nUbSJCnNQg+sw4beRwLfZ1FwiSTMf53gBLicFaVo+Kzzt84IPNgkKi1ieByMghVOvnln aN53WIz2tagMgqFLb/YOQGR7yqNhe97KGlRI5Z1guSdcnx/03fdfcTezEi5M+5TtNdgQ ZQJuPe6IwIDcGyvwpmCnrtdMErVaGQlU1hQBdJIu5pHW76lrlsLs0cOf8dFWqSJQcRfY evIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=6ZTCBxyKbsDQPamsFyjyNXArr0pi3zO2SFjD7elK/uQ=; b=AfbazyNeTvM6wEu0JJeMGz28SvbYTndvcFMeElCaSvCAC9kiEearqYjdax0l5fX0/L 88K4u6ECS6JuW8fcbzpDiL/nrcJB5n/EN47Nirlr6ihKZkiNu6lWJRWsqNlL1ZBKnhtm 2qcTv2LZiAE1v5afi0CKLkojmEuZ4nHmb5MP3uOBiVLViQmGc/is5wV8YTlbdQYiSHFR BHn03M8MPRzU1nTK8+cOzcvpAF77lmvyVp8mKLLz2O5jGN85qxQ4p6fMBcIH788L8dFm pUAvYNosR5Y5gQpiPRfkxv94lnE7vIf7NR0jJYrV/87GGIESHgTE7SLaACaitiC33xRu 4mOA== X-Gm-Message-State: APf1xPA3+vOAVU7h12tvqCKvfzXEaDFpz/rMTXMTN8o6C7C+ye1eD24/ VYNlIVIb/pJwP/6o39K5d42Y3lGZTobwDE4J2U8= X-Google-Smtp-Source: AG47ELudbZBTmaobNJbpO2ouqM5dhNMw6jTZpdSQrAVnvs5VrliHeP4W5VSqN75hozg+NO/KjH10kQKZx21AyIYgnwM= X-Received: by 10.36.90.212 with SMTP id v203mr2355851ita.150.1519833876076; Wed, 28 Feb 2018 08:04:36 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 28 Feb 2018 08:04:35 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <5DB55652-7509-4026-B678-30EACFEB6380@lurchi.franken.de> References: <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.com> <5DB55652-7509-4026-B678-30EACFEB6380@lurchi.franken.de> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Wed, 28 Feb 2018 08:04:35 -0800 Message-ID: Subject: Re: Space for Packet Metadata To: Nick Banks , Michael Tuexen Cc: IETF QUIC WG , "Eggert, Lars" Content-Type: multipart/alternative; boundary="001a1143b9b04d2184056647e6dd" 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, 28 Feb 2018 16:04:39 -0000 --001a1143b9b04d2184056647e6dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable https://blogs.cisco.com/enterprise/ipv6-mtu-gotchas-and-other-icmp-issues IPV6 UDP overhead is 48 bytes https://en.wikipedia.org/wiki/User_Datagram_Protocol Minimum expected PMTU is 1280 bytes (and required by QUIC) Local MTU expected 1536 bytes 1536 - 48 =3D 1488 1488 - 1280 =3D 208 bytes So there is already 208 bytes reserved for tunnelling etc. Which is fine. Exactly what I was asking for. On 28 February 2018 at 16.55.05, Michael Tuexen ( michael.tuexen@lurchi.franken.de) wrote: > On Feb 28, 2018, at 4:30 PM, Nick Banks wrote: > > According to spec, QUIC requires at least 1280 (from 9.4): > > "QUIC depends on the network path supporting a MTU of at least 1280 octets. This is the IPv6 minimum MTU and therefore also supported by most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below this number, even if it receives signals that indicate a smaller limit might exist.' When discussing safe MTU values for WebRTC, 1280 for IPv6 was acceptable, but not for IPv4. After a discussion, the suggested value for IPv4 was 1200. See https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-5 Not sure what changed in between... Best regards Michael > > - Nick > > -----Original Message----- > From: QUIC On Behalf Of Eggert, Lars > Sent: Wednesday, February 28, 2018 7:12 AM > To: Mikkel Fahn=C3=B8e J=C3=B8rgensen > Cc: IETF QUIC WG > Subject: Re: Space for Packet Metadata > > On 2018-2-28, at 16:03, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: >> Yes, but can it go below 1200? It seems the handshake aims to squeeze up near the minimum guaranteed (required) PMTU and QUIC implementations would probably not expect to maintain a connection that drops below PMTU 1200. > > The minimum IPv4 MTU is 576, so I'd expect QUIC stacks to probe as least that low. > > Lars --001a1143b9b04d2184056647e6dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = https://b= logs.cisco.com/enterprise/ipv6-mtu-gotchas-and-other-icmp-issues<= div id=3D"bloop_customfont" style=3D"font-family:Helvetica,Arial;font-size:= 13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto">
IPV6 UDP overhead is 48 b= ytes=C2=A0= https://en.wikipedia.org/wiki/User_Datagram_Protocol

Minimum expecte= d PMTU is 1280 bytes (and required by QUIC)
Local MTU expected 15= 36 bytes

1536 - 48 =3D 1488
1488 - 1280 = =3D 208 bytes

So there is already 208 bytes reserv= ed for tunnelling etc. Which is fine. Exactly what I was asking for.
<= div id=3D"bloop_sign_1519833506955880192" class=3D"bloop_sign">


On 28 February 2018 at 16.55.05, Michael Tuexen (michael.tuexen@lurchi.franken.= de) wrote:

=
> On Feb 28, 2018, at 4:30 PM, Nick Banks <nibanks@microsoft.com> wrote:
> =20
> According to spec, QUIC requires at least 1280 (from 9.4):
> =20
> "QUIC depends on the network path supporting a MTU of at leas= t 1280 octets. This is the IPv6 minimum MTU and therefore also supported by= most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below this = number, even if it receives signals that indicate a smaller limit might exi= st.'
When discussing safe MTU values for WebRTC, 1280 for IPv6 was acceptabl= e, but not for IPv4. After a discussion,
the suggested value for IPv4 was 1200. See
https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#= section-5

Not sure what changed in between...

Best regards
Michael
> =20
> - Nick
> =20
> -----Original Message-----
> From: QUIC <quic-bounc= es@ietf.org> On Behalf Of Eggert, Lars
> Sent: Wednesday, February 28, 2018 7:12 AM
> To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
> Cc: IETF QUIC WG <quic@ietf.or= g>
> Subject: Re: Space for Packet Metadata
> =20
> On 2018-2-28, at 16:03, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
>> Yes, but can it go below 1200? It seems the handshake aims to = squeeze up near the minimum guaranteed (required) PMTU and QUIC implementat= ions would probably not expect to maintain a connection that drops below PM= TU 1200.
> =20
> The minimum IPv4 MTU is 576, so I'd expect QUIC stacks to prob= e as least that low.
> =20
> Lars

--001a1143b9b04d2184056647e6dd-- From nobody Wed Feb 28 08:07:29 2018 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 5768912DB6B for ; Wed, 28 Feb 2018 08:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 ZkkhDWjus7L3 for ; Wed, 28 Feb 2018 08:07:25 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id B0B3D124B17 for ; Wed, 28 Feb 2018 08:07:25 -0800 (PST) Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 022CB1B00056; Wed, 28 Feb 2018 16:06:49 +0000 (GMT) Message-ID: <5A96D399.4010300@erg.abdn.ac.uk> Date: Wed, 28 Feb 2018 16:06:49 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Nick Banks CC: "Eggert, Lars" , =?UTF-8?B?TWlra2VsIEZhaG7DuGUgSsO4cg==?= =?UTF-8?B?Z2Vuc2Vu?= , IETF QUIC WG Subject: Re: Space for Packet Metadata References: <96577B0E-502B-4723-9A9B-63D8B365D5AA@netapp.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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, 28 Feb 2018 16:07:28 -0000 For IPv6 that may be fine. The QUIC transport paper (*) Section 7.1 speaks of "Packet Size Consideration"- as far as I know this is just UDP traffic from google Chrome clients to google servers. They showed 3% unreachable for 1200 B payloads. Other networks could well be different. We are in the midst of a large measurement campaign related to our work in TSVWG on path MTU discovery. I would expect a wide variety of Path MTUs - even though the current majority of paths will support 1280 bytes, many IPv4 paths do not - there are also many paths that support much more. Gorry * http://delivery.acm.org/10.1145/3100000/3098842/p183-Langley.pdf?ip=212.159.18.54&id=3098842&acc=OA&key=4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35%2E5945DC2EABF3343C&__acm__=1519833743_fa365ff0c9cc6c6e266add2dba8f385f On 28/02/2018, 15:30, Nick Banks wrote: > According to spec, QUIC requires at least 1280 (from 9.4): > > "QUIC depends on the network path supporting a MTU of at least 1280 octets. This is the IPv6 minimum MTU and therefore also supported by most modern IPv4 networks. An endpoint MUST NOT reduce its MTU below this number, even if it receives signals that indicate a smaller limit might exist.' > > - Nick > > -----Original Message----- > From: QUIC On Behalf Of Eggert, Lars > Sent: Wednesday, February 28, 2018 7:12 AM > To: Mikkel Fahnøe Jørgensen > Cc: IETF QUIC WG > Subject: Re: Space for Packet Metadata > > On 2018-2-28, at 16:03, Mikkel Fahnøe Jørgensen wrote: >> Yes, but can it go below 1200? It seems the handshake aims to squeeze up near the minimum guaranteed (required) PMTU and QUIC implementations would probably not expect to maintain a connection that drops below PMTU 1200. > The minimum IPv4 MTU is 576, so I'd expect QUIC stacks to probe as least that low. > > Lars From nobody Wed Feb 28 16:40:04 2018 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 E59911272E1 for ; Wed, 28 Feb 2018 16:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-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=evequefou.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 1BK6fEKguOCO for ; Wed, 28 Feb 2018 16:40:01 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0126.outbound.protection.outlook.com [104.47.36.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A62C12711A for ; Wed, 28 Feb 2018 16:40:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VnLntNsZ39Jj/bdkEykYfJ+MoUeRqHErEy/WQYP6R5Q=; b=d3JS2qvcaosQz/01ApCv3K44lm3vE6n5d+sIHi4vhEKX297EicGOGTIQJ6q4fPHCVyWPZtHyDh9jyEnB1bBD9JTkriCeBe/V/dXdEUvIgbnNlGdNUm+7rcBPchKZUlPSgBW2glcovdW9ur8xGKH4uQWpW+67L1NfurNYxxVhk2I= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB3584.namprd08.prod.outlook.com (10.164.203.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.527.15; Thu, 1 Mar 2018 00:39:58 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([fe80::5410:deca:3ee5:983f]) by MWHPR08MB2432.namprd08.prod.outlook.com ([fe80::5410:deca:3ee5:983f%16]) with mapi id 15.20.0527.021; Thu, 1 Mar 2018 00:39:57 +0000 From: Mike Bishop To: QUIC WG Subject: QCRAM Review Request: PR #1141 Thread-Topic: QCRAM Review Request: PR #1141 Thread-Index: AdOw7SHmzhNvawT0SnaeDYyjVrIBRA== Date: Thu, 1 Mar 2018 00:39:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB3584; 7:HpORCLLAnx1mjh+tC53mZA4jToukfxTjSXz00qIa/T2yewZjH6KeBIrXx9AH4m+Ta0lWhfA4EFP+GSxCTNj5J0+6yhv/XyfTtFplXnBhwx19oIB1lCMNOVLLMGyET3Dt5rSSIijYC+BQgbeVLWHNZnkYVI7VZ8Y003uIM5DGMS98oUORAqduGp9XUBCaXiJ9Zf5v//FBHCL2yzkTeHr5Cu09hVnXldlpZU5mbP1v9SmcG5DSM9nhIc6jiWpJdEy+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4b5505e7-7541-4072-bb7e-08d57f0cf597 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR08MB3584; x-ms-traffictypediagnostic: MWHPR08MB3584: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(3231220)(944501221)(52105095)(93006095)(93001095)(10201501046)(6041288)(20161123564045)(20161123562045)(20161123560045)(20161123558120)(2016111802025)(6072148)(6043046)(201708071742011); SRVR:MWHPR08MB3584; BCL:0; PCL:0; RULEID:; SRVR:MWHPR08MB3584; x-forefront-prvs: 05986C03E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400003)(366004)(376002)(346002)(39380400002)(396003)(199004)(189003)(14454004)(966005)(8936002)(81166006)(6306002)(54896002)(86362001)(9686003)(53946003)(81156014)(478600001)(8676002)(74482002)(5250100002)(186003)(33656002)(55016002)(606006)(25786009)(6506007)(106356001)(6116002)(3846002)(59450400001)(790700001)(5660300001)(6916009)(102836004)(7696005)(66066001)(97736004)(26005)(7736002)(236005)(74316002)(6436002)(99286004)(2906002)(3660700001)(3280700002)(68736007)(105586002)(2900100001)(53936002)(316002)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB3584; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: WkYOa2y+0gM3zjoZuSJyTIh/W4wHG2qnB41kcnfjDo7gpKuK+iGyDN1SDye5Ss19tPTEPSwv9FtRtFw4lsJt01YoOhp80vmzkFZEM+KIY4XRu2H3ZmLO0uZl5CwWN/+aJ/s6/HElYqKjCnBPTQNfzCQJjfk2obY210xyMZsEy6Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB24325CADE88C887A869F65F1DAC60MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 4b5505e7-7541-4072-bb7e-08d57f0cf597 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2018 00:39:57.7458 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB3584 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 Mar 2018 00:40:04 -0000 --_000_MWHPR08MB24325CADE88C887A869F65F1DAC60MWHPR08MB2432namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable https://github.com/quicwg/base-drafts/pull/1141 One suggestion from Martin's implementation feedback that has been mentione= d before is reworking the QCRAM instruction space. The QCRAM draft uses th= e HPACK instructions, except that it cannibalizes table size changes for th= e Duplicate instruction. That leads to some inefficiency with the separate= streams, since you have to validate that instructions aren't used on the w= rong stream and some of the opcode space is wasted on each stream. This PR observes that each stream has a fully disjoint set of commands from= the other: * Table updates * Insert with Name Reference from Static Table * Insert with Name Reference from Dynamic Table * Insert without Name Reference * Duplicate * Change table size * Header blocks * Indexed entry from Static * Indexed entry from Dynamic * Literal with Name Reference from Static Table * Literal with Name Reference from Static Table, Never Indexed * Literal with Name Reference from Dynamic Table * Literal with Name Reference from Dynamic Table, Never Indexed * Literal without Name Reference * Literal without Name Reference, Never Indexed The PR takes advantage of the disjoint space to rework the opcodes in hopes= of saving bytes on common instructions. It does this in two ways: * Uses a bit in the opcode to differentiate static versus dynamic table= s, instead of concatenating them * Gives us the future option to make the static table longer without= hurting the dynamic table performance * Uses a bit in the opcode to identify string literals, instead of usin= g a sentinel value of zero * Requires modifying the HPACK string definition to not require byte= alignment at the beginning * Gives us the future option to make the tables zero-based instead o= f one-based * Makes indexing easier to explain in a future PR Here's the impact: Operation HPACK QCRAM PR#1141 Impact Table updates Insert with Name Reference from Static Table "01" + index < 62 "01" + index < 62 "11" + index Same Insert with Name Reference from Dynamic Table "01" + index >=3D 62 (one byte for first 2 entries, then 2 bytes) "01" + index >=3D 62 (one byte for first 2 entries, then 2 bytes) "10" + index (one byte for first 64 entries) One byte saved for 62 of 64 most recent entries Insert without Name Reference "01000000" "01000000" "01" One byte saved for header names < 32 octets Duplicate Not supported "001" + index >=3D 62 "000" + index Moot; you're unlikely to duplicate recent entries Change table size "001" Not supported "001" Same Header blocks Indexed entry from Static "1" + index < 62 "1" + index < 62 "11" + index Same Indexed entry from Dynamic "1" + index >=3D 62 "1" + index >=3D 62 "10" + index One byte longer for indices 62-63 Literal with Name Reference from Static Table "0000" + index < 62 (two bytes for index > 15) "0000" + index < 62 (two bytes for index > 15) "0001" + index Same Literal with Name Reference from Static Table, Never Indexed "0001" + index < 62 (two bytes for index > 15) "0001" + index < 62 (two bytes for index > 15) "0011" + index Same Literal with Name Reference from Dynamic Table "0000" + index >=3D 62 (always 2+ bytes) "0000" + index >=3D 62 (always 2+ bytes) "0000" + index One byte saved for first 15 entries Literal with Name Reference from Dynamic Table, Never Indexed "0001" + index > 62 (always 2+ bytes) "0001" + index > 62 (always 2+ bytes) "0010" + index One byte saved for first 15 entries Literal without Name Reference "00000000" "00000000" "010" One byte saved for header names < 16 octets Literal without Name Reference, Never Indexed "00010000" "00010000" "011" One byte saved for header names < 16 octets There's been some churn on the PR today as Martin and I worked some of this= out, so please give it a read (or another read) now and provide feedback. Thanks! --_000_MWHPR08MB24325CADE88C887A869F65F1DAC60MWHPR08MB2432namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

https://github.com/quicwg/base-drafts/pull/1141

 

One suggestion from Martin’s implementation fe= edback that has been mentioned before is reworking the QCRAM instruction sp= ace.  The QCRAM draft uses the HPACK instructions, except that it cann= ibalizes table size changes for the Duplicate instruction.  That leads to some inefficiency with the separate strea= ms, since you have to validate that instructions aren’t used on the w= rong stream and some of the opcode space is wasted on each stream.

 

This PR observes that each stream has a fully disjoi= nt set of commands from the other:

  • Table updates
    • Insert with Name Reference from Static Table
    • Ins= ert with Name Reference from Dynamic Table
    • Insert with= out Name Reference
    • Duplicate
    • Cha= nge table size
  • Header blocks
    • Indexed entry from Static
    • Indexed entry from Dyn= amic
    • Literal with Name Reference from Static Table
    • Literal with Name Reference from Static Table, Never Inde= xed
    • Literal with Name Reference from Dynamic Table
    • Literal with Name Reference from Dynamic Table, Never Ind= exed
    • Literal without Name Reference
      • Literal without Name Reference, Never Indexed

 

The PR takes advantage of the disjoint space to rewo= rk the opcodes in hopes of saving bytes on common instructions.  It do= es this in two ways:

  • Uses a bit in the opcode to differentiate static versus dynamic table= s, instead of concatenating them
    • Gives us the future option to make the static table longer without hu= rting the dynamic table performance
  • Uses a bit in the opcode to identify string literals, instead of= using a sentinel value of zero
    • Requires modifying the HPACK string definition to not require byte al= ignment at the beginning
    • Gives us the future option to= make the tables zero-based instead of one-based
    • Mak= es indexing easier to explain in a future PR

 

Here’s the impact:

 

Operation

HPACK

QCRAM

PR#1141

Impact

Table updates

 

 

 

 

Insert with Name Reference from Static Table=

“01” + index < 62

“01” + index < 62

“11” + index

Same

Insert with Name Reference from Dynamic Table

“01” + index >=3D 62

(one byte for first 2 entries, then 2 bytes)

“01” + index >=3D 62

(one byte for first 2 entries, then 2 bytes)

“10” + index

(one byte for first 64 entries)

One byte saved for 62 = of 64 most recent entries

Insert without Name Reference

“01000000”

“01000000”

“01”

 

One byte saved for hea= der names < 32 octets

Duplicate

Not supported

“001” + index >=3D 62<= /p>

“000” + index

Moot; you’re unlikely to duplicate recent entr= ies

Change table size

“001”

Not supported

“001”

Same

Header blocks=

 

 

 

 

Indexed entry from Static

“1” + index < 62

“1” + index < 62

“11” + index

Same

Indexed entry from Dynamic

“1” + index >=3D 62

“1” + index >=3D 62

“10” + index

One byte longer for in= dices 62-63

Literal with Name Reference from Static Table

“0000” + index < 62

(two bytes for index > 15)

“0000” + index < 62

(two bytes for index > 15)

“0001” + index

Same

Literal with Name Reference from Static Table, Ne= ver Indexed

“0001” + index < 62

(two bytes for index > 15)

“0001” + index < 62

(two bytes for index > 15)

“0011” + index

Same

Literal with Name Reference from Dynamic Table

“0000” + index >=3D 62=

(always 2+ bytes)

“0000” + index >=3D 62=

(always 2+ bytes)

“0000” + index

One byte saved for fir= st 15 entries

Literal with Name Reference from Dynamic Table, N= ever Indexed

“0001” + index > 62

(always 2+ bytes)

“0001” + index > 62

(always 2+ bytes)

“0010” + index

One byte saved for fir= st 15 entries

Literal without Name Reference

“00000000”

“00000000”

“010”

One byte saved for hea= der names < 16 octets

Literal without Name Reference, Never Indexed

“00010000”

“00010000”

“011”

One byte saved for hea= der names < 16 octets

 

There’s been some churn on the PR today as Mar= tin and I worked some of this out, so please give it a read (or another rea= d) now and provide feedback.

 

Thanks!

--_000_MWHPR08MB24325CADE88C887A869F65F1DAC60MWHPR08MB2432namp_--