From nobody Tue Nov 1 17:24:30 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC17129959 for ; Tue, 1 Nov 2016 17:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CW4r9vBZbHKi for ; Tue, 1 Nov 2016 17:24:26 -0700 (PDT) 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 BDB3A127078 for ; Tue, 1 Nov 2016 17:24:25 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id b35so121919uaa.3 for ; Tue, 01 Nov 2016 17:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=zqcxsHGz4Kr95rFbZtgQzoRPPUqlgTuHpeERWR/xC4k=; b=nK2XGBBwCAqAWtF/KesmFYjL02w871p84weygYnFDl+oRLOJrqiPp1UQB82BM/rGG9 sqqrzMLs7isw9RdHH+YixYncCCcMkJwj2jewVGKXBvq7W0mzSNRJLCddk2PI3H27VdJ0 3Seah1jcx7Mje7rElyN8e8ZDXtl+gjt87lkDV0aQpm/ky0nIKWL2BB90AkHzzadg3ISL EaCcEmU6ru07uWLR7SnYtHQ2JRsJCb/pilJPWKxG/Da50iik8qaR2RjDHXryYVM5+r5P gWTK7xi0rTQu4poL32H9jkinfPEnFT8QtuywVhN2bQjdR3Tl/z12GDcTDDwmVDvzsenn Wr3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zqcxsHGz4Kr95rFbZtgQzoRPPUqlgTuHpeERWR/xC4k=; b=RWAa040ImbBqLADQJ/QGTWDZFYnwmg8w/nMZVKNxbCDFr/qUVfN3XxMLBumPHt8ocA VLqRBwGCGC23bfmYzJIdAITnpRtEkgfDWSbyN2ABSjb3MAy5v3DPVoMHK2RhFB4osMri K2E0YiRbAX2BUR1cCRARpPVFebMIHVbLhxmw0nMI8SJ9f0F4cKJ4ZKS7ldVm8anhSerC ITzxJje3PHHrCqhqmgbOQ1jwzNzuDwUH0b4wFvHgDGp2/Bn0lPp4ONjT3rGYQ0eNrch+ yqW9RFMZuLJ6lXn8UytMuBkYohcjDqYROQbPxuYLlc2/Lswc5Ir1Oa3HS+uCrtUpvuUl Jy5A== X-Gm-Message-State: ABUngvenrZBSBe1NuWQf7eInFsIBw2x/ntbedhlDYql099Pp5iqkjOTN0nCbNHpgreIoy5JfSbM7h2ZypHlP8QNU X-Received: by 10.176.69.230 with SMTP id u93mr574038uau.158.1478046264472; Tue, 01 Nov 2016 17:24:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Tue, 1 Nov 2016 17:24:23 -0700 (PDT) From: Jana Iyengar Date: Tue, 1 Nov 2016 17:24:23 -0700 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=94eb2c11c9e88eb9da0540467608 Archived-At: Subject: [QUIC] New drafts posted X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 00:24:29 -0000 --94eb2c11c9e88eb9da0540467608 Content-Type: text/plain; charset=UTF-8 We've posted new versions of the following drafts. Note that the drafts continue to document current QUIC. We've introduced DISCUSS or DISCUSS_AND_REPLACE tags for some mechanisms/formats that document current QUIC behavior, but which the wg may want to reconsider after document adoption. draft-hamilton-quic-transport-protocol-01 : There are a few structural changes, based on the detailed feedback from Lars and Marcelo. We've also tried to separate packet transmission logic (earlier in the draft) from stream semantics (later in the draft), reflecting list discussion. There are also many text additions and changes that you can see here , including a full listing of the connection error codes. draft-iyengar-quic-loss-recovery-01 : Based on list discussion, we've focussed on loss *detection* logic and steered clear of retransmission logic (though I realized that we still left a number of references to "QUIC loss recovery" in the text, which we'll change to "QUIC loss detection" in the next rev.) We've also described most of QUIC loss detection in pseudo-code form. See the various changes here . Please read and send feedback! --94eb2c11c9e88eb9da0540467608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We've posted new versions of the following drafts= . Note that the drafts continue to document current QUIC. We've introdu= ced DISCUSS or DISCUSS_AND_REPLACE tags for some mechanisms/formats that do= cument current QUIC behavior, but which the wg may want to reconsider after= document adoption.=C2=A0

There ar= e a few structural changes, based on the detailed feedback from Lars and Ma= rcelo. We've also tried to separate packet transmission logic (earlier = in the draft) from stream semantics (later in the draft), reflecting list d= iscussion.

There are also many text additions and = changes that you can see here, including a full li= sting of the connection error codes.

Based on list discussion= , we've focussed on loss *detection* logic and steered clear of retrans= mission logic (though I realized that we still left a number of references = to "QUIC loss recovery" in the text, which we'll change to &q= uot;QUIC loss detection" in the next rev.)=C2=A0

<= div>We've also described most of QUIC loss detection in pseudo-code for= m. See the various changes=C2=A0here.

Please read and send feedback!
--94eb2c11c9e88eb9da0540467608-- From nobody Tue Nov 1 21:21:23 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA2F129404 for ; Tue, 1 Nov 2016 21:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVpAZOkbZkct for ; Tue, 1 Nov 2016 21:21:21 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99315129551 for ; Tue, 1 Nov 2016 21:21:21 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id z190so4893447qkc.2 for ; Tue, 01 Nov 2016 21:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=fh9jwaXMGtd10WWBmq+WjvRW586rVzZj0KCp/sy1RHI=; b=TClxDNwocGftE5aaLnlbRs8d3BES2vkKNJvlNQaIWpxhwusW+xvkUvtqvcfcjEEuc9 292mc+7RLYHzjJKehYNQ9ffjvznZ7OohOAwLq9bPndeuKeR2LAJOsDMQoopLsuK0vowB 5QmRS5WGFyWapfPOWnqgzOGO5r0NsMVuRWlFJUMqEgWc8DRbrcitu67nDY0Cb0GL+2Wg VECVehOokYA3Oz9t1uZTA9xGCi9SfDdp2eTUR0EhIel43jnBTHN9E6CMcnQXnx/eSvmP XC47iJ9K1dXbl4oLPrE8WBnteD8C6QY4z9cMz9fIwHc+0AmgxDTiZUaQ6U9lHaI5UzGw 77mA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=fh9jwaXMGtd10WWBmq+WjvRW586rVzZj0KCp/sy1RHI=; b=TBmHo4qjy5EROJHLmFDfNzWs/LqPBwrE0oRh37LCUyPTQf99pCOHS6rYwvObJp2o8n OM0ogouL9xqWcM3GX/UYLDKziJ9rVlq+nmr7RPoey2/ZlEBR3yIjNMQ3Hub06rLm+24I DSXddmYMmFzembGnQAN0pEFUfJzM9flZPAmYbiZay+pZNh37kzs7css57cF1DDciZEkT Ub0dZYctIaEnhPzq9LUxAZ0lYFssamuE0SAsupX11RP0vscBIZDNPrlOLCrGpjlpOGqz ClCHZs6Yq/8wgljHj968EuFwDKQ+uPyB2bkwjwYbvF3PNIke9SYlxHZIrRhzQjTiFMcM t41A== X-Gm-Message-State: ABUngvd96QNAQdM1vUbDutMpmMibnCGSFbadSBszy2PJS1uYnWWlo6zuvnpyNgvAXa1gqwQboVwJZm8aGpUifg== X-Received: by 10.55.12.2 with SMTP id 2mr1326116qkm.68.1478060480729; Tue, 01 Nov 2016 21:21:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 1 Nov 2016 21:21:20 -0700 (PDT) From: Martin Thomson Date: Wed, 2 Nov 2016 15:21:20 +1100 Message-ID: To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org Subject: [QUIC] Loss recovery description X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 04:21:23 -0000 On 2 November 2016 at 11:24, Jana Iyengar wrote: > draft-iyengar-quic-loss-recovery-01: > Based on list discussion, we've focussed on loss *detection* logic and > steered clear of retransmission logic (though I realized that we still left > a number of references to "QUIC loss recovery" in the text, which we'll > change to "QUIC loss detection" in the next rev.) I find the description quite baffling (though it's probably an improvement over the previous version). I'm guessing that this is just because pieces are missing, but here's a taste: loss_detection_alarm is apparently multi-modal, but the mode isn't set, only the time is. Is this just a single timer with varying timeouts? loss_detection_alarm has a bunch of functions (.reset(), .cancel(), .set(), .get_delay()), of which I am left guessing as to their intention (mainly how do .cancel() and .reset() differ). What is delayed_ack_timer? rttvar? What does it mean to have retransmittable packets outstanding? is this unacknowledged, or in a buffer awaiting transmission? It seems like the handshake packets being outstanding is unacknowledged, but it shortcuts processing and cancels the timer if retransmittable packets are outstanding (aren't handshake packets retransmittable?) There are a whole bunch of constants, all of which are unexplained. I'm looking for some "why" on every single constant. What is smoothed_rtt set to initially? Formatting-wise, you need to decide if there are semi-colons or not, and whether you intend to treat variables as locals or globals. Section 3.6 seems to treat lost_packets as a local, but neglects to pass it anywhere. Is the alarm that fires in Section 3.6 (OnAlarm(acked_packet)) the one that was set in Section 3.3 (SetLossDetectionAlarm)? Where does acked_packet come from? From nobody Wed Nov 2 00:01:29 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AE2129529 for ; Wed, 2 Nov 2016 00:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiKsOADH2ANU for ; Wed, 2 Nov 2016 00:01:26 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D366126CD8 for ; Wed, 2 Nov 2016 00:01:26 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id AABE022E255; Wed, 2 Nov 2016 03:01:19 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: <9891C0F0-B349-4E30-A176-20D0AF2EE2D0@mnot.net> Date: Wed, 2 Nov 2016 18:01:16 +1100 To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Lars Eggert Subject: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 07:01:29 -0000 Everyone,=20 As discussed previously, we plan on using Github to manage our documents = and issues list.=20 To help people understand how that will work, we've started to write = down a contribution policy, based upon the process that was used to = develop HTTP/2 successfully. Please take a moment and read: https://github.com/quicwg/wg-materials/blob/master/CONTRIBUTING.md If you have any suggestions, questions or concerns, please raise them on = the mailing list, or against that repo. Note that the separate "issues" = mailing list hasn't yet been activated until we confirm this process = with the WG. Regards, Mark and Lars (WG Chairs) From nobody Wed Nov 2 00:30:46 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C802129471 for ; Wed, 2 Nov 2016 00:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 gGQLLryDUS1B for ; Wed, 2 Nov 2016 00:30:42 -0700 (PDT) Received: from smtp-out-02.aalto.fi (smtp-out-02.aalto.fi [130.233.228.121]) by ietfa.amsl.com (Postfix) with ESMTP id 769B81294D7 for ; Wed, 2 Nov 2016 00:30:42 -0700 (PDT) Received: from smtp-out-02.aalto.fi (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 86AC8271233_8199620B for ; Wed, 2 Nov 2016 07:30:40 +0000 (GMT) Received: from EXHUB01.org.aalto.fi (exhub01.org.aalto.fi [130.233.222.118]) by smtp-out-02.aalto.fi (Sophos Email Appliance) with ESMTP id 44584271207_8199620F for ; Wed, 2 Nov 2016 07:30:40 +0000 (GMT) Received: from EXMDB04.org.aalto.fi ([169.254.1.4]) by EXHUB01.org.aalto.fi ([130.233.222.118]) with mapi id 14.03.0319.002; Wed, 2 Nov 2016 09:30:40 +0200 From: Ahsan Saba To: "quic@ietf.org" Thread-Topic: New Issue: stream state transition diagram typo Thread-Index: AQHSNNsCO+rr278ytkOCjh7pl12zYw== Date: Wed, 2 Nov 2016 07:30:39 +0000 Message-ID: <9DAB78F5-A580-4BF4-B7DD-2290F3EED3D0@aalto.fi> References: <25138_1478046274_58193241_25138_693_1_CAGD1bZa82qRBye2rYkHZYgBbz5fCMPGma62-0EMOPx-u+inj3w@mail.gmail.com> In-Reply-To: <25138_1478046274_58193241_25138_693_1_CAGD1bZa82qRBye2rYkHZYgBbz5fCMPGma62-0EMOPx-u+inj3w@mail.gmail.com> Accept-Language: en-US, fi-FI Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.233.223.20] Content-Type: multipart/alternative; boundary="_000_9DAB78F5A5804BF4B7DD2290F3EED3D0aaltofi_" MIME-Version: 1.0 Archived-At: Subject: [QUIC] New Issue: stream state transition diagram typo X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 07:30:44 -0000 --_000_9DAB78F5A5804BF4B7DD2290F3EED3D0aaltofi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpIaSwNCg0KR2V0dGluZyB0aGUgYmFsbCByb2xsaW5nIHdpdGggYSBzaW1wbGUgb25lLiBJIGJl bGlldmUgdGhlcmUgaXMgYSB0eXBvIGluIHRoZSBkaWFncmFtIHNob3dpbmcgc3RyZWFtIHN0YXRl IHRyYW5zaXRpb25zIG9uIFBhZ2UgMjkgb2YgZHJhZnQtaGFtaWx0b24tcXVpYy10cmFuc3BvcnQt cHJvdG9jb2wtMDEuIFRoZSB0cmFuc2l0aW9uIGZyb20gaGFsZiBjbG9zZWQgKGxvY2FsKSBhbmQg aGFsZiBjbG9zZWQgKHJlbW90ZSkgdG8gY2xvc2VkIGlzIGRvbmUgYnkgc2VuZCBGSU4gYW5kIHJl Y3YgRklOIHJlc3BlY3RpdmVseS4gSXQgc2hvdWxkIGJlIHJldmVyc2VkLg0KDQpBbHNvIHdvbmRl cmluZyBpZiBzaW1pbGFyIOKAnHNtYWxsaXNo4oCdIGlzc3VlcyBzaG91bGQgYmUgcG9zdGVkIG9u IHRoZSBtYWlsaW5nIGxpc3Qgb3IgZ2l0aHViIGluIHRoZSBmdXR1cmUuDQoNClJlZ2FyZHMsDQpT YWJhDQoNCg0K --_000_9DAB78F5A5804BF4B7DD2290F3EED3D0aaltofi_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPHByZSBzdHlsZT0iZm9udC1zaXpl OiAxM3B4OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsiIGNsYXNzPSIiPjxi ciBjbGFzcz0iIj48L3ByZT4NCjxkaXYgY2xhc3M9IiI+SGksJm5ic3A7PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5HZXR0aW5nIHRoZSBi YWxsIHJvbGxpbmcgd2l0aCBhIHNpbXBsZSBvbmUuIEkgYmVsaWV2ZSB0aGVyZSBpcyBhIHR5cG8g aW4gdGhlIGRpYWdyYW0gc2hvd2luZyBzdHJlYW0gc3RhdGUgdHJhbnNpdGlvbnMgb24gUGFnZSAy OSBvZiZuYnNwOzxzcGFuIHN0eWxlPSJmb250LXNpemU6IDFlbTsgbGluZS1oZWlnaHQ6IDBwdDsg Zm9udC13ZWlnaHQ6IGJvbGQ7IiBjbGFzcz0iIj5kcmFmdC1oYW1pbHRvbi1xdWljLXRyYW5zcG9y dC1wcm90b2NvbC0wMTwvc3Bhbj4uDQogVGhlIHRyYW5zaXRpb24gZnJvbSBoYWxmIGNsb3NlZCAo bG9jYWwpIGFuZCBoYWxmIGNsb3NlZCAocmVtb3RlKSB0byBjbG9zZWQgaXMgZG9uZSBieSBzZW5k IEZJTiBhbmQgcmVjdiBGSU4gcmVzcGVjdGl2ZWx5LiBJdCBzaG91bGQgYmUgcmV2ZXJzZWQuJm5i c3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5BbHNvIHdvbmRlcmluZyBpZiBzaW1pbGFyIOKAnHNtYWxsaXNo4oCdIGlzc3VlcyBzaG91 bGQgYmUgcG9zdGVkIG9uIHRoZSBtYWlsaW5nIGxpc3Qgb3IgZ2l0aHViIGluIHRoZSBmdXR1cmUu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5SZWdhcmRzLCZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TYWJhJm5ic3A7PC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9DAB78F5A5804BF4B7DD2290F3EED3D0aaltofi_-- From nobody Wed Nov 2 00:41:39 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055431297F3 for ; Wed, 2 Nov 2016 00:41:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lHznHU2W7ten for ; Wed, 2 Nov 2016 00:41:35 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 15F53129553 for ; Wed, 2 Nov 2016 00:41:35 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id 20so6043727uak.0 for ; Wed, 02 Nov 2016 00:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=S2Wg//yUYz4eecOCdl8tNPi8lqp/86v3KxVHjWoYyd0=; b=LYYadG5scS9ngzC3VKNXn/rwhUbWffMwAqli26b3RVCsBnXZXA1psVSQJHGDoExVJB TnHDW5i3zP7eOy0A0oWovZgtpY/17vSTKNkj8uXiMhpkYX7GdXOd5slJATAkayeZxZXS gXqj+UNBHRnWaUK8yd/+G/5/VU84hVQr1vn3qtsPlfNcGznSRZvC46tQxCyp9abgoBVk 6kSj/5O9Xzplf/QinWK0hEVJwRR1IqeYDimNCoyR781Rvwl1+DMN7mwffHAHdY2sF0XV b5kbcbP6xGtj2m21txqaOCc9CCwK+5VAQbOsnFnHM6XWP9txx+2caFAAe0JgUXgaQ3mO EO1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=S2Wg//yUYz4eecOCdl8tNPi8lqp/86v3KxVHjWoYyd0=; b=lZUZanVC24VRRBehA2cv4LaFCx0Wc4aRMjQCIve7/p3c+fDUCnC+NgZp/A+zwHTf/f dtRGBg0AEr4wvk6P4POvx1x8al4L28stzKrEsnA/g75861WwpFeF9ST4LJnCBvXxXmbs DLiB87E1WOJE8FTqSTihBYq1M+28RHsE5Z3J7R6tR5sKJpDrCTdvA/iTi5XTsgFfO7Xk x+rAimLgz4oIB7sQax80Y3GudLFACjaZGmATnFJELxr/wVI+UDc4aG5LZJMxo81e3aZN 6wHvYZAEn1WR26z6M/vdXLNpnCPvNBnUNAneREFA2/L7nqAAjolgZ4zk6w0RWYSf9kps AT8A== X-Gm-Message-State: ABUngveb5zk92smRJ6QVit30Vv0o0u82lhkZd4+U89LwYAYcKZ8a/ueuYpRq9IKTQyvslo0oQps5kWAlob+kNlzC X-Received: by 10.176.83.57 with SMTP id x54mr1260731uax.141.1478072493984; Wed, 02 Nov 2016 00:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Wed, 2 Nov 2016 00:41:33 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 2 Nov 2016 00:41:33 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c191efef50b9605404c912f Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Loss recovery description X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 07:41:37 -0000 --94eb2c191efef50b9605404c912f Content-Type: text/plain; charset=UTF-8 Hi Martin, Thanks for your quick feedback. More inline: On Tue, Nov 1, 2016 at 9:21 PM, Martin Thomson wrote: > On 2 November 2016 at 11:24, Jana Iyengar wrote: > > draft-iyengar-quic-loss-recovery-01: > > Based on list discussion, we've focussed on loss *detection* logic and > > steered clear of retransmission logic (though I realized that we still > left > > a number of references to "QUIC loss recovery" in the text, which we'll > > change to "QUIC loss detection" in the next rev.) > > I find the description quite baffling (though it's probably an > improvement over the previous version). I'm guessing that this is > just because pieces are missing, but here's a taste: > Understanding the algorithm, as it's currently specified, assumes more knowledge of TCP loss recovery mechanisms than it should. So, point taken -- it's certainly not complete (pieces are missing indeed, as you note below), but the progress was in adding algorithmic substance to the draft. There's more work to be done in making it complete, so everything you point out below is useful. To be clear, we simplified and added the entire loss detection algorithm (which was largely missing in -00), but admittedly there's scaffolding missing. The draft needs significant work. FWIW, the algorithmic core is a complete re-do of the TCP loss recovery zoo, and our goal was to get the core novel mechanisms out before Seoul. I'll answer your more specific questions below. loss_detection_alarm is apparently multi-modal, but the mode isn't > set, only the time is. Is this just a single timer with varying > timeouts? > Yes. This is worth clarifying though, so we'll do that in the next rev. > loss_detection_alarm has a bunch of functions (.reset(), .cancel(), > .set(), .get_delay()), of which I am left guessing as to their > intention (mainly how do .cancel() and .reset() differ). > Their intention is roughly what you'd guess, but yes, this was definitely left out (to be fixed.) reset() and cancel() should be the same, we should probably just use reset() to clear a pending alarm. > What is delayed_ack_timer? rttvar? > delayed_ack_timer is the standard delayed ack algorithm as specified in RFC 1122 and 5681. rttvar is as specified in RFC 6298. These should both be documented separately for QUIC, and they probably belong in this document. > What does it mean to have retransmittable packets outstanding? is > this unacknowledged, or in a buffer awaiting transmission? It seems > like the handshake packets being outstanding is unacknowledged, but it > shortcuts processing and cancels the timer if retransmittable packets > are outstanding (aren't handshake packets retransmittable?) > "outstanding" is used in TCP literature to mean unacknowledged data (see RFC 5681.) There's an unfortunate mistake in the first line of SetLossDetectionAlarm -- the predicate should be "if (no retransmittable packets are outstanding)", which might alleviate some confusion. Retransmittable frames are defined above in Section 2: "Retransmittable frames are frames requiring reliable delivery. The most common are STREAM frames, which typically contain application data." Retransmittable packets are packets containing one ore more retransmittable frames. This should be clarified as well. Handshake packets are retransmittable, since handshake data is sent in STREAM frames. Again, should be clarified. (That said, my script to convert a Google Doc to an XML file seems to have failed badly. Comments in the pseudo code have gone missing. WillFix.) > There are a whole bunch of constants, all of which are unexplained. > I'm looking for some "why" on every single constant. > Fair enough. For clarification the constants come from TCP loss recovery mechanisms (RFCs 6298 for RTO constants, 5681 for reordering threshold, draft-dukkipati-tcpm-tcp-loss-probe for TLP constants.) > What is smoothed_rtt set to initially? > smoothed_rtt should be part of a description of the RTT computation algorithm (basically RFC 6298), which is currently mentioned in Section 5.1 (as SRTT). > Formatting-wise, you need to decide if there are semi-colons or not, and whether you intend to treat variables as locals or globals. > The globals are listed in Section 3.1, and the rest should be locals. > Section 3.6 seems to treat lost_packets as a local, but neglects to > pass it anywhere. > Yes, this was an oversight. OnAlarm() is an asynchronous call, and doesn't return anything. This should change MaybeRetransmitLostPackets(lost_packets) (We should also change MaybeRetransmitLostPackets() to NotifyConnectionOfLostPackets() or some such.) > Is the alarm that fires in Section 3.6 (OnAlarm(acked_packet)) the one > that was set in Section 3.3 (SetLossDetectionAlarm)? Where does > Yes. > acked_packet come from? > OnAlarm should not have an acked_packet as a parameter. We'll rewrite OnAlarm() and DetectLostPackets() to be correct. --94eb2c191efef50b9605404c912f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for your quick feedback. More inline:

On Tue, Nov 1, 2016 at= 9:21 PM, Martin Thomson <martin.thomson@gmail.com> w= rote:
On 2 November 20= 16 at 11:24, Jana Iyengar <jri@google.= com> wrote:
> draft-iyengar-quic-loss-recovery-01:
> Based on list discussion, we've focussed on loss *detection* logic= and
> steered clear of retransmission logic (though I realized that we still= left
> a number of references to "QUIC loss recovery" in the text, = which we'll
> change to "QUIC loss detection" in the next rev.)

I find the description quite baffling (though it's probably an
improvement over the previous version).=C2=A0 I'm guessing that this is=
just because pieces are missing, but here's a taste:

Understanding the algorithm, as it's currently specif= ied, assumes more knowledge of TCP loss recovery mechanisms than it should.= So, point taken -- it's certainly not complete (pieces are missing ind= eed, as you note below), but the progress was in adding algorithmic substan= ce to the draft. There's more work to be done in making it complete, so= everything you point out below is useful.=C2=A0

T= o be clear, we simplified and added the entire loss detection algorithm (wh= ich was largely missing in -00), but admittedly there's scaffolding mis= sing. The draft needs significant work. FWIW, the algorithmic core is a com= plete re-do of the TCP loss recovery zoo, and our goal was to get the core = novel mechanisms out before Seoul. I'll answer your more specific quest= ions below.

loss_detection_alarm is apparently multi-modal, but the mode isn't
set, only the time is.=C2=A0 Is this just a single timer with varying
timeouts?

Yes. This is worth clarifying= though, so we'll do that in the next rev.
=C2=A0
loss_detection_alarm has a bunch of functions (.reset(), .cancel(),
.set(), .get_delay()), of which I am left guessing as to their
intention (mainly how do .cancel() and .reset() differ).

Their intention is roughly what you'd guess, but yes,= this was definitely left out (to be fixed.) reset() and cancel() should be= the same, we should probably just use reset() to clear a pending alarm.
=C2=A0
What is delayed_ack_timer?=C2=A0 rttvar?

delayed_ack_timer is the standard delayed ack algorithm as specified in R= FC 1122 and 5681. rttvar is as specified in RFC 6298. These should both be = documented separately for QUIC, and they probably belong in this document.<= /div>
=C2=A0
What does it mean to have retransmittable packets outstanding?=C2=A0 is
this unacknowledged, or in a buffer awaiting transmission?=C2=A0 It seems like the handshake packets being outstanding is unacknowledged, but it
shortcuts processing and cancels the timer if retransmittable packets
are outstanding=C2=A0 (aren't handshake packets retransmittable?)

"outstanding" is used in TCP liter= ature to mean unacknowledged data (see RFC 5681.) =C2=A0There's an unfo= rtunate mistake in the first line of SetLossDetectionAlarm -- the predicate= should be "if (no retransmittable packets are outstanding)", whi= ch might alleviate some confusion.

Retransmittable= frames are defined above in Section 2: "Retransmittable frames are fr= ames requiring reliable delivery. The most common are STREAM frames, which = typically contain application data." Retransmittable packets are packe= ts containing one ore more retransmittable frames. This should be clarified= as well.

Handshake packets are retransmittable, s= ince handshake data is sent in STREAM frames. Again, should be clarified.

(That said, my script to convert a Google Doc to an= XML file seems to have failed badly. Comments in the pseudo code have gone= missing. WillFix.)
=C2=A0
There are a whole bunch of constants, all of which are unexplained.
I'm looking for some "why" on every single constant.

Fair enough. For clarification the constants co= me from TCP loss recovery mechanisms (RFCs 6298 for RTO constants, 5681 for= reordering threshold, draft-dukkipati-tcpm-tcp-loss-probe for TLP constant= s.)
=C2=A0
What is smoothed_rtt set to initially?

= smoothed_rtt should be part of a description of the RTT computation algorit= hm (basically RFC 6298), which is currently mentioned in Section 5.1 (as SR= TT).
=C2=A0
and whether you intend to treat variables as locals or globals.

The globals are listed in Section 3.1, and the res= t should be locals.
=C2=A0
Section 3.6 seems to treat lost_packets as a local, but neglects to
pass it anywhere.

Yes, this was an over= sight. OnAlarm() is an asynchronous call, and doesn't return anything. = This should change=C2=A0MaybeRetransmitLostPackets(lost_packets)

(W= e should also change MaybeRetransmitLostPackets() to NotifyConnectionOfLost= Packets() or some such.)
=C2=A0
Is the alarm that fires in Section 3.6 (OnAlarm(acked_packet)) the one
that was set in Section 3.3 (SetLossDetectionAlarm)?=C2=A0 Where does

Yes.
=C2=A0
acked_packet come from?

OnAlarm should not = have an acked_packet as a parameter. We'll rewrite OnAlarm() and Detect= LostPackets() to be correct.
--94eb2c191efef50b9605404c912f-- From nobody Wed Nov 2 01:00:36 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDA75129534 for ; Wed, 2 Nov 2016 01:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pob1pSGxwVOk for ; Wed, 2 Nov 2016 01:00:33 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735521294C0 for ; Wed, 2 Nov 2016 01:00:33 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id C31D322E255; Wed, 2 Nov 2016 04:00:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Mark Nottingham In-Reply-To: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> Date: Wed, 2 Nov 2016 19:00:24 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <7B8E8785-7E3B-4A02-96F1-8625F05687C9@mnot.net> References: <4B3A8FA0-F5CE-4320-B4BD-9DF13057918E@mnot.net> To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Lars Eggert Subject: Re: [QUIC] First Interim planning -- availability poll X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 08:00:35 -0000 Just a reminder - if you haven't filled this out, please do so ASAP, as = we'd like to finalise planning soon.=20 Regards, > On 26 Oct. 2016, at 6:43 pm, Mark Nottingham wrote: >=20 > Everyone, >=20 > We'd like to get our first interim meeting nailed down soon. We have a = host with with what we believe to be a suitable space in Tokyo, Japan on = 24-26 January. >=20 > To make sure that it's suitable for a good portion of the WG, as well = as to assist planning, please fill out this poll to indicate your = availability: > http://doodle.com/poll/ams8q39eecud4zih >=20 > In particular, if you'd like to actively participate but the cannot = make those dates, please indicate that with "Cannot make it." >=20 > We'll have more details soon. >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 >=20 > Sent from my iPhone > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic -- Mark Nottingham https://www.mnot.net/ From nobody Wed Nov 2 01:02:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3764129544 for ; Wed, 2 Nov 2016 01:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIp6yrjzICf0 for ; Wed, 2 Nov 2016 01:02:18 -0700 (PDT) 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 30565129453 for ; Wed, 2 Nov 2016 01:02:18 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id 12so6295924uas.2 for ; Wed, 02 Nov 2016 01:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UiuFfVzxIo17kW5D/o2Lw0tV7zEtDwVrVvObt5NSLDw=; b=WpLqWSMEPJ694RwHlO8LNhtfs+bAq6oRMWtyChm/fl6oLkqasVFh3/+Apl20Fd4RDG itX2aWOOQm3bdCfUnt7+R9TDmstBXEnykWnjY4Cq456pkX672ZslFW/tcmCC/nfbP1YS 3C3CFWWMYu0J8sMVur/vHIgLexF3YB5lg0ulgKEnopN1qF9hRIf9i/yyWF1Qk+6e3lms 7PIgSGO/vmogEL60mjeuhpFfNpDP2UVScWZfKI0L8ElkHqlT3XgpSacPw50G2cU2mqH/ hKdDOYXZ8HUJW5IbvfG04Zzf286J75FIQ6PllQQ/5ALlXdwu6S7qezB1uPSYyLJ1TVnY kxVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UiuFfVzxIo17kW5D/o2Lw0tV7zEtDwVrVvObt5NSLDw=; b=lyOFxuZNKl1JoeqeZbrKLqTEXK+T2BQswlsytFZOcJ/QL0SptbEzGXUi9J9ciNwa4j vL8ky31nEj8VLCA//FQgHNnjpzfnbJiiFqux/8o2aqb/QDDhfKEHrRdlsllrNMAJgOE/ iyFRXvR/3Am333kLbG89/zcFNmpSYy+6ZX8eR+Xf9VpSUzC0s4EPmnxrsNtFJEGImRfs FXbkpKPY3a2CFlfNFpHdtR5m9BFqArpbdMAZmZCplQIuDFegathOFtdOBTAe8wZwiThC iNo8duYN/zRamwZEjp61wx4mBAS3FAuTKM3dtletVQd2fDcm7NZNTaB832QNGaJungcz B+aw== X-Gm-Message-State: ABUngvcLLwozCCwRrSkbJ9/4iB2or3Vpc/8V/N94TSSOoz1EDbzzm7h8X/AmR/Mng77GoB7cAKdfBzLXAp6OArIO X-Received: by 10.176.65.4 with SMTP id j4mr1295474uad.93.1478073737149; Wed, 02 Nov 2016 01:02:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Wed, 2 Nov 2016 01:02:16 -0700 (PDT) In-Reply-To: <9DAB78F5-A580-4BF4-B7DD-2290F3EED3D0@aalto.fi> References: <25138_1478046274_58193241_25138_693_1_CAGD1bZa82qRBye2rYkHZYgBbz5fCMPGma62-0EMOPx-u+inj3w@mail.gmail.com> <9DAB78F5-A580-4BF4-B7DD-2290F3EED3D0@aalto.fi> From: Jana Iyengar Date: Wed, 2 Nov 2016 01:02:16 -0700 Message-ID: To: Ahsan Saba Content-Type: multipart/alternative; boundary=94eb2c122fae0e5dd105404cdc98 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] New Issue: stream state transition diagram typo X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2016 08:02:21 -0000 --94eb2c122fae0e5dd105404cdc98 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Ahsan, Getting the ball rolling with a simple one. I believe there is a typo in > the diagram showing stream state transitions on Page 29 of > draft-hamilton-quic-transport-protocol-01. The transition from half > closed (local) and half closed (remote) to closed is done by send FIN and > recv FIN respectively. It should be reversed. > Ah! Nice catch -- fixed. > Also wondering if similar =E2=80=9Csmallish=E2=80=9D issues should be pos= ted on the > mailing list or github in the future. > Not sure. Is it ok to do github before documents are adopted? - jana Regards, > Saba > > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --94eb2c122fae0e5dd105404cdc98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ahsan,

Getting the ball rolling with a simple one. I believe there is a typo = in the diagram showing stream state transitions on Page 29 of=C2=A0draft-hamilton-quic-= transport-protocol-01. The transition from half closed (local) and half closed (remote) to closed= is done by send FIN and recv FIN respectively. It should be reversed.=C2= =A0

Ah! Nice catch -- fixed.
=C2=A0
Also wondering if similar =E2=80=9Csmallish=E2=80=9D issues should be = posted on the mailing list or github in the future.

Not sure. Is it ok to do github before documents are a= dopted?

- jana

Regards,=C2=A0
Saba=C2=A0



_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinfo/quic


--94eb2c122fae0e5dd105404cdc98-- From nobody Wed Nov 2 08:17:55 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F86F129505 for ; Wed, 2 Nov 2016 08:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 goh4jcl7M93T for ; Wed, 2 Nov 2016 08:17:50 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5416B1294C1 for ; Wed, 2 Nov 2016 08:10:26 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id n204so11208906qke.2 for ; Wed, 02 Nov 2016 08:10:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=joqoDlGNe+Fw/5nsSXBb+8Fhns2/ZhTuIPfxAuSj+z8=; b=i50/GQN095Tt+/HJXy4wuUmIYYQ6v/faltX57NfIcQTt7JgzgCILcihYA+INagLWra rXr4Y+luw0fMKqXftoTSEBKLi1vlAhN6XqTLRvj6shtWZMfREs36pzi4/rGuOnlH5AfK 64lMIo9qM7jaq03MDabOy17gWfv9d1FulaAIWNRh5oUWmNz3VqfdLWn+rNutbqi/C04d 1WZWP6HJhw8p2HuSypjZ5UdZqW/rMqOKC4YemfuO31WeVbly41OqIU2oVglrPrXezRlX nlAzmaCWT1y0obn/mar5aGt7jjj5qcG/rDuUNODtKEWdzxMH4vP6W+d6ZpSbqkoYo6ve Yj6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=joqoDlGNe+Fw/5nsSXBb+8Fhns2/ZhTuIPfxAuSj+z8=; b=KSjmVsd4D4MkhDFPNOiCVmJaGTnxsGLXDsgmnmvR1USE1GNsRPMrhJhY6DMrCrPALP zp9Msv2WhM1HvOh7hDp9INYPKJvJ826xgIelGWdHMsO8KsMl37TSsrhCfu2b32e11V1T zQ+AXo3R/UH/n9QU1SWRJsNF0QFQ0m9bLti+9+hTPRdzQJmtX7xGA3+WYnUpgsO1pdnQ h95ZNS0RH586bd+iqsHg7gQbAsHhDQMUrmUzEU3LNG+0xeDqW+NYiJOkI5OyyTCkpvQ2 h6v9rcT1/savpM/BhGyPksdc+xkxR8Ih+v4Ww7uvypp0ZpcNHj+A0mRgLkHJLSm1Sq8j /xSQ== X-Gm-Message-State: ABUngvf0ppYnpx6K0YIIiCFcbV5rT1QbanZICfBSmKFlBlLXGBSIPanuOcwoylbZHNYmhIX51lEVjr3el9yWCw== X-Received: by 10.55.99.141 with SMTP id x135mr3400390qkb.147.1478099425000; Wed, 02 Nov 2016 08:10:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 2 Nov 2016 08:10:24 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 3 Nov 2016 02:10:24 +1100 Message-ID: To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Loss recovery description X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 02 Nov 2016 15:17:52 -0000 Thanks Jana, I think that I got the gist, but found that I was guessing too much. I'm certainly short on my encyclopedic knowledge of the TCP RFCs. On 2 November 2016 at 18:41, Jana Iyengar wrote: > The globals are listed in Section 3.1, and the rest should be locals. The one that stands out is lost_packets. Also time_loss isn't used [-Wunused] From nobody Wed Nov 2 08:20:41 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5D3412965C for ; Wed, 2 Nov 2016 08:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijXNqNI4XLmp for ; Wed, 2 Nov 2016 08:20:38 -0700 (PDT) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::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 995CE12951B for ; Wed, 2 Nov 2016 08:20:38 -0700 (PDT) Received: by mail-qk0-x233.google.com with SMTP id x190so20188557qkb.0 for ; Wed, 02 Nov 2016 08:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YTj5fHFz7EBVhrHD6KK/YuAt0oRBd0wsC5YbEqWz90Q=; b=XrAaOa/Hbe8bTicSRT+Go69wu9b96C/03Ucez6DzJuihdQj99uKJlH5deNGbyO93rd lJoUEwccjrjxkJkGuD/MhjxA/GKIqpztHKYF4m/JS7LMBs810HU0jBw/+6XxsXwIKB0l cn67RaJs/c36rjXC/yGxM3brvViLc55nLfcDb/N0LZ2MSp0ctEDTeE1AR4hk1ipZLV7k fcs80dYT/fpoXa1Eg/RmnLFcTyWmSvQVCh1Ane79gV1WFelis+yBwv2BiYEIaONJQbrl YlrTw4vl7CXXjz5FOcVZrff5HKll4JKUtXzd0vrBP5bKjmT8QpM6+MqhwC1d/fsPOFGw mnzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YTj5fHFz7EBVhrHD6KK/YuAt0oRBd0wsC5YbEqWz90Q=; b=M8dsGI/DsxOlPI4PABVYKyFco1Na+pLgCcW7T5g9rvk15cFVxBhpe8BduIQvXd4Gfu HMj4IctBc+zdbgXM/sH2wpgH4o6AJLMsiEInbfpoklhmuGgF/dW9rRu7gVvG6PdMqS3m opRHNlQFf3GUTH56Ju732Nix7B6EEne3O2MKI2faLXHwMvAK7ifCQuYcJtvCf2w9GD8T tZjbPkY6H6fwST4D5ZDk/lCPziwvarq0Cyame/T0ZA53tUySxKqqbZeFvBVkI31//Zb0 zxudo8ur+5CiYOul/9LdWoQEuDNPV4kRTKyJqw4SGoyBglksrhnW6miWlhLWOI9F6sGH EPRg== X-Gm-Message-State: ABUngvfYV6EJc0/bgvvkNUFIxNiLlX75ooMmn030uY9dZ7MtbLXhKfvrERwTB2FBbcBnZKJOas6Y8UTdt+4w/A== X-Received: by 10.55.12.2 with SMTP id 2mr3551705qkm.68.1478100037614; Wed, 02 Nov 2016 08:20:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 2 Nov 2016 08:20:37 -0700 (PDT) In-Reply-To: References: <25138_1478046274_58193241_25138_693_1_CAGD1bZa82qRBye2rYkHZYgBbz5fCMPGma62-0EMOPx-u+inj3w@mail.gmail.com> <9DAB78F5-A580-4BF4-B7DD-2290F3EED3D0@aalto.fi> From: Martin Thomson Date: Thu, 3 Nov 2016 02:20:37 +1100 Message-ID: To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ahsan Saba , "quic@ietf.org" Subject: Re: [QUIC] New Issue: stream state transition diagram typo X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 02 Nov 2016 15:20:40 -0000 On 2 November 2016 at 19:02, Jana Iyengar wrote: > Not sure. Is it ok to do github before documents are adopted? Not a chair, but if you have things on github, you can do github. The docs are currently private, so the process for managing them is entirely up to the authors. Note that moving repos around can be a little tricky. You have to be owner of both source and target organization. If there is an official organization, and the chairs are amenable, hosting the docs there might be easiest to manage (with a prominent disclaimer about status). Copying is possible, but it loses some information (issues primarily) and forking is a disaster. From nobody Wed Nov 2 08:30:28 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3588B129505 for ; Wed, 2 Nov 2016 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.418 X-Spam-Level: X-Spam-Status: No, score=-8.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzPI8AruZHR1 for ; Wed, 2 Nov 2016 08:30:18 -0700 (PDT) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62E5712965C for ; Wed, 2 Nov 2016 08:30:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,583,1473145200"; d="scan'208";a="155148193" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx144-out.netapp.com with ESMTP; 02 Nov 2016 08:29:46 -0700 Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 2 Nov 2016 08:29:58 -0700 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Wed, 2 Nov 2016 08:29:58 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FoUFIZ4Eyv3cuxLlbYME2AVuq0W44RHclhsVUm8xVJM=; b=XO+vsuJyBovA4Bv0rbZBdV7G9VkJHNKIdF0XawX3+9Eut727l/8kISnQds5CDPha+A2+V0n6zfqbOUmBzpVKsqSy/FokSJ1st++REMYefY/P2ebopiSTHmSdHqG8xJbA39mtxVckd0zzU0qfEYDhGTOL0VOisNKuEI1wbzE9dU0= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1154.namprd06.prod.outlook.com (10.160.157.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.679.12; Wed, 2 Nov 2016 15:29:57 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0679.020; Wed, 2 Nov 2016 15:29:57 +0000 From: "Eggert, Lars" To: Martin Thomson Thread-Topic: Github how and when (was: Re: [QUIC] New Issue: stream state transition diagram typo) Thread-Index: AQHSNR33cV2oxv74LkinFQFjYoTJpQ== Date: Wed, 2 Nov 2016 15:29:57 +0000 Message-ID: <6BAB9426-CB76-4397-B0EA-2EA66C85F395@netapp.com> References: <25138_1478046274_58193241_25138_693_1_CAGD1bZa82qRBye2rYkHZYgBbz5fCMPGma62-0EMOPx-u+inj3w@mail.gmail.com> <9DAB78F5-A580-4BF4-B7DD-2290F3EED3D0@aalto.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 31fe7c9f-8672-4815-b80c-08d403351a5b x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1154; 7:jYkC1hAMNx/VChLIuxFfLQhc0uXmq+LLoWMexjYgwz9thbUQ4wn6yze9msP6XW7DyX/AQQIWmO14sYHFHUsKiyJej9axMTqgCSj67TrvxSLLZWcXebqIexF89Dbdzqzbhp/4IrH/U3nde6RfDpR2w8nILo6EQraGtDNzT3V40JjT8+pFOW8O2jHdIqWXw8AJ3KlL50zThFlFdnl5gJyQqsrDC2q59OmBBtyoEW0q7VaegrrOPMPUePVIGW22CMfClafsKZDBD7d0oeIxAeWidM5UmmAIJZJemXLXvcznQYlsYeK8abrVrfcIQPe2C7i4RJD+eug1sunh5kgwuwSVuCj04fvYzDlfq7ZkbKPZfFI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6043046)(6042046); SRVR:BN3PR0601MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1154; x-forefront-prvs: 0114FF88F6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(377424004)(24454002)(189002)(77096005)(106356001)(5660300001)(36756003)(50226002)(66066001)(76176999)(189998001)(305945005)(97736004)(68736007)(86362001)(93886004)(50986999)(7736002)(7846002)(101416001)(8676002)(57306001)(81166006)(81156014)(19580405001)(19580395003)(110136003)(229853001)(10400500002)(82746002)(122556002)(586003)(87936001)(92566002)(102836003)(3846002)(5002640100001)(11100500001)(2950100002)(6916009)(4326007)(106116001)(6116002)(2900100001)(8936002)(83716003)(15975445007)(33656002)(3660700001)(99286002)(3280700002)(105586002)(2906002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1154; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <0C72D5C66A1C0C428DF65A2A9D038249@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Nov 2016 15:29:57.5200 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1154 X-OriginatorOrg: netapp.com Archived-At: Cc: Jana Iyengar , Ahsan Saba , "quic@ietf.org" Subject: [QUIC] Github how and when (was: Re: New Issue: stream state transition diagram typo) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 02 Nov 2016 15:30:20 -0000 On 2016-11-02, at 16:20, Martin Thomson wrote: > Not a chair, but if you have things on github, you can do github. The > docs are currently private, so the process for managing them is > entirely up to the authors. Need to check with Mark, but I think the intent is that we'd be appointing = WG editors for the various work items during Seoul, and ideally also also b= e adopting some of the current batch of individual IDs as the basis for tho= se WG work items. We'd then move those underneath the WG github at https://github.com/quicwg = and follow the process at https://github.com/quicwg/wg-materials/blob/maste= r/CONTRIBUTING.md that Mark has just asked for feedback on. Lars= From nobody Wed Nov 2 09:42:14 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D751296CA for ; Wed, 2 Nov 2016 09:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QrOlgbjbTv9 for ; Wed, 2 Nov 2016 09:42:11 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 7608A1296AF for ; Wed, 2 Nov 2016 09:42:11 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id d128so7037496ybh.2 for ; Wed, 02 Nov 2016 09:42:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YJa9jlE4/CQckyFvCDmjXc84ys02o5oIiLZSL1E14bw=; b=XsFjy4cIkS/HYw6tU1ztucF5Mg4t9ktDClPO1eaGAmbP/ouyUWa+nXHn6l9fCp55Fx jn+56b9waM/8y3nWCO+3R5R+UMX2QaV4Unn+n98vGVrXUWXJUAQkGpNa4+1nZB9ljjBG yAeNfSwTuBrR5tEnioRAMYIROVXaoYwwIvtOJcA8mdaP1u9NcM8GYAIUwceokDwvdLaR e67ggStUMg6wJKhvfpQolkxfv/+ptBlx8NuHyUQPQaMQgkI98D0ci2H3UglDLNQ6/tCV zBVlF+fs60tVkmDRgF9d87IhZlQ17S/l5VJuS+VasOhcpQaMZ0dbL5q/tLkXGYJ1kAYC R62g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YJa9jlE4/CQckyFvCDmjXc84ys02o5oIiLZSL1E14bw=; b=XE42OK2cyBlr9ud5cxAWRKldVJnjv5CrEptR+BEUBhgYiZAhP2Lh5U3jFR/RrSezjO amjm7Ytrb5aJc8Bjkb6Rkf23Dts19V7upDENTTgtHjHdK0sUgBPmfOKuhYiWUJ+CWcea lwVlnM51iP1BdfXGTIegdB+sXGeYQVfR63I0e0YTZywKwMP0dZ4ZAmvauarW2998Oz+N yWOY1SDvPWJQNEj+mG3vGcr76f3lWyNxuWLaF49y6gaVHSxU3DK06lg/fNObpWgP0/m6 aSAZoNk4YN692F0CPyLHV2vuKpcnGG0mvv+xCNMI1DUsWfm2R2bs5vYejZBIoi6OSwK4 n6ng== X-Gm-Message-State: ABUngvdMhXRK235N0CY6YlA+8zC92C6U86TKxg5iUc29HeBERtcGeHVDFxxfp4pssQh+jjfdO8eBcuI6ObeY8/py X-Received: by 10.37.79.84 with SMTP id d81mr3229814ybb.175.1478104930559; Wed, 02 Nov 2016 09:42:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.39.135 with HTTP; Wed, 2 Nov 2016 09:41:50 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Wed, 2 Nov 2016 12:41:50 -0400 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113c40e0540e200540541fb2 Archived-At: Cc: Jana Iyengar , quic@ietf.org Subject: Re: [QUIC] Loss recovery description X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 02 Nov 2016 16:42:13 -0000 --001a113c40e0540e200540541fb2 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 2, 2016 at 11:10 AM, Martin Thomson wrote: > Thanks Jana, I think that I got the gist, but found that I was > guessing too much. I'm certainly short on my encyclopedic knowledge > of the TCP RFCs. > > On 2 November 2016 at 18:41, Jana Iyengar wrote: > > The globals are listed in Section 3.1, and the rest should be locals. > > The one that stands out is lost_packets. > > Also time_loss isn't used [-Wunused] > > There should be a "if (time_loss)" line directly after the foreach loop in DetectLostPackets. It was inadvertently deleted at some point, now fixed in the master doc. --001a113c40e0540e200540541fb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Nov 2, 2016 at 11:10 AM, Martin Thomson <martin.thomson@gma= il.com> wrote:
Thanks Jana, I think that I got the gist, but found that I was
guessing too much.=C2=A0 I'm certainly short on my encyclopedic knowled= ge
of the TCP RFCs.

On 2 November 2016 at 18:41, Jana Iyengar <jri@google.com> wrote:
> The globals are listed in Section 3.1, and the rest should be locals.<= br>
The one that stands out is lost_packets.

Also time_loss isn't used [-Wunused]

There should be a "if (time_loss)" line dir= ectly after the foreach loop in DetectLostPackets.=C2=A0 It was inadvertent= ly deleted at some point, now fixed in the master doc.

--001a113c40e0540e200540541fb2-- From nobody Wed Nov 2 10:21:06 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C800A12968B for ; Wed, 2 Nov 2016 10:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0cKqgXgwzsg for ; Wed, 2 Nov 2016 10:21:04 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 1289D1294E1 for ; Wed, 2 Nov 2016 10:21:04 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id x186so18621081vkd.1 for ; Wed, 02 Nov 2016 10:21:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fPIPVvFm6ZMmxlnQCksuFJSK9KUVT9E0LFZuoSk3LQ4=; b=iIaT72cR3YQV5wa38B4FSz2CHp+DVCnnzInO9hG7buljPtngKZ1Hs3/WAO+1maMCY9 z7yabANMbTypWiKnzQ76KbMS2FrDZfSiQPQCekdzL7JmDzrY/HZiUhkrStfNtDb+4JTN fXN6Y4pgv+0qUHnn8gcdyDsR+bJHiLEkmyiNOPYPawDAoKrNmvJjMn29XVj4hnwjp9PU D5zndLFS8WtxzV2XhyJnJX5QekLA88brkCOlzowOjB14o2LSbOOiOmxX2A456UhkRRUu 0bWCW+ZLSMgPd7+9844Dxb785b0oR79kW+6V02GyMSIsJNFMxPOYTEyLF9ESbw5OPgvj Uj4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fPIPVvFm6ZMmxlnQCksuFJSK9KUVT9E0LFZuoSk3LQ4=; b=k4YbnK694EWE+J8+Umt+0iIX9wltbmqUbPTzxdwtdVdOB92f+BfT/jjWs5ntAZA3vX ieCNGJRHFibDtZSMLeJHAELL/fxjoQkuF9rl+MSI11aViJf9Z+FZhmGFBH+3rKZMOKa0 lcWTtIlNZ+WLj+OdqkHF+iuhCeFu1iW+Ht+XejMD6JesnXy7AdbQ24a5NGwEjlcCvltZ HxadeEkvzmyZx4LslKvfYujE5N5hPxsKmnNvXlK7CbzfQjzVAqPa/cg9FIoRGl8kz4mZ 7k6OPB+ZK7QEnc0/Vaol+bFZ5fN/hX+ci8bEpqJ5XqkI20X7rDu6BeMlbtmzVn0an1B+ n61w== X-Gm-Message-State: ABUngve/RmXZNdUg5+ZKz9NZeaR4nwq7BbyjCuy+U7myyiS8cATpfyYitJ0EP6PC455kldImyohGzWRqxwxjR19/ X-Received: by 10.31.84.130 with SMTP id i124mr2940965vkb.66.1478107262995; Wed, 02 Nov 2016 10:21:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Wed, 2 Nov 2016 10:21:02 -0700 (PDT) In-Reply-To: References: From: Jana Iyengar Date: Wed, 2 Nov 2016 10:21:02 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e5bfc5a2a85054054aa2a Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Loss recovery description X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 02 Nov 2016 17:21:06 -0000 --001a114e5bfc5a2a85054054aa2a Content-Type: text/plain; charset=UTF-8 On Wed, Nov 2, 2016 at 8:10 AM, Martin Thomson wrote: > Thanks Jana, I think that I got the gist, but found that I was > guessing too much. I'm certainly short on my encyclopedic knowledge > of the TCP RFCs. Yeah, that's a bug in the current draft, not a feature. Thank you again for your read and your review -- I'd definitely appreciate another review after we've had a chance to fill it out some more to make it more self-contained. On 2 November 2016 at 18:41, Jana Iyengar wrote: > > The globals are listed in Section 3.1, and the rest should be locals. > > The one that stands out is lost_packets. > > Also time_loss isn't used [-Wunused] > --001a114e5bfc5a2a85054054aa2a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 2, 2016 at 8:10 AM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
Thanks Jana, I th= ink that I got the gist, but found that I was
guessing too much.=C2=A0 I'm certainly short on my encyclopedic knowled= ge
of the TCP RFCs.

Yeah, that's a bug in = the current draft, not a feature. Thank you again for your read and your re= view -- I'd definitely appreciate another review after we've had a = chance to fill it out some more to make it more self-contained.
<= br>
On 2 November 2016 at 18:41, Jana Iyengar <jri@google.com> wrote:
> The globals are listed in Section 3.1, and the rest should be locals.<= br>
The one that stands out is lost_packets.

Also time_loss isn't used [-Wunused]

--001a114e5bfc5a2a85054054aa2a-- From nobody Wed Nov 2 10:25:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C665B1296CC for ; Wed, 2 Nov 2016 10:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIOz0KdOAJ3T for ; Wed, 2 Nov 2016 10:25:18 -0700 (PDT) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B6B53129446 for ; Wed, 2 Nov 2016 10:25:18 -0700 (PDT) Received: by mail-vk0-x234.google.com with SMTP id p9so18696561vkd.3 for ; Wed, 02 Nov 2016 10:25:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ett9Xo70H0h05c2xf1Qpxv99xiSxGVmu+2kHJB57Ofg=; b=VFjhKUeMv2hSzKFNzmU0LiglxKC6D4kDqeHng5fJaDtcczDDn6gITVHncWnhZ1lJiH JofvaGEvIF9WgPI844cQYRLE0fyif6pa2OYFXNfQ6t5pF6sdeQIAe1+o/7c3GwarazUY gJ9+3WVgd/TBLSxsrl/eZeToB2vigbK3oT6V4DdJfbbskfpvu0LZuP9fiMtbiuGXsIS9 u8ulj7wJiXWPOvlBU2oct7Py5VjI07dfy666GDsrBsqdrY0tF4Hijc3g3+aY0h2AbKKW O9GxNIIlz98OpWXH/H/KdGxpXvaJzHJ/TpSZMBX90pQ1H6hbsReM8Mg+CXQ/ja+ncqt1 z6pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ett9Xo70H0h05c2xf1Qpxv99xiSxGVmu+2kHJB57Ofg=; b=hHwrX/BltMy7ENbKGXcC4YX30IByu/u9CNMJJOKYfuid3RlluB92Hz2671Ur4zyvQY 4UVDyT5fBMo8BDkp2chyLwLupnO5OOtRA5WSYdHce7+04qRZaJFSI6CopTtMASktfSGK pMttF3QmQH0pnt2KmhQ+T/gYsqv8OvdOKWA2FgpahGN9Zp5g5yEdGLp6+kF97WZ2zGAM qch6Ree7An6JPCJ9TNWV+pcdNWTYiT5pIcDWfNdvs5cFjPkVLlfh9FN6Ca9X0Ui/g2WJ lzVMogLEA9tKuxxVxOTI4WVqMavpIDjWSbNrGzoqWblYLl35cECXp+DOPMpbrNd2pYIn eHPg== X-Gm-Message-State: ABUngvfsC7wGrjfLxoWpQBKSCE7Q49W6g4eXXjfZg78mT6mTnyUcgDlbxQ23/AJQY2rmSaQLzs0Ti4AB2jc7Wj6t X-Received: by 10.31.76.134 with SMTP id z128mr3289490vka.59.1478107517643; Wed, 02 Nov 2016 10:25:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.71.136 with HTTP; Wed, 2 Nov 2016 10:25:17 -0700 (PDT) In-Reply-To: <6BAB9426-CB76-4397-B0EA-2EA66C85F395@netapp.com> References: <25138_1478046274_58193241_25138_693_1_CAGD1bZa82qRBye2rYkHZYgBbz5fCMPGma62-0EMOPx-u+inj3w@mail.gmail.com> <9DAB78F5-A580-4BF4-B7DD-2290F3EED3D0@aalto.fi> <6BAB9426-CB76-4397-B0EA-2EA66C85F395@netapp.com> From: Jana Iyengar Date: Wed, 2 Nov 2016 10:25:17 -0700 Message-ID: To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=001a114dad5087cd98054054b971 Archived-At: Cc: Ahsan Saba , Martin Thomson , "quic@ietf.org" Subject: Re: [QUIC] Github how and when (was: Re: New Issue: stream state transition diagram typo) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 02 Nov 2016 17:25:21 -0000 --001a114dad5087cd98054054b971 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 2, 2016 at 8:29 AM, Eggert, Lars wrote: > On 2016-11-02, at 16:20, Martin Thomson wrote: > > Not a chair, but if you have things on github, you can do github. The > > docs are currently private, so the process for managing them is > > entirely up to the authors. > > Need to check with Mark, but I think the intent is that we'd be appointing > WG editors for the various work items during Seoul, and ideally also also > be adopting some of the current batch of individual IDs as the basis for > those WG work items. > > We'd then move those underneath the WG github at https://github.com/quicwg > and follow the process at https://github.com/quicwg/wg- > materials/blob/master/CONTRIBUTING.md that Mark has just asked for > feedback on. > That's what I figured as well. Thanks for the clarification. We'll continue discussions of the individual drafts on the mailing list in the meanwhile. --001a114dad5087cd98054054b971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 2, 2016 at 8:29 AM, Eggert, Lars <lars@netapp.com> wro= te:
On 2016-11-02, at 16:20, Martin Thomson <martin.thomson@gmail.com> wrote:
> Not a chair, but if you have things on github, you can do github.=C2= =A0 The
> docs are currently private, so the process for managing them is
> entirely up to the authors.

Need to check with Mark, but I think the intent is that we'd be appoint= ing WG editors for the various work items during Seoul, and ideally also al= so be adopting some of the current batch of individual IDs as the basis for= those WG work items.

We'd then move those underneath the WG github at https://github.com/qui= cwg and follow the process at = https://github.com/quicwg/wg-materials/blob/master/CONTRIBUTING.m= d that Mark has just asked for feedback on.

That's what I figured as well. Than= ks for the clarification.
We'= ;ll continue discussions of the individual drafts on the mailing list in th= e meanwhile.=C2=A0
--001a114dad5087cd98054054b971-- From nobody Wed Nov 2 11:10:36 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E65129A77 for ; Wed, 2 Nov 2016 11:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VViwSZcqwoDY for ; Wed, 2 Nov 2016 11:10:34 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 A9D74129AAF for ; Wed, 2 Nov 2016 11:10:33 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id p9so19785910vkd.3 for ; Wed, 02 Nov 2016 11:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=FjZ9DcjS5A8HfZm7TvCSzndWYspVVTHM2PfbmdK/pEc=; b=sEJYSN0H2a7HY/08R4bJ1Rk/tJ4ZQ+MfmnfrvpQh1kWiNha4ZYmurFEzWEKDpxI4hh Ce6rOyautgl2+q8wlV/aDuyj/RMtd2qaq1mEKt4jMSjZgImVPHZRcw/eEdlmLeTUagrR c8qWn2htXMkn2juf0Id06tix52sav5cirqfKrZ1IR+aG3V2pnuDKmP8REmUl8B4Caedg iF9h8KuoYr/7ejLS0VMPSged3m6peopZ/qIu+bf3Qjo5jvFc6DEVwUej0u2oDrpem/fV tc15COlJxEIOY7DLHr70jylPQ9jtspB/qU/Q2cTS7tKAF3M9Gcc7UaeL6vc/tZopeR9L qykQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FjZ9DcjS5A8HfZm7TvCSzndWYspVVTHM2PfbmdK/pEc=; b=MjXcm+OjaEfnu/CD0FNXrsk94Y+c/0HrgyovGio5mGIV6f0AQt3xR0tZMXopsLCnZu j9Eyaf1fJwajkHcON36eKaqMZiG8EhO3eJjOYXzPwwn62BhJuOndwJVJXIjyrYWEtueT a+7g+eAku4Vb692ilfkS50wMYah4Khw/pEa/6BUwI85VIqpJL/mhikoR7+GEatcZs5m2 nh/ZZ2Ehr8OtsobQMPJ4O7ulEpBZWE+/lQblhlCMKDfMdoLr7AocjZsk1NA3Nf6gGZ/k bDSkID9Vil67ZdFEgvkIud+/ddDTcVURQetJSZz+vtTdphAVU7QrlvbyDF4Hcn4oat3A Kx9Q== X-Gm-Message-State: ABUngvcREqp5SL+Lc3Rkg+yKEK4v6LQYsdR6CqiYeGzXEhjM4brrNrbaxeHkU2Ne04ApMnxEWnMCWgAImOQd/Q== X-Received: by 10.31.78.134 with SMTP id c128mr3180665vkb.25.1478110232584; Wed, 02 Nov 2016 11:10:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.35.134 with HTTP; Wed, 2 Nov 2016 11:10:32 -0700 (PDT) From: Dragana Damjanovic Date: Wed, 2 Nov 2016 19:10:32 +0100 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114845385a27540540555b98 Archived-At: Subject: [QUIC] Comment on draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 02 Nov 2016 18:10:35 -0000 --001a114845385a27540540555b98 Content-Type: text/plain; charset=UTF-8 Hi, I had a quick look at draft-thomson-quic-tls-01. My apologies if I miss something. During a handshake a client can received messages form a serve in clear text, protected by 0-RTT key and 1-RTT key. There is only one bit to distinguish which of the 2 keys or clear text is used. This will need more explanation, e.g. how to distinguish a clear text server hello and messages protected with 1-RTT key, as well as a a server hello protected with 0-RTT key and messages protected with 1-RTT key. This 2 combination can be confused if some of packets get lost. Maybe this is left for the next update of the draft (in that case sorry for the noise). dragana --001a114845385a27540540555b98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I had a quick look at draft-tho= mson-quic-tls-01. My apologies if I miss something.

Duri= ng a handshake a client can received messages form a serve in clear text, p= rotected by 0-RTT key and 1-RTT key. There is only one bit to distinguish w= hich of the 2 keys or clear text=C2=A0 is used. This will need more explana= tion, e.g. how to distinguish a clear text server hello and messages protec= ted with 1-RTT key, as well as a a server hello protected with 0-RTT key an= d messages protected with 1-RTT key. This 2 combination can be confused if = some of packets get lost.
Maybe this is left for the next upd= ate of the draft (in that case sorry for the noise).


= dragana
--001a114845385a27540540555b98-- From nobody Wed Nov 2 18:20:46 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7121296D7 for ; Wed, 2 Nov 2016 18:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TT3plPNI72tw for ; Wed, 2 Nov 2016 18:20:43 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B4D129409 for ; Wed, 2 Nov 2016 18:20:42 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id o68so39856765qkf.3 for ; Wed, 02 Nov 2016 18:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U7uKObZN29adOPFtHS03Xa0UyjQZ7OOroEtXMjXpgtc=; b=qEB/398d1VImXD0ZYY4hElaNCkiK6FtYuOp4OBC8JpKA7i9X20daNnE+s0/N3mkCst be9w+1JxlpPUnYp1rT7ze9HN4Ck0cGpd6AgIma1KUMY3+07uM2i64AP+sZ5oUnJGV4bH K65DdurfCHJ8fCRmUu/QYRGMjXpoUwR84AkDCvXmkIvxyucm4CzWcs8P9hIHizkyB2XN YEXn8Qrzmd3llu0m4T2LUf+voTRSY8yOR/W+/KEJMTEXuvRk7jUgFfI3eYKuLY7IxBgy /nJQ7yXIBzNUNSpmjjgyyhPqscoX+Q8zPGWyjncBpMXfWuQieLuskRScHDNhqXVnYWBu TbGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U7uKObZN29adOPFtHS03Xa0UyjQZ7OOroEtXMjXpgtc=; b=CoP0o58Bv5bqNuhOvYdlOgCgtTZoFIMsNLeBkwHJL8VuUq32U6lATXn/qxoTrm8JVg xCsjz536k10Y689dHszDBQOh5bmGakYjHwG9lkeEkkTmiXVsInI3uYM3krCtxiGr9FEW k0inh43pCqea4IZrEpKIcD5mzzDaCebqZ9jJBshwErRhH5w0I97MyO8bYos4C1+LQu+l 2m5mmM1WGX3H2aICIt9jZPe6KybjaRkJ04oitI6QviwNHmOHY7stmWk9VZcsoQPmylIb RXNuD4NnGiLpC+a9KK34yubIIUixhm9qOgmULeVr0yIA80yfbJwpkHn8GRyC7Fpo/BIu tCHw== X-Gm-Message-State: ABUngvcRVMkxCo7HhYZLwfM0x8TB7EOO/UgaskapkHm8BiJAZt7BRJJqNZ3rBFptKKeZ8zJnmCnoBHc6gyQqzg== X-Received: by 10.55.99.141 with SMTP id x135mr5325304qkb.147.1478136041869; Wed, 02 Nov 2016 18:20:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 2 Nov 2016 18:20:41 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 3 Nov 2016 12:20:41 +1100 Message-ID: To: Dragana Damjanovic Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Comment on draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 03 Nov 2016 01:20:44 -0000 On 3 November 2016 at 05:10, Dragana Damjanovic wrote: > During a handshake a client can received messages form a serve in clear > text, protected by 0-RTT key and 1-RTT key. There is only one bit to > distinguish which of the 2 keys or clear text is used. This will need more > explanation, e.g. how to distinguish a clear text server hello and messages > protected with 1-RTT key, as well as a a server hello protected with 0-RTT > key and messages protected with 1-RTT key. This 2 combination can be > confused if some of packets get lost. > Maybe this is left for the next update of the draft (in that case sorry for > the noise). The fact that the current version allows the server to encipher with the 0-RTT key is a bug. That violates the security guarantees TLS provides regarding key use (it's a subtle thing, but it's down to the way the formal analysis of TLS has been performed). I neglected to merge the PR that talks about this before submitting, but my copy here is up to date: https://martinthomson.github.io/quic-tls/ Generally speaking, there are only two different keys in use for any given direction at any one time. This includes cleartext vs. 1-RTT. The epoch bit helps to identify which of those is in play. I intend to do a bit of an overhaul of this stuff, since it's the most complicated and confusing part of the draft. It's also the kludgiest because it requires integration with packet acknowledgment. The trickiest part is that TLS cleartext handshake packets need to be retransmitted using the cleartext epoch (or the 0-RTT epoch for the client's second flight if 0-RTT was accepted), even if you have 1-RTT keys. This means that you can't move to the next epoch until you are certain that you don't need to retransmit any handshake packets. The only good part is that as far as QUIC is concerned handshake packets are always cleartext or 0-RTT and you always know which. From nobody Thu Nov 3 07:14:41 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88431299F5 for ; Thu, 3 Nov 2016 07:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4RznW5p9-5qw for ; Thu, 3 Nov 2016 07:14:39 -0700 (PDT) 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 0C76A1299D1 for ; Thu, 3 Nov 2016 07:14:39 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id d65so40918866vkg.0 for ; Thu, 03 Nov 2016 07:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P2B4UUuDZ7YykzvlTtPp5MttGi+Cdb2lR/GdM13vr+M=; b=P7jP2UraEniMCwYFi2tYm9d3xnjWhGE0Sj/WF/UPL/A3fDhHjWrxQZMHiHygM4e8EB c1LJ03LglMRqUq+S/A3A8YiZ9SMEzALVBZflL/SiPe232PJc/TzkRJ5sWZXX0yukyG/E xHNs7ZDcQew7vTOXWHioWHmpuWilZKDDMZS2bKVX1Pm+ezJuMP2CqKovuFavty3iTd8g n50SYJG732XXZ4jYMHOhN2QYKHqggKpIPKxqwFdRu0Z4VBki4GWWdJkIChX9Ar5cL4Zw Eh7Y23AoX0iWj0qSA9rdCv901fsDyVt5PG64K1uRdgj3T9978rF4bEztSh5nugdSY3KY bMHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P2B4UUuDZ7YykzvlTtPp5MttGi+Cdb2lR/GdM13vr+M=; b=O8ecrLOTDXdrKuNWFE95UeQBejFr2VBykjPl/opCBxrQLbVsxGWTw6sRsjuP0Zdds8 7gbt48PY0sbGdV4BB5VihnNFlPuwhRKZ22Z2C79Xo5KJf1xRcy7n3wJlhojwmihFmj2p EOWsZeAfGLkByORpyJamuIrDXcbKBn2LS8m02nL2oWw+Ft0w8yh/Fc+8DOS0pIfh6jJu R6jqLsVI6VKscoU4Kx3ecNQQLzNbwHhKx+tTCSh5OVXTjbcWAbN9wZzpWEun3KO0pqSt yh18mGmNM58IKZdTSVkxse0TTCL3PXIWGu4GnNuxM2Jl00O4YOVu2vBXMld+CxewB7SZ ZvFw== X-Gm-Message-State: ABUngvecKVdfYl94pO8DiP05HwOJC2oe5quJRRB0WBc/8MFvdPK1j+GlOnER3Xj5JV+8yK2MgqrKpyn4wEKtuQ== X-Received: by 10.31.106.196 with SMTP id f187mr6570645vkc.33.1478182478152; Thu, 03 Nov 2016 07:14:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.35.134 with HTTP; Thu, 3 Nov 2016 07:14:37 -0700 (PDT) In-Reply-To: References: From: Dragana Damjanovic Date: Thu, 3 Nov 2016 15:14:37 +0100 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e022e8606600540662d67 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Comment on draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 03 Nov 2016 14:14:41 -0000 --001a114e022e8606600540662d67 Content-Type: text/plain; charset=UTF-8 Sorry I have not looked at you repo, I was just reading the last 01 draft. With the new version the problem is resolved. The transition from 0-RTT to 1-RTT still needs to be fixed. The draft says it will switch to 1-RTT after sending finish message, but it can't. That is what you are saying in this e-mail? It needs to continue using 0-RTT until client finish message is acked. dragana On Thu, Nov 3, 2016 at 2:20 AM, Martin Thomson wrote: > On 3 November 2016 at 05:10, Dragana Damjanovic > wrote: > > During a handshake a client can received messages form a serve in clear > > text, protected by 0-RTT key and 1-RTT key. There is only one bit to > > distinguish which of the 2 keys or clear text is used. This will need > more > > explanation, e.g. how to distinguish a clear text server hello and > messages > > protected with 1-RTT key, as well as a a server hello protected with > 0-RTT > > key and messages protected with 1-RTT key. This 2 combination can be > > confused if some of packets get lost. > > Maybe this is left for the next update of the draft (in that case sorry > for > > the noise). > > The fact that the current version allows the server to encipher with > the 0-RTT key is a bug. That violates the security guarantees TLS > provides regarding key use (it's a subtle thing, but it's down to the > way the formal analysis of TLS has been performed). I neglected to > merge the PR that talks about this before submitting, but my copy here > is up to date: https://martinthomson.github.io/quic-tls/ > > Generally speaking, there are only two different keys in use for any > given direction at any one time. This includes cleartext vs. 1-RTT. > The epoch bit helps to identify which of those is in play. I intend > to do a bit of an overhaul of this stuff, since it's the most > complicated and confusing part of the draft. It's also the kludgiest > because it requires integration with packet acknowledgment. > > The trickiest part is that TLS cleartext handshake packets need to be > retransmitted using the cleartext epoch (or the 0-RTT epoch for the > client's second flight if 0-RTT was accepted), even if you have 1-RTT > keys. This means that you can't move to the next epoch until you are > certain that you don't need to retransmit any handshake packets. The > only good part is that as far as QUIC is concerned handshake packets > are always cleartext or 0-RTT and you always know which. > --001a114e022e8606600540662d67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry I have not looked at you repo, I was just readi= ng the last 01 draft.

With the new version the problem is resolved.= The transition from 0-RTT to 1-RTT still needs to be fixed. The draft says= it will switch to 1-RTT after sending finish message, but it can't. Th= at is what you are saying in this e-mail? It needs to continue using 0-RTT = until client finish message is acked.

dragana

On Thu, Nov 3, 2016 = at 2:20 AM, Martin Thomson <martin.thomson@gmail.com>= wrote:
On 3 November 2016 at 05:10, Drag= ana Damjanovic
<dragana.d= amjano@gmail.com> wrote:
> During a handshake a client can received messages form a serve in clea= r
> text, protected by 0-RTT key and 1-RTT key. There is only one bit to > distinguish which of the 2 keys or clear text=C2=A0 is used. This will= need more
> explanation, e.g. how to distinguish a clear text server hello and mes= sages
> protected with 1-RTT key, as well as a a server hello protected with 0= -RTT
> key and messages protected with 1-RTT key. This 2 combination can be > confused if some of packets get lost.
> Maybe this is left for the next update of the draft (in that case sorr= y for
> the noise).

The fact that the current version allows the server to encipher with=
the 0-RTT key is a bug.=C2=A0 That violates the security guarantees TLS
provides regarding key use (it's a subtle thing, but it's down to t= he
way the formal analysis of TLS has been performed).=C2=A0 I neglected to merge the PR that talks about this before submitting, but my copy here
is up to date: https://martinthomson.github.io/quic-tl= s/

Generally speaking, there are only two different keys in use for any
given direction at any one time.=C2=A0 This includes cleartext vs. 1-RTT. The epoch bit helps to identify which of those is in play.=C2=A0 I intend to do a bit of an overhaul of this stuff, since it's the most
complicated and confusing part of the draft.=C2=A0 It's also the kludgi= est
because it requires integration with packet acknowledgment.

The trickiest part is that TLS cleartext handshake packets need to be
retransmitted using the cleartext epoch (or the 0-RTT epoch for the
client's second flight if 0-RTT was accepted), even if you have 1-RTT keys.=C2=A0 This means that you can't move to the next epoch until you = are
certain that you don't need to retransmit any handshake packets.=C2=A0 = The
only good part is that as far as QUIC is concerned handshake packets
are always cleartext or 0-RTT and you always know which.

--001a114e022e8606600540662d67-- From nobody Thu Nov 3 10:45:37 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B970129ABD for ; Thu, 3 Nov 2016 10:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnZDbs1cHQM8 for ; Thu, 3 Nov 2016 10:45:31 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 952D4129A7F for ; Thu, 3 Nov 2016 10:45:31 -0700 (PDT) Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) by linode64.ducksong.com (Postfix) with ESMTPSA id 947B23A015 for ; Thu, 3 Nov 2016 13:45:29 -0400 (EDT) Received: by mail-yw0-f176.google.com with SMTP id h14so57431884ywa.2 for ; Thu, 03 Nov 2016 10:45:29 -0700 (PDT) X-Gm-Message-State: ABUngveVtErjt00HtcdCnaz/AIFkx5Zd5MAlDAwsErLsV2JuWmDXrvyTZoiUd8OnXW2Db8psmSekI808hQgr9w== X-Received: by 10.36.39.85 with SMTP id g82mr6266533ita.52.1478195129272; Thu, 03 Nov 2016 10:45:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.236 with HTTP; Thu, 3 Nov 2016 10:45:28 -0700 (PDT) From: Patrick McManus Date: Thu, 3 Nov 2016 13:45:28 -0400 X-Gmail-Original-Message-ID: Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a1147cc5c96d27d0540691fc7 Archived-At: Subject: [QUIC] Early Editorial Review Comment draft-hamilton-quic-transport-protocol-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 03 Nov 2016 17:45:35 -0000 --001a1147cc5c96d27d0540691fc7 Content-Type: text/plain; charset=UTF-8 Ryan, Jana, et al - thanks for the draft updates! Its no fun taking running code and turning it into an IETF document :) Hopefully this review helps in that process. I have read fairly thoroughly through draft-hamilton-quic-transport-protocol-01 and have some initial comments. These are largely, but not completely, editorial in nature.I have also read the companion documents, though not yet as closely. Its possible I'm saying something that is contradicted in their details - though I think this reflects on how we choose to arrange the document split. 0] *There is really very little talk about addressing.* In TCP, this was obvious - the 5 tuple identifies the connection and binds the addressing into the transport. Not much to say. But quic awesomely separates the connection identifier without really talking about how addressing has to work. There is a TODO about rebinding that is obviously part of this (github issue!), but even the original binding is underspecified (e.g. where is the server side of the client handshake addressed to?). Its also not clear how the STK applies to this, and that goes into security considerations etc, etc.. There are some intuitive answers to these questions, but we ought to document. 1] *Draft Intended Status is listed as experimenta*l. What's up with that? Standards Track I would hope, or I'm going home now :) 2] *Use of QUIC Receiver* - is that an endpoint, or is it meant to be broader like an intermediary who reads QUIC? its not defined.. but because when it talks about flow control it is really talking about sending I suspect it is a endpoint.. so I would change it to endpoint 3] Re version field "*This mechanism eliminates roundtrip latency when the client's optimistically-chosen version is spoken by the server, and incentivizes servers to not lag behind clients in deployment of newer versions*." - You could also argue that it dis-incentivizes clients from upgrading to newer versions for fear of triggering fallback :).. Personally, I would design it the same way as documented but rationalize it differently (i.e. we expect the common case to be a version match and want to enable client sends first) - the document doesn't imo really benefit from including design rationale unless it helps the reader make a better implementation. This is a fuzzy line and a general comment - I just wanted to get it out there.. personally I would just remove the rationale and leave the facts - do you really want to write about every design decision (e.g. little endian!) and have to review the rationale text in addition to the normative text? 4]* quic version* - what version does this document describe? I would say its time to start putting tokens in. Getting this right early will really help with rapid evolution. h2 used npn tokens which were kind of an inifinite space, so we just put "draft" in all the names. One thing quic might consider is just setting the high bit for all the pre-RFC version numbers (and bumping it one on each new draft).. then we can clear it for the final draft and have plenty of time to forget those implementations ever existed. *5] "PUBLIC_RESET packets that reset a connection are currently not authenticated."* the word currently is weird now that we're in the IETF process. The version of the protocol described by this draft has a PUBLIC_RESET packet that is not authenticated. period. The next draft might say something different - and if you think it might the 'right' thing to do would be to open a github design issue for tracking when the group gets that far.. I guess this maps to the DISCUSS_AND_MODIFY annotations you've got now - which seems helpful. *6] Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC packet boundary.* I think you only need one part of this right? Otherwise you need to define what a QUIC packet boundary is in some way that doesn't match what it seems like it is. *7] 4.2.2 doesn't really describe how to find the type very well*.. I think you could make it a simple enumeration by saying that 0x80 -> 0xFF is stream, 0x40 -> 0x7F is ack, and the others are 8 are constants < 0x40 *8] in 4.3 label "2nd supported version (32) supported"* seems like a typo (double supported) *9] 5.2 is really frustrating. In general, the transport+tls+http-binding documents make it really hard to figure out what a handshake would look like. The decomposition strategy of the documents is weakest here - and its a very important part. *I'm concerned this is going to be an interop problem. It might be signficantly easier to document if we restricted quic to TLS. I think it is something that should be opened as a design issue for the WG to discuss. Its really weird for a transport document to declare the handshake protocol out of scope and not even be able to include it cleanly by reference. *10] in 7 "A sender bundles one or more frames in a Regular QUIC packet. A sender MAY bundle any set of frames in a packet. All QUIC packets MUST contain a packet number and MAY contain one or more frames.. "* This is kind of a mess. Frames only apply to regular packets right? Specifically version negotiation packets have ambiguous lengths if they don't just fill the quic packet - so we don't want to say All QUIC packets MAY contain.. *11] *i*n 4.2 the first packet sent by an endpoint MUST have a packet number of 1. but in 7 the first packet in both directions of the connection MUST have a packet number of 0. *I don't know how to reconcile this. *12] 6.2 seems to let the sender skip arbitrary packet numbers..* except packet 0/1 is required so the language should be tightened perhaps? Optimistically, -Patrick --001a1147cc5c96d27d0540691fc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ryan, Jana, et al - thanks for the draft updates! Its= no fun taking running code and turning it into an IETF document :) Hopefully this=20 review helps in that process.

I have read fairly thoroughly th= rough draft-hamilton-quic-transport-protocol-01 and have some initial comments. These are largely, but not completely,=20 editorial in nature.I have also read the companion documents, though not yet as closely. Its possible I'm saying something that is contradicted= =20 in their details - though I think this reflects on how we choose to=20 arrange the document split.

0] There is really v= ery little talk about addressing. In TCP, this was obvious - the 5 tuple identifies the connection and=20 binds the addressing into the transport. Not much to say. But quic=20 awesomely separates the connection identifier without really talking=20 about how addressing has to work. There is a TODO about rebinding that=20 is obviously part of this (github issue!), but even the original binding is underspecified (e.g. where is the server side of the client=20 handshake addressed to?). Its also not clear how the STK applies to=20 this, and that goes into security considerations etc, etc.. There are=20 some intuitive answers to these questions, but we ought to document.

1] Draft Intended Status is listed as experimental= . What's up with that? Standards Track I would hope, or I'm going h= ome now :)

2] Use of QUIC Receiver - is that an endpoint, or is it meant to be broader like an=20 intermediary who reads QUIC? its not defined.. but because when it talks about flow control it is really talking about sending I suspect it is a endpoint.. so I would change it to endpoint

3] Re version field &qu= ot;This mechanism eliminates roundtrip latency when the client's =20 optimistically-chosen version is spoken by the server, and =20 incentivizes servers to not lag behind clients in deployment of newer =20 versions." - You could also argue that it dis-incentivizes clients= =20 from upgrading to newer versions for fear of triggering fallback :)..=20 Personally, I would design it the same way as documented but rationalize it differently (i.e. we expect the common case to be a version match=20 and want to enable client sends first) - the document doesn't imo reall= y benefit from including design rationale unless it helps the reader make a better implementation. This is a fuzzy line and a general comment - I just wanted to get it out there.. personally I would just remove the=20 rationale and leave the facts - do you really want to write about every=20 design decision (e.g. little endian!) and have to review the rationale=20 text in addition to the normative text?

4] quic versio= n - what version does this document describe? I would say its time to=20 start putting tokens in. Getting this right early will really help with=20 rapid evolution. h2 used npn tokens which were kind of an inifinite=20 space, so we just put "draft" in all the names. One thing quic mi= ght=20 consider is just setting the high bit for all the pre-RFC version=20 numbers (and bumping it one on each new draft).. then we can clear it=20 for the final draft and have plenty of time to forget those=20 implementations ever existed.
5] "PUBLIC_RESET packets that reset a connection ar=
e currently not authenticated."
the word currently is weird now that we're in the IETF process. The versio= n of the protocol described by this draft has a PUBLIC_RESET packet that=20 is not authenticated. period. The next draft might say something=20 different - and if you think it might the 'right' thing to do would= be=20 to open a github design issue for tracking when the group gets that=20 far.. I guess this maps to the DISCUSS_AND_MODIFY annotations you've go= t now - which seems helpful.
6] Frames MUST fit within a single QUI=
C packet and MUST NOT span a QUIC packet boundary.
I think you only need one part of this right? Otherwise you need to=20 define what a QUIC packet boundary is in some way that doesn't match=20 what it seems like it is.

7] 4.2.2 doesn't really = describe how to find the type very well.. I think you could make it a simple enumeration by saying that 0x80=20 -> 0xFF is stream, 0x40 -> 0x7F is ack, and the others are 8 are=20 constants < 0x40

8] in 4.3 label "2nd supporte= d version (32) supported" seems like a typo (double supported)
=
9] 5.2 is really frustrating. In general, the transport+tls+http-binding=20 documents make it really hard to figure out what a handshake would look=20 like. The decomposition strategy of the documents is weakest here - and=20 its a very important part.=C2=A0 I'm concerned this is going to be = an=20 interop problem. It might be signficantly easier to document if we=20 restricted quic to TLS. I think it is something that should be opened as a design issue for the WG to discuss. Its really weird for a transport=20 document to declare the handshake protocol out of scope and not even be=20 able to include it cleanly by reference.

10] in 7=20 "A sender bundles one or more frames in a Regular QUIC packet. A =20 sender MAY bundle any set of frames in a packet. All QUIC packets =20 MUST contain a packet number and MAY contain one or more frames.. "
This is kind of a mess. Frames only apply to regular packets right?=20 Specifically version negotiation packets have ambiguous lengths if they=20 don't just fill the quic packet - so we don't want to say All QUIC= =20 packets MAY contain..

11] in 4.2=20 the first packet sent by an endpoint MUST have a packet number of 1. but in 7 the first packet in both directions of the connection MUST have a=20 packet number of 0. I don't know how to reconcile this.

12] 6.2 seems to let the sender skip arbitrary packet numbers.. except packet 0/1 is required so the language should be tightened perhap= s?

Optimistically,
-Patrick
--001a1147cc5c96d27d0540691fc7-- From nobody Thu Nov 3 14:29:17 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B340F1296B5 for ; Thu, 3 Nov 2016 14:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmtbjGe0SZ0h for ; Thu, 3 Nov 2016 14:29:13 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1501294B0 for ; Thu, 3 Nov 2016 14:29:13 -0700 (PDT) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.161.181]) by linode64.ducksong.com (Postfix) with ESMTPSA id 425AE3A015 for ; Thu, 3 Nov 2016 17:29:10 -0400 (EDT) Received: by mail-yw0-f181.google.com with SMTP id r204so67649082ywb.0 for ; Thu, 03 Nov 2016 14:29:10 -0700 (PDT) X-Gm-Message-State: ABUngvcvfMABafad2v9jalSWQTXFTrheRcMolqDnazVNWoWonKBdlfnTZ3jRQ/QAHgkbgs96kI0EdJX/51zQ2g== X-Received: by 10.107.205.13 with SMTP id d13mr3884574iog.8.1478208550043; Thu, 03 Nov 2016 14:29:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.236 with HTTP; Thu, 3 Nov 2016 14:29:09 -0700 (PDT) From: Patrick McManus Date: Thu, 3 Nov 2016 17:29:09 -0400 X-Gmail-Original-Message-ID: Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=94eb2c187b4087894a05406c3f0e Archived-At: Subject: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 03 Nov 2016 21:29:15 -0000 --94eb2c187b4087894a05406c3f0e Content-Type: text/plain; charset=UTF-8 Hi Robbie, Mike, et al. Thanks for getting the ball rolling with https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00.. I have a thought on the mapping - Putting all of the header frames onto one in-order stream is a pretty big hammer. Is there stomach for looking at a strategy where hpack references the dynamic table state via some kind of instruction counter? That way the headers could be on the data (>=5) stream and just the dynamic table manipulation stuff from hpack could be on stream 3.. implementations would be able to choose whether to generate hpack that referenced the current counter or an older one (within some window).. an older one is going to be more robust to reordering happening on stream 3 so the dep between the streams is loosened. Anecdotally the rate of change of the dynamic table slows down (though I have no data - could collect it if we're serious) after an initial burst and at that point not using table updates until they've been acked could be a reasonable thing to do... and this even allows pre-populating the dynamic table at setup time with site-local values rather than in response to a query. Rewinding to any particular instruction seems to be a big burden, but we could probably do some things with checkpoints and acks to bound it all. this is a fairly significant bit of surgery to h2's formats, but given that one of the real quic opportunities is to perform better under loss it could be worthwhile to sever ordering dependencies even further. Seems like a reasonable thing to investigate to me. Thanks -Patrick --94eb2c187b4087894a05406c3f0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robbie, Mike, et al. Thanks for getting = the ball rolling with https://tools.ietf.org/html/draft-shade-quic-http2-map= ping-00..

I have a thought on the mapping - Putting = all of the header frames onto one in-order stream is a pretty big hammer. <= br>
Is there stomach for looking at a strategy where hpack references th= e dynamic table state via some kind of instruction counter? That way the he= aders could be on the data (>=3D5) stream and just the dynamic table man= ipulation stuff from hpack could be on stream 3.. implementations would be = able to choose whether to generate hpack that referenced the current counte= r or an older one (within some window).. an older one is going to be more r= obust to reordering happening on stream 3 so the dep between the streams is= loosened. Anecdotally the rate of change of the dynamic table slows down (= though I have no data - could collect it if we're serious) after an ini= tial burst and at that point not using table updates until they've been= acked could be a reasonable thing to do... and this even allows pre-popula= ting the dynamic table at setup time with site-local values rather than in = response to a query. Rewinding to any particular instruction seems to be a = big burden, but we could probably do some things with checkpoints and acks = to bound it all.

this is a fairly signif= icant bit of surgery to h2's formats, but given that one of the real qu= ic opportunities is to perform better under loss it could be worthwhile to = sever ordering dependencies even further. Seems like a reasonable thing to = investigate to me.

Thanks
-Patrick

--94eb2c187b4087894a05406c3f0e-- From nobody Thu Nov 3 14:40:00 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 182BC129AD9 for ; Thu, 3 Nov 2016 14:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2E-VeYmnVm55 for ; Thu, 3 Nov 2016 14:39:57 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id CE940129980 for ; Thu, 3 Nov 2016 14:39:57 -0700 (PDT) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com [209.85.218.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id 6DE943A015 for ; Thu, 3 Nov 2016 17:39:57 -0400 (EDT) Received: by mail-oi0-f46.google.com with SMTP id v84so112900490oie.3 for ; Thu, 03 Nov 2016 14:39:57 -0700 (PDT) X-Gm-Message-State: ABUngvfOjzp9zgMzi8cfNRK5hdslNAZo4A3vtYbYelzIGIePuyuWyZtRbY4B6qIo00JWBxVP7EKu22IL229rmg== X-Received: by 10.107.57.135 with SMTP id g129mr2772288ioa.178.1478209197054; Thu, 03 Nov 2016 14:39:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.236 with HTTP; Thu, 3 Nov 2016 14:39:56 -0700 (PDT) From: Patrick McManus Date: Thu, 3 Nov 2016 17:39:56 -0400 X-Gmail-Original-Message-ID: Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114ac3e218237c05406c6649 Archived-At: Subject: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 03 Nov 2016 21:39:59 -0000 --001a114ac3e218237c05406c6649 Content-Type: text/plain; charset=UTF-8 Hi Robbie, Mike, et al. Thanks for getting the ball rolling with https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00.. What is the thinking about rfc 7540 h2 extensions and the h2/quic mapping.. particularly the way it allows unspecified frame types which may or may not require negotiation. it seems some of these extensions may have stateful issues across streams, ala hpack and some may not. If the extension were only defined for h2-over-quic that would be for the extension to sort out.. but it doesn't seem like we are limiting things to quic vs tcp, or are we? -Patrick --001a114ac3e218237c05406c6649 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robbie, Mike, et al. Thanks for get= ting the ball rolling with https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00..

What is the thi= nking about rfc 7540 h2 extensions and the h2/quic mapping.. particularly t= he way it allows unspecified frame types which may or may not require negot= iation.

it seems some of these extensions may have stateful is= sues across streams, ala hpack and some may not.

If the extens= ion were only defined for h2-over-quic that would be for the extension to s= ort out.. but it doesn't seem like we are limiting things to quic vs tc= p, or are we?

-Patrick

--001a114ac3e218237c05406c6649-- From nobody Thu Nov 3 14:52:53 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC82512944A for ; Thu, 3 Nov 2016 14:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.63 X-Spam-Level: X-Spam-Status: No, score=-0.63 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_IMAGE_ONLY_12=2.059, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] 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 czPUUqABlDav for ; Thu, 3 Nov 2016 14:52:49 -0700 (PDT) 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 725B0127A91 for ; Thu, 3 Nov 2016 14:52:49 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id v84so113585436oie.3 for ; Thu, 03 Nov 2016 14:52:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=uv0rv69etqTG9eI4GfE/QWLRTSvLDdAKvrfauP3PC74=; b=rEEqMBNC4LAuBN57CozQ8i9pyE3McsJ5A39zqZYCklAXzBMleuweNa7W/q+dDS3Vul Jt9mNOzQEHPjYELRi0mRNefaawibE6m22icGrWXwx92iDWYpLZltNn/5ujZViIjUBlRZ R4mPbIFyw5HztfS1x3C5DJx0lXyjBmwowRdq2HvtMPfgKmipEzgB5lH/Yf9KY874Akci ghtEa3HNCTLJjLAEkg+Wvl8vc8ppRi8MVYo0M5OMAhC0Jy4nD0Vqc8orl3eIBvLIcDoC VQpOBpWxgfpeyUA++Jh0svdAOl7sZZPBNjPG7+Zjzq5N1/zKfA2gRxmR1ezhskbr2JHu Wz7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uv0rv69etqTG9eI4GfE/QWLRTSvLDdAKvrfauP3PC74=; b=f1AQM5LDG1ZwIjFUO525Kr8k/HAvaCwOOUedrG8zX7LaJaEnQ3ANB0RrxJt75Agthz wk14wzdK7bVMdFQoK/lxNIyBO4yPhdjIKwRNDGejQL7ZYdu+dK1M/lpk28M1byvocWx2 466QIfTOvzJWu5u8XpAJpVgotIz23vdSvXwGKQ90czpG12/R02B1RJMXIbY76dmJvAbq BzJAFCLgS6h7DQvGNHeliVChz9snaY7UcucFNGYXevjUgSmCMeT7xKZGkrvZvu/gKUt5 GC42xh6CAYkWWnxTdWvF3xyewuRienCVtLcF/lZq5dpU1bPTuu8mPVhqQT8vPp/yrBi1 BQmg== X-Gm-Message-State: ABUngvd321T3LeP3q0p/Syp9b8SywDCX3Ji7nsQAxsC9SIECFH+WSd9VoQiMfQMP9vuEay1KoyCi6tk6nCltMw== X-Received: by 10.107.57.135 with SMTP id g129mr2805742ioa.178.1478209968467; Thu, 03 Nov 2016 14:52:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.236 with HTTP; Thu, 3 Nov 2016 14:52:48 -0700 (PDT) From: Patrick McManus Date: Thu, 3 Nov 2016 17:52:48 -0400 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114ac3e213128005406c94bd Archived-At: Subject: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 03 Nov 2016 21:52:51 -0000 --001a114ac3e213128005406c94bd Content-Type: text/plain; charset=UTF-8 Hi Robbie, Mike, et al. Thanks for getting the ball rolling with https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00.. What is the thinking about rfc 7540 h2 extensions and the h2/quic mapping.. particularly the way it allows unspecified frame types which may or may not require negotiation. it seems some of these extensions may have stateful issues across streams, ala hpack and some may not. If the extension were only defined for h2-over-quic that would be for the extension to sort out.. but it doesn't seem like we are limiting things to be defined in quic vs tcp, or are we? -Patrick --001a114ac3e213128005406c94bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robbie, M= ike, et al. Thanks for getting the ball rolling with https= ://tools.ietf.org/html/draft-shade-quic-http2-mapping-00..
What is the thinking about rfc 7540 h2 extensions and the h2/quic mapping..=20 particularly the way it allows unspecified frame types which may or may=20 not require negotiation.

it seems some of these extensions may= have stateful issues across streams, ala hpack and some may not.

If the extension were only defined for h2-over-quic that would be for the=20 extension to sort out.. but it doesn't seem like we are limiting things= =20 to be defined in quic vs tcp, or are we?

-Patrick
--001a114ac3e213128005406c94bd-- From nobody Thu Nov 3 15:35:59 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2946D129874 for ; Thu, 3 Nov 2016 15:35:58 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibXF85IldSAR for ; Thu, 3 Nov 2016 15:35:55 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0118.outbound.protection.outlook.com [104.47.34.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B1B12986E for ; Thu, 3 Nov 2016 15:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PG8hOXwzD4jDeUglQytcRMnD7t5CMW5LBTiHPLUGRX0=; b=S5s7lMaOyYsu2EOS8gSh3aKPwpKxa9kEnSfhevOL03HXyoggYffqwwMvgophTNfC4U7XlV5you0jZTE2MouWBbyEUq8rBTJIUVhLPxO86fQkwpM1Jav6+4HBilV5mofjs0wyv0CguVZ+7FNvOySRqdP5Y1w5r+1Bw8R6hKX5yPQ= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Thu, 3 Nov 2016 22:35:53 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0693.009; Thu, 3 Nov 2016 22:35:53 +0000 From: Mike Bishop To: Patrick McManus , "quic@ietf.org" Thread-Topic: [QUIC] h2 mapping - hpack dynamic table by reference Thread-Index: AQHSNhlXVDFlp6NaHU6EWkOyW4vQq6DH1GNw Date: Thu, 3 Nov 2016 22:35: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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:f::157] x-ms-office365-filtering-correlation-id: c3478acf-9f5c-4469-ce6f-08d40439c553 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:vXznxuhHBxqPXalfhUGmtw+ZU6ow2tyeUarkiACTSVHjRsM+LqfSnHrsLMojie0VS33yTfiyo3dqzhbxcNiiJ0uhZI5+pY7VNqtoki6JY7rNdFWIjh/1ffCyTVgeieJb9pVoG/kGKw7u6css1avUk+uf4FEBYw7Wol6VtyuH8VFqFuNcWGFlxYZsc5G5+RsTQY+fM771a5x3V9dSbnEG5r4QHoJ40ID6LYYXRc9wEU+Rza9qXbeo6BqPnqtCCLqiC6YZwZhL1KzicWKrscI/cPYgP/bA1vUVuVlZ1Ny1YXsvICRhSyCCwBOonxhMkMyIr5Rhsw2v8ox3vBP3hVEAaY1R3kjsKMixluhxTh1gyngr6ynLwMdRy95C+gYuzVDN x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2706; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(6045074)(6060222)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6061219)(6046074); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 011579F31F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(377454003)(199003)(189998001)(97736004)(9686002)(5001770100001)(76576001)(2950100002)(7736002)(7846002)(5660300001)(81166006)(8676002)(107886002)(81156014)(11100500001)(102836003)(19580405001)(19580395003)(74316002)(586003)(790700001)(19300405004)(6116002)(3280700002)(2900100001)(87936001)(3660700001)(8936002)(19609705001)(54356999)(10400500002)(10290500002)(122556002)(33656002)(76176999)(50986999)(5005710100001)(86362001)(10090500001)(101416001)(2501003)(7696004)(2906002)(19625215002)(92566002)(7906003)(19617315012)(106356001)(68736007)(105586002)(77096005)(5002640100001)(8990500004)(99286002)(106116001)(15975445007)(86612001)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708E353447E58F702ACCF1987A30BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2016 22:35:53.4812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 03 Nov 2016 22:35:58 -0000 --_000_BN6PR03MB2708E353447E58F702ACCF1987A30BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFuYSBhbmQgSSB3ZXJlIHRhbGtpbmcgYWJvdXQgdGhhdCBhdCB0aGUgSFRUUCBXb3Jrc2hvcC4g IFRoZSBjdXJyZW50IHNvbHV0aW9uIGlzIHByb2JhYmx5IHRoZSBiZXN0IHRoYXQgY2FuIGJlIGFj aGlldmVkIHdpdGhvdXQgbW9kaWZ5aW5nIEhQQUNLLCBiZWNhdXNlIEhQQUNLIHRha2VzIGEgaGFy ZCBkZXBlbmRlbmN5IG9uIHJlbGlhYmxlIGluLW9yZGVyIGRlbGl2ZXJ5LCB3aGljaCBhIGRlZGlj YXRlIHN0cmVhbSBjYW4gcHJvdmlkZS4gIElmIHdlIHdlcmUgdG8gZGVmaW5lIEhQQUNLdjIgKG9y IFFQQUNLLCBpZiB5b3UgcHJlZmVyKSBhbmQgbWFrZSBpdHMgc2VtYW50aWNzIG1vcmUgb3V0LW9m LW9yZGVyLWZyaWVuZGx5LCB3ZSBjb3VsZCBkbyBhIG51bWJlciBvZiB0aGluZ3MsIGFzIHlvdSBz dWdnZXN0Lg0KDQpTb21lIGFwcHJvYWNoZXMgd2UgdGFsa2VkIGFib3V0Og0KDQogICogICBFc3Rh Ymxpc2ggYSBzdGF0aWMgZGljdGlvbmFyeSBpbiB0aGUgZmlyc3QgZmxpZ2h0IGFuZCBuZXZlciBj aGFuZ2UgaXQuDQogICogICBOZXdseS1hZGRlZCBlbnRyaWVzIGhhdmUgZXhwbGljaXQgYW5kIG5l dmVyLXJldXNlZCBpbmRpY2VzLiAgQWxsIEhQQUNLIGZyYW1lcyBhcmUgb24tc3RyZWFtIGFuZCBv bmx5IGJsb2NrIGlmIHRoZXkgcmVmZXJlbmNlIGFuIGVudHJ5IHlvdSBkb27igJl0IHlldCBoYXZl Lg0KICAqICAgU3BsaXQgSFBBQ0sgaW50byB0d28gZGlmZmVyZW50IGZyYW1lIHR5cGVzIOKAkyBv bmUgb25seSBtb2RpZmllcyB0aGUgaGVhZGVyIHRhYmxlOyBvbmUgb25seSBlbWl0cyBoZWFkZXJz LiAgRWFjaCDigJxtb2RpZnnigJ0gZnJhbWUgaW5jcmVtZW50cyBhIGdlbmVyYXRpb24gbnVtYmVy IGFuZCByZWNvcmRzIHRoZSBudW1iZXIgb2Yg4oCcZW1pdOKAnSBmcmFtZXMgaW4gdGhlIHByZXZp b3VzIGdlbmVyYXRpb24uICBFbWl0dGluZyBmcmFtZXMgYmxvY2sgdW50aWwgdGhlIGhlYWRlciB0 YWJsZSByZWFjaGVzIGl0cyBnZW5lcmF0aW9uOyB0aGUgb2xkIGhlYWRlciBzdGF0ZSBjYW4gYmUg ZGlzY2FyZGVkIHdoZW4geW91IGtub3cgeW914oCZdmUgc2VlbiBhbGwgZW1pdHRpbmcgZnJhbWVz IGZyb20gdGhhdCBnZW5lcmF0aW9uLg0KDQpZb3VyIGlkZWEgaXMgc2ltaWxhciB0byB0aGUgbGFz dCBvZiB0aGVzZSwgYnV0IGNob29zaW5nIHRvIGVuY29kZSB0byBhbiBvbGQgc3RhdGUgZm9yIGJl dHRlciByZWxpYWJpbGl0eSBpcyBhbiBpbnRlcmVzdGluZyB3cmlua2xlLiAgWW914oCZZCBoYXZl IHRvIGFkZCBhbiBleHBsaWNpdCBzaWduYWwgdG8gZXZpY3QgdGhlIG9sZCBzdGF0ZSBmb3IgdGhh dCB0byB3b3JrLiAgRGVmaW5pbmcgYW4gZW5kcG9pbnTigJlzIG1lbW9yeSBjb21taXRtZW50IGFu ZCBtYW5hZ2VtZW50IGdldHMgYSBsaXR0bGUgZnV6emllciBpbiB0aGlzIHdvcmxkLCBubyBtYXR0 ZXIgd2hhdCBhcHByb2FjaCB3ZSB0YWtlLg0KDQpJIHRoaW5rIHdl4oCZbGwgbmVlZCB0byBzZXJp b3VzbHkgY29uc2lkZXIgc29tZXRoaW5nIGluIHRoaXMgc3BhY2UuICBJdCBhbHNvIGltcGxpZXMg Y2hhbmdpbmcgSFBBQ0sgaW1wbGVtZW50YXRpb25zIHRvIGJlIG1vcmUgY2F1dGlvdXMgYWJvdXQg YWRkaW5nIHRvIHRoZSB0YWJsZS4gIEkgZGlkIHNvbWUgcHJvdG90eXBlcyBkdXJpbmcgSFRUUC8y IGFuZCBjb25jbHVkaW5nIHRoYXQg4oCcaW5kZXggZXZlcnl0aGluZ+KAnSB3YXMgbm90IHN1YnN0 YW50aWFsbHkgd29yc2UgdGhhbiB0aGUgaHlwb3RoZXRpY2FsIGlkZWFsIGdpdmVuIGEgcmVhc29u YWJsZSB0YWJsZSBzaXplLCBzbyB3ZSB3ZW50IHdpdGggdGhhdCB0byBzYXZlIHRpbWUuICBXaXRo IFFQQUNLLCB0aGF0IHdpbGwgYmUgYSBkZWNpZGVkbHkgc3ViLW9wdGltYWwgc3RyYXRlZ3ksIGFu ZCB0aGVyZSB3aWxsIGJlIHNvbWUgYXJ0IGluIGRlc2lnbmluZyBjb21wcmVzc29ycyB0byBiZSBh cyBlZmZlY3RpdmUgYXMgcG9zc2libGUgaW4gdGhlIHByZXNlbmNlIG9mIHJlb3JkZXJpbmcuDQoN CkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQ YXRyaWNrIE1jTWFudXMNClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAzLCAyMDE2IDI6MjkgUE0N ClRvOiBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBbUVVJQ10gaDIgbWFwcGluZyAtIGhwYWNrIGR5 bmFtaWMgdGFibGUgYnkgcmVmZXJlbmNlDQoNCkhpIFJvYmJpZSwgTWlrZSwgZXQgYWwuIFRoYW5r cyBmb3IgZ2V0dGluZyB0aGUgYmFsbCByb2xsaW5nIHdpdGggaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXNoYWRlLXF1aWMtaHR0cDItbWFwcGluZy0wMC4uDQpJIGhhdmUgYSB0aG91 Z2h0IG9uIHRoZSBtYXBwaW5nIC0gUHV0dGluZyBhbGwgb2YgdGhlIGhlYWRlciBmcmFtZXMgb250 byBvbmUgaW4tb3JkZXIgc3RyZWFtIGlzIGEgcHJldHR5IGJpZyBoYW1tZXIuDQoNCklzIHRoZXJl IHN0b21hY2ggZm9yIGxvb2tpbmcgYXQgYSBzdHJhdGVneSB3aGVyZSBocGFjayByZWZlcmVuY2Vz IHRoZSBkeW5hbWljIHRhYmxlIHN0YXRlIHZpYSBzb21lIGtpbmQgb2YgaW5zdHJ1Y3Rpb24gY291 bnRlcj8gVGhhdCB3YXkgdGhlIGhlYWRlcnMgY291bGQgYmUgb24gdGhlIGRhdGEgKD49NSkgc3Ry ZWFtIGFuZCBqdXN0IHRoZSBkeW5hbWljIHRhYmxlIG1hbmlwdWxhdGlvbiBzdHVmZiBmcm9tIGhw YWNrIGNvdWxkIGJlIG9uIHN0cmVhbSAzLi4gaW1wbGVtZW50YXRpb25zIHdvdWxkIGJlIGFibGUg dG8gY2hvb3NlIHdoZXRoZXIgdG8gZ2VuZXJhdGUgaHBhY2sgdGhhdCByZWZlcmVuY2VkIHRoZSBj dXJyZW50IGNvdW50ZXIgb3IgYW4gb2xkZXIgb25lICh3aXRoaW4gc29tZSB3aW5kb3cpLi4gYW4g b2xkZXIgb25lIGlzIGdvaW5nIHRvIGJlIG1vcmUgcm9idXN0IHRvIHJlb3JkZXJpbmcgaGFwcGVu aW5nIG9uIHN0cmVhbSAzIHNvIHRoZSBkZXAgYmV0d2VlbiB0aGUgc3RyZWFtcyBpcyBsb29zZW5l ZC4gQW5lY2RvdGFsbHkgdGhlIHJhdGUgb2YgY2hhbmdlIG9mIHRoZSBkeW5hbWljIHRhYmxlIHNs b3dzIGRvd24gKHRob3VnaCBJIGhhdmUgbm8gZGF0YSAtIGNvdWxkIGNvbGxlY3QgaXQgaWYgd2Un cmUgc2VyaW91cykgYWZ0ZXIgYW4gaW5pdGlhbCBidXJzdCBhbmQgYXQgdGhhdCBwb2ludCBub3Qg dXNpbmcgdGFibGUgdXBkYXRlcyB1bnRpbCB0aGV5J3ZlIGJlZW4gYWNrZWQgY291bGQgYmUgYSBy ZWFzb25hYmxlIHRoaW5nIHRvIGRvLi4uIGFuZCB0aGlzIGV2ZW4gYWxsb3dzIHByZS1wb3B1bGF0 aW5nIHRoZSBkeW5hbWljIHRhYmxlIGF0IHNldHVwIHRpbWUgd2l0aCBzaXRlLWxvY2FsIHZhbHVl cyByYXRoZXIgdGhhbiBpbiByZXNwb25zZSB0byBhIHF1ZXJ5LiBSZXdpbmRpbmcgdG8gYW55IHBh cnRpY3VsYXIgaW5zdHJ1Y3Rpb24gc2VlbXMgdG8gYmUgYSBiaWcgYnVyZGVuLCBidXQgd2UgY291 bGQgcHJvYmFibHkgZG8gc29tZSB0aGluZ3Mgd2l0aCBjaGVja3BvaW50cyBhbmQgYWNrcyB0byBi b3VuZCBpdCBhbGwuDQoNCnRoaXMgaXMgYSBmYWlybHkgc2lnbmlmaWNhbnQgYml0IG9mIHN1cmdl cnkgdG8gaDIncyBmb3JtYXRzLCBidXQgZ2l2ZW4gdGhhdCBvbmUgb2YgdGhlIHJlYWwgcXVpYyBv cHBvcnR1bml0aWVzIGlzIHRvIHBlcmZvcm0gYmV0dGVyIHVuZGVyIGxvc3MgaXQgY291bGQgYmUg d29ydGh3aGlsZSB0byBzZXZlciBvcmRlcmluZyBkZXBlbmRlbmNpZXMgZXZlbiBmdXJ0aGVyLiBT ZWVtcyBsaWtlIGEgcmVhc29uYWJsZSB0aGluZyB0byBpbnZlc3RpZ2F0ZSB0byBtZS4NClRoYW5r cw0KLVBhdHJpY2sNCg0K --_000_BN6PR03MB2708E353447E58F702ACCF1987A30BN6PR03MB2708namp_ 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 aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjIwNDMxNjM1OTk7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzk4MjczMTg0IDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5K YW5hIGFuZCBJIHdlcmUgdGFsa2luZyBhYm91dCB0aGF0IGF0IHRoZSBIVFRQIFdvcmtzaG9wLiZu YnNwOyBUaGUgY3VycmVudCBzb2x1dGlvbiBpcyBwcm9iYWJseSB0aGUgYmVzdCB0aGF0IGNhbiBi ZSBhY2hpZXZlZCB3aXRob3V0IG1vZGlmeWluZyBIUEFDSywgYmVjYXVzZSBIUEFDSyB0YWtlcyBh IGhhcmQgZGVwZW5kZW5jeSBvbiByZWxpYWJsZSBpbi1vcmRlciBkZWxpdmVyeSwgd2hpY2ggYSBk ZWRpY2F0ZSBzdHJlYW0NCiBjYW4gcHJvdmlkZS4mbmJzcDsgSWYgd2Ugd2VyZSB0byBkZWZpbmUg SFBBQ0t2MiAob3IgUVBBQ0ssIGlmIHlvdSBwcmVmZXIpIGFuZCBtYWtlIGl0cyBzZW1hbnRpY3Mg bW9yZSBvdXQtb2Ytb3JkZXItZnJpZW5kbHksIHdlIGNvdWxkIGRvIGEgbnVtYmVyIG9mIHRoaW5n cywgYXMgeW91IHN1Z2dlc3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWUgYXBwcm9hY2hl cyB3ZSB0YWxrZWQgYWJvdXQ6PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+RXN0YWJsaXNoIGEgc3RhdGlj IGRpY3Rpb25hcnkgaW4gdGhlIGZpcnN0IGZsaWdodCBhbmQgbmV2ZXIgY2hhbmdlIGl0LjxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPk5ld2x5LWFkZGVkIGVudHJpZXMgaGF2ZSBl eHBsaWNpdCBhbmQgbmV2ZXItcmV1c2VkIGluZGljZXMuJm5ic3A7IEFsbCBIUEFDSyBmcmFtZXMg YXJlIG9uLXN0cmVhbSBhbmQgb25seSBibG9jayBpZiB0aGV5IHJlZmVyZW5jZSBhbiBlbnRyeSB5 b3UgZG9u4oCZdCB5ZXQgaGF2ZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5T cGxpdCBIUEFDSyBpbnRvIHR3byBkaWZmZXJlbnQgZnJhbWUgdHlwZXMg4oCTIG9uZSBvbmx5IG1v ZGlmaWVzIHRoZSBoZWFkZXIgdGFibGU7IG9uZSBvbmx5IGVtaXRzIGhlYWRlcnMuJm5ic3A7IEVh Y2gg4oCcbW9kaWZ54oCdIGZyYW1lIGluY3JlbWVudHMgYSBnZW5lcmF0aW9uIG51bWJlciBhbmQg cmVjb3JkcyB0aGUgbnVtYmVyDQogb2Yg4oCcZW1pdOKAnSBmcmFtZXMgaW4gdGhlIHByZXZpb3Vz IGdlbmVyYXRpb24uJm5ic3A7IEVtaXR0aW5nIGZyYW1lcyBibG9jayB1bnRpbCB0aGUgaGVhZGVy IHRhYmxlIHJlYWNoZXMgaXRzIGdlbmVyYXRpb247IHRoZSBvbGQgaGVhZGVyIHN0YXRlIGNhbiBi ZSBkaXNjYXJkZWQgd2hlbiB5b3Uga25vdyB5b3XigJl2ZSBzZWVuIGFsbCBlbWl0dGluZyBmcmFt ZXMgZnJvbSB0aGF0IGdlbmVyYXRpb24uPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllv dXIgaWRlYSBpcyBzaW1pbGFyIHRvIHRoZSBsYXN0IG9mIHRoZXNlLCBidXQgY2hvb3NpbmcgdG8g ZW5jb2RlIHRvIGFuIG9sZCBzdGF0ZSBmb3IgYmV0dGVyIHJlbGlhYmlsaXR5IGlzIGFuIGludGVy ZXN0aW5nIHdyaW5rbGUuJm5ic3A7IFlvdeKAmWQgaGF2ZSB0byBhZGQgYW4gZXhwbGljaXQgc2ln bmFsIHRvIGV2aWN0IHRoZSBvbGQgc3RhdGUgZm9yIHRoYXQgdG8gd29yay4mbmJzcDsgRGVmaW5p bmcgYW4gZW5kcG9pbnTigJlzIG1lbW9yeQ0KIGNvbW1pdG1lbnQgYW5kIG1hbmFnZW1lbnQgZ2V0 cyBhIGxpdHRsZSBmdXp6aWVyIGluIHRoaXMgd29ybGQsIG5vIG1hdHRlciB3aGF0IGFwcHJvYWNo IHdlIHRha2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgd2XigJlsbCBuZWVkIHRv IHNlcmlvdXNseSBjb25zaWRlciBzb21ldGhpbmcgaW4gdGhpcyBzcGFjZS4mbmJzcDsgSXQgYWxz byBpbXBsaWVzIGNoYW5naW5nIEhQQUNLIGltcGxlbWVudGF0aW9ucyB0byBiZSBtb3JlIGNhdXRp b3VzIGFib3V0IGFkZGluZyB0byB0aGUgdGFibGUuJm5ic3A7IEkgZGlkIHNvbWUgcHJvdG90eXBl cyBkdXJpbmcgSFRUUC8yIGFuZCBjb25jbHVkaW5nIHRoYXQg4oCcaW5kZXggZXZlcnl0aGluZ+KA nQ0KIHdhcyBub3Qgc3Vic3RhbnRpYWxseSB3b3JzZSB0aGFuIHRoZSBoeXBvdGhldGljYWwgaWRl YWwgZ2l2ZW4gYSByZWFzb25hYmxlIHRhYmxlIHNpemUsIHNvIHdlIHdlbnQgd2l0aCB0aGF0IHRv IHNhdmUgdGltZS4mbmJzcDsgV2l0aCBRUEFDSywgdGhhdCB3aWxsIGJlIGEgZGVjaWRlZGx5IHN1 Yi1vcHRpbWFsIHN0cmF0ZWd5LCBhbmQgdGhlcmUgd2lsbCBiZSBzb21lIGFydCBpbiBkZXNpZ25p bmcgY29tcHJlc3NvcnMgdG8gYmUgYXMgZWZmZWN0aXZlIGFzDQogcG9zc2libGUgaW4gdGhlIHBy ZXNlbmNlIG9mIHJlb3JkZXJpbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9i PiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwv Yj5QYXRyaWNrIE1jTWFudXM8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5vdmVtYmVyIDMs IDIwMTYgMjoyOSBQTTxicj4NCjxiPlRvOjwvYj4gcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBbUVVJQ10gaDIgbWFwcGluZyAtIGhwYWNrIGR5bmFtaWMgdGFibGUgYnkgcmVmZXJl bmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIFJvYmJpZSwgTWlrZSwgZXQgYWwuIFRoYW5r cyBmb3IgZ2V0dGluZyB0aGUgYmFsbCByb2xsaW5nIHdpdGgNCjxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaGFkZS1xdWljLWh0dHAyLW1hcHBpbmctMDAiPmh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaGFkZS1xdWljLWh0dHAyLW1hcHBpbmctMDA8 L2E+Li4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBoYXZlIGEgdGhvdWdodCBvbiB0aGUgbWFwcGluZyAtIFB1dHRpbmcgYWxsIG9mIHRoZSBo ZWFkZXIgZnJhbWVzIG9udG8gb25lIGluLW9yZGVyIHN0cmVhbSBpcyBhIHByZXR0eSBiaWcgaGFt bWVyLg0KPGJyPg0KPGJyPg0KSXMgdGhlcmUgc3RvbWFjaCBmb3IgbG9va2luZyBhdCBhIHN0cmF0 ZWd5IHdoZXJlIGhwYWNrIHJlZmVyZW5jZXMgdGhlIGR5bmFtaWMgdGFibGUgc3RhdGUgdmlhIHNv bWUga2luZCBvZiBpbnN0cnVjdGlvbiBjb3VudGVyPyBUaGF0IHdheSB0aGUgaGVhZGVycyBjb3Vs ZCBiZSBvbiB0aGUgZGF0YSAoJmd0Oz01KSBzdHJlYW0gYW5kIGp1c3QgdGhlIGR5bmFtaWMgdGFi bGUgbWFuaXB1bGF0aW9uIHN0dWZmIGZyb20gaHBhY2sgY291bGQgYmUgb24gc3RyZWFtDQogMy4u IGltcGxlbWVudGF0aW9ucyB3b3VsZCBiZSBhYmxlIHRvIGNob29zZSB3aGV0aGVyIHRvIGdlbmVy YXRlIGhwYWNrIHRoYXQgcmVmZXJlbmNlZCB0aGUgY3VycmVudCBjb3VudGVyIG9yIGFuIG9sZGVy IG9uZSAod2l0aGluIHNvbWUgd2luZG93KS4uIGFuIG9sZGVyIG9uZSBpcyBnb2luZyB0byBiZSBt b3JlIHJvYnVzdCB0byByZW9yZGVyaW5nIGhhcHBlbmluZyBvbiBzdHJlYW0gMyBzbyB0aGUgZGVw IGJldHdlZW4gdGhlIHN0cmVhbXMgaXMgbG9vc2VuZWQuDQogQW5lY2RvdGFsbHkgdGhlIHJhdGUg b2YgY2hhbmdlIG9mIHRoZSBkeW5hbWljIHRhYmxlIHNsb3dzIGRvd24gKHRob3VnaCBJIGhhdmUg bm8gZGF0YSAtIGNvdWxkIGNvbGxlY3QgaXQgaWYgd2UncmUgc2VyaW91cykgYWZ0ZXIgYW4gaW5p dGlhbCBidXJzdCBhbmQgYXQgdGhhdCBwb2ludCBub3QgdXNpbmcgdGFibGUgdXBkYXRlcyB1bnRp bCB0aGV5J3ZlIGJlZW4gYWNrZWQgY291bGQgYmUgYSByZWFzb25hYmxlIHRoaW5nIHRvIGRvLi4u IGFuZCB0aGlzDQogZXZlbiBhbGxvd3MgcHJlLXBvcHVsYXRpbmcgdGhlIGR5bmFtaWMgdGFibGUg YXQgc2V0dXAgdGltZSB3aXRoIHNpdGUtbG9jYWwgdmFsdWVzIHJhdGhlciB0aGFuIGluIHJlc3Bv bnNlIHRvIGEgcXVlcnkuIFJld2luZGluZyB0byBhbnkgcGFydGljdWxhciBpbnN0cnVjdGlvbiBz ZWVtcyB0byBiZSBhIGJpZyBidXJkZW4sIGJ1dCB3ZSBjb3VsZCBwcm9iYWJseSBkbyBzb21lIHRo aW5ncyB3aXRoIGNoZWNrcG9pbnRzIGFuZCBhY2tzIHRvIGJvdW5kDQogaXQgYWxsLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+dGhpcyBpcyBhIGZhaXJseSBzaWduaWZpY2FudCBi aXQgb2Ygc3VyZ2VyeSB0byBoMidzIGZvcm1hdHMsIGJ1dCBnaXZlbiB0aGF0IG9uZSBvZiB0aGUg cmVhbCBxdWljIG9wcG9ydHVuaXRpZXMgaXMgdG8gcGVyZm9ybSBiZXR0ZXIgdW5kZXIgbG9zcyBp dCBjb3VsZCBiZSB3b3J0aHdoaWxlIHRvIHNldmVyIG9yZGVyaW5nIGRlcGVuZGVuY2llcyBldmVu IGZ1cnRoZXIuDQogU2VlbXMgbGlrZSBhIHJlYXNvbmFibGUgdGhpbmcgdG8gaW52ZXN0aWdhdGUg dG8gbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r czxicj4NCi1QYXRyaWNrPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_BN6PR03MB2708E353447E58F702ACCF1987A30BN6PR03MB2708namp_-- From nobody Thu Nov 3 16:14:46 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AF71297B8 for ; Thu, 3 Nov 2016 16:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id peEL1HkgdZs4 for ; Thu, 3 Nov 2016 16:14:42 -0700 (PDT) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 355C11294A4 for ; Thu, 3 Nov 2016 16:14:41 -0700 (PDT) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 929FE22E255; Thu, 3 Nov 2016 19:14:32 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Fri, 4 Nov 2016 10:14:29 +1100 To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Lars Eggert Subject: [QUIC] Starting work (and getting to interop) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 03 Nov 2016 23:14:44 -0000 Everyone, We'd very much like to see diversity of implementations throughout the = work, so that there's a healthy feedback cycle between the = implementations and drafts.=20 In discussions so far, we've heard two alternative ways of starting the = work: * "Full stack" -- Starting interop work with core, encryption, = congestion control and HTTP * "Minimal" -- Starting interop work with just the core spec (version = negotiation, framing, streams...), leaving encryption and congestion = control until later.=20 "Full" is a higher bar, but exercises everything we'll be working on. = "Minimal" would be only suitable for testing on controlled networks, not = for use on uncontrolled networks -- but may be easier for new = implementations getting up to speed. It'd be great to hear people's preferences and thoughts here (including = other approaches, or refinements of those above), especially from = implementers (since they'll be the ones most directly impacted). Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Thu Nov 3 17:46:07 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFF3129489 for ; Thu, 3 Nov 2016 17:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WO-ugxVIiqpD for ; Thu, 3 Nov 2016 17:46:04 -0700 (PDT) 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 9F368129408 for ; Thu, 3 Nov 2016 17:46:04 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id q130so79699692qke.1 for ; Thu, 03 Nov 2016 17:46:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dkHKdxB035NyKD//dpocxq2hIkCmwgJOIETDM2HGKxk=; b=r2d4cjoAr2nqt50nI4po5bQYlkw/OJzqjKuejw8DUSrhz0BV6i+YVOKecW08twkV7Z uKq1DmocXfCluN9pse3J1sFepBjL+ENMciE3RmZGhsxPLIhnrJZCzsHUye6BGPsFmS2O LWHxjq4U9om8Bo9HWw3XLthN4mCcFsZ8cRJhuRhqeIDHD/Fzn1HTFqRufzz6+vHLbhw4 hax4C/xoRDlnJ9A2Sn/Apd0+1U7mZnThq8YHectIyVEj7+vujXb9/5gY0fQio1MX/MD1 qFSuayhrYH2h6COyOheXS4Dp+oSJLnSQ5k9CGaGGZpom3kf5FmTQ6WdBNSVe7BcoOKlR JWrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dkHKdxB035NyKD//dpocxq2hIkCmwgJOIETDM2HGKxk=; b=aJV3MCdusBisAaTQZwgmU2hpWTDsX37ZqIDIkqF+q5pliWpnsZ7y/f3T0fUteuFUog n6hHdqZrOAUH1LgLcOPWLN8hWTodXFUZrrmzOcq4RYN8czMfOhgjS5n3glPvQRa4jqcM 4qEzLt2q6JkFd0jFagJKLj+QuKM4MTdxWfhqI23b6MKT3D18h9bHJDbOj6qGwMt2M6ds ti6E1kwyFYbJsNeRnjrKbLs/p1IS7MAMCIokUNaI1tRLdPruTnr7LAzn7ROo/h6nNW2z m/9wSpclmxyiw7zvHy5C84sjeu0z1TYcKKUafTlbXaSiNU6DhI08ezrMmWpxzj+FLxh9 QkLw== X-Gm-Message-State: ABUngveV130h0DaV7CxftTuzYikDC4Lp3md+aWmTKzFpTsxgr2rHYjN3mfUGXjBlsBfhcguKew8gUw0RDB7PcA== X-Received: by 10.55.184.68 with SMTP id i65mr11501940qkf.5.1478220363770; Thu, 03 Nov 2016 17:46:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 3 Nov 2016 17:46:02 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 4 Nov 2016 11:46:02 +1100 Message-ID: To: Dragana Damjanovic Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Comment on draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 00:46:06 -0000 On 4 November 2016 at 01:14, Dragana Damjanovic wrote: > Sorry I have not looked at you repo, I was just reading the last 01 draft. Don't apologize, it's my fault :) > With the new version the problem is resolved. The transition from 0-RTT to > 1-RTT still needs to be fixed. The draft says it will switch to 1-RTT after > sending finish message, but it can't. That is what you are saying in this > e-mail? It needs to continue using 0-RTT until client finish message is > acked. I don't think that's necessary. In the latest TLS 1.3, the 1-RTT keys only depend on the transcript up to the Server's Finished. That means that the server has enough information to decrypt the 1-RTT keys as soon as it has finished sending its handshake messages. Therefore, if the client can switch to 1-RTT, it should do so as quickly as possible. (This is a change since I wrote the draft, so the draft is probably wrong.) The challenge I'm talking about is that the client's Finished (and Certificate{|Verify}) need to be sent in the clear (or 0-RTT). Until they are acknowledged, the client can't rotate keys. If the client doesn't use 0-RTT, those packets will have KEY_PHASE=0, 1-RTT packets will have KEY_PHASE=1, and any updated key will result in packets with KEY_PHASE=0. Those updated packets appear to be the same as the "cleartext" handshake packets. Normal key updates are easier because you only have to look for an ack of any packet with the new KEY_PHASE. The handshake is terrible because you can get an ack of the first 1-RTT data, but the server might not have finished receiving handshake messages.) From nobody Thu Nov 3 17:54:14 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE35129416 for ; Thu, 3 Nov 2016 17:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVn0oTfnkqYs for ; Thu, 3 Nov 2016 17:54:12 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5BE9129408 for ; Thu, 3 Nov 2016 17:54:11 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id x190so78100662qkb.0 for ; Thu, 03 Nov 2016 17:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7tEdiYjTaQabXrpfC+6S+fIEp2W8poGFeV4DYbIg9qs=; b=Tc69UvAvt/lIhFYebsc11kCP86SumYKDPjig2HQDzZo/u/txD62q1fnEjny6wA7lo5 2Tj9Pgwa3muajM7UvSd2y+Fobg8IBErx3mnrH2rDr3mYMoNplwtkscSDeh44+WRhcFzO A1CAwSqpNcM4jDJZ+BELzrTIjqudv+HmbM52EPNqmKVGINNPcVy01yrpVEPe9Rzcnty/ aQ3VDMJfdeoem70zf2550hfeBKOYAV059FPjnavBXlPeoJJcup2dBRUGKOQIsYVuy37r XARcRr0pgOBm9z+ozqYc+4rDVP0c/QEh15BbUafXdCZxLio+6zED5xIiJvorQSpvwFYS AW6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7tEdiYjTaQabXrpfC+6S+fIEp2W8poGFeV4DYbIg9qs=; b=CoGocFW7O2RPQLTHL9NzTyWoTsY4be2/bMRYpKW4uL+eyipDIDpe112RVSG1+zNLFN RARBnReUYa92QiJGijqMEhyl5ZP2Lunm6YkCGud5ecIRGXetKz3z8hkadgKClmFUmWS+ JKiYFeweaXK7tw/Tmmo5tzHgRTD+cPeDyOgB1PtC1zcRQZowPtVqAFXNbLWIdZO8rUat f1gMhU6u7upMq6XWSu+IpG1CeVcw6OQyTI0/ucImRoi5fwkuJ6yjldlJNDNkpa4NM2X6 8daJN1e9vdxfHzj9k6q4jjfrQtfxOiQ3MFadxJ4DD09Zmp9SmMNDnAhdrEQtXKFWa9d2 GlJw== X-Gm-Message-State: ABUngvesFpKPp0RIe/zI8JSEOe6ney7Yn5u3Xn4kN2cz0eo/4jyo8Df3rJfIR/GgvWSZ/sM+g4UziGvT7F7OJw== X-Received: by 10.55.12.2 with SMTP id 2mr10538560qkm.68.1478220851041; Thu, 03 Nov 2016 17:54:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 3 Nov 2016 17:54:10 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 4 Nov 2016 11:54:10 +1100 Message-ID: To: Patrick McManus Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 00:54:13 -0000 On 4 November 2016 at 08:29, Patrick McManus wrote: > this is a fairly significant bit of surgery to h2's formats, but given that > one of the real quic opportunities is to perform better under loss it could > be worthwhile to sever ordering dependencies even further. Seems like a > reasonable thing to investigate to me. I agree. We risk negating much of the performance wins by creating head-of-line blocking in header fields. With many resources, a lot of the critical early interactions are entirely header fields, and hpack is strictly serialized. Maybe this is a good time to raise the possibility that we might need hpack modifications and that those modifications might benefit from a new document. We split hpack out in h2, and it was a neat break that we never regretted. From nobody Thu Nov 3 18:07:24 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3ADF1294FD for ; Thu, 3 Nov 2016 18:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csLMuZzB-b6R for ; Thu, 3 Nov 2016 18:07:21 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 37D40129408 for ; Thu, 3 Nov 2016 18:07:21 -0700 (PDT) Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com [209.85.218.47]) by linode64.ducksong.com (Postfix) with ESMTPSA id 8D2C73A015 for ; Thu, 3 Nov 2016 21:07:20 -0400 (EDT) Received: by mail-oi0-f47.google.com with SMTP id 128so124827104oih.0 for ; Thu, 03 Nov 2016 18:07:20 -0700 (PDT) X-Gm-Message-State: ABUngveZfqYHNE33GLVFJAg7BfrWoFucn9Sh4UpkN2xZYHMjltC2DYNI/YrK2tE0ADPadx+gRwvq+emVLgYz5g== X-Received: by 10.36.73.134 with SMTP id e6mr307894itd.109.1478221640216; Thu, 03 Nov 2016 18:07:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.228.236 with HTTP; Thu, 3 Nov 2016 18:07:19 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Thu, 3 Nov 2016 21:07:19 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Mike Bishop Content-Type: multipart/alternative; boundary=001a113a98c4c3d54205406f4bb4 Archived-At: Cc: "quic@ietf.org" , Patrick McManus Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 01:07:22 -0000 --001a113a98c4c3d54205406f4bb4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 3, 2016 at 6:35 PM, Mike Bishop wrote: > Jana and I were talking about that at the HTTP Workshop. > good! > > Your idea is similar to the last of these, but choosing to encode to an > old state for better reliability is an interesting wrinkle. You=E2=80=99= d have to > add an explicit signal to evict the old state for that to work. > yep.. and because of the out-of-order use of the state it gets tricky if you're aggressive about that.. but retry with REFUSED_STREAM might provide an escape valve in the really bad corner case. all handwaving of course. > Defining an endpoint=E2=80=99s memory commitment and management gets a li= ttle > fuzzier in this world, no matter what approach we take. > > > > I think we=E2=80=99ll need to seriously consider something in this space.= It also > implies changing HPACK implementations to be more cautious about adding t= o > the table. I did some prototypes during HTTP/2 and concluding that =E2= =80=9Cindex > everything=E2=80=9D was not substantially worse than the hypothetical ide= al given a > reasonable table size, so we went with that to save time. With QPACK, th= at > will be a decidedly sub-optimal strategy, and there will be some art in > designing compressors to be as effective as possible in the presence of > reordering. > > When we get to the github issue stage I'll open one. Something to tackle early I would hope. Thanks! --001a113a98c4c3d54205406f4bb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 3, 2016 at 6:35 PM, Mike Bishop <Michael.Bishop= @microsoft.com> wrote:

Jana and I were talking about that at the HTTP Works= hop.=C2=A0


good!
=
=C2=A0

Your idea is similar to the last of these, but choos= ing to encode to an old state for better reliability is an interesting wrin= kle.=C2=A0 You=E2=80=99d have to add an explicit signal to evict the old st= ate for that to work.=C2=A0


yep.. and because of the out-of-order use of the state it gets tricky if y= ou're aggressive about that.. but retry with REFUSED_STREAM might provi= de an escape valve in the really bad corner case. all handwaving of course.=
=C2=A0

Defining an endpoint=E2=80=99s memory commitment and management gets a little fuzzier in this world, no matter w= hat approach we take.

=C2=A0

I think we=E2=80=99ll need to seriously consider som= ething in this space.=C2=A0 It also implies changing HPACK implementations = to be more cautious about adding to the table.=C2=A0 I did some prototypes = during HTTP/2 and concluding that =E2=80=9Cindex everything=E2=80=9D was not substantially worse than the hypothetical ideal given a reasonable= table size, so we went with that to save time.=C2=A0 With QPACK, that will= be a decidedly sub-optimal strategy, and there will be some art in designi= ng compressors to be as effective as possible in the presence of reordering.


<= div>When we get to the github issue stage I'll open one. Something to t= ackle early I would hope.

Thanks!

--001a113a98c4c3d54205406f4bb4-- From nobody Thu Nov 3 23:57:13 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2355129494 for ; Thu, 3 Nov 2016 23:57:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7BqSbmPJ13HE for ; Thu, 3 Nov 2016 23:57:09 -0700 (PDT) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06E7129436 for ; Thu, 3 Nov 2016 23:57:09 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id 6A1B21C12DF; Fri, 4 Nov 2016 07:57:07 +0100 (CET) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 5B0D11C12D7; Fri, 4 Nov 2016 07:57:05 +0100 (CET) (Extended-Queue-bit tech_pjqhn@fff.in.tum.de) To: Mark Nottingham , quic@ietf.org References: From: Joerg Ott Message-ID: Date: Fri, 4 Nov 2016 07:57:04 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Lars Eggert , Ahsan Saba Subject: Re: [QUIC] Starting work (and getting to interop) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 06:57:12 -0000 Hi, we may even have three levels: minimal (base spec, handshake, framing), intermediate (add congestion control and repair), and full (add crypt). I believe it would be useful for feedback to the spec to not depend on the full crypto bit simply to be able to get broader and earlier feedback. While we are doing our implementation, we make many notes on the spec (and "discuss" items in there). So will others and moving on to minimal interop will help us consolidating those different inputs to the spec. At this point, depending on TLS 1.3 would appear to be a bit like head of line blocking. In any case, we would need to document the "expectations" for the different levels. Cheers, Jörg On 04.11.16 00:14, Mark Nottingham wrote: > Everyone, > > We'd very much like to see diversity of implementations throughout the work, so that there's a healthy feedback cycle between the implementations and drafts. > > In discussions so far, we've heard two alternative ways of starting the work: > > * "Full stack" -- Starting interop work with core, encryption, congestion control and HTTP > > * "Minimal" -- Starting interop work with just the core spec (version negotiation, framing, streams...), leaving encryption and congestion control until later. > > "Full" is a higher bar, but exercises everything we'll be working on. "Minimal" would be only suitable for testing on controlled networks, not for use on uncontrolled networks -- but may be easier for new implementations getting up to speed. > > It'd be great to hear people's preferences and thoughts here (including other approaches, or refinements of those above), especially from implementers (since they'll be the ones most directly impacted). > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > From nobody Fri Nov 4 02:02:21 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D4E129529 for ; Fri, 4 Nov 2016 02:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 K8jmmMYNTjd1 for ; Fri, 4 Nov 2016 02:02:17 -0700 (PDT) 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 ABB5312951F for ; Fri, 4 Nov 2016 02:02:17 -0700 (PDT) Received: by mail-vk0-x229.google.com with SMTP id x186so61619749vkd.1 for ; Fri, 04 Nov 2016 02:02:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GVRxaEWnAMUil9nkPTS0YjftXIx0LCPopowtRmuo97k=; b=MSY6FAUf2fm5Pgiq/k65dqlw09hkl0DQ6pn0vEG9NyNLBZwS0VBNtWAucT3ImdyFOp +HS5lvOUCC5fLczMBsBxcsrlmCILnwLz5tPUXZ6H0xaKn+jaem2vhfy2S0Knk181QEyK CcfSQSPeRVIHFp6Pf2995QW1WW2dFi7H95Jkjpb1/6zn5TWpjD0WyWSfmOQCLNx0lwC0 Iduj7Dn72vODtXMkpxzwFA1UJWPQIqc0sSYygaRHV5gxNspBrfy/Unm/T8vjRBxb+DWL acMiLVH+2dyr1UdxxazPHF5EZk7fdNFw9vR5GzwpGwnTNFz9a48l4lVcWYPZzyPgTYyV fPYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GVRxaEWnAMUil9nkPTS0YjftXIx0LCPopowtRmuo97k=; b=KTzZclhqdHTkCQdwL55imuTPgmIZzAeZ69iyxYczACI/DIiV7avR9y+Y/AHgB/HFZm TDjzvgbCuynEdT6SBv/+Rt1yfwfd0o2vSGd4KWdxVW2FmgScgV3Ad/PSX+Va5sLrx1I5 47yWjAqFeACEqyKxPdQ5tHoI0OjwnFd522CFmrGMHTujLEjb4bHVR26da+whrWenROlx gx8iw9wrEZ03NsW/jU8hqSnLPwyqQTqednYKm1R9JaeCcdimTlQaX8ipASJ92bxk3SuA 6onAeNUm7XkLbFI08GcOUdcIs/W0LX1ayEJGv+H6ilWoVk8v1gEeVUHT4V4LPKPBjztu rVwg== X-Gm-Message-State: ABUngvciVfWj+vrUzcB4w/ni+qeuJpKG04jxrxhP+u5KaWFXluPnh8+I7ZuYU5NqcCQj/pjjvcZ2rRbmnq2h9A== X-Received: by 10.31.106.196 with SMTP id f187mr9296128vkc.33.1478250136699; Fri, 04 Nov 2016 02:02:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.35.134 with HTTP; Fri, 4 Nov 2016 02:02:16 -0700 (PDT) In-Reply-To: References: From: Dragana Damjanovic Date: Fri, 4 Nov 2016 10:02:16 +0100 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e022e498978054075eee1 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Comment on draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 09:02:19 -0000 --001a114e022e498978054075eee1 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 4, 2016 at 1:46 AM, Martin Thomson wrote: > On 4 November 2016 at 01:14, Dragana Damjanovic > wrote: > > Sorry I have not looked at you repo, I was just reading the last 01 > draft. > > Don't apologize, it's my fault :) > > > With the new version the problem is resolved. The transition from 0-RTT > to > > 1-RTT still needs to be fixed. The draft says it will switch to 1-RTT > after > > sending finish message, but it can't. That is what you are saying in this > > e-mail? It needs to continue using 0-RTT until client finish message is > > acked. > > I don't think that's necessary. In the latest TLS 1.3, the 1-RTT keys > only depend on the transcript up to the Server's Finished. That means > that the server has enough information to decrypt the 1-RTT keys as > soon as it has finished sending its handshake messages. Therefore, if > the client can switch to 1-RTT, it should do so as quickly as > possible. (This is a change since I wrote the draft, so the draft is > probably wrong.) > > The challenge I'm talking about is that the client's Finished (and > Certificate{|Verify}) need to be sent in the clear (or 0-RTT). Until > they are acknowledged, the client can't rotate keys. If the client > doesn't use 0-RTT, those packets will have KEY_PHASE=0, 1-RTT packets > will have KEY_PHASE=1, and any updated key will result in packets with > KEY_PHASE=0. Those updated packets appear to be the same as the > "cleartext" handshake packets. > > I think we are talking about the same thing. I was only saying that problem exist if 0-RTT key is used. After the client has sent Finish message it knows 1-RTT key but it can't rotate keys and it can't start sending messages using 1-RTT key, because server can get confuse whether it is clear text or 1-RTT key-encrypted message. It needs to wait for the ack of the Finish messages. This is too long to wait, it is one RTT if nothing gets lost. I was suggesting to continue sending data using 0-RTT until ack arrives. dragana > Normal key updates are easier because you only have to look for an ack > of any packet with the new KEY_PHASE. The handshake is terrible > because you can get an ack of the first 1-RTT data, but the server > might not have finished receiving handshake messages.) > --001a114e022e498978054075eee1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 4, 2016 at 1:46 AM, Martin Thomson <martin.thomson@gmai= l.com> wrote:
On 4 November= 2016 at 01:14, Dragana Damjanovic
<dragana.d= amjano@gmail.com> wrote:
> Sorry I have not looked at you repo, I was just reading the last 01 dr= aft.

Don't apologize, it's my fault :)

> With the new version the problem is resolved. The transition from 0-RT= T to
> 1-RTT still needs to be fixed. The draft says it will switch to 1-RTT = after
> sending finish message, but it can't. That is what you are saying = in this
> e-mail? It needs to continue using 0-RTT until client finish message i= s
> acked.

I don't think that's necessary.=C2=A0 In the latest TLS 1.3,= the 1-RTT keys
only depend on the transcript up to the Server's Finished.=C2=A0 That m= eans
that the server has enough information to decrypt the 1-RTT keys as
soon as it has finished sending its handshake messages.=C2=A0 Therefore, if=
the client can switch to 1-RTT, it should do so as quickly as
possible.=C2=A0 (This is a change since I wrote the draft, so the draft is<= br> probably wrong.)
=C2=A0
The challenge I'm talking about is that the client's Finished (and<= br> Certificate{|Verify}) need to be sent in the clear (or 0-RTT).=C2=A0 Until<= br> they are acknowledged, the client can't rotate keys.=C2=A0 If the clien= t
doesn't use 0-RTT, those packets will have KEY_PHASE=3D0, 1-RTT packets=
will have KEY_PHASE=3D1, and any updated key will result in packets with KEY_PHASE=3D0.=C2=A0 Those updated packets appear to be the same as the
"cleartext" handshake packets.


I think we are talking about the same = thing. I was only saying that problem exist if 0-RTT key is used. After the= client has sent Finish message it knows 1-RTT key but it can't rotate = keys and=C2=A0 it can't start sending messages using 1-RTT key, because= server can get confuse whether it is clear text or 1-RTT key-encrypted mes= sage. It needs to wait for the ack of the Finish messages. This is too long= to wait, it is one RTT if nothing gets lost.
I was suggesti= ng to continue sending data using 0-RTT until ack arrives.

dragana
=C2=A0
Normal key updates are easier because you only have to look for an ack
of any packet with the new KEY_PHASE.=C2=A0 The handshake is terrible
because you can get an ack of the first 1-RTT data, but the server
might not have finished receiving handshake messages.)

--001a114e022e498978054075eee1-- From luke.clemente@gmail.com Fri Nov 4 02:44:31 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1EF129411 for ; Fri, 4 Nov 2016 02:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sE49dZSjIhGJ for ; Fri, 4 Nov 2016 02:44:28 -0700 (PDT) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c: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 9E6391293FC for ; Fri, 4 Nov 2016 02:44:28 -0700 (PDT) Received: by mail-wm0-x232.google.com with SMTP id p190so38844856wmp.1 for ; Fri, 04 Nov 2016 02:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=leDdMFfDtblKli2xPklNNCkIFWBmC+A+YHDDF3qdZIA=; b=ESYFcFveXZGmHBwM7XbG0LZH9//Bd4kf0Ug+8tppwJz/s+CIuLZXKANFY66cP3VdKa ZYd8C5pOxhxom8xJoCLLodFnB2RykTWChpAqYD5+pAlF6XQj4dgA+a0wYIRZpH/4ojmV sweboND1Qble226+PalBIIi3KM3vV4zknUZYWtxzFjKBdVOiNBW9MO9mAhSwp1rFDKw6 zSK9tTAN6nNR+ZGvxVjooPqxuFUtfqc4sO1fkB26IArFNRzUdbDTQRosy2FP2VjBKHgv AKTHfTN8bfukYtr1776LtxXBUA4z4WC9bhWA3ADxo4XW9DvXj24NJaOPcryK8poFL7sm 0lHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=leDdMFfDtblKli2xPklNNCkIFWBmC+A+YHDDF3qdZIA=; b=XGQ9yMDEiwhHjOJXVpauZVUJGPAgHg0rylLxOBalkcrbXMJs5tbKNU/gDJ+G8ny7ks 2CG5YLQvPOSqvXbYRpIqXy5HANv3Bt/MogjodQpW4dqBBKGntGMGD6RhcbDdq35RHVpP ZrRETdtoWfYl/07EMi2HcmY1KW4N3YFajFsCQePUbFjyohOQnVZD56w93LOK0j+Dskuj YH9MrY9IK2mRWWmcUxu91ZhuwQ9DvJVLRG4h4XSCKQSwWgtIR/lGbaRBhDbk2/tcrui5 nl5FnMaqYbBEOYvwKTIojNtuJBTVAIZIrzfs06HQ4K/Ew5MvYTtsgk7EWIVSYmvCGhFN G7/w== X-Gm-Message-State: ABUngvfz+674g7FQDvI8xZFiG2HboJ63W5tQbfwnVaPag8Mjz3J3robmbEJs6cQMlmDL3g== X-Received: by 10.194.125.114 with SMTP id mp18mr10806437wjb.106.1478252667131; Fri, 04 Nov 2016 02:44:27 -0700 (PDT) Received: from ?IPv6:2001:a61:12a9:8801:fda6:7222:da14:edb8? ([2001:a61:12a9:8801:fda6:7222:da14:edb8]) by smtp.gmail.com with ESMTPSA id n3sm13336599wjq.34.2016.11.04.02.44.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Nov 2016 02:44:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Lucas Clemente In-Reply-To: Date: Fri, 4 Nov 2016 10:44:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2DB037DB-7DEC-4124-AB7A-4B3CDEA79BE3@gmail.com> References: To: Joerg Ott X-Mailer: Apple Mail (2.3251) Archived-At: X-Mailman-Approved-At: Fri, 04 Nov 2016 02:52:38 -0700 Cc: Ahsan Saba , Lars Eggert , Mark Nottingham , quic@ietf.org Subject: Re: [QUIC] Starting work (and getting to interop) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 09:47:09 -0000 Hi all, One experience from our implementation = (https://github.com/lucas-clemente/quic-go) was that getting to interop = asap helped us a lot. We basically worked through the handshake from the = beginning, adding features as they were required to continue. That way, = we could always do integration testing with the quic_client or Chrome. = For example, we only added frames as we encountered them, such that = WINDOW_UPDATEs appeared only way after the crypto was fully implemented. = Similarly, we started with very basic loss detection (fast = retransmisison), and only later added proper RTOs, and still have some = work to do there. Of course, there=E2=80=99s currently a lot of stuff in the protocol not = covered by the drafts (e.g. the crypto doc is quite outdated), so just = implementing everything from the spec without looking at Chrome=E2=80=99s = source would probably have been impossible for us. We have some notes on the drafts that we made while implementing, but we = don=E2=80=99t really feel like mailing lists are an efficient way of = discussing these ideas and proposals. We look forward to having the = specs on Github :) Ciao, Lucas > On 4 Nov 2016, at 07:57, Joerg Ott wrote: >=20 > Hi, >=20 > we may even have three levels: minimal (base spec, handshake, = framing), > intermediate (add congestion control and repair), and full (add = crypt). >=20 > I believe it would be useful for feedback to the spec to not depend > on the full crypto bit simply to be able to get broader and earlier > feedback. While we are doing our implementation, we make many > notes on the spec (and "discuss" items in there). So will others > and moving on to minimal interop will help us consolidating those > different inputs to the spec. >=20 > At this point, depending on TLS 1.3 would appear to be a bit > like head of line blocking. >=20 > In any case, we would need to document the "expectations" for the > different levels. >=20 > Cheers, > J=C3=B6rg >=20 > On 04.11.16 00:14, Mark Nottingham wrote: >> Everyone, >>=20 >> We'd very much like to see diversity of implementations throughout = the work, so that there's a healthy feedback cycle between the = implementations and drafts. >>=20 >> In discussions so far, we've heard two alternative ways of starting = the work: >>=20 >> * "Full stack" -- Starting interop work with core, encryption, = congestion control and HTTP >>=20 >> * "Minimal" -- Starting interop work with just the core spec (version = negotiation, framing, streams...), leaving encryption and congestion = control until later. >>=20 >> "Full" is a higher bar, but exercises everything we'll be working on. = "Minimal" would be only suitable for testing on controlled networks, not = for use on uncontrolled networks -- but may be easier for new = implementations getting up to speed. >>=20 >> It'd be great to hear people's preferences and thoughts here = (including other approaches, or refinements of those above), especially = from implementers (since they'll be the ones most directly impacted). >>=20 >> Cheers, >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >=20 From nobody Fri Nov 4 06:07:14 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A841294AE for ; Fri, 4 Nov 2016 06:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kL-O-MQlg441 for ; Fri, 4 Nov 2016 06:07:11 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 C758C12940C for ; Fri, 4 Nov 2016 06:07:10 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id t79so48862312wmt.0 for ; Fri, 04 Nov 2016 06:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F0UfDk+bOuRM54R0rxJt/rXkQLqpPP1uvqrIba5fNDc=; b=h5911K3v6FrLDaP11jjaJkC9F9LzrAl6rdADRlnhfeWrUnUn6FT3gEas3FOGPSATPb 5Kx4LTEo15bVPGicEIBSmIKrTgvJvSAhc8FX/MxZUiYXHW1Dm6dFuNfuAVgo3Clc8ncS 9oy6g3F9uHsFuijII5KQCZ59G8huu7l+d49y/Llcsiv5yMrbleaarP2jGoP5Qh+vjqpl +SW/0w7Srd2ISWFEc+F896GYmumZQPIiCgIKliDa2IRPTs3ur6PNDhqWw7LD7nktjxw9 KkoCo/crHMFC63+Eo6yZYbhY4J/seTF3KJSyCh8QyxIBnUmozdNbhGUKRMFFuMnCKdnr 117g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F0UfDk+bOuRM54R0rxJt/rXkQLqpPP1uvqrIba5fNDc=; b=PwQc9cGN3AuZUCTqTAD3ANsA9AgUv1oEyeOwUY3EfhL7+inucuVT4/umlTowbkfUtF xFxDtauMRr9ZRtycoWNrPZOsK2bL84MTk/6NNw97NyCJkReAQm1PCV6+nLzvb8uHHEPZ OZjaYPNzPKIkBM7aGx50xSxsl98vtnveA1nv2UE2uF+aYne3Uxz21c8BxdzXfEEI67Ui GeZkNxb9stl75IxOgZhO+RJVAeBtsWqmUeFqnUfeN/thH/fWYmDVyUwnb02Dml7cb1+X TULSlS8aXUmOF/XAqzrlbI6rZ3F7fGgj9YQE/8EVKFhEKNr5LdcfPrfrbmmwhpi34wMJ dd6A== X-Gm-Message-State: ABUngvcW+Mo9b8uZASTnn7CG/IKSsiyDhDiTFkyQWPA18BZNhstqjGqet40kqdE9gsVWMPxRrkIkxXFRFekm5H4g X-Received: by 10.194.242.1 with SMTP id wm1mr14117046wjc.14.1478264828639; Fri, 04 Nov 2016 06:07:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.175.81 with HTTP; Fri, 4 Nov 2016 06:06:48 -0700 (PDT) In-Reply-To: References: From: Robbie Shade Date: Fri, 4 Nov 2016 09:06:48 -0400 Message-ID: To: Patrick McManus , "Charles 'Buck' Krasic" Content-Type: multipart/alternative; boundary=089e013d1448fef7b30540795985 Archived-At: Cc: Mike Bishop , "quic@ietf.org" Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 13:07:13 -0000 --089e013d1448fef7b30540795985 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed that fixing the HPACK head of line blocking problem is well worth tackling, thanks for bringing this up. +Buck who has been thinking about this as well. On Thu, Nov 3, 2016 at 9:07 PM, Patrick McManus wrote: > > > On Thu, Nov 3, 2016 at 6:35 PM, Mike Bishop > wrote: > >> Jana and I were talking about that at the HTTP Workshop. >> > > good! > > >> >> Your idea is similar to the last of these, but choosing to encode to an >> old state for better reliability is an interesting wrinkle. You=E2=80= =99d have to >> add an explicit signal to evict the old state for that to work. >> > > yep.. and because of the out-of-order use of the state it gets tricky if > you're aggressive about that.. but retry with REFUSED_STREAM might provid= e > an escape valve in the really bad corner case. all handwaving of course. > > >> Defining an endpoint=E2=80=99s memory commitment and management gets a l= ittle >> fuzzier in this world, no matter what approach we take. >> >> >> >> I think we=E2=80=99ll need to seriously consider something in this space= . It >> also implies changing HPACK implementations to be more cautious about >> adding to the table. I did some prototypes during HTTP/2 and concluding >> that =E2=80=9Cindex everything=E2=80=9D was not substantially worse than= the hypothetical >> ideal given a reasonable table size, so we went with that to save time. >> With QPACK, that will be a decidedly sub-optimal strategy, and there wil= l >> be some art in designing compressors to be as effective as possible in t= he >> presence of reordering. >> >> > When we get to the github issue stage I'll open one. Something to tackle > early I would hope. > > Thanks! > > --089e013d1448fef7b30540795985 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed that fixing the HPACK head of line blocking problem= is well worth tackling, thanks for bringing this up.

+B= uck who has been thinking about this as well.


On Thu, Nov 3, 2016 at 9:0= 7 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:


On Thu, Nov 3, 2016 at 6:= 35 PM, Mike Bishop <Michael.Bishop@microsoft.c= om> wrote:

Jana and I were talking about that at the HTTP Works= hop.=C2=A0


good!
=
=C2=A0


Your idea is similar to the last of these, but choos= ing to encode to an old state for better reliability is an interesting wrin= kle.=C2=A0 You=E2=80=99d have to add an explicit signal to evict the old st= ate for that to work.=C2=A0


yep.. and because of the out-of-order use of the state it gets tricky if y= ou're aggressive about that.. but retry with REFUSED_STREAM might provi= de an escape valve in the really bad corner case. all handwaving of course.=
=C2=A0

D= efining an endpoint=E2=80=99s memory commitment and management gets a little fuzzier in this world, no matter w= hat approach we take.

=C2=A0

I think we=E2=80=99ll need to seriously consider som= ething in this space.=C2=A0 It also implies changing HPACK implementations = to be more cautious about adding to the table.=C2=A0 I did some prototypes = during HTTP/2 and concluding that =E2=80=9Cindex everything=E2=80=9D was not substantially worse than the hypothetical ideal given a reasonable= table size, so we went with that to save time.=C2=A0 With QPACK, that will= be a decidedly sub-optimal strategy, and there will be some art in designi= ng compressors to be as effective as possible in the presence of reordering.


<= div>When we get to the github issue stage I'll open one. Something to t= ackle early I would hope.

Thanks!


--089e013d1448fef7b30540795985-- From nobody Fri Nov 4 10:28:50 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB8E1293F3 for ; Fri, 4 Nov 2016 10:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ASkeeZyo_RAg for ; Fri, 4 Nov 2016 10:28:47 -0700 (PDT) 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 B3D72129467 for ; Fri, 4 Nov 2016 10:28:47 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id v84so173400684oie.3 for ; Fri, 04 Nov 2016 10:28:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sa5rdFqR0ap40B021rev62C5vpm5KP9lYdcX7ObwvDI=; b=p04z3NnM4v5JzwsSUOGmWTh+U3fWQwzGkG9wqZpv6hnaPuh+JoOyxxNfQFbj1byF/Z dEiEoCe35SKS8IB29XDKAEY0wSFlHuB2zqQzc7RP4FwM9zyAvA3aFgcJ3JkSTNh/CaT6 2SA/Oqwjdkltpkr7w+CH9D/9Ph+pTITTVakQHDI6tUIuLwO5gF7gsD5nwcb2K2XNNUP3 5nKkOLPqXwzsDXaqZAwPl666BeqA8LPeDe9M+uGjlzNsPK+XFoBeZO8sZKIjHZJYP7JS Rw9x+cDoQfQDSTEMZo66YC7yi6E8N9HpmpRv31OYRMargOGv3PAH0qRb/jWUk1+WN8En oYCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sa5rdFqR0ap40B021rev62C5vpm5KP9lYdcX7ObwvDI=; b=Fmwch/Bfc6zmfI4rAfEhd/+ypAXCi4bnzzqHgPCttTJDJtB/+U95rNWeWuckEP8zpd WLW/t/oAroihZIEE16GInph9c7Klu57y0VpVM4JYnHuPbRsqVHHQK7ysIaZRtRdYf9yt Z+CCSq0pD/pUrNUnKrcLwsUyDneSpKCZ8emIQM1dH4EdnfSABWbgBPJe7A19D3EmrIwO 6NiE3pVOJdeXSqqAml+KuAnsHjFDBFedhLteo4dmAefZYC7fX0Bd1nITBr7XwbiB+7q2 pyjL2ZlbbJGYMfdzI3PnBzlZzXwtHOhnZ5kZMHr0spkgna8ErMgzvGyWsAvpK3Fb3SYn 0dgw== X-Gm-Message-State: ABUngvfa6BCRQ6BQBZdVCQzSdg8pzORx3YfLwm2YfyNLBZqzVqaUh6zIbCSQMkzxcv1O/ZpKYEVH0c8DiOueXYvx X-Received: by 10.107.18.230 with SMTP id 99mr13806123ios.41.1478280526803; Fri, 04 Nov 2016 10:28:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.1.2 with HTTP; Fri, 4 Nov 2016 10:28:26 -0700 (PDT) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Fri, 4 Nov 2016 10:28:26 -0700 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113fd398ae1f0805407d0185 Archived-At: Cc: quic@ietf.org, Patrick McManus Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 17:28:50 -0000 --001a113fd398ae1f0805407d0185 Content-Type: text/plain; charset=UTF-8 I have indeed been thinking about this very issue. Here is an outline of what I've got so far. I think it's not so far from what others are thinking. I call the new scheme QUIC HPACK (as opposed to HTTP/2 HPACK for status quo). - Premise: certain indexed entries should be avoided, namely indexed entries that would refer to entries that originate from headers *that are still in flight*, because packet loss on those other headers would HOL block the current stream. - The idea of QUIC HPACK then is to mark updates to the dynamic table as "pending" initially, and commit them later when the header they originate from is no longer in flight (i.e. acked to sender). Indexed entries would only be generated against dynamic tables entries that are committed. I.e., when encoding an entry, if there is a matching but pending entry in the dynamic table, generate a literal instead of indexed. - I have collected some data to measure the time between when entries are added to the table, and the creation of subsequent indexed entries that refer to them. It suggests that a small fraction of HTTP/2 HPACK indexed entries (under standard HPACK) would become literals under QUIC HPACK. ~50% are > 10s apart, and ~90% are > 50ms apart. - the new behavior could be optional, individual HTTP/2 transactions to select between this new scheme and the status quo, trading between compression and HOL freedom. Status quo transactions would still use stream 3 (HTTP/2 HPACK). Algorithm/design details: - instead using the shared headers stream (#3), each HTTP/2 transaction has a dedicated stream for headers - i.e. each HTTP/2 transaction has two QUIC streams: 1 for headers (incl. trailers if used), 1 for body. - 1 bit of the stream id will be used to classify the QUIC stream as headers or body. - like the current global header stream, these new headers streams will protected from RSTs. - *QUIC HPACK algorithm will process all headers, even if the corresponding HTTP/2 transaction may have been cancelled and corresponding body stream RST*. - QUIC HPACK encode and decode are divided into two phases each: transmit and commit. - in addition to the info already included in HTTP/2 header frames, each header transmitted from encoder to decoder will include a pair of sequence numbers, the encode sequence number and the commit epoch, described below. - *the pair will always have the property that commit epoch < encode sequence number.* - first phase (transmit): header is encoded/decoded, but updates to dynamic table are marked pending. - when processing a header, the encoder will decide which entries should be added to the dynamic table, as in current HPACK, but the entry in the dynamic table will have a "pending" flag set, preventing it from being a reference for indexed entries yet. - the encoder assigns a sequence number to each header (block), the total number of headers encoded so far (encode epoch). - the encoder/decoder enters each header into a commit sequencer (ordered queue) to be used in the second phase. - *the header is transmitted from encoder to decoder. the decoder can always decode immediately, because this algorithm prevents a header from referring to other headers that might still be in flight.* - second phase (commit): once fully transmitted, pending updates are committed, in the same order they were encoded. - at encoder, when a previously transmitted header has been acked, the entry in the commit-sequencer is marked committed. - the front of the sequencer is popped while the front is a committed entry. (loop) - the commit epoch tracks the highest sequence number popped. - at decoder, when a header is received, it will pop off the front of the commit sequencer while its sequence number is <= the just received commit epoch (loop). - each popped entry is marked committed. - now the received header is decoded. - a special case that is handled by the dynamic table in HTTP/2 HPACK but I think needs to be treated differently for QUIC HPACK, that is entries that refer to other entries from the same header. For this I propose to define a new distinct table, and corresponding distinct entry types, "Intra". This would be an ephemeral per-header table that exists only during the transmit phase. - *I don't have data yet for how many entries fall into this category.* On Thu, Nov 3, 2016 at 5:54 PM, Martin Thomson wrote: > On 4 November 2016 at 08:29, Patrick McManus wrote: > > this is a fairly significant bit of surgery to h2's formats, but given > that > > one of the real quic opportunities is to perform better under loss it > could > > be worthwhile to sever ordering dependencies even further. Seems like a > > reasonable thing to investigate to me. > > I agree. We risk negating much of the performance wins by creating > head-of-line blocking in header fields. With many resources, a lot of > the critical early interactions are entirely header fields, and hpack > is strictly serialized. > > Maybe this is a good time to raise the possibility that we might need > hpack modifications and that those modifications might benefit from a > new document. We split hpack out in h2, and it was a neat break that > we never regretted. > > -- Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a113fd398ae1f0805407d0185 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have indeed been thinking about this very issue.=C2= =A0 Here is an outline of what I've got so far.=C2=A0 I think it's = not so far from what others are thinking.

I call the new scheme QUIC HPACK (as opposed to HTTP/2 HPACK for status qu= o). =C2=A0=C2=A0
  • Premise: =C2=A0certain indexed entri= es should be avoided, namely indexed entries that would refer to entries th= at originate from headers that are still in flight, because packet l= oss on those other headers would HOL block the current stream.
  • The = idea of QUIC HPACK then is to mark updates to the dynamic table as "pe= nding" initially, and commit them later when the header they originate= from is no longer in flight (i.e. acked to sender). =C2=A0 Indexed entries= would only be generated against dynamic tables entries that are committed.= =C2=A0 I.e., when encoding an entry, if there is a =C2=A0matching but pendi= ng entry in the dynamic table, generate a literal instead of indexed.
    • <= ul>
  • I have collected some data to measure the time between when entries = are added to the table, and the creation of subsequent indexed entries that= refer to them. =C2=A0 It suggests that a small fraction of HTTP/2 HPACK in= dexed entries (under standard HPACK) would become literals under QUIC HPACK= . =C2=A0=C2=A0~50% are > 10s apart, and ~90% are > 50ms apart.
  • the new behavior could be optional, individual HTTP/2 transactions t= o select between this new scheme and the status quo, trading between compre= ssion and HOL freedom. =C2=A0 Status quo transactions would still use strea= m 3 (HTTP/2 HPACK).
Algorithm/design details:
  • inste= ad using the shared headers stream (#3), each HTTP/2 transaction has a dedi= cated stream for headers
    • i.e. each HTTP/2 transaction has two Q= UIC streams: 1 for headers (incl. trailers if used), 1 for body.
    • 1 = bit of the stream id will be used to classify the QUIC stream as headers or= body.
      • like the current global header stream, these new headers= streams will protected from RSTs.
        • QUIC HPACK algorithm will= process all headers, even if the corresponding HTTP/2 transaction may have= been cancelled and corresponding body stream RST.
    <= li>QUIC HPACK encode and decode are divided into two phases each: transmit = and commit. =C2=A0=C2=A0
    • in addition to the info already includ= ed in HTTP/2 header frames, each header transmitted from encoder to decoder= will include a pair of sequence numbers, the encode sequence number and th= e commit epoch, described below.
      • =C2=A0the pair will always = have the property that commit epoch < encode sequence number.
      • first phase (transmit): =C2=A0header is encoded/decoded, but updates= to dynamic table are marked pending.
        • when processing a header,= the encoder will decide which entries should be added to the dynamic table= , as in current HPACK, but the entry in the dynamic table will have a "= ;pending" flag set, preventing it from being a reference for indexed e= ntries yet.
        • the encoder assigns a sequence number to each header (b= lock), the total number of headers encoded so far (encode epoch).=C2=A0
        • the encoder/decoder enters each header into a commit sequencer (ordere= d queue) to be used in the second phase.
        • the header is transmitt= ed from encoder to decoder. =C2=A0the decoder can always decode immediately= , because this algorithm prevents a header from referring to other headers = that might still be in flight.
      • second phase (commit): =C2= =A0once fully transmitted, =C2=A0pending updates are committed, in the same= order they were encoded.
        • at encoder, when a previously transmi= tted header has been acked, the entry in the commit-sequencer is marked com= mitted.
          • the front of the sequencer is popped while the front is= a committed entry. (loop)
          • the commit epoch tracks the highest sequ= ence number popped.
        • at decoder, when a header is received, it = will pop off the front of the commit sequencer while its sequence number is= <=3D the just received commit epoch (loop). =C2=A0
          • each= popped entry is marked committed.
          • now the received header is decod= ed.
      • a special case that is handled by the dynamic table i= n HTTP/2 HPACK but I think needs to be treated differently for QUIC HPACK, = that is entries that refer to other entries from the same header. =C2=A0 = =C2=A0For this I propose to define a new distinct table, and corresponding = distinct entry types, "Intra". =C2=A0 This would be an ephemeral = per-header table that exists only during the transmit phase.
        • I don't have data yet for how many entries fall into this category.

On Thu, Nov 3, 2016 at 5:54 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 4 November 2016 at 08:29, Patrick McManus <= pmcmanus@mozilla.com> wrote:=
> this is a fairly significant bit of surgery to h2's formats, but g= iven that
> one of the real quic opportunities is to perform better under loss it = could
> be worthwhile to sever ordering dependencies even further. Seems like = a
> reasonable thing to investigate to me.

I agree.=C2=A0 We risk negating much of the performance wins by crea= ting
head-of-line blocking in header fields.=C2=A0 With many resources, a lot of=
the critical early interactions are entirely header fields, and hpack
is strictly serialized.

Maybe this is a good time to raise the possibility that we might need
hpack modifications and that those modifications might benefit from a
new document.=C2=A0 We split hpack out in h2, and it was a neat break that<= br> we never regretted.




--
Charles '= ;Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141

--001a113fd398ae1f0805407d0185-- From nobody Fri Nov 4 11:16:33 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A4CF129608 for ; Fri, 4 Nov 2016 11:16:32 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zPZSk4y-wzz for ; Fri, 4 Nov 2016 11:16:22 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0117.outbound.protection.outlook.com [104.47.33.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74396129600 for ; Fri, 4 Nov 2016 11:16:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LXmuINbhVvrdCjHULhgTDvkfFDoGhioE8/nq8VH1O8Y=; b=h3o1psUBPhp0FWNAaAQEr/zDzx+sq/aw3ytgbUjx3WIJ0fl27akMZ24hZ7C/b42HWLv2wp5ByT/bs2UwHR2hAa6jNbqQXzJMb31BOyYSBNB4Kes9bgJVpbyd39WINKDd3joXH1CboOOxMPLvfycv/Neqi9LzYZm4XUNvieiIoio= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Fri, 4 Nov 2016 18:16:19 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0693.016; Fri, 4 Nov 2016 18:16:19 +0000 From: Mike Bishop To: Charles 'Buck' Krasic , Martin Thomson Thread-Topic: [QUIC] h2 mapping - hpack dynamic table by reference Thread-Index: AQHSNhlXVDFlp6NaHU6EWkOyW4vQq6DH/7UAgAEVywCAAAX4YA== Date: Fri, 4 Nov 2016 18:16:19 +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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:2::ef] x-ms-office365-filtering-correlation-id: 9a004748-8219-4c86-c6cf-08d404dead0f x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:Qo+5DR5kMmAz0WkI7ybSiXIDPwt6WO3sARg9+eKyL6oO3hpwePdQSWpnt1AAMJKID+7Ih2WniiGNzZ+MtUjL9COHsClxi5xHvX1HiHc2lNQU3lXdW+5WOKFv8ovPJ6UfQWmRVd6V1UgRYSAgavlAtZ9s51bWcIwSqB6eyuL2JC8ShvsQWgAVe2kXlwb4QwssmCm6H0diaUCGDtm8IDmRuz7ioWFomGLDIXSYvYf8yyzAVx02KGzGwroNG7KQxwKx2PISLM7G0NXcaql481bytiQvCbmuwI2lZMqP1Oa4/YbdnxBG/ziVrqkEy1kKUejohAYUnlaIWBoeE7KnopXTYWWtqr3HY4EDH70dA4D16/d1q0h302zoFGeB4o9MEBMi x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2708; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060229)(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6061226)(6046074); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 01165471DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(377454003)(199003)(2906002)(2950100002)(189998001)(6116002)(790700001)(11100500001)(19300405004)(4326007)(586003)(102836003)(8676002)(7736002)(19609705001)(74316002)(5002640100001)(19580395003)(5001770100001)(19580405001)(97736004)(7846002)(76576001)(81156014)(81166006)(87936001)(99286002)(76176999)(122556002)(92566002)(54356999)(551934003)(105586002)(3660700001)(5005710100001)(10400500002)(33656002)(106116001)(5660300001)(106356001)(10290500002)(77096005)(9686002)(68736007)(101416001)(10090500001)(8990500004)(3280700002)(16236675004)(7696004)(86612001)(8936002)(86362001)(50986999)(19625215002)(15975445007)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708E5B2C2A8E43532E1447D87A20BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2016 18:16:19.7654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Cc: "quic@ietf.org" , Patrick McManus Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 18:16:32 -0000 --_000_BN6PR03MB2708E5B2C2A8E43532E1447D87A20BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBpcyBjZXJ0YWlubHkgaW50ZXJlc3RpbmcsIGJ1dCBmZWVscyBtb3JlIGxpa2UgYSB3aXNl IHN0cmF0ZWd5IGZvciBhbiBlbmNvZGVyIHRvIGVtcGxveSAoaWYgeW91IHdhbnQgdG8gYXZvaWQg YmxvY2tpbmcsIGRvbuKAmXQgcmVmZXJlbmNlIGEgaGVhZGVyIHRoYXQgaGFzbuKAmXQgYmVlbiBB Q0tlZCkgdGhhbiBhbiBpbmRlcGVuZGVudCBjaGFuZ2UgdG8gdGhlIHByb3RvY29sLiAgVGhpbmsg YWJvdXQgdXNpbmcsIHNheSwgdGhlIHVuaXF1ZS1pbmRleC1wZXItZW50cnkgYXBwcm9hY2ggKHdo aWNoIHJlcXVpcmVzIGJsb2NraW5nIG9uIHVua25vd24gaW5kaWNlcykg4oCTIGFuIGVuY29kZXIg dGhhdCB3YW50ZWQgdG8gYmUgc21hcnQgY291bGQgZG8gYXMgeW91IGRlc2NyaWJlIGJlbG93IGFu ZCBlbWl0IGxpdGVyYWxzIHVudGlsIHRoZSBmcmFtZSBoYXMgYmVlbiBBQ0vigJlkLiAgKFVubGVz cyB0aGUgZnJhbWUgd2FzIGdvaW5nIGluIHRoZSBzYW1lIHBhY2tldCBhcyB0aGUgb3JpZ2luYWwg dmFsdWUsIGlmIGl0IHdhbnRzIHRvIGJlIGV2ZW4gc21hcnRlcuKApi4pICBBbiBlbmNvZGVyIHRo YXQgZGlkbuKAmXQgd2FudCB0aGUgY29tcGxleGl0eSB3b3VsZCBqdXN0IGVtaXQgdGhlIG1vc3Qg Y29tcGFjdCByZXByZXNlbnRhdGlvbiBpdCBjb3VsZCwga25vd2luZyBpdCBtaWdodCBjYXVzZSBz b21lIGJsb2NrYWdlIG9uIHRoZSByZWNlaXZlci4NCg0KVGhlIHR3by1zdHJlYW1zLXBlci1yZXF1 ZXN0IGZlZWxzIGphcnJpbmcgdG8gbWUuICBGb3IgSFRUUCwgYXQgbGVhc3QsIHlvdSBoYXZlIGEg cmVhc29uYWJseSB3ZWxsLWRlZmluZWQgc2VyaWVzIG9mIOKAnEhlYWRlcnMrLCBCb2R5PywgSGVh ZGVycz/igJ0gaW4gZWFjaCBkaXJlY3Rpb24gZm9yIGVhY2ggdHJhbnNhY3Rpb24uICBJIGRvbuKA mXQgdGhpbmsgeW914oCZbGwgZ2V0IHJpZCBvZiB0aGUgbmVlZCB0byBoYXZlIHNvbWUgZnJhbWlu ZyBhcm91bmQgdGhlIGhlYWRlcnM7IEnigJltIG5vdCBjb252aW5jZWQgKGJ1dCB3aWxsaW5nIHRv IGJlKSB0aGF0IHRoZSBjb21wbGV4aXR5IG9mIG1hbmFnaW5nIHR3byBhZmZpbGlhdGVkIHN0cmVh bXMgaXMgZ3JlYXRlciB0aGFuIHRoYXQgb2YgbmVlZGluZyBmcmFtaW5nIGFyb3VuZCB0aGUgYm9k eSBhcyB3ZWxsIGJlY2F1c2UgaXQgc2hhcmVzIGEgc3RyZWFtIHdpdGggdGhlIGhlYWRlcnMuDQoN CkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBD aGFybGVzICdCdWNrJyBLcmFzaWMNClNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgNCwgMjAxNiAxMDoy OCBBTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpDYzog cXVpY0BpZXRmLm9yZzsgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbT4NClN1 YmplY3Q6IFJlOiBbUVVJQ10gaDIgbWFwcGluZyAtIGhwYWNrIGR5bmFtaWMgdGFibGUgYnkgcmVm ZXJlbmNlDQoNCkkgaGF2ZSBpbmRlZWQgYmVlbiB0aGlua2luZyBhYm91dCB0aGlzIHZlcnkgaXNz dWUuICBIZXJlIGlzIGFuIG91dGxpbmUgb2Ygd2hhdCBJJ3ZlIGdvdCBzbyBmYXIuICBJIHRoaW5r IGl0J3Mgbm90IHNvIGZhciBmcm9tIHdoYXQgb3RoZXJzIGFyZSB0aGlua2luZy4NCg0KSSBjYWxs IHRoZSBuZXcgc2NoZW1lIFFVSUMgSFBBQ0sgKGFzIG9wcG9zZWQgdG8gSFRUUC8yIEhQQUNLIGZv ciBzdGF0dXMgcXVvKS4NCg0KICAqICAgUHJlbWlzZTogIGNlcnRhaW4gaW5kZXhlZCBlbnRyaWVz IHNob3VsZCBiZSBhdm9pZGVkLCBuYW1lbHkgaW5kZXhlZCBlbnRyaWVzIHRoYXQgd291bGQgcmVm ZXIgdG8gZW50cmllcyB0aGF0IG9yaWdpbmF0ZSBmcm9tIGhlYWRlcnMgdGhhdCBhcmUgc3RpbGwg aW4gZmxpZ2h0LCBiZWNhdXNlIHBhY2tldCBsb3NzIG9uIHRob3NlIG90aGVyIGhlYWRlcnMgd291 bGQgSE9MIGJsb2NrIHRoZSBjdXJyZW50IHN0cmVhbS4NCiAgKiAgIFRoZSBpZGVhIG9mIFFVSUMg SFBBQ0sgdGhlbiBpcyB0byBtYXJrIHVwZGF0ZXMgdG8gdGhlIGR5bmFtaWMgdGFibGUgYXMgInBl bmRpbmciIGluaXRpYWxseSwgYW5kIGNvbW1pdCB0aGVtIGxhdGVyIHdoZW4gdGhlIGhlYWRlciB0 aGV5IG9yaWdpbmF0ZSBmcm9tIGlzIG5vIGxvbmdlciBpbiBmbGlnaHQgKGkuZS4gYWNrZWQgdG8g c2VuZGVyKS4gICBJbmRleGVkIGVudHJpZXMgd291bGQgb25seSBiZSBnZW5lcmF0ZWQgYWdhaW5z dCBkeW5hbWljIHRhYmxlcyBlbnRyaWVzIHRoYXQgYXJlIGNvbW1pdHRlZC4gIEkuZS4sIHdoZW4g ZW5jb2RpbmcgYW4gZW50cnksIGlmIHRoZXJlIGlzIGEgIG1hdGNoaW5nIGJ1dCBwZW5kaW5nIGVu dHJ5IGluIHRoZSBkeW5hbWljIHRhYmxlLCBnZW5lcmF0ZSBhIGxpdGVyYWwgaW5zdGVhZCBvZiBp bmRleGVkLg0KDQogICAgICogICBJIGhhdmUgY29sbGVjdGVkIHNvbWUgZGF0YSB0byBtZWFzdXJl IHRoZSB0aW1lIGJldHdlZW4gd2hlbiBlbnRyaWVzIGFyZSBhZGRlZCB0byB0aGUgdGFibGUsIGFu ZCB0aGUgY3JlYXRpb24gb2Ygc3Vic2VxdWVudCBpbmRleGVkIGVudHJpZXMgdGhhdCByZWZlciB0 byB0aGVtLiAgIEl0IHN1Z2dlc3RzIHRoYXQgYSBzbWFsbCBmcmFjdGlvbiBvZiBIVFRQLzIgSFBB Q0sgaW5kZXhlZCBlbnRyaWVzICh1bmRlciBzdGFuZGFyZCBIUEFDSykgd291bGQgYmVjb21lIGxp dGVyYWxzIHVuZGVyIFFVSUMgSFBBQ0suICAgfjUwJSBhcmUgPiAxMHMgYXBhcnQsIGFuZCB+OTAl IGFyZSA+IDUwbXMgYXBhcnQuDQoNCiAgKiAgIHRoZSBuZXcgYmVoYXZpb3IgY291bGQgYmUgb3B0 aW9uYWwsIGluZGl2aWR1YWwgSFRUUC8yIHRyYW5zYWN0aW9ucyB0byBzZWxlY3QgYmV0d2VlbiB0 aGlzIG5ldyBzY2hlbWUgYW5kIHRoZSBzdGF0dXMgcXVvLCB0cmFkaW5nIGJldHdlZW4gY29tcHJl c3Npb24gYW5kIEhPTCBmcmVlZG9tLiAgIFN0YXR1cyBxdW8gdHJhbnNhY3Rpb25zIHdvdWxkIHN0 aWxsIHVzZSBzdHJlYW0gMyAoSFRUUC8yIEhQQUNLKS4NCkFsZ29yaXRobS9kZXNpZ24gZGV0YWls czoNCg0KICAqICAgaW5zdGVhZCB1c2luZyB0aGUgc2hhcmVkIGhlYWRlcnMgc3RyZWFtICgjMyks IGVhY2ggSFRUUC8yIHRyYW5zYWN0aW9uIGhhcyBhIGRlZGljYXRlZCBzdHJlYW0gZm9yIGhlYWRl cnMNCg0KICAgICAqICAgaS5lLiBlYWNoIEhUVFAvMiB0cmFuc2FjdGlvbiBoYXMgdHdvIFFVSUMg c3RyZWFtczogMSBmb3IgaGVhZGVycyAoaW5jbC4gdHJhaWxlcnMgaWYgdXNlZCksIDEgZm9yIGJv ZHkuDQogICAgICogICAxIGJpdCBvZiB0aGUgc3RyZWFtIGlkIHdpbGwgYmUgdXNlZCB0byBjbGFz c2lmeSB0aGUgUVVJQyBzdHJlYW0gYXMgaGVhZGVycyBvciBib2R5Lg0KDQogICAgICAgICogICBs aWtlIHRoZSBjdXJyZW50IGdsb2JhbCBoZWFkZXIgc3RyZWFtLCB0aGVzZSBuZXcgaGVhZGVycyBz dHJlYW1zIHdpbGwgcHJvdGVjdGVkIGZyb20gUlNUcy4NCg0KICAgICAgICAgICAqICAgUVVJQyBI UEFDSyBhbGdvcml0aG0gd2lsbCBwcm9jZXNzIGFsbCBoZWFkZXJzLCBldmVuIGlmIHRoZSBjb3Jy ZXNwb25kaW5nIEhUVFAvMiB0cmFuc2FjdGlvbiBtYXkgaGF2ZSBiZWVuIGNhbmNlbGxlZCBhbmQg Y29ycmVzcG9uZGluZyBib2R5IHN0cmVhbSBSU1QuDQoNCiAgKiAgIFFVSUMgSFBBQ0sgZW5jb2Rl IGFuZCBkZWNvZGUgYXJlIGRpdmlkZWQgaW50byB0d28gcGhhc2VzIGVhY2g6IHRyYW5zbWl0IGFu ZCBjb21taXQuDQoNCiAgICAgKiAgIGluIGFkZGl0aW9uIHRvIHRoZSBpbmZvIGFscmVhZHkgaW5j bHVkZWQgaW4gSFRUUC8yIGhlYWRlciBmcmFtZXMsIGVhY2ggaGVhZGVyIHRyYW5zbWl0dGVkIGZy b20gZW5jb2RlciB0byBkZWNvZGVyIHdpbGwgaW5jbHVkZSBhIHBhaXIgb2Ygc2VxdWVuY2UgbnVt YmVycywgdGhlIGVuY29kZSBzZXF1ZW5jZSBudW1iZXIgYW5kIHRoZSBjb21taXQgZXBvY2gsIGRl c2NyaWJlZCBiZWxvdy4NCg0KICAgICAgICAqICAgIHRoZSBwYWlyIHdpbGwgYWx3YXlzIGhhdmUg dGhlIHByb3BlcnR5IHRoYXQgY29tbWl0IGVwb2NoIDwgZW5jb2RlIHNlcXVlbmNlIG51bWJlci4N Cg0KICAgICAqICAgZmlyc3QgcGhhc2UgKHRyYW5zbWl0KTogIGhlYWRlciBpcyBlbmNvZGVkL2Rl Y29kZWQsIGJ1dCB1cGRhdGVzIHRvIGR5bmFtaWMgdGFibGUgYXJlIG1hcmtlZCBwZW5kaW5nLg0K DQogICAgICAgICogICB3aGVuIHByb2Nlc3NpbmcgYSBoZWFkZXIsIHRoZSBlbmNvZGVyIHdpbGwg ZGVjaWRlIHdoaWNoIGVudHJpZXMgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBkeW5hbWljIHRhYmxl LCBhcyBpbiBjdXJyZW50IEhQQUNLLCBidXQgdGhlIGVudHJ5IGluIHRoZSBkeW5hbWljIHRhYmxl IHdpbGwgaGF2ZSBhICJwZW5kaW5nIiBmbGFnIHNldCwgcHJldmVudGluZyBpdCBmcm9tIGJlaW5n IGEgcmVmZXJlbmNlIGZvciBpbmRleGVkIGVudHJpZXMgeWV0Lg0KICAgICAgICAqICAgdGhlIGVu Y29kZXIgYXNzaWducyBhIHNlcXVlbmNlIG51bWJlciB0byBlYWNoIGhlYWRlciAoYmxvY2spLCB0 aGUgdG90YWwgbnVtYmVyIG9mIGhlYWRlcnMgZW5jb2RlZCBzbyBmYXIgKGVuY29kZSBlcG9jaCku DQogICAgICAgICogICB0aGUgZW5jb2Rlci9kZWNvZGVyIGVudGVycyBlYWNoIGhlYWRlciBpbnRv IGEgY29tbWl0IHNlcXVlbmNlciAob3JkZXJlZCBxdWV1ZSkgdG8gYmUgdXNlZCBpbiB0aGUgc2Vj b25kIHBoYXNlLg0KICAgICAgICAqICAgdGhlIGhlYWRlciBpcyB0cmFuc21pdHRlZCBmcm9tIGVu Y29kZXIgdG8gZGVjb2Rlci4gIHRoZSBkZWNvZGVyIGNhbiBhbHdheXMgZGVjb2RlIGltbWVkaWF0 ZWx5LCBiZWNhdXNlIHRoaXMgYWxnb3JpdGhtIHByZXZlbnRzIGEgaGVhZGVyIGZyb20gcmVmZXJy aW5nIHRvIG90aGVyIGhlYWRlcnMgdGhhdCBtaWdodCBzdGlsbCBiZSBpbiBmbGlnaHQuDQoNCiAg ICAgKiAgIHNlY29uZCBwaGFzZSAoY29tbWl0KTogIG9uY2UgZnVsbHkgdHJhbnNtaXR0ZWQsICBw ZW5kaW5nIHVwZGF0ZXMgYXJlIGNvbW1pdHRlZCwgaW4gdGhlIHNhbWUgb3JkZXIgdGhleSB3ZXJl IGVuY29kZWQuDQoNCiAgICAgICAgKiAgIGF0IGVuY29kZXIsIHdoZW4gYSBwcmV2aW91c2x5IHRy YW5zbWl0dGVkIGhlYWRlciBoYXMgYmVlbiBhY2tlZCwgdGhlIGVudHJ5IGluIHRoZSBjb21taXQt c2VxdWVuY2VyIGlzIG1hcmtlZCBjb21taXR0ZWQuDQoNCiAgICAgICAgICAgKiAgIHRoZSBmcm9u dCBvZiB0aGUgc2VxdWVuY2VyIGlzIHBvcHBlZCB3aGlsZSB0aGUgZnJvbnQgaXMgYSBjb21taXR0 ZWQgZW50cnkuIChsb29wKQ0KICAgICAgICAgICAqICAgdGhlIGNvbW1pdCBlcG9jaCB0cmFja3Mg dGhlIGhpZ2hlc3Qgc2VxdWVuY2UgbnVtYmVyIHBvcHBlZC4NCg0KICAgICAgICAqICAgYXQgZGVj b2Rlciwgd2hlbiBhIGhlYWRlciBpcyByZWNlaXZlZCwgaXQgd2lsbCBwb3Agb2ZmIHRoZSBmcm9u dCBvZiB0aGUgY29tbWl0IHNlcXVlbmNlciB3aGlsZSBpdHMgc2VxdWVuY2UgbnVtYmVyIGlzIDw9 IHRoZSBqdXN0IHJlY2VpdmVkIGNvbW1pdCBlcG9jaCAobG9vcCkuDQoNCiAgICAgICAgICAgKiAg IGVhY2ggcG9wcGVkIGVudHJ5IGlzIG1hcmtlZCBjb21taXR0ZWQuDQogICAgICAgICAgICogICBu b3cgdGhlIHJlY2VpdmVkIGhlYWRlciBpcyBkZWNvZGVkLg0KDQogICAgICogICBhIHNwZWNpYWwg Y2FzZSB0aGF0IGlzIGhhbmRsZWQgYnkgdGhlIGR5bmFtaWMgdGFibGUgaW4gSFRUUC8yIEhQQUNL IGJ1dCBJIHRoaW5rIG5lZWRzIHRvIGJlIHRyZWF0ZWQgZGlmZmVyZW50bHkgZm9yIFFVSUMgSFBB Q0ssIHRoYXQgaXMgZW50cmllcyB0aGF0IHJlZmVyIHRvIG90aGVyIGVudHJpZXMgZnJvbSB0aGUg c2FtZSBoZWFkZXIuICAgIEZvciB0aGlzIEkgcHJvcG9zZSB0byBkZWZpbmUgYSBuZXcgZGlzdGlu Y3QgdGFibGUsIGFuZCBjb3JyZXNwb25kaW5nIGRpc3RpbmN0IGVudHJ5IHR5cGVzLCAiSW50cmEi LiAgIFRoaXMgd291bGQgYmUgYW4gZXBoZW1lcmFsIHBlci1oZWFkZXIgdGFibGUgdGhhdCBleGlz dHMgb25seSBkdXJpbmcgdGhlIHRyYW5zbWl0IHBoYXNlLg0KDQogICAgICAgICogICBJIGRvbid0 IGhhdmUgZGF0YSB5ZXQgZm9yIGhvdyBtYW55IGVudHJpZXMgZmFsbCBpbnRvIHRoaXMgY2F0ZWdv cnkuDQoNCk9uIFRodSwgTm92IDMsIDIwMTYgYXQgNTo1NCBQTSwgTWFydGluIFRob21zb24gPG1h cnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4g d3JvdGU6DQpPbiA0IE5vdmVtYmVyIDIwMTYgYXQgMDg6MjksIFBhdHJpY2sgTWNNYW51cyA8cG1j bWFudXNAbW96aWxsYS5jb208bWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tPj4gd3JvdGU6DQo+ IHRoaXMgaXMgYSBmYWlybHkgc2lnbmlmaWNhbnQgYml0IG9mIHN1cmdlcnkgdG8gaDIncyBmb3Jt YXRzLCBidXQgZ2l2ZW4gdGhhdA0KPiBvbmUgb2YgdGhlIHJlYWwgcXVpYyBvcHBvcnR1bml0aWVz IGlzIHRvIHBlcmZvcm0gYmV0dGVyIHVuZGVyIGxvc3MgaXQgY291bGQNCj4gYmUgd29ydGh3aGls ZSB0byBzZXZlciBvcmRlcmluZyBkZXBlbmRlbmNpZXMgZXZlbiBmdXJ0aGVyLiBTZWVtcyBsaWtl IGENCj4gcmVhc29uYWJsZSB0aGluZyB0byBpbnZlc3RpZ2F0ZSB0byBtZS4NCg0KSSBhZ3JlZS4g IFdlIHJpc2sgbmVnYXRpbmcgbXVjaCBvZiB0aGUgcGVyZm9ybWFuY2Ugd2lucyBieSBjcmVhdGlu Zw0KaGVhZC1vZi1saW5lIGJsb2NraW5nIGluIGhlYWRlciBmaWVsZHMuICBXaXRoIG1hbnkgcmVz b3VyY2VzLCBhIGxvdCBvZg0KdGhlIGNyaXRpY2FsIGVhcmx5IGludGVyYWN0aW9ucyBhcmUgZW50 aXJlbHkgaGVhZGVyIGZpZWxkcywgYW5kIGhwYWNrDQppcyBzdHJpY3RseSBzZXJpYWxpemVkLg0K DQpNYXliZSB0aGlzIGlzIGEgZ29vZCB0aW1lIHRvIHJhaXNlIHRoZSBwb3NzaWJpbGl0eSB0aGF0 IHdlIG1pZ2h0IG5lZWQNCmhwYWNrIG1vZGlmaWNhdGlvbnMgYW5kIHRoYXQgdGhvc2UgbW9kaWZp Y2F0aW9ucyBtaWdodCBiZW5lZml0IGZyb20gYQ0KbmV3IGRvY3VtZW50LiAgV2Ugc3BsaXQgaHBh Y2sgb3V0IGluIGgyLCBhbmQgaXQgd2FzIGEgbmVhdCBicmVhayB0aGF0DQp3ZSBuZXZlciByZWdy ZXR0ZWQuDQoNCg0KDQotLQ0KQ2hhcmxlcyAnQnVjaycgS3Jhc2ljIHwgU29mdHdhcmUgRW5naW5l ZXIgfCBja3Jhc2ljQGdvb2dsZS5jb208bWFpbHRvOmNrcmFzaWNAZ29vZ2xlLmNvbT4gfCArMSAo NDA4KSA0MTItMTE0MQ0K --_000_BN6PR03MB2708E5B2C2A8E43532E1447D87A20BN6PR03MB2708namp_ 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 aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjQyMDE4MzMwNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTQyOTQ5MDg5Njt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7 fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTA5MzYyOTc3NTsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTEyMDcxNTQ5NTA7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGNlcnRhaW5s eSBpbnRlcmVzdGluZywgYnV0IGZlZWxzIG1vcmUgbGlrZSBhIHdpc2Ugc3RyYXRlZ3kgZm9yIGFu IGVuY29kZXIgdG8gZW1wbG95IChpZiB5b3Ugd2FudCB0byBhdm9pZCBibG9ja2luZywgZG9u4oCZ dCByZWZlcmVuY2UgYSBoZWFkZXIgdGhhdCBoYXNu4oCZdCBiZWVuIEFDS2VkKSB0aGFuIGFuIGlu ZGVwZW5kZW50IGNoYW5nZSB0byB0aGUgcHJvdG9jb2wuJm5ic3A7IFRoaW5rIGFib3V0IHVzaW5n LA0KIHNheSwgdGhlIHVuaXF1ZS1pbmRleC1wZXItZW50cnkgYXBwcm9hY2ggKHdoaWNoIHJlcXVp cmVzIGJsb2NraW5nIG9uIHVua25vd24gaW5kaWNlcykg4oCTIGFuIGVuY29kZXIgdGhhdCB3YW50 ZWQgdG8gYmUgc21hcnQgY291bGQgZG8gYXMgeW91IGRlc2NyaWJlIGJlbG93IGFuZCBlbWl0IGxp dGVyYWxzIHVudGlsIHRoZSBmcmFtZSBoYXMgYmVlbiBBQ0vigJlkLiZuYnNwOyAoVW5sZXNzIHRo ZSBmcmFtZSB3YXMgZ29pbmcgaW4gdGhlIHNhbWUgcGFja2V0IGFzIHRoZQ0KIG9yaWdpbmFsIHZh bHVlLCBpZiBpdCB3YW50cyB0byBiZSBldmVuIHNtYXJ0ZXLigKYuKSZuYnNwOyBBbiBlbmNvZGVy IHRoYXQgZGlkbuKAmXQgd2FudCB0aGUgY29tcGxleGl0eSB3b3VsZCBqdXN0IGVtaXQgdGhlIG1v c3QgY29tcGFjdCByZXByZXNlbnRhdGlvbiBpdCBjb3VsZCwga25vd2luZyBpdCBtaWdodCBjYXVz ZSBzb21lIGJsb2NrYWdlIG9uIHRoZSByZWNlaXZlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHR3by1zdHJlYW1zLXBlci1yZXF1ZXN0IGZlZWxzIGphcnJpbmcgdG8gbWUuJm5ic3A7IEZv ciBIVFRQLCBhdCBsZWFzdCwgeW91IGhhdmUgYSByZWFzb25hYmx5IHdlbGwtZGVmaW5lZCBzZXJp ZXMgb2Yg4oCcSGVhZGVycyYjNDM7LCBCb2R5PywgSGVhZGVycz/igJ0gaW4gZWFjaCBkaXJlY3Rp b24gZm9yIGVhY2ggdHJhbnNhY3Rpb24uJm5ic3A7IEkgZG9u4oCZdCB0aGluayB5b3XigJlsbCBn ZXQgcmlkIG9mIHRoZSBuZWVkIHRvIGhhdmUgc29tZQ0KIGZyYW1pbmcgYXJvdW5kIHRoZSBoZWFk ZXJzOyBJ4oCZbSBub3QgY29udmluY2VkIChidXQgd2lsbGluZyB0byBiZSkgdGhhdCB0aGUgY29t cGxleGl0eSBvZiBtYW5hZ2luZyB0d28gYWZmaWxpYXRlZCBzdHJlYW1zIGlzIGdyZWF0ZXIgdGhh biB0aGF0IG9mIG5lZWRpbmcgZnJhbWluZyBhcm91bmQgdGhlIGJvZHkgYXMgd2VsbCBiZWNhdXNl IGl0IHNoYXJlcyBhIHN0cmVhbSB3aXRoIHRoZSBoZWFkZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+ T24gQmVoYWxmIE9mDQo8L2I+Q2hhcmxlcyAnQnVjaycgS3Jhc2ljPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgTm92ZW1iZXIgNCwgMjAxNiAxMDoyOCBBTTxicj4NCjxiPlRvOjwvYj4gTWFydGlu IFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ IHF1aWNAaWV0Zi5vcmc7IFBhdHJpY2sgTWNNYW51cyAmbHQ7cG1jbWFudXNAbW96aWxsYS5jb20m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUVVJQ10gaDIgbWFwcGluZyAtIGhwYWNrIGR5 bmFtaWMgdGFibGUgYnkgcmVmZXJlbmNlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBoYXZlIGluZGVlZCBiZWVuIHRoaW5raW5nIGFib3V0IHRoaXMgdmVyeSBpc3N1ZS4m bmJzcDsgSGVyZSBpcyBhbiBvdXRsaW5lIG9mIHdoYXQgSSd2ZSBnb3Qgc28gZmFyLiZuYnNwOyBJ IHRoaW5rIGl0J3Mgbm90IHNvIGZhciBmcm9tIHdoYXQgb3RoZXJzIGFyZSB0aGlua2luZy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkkgY2FsbCB0aGUgbmV3IHNjaGVtZSBRVUlDIEhQQUNLIChhcyBvcHBvc2VkIHRvIEhUVFAvMiBI UEFDSyBmb3Igc3RhdHVzIHF1bykuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KUHJlbWlzZTogJm5ic3A7Y2VydGFp biBpbmRleGVkIGVudHJpZXMgc2hvdWxkIGJlIGF2b2lkZWQsIG5hbWVseSBpbmRleGVkIGVudHJp ZXMgdGhhdCB3b3VsZCByZWZlciB0byBlbnRyaWVzIHRoYXQgb3JpZ2luYXRlIGZyb20gaGVhZGVy cw0KPGk+dGhhdCBhcmUgc3RpbGwgaW4gZmxpZ2h0PC9pPiwgYmVjYXVzZSBwYWNrZXQgbG9zcyBv biB0aG9zZSBvdGhlciBoZWFkZXJzIHdvdWxkIEhPTCBibG9jayB0aGUgY3VycmVudCBzdHJlYW0u PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwxIGxldmVsMSBsZm8xIj4NClRoZSBpZGVhIG9mIFFVSUMgSFBBQ0sgdGhlbiBpcyB0 byBtYXJrIHVwZGF0ZXMgdG8gdGhlIGR5bmFtaWMgdGFibGUgYXMgJnF1b3Q7cGVuZGluZyZxdW90 OyBpbml0aWFsbHksIGFuZCBjb21taXQgdGhlbSBsYXRlciB3aGVuIHRoZSBoZWFkZXIgdGhleSBv cmlnaW5hdGUgZnJvbSBpcyBubyBsb25nZXIgaW4gZmxpZ2h0IChpLmUuIGFja2VkIHRvIHNlbmRl cikuICZuYnNwOyBJbmRleGVkIGVudHJpZXMgd291bGQgb25seSBiZSBnZW5lcmF0ZWQgYWdhaW5z dCBkeW5hbWljIHRhYmxlcw0KIGVudHJpZXMgdGhhdCBhcmUgY29tbWl0dGVkLiZuYnNwOyBJLmUu LCB3aGVuIGVuY29kaW5nIGFuIGVudHJ5LCBpZiB0aGVyZSBpcyBhICZuYnNwO21hdGNoaW5nIGJ1 dCBwZW5kaW5nIGVudHJ5IGluIHRoZSBkeW5hbWljIHRhYmxlLCBnZW5lcmF0ZSBhIGxpdGVyYWwg aW5zdGVhZCBvZiBpbmRleGVkLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMSBsZXZlbDIgbGZvMSI+DQpJIGhhdmUgY29sbGVjdGVkIHNvbWUgZGF0 YSB0byBtZWFzdXJlIHRoZSB0aW1lIGJldHdlZW4gd2hlbiBlbnRyaWVzIGFyZSBhZGRlZCB0byB0 aGUgdGFibGUsIGFuZCB0aGUgY3JlYXRpb24gb2Ygc3Vic2VxdWVudCBpbmRleGVkIGVudHJpZXMg dGhhdCByZWZlciB0byB0aGVtLiAmbmJzcDsgSXQgc3VnZ2VzdHMgdGhhdCBhIHNtYWxsIGZyYWN0 aW9uIG9mIEhUVFAvMiBIUEFDSyBpbmRleGVkIGVudHJpZXMgKHVuZGVyIHN0YW5kYXJkIEhQQUNL KSB3b3VsZCBiZWNvbWUNCiBsaXRlcmFscyB1bmRlciBRVUlDIEhQQUNLLiAmbmJzcDsmbmJzcDt+ NTAlIGFyZSAmZ3Q7IDEwcyBhcGFydCwgYW5kIH45MCUgYXJlICZndDsgNTBtcyBhcGFydC48bzpw PjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQp0aGUg bmV3IGJlaGF2aW9yIGNvdWxkIGJlIG9wdGlvbmFsLCBpbmRpdmlkdWFsIEhUVFAvMiB0cmFuc2Fj dGlvbnMgdG8gc2VsZWN0IGJldHdlZW4gdGhpcyBuZXcgc2NoZW1lIGFuZCB0aGUgc3RhdHVzIHF1 bywgdHJhZGluZyBiZXR3ZWVuIGNvbXByZXNzaW9uIGFuZCBIT0wgZnJlZWRvbS4gJm5ic3A7IFN0 YXR1cyBxdW8gdHJhbnNhY3Rpb25zIHdvdWxkIHN0aWxsIHVzZSBzdHJlYW0gMyAoSFRUUC8yIEhQ QUNLKS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsZ29yaXRo bS9kZXNpZ24gZGV0YWlsczo8bzpwPjwvbzpwPjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij4NCmluc3RlYWQgdXNpbmcgdGhlIHNoYXJlZCBoZWFkZXJzIHN0cmVhbSAoIzMpLCBlYWNoIEhU VFAvMiB0cmFuc2FjdGlvbiBoYXMgYSBkZWRpY2F0ZWQgc3RyZWFtIGZvciBoZWFkZXJzPG86cD48 L286cD48L2xpPjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBs Zm8yIj4NCmkuZS4gZWFjaCBIVFRQLzIgdHJhbnNhY3Rpb24gaGFzIHR3byBRVUlDIHN0cmVhbXM6 IDEgZm9yIGhlYWRlcnMgKGluY2wuIHRyYWlsZXJzIGlmIHVzZWQpLCAxIGZvciBib2R5LjxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMCBsZXZlbDIgbGZvMiI+DQoxIGJpdCBvZiB0aGUgc3RyZWFtIGlkIHdpbGwgYmUgdXNlZCB0 byBjbGFzc2lmeSB0aGUgUVVJQyBzdHJlYW0gYXMgaGVhZGVycyBvciBib2R5LjxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0K PHVsIHR5cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMCBsZXZlbDMgbGZvMiI+DQpsaWtlIHRoZSBjdXJyZW50IGdsb2JhbCBoZWFk ZXIgc3RyZWFtLCB0aGVzZSBuZXcgaGVhZGVycyBzdHJlYW1zIHdpbGwgcHJvdGVjdGVkIGZyb20g UlNUcy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8L3VsPg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8dWwgdHlwZT0ic3F1YXJlIj4NCjx1bCB0eXBlPSJzcXVh cmUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWw0IGxmbzIiPg0KPGk+UVVJQyBIUEFDSyBhbGdvcml0aG0gd2lsbCBwcm9jZXNzIGFsbCBo ZWFkZXJzLCBldmVuIGlmIHRoZSBjb3JyZXNwb25kaW5nIEhUVFAvMiB0cmFuc2FjdGlvbiBtYXkg aGF2ZSBiZWVuIGNhbmNlbGxlZCBhbmQgY29ycmVzcG9uZGluZyBib2R5IHN0cmVhbSBSU1Q8L2k+ LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjwvdWw+DQo8L3VsPg0KPHVsIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzIiPg0KUVVJQyBIUEFDSyBlbmNvZGUgYW5kIGRlY29kZSBhcmUgZGl2aWRlZCBp bnRvIHR3byBwaGFzZXMgZWFjaDogdHJhbnNtaXQgYW5kIGNvbW1pdC4gJm5ic3A7Jm5ic3A7PG86 cD48L286cD48L2xpPjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MiBsZm8yIj4NCmluIGFkZGl0aW9uIHRvIHRoZSBpbmZvIGFscmVhZHkgaW5jbHVkZWQgaW4gSFRU UC8yIGhlYWRlciBmcmFtZXMsIGVhY2ggaGVhZGVyIHRyYW5zbWl0dGVkIGZyb20gZW5jb2RlciB0 byBkZWNvZGVyIHdpbGwgaW5jbHVkZSBhIHBhaXIgb2Ygc2VxdWVuY2UgbnVtYmVycywgdGhlIGVu Y29kZSBzZXF1ZW5jZSBudW1iZXIgYW5kIHRoZSBjb21taXQgZXBvY2gsIGRlc2NyaWJlZCBiZWxv dy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlw ZT0iY2lyY2xlIj4NCjx1bCB0eXBlPSJzcXVhcmUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzIiPg0KJm5ic3A7PGk+dGhlIHBh aXIgd2lsbCBhbHdheXMgaGF2ZSB0aGUgcHJvcGVydHkgdGhhdCBjb21taXQgZXBvY2ggJmx0OyBl bmNvZGUgc2VxdWVuY2UgbnVtYmVyLjwvaT48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8 L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMiI+DQpmaXJz dCBwaGFzZSAodHJhbnNtaXQpOiAmbmJzcDtoZWFkZXIgaXMgZW5jb2RlZC9kZWNvZGVkLCBidXQg dXBkYXRlcyB0byBkeW5hbWljIHRhYmxlIGFyZSBtYXJrZWQgcGVuZGluZy48bzpwPjwvbzpwPjwv bGk+PC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjx1 bCB0eXBlPSJzcXVhcmUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47 bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzIiPg0Kd2hlbiBwcm9jZXNzaW5nIGEgaGVhZGVyLCB0aGUg ZW5jb2RlciB3aWxsIGRlY2lkZSB3aGljaCBlbnRyaWVzIHNob3VsZCBiZSBhZGRlZCB0byB0aGUg ZHluYW1pYyB0YWJsZSwgYXMgaW4gY3VycmVudCBIUEFDSywgYnV0IHRoZSBlbnRyeSBpbiB0aGUg ZHluYW1pYyB0YWJsZSB3aWxsIGhhdmUgYSAmcXVvdDtwZW5kaW5nJnF1b3Q7IGZsYWcgc2V0LCBw cmV2ZW50aW5nIGl0IGZyb20gYmVpbmcgYSByZWZlcmVuY2UgZm9yIGluZGV4ZWQgZW50cmllcyB5 ZXQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwwIGxldmVsMyBsZm8yIj4NCnRoZSBlbmNvZGVyIGFzc2lnbnMgYSBzZXF1ZW5j ZSBudW1iZXIgdG8gZWFjaCBoZWFkZXIgKGJsb2NrKSwgdGhlIHRvdGFsIG51bWJlciBvZiBoZWFk ZXJzIGVuY29kZWQgc28gZmFyIChlbmNvZGUgZXBvY2gpLiZuYnNwOzxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDMg bGZvMiI+DQp0aGUgZW5jb2Rlci9kZWNvZGVyIGVudGVycyBlYWNoIGhlYWRlciBpbnRvIGEgY29t bWl0IHNlcXVlbmNlciAob3JkZXJlZCBxdWV1ZSkgdG8gYmUgdXNlZCBpbiB0aGUgc2Vjb25kIHBo YXNlLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBp bjttc28tbGlzdDpsMCBsZXZlbDMgbGZvMiI+DQo8aT50aGUgaGVhZGVyIGlzIHRyYW5zbWl0dGVk IGZyb20gZW5jb2RlciB0byBkZWNvZGVyLiAmbmJzcDt0aGUgZGVjb2RlciBjYW4gYWx3YXlzIGRl Y29kZSBpbW1lZGlhdGVseSwgYmVjYXVzZSB0aGlzIGFsZ29yaXRobSBwcmV2ZW50cyBhIGhlYWRl ciBmcm9tIHJlZmVycmluZyB0byBvdGhlciBoZWFkZXJzIHRoYXQgbWlnaHQgc3RpbGwgYmUgaW4g ZmxpZ2h0LjwvaT48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8L3VsPg0KPHVsIHR5cGU9 ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIgbGZvMiI+DQpzZWNvbmQgcGhhc2UgKGNvbW1p dCk6ICZuYnNwO29uY2UgZnVsbHkgdHJhbnNtaXR0ZWQsICZuYnNwO3BlbmRpbmcgdXBkYXRlcyBh cmUgY29tbWl0dGVkLCBpbiB0aGUgc2FtZSBvcmRlciB0aGV5IHdlcmUgZW5jb2RlZC48bzpwPjwv bzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xl Ij4NCjx1bCB0eXBlPSJzcXVhcmUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzIiPg0KYXQgZW5jb2Rlciwgd2hlbiBhIHByZXZp b3VzbHkgdHJhbnNtaXR0ZWQgaGVhZGVyIGhhcyBiZWVuIGFja2VkLCB0aGUgZW50cnkgaW4gdGhl IGNvbW1pdC1zZXF1ZW5jZXIgaXMgbWFya2VkIGNvbW1pdHRlZC48bzpwPjwvbzpwPjwvbGk+PC91 bD4NCjwvdWw+DQo8L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8 dWwgdHlwZT0ic3F1YXJlIj4NCjx1bCB0eXBlPSJzcXVhcmUiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWw0IGxmbzIiPg0KdGhlIGZyb250 IG9mIHRoZSBzZXF1ZW5jZXIgaXMgcG9wcGVkIHdoaWxlIHRoZSBmcm9udCBpcyBhIGNvbW1pdHRl ZCBlbnRyeS4gKGxvb3ApPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsNCBsZm8yIj4NCnRoZSBjb21taXQgZXBvY2gg dHJhY2tzIHRoZSBoaWdoZXN0IHNlcXVlbmNlIG51bWJlciBwb3BwZWQuPG86cD48L286cD48L2xp PjwvdWw+DQo8L3VsPg0KPC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0i Y2lyY2xlIj4NCjx1bCB0eXBlPSJzcXVhcmUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzIiPg0KYXQgZGVjb2Rlciwgd2hlbiBh IGhlYWRlciBpcyByZWNlaXZlZCwgaXQgd2lsbCBwb3Agb2ZmIHRoZSBmcm9udCBvZiB0aGUgY29t bWl0IHNlcXVlbmNlciB3aGlsZSBpdHMgc2VxdWVuY2UgbnVtYmVyIGlzICZsdDs9IHRoZSBqdXN0 IHJlY2VpdmVkIGNvbW1pdCBlcG9jaCAobG9vcCkuICZuYnNwOzxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjx1 bCB0eXBlPSJzcXVhcmUiPg0KPHVsIHR5cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDQgbGZvMiI+DQplYWNoIHBvcHBl ZCBlbnRyeSBpcyBtYXJrZWQgY29tbWl0dGVkLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDQgbGZvMiI+DQpub3cg dGhlIHJlY2VpdmVkIGhlYWRlciBpcyBkZWNvZGVkLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91 bD4NCjwvdWw+DQo8L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDIg bGZvMiI+DQphIHNwZWNpYWwgY2FzZSB0aGF0IGlzIGhhbmRsZWQgYnkgdGhlIGR5bmFtaWMgdGFi bGUgaW4gSFRUUC8yIEhQQUNLIGJ1dCBJIHRoaW5rIG5lZWRzIHRvIGJlIHRyZWF0ZWQgZGlmZmVy ZW50bHkgZm9yIFFVSUMgSFBBQ0ssIHRoYXQgaXMgZW50cmllcyB0aGF0IHJlZmVyIHRvIG90aGVy IGVudHJpZXMgZnJvbSB0aGUgc2FtZSBoZWFkZXIuICZuYnNwOyAmbmJzcDtGb3IgdGhpcyBJIHBy b3Bvc2UgdG8gZGVmaW5lIGEgbmV3IGRpc3RpbmN0IHRhYmxlLCBhbmQgY29ycmVzcG9uZGluZw0K IGRpc3RpbmN0IGVudHJ5IHR5cGVzLCAmcXVvdDtJbnRyYSZxdW90Oy4gJm5ic3A7IFRoaXMgd291 bGQgYmUgYW4gZXBoZW1lcmFsIHBlci1oZWFkZXIgdGFibGUgdGhhdCBleGlzdHMgb25seSBkdXJp bmcgdGhlIHRyYW5zbWl0IHBoYXNlLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjx1bCB0 eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPHVsIHR5cGU9InNxdWFyZSI+DQo8bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDMgbGZv MiI+DQo8aT5JIGRvbid0IGhhdmUgZGF0YSB5ZXQgZm9yIGhvdyBtYW55IGVudHJpZXMgZmFsbCBp bnRvIHRoaXMgY2F0ZWdvcnkuPC9pPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjwvdWw+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBO b3YgMywgMjAxNiBhdCA1OjU0IFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEgaHJlZj0ibWFpbHRv Om1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1hcnRpbi50aG9tc29u QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gNCBOb3Zl bWJlciAyMDE2IGF0IDA4OjI5LCBQYXRyaWNrIE1jTWFudXMgJmx0OzxhIGhyZWY9Im1haWx0bzpw bWNtYW51c0Btb3ppbGxhLmNvbSI+cG1jbWFudXNAbW96aWxsYS5jb208L2E+Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7IHRoaXMgaXMgYSBmYWlybHkgc2lnbmlmaWNhbnQgYml0IG9mIHN1cmdlcnkgdG8g aDIncyBmb3JtYXRzLCBidXQgZ2l2ZW4gdGhhdDxicj4NCiZndDsgb25lIG9mIHRoZSByZWFsIHF1 aWMgb3Bwb3J0dW5pdGllcyBpcyB0byBwZXJmb3JtIGJldHRlciB1bmRlciBsb3NzIGl0IGNvdWxk PGJyPg0KJmd0OyBiZSB3b3J0aHdoaWxlIHRvIHNldmVyIG9yZGVyaW5nIGRlcGVuZGVuY2llcyBl dmVuIGZ1cnRoZXIuIFNlZW1zIGxpa2UgYTxicj4NCiZndDsgcmVhc29uYWJsZSB0aGluZyB0byBp bnZlc3RpZ2F0ZSB0byBtZS48YnI+DQo8YnI+DQpJIGFncmVlLiZuYnNwOyBXZSByaXNrIG5lZ2F0 aW5nIG11Y2ggb2YgdGhlIHBlcmZvcm1hbmNlIHdpbnMgYnkgY3JlYXRpbmc8YnI+DQpoZWFkLW9m LWxpbmUgYmxvY2tpbmcgaW4gaGVhZGVyIGZpZWxkcy4mbmJzcDsgV2l0aCBtYW55IHJlc291cmNl cywgYSBsb3Qgb2Y8YnI+DQp0aGUgY3JpdGljYWwgZWFybHkgaW50ZXJhY3Rpb25zIGFyZSBlbnRp cmVseSBoZWFkZXIgZmllbGRzLCBhbmQgaHBhY2s8YnI+DQppcyBzdHJpY3RseSBzZXJpYWxpemVk Ljxicj4NCjxicj4NCk1heWJlIHRoaXMgaXMgYSBnb29kIHRpbWUgdG8gcmFpc2UgdGhlIHBvc3Np YmlsaXR5IHRoYXQgd2UgbWlnaHQgbmVlZDxicj4NCmhwYWNrIG1vZGlmaWNhdGlvbnMgYW5kIHRo YXQgdGhvc2UgbW9kaWZpY2F0aW9ucyBtaWdodCBiZW5lZml0IGZyb20gYTxicj4NCm5ldyBkb2N1 bWVudC4mbmJzcDsgV2Ugc3BsaXQgaHBhY2sgb3V0IGluIGgyLCBhbmQgaXQgd2FzIGEgbmVhdCBi cmVhayB0aGF0PGJyPg0Kd2UgbmV2ZXIgcmVncmV0dGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnIgY2xlYXI9ImFs bCI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICNENTBGMjUg MS41cHQ7cGFkZGluZzoyLjBwdCI+Q2hhcmxlcyAnQnVjaycgS3Jhc2ljJm5ic3A7fDwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICMzMzY5RTggMS41cHQ7cGFk ZGluZzoyLjBwdCI+Jm5ic3A7U29mdHdhcmUNCiBFbmdpbmVlciZuYnNwO3w8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpzb2xpZCAjMDA5OTM5IDEuNXB0O3BhZGRpbmc6 Mi4wcHQiPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpja3Jhc2ljQGdvb2dsZS5jb20iIHRhcmdldD0i X2JsYW5rIj5ja3Jhc2ljQGdvb2dsZS5jb208L2E+Jm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICNFRUIyMTEgMS41cHQ7cGFkZGluZzoyLjBwdCI+ Jm5ic3A7JiM0MzsxDQogKDQwOCkgNDEyLTExNDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR03MB2708E5B2C2A8E43532E1447D87A20BN6PR03MB2708namp_-- From nobody Fri Nov 4 11:29:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FFD1295EE for ; Fri, 4 Nov 2016 11:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmKXvB9P6OW5 for ; Fri, 4 Nov 2016 11:29:37 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 96E0C129565 for ; Fri, 4 Nov 2016 11:29:37 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by linode64.ducksong.com (Postfix) with ESMTPSA id EE5593A051 for ; Fri, 4 Nov 2016 14:29:35 -0400 (EDT) Received: by mail-oi0-f48.google.com with SMTP id x4so175408432oix.2 for ; Fri, 04 Nov 2016 11:29:35 -0700 (PDT) X-Gm-Message-State: ABUngveQynjB29wrQQYoP1Fol+gM4xDJ+VwgjB+eQqtDvImnOWX9IEbAD+RXTO7iBrvzGzt4DAc5DjH4D8IyfA== X-Received: by 10.107.57.135 with SMTP id g129mr6549149ioa.178.1478284175487; Fri, 04 Nov 2016 11:29:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.84.71 with HTTP; Fri, 4 Nov 2016 11:29:34 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Fri, 4 Nov 2016 14:29:34 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Mike Bishop Content-Type: multipart/alternative; boundary=001a114ac3e2283ab905407ddba5 Archived-At: Cc: "quic@ietf.org" , Martin Thomson , Patrick McManus , Charles 'Buck' Krasic Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 18:29:39 -0000 --001a114ac3e2283ab905407ddba5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm thinking more along the lines of Mike -but I'm excited there is energy around this. Its definitely nice if we have a format that lends itself to a range of implementation choices and complexities. If I take martin's suggestion just a tad bit further, we might be able to spitball some designs as reworked id's of a 7541 update (i.e. add a 5th document, qpack, to the quic suite) and then see if it can be applied fairly succinctly to the quic-h2-mapping document.. On Fri, Nov 4, 2016 at 2:16 PM, Mike Bishop wrote: > This is certainly interesting, but feels more like a wise strategy for an > encoder to employ (if you want to avoid blocking, don=E2=80=99t reference= a header > that hasn=E2=80=99t been ACKed) than an independent change to the protoco= l. Think > about using, say, the unique-index-per-entry approach (which requires > blocking on unknown indices) =E2=80=93 an encoder that wanted to be smart= could do > as you describe below and emit literals until the frame has been ACK=E2= =80=99d. > (Unless the frame was going in the same packet as the original value, if = it > wants to be even smarter=E2=80=A6.) An encoder that didn=E2=80=99t want = the complexity > would just emit the most compact representation it could, knowing it migh= t > cause some blockage on the receiver. > > > > The two-streams-per-request feels jarring to me. For HTTP, at least, you > have a reasonably well-defined series of =E2=80=9CHeaders+, Body?, Header= s?=E2=80=9D in > each direction for each transaction. I don=E2=80=99t think you=E2=80=99l= l get rid of the > need to have some framing around the headers; I=E2=80=99m not convinced (= but > willing to be) that the complexity of managing two affiliated streams is > greater than that of needing framing around the body as well because it > shares a stream with the headers. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Charles 'Buck' > Krasic > *Sent:* Friday, November 4, 2016 10:28 AM > *To:* Martin Thomson > *Cc:* quic@ietf.org; Patrick McManus > *Subject:* Re: [QUIC] h2 mapping - hpack dynamic table by reference > > > > I have indeed been thinking about this very issue. Here is an outline of > what I've got so far. I think it's not so far from what others are > thinking. > > > > I call the new scheme QUIC HPACK (as opposed to HTTP/2 HPACK for status > quo). > > - Premise: certain indexed entries should be avoided, namely indexed > entries that would refer to entries that originate from headers *that > are still in flight*, because packet loss on those other headers would > HOL block the current stream. > - The idea of QUIC HPACK then is to mark updates to the dynamic table > as "pending" initially, and commit them later when the header they > originate from is no longer in flight (i.e. acked to sender). Indexe= d > entries would only be generated against dynamic tables entries that ar= e > committed. I.e., when encoding an entry, if there is a matching but > pending entry in the dynamic table, generate a literal instead of inde= xed. > > > - I have collected some data to measure the time between when entries > are added to the table, and the creation of subsequent indexed entr= ies that > refer to them. It suggests that a small fraction of HTTP/2 HPACK = indexed > entries (under standard HPACK) would become literals under QUIC HPA= CK. > ~50% are > 10s apart, and ~90% are > 50ms apart. > > > - the new behavior could be optional, individual HTTP/2 transactions > to select between this new scheme and the status quo, trading between > compression and HOL freedom. Status quo transactions would still use > stream 3 (HTTP/2 HPACK). > > Algorithm/design details: > > - instead using the shared headers stream (#3), each HTTP/2 > transaction has a dedicated stream for headers > > > - i.e. each HTTP/2 transaction has two QUIC streams: 1 for headers > (incl. trailers if used), 1 for body. > - 1 bit of the stream id will be used to classify the QUIC stream > as headers or body. > > > - like the current global header stream, these new headers streams > will protected from RSTs. > > > - *QUIC HPACK algorithm will process all headers, even if the > corresponding HTTP/2 transaction may have been cancelled and = corresponding > body stream RST*. > > > - QUIC HPACK encode and decode are divided into two phases each: > transmit and commit. > > > - in addition to the info already included in HTTP/2 header frames, > each header transmitted from encoder to decoder will include a pair= of > sequence numbers, the encode sequence number and the commit epoch, > described below. > > > - *the pair will always have the property that commit epoch < encode > sequence number.* > > > - first phase (transmit): header is encoded/decoded, but updates to > dynamic table are marked pending. > > > - when processing a header, the encoder will decide which entries > should be added to the dynamic table, as in current HPACK, but t= he entry in > the dynamic table will have a "pending" flag set, preventing it = from being > a reference for indexed entries yet. > - the encoder assigns a sequence number to each header (block), > the total number of headers encoded so far (encode epoch). > - the encoder/decoder enters each header into a commit sequencer > (ordered queue) to be used in the second phase. > - *the header is transmitted from encoder to decoder. the > decoder can always decode immediately, because this algorithm pr= events a > header from referring to other headers that might still be in fl= ight.* > > > - second phase (commit): once fully transmitted, pending updates are > committed, in the same order they were encoded. > > > - at encoder, when a previously transmitted header has been acked, the > entry in the commit-sequencer is marked committed. > > > - the front of the sequencer is popped while the front is a committed > entry. (loop) > - the commit epoch tracks the highest sequence number popped. > > > - at decoder, when a header is received, it will pop off the front of > the commit sequencer while its sequence number is <=3D the just = received > commit epoch (loop). > > > - each popped entry is marked committed. > - now the received header is decoded. > > > - a special case that is handled by the dynamic table in HTTP/2 HPACK > but I think needs to be treated differently for QUIC HPACK, that is= entries > that refer to other entries from the same header. For this I pro= pose to > define a new distinct table, and corresponding distinct entry types= , > "Intra". This would be an ephemeral per-header table that exists = only > during the transmit phase. > > > - *I don't have data yet for how many entries fall into this category.= * > > > > On Thu, Nov 3, 2016 at 5:54 PM, Martin Thomson > wrote: > > On 4 November 2016 at 08:29, Patrick McManus wrote= : > > this is a fairly significant bit of surgery to h2's formats, but given > that > > one of the real quic opportunities is to perform better under loss it > could > > be worthwhile to sever ordering dependencies even further. Seems like a > > reasonable thing to investigate to me. > > I agree. We risk negating much of the performance wins by creating > head-of-line blocking in header fields. With many resources, a lot of > the critical early interactions are entirely header fields, and hpack > is strictly serialized. > > Maybe this is a good time to raise the possibility that we might need > hpack modifications and that those modifications might benefit from a > new document. We split hpack out in h2, and it was a neat break that > we never regretted. > > > > > > -- > > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 > --001a114ac3e2283ab905407ddba5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm thinking more along the lines of Mike -b= ut I'm excited there is energy around this. Its definitely nice if we h= ave a format that lends itself to a range of implementation choices and com= plexities.

If I take martin's suggestion just a tad bit fu= rther, we might be able to spitball some designs as reworked id's of a = 7541 update (i.e. add a 5th document, qpack, to the quic suite) and then se= e if it can be applied fairly succinctly to the quic-h2-mapping document..<= br>


On Fri, Nov 4, 2016 at 2:16 PM, Mike Bishop <Michael.Bish= op@microsoft.com> wrote:

This is certainly interesting, but feels more like a= wise strategy for an encoder to employ (if you want to avoid blocking, don= =E2=80=99t reference a header that hasn=E2=80=99t been ACKed) than an indep= endent change to the protocol.=C2=A0 Think about using, say, the unique-index-per-entry approach (which requires blocking on unkno= wn indices) =E2=80=93 an encoder that wanted to be smart could do as you de= scribe below and emit literals until the frame has been ACK=E2=80=99d.=C2= =A0 (Unless the frame was going in the same packet as the original value, if it wants to be even smarter=E2=80=A6.)=C2=A0 An encoder= that didn=E2=80=99t want the complexity would just emit the most compact r= epresentation it could, knowing it might cause some blockage on the receive= r.

=C2=A0

The two-streams-per-request feels jarring to me.=C2= =A0 For HTTP, at least, you have a reasonably well-defined series of =E2=80= =9CHeaders+, Body?, Headers?=E2=80=9D in each direction for each transactio= n.=C2=A0 I don=E2=80=99t think you=E2=80=99ll get rid of the need to have s= ome framing around the headers; I=E2=80=99m not convinced (but willing to be) = that the complexity of managing two affiliated streams is greater than that= of needing framing around the body as well because it shares a stream with= the headers.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Charles 'Buck' Krasic
Sent: Friday, November 4, 2016 10:28 AM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: quic@ietf.org= ; Patrick McManus <pmcmanus@mozilla.com>
Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference=

=C2=A0

I have indeed been thinking about this very issue.= =C2=A0 Here is an outline of what I've got so far.=C2=A0 I think it'= ;s not so far from what others are thinking.

=C2=A0

I call the new scheme QUIC HPACK (as opposed to HTTP= /2 HPACK for status quo). =C2=A0=C2=A0

  • Premise: =C2=A0certain indexed entries should be avoided, namely indexed en= tries that would refer to entries that originate from headers that are still in flight, because packet loss on those other headers= would HOL block the current stream.
  • The idea of QUIC HPACK then is to mark updates to the dynamic table as &quo= t;pending" initially, and commit them later when the header they origi= nate from is no longer in flight (i.e. acked to sender). =C2=A0 Indexed ent= ries would only be generated against dynamic tables entries that are committed.=C2=A0 I.e., when encoding an entry, if there i= s a =C2=A0matching but pending entry in the dynamic table, generate a liter= al instead of indexed.
    • I have collected some data to measure the time between when entries are add= ed to the table, and the creation of subsequent indexed entries that refer = to them. =C2=A0 It suggests that a small fraction of HTTP/2 HPACK indexed e= ntries (under standard HPACK) would become literals under QUIC HPACK. =C2=A0=C2=A0~50% are > 10s apart, and ~90% a= re > 50ms apart.
  • the new behavior could be optional, individual HTTP/2 transactions to selec= t between this new scheme and the status quo, trading between compression a= nd HOL freedom. =C2=A0 Status quo transactions would still use stream 3 (HT= TP/2 HPACK).

Algorithm/design details:

  • instead using the shared headers stream (#3), each HTTP/2 transaction has a= dedicated stream for headers
    • i.e. each HTTP/2 transaction has two QUIC streams: 1 for headers (incl. tra= ilers if used), 1 for body.
    • 1 bit of the stream id will be used to classify the QUIC stream as headers = or body.
      • like the current global header stream, these new headers streams will prote= cted from RSTs.
        • QUIC HPACK algorithm will process all headers, even if the corresponding= HTTP/2 transaction may have been cancelled and corresponding body stream R= ST.
  • QUIC HPACK encode and decode are divided into two phases each: transmit and= commit. =C2=A0=C2=A0
    • in addition to the info already included in HTTP/2 header frames, each head= er transmitted from encoder to decoder will include a pair of sequence numb= ers, the encode sequence number and the commit epoch, described below.
      • =C2=A0the pair will always have the property that commit epoch < enco= de sequence number.
    • first phase (transmit): =C2=A0header is encoded/decoded, but updates to dyn= amic table are marked pending.
      • when processing a header, the encoder will decide which entries should be a= dded to the dynamic table, as in current HPACK, but the entry in the dynami= c table will have a "pending" flag set, preventing it from being = a reference for indexed entries yet.
      • the encoder assigns a sequence number to each header (block), the total num= ber of headers encoded so far (encode epoch).=C2=A0
      • the encoder/decoder enters each header into a commit sequencer (ordered que= ue) to be used in the second phase.
      • the header is transmitted from encoder to decoder. =C2=A0the decoder can= always decode immediately, because this algorithm prevents a header from r= eferring to other headers that might still be in flight.<= /li>
    • second phase (commit): =C2=A0once fully transmitted, =C2=A0pending updates = are committed, in the same order they were encoded.
      • at encoder, when a previously transmitted header has been acked, the entry = in the commit-sequencer is marked committed.
        • the front of the sequencer is popped while the front is a committed entry. = (loop)
        • the commit epoch tracks the highest sequence number popped.
      • at decoder, when a header is received, it will pop off the front of the com= mit sequencer while its sequence number is <=3D the just received commit= epoch (loop). =C2=A0
        • each popped entry is marked committed.
        • now the received header is decoded.
    • a special case that is handled by the dynamic table in HTTP/2 HPACK but I t= hink needs to be treated differently for QUIC HPACK, that is entries that r= efer to other entries from the same header. =C2=A0 =C2=A0For this I propose= to define a new distinct table, and corresponding distinct entry types, "Intra". =C2=A0 This would be an ephemeral= per-header table that exists only during the transmit phase.=
      • I don't have data yet for how many entries fall into this category.<= /i>

=C2=A0

On Thu, Nov 3, 2016 at 5:54 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:

On 4 November 2016 at= 08:29, Patrick McManus <pmcmanus@mozilla.com> wrote:
> this is a fairly significant bit of surgery to h2's formats, but g= iven that
> one of the real quic opportunities is to perform better under loss it = could
> be worthwhile to sever ordering dependencies even further. Seems like = a
> reasonable thing to investigate to me.

I agree.=C2=A0 We risk negating much of the performance wins by creating head-of-line blocking in header fields.=C2=A0 With many resources, a lot of=
the critical early interactions are entirely header fields, and hpack
is strictly serialized.

Maybe this is a good time to raise the possibility that we might need
hpack modifications and that those modifications might benefit from a
new document.=C2=A0 We split hpack out in h2, and it was a neat break that<= br> we never regretted.



=C2=A0

--

Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|ckrasic@goo= gle.com=C2=A0|=C2=A0+1 (408) 412-1141


--001a114ac3e2283ab905407ddba5-- From nobody Fri Nov 4 12:36:13 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC03129508 for ; Fri, 4 Nov 2016 12:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4pT65cURj9G for ; Fri, 4 Nov 2016 12:36:09 -0700 (PDT) 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 0E29F129463 for ; Fri, 4 Nov 2016 12:36:09 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id q124so3922924itd.1 for ; Fri, 04 Nov 2016 12:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TWAAHZV2Fljv2QUISuLd5/N1bch/iPIGQsbq8LlTXd0=; b=Imc9ZaL8bTbaSud3RvPOG/LpSWZhvOstjWpoPikp+FK4y6kkS62XnKPNsJVPYVUnxO SEXlQbtxuilMKtmiVM0EEypDETRqp7yIG/kuDR3pwmXF6MFSAOgW/dBxCRMa5i1hm3Ik Dv4W7njKgDaNtN15KOq2vsXytwl151ZkFvcksSKXDFgvnd1Ui+6GTp8IJ6kRLPE49w3m E9OJzroSmTqOw6aLnfvtCPceeKLylHP8F5OgIAhrJObaopZuQhhqe0xNwdi0HKzkaZEA DK8PrlTxprc/AoXQ8Y4i5ixxbGIMCGfchzgcYrpRE8L6ZjEmQH+RaA7Fjw6u2LvIujl7 O/Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TWAAHZV2Fljv2QUISuLd5/N1bch/iPIGQsbq8LlTXd0=; b=Eihxah7wPLHyuRVintjXTglrMM1gLVnMMyn8p5ZDjniXlY11kTh0QiP7rtwt8NjHxy uQuR3pMBcek06pnp4qb9xmAQT43OQdzdEsm22UsByAr5on4yGRfLJckbnoLRakls9ivX B4Kr7UtT9wIO5WgYgIMB9DXKh5JsnqvvLVmJWbaveMDLCLFmuqsHVKj2PjcAzw7xq4ol Ca00ydkAWY7sBFl1DT/vMmJ62pqVZw3HM5gc0jV5g3yDQG3dVXdky42jp1uIc2zVR5c+ IZtydg4yvBPQEWsGjja32avtwlbEhSEpY1H3XuIjVBVAWcuRp2yDCEGvqtn7SiU8v/J6 uxCQ== X-Gm-Message-State: ABUngve7jDPflGxHnq24r+oCqSE4DhYi0I3EAco+Fw5mNoJVcTldxyLQRdUI1fC7MIS9PQnmyMQFWpo8Nn/Fx7N2 X-Received: by 10.36.178.81 with SMTP id h17mr14500iti.98.1478288168091; Fri, 04 Nov 2016 12:36:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.1.2 with HTTP; Fri, 4 Nov 2016 12:35:47 -0700 (PDT) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Fri, 4 Nov 2016 12:35:47 -0700 Message-ID: To: Mike Bishop Content-Type: multipart/alternative; boundary=f403045d96ae22ce6905407ec9e5 Archived-At: Cc: "quic@ietf.org" , Martin Thomson , Patrick McManus Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 19:36:12 -0000 --f403045d96ae22ce6905407ec9e5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 4, 2016 at 11:16 AM, Mike Bishop wrote: > This is certainly interesting, but feels more like a wise strategy for an > encoder to employ (if you want to avoid blocking, don=E2=80=99t reference= a header > that hasn=E2=80=99t been ACKed) than an independent change to the protoco= l. > I'd be happy if it could be done with just encoder strategy, but I don't think it can. Hence the extra sequence numbers sent, and the modified logic at the decoder. That said, I have definitely trying to make the delta as small and sharply focused on HOL as possible. Think about using, say, the unique-index-per-entry approach (which requires > blocking on unknown indices) =E2=80=93 an encoder that wanted to be smart= could do > as you describe below and emit literals until the frame has been ACK=E2= =80=99d. > (Unless the frame was going in the same packet as the original value, if = it > wants to be even smarter=E2=80=A6.) > The same packet as original value is interesting, but I think possibly super hard. There's a circular dependency of estimating the compressed header size as part of knowing whether they will go in the same packet, in order decide on representation strategy that will turn effect compressed header size. Maybe alternative, more or less crazy, approach would be use some combination of pseudo requests/pushes to prime the dictionary? > An encoder that didn=E2=80=99t want the complexity would just emit the mo= st > compact representation it could, knowing it might cause some blockage on > the receiver. > That's what I was saying wrt "status quo transactions". just sticking with the current headers over stream 3 would allow for the prefers more compact representation option. > > The two-streams-per-request feels jarring to me. For HTTP, at least, you > have a reasonably well-defined series of =E2=80=9CHeaders+, Body?, Header= s?=E2=80=9D in > each direction for each transaction. I don=E2=80=99t think you=E2=80=99l= l get rid of the > need to have some framing around the headers; I=E2=80=99m not convinced (= but > willing to be) that the complexity of managing two affiliated streams is > greater than that of needing framing around the body as well because it > shares a stream with the headers. > Right. Our QUIC implementation does layer HTTP/2 HEADER frames above QUIC STREAM frames. That would be true in this design also. However, the status quo does allow the body data to be sent without any extra framing above QUIC STREAM frames. I didn't see an obvious way not to lose that latter property if headers and body are in the same stream. > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Charles 'Buck' > Krasic > *Sent:* Friday, November 4, 2016 10:28 AM > *To:* Martin Thomson > *Cc:* quic@ietf.org; Patrick McManus > *Subject:* Re: [QUIC] h2 mapping - hpack dynamic table by reference > > > > I have indeed been thinking about this very issue. Here is an outline of > what I've got so far. I think it's not so far from what others are > thinking. > > > > I call the new scheme QUIC HPACK (as opposed to HTTP/2 HPACK for status > quo). > > - Premise: certain indexed entries should be avoided, namely indexed > entries that would refer to entries that originate from headers *that > are still in flight*, because packet loss on those other headers would > HOL block the current stream. > - The idea of QUIC HPACK then is to mark updates to the dynamic table > as "pending" initially, and commit them later when the header they > originate from is no longer in flight (i.e. acked to sender). Indexe= d > entries would only be generated against dynamic tables entries that ar= e > committed. I.e., when encoding an entry, if there is a matching but > pending entry in the dynamic table, generate a literal instead of inde= xed. > > > - I have collected some data to measure the time between when entries > are added to the table, and the creation of subsequent indexed entr= ies that > refer to them. It suggests that a small fraction of HTTP/2 HPACK = indexed > entries (under standard HPACK) would become literals under QUIC HPA= CK. > ~50% are > 10s apart, and ~90% are > 50ms apart. > > > - the new behavior could be optional, individual HTTP/2 transactions > to select between this new scheme and the status quo, trading between > compression and HOL freedom. Status quo transactions would still use > stream 3 (HTTP/2 HPACK). > > Algorithm/design details: > > - instead using the shared headers stream (#3), each HTTP/2 > transaction has a dedicated stream for headers > > > - i.e. each HTTP/2 transaction has two QUIC streams: 1 for headers > (incl. trailers if used), 1 for body. > - 1 bit of the stream id will be used to classify the QUIC stream > as headers or body. > > > - like the current global header stream, these new headers streams > will protected from RSTs. > > > - *QUIC HPACK algorithm will process all headers, even if the > corresponding HTTP/2 transaction may have been cancelled and = corresponding > body stream RST*. > > > - QUIC HPACK encode and decode are divided into two phases each: > transmit and commit. > > > - in addition to the info already included in HTTP/2 header frames, > each header transmitted from encoder to decoder will include a pair= of > sequence numbers, the encode sequence number and the commit epoch, > described below. > > > - *the pair will always have the property that commit epoch < encode > sequence number.* > > > - first phase (transmit): header is encoded/decoded, but updates to > dynamic table are marked pending. > > > - when processing a header, the encoder will decide which entries > should be added to the dynamic table, as in current HPACK, but t= he entry in > the dynamic table will have a "pending" flag set, preventing it = from being > a reference for indexed entries yet. > - the encoder assigns a sequence number to each header (block), > the total number of headers encoded so far (encode epoch). > - the encoder/decoder enters each header into a commit sequencer > (ordered queue) to be used in the second phase. > - *the header is transmitted from encoder to decoder. the > decoder can always decode immediately, because this algorithm pr= events a > header from referring to other headers that might still be in fl= ight.* > > > - second phase (commit): once fully transmitted, pending updates are > committed, in the same order they were encoded. > > > - at encoder, when a previously transmitted header has been acked, the > entry in the commit-sequencer is marked committed. > > > - the front of the sequencer is popped while the front is a committed > entry. (loop) > - the commit epoch tracks the highest sequence number popped. > > > - at decoder, when a header is received, it will pop off the front of > the commit sequencer while its sequence number is <=3D the just = received > commit epoch (loop). > > > - each popped entry is marked committed. > - now the received header is decoded. > > > - a special case that is handled by the dynamic table in HTTP/2 HPACK > but I think needs to be treated differently for QUIC HPACK, that is= entries > that refer to other entries from the same header. For this I pro= pose to > define a new distinct table, and corresponding distinct entry types= , > "Intra". This would be an ephemeral per-header table that exists = only > during the transmit phase. > > > - *I don't have data yet for how many entries fall into this category.= * > > > > On Thu, Nov 3, 2016 at 5:54 PM, Martin Thomson > wrote: > > On 4 November 2016 at 08:29, Patrick McManus wrote= : > > this is a fairly significant bit of surgery to h2's formats, but given > that > > one of the real quic opportunities is to perform better under loss it > could > > be worthwhile to sever ordering dependencies even further. Seems like a > > reasonable thing to investigate to me. > > I agree. We risk negating much of the performance wins by creating > head-of-line blocking in header fields. With many resources, a lot of > the critical early interactions are entirely header fields, and hpack > is strictly serialized. > > Maybe this is a good time to raise the possibility that we might need > hpack modifications and that those modifications might benefit from a > new document. We split hpack out in h2, and it was a neat break that > we never regretted. > > > > > > -- > > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --f403045d96ae22ce6905407ec9e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 4, 2016 at 11:16 AM, Mike Bishop <Michael.Bisho= p@microsoft.com> wrote:

This is certainly interesting, but feels more like a= wise strategy for an encoder to employ (if you want to avoid blocking, don= =E2=80=99t reference a header that hasn=E2=80=99t been ACKed) than an indep= endent change to the protocol.=C2=A0

=C2= =A0
I'd be happy if it could be done with just encoder st= rategy, but I don't think it can. =C2=A0 Hence the extra sequence numbe= rs sent, and the modified logic at the decoder. =C2=A0 =C2=A0That said, I h= ave definitely trying to make the delta as small and sharply focused on HOL= as possible.

Think about using, say, the unique-index-per-entry approach (which requires blocking on unkno= wn indices) =E2=80=93 an encoder that wanted to be smart could do as you de= scribe below and emit literals until the frame has been ACK=E2=80=99d.=C2= =A0 (Unless the frame was going in the same packet as the original value, if it wants to be even smarter=E2=80=A6.)=C2=A0

<= /div>

The same packet as original value is = interesting, but I think possibly super hard.=C2=A0 There's a circular = dependency of estimating the compressed header size as part of knowing whet= her they will go in the same packet, in order decide on representation stra= tegy that will turn effect compressed header size.

Maybe alternative, more or less crazy, approach would be use some combinat= ion of pseudo requests/pushes to prime the dictionary?
=C2=A0

An encoder that didn=E2=80=99t want the complexity would just emit = the most compact representation it could, knowing it might cause some block= age on the receiver.


That&#= 39;s what I was saying wrt "status quo transactions".
<= br>




<= br>




<= br>




<= br>




<= br>




<= br>




<= br>




<= br>




<= br>
just sticking with the current headers over stream 3 would al= low for the prefers more compact representation option.=C2=A0

=C2=A0

The two-streams-per-request feels jarring to me.=C2= =A0 For HTTP, at least, you have a reasonably well-defined series of =E2=80= =9CHeaders+, Body?, Headers?=E2=80=9D in each direction for each transactio= n.=C2=A0 I don=E2=80=99t think you=E2=80=99ll get rid of the need to have s= ome framing around the headers; I=E2=80=99m not convinced (but willing to be) = that the complexity of managing two affiliated streams is greater than that= of needing framing around the body as well because it shares a stream with= the headers.


Right.=C2=A0 = Our QUIC implementation does layer HTTP/2 HEADER frames above QUIC STREAM f= rames.=C2=A0 That would be true in this design also.=C2=A0 However, the sta= tus quo does allow the body data to be sent without any extra framing above= QUIC STREAM frames.=C2=A0 I didn't see an obvious way not to lose that= latter property if headers and body are in the same stream. =C2=A0=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Charles 'Buck' Krasic
Sent: Friday, November 4, 2016 10:28 AM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: quic@ietf.org= ; Patrick McManus <pmcmanus@mozilla.com>
Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference=

=C2=A0

I have indeed been thinking about this very issue.= =C2=A0 Here is an outline of what I've got so far.=C2=A0 I think it'= ;s not so far from what others are thinking.

=C2=A0

I call the new scheme QUIC HPACK (as opposed to HTTP= /2 HPACK for status quo). =C2=A0=C2=A0

  • Premise: =C2=A0certain indexed entries should be avoided, namely indexed en= tries that would refer to entries that originate from headers that are still in flight, because packet loss on those other headers= would HOL block the current stream.
  • The idea of QUIC HPACK then is to mark updates to the dynamic table as &quo= t;pending" initially, and commit them later when the header they origi= nate from is no longer in flight (i.e. acked to sender). =C2=A0 Indexed ent= ries would only be generated against dynamic tables entries that are committed.=C2=A0 I.e., when encoding an entry, if there i= s a =C2=A0matching but pending entry in the dynamic table, generate a liter= al instead of indexed.
    • I have collected some data to measure the time between when entries are add= ed to the table, and the creation of subsequent indexed entries that refer = to them. =C2=A0 It suggests that a small fraction of HTTP/2 HPACK indexed e= ntries (under standard HPACK) would become literals under QUIC HPACK. =C2=A0=C2=A0~50% are > 10s apart, and ~90% a= re > 50ms apart.
  • the new behavior could be optional, individual HTTP/2 transactions to selec= t between this new scheme and the status quo, trading between compression a= nd HOL freedom. =C2=A0 Status quo transactions would still use stream 3 (HT= TP/2 HPACK).

Algorithm/design details:

  • instead using the shared headers stream (#3), each HTTP/2 transaction has a= dedicated stream for headers
    • i.e. each HTTP/2 transaction has two QUIC streams: 1 for headers (incl. tra= ilers if used), 1 for body.
    • 1 bit of the stream id will be used to classify the QUIC stream as headers = or body.
      • like the current global header stream, these new headers streams will prote= cted from RSTs.
        • QUIC HPACK algorithm will process all headers, even if the corresponding= HTTP/2 transaction may have been cancelled and corresponding body stream R= ST.
  • QUIC HPACK encode and decode are divided into two phases each: transmit and= commit. =C2=A0=C2=A0
    • in addition to the info already included in HTTP/2 header frames, each head= er transmitted from encoder to decoder will include a pair of sequence numb= ers, the encode sequence number and the commit epoch, described below.
      • =C2=A0the pair will always have the property that commit epoch < enco= de sequence number.
    • first phase (transmit): =C2=A0header is encoded/decoded, but updates to dyn= amic table are marked pending.
      • when processing a header, the encoder will decide which entries should be a= dded to the dynamic table, as in current HPACK, but the entry in the dynami= c table will have a "pending" flag set, preventing it from being = a reference for indexed entries yet.
      • the encoder assigns a sequence number to each header (block), the total num= ber of headers encoded so far (encode epoch).=C2=A0
      • the encoder/decoder enters each header into a commit sequencer (ordered que= ue) to be used in the second phase.
      • the header is transmitted from encoder to decoder. =C2=A0the decoder can= always decode immediately, because this algorithm prevents a header from r= eferring to other headers that might still be in flight.<= /li>
    • second phase (commit): =C2=A0once fully transmitted, =C2=A0pending updates = are committed, in the same order they were encoded.
      • at encoder, when a previously transmitted header has been acked, the entry = in the commit-sequencer is marked committed.
        • the front of the sequencer is popped while the front is a committed entry. = (loop)
        • the commit epoch tracks the highest sequence number popped.
      • at decoder, when a header is received, it will pop off the front of the com= mit sequencer while its sequence number is <=3D the just received commit= epoch (loop). =C2=A0
        • each popped entry is marked committed.
        • now the received header is decoded.
    • a special case that is handled by the dynamic table in HTTP/2 HPACK but I t= hink needs to be treated differently for QUIC HPACK, that is entries that r= efer to other entries from the same header. =C2=A0 =C2=A0For this I propose= to define a new distinct table, and corresponding distinct entry types, "Intra". =C2=A0 This would be an ephemeral= per-header table that exists only during the transmit phase.=
      • I don't have data yet for how many entries fall into this category.<= /i>

=C2=A0

On Thu, Nov 3, 2016 at 5:54 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:

On 4 November 2016 at= 08:29, Patrick McManus <pmcmanus@mozilla.com> wrote:
> this is a fairly significant bit of surgery to h2's formats, but g= iven that
> one of the real quic opportunities is to perform better under loss it = could
> be worthwhile to sever ordering dependencies even further. Seems like = a
> reasonable thing to investigate to me.

I agree.=C2=A0 We risk negating much of the performance wins by creating head-of-line blocking in header fields.=C2=A0 With many resources, a lot of=
the critical early interactions are entirely header fields, and hpack
is strictly serialized.

Maybe this is a good time to raise the possibility that we might need
hpack modifications and that those modifications might benefit from a
new document.=C2=A0 We split hpack out in h2, and it was a neat break that<= br> we never regretted.



=C2=A0

--

Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|ckrasic@goo= gle.com=C2=A0|=C2=A0+1 = (408) 412-1141




--
Charles '= ;Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141

--f403045d96ae22ce6905407ec9e5-- From nobody Fri Nov 4 14:01:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AA7F129687 for ; Fri, 4 Nov 2016 14:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9ii4Wwljvpm for ; Fri, 4 Nov 2016 14:01:19 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id BF2F512968C for ; Fri, 4 Nov 2016 14:01:18 -0700 (PDT) Received: from mail-it0-f45.google.com (mail-it0-f45.google.com [209.85.214.45]) by linode64.ducksong.com (Postfix) with ESMTPSA id 0B2BD3A015 for ; Fri, 4 Nov 2016 17:01:18 -0400 (EDT) Received: by mail-it0-f45.google.com with SMTP id e187so6334085itc.0 for ; Fri, 04 Nov 2016 14:01:18 -0700 (PDT) X-Gm-Message-State: ABUngveqv7uQWapVsCbC2ga2PM3PMQpRC9MTzJclmC967i1q7Mfl+QeyIMD/C2j9TUq/2iiq/xCbIMAmwyakFw== X-Received: by 10.107.57.135 with SMTP id g129mr7166952ioa.178.1478293277608; Fri, 04 Nov 2016 14:01:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.84.71 with HTTP; Fri, 4 Nov 2016 14:01:17 -0700 (PDT) From: Patrick McManus Date: Fri, 4 Nov 2016 17:01:17 -0400 X-Gmail-Original-Message-ID: Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114ac3e2af982705407ff92a Archived-At: Subject: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 21:01:21 -0000 --001a114ac3e2af982705407ff92a Content-Type: text/plain; charset=UTF-8 Hi All - two more things to raise.. one I hope editorial and one design - when we start doing github, I'll open issues to track there. First, editorially draft-hamilton-quic-transport-protocol-01 generally refers to packet numbers instead of sequence numbers. There seem to be two exceptions to that - in 6.2 and the identifier SEQUENCE_NUMBER_LIMIT_REACHED. OTOH https://tools.ietf.org/html/draft-thomson-quic-tls-01 almost always refers to sequence numbers (with one exception). I think SN is not defined, but PN is and it should standardize on the PN language. Second, draft-hamilton-quic-transport-protocol-01 boldly uses little endian encoding. Ya gotta admire that chutzpah in an IETF draft :) From a processor alignment pov, it makes perfect sense and I would support it on a clean slate or on a well layered protocol. quic however, by design, is neither of those things. So we get into a bit of a mess - the packet number is little endian when it appears in transport fields, but in the TLS document the AEAD nonce is formed by padding the big endian representation of the same number. That smells like a bug waiting to happen. Likewise a Stream ID in a transport STREAM frame would be big endian, but when that same ID is encoded via 7540 rules from the h2-mapping document (e.g. in a PUSH_PROMISE) then it needs to be big endian. Again - seems like a footgun. So while I salute the valiant effort to go little endian, I think we ought to bow to the constraints this effort faces and go the traditional all network byte order path. -Patrick --001a114ac3e2af982705407ff92a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All - two more things to raise.. one I h= ope editorial and one design - when we start doing github, I'll open is= sues to track there.

First, editorially draft-hamilton-quic-tr= ansport-protocol-01 generally refers to packet numbers instead of sequence = numbers. There seem to be two exceptions to that - in 6.2 and the identifie= r SEQUENCE_NUMBER_LIMIT_REACHED. OTOH https://tools.ietf.org/html/draft-thomson-quic= -tls-01 almost always refers to sequence numbers (with one exception). = I think SN is not defined, but PN is and it should standardize on the PN la= nguage.

Second, draft-hamilton-quic-transport-protocol-01 bold= ly uses little endian encoding. Ya gotta admire that chutzpah in an IETF dr= aft :) From a processor alignment pov, it makes perfect sense and I would s= upport it on a clean slate or on a well layered protocol. quic however, by = design, is neither of those things.

So we get into a bit of a mess -= the packet number is little endian when it appears in transport fields, bu= t in the TLS document the AEAD nonce is formed by padding the big endian re= presentation of the same number. That smells like a bug waiting to happen. = Likewise a Stream ID in a transport STREAM frame would be big endian, but w= hen that same ID is encoded via 7540 rules from the h2-mapping document (e.= g. in a PUSH_PROMISE) then it needs to be big endian. Again - seems like a = footgun. So while I salute the valiant effort to go little endian, I think = we ought to bow to the constraints this effort faces and go the traditional= all network byte order path.

-Patrick



--001a114ac3e2af982705407ff92a-- From nobody Fri Nov 4 16:20:44 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFD2129413 for ; Fri, 4 Nov 2016 16:20:41 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jSlI4qUXEBb for ; Fri, 4 Nov 2016 16:20:38 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0136.outbound.protection.outlook.com [104.47.38.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 6A72012986E for ; Fri, 4 Nov 2016 16:20:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0ExXF3gCFl+Zg66bIZvG3yWJ37G/v2JvW/fzwvvnb7c=; b=RJ96abj+jO73qiASQl/cx5yW629wld37kjCnMRrOhOj8HdyhVE8Z9rOvjecitPBebFkCj7bOla/Y+/cUNqLCoBm4blCvVfkOPrCcfnuuEk9iIwvyW4VXFDuJpl/Q/HIf8xUjTypFBANRcZHFvtrrNyHVE2yyk67CYzKct02UNSI= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Fri, 4 Nov 2016 23:20:35 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0693.016; Fri, 4 Nov 2016 23:20:35 +0000 From: Mike Bishop To: Charles 'Buck' Krasic Thread-Topic: [QUIC] h2 mapping - hpack dynamic table by reference Thread-Index: AQHSNhlXVDFlp6NaHU6EWkOyW4vQq6DH/7UAgAEVywCAAAX4YIAAHZ2AgAAxT9A= Date: Fri, 4 Nov 2016 23:20:35 +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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:2::ef] x-ms-office365-filtering-correlation-id: f1a2bc32-4fd1-406b-4cf2-08d405092e46 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:o/oYGO3nEQjOGTaQ3DbsUtJelZvvZ6xJpbrIADljfas37Q/EeJbLGlN7r4qBctBzawiPv6gvDax5/UhWf2iZXZ9KUe+xnGLKZ2WCovxZVp/5c3B6fVm7gtbAeHEu4MBh+Qb5Ztpfb9EXBiG4vs7sv2M7KhgPOhw3PlJHWTdb3E86A1up9SGyBg6rJdY5bF6KoppvH/DV1Rvz7JTFH3WBm/Sck1wKQ5+JEqloB6iu8RA/xa1D+6pio2umaER/T+7fmLohRw2SQFkmKzpvp2q0+z6YQJ0zadh9B9UT7ubzH4WXXbMtUgVAmGtYzZLtiQsZygmQh/K9OLktsMNmMk4QYFzrsljyd/ESeCy+dAuj4PIH1328uMuSxyHhdDyE69qh x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2705; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060229)(6040176)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6046074)(6061226); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 01165471DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(189002)(24454002)(106116001)(16236675004)(6916009)(106356001)(93886004)(99286002)(2950100002)(76576001)(5002640100001)(19609705001)(7696004)(790700001)(586003)(6116002)(102836003)(4326007)(2906002)(86362001)(110136003)(5660300001)(86612001)(87936001)(105586002)(101416001)(11100500001)(122556002)(19625215002)(189998001)(50986999)(97736004)(76176999)(54356999)(10290500002)(92566002)(5005710100001)(8990500004)(8936002)(10400500002)(77096005)(9686002)(10090500001)(68736007)(2900100001)(33656002)(15975445007)(551934003)(19580395003)(3660700001)(19580405001)(3280700002)(74316002)(19300405004)(7846002)(81156014)(81166006)(8676002)(7736002)(569005); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708E83F77D3456A26256ADF87A20BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2016 23:20:35.2994 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: "quic@ietf.org" , Martin Thomson , Patrick McManus Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 04 Nov 2016 23:20:42 -0000 --_000_BN6PR03MB2708E83F77D3456A26256ADF87A20BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2gsIGdyYW50ZWQgdGhhdCBpdOKAmXMgbm90IHN1ZmZpY2llbnQgdG8gY2FsbCBpdCBhbiBlbmNv ZGVyIHN0cmF0ZWd5IGFuZCBqdXN0IGtlZXAgdXNpbmcgSFBBQ0suICBJ4oCZbSBqdXN0IG1ha2lu ZyB0aGUgYXJndW1lbnQgdGhhdCBpdCBuZWVkIG5vdCBiZSB0aGUgYmFzaXMgb2YgdGhlIHByb3Rv Y29sIGRlc2lnbiDigJMgdGhlIHByb3RvY29sIGNhbiBlbmFibGUgYW4gZW5jb2RlciB0aGF0IHdh bnRzIHRvIGRvIHN1Y2ggYSBzdHJhdGVneSB0byBkbyBzbyB3aXRob3V0IG1hbmRhdGluZyBpdC4g IEkgcmVhbGx5IGRvbuKAmXQgd2FudCBhIGR1YWwgSFBBQ0stYW5kLVFQQUNLIGFwcHJvYWNoIOKA kyBtYXliZSB3ZSBjYW4gZGVmaW5lIGEgbGVnYWN5IHZlcnNpb24gd2hlcmUgSFBBQ0sgb24gc3Ry ZWFtIDMgaXMgdXNlZCwgYnV0IGF0IHdvcnN0IGNhc2UsIHlvdSBzaG91bGQgc2VsZWN0IGFuZCBj b21taXQgdG8gb25lIGZvciBhIGNvbm5lY3Rpb24uDQoNCkkgYWxzbyBhZ3JlZSB0aGF0IGp1ZGdp bmcgd2hldGhlciB5b3XigJlsbCBiZSB3aXRoaW4gdGhlIHNhbWUgcGFja2V0IGNvdWxkIGxlYWQg dG8gbG9vcHMuICBQZXJoYXBzIGJldHRlciBsZWZ0IGFsb25lIGZvciBtb3N0IGltcGxlbWVudGF0 aW9ucywgdGhhdOKAmXMgZmFpci4NCg0KVGhlIHRoaW5nIHRoYXQgc3RyaWtlcyBtZSBpcyB0aGF0 IHRoZSBIVFRQLzIgZnJhbWluZyBsYXllciBpcyBlc3NlbnRpYWxseSBtZXNzYWdlLWJhc2VkIChm cmFtZXMpLCB3aGlsZSBmcm9tIHRoZSBhcHBsaWNhdGlvbiBsYXllciwgUVVJQyBpcyBwdXJlbHkg c3RyZWFtLWJhc2VkLiAgSeKAmW0gdGhpbmtpbmcgdGhhdCBmb3IgSFRUUC1vdmVyLVFVSUMsIHdl IGRlZmluZSBhIGxpZ2h0LXdlaWdodCBmcmFtaW5nIHRvIGRpZmZlcmVudGlhdGUgaGVhZGVycyBm cm9tIGJvZHkgYW5kIG1vdmUgdGhlIGhlYWRlcnMgYmFjayBvbi1zdHJlYW0sIGlmIHdlIGNhbi4g IE1heWJlIGp1c3QgYSBjb3VwbGUgYnl0ZXMgb2YgdHlwZSBpZGVudGlmaWNhdGlvbiwgbGVuZ3Ro LCBhbmQgZW5vdWdoIGNvbnRleHQgdG8gZGlmZmVyZW50aWF0ZSBpbnRlcm1lZGlhdGUgaGVhZGVy IGJsb2NrcyBmcm9tIGZpbmFsIHJlc3BvbnNlIGhlYWRlcnMgZnJvbSBib2R5IGZyb20gdHJhaWxl cnPigKY/ICBQVVNIX1BST01JU0UgcHJvYmFibHkgbGl2ZXMgaGVyZSwgdG9vLg0KDQpGcm9tOiBD aGFybGVzICdCdWNrJyBLcmFzaWMgW21haWx0bzpja3Jhc2ljQGdvb2dsZS5jb21dDQpTZW50OiBG cmlkYXksIE5vdmVtYmVyIDQsIDIwMTYgMTI6MzYgUE0NClRvOiBNaWtlIEJpc2hvcCA8TWljaGFl bC5CaXNob3BAbWljcm9zb2Z0LmNvbT4NCkNjOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21z b25AZ21haWwuY29tPjsgcXVpY0BpZXRmLm9yZzsgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Bt b3ppbGxhLmNvbT4NClN1YmplY3Q6IFJlOiBbUVVJQ10gaDIgbWFwcGluZyAtIGhwYWNrIGR5bmFt aWMgdGFibGUgYnkgcmVmZXJlbmNlDQoNCg0KDQpPbiBGcmksIE5vdiA0LCAyMDE2IGF0IDExOjE2 IEFNLCBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWlj aGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KVGhpcyBpcyBjZXJ0YWlubHkgaW50 ZXJlc3RpbmcsIGJ1dCBmZWVscyBtb3JlIGxpa2UgYSB3aXNlIHN0cmF0ZWd5IGZvciBhbiBlbmNv ZGVyIHRvIGVtcGxveSAoaWYgeW91IHdhbnQgdG8gYXZvaWQgYmxvY2tpbmcsIGRvbuKAmXQgcmVm ZXJlbmNlIGEgaGVhZGVyIHRoYXQgaGFzbuKAmXQgYmVlbiBBQ0tlZCkgdGhhbiBhbiBpbmRlcGVu ZGVudCBjaGFuZ2UgdG8gdGhlIHByb3RvY29sLg0KDQpJJ2QgYmUgaGFwcHkgaWYgaXQgY291bGQg YmUgZG9uZSB3aXRoIGp1c3QgZW5jb2RlciBzdHJhdGVneSwgYnV0IEkgZG9uJ3QgdGhpbmsgaXQg Y2FuLiAgIEhlbmNlIHRoZSBleHRyYSBzZXF1ZW5jZSBudW1iZXJzIHNlbnQsIGFuZCB0aGUgbW9k aWZpZWQgbG9naWMgYXQgdGhlIGRlY29kZXIuICAgIFRoYXQgc2FpZCwgSSBoYXZlIGRlZmluaXRl bHkgdHJ5aW5nIHRvIG1ha2UgdGhlIGRlbHRhIGFzIHNtYWxsIGFuZCBzaGFycGx5IGZvY3VzZWQg b24gSE9MIGFzIHBvc3NpYmxlLg0KDQpUaGluayBhYm91dCB1c2luZywgc2F5LCB0aGUgdW5pcXVl LWluZGV4LXBlci1lbnRyeSBhcHByb2FjaCAod2hpY2ggcmVxdWlyZXMgYmxvY2tpbmcgb24gdW5r bm93biBpbmRpY2VzKSDigJMgYW4gZW5jb2RlciB0aGF0IHdhbnRlZCB0byBiZSBzbWFydCBjb3Vs ZCBkbyBhcyB5b3UgZGVzY3JpYmUgYmVsb3cgYW5kIGVtaXQgbGl0ZXJhbHMgdW50aWwgdGhlIGZy YW1lIGhhcyBiZWVuIEFDS+KAmWQuICAoVW5sZXNzIHRoZSBmcmFtZSB3YXMgZ29pbmcgaW4gdGhl IHNhbWUgcGFja2V0IGFzIHRoZSBvcmlnaW5hbCB2YWx1ZSwgaWYgaXQgd2FudHMgdG8gYmUgZXZl biBzbWFydGVy4oCmLikNCg0KVGhlIHNhbWUgcGFja2V0IGFzIG9yaWdpbmFsIHZhbHVlIGlzIGlu dGVyZXN0aW5nLCBidXQgSSB0aGluayBwb3NzaWJseSBzdXBlciBoYXJkLiAgVGhlcmUncyBhIGNp cmN1bGFyIGRlcGVuZGVuY3kgb2YgZXN0aW1hdGluZyB0aGUgY29tcHJlc3NlZCBoZWFkZXIgc2l6 ZSBhcyBwYXJ0IG9mIGtub3dpbmcgd2hldGhlciB0aGV5IHdpbGwgZ28gaW4gdGhlIHNhbWUgcGFj a2V0LCBpbiBvcmRlciBkZWNpZGUgb24gcmVwcmVzZW50YXRpb24gc3RyYXRlZ3kgdGhhdCB3aWxs IHR1cm4gZWZmZWN0IGNvbXByZXNzZWQgaGVhZGVyIHNpemUuDQoNCk1heWJlIGFsdGVybmF0aXZl LCBtb3JlIG9yIGxlc3MgY3JhenksIGFwcHJvYWNoIHdvdWxkIGJlIHVzZSBzb21lIGNvbWJpbmF0 aW9uIG9mIHBzZXVkbyByZXF1ZXN0cy9wdXNoZXMgdG8gcHJpbWUgdGhlIGRpY3Rpb25hcnk/DQoN CkFuIGVuY29kZXIgdGhhdCBkaWRu4oCZdCB3YW50IHRoZSBjb21wbGV4aXR5IHdvdWxkIGp1c3Qg ZW1pdCB0aGUgbW9zdCBjb21wYWN0IHJlcHJlc2VudGF0aW9uIGl0IGNvdWxkLCBrbm93aW5nIGl0 IG1pZ2h0IGNhdXNlIHNvbWUgYmxvY2thZ2Ugb24gdGhlIHJlY2VpdmVyLg0KDQpUaGF0J3Mgd2hh dCBJIHdhcyBzYXlpbmcgd3J0ICJzdGF0dXMgcXVvIHRyYW5zYWN0aW9ucyIuDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KanVzdCBzdGlja2luZyB3aXRoIHRoZSBjdXJyZW50IGhlYWRlcnMgb3Zl ciBzdHJlYW0gMyB3b3VsZCBhbGxvdyBmb3IgdGhlIHByZWZlcnMgbW9yZSBjb21wYWN0IHJlcHJl c2VudGF0aW9uIG9wdGlvbi4NCg0KDQpUaGUgdHdvLXN0cmVhbXMtcGVyLXJlcXVlc3QgZmVlbHMg amFycmluZyB0byBtZS4gIEZvciBIVFRQLCBhdCBsZWFzdCwgeW91IGhhdmUgYSByZWFzb25hYmx5 IHdlbGwtZGVmaW5lZCBzZXJpZXMgb2Yg4oCcSGVhZGVycyssIEJvZHk/LCBIZWFkZXJzP+KAnSBp biBlYWNoIGRpcmVjdGlvbiBmb3IgZWFjaCB0cmFuc2FjdGlvbi4gIEkgZG9u4oCZdCB0aGluayB5 b3XigJlsbCBnZXQgcmlkIG9mIHRoZSBuZWVkIHRvIGhhdmUgc29tZSBmcmFtaW5nIGFyb3VuZCB0 aGUgaGVhZGVyczsgSeKAmW0gbm90IGNvbnZpbmNlZCAoYnV0IHdpbGxpbmcgdG8gYmUpIHRoYXQg dGhlIGNvbXBsZXhpdHkgb2YgbWFuYWdpbmcgdHdvIGFmZmlsaWF0ZWQgc3RyZWFtcyBpcyBncmVh dGVyIHRoYW4gdGhhdCBvZiBuZWVkaW5nIGZyYW1pbmcgYXJvdW5kIHRoZSBib2R5IGFzIHdlbGwg YmVjYXVzZSBpdCBzaGFyZXMgYSBzdHJlYW0gd2l0aCB0aGUgaGVhZGVycy4NCg0KUmlnaHQuICBP dXIgUVVJQyBpbXBsZW1lbnRhdGlvbiBkb2VzIGxheWVyIEhUVFAvMiBIRUFERVIgZnJhbWVzIGFi b3ZlIFFVSUMgU1RSRUFNIGZyYW1lcy4gIFRoYXQgd291bGQgYmUgdHJ1ZSBpbiB0aGlzIGRlc2ln biBhbHNvLiAgSG93ZXZlciwgdGhlIHN0YXR1cyBxdW8gZG9lcyBhbGxvdyB0aGUgYm9keSBkYXRh IHRvIGJlIHNlbnQgd2l0aG91dCBhbnkgZXh0cmEgZnJhbWluZyBhYm92ZSBRVUlDIFNUUkVBTSBm cmFtZXMuICBJIGRpZG4ndCBzZWUgYW4gb2J2aW91cyB3YXkgbm90IHRvIGxvc2UgdGhhdCBsYXR0 ZXIgcHJvcGVydHkgaWYgaGVhZGVycyBhbmQgYm9keSBhcmUgaW4gdGhlIHNhbWUgc3RyZWFtLg0K DQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgQ2hhcmxlcyAnQnVjaycgS3Jhc2ljDQpTZW50 OiBGcmlkYXksIE5vdmVtYmVyIDQsIDIwMTYgMTA6MjggQU0NClRvOiBNYXJ0aW4gVGhvbXNvbiA8 bWFydGluLnRob21zb25AZ21haWwuY29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+ Pg0KQ2M6IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+OyBQYXRyaWNrIE1jTWFu dXMgPHBtY21hbnVzQG1vemlsbGEuY29tPG1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbT4+DQpT dWJqZWN0OiBSZTogW1FVSUNdIGgyIG1hcHBpbmcgLSBocGFjayBkeW5hbWljIHRhYmxlIGJ5IHJl ZmVyZW5jZQ0KDQpJIGhhdmUgaW5kZWVkIGJlZW4gdGhpbmtpbmcgYWJvdXQgdGhpcyB2ZXJ5IGlz c3VlLiAgSGVyZSBpcyBhbiBvdXRsaW5lIG9mIHdoYXQgSSd2ZSBnb3Qgc28gZmFyLiAgSSB0aGlu ayBpdCdzIG5vdCBzbyBmYXIgZnJvbSB3aGF0IG90aGVycyBhcmUgdGhpbmtpbmcuDQoNCkkgY2Fs bCB0aGUgbmV3IHNjaGVtZSBRVUlDIEhQQUNLIChhcyBvcHBvc2VkIHRvIEhUVFAvMiBIUEFDSyBm b3Igc3RhdHVzIHF1bykuDQoNCiAgKiAgIFByZW1pc2U6ICBjZXJ0YWluIGluZGV4ZWQgZW50cmll cyBzaG91bGQgYmUgYXZvaWRlZCwgbmFtZWx5IGluZGV4ZWQgZW50cmllcyB0aGF0IHdvdWxkIHJl ZmVyIHRvIGVudHJpZXMgdGhhdCBvcmlnaW5hdGUgZnJvbSBoZWFkZXJzIHRoYXQgYXJlIHN0aWxs IGluIGZsaWdodCwgYmVjYXVzZSBwYWNrZXQgbG9zcyBvbiB0aG9zZSBvdGhlciBoZWFkZXJzIHdv dWxkIEhPTCBibG9jayB0aGUgY3VycmVudCBzdHJlYW0uDQogICogICBUaGUgaWRlYSBvZiBRVUlD IEhQQUNLIHRoZW4gaXMgdG8gbWFyayB1cGRhdGVzIHRvIHRoZSBkeW5hbWljIHRhYmxlIGFzICJw ZW5kaW5nIiBpbml0aWFsbHksIGFuZCBjb21taXQgdGhlbSBsYXRlciB3aGVuIHRoZSBoZWFkZXIg dGhleSBvcmlnaW5hdGUgZnJvbSBpcyBubyBsb25nZXIgaW4gZmxpZ2h0IChpLmUuIGFja2VkIHRv IHNlbmRlcikuICAgSW5kZXhlZCBlbnRyaWVzIHdvdWxkIG9ubHkgYmUgZ2VuZXJhdGVkIGFnYWlu c3QgZHluYW1pYyB0YWJsZXMgZW50cmllcyB0aGF0IGFyZSBjb21taXR0ZWQuICBJLmUuLCB3aGVu IGVuY29kaW5nIGFuIGVudHJ5LCBpZiB0aGVyZSBpcyBhICBtYXRjaGluZyBidXQgcGVuZGluZyBl bnRyeSBpbiB0aGUgZHluYW1pYyB0YWJsZSwgZ2VuZXJhdGUgYSBsaXRlcmFsIGluc3RlYWQgb2Yg aW5kZXhlZC4NCg0KICAgICAqICAgSSBoYXZlIGNvbGxlY3RlZCBzb21lIGRhdGEgdG8gbWVhc3Vy ZSB0aGUgdGltZSBiZXR3ZWVuIHdoZW4gZW50cmllcyBhcmUgYWRkZWQgdG8gdGhlIHRhYmxlLCBh bmQgdGhlIGNyZWF0aW9uIG9mIHN1YnNlcXVlbnQgaW5kZXhlZCBlbnRyaWVzIHRoYXQgcmVmZXIg dG8gdGhlbS4gICBJdCBzdWdnZXN0cyB0aGF0IGEgc21hbGwgZnJhY3Rpb24gb2YgSFRUUC8yIEhQ QUNLIGluZGV4ZWQgZW50cmllcyAodW5kZXIgc3RhbmRhcmQgSFBBQ0spIHdvdWxkIGJlY29tZSBs aXRlcmFscyB1bmRlciBRVUlDIEhQQUNLLiAgIH41MCUgYXJlID4gMTBzIGFwYXJ0LCBhbmQgfjkw JSBhcmUgPiA1MG1zIGFwYXJ0Lg0KDQogICogICB0aGUgbmV3IGJlaGF2aW9yIGNvdWxkIGJlIG9w dGlvbmFsLCBpbmRpdmlkdWFsIEhUVFAvMiB0cmFuc2FjdGlvbnMgdG8gc2VsZWN0IGJldHdlZW4g dGhpcyBuZXcgc2NoZW1lIGFuZCB0aGUgc3RhdHVzIHF1bywgdHJhZGluZyBiZXR3ZWVuIGNvbXBy ZXNzaW9uIGFuZCBIT0wgZnJlZWRvbS4gICBTdGF0dXMgcXVvIHRyYW5zYWN0aW9ucyB3b3VsZCBz dGlsbCB1c2Ugc3RyZWFtIDMgKEhUVFAvMiBIUEFDSykuDQpBbGdvcml0aG0vZGVzaWduIGRldGFp bHM6DQoNCiAgKiAgIGluc3RlYWQgdXNpbmcgdGhlIHNoYXJlZCBoZWFkZXJzIHN0cmVhbSAoIzMp LCBlYWNoIEhUVFAvMiB0cmFuc2FjdGlvbiBoYXMgYSBkZWRpY2F0ZWQgc3RyZWFtIGZvciBoZWFk ZXJzDQoNCiAgICAgKiAgIGkuZS4gZWFjaCBIVFRQLzIgdHJhbnNhY3Rpb24gaGFzIHR3byBRVUlD IHN0cmVhbXM6IDEgZm9yIGhlYWRlcnMgKGluY2wuIHRyYWlsZXJzIGlmIHVzZWQpLCAxIGZvciBi b2R5Lg0KICAgICAqICAgMSBiaXQgb2YgdGhlIHN0cmVhbSBpZCB3aWxsIGJlIHVzZWQgdG8gY2xh c3NpZnkgdGhlIFFVSUMgc3RyZWFtIGFzIGhlYWRlcnMgb3IgYm9keS4NCg0KICAgICAgICAqICAg bGlrZSB0aGUgY3VycmVudCBnbG9iYWwgaGVhZGVyIHN0cmVhbSwgdGhlc2UgbmV3IGhlYWRlcnMg c3RyZWFtcyB3aWxsIHByb3RlY3RlZCBmcm9tIFJTVHMuDQoNCiAgICAgICAgICAgKiAgIFFVSUMg SFBBQ0sgYWxnb3JpdGhtIHdpbGwgcHJvY2VzcyBhbGwgaGVhZGVycywgZXZlbiBpZiB0aGUgY29y cmVzcG9uZGluZyBIVFRQLzIgdHJhbnNhY3Rpb24gbWF5IGhhdmUgYmVlbiBjYW5jZWxsZWQgYW5k IGNvcnJlc3BvbmRpbmcgYm9keSBzdHJlYW0gUlNULg0KDQogICogICBRVUlDIEhQQUNLIGVuY29k ZSBhbmQgZGVjb2RlIGFyZSBkaXZpZGVkIGludG8gdHdvIHBoYXNlcyBlYWNoOiB0cmFuc21pdCBh bmQgY29tbWl0Lg0KDQogICAgICogICBpbiBhZGRpdGlvbiB0byB0aGUgaW5mbyBhbHJlYWR5IGlu Y2x1ZGVkIGluIEhUVFAvMiBoZWFkZXIgZnJhbWVzLCBlYWNoIGhlYWRlciB0cmFuc21pdHRlZCBm cm9tIGVuY29kZXIgdG8gZGVjb2RlciB3aWxsIGluY2x1ZGUgYSBwYWlyIG9mIHNlcXVlbmNlIG51 bWJlcnMsIHRoZSBlbmNvZGUgc2VxdWVuY2UgbnVtYmVyIGFuZCB0aGUgY29tbWl0IGVwb2NoLCBk ZXNjcmliZWQgYmVsb3cuDQoNCiAgICAgICAgKiAgICB0aGUgcGFpciB3aWxsIGFsd2F5cyBoYXZl IHRoZSBwcm9wZXJ0eSB0aGF0IGNvbW1pdCBlcG9jaCA8IGVuY29kZSBzZXF1ZW5jZSBudW1iZXIu DQoNCiAgICAgKiAgIGZpcnN0IHBoYXNlICh0cmFuc21pdCk6ICBoZWFkZXIgaXMgZW5jb2RlZC9k ZWNvZGVkLCBidXQgdXBkYXRlcyB0byBkeW5hbWljIHRhYmxlIGFyZSBtYXJrZWQgcGVuZGluZy4N Cg0KICAgICAgICAqICAgd2hlbiBwcm9jZXNzaW5nIGEgaGVhZGVyLCB0aGUgZW5jb2RlciB3aWxs IGRlY2lkZSB3aGljaCBlbnRyaWVzIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgZHluYW1pYyB0YWJs ZSwgYXMgaW4gY3VycmVudCBIUEFDSywgYnV0IHRoZSBlbnRyeSBpbiB0aGUgZHluYW1pYyB0YWJs ZSB3aWxsIGhhdmUgYSAicGVuZGluZyIgZmxhZyBzZXQsIHByZXZlbnRpbmcgaXQgZnJvbSBiZWlu ZyBhIHJlZmVyZW5jZSBmb3IgaW5kZXhlZCBlbnRyaWVzIHlldC4NCiAgICAgICAgKiAgIHRoZSBl bmNvZGVyIGFzc2lnbnMgYSBzZXF1ZW5jZSBudW1iZXIgdG8gZWFjaCBoZWFkZXIgKGJsb2NrKSwg dGhlIHRvdGFsIG51bWJlciBvZiBoZWFkZXJzIGVuY29kZWQgc28gZmFyIChlbmNvZGUgZXBvY2gp Lg0KICAgICAgICAqICAgdGhlIGVuY29kZXIvZGVjb2RlciBlbnRlcnMgZWFjaCBoZWFkZXIgaW50 byBhIGNvbW1pdCBzZXF1ZW5jZXIgKG9yZGVyZWQgcXVldWUpIHRvIGJlIHVzZWQgaW4gdGhlIHNl Y29uZCBwaGFzZS4NCiAgICAgICAgKiAgIHRoZSBoZWFkZXIgaXMgdHJhbnNtaXR0ZWQgZnJvbSBl bmNvZGVyIHRvIGRlY29kZXIuICB0aGUgZGVjb2RlciBjYW4gYWx3YXlzIGRlY29kZSBpbW1lZGlh dGVseSwgYmVjYXVzZSB0aGlzIGFsZ29yaXRobSBwcmV2ZW50cyBhIGhlYWRlciBmcm9tIHJlZmVy cmluZyB0byBvdGhlciBoZWFkZXJzIHRoYXQgbWlnaHQgc3RpbGwgYmUgaW4gZmxpZ2h0Lg0KDQog ICAgICogICBzZWNvbmQgcGhhc2UgKGNvbW1pdCk6ICBvbmNlIGZ1bGx5IHRyYW5zbWl0dGVkLCAg cGVuZGluZyB1cGRhdGVzIGFyZSBjb21taXR0ZWQsIGluIHRoZSBzYW1lIG9yZGVyIHRoZXkgd2Vy ZSBlbmNvZGVkLg0KDQogICAgICAgICogICBhdCBlbmNvZGVyLCB3aGVuIGEgcHJldmlvdXNseSB0 cmFuc21pdHRlZCBoZWFkZXIgaGFzIGJlZW4gYWNrZWQsIHRoZSBlbnRyeSBpbiB0aGUgY29tbWl0 LXNlcXVlbmNlciBpcyBtYXJrZWQgY29tbWl0dGVkLg0KDQogICAgICAgICAgICogICB0aGUgZnJv bnQgb2YgdGhlIHNlcXVlbmNlciBpcyBwb3BwZWQgd2hpbGUgdGhlIGZyb250IGlzIGEgY29tbWl0 dGVkIGVudHJ5LiAobG9vcCkNCiAgICAgICAgICAgKiAgIHRoZSBjb21taXQgZXBvY2ggdHJhY2tz IHRoZSBoaWdoZXN0IHNlcXVlbmNlIG51bWJlciBwb3BwZWQuDQoNCiAgICAgICAgKiAgIGF0IGRl Y29kZXIsIHdoZW4gYSBoZWFkZXIgaXMgcmVjZWl2ZWQsIGl0IHdpbGwgcG9wIG9mZiB0aGUgZnJv bnQgb2YgdGhlIGNvbW1pdCBzZXF1ZW5jZXIgd2hpbGUgaXRzIHNlcXVlbmNlIG51bWJlciBpcyA8 PSB0aGUganVzdCByZWNlaXZlZCBjb21taXQgZXBvY2ggKGxvb3ApLg0KDQogICAgICAgICAgICog ICBlYWNoIHBvcHBlZCBlbnRyeSBpcyBtYXJrZWQgY29tbWl0dGVkLg0KICAgICAgICAgICAqICAg bm93IHRoZSByZWNlaXZlZCBoZWFkZXIgaXMgZGVjb2RlZC4NCg0KICAgICAqICAgYSBzcGVjaWFs IGNhc2UgdGhhdCBpcyBoYW5kbGVkIGJ5IHRoZSBkeW5hbWljIHRhYmxlIGluIEhUVFAvMiBIUEFD SyBidXQgSSB0aGluayBuZWVkcyB0byBiZSB0cmVhdGVkIGRpZmZlcmVudGx5IGZvciBRVUlDIEhQ QUNLLCB0aGF0IGlzIGVudHJpZXMgdGhhdCByZWZlciB0byBvdGhlciBlbnRyaWVzIGZyb20gdGhl IHNhbWUgaGVhZGVyLiAgICBGb3IgdGhpcyBJIHByb3Bvc2UgdG8gZGVmaW5lIGEgbmV3IGRpc3Rp bmN0IHRhYmxlLCBhbmQgY29ycmVzcG9uZGluZyBkaXN0aW5jdCBlbnRyeSB0eXBlcywgIkludHJh Ii4gICBUaGlzIHdvdWxkIGJlIGFuIGVwaGVtZXJhbCBwZXItaGVhZGVyIHRhYmxlIHRoYXQgZXhp c3RzIG9ubHkgZHVyaW5nIHRoZSB0cmFuc21pdCBwaGFzZS4NCg0KICAgICAgICAqICAgSSBkb24n dCBoYXZlIGRhdGEgeWV0IGZvciBob3cgbWFueSBlbnRyaWVzIGZhbGwgaW50byB0aGlzIGNhdGVn b3J5Lg0KDQpPbiBUaHUsIE5vdiAzLCAyMDE2IGF0IDU6NTQgUE0sIE1hcnRpbiBUaG9tc29uIDxt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+ IHdyb3RlOg0KT24gNCBOb3ZlbWJlciAyMDE2IGF0IDA4OjI5LCBQYXRyaWNrIE1jTWFudXMgPHBt Y21hbnVzQG1vemlsbGEuY29tPG1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbT4+IHdyb3RlOg0K PiB0aGlzIGlzIGEgZmFpcmx5IHNpZ25pZmljYW50IGJpdCBvZiBzdXJnZXJ5IHRvIGgyJ3MgZm9y bWF0cywgYnV0IGdpdmVuIHRoYXQNCj4gb25lIG9mIHRoZSByZWFsIHF1aWMgb3Bwb3J0dW5pdGll cyBpcyB0byBwZXJmb3JtIGJldHRlciB1bmRlciBsb3NzIGl0IGNvdWxkDQo+IGJlIHdvcnRod2hp bGUgdG8gc2V2ZXIgb3JkZXJpbmcgZGVwZW5kZW5jaWVzIGV2ZW4gZnVydGhlci4gU2VlbXMgbGlr ZSBhDQo+IHJlYXNvbmFibGUgdGhpbmcgdG8gaW52ZXN0aWdhdGUgdG8gbWUuDQoNCkkgYWdyZWUu ICBXZSByaXNrIG5lZ2F0aW5nIG11Y2ggb2YgdGhlIHBlcmZvcm1hbmNlIHdpbnMgYnkgY3JlYXRp bmcNCmhlYWQtb2YtbGluZSBibG9ja2luZyBpbiBoZWFkZXIgZmllbGRzLiAgV2l0aCBtYW55IHJl c291cmNlcywgYSBsb3Qgb2YNCnRoZSBjcml0aWNhbCBlYXJseSBpbnRlcmFjdGlvbnMgYXJlIGVu dGlyZWx5IGhlYWRlciBmaWVsZHMsIGFuZCBocGFjaw0KaXMgc3RyaWN0bHkgc2VyaWFsaXplZC4N Cg0KTWF5YmUgdGhpcyBpcyBhIGdvb2QgdGltZSB0byByYWlzZSB0aGUgcG9zc2liaWxpdHkgdGhh dCB3ZSBtaWdodCBuZWVkDQpocGFjayBtb2RpZmljYXRpb25zIGFuZCB0aGF0IHRob3NlIG1vZGlm aWNhdGlvbnMgbWlnaHQgYmVuZWZpdCBmcm9tIGENCm5ldyBkb2N1bWVudC4gIFdlIHNwbGl0IGhw YWNrIG91dCBpbiBoMiwgYW5kIGl0IHdhcyBhIG5lYXQgYnJlYWsgdGhhdA0Kd2UgbmV2ZXIgcmVn cmV0dGVkLg0KDQoNCg0KLS0NCkNoYXJsZXMgJ0J1Y2snIEtyYXNpYyB8IFNvZnR3YXJlIEVuZ2lu ZWVyIHwgY2tyYXNpY0Bnb29nbGUuY29tPG1haWx0bzpja3Jhc2ljQGdvb2dsZS5jb20+IHwgKzEg KDQwOCkgNDEyLTExNDE8dGVsOig0MDgpJTIwNDEyLTExNDE+DQoNCg0KDQotLQ0KQ2hhcmxlcyAn QnVjaycgS3Jhc2ljIHwgU29mdHdhcmUgRW5naW5lZXIgfCBja3Jhc2ljQGdvb2dsZS5jb208bWFp bHRvOmNrcmFzaWNAZ29vZ2xlLmNvbT4gfCArMSAoNDA4KSA0MTItMTE0MQ0K --_000_BN6PR03MB2708E83F77D3456A26256ADF87A20BN6PR03MB2708namp_ 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 aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MjA2NzEyMjY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDU4NTk2MTk4O30N CkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDozNjYxMDUxMjM7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOi0xMjE5NzMxOTUwO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo0MDQzMDQwOTY7DQoJ bXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5NTM2NzAyNDA7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXci Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1saXN0 LWlkOjQzNTcxMzA4NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6ODM5MTM0NDI4O30NCkBsaXN0 IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6NDUyMDIxOTQ2Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotNzU2MjY5ODIyO30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs NDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNQ0KCXttc28tbGlzdC1pZDo1NDY1MzM4MDc7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjE2MDc0Nzc0MDt9DQpAbGlzdCBsNTpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw1OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDU6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDU6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDU6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDU6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDYNCgl7bXNvLWxpc3QtaWQ6NzUw NTg5NDMxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTQyOTk0NDQwMDt9DQpAbGlzdCBsNjps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2 OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw2OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw2OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw3DQoJe21zby1saXN0LWlkOjg5OTI5NDYwODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 MTYxNDgwNzA5MDt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGw3OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGw3OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoz LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw3OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw4DQoJe21zby1saXN0LWlkOjkyNjMwNTk4MDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzMTg1NDU3MDQ7fQ0KQGxpc3QgbDg6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsODpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw4 OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw4OmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw4OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoy LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw4OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw4OmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw4OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw4OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw5DQoJe21z by1saXN0LWlkOjEwMDU5NDE3MDc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjM4Nzg2MzQ0NDt9 DQpAbGlzdCBsOTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw5OmxldmVsMg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5l dyBSb21hbiI7fQ0KQGxpc3QgbDk6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDk6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDk6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDk6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDEwDQoJe21zby1saXN0LWlkOjExMjE0NjE0MzQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjE5MDI2NDc5NjA7fQ0KQGxpc3QgbDEwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDEwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDEwOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEwOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMQ0KCXttc28tbGlzdC1pZDoxMjU0 MjM4MjE1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTE3NzQwMjQyNjt9DQpAbGlzdCBsMTE6 bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTE6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9 DQpAbGlzdCBsMTE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDExOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEx OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMTpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDEyDQoJe21zby1saXN0LWlkOjEyNzg5NDgzNDU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjkxODMwMzI1MDt9DQpAbGlzdCBsMTI6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTI6bGV2ZWwzDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDEyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTI6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwxMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTI6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEzDQoJe21zby1saXN0LWlkOjE0NDUz NDQzNDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjMyODUyNzk4O30NCkBsaXN0IGwxMzps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMzpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwxMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTM6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxMzpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTM6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDEzOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTQNCgl7bXNvLWxpc3QtaWQ6MTU5NzUyMjA0OTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTE4ODU5ODk5MzQ7fQ0KQGxpc3QgbDE0OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDE0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE0OmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE0OmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE0OmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxNQ0KCXttc28tbGlzdC1pZDoxODEyNDA1 NzA0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzMxNTc4Nzc2O30NCkBsaXN0IGwxNTpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxNTpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwxNTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTU6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE1OmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxNTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTU6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE1OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTYNCgl7bXNvLWxpc3QtaWQ6MTg3NjMxMzU3ODsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTY1NDUxOTY4NDt9DQpAbGlzdCBsMTY6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMTY6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE2OmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxNjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTY6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE2Omxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxNjpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTY6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE2OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxNw0KCXttc28tbGlzdC1p ZDoxOTgzOTIzNjQ4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczozMTk5NTUwODQ7fQ0KQGxpc3Qg bDE3OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE3OmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KQGxpc3QgbDE3OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxNzps ZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTc6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE3OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxNzpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTc6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE3OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxOA0KCXttc28tbGlzdC1pZDoyMTIzNTI1MDI0Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxOTA2NzM1ODY4O30NCkBsaXN0IGwxODpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwxODpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxODpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTg6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE4OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxODpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTg6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE4OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxODps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1 bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T2gsIGdyYW50ZWQgdGhhdCBpdOKAmXMgbm90IHN1ZmZpY2ll bnQgdG8gY2FsbCBpdCBhbiBlbmNvZGVyIHN0cmF0ZWd5IGFuZCBqdXN0IGtlZXAgdXNpbmcgSFBB Q0suJm5ic3A7IEnigJltIGp1c3QgbWFraW5nIHRoZSBhcmd1bWVudCB0aGF0IGl0IG5lZWQgbm90 IGJlIHRoZSBiYXNpcyBvZiB0aGUgcHJvdG9jb2wgZGVzaWduIOKAkyB0aGUgcHJvdG9jb2wgY2Fu IGVuYWJsZSBhbiBlbmNvZGVyIHRoYXQgd2FudHMgdG8gZG8gc3VjaA0KIGEgc3RyYXRlZ3kgdG8g ZG8gc28gd2l0aG91dCBtYW5kYXRpbmcgaXQuJm5ic3A7IEkgcmVhbGx5IGRvbuKAmXQgd2FudCBh IGR1YWwgSFBBQ0stYW5kLVFQQUNLIGFwcHJvYWNoIOKAkyBtYXliZSB3ZSBjYW4gZGVmaW5lIGEg bGVnYWN5IHZlcnNpb24gd2hlcmUgSFBBQ0sgb24gc3RyZWFtIDMgaXMgdXNlZCwgYnV0IGF0IHdv cnN0IGNhc2UsIHlvdSBzaG91bGQgc2VsZWN0IGFuZCBjb21taXQgdG8gb25lIGZvciBhIGNvbm5l Y3Rpb24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBhZ3JlZSB0aGF0IGp1ZGdpbmcg d2hldGhlciB5b3XigJlsbCBiZSB3aXRoaW4gdGhlIHNhbWUgcGFja2V0IGNvdWxkIGxlYWQgdG8g bG9vcHMuJm5ic3A7IFBlcmhhcHMgYmV0dGVyIGxlZnQgYWxvbmUgZm9yIG1vc3QgaW1wbGVtZW50 YXRpb25zLCB0aGF04oCZcyBmYWlyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgdGhpbmcg dGhhdCBzdHJpa2VzIG1lIGlzIHRoYXQgdGhlIEhUVFAvMiBmcmFtaW5nIGxheWVyIGlzIGVzc2Vu dGlhbGx5IG1lc3NhZ2UtYmFzZWQgKGZyYW1lcyksIHdoaWxlIGZyb20gdGhlIGFwcGxpY2F0aW9u IGxheWVyLCBRVUlDIGlzIHB1cmVseSBzdHJlYW0tYmFzZWQuJm5ic3A7IEnigJltIHRoaW5raW5n IHRoYXQgZm9yIEhUVFAtb3Zlci1RVUlDLCB3ZSBkZWZpbmUgYSBsaWdodC13ZWlnaHQgZnJhbWlu ZyB0bw0KIGRpZmZlcmVudGlhdGUgaGVhZGVycyBmcm9tIGJvZHkgYW5kIG1vdmUgdGhlIGhlYWRl cnMgYmFjayBvbi1zdHJlYW0sIGlmIHdlIGNhbi4mbmJzcDsgTWF5YmUganVzdCBhIGNvdXBsZSBi eXRlcyBvZiB0eXBlIGlkZW50aWZpY2F0aW9uLCBsZW5ndGgsIGFuZCBlbm91Z2ggY29udGV4dCB0 byBkaWZmZXJlbnRpYXRlIGludGVybWVkaWF0ZSBoZWFkZXIgYmxvY2tzIGZyb20gZmluYWwgcmVz cG9uc2UgaGVhZGVycyBmcm9tIGJvZHkgZnJvbSB0cmFpbGVyc+KApj8mbmJzcDsNCiBQVVNIX1BS T01JU0UgcHJvYmFibHkgbGl2ZXMgaGVyZSwgdG9vLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj5Gcm9tOjwvYj4gQ2hhcmxlcyAnQnVjaycgS3Jhc2ljIFttYWlsdG86Y2tyYXNpY0Bnb29nbGUu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgTm92ZW1iZXIgNCwgMjAxNiAxMjozNiBQ TTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29m dC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNYXJ0aW4gVGhvbXNvbiAmbHQ7bWFydGluLnRob21z b25AZ21haWwuY29tJmd0OzsgcXVpY0BpZXRmLm9yZzsgUGF0cmljayBNY01hbnVzICZsdDtwbWNt YW51c0Btb3ppbGxhLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtRVUlDXSBoMiBt YXBwaW5nIC0gaHBhY2sgZHluYW1pYyB0YWJsZSBieSByZWZlcmVuY2U8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIEZyaSwgTm92IDQsIDIwMTYgYXQgMTE6MTYgQU0sIE1pa2UgQmlzaG9wICZsdDs8YSBo cmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhp cyBpcyBjZXJ0YWlubHkgaW50ZXJlc3RpbmcsIGJ1dCBmZWVscyBtb3JlIGxpa2UgYSB3aXNlIHN0 cmF0ZWd5IGZvciBhbiBlbmNvZGVyIHRvIGVtcGxveSAoaWYgeW91IHdhbnQgdG8gYXZvaWQgYmxv Y2tpbmcsIGRvbuKAmXQgcmVmZXJlbmNlIGEgaGVhZGVyIHRoYXQgaGFzbuKAmXQgYmVlbiBBQ0tl ZCkgdGhhbg0KIGFuIGluZGVwZW5kZW50IGNoYW5nZSB0byB0aGUgcHJvdG9jb2wuJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SSdkIGJlIGhhcHB5IGlmIGl0IGNvdWxkIGJlIGRvbmUgd2l0aCBq dXN0IGVuY29kZXIgc3RyYXRlZ3ksIGJ1dCBJIGRvbid0IHRoaW5rIGl0IGNhbi4gJm5ic3A7IEhl bmNlIHRoZSBleHRyYSBzZXF1ZW5jZSBudW1iZXJzIHNlbnQsIGFuZCB0aGUgbW9kaWZpZWQgbG9n aWMgYXQgdGhlIGRlY29kZXIuICZuYnNwOyAmbmJzcDtUaGF0IHNhaWQsIEkgaGF2ZSBkZWZpbml0 ZWx5IHRyeWluZyB0byBtYWtlIHRoZSBkZWx0YSBhcyBzbWFsbCBhbmQNCiBzaGFycGx5IGZvY3Vz ZWQgb24gSE9MIGFzIHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhpbmsgYWJvdXQgdXNp bmcsIHNheSwgdGhlIHVuaXF1ZS1pbmRleC1wZXItZW50cnkgYXBwcm9hY2ggKHdoaWNoIHJlcXVp cmVzIGJsb2NraW5nIG9uIHVua25vd24gaW5kaWNlcykg4oCTIGFuIGVuY29kZXIgdGhhdCB3YW50 ZWQgdG8gYmUgc21hcnQgY291bGQgZG8gYXMgeW91IGRlc2NyaWJlIGJlbG93IGFuZA0KIGVtaXQg bGl0ZXJhbHMgdW50aWwgdGhlIGZyYW1lIGhhcyBiZWVuIEFDS+KAmWQuJm5ic3A7IChVbmxlc3Mg dGhlIGZyYW1lIHdhcyBnb2luZyBpbiB0aGUgc2FtZSBwYWNrZXQgYXMgdGhlIG9yaWdpbmFsIHZh bHVlLCBpZiBpdCB3YW50cyB0byBiZSBldmVuIHNtYXJ0ZXLigKYuKSZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBzYW1lIHBhY2tldCBhcyBvcmlnaW5hbCB2YWx1ZSBpcyBpbnRlcmVzdGlu ZywgYnV0IEkgdGhpbmsgcG9zc2libHkgc3VwZXIgaGFyZC4mbmJzcDsgVGhlcmUncyBhIGNpcmN1 bGFyIGRlcGVuZGVuY3kgb2YgZXN0aW1hdGluZyB0aGUgY29tcHJlc3NlZCBoZWFkZXIgc2l6ZSBh cyBwYXJ0IG9mIGtub3dpbmcgd2hldGhlciB0aGV5IHdpbGwgZ28gaW4gdGhlIHNhbWUgcGFja2V0 LCBpbiBvcmRlciBkZWNpZGUgb24gcmVwcmVzZW50YXRpb24NCiBzdHJhdGVneSB0aGF0IHdpbGwg dHVybiBlZmZlY3QgY29tcHJlc3NlZCBoZWFkZXIgc2l6ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWF5YmUgYWx0ZXJuYXRpdmUsIG1vcmUg b3IgbGVzcyBjcmF6eSwgYXBwcm9hY2ggd291bGQgYmUgdXNlIHNvbWUgY29tYmluYXRpb24gb2Yg cHNldWRvIHJlcXVlc3RzL3B1c2hlcyB0byBwcmltZSB0aGUgZGljdGlvbmFyeT88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkFuIGVuY29kZXIgdGhhdCBkaWRu4oCZdCB3YW50IHRoZSBjb21wbGV4aXR5IHdv dWxkIGp1c3QgZW1pdCB0aGUgbW9zdCBjb21wYWN0IHJlcHJlc2VudGF0aW9uIGl0IGNvdWxkLCBr bm93aW5nIGl0IG1pZ2h0IGNhdXNlIHNvbWUgYmxvY2thZ2Ugb24gdGhlIHJlY2VpdmVyLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYXQncyB3aGF0IEkgd2FzIHNheWluZyB3cnQgJnF1b3Q7c3RhdHVz IHF1byB0cmFuc2FjdGlvbnMmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+anVzdCBzdGlja2lu ZyB3aXRoIHRoZSBjdXJyZW50IGhlYWRlcnMgb3ZlciBzdHJlYW0gMyB3b3VsZCBhbGxvdyBmb3Ig dGhlIHByZWZlcnMgbW9yZSBjb21wYWN0IHJlcHJlc2VudGF0aW9uIG9wdGlvbi4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5UaGUgdHdvLXN0cmVhbXMtcGVyLXJlcXVlc3QgZmVlbHMgamFycmluZyB0byBtZS4mbmJz cDsgRm9yIEhUVFAsIGF0IGxlYXN0LCB5b3UgaGF2ZSBhIHJlYXNvbmFibHkgd2VsbC1kZWZpbmVk IHNlcmllcyBvZiDigJxIZWFkZXJzJiM0MzssIEJvZHk/LCBIZWFkZXJzP+KAnSBpbiBlYWNoIGRp cmVjdGlvbiBmb3IgZWFjaCB0cmFuc2FjdGlvbi4mbmJzcDsNCiBJIGRvbuKAmXQgdGhpbmsgeW91 4oCZbGwgZ2V0IHJpZCBvZiB0aGUgbmVlZCB0byBoYXZlIHNvbWUgZnJhbWluZyBhcm91bmQgdGhl IGhlYWRlcnM7IEnigJltIG5vdCBjb252aW5jZWQgKGJ1dCB3aWxsaW5nIHRvIGJlKSB0aGF0IHRo ZSBjb21wbGV4aXR5IG9mIG1hbmFnaW5nIHR3byBhZmZpbGlhdGVkIHN0cmVhbXMgaXMgZ3JlYXRl ciB0aGFuIHRoYXQgb2YgbmVlZGluZyBmcmFtaW5nIGFyb3VuZCB0aGUgYm9keSBhcyB3ZWxsIGJl Y2F1c2UgaXQgc2hhcmVzDQogYSBzdHJlYW0gd2l0aCB0aGUgaGVhZGVycy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5SaWdodC4mbmJzcDsgT3VyIFFVSUMgaW1wbGVtZW50YXRpb24gZG9lcyBsYXllciBI VFRQLzIgSEVBREVSIGZyYW1lcyBhYm92ZSBRVUlDIFNUUkVBTSBmcmFtZXMuJm5ic3A7IFRoYXQg d291bGQgYmUgdHJ1ZSBpbiB0aGlzIGRlc2lnbiBhbHNvLiZuYnNwOyBIb3dldmVyLCB0aGUgc3Rh dHVzIHF1byBkb2VzIGFsbG93IHRoZSBib2R5IGRhdGEgdG8gYmUgc2VudCB3aXRob3V0IGFueSBl eHRyYSBmcmFtaW5nIGFib3ZlIFFVSUMgU1RSRUFNDQogZnJhbWVzLiZuYnNwOyBJIGRpZG4ndCBz ZWUgYW4gb2J2aW91cyB3YXkgbm90IHRvIGxvc2UgdGhhdCBsYXR0ZXIgcHJvcGVydHkgaWYgaGVh ZGVycyBhbmQgYm9keSBhcmUgaW4gdGhlIHNhbWUgc3RyZWFtLiAmbmJzcDsmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9u IEJlaGFsZiBPZiA8L2I+Q2hhcmxlcyAnQnVjaycgS3Jhc2ljPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgTm92ZW1iZXIgNCwgMjAxNiAxMDoyOCBBTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRo b21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGll dGYub3JnPC9hPjsgUGF0cmljayBNY01hbnVzICZsdDs8YSBocmVmPSJtYWlsdG86cG1jbWFudXNA bW96aWxsYS5jb20iIHRhcmdldD0iX2JsYW5rIj5wbWNtYW51c0Btb3ppbGxhLmNvbTwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUVVJQ10gaDIgbWFwcGluZyAtIGhwYWNrIGR5bmFt aWMgdGFibGUgYnkgcmVmZXJlbmNlPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+SSBoYXZlIGluZGVlZCBiZWVuIHRoaW5raW5nIGFib3V0IHRo aXMgdmVyeSBpc3N1ZS4mbmJzcDsgSGVyZSBpcyBhbiBvdXRsaW5lIG9mIHdoYXQgSSd2ZSBnb3Qg c28gZmFyLiZuYnNwOyBJIHRoaW5rIGl0J3Mgbm90IHNvIGZhciBmcm9tIHdoYXQgb3RoZXJzIGFy ZSB0aGlua2luZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5JIGNhbGwgdGhlIG5ldyBzY2hlbWUgUVVJQyBIUEFDSyAoYXMg b3Bwb3NlZCB0byBIVFRQLzIgSFBBQ0sgZm9yIHN0YXR1cyBxdW8pLiAmbmJzcDsmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxNiBsZXZlbDEgbGZvMSI+DQpQ cmVtaXNlOiAmbmJzcDtjZXJ0YWluIGluZGV4ZWQgZW50cmllcyBzaG91bGQgYmUgYXZvaWRlZCwg bmFtZWx5IGluZGV4ZWQgZW50cmllcyB0aGF0IHdvdWxkIHJlZmVyIHRvIGVudHJpZXMgdGhhdCBv cmlnaW5hdGUgZnJvbSBoZWFkZXJzDQo8aT50aGF0IGFyZSBzdGlsbCBpbiBmbGlnaHQ8L2k+LCBi ZWNhdXNlIHBhY2tldCBsb3NzIG9uIHRob3NlIG90aGVyIGhlYWRlcnMgd291bGQgSE9MIGJsb2Nr IHRoZSBjdXJyZW50IHN0cmVhbS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDE2IGxldmVsMSBsZm8xIj4NClRoZSBpZGVhIG9m IFFVSUMgSFBBQ0sgdGhlbiBpcyB0byBtYXJrIHVwZGF0ZXMgdG8gdGhlIGR5bmFtaWMgdGFibGUg YXMgJnF1b3Q7cGVuZGluZyZxdW90OyBpbml0aWFsbHksIGFuZCBjb21taXQgdGhlbSBsYXRlciB3 aGVuIHRoZSBoZWFkZXIgdGhleSBvcmlnaW5hdGUgZnJvbSBpcyBubyBsb25nZXIgaW4gZmxpZ2h0 IChpLmUuIGFja2VkIHRvIHNlbmRlcikuICZuYnNwOyBJbmRleGVkIGVudHJpZXMgd291bGQgb25s eSBiZSBnZW5lcmF0ZWQgYWdhaW5zdCBkeW5hbWljIHRhYmxlcw0KIGVudHJpZXMgdGhhdCBhcmUg Y29tbWl0dGVkLiZuYnNwOyBJLmUuLCB3aGVuIGVuY29kaW5nIGFuIGVudHJ5LCBpZiB0aGVyZSBp cyBhICZuYnNwO21hdGNoaW5nIGJ1dCBwZW5kaW5nIGVudHJ5IGluIHRoZSBkeW5hbWljIHRhYmxl LCBnZW5lcmF0ZSBhIGxpdGVyYWwgaW5zdGVhZCBvZiBpbmRleGVkLjxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMTEgbGV2ZWwyIGxmbzIiPg0KSSBo YXZlIGNvbGxlY3RlZCBzb21lIGRhdGEgdG8gbWVhc3VyZSB0aGUgdGltZSBiZXR3ZWVuIHdoZW4g ZW50cmllcyBhcmUgYWRkZWQgdG8gdGhlIHRhYmxlLCBhbmQgdGhlIGNyZWF0aW9uIG9mIHN1YnNl cXVlbnQgaW5kZXhlZCBlbnRyaWVzIHRoYXQgcmVmZXIgdG8gdGhlbS4gJm5ic3A7IEl0IHN1Z2dl c3RzIHRoYXQgYSBzbWFsbCBmcmFjdGlvbiBvZiBIVFRQLzIgSFBBQ0sgaW5kZXhlZCBlbnRyaWVz ICh1bmRlciBzdGFuZGFyZCBIUEFDSykgd291bGQgYmVjb21lDQogbGl0ZXJhbHMgdW5kZXIgUVVJ QyBIUEFDSy4gJm5ic3A7Jm5ic3A7fjUwJSBhcmUgJmd0OyAxMHMgYXBhcnQsIGFuZCB+OTAlIGFy ZSAmZ3Q7IDUwbXMgYXBhcnQuPG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6 bDYgbGV2ZWwxIGxmbzMiPg0KdGhlIG5ldyBiZWhhdmlvciBjb3VsZCBiZSBvcHRpb25hbCwgaW5k aXZpZHVhbCBIVFRQLzIgdHJhbnNhY3Rpb25zIHRvIHNlbGVjdCBiZXR3ZWVuIHRoaXMgbmV3IHNj aGVtZSBhbmQgdGhlIHN0YXR1cyBxdW8sIHRyYWRpbmcgYmV0d2VlbiBjb21wcmVzc2lvbiBhbmQg SE9MIGZyZWVkb20uICZuYnNwOyBTdGF0dXMgcXVvIHRyYW5zYWN0aW9ucyB3b3VsZCBzdGlsbCB1 c2Ugc3RyZWFtIDMgKEhUVFAvMiBIUEFDSykuPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkFsZ29yaXRobS9kZXNpZ24gZGV0YWlsczo8bzpwPjwvbzpwPjwvcD4N Cjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwzIGxldmVsMSBsZm80Ij4NCmluc3RlYWQgdXNpbmcgdGhlIHNoYXJlZCBoZWFk ZXJzIHN0cmVhbSAoIzMpLCBlYWNoIEhUVFAvMiB0cmFuc2FjdGlvbiBoYXMgYSBkZWRpY2F0ZWQg c3RyZWFtIGZvciBoZWFkZXJzPG86cD48L286cD48L2xpPjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+ DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MGluO21zby1saXN0Omw1IGxldmVsMiBsZm81Ij4NCmkuZS4gZWFjaCBIVFRQLzIgdHJhbnNhY3Rp b24gaGFzIHR3byBRVUlDIHN0cmVhbXM6IDEgZm9yIGhlYWRlcnMgKGluY2wuIHRyYWlsZXJzIGlm IHVzZWQpLCAxIGZvciBib2R5LjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNSBsZXZlbDIgbGZvNSI+DQoxIGJpdCBvZiB0aGUg c3RyZWFtIGlkIHdpbGwgYmUgdXNlZCB0byBjbGFzc2lmeSB0aGUgUVVJQyBzdHJlYW0gYXMgaGVh ZGVycyBvciBib2R5LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjx1bCB0eXBlPSJkaXNj Ij4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPHVsIHR5cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDMgbGZvNiI+DQpsaWtl IHRoZSBjdXJyZW50IGdsb2JhbCBoZWFkZXIgc3RyZWFtLCB0aGVzZSBuZXcgaGVhZGVycyBzdHJl YW1zIHdpbGwgcHJvdGVjdGVkIGZyb20gUlNUcy48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+ DQo8L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8dWwgdHlwZT0i c3F1YXJlIj4NCjx1bCB0eXBlPSJzcXVhcmUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDggbGV2ZWw0IGxmbzciPg0KPGk+UVVJQyBIUEFDSyBhbGdv cml0aG0gd2lsbCBwcm9jZXNzIGFsbCBoZWFkZXJzLCBldmVuIGlmIHRoZSBjb3JyZXNwb25kaW5n IEhUVFAvMiB0cmFuc2FjdGlvbiBtYXkgaGF2ZSBiZWVuIGNhbmNlbGxlZCBhbmQgY29ycmVzcG9u ZGluZyBib2R5IHN0cmVhbSBSU1Q8L2k+LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjwv dWw+DQo8L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzgiPg0KUVVJQyBIUEFDSyBlbmNvZGUg YW5kIGRlY29kZSBhcmUgZGl2aWRlZCBpbnRvIHR3byBwaGFzZXMgZWFjaDogdHJhbnNtaXQgYW5k IGNvbW1pdC4gJm5ic3A7Jm5ic3A7PG86cD48L286cD48L2xpPjwvdWw+DQo8dWwgdHlwZT0iZGlz YyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwxNyBsZXZlbDIgbGZvOSI+DQppbiBhZGRpdGlvbiB0byB0aGUgaW5m byBhbHJlYWR5IGluY2x1ZGVkIGluIEhUVFAvMiBoZWFkZXIgZnJhbWVzLCBlYWNoIGhlYWRlciB0 cmFuc21pdHRlZCBmcm9tIGVuY29kZXIgdG8gZGVjb2RlciB3aWxsIGluY2x1ZGUgYSBwYWlyIG9m IHNlcXVlbmNlIG51bWJlcnMsIHRoZSBlbmNvZGUgc2VxdWVuY2UgbnVtYmVyIGFuZCB0aGUgY29t bWl0IGVwb2NoLCBkZXNjcmliZWQgYmVsb3cuPG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0K PHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8dWwgdHlwZT0ic3F1YXJlIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MyBsZm8xMCI+DQombmJzcDs8aT50aGUgcGFpciB3aWxsIGFsd2F5cyBoYXZlIHRoZSBwcm9wZXJ0 eSB0aGF0IGNvbW1pdCBlcG9jaCAmbHQ7IGVuY29kZSBzZXF1ZW5jZSBudW1iZXIuPC9pPjxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlw ZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwxMyBsZXZlbDIgbGZvMTEiPg0KZmlyc3QgcGhhc2UgKHRyYW5zbWl0KTogJm5ic3A7aGVh ZGVyIGlzIGVuY29kZWQvZGVjb2RlZCwgYnV0IHVwZGF0ZXMgdG8gZHluYW1pYyB0YWJsZSBhcmUg bWFya2VkIHBlbmRpbmcuPG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHR5cGU9ImRp c2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8dWwgdHlwZT0ic3F1YXJlIj4NCjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMyBsZm8xMiI+DQp3 aGVuIHByb2Nlc3NpbmcgYSBoZWFkZXIsIHRoZSBlbmNvZGVyIHdpbGwgZGVjaWRlIHdoaWNoIGVu dHJpZXMgc2hvdWxkIGJlIGFkZGVkIHRvIHRoZSBkeW5hbWljIHRhYmxlLCBhcyBpbiBjdXJyZW50 IEhQQUNLLCBidXQgdGhlIGVudHJ5IGluIHRoZSBkeW5hbWljIHRhYmxlIHdpbGwgaGF2ZSBhICZx dW90O3BlbmRpbmcmcXVvdDsgZmxhZyBzZXQsIHByZXZlbnRpbmcgaXQgZnJvbSBiZWluZyBhIHJl ZmVyZW5jZSBmb3IgaW5kZXhlZCBlbnRyaWVzIHlldC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwzIGxmbzEyIj4N CnRoZSBlbmNvZGVyIGFzc2lnbnMgYSBzZXF1ZW5jZSBudW1iZXIgdG8gZWFjaCBoZWFkZXIgKGJs b2NrKSwgdGhlIHRvdGFsIG51bWJlciBvZiBoZWFkZXJzIGVuY29kZWQgc28gZmFyIChlbmNvZGUg ZXBvY2gpLiZuYnNwOzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDMgbGZvMTIiPg0KdGhlIGVuY29kZXIvZGVjb2Rl ciBlbnRlcnMgZWFjaCBoZWFkZXIgaW50byBhIGNvbW1pdCBzZXF1ZW5jZXIgKG9yZGVyZWQgcXVl dWUpIHRvIGJlIHVzZWQgaW4gdGhlIHNlY29uZCBwaGFzZS48bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwzIGxmbzEy Ij4NCjxpPnRoZSBoZWFkZXIgaXMgdHJhbnNtaXR0ZWQgZnJvbSBlbmNvZGVyIHRvIGRlY29kZXIu ICZuYnNwO3RoZSBkZWNvZGVyIGNhbiBhbHdheXMgZGVjb2RlIGltbWVkaWF0ZWx5LCBiZWNhdXNl IHRoaXMgYWxnb3JpdGhtIHByZXZlbnRzIGEgaGVhZGVyIGZyb20gcmVmZXJyaW5nIHRvIG90aGVy IGhlYWRlcnMgdGhhdCBtaWdodCBzdGlsbCBiZSBpbiBmbGlnaHQuPC9pPjxvOnA+PC9vOnA+PC9s aT48L3VsPg0KPC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xl Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxMCBs ZXZlbDIgbGZvMTMiPg0Kc2Vjb25kIHBoYXNlIChjb21taXQpOiAmbmJzcDtvbmNlIGZ1bGx5IHRy YW5zbWl0dGVkLCAmbmJzcDtwZW5kaW5nIHVwZGF0ZXMgYXJlIGNvbW1pdHRlZCwgaW4gdGhlIHNh bWUgb3JkZXIgdGhleSB3ZXJlIGVuY29kZWQuPG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0K PHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8dWwgdHlwZT0ic3F1YXJlIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omw5IGxldmVs MyBsZm8xNCI+DQphdCBlbmNvZGVyLCB3aGVuIGEgcHJldmlvdXNseSB0cmFuc21pdHRlZCBoZWFk ZXIgaGFzIGJlZW4gYWNrZWQsIHRoZSBlbnRyeSBpbiB0aGUgY29tbWl0LXNlcXVlbmNlciBpcyBt YXJrZWQgY29tbWl0dGVkLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjwvdWw+DQo8dWwg dHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjx1bCB0eXBlPSJzcXVhcmUiPg0KPHVs IHR5cGU9InNxdWFyZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMTUgbGV2ZWw0IGxmbzE1Ij4NCnRoZSBmcm9udCBvZiB0aGUgc2VxdWVuY2VyIGlz IHBvcHBlZCB3aGlsZSB0aGUgZnJvbnQgaXMgYSBjb21taXR0ZWQgZW50cnkuIChsb29wKTxvOnA+ PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlz dDpsMTUgbGV2ZWw0IGxmbzE1Ij4NCnRoZSBjb21taXQgZXBvY2ggdHJhY2tzIHRoZSBoaWdoZXN0 IHNlcXVlbmNlIG51bWJlciBwb3BwZWQuPG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPC91 bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjx1bCB0eXBl PSJzcXVhcmUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDE4IGxldmVsMyBsZm8xNiI+DQphdCBkZWNvZGVyLCB3aGVuIGEgaGVhZGVyIGlzIHJlY2Vp dmVkLCBpdCB3aWxsIHBvcCBvZmYgdGhlIGZyb250IG9mIHRoZSBjb21taXQgc2VxdWVuY2VyIHdo aWxlIGl0cyBzZXF1ZW5jZSBudW1iZXIgaXMgJmx0Oz0gdGhlIGp1c3QgcmVjZWl2ZWQgY29tbWl0 IGVwb2NoIChsb29wKS4gJm5ic3A7PG86cD48L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPC91bD4N Cjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPHVsIHR5cGU9InNxdWFyZSI+ DQo8dWwgdHlwZT0ic3F1YXJlIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6 MGluO21zby1saXN0OmwxMiBsZXZlbDQgbGZvMTciPg0KZWFjaCBwb3BwZWQgZW50cnkgaXMgbWFy a2VkIGNvbW1pdHRlZC48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDEyIGxldmVsNCBsZm8xNyI+DQpub3cgdGhlIHJlY2VpdmVk IGhlYWRlciBpcyBkZWNvZGVkLjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjwvdWw+DQo8 L3VsPg0KPHVsIHR5cGU9ImRpc2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsNCBsZXZlbDIgbGZvMTgiPg0KYSBz cGVjaWFsIGNhc2UgdGhhdCBpcyBoYW5kbGVkIGJ5IHRoZSBkeW5hbWljIHRhYmxlIGluIEhUVFAv MiBIUEFDSyBidXQgSSB0aGluayBuZWVkcyB0byBiZSB0cmVhdGVkIGRpZmZlcmVudGx5IGZvciBR VUlDIEhQQUNLLCB0aGF0IGlzIGVudHJpZXMgdGhhdCByZWZlciB0byBvdGhlciBlbnRyaWVzIGZy b20gdGhlIHNhbWUgaGVhZGVyLiAmbmJzcDsgJm5ic3A7Rm9yIHRoaXMgSSBwcm9wb3NlIHRvIGRl ZmluZSBhIG5ldyBkaXN0aW5jdCB0YWJsZSwgYW5kIGNvcnJlc3BvbmRpbmcNCiBkaXN0aW5jdCBl bnRyeSB0eXBlcywgJnF1b3Q7SW50cmEmcXVvdDsuICZuYnNwOyBUaGlzIHdvdWxkIGJlIGFuIGVw aGVtZXJhbCBwZXItaGVhZGVyIHRhYmxlIHRoYXQgZXhpc3RzIG9ubHkgZHVyaW5nIHRoZSB0cmFu c21pdCBwaGFzZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+ DQo8dWwgdHlwZT0iY2lyY2xlIj4NCjx1bCB0eXBlPSJzcXVhcmUiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDE0IGxldmVsMyBsZm8xOSI+DQo8aT5J IGRvbid0IGhhdmUgZGF0YSB5ZXQgZm9yIGhvdyBtYW55IGVudHJpZXMgZmFsbCBpbnRvIHRoaXMg Y2F0ZWdvcnkuPC9pPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC91bD4NCjwvdWw+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIFRodSwgTm92IDMs IDIwMTYgYXQgNTo1NCBQTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFp bC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiA0IE5vdmVt YmVyIDIwMTYgYXQgMDg6MjksIFBhdHJpY2sgTWNNYW51cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBt Y21hbnVzQG1vemlsbGEuY29tIiB0YXJnZXQ9Il9ibGFuayI+cG1jbWFudXNAbW96aWxsYS5jb208 L2E+Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7IHRoaXMgaXMgYSBmYWlybHkgc2lnbmlmaWNhbnQgYml0 IG9mIHN1cmdlcnkgdG8gaDIncyBmb3JtYXRzLCBidXQgZ2l2ZW4gdGhhdDxicj4NCiZndDsgb25l IG9mIHRoZSByZWFsIHF1aWMgb3Bwb3J0dW5pdGllcyBpcyB0byBwZXJmb3JtIGJldHRlciB1bmRl ciBsb3NzIGl0IGNvdWxkPGJyPg0KJmd0OyBiZSB3b3J0aHdoaWxlIHRvIHNldmVyIG9yZGVyaW5n IGRlcGVuZGVuY2llcyBldmVuIGZ1cnRoZXIuIFNlZW1zIGxpa2UgYTxicj4NCiZndDsgcmVhc29u YWJsZSB0aGluZyB0byBpbnZlc3RpZ2F0ZSB0byBtZS48YnI+DQo8YnI+DQpJIGFncmVlLiZuYnNw OyBXZSByaXNrIG5lZ2F0aW5nIG11Y2ggb2YgdGhlIHBlcmZvcm1hbmNlIHdpbnMgYnkgY3JlYXRp bmc8YnI+DQpoZWFkLW9mLWxpbmUgYmxvY2tpbmcgaW4gaGVhZGVyIGZpZWxkcy4mbmJzcDsgV2l0 aCBtYW55IHJlc291cmNlcywgYSBsb3Qgb2Y8YnI+DQp0aGUgY3JpdGljYWwgZWFybHkgaW50ZXJh Y3Rpb25zIGFyZSBlbnRpcmVseSBoZWFkZXIgZmllbGRzLCBhbmQgaHBhY2s8YnI+DQppcyBzdHJp Y3RseSBzZXJpYWxpemVkLjxicj4NCjxicj4NCk1heWJlIHRoaXMgaXMgYSBnb29kIHRpbWUgdG8g cmFpc2UgdGhlIHBvc3NpYmlsaXR5IHRoYXQgd2UgbWlnaHQgbmVlZDxicj4NCmhwYWNrIG1vZGlm aWNhdGlvbnMgYW5kIHRoYXQgdGhvc2UgbW9kaWZpY2F0aW9ucyBtaWdodCBiZW5lZml0IGZyb20g YTxicj4NCm5ldyBkb2N1bWVudC4mbmJzcDsgV2Ugc3BsaXQgaHBhY2sgb3V0IGluIGgyLCBhbmQg aXQgd2FzIGEgbmVhdCBicmVhayB0aGF0PGJyPg0Kd2UgbmV2ZXIgcmVncmV0dGVkLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi cj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+LS0NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpzb2xpZCAjRDUwRjI1IDEuNXB0O3BhZGRp bmc6Mi4wcHQiPkNoYXJsZXMgJ0J1Y2snIEtyYXNpYyZuYnNwO3w8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojNTU1NTU1O2JvcmRlcjpzb2xpZCAjMzM2OUU4IDEuNXB0O3BhZGRpbmc6Mi4wcHQi PiZuYnNwO1NvZnR3YXJlDQogRW5naW5lZXImbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzU1NTU1NTtib3JkZXI6c29saWQgIzAwOTkzOSAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJz cDs8YSBocmVmPSJtYWlsdG86Y2tyYXNpY0Bnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2ty YXNpY0Bnb29nbGUuY29tPC9hPiZuYnNwO3w8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNTU1 NTU1O2JvcmRlcjpzb2xpZCAjRUVCMjExIDEuNXB0O3BhZGRpbmc6Mi4wcHQiPiZuYnNwOyYjNDM7 MQ0KPGEgaHJlZj0idGVsOig0MDgpJTIwNDEyLTExNDEiIHRhcmdldD0iX2JsYW5rIj4oNDA4KSA0 MTItMTE0MTwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzU1NTU1NTtib3JkZXI6c29saWQgI0Q1MEYyNSAxLjVwdDtwYWRkaW5nOjIuMHB0Ij5DaGFy bGVzICdCdWNrJyBLcmFzaWMmbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1 NTtib3JkZXI6c29saWQgIzMzNjlFOCAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDtTb2Z0d2Fy ZQ0KIEVuZ2luZWVyJm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9y ZGVyOnNvbGlkICMwMDk5MzkgMS41cHQ7cGFkZGluZzoyLjBwdCI+Jm5ic3A7PGEgaHJlZj0ibWFp bHRvOmNrcmFzaWNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNrcmFzaWNAZ29vZ2xlLmNv bTwvYT4mbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzU1NTU1NTtib3JkZXI6c29s aWQgI0VFQjIxMSAxLjVwdDtwYWRkaW5nOjIuMHB0Ij4mbmJzcDsmIzQzOzENCiAoNDA4KSA0MTIt MTE0MTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB2708E83F77D3456A26256ADF87A20BN6PR03MB2708namp_-- From nobody Fri Nov 4 21:04:36 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39D86129611 for ; Fri, 4 Nov 2016 21:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5SSbj0bQmTk for ; Fri, 4 Nov 2016 21:04:32 -0700 (PDT) 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 3CB5E129654 for ; Fri, 4 Nov 2016 21:04:32 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id u205so21178861itc.0 for ; Fri, 04 Nov 2016 21:04:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oJWI/pSRNmJaXgLvTS932IN3LhVuGqZwAkXwgai4PzE=; b=eEJlc1rqNb8YVyNump1H68BvbeTzCj4Y+JtyQeVnH1B6cTySCJg72+u3rN5/mIGguI 1xnProtDDcLV0l7Sya63c1js8mLE+so6zqooEB2XREIwnot/USKFBmXYVU024GBrG1fJ XU7l/qnxh2og/Rqym8BqKaBY7M8XPv92fxdVnSe3kVRwlVjN2+W38XqgPsGHsFuWvMMl iroOGcgPeIb93ZU/Ugt1ZmcBNRFWy0/xO+ppMUdcQf9GAPUZuHyzNSD/Hipos9H3KbNE sRxIAhPeGBaT3yk3QADDMyB7itGC9MEjW/Ssp3cud3bybkyuXyj6TcBFf8qTwf08v8g/ Dn5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oJWI/pSRNmJaXgLvTS932IN3LhVuGqZwAkXwgai4PzE=; b=UNxouVqCYLb9W3sqUnaCNDHza3/Z1wAcRoerFC1gn3bf26ui/9gAcf06runilmYcGF 6h5sjhOzeaRQhRE44J0i9ewDdiGfu1AkDlZelfs2L/FuXhaHMzWM+J3R6cXuKMN6EWks qBLI24mJyToPEvDLf8juJLGFexZYxsUhSbZeKAZ1jeL4M+VwihzHNcAcI2kb4GzWzHam 80EkEsAuMnyLNFkqpNZh00DgA+Z23Ls1B0uapLbWlggzpkJ/AFYnS8EL7JknVV6Q7J2O 9FTFoKtwTIja/ZpLfdgShIWAepy7KGV8+FSr0isECsy7ZRFvGH1drGoQkICqAdBK7/O6 ifKw== X-Gm-Message-State: ABUngvfqcnoD3N91Z1vSoXJ0pnI2+sJdqfH31x4JRldf7hukIv0myuFV7JyVl+CujYv+j4TrVQX5oYYHqpPkEvSt X-Received: by 10.107.26.15 with SMTP id a15mr3464880ioa.103.1478318671350; Fri, 04 Nov 2016 21:04:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.1.2 with HTTP; Fri, 4 Nov 2016 21:04:10 -0700 (PDT) In-Reply-To: References: From: "Charles 'Buck' Krasic" Date: Fri, 4 Nov 2016 21:04:10 -0700 Message-ID: To: Mike Bishop Content-Type: multipart/alternative; boundary=001a113fd72645be57054085e331 Archived-At: Cc: "quic@ietf.org" , Martin Thomson , Patrick McManus Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 05 Nov 2016 04:04:35 -0000 --001a113fd72645be57054085e331 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 4, 2016 at 4:20 PM, Mike Bishop wrote: > Oh, granted that it=E2=80=99s not sufficient to call it an encoder strate= gy and > just keep using HPACK. I=E2=80=99m just making the argument that it need= not be > the basis of the protocol design =E2=80=93 the protocol can enable an enc= oder that > wants to do such a strategy to do so without mandating it. I really don= =E2=80=99t > want a dual HPACK-and-QPACK approach =E2=80=93 maybe we can define a lega= cy version > where HPACK on stream 3 is used, but at worst case, you should select and > commit to one for a connection. > Yea, all or nothing per connection might be the simplest option. That's certainly my plan for my initial experimentation. > > > I also agree that judging whether you=E2=80=99ll be within the same packe= t could > lead to loops. Perhaps better left alone for most implementations, that= =E2=80=99s > fair. > > > > The thing that strikes me is that the HTTP/2 framing layer is essentially > message-based (frames), while from the application layer, QUIC is purely > stream-based. > Right, but streams are so lightweight, the philosophy is that you can use QUIC streams as messages. You're of course free to frame messages on your own within a stream. > I=E2=80=99m thinking that for HTTP-over-QUIC, we define a light-weight fr= aming to > differentiate headers from body and move the headers back on-stream, if w= e > can. Maybe just a couple bytes of type identification, length, and enoug= h > context to differentiate intermediate header blocks from final response > headers from body from trailers=E2=80=A6? PUSH_PROMISE probably lives he= re, too. > > > Yes, you could imagine something like that, maybe even use something very close to HTTP/2 DATA frames. I don't think overhead is such a big deal either way. I think the big simplification of separate headers streams are around cancellation. Keeping the encoder/decoder state perfectly in sync will be much harder if the headers share fate with the body. I believe a whole lot of complexity will be avoided by having headers reliably delivered, even when HTTP/2 transactions and corresponding body streams are cancelled/RST. > *From:* Charles 'Buck' Krasic [mailto:ckrasic@google.com] > *Sent:* Friday, November 4, 2016 12:36 PM > *To:* Mike Bishop > *Cc:* Martin Thomson ; quic@ietf.org; Patrick > McManus > > *Subject:* Re: [QUIC] h2 mapping - hpack dynamic table by reference > > > > > > > > On Fri, Nov 4, 2016 at 11:16 AM, Mike Bishop > wrote: > > This is certainly interesting, but feels more like a wise strategy for an > encoder to employ (if you want to avoid blocking, don=E2=80=99t reference= a header > that hasn=E2=80=99t been ACKed) than an independent change to the protoco= l. > > > > I'd be happy if it could be done with just encoder strategy, but I don't > think it can. Hence the extra sequence numbers sent, and the modified > logic at the decoder. That said, I have definitely trying to make the > delta as small and sharply focused on HOL as possible. > > > > Think about using, say, the unique-index-per-entry approach (which > requires blocking on unknown indices) =E2=80=93 an encoder that wanted to= be smart > could do as you describe below and emit literals until the frame has been > ACK=E2=80=99d. (Unless the frame was going in the same packet as the ori= ginal > value, if it wants to be even smarter=E2=80=A6.) > > > > The same packet as original value is interesting, but I think possibly > super hard. There's a circular dependency of estimating the compressed > header size as part of knowing whether they will go in the same packet, i= n > order decide on representation strategy that will turn effect compressed > header size. > > > > Maybe alternative, more or less crazy, approach would be use some > combination of pseudo requests/pushes to prime the dictionary? > > > > An encoder that didn=E2=80=99t want the complexity would just emit the mo= st > compact representation it could, knowing it might cause some blockage on > the receiver. > > > > That's what I was saying wrt "status quo transactions". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > just sticking with the current headers over stream 3 would allow for the > prefers more compact representation option. > > > > > > The two-streams-per-request feels jarring to me. For HTTP, at least, you > have a reasonably well-defined series of =E2=80=9CHeaders+, Body?, Header= s?=E2=80=9D in > each direction for each transaction. I don=E2=80=99t think you=E2=80=99l= l get rid of the > need to have some framing around the headers; I=E2=80=99m not convinced (= but > willing to be) that the complexity of managing two affiliated streams is > greater than that of needing framing around the body as well because it > shares a stream with the headers. > > > > Right. Our QUIC implementation does layer HTTP/2 HEADER frames above QUI= C > STREAM frames. That would be true in this design also. However, the > status quo does allow the body data to be sent without any extra framing > above QUIC STREAM frames. I didn't see an obvious way not to lose that > latter property if headers and body are in the same stream. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Charles 'Buck' > Krasic > *Sent:* Friday, November 4, 2016 10:28 AM > *To:* Martin Thomson > *Cc:* quic@ietf.org; Patrick McManus > *Subject:* Re: [QUIC] h2 mapping - hpack dynamic table by reference > > > > I have indeed been thinking about this very issue. Here is an outline of > what I've got so far. I think it's not so far from what others are > thinking. > > > > I call the new scheme QUIC HPACK (as opposed to HTTP/2 HPACK for status > quo). > > - Premise: certain indexed entries should be avoided, namely indexed > entries that would refer to entries that originate from headers *that > are still in flight*, because packet loss on those other headers would > HOL block the current stream. > - The idea of QUIC HPACK then is to mark updates to the dynamic table > as "pending" initially, and commit them later when the header they > originate from is no longer in flight (i.e. acked to sender). Indexe= d > entries would only be generated against dynamic tables entries that ar= e > committed. I.e., when encoding an entry, if there is a matching but > pending entry in the dynamic table, generate a literal instead of inde= xed. > > > - I have collected some data to measure the time between when entries > are added to the table, and the creation of subsequent indexed entr= ies that > refer to them. It suggests that a small fraction of HTTP/2 HPACK = indexed > entries (under standard HPACK) would become literals under QUIC HPA= CK. > ~50% are > 10s apart, and ~90% are > 50ms apart. > > > - the new behavior could be optional, individual HTTP/2 transactions > to select between this new scheme and the status quo, trading between > compression and HOL freedom. Status quo transactions would still use > stream 3 (HTTP/2 HPACK). > > Algorithm/design details: > > - instead using the shared headers stream (#3), each HTTP/2 > transaction has a dedicated stream for headers > > > - i.e. each HTTP/2 transaction has two QUIC streams: 1 for headers > (incl. trailers if used), 1 for body. > - 1 bit of the stream id will be used to classify the QUIC stream > as headers or body. > > > - like the current global header stream, these new headers streams > will protected from RSTs. > > > - *QUIC HPACK algorithm will process all headers, even if the > corresponding HTTP/2 transaction may have been cancelled and = corresponding > body stream RST*. > > > - QUIC HPACK encode and decode are divided into two phases each: > transmit and commit. > > > - in addition to the info already included in HTTP/2 header frames, > each header transmitted from encoder to decoder will include a pair= of > sequence numbers, the encode sequence number and the commit epoch, > described below. > > > - *the pair will always have the property that commit epoch < encode > sequence number.* > > > - first phase (transmit): header is encoded/decoded, but updates to > dynamic table are marked pending. > > > - when processing a header, the encoder will decide which entries > should be added to the dynamic table, as in current HPACK, but t= he entry in > the dynamic table will have a "pending" flag set, preventing it = from being > a reference for indexed entries yet. > - the encoder assigns a sequence number to each header (block), > the total number of headers encoded so far (encode epoch). > - the encoder/decoder enters each header into a commit sequencer > (ordered queue) to be used in the second phase. > - *the header is transmitted from encoder to decoder. the > decoder can always decode immediately, because this algorithm pr= events a > header from referring to other headers that might still be in fl= ight.* > > > - second phase (commit): once fully transmitted, pending updates are > committed, in the same order they were encoded. > > > - at encoder, when a previously transmitted header has been acked, the > entry in the commit-sequencer is marked committed. > > > - the front of the sequencer is popped while the front is a committed > entry. (loop) > - the commit epoch tracks the highest sequence number popped. > > > - at decoder, when a header is received, it will pop off the front of > the commit sequencer while its sequence number is <=3D the just = received > commit epoch (loop). > > > - each popped entry is marked committed. > - now the received header is decoded. > > > - a special case that is handled by the dynamic table in HTTP/2 HPACK > but I think needs to be treated differently for QUIC HPACK, that is= entries > that refer to other entries from the same header. For this I pro= pose to > define a new distinct table, and corresponding distinct entry types= , > "Intra". This would be an ephemeral per-header table that exists = only > during the transmit phase. > > > - *I don't have data yet for how many entries fall into this category.= * > > > > On Thu, Nov 3, 2016 at 5:54 PM, Martin Thomson > wrote: > > On 4 November 2016 at 08:29, Patrick McManus wrote= : > > this is a fairly significant bit of surgery to h2's formats, but given > that > > one of the real quic opportunities is to perform better under loss it > could > > be worthwhile to sever ordering dependencies even further. Seems like a > > reasonable thing to investigate to me. > > I agree. We risk negating much of the performance wins by creating > head-of-line blocking in header fields. With many resources, a lot of > the critical early interactions are entirely header fields, and hpack > is strictly serialized. > > Maybe this is a good time to raise the possibility that we might need > hpack modifications and that those modifications might benefit from a > new document. We split hpack out in h2, and it was a neat break that > we never regretted. > > > > > > -- > > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 > > > > > > -- > > Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) > 412-1141 > --=20 Charles 'Buck' Krasic | Software Engineer | ckrasic@google.com | +1 (408) 412-1141 --001a113fd72645be57054085e331 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 4, 2016 at 4:20 PM, Mike Bishop <Michael.Bishop= @microsoft.com> wrote:

Oh, granted that it=E2=80=99s not sufficient to call= it an encoder strategy and just keep using HPACK.=C2=A0 I=E2=80=99m just m= aking the argument that it need not be the basis of the protocol design =E2= =80=93 the protocol can enable an encoder that wants to do such a strategy to do so without mandating it.=C2=A0 I really don=E2=80=99t wan= t a dual HPACK-and-QPACK approach =E2=80=93 maybe we can define a legacy ve= rsion where HPACK on stream 3 is used, but at worst case, you should select= and commit to one for a connection.

Yea, = all or nothing per connection might be the simplest option.=C2=A0 That'= s certainly my plan for my initial experimentation.=C2=A0

=

=C2=A0

I also agree that judging whether you=E2=80=99ll be = within the same packet could lead to loops.=C2=A0 Perhaps better left alone= for most implementations, that=E2=80=99s fair.

=C2=A0

The thing that strikes me is that the HTTP/2 framing= layer is essentially message-based (frames), while from the application la= yer, QUIC is purely stream-based.=C2=A0

<= br>
Right, but streams are so lightweight, the philosophy is that= you can use QUIC streams as messages. You're of course free to frame m= essages on your own within a stream.
=C2=A0

I=E2=80=99m= thinking that for HTTP-over-QUIC, we define a light-weight framing to differentiate headers from body and move the headers back on-stream, if we= can.=C2=A0 Maybe just a couple bytes of type identification, length, and e= nough context to differentiate intermediate header blocks from final respon= se headers from body from trailers=E2=80=A6?=C2=A0 PUSH_PROMISE probably lives here, too.

=C2=A0

Yes, = you could imagine something like that, maybe even use something very close = to HTTP/2 DATA frames. =C2=A0 I don't think overhead is such a big deal= either way.

I think the big simplification of sep= arate headers streams are around cancellation.=C2=A0 Keeping the encoder/de= coder state perfectly in sync will be much harder if the headers share fate= with the body. =C2=A0 I believe a whole lot of complexity will be avoided = by having headers reliably delivered, even when HTTP/2 transactions and cor= responding body streams are cancelled/RST. =C2=A0=C2=A0
=C2=A0

From: Charles 'Buck' Krasic [mailto:<= a href=3D"mailto:ckrasic@google.com" target=3D"_blank">ckrasic@google.com]
Sent: Friday, November 4, 2016 12:36 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Martin Thomson <martin.thomson@gmail.com>; quic@ietf.org; Patrick McManus <pmcmanus@mozilla.com= >


Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference=

=C2=A0

=C2=A0

=C2=A0

On Fri, Nov 4, 2016 at 11:16 AM, Mike Bishop <Michael.Bish= op@microsoft.com> wrote:

This is certainly interesting, but feels more like a= wise strategy for an encoder to employ (if you want to avoid blocking, don= =E2=80=99t reference a header that hasn=E2=80=99t been ACKed) than an independent change to the protocol.=C2=A0

=C2=A0

I'd be happy if it could be done with just encod= er strategy, but I don't think it can. =C2=A0 Hence the extra sequence = numbers sent, and the modified logic at the decoder. =C2=A0 =C2=A0That said= , I have definitely trying to make the delta as small and sharply focused on HOL as possible.

=C2=A0

Think about using, say, the unique-index-per-entry a= pproach (which requires blocking on unknown indices) =E2=80=93 an encoder t= hat wanted to be smart could do as you describe below and emit literals until the frame has been ACK=E2=80=99d.=C2=A0 (Unless the fr= ame was going in the same packet as the original value, if it wants to be e= ven smarter=E2=80=A6.)=C2=A0

=C2=A0

The same packet as original value is interesting, bu= t I think possibly super hard.=C2=A0 There's a circular dependency of e= stimating the compressed header size as part of knowing whether they will g= o in the same packet, in order decide on representation strategy that will turn effect compressed header size.

=C2=A0

Maybe alternative, more or less crazy, approach woul= d be use some combination of pseudo requests/pushes to prime the dictionary= ?

=C2=A0

An encoder that didn=E2=80=99t want the complexity w= ould just emit the most compact representation it could, knowing it might c= ause some blockage on the receiver.

=C2=A0

That's what I was saying wrt "status quo tr= ansactions".

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

just sticking with the current headers over stream 3= would allow for the prefers more compact representation option.=C2=A0

=C2=A0

=C2=A0

The two-streams-per-request feels jarring to me.=C2= =A0 For HTTP, at least, you have a reasonably well-defined series of =E2=80= =9CHeaders+, Body?, Headers?=E2=80=9D in each direction for each transactio= n.=C2=A0 I don=E2=80=99t think you=E2=80=99ll get rid of the need to have some fram= ing around the headers; I=E2=80=99m not convinced (but willing to be) that = the complexity of managing two affiliated streams is greater than that of n= eeding framing around the body as well because it shares a stream with the headers.

=C2=A0

Right.=C2=A0 Our QUIC implementation does layer HTTP= /2 HEADER frames above QUIC STREAM frames.=C2=A0 That would be true in this= design also.=C2=A0 However, the status quo does allow the body data to be = sent without any extra framing above QUIC STREAM frames.=C2=A0 I didn't see an obvious way not to lose that latter prop= erty if headers and body are in the same stream. =C2=A0=C2=A0=

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Charles 'Buck' Krasic
Sent: Friday, November 4, 2016 10:28 AM
To: Martin Thomson <martin.thomson@gmail.com>
Cc: quic@ietf.org= ; Patrick McManus <pmcmanus@mozilla.com>
Subject: Re: [QUIC] h2 mapping - hpack dynamic table by reference=

=C2=A0

I have indeed been thinking about this very issue.= =C2=A0 Here is an outline of what I've got so far.=C2=A0 I think it'= ;s not so far from what others are thinking.

=C2=A0

I call the new scheme QUIC HPACK (as opposed to HTTP= /2 HPACK for status quo). =C2=A0=C2=A0

  • Premise: =C2=A0certain indexed entries should be avoided, namely indexed en= tries that would refer to entries that originate from headers that are still in flight, because packet loss on those other headers= would HOL block the current stream.
  • The idea of QUIC HPACK then is to mark updates to the dynamic table as &quo= t;pending" initially, and commit them later when the header they origi= nate from is no longer in flight (i.e. acked to sender). =C2=A0 Indexed ent= ries would only be generated against dynamic tables entries that are committed.=C2=A0 I.e., when encoding an entry, if there i= s a =C2=A0matching but pending entry in the dynamic table, generate a liter= al instead of indexed.
    • I have collected some data to measure the time between when entries are add= ed to the table, and the creation of subsequent indexed entries that refer = to them. =C2=A0 It suggests that a small fraction of HTTP/2 HPACK indexed e= ntries (under standard HPACK) would become literals under QUIC HPACK. =C2=A0=C2=A0~50% are > 10s apart, and ~90% a= re > 50ms apart.
  • the new behavior could be optional, individual HTTP/2 transactions to selec= t between this new scheme and the status quo, trading between compression a= nd HOL freedom. =C2=A0 Status quo transactions would still use stream 3 (HT= TP/2 HPACK).

Algorithm/design details:

  • instead using the shared headers stream (#3), each HTTP/2 transaction has a= dedicated stream for headers
    • i.e. each HTTP/2 transaction has two QUIC streams: 1 for headers (incl. tra= ilers if used), 1 for body.
    • 1 bit of the stream id will be used to classify the QUIC stream as headers = or body.
      • like the current global header stream, these new headers streams will prote= cted from RSTs.
        • QUIC HPACK algorithm will process all headers, even if the corresponding= HTTP/2 transaction may have been cancelled and corresponding body stream R= ST.
  • QUIC HPACK encode and decode are divided into two phases each: transmit and= commit. =C2=A0=C2=A0
    • in addition to the info already included in HTTP/2 header frames, each head= er transmitted from encoder to decoder will include a pair of sequence numb= ers, the encode sequence number and the commit epoch, described below.
      • =C2=A0the pair will always have the property that commit epoch < enco= de sequence number.
    • first phase (transmit): =C2=A0header is encoded/decoded, but updates to dyn= amic table are marked pending.
      • when processing a header, the encoder will decide which entries should be a= dded to the dynamic table, as in current HPACK, but the entry in the dynami= c table will have a "pending" flag set, preventing it from being = a reference for indexed entries yet.
      • the encoder assigns a sequence number to each header (block), the total num= ber of headers encoded so far (encode epoch).=C2=A0
      • the encoder/decoder enters each header into a commit sequencer (ordered que= ue) to be used in the second phase.
      • the header is transmitted from encoder to decoder. =C2=A0the decoder can= always decode immediately, because this algorithm prevents a header from r= eferring to other headers that might still be in flight.<= /li>
    • second phase (commit): =C2=A0once fully transmitted, =C2=A0pending updates = are committed, in the same order they were encoded.
      • at encoder, when a previously transmitted header has been acked, the entry = in the commit-sequencer is marked committed.
        • the front of the sequencer is popped while the front is a committed entry. = (loop)
        • the commit epoch tracks the highest sequence number popped.
      • at decoder, when a header is received, it will pop off the front of the com= mit sequencer while its sequence number is <=3D the just received commit= epoch (loop). =C2=A0
        • each popped entry is marked committed.
        • now the received header is decoded.
    • a special case that is handled by the dynamic table in HTTP/2 HPACK but I t= hink needs to be treated differently for QUIC HPACK, that is entries that r= efer to other entries from the same header. =C2=A0 =C2=A0For this I propose= to define a new distinct table, and corresponding distinct entry types, "Intra". =C2=A0 This would be an ephemeral= per-header table that exists only during the transmit phase.=
      • I don't have data yet for how many entries fall into this category.<= /i>

=C2=A0

On Thu, Nov 3, 2016 at 5:54 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:

On 4 November 2016 at= 08:29, Patrick McManus <pmcmanus@mozilla.com> wrote:
> this is a fairly significant bit of surgery to h2's formats, but g= iven that
> one of the real quic opportunities is to perform better under loss it = could
> be worthwhile to sever ordering dependencies even further. Seems like = a
> reasonable thing to investigate to me.

I agree.=C2=A0 We risk negating much of the performance wins by creating head-of-line blocking in header fields.=C2=A0 With many resources, a lot of=
the critical early interactions are entirely header fields, and hpack
is strictly serialized.

Maybe this is a good time to raise the possibility that we might need
hpack modifications and that those modifications might benefit from a
new document.=C2=A0 We split hpack out in h2, and it was a neat break that<= br> we never regretted.



=C2=A0

--

Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|ckrasic@goo= gle.com=C2=A0|=C2=A0+1 (408) 412-1141



=C2=A0

--

Charles 'Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|ckrasic@goo= gle.com=C2=A0|=C2=A0+1 = (408) 412-1141




--
Charles '= ;Buck' Krasic=C2=A0|=C2=A0Software Engineer=C2=A0|=C2=A0ckrasic@google.com=C2=A0|=C2=A0+1 (408) 412-1141

--001a113fd72645be57054085e331-- From nobody Fri Nov 4 21:15:13 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561251293FE for ; Fri, 4 Nov 2016 21:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5i1Hg6Y35zAV for ; Fri, 4 Nov 2016 21:15:10 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABBFC1293FB for ; Fri, 4 Nov 2016 21:15:10 -0700 (PDT) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1c2sNo-0002pD-R0 for quic@ietf.org; Sat, 05 Nov 2016 05:15:09 +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 1c2sNk-0002ed-JR for quic@ietf.org; Sat, 05 Nov 2016 00:15:06 -0400 Received: (qmail 12143 invoked from network); 5 Nov 2016 04:15:03 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.170]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Nov 2016 04:15:03 -0000 From: "Christian Huitema" To: "'Dragana Damjanovic'" , "'Martin Thomson'" References: In-Reply-To: Date: Fri, 4 Nov 2016 21:14:59 -0700 Message-ID: <057801d2371b$2d47ca90$87d75fb0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIFwFqE43UepxeEE7pkpcPE9X7NSQJc8o9/AVkCjKECHwbmUQKnPYW2oB7MVHA= Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD+s2 ReFr0A5+1CI7pxVabQoHHTW1/Du2Kv0GGZkVE0/tdcmtTcWSOKD5RASVzg27in97Vz6IRLbhBYyX 7lr6B6d5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdbNYJZHmTztvoh1m9SAwL4/i885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suokd0uMbDf1yoqZkUeJni0+RQZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVKnG+eTs8kbKBy2XcsLzqKfmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV6YO2/mqpOb7Q80SeXyngcEZA0ovkdUHlhxng/6M5IV+I73x9yTpqy088VxyqIsKLEe bp9tI6dJK7GvNGOBzee8 X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.234 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.07) X-Recommended-Action: accept Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Comment on draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 05 Nov 2016 04:15:12 -0000 On Friday, November 4, 2016 2:02 AM, Dragana Damjanovic wrote: > On Fri, Nov 4, 2016 at 1:46 AM, Martin Thomson = wrote: >>On 4 November 2016 at 01:14, Dragana Damjanovic wrote: >> Sorry I have not looked at you repo, I was just reading the last 01 = draft. > > Don't apologize, it's my fault :) Well, I am looking at the version on Martin's repo, and there are a few = things that I don't get. The flow diagram in 2.1. Handshake Overview supposedly mimics the = diagram in section 2.3. Zero-RTT Data of the TLS 1.3 spec, except there = is a minor difference, probably an oversight, the "(Finished)" message = after the Hello and extensions. There is no such message in the TLS 1.3 = diagram, although there might have been in a prior version. The other = difference is the timing of early data.=20 The text in the introduction of section 3 says that "QUIC Stream 1 = carries a complete TLS connection. This includes the TLS record layer in = its entirety." That means that we have two potential layers of = encryption: the QUIC record protection, which is protected by the keys = described as @A, @B, @C in the diagram; and the TLS record layer, which = protects some of the messages sent on stream 1. @A is clear text. The = draft says that "The server sends its handshake messages without = protection (@A)". That's true as far as the QUIC record layer is = concerned, not so true for the TLS layer itself. In the same vein, I would like to understand why the last flight of TLS = client messages (end of early data, finished) are protected by the 0-RTT = key (@B) rather than the 1-RTT key (@C). Isn't end-of-early-data = triggering a transition to @B? In fact, why are we concerned with early = data on stream 1? If the client sends early data, it will be probably = using stream 3, and the TLS record layer will not be engaged. -- Christian Huitema From nobody Sat Nov 5 01:14:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD7A12940F for ; Sat, 5 Nov 2016 01:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.418 X-Spam-Level: X-Spam-Status: No, score=-8.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCHHkJ5VNCsN for ; Sat, 5 Nov 2016 01:14:05 -0700 (PDT) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84EE81293E8 for ; Sat, 5 Nov 2016 01:14:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.31,448,1473145200"; d="scan'208";a="154258490" Received: from vmwexchts01-prd.hq.netapp.com ([10.122.105.12]) by mx143-out.netapp.com with ESMTP; 05 Nov 2016 01:08:52 -0700 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by VMWEXCHTS01-PRD.hq.netapp.com (10.122.105.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 5 Nov 2016 01:09:02 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Sat, 5 Nov 2016 01:09:02 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cd5CKmUBX5wQsgyuqM1ScdaOcINl4j60W62DP291WMs=; b=Ae0N324axlY8uSxMIA+PgOdMIAVZaEnZRIHhs0pz8GPzD6umG5DsAlgJD90p/D5fFI2RAK81qSdjhNTU+L0CVbl1eFSrWuItU+QVt71fODj2n0ThAT2y4qC0cBaRwUPgVmXD8XWd60sJDKWX6hejzXOpU9GJ1CkOGVu7R9xSCnQ= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1155.namprd06.prod.outlook.com (10.160.157.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Sat, 5 Nov 2016 08:09:01 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0707.006; Sat, 5 Nov 2016 08:09:00 +0000 From: "Eggert, Lars" To: Patrick McManus Thread-Topic: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order Thread-Index: AQHSNt6kd+iyBE6wJkezIDlx1WlgV6DKCfuA Date: Sat, 5 Nov 2016 08:09:00 +0000 Message-ID: <08188AC9-60C7-4E71-AE01-54D9FD487918@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a61:31d8:9c01:a0ba:6217:872d:f2bc] x-ms-office365-filtering-correlation-id: d50bd906-c45a-4476-8789-08d40553002b x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1155; 7:JeqcArmNmmk+GEaoQ85Huz1KSXago7f/f+iEz3Ai5R37v6TAJlQGbEsGRpp+A1yObyVWjiF8AOJCOO3zX/GiWlNbCs8dFC4y41VL9ZZ9n9VzZLiDSTbCH2B5ui1in/KCag5u9cgo1TdoJOWga9NMgE0tkIU1FocDh8xVpJBiJq2wdwQMe7hGXU+9Ys2Uavx3hvdgIrvMi8SDdZfycAYujT1VCELun6/2lT7PN5PsyYSGR1fbOxe/8eSirHa1lkKkeu2E04HkdDVbWdTIQ63nMfZKECDNjFV/u/bkIkohnO5BPQDLvzSQQTXSpKJo0G348Jlva2uwAaINRexhNtXsUQsMpYMstSpB+IabJ4q1+sg= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0601MB1155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6042046)(6043046); SRVR:BN3PR0601MB1155; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1155; x-forefront-prvs: 011787B9DD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(377424004)(199003)(24454002)(92566002)(105586002)(6916009)(305945005)(7736002)(2900100001)(57306001)(2950100002)(86362001)(6116002)(19580395003)(3280700002)(106116001)(102836003)(97736004)(106356001)(19580405001)(99286002)(7846002)(4326007)(110136003)(122556002)(586003)(2906002)(82746002)(83716003)(36756003)(3660700001)(87936001)(5660300001)(33656002)(10400500002)(68736007)(8676002)(8936002)(77096005)(81166006)(5002640100001)(81156014)(50986999)(189998001)(76176999)(50226002)(101416001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1155; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <3C82280753F1EE4D8959158B58D50992@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Nov 2016 08:09:00.8879 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1155 X-OriginatorOrg: netapp.com Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 05 Nov 2016 08:14:06 -0000 On 2016-11-04, at 22:01, Patrick McManus wrote: > Second, draft-hamilton-quic-transport-protocol-01 boldly uses little endi= an encoding. Ya gotta admire that chutzpah in an IETF draft :) From a proce= ssor alignment pov, it makes perfect sense and I would support it on a clea= n slate or on a well layered protocol. quic however, by design, is neither = of those things. Chair hat off: That totally threw me when I started to implement, because a= pparently my mind is trained to automatically insert htonl() etc., and it t= ook me a minute or so to understand why my code was producing incorrectly l= aid out packets. Lars= From nobody Sat Nov 5 01:57:52 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8574129407 for ; Sat, 5 Nov 2016 01:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_HELO_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 58YcqnpgqrsX for ; Sat, 5 Nov 2016 01:57:49 -0700 (PDT) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC2A1293E8 for ; Sat, 5 Nov 2016 01:57:48 -0700 (PDT) Received: from [192.168.1.101] (p508F1FF0.dip0.t-ipconnect.de [80.143.31.240]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 7FC98721E281E; Sat, 5 Nov 2016 09:57:41 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Michael Tuexen In-Reply-To: <08188AC9-60C7-4E71-AE01-54D9FD487918@netapp.com> Date: Sat, 5 Nov 2016 09:57:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <08188AC9-60C7-4E71-AE01-54D9FD487918@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "quic@ietf.org" , Patrick McManus Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 05 Nov 2016 08:57:51 -0000 > On 5 Nov 2016, at 09:09, Eggert, Lars wrote: >=20 > On 2016-11-04, at 22:01, Patrick McManus wrote: >> Second, draft-hamilton-quic-transport-protocol-01 boldly uses little = endian encoding. Ya gotta admire that chutzpah in an IETF draft :) =46rom = a processor alignment pov, it makes perfect sense and I would support it = on a clean slate or on a well layered protocol. quic however, by design, = is neither of those things. >=20 > Chair hat off: That totally threw me when I started to implement, = because apparently my mind is trained to automatically insert htonl() = etc., and it took me a minute or so to understand why my code was = producing incorrectly laid out packets. I guess if you really want to write a portable implementation you need = to insert functions, just not hton[sl](). You need to write htole[sl] and use them... Best regards Michael >=20 > Lars From nobody Sat Nov 5 02:23:48 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC701294E3 for ; Sat, 5 Nov 2016 02:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id psrufG-oI2A0 for ; Sat, 5 Nov 2016 02:23:45 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 413B8129496 for ; Sat, 5 Nov 2016 02:23:44 -0700 (PDT) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 2006E1A0A4A; Sat, 5 Nov 2016 10:23:13 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CEB37ECE-15EE-4075-A538-678BC86D71CF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Sat, 5 Nov 2016 10:23:12 +0100 Message-Id: References: To: Patrick McManus X-Mailer: Apple Mail (2.3124) Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 05 Nov 2016 09:23:47 -0000 --Apple-Mail=_CEB37ECE-15EE-4075-A538-678BC86D71CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Patrick, all, > On 04 Nov 2016, at 22:01, Patrick McManus = wrote: >=20 > Hi All - two more things to raise.. one I hope editorial and one = design - when we start doing github, I'll open issues to track there. >=20 > First, editorially draft-hamilton-quic-transport-protocol-01 generally = refers to packet numbers instead of sequence numbers. There seem to be = two exceptions to that - in 6.2 and the identifier = SEQUENCE_NUMBER_LIMIT_REACHED. OTOH = https://tools.ietf.org/html/draft-thomson-quic-tls-01 almost always = refers to sequence numbers (with one exception). I think SN is not = defined, but PN is and it should standardize on the PN language. >=20 > Second, draft-hamilton-quic-transport-protocol-01 boldly uses little = endian encoding. Ya gotta admire that chutzpah in an IETF draft :) =46rom = a processor alignment pov, it makes perfect sense and I would support it = on a clean slate or on a well layered protocol. quic however, by design, = is neither of those things. >=20 > So we get into a bit of a mess - the packet number is little endian = when it appears in transport fields, but in the TLS document the AEAD = nonce is formed by padding the big endian representation of the same = number. That smells like a bug waiting to happen. Likewise a Stream ID = in a transport STREAM frame would be big endian, but when that same ID = is encoded via 7540 rules from the h2-mapping document (e.g. in a = PUSH_PROMISE) then it needs to be big endian. Again - seems like a = footgun. So while I salute the valiant effort to go little endian, I = think we ought to bow to the constraints this effort faces and go the = traditional all network byte order path. Either +1 or +16777216 to this, depending on your native byte order. Even without the interactions with TLS and H2, a QUIC header merged with = a UDP header would have two byte orders (big in the ports and length, = little everywhere else). The currently dominant processor architectures may be little-endian = (though, given that the byte-order conversion calls pretty much always = operate on cache, they're basically free) but we've spent decades = training everyone that the network is big endian, and this decision = itself also has a rationale grounded in transparency and diagnosability = for humans looking at packet dumps: most of our notations for dealing = with numbers are big-endian. So going little-endian seems like an = esoteric choice with a whole lot more downside than upside. Cheers, Brian --Apple-Mail=_CEB37ECE-15EE-4075-A538-678BC86D71CF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYHaUAAAoJEIoSt78L6kajHtEQAJORUnGg1cL1JQEPj2VADfju 1GXlOOAKcc/amaFKcAh80vFr1pAbCoHOS3uVIESw7Sh1eyXKUbmH3utF5LuTYgE+ jUTAuVV7BMOw3HB7LpW5ANmFxMGOSioJd7tb0PtCTiJLbWdUQxP70VFpbhDzq4Mr aUu2b+ABH4f4ubuovUdhkz3zlBXzHhRMq3BMz+bKnNKASfwDq4M/Cxk8PO9lWmKX 2Rxqv98H01l8h+YOFQrTbvhcVTf2+Waw80CP/5n4U0lRVcvAeunJ/4FM0/B31LqY 8taLc4aydfsbUfIa+j8/7FYAPNzn1YHMyQtDxb3gOduBquQAHKj5MlKrHEE0kNpb ZXS1bMoxogxebYisNyLPavauLE4nVCyvkCeOjs0RuIaX+v5t9e8kZ57bVS34+f2K 66fuqzRb7E2vj8RQARAxAgLURrDMBQhh3YEN4F/FgpLWBTjBZHKfYeINmiLXRvz0 +bnFG4SkDsDidbe8mtbIcQHf7niUISfJrlFNCHASHAmkNClxOkczCFLFGv8iyOnw WRQ9Td3L5EF5c11dopHR4vAutb+wP5hERzAITQ31zrzOD9M7134MtzxkUXrzX3/Z ILsRkQBtdXcJu93mUO0PhumqgcjS5qFoVuVv5NtA9iOyOPw9b5XkGTGoaOw52ZAJ P8UwMVZIyxIFQoxvIPe6 =hTwb -----END PGP SIGNATURE----- --Apple-Mail=_CEB37ECE-15EE-4075-A538-678BC86D71CF-- From nobody Sun Nov 6 11:53:28 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B637E1293F2 for ; Sun, 6 Nov 2016 11:53:26 -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, 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 (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAl5Ft3XjC70 for ; Sun, 6 Nov 2016 11:53:25 -0800 (PST) Received: from BAY004-OMC3S25.hotmail.com (bay004-omc3s25.hotmail.com [65.54.190.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64E341293F0 for ; Sun, 6 Nov 2016 11:53:25 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com ([65.54.190.189]) by BAY004-OMC3S25.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 6 Nov 2016 11:53:25 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Gwe0uj2KFIYkf7P9/f23sOZsMK1JYHqHV/hQMfAZ2Tg=; b=aSqXaZX5NTRQ1MykB+drwTGLkb8hCnS4Fo2/licuyWVlqMPH+ORRJUkkKnXm7CfkaqcSIGVyAsu6ZgNTOGixGBciUYQJ796BfPeyLz4/FgIZITTPHh/DycWRQPkVm12KrKg8p0Ae7Ql26x0xWp/pEMCS0TCk80BoXs1foN6HqU9G+YfDPQkRnYHYnCJQb2tVYiyMK36eJbLzOulK5WktD4OfE1q8hbI3Zug8ftveWIRKpX0IZtv7I84DKwLZq9r/edshcuBlR2p7h+lFPUlA2jCUIPSrnLQM6Ws5p+A8xXq/awUqUzyXMDSch57mhbgOA9xc8/wiTY/vY0vTQWi/tw== Received: from CO1NAM04FT060.eop-NAM04.prod.protection.outlook.com (10.152.90.51) by CO1NAM04HT042.eop-NAM04.prod.protection.outlook.com (10.152.91.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.6; Sun, 6 Nov 2016 19:53:23 +0000 Received: from DM5PR20MB1643.namprd20.prod.outlook.com (10.152.90.56) by CO1NAM04FT060.mail.protection.outlook.com (10.152.91.116) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.3 via Frontend Transport; Sun, 6 Nov 2016 19:53:23 +0000 Received: from DM5PR20MB1643.namprd20.prod.outlook.com ([10.171.159.146]) by DM5PR20MB1643.namprd20.prod.outlook.com ([10.171.159.146]) with mapi id 15.01.0707.006; Sun, 6 Nov 2016 19:53:23 +0000 From: Dmitri Tikhonov To: "quic@ietf.org" Thread-Topic: Unnecessary QUIC error codes Thread-Index: AQHSODJTgV7GZJwnyUOPlUyxzTAd2A== Date: Sun, 6 Nov 2016 19:53:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:2243; Count:36 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [BgJxENJCZLGbNDs7MwtmPEMx2yyWSgJ8] x-incomingheadercount: 36 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; CO1NAM04HT042; 7:DG5LbnMAgxMOy9Ne0wi7IkYKr/gf/bx+VjD8d1qmKdnjx2RxDEaMwIy4pEhcDtcMG827EJc6BkcN4uV5Qz87eAlirgsxWm3wQeJMC5rUJcv6qRsh2t9EYn3UE54crWNzKfA0H7ATVCfZdHySGzViK5T9g19T+85AU70nF7CqVjUxBIMJleY5Lpp1QdXDRr4ZlhUu0hUaHNWVHuPKTMF5szj5bL9cE85zG2pgPneXTkv/FG5dv/ThUbVilAqHgEioCYT7MSy4V/dB2q1+03W8RggBkBVJy2Z7TdU5PWRp6cCCN8fY43+U3eZTUGT/axQI6LGQbjto+Fbx3MRI/IVMs1AAQNP8VCuKcOb4r0hCe/A= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1NAM04HT042; H:DM5PR20MB1643.namprd20.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 23f991ca-23a2-41df-1e35-08d4067e9155 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CO1NAM04HT042; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:CO1NAM04HT042; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM04HT042; x-forefront-prvs: 0118CD8765 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR20MB1643290380E6765DB9395262C1A40DM5PR20MB1643namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2016 19:53:23.9462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT042 X-OriginalArrivalTime: 06 Nov 2016 19:53:25.0183 (UTC) FILETIME=[6F9294F0:01D23867] Archived-At: Subject: [QUIC] Unnecessary QUIC error codes X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 06 Nov 2016 19:53:27 -0000 --_000_DM5PR20MB1643290380E6765DB9395262C1A40DM5PR20MB1643namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Fellow QUICsters: I read through the new QUIC draft (Octber 31, 2016) and I think I see sever= al error codes that do not belong in the protocol. Some of them have too m= uch "chrome," others seem to have bled through from the code onto the draft= , so to speak. Category I: Chromisms QUIC_MAYBE_CORRUPTED_MEMORY Looking at the code, what is considered potential memory corruption by Quic= Connection::MaybeConsiderAsMemoryCorruption() is subjective. An implementa= tion should not try to guess how its peer corrupts memory. QUIC_PACKET_TOO_LARGE This is a Chromism because kMaxPacketSize is defined in Chromium code, but = not in the document. QUIC_STREAM_SEQUENCER_INVALID_STATE This is a Chromism (what's a Stream Sequencer?). It also falls into Catego= ry II (see below). QUIC_TOO_MANY_SESSIONS_ON_SERVER Chromism: what is a session? Category II: Doctor It Hurts When I Do This A guy goes to see a doctor. "Doc, it hurts when I do this!" "Don't do it,= then." QUIC_FLOW_CONTROL_SENT_TOO_MUCH_DATA QUIC_FAILED_TO_SERIALIZE_PACKET Category III: Telepathic Packet Delivery QUIC_PACKET_WRITE_ERROR If we can't write to socket, how will the peer learn of this error code? QUIC_ENCRYPTION_FAILURE If we can't encrypt a packet, how does the CONNECTION_CLOSE frame get sent = out? Thanks, Kelly. --_000_DM5PR20MB1643290380E6765DB9395262C1A40DM5PR20MB1643namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Fellow QUICsters:


I read through the new QUIC draft (Octber 31, 2016) and I think I see se= veral error codes that do not belong in the protocol.  Some of them ha= ve too much "chrome," others seem to have bled through from the c= ode onto the draft, so to speak.


Category I: Chromisms


QUIC_MAYBE_CORRUPTED_MEMORY

Looking at the code, what is considered potential memory corruption by Q= uicConnection::MaybeConsiderAsMemoryCorruption() is subjective.  An im= plementation should not try to guess how its peer corrupts memory.


QUIC_PACKET_TOO_LARGE


This is a Chromism because kMaxPacketSize is defined in Chromium code, b= ut not in the document.


QUIC_STREAM_SEQUENCER_INVALID_STATE


This is a Chromism (what's a Stream Sequencer?).  It also falls int= o Category II (see below).


QUIC_TOO_MANY_SESSIONS_ON_SERVER


Chromism: what is a session?


Category II: Doctor It Hurts When I Do This

A guy goes to see a doctor.  "Doc, it hurts when I do this!= "  "Don't do it, then."

QUIC_FLOW_CONTROL_SENT_TOO_MUCH_DATA


QUIC_FAILED_TO_SERIALIZE_PACKET


Category III: Telepathic Packet Delivery


QUIC_PACKET_WRITE_ERROR


If we can't write to socket, how will the peer learn of this error code?=


QUIC_ENCRYPTION_FAILURE


If we can't encrypt a packet, how does the CONNECTION_CLOSE frame get se= nt out?



Thanks,


Kelly.


--_000_DM5PR20MB1643290380E6765DB9395262C1A40DM5PR20MB1643namp_-- From nobody Sun Nov 6 19:31:43 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4D7129BAC for ; Sun, 6 Nov 2016 19:31:41 -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 UhBmerMHVPPy for ; Sun, 6 Nov 2016 19:31:38 -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 EE1EC129BAB for ; Sun, 6 Nov 2016 19:31:37 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n21so51106593qka.3 for ; Sun, 06 Nov 2016 19:31:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4xH5F95v+NZGbmf1SfSWTU91dbnwjGFmlEtyJuGOmQY=; b=Q3WSlKSgPfbmhyKe16eAD86FMXK7eRASSoMHdIJOIYNo8zqKCvQkwdwG/OhAu7E5H/ /HuaS2FvuDJD9N/5SlQFvAoTUfPtjxp05O6XnIlkA8RMUqRpOPrHYu7QCAj4loxkxvYC RfXSEMOnrNTgXFfIHWeDmzHDCLk5lEdez/BxdvvQnd8ySOp/OlJKji6CmAuroqaHOjOI 39Kaqgr7ldaU+fZ2WKxcF5lW2dEI5YtMr95h5gp7MxnnlZI74BHvSMI3WO4R4uGVKZlx nATaSRtD8UaRlIf2LPB6v4c9dvQ3gUV6FyfdEHZaLtc1H95NJ3Im2nkP6qFNWkrIkXm4 9chg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4xH5F95v+NZGbmf1SfSWTU91dbnwjGFmlEtyJuGOmQY=; b=Sj15miOk5wfZOEJnkqJ3uw1ikcr7kGhufXmcCQj5SU3yceW8fFz7qny6gP8Oy9wXg9 6X8OP7b5YhcyTIryk0Su7bAuQpflMUCeV+nkjEkq1gSomGVJ+06r3wUdZhCQBwmd3gXw ONFcQyuA5emZkJppC+xI8NmY9dw9Prm5yaRGVRc3S09GjMFuoRVI3WHHtUw44l8oOvRZ VIBSrtoUO1PDHhfjjda/X5yaUhRfre/qcF4DT1dOU5ctGmCjCFXxVi/hgnhVNbxXS8Ow RBF9DYvhDCEZUyhwopmiAN4nQKUT05pbxzOcUpz5xkKRJiscW7vZW2+q8GYsK/ALmiaJ Mr1A== X-Gm-Message-State: ABUngvdHJYaWXdkY2OBSCJkyAqYHMAQiigy2G04wT4C2mZybifucwhtROpUESyUgoxorRk+XljVDHVDAiQjjaQ== X-Received: by 10.55.99.141 with SMTP id x135mr4537905qkb.147.1478489497129; Sun, 06 Nov 2016 19:31:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 6 Nov 2016 19:31:36 -0800 (PST) In-Reply-To: <057801d2371b$2d47ca90$87d75fb0$@huitema.net> References: <057801d2371b$2d47ca90$87d75fb0$@huitema.net> From: Martin Thomson Date: Mon, 7 Nov 2016 14:31:36 +1100 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: quic@ietf.org, Dragana Damjanovic Subject: Re: [QUIC] Comment on draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 03:31:41 -0000 On 5 November 2016 at 15:14, Christian Huitema wrote: > The flow diagram in 2.1. Handshake Overview supposedly mimics the diagram= in section 2.3. Zero-RTT Data of the TLS 1.3 spec, except there is a minor= difference, probably an oversight, the "(Finished)" message after the Hell= o and extensions. There is no such message in the TLS 1.3 diagram, although= there might have been in a prior version. The other difference is the timi= ng of early data. I've removed this from my version. It disappeared in a recent version of TLS and I didn't track well enough. > The text in the introduction of section 3 says that "QUIC Stream 1 carrie= s a complete TLS connection. This includes the TLS record layer in its enti= rety." That means that we have two potential layers of encryption: the QUIC= record protection, which is protected by the keys described as @A, @B, @C = in the diagram; and the TLS record layer, which protects some of the messag= es sent on stream 1. @A is clear text. The draft says that "The server send= s its handshake messages without protection (@A)". That's true as far as th= e QUIC record layer is concerned, not so true for the TLS layer itself. Yes, this was the result of a lot of back-and-forth. The advantage is that it avoids shifting the complexity associated with handshake encryption to QUIC. It also keeps the implementation pretty simple, because we can use TLS (not DTLS). The disadvantage is that you double-encrypt a few packets. Right now, those packets are the NewSessionTicket, the client's final flight, and maybe the close_notify alert. I can't think of any other data that TLS encrypts that needs to be sent right now. > In the same vein, I would like to understand why the last flight of TLS c= lient messages (end of early data, finished) are protected by the 0-RTT key= (@B) rather than the 1-RTT key (@C). Isn't end-of-early-data triggering a = transition to @B? In fact, why are we concerned with early data on stream 1= ? If the client sends early data, it will be probably using stream 3, and t= he TLS record layer will not be engaged. The finished was a mistake. However, I've no good concept of what to do with end_of_early_data. QUIC probably doesn't need it at all, since it marks transitions between 0-RTT and 1-RTT with the KEY_PHASE bit. As you observe, sending it on stream 1 isn't going to have the desired effect. I've opened https://github.com/martinthomson/quic-tls/issues/12 to track that. From nobody Sun Nov 6 19:35:21 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A843129BB9 for ; Sun, 6 Nov 2016 19:35:20 -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 k3WDrf7M3gPB for ; Sun, 6 Nov 2016 19:35:19 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d: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 1C5E8129BB1 for ; Sun, 6 Nov 2016 19:35:19 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id x190so160214426qkb.0 for ; Sun, 06 Nov 2016 19:35:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7FzjYE1Wm0erspsSXACKpQwa31QlxVWdvzcQXEl7nJc=; b=Yf3S1Y0ZIPz3QAiVto7gFxpYDwNEkuzhxaqpVp3Dq2ZKj9viLVwP2qccMYfIVeb7O+ Hef7z7ac5/xSaIGmm5A83WaVHzg9GJl1oOOa8eeENxmPkTk8dMDqdg+UGx177/h0+vJ+ 0C+svrt4QICq2Y5eW+sUpqpH721Za3+ntcQg9L8jQy1QYcLemM16uQpGJwbyN0F9Nzgk zyTaKL1ibNq+Cfbev4GE3GGkSE8uXNMt4VpjzqGPfPpeZL2aSGHisi6gxoiHLYt6KZHD 9YuHoXbToai//EqZDJF0XIY1LuNk3gs0eQEdp0P2PiJ4XaJqT+chPe9WoZPOjAH7WSBF 30iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7FzjYE1Wm0erspsSXACKpQwa31QlxVWdvzcQXEl7nJc=; b=AJ8FTVL2AnrFHGEBn70xywWsr3TrMj2mA8epJEtmHIdxO61kDoyiylMWDOqFFi1a0a Mon01QAiEYepPu6cwayi4fyrmp5uxSX/SVTC4gUEmgLKKDsmL1D2UyGBMtrjl3UE0Q3E Vx/htoWHtzPb3vApKbRfYR0DCqCU4bDQ0y3LJm6ezTY/2aFqq3t1+XNiIOKi0sa98M2w uaxGKOxqz0mZpF1VuZQiMmPtsn0wOSeEX7dhu8vSYS6JovaGGl2Ex26KYdPzoVpZud/B bWo8cyia8E0Q5zG5R9z2jB0grQJ+d8rVEuPXayRRoYrtYZQPTaymnjKSx+5fABG/5uTP RsIA== X-Gm-Message-State: ABUngvf4o96VWYaJk28UzEGeWpwCt7uj9hBT/Dff9sieFk2DADMqbFWjHgzgvptAoXiU5VGM6GoPNC/5pdWAlA== X-Received: by 10.55.155.151 with SMTP id d145mr4676695qke.115.1478489717930; Sun, 06 Nov 2016 19:35:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 6 Nov 2016 19:35:17 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 7 Nov 2016 14:35:17 +1100 Message-ID: To: Patrick McManus Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 03:35:20 -0000 On 5 November 2016 at 08:01, Patrick McManus wrote: > First, editorially draft-hamilton-quic-transport-protocol-01 generally > refers to packet numbers instead of sequence numbers. There seem to be two > exceptions to that - in 6.2 and the identifier > SEQUENCE_NUMBER_LIMIT_REACHED. OTOH > https://tools.ietf.org/html/draft-thomson-quic-tls-01 almost always refers > to sequence numbers (with one exception). I think SN is not defined, but PN > is and it should standardize on the PN language. Thanks Patrick. They are sequence numbers in TLS, so it's easy to be lazy. We should talk about packet numbers when talking about QUIC: https://github.com/martinthomson/quic-tls/issues/13 From nobody Sun Nov 6 22:16:54 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5623F129C46 for ; Sun, 6 Nov 2016 22:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOZ8Gy-BNpc7 for ; Sun, 6 Nov 2016 22:16:51 -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 86BEE129C3D for ; Sun, 6 Nov 2016 22:16:51 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1c3dEf-0002iH-92 for quic@ietf.org; Mon, 07 Nov 2016 07:16:49 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1c3dE8-0006Gy-JD for quic@ietf.org; Mon, 07 Nov 2016 01:16:47 -0500 Received: (qmail 15052 invoked from network); 7 Nov 2016 06:16:15 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.170]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Nov 2016 06:16:15 -0000 From: "Christian Huitema" To: "'Martin Thomson'" , "'Patrick McManus'" References: In-Reply-To: Date: Sun, 6 Nov 2016 22:16:13 -0800 Message-ID: <003201d238be$71f3f200$55dbd600$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKFoND2ejQ4qERTlGAa5Nqd4W8x2QEY0OUun11xNIA= Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMDxbv w5ft5DFISL0ntRvW0KWIoXvi+Z5Jf73Awq1DYAhvdcmtTcWSOKD5RASVzg27isHQQQX4d8d1Wjzb XaO9Az55kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbd0eW4EZMjhDISu9LQ4Vd1WPi885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suokMCPVg8gdjriVmAe4m5qrOAZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVJ52x4j7SJ9+yFYhxTTZdKAmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV46n/TYyQX4QewGgUaWBSqGlrtXw1c9IHjJjxHw61Bw8RquN6UIEUbDp4qQeYkcvTCl J+6wa7BDiaF6UX6W4Pbk X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 06:16:53 -0000 On Sunday, November 6, 2016 7:35 PM, Martin Thomson wrote > > Thanks Patrick. They are sequence numbers in TLS, so it's easy to be > lazy. We should talk about packet numbers when talking about QUIC: > > https://github.com/martinthomson/quic-tls/issues/13 Also, the sequence number of TLS are probably different from the packet = numbers used in QUIC -- a TLS record can span multiple QUIC packets, the = QUIC packet number also counts the 0-RTT packets on other streams beside = stream 1, etc. There is a lot of text in the TLS draft that concerns itself with the = QUIC packet layer encryption, including discussion of retransmissions. = Are we sure that this is the right place for this text? What if someone = decided to use a version of QUIC that uses something else than TLS to = establish keys? -- Christian Huitema From nobody Sun Nov 6 22:31:47 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF8B129C64 for ; Sun, 6 Nov 2016 22:31: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, 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 4YF0USHGUQbR for ; Sun, 6 Nov 2016 22:31:46 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d: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 EFA47129ABA for ; Sun, 6 Nov 2016 22:31:45 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id x190so163126092qkb.0 for ; Sun, 06 Nov 2016 22:31:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cVa3Pr3dxfXaOi/wo7SOjK8vNxWEe+vt4Tbs2zqX2Lg=; b=rvKXu01YD4wj5XQ0DfpJsdvoqkdW3iZCd9MZRZ4ajsrfFocnJyV8Vo4pXuZCfjJNAk KRv9yAVfufxSzA57zIucCU83bYq334cGEfLWuSR2gTmfgXs+TiWrWnhfnb06FD7dscaw h1/R96Mcpo9v710+unjEPMc51cxH5Tr1tU+BXmJkNOXS39YqsPIYpzeCzNiradDSjrNh MiZPOPH0E8XB6WVNgGCdBDO1nrzS90MxOmK4RdeChwbcQj4IfFzgdN5RNmLrEsEMyjD1 Kifcz3tHjS8VhW/Hrt2pB+lGKhy1QblDr8b+0RjYzsFa+ts7hO0OGyVFHfcbyCF5kYxq AlMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cVa3Pr3dxfXaOi/wo7SOjK8vNxWEe+vt4Tbs2zqX2Lg=; b=WiRkHOc8dYk5kpRi+t1NNwmq+xaoS/KocQCcS9sfHrDqLAGnVwLFw3N7Kv4t9LNB1y lcr4DF6/U8aduV7jYsSYq6WcRKNTWDodq56hVylagIoit/rtSfsifADTomEwb69xvzPu 91bBPiv1e5FivS+XBstydMEE1N4Fp7koifDbz7z1FhHK/NZz60ktF6s/kyZekak/Z7nQ +99b8YkWIMJpchsPPXqSJlds6YIgyGwf9kghTVRQTfNOmenvDEOIRux1lNbLmz0zdIkk VJi3AWQpYZo7M4ZSic7rm4Bx7zRHchuhQ7tC7STuRb0h7iOpzFdsiNjmEHTcRQLSnDBM U6zA== X-Gm-Message-State: ABUngvdGQXz7UjFZKIHyjviy99ni+yt5F1VlCJBnPPrIbu71XHqadV51D/V01TyAhDjKDzJPex3gCQybwvBUug== X-Received: by 10.233.235.72 with SMTP id b69mr5723404qkg.144.1478500305145; Sun, 06 Nov 2016 22:31:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 6 Nov 2016 22:31:44 -0800 (PST) In-Reply-To: <003201d238be$71f3f200$55dbd600$@huitema.net> References: <003201d238be$71f3f200$55dbd600$@huitema.net> From: Martin Thomson Date: Mon, 7 Nov 2016 17:31:44 +1100 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org, Patrick McManus Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 06:31:47 -0000 On 7 November 2016 at 17:16, Christian Huitema wrote: > > There is a lot of text in the TLS draft that concerns itself with the QUIC packet layer encryption, including discussion of retransmissions. Are we sure that this is the right place for this text? Yes. Though I think that merging this with the main draft would make some of that easier (and some of it harder). > What if someone decided to use a version of QUIC that uses something else than TLS to establish keys? They would have to solve all the same problems. QUIC-as-it-is-deployed, makes different decisions in some places (trial decryption, for example), but the basic set of problems is the same. From nobody Mon Nov 7 08:17:52 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E301297CB for ; Mon, 7 Nov 2016 08:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 YLe_iPQ1VuZa for ; Mon, 7 Nov 2016 08:17:50 -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 31CF91295B4 for ; Mon, 7 Nov 2016 08:09:26 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1c3mU5-0001Kh-KB for quic@ietf.org; Mon, 07 Nov 2016 17:09:24 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1c3mTV-0008UA-4M for quic@ietf.org; Mon, 07 Nov 2016 11:09:19 -0500 Received: (qmail 28234 invoked from network); 7 Nov 2016 16:08:43 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.170]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Nov 2016 16:08:43 -0000 From: "Christian Huitema" To: "'Martin Thomson'" References: <003201d238be$71f3f200$55dbd600$@huitema.net> In-Reply-To: Date: Mon, 7 Nov 2016 08:08:41 -0800 Message-ID: <013a01d23911$3642f230$a2c8d690$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKFoND2ejQ4qERTlGAa5Nqd4W8x2QEY0OUuATqzEkcAq2AnrJ9O5Niw Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMDx5O vMaWjVcscARD6qvTBpWnElX0bRTQZLsv/wjAzgohdcmtTcWSOKD5RASVzg27iuke3OQ7qBRQtKLx pF+RUIJ5kYwBFjHSX1ySASMY7Q8kVWau65pVsnZkx/s3iU5HXZFVgpT1b21uZVckGp0ccOY/32e+ 5fVqy4sN42wuoCbdQk89ftyIVO+V4NZPJRU0Ffi885J4uw2WezmviQauN2SLBDMrD7q/cJogwbqz suok92hd3DC+E4Up3aD/Y9PuSAZIe8Pggnek1xH/TgvWD0MaKXvNWrRcSD72jROfhu6vZJ0Q4x+0 GOxZvoENDONKwZkjGlUCvU6ZAmJB8zrNH9DxX8G2bApANEDRnSX/sJx0Uf5/xO8dap3thvg9e/eV ioOoT5f9zNwjlArtXM+EHVJ52x4j7SJ9+yFYhxTTZdKAmJdDwLTy7ggkbtiREBmTEN9TLrF9l3It GfA/WrnALV46n/TYyQX4QewGgUaWBSqGlrtXw1c9IHjJjxHw61Bw8RquN6UIEUbDp4qQeYkcvTCl J+6wa7BDiaF6UX6W4Pbk X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.17) X-Recommended-Action: accept Archived-At: Cc: quic@ietf.org, 'Patrick McManus' Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 16:17:51 -0000 On Sunday, November 6, 2016 10:32 PM, Martin Thomson wrote: > On 7 November 2016 at 17:16, Christian Huitema = wrote: >> >> There is a lot of text in the TLS draft that concerns itself with the = QUIC packet layer=20 >> encryption, including discussion of retransmissions. Are we sure that = this is the right=20 >> place for this text? > > Yes. Though I think that merging this with the main draft would make > some of that easier (and some of it harder). > >> What if someone decided to use a version of QUIC that uses something = else than TLS to establish keys? > > They would have to solve all the same problems. > QUIC-as-it-is-deployed, makes different decisions in some places > (trial decryption, for example), but the basic set of problems is the > same. The integration of encryption and transport is a key element of the QUIC = design. The problems that is poses are independent of the particular = security session protocol running on stream 1. I am trying to think of a = negotiation-agnostic API for the packet layer. I like this kind of API, = because they allow for modular code design and testing. I like your notation of epochs, @A, @B, @C, etc. It allows us to speak = about the different phases, clear-text, 0-RTT, 1-RTT, key renewal, and = to discuss the interaction between epoch transition and packet = retransmission. The security layer will provide the 0-RTT and 1-RTT keys = to the packet layer. These are API events that are independent of the = security negotiation mechanisms, and can be used in the packet layer = design. Loss detection is independent of the stream mechanisms, but = retransmission is not. We may want to do a specific retransmission rule = for stream 1 during epochs A and B. -- Christian Huitema From nobody Mon Nov 7 10:04:26 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62C4E1294E7 for ; Mon, 7 Nov 2016 10:04:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihOowIKR4iGz for ; Mon, 7 Nov 2016 10:04:22 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 9E86E12945E for ; Mon, 7 Nov 2016 10:04:22 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 12so126482419uas.2 for ; Mon, 07 Nov 2016 10:04:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JOwNPep+nKQHOT0YiCOU/KctOdzAomggew6ZpdMmo3I=; b=UjbBhVKr8FG6iZNa6/Up3cBu6XR+JoXZwk5Dv22mz03ScumZuHvfB/jH6FQ8PPMTjk MnwiP3i4jSqN33xYk3HfPuuMZZy+Q2fdL8nHK/hqGUu922QBlov1sIKSsrlHn03xpHDf SAbaVhBbZybSSQT9URgMmioIGNI8DK2kSlhdOlGMkS/hzp+ZEWgr/knolnZLbSXwEop8 kOtU/N/7uaDDoClEPm0fEx901C+MkzfjsGyxAQ6Lq72qeyb6rgzH7Vy/o3Xx63G1Zfh3 3HKl8YtLFIIaLL1uXM8FVOQZl4M19FRzJ+0tI7rDmamuf4kMo8gdCPKmx8QtpaF0r5M+ nrZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JOwNPep+nKQHOT0YiCOU/KctOdzAomggew6ZpdMmo3I=; b=EvJbOjhtDdfUUnzcDYpv8oLRqEiYDEQUnr1TqN4Z12eDuWh8tCOGL8a7PpMqmXeol8 g6KG7G+akUmWB1re0imXN2ogZScJ4TpV61TIhHbYbbNCXZJWr2bYoBZ+EMJWFQfhWtH4 GGeFuS2yqi/ASz9V/TYsjti5gg3XEaI9ZjlDhs2XIAlpXlxbBa0m/VSpKRxiOPL1gSsi 0UN1HZHcmgK06XxdMJy9jgVlIw7RWglJ9XwdszVMpruVtqJCgVmPNNdmUHI9j14ufp6V jBolqKiq+CjlcBXWpFjKW7l2fdgeS6xaKyccop58c0aLLWL5c52tylNdS9ZLcPjKTEx1 fwiQ== X-Gm-Message-State: ABUngvdaKedwvBQRam3FH/IQ060pD92bwrDKNy+jDMy97EEB+LDJhmUQXhzHuiDRVoBZQrs8DmM9eJt8ZKnxpxGk X-Received: by 10.176.69.230 with SMTP id u93mr5099515uau.158.1478541861518; Mon, 07 Nov 2016 10:04:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Mon, 7 Nov 2016 10:04:21 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Mon, 7 Nov 2016 10:04:21 -0800 Message-ID: To: Patrick McManus Content-Type: multipart/alternative; boundary=94eb2c11c9e8717f7a0540b9da15 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Early Editorial Review Comment draft-hamilton-quic-transport-protocol-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 18:04:24 -0000 --94eb2c11c9e8717f7a0540b9da15 Content-Type: text/plain; charset=UTF-8 Thanks much for the review, Patrick! I'm leaving out most editorial comments, with the intention of addressing them after adoption. A couple of responses in the meanwhile though: 0] *There is really very little talk about addressing.* In TCP, this was > obvious - the 5 tuple identifies the connection and binds the addressing > into the transport. Not much to say. But quic awesomely separates the > connection identifier without really talking about how addressing has to > work. There is a TODO about rebinding that is obviously part of this > (github issue!), but even the original binding is underspecified (e.g. > where is the server side of the client handshake addressed to?). Its also > not clear how the STK applies to this, and that goes into security > considerations etc, etc.. There are some intuitive answers to these > questions, but we ought to document. > Good point. I've been thinking about perhaps separate out a discussion of the Connection ID, since I also expect there to be discussion around the current design of it being entirely client-chosen. Use of connection ID is currently in various parts of the doc, but given its novelty, I wonder if a separate "QUIC Addressing" overview section makes sense, which would point to the various places in the doc that consider addressing. FWIW, the STK records the IP address, since it's a proof of IP ownership, similar to the TFO cookie. Using the connection ID is largely useless here, since the STK is meant to be it for a new connection (with a new connection ID.) > 1] *Draft Intended Status is listed as experimenta*l. What's up with > that? Standards Track I would hope, or I'm going home now :) > :-) I don't think this matters, since the status should change with adoption. - jana --94eb2c11c9e8717f7a0540b9da15 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks much for the review, Patrick! I'm leaving out m= ost editorial comments, with the intention of addressing them after adoptio= n. A couple of responses in the meanwhile though:

0] There is really very little talk about addressing.= In TCP, this was obvious - the 5 tuple identifies the connection and binds= the addressing into the transport. Not much to say. But quic awesomely sep= arates the connection identifier without really talking about how addressin= g has to work. There is a TODO about rebinding that is obviously part of th= is (github issue!), but even the original binding is underspecified (e.g. w= here is the server side of the client handshake addressed to?). Its also no= t clear how the STK applies to this, and that goes into security considerat= ions etc, etc.. There are some intuitive answers to these questions, but we= ought to document.

Good point.= I've been thinking about perhaps separate out a discussion of the Conn= ection ID, since I also expect there to be discussion around the current de= sign of it being entirely client-chosen. Use of connection ID is currently = in various parts of the doc, but given its novelty, I wonder if a separate = "QUIC Addressing" overview section makes sense, which would point= to the various places in the doc that consider addressing.

<= /div>
FWIW, the STK records the IP address, since it's a proof of I= P ownership, similar to the TFO cookie. Using the connection ID is largely = useless here, since the STK is meant to be =C2=A0it for a new connection (w= ith a new connection ID.)
=C2=A0
1] Draft Intended Status is listed as experime= ntal. What's up with that? Standards Track I would hope, or I'm= going home now :)

:-) I don= 9;t think this matters, since the status should change with adoption.
=

- jana

--94eb2c11c9e8717f7a0540b9da15-- From nobody Mon Nov 7 11:26:33 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 749A81294CF for ; Mon, 7 Nov 2016 11:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uD6S9_rmJ9v for ; Mon, 7 Nov 2016 11:26:27 -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 41132129558 for ; Mon, 7 Nov 2016 11:26:27 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id 12so128472128uas.2 for ; Mon, 07 Nov 2016 11:26:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hc3bJhnHrlx5PbVeFs9fpggSWW9KzRCy8JMD5QmEoSo=; b=TTDN2A/4yzv6JLj8De1fV1DkiWJ3IVM6vvCPWEOCHjQndqXlO61SGNOLL3tf3cbqvy eB/xudMlNZvMU0a+EZJsv7XMPvUTRJBUj3KbxEBFDWuwalMl7dFXslmnEZj42FfJCtRx 03X1h9c3kfxu0k0kGoOGMGAfKL6mQPCThanqGnXcEj7JjISFR9oQDrrKADaO+4p+w6A7 Zk2ot54EXtfwXQLvNLwTi569GGBf6WpLm7mVQr54T7n7I7dTiQ4z15hJ0/IrwdVF0GTo 9GGbFcwFRjrcCDaLjcivU/MaBzbkaIpY8vWiS2SzbgNUpuMT3e2wSXoRVsKEjWQh501f FCcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hc3bJhnHrlx5PbVeFs9fpggSWW9KzRCy8JMD5QmEoSo=; b=TdR+nZCyPY2zvSIGzPDtvJWHQU3931fh3pnm2aTFicS4H1zUil9UDQOhPXrSH0sAoD Oi24GPh5qstblZvLSkjeO0PeGwMBY5wg0HhQnT7+bAJ8zUNTeF6WRAbL67p6uNK85XfW 89J2AWhL+hzDecrIqXsJDEvURKT3ADJX51psBhQeKp9n8ZxWvngSW3bkICBezrD0ihHC ftwu5+WaI8elnIRq1sDbiA0A92Br8sDDk+nGrbWIOscmrtYtJUnn3M8absfJ8Ur6M3XE XRrD2n4+4C3XYE+d8A/gVJkcdkQHfr0cD40CpvadKjqlkpwE2vigGYVvZ9Aq7emTbr4X lW/g== X-Gm-Message-State: ABUngveztp3ElQF7tr4R3uTugC2SQdjTAaFn+LGRMIWcArGTNm66DMH+h5TWUHGp0I8mbfnjv7AhUQBP1k+fq6oT X-Received: by 10.176.82.157 with SMTP id v29mr4916704uav.123.1478546786189; Mon, 07 Nov 2016 11:26:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Mon, 7 Nov 2016 11:26:25 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Mon, 7 Nov 2016 11:26:25 -0800 Message-ID: To: Patrick McManus Content-Type: multipart/alternative; boundary=94eb2c18f88af9fe9b0540baff20 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 19:26:29 -0000 --94eb2c18f88af9fe9b0540baff20 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 3, 2016 at 2:39 PM, Patrick McManus wrote: > Hi Robbie, Mike, et al. Thanks for getting the ball rolling with > https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00.. > > What is the thinking about rfc 7540 h2 extensions and the h2/quic > mapping.. particularly the way it allows unspecified frame types which may > or may not require negotiation. > > it seems some of these extensions may have stateful issues across streams, > ala hpack and some may not. > > If the extension were only defined for h2-over-quic that would be for the > extension to sort out.. but it doesn't seem like we are limiting things to > quic vs tcp, or are we? > Not sure what you mean by not limiting things to QUIC vs. TCP -- do you have a different mapping in mind? My sense is that we'll need to (i) define how current extensions will work with QUIC (eg, HPACK), and (ii) require that future extensions be defined explicitly for both TCP and QUIC. > -Patrick > > --94eb2c18f88af9fe9b0540baff20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 3, 2016 at 2:39 PM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
=
Hi Robbie, Mike, et al. Thanks for getting the ball rolling = with https://tools.ietf.org/html/draft-shade-quic-htt= p2-mapping-00..

What is the thinking about rfc 7540 h= 2 extensions and the h2/quic mapping.. particularly the way it allows unspe= cified frame types which may or may not require negotiation.

i= t seems some of these extensions may have stateful issues across streams, a= la hpack and some may not.

If the extension were only defined = for h2-over-quic that would be for the extension to sort out.. but it doesn= 't seem like we are limiting things to quic vs tcp, or are we?

Not sure what you mean by not limiting = things to QUIC vs. TCP -- do you have a different mapping in mind?=C2=A0

My sense is that we'll need to
(i) def= ine how current extensions will work with QUIC (eg, HPACK), and
(= ii) require that future extensions be defined explicitly =C2=A0for both TCP= and QUIC.


<= /div>-Patrick

=

--94eb2c18f88af9fe9b0540baff20-- From nobody Mon Nov 7 11:34:46 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD9B1296EC for ; Mon, 7 Nov 2016 11:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mys0SXf0aRud for ; Mon, 7 Nov 2016 11:34:43 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id E4FFB129695 for ; Mon, 7 Nov 2016 11:34:42 -0800 (PST) Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) by linode64.ducksong.com (Postfix) with ESMTPSA id 17B8A3A015 for ; Mon, 7 Nov 2016 14:34:42 -0500 (EST) Received: by mail-it0-f44.google.com with SMTP id u205so150250970itc.0 for ; Mon, 07 Nov 2016 11:34:42 -0800 (PST) X-Gm-Message-State: ABUngvfEVBhK/K9F3Cb+ZVAk41tBTTWCcNvLtmsW2joXZ8YW64mZC76pZyy6tEr05e84MwIpVSeg7paikExJiA== X-Received: by 10.36.39.85 with SMTP id g82mr6516215ita.52.1478547281659; Mon, 07 Nov 2016 11:34:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.84.71 with HTTP; Mon, 7 Nov 2016 11:34:41 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Mon, 7 Nov 2016 14:34:41 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a1147cc5c81d0bf0540bb1def Archived-At: Cc: quic@ietf.org, Patrick McManus Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 19:34:45 -0000 --001a1147cc5c81d0bf0540bb1def Content-Type: text/plain; charset=UTF-8 On Mon, Nov 7, 2016 at 2:26 PM, Jana Iyengar wrote: > On Thu, Nov 3, 2016 at 2:39 PM, Patrick McManus > wrote: > >> Hi Robbie, Mike, et al. Thanks for getting the ball rolling with >> https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00.. >> >> What is the thinking about rfc 7540 h2 extensions and the h2/quic >> mapping.. particularly the way it allows unspecified frame types which may >> or may not require negotiation. >> >> it seems some of these extensions may have stateful issues across >> streams, ala hpack and some may not. >> >> If the extension were only defined for h2-over-quic that would be for the >> extension to sort out.. but it doesn't seem like we are limiting things to >> quic vs tcp, or are we? >> > > Not sure what you mean by not limiting things to QUIC vs. TCP -- do you > have a different mapping in mind? > I meant explicitly scoping h2 extensions so that they only apply to quic and/or tcp.. and it does seem like that's what you mean :) > > My sense is that we'll need to > (i) define how current extensions will work with QUIC (eg, HPACK), and > fwiw HPACK/QPACK is not an extension and you can't define it as one in quic because it would need to be negotiated and that's going to break the 0RTT goal of the protocol. I don't think that's a problem though as there is no need to make it an extension :) > (ii) require that future extensions be defined explicitly for both TCP > and QUIC. > So the mapping document will need to establish a new h2 extension registry? -P --001a1147cc5c81d0bf0540bb1def Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 7, 2016 at 2:26 PM, Jana Iyengar <jri@google.com> wrote:
On Thu, Nov 3, 201= 6 at 2:39 PM, Patrick McManus <pmcmanus@mozilla.com> wrot= e:
H= i Robbie, Mike, et al. Thanks for getting the ball rolling with https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00..

What is the thinking about rfc 7540 h2 extensions and= the h2/quic mapping.. particularly the way it allows unspecified frame typ= es which may or may not require negotiation.

it seems some of = these extensions may have stateful issues across streams, ala hpack and som= e may not.

If the extension were only defined for h2-over-quic= that would be for the extension to sort out.. but it doesn't seem like= we are limiting things to quic vs tcp, or are we?
=

Not sure what you mean by not limiting things to= QUIC vs. TCP -- do you have a different mapping in mind?=C2=A0
=


I meant explicitly scoping= h2 extensions so that they only apply to quic and/or tcp.. and it does see= m like that's what you mean :)
=C2=A0

My sense is that we'll need to
(i) define how current extensions will work with QUIC (eg, HPACK), and

fwiw HPACK/QPACK is = not an extension and you can't define it as one in quic because it woul= d need to be negotiated and that's going to break the 0RTT goal of the = protocol. I don't think that's a problem though as there is no need= to make it an extension :)
=C2=A0
(ii) require that future extensions be defined explicitly =C2=A0= for both TCP and QUIC.

<= div>So the mapping document will need to establish a new h2 extension regis= try?

-P

=C2=A0
--001a1147cc5c81d0bf0540bb1def-- From nobody Mon Nov 7 12:01:37 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9889C129436 for ; Mon, 7 Nov 2016 12:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94Gn-B-EBad6 for ; Mon, 7 Nov 2016 12:01:34 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c: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 C21B0129695 for ; Mon, 7 Nov 2016 12:01:31 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id w194so130768053vkw.2 for ; Mon, 07 Nov 2016 12:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Apyx1hvOOyeKCWyAfB/yIsFqnIBdFXrcOky6rYl9bOs=; b=NLJRIzWRviy2ssurDGYX1qcHNV6WTKHDEoY4DWHo26LGRD1pJBlXe+MyO6b0fPWrAB 5lg+cNLzSRQFSmdNS2gJILwT8FpjOF+mvqeByYWqVqbyqVxp+Bu7T0uMG1aQ1bDaHLZK UXtvPES8QrpIjjaWJHXw8H0bhNkT5Du00Gisj2AdFASrG3+Cix44myP3fMTaVxn06FC6 BxWpsxZdj9+JwTfJRIdCaoNC/MNh4ymMAICrGRv/tA4cGZjfUXyXRsTg9SkDj6PbDyPP X0hOjSeemVveBEzBuFC+E8tqjcC18YtIt0CGmjrYXER/Jl2b3dHR9mBZdhjjj60MYy00 wz9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Apyx1hvOOyeKCWyAfB/yIsFqnIBdFXrcOky6rYl9bOs=; b=lPfXhEX0SfzfpCgyOnhUSMkos15NODWiQ7CW4bIxAODRE3TfGVYoJ8LQ1/V7O6ScBZ 3/jwRZteDAGVaet+3Nuy+56DHuqO4XNA+LDT/T7DOFgdA9aB6T0txk4qiSYFKlMJIYqt TUcgN4O9u/NLW6LVaPohmZrEM536e98Z0NC3x6Ld0dGmRtjd5+5hbjunEsxceeu6ccwW DGvmiav/X+68bZWoHoVhPPiTI4PVppgkFAN2IcgDfDwtqJ/qsGcV1G2Rg+b3cyLgMZHP iOXl+QO8sEGvxBe9AvD4ZCiZKSb0US4qRxjeN2BUxMEZiHnuO183FKiO4nagFkcZDhzi nkIg== X-Gm-Message-State: ABUngveOfGv2ZllO8hG5X5U3nm0W/XLYDpsJSg+YkPJpq+N02Ls3hk0jlzzOf6/7p8EE1BplU7Krd1BOMwkqKN1U X-Received: by 10.31.7.147 with SMTP id 141mr5745585vkh.154.1478548890670; Mon, 07 Nov 2016 12:01:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Mon, 7 Nov 2016 12:01:30 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Mon, 7 Nov 2016 12:01:30 -0800 Message-ID: To: Dmitri Tikhonov Content-Type: multipart/alternative; boundary=001a1143d1586a1a320540bb7dca Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Unnecessary QUIC error codes X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 20:01:35 -0000 --001a1143d1586a1a320540bb7dca Content-Type: text/plain; charset=UTF-8 Hi Kelly, Thanks for your read of the draft! Yes, indeed this listing is of "all possible" QUIC errors since the draft is currently a documentation of current QUIC. The point of listing them all was for the wg, after adoption, to figure out what to do with them. Some of these error codes are sent over the wire, and others are not -- the draft currently incorrectly states that these are all CONNECTION_CLOSE frame error codes. These are certainly connection close error codes, but not all of them are communicated to the peer. We may drop the local error codes, since they have no business being in the protocol (The ones in your "Telepathic Packet Delivery" category.) That said, we may choose to keep some of them as suggestions for reasons that an implementation MAY close a connection. The Chromisms that you note should be fixed -- QUIC_STREAM_SEQUENCER_INVALID_STATE: means that the receiver's stream reassembly engine is in some funky state QUIC_TOO_MANY_SESSIONS_ON_SERVER: sessions are the same as connections I'll put this email on the list of things to fix post-adoption. Thanks again! - jana On Sun, Nov 6, 2016 at 11:53 AM, Dmitri Tikhonov wrote: > Fellow QUICsters: > > > I read through the new QUIC draft (Octber 31, 2016) and I think I see > several error codes that do not belong in the protocol. Some of them have > too much "chrome," others seem to have bled through from the code onto the > draft, so to speak. > > > *Category I: Chromisms* > > QUIC_MAYBE_CORRUPTED_MEMORY > > Looking at the code, what is considered potential memory corruption by > QuicConnection::MaybeConsiderAsMemoryCorruption() is subjective. An > implementation should not try to guess how its peer corrupts memory. > > > QUIC_PACKET_TOO_LARGE > > > This is a Chromism because kMaxPacketSize is defined in Chromium code, but > not in the document. > > > QUIC_STREAM_SEQUENCER_INVALID_STATE > > > This is a Chromism (what's a Stream Sequencer?). It also falls into > Category II (see below). > > > QUIC_TOO_MANY_SESSIONS_ON_SERVER > > > Chromism: what is a session? > > > *Category II: Doctor It Hurts When I Do This* > > *A guy goes to see a doctor. "Doc, it hurts when I do this!" "Don't do > it, then."* > > QUIC_FLOW_CONTROL_SENT_TOO_MUCH_DATA > > > QUIC_FAILED_TO_SERIALIZE_PACKET > > > *Category III: Telepathic Packet Delivery* > > > QUIC_PACKET_WRITE_ERROR > > > If we can't write to socket, how will the peer learn of this error code? > > > QUIC_ENCRYPTION_FAILURE > > > If we can't encrypt a packet, how does the CONNECTION_CLOSE frame get sent > out? > > > > Thanks, > > > Kelly. > > > --001a1143d1586a1a320540bb7dca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kelly,

Thanks for your read of the d= raft! Yes, indeed this listing is of "all possible" QUIC errors s= ince the draft is currently a documentation of current QUIC.

=
The point of listing them all was for the wg, after adoption, to= figure out what to do with them. Some of these error codes are sent over t= he wire, and others are not -- the draft currently incorrectly states that = these are all CONNECTION_CLOSE frame error codes. These are certainly conne= ction close error codes, but not all of them are communicated to the peer.<= /div>

We may drop the local error codes, since they have= no business being in the protocol (The ones in your "Telepathic Packe= t Delivery" category.) That said, we may choose to keep some of them a= s suggestions for reasons that an implementation MAY close a connection.

The Chromisms that you note should be fixed --
=
QUIC_STREAM_SEQUENCER_INVALID_STATE: means that the receiver's str= eam reassembly engine is in some funky state
QUIC_TOO_MANY_SE= SSIONS_ON_SERVER: sessions are the same as connections

I'll put this email on the list of things to fix post-adoption= . Thanks again!
- jana

=
On Sun, Nov 6, 2016 at 11:53 AM, Dmitri Tikhonov= <k.langen@outlook.com> wrote:

Fellow QUICsters:


I read through the new QUIC draft (Octber 31, 2016) and I think I see se= veral error codes that do not belong in the protocol.=C2=A0 Some of them ha= ve too much "chrome," others seem to have bled through from the c= ode onto the draft, so to speak.


Category I: Chromisms


QUIC_MAYBE_CORRUPTED_MEMORY

Looking at the code, what is considered potential memory corruption by Q= uicConnection::MaybeConsiderAsMemoryCorruption() is subjective.= =C2=A0 An implementation should not try to guess how its peer corrupts memo= ry.


QUIC_PACKET_TOO_LARGE


This is a Chromism because kMaxPacketSize is defined in Chromium code, b= ut not in the document.


QUIC_STREAM_SEQUENCER_INVALID_STATE


This is a Chromism (what's a Stream Sequencer?).=C2=A0 It also falls= into Category II (see below).


QUIC_TOO_MANY_SESSIONS_ON_SERVER


Chromism: what is a session?


Category II: Doctor It Hurts When I Do This

A guy goes to see a doctor.=C2=A0 "Doc, it hurts when I do this!= "=C2=A0 "Don't do it, then."

QUIC_FLOW_CONTROL_SENT_TOO_MUCH_DATA


QUIC_FAILED_TO_SERIALIZE_PACKET


Category III: Telepathic Packet Delivery


QUIC_PACKET_WRITE_ERROR


If we can't write to socket, how will the peer learn of this error c= ode?


QUIC_ENCRYPTION_FAILURE


If we can't encrypt a packet, how does the CONNECTION_CLOSE frame ge= t sent out?



Thanks,


Kelly.



--001a1143d1586a1a320540bb7dca-- From nobody Mon Nov 7 12:52:55 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9800129987 for ; Mon, 7 Nov 2016 12:52: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, 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 5ErggUM3FanN for ; Mon, 7 Nov 2016 12:52:52 -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 3D2701296DD for ; Mon, 7 Nov 2016 12:52:52 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id w33so95261495qtc.3 for ; Mon, 07 Nov 2016 12:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Pe5v2pp7x8dEFtm8X3xVg6Bzhjun2V5yedmYqbyE4qA=; b=BsXcgFlGIZ31csFAckJRLbsuAgkSX7AjylwZ/kYHphqNhmAS4mgpvZedODNJJtpFwb fudQVuWfIOMaTCkDJ0+U52cWodDXOCF4AlxExDvYaWTD9I3AWbSyz1atfyTMitBCc+nk 7EewKyVjCV1niFhNOXD0+jsO/vaGRdomVub8mihn386fuAJFPjcvVvznVXUDcMqJ8Mqq A6Y5s+fVJagUb6NWR7hkHJPo3HauMEhw0IVQe+N+0RZWPqCrMHr/1s/u6R3iKKkWUoCD v06fLJdAi5DgZN8PlyJZnwvIo0+RXSTy4SAK+UfJ+yFghSeNPux9WToYh8GDutnSGzqE nc9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Pe5v2pp7x8dEFtm8X3xVg6Bzhjun2V5yedmYqbyE4qA=; b=MUn5VetxzVDr3xH6egaGfG85enoqii+tY6xszqT16vj6wLQWaxob9X7w0LvPNea5lP +XmPO7dws3E82NRXEbQcfCqexAwkMaACY4WLhkA8pAxU8gKGU8+IrZ2oY8AR5YaSMZef c4V51AZFipTwFhW5qa0DamHL0DixMI2iRQTDD12yVTZG7DRfU1g1e6W1OYZckokWwHwC v51b/YLB2ANjT6CuSIBmqnyXWVqsjfjoXPAbHmSfA2ISjKnAM/yj6GluMKV4jK5cBjI/ HTYSIMtYzZGO0Hk0gGgYjTbto/eHwZk2MFBHY/mtETmveZbdQkiXnD2abLXo/tsSGAe2 Blbw== X-Gm-Message-State: ABUngvdnxKQngAuVhH0q78uAD12RTnAjJG4ERrfdJ/WOv7Rx/b4tmQPaKgYDWFu2RgVdNINLjPeqL5xlr0Uphw== X-Received: by 10.237.53.132 with SMTP id c4mr8912076qte.85.1478551971219; Mon, 07 Nov 2016 12:52:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 7 Nov 2016 12:52:50 -0800 (PST) In-Reply-To: <013a01d23911$3642f230$a2c8d690$@huitema.net> References: <003201d238be$71f3f200$55dbd600$@huitema.net> <013a01d23911$3642f230$a2c8d690$@huitema.net> From: Martin Thomson Date: Tue, 8 Nov 2016 07:52:50 +1100 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org, Patrick McManus Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 20:52:54 -0000 On 8 November 2016 at 03:08, Christian Huitema wrote: > Loss detection is independent of the stream mechanisms, but retransmission is not. We may want to do a specific retransmission rule for stream 1 during epochs A and B. Agreed. I've tried to capture that, but it definitely needs refinement. From nobody Mon Nov 7 13:01:48 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87BB1295E3 for ; Mon, 7 Nov 2016 13:01:46 -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 XohuHAd59fnp for ; Mon, 7 Nov 2016 13:01:45 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d: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 96C1012946A for ; Mon, 7 Nov 2016 13:01:45 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id q130so193165574qke.1 for ; Mon, 07 Nov 2016 13:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=eYwRhhh18GXjLY8D+vOCJIvrIXDrpnIfZcref4I+fjg=; b=pIpWepa3Pyuoir0ljAqpxqtneZFTBt4meTZGYHMImMeWK+8/25hZLoyhkYTXpsceIS gijTB+aBFxst56saWxAeWbSBKKQcIu0sktoWZQfuFBBpCm+g7zwShdtbOD1/iLdiR23F fbAACtibQVSbb0JhMmHPu6g7g46nJZICTbfHj3xDaDrDhB5VRn+1HMPmDD2LGB5kKEVr v1lOU4NJnLeMKhFCDJrDCoj8Emlp1uw0b27xPNLh7nYwDvJh22LhE2LkecPras6y7NnT o4cJOgfH9EPHQazdrkV9+ZB+nkl7/d9MWXgYS4jqfqJzqZKgNdh8Ftd9G/oMb6FmD86m vJXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=eYwRhhh18GXjLY8D+vOCJIvrIXDrpnIfZcref4I+fjg=; b=bvYNkDUvxuNhyRmJ/wrrN1xeODowTMZMlxLfGNnoNrKV2qn6cxm7xoBgfJ161sMGR6 i9RuAushVoZucDbmipbLOmnJGHLymicdxFi7SNi5W32nD3BIkJV+fvqy9ZfwR/cHbF3v zHgS+oBebgHcA22Onka7bCendL4NAFNN6aMJlYUqkrX8msRCde+EeE75hZN2LM44ITD0 bgdWGGE6nOIcEAZWTE+SlBoeaKV1KoFkOrVRix+x1kRiiwMTwaTxNGvVnEfzQyYItz1K I/fMlbTiK/ukmeMPqb0DiXwnPPFKQQAiT+bt4f2+6KZ+NRkWnyfqB2PjkYliPRCeqwW+ xH1w== X-Gm-Message-State: ABUngvfVKGwQG6ekd9H5yHnA532lN2Y5WsSFKqCJG9x3Sezikxyv4gWEcA05J3n/mtbxPEtBRslHRQG72a17Tg== X-Received: by 10.55.99.141 with SMTP id x135mr8290623qkb.147.1478552504635; Mon, 07 Nov 2016 13:01:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 7 Nov 2016 13:01:44 -0800 (PST) From: Martin Thomson Date: Tue, 8 Nov 2016 08:01:44 +1100 Message-ID: To: quic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 21:01:47 -0000 I'm getting a lot of questions from people who are starting to implement. I'm guessing that I'm only seeing a small proportion of the total volume. That's great. But it's going to be hard to deploy unless we have some ground rules about how to identify the protocol version. Here's a strawman, loosely based on what I've learned from HTTP/2 and TLS 1.3: QUIC version numbers are 32-bits. We reserve everything in the range 0xffff0000-0xffffffff for experimentation. We designate 0xffff5100 and up as corresponding to versions of the draft. That is, 0xffff5101 would correspond to a potential -01 version of the core protocol draft. (Obviously, this would be post-WG-adoption, which I hope happens soon.) Similarly, we designate ALPN labels to match. "quic-01" would correspond to the same version of the HTTP mapping draft. Hopefully the mapping draft would progress in lock-step, but if it doesn't, then the core protocol version that corresponds to the ALPN label would be determined by what version of the core protocol is referenced by the mapping document. I think that we should agree to a scheme for protocol identifiers (it doesn't have to be this) at the meeting next week. From nobody Mon Nov 7 13:41:25 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CB212998A for ; Mon, 7 Nov 2016 13:41:23 -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 qNJye13uedNG for ; Mon, 7 Nov 2016 13:41:16 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1791F129415 for ; Mon, 7 Nov 2016 13:41:16 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id n204so183935850qke.2 for ; Mon, 07 Nov 2016 13:41:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lS4zrd0Ci1qRXSYdMUuyJhirw5zNRRCPAZpR1ZkbyEA=; b=l1pHEkNKyR/vxSdhh9e3dqbEkuQ7ly6sR7QGmc8gat6CRNOvwrXuNgCjbPdsMz5eor yLjJZPZpgeuppidcV8XUS9vgRqcoxXqL6KTnVuVlwnIEDp85BCphDegEMQq/m/0yAtWr zZtqLAHXuZYXNOVcjQi5uSlssQqO0SixjEmxc/SYgBsy4QHGVenO6DbQbqV3b2fNAccf Llb5CVTLehzE2szOpVcCU8TFXoXimduVxrIs2QF5KK4WIRa9C/XHHLZxmsgvnZOxD6WA 78mY5m/6LMkzUKgtiB5WAseQwdUBFGeuW0nq/NK1DZyc9ovUK5xCW2UCsCRd336K56PW xkXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lS4zrd0Ci1qRXSYdMUuyJhirw5zNRRCPAZpR1ZkbyEA=; b=ZEQdmq/Iw/E26pNflDmzOwo+x/39Tq7pzaUxUAbsKorj1WpIXV7qWYbQoa/hWLK/6x Mm2L07jygpOQ4H2vfAwWm64m5qT8tRhutrYLM2eCImajnbR929DLNYnbuN1hXUNPlm1B RY+V8x6TaZSmH7k6rj/7AK4gjA7m4aHffVgk4804VY157XvFt/17kWtz1crDm1zit//O xjfzckZNSxdDaKJBWdVmEKQvJ2T6oHQnEChOoROgMRNf4jzqjRTAZJHzgerIpn9wYnYX tphKjcg0zC2PxiIUaKuS0R0MaOGEHJUreO2PcUXAe2prnQta1uJ3AqqIUj1Ozb1xzIok Vr0A== X-Gm-Message-State: ABUngvcq7H2swkLTMVSAZM5raUv56hpw8QBtukLgjcoI9jNcDUTVk3P9N6eRlvJmWzIbSUny6ZYFv1xC2HaSEQ== X-Received: by 10.55.190.66 with SMTP id o63mr8794681qkf.254.1478554875148; Mon, 07 Nov 2016 13:41:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.165.100 with HTTP; Mon, 7 Nov 2016 13:40:44 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Mon, 7 Nov 2016 13:40:44 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c04395c1d5da50540bce2a1 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 21:41:23 -0000 --94eb2c04395c1d5da50540bce2a1 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson wrote: > I'm getting a lot of questions from people who are starting to > implement. I'm guessing that I'm only seeing a small proportion of > the total volume. That's great. > > But it's going to be hard to deploy unless we have some ground rules > about how to identify the protocol version. > > Here's a strawman, loosely based on what I've learned from HTTP/2 and TLS > 1.3: > > QUIC version numbers are 32-bits. This is, presumably, one of the things we can change. More broadly, I think we need to think about a more granular approach to this, so we can have multiple folks experimenting without either needless conflict or over-much coordination. There are a lot of folks who have deeply held opinions about extensions, negotiation, and version, and I don't want to tread over all that ground, but I think we should not assume that we should start from where we are. Just my personal opinion, Ted > We reserve everything in the range > 0xffff0000-0xffffffff for experimentation. We designate 0xffff5100 > and up as corresponding to versions of the draft. That is, 0xffff5101 > would correspond to a potential -01 version of the core protocol > draft. (Obviously, this would be post-WG-adoption, which I hope > happens soon.) > > Similarly, we designate ALPN labels to match. "quic-01" would > correspond to the same version of the HTTP mapping draft. Hopefully > the mapping draft would progress in lock-step, but if it doesn't, then > the core protocol version that corresponds to the ALPN label would be > determined by what version of the core protocol is referenced by the > mapping document. > > I think that we should agree to a scheme for protocol identifiers (it > doesn't have to be this) at the meeting next week. > > --94eb2c04395c1d5da50540bce2a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
I'm getting a lot of questions from people who are starting to
implement.=C2=A0 I'm guessing that I'm only seeing a small proporti= on of
the total volume.=C2=A0 That's great.

But it's going to be hard to deploy unless we have some ground rules about how to identify the protocol version.

Here's a strawman, loosely based on what I've learned from HTTP/2 a= nd TLS 1.3:

QUIC version numbers are 32-bits.

This is, = presumably, one of the things we can change.=C2=A0 More broadly, I think we= need to think about a more granular approach to this, so we can have multi= ple folks experimenting without either needless conflict or over-much coord= ination.=C2=A0

There are a lot of folks who have deeply held opinio= ns about extensions, negotiation, and version, and I don't want to=C2= =A0 tread over all that ground, but I think we should not assume that we sh= ould start from where we are.


Just my personal opinio= n,

Ted

=C2=A0
=C2=A0 We reserve everything in the range
0xffff0000-0xffffffff for experimentation.=C2=A0 We designate 0xffff5100 and up as corresponding to versions of the draft.=C2=A0 That is, 0xffff5101=
would correspond to a potential -01 version of the core protocol
draft.=C2=A0 (Obviously, this would be post-WG-adoption, which I hope
happens soon.)

Similarly, we designate ALPN labels to match.=C2=A0 "quic-01" wou= ld
correspond to the same version of the HTTP mapping draft.=C2=A0 Hopefully the mapping draft would progress in lock-step, but if it doesn't, then<= br> the core protocol version that corresponds to the ALPN label would be
determined by what version of the core protocol is referenced by the
mapping document.

I think that we should agree to a scheme for protocol identifiers (it
doesn't have to be this) at the meeting next week.


--94eb2c04395c1d5da50540bce2a1-- From nobody Mon Nov 7 14:26:29 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD7E129AE8 for ; Mon, 7 Nov 2016 14:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u4OwtkLWxdc for ; Mon, 7 Nov 2016 14:26:24 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2A220129A4F for ; Mon, 7 Nov 2016 14:26:24 -0800 (PST) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id E0E083A015 for ; Mon, 7 Nov 2016 17:26:22 -0500 (EST) Received: by mail-it0-f41.google.com with SMTP id q124so53930235itd.1 for ; Mon, 07 Nov 2016 14:26:22 -0800 (PST) X-Gm-Message-State: ABUngve229l9QNFUJVfIR+l8Gr15wL8HB1rIjgSGdHG4bqjBi0m6K9n2frIYNoE5LG5bkmLX/GLS4P5Fg7V8nQ== X-Received: by 10.107.12.229 with SMTP id 98mr12377767iom.183.1478557582465; Mon, 07 Nov 2016 14:26:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.84.71 with HTTP; Mon, 7 Nov 2016 14:26:21 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Mon, 7 Nov 2016 17:26:21 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ted Hardie Content-Type: multipart/alternative; boundary=001a113f97947bdd170540bd8342 Archived-At: Cc: quic@ietf.org, Martin Thomson Subject: Re: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 22:26:28 -0000 --001a113f97947bdd170540bd8342 Content-Type: text/plain; charset=UTF-8 I'm eager to get a plan on this as well - its essential for iteration and diversity. I would push back just a tad against Ted's message - this might be the one place in the protocol where we have some backwards compatible constraints. There is already trail blazing code running on UDP/443 but we also want to allow ietf-quic to run on UDP/443 simultaneously during development to get experience with that So I'm not sure we really can change the location of the version field, at least not in a way that isn't cleverly compatible. It is essentially the magic number of the format. However, I think we're in a good place here if we can agree that network byte order is the way to go. If we do that, Google can 'squat' on the high byte (which would include what I understand are the 34 existing versions if expressed as low endian) for now and the IETF space can have the low three bytes without worry.. by the time it gets up to the 25th bit I would hope old proto-quic implementations were no longer a going concern. A similarly high range could also be carved out for permissionless experimentations in the pre-rfc period - but we wouldn't have to settle on that right away. And this makes for a nice document - just say the first draft is verison 1 and is in network byte order and that packets received with a version >= 0x01000000 MUST NOT be replied to with ietf-quic. -Patrick On Mon, Nov 7, 2016 at 4:40 PM, Ted Hardie wrote: > On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson > wrote: > >> I'm getting a lot of questions from people who are starting to >> implement. I'm guessing that I'm only seeing a small proportion of >> the total volume. That's great. >> >> But it's going to be hard to deploy unless we have some ground rules >> about how to identify the protocol version. >> >> Here's a strawman, loosely based on what I've learned from HTTP/2 and TLS >> 1.3: >> >> QUIC version numbers are 32-bits. > > > This is, presumably, one of the things we can change. More broadly, I > think we need to think about a more granular approach to this, so we can > have multiple folks experimenting without either needless conflict or > over-much coordination. > > There are a lot of folks who have deeply held opinions about extensions, > negotiation, and version, and I don't want to tread over all that ground, > but I think we should not assume that we should start from where we are. > > > Just my personal opinion, > > Ted > > > >> We reserve everything in the range >> 0xffff0000-0xffffffff for experimentation. We designate 0xffff5100 >> and up as corresponding to versions of the draft. That is, 0xffff5101 >> would correspond to a potential -01 version of the core protocol >> draft. (Obviously, this would be post-WG-adoption, which I hope >> happens soon.) >> >> Similarly, we designate ALPN labels to match. "quic-01" would >> correspond to the same version of the HTTP mapping draft. Hopefully >> the mapping draft would progress in lock-step, but if it doesn't, then >> the core protocol version that corresponds to the ALPN label would be >> determined by what version of the core protocol is referenced by the >> mapping document. >> >> I think that we should agree to a scheme for protocol identifiers (it >> doesn't have to be this) at the meeting next week. >> >> > --001a113f97947bdd170540bd8342 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm eager to get a plan on this as= well - its essential for iteration and diversity.

I would pus= h back just a tad against Ted's message - this might be the one place i= n the protocol where we have some backwards compatible constraints. There i= s already trail blazing code running on UDP/443 but we also want to allow i= etf-quic to run on UDP/443 simultaneously during development to get experie= nce with that So I'm not sure we really can change the location of the = version field, at least not in a way that isn't cleverly compatible. It= is essentially the magic number of the format.

However, I thi= nk we're in a good place here if we can agree that network byte order i= s the way to go. If we do that, Google can 'squat' on the high byte= (which would include what I understand are the 34 existing versions if exp= ressed as low endian) for now and the IETF space can have the low three byt= es without worry.. by the time it gets up to the 25th bit I would hope old = proto-quic implementations were no longer a going concern. A similarly high= range could also be carved out for permissionless experimentations in the = pre-rfc period - but we wouldn't have to settle on that right away.
=
And this makes for a nice document - just say the first draft is = verison 1 and is in network byte order and that packets received with a ver= sion >=3D 0x01000000 MUST NOT be replied to with ietf-quic.

-Patrick





On Mon, Nov 7= , 2016 at 4:40 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Mon, = Nov 7, 2016 at 1:01 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I'm getting a lot of questions from people who are starting to
implement.=C2=A0 I'm guessing that I'm only seeing a small proporti= on of
the total volume.=C2=A0 That's great.

But it's going to be hard to deploy unless we have some ground rules about how to identify the protocol version.

Here's a strawman, loosely based on what I've learned from HTTP/2 a= nd TLS 1.3:

QUIC version numbers are 32-bits.

Th= is is, presumably, one of the things we can change.=C2=A0 More broadly, I t= hink we need to think about a more granular approach to this, so we can hav= e multiple folks experimenting without either needless conflict or over-muc= h coordination.=C2=A0

There are a lot of folks who have deeply held= opinions about extensions, negotiation, and version, and I don't want = to=C2=A0 tread over all that ground, but I think we should not assume that = we should start from where we are.


Just my personal o= pinion,

Ted

=C2=A0
=C2=A0 We reserve every= thing in the range
0xffff0000-0xffffffff for experimentation.=C2=A0 We designate 0xffff5100 and up as corresponding to versions of the draft.=C2=A0 That is, 0xffff5101=
would correspond to a potential -01 version of the core protocol
draft.=C2=A0 (Obviously, this would be post-WG-adoption, which I hope
happens soon.)

Similarly, we designate ALPN labels to match.=C2=A0 "quic-01" wou= ld
correspond to the same version of the HTTP mapping draft.=C2=A0 Hopefully the mapping draft would progress in lock-step, but if it doesn't, then<= br> the core protocol version that corresponds to the ALPN label would be
determined by what version of the core protocol is referenced by the
mapping document.

I think that we should agree to a scheme for protocol identifiers (it
doesn't have to be this) at the meeting next week.



--001a113f97947bdd170540bd8342-- From nobody Mon Nov 7 14:44:07 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5F4129855 for ; Mon, 7 Nov 2016 14:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYdJU7pFoBuF for ; Mon, 7 Nov 2016 14:44:05 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c: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 E344B129664 for ; Mon, 7 Nov 2016 14:44:04 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id x186so134281677vkd.1 for ; Mon, 07 Nov 2016 14:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DPUBrXFMZPHdQZquIJDBQB46Fv2KWZ3OYb6PJ443oBk=; b=nU7g46u3HqknleimXibqQJYIfQCkm1N9xAzT5dI7X0zYt+T6hI83OFsyknPFg+mqli YeZbsxctkomp13NowNvlGzdLXThP5yjVzNupoL3Dw3ETObLSm9X49NW9v2XH7AZyAfXl UihV4JprtOSTlspZRtX3KiV55pYY6/w0hBKuku4GaxCB+KF0G/66YWXGJJpTqkEET7oi Xvy8FQjeKzK+D74llx3LVVYt/R51hu7LW70DG4PYE+bqbTgKQXys6GwnEbFFbjqN7T+W nCsjnXx8Po6Ytby/W4A+okVif1fJijxoJ/aVSJVdr+zCq8+Fe0tUUZ6lwMBjY5ST1aFO bdfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DPUBrXFMZPHdQZquIJDBQB46Fv2KWZ3OYb6PJ443oBk=; b=Lj5tBefBg2kAZJJbb0og6d++WMh4N446EPFnVeCRnsJREefsA9chwbd6hP9R5CCSMG r6eWQnzFIK1kkUZNV8U5KJTKhvi+uEOrnTYDvuvDPkdF6gGuBxd4rqM0cQ1gFuQYxnh2 wrfOnbQx9nuQkwfrsRMOEiiW51S570chVGfkMwynQPrgL4rFmLAAv49N3S8QIIPgT7cu IRbrE7yKS5zMi2eZvDVBYj657XFiKRDBLqKJ+d0i6x4JDfHfPeukNluZZRclKk1r5E0m 4bGMgLROwCQIxt8/cZkCok4jqy05dN83KxnC+Jxe+HuRAG5XsYpAjg/9gFt49myN+6Ux Mw/Q== X-Gm-Message-State: ABUngvf/8re+HkkjovkTuxGuDOIwaQfRlvFOVVirtAtOMJOLlGW3h0OXh0rDECF34iDbD+yu9uKnMEFRSPyiHB0X X-Received: by 10.31.76.134 with SMTP id z128mr6225268vka.59.1478558643824; Mon, 07 Nov 2016 14:44:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Mon, 7 Nov 2016 14:44:03 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Mon, 7 Nov 2016 14:44:03 -0800 Message-ID: To: Patrick McManus Content-Type: multipart/alternative; boundary=001a114dad50beffa60540bdc26a Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 22:44:06 -0000 --001a114dad50beffa60540bdc26a Content-Type: text/plain; charset=UTF-8 On Mon, Nov 7, 2016 at 11:34 AM, Patrick McManus wrote: > > > On Mon, Nov 7, 2016 at 2:26 PM, Jana Iyengar wrote: > >> On Thu, Nov 3, 2016 at 2:39 PM, Patrick McManus >> wrote: >> >>> Hi Robbie, Mike, et al. Thanks for getting the ball rolling with >>> https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00.. >>> >>> What is the thinking about rfc 7540 h2 extensions and the h2/quic >>> mapping.. particularly the way it allows unspecified frame types which may >>> or may not require negotiation. >>> >>> it seems some of these extensions may have stateful issues across >>> streams, ala hpack and some may not. >>> >>> If the extension were only defined for h2-over-quic that would be for >>> the extension to sort out.. but it doesn't seem like we are limiting things >>> to quic vs tcp, or are we? >>> >> >> Not sure what you mean by not limiting things to QUIC vs. TCP -- do you >> have a different mapping in mind? >> > > > I meant explicitly scoping h2 extensions so that they only apply to quic > and/or tcp.. and it does seem like that's what you mean :) > Gotcha. I think it makes sense to limit to QUIC and TCP at the moment since there is a proposal to run HTTP over these, until such a time as there is a need to define over another transport (let's call it Essy Transport Protocol, you know, EssyTP). I suspect at that point the httpbis wg (hey, that's you! :-)) can figure out how to define extensions over the other transport. My sense is that we'll need to >> (i) define how current extensions will work with QUIC (eg, HPACK), and >> > > fwiw HPACK/QPACK is not an extension and you can't define it as one in > quic because it would need to be negotiated and that's going to break the > 0RTT goal of the protocol. I don't think that's a problem though as there > is no need to make it an extension :) > Ah, sorry -- my grasp of which things are extensions and which ones not in HTTP-land is weak. I think compression is likely to be one of those things that is different in QUIC than in HTTP/2. > > >> (ii) require that future extensions be defined explicitly for both TCP >> and QUIC. >> > > So the mapping document will need to establish a new h2 extension registry? > Do you mean an IANA registry? It's probably safest to put these extensions will be in different namespaces entirely, so yes, if I understand your question correctly. - jana > > -P > > > --001a114dad50beffa60540bdc26a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 7, 2016 at 11:34 AM, Patrick McManus <= pmcmanus@mozilla.= com> wrote:


On Mon, Nov 7, 2016 at 2:26 PM, Jana Iyengar <jri@google.com> wrote:
On Thu, Nov 3, 2016 at 2:= 39 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Hi Robbi= e, Mike, et al. Thanks for getting the ball rolling with h= ttps://tools.ietf.org/html/draft-shade-quic-http2-mapping-00.= .

What is the thinking about rfc 7540 h2 extensions and the h2= /quic mapping.. particularly the way it allows unspecified frame types whic= h may or may not require negotiation.

it seems some of these e= xtensions may have stateful issues across streams, ala hpack and some may n= ot.

If the extension were only defined for h2-over-quic that w= ould be for the extension to sort out.. but it doesn't seem like we are= limiting things to quic vs tcp, or are we?
Not sure what you mean by not limiting things to QUIC v= s. TCP -- do you have a different mapping in mind?=C2=A0
<= /div>


I meant explicitly scoping= h2 extensions so that they only apply to quic and/or tcp.. and it does see= m like that's what you mean :)

Gotcha. I think it makes sense to limit to QUIC and TCP at = the moment since there is a proposal to run HTTP over these, until such a t= ime as there is a need to define over another transport (let's call it = Essy Transport Protocol, you know, EssyTP). I suspect at that point the htt= pbis wg (hey, that's you! :-)) can figure out how to define extensions = over the other transport.

My sense is that we'll= need to
(i) define how current extensions will work with QUIC (e= g, HPACK), and

fwiw HPACK/QPACK is not an extension and you can't define it as one = in quic because it would need to be negotiated and that's going to brea= k the 0RTT goal of the protocol. I don't think that's a problem tho= ugh as there is no need to make it an extension :)
<= /blockquote>

Ah, sorry -- my grasp of which things are e= xtensions and which ones not in HTTP-land is weak. I think compression is l= ikely to be one of those things that is different in QUIC than in HTTP/2.
=C2=A0
(ii) require that future extensions be defined explic= itly =C2=A0for both TCP and QUIC.
=
So the mapping document will need to establish a new = h2 extension registry?

<= div>Do you mean an IANA registry? It's probably safest to put these ext= ensions will be in different namespaces entirely, so yes, if I understand y= our question correctly.

- jana
=C2=A0

-P

=C2=A0

--001a114dad50beffa60540bdc26a-- From nobody Mon Nov 7 15:30:27 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EC21296EA for ; Mon, 7 Nov 2016 15:30:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4mHmpClI5lY for ; Mon, 7 Nov 2016 15:30:14 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45C2F1294AC for ; Mon, 7 Nov 2016 15:30:14 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id p9so135049554vkd.3 for ; Mon, 07 Nov 2016 15:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oyyUg08gOT8Wu2WFeHZhYoilSP9HYmPqZIphB4yIZXU=; b=axVnASNuoYdbCAZFWuRHuZA7+TclE5WjHlFMvToN+cdioWiPYd4Ae+sGfl6mTMV/FZ Pq0RDmwbiAbsQZ4GRGTKyc4SmGn38c8oVo6U/65svz2MCoCbWQvX4hYCz2TPe56Xg3oK euocoj5xmU1yQcGxNUqy8TCpfyIBBQv47YnmYs1pSupUZ83zhmI90nLl+pBBAV1rFlDv tcxsTdvrbfT8Pnzcks5MF5/KKfm+ZonhpKGWvzF/SsG5DFWwkbP4wRPjouREA7UzD8+u GhpdTNCmsAaX0FG/fK62RhKwcNYOGum+SDtKGsiUZuOINTfiuMY8jvnr/Tedk2hCPVQg 1e4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oyyUg08gOT8Wu2WFeHZhYoilSP9HYmPqZIphB4yIZXU=; b=NGgYXW68s9bW31P2ovnMpScEw0isNnvNLrcJKFxUNP5d602jdnL5Lqtu6FNOhur/p2 3vTVYuGK5Kz+e/o2NK2IxFweRJQHbWD4EuJEaR1AuE0E5MEs4/fEa4XbRqQCEmGHx1FE u6Y5ox2qrxrfKUXcvoU/5mQTWSQiJ4rmkHuA/B3ApRsR4Ei24xF6/VRw1UyrTRDUyVh0 xA2JKEhNfdSwQ2mfe4ybKTf9GO++ZeA/HxBmrNoiCICt6kVSSWvdkK+m/2eiLrPWXLF8 TtGbQutNc3TpxvTkAnbANLTD5B+yF+DzpGBNwghQx8EZg3I0Iam0utMR/8IjtO403VSr weUw== X-Gm-Message-State: ABUngvfSZWWXANUY/jnrsqxCkftnaaL8lhP9br8msDl3l9UvL95pZs/x5W8oj7onbHCTImeytxTo4FwcOwhfeyy4 X-Received: by 10.31.186.195 with SMTP id k186mr5601333vkf.23.1478561413230; Mon, 07 Nov 2016 15:30:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Mon, 7 Nov 2016 15:30:12 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Mon, 7 Nov 2016 15:30:12 -0800 Message-ID: To: Patrick McManus Content-Type: multipart/alternative; boundary=001a11441088d0da120540be6789 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 23:30:26 -0000 --001a11441088d0da120540be6789 Content-Type: text/plain; charset=UTF-8 Hi Patrick, On Fri, Nov 4, 2016 at 2:01 PM, Patrick McManus wrote: > Hi All - two more things to raise.. one I hope editorial and one design - > when we start doing github, I'll open issues to track there. > > First, editorially draft-hamilton-quic-transport-protocol-01 generally > refers to packet numbers instead of sequence numbers. There seem to be two > exceptions to that - in 6.2 and the identifier > SEQUENCE_NUMBER_LIMIT_REACHED. OTOH https://tools.ietf.org/html/ > draft-thomson-quic-tls-01 almost always refers to sequence numbers (with > one exception). I think SN is not defined, but PN is and it should > standardize on the PN language. > This should all be Packet Number, and we should fix it all. The history is that we used to call these Sequence Numbers, until we decided that the overlap with TCP terminology was unnecessarily confusing, since there are clear semantic differences between sequence number in TCP and packet number in QUIC. (Specifically, sequencing is used in TCP to order received bytes at the receiver, whereas Sequence Numbers in QUIC have only to do with the order in which packets may have been sent. There's also freedom at a sender to skip some numbers while sending, to avoid optimistic ack attacks, which means that packets sent in sequence may have discontiguous numbers assigned.) > Second, draft-hamilton-quic-transport-protocol-01 boldly uses little > endian encoding. Ya gotta admire that chutzpah in an IETF draft :) > More chutzpah than redefining HTTP transport with a 3-part non-layered protocol at the IETF? :-) >From a processor alignment pov, it makes perfect sense and I would support > it on a clean slate or on a well layered protocol. quic however, by design, > is neither of those things. > (I now proceed into this bikeshed. It was good to know you all.) I think disagree. I definitely think we have a clean-slate, at least as far as *this* protocol is concerned (modulo the running code.) I would argue that we have a well-layered protocol, but it is not "simply-layered". See more below. So we get into a bit of a mess - the packet number is little endian when it > appears in transport fields, but in the TLS document the AEAD nonce is > formed by padding the big endian representation of the same number. That > smells like a bug waiting to happen. Likewise a Stream ID in a transport > STREAM frame would be big endian, but when that same ID is encoded via 7540 > rules from the h2-mapping document (e.g. in a PUSH_PROMISE) then it needs > to be big endian. Again - seems like a footgun. So while I salute the > valiant effort to go little endian, I think we ought to bow to the > constraints this effort faces and go the traditional all network byte order > path. > So, to be clear, as long as the QUIC framer (as against the TLS or the HTTP framer) is the thing that's writing numbers on one side, and the QUIC framer is the thing reading numbers on the other side, there's no issue with endianness. In addition, if it's a non-QUIC framer writing numbers on one side, and a non-QUIC framer reading numbers on the other side, QUIC doesn't introduce any issues with endianness. On how the bits are used by other components which interact with the QUIC framer, that's a matter of API. So, if the TLS nonce is sent and delivered over Stream 1. QUIC transports and delivers bytes over Stream 1. QUIC doesn't care about the endianness of the nonce just as the nonce's endianness would have nothing to do with TCP's rules about endianness in TCP fields. Similarly, a Stream ID in a PUSH_PROMISE frame, which is sent as an H2 frame is basically opaque data on the wire to QUIC. In the mapping doc, a PUSH_PROMISE frame is sent over the Headers stream, which is entirely an HTTP-mapping concept. From QUIC's pov, it's a stream as any other. When an HTTP client receives this frame over QUIC, it will probably "reserve" this stream ID through an API call down into QUIC. So yes, while not simply-layered, there's very clear encapsulation and separation of functions and concerns. Non-QUIC entities MUST NOT put things in the QUIC frame format, and MUST NOT read things directly from the frame format. That said, I understand that there's baggage in terms of what the IETF has always done. The argument against it is that when engineering for the common case, little endian makes much more sense in today's world. (ducking for cover) - jana > > -Patrick > > > > --001a11441088d0da120540be6789 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi P= atrick,

On Fri, Nov 4, 2016 at 2:01 PM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
Hi All - two more things to raise.. one I = hope editorial and one design - when we start doing github, I'll open i= ssues to track there.

First, editorially draft-hamilton-quic-t= ransport-protocol-01 generally refers to packet numbers instead of seq= uence numbers. There seem to be two exceptions to that - in 6.2 and the ide= ntifier SEQUENCE_NUMBER_LIMIT_REACHED. OTOH https://tools.ietf.org= /html/draft-thomson-quic-tls-01 almost always refers to sequence n= umbers (with one exception). I think SN is not defined, but PN is and it sh= ould standardize on the PN language.

This should all be Packet Number, and we should fix it all.= The history is that we used to call these Sequence Numbers, until we decid= ed that the overlap with TCP terminology was unnecessarily confusing, since= there are clear semantic differences between sequence number in TCP and pa= cket number in QUIC. (Specifically, sequencing is used in TCP to order rece= ived bytes at the receiver, whereas Sequence Numbers in QUIC have only to d= o with the order in which packets may have been sent. There's also free= dom at a sender to skip some numbers while sending, to avoid optimistic ack= attacks, which means that packets sent in sequence may have discontiguous = numbers assigned.)
=C2=A0
Second, draft-hamilton-qui= c-transport-protocol-01 boldly uses little endian encoding. Ya gotta a= dmire that chutzpah in an IETF draft :)

<= /div>
More chutzpah than redefining HTTP transport with a 3-part non-la= yered protocol at the IETF? :-)

From a processor alignment= pov, it makes perfect sense and I would support it on a clean slate or on = a well layered protocol. quic however, by design, is neither of those thing= s.

(I now proceed into this= bikeshed. It was good to know you all.)
I think disagree. I = definitely think we have a clean-slate, at least as far as *this* protocol = is concerned (modulo the running code.) I would argue that we have a well-l= ayered protocol, but it is not "simply-layered". See more below.<= br>

<= div dir=3D"ltr">
So we get into a bit of a mess - the packet number is = little endian when it appears in transport fields, but in the TLS document = the AEAD nonce is formed by padding the big endian representation of the sa= me number. That smells like a bug waiting to happen. Likewise a Stream ID i= n a transport STREAM frame would be big endian, but when that same ID is en= coded via 7540 rules from the h2-mapping document (e.g. in a PUSH_PROMISE) = then it needs to be big endian. Again - seems like a footgun. So while I sa= lute the valiant effort to go little endian, I think we ought to bow to the= constraints this effort faces and go the traditional all network byte orde= r path.

So, to be clear, as lon= g as the QUIC framer (as against the TLS or the HTTP framer) is the thing t= hat's writing numbers on one side, and the QUIC framer is the thing rea= ding numbers on the other side, there's no issue with endianness. In ad= dition, if it's a non-QUIC framer writing numbers on one side, and a no= n-QUIC framer reading numbers on the other side, QUIC doesn't introduce= any issues with endianness.
On how the bits are used by other co= mponents which interact with the QUIC framer, that's a matter of API.= =C2=A0

So, if the TLS nonce is sent and delivered = over Stream 1. QUIC transports and delivers bytes over Stream 1. QUIC doesn= 't care about the endianness of the nonce just as the nonce's endia= nness would have nothing to do with TCP's rules about endianness in TCP= fields.

Similarly, =C2=A0a Stream ID in a PUSH_PR= OMISE frame, which is sent as an H2 frame is basically opaque data on the w= ire to QUIC. In the mapping doc, a PUSH_PROMISE frame is sent over the Head= ers stream, which is entirely an HTTP-mapping concept. From QUIC's pov,= it's a stream as any other. When an HTTP client receives this frame ov= er QUIC, it will probably "reserve" this stream ID through an API= call down into QUIC.=C2=A0

So yes, while not simp= ly-layered, there's very clear encapsulation and separation of function= s and concerns. Non-QUIC entities MUST NOT put things in the QUIC frame for= mat, and MUST NOT read things directly from the frame format.
That said, I understand that there's baggage in terms of wh= at the IETF has always done. The argument against it is that when engineeri= ng for the common case, little endian makes much more sense in today's = world.

(ducking for cover)
- jana
<= div>


-Patr= ick




--001a11441088d0da120540be6789-- From nobody Mon Nov 7 15:35:49 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A575129462 for ; Mon, 7 Nov 2016 15:35: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, 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 IgzrTSXpQxV4 for ; Mon, 7 Nov 2016 15:35:45 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 3903A1294AC for ; Mon, 7 Nov 2016 15:35:45 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id c47so97642928qtc.2 for ; Mon, 07 Nov 2016 15:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YtHueWpmAJXKCZYxQPeA8KjMh6EliRtitXDN0JklnlI=; b=jE6TnQNm6YZ7w8eXNH31ZXgPtIK6/M4QW4N8bm3q+IVjyGsMHf8HHGqG6j11wZZA5j ciEvYfbKPCfcK44FQgWrKtWqUOJViGs0aPMth0Ffcw96oJCDdYWFUbDttN2kF1PVmhiI RSSHT8Wlq97ys/mrV9PzjmNbhbGlDZyIzJ0k9iPGjnxRs9CyFCb2gnDPxAq407y2ng2M UDHdy2tLG5glNNnZh4r+5FQOrY/bu3ssyMIPUwgmP3xQIYmfAVaudZxKIuEoTRYPlCb0 hWH1rxE9EN3zLahUUH8RW/OHoEieJOXSaLigxJcR2z0w4XjDtSAUaCuBkxoxbrTGuGuj gIBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YtHueWpmAJXKCZYxQPeA8KjMh6EliRtitXDN0JklnlI=; b=NbIsLiWqGcFLOAriHDa4oTX2zeoJR6DOAYrQXqq3spDjSUuDKvozfSuZ96Q94jBw+3 Ps5yTsBnhxONhCM3ug63KEromcfBVd7uuIUeHDebRJacvsO30x/sR+Pr3WWCqCbp4STX 7hhouU+PA4Je3J4sYeLxg+wippBbQifSGLsFKb7tn87IU7lhlYRPYDP598JYLfLKKXK/ hcGRQqmgE8zHoGYUmp51HPGOJd0CqzMsoGi+wdAhWqwJFyHkr1SR7pNKCLgBe77chzYL ZilD32fAnw5oDXfHs+vg0VI4Pdpc0F477/H5B1ylAuapzvRDJxJAn4vah7tw0PxsINRm 0YHw== X-Gm-Message-State: ABUngvdP62RgSbM994E3NAqssG2DtqVxduY/FSQUaPrBiR/FrpcoHqocvg6SRjeMD2JySfgTGF9wC5Iw947qQw== X-Received: by 10.200.56.27 with SMTP id q27mr9936180qtb.116.1478561744341; Mon, 07 Nov 2016 15:35:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 7 Nov 2016 15:35:43 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 8 Nov 2016 10:35:43 +1100 Message-ID: To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org, Patrick McManus Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 07 Nov 2016 23:35:47 -0000 I'm going to recommend that the big-endian and little-endian proponents find themselves a room in Seoul. I plan to mute any thread that continues in this fashion. It's not a rathole, it's the Sarlacc. On 8 November 2016 at 10:30, Jana Iyengar wrote: > Hi Patrick, > > On Fri, Nov 4, 2016 at 2:01 PM, Patrick McManus > wrote: >> >> Hi All - two more things to raise.. one I hope editorial and one design - >> when we start doing github, I'll open issues to track there. >> >> First, editorially draft-hamilton-quic-transport-protocol-01 generally >> refers to packet numbers instead of sequence numbers. There seem to be two >> exceptions to that - in 6.2 and the identifier >> SEQUENCE_NUMBER_LIMIT_REACHED. OTOH >> https://tools.ietf.org/html/draft-thomson-quic-tls-01 almost always refers >> to sequence numbers (with one exception). I think SN is not defined, but PN >> is and it should standardize on the PN language. > > > This should all be Packet Number, and we should fix it all. The history is > that we used to call these Sequence Numbers, until we decided that the > overlap with TCP terminology was unnecessarily confusing, since there are > clear semantic differences between sequence number in TCP and packet number > in QUIC. (Specifically, sequencing is used in TCP to order received bytes at > the receiver, whereas Sequence Numbers in QUIC have only to do with the > order in which packets may have been sent. There's also freedom at a sender > to skip some numbers while sending, to avoid optimistic ack attacks, which > means that packets sent in sequence may have discontiguous numbers > assigned.) > >> >> Second, draft-hamilton-quic-transport-protocol-01 boldly uses little >> endian encoding. Ya gotta admire that chutzpah in an IETF draft :) > > > More chutzpah than redefining HTTP transport with a 3-part non-layered > protocol at the IETF? :-) > >> From a processor alignment pov, it makes perfect sense and I would support >> it on a clean slate or on a well layered protocol. quic however, by design, >> is neither of those things. > > > (I now proceed into this bikeshed. It was good to know you all.) > I think disagree. I definitely think we have a clean-slate, at least as far > as *this* protocol is concerned (modulo the running code.) I would argue > that we have a well-layered protocol, but it is not "simply-layered". See > more below. > >> So we get into a bit of a mess - the packet number is little endian when >> it appears in transport fields, but in the TLS document the AEAD nonce is >> formed by padding the big endian representation of the same number. That >> smells like a bug waiting to happen. Likewise a Stream ID in a transport >> STREAM frame would be big endian, but when that same ID is encoded via 7540 >> rules from the h2-mapping document (e.g. in a PUSH_PROMISE) then it needs to >> be big endian. Again - seems like a footgun. So while I salute the valiant >> effort to go little endian, I think we ought to bow to the constraints this >> effort faces and go the traditional all network byte order path. > > > So, to be clear, as long as the QUIC framer (as against the TLS or the HTTP > framer) is the thing that's writing numbers on one side, and the QUIC framer > is the thing reading numbers on the other side, there's no issue with > endianness. In addition, if it's a non-QUIC framer writing numbers on one > side, and a non-QUIC framer reading numbers on the other side, QUIC doesn't > introduce any issues with endianness. > On how the bits are used by other components which interact with the QUIC > framer, that's a matter of API. > > So, if the TLS nonce is sent and delivered over Stream 1. QUIC transports > and delivers bytes over Stream 1. QUIC doesn't care about the endianness of > the nonce just as the nonce's endianness would have nothing to do with TCP's > rules about endianness in TCP fields. > > Similarly, a Stream ID in a PUSH_PROMISE frame, which is sent as an H2 > frame is basically opaque data on the wire to QUIC. In the mapping doc, a > PUSH_PROMISE frame is sent over the Headers stream, which is entirely an > HTTP-mapping concept. From QUIC's pov, it's a stream as any other. When an > HTTP client receives this frame over QUIC, it will probably "reserve" this > stream ID through an API call down into QUIC. > > So yes, while not simply-layered, there's very clear encapsulation and > separation of functions and concerns. Non-QUIC entities MUST NOT put things > in the QUIC frame format, and MUST NOT read things directly from the frame > format. > > That said, I understand that there's baggage in terms of what the IETF has > always done. The argument against it is that when engineering for the common > case, little endian makes much more sense in today's world. > > (ducking for cover) > - jana > >> >> >> -Patrick >> >> >> > From nobody Mon Nov 7 18:04:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6731294D6 for ; Mon, 7 Nov 2016 18:04:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ae4eLfxo-DTD for ; Mon, 7 Nov 2016 18:04:04 -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 097E5129502 for ; Mon, 7 Nov 2016 18:04:04 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id 137so89758378vkl.0 for ; Mon, 07 Nov 2016 18:04:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D6OnmRbttNvkBmjrV2rqHj48XPTQ1Ee2hOCjoN2MLsE=; b=oyN3M8rKqS9kQnfWLgAlxR35Fk1tOcAEMAUrBxE4q+UNzWfqv0QF1/z6/S3HjVx0TC Id002UdFslU22MPxj4JvtiUAiAGPKJTYz87khsYJ9wbGTyoAAJePV6FhqvUMatphXlN7 CHM81oAe8FnL05T6DniRzQcBg7dLrZaPErbCmg0eqO+AMKvijfafSGGZhzBZjmPsizxV tZUdgTXoaRs1zgHvw55Z0Pzf05JlOCFYsMzNQCDsB4yu+sSknmNOVHF9XPJWIWVJar9+ ViQ9l7x8q/fBZlJYJppgiD4ermuMuBtJExkAqKrOQ/ljLHzGZgynnrt6VQ2xRp3GAJUM Zy1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D6OnmRbttNvkBmjrV2rqHj48XPTQ1Ee2hOCjoN2MLsE=; b=KKCeC8hXlkCWumenYFx/2Emm4Z93brP1nBdEHFGIUWuDGpPYBDeg5g5R7ZLaepd+uP Uoj1VbwCfnWBB8FB3hVdIKmvQjCqqnq8wBQlSp9aaoxtp4yLe1Tmwk98Tck3LGexbVW6 zcshcqT/G1LBTyKNb73fN2+vi2LRJCTD9A/igSDV9mbSjNJ1QvmU1CMFzmGXp1PwPM9D ueFv5l0VM8mdgUB8q6vs5tLwykWYzC3b/3dKf9lWy8U86GHmBjvdxbA8wmna4OpxCHyS UjiIRD6lh7gRV+qXZAj7JWUc0y5MiFyG+FETS2W5Sl/xc1c1A6dI9Z+5KQlzO90UbKOj nuBw== X-Gm-Message-State: ABUngveDgsIdM7BhJ3YQp5damQvqULNRAQUYeEvLAIsrHdwDTPeTT3+wNZ9BFAjieny+ILVemcYAzBsFCHrlDPy3 X-Received: by 10.31.7.147 with SMTP id 141mr6572788vkh.154.1478570642884; Mon, 07 Nov 2016 18:04:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Mon, 7 Nov 2016 18:04:02 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Mon, 7 Nov 2016 18:04:02 -0800 Message-ID: To: Patrick McManus Content-Type: multipart/alternative; boundary=001a1143d158f22c810540c08d3b Archived-At: Cc: Ted Hardie , quic@ietf.org, Martin Thomson Subject: Re: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 02:04:06 -0000 --001a1143d158f22c810540c08d3b Content-Type: text/plain; charset=UTF-8 I agree that we should have a plan for iteration and diversity, and should have versioning figured out early. FWIW, I don't think compatibility is an issue (it would be convenient if the placement of the version field were not changed,) since this version space is quite humongous. QUIC currently treats this as a 32-bit space, into which the QUIC version made up of 4 ASCII characters is encoded. "Q034" is encoded on the wire as 0x 51 30 33 36. There's no interesting structure here since these aren't treated as numbers... so unfortunately Patrick, I don't think your clever trick is going to do much. Google servers and Chrome use lists of currently-supported versions on each side, and there's no expectation of continuity in the 32-bit space, since the versions are simply arbitrary points in this space. So, I'll take Martin's arrangement and change it slightly: The IETF reserves versions 0x00000001 to 0x0000ffff (16K versions) for standards work (drafts and standards.) - In this space, designate 0x00000001 - 0x0000fff (4096 versions) to QUIC standards - Designate the rest of the IETF-reserved space, 0x00001000 - 0x0000ffff (~60K versions), for corresponding draft versions. That is, 0x00001001 would correspond to a potential -01 version of the core protocol draft. This leaves the space from 0x00010000 upwards (~4 billion versions) for uncoordinated and distributed experimentation. Since current QUIC sits at 0x51303336, this shouldn't interfere with future draft versions. On Mon, Nov 7, 2016 at 2:26 PM, Patrick McManus wrote: > I'm eager to get a plan on this as well - its essential for iteration and > diversity. > > I would push back just a tad against Ted's message - this might be the one > place in the protocol where we have some backwards compatible constraints. > There is already trail blazing code running on UDP/443 but we also want to > allow ietf-quic to run on UDP/443 simultaneously during development to get > experience with that So I'm not sure we really can change the location of > the version field, at least not in a way that isn't cleverly compatible. It > is essentially the magic number of the format. > > However, I think we're in a good place here if we can agree that network > byte order is the way to go. If we do that, Google can 'squat' on the high > byte (which would include what I understand are the 34 existing versions if > expressed as low endian) for now and the IETF space can have the low three > bytes without worry.. by the time it gets up to the 25th bit I would hope > old proto-quic implementations were no longer a going concern. A similarly > high range could also be carved out for permissionless experimentations in > the pre-rfc period - but we wouldn't have to settle on that right away. > > And this makes for a nice document - just say the first draft is verison 1 > and is in network byte order and that packets received with a version >= > 0x01000000 MUST NOT be replied to with ietf-quic. > > -Patrick > > > > > > On Mon, Nov 7, 2016 at 4:40 PM, Ted Hardie wrote: > >> On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson >> wrote: >> >>> I'm getting a lot of questions from people who are starting to >>> implement. I'm guessing that I'm only seeing a small proportion of >>> the total volume. That's great. >>> >>> But it's going to be hard to deploy unless we have some ground rules >>> about how to identify the protocol version. >>> >>> Here's a strawman, loosely based on what I've learned from HTTP/2 and >>> TLS 1.3: >>> >>> QUIC version numbers are 32-bits. >> >> >> This is, presumably, one of the things we can change. More broadly, I >> think we need to think about a more granular approach to this, so we can >> have multiple folks experimenting without either needless conflict or >> over-much coordination. >> >> There are a lot of folks who have deeply held opinions about extensions, >> negotiation, and version, and I don't want to tread over all that ground, >> but I think we should not assume that we should start from where we are. >> >> >> Just my personal opinion, >> >> Ted >> >> >> >>> We reserve everything in the range >>> 0xffff0000-0xffffffff for experimentation. We designate 0xffff5100 >>> and up as corresponding to versions of the draft. That is, 0xffff5101 >>> would correspond to a potential -01 version of the core protocol >>> draft. (Obviously, this would be post-WG-adoption, which I hope >>> happens soon.) >>> >>> Similarly, we designate ALPN labels to match. "quic-01" would >>> correspond to the same version of the HTTP mapping draft. Hopefully >>> the mapping draft would progress in lock-step, but if it doesn't, then >>> the core protocol version that corresponds to the ALPN label would be >>> determined by what version of the core protocol is referenced by the >>> mapping document. >>> >>> I think that we should agree to a scheme for protocol identifiers (it >>> doesn't have to be this) at the meeting next week. >>> >>> >> > --001a1143d158f22c810540c08d3b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that we should have a plan for iteration and diver= sity, and should have versioning figured out early. FWIW, I don't think= compatibility is an issue (it would be convenient if the placement of the = version field were not changed,) since this version space is quite humongou= s.

QUIC currently treats this as a 32-bit space, into wh= ich the QUIC version made up of 4 ASCII characters is encoded. "Q034&q= uot; is encoded on the wire as 0x 51 30 33 36. There's no interesting s= tructure here since these aren't treated as numbers... so unfortunately= Patrick, I don't think your clever trick is going to do much. Google s= ervers and Chrome use lists of currently-supported versions on each side, a= nd there's no expectation of continuity in the 32-bit space, since the = versions are simply arbitrary points in this space.

So, I'll take Martin's arrangement and change it slightly:
<= div>
The IETF reserves versions 0x00000001 to 0x0000ffff (16K= versions) for standards work (drafts and standards.)=C2=A0
- In = this space, designate =C2=A00x00000001 - 0x0000fff (4096 versions) to QUIC = standards
- Designate the rest of the IETF-reserved space, 0x0000= 1000 - 0x0000ffff (~60K versions), for corresponding draft versions. That i= s, 0x00001001 would correspond to a potential -01 version of the core proto= col draft.

This leaves the space from 0x00010000 u= pwards (~4 billion versions) for uncoordinated and distributed experimentat= ion. Since current QUIC sits at 0x51303336, this shouldn't interfere wi= th future draft versions.


On Mon, Nov 7, 2016 at 2:26 PM, Patrick = McManus <pmcmanus@mozilla.com> wrote:
I'm eager to get a = plan on this as well - its essential for iteration and diversity.

I would push back just a tad against Ted's message - this might be = the one place in the protocol where we have some backwards compatible const= raints. There is already trail blazing code running on UDP/443 but we also = want to allow ietf-quic to run on UDP/443 simultaneously during development= to get experience with that So I'm not sure we really can change the l= ocation of the version field, at least not in a way that isn't cleverly= compatible. It is essentially the magic number of the format.

However, I think we're in a good place here if we can agree that netwo= rk byte order is the way to go. If we do that, Google can 'squat' o= n the high byte (which would include what I understand are the 34 existing = versions if expressed as low endian) for now and the IETF space can have th= e low three bytes without worry.. by the time it gets up to the 25th bit I = would hope old proto-quic implementations were no longer a going concern. A= similarly high range could also be carved out for permissionless experimen= tations in the pre-rfc period - but we wouldn't have to settle on that = right away.

And this makes for a nice document - just say the = first draft is verison 1 and is in network byte order and that packets rece= ived with a version >=3D 0x01000000 MUST NOT be replied to with ietf-qui= c.

-Patrick

=




On Mon, Nov 7, 2016 at 4:40 PM, Ted Hardie = <ted.ietf@gmail.= com> wrote:
On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson &l= t;martin.thom= son@gmail.com> wrote:
I'm getting a lot of questions from people who are starting to implement.=C2=A0 I'm guessing that I'm only seeing a small proporti= on of
the total volume.=C2=A0 That's great.

But it's going to be hard to deploy unless we have some ground rules about how to identify the protocol version.

Here's a strawman, loosely based on what I've learned from HTTP/2 a= nd TLS 1.3:

QUIC version numbers are 32-bits.

Th= is is, presumably, one of the things we can change.=C2=A0 More broadly, I t= hink we need to think about a more granular approach to this, so we can hav= e multiple folks experimenting without either needless conflict or over-muc= h coordination.=C2=A0

There are a lot of folks who have deeply held= opinions about extensions, negotiation, and version, and I don't want = to=C2=A0 tread over all that ground, but I think we should not assume that = we should start from where we are.


Just my personal o= pinion,

Ted

=C2=A0
=C2=A0 We reserve everything in th= e range
0xffff0000-0xffffffff for experimentation.=C2=A0 We designate 0xffff5100 and up as corresponding to versions of the draft.=C2=A0 That is, 0xffff5101=
would correspond to a potential -01 version of the core protocol
draft.=C2=A0 (Obviously, this would be post-WG-adoption, which I hope
happens soon.)

Similarly, we designate ALPN labels to match.=C2=A0 "quic-01" wou= ld
correspond to the same version of the HTTP mapping draft.=C2=A0 Hopefully the mapping draft would progress in lock-step, but if it doesn't, then<= br> the core protocol version that corresponds to the ALPN label would be
determined by what version of the core protocol is referenced by the
mapping document.

I think that we should agree to a scheme for protocol identifiers (it
doesn't have to be this) at the meeting next week.




--001a1143d158f22c810540c08d3b-- From nobody Mon Nov 7 18:23:20 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7F51294EC for ; Mon, 7 Nov 2016 18:23:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AN9nLAEhIoun for ; Mon, 7 Nov 2016 18:23:16 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0090.outbound.protection.outlook.com [104.47.33.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 3F8541294B9 for ; Mon, 7 Nov 2016 18:23:16 -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=KqtE27afEw6k/7oMmspNjfwhrUtQ0lcx925V3AZkbr4=; b=agGGnoUoc7gYVhwbwB/OM1M4PEUCvnNOMJVDZbkRLkQA07ixLEIA5L8Q1Dx668n42tgOJh4cmwrRVQ1j4I0UjBX1IvOq6wZISTDHLYX1eUzhvQPCNgxlR1WP8GkDTazJqzSxg5Gg17hTwiq+Y2ej5WFFyyPVRz9/Xvr0DQrxv2I= Received: from CY4PR03MB2710.namprd03.prod.outlook.com (10.173.43.141) by CY4PR03MB2709.namprd03.prod.outlook.com (10.173.43.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Tue, 8 Nov 2016 02:23:13 +0000 Received: from CY4PR03MB2710.namprd03.prod.outlook.com ([10.173.43.141]) by CY4PR03MB2710.namprd03.prod.outlook.com ([10.173.43.141]) with mapi id 15.01.0707.006; Tue, 8 Nov 2016 02:23:13 +0000 From: Mike Bishop To: Jana Iyengar , Patrick McManus Thread-Topic: [QUIC] h2 mapping - extensions Thread-Index: AQHSNhrWVkwvFIuWr0eoGbjCghGjY6DN7XKAgAACUICAADTogIAAOkaw Date: Tue, 8 Nov 2016 02:23:12 +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=Michael.Bishop@microsoft.com; x-originating-ip: [172.56.42.178] x-ms-office365-filtering-correlation-id: 5e241549-2056-4142-0296-08d4077e30c1 x-microsoft-exchange-diagnostics: 1; CY4PR03MB2709; 7:alQAAZWGLyUCg/uFCVODNLFW/KGCZ66lOfMpkTXdsxv3JRAPIyo3hrY5taix8H+el9vuVgT+ezunSFG9AnCqYCoau61GG6dFaK/CPNchaUHAXi/MJfsDXCOUqlJkZpU5Ol1GvUwfLKdf1xU+DFrUiOiODexulA7+1kmwLc3l5ZJH6grDUAhMh/o7nj2RtaeCZY3xZTiTfVplzVdH51/TCNvI7mfCQ0OzAC9fR4V9Ls/MEU1TdQuDF/oEfPtnwm6EYI84V0uKgGj/nrZ9GqSTg3jHsxHN+W1o2M8h6jzsIYPDCe5NdoN2fPKg2l4wY2RaU+XADDTv3RwUsH/imVOwqKYZ5UXdX5xxExcXntORqg+jKZ+FprZS1DHvxC4zTB9Y x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY4PR03MB2709; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060229)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6061226)(6046074); SRVR:CY4PR03MB2709; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2709; x-forefront-prvs: 01208B1E18 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(199003)(377454003)(101416001)(2900100001)(68736007)(3660700001)(77096005)(50986999)(9686002)(66066001)(2906002)(4326007)(54356999)(76176999)(106356001)(74316002)(5005710100001)(86362001)(19609705001)(5660300001)(7736002)(87936001)(7906003)(7846002)(7696004)(86612001)(92566002)(189998001)(10290500002)(3280700002)(99286002)(8936002)(561944003)(8990500004)(105586002)(10090500001)(106116001)(5001770100001)(97736004)(586003)(102836003)(93886004)(2950100002)(3846002)(6116002)(790700001)(76576001)(33656002)(81156014)(8676002)(81166006)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2709; H:CY4PR03MB2710.namprd03.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR03MB2710302DAFFB6926E882824D87A60CY4PR03MB2710namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2016 02:23:12.8689 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2709 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 02:23:19 -0000 --_000_CY4PR03MB2710302DAFFB6926E882824D87A60CY4PR03MB2710namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SmFuYSwgaDIgZXh0ZW5zaW9ucyBhcmUgdmVyeSBicm9hZCDigJMgeW91IGNhbiBuZWdvdGlhdGUg KG1ldGhvZCB1bnNwZWNpZmllZCwgYnV0IHVzdWFsbHkgYSBtdXR1YWwgU0VUVElORykgYW55IGRl cGFydHVyZSBmcm9tIG9yIGFkZGl0aW9uIHRvIHRoZSBzcGVjLiAgQWRkaXRpb25hbGx5LCBjbGll bnRzIE1VU1QgaWdub3JlIHVua25vd24gZnJhbWUgdHlwZXMsIHNvIGFueXRoaW5nIHRoYXQgZG9l c27igJl0IGNoYW5nZSB0aGUgY29yZSBvZiB0aGUgcHJvdG9jb2wgKGUuZy4gT1JJR0lOKSBjYW4g YmUgc2VudCBzcGVjdWxhdGl2ZWx5LCB3aXRob3V0IGtub3dpbmcgd2hldGhlciB0aGUgcGVlciB3 aWxsIHVuZGVyc3RhbmQuDQoNCkluIHRoZSBjdXJyZW50IG1hcHBpbmcsIHlvdeKAmXJlIGVmZmVj dGl2ZWx5IHJ1bm5pbmcgYSBmdWxsIEhUVFAvMiBmcmFtaW5nIGxheWVyIGFuZCBtdXggb24gU3Ry ZWFtIDMuICBJdOKAmXMgcmVmZXJyZWQgdG8gYXMg4oCcdGhlIEhFQURFUlMgc3RyZWFtLOKAnSBi dXQgaXQgYWN0dWFsbHkgY2FycmllcyBTRVRUSU5HUywgUFVTSF9QUk9NSVNFLCBQUklPUklUWSwg YW5kIGJhc2ljYWxseSBhbnl0aGluZyBlbHNlLiAgVGhlIG1hcHBpbmcgZG9jdW1lbnQgY2FsbHMg b3V0IHRoaW5ncyB0aGF0IGFyZSBkZWxlZ2F0ZWQgdG8gdGhlIFFVSUMgbGF5ZXIgKFBJTkcsIEdP QVdBWSwgV0lORE9XX1VQREFURSkgb3Igb3RoZXIgUVVJQyBzdHJlYW1zIChEQVRBKSwgYnV0IG90 aGVyd2lzZSB5b3UgY291bGQgdGFrZSBhcmJpdHJhcnkgaDIgZXh0ZW5zaW9ucyBhbmQgZHJvcCBp dCBvbiBTdHJlYW0gMyB3aXRob3V0IG11Y2ggY2hhbmdlLiAgSWYgd2Uga2VlcCB0aGF0IG1vZGVs LCB0aGF04oCZcyBwcm9iYWJseSB0aGUgZGVmYXVsdCBhbnN3ZXIg4oCTIGFuIGV4dGVuc2lvbiB3 b3JrcyB1bmxlc3MgaXQgaGFzIHNvbWUgaGFyZCBkZXBlbmRlbmN5IG9uIG9yZGVyaW5nIHcuci50 LiBtZXNzYWdlIGJvZHkuDQoNClRoYXQgc2FpZCwgSeKAmWQgcHJlZmVyIHRvIGJyZWFrIG91dCBv ZiB0aGUgZG91YmxlLW11eCBtb2RlbCBpZiB3ZSBjYW4sIG1vdmluZyB0aGluZ3MgdG8gdGhlaXIg b3duIHN0cmVhbXMgYXMgbXVjaCBhcyBwb3NzaWJsZSB0byB0YWtlIGFkdmFudGFnZSBvZiBnZXR0 aW5nIG91dCBvZiBoZWFkLW9mLWxpbmUgYmxvY2tpbmcuICBJ4oCZbSB3b3JraW5nIG9uIGEgZHJh ZnQsIGFsYmVpdCB0b28gbGF0ZSBmb3IgU2VvdWwsIGFuZCBhdCBsZWFzdCBIRUFERVJTL1BVU0hf UFJPTUlTRS9EQVRBIChhbmQgZXZlcnlvbmXigJlzIGZhdm9yaXRlLCBDT05USU5VQVRJT04pIGNh biBiZSBkcm9wcGVkIHRvIG90aGVyIHN0cmVhbXMgcHJldHR5IGVhc2lseS4gIFdlIG1heSBzdGls bCBuZWVkIGEgZGVkaWNhdGVkIHN0cmVhbSBmb3IgU0VUVElOR1MsIHRob3VnaCwgd2hpY2ggbWVh bnMgcHV0dGluZyBleHRlbnNpb25zIHRoZXJlIHRvbyBzdGlsbCBpc27igJl0IGFzIG11Y2ggb2Yg YSBzdHJldGNoIOKAkyBhdCBsZWFzdCwgZm9yIHRoaW5ncyB0aGF0IGxpdmUgb24gc3RyZWFtIHpl cm8uICBBbmQgb24tc3RyZWFtIGV4dGVuc2lvbnMsIHRvbywgcGVyaGFwcy4NCg0KRnJvbTogUVVJ QyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbmEgSXllbmdh cg0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciA3LCAyMDE2IDI6NDQgUE0NClRvOiBQYXRyaWNrIE1j TWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPg0KQ2M6IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbUVVJQ10gaDIgbWFwcGluZyAtIGV4dGVuc2lvbnMNCg0KDQoNCk9uIE1vbiwgTm92IDcs IDIwMTYgYXQgMTE6MzQgQU0sIFBhdHJpY2sgTWNNYW51cyA8cG1jbWFudXNAbW96aWxsYS5jb208 bWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tPj4gd3JvdGU6DQoNCg0KT24gTW9uLCBOb3YgNywg MjAxNiBhdCAyOjI2IFBNLCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlA Z29vZ2xlLmNvbT4+IHdyb3RlOg0KT24gVGh1LCBOb3YgMywgMjAxNiBhdCAyOjM5IFBNLCBQYXRy aWNrIE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPG1haWx0bzpwbWNtYW51c0Btb3ppbGxh LmNvbT4+IHdyb3RlOg0KSGkgUm9iYmllLCBNaWtlLCBldCBhbC4gVGhhbmtzIGZvciBnZXR0aW5n IHRoZSBiYWxsIHJvbGxpbmcgd2l0aCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt c2hhZGUtcXVpYy1odHRwMi1tYXBwaW5nLTAwLi4NCldoYXQgaXMgdGhlIHRoaW5raW5nIGFib3V0 IHJmYyA3NTQwIGgyIGV4dGVuc2lvbnMgYW5kIHRoZSBoMi9xdWljIG1hcHBpbmcuLiBwYXJ0aWN1 bGFybHkgdGhlIHdheSBpdCBhbGxvd3MgdW5zcGVjaWZpZWQgZnJhbWUgdHlwZXMgd2hpY2ggbWF5 IG9yIG1heSBub3QgcmVxdWlyZSBuZWdvdGlhdGlvbi4NCml0IHNlZW1zIHNvbWUgb2YgdGhlc2Ug ZXh0ZW5zaW9ucyBtYXkgaGF2ZSBzdGF0ZWZ1bCBpc3N1ZXMgYWNyb3NzIHN0cmVhbXMsIGFsYSBo cGFjayBhbmQgc29tZSBtYXkgbm90Lg0KSWYgdGhlIGV4dGVuc2lvbiB3ZXJlIG9ubHkgZGVmaW5l ZCBmb3IgaDItb3Zlci1xdWljIHRoYXQgd291bGQgYmUgZm9yIHRoZSBleHRlbnNpb24gdG8gc29y dCBvdXQuLiBidXQgaXQgZG9lc24ndCBzZWVtIGxpa2Ugd2UgYXJlIGxpbWl0aW5nIHRoaW5ncyB0 byBxdWljIHZzIHRjcCwgb3IgYXJlIHdlPw0KDQpOb3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IG5v dCBsaW1pdGluZyB0aGluZ3MgdG8gUVVJQyB2cy4gVENQIC0tIGRvIHlvdSBoYXZlIGEgZGlmZmVy ZW50IG1hcHBpbmcgaW4gbWluZD8NCg0KSSBtZWFudCBleHBsaWNpdGx5IHNjb3BpbmcgaDIgZXh0 ZW5zaW9ucyBzbyB0aGF0IHRoZXkgb25seSBhcHBseSB0byBxdWljIGFuZC9vciB0Y3AuLiBhbmQg aXQgZG9lcyBzZWVtIGxpa2UgdGhhdCdzIHdoYXQgeW91IG1lYW4gOikNCg0KR290Y2hhLiBJIHRo aW5rIGl0IG1ha2VzIHNlbnNlIHRvIGxpbWl0IHRvIFFVSUMgYW5kIFRDUCBhdCB0aGUgbW9tZW50 IHNpbmNlIHRoZXJlIGlzIGEgcHJvcG9zYWwgdG8gcnVuIEhUVFAgb3ZlciB0aGVzZSwgdW50aWwg c3VjaCBhIHRpbWUgYXMgdGhlcmUgaXMgYSBuZWVkIHRvIGRlZmluZSBvdmVyIGFub3RoZXIgdHJh bnNwb3J0IChsZXQncyBjYWxsIGl0IEVzc3kgVHJhbnNwb3J0IFByb3RvY29sLCB5b3Uga25vdywg RXNzeVRQKS4gSSBzdXNwZWN0IGF0IHRoYXQgcG9pbnQgdGhlIGh0dHBiaXMgd2cgKGhleSwgdGhh dCdzIHlvdSEgOi0pKSBjYW4gZmlndXJlIG91dCBob3cgdG8gZGVmaW5lIGV4dGVuc2lvbnMgb3Zl ciB0aGUgb3RoZXIgdHJhbnNwb3J0Lg0KDQpNeSBzZW5zZSBpcyB0aGF0IHdlJ2xsIG5lZWQgdG8N CihpKSBkZWZpbmUgaG93IGN1cnJlbnQgZXh0ZW5zaW9ucyB3aWxsIHdvcmsgd2l0aCBRVUlDIChl ZywgSFBBQ0spLCBhbmQNCg0KZndpdyBIUEFDSy9RUEFDSyBpcyBub3QgYW4gZXh0ZW5zaW9uIGFu ZCB5b3UgY2FuJ3QgZGVmaW5lIGl0IGFzIG9uZSBpbiBxdWljIGJlY2F1c2UgaXQgd291bGQgbmVl ZCB0byBiZSBuZWdvdGlhdGVkIGFuZCB0aGF0J3MgZ29pbmcgdG8gYnJlYWsgdGhlIDBSVFQgZ29h bCBvZiB0aGUgcHJvdG9jb2wuIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIGEgcHJvYmxlbSB0aG91Z2gg YXMgdGhlcmUgaXMgbm8gbmVlZCB0byBtYWtlIGl0IGFuIGV4dGVuc2lvbiA6KQ0KDQpBaCwgc29y cnkgLS0gbXkgZ3Jhc3Agb2Ygd2hpY2ggdGhpbmdzIGFyZSBleHRlbnNpb25zIGFuZCB3aGljaCBv bmVzIG5vdCBpbiBIVFRQLWxhbmQgaXMgd2Vhay4gSSB0aGluayBjb21wcmVzc2lvbiBpcyBsaWtl bHkgdG8gYmUgb25lIG9mIHRob3NlIHRoaW5ncyB0aGF0IGlzIGRpZmZlcmVudCBpbiBRVUlDIHRo YW4gaW4gSFRUUC8yLg0KDQooaWkpIHJlcXVpcmUgdGhhdCBmdXR1cmUgZXh0ZW5zaW9ucyBiZSBk ZWZpbmVkIGV4cGxpY2l0bHkgIGZvciBib3RoIFRDUCBhbmQgUVVJQy4NCg0KU28gdGhlIG1hcHBp bmcgZG9jdW1lbnQgd2lsbCBuZWVkIHRvIGVzdGFibGlzaCBhIG5ldyBoMiBleHRlbnNpb24gcmVn aXN0cnk/DQoNCkRvIHlvdSBtZWFuIGFuIElBTkEgcmVnaXN0cnk/IEl0J3MgcHJvYmFibHkgc2Fm ZXN0IHRvIHB1dCB0aGVzZSBleHRlbnNpb25zIHdpbGwgYmUgaW4gZGlmZmVyZW50IG5hbWVzcGFj ZXMgZW50aXJlbHksIHNvIHllcywgaWYgSSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24gY29ycmVj dGx5Lg0KDQotIGphbmENCg0KDQotUA0KDQoNCg== --_000_CY4PR03MB2710302DAFFB6926E882824D87A60CY4PR03MB2710namp_ 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 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SmFuYSwgaDIgZXh0ZW5zaW9u cyBhcmUgdmVyeSBicm9hZCDigJMgeW91IGNhbiBuZWdvdGlhdGUgKG1ldGhvZCB1bnNwZWNpZmll ZCwgYnV0IHVzdWFsbHkgYSBtdXR1YWwgU0VUVElORykgYW55IGRlcGFydHVyZSBmcm9tIG9yIGFk ZGl0aW9uIHRvIHRoZSBzcGVjLiZuYnNwOyBBZGRpdGlvbmFsbHksIGNsaWVudHMgTVVTVCBpZ25v cmUgdW5rbm93biBmcmFtZSB0eXBlcywgc28gYW55dGhpbmcgdGhhdCBkb2VzbuKAmXQgY2hhbmdl DQogdGhlIGNvcmUgb2YgdGhlIHByb3RvY29sIChlLmcuIE9SSUdJTikgY2FuIGJlIHNlbnQgc3Bl Y3VsYXRpdmVseSwgd2l0aG91dCBrbm93aW5nIHdoZXRoZXIgdGhlIHBlZXIgd2lsbCB1bmRlcnN0 YW5kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgY3VycmVudCBtYXBwaW5nLCB5b3Xi gJlyZSBlZmZlY3RpdmVseSBydW5uaW5nIGEgZnVsbCBIVFRQLzIgZnJhbWluZyBsYXllciBhbmQg bXV4IG9uIFN0cmVhbSAzLiZuYnNwOyBJdOKAmXMgcmVmZXJyZWQgdG8gYXMg4oCcdGhlIEhFQURF UlMgc3RyZWFtLOKAnSBidXQgaXQgYWN0dWFsbHkgY2FycmllcyBTRVRUSU5HUywgUFVTSF9QUk9N SVNFLCBQUklPUklUWSwgYW5kIGJhc2ljYWxseSBhbnl0aGluZyBlbHNlLiZuYnNwOyBUaGUgbWFw cGluZw0KIGRvY3VtZW50IGNhbGxzIG91dCB0aGluZ3MgdGhhdCBhcmUgZGVsZWdhdGVkIHRvIHRo ZSBRVUlDIGxheWVyIChQSU5HLCBHT0FXQVksIFdJTkRPV19VUERBVEUpIG9yIG90aGVyIFFVSUMg c3RyZWFtcyAoREFUQSksIGJ1dCBvdGhlcndpc2UgeW91IGNvdWxkIHRha2UgYXJiaXRyYXJ5IGgy IGV4dGVuc2lvbnMgYW5kIGRyb3AgaXQgb24gU3RyZWFtIDMgd2l0aG91dCBtdWNoIGNoYW5nZS4m bmJzcDsgSWYgd2Uga2VlcCB0aGF0IG1vZGVsLCB0aGF04oCZcyBwcm9iYWJseQ0KIHRoZSBkZWZh dWx0IGFuc3dlciDigJMgYW4gZXh0ZW5zaW9uIHdvcmtzIHVubGVzcyBpdCBoYXMgc29tZSBoYXJk IGRlcGVuZGVuY3kgb24gb3JkZXJpbmcgdy5yLnQuIG1lc3NhZ2UgYm9keS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhdCBzYWlkLCBJ4oCZZCBwcmVmZXIgdG8gYnJlYWsgb3V0IG9mIHRoZSBk b3VibGUtbXV4IG1vZGVsIGlmIHdlIGNhbiwgbW92aW5nIHRoaW5ncyB0byB0aGVpciBvd24gc3Ry ZWFtcyBhcyBtdWNoIGFzIHBvc3NpYmxlIHRvIHRha2UgYWR2YW50YWdlIG9mIGdldHRpbmcgb3V0 IG9mIGhlYWQtb2YtbGluZSBibG9ja2luZy4mbmJzcDsgSeKAmW0gd29ya2luZyBvbiBhIGRyYWZ0 LCBhbGJlaXQgdG9vIGxhdGUgZm9yIFNlb3VsLA0KIGFuZCBhdCBsZWFzdCBIRUFERVJTL1BVU0hf UFJPTUlTRS9EQVRBIChhbmQgZXZlcnlvbmXigJlzIGZhdm9yaXRlLCBDT05USU5VQVRJT04pIGNh biBiZSBkcm9wcGVkIHRvIG90aGVyIHN0cmVhbXMgcHJldHR5IGVhc2lseS4mbmJzcDsgV2UgbWF5 IHN0aWxsIG5lZWQgYSBkZWRpY2F0ZWQgc3RyZWFtIGZvciBTRVRUSU5HUywgdGhvdWdoLCB3aGlj aCBtZWFucyBwdXR0aW5nIGV4dGVuc2lvbnMgdGhlcmUgdG9vIHN0aWxsIGlzbuKAmXQgYXMgbXVj aCBvZiBhIHN0cmV0Y2gNCiDigJMgYXQgbGVhc3QsIGZvciB0aGluZ3MgdGhhdCBsaXZlIG9uIHN0 cmVhbSB6ZXJvLiZuYnNwOyBBbmQgb24tc3RyZWFtIGV4dGVuc2lvbnMsIHRvbywgcGVyaGFwcy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29t cG9zZSI+PG86cD4mbmJzcDs8L286cD48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YN CjwvYj5KYW5hIEl5ZW5nYXI8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBOb3ZlbWJlciA3LCAy MDE2IDI6NDQgUE08YnI+DQo8Yj5Ubzo8L2I+IFBhdHJpY2sgTWNNYW51cyAmbHQ7cG1jbWFudXNA bW96aWxsYS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBxdWljQGlldGYub3JnPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBbUVVJQ10gaDIgbWFwcGluZyAtIGV4dGVuc2lvbnM8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1vbiwgTm92IDcsIDIwMTYgYXQgMTE6MzQgQU0sIFBhdHJpY2sgTWNNYW51cyAm bHQ7PGEgaHJlZj0ibWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tIiB0YXJnZXQ9Il9ibGFuayI+ cG1jbWFudXNAbW96aWxsYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBOb3YgNywgMjAxNiBhdCAyOjI2IFBNLCBK YW5hIEl5ZW5nYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmpyaUBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1 LCBOb3YgMywgMjAxNiBhdCAyOjM5IFBNLCBQYXRyaWNrIE1jTWFudXMgJmx0OzxhIGhyZWY9Im1h aWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnBtY21hbnVzQG1vemls bGEuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIFJvYmJpZSwgTWlrZSwgZXQgYWwuIFRoYW5rcyBmb3Ig Z2V0dGluZyB0aGUgYmFsbCByb2xsaW5nIHdpdGgNCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1zaGFkZS1xdWljLWh0dHAyLW1hcHBpbmctMDAiIHRhcmdldD0iX2Js YW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaGFkZS1xdWljLWh0dHAy LW1hcHBpbmctMDA8L2E+Li48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5XaGF0IGlzIHRoZSB0aGlua2luZyBh Ym91dCByZmMgNzU0MCBoMiBleHRlbnNpb25zIGFuZCB0aGUgaDIvcXVpYyBtYXBwaW5nLi4gcGFy dGljdWxhcmx5IHRoZSB3YXkgaXQgYWxsb3dzIHVuc3BlY2lmaWVkIGZyYW1lIHR5cGVzIHdoaWNo IG1heSBvciBtYXkgbm90IHJlcXVpcmUgbmVnb3RpYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+aXQg c2VlbXMgc29tZSBvZiB0aGVzZSBleHRlbnNpb25zIG1heSBoYXZlIHN0YXRlZnVsIGlzc3VlcyBh Y3Jvc3Mgc3RyZWFtcywgYWxhIGhwYWNrIGFuZCBzb21lIG1heSBub3QuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHRoZSBleHRlbnNpb24gd2VyZSBvbmx5 IGRlZmluZWQgZm9yIGgyLW92ZXItcXVpYyB0aGF0IHdvdWxkIGJlIGZvciB0aGUgZXh0ZW5zaW9u IHRvIHNvcnQgb3V0Li4gYnV0IGl0IGRvZXNuJ3Qgc2VlbSBsaWtlIHdlIGFyZSBsaW1pdGluZyB0 aGluZ3MgdG8gcXVpYyB2cyB0Y3AsIG9yIGFyZSB3ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3Qg c3VyZSB3aGF0IHlvdSBtZWFuIGJ5IG5vdCBsaW1pdGluZyB0aGluZ3MgdG8gUVVJQyB2cy4gVENQ IC0tIGRvIHlvdSBoYXZlIGEgZGlmZmVyZW50IG1hcHBpbmcgaW4gbWluZD8mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIG1lYW50IGV4cGxpY2l0bHkgc2NvcGluZyBoMiBleHRlbnNpb25zIHNvIHRoYXQgdGhleSBv bmx5IGFwcGx5IHRvIHF1aWMgYW5kL29yIHRjcC4uIGFuZCBpdCBkb2VzIHNlZW0gbGlrZSB0aGF0 J3Mgd2hhdCB5b3UgbWVhbiA6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5H b3RjaGEuIEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8gbGltaXQgdG8gUVVJQyBhbmQgVENQIGF0 IHRoZSBtb21lbnQgc2luY2UgdGhlcmUgaXMgYSBwcm9wb3NhbCB0byBydW4gSFRUUCBvdmVyIHRo ZXNlLCB1bnRpbCBzdWNoIGEgdGltZSBhcyB0aGVyZSBpcyBhIG5lZWQgdG8gZGVmaW5lIG92ZXIg YW5vdGhlciB0cmFuc3BvcnQgKGxldCdzIGNhbGwgaXQgRXNzeSBUcmFuc3BvcnQgUHJvdG9jb2ws IHlvdSBrbm93LA0KIEVzc3lUUCkuIEkgc3VzcGVjdCBhdCB0aGF0IHBvaW50IHRoZSBodHRwYmlz IHdnIChoZXksIHRoYXQncyB5b3UhIDotKSkgY2FuIGZpZ3VyZSBvdXQgaG93IHRvIGRlZmluZSBl eHRlbnNpb25zIG92ZXIgdGhlIG90aGVyIHRyYW5zcG9ydC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NeSBzZW5zZSBpcyB0 aGF0IHdlJ2xsIG5lZWQgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPihpKSBkZWZpbmUgaG93IGN1cnJlbnQgZXh0ZW5zaW9ucyB3aWxsIHdvcmsg d2l0aCBRVUlDIChlZywgSFBBQ0spLCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+ZndpdyBIUEFDSy9RUEFDSyBpcyBub3QgYW4gZXh0ZW5zaW9uIGFuZCB5b3UgY2FuJ3Qg ZGVmaW5lIGl0IGFzIG9uZSBpbiBxdWljIGJlY2F1c2UgaXQgd291bGQgbmVlZCB0byBiZSBuZWdv dGlhdGVkIGFuZCB0aGF0J3MgZ29pbmcgdG8gYnJlYWsgdGhlIDBSVFQgZ29hbCBvZiB0aGUgcHJv dG9jb2wuIEkgZG9uJ3QgdGhpbmsgdGhhdCdzIGEgcHJvYmxlbSB0aG91Z2ggYXMgdGhlcmUgaXMg bm8gbmVlZCB0byBtYWtlDQogaXQgYW4gZXh0ZW5zaW9uIDopPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFoLCBzb3JyeSAtLSBteSBncmFzcCBvZiB3aGljaCB0aGluZ3MgYXJl IGV4dGVuc2lvbnMgYW5kIHdoaWNoIG9uZXMgbm90IGluIEhUVFAtbGFuZCBpcyB3ZWFrLiBJIHRo aW5rIGNvbXByZXNzaW9uIGlzIGxpa2VseSB0byBiZSBvbmUgb2YgdGhvc2UgdGhpbmdzIHRoYXQg aXMgZGlmZmVyZW50IGluIFFVSUMgdGhhbiBpbiBIVFRQLzIuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGlpKSByZXF1aXJl IHRoYXQgZnV0dXJlIGV4dGVuc2lvbnMgYmUgZGVmaW5lZCBleHBsaWNpdGx5ICZuYnNwO2ZvciBi b3RoIFRDUCBhbmQgUVVJQy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28g dGhlIG1hcHBpbmcgZG9jdW1lbnQgd2lsbCBuZWVkIHRvIGVzdGFibGlzaCBhIG5ldyBoMiBleHRl bnNpb24gcmVnaXN0cnk/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvIHlv dSBtZWFuIGFuIElBTkEgcmVnaXN0cnk/IEl0J3MgcHJvYmFibHkgc2FmZXN0IHRvIHB1dCB0aGVz ZSBleHRlbnNpb25zIHdpbGwgYmUgaW4gZGlmZmVyZW50IG5hbWVzcGFjZXMgZW50aXJlbHksIHNv IHllcywgaWYgSSB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb24gY29ycmVjdGx5LjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGphbmE8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+LVA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4 OCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CY4PR03MB2710302DAFFB6926E882824D87A60CY4PR03MB2710namp_-- From nobody Mon Nov 7 20:13:52 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE768129486 for ; Mon, 7 Nov 2016 20:13:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZpOjmh1XBa2 for ; Mon, 7 Nov 2016 20:13:50 -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 6A13A129476 for ; Mon, 7 Nov 2016 20:13:50 -0800 (PST) Received: from mail-it0-f53.google.com (mail-it0-f53.google.com [209.85.214.53]) by linode64.ducksong.com (Postfix) with ESMTPSA id 8C3C23A015 for ; Mon, 7 Nov 2016 23:13:49 -0500 (EST) Received: by mail-it0-f53.google.com with SMTP id q124so71111956itd.1 for ; Mon, 07 Nov 2016 20:13:49 -0800 (PST) X-Gm-Message-State: ABUngvexzDmA+3bAYlqTO1yih9oIHyw5NugBjPNE5U+0dhtkb3jcHYPpRDI1HqkmyKCbi+Ppj8WecAyCEvcWuw== X-Received: by 10.107.12.229 with SMTP id 98mr13814750iom.183.1478578429176; Mon, 07 Nov 2016 20:13:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.84.71 with HTTP; Mon, 7 Nov 2016 20:13:48 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Mon, 7 Nov 2016 23:13:48 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a113f97940b322d0540c25e6a Archived-At: Cc: quic@ietf.org, Patrick McManus Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 04:13:52 -0000 --001a113f97940b322d0540c25e6a Content-Type: text/plain; charset=UTF-8 hey Jana, On Mon, Nov 7, 2016 at 6:30 PM, Jana Iyengar wrote: (I now proceed into this bikeshed. It was good to know you all.) > fwiw - I don't believe this to be a mere matter of preference, though some may disagree. Its probably worth citing the spdy spec bug that got the endian-ness of the Setting ID wrong as a motivator. Totally avoidable category of problem. > I think disagree. I definitely think we have a clean-slate, at least as > far as *this* protocol is concerned (modulo the running code.) I would > argue that we have a well-layered protocol, but it is not "simply-layered". > See more below. > The layer boundaries here are not strong - and that's OK! That's the nature of this design and the source of of its benefits. I should have said not strongly layered instead of not well layered which implied a judgment that I don't even agree with. What we should be aiming for is strong alignment and coherency, not strong boundaries. I mentioned a couple ways these layers bleed through already (h2 frames referencing transport frame ids, and the packet number in the aead nonce), but there's also the transport windowing information carried in a tls extension and the versioning information repeated in no less than 3 layers (alt-svc, version, alpn) and no doubt more spots. All of this is for the good - I'm just saying we need to look at the coherency question as the integrated big picture. Putting things in the same byte order is just table stakes. wrt clean slate - my references were to the constraints of tls 1.3 and h2.. we're going to want to keep those as unchanged as possible as design goals; so aligning with them is valuable and that's a constraint. Aligning is important, as they aren't layers isolated from each other in the same way TCP/TLS/7540-h2 are. I may have been misunderstood to be referencing google-quic and I certainly appreciate a willingness to break with that. does that make more sense? -P --001a113f97940b322d0540c25e6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
hey Jana,

On Mon, Nov 7, 2016 at 6:30 PM, Jana Iyengar <jri@google.co= m> wrote:

(I now proceed into this bikeshed. It was good to know you all.)<= br>

fwiw - I d= on't believe this to be a mere matter of preference, though some may di= sagree. Its probably worth citing the spdy spec bug that got the endian-nes= s of=20 the Setting ID wrong as a motivator. Totally avoidable category of problem.=
=C2=A0
I think disagree. I definite= ly think we have a clean-slate, at least as far as *this* protocol is conce= rned (modulo the running code.) I would argue that we have a well-layered p= rotocol, but it is not "simply-layered". See more below.

The layer boundaries here are not strong= - and that's OK! That's the nature of this design and the source o= f of its benefits. I should have said=C2=A0 not strongly layered instead of= not well layered which implied a judgment that I don't even agree with= . What we should be aiming for is strong alignment and coherency, not stron= g boundaries.

I mentioned a couple ways these layers blee= d through already (h2 frames referencing transport frame ids, and the packe= t number in the aead nonce), but there's also the transport windowing i= nformation carried in a tls extension and the versioning information repeat= ed in no less than 3 layers (alt-svc, version, alpn) and no doubt more spot= s. All of this is for the good - I'm just saying we need to look at the= coherency question as the integrated big picture. Putting things in the sa= me byte order is just table stakes.

wrt clean = slate - my references were to the=20 constraints of tls 1.3 and h2.. we're going to want to keep those as=20 unchanged as possible as design goals; so aligning with them is valuable and that's a constraint. Aligning is important, as they aren't lay= ers isolated from each other in the same way TCP/TLS/7540-h2 are.

I = may have been misunderstood to be=20 referencing google-quic and I certainly appreciate a willingness to break w= ith=20 that.

does that make more sense?
-P
--001a113f97940b322d0540c25e6a-- From nobody Mon Nov 7 23:08:37 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E7B1295BF for ; Mon, 7 Nov 2016 23:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZyGUl3Bd2l1 for ; Mon, 7 Nov 2016 23:08:33 -0800 (PST) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::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 B12A712967C for ; Mon, 7 Nov 2016 23:08:32 -0800 (PST) Received: by mail-ua0-x22b.google.com with SMTP id 12so139793972uas.2 for ; Mon, 07 Nov 2016 23:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eVvM4m06uf5OWdwFz1Q+956Euy5Hg8fevXSY+g1xbeU=; b=nugTpk/b3MtME0MV1BXXMtGyjObN9LpKjesOL+qGFMF9KVgZeLahEX7C2EpYgWNhio G02ZL1raIL/b8AnwdjhvoW6pjOdi61hPL5EnWtn74BJlh3KXZj/xSo1X+Q/SzTV80BNh g69QbDsgUEkntjbMVVEpGnY9k3qx7UETNf9qelfEydE/9AxuF1Hv8WqAvMUeNytVJvvo Mv0zaVhtSUwTBnggTfCIhzYwLu80GRHIugPp6d0NDmOqDIV7Phi9U35HXIy4JwDOGtml ecoICqefA9RGatoiiDGmCmEv2GitElXccAjgifb1cmf0rHKgjFHvQ3qU+xjmnIHu6eNj w9Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eVvM4m06uf5OWdwFz1Q+956Euy5Hg8fevXSY+g1xbeU=; b=BzuNvDi3WleUU6pcdTjGTfhOWyHNuk/PWOVT1fFP6IiQ526Mx4IHDmDBBSvcAxWIQq 1JTzjQRYMahQWPMcIVqOulQfoHWiqWvffX/p1xMkN0SOVCLqb8NVOUcC9lJrIX68LgHo XG+26DEpYMobtktF/Rddu2fwnUKtQ9kguHOSS7O2TTiHacV1kwmZ1wWy7YJm+K7oEmyh BuNOjX7F8deXqdJS+ZwvnJX93KURlWyMUmDaRSfCSPsmnOLRmGbOiIW7ZWDeP1Pwno0T hxroKgSSo76w82WK7p9CuCZ82u8ThEGTZQNrtveGgrtKi+GKzMl55zjYy3eyfnbJ5Npc 59pA== X-Gm-Message-State: ABUngvdoeJ6G0/1pz0UoUBmCcOWj49E5pF/Kyod+Tv+2t6QpRJDI1sQkOKObVDqdQMGVN0DhA3fjPZz5xRwfBUG0 X-Received: by 10.176.82.157 with SMTP id v29mr6283479uav.123.1478588911730; Mon, 07 Nov 2016 23:08:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Mon, 7 Nov 2016 23:08:30 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Mon, 7 Nov 2016 23:08:30 -0800 Message-ID: To: Patrick McManus Content-Type: multipart/alternative; boundary=94eb2c18f88ada84a70540c4ce5e Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 07:08:36 -0000 --94eb2c18f88ada84a70540c4ce5e Content-Type: text/plain; charset=UTF-8 On Mon, Nov 7, 2016 at 8:13 PM, Patrick McManus wrote: > hey Jana, > > On Mon, Nov 7, 2016 at 6:30 PM, Jana Iyengar wrote: > > (I now proceed into this bikeshed. It was good to know you all.) >> > > fwiw - I don't believe this to be a mere matter of preference, though some > may disagree. Its probably worth citing the spdy spec bug that got the > endian-ness of the Setting ID wrong as a motivator. Totally avoidable > category of problem. > Fair enough. Apologies for being facetious. I think disagree. I definitely think we have a clean-slate, at least as far >> as *this* protocol is concerned (modulo the running code.) I would argue >> that we have a well-layered protocol, but it is not "simply-layered". See >> more below. >> > > The layer boundaries here are not strong - and that's OK! That's the > nature of this design and the source of of its benefits. I should have > said not strongly layered instead of not well layered which implied a > judgment that I don't even agree with. What we should be aiming for is > strong alignment and coherency, not strong boundaries. > +1. I mentioned a couple ways these layers bleed through already (h2 frames > referencing transport frame ids, and the packet number in the aead nonce), > but there's also the transport windowing information carried in a tls > extension and the versioning information repeated in no less than 3 layers > (alt-svc, version, alpn) and no doubt more spots. All of this is for the > good - I'm just saying we need to look at the coherency question as the > integrated big picture. Putting things in the same byte order is just table > stakes. > I agree that we should look at the integrated picture. My argument was that the wire format of QUIC is independent of wire formats of the others. In general, I think that we can separate concerns about byte order for QUIC from others. That said, your point is about reducing vulnerabilities, and is well taken. I think you're making a compelling argument. > wrt clean slate - my references were to the constraints of tls 1.3 and > h2.. we're going to want to keep those as unchanged as possible as design > goals; so aligning with them is valuable and that's a constraint. Aligning > is important, as they aren't layers isolated from each other in the same > way TCP/TLS/7540-h2 are. > As I pointed out in my earlier email, I think that these are close but separable. Specifically, when it comes to wire format, I think it's reasonable to separate the processing of the various headers, which is what matters for endianness. I don't think that QUIC's choice of endianness should or will affect the wire formats of either TLS or H2, because, as I pointed out, neither TLS nor H2 will be processing the QUIC wire format directly. > I may have been misunderstood to be referencing google-quic and I > certainly appreciate a willingness to break with that. > Thanks for the clarification. > does that make more sense? > It does. I still think, perhaps naively, that these wire formats are separable. If QUIC version shows up in 3 places, it obeys the wire format of the 3 places where it shows up. I can see how different endian-nesses can leak though, but my point was that these could be well-specified where there's confusion. That said, I think your point is "avoid the confusion in the first place." This may be worth a consensus call, since the spec says little-endian currently, and we'll have to decide what to do upon adoption. - jana > -P > --94eb2c18f88ada84a70540c4ce5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 7, 2016 at 8:13 PM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
hey J= ana,

On Mon, Nov 7, 2016 at 6:30 PM, Jana Iyengar <jri@google.com= > wrote:

(I now proceed into this bikeshed. It was good t= o know you all.)

fwiw - I don't believe this to be a mere matter of prefer= ence, though some may disagree. Its probably worth citing the spdy spec bug= that got the endian-ness of=20 the Setting ID wrong as a motivator. Totally avoidable category of problem.=

Fair enough.= Apologies for being facetious.

I think disagree. I definitely= think we have a clean-slate, at least as far as *this* protocol is concern= ed (modulo the running code.) I would argue that we have a well-layered pro= tocol, but it is not "simply-layered". See more below.
<= /div>

The layer boundaries here are not s= trong - and that's OK! That's the nature of this design and the sou= rce of of its benefits. I should have said=C2=A0 not strongly layered inste= ad of not well layered which implied a judgment that I don't even agree= with. What we should be aiming for is strong alignment and coherency, not = strong boundaries.

<= div>+1.

I me= ntioned a couple ways these layers bleed through already (h2 frames referen= cing transport frame ids, and the packet number in the aead nonce), but the= re's also the transport windowing information carried in a tls extensio= n and the versioning information repeated in no less than 3 layers (alt-svc= , version, alpn) and no doubt more spots. All of this is for the good - I&#= 39;m just saying we need to look at the coherency question as the integrate= d big picture. Putting things in the same byte order is just table stakes.<= br>

I agree that we= should look at the integrated picture. My argument was that the wire forma= t of QUIC is independent of wire formats of the others. In general, I think= that we can separate concerns about byte order for QUIC from others. That = said, your point is about reducing vulnerabilities, and is well taken. I th= ink you're making a compelling argument.
=C2=A0
wrt clean slate - my referenc= es were to the=20 constraints of tls 1.3 and h2.. we're going to want to keep those as=20 unchanged as possible as design goals; so aligning with them is valuable and that's a constraint. Aligning is important, as they aren't lay= ers isolated from each other in the same way TCP/TLS/7540-h2 are.
=

As I pointed out in my e= arlier email, I think that these are close but separable. Specifically, whe= n it comes to wire format, I think it's reasonable to separate the proc= essing of the various headers, which is what matters for endianness. I don&= #39;t think that QUIC's choice of endianness should or will affect the = wire formats of either TLS or H2, because, as I pointed out, neither TLS no= r H2 will be processing the QUIC wire format directly.
=C2=A0
I may have been misunderstood to be=20 referencing google-quic and I certainly appreciate a willingness to break w= ith=20 that.

Thanks for th= e clarification.
=C2=A0
does= that make more sense?

<= div>It does. I still think, perhaps naively, that these wire formats are se= parable. If QUIC version shows up in 3 places, it obeys the wire format of = the 3 places where it shows up. I can see how different endian-nesses can l= eak though, but my point was that these could be well-specified where there= 's confusion. That said, I think your point is "avoid the confusio= n in the first place."

This may be worth a co= nsensus call, since the spec says little-endian currently, and we'll ha= ve to decide what to do upon adoption.

- jana
=C2=A0
-P

--94eb2c18f88ada84a70540c4ce5e-- From nobody Tue Nov 8 00:57:31 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6595129CA8 for ; Tue, 8 Nov 2016 00:57:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=OMmdKxsL; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=OMmdKxsL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WZWMjfs8Vuz for ; Tue, 8 Nov 2016 00:57:28 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C648A129C9C for ; Tue, 8 Nov 2016 00:57:11 -0800 (PST) Received: by mail.greenbytes.de (Postfix, from userid 117) id A6C2915A2ED6; Tue, 8 Nov 2016 09:57:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1478595429; bh=SM7DEliNP51O/WM7pXo0MOfy/nwboLw3tBJzJe8DqDs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=OMmdKxsLNDOE2AmfnofgSpGEVL4KNlm+SKgyF1hpq/OJ3g7++p4vkudI09PWvDDyI 3M3nrTAbrAi5MJSGNS7+bn53Jta9rfGBd2de8m/c7Rc03lF5pMHDVMwvXXIcOGVN2G dT4Nu96LLe+naRw93UnwA9vuiS6jTEkSAUIB8dnk= Received: from [192.168.1.175] (unknown [192.168.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id D069115A2ED5; Tue, 8 Nov 2016 09:57:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1478595429; bh=SM7DEliNP51O/WM7pXo0MOfy/nwboLw3tBJzJe8DqDs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=OMmdKxsLNDOE2AmfnofgSpGEVL4KNlm+SKgyF1hpq/OJ3g7++p4vkudI09PWvDDyI 3M3nrTAbrAi5MJSGNS7+bn53Jta9rfGBd2de8m/c7Rc03lF5pMHDVMwvXXIcOGVN2G dT4Nu96LLe+naRw93UnwA9vuiS6jTEkSAUIB8dnk= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Stefan Eissing In-Reply-To: Date: Tue, 8 Nov 2016 09:57:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Mike Bishop X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Jana Iyengar , "quic@ietf.org" , Patrick McManus Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 08:57:30 -0000 > Am 08.11.2016 um 03:23 schrieb Mike Bishop = : >=20 > That said, I=E2=80=99d prefer to break out of the double-mux model if = we can, moving things to their own streams as much as possible to take = advantage of getting out of head-of-line blocking. I=E2=80=99m working = on a draft, albeit too late for Seoul, and at least = HEADERS/PUSH_PROMISE/DATA (and everyone=E2=80=99s favorite, = CONTINUATION) can be dropped to other streams pretty easily. We may = still need a dedicated stream for SETTINGS, though, which means putting = extensions there too still isn=E2=80=99t as much of a stretch =E2=80=93 = at least, for things that live on stream zero. And on-stream = extensions, too, perhaps. +1= From nobody Tue Nov 8 12:09:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAFD1295A7 for ; Tue, 8 Nov 2016 12:09:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNrtC77G4aTj for ; Tue, 8 Nov 2016 12:09:35 -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 B672B1295CA for ; Tue, 8 Nov 2016 12:09:35 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id r204so193547589ywb.0 for ; Tue, 08 Nov 2016 12:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GTUvyTJnTwzjTnvFIKT6VFaBOllQgGrC+e1T4A6ACig=; b=ok+lIk04ZroIQyIOZYWXsWIzUI5ysuBP11VdBLbjNEBGi3lo+mV+Iwu7/k8JKzTaW2 AAuiIgV8FTWnsmeyfLXyYOr/ijw15qan6AL5PxlbAshTR4KNEa/yYzfHbhdX3H3kbITo AYW3Hixy5PNOsc8kzMf/6U8sHoCrDbZlK5aC9EU43x6OJYOUqS0NPVPvOnZZ4+lEqOYU N0mLZJnc0bpBugbOCGUo4yyLKseZR8JOsGDnmhzsgMfNu80hoKUYj1o4HSE+IYVMMAPr 4t9pGwXGsvKxSmp9MRW5LXQw+ZKTFWNLqHuH3OvcUizkM5UiKbJdI4p4M62BEw2xdrR4 oYEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GTUvyTJnTwzjTnvFIKT6VFaBOllQgGrC+e1T4A6ACig=; b=EV5PxP4rNu9BQBOfSWupPbNXZNlWdFRCsTdVxCf4vd2PCHU54hz+HrcrcuBx22lkDq wicIzMO6/sMWSJGoYP4VqSZahvWn7EqVFExC1qFp6OWgsxN3XLY0z9rR3Sl6upV4nDMp jPfiOTV0wm/3LWaPPSTQKk3ElRsGhHOiqQO89lZtwYue6FG98vW45FEM0c4FD3mSn9mW W4kroLuT0RQ0I7zBt8EOzfBx3izurr4mWT1I2hg04tSlIp0xuVhNM9rhb1deLA6VkbI9 2gAyMPxX+v+i97emyIsf9k7K10ImCzf+qqkrZj4jH3Fuqa9477AREjLqN9QX9esqphWk nRcw== X-Gm-Message-State: ABUngve/ukfp62zzxgSj47+iEruAL8DOz3t57KI0RYf8SkYmTJs7lgiGcH7qxYGQYdS/GnCxvTDFlk5DR0BwCURR X-Received: by 10.129.168.131 with SMTP id f125mr11697307ywh.215.1478635774778; Tue, 08 Nov 2016 12:09:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.203.69 with HTTP; Tue, 8 Nov 2016 12:09:14 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 8 Nov 2016 15:09:14 -0500 Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c13cbe21becb80540cfb816 Archived-At: Cc: Ted Hardie , quic@ietf.org, Martin Thomson , Patrick McManus Subject: Re: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 20:09:38 -0000 --94eb2c13cbe21becb80540cfb816 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 7, 2016 at 9:04 PM, Jana Iyengar wrote: > I agree that we should have a plan for iteration and diversity, and should > have versioning figured out early. FWIW, I don't think compatibility is an > issue (it would be convenient if the placement of the version field were > not changed,) since this version space is quite humongous. > > QUIC currently treats this as a 32-bit space, into which the QUIC version > made up of 4 ASCII characters is encoded. "Q034" is encoded on the wire as > 0x 51 30 33 36. There's no interesting structure here since these aren't > treated as numbers... so unfortunately Patrick, I don't think your clever > trick is going to do much. Google servers and Chrome use lists of > currently-supported versions on each side, and there's no expectation of > continuity in the 32-bit space, since the versions are simply arbitrary > points in this space. > > So, I'll take Martin's arrangement and change it slightly: > > The IETF reserves versions 0x00000001 to 0x0000ffff (16K versions) for > standards work (drafts and standards.) > - In this space, designate 0x00000001 - 0x0000fff (4096 versions) to QUIC > standards > - Designate the rest of the IETF-reserved space, 0x00001000 - 0x0000ffff > (~60K versions), for corresponding draft versions. That is, 0x00001001 > would correspond to a potential -01 version of the core protocol draft. > > This leaves the space from 0x00010000 upwards (~4 billion versions) for > uncoordinated and distributed experimentation. Since current QUIC sits at > 0x51303336, this shouldn't interfere with future draft versions. > > Distributed is great, uncoordinated sounds a bit dangerous to me. Before a larger number of experiments with different versions start, I'd suggest we allocate a 256 or so versions to each organization which has a need to experiment, in order to prevent conflicts. Until we have a process for that, ideally we can focus on the core drafts and any experimentation can mostly be done with feature negotiation, not full version negotiation? In a similar direction, possibly we want to allocate a QuicTag for each organization to use to negotiate features? > On Mon, Nov 7, 2016 at 2:26 PM, Patrick McManus > wrote: > >> I'm eager to get a plan on this as well - its essential for iteration and >> diversity. >> >> I would push back just a tad against Ted's message - this might be the >> one place in the protocol where we have some backwards compatible >> constraints. There is already trail blazing code running on UDP/443 but we >> also want to allow ietf-quic to run on UDP/443 simultaneously during >> development to get experience with that So I'm not sure we really can >> change the location of the version field, at least not in a way that isn't >> cleverly compatible. It is essentially the magic number of the format. >> >> However, I think we're in a good place here if we can agree that network >> byte order is the way to go. If we do that, Google can 'squat' on the high >> byte (which would include what I understand are the 34 existing versions if >> expressed as low endian) for now and the IETF space can have the low three >> bytes without worry.. by the time it gets up to the 25th bit I would hope >> old proto-quic implementations were no longer a going concern. A similarly >> high range could also be carved out for permissionless experimentations in >> the pre-rfc period - but we wouldn't have to settle on that right away. >> >> And this makes for a nice document - just say the first draft is verison >> 1 and is in network byte order and that packets received with a version >= >> 0x01000000 MUST NOT be replied to with ietf-quic. >> >> -Patrick >> >> >> >> >> >> On Mon, Nov 7, 2016 at 4:40 PM, Ted Hardie wrote: >> >>> On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson >> > wrote: >>> >>>> I'm getting a lot of questions from people who are starting to >>>> implement. I'm guessing that I'm only seeing a small proportion of >>>> the total volume. That's great. >>>> >>>> But it's going to be hard to deploy unless we have some ground rules >>>> about how to identify the protocol version. >>>> >>>> Here's a strawman, loosely based on what I've learned from HTTP/2 and >>>> TLS 1.3: >>>> >>>> QUIC version numbers are 32-bits. >>> >>> >>> This is, presumably, one of the things we can change. More broadly, I >>> think we need to think about a more granular approach to this, so we can >>> have multiple folks experimenting without either needless conflict or >>> over-much coordination. >>> >>> There are a lot of folks who have deeply held opinions about extensions, >>> negotiation, and version, and I don't want to tread over all that ground, >>> but I think we should not assume that we should start from where we are. >>> >>> >>> Just my personal opinion, >>> >>> Ted >>> >>> >>> >>>> We reserve everything in the range >>>> 0xffff0000-0xffffffff for experimentation. We designate 0xffff5100 >>>> and up as corresponding to versions of the draft. That is, 0xffff5101 >>>> would correspond to a potential -01 version of the core protocol >>>> draft. (Obviously, this would be post-WG-adoption, which I hope >>>> happens soon.) >>>> >>>> Similarly, we designate ALPN labels to match. "quic-01" would >>>> correspond to the same version of the HTTP mapping draft. Hopefully >>>> the mapping draft would progress in lock-step, but if it doesn't, then >>>> the core protocol version that corresponds to the ALPN label would be >>>> determined by what version of the core protocol is referenced by the >>>> mapping document. >>>> >>>> I think that we should agree to a scheme for protocol identifiers (it >>>> doesn't have to be this) at the meeting next week. >>>> >>>> >>> >> > --94eb2c13cbe21becb80540cfb816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 7, 2016 at 9:04 PM, Jana Iyengar <jri@google.com> wrote= :
I agree that we should= have a plan for iteration and diversity, and should have versioning figure= d out early. FWIW, I don't think compatibility is an issue (it would be= convenient if the placement of the version field were not changed,) since = this version space is quite humongous.

QUIC currently tr= eats this as a 32-bit space, into which the QUIC version made up of 4 ASCII= characters is encoded. "Q034" is encoded on the wire as 0x 51 30= 33 36. There's no interesting structure here since these aren't tr= eated as numbers... so unfortunately Patrick, I don't think your clever= trick is going to do much. Google servers and Chrome use lists of currentl= y-supported versions on each side, and there's no expectation of contin= uity in the 32-bit space, since the versions are simply arbitrary points in= this space.

So, I'll take Martin's arrang= ement and change it slightly:

The IETF reserves ve= rsions 0x00000001 to 0x0000ffff (16K versions) for standards work (drafts a= nd standards.)=C2=A0
- In this space, designate =C2=A00x00000001 = - 0x0000fff (4096 versions) to QUIC standards
- Designate the res= t of the IETF-reserved space, 0x00001000 - 0x0000ffff (~60K versions), for = corresponding draft versions. That is, 0x00001001 would correspond to a pot= ential -01 version of the core protocol draft.

Thi= s leaves the space from 0x00010000 upwards (~4 billion versions) for uncoor= dinated and distributed experimentation. Since current QUIC sits at 0x51303= 336, this shouldn't interfere with future draft versions.

Distributed is great, uncoord= inated sounds a bit dangerous to me.=C2=A0 Before a larger number of experi= ments with different versions start, I'd suggest we allocate a 256 or s= o versions to each organization which has a need to experiment, in order to= prevent conflicts.

Until we have a process for th= at, ideally we can focus on the core drafts and any experimentation can mos= tly be done with feature negotiation, not full version negotiation?=C2=A0 I= n a similar direction, possibly we want to allocate a QuicTag for each orga= nization to use to negotiate features?


On = Mon, Nov 7, 2016 at 2:26 PM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
=
I'm eager to get a plan on this as well - its essential = for iteration and diversity.

I would push back just a tad agai= nst Ted's message - this might be the one place in the protocol where w= e have some backwards compatible constraints. There is already trail blazin= g code running on UDP/443 but we also want to allow ietf-quic to run on UDP= /443 simultaneously during development to get experience with that So I'= ;m not sure we really can change the location of the version field, at leas= t not in a way that isn't cleverly compatible. It is essentially the ma= gic number of the format.

However, I think we're in a good= place here if we can agree that network byte order is the way to go. If we= do that, Google can 'squat' on the high byte (which would include = what I understand are the 34 existing versions if expressed as low endian) = for now and the IETF space can have the low three bytes without worry.. by = the time it gets up to the 25th bit I would hope old proto-quic implementat= ions were no longer a going concern. A similarly high range could also be c= arved out for permissionless experimentations in the pre-rfc period - but w= e wouldn't have to settle on that right away.

And this mak= es for a nice document - just say the first draft is verison 1 and is in ne= twork byte order and that packets received with a version >=3D 0x0100000= 0 MUST NOT be replied to with ietf-quic.

-Patrick

<= div>



=

On Mon, = Nov 7, 2016 at 4:40 PM, Ted Hardie <ted.ietf@gmail.com> wro= te:
On Mon, Nov 7,= 2016 at 1:01 PM, Martin Thomson <martin.thomson@gmail.com><= /span> wrote:
I'm getting = a lot of questions from people who are starting to
implement.=C2=A0 I'm guessing that I'm only seeing a small proporti= on of
the total volume.=C2=A0 That's great.

But it's going to be hard to deploy unless we have some ground rules about how to identify the protocol version.

Here's a strawman, loosely based on what I've learned from HTTP/2 a= nd TLS 1.3:

QUIC version numbers are 32-bits.

Th= is is, presumably, one of the things we can change.=C2=A0 More broadly, I t= hink we need to think about a more granular approach to this, so we can hav= e multiple folks experimenting without either needless conflict or over-muc= h coordination.=C2=A0

There are a lot of folks who have deeply held= opinions about extensions, negotiation, and version, and I don't want = to=C2=A0 tread over all that ground, but I think we should not assume that = we should start from where we are.


Just my personal o= pinion,

Ted

=C2=A0
=C2=A0 We reserve everything in th= e range
0xffff0000-0xffffffff for experimentation.=C2=A0 We designate 0xffff5100 and up as corresponding to versions of the draft.=C2=A0 That is, 0xffff5101=
would correspond to a potential -01 version of the core protocol
draft.=C2=A0 (Obviously, this would be post-WG-adoption, which I hope
happens soon.)

Similarly, we designate ALPN labels to match.=C2=A0 "quic-01" wou= ld
correspond to the same version of the HTTP mapping draft.=C2=A0 Hopefully the mapping draft would progress in lock-step, but if it doesn't, then<= br> the core protocol version that corresponds to the ALPN label would be
determined by what version of the core protocol is referenced by the
mapping document.

I think that we should agree to a scheme for protocol identifiers (it
doesn't have to be this) at the meeting next week.





--94eb2c13cbe21becb80540cfb816-- From nobody Tue Nov 8 13:32:09 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCC7129493 for ; Tue, 8 Nov 2016 13:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSyBWKDwQCB3 for ; Tue, 8 Nov 2016 13:32:05 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id C03A81293F3 for ; Tue, 8 Nov 2016 13:32:05 -0800 (PST) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) by linode64.ducksong.com (Postfix) with ESMTPSA id 241163A01B for ; Tue, 8 Nov 2016 16:32:05 -0500 (EST) Received: by mail-it0-f47.google.com with SMTP id q124so234194794itd.1 for ; Tue, 08 Nov 2016 13:32:05 -0800 (PST) X-Gm-Message-State: ABUngveHrJ+ein64pwwjbJi0TBe2xACuq+BCnDVodOWppi/94iL4qBrFyk047MLTxbcGYhLgWt6LK6eqBXPn3Q== X-Received: by 10.36.4.20 with SMTP id 20mr9493120itb.109.1478640724688; Tue, 08 Nov 2016 13:32:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.84.71 with HTTP; Tue, 8 Nov 2016 13:32:04 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Tue, 8 Nov 2016 16:32:04 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ian Swett Content-Type: multipart/alternative; boundary=001a11c149a225495a0540d0df5b Archived-At: Cc: Jana Iyengar , Ted Hardie , quic@ietf.org, Martin Thomson , Patrick McManus Subject: Re: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 21:32:07 -0000 --001a11c149a225495a0540d0df5b Content-Type: text/plain; charset=UTF-8 maybe just a wiki page for self-registration during the pre-rfc period would suffice? permissionless is good. On Tue, Nov 8, 2016 at 3:09 PM, Ian Swett wrote: > On Mon, Nov 7, 2016 at 9:04 PM, Jana Iyengar wrote: > >> I agree that we should have a plan for iteration and diversity, and >> should have versioning figured out early. FWIW, I don't think compatibility >> is an issue (it would be convenient if the placement of the version field >> were not changed,) since this version space is quite humongous. >> >> QUIC currently treats this as a 32-bit space, into which the QUIC version >> made up of 4 ASCII characters is encoded. "Q034" is encoded on the wire as >> 0x 51 30 33 36. There's no interesting structure here since these aren't >> treated as numbers... so unfortunately Patrick, I don't think your clever >> trick is going to do much. Google servers and Chrome use lists of >> currently-supported versions on each side, and there's no expectation of >> continuity in the 32-bit space, since the versions are simply arbitrary >> points in this space. >> >> So, I'll take Martin's arrangement and change it slightly: >> >> The IETF reserves versions 0x00000001 to 0x0000ffff (16K versions) for >> standards work (drafts and standards.) >> - In this space, designate 0x00000001 - 0x0000fff (4096 versions) to >> QUIC standards >> - Designate the rest of the IETF-reserved space, 0x00001000 - 0x0000ffff >> (~60K versions), for corresponding draft versions. That is, 0x00001001 >> would correspond to a potential -01 version of the core protocol draft. >> >> This leaves the space from 0x00010000 upwards (~4 billion versions) for >> uncoordinated and distributed experimentation. Since current QUIC sits at >> 0x51303336, this shouldn't interfere with future draft versions. >> >> > Distributed is great, uncoordinated sounds a bit dangerous to me. Before > a larger number of experiments with different versions start, I'd suggest > we allocate a 256 or so versions to each organization which has a need to > experiment, in order to prevent conflicts. > > Until we have a process for that, ideally we can focus on the core drafts > and any experimentation can mostly be done with feature negotiation, not > full version negotiation? In a similar direction, possibly we want to > allocate a QuicTag for each organization to use to negotiate features? > > >> On Mon, Nov 7, 2016 at 2:26 PM, Patrick McManus >> wrote: >> >>> I'm eager to get a plan on this as well - its essential for iteration >>> and diversity. >>> >>> I would push back just a tad against Ted's message - this might be the >>> one place in the protocol where we have some backwards compatible >>> constraints. There is already trail blazing code running on UDP/443 but we >>> also want to allow ietf-quic to run on UDP/443 simultaneously during >>> development to get experience with that So I'm not sure we really can >>> change the location of the version field, at least not in a way that isn't >>> cleverly compatible. It is essentially the magic number of the format. >>> >>> However, I think we're in a good place here if we can agree that network >>> byte order is the way to go. If we do that, Google can 'squat' on the high >>> byte (which would include what I understand are the 34 existing versions if >>> expressed as low endian) for now and the IETF space can have the low three >>> bytes without worry.. by the time it gets up to the 25th bit I would hope >>> old proto-quic implementations were no longer a going concern. A similarly >>> high range could also be carved out for permissionless experimentations in >>> the pre-rfc period - but we wouldn't have to settle on that right away. >>> >>> And this makes for a nice document - just say the first draft is verison >>> 1 and is in network byte order and that packets received with a version >= >>> 0x01000000 MUST NOT be replied to with ietf-quic. >>> >>> -Patrick >>> >>> >>> >>> >>> >>> On Mon, Nov 7, 2016 at 4:40 PM, Ted Hardie wrote: >>> >>>> On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson < >>>> martin.thomson@gmail.com> wrote: >>>> >>>>> I'm getting a lot of questions from people who are starting to >>>>> implement. I'm guessing that I'm only seeing a small proportion of >>>>> the total volume. That's great. >>>>> >>>>> But it's going to be hard to deploy unless we have some ground rules >>>>> about how to identify the protocol version. >>>>> >>>>> Here's a strawman, loosely based on what I've learned from HTTP/2 and >>>>> TLS 1.3: >>>>> >>>>> QUIC version numbers are 32-bits. >>>> >>>> >>>> This is, presumably, one of the things we can change. More broadly, I >>>> think we need to think about a more granular approach to this, so we can >>>> have multiple folks experimenting without either needless conflict or >>>> over-much coordination. >>>> >>>> There are a lot of folks who have deeply held opinions about >>>> extensions, negotiation, and version, and I don't want to tread over all >>>> that ground, but I think we should not assume that we should start from >>>> where we are. >>>> >>>> >>>> Just my personal opinion, >>>> >>>> Ted >>>> >>>> >>>> >>>>> We reserve everything in the range >>>>> 0xffff0000-0xffffffff for experimentation. We designate 0xffff5100 >>>>> and up as corresponding to versions of the draft. That is, 0xffff5101 >>>>> would correspond to a potential -01 version of the core protocol >>>>> draft. (Obviously, this would be post-WG-adoption, which I hope >>>>> happens soon.) >>>>> >>>>> Similarly, we designate ALPN labels to match. "quic-01" would >>>>> correspond to the same version of the HTTP mapping draft. Hopefully >>>>> the mapping draft would progress in lock-step, but if it doesn't, then >>>>> the core protocol version that corresponds to the ALPN label would be >>>>> determined by what version of the core protocol is referenced by the >>>>> mapping document. >>>>> >>>>> I think that we should agree to a scheme for protocol identifiers (it >>>>> doesn't have to be this) at the meeting next week. >>>>> >>>>> >>>> >>> >> > --001a11c149a225495a0540d0df5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
maybe just a wiki page for self-registration during the pr= e-rfc period would suffice? permissionless is good.

On Tue, Nov 8, 2016 at 3:09 PM,= Ian Swett <ianswett@google.com> wrote:
On Mon, Nov 7, 2016 at 9:04 PM, Jana Iyengar <= span dir=3D"ltr"><jr= i@google.com> wrote:
I agree that we should have a plan for iteration and diversity, = and should have versioning figured out early. FWIW, I don't think compa= tibility is an issue (it would be convenient if the placement of the versio= n field were not changed,) since this version space is quite humongous.
QUIC currently treats this as a 32-bit space, into which th= e QUIC version made up of 4 ASCII characters is encoded. "Q034" i= s encoded on the wire as 0x 51 30 33 36. There's no interesting structu= re here since these aren't treated as numbers... so unfortunately Patri= ck, I don't think your clever trick is going to do much. Google servers= and Chrome use lists of currently-supported versions on each side, and the= re's no expectation of continuity in the 32-bit space, since the versio= ns are simply arbitrary points in this space.

So, = I'll take Martin's arrangement and change it slightly:
The IETF reserves versions 0x00000001 to 0x0000ffff (16K versi= ons) for standards work (drafts and standards.)=C2=A0
- In this s= pace, designate =C2=A00x00000001 - 0x0000fff (4096 versions) to QUIC standa= rds
- Designate the rest of the IETF-reserved space, 0x00001000 -= 0x0000ffff (~60K versions), for corresponding draft versions. That is, 0x0= 0001001 would correspond to a potential -01 version of the core protocol dr= aft.

This leaves the space from 0x00010000 upwards= (~4 billion versions) for uncoordinated and distributed experimentation. S= ince current QUIC sits at 0x51303336, this shouldn't interfere with fut= ure draft versions.


<= /span>
Distributed is great, uncoordinated sounds a bit dangerous to me= .=C2=A0 Before a larger number of experiments with different versions start= , I'd suggest we allocate a 256 or so versions to each organization whi= ch has a need to experiment, in order to prevent conflicts.

<= /div>
Until we have a process for that, ideally we can focus on the cor= e drafts and any experimentation can mostly be done with feature negotiatio= n, not full version negotiation?=C2=A0 In a similar direction, possibly we = want to allocate a QuicTag for each organization to use to negotiate featur= es?

On Mon, Nov 7, 2016 at 2:26 PM, Patrick McManu= s <pmcmanus@mozilla.com> wrote:
I'm eager to get a plan o= n this as well - its essential for iteration and diversity.

I = would push back just a tad against Ted's message - this might be the on= e place in the protocol where we have some backwards compatible constraints= . There is already trail blazing code running on UDP/443 but we also want t= o allow ietf-quic to run on UDP/443 simultaneously during development to ge= t experience with that So I'm not sure we really can change the locatio= n of the version field, at least not in a way that isn't cleverly compa= tible. It is essentially the magic number of the format.

Howev= er, I think we're in a good place here if we can agree that network byt= e order is the way to go. If we do that, Google can 'squat' on the = high byte (which would include what I understand are the 34 existing versio= ns if expressed as low endian) for now and the IETF space can have the low = three bytes without worry.. by the time it gets up to the 25th bit I would = hope old proto-quic implementations were no longer a going concern. A simil= arly high range could also be carved out for permissionless experimentation= s in the pre-rfc period - but we wouldn't have to settle on that right = away.

And this makes for a nice document - just say the first = draft is verison 1 and is in network byte order and that packets received w= ith a version >=3D 0x01000000 MUST NOT be replied to with ietf-quic.

-Patrick




<= div class=3D"m_-4233913786105247430m_-2163481478576219034HOEnZb">

On Mon, Nov 7, 2016 at 4:40 PM, Ted Hard= ie <ted.ietf@gmail.com> wrote:
On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson= <martin.thomson@gmail.com> wrote:
I'm getting a lot of questions from people= who are starting to
implement.=C2=A0 I'm guessing that I'm only seeing a small proporti= on of
the total volume.=C2=A0 That's great.

But it's going to be hard to deploy unless we have some ground rules about how to identify the protocol version.

Here's a strawman, loosely based on what I've learned from HTTP/2 a= nd TLS 1.3:

QUIC version numbers are 32-bits.

Th= is is, presumably, one of the things we can change.=C2=A0 More broadly, I t= hink we need to think about a more granular approach to this, so we can hav= e multiple folks experimenting without either needless conflict or over-muc= h coordination.=C2=A0

There are a lot of folks who have deeply held= opinions about extensions, negotiation, and version, and I don't want = to=C2=A0 tread over all that ground, but I think we should not assume that = we should start from where we are.


Just my personal o= pinion,

Ted

=C2=A0
=C2=A0 We reserve everything in th= e range
0xffff0000-0xffffffff for experimentation.=C2=A0 We designate 0xffff5100 and up as corresponding to versions of the draft.=C2=A0 That is, 0xffff5101=
would correspond to a potential -01 version of the core protocol
draft.=C2=A0 (Obviously, this would be post-WG-adoption, which I hope
happens soon.)

Similarly, we designate ALPN labels to match.=C2=A0 "quic-01" wou= ld
correspond to the same version of the HTTP mapping draft.=C2=A0 Hopefully the mapping draft would progress in lock-step, but if it doesn't, then<= br> the core protocol version that corresponds to the ALPN label would be
determined by what version of the core protocol is referenced by the
mapping document.

I think that we should agree to a scheme for protocol identifiers (it
doesn't have to be this) at the meeting next week.






--001a11c149a225495a0540d0df5b-- From nobody Tue Nov 8 13:37:54 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43DA91298A1 for ; Tue, 8 Nov 2016 13:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id heDLey8XCcTJ for ; Tue, 8 Nov 2016 13:37:50 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8624D129AB7 for ; Tue, 8 Nov 2016 13:37:50 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AEC4042373D; Tue, 8 Nov 2016 21:37:49 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 98656423701; Tue, 8 Nov 2016 21:37:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478641069; bh=27OND3ATzLB5jsZZ1a+HvqQ53QmHOIMBURougu4ITko=; l=534; h=From:To:CC:Date:References:In-Reply-To:From; b=EjTt+EHxbUf3LYfrkLk6RClAW3Z0FrSbzd+h+0w6gIWtNGYVit02CXsgg8Qb0SdQ3 /WExtrDJFfA3WI/re3mOMEbR5jpDAoNuOSsXdqZQUJN0b73YH1vLFKU4nPGEi4lusj L6cI//1ZFyOpa1Q+kC74KnHvN0F1lSAvvDkBj6zk= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 942561FC94; Tue, 8 Nov 2016 21:37:49 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 8 Nov 2016 13:37:49 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 8 Nov 2016 16:37:48 -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.1178.000; Tue, 8 Nov 2016 16:37:48 -0500 From: "Salz, Rich" To: Patrick McManus , Ian Swett Thread-Topic: [QUIC] Protocol identifiers for drafts Thread-Index: AQHSOToqEtniql95u0q0hX2M3gABdaDOYIwAgAAMv4CAADzSAIABLzQAgAAXJAD//61o8A== Date: Tue, 8 Nov 2016 21:37:48 +0000 Message-ID: <207ba12265b240deb9447c48f96a09ce@usma1ex-dag1mb1.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.33.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Jana Iyengar , Ted Hardie , "quic@ietf.org" , Martin Thomson Subject: Re: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 21:37:53 -0000 PiBEaXN0cmlidXRlZCBpcyBncmVhdCwgdW5jb29yZGluYXRlZCBzb3VuZHMgYSBiaXQgZGFuZ2Vy b3VzIHRvIG1lLsKgIEJlZm9yZSBhIGxhcmdlciBudW1iZXIgb2YgZXhwZXJpbWVudHMgd2l0aCBk aWZmZXJlbnQgdmVyc2lvbnMgc3RhcnQsIEknZCBzdWdnZXN0IHdlIGFsbG9jYXRlIGEgMjU2IG9y IHNvIHZlcnNpb25zIHRvIGVhY2ggb3JnYW5pemF0aW9uIHdoaWNoIGhhcyBhIG5lZWQgdG8gZXhw ZXJpbWVudCwgaW4gb3JkZXIgdG8gcHJldmVudCBjb25mbGljdHMuDQoNCkRvIHdlIG5lZWQgbGFy Z2VyIGFsbG9jYXRpb25zPyAgTWF5YmUgaWRlbnRpZnkgY2xhc3NlcywgQSBCIEMgRCBvciBzb21l dGhpbmc/DQoNCgkvciQsIHRob3NlIHdobyBmb3JnZXQgaGlzdG9yeSAuLi4NCg== From nobody Tue Nov 8 13:41:56 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AF2D129694 for ; Tue, 8 Nov 2016 13:41:55 -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 qaVkbEy0vysN for ; Tue, 8 Nov 2016 13:41:53 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CE0A129AB7 for ; Tue, 8 Nov 2016 13:41:53 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id l124so194064617ywb.3 for ; Tue, 08 Nov 2016 13:41:53 -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=9OEF+70vdmn1XuxRdChclqe6JCgYrFLotgy4czSDctE=; b=EhCyA0oNKSH6Lbj20SAfxwkR7SABbnBBYw/FnVZcb5Z1dmd4HZ7BBGwem54nQFg00C Pp6VqzmDJDx7IbcG/kI0Iaa9AaxUVL4t/TAtZkITMb/7CSFIa8bPRFyhCLMQt8IXtk9L qSnJ7QKKE82/Y0D3vgjHk+eO6MJqb4lGYv1doDyu6UiGKTL8A72TTLxTdy862/Z/FsG3 j5Pg0soaMSjyNQmvqWBlqorzCdRLP0UIdJXMQRrwsomxKyObTIRlHDJc3zqZb45fz8Dt VggWnC6xZkpBm1aPk9OXma847P1uezeTRKMcMnIcnKFRdCKhUwoXKOTVi/QfP3OYEfay cv9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9OEF+70vdmn1XuxRdChclqe6JCgYrFLotgy4czSDctE=; b=R3V5vV4f0XTMnqNkK58DFTub18oyeLkrIpDl3Po+bsMjxMvfWgbAVq/9scgtEWuZ9g qXoFIsa/Rx1tgS/Tb2jjyMirpwkUxufiAyc34ZiZ5kSyUmC3nG2x15ZDciTWkvLfsnLI lYK2I3NyJpQslRBVq1Fx2ggDUFkuCHj2c2ATDeU4EMrbZ7HtGKSeyy+8UB2kjCYmJygu XRitCylg9fjiuzI0UeIphXtjBURnjZOSVrsEXlrdRshETxtf5TS56eP873dTjtLX2erM i23f+qFZitn4M0cqhNCkBCaGOsMVWXmWPGUykeIBAGd42IA7rjp7QKXwr5wzaMKx6pjx x5sA== X-Gm-Message-State: ABUngvde0XmRA5pmlvy/PSo9nCaLkNQBL+WuDrkbNxuJkVxUHMwS6SNX0eph49nuDwQtsPxK215fynCyAXgRLQ== X-Received: by 10.129.121.1 with SMTP id u1mr13698726ywc.146.1478641312396; Tue, 08 Nov 2016 13:41:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Tue, 8 Nov 2016 13:41:11 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 8 Nov 2016 13:41:11 -0800 Message-ID: To: Patrick McManus Content-Type: multipart/alternative; boundary=94eb2c0a8f822d2cc10540d102de Archived-At: Cc: Jana Iyengar , Ian Swett , quic@ietf.org, Martin Thomson , Ted Hardie Subject: Re: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 21:41:55 -0000 --94eb2c0a8f822d2cc10540d102de Content-Type: text/plain; charset=UTF-8 On Tue, Nov 8, 2016 at 1:32 PM, Patrick McManus wrote: > maybe just a wiki page for self-registration during the pre-rfc period > would suffice? permissionless is good. > A wiki seems fine here. If people are going to be malicious, they're going to be malicious. -Ekr > > On Tue, Nov 8, 2016 at 3:09 PM, Ian Swett wrote: > >> On Mon, Nov 7, 2016 at 9:04 PM, Jana Iyengar wrote: >> >>> I agree that we should have a plan for iteration and diversity, and >>> should have versioning figured out early. FWIW, I don't think compatibility >>> is an issue (it would be convenient if the placement of the version field >>> were not changed,) since this version space is quite humongous. >>> >>> QUIC currently treats this as a 32-bit space, into which the QUIC >>> version made up of 4 ASCII characters is encoded. "Q034" is encoded on the >>> wire as 0x 51 30 33 36. There's no interesting structure here since these >>> aren't treated as numbers... so unfortunately Patrick, I don't think your >>> clever trick is going to do much. Google servers and Chrome use lists of >>> currently-supported versions on each side, and there's no expectation of >>> continuity in the 32-bit space, since the versions are simply arbitrary >>> points in this space. >>> >>> So, I'll take Martin's arrangement and change it slightly: >>> >>> The IETF reserves versions 0x00000001 to 0x0000ffff (16K versions) for >>> standards work (drafts and standards.) >>> - In this space, designate 0x00000001 - 0x0000fff (4096 versions) to >>> QUIC standards >>> - Designate the rest of the IETF-reserved space, 0x00001000 - 0x0000ffff >>> (~60K versions), for corresponding draft versions. That is, 0x00001001 >>> would correspond to a potential -01 version of the core protocol draft. >>> >>> This leaves the space from 0x00010000 upwards (~4 billion versions) for >>> uncoordinated and distributed experimentation. Since current QUIC sits at >>> 0x51303336, this shouldn't interfere with future draft versions. >>> >>> >> Distributed is great, uncoordinated sounds a bit dangerous to me. Before >> a larger number of experiments with different versions start, I'd suggest >> we allocate a 256 or so versions to each organization which has a need to >> experiment, in order to prevent conflicts. >> >> Until we have a process for that, ideally we can focus on the core drafts >> and any experimentation can mostly be done with feature negotiation, not >> full version negotiation? In a similar direction, possibly we want to >> allocate a QuicTag for each organization to use to negotiate features? >> >> >>> On Mon, Nov 7, 2016 at 2:26 PM, Patrick McManus >>> wrote: >>> >>>> I'm eager to get a plan on this as well - its essential for iteration >>>> and diversity. >>>> >>>> I would push back just a tad against Ted's message - this might be the >>>> one place in the protocol where we have some backwards compatible >>>> constraints. There is already trail blazing code running on UDP/443 but we >>>> also want to allow ietf-quic to run on UDP/443 simultaneously during >>>> development to get experience with that So I'm not sure we really can >>>> change the location of the version field, at least not in a way that isn't >>>> cleverly compatible. It is essentially the magic number of the format. >>>> >>>> However, I think we're in a good place here if we can agree that >>>> network byte order is the way to go. If we do that, Google can 'squat' on >>>> the high byte (which would include what I understand are the 34 existing >>>> versions if expressed as low endian) for now and the IETF space can have >>>> the low three bytes without worry.. by the time it gets up to the 25th bit >>>> I would hope old proto-quic implementations were no longer a going concern. >>>> A similarly high range could also be carved out for permissionless >>>> experimentations in the pre-rfc period - but we wouldn't have to settle on >>>> that right away. >>>> >>>> And this makes for a nice document - just say the first draft is >>>> verison 1 and is in network byte order and that packets received with a >>>> version >= 0x01000000 MUST NOT be replied to with ietf-quic. >>>> >>>> -Patrick >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Nov 7, 2016 at 4:40 PM, Ted Hardie wrote: >>>> >>>>> On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson < >>>>> martin.thomson@gmail.com> wrote: >>>>> >>>>>> I'm getting a lot of questions from people who are starting to >>>>>> implement. I'm guessing that I'm only seeing a small proportion of >>>>>> the total volume. That's great. >>>>>> >>>>>> But it's going to be hard to deploy unless we have some ground rules >>>>>> about how to identify the protocol version. >>>>>> >>>>>> Here's a strawman, loosely based on what I've learned from HTTP/2 and >>>>>> TLS 1.3: >>>>>> >>>>>> QUIC version numbers are 32-bits. >>>>> >>>>> >>>>> This is, presumably, one of the things we can change. More broadly, I >>>>> think we need to think about a more granular approach to this, so we can >>>>> have multiple folks experimenting without either needless conflict or >>>>> over-much coordination. >>>>> >>>>> There are a lot of folks who have deeply held opinions about >>>>> extensions, negotiation, and version, and I don't want to tread over all >>>>> that ground, but I think we should not assume that we should start from >>>>> where we are. >>>>> >>>>> >>>>> Just my personal opinion, >>>>> >>>>> Ted >>>>> >>>>> >>>>> >>>>>> We reserve everything in the range >>>>>> 0xffff0000-0xffffffff for experimentation. We designate 0xffff5100 >>>>>> and up as corresponding to versions of the draft. That is, 0xffff5101 >>>>>> would correspond to a potential -01 version of the core protocol >>>>>> draft. (Obviously, this would be post-WG-adoption, which I hope >>>>>> happens soon.) >>>>>> >>>>>> Similarly, we designate ALPN labels to match. "quic-01" would >>>>>> correspond to the same version of the HTTP mapping draft. Hopefully >>>>>> the mapping draft would progress in lock-step, but if it doesn't, then >>>>>> the core protocol version that corresponds to the ALPN label would be >>>>>> determined by what version of the core protocol is referenced by the >>>>>> mapping document. >>>>>> >>>>>> I think that we should agree to a scheme for protocol identifiers (it >>>>>> doesn't have to be this) at the meeting next week. >>>>>> >>>>>> >>>>> >>>> >>> >> > --94eb2c0a8f822d2cc10540d102de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 8, 2016 at 1:32 PM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
maybe= just a wiki page for self-registration during the pre-rfc period would suf= fice? permissionless is good.

A w= iki seems fine here. If people are going to be malicious, they're going= to be malicious.

-Ekr
=C2=A0

On = Tue, Nov 8, 2016 at 3:09 PM, Ian Swett <ianswett@google.com> wrote:
On Mon, Nov 7, 2016 at 9:04 P= M, Jana Iyengar <jri@google.com> wrote:
I agree that we should have a plan for iteratio= n and diversity, and should have versioning figured out early. FWIW, I don&= #39;t think compatibility is an issue (it would be convenient if the placem= ent of the version field were not changed,) since this version space is qui= te humongous.

QUIC currently treats this as a 32-bit spa= ce, into which the QUIC version made up of 4 ASCII characters is encoded. &= quot;Q034" is encoded on the wire as 0x 51 30 33 36. There's no in= teresting structure here since these aren't treated as numbers... so un= fortunately Patrick, I don't think your clever trick is going to do muc= h. Google servers and Chrome use lists of currently-supported versions on e= ach side, and there's no expectation of continuity in the 32-bit space,= since the versions are simply arbitrary points in this space.
So, I'll take Martin's arrangement and change it sligh= tly:

The IETF reserves versions 0x00000001 to 0x00= 00ffff (16K versions) for standards work (drafts and standards.)=C2=A0
- In this space, designate =C2=A00x00000001 - 0x0000fff (4096 version= s) to QUIC standards
- Designate the rest of the IETF-reserved sp= ace, 0x00001000 - 0x0000ffff (~60K versions), for corresponding draft versi= ons. That is, 0x00001001 would correspond to a potential -01 version of the= core protocol draft.

This leaves the space from 0= x00010000 upwards (~4 billion versions) for uncoordinated and distributed e= xperimentation. Since current QUIC sits at 0x51303336, this shouldn't i= nterfere with future draft versions.


Distributed is great, uncoordinated sounds a bi= t dangerous to me.=C2=A0 Before a larger number of experiments with differe= nt versions start, I'd suggest we allocate a 256 or so versions to each= organization which has a need to experiment, in order to prevent conflicts= .

Until we have a process for that, ideally we can= focus on the core drafts and any experimentation can mostly be done with f= eature negotiation, not full version negotiation?=C2=A0 In a similar direct= ion, possibly we want to allocate a QuicTag for each organization to use to= negotiate features?


On Mon, Nov 7, 2016 at 2:26 PM, Patric= k McManus <pmcmanus@mozilla.com> wrote:
I'm eager to get = a plan on this as well - its essential for iteration and diversity.

=
I would push back just a tad against Ted's message - this might b= e the one place in the protocol where we have some backwards compatible con= straints. There is already trail blazing code running on UDP/443 but we als= o want to allow ietf-quic to run on UDP/443 simultaneously during developme= nt to get experience with that So I'm not sure we really can change the= location of the version field, at least not in a way that isn't clever= ly compatible. It is essentially the magic number of the format.

However, I think we're in a good place here if we can agree that net= work byte order is the way to go. If we do that, Google can 'squat'= on the high byte (which would include what I understand are the 34 existin= g versions if expressed as low endian) for now and the IETF space can have = the low three bytes without worry.. by the time it gets up to the 25th bit = I would hope old proto-quic implementations were no longer a going concern.= A similarly high range could also be carved out for permissionless experim= entations in the pre-rfc period - but we wouldn't have to settle on tha= t right away.

And this makes for a nice document - just say th= e first draft is verison 1 and is in network byte order and that packets re= ceived with a version >=3D 0x01000000 MUST NOT be replied to with ietf-q= uic.

-Patrick



<= div class=3D"gmail_extra">
On Mon, Nov 7, 201= 6 at 4:40 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Mon, Nov 7, 2016 at 1= :01 PM, Martin Thomson <martin.thomson@gmail.com> wro= te:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">I'm getting a lot of q= uestions from people who are starting to
implement.=C2=A0 I'm guessing that I'm only seeing a small proporti= on of
the total volume.=C2=A0 That's great.

But it's going to be hard to deploy unless we have some ground rules about how to identify the protocol version.

Here's a strawman, loosely based on what I've learned from HTTP/2 a= nd TLS 1.3:

QUIC version numbers are 32-bits.

Th= is is, presumably, one of the things we can change.=C2=A0 More broadly, I t= hink we need to think about a more granular approach to this, so we can hav= e multiple folks experimenting without either needless conflict or over-muc= h coordination.=C2=A0

There are a lot of folks who have deeply held= opinions about extensions, negotiation, and version, and I don't want = to=C2=A0 tread over all that ground, but I think we should not assume that = we should start from where we are.


Just my personal o= pinion,

Ted

=C2=A0
=C2=A0 We reserve everything in th= e range
0xffff0000-0xffffffff for experimentation.=C2=A0 We designate 0xffff5100 and up as corresponding to versions of the draft.=C2=A0 That is, 0xffff5101=
would correspond to a potential -01 version of the core protocol
draft.=C2=A0 (Obviously, this would be post-WG-adoption, which I hope
happens soon.)

Similarly, we designate ALPN labels to match.=C2=A0 "quic-01" wou= ld
correspond to the same version of the HTTP mapping draft.=C2=A0 Hopefully the mapping draft would progress in lock-step, but if it doesn't, then<= br> the core protocol version that corresponds to the ALPN label would be
determined by what version of the core protocol is referenced by the
mapping document.

I think that we should agree to a scheme for protocol identifiers (it
doesn't have to be this) at the meeting next week.







--94eb2c0a8f822d2cc10540d102de-- From nobody Tue Nov 8 13:43:26 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC721294B6 for ; Tue, 8 Nov 2016 13:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pt79poPLNag1 for ; Tue, 8 Nov 2016 13:43:22 -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 6C835127ABE for ; Tue, 8 Nov 2016 13:43:22 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id i145so99760792ywg.2 for ; Tue, 08 Nov 2016 13:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+SED2UhlacmQkJPPbGg3Zu4YnT62wnp0mk9E1fFm0c4=; b=Zi94YQ+cIw9cjbCk4qbAuVXFHdhBD8wgLcv8rN8gF9atuBhhee1nYqRN6bSQbfJkLr vjyBCdn8WpG0c1LqMa9nt4WrLHRK9ahFv4pyQMUqpe05m4ePTAnjD+/cOGLBcnkKSrB3 wXDhlIqnl6U+GJ5dynGuQvjg3pppfhxqy1R3P7uNHEhCcETmdMhNqiLLKwdO2ZvHEyoB YBLVLAnqaCvdHjQ9BwWdNaR6YL9BkOkZkT14H6JWFN9J0HL9c+NwBazU4sjeOp9vSs2z zfuVAWQUXmIxxe3H/91YJZo6qccEpXvGPuXcC3wNUEI/rUSsIHjwYZ12DJSGb368ZrQI tV+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+SED2UhlacmQkJPPbGg3Zu4YnT62wnp0mk9E1fFm0c4=; b=gOzvIkDxKdRserreqqDw5GXLBl5M0+dhgmaZeJryfGtHVLQlilEuanF9JFvhuU37AR TDHKnaNLRVszgJb1vRa6G1jYrx3/Hwvw4I6hbU8cWNNnb/Ya2Kd84eTP11wpsUYG3mQZ P8qTRzF/R5cCk2ebIt4D+wHUvLSjhHlQo7aemVWUf5yTln5H8GA26G+2ccqU5SEIPn/h JjS79iek1sjJelkDjQpz7d1ct3MZaFZpHCp8rUAYmmZzdQOuddjhq7GyAqoDI/ZaIjC0 fGrCQ//7P0qmK+3TXa9vZAniW2CycZdnHjyQQ9ohaT3T6Np5fSHVQusE23/ak5zUB050 ytqg== X-Gm-Message-State: ABUngvenpTqxeVbMzffpaHVxcXngSVSYaszaJ0j3JsVlTGevefbuVWoODOofZX/WjX0Q5LHU+GYizpiZ0TcUshuA X-Received: by 10.129.117.215 with SMTP id q206mr15073842ywc.143.1478641401605; Tue, 08 Nov 2016 13:43:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.203.69 with HTTP; Tue, 8 Nov 2016 13:43:01 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 8 Nov 2016 16:43:01 -0500 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1147f9ce7e723f0540d1078a Archived-At: Cc: Jana Iyengar , Ted Hardie , quic@ietf.org, Martin Thomson , Patrick McManus Subject: Re: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 21:43:24 -0000 --001a1147f9ce7e723f0540d1078a Content-Type: text/plain; charset=UTF-8 A wiki sounds fine to me. On Tue, Nov 8, 2016 at 4:41 PM, Eric Rescorla wrote: > On Tue, Nov 8, 2016 at 1:32 PM, Patrick McManus > wrote: > >> maybe just a wiki page for self-registration during the pre-rfc period >> would suffice? permissionless is good. >> > > A wiki seems fine here. If people are going to be malicious, they're going > to be malicious. > > -Ekr > > >> >> On Tue, Nov 8, 2016 at 3:09 PM, Ian Swett wrote: >> >>> On Mon, Nov 7, 2016 at 9:04 PM, Jana Iyengar wrote: >>> >>>> I agree that we should have a plan for iteration and diversity, and >>>> should have versioning figured out early. FWIW, I don't think compatibility >>>> is an issue (it would be convenient if the placement of the version field >>>> were not changed,) since this version space is quite humongous. >>>> >>>> QUIC currently treats this as a 32-bit space, into which the QUIC >>>> version made up of 4 ASCII characters is encoded. "Q034" is encoded on the >>>> wire as 0x 51 30 33 36. There's no interesting structure here since these >>>> aren't treated as numbers... so unfortunately Patrick, I don't think your >>>> clever trick is going to do much. Google servers and Chrome use lists of >>>> currently-supported versions on each side, and there's no expectation of >>>> continuity in the 32-bit space, since the versions are simply arbitrary >>>> points in this space. >>>> >>>> So, I'll take Martin's arrangement and change it slightly: >>>> >>>> The IETF reserves versions 0x00000001 to 0x0000ffff (16K versions) for >>>> standards work (drafts and standards.) >>>> - In this space, designate 0x00000001 - 0x0000fff (4096 versions) to >>>> QUIC standards >>>> - Designate the rest of the IETF-reserved space, 0x00001000 - >>>> 0x0000ffff (~60K versions), for corresponding draft versions. That is, >>>> 0x00001001 would correspond to a potential -01 version of the core protocol >>>> draft. >>>> >>>> This leaves the space from 0x00010000 upwards (~4 billion versions) for >>>> uncoordinated and distributed experimentation. Since current QUIC sits at >>>> 0x51303336, this shouldn't interfere with future draft versions. >>>> >>>> >>> Distributed is great, uncoordinated sounds a bit dangerous to me. >>> Before a larger number of experiments with different versions start, I'd >>> suggest we allocate a 256 or so versions to each organization which has a >>> need to experiment, in order to prevent conflicts. >>> >>> Until we have a process for that, ideally we can focus on the core >>> drafts and any experimentation can mostly be done with feature negotiation, >>> not full version negotiation? In a similar direction, possibly we want to >>> allocate a QuicTag for each organization to use to negotiate features? >>> >>> >>>> On Mon, Nov 7, 2016 at 2:26 PM, Patrick McManus >>>> wrote: >>>> >>>>> I'm eager to get a plan on this as well - its essential for iteration >>>>> and diversity. >>>>> >>>>> I would push back just a tad against Ted's message - this might be the >>>>> one place in the protocol where we have some backwards compatible >>>>> constraints. There is already trail blazing code running on UDP/443 but we >>>>> also want to allow ietf-quic to run on UDP/443 simultaneously during >>>>> development to get experience with that So I'm not sure we really can >>>>> change the location of the version field, at least not in a way that isn't >>>>> cleverly compatible. It is essentially the magic number of the format. >>>>> >>>>> However, I think we're in a good place here if we can agree that >>>>> network byte order is the way to go. If we do that, Google can 'squat' on >>>>> the high byte (which would include what I understand are the 34 existing >>>>> versions if expressed as low endian) for now and the IETF space can have >>>>> the low three bytes without worry.. by the time it gets up to the 25th bit >>>>> I would hope old proto-quic implementations were no longer a going concern. >>>>> A similarly high range could also be carved out for permissionless >>>>> experimentations in the pre-rfc period - but we wouldn't have to settle on >>>>> that right away. >>>>> >>>>> And this makes for a nice document - just say the first draft is >>>>> verison 1 and is in network byte order and that packets received with a >>>>> version >= 0x01000000 MUST NOT be replied to with ietf-quic. >>>>> >>>>> -Patrick >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Nov 7, 2016 at 4:40 PM, Ted Hardie wrote: >>>>> >>>>>> On Mon, Nov 7, 2016 at 1:01 PM, Martin Thomson < >>>>>> martin.thomson@gmail.com> wrote: >>>>>> >>>>>>> I'm getting a lot of questions from people who are starting to >>>>>>> implement. I'm guessing that I'm only seeing a small proportion of >>>>>>> the total volume. That's great. >>>>>>> >>>>>>> But it's going to be hard to deploy unless we have some ground rules >>>>>>> about how to identify the protocol version. >>>>>>> >>>>>>> Here's a strawman, loosely based on what I've learned from HTTP/2 >>>>>>> and TLS 1.3: >>>>>>> >>>>>>> QUIC version numbers are 32-bits. >>>>>> >>>>>> >>>>>> This is, presumably, one of the things we can change. More broadly, >>>>>> I think we need to think about a more granular approach to this, so we can >>>>>> have multiple folks experimenting without either needless conflict or >>>>>> over-much coordination. >>>>>> >>>>>> There are a lot of folks who have deeply held opinions about >>>>>> extensions, negotiation, and version, and I don't want to tread over all >>>>>> that ground, but I think we should not assume that we should start from >>>>>> where we are. >>>>>> >>>>>> >>>>>> Just my personal opinion, >>>>>> >>>>>> Ted >>>>>> >>>>>> >>>>>> >>>>>>> We reserve everything in the range >>>>>>> 0xffff0000-0xffffffff for experimentation. We designate 0xffff5100 >>>>>>> and up as corresponding to versions of the draft. That is, >>>>>>> 0xffff5101 >>>>>>> would correspond to a potential -01 version of the core protocol >>>>>>> draft. (Obviously, this would be post-WG-adoption, which I hope >>>>>>> happens soon.) >>>>>>> >>>>>>> Similarly, we designate ALPN labels to match. "quic-01" would >>>>>>> correspond to the same version of the HTTP mapping draft. Hopefully >>>>>>> the mapping draft would progress in lock-step, but if it doesn't, >>>>>>> then >>>>>>> the core protocol version that corresponds to the ALPN label would be >>>>>>> determined by what version of the core protocol is referenced by the >>>>>>> mapping document. >>>>>>> >>>>>>> I think that we should agree to a scheme for protocol identifiers (it >>>>>>> doesn't have to be this) at the meeting next week. >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --001a1147f9ce7e723f0540d1078a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A wiki sounds fine to me.
=
On Tue, Nov 8, 2016 at 4:41 PM, Eric Rescorl= a <e= kr@rtfm.com> wrote:
On Tue, Nov 8, 2016 at 1:32 PM, Patrick McManus <= ;pmcmanus@mozilla= .com> wrote:
maybe just a wiki page for self-registration during the pre-rfc period w= ould suffice? permissionless is good.

=
A wiki seems fine here. If people are going to be malicious, th= ey're going to be malicious.

-Ekr
=C2=A0

On Tue, Nov 8, 2016 at 3:09 PM, Ian Swett <ianswett@google.com&g= t; wrote:
On Mon, Nov 7, 2016 at= 9:04 PM, Jana Iyengar <jri@google.com> wrote:
I agree that we should have a plan for i= teration and diversity, and should have versioning figured out early. FWIW,= I don't think compatibility is an issue (it would be convenient if the= placement of the version field were not changed,) since this version space= is quite humongous.

QUIC currently treats this as a 32-= bit space, into which the QUIC version made up of 4 ASCII characters is enc= oded. "Q034" is encoded on the wire as 0x 51 30 33 36. There'= s no interesting structure here since these aren't treated as numbers..= . so unfortunately Patrick, I don't think your clever trick is going to= do much. Google servers and Chrome use lists of currently-supported versio= ns on each side, and there's no expectation of continuity in the 32-bit= space, since the versions are simply arbitrary points in this space.
=

So, I'll take Martin's arrangement and change i= t slightly:

The IETF reserves versions 0x00000001 = to 0x0000ffff (16K versions) for standards work (drafts and standards.)=C2= =A0
- In this space, designate =C2=A00x00000001 - 0x0000fff (4096= versions) to QUIC standards
- Designate the rest of the IETF-res= erved space, 0x00001000 - 0x0000ffff (~60K versions), for corresponding dra= ft versions. That is, 0x00001001 would correspond to a potential -01 versio= n of the core protocol draft.

This leaves the spac= e from 0x00010000 upwards (~4 billion versions) for uncoordinated and distr= ibuted experimentation. Since current QUIC sits at 0x51303336, this shouldn= 't interfere with future draft versions.


Distributed is great, uncoordinated sou= nds a bit dangerous to me.=C2=A0 Before a larger number of experiments with= different versions start, I'd suggest we allocate a 256 or so versions= to each organization which has a need to experiment, in order to prevent c= onflicts.

Until we have a process for that, ideall= y we can focus on the core drafts and any experimentation can mostly be don= e with feature negotiation, not full version negotiation?=C2=A0 In a simila= r direction, possibly we want to allocate a QuicTag for each organization t= o use to negotiate features?


On Mon, Nov 7, 2016 at 2:26 PM, Patrick Mc= Manus <pmcmanus@mozilla.com> wrote:
I'm eager to get a p= lan on this as well - its essential for iteration and diversity.

I would push back just a tad against Ted's message - this might be t= he one place in the protocol where we have some backwards compatible constr= aints. There is already trail blazing code running on UDP/443 but we also w= ant to allow ietf-quic to run on UDP/443 simultaneously during development = to get experience with that So I'm not sure we really can change the lo= cation of the version field, at least not in a way that isn't cleverly = compatible. It is essentially the magic number of the format.

= However, I think we're in a good place here if we can agree that networ= k byte order is the way to go. If we do that, Google can 'squat' on= the high byte (which would include what I understand are the 34 existing v= ersions if expressed as low endian) for now and the IETF space can have the= low three bytes without worry.. by the time it gets up to the 25th bit I w= ould hope old proto-quic implementations were no longer a going concern. A = similarly high range could also be carved out for permissionless experiment= ations in the pre-rfc period - but we wouldn't have to settle on that r= ight away.

And this makes for a nice document - just say the f= irst draft is verison 1 and is in network byte order and that packets recei= ved with a version >=3D 0x01000000 MUST NOT be replied to with ietf-quic= .

=
-Pa= trick





On Mon, Nov 7,= 2016 at 4:40 PM, Ted Hardie <ted.ietf@gmail.com> wrote:
On Mon, Nov 7, 2016 = at 1:01 PM, Martin Thomson <martin.thomson@gmail.com>= wrote:
I'm getting a lot = of questions from people who are starting to
implement.=C2=A0 I'm guessing that I'm only seeing a small proporti= on of
the total volume.=C2=A0 That's great.

But it's going to be hard to deploy unless we have some ground rules about how to identify the protocol version.

Here's a strawman, loosely based on what I've learned from HTTP/2 a= nd TLS 1.3:

QUIC version numbers are 32-bits.

Th= is is, presumably, one of the things we can change.=C2=A0 More broadly, I t= hink we need to think about a more granular approach to this, so we can hav= e multiple folks experimenting without either needless conflict or over-muc= h coordination.=C2=A0

There are a lot of folks who have deeply held= opinions about extensions, negotiation, and version, and I don't want = to=C2=A0 tread over all that ground, but I think we should not assume that = we should start from where we are.


Just my personal o= pinion,

Ted

=C2=A0
=C2=A0 We reserve everything in th= e range
0xffff0000-0xffffffff for experimentation.=C2=A0 We designate 0xffff5100 and up as corresponding to versions of the draft.=C2=A0 That is, 0xffff5101=
would correspond to a potential -01 version of the core protocol
draft.=C2=A0 (Obviously, this would be post-WG-adoption, which I hope
happens soon.)

Similarly, we designate ALPN labels to match.=C2=A0 "quic-01" wou= ld
correspond to the same version of the HTTP mapping draft.=C2=A0 Hopefully the mapping draft would progress in lock-step, but if it doesn't, then<= br> the core protocol version that corresponds to the ALPN label would be
determined by what version of the core protocol is referenced by the
mapping document.

I think that we should agree to a scheme for protocol identifiers (it
doesn't have to be this) at the meeting next week.








--001a1147f9ce7e723f0540d1078a-- From nobody Tue Nov 8 13:52:49 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11C0129AB7 for ; Tue, 8 Nov 2016 13: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 uQJxUuFL6ksT for ; Tue, 8 Nov 2016 13:52: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 9D549129543 for ; Tue, 8 Nov 2016 13:52:47 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id i145so100058829ywg.2 for ; Tue, 08 Nov 2016 13:52:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dwrdh//j7QJ6oXDaPD+a0h5EXSYzQNGU4ofuK9cFKNI=; b=FZItyRUIGD+XA667CTyIPh0N2QR/tReNfsaeZypOZEiqwRgQYUdFlkoLSXH6lpximL ji7CtRgz7SrUHHsWa/J4Jzal85wW2EOinMd378q7OyaMGLdi2R9n8Ds8a3KrCauS8fmR Qo54yp0Q6DIwR9NKuF9CZqT/aFLFUxao88XKRUFQVd6BLyBmd3i0fUsK44rVLjSs2ife TRDbIh45xpvsJp9TghYcjRkXy+ua+8j7dlF3rKpI/CNCSxHK4OCa1eRiObppeSfnqSl8 XiKeTTAalYjnKPOkcFecV65pN8RkNwB1PKwT4N6bNRHK8owr7dh+LIoR72IN1K+T23zz WJAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dwrdh//j7QJ6oXDaPD+a0h5EXSYzQNGU4ofuK9cFKNI=; b=G4MGzMd0JWcYqy8l5msWIn8Yo7rpJoAJ6XQyEvn9puJdena1UJ+kW7dwaLmsl1UzoY xTigIZFutOzsdTJdYSQx0lBFp3fTvnjKSjKzI3dh/LDc+w6EuVuJ52rIcoJyRERsM3kN 2fCX70SJPNO0sT072IXwdaKSi8RgivXbIvJpj7XRn15YAYpRhUM55Yt/0kUb6PFAmW4L D0BCCLDHYWSRsceEH1SO1q+p84f8AAlBo64nGFjoUZ/bTL66PMpxmocCxeUXjVrwks1Q c/vgPZ/qe43SwVt1EwjI4PIbXK+94ci15oqnCc0Mu+kJ1nSd6wPSApddQDPEyj2O5/1D DziQ== X-Gm-Message-State: ABUngveMKvejOy4PV3eV7+W1Ns+YX80DuzLJi8LHiuqMT1BqbVw6DSlRCuGnnJnQhI9fQzNop1IgkBaxHqocKg== X-Received: by 10.129.40.149 with SMTP id o143mr13431349ywo.106.1478641966795; Tue, 08 Nov 2016 13:52:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.52.15 with HTTP; Tue, 8 Nov 2016 13:52:46 -0800 (PST) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Tue, 8 Nov 2016 15:52:46 -0600 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140865a2eba8e0540d12949 Archived-At: Cc: Ted Hardie , Ian Swett , Patrick McManus , Jana Iyengar , quic@ietf.org, Martin Thomson Subject: Re: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 21:52:49 -0000 --001a1140865a2eba8e0540d12949 Content-Type: text/plain; charset=UTF-8 For what it's worth ... On Tue, Nov 8, 2016 at 3:41 PM, Eric Rescorla wrote: > On Tue, Nov 8, 2016 at 1:32 PM, Patrick McManus > wrote: > >> maybe just a wiki page for self-registration during the pre-rfc period >> would suffice? permissionless is good. >> > > A wiki seems fine here. If people are going to be malicious, they're going > to be malicious. > > -Ekr > I'm OK with the wiki page for self-registration happening, but I'm hoping that experimental versions aren't widely deployed for long periods of time, which is what would justify more elaborate version number allocation schemes. I'm happy to listen to people explain to me that I have nothing to worry about, of course. Spencer, as AD --001a1140865a2eba8e0540d12949 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

--001a114dd36eda7641054248f398-- From nobody Sun Nov 27 07:19:49 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BE412957E for ; Sun, 27 Nov 2016 07:19:48 -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 (1024-bit key) header.d=krose.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 wzZP7rMGnVRZ for ; Sun, 27 Nov 2016 07:19:45 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADFAD1294FA for ; Sun, 27 Nov 2016 07:19:45 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id n21so117880389qka.3 for ; Sun, 27 Nov 2016 07:19:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s9kcSZxM7xPGltDZfZX+GtiRO1PJzZT9aV3vHH4zu/k=; b=WX5nv8yt+H39qB2EQOhCxT3BIitu7Ms9fLqpZsIfryFsctinQMGmxpHEtO0KdwTEvb NX/gZnVBadlHpTnSNU8CP29mJpakj8R+3Hax7JsYoBRwpDpgevufBlhKCzyWZcSz0REv vnpnji+jY9Qpps7WWGuE4WYdsb4GqlYHpDWWg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s9kcSZxM7xPGltDZfZX+GtiRO1PJzZT9aV3vHH4zu/k=; b=kbp0QKkt5OWkMscmYaGmYgFXdci+qOGZhhETPMTlcQkoGZ/NP1Sb/67c3YgvwQZcgT MEJ/xSX3K5RCzfpYRWCVhd6dsXNbOJrwyt2a88myP3Au5O+2OdfczWde4FbJJDbkepio Oxk2OPHiHle8jG4i0pduEVt8WykCLvL/GApvSzHK6zP5p4D9A8d/QbYeKWmkSQksQiVM ctTNJs89Sz3qaZ1HuJgFAYmzMy/XzZbA17tRvIa2nHT2ypIIih63XtGXgbdJinWl5o3y XvAeKlqqMz3xVLQWfvIBj+fWATJ3lYhzR2khWzY94zMcojwR6idaocH++X513fRnS5Q7 vpMA== X-Gm-Message-State: AKaTC03oKlD+0lQtO3CWLWC8TVWBCXKXw62bBKY2OsopaqtbzfuAtBcm9TWjnTqqU0/bBGG3iKiTqJS1fkU0yw== X-Received: by 10.55.157.195 with SMTP id g186mr14581626qke.13.1480259984874; Sun, 27 Nov 2016 07:19:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.180.2 with HTTP; Sun, 27 Nov 2016 07:19:44 -0800 (PST) X-Originating-IP: [2001:470:1f07:121:69b7:774f:5af8:ee2d] In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Kyle Rose Date: Sun, 27 Nov 2016 10:19:44 -0500 Message-ID: Subject: Re: Public reset PR To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114d8ad0930543054249e2ab Archived-At: Cc: Jim Roskind , IETF QUIC WG , Christian Huitema , Brian Trammell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 15:19:48 -0000 --001a114d8ad0930543054249e2ab Content-Type: text/plain; charset=UTF-8 On Sat, Nov 26, 2016 at 9:23 PM, Eric Rescorla wrote: > Well, there are actually two designs: > > 1. The middlebox can see the public reset but not verify it > 2. The middlebox cannot distinguish the public reset from other packets. > > I am concerned about #1 for the reasons indicated previously and I > originally did not see how to do #2 > without fairly significant client-side complexity. Now that I do, it does > seem like it's probably the leading > option absent some convincing policy argument that middleboxes should be > able to see these packets. > The problem with #2 (and related proposals to hide all connection state from path elements) is that it will encourage middleboxes to continue dropping all UDP state with a short timeout, requiring frequent keepalives that (e.g.) consume battery in mobile devices. Can not the TTL games Christian suggested for spoofed public resets be avoided by a middlebox detecting smaller TTLs than previously seen for a flow? If only packets likely to reach the destination were able to trigger short state timeouts on middleboxes, then keepalive responses from the destination seem like they would be sufficient to cover both off-path cases and the man-on-the-side. Kyle --001a114d8ad0930543054249e2ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Nov 26, 2016 at 9:23 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
Well= , there are actually two designs:

1. The middlebox= can see the public reset but not verify it
2. The middlebox cann= ot distinguish the public reset from other packets.

I am concerned about #1 for the reasons indicated previously and I origin= ally did not see how to do #2
without fairly significant client-s= ide complexity. Now that I do, it does seem like it's probably the lead= ing
option absent some convincing policy argument that middleboxe= s should be able to see these packets.

The problem with #2 (and related proposals to hide all connection state f= rom path elements) is that it will encourage middleboxes to continue droppi= ng all UDP state with a short timeout, requiring frequent keepalives that (= e.g.) consume battery in mobile devices.

Can not the TTL = games Christian suggested for spoofed public resets be avoided by a middleb= ox detecting smaller TTLs than previously seen for a flow? If only packets = likely to reach the destination were able to trigger short state timeouts o= n middleboxes, then keepalive responses from the destination seem like they= would be sufficient to cover both off-path cases and the man-on-the-side.<= br>

Kyle
--001a114d8ad0930543054249e2ab-- From nobody Sun Nov 27 07:48:19 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8902312951E for ; Sun, 27 Nov 2016 07:48:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEVO4QKKiyAk for ; Sun, 27 Nov 2016 07:48:17 -0800 (PST) Received: from mail-wj0-x232.google.com (mail-wj0-x232.google.com [IPv6:2a00:1450:400c: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 182C3129426 for ; Sun, 27 Nov 2016 07:48:17 -0800 (PST) Received: by mail-wj0-x232.google.com with SMTP id mp19so96037963wjc.1 for ; Sun, 27 Nov 2016 07:48:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bizD6n7VYpSfim8jOfbGgRTN0/O4OKWZcnlpqT1TQFs=; b=TW8jies322FTRRTHwH1RAeIxLgUpZBXzZfhTHP2FGa2HTmZvqSoJOuM2cvAMNXuhts ZLMNlV6F0L5BfReJ4exC/9VMmaTWi4zbQO1NF3P3G9tIu1NZrTur0hbJtCV/Nme9yKqe 7h9pPyGokGVl00/K272zc/2CXS3CBSoQxr/c+6xW6Os5oQl/Zri+x4+/efixqAzQtXJY Llj729Mi6E8YW6hFeI86MjcVU1nKe1R/xQ37Tn3OpI4SdgOByye0g0N3KQFKeZ8LuiEj UFo3UvrZAYRdtk8uM+EJJPuf+CxWunjwvi729hnicx/g5EwK3A2EFwp4+HuFeMi+CW/C uUxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bizD6n7VYpSfim8jOfbGgRTN0/O4OKWZcnlpqT1TQFs=; b=X8gJbmEEVXjc0SfyKTElpFJFKj/xqkEvR4uEfSs3yUJUjIr9yMTgGF2/nPYmiKh726 6VmSXsM8If3M9cKmFccMZLNgA9pCZIl76W7S00QV7Pj5QGWyguffZL2NVHGNKtEvQqNu y3A5mkkll2jxB7RSHAcCFyrZ/WW/M6/KD7px3F0QrPaBATICbaY41SwrgXnLSsMS8Twc MYecd/KSzskoAgGK3jpFbyfUGkr/TymgHcGgi5xn71OurBanAePEGWrDW6DFCEi6IGOj zX0sSuCUPGAL5N8jP6OJhjxVIwkegpu6Iy5mvveoFj/H4tJ7k7lXNQtoPanJiqjbS5x/ YHog== X-Gm-Message-State: AKaTC03pA3RK9TOSBTBt90jP3Q/pB8wh5vs0QRMSq6a/0j3VaayruQM/oHyCnwcCBBGhR6q20WlkVDP9qDO/44yL X-Received: by 10.194.59.71 with SMTP id x7mr18112587wjq.74.1480261695396; Sun, 27 Nov 2016 07:48:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.22 with HTTP; Sun, 27 Nov 2016 07:48:14 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Sun, 27 Nov 2016 07:48:14 -0800 Message-ID: Subject: Re: [quic-protocol] "outstanding data" retransmission To: Martin Thomson Content-Type: multipart/alternative; boundary=047d7ba9790687d83d05424a48ce Archived-At: Cc: IETF QUIC WG , Tatsuhiro Tsujikawa X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 15:48:18 -0000 --047d7ba9790687d83d05424a48ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 24, 2016 at 4:25 PM, Martin Thomson wrote: > On 25 November 2016 at 02:56, Ryan Hamilton wrote: > > Indeed, when a RST_STREAM NO_ERROR is sent the endpoint should continue > > retransmitting outstanding data. > > That's a fairly ugly exception to an otherwise clean function (kill > this stream). Now you have a code that is (half-kill this stream). > > The reason that this works in HTTP/2 is that we don't really have any > option to give up on retransmission. > > I would prefer to find a cleaner solution for this. If that's an > error code, then we should make an explicit half-reset code. > =E2=80=8BA different error code is fine with me. Being consistent by using = the same code as HTTP/2 seemed nice =E2=80=8Bbut if folks find that more confusing I= 'm fine with that. --047d7ba9790687d83d05424a48ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 2= 4, 2016 at 4:25 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
=
= On 25 November 2016 at 02:56, Ryan Hamilton <rch@google.com> wrote:
> Indeed, when a RST_STREAM NO_ERROR is sent the endpoint should continu= e
> retransmitting outstanding data.

That's a fairly ugly exception to an otherwise clean function (k= ill
this stream).=C2=A0 Now you have a code that is (half-kill this stream).
The reason that this works in HTTP/2 is that we don't really have any option to give up on retransmission.

I would prefer to find a cleaner solution for this.=C2=A0 If that's an<= br> error code, then we should make an explicit half-reset code.

=E2=80=8BA different error= code is fine with me. Being consistent by using the same code as HTTP/2 se= emed nice =E2=80=8Bbut if folks find that more confusing I'm fine with = that.=C2=A0

--047d7ba9790687d83d05424a48ce-- From nobody Sun Nov 27 13:36:36 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65FC91294DF for ; Sun, 27 Nov 2016 13:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fp10qFuEKpyA for ; Sun, 27 Nov 2016 13:36: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 8E49D124281 for ; Sun, 27 Nov 2016 13:36:33 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cB77e-0004VL-Ka for quic@ietf.org; Sun, 27 Nov 2016 22:36:31 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cB77b-0001dg-S8 for quic@ietf.org; Sun, 27 Nov 2016 16:36:28 -0500 Received: (qmail 23417 invoked from network); 27 Nov 2016 21:36:27 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Nov 2016 21:36:26 -0000 From: "Christian Huitema" To: "'Kyle Rose'" , "'Eric Rescorla'" References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> In-Reply-To: Date: Sun, 27 Nov 2016 11:36:22 -1000 Message-ID: <10b901d248f6$4df37040$e9da50c0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJonVXnL4d4ZG4Opi5oOnyTDTVr/wFxK6dxAjaMj8gCk11JPgK0p11kAM33deQCcSx/dgH5uKaZn09M81A= Content-Language: en-us Subject: RE: Public reset PR X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMDyW6 MnMdmSb2xIP3IUVS8otFXXWdmkSMcmppy329HLuldcmtTcWSOKD5RASVzg27iipWm9T+NduR4dWL Z2bCpe95kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRr9EcJ34BT4NI2tYPYpe0B0MQOp+UtDOd2Xrp4Ao XsNbYI86krgx3/MiyhynFjvn4vwETjrysRdTQFgEXAljBCLeNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxNnmFCUctm6OHeH6tWPSXJE7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRYE83tH9htpyVATiooT/rJiGHIfgXXvuhI9vwJN89WVO9R0tarUwIt7i7NiVJNL9jNC r2VPLfZa8ts/I6OTYjIAMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.05) X-Classification: not-spam/combined X-Recommended-Action: accept Archived-At: Cc: 'Jim Roskind' , 'IETF QUIC WG' , 'Brian Trammell' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 21:36:35 -0000 On Sunday, November 27, 2016 5:20 AM, Kyle Rose wrote: > On Sat, Nov 26, 2016 at 9:23 PM, Eric Rescorla = wrote: >> Well, there are actually two designs: >> >> 1. The middlebox can see the public reset but not verify it >> 2. The middlebox cannot distinguish the public reset from other = packets. >> >> I am concerned about #1 for the reasons indicated previously and I = originally did not see how to do #2 >> without fairly significant client-side complexity. Now that I do, it = does seem like it's probably the leading >> option absent some convincing policy argument that middleboxes should = be able to see these packets. Responding to Eric: I am not sure that I understand how the second = option works for the "rebooted server" scenario. Sure, the rebooted = server can use a persistent secret to compose the magic prefix of the = encrypted payload. But what about the sequence number? If it is not = within the range that the client expect, the packet will be dropped = before processing the encrypted payload. > The problem with #2 (and related proposals to hide all connection = state from path=20 > elements) is that it will encourage middleboxes to continue dropping = all UDP state=20 > with a short timeout, requiring frequent keepalives that (e.g.) = consume battery in=20 > mobile devices. This is the SPUD/PLUS argument. But then, there is a long history of = protocols designed with high hopes of cooperation with middle boxes, = without an actual result. So at a minimum we have to ensure that = whatever solution is proposed does not introduce new attacks, or undue = complexity. > Can not the TTL games Christian suggested for spoofed public resets be = avoided by=20 > a middlebox detecting smaller TTLs than previously seen for a flow? If = only packets=20 > likely to reach the destination were able to trigger short state = timeouts on=20 > middleboxes, then keepalive responses from the destination seem like = they would be > sufficient to cover both off-path cases and the man-on-the-side. I would rather not rely on middleboxes playing whack-a-mole with = attackers. If we do anything at all, we should have some prescriptive = behavior based for example on "shorter timer after reset". -- Christian Huitema From nobody Sun Nov 27 13:38:05 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E01D1294DF for ; Sun, 27 Nov 2016 13:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEfBKp-aFNou for ; Sun, 27 Nov 2016 13:38:02 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0099.outbound.protection.outlook.com [104.47.41.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE28124281 for ; Sun, 27 Nov 2016 13:38: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=90faqbLNHH/ud9Ge3JC0h2N4dUxpsfjh6fEu1hCPcbg=; b=XmTkYOoeEjoSx/mj49KRDAZEhlave5tOh/GA9Bn7T/37qZ9zanZaOdioYoI6S4La37aH0yNTMBThXNSlVWanrjLr7nS243tbY9rdfUtdSKfNW0q+uphGU0jXPlzMUP1E8P2F2MUpDpazjs/yz2uQUuUbpy8yVsKTGz+H5j8T0mM= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Sun, 27 Nov 2016 21:37:59 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.015; Sun, 27 Nov 2016 21:37:59 +0000 From: Mike Bishop To: Martin Thomson , Ryan Hamilton Subject: RE: [quic-protocol] "outstanding data" retransmission Thread-Topic: [quic-protocol] "outstanding data" retransmission Thread-Index: AQHSRmn1uc4P9Fhu2k6l4wpBOTzE/aDoSfKAgACOLwCABIet4A== Date: Sun, 27 Nov 2016 21:37: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=Michael.Bishop@microsoft.com; x-originating-ip: [2601:600:8300:3b9a:c78:f6bc:b95e:6cb3] x-ms-office365-filtering-correlation-id: 7d028e0b-00f3-4d82-f18a-08d4170da8a1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:SRfADgRO1Zs0ktenAwCZ/EK0KonbqpvcRE6SuOou9i/geLXh6HGzp718p4MfNNnD0EZcEsHYv1g1V4dZoIihrD5tXSc5WIsUJoxlAq1X554RUxeLQ582+aW+7awUuXhlpZ1nco52oayi4SB5ypNPd8m7a5J+TqYJnLaAGmInlWMEuyL5hcRQX4A5l49Y66RUOaz3Nh6oBVnVXnDtUyL/mSgxzd+JZvh2m3cDXZUL2MuLO99oF2AFuFPrfeJkvAio8p0SAqXMrI/fKaqvrg9bcr248/KKNO254CKRIDzEV4PfsEoe01GzRmC4+els/oplq6iiZ00o32bGpdOlS/5J7N7lebtVFbBu2I+h9SNO+7Mx5XqMcY4L7LNZeitPESonZbdwL22g8FEy5bl4CyxHvoPistvRk5w4VbOJ2h7X7ClLCT7Eo6nSVeg5BNI0fyvYcqXpDDqU1zrUaYp9/Mckzb/BlJ1ls0DFBGmZS9wChhU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6040361)(6045199)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6061324)(6041248)(6046074)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(20161123558021)(6072148)(6047074)(6042181); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0139052FDB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(377454003)(24454002)(13464003)(76576001)(4326007)(9686002)(33656002)(105586002)(5660300001)(8936002)(8676002)(81156014)(106356001)(97736004)(7696004)(92566002)(68736007)(50986999)(81166006)(76176999)(54356999)(189998001)(99286002)(101416001)(2906002)(2950100002)(5001770100001)(5005710100001)(10090500001)(10290500002)(86612001)(8990500004)(122556002)(86362001)(6506003)(2900100001)(229853002)(7736002)(74316002)(3280700002)(39060400001)(38730400001)(305945005)(6116002)(106116001)(102836003)(77096006)(3660700001)(7846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.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) 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-originalarrivaltime: 27 Nov 2016 21:37:59.4999 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: IETF QUIC WG , Tatsuhiro Tsujikawa X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 21:38:04 -0000 V2VsbCwgcmVtZW1iZXIgdGhhdCB0aGUgSFRUUC8yIHNlbWFudGljIGlzICJJIG5vIGxvbmdlciBj YXJlIGFib3V0IHdoYXQgeW91J3JlIHNlbmRpbmcuIiAgTWF5YmUgd2UgbWVldCBpbiB0aGUgbWlk ZGxlIGFuZCBzYXkgdGhhdCB5b3Ugc2hvdWxkbid0IGNvbnRpbnVlIHNlbmRpbmcgb25seSBhZnRl ciByZWNlaXB0PyAgQWZ0ZXIgc2VuZGluZywgeW91IGRvbid0IGhhdmUgYW55IGFja25vd2xlZGdl bWVudCBmcm9tIHRoZSByZW1vdGUgc2lkZSB0aGF0IHRoZXkgZG9uJ3QgY2FyZSBhYm91dCB3aGF0 IHlvdSdyZSBzZW5kaW5nLiAgSWYgdGhleSBhY3R1YWxseSBkb24ndCBjYXJlLCB0aGV5IGNhbiBS U1RfU1RSRUFNIGluIHR1cm4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBR VUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFydGluIFRo b21zb24NClNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAyNCwgMjAxNiA0OjI2IFBNDQpUbzogUnlh biBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb20+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYu b3JnPjsgVGF0c3VoaXJvIFRzdWppa2F3YSA8dGF0c3VoaXJvLnRAZ21haWwuY29tPg0KU3ViamVj dDogUmU6IFtxdWljLXByb3RvY29sXSAib3V0c3RhbmRpbmcgZGF0YSIgcmV0cmFuc21pc3Npb24N Cg0KT24gMjUgTm92ZW1iZXIgMjAxNiBhdCAwMjo1NiwgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2ds ZS5jb20+IHdyb3RlOg0KPiBJbmRlZWQsIHdoZW4gYSBSU1RfU1RSRUFNIE5PX0VSUk9SIGlzIHNl bnQgdGhlIGVuZHBvaW50IHNob3VsZCANCj4gY29udGludWUgcmV0cmFuc21pdHRpbmcgb3V0c3Rh bmRpbmcgZGF0YS4NCg0KVGhhdCdzIGEgZmFpcmx5IHVnbHkgZXhjZXB0aW9uIHRvIGFuIG90aGVy d2lzZSBjbGVhbiBmdW5jdGlvbiAoa2lsbCB0aGlzIHN0cmVhbSkuICBOb3cgeW91IGhhdmUgYSBj b2RlIHRoYXQgaXMgKGhhbGYta2lsbCB0aGlzIHN0cmVhbSkuDQoNClRoZSByZWFzb24gdGhhdCB0 aGlzIHdvcmtzIGluIEhUVFAvMiBpcyB0aGF0IHdlIGRvbid0IHJlYWxseSBoYXZlIGFueSBvcHRp b24gdG8gZ2l2ZSB1cCBvbiByZXRyYW5zbWlzc2lvbi4NCg0KSSB3b3VsZCBwcmVmZXIgdG8gZmlu ZCBhIGNsZWFuZXIgc29sdXRpb24gZm9yIHRoaXMuICBJZiB0aGF0J3MgYW4gZXJyb3IgY29kZSwg dGhlbiB3ZSBzaG91bGQgbWFrZSBhbiBleHBsaWNpdCBoYWxmLXJlc2V0IGNvZGUuDQoNCg== From nobody Sun Nov 27 14:14:09 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D44129532 for ; Sun, 27 Nov 2016 14:14: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, 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 LNRUOwwcpOBQ for ; Sun, 27 Nov 2016 14:14:07 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EB612950F for ; Sun, 27 Nov 2016 14:14:06 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id r204so101545470ywb.0 for ; Sun, 27 Nov 2016 14:14:06 -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=SkSIFUqqe7hbZzIaUU4O7/8Pl+Hvf1uiV+eTUEkkLmE=; b=O6vD4OCrqecrgfvt7vVOXaAb6oICahVd63Rf2ig3ChcW5SHy2tIf2IuXTlVGUnaZX2 45PXbUHixQQoGM/3H6lA4RjEd6aPdOztyd7EidjLCNbQMg5Cg2boyTmteHNUvZdZnnFD Q384vuUV97pza23YRVoXaD5RFyIl1SiGKbvFMyvUu8+TY06v8RSOCkI4Dz6ObE3vVS0j UkQGUcp685JiDbLWZWaAOPjPUiPTP6/SrAPj8H1LCXhAR/y3tPryScfKUMtC1PtPOx62 YoKDkQLNJ9TUEpwDg7ZbZh+wODj6rRccRyK7LGRFgQLNxwkDYDJk+2s8pVK1IsFAqrai LdTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SkSIFUqqe7hbZzIaUU4O7/8Pl+Hvf1uiV+eTUEkkLmE=; b=bmoC1vvL2Q7+JmcvjhfuSbOeaGcgZ2sU5NGjSeQ2cfvYph+pucg73BuRPT03oSj4Pb z68wNiXJshkSK6N1ht1MK0reENp5iVXUnYjYxrgAYtLAGZAoM8lAzsrSchsMDxXUov4k 2Uhn2g5z8CDEUQnca02uxf7m1R4Ygy0YjVgK1Dfu3aIWKdxPacKORQEXgQX/DrZ+Zwiq O0kB9s/qFlkRUetInF0xCDxLJQ4RWSKlXQXAooPpPZLagdvexopj1YX9VSl1BLOYc0Rh UhTIri6zz5kBPIRIRaLt3zvHCJDejJTkb6goBB5tmpmU8V3QQIHq05vC2Wqn7yvkQgwX wm2w== X-Gm-Message-State: AKaTC029ONkSPellfEY4vtjQUNepBH3e9YEaROx41uQVjR+otOpBL63ljVTRw3iZ8Om9bqwPdRcItp+8qOHTVg== X-Received: by 10.129.53.194 with SMTP id c185mr22836425ywa.205.1480284846103; Sun, 27 Nov 2016 14:14:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sun, 27 Nov 2016 14:13:25 -0800 (PST) In-Reply-To: <10b901d248f6$4df37040$e9da50c0$@huitema.net> References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> <10b901d248f6$4df37040$e9da50c0$@huitema.net> From: Eric Rescorla Date: Sun, 27 Nov 2016 14:13:25 -0800 Message-ID: Subject: Re: Public reset PR To: Christian Huitema Content-Type: multipart/alternative; boundary=001a114214786b4d7f05424facf2 Archived-At: Cc: Jim Roskind , Kyle Rose , IETF QUIC WG , Brian Trammell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 22:14:08 -0000 --001a114214786b4d7f05424facf2 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 27, 2016 at 1:36 PM, Christian Huitema wrote: > On Sunday, November 27, 2016 5:20 AM, Kyle Rose wrote: > > > On Sat, Nov 26, 2016 at 9:23 PM, Eric Rescorla > wrote: > >> Well, there are actually two designs: > >> > >> 1. The middlebox can see the public reset but not verify it > >> 2. The middlebox cannot distinguish the public reset from other packets. > >> > >> I am concerned about #1 for the reasons indicated previously and I > originally did not see how to do #2 > >> without fairly significant client-side complexity. Now that I do, it > does seem like it's probably the leading > >> option absent some convincing policy argument that middleboxes should > be able to see these packets. > > Responding to Eric: I am not sure that I understand how the second option > works for the "rebooted server" scenario. Sure, the rebooted server can use > a persistent secret to compose the magic prefix of the encrypted payload. > But what about the sequence number? If it is not within the range that the > client expect, the packet will be dropped before processing the encrypted > payload. > Christian, can you elaborate on this? You are referring to the range of the server's sequence numbers, right? If so, it seems like that's fixed by modifying my algorithm to check the prefix as the first thing on an incoming packet. But maybe I've missed something. Thanks, -Ekr > > The problem with #2 (and related proposals to hide all connection state > from path > > elements) is that it will encourage middleboxes to continue dropping all > UDP state > > with a short timeout, requiring frequent keepalives that (e.g.) consume > battery in > > mobile devices. > > This is the SPUD/PLUS argument. But then, there is a long history of > protocols designed with high hopes of cooperation with middle boxes, > without an actual result. So at a minimum we have to ensure that whatever > solution is proposed does not introduce new attacks, or undue complexity. > > > Can not the TTL games Christian suggested for spoofed public resets be > avoided by > > a middlebox detecting smaller TTLs than previously seen for a flow? If > only packets > > likely to reach the destination were able to trigger short state > timeouts on > > middleboxes, then keepalive responses from the destination seem like > they would be > > sufficient to cover both off-path cases and the man-on-the-side. > > I would rather not rely on middleboxes playing whack-a-mole with > attackers. If we do anything at all, we should have some prescriptive > behavior based for example on "shorter timer after reset". > > -- Christian Huitema > > > > --001a114214786b4d7f05424facf2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 27, 2016 at 1:36 PM, Christian Huitema &l= t;huitema@huitema.= net> wrote:
On Sunday, Nove= mber 27, 2016 5:20 AM, Kyle Rose wrote:

> On Sat, Nov 26, 2016 at 9:23 PM, Eric Rescorla <mailto:ekr@rtfm.com> wrote:
>> Well, there are actually two designs:
>>
>> 1. The middlebox can see the public reset but not verify it
>> 2. The middlebox cannot distinguish the public reset from other pa= ckets.
>>
>> I am concerned about #1 for the reasons indicated previously and I= originally did not see how to do #2
>> without fairly significant client-side complexity. Now that I do, = it does seem like it's probably the leading
>> option absent some convincing policy argument that middleboxes sho= uld be able to see these packets.

Responding to Eric: I am not sure that I understand how the second o= ption works for the "rebooted server" scenario. Sure, the reboote= d server can use a persistent secret to compose the magic prefix of the enc= rypted payload. But what about the sequence number? If it is not within the= range that the client expect, the packet will be dropped before processing= the encrypted payload.

Christian, can = you elaborate on this? You are referring to the range of the server's s= equence numbers, right? If so, it seems like that's fixed by modifying = my algorithm to check the prefix as the first thing on an incoming packet. = But maybe I've missed something.

Thanks,
=
-Ekr


> The problem with #2 (and related proposals to hide all connection stat= e from path
> elements) is that it will encourage middleboxes to continue dropping a= ll UDP state
> with a short timeout, requiring frequent keepalives that (e.g.) consum= e battery in
> mobile devices.

This is the SPUD/PLUS argument. But then, there is a long history of= protocols designed with high hopes of cooperation with middle boxes, witho= ut an actual result. So at a minimum we have to ensure that whatever soluti= on is proposed does not introduce new attacks, or undue complexity.

> Can not the TTL games Christian suggested for spoofed public resets be= avoided by
> a middlebox detecting smaller TTLs than previously seen for a flow? If= only packets
> likely to reach the destination were able to trigger short state timeo= uts on
> middleboxes, then keepalive responses from the destination seem like t= hey would be
> sufficient to cover both off-path cases and the man-on-the-side.

I would rather not rely on middleboxes playing whack-a-mole with att= ackers. If we do anything at all, we should have some prescriptive behavior= based for example on "shorter timer after reset".

-- Christian Huitema




--001a114214786b4d7f05424facf2-- From nobody Sun Nov 27 14:47:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E897129453 for ; Sun, 27 Nov 2016 14:47:06 -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 9hgkgpRU7rej for ; Sun, 27 Nov 2016 14:47:03 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 625F81293FC for ; Sun, 27 Nov 2016 14:47:03 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id c47so107634931qtc.2 for ; Sun, 27 Nov 2016 14:47:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Nas0TM2LDJwPXDIEaK4v8k4TgdoVQHHZ0OlnuLEZ2+o=; b=fmxDioxO47Fc0v1Tfexu/rKHi/7WoDEzbcnD7cJlRvEEt5366Tw8/XywkU6M3a51rJ GVdJzsxS0Zwgqo9QSzsdoE3F1g8U92z6cN0LOvv3HkhJ/fpY3MVOEjh2vdcjpVOFY1z9 EGbnRoKvw6WvYz+V8xMY5NjBXSL11LaXBK17CUWfCZouw3L/pcs65Rrx6Za5vC1ckfsD TyVto3X76sthP2nrU2yGU2Uz7WioclksgvOGu9QkiCaAFxM0BTD0h2yXeqZFZHuX/rB0 eJ4rAcshUDZx0wjjl5C/9KTB92ZxRJevcE2zmKz3bNMfobl3TUwfcmOLNV3vV58O8rJz a+Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Nas0TM2LDJwPXDIEaK4v8k4TgdoVQHHZ0OlnuLEZ2+o=; b=LL8ipHyEvhoE0oJXGS1qUJgkWMd77UQWFC1A/YGFpyNAD3CW1Luwtp1moqXCElpXer OsQq/QvH2JpYf75NSayuF/CeeG0lMHXwVIEEOnybuf3Xxs+FidBEhLu5khymUI4SOScF P88lGWo9X7cOBG3DJQaltv+zg0Hu2lgjp0WJLia5UG1JvQfds/KHui6ozzgCTNPIjoF7 BnQw8ufWvlzq/VxW0z914oDrXi2isQSQPI+mUeZc0uVAg3oZ6nihDWbVwczEpiFLvKZP VOiPWqJEem3PDCvxAD/xzeaJOg+5VHnFzv8P0MeCsQuk1pxaoqKda9PbqyphgoChUbcU dMCA== X-Gm-Message-State: AKaTC01Dx76KwiNFpKLHzCPGKbdz5rhJAUdunTHTtP3BxrOyvzfoIDDdFC9AoywGVm5dgfIqA/pyBi8AUVMCLg== X-Received: by 10.200.41.248 with SMTP id 53mr17890769qtt.3.1480286822408; Sun, 27 Nov 2016 14:47:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Sun, 27 Nov 2016 14:47:01 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 28 Nov 2016 09:47:01 +1100 Message-ID: Subject: Re: [quic-protocol] "outstanding data" retransmission To: Mike Bishop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF QUIC WG , Tatsuhiro Tsujikawa , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 22:47:06 -0000 On 28 November 2016 at 08:37, Mike Bishop wr= ote: > Well, remember that the HTTP/2 semantic is "I no longer care about what y= ou're sending." Maybe we meet in the middle and say that you shouldn't con= tinue sending only after receipt? After sending, you don't have any acknow= ledgement from the remote side that they don't care about what you're sendi= ng. If they actually don't care, they can RST_STREAM in turn. That has a subtly different effect. The client has to wait for the end of the response. If the response takes any time to arrive, the client is still obligated to send. That said, I think that's the most workable solution here. I would like to ensure that a reset is a reset. From nobody Sun Nov 27 16:36:00 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9780A1294B7 for ; Sun, 27 Nov 2016 16:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i8Fuatdaiqu for ; Sun, 27 Nov 2016 16:35: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 B6C28126579 for ; Sun, 27 Nov 2016 16:35:56 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cB9vG-0004HY-2g for quic@ietf.org; Mon, 28 Nov 2016 01:35:55 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cB9vD-0007cO-N9 for quic@ietf.org; Sun, 27 Nov 2016 19:35:52 -0500 Received: (qmail 23491 invoked from network); 28 Nov 2016 00:35:51 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Nov 2016 00:35:50 -0000 From: "Christian Huitema" To: "'Eric Rescorla'" References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> <10b901d248f6$4df37040$e9da50c0$@huitema.net> In-Reply-To: Date: Sun, 27 Nov 2016 14:35:45 -1000 Message-ID: <10f701d2490f$5d933030$18b99090$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJonVXnL4d4ZG4Opi5oOnyTDTVr/wFxK6dxAjaMj8gCk11JPgK0p11kAM33deQCcSx/dgH5uKaZAbbvkdsC6gRqep8qlG1Q Content-Language: en-us Subject: RE: Public reset PR X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD6GI daWYcNbdOzDdVDRHggPEG9ZlUWfZrbw+sqLSWPhfdcmtTcWSOKD5RASVzg27isAXVRQgHbLLzV7b 3SwTZqt5kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRucORJzL3o1PImT0GNRxIHUMQOp+UtDOd2Xrp4Ao XsNbR5gKbK3xJI2P/mgJSlQCj8ajQpZU2HoSraNABsQx+TneNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxNnmFCUctm6OHeH6tWPSXJE7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRYE83tH9htpyVATiooT/rJiGHIfgXXvuhI9vwJN89WVO9R0tarUwIt7i7NiVJNL9jNC r2VPLfZa8ts/I6OTYjIAMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.13) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: 'Jim Roskind' , 'Kyle Rose' , 'IETF QUIC WG' , 'Brian Trammell' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 00:35:58 -0000 On Sunday, November 27, 2016 12:13 PM, Eric Rescorla wrote: > On Sun, Nov 27, 2016 at 1:36 PM, Christian Huitema = wrote: >> ... >> Responding to Eric: I am not sure that I understand how the second = option works=20 >> for the "rebooted server" scenario. Sure, the rebooted server can use = a persistent=20 >> secret to compose the magic prefix of the encrypted payload. But what = about the=20 >> sequence number? If it is not within the range that the client = expect, the packet=20 >> will be dropped before processing the encrypted payload. > > Christian, can you elaborate on this? You are referring to the range = of the server's=20 > sequence numbers, right? Yes. If the rebooted server makes up a sequence number for the PR, the = packet could be rejected by sequence number testing prior to the = decryption attempt. Also, if a middlebox keeps track of sequence numbers = it will discover that the PR is out of sequence, which somehow breaks = the design goal that "The middlebox cannot distinguish the public reset = from other packets." > If so, it seems like that's fixed by modifying my algorithm to check = the prefix as the > first thing on an incoming packet. But maybe I've missed something. That will work for the client, but an overactive middlebox could decide = that "this packet does not look to have the right sequence number" and = drop it. I suppose that we could work around that with a creative use of = sequence number compression. Mostly. -- Christian Huitema From nobody Sun Nov 27 16:44:06 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F359312941C for ; Sun, 27 Nov 2016 16:44:04 -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 MTQxib1nEuHc for ; Sun, 27 Nov 2016 16:44:03 -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 BABF0126579 for ; Sun, 27 Nov 2016 16:44:03 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id i145so103315562ywg.2 for ; Sun, 27 Nov 2016 16:44:03 -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=gvKYMlTI/PyStbcEsIN6fCDNWadrcgXWAJ0DO2mXb/8=; b=q28YjgX2FjQ+BtsBr4ybVyQyNhYaX8Ph/UxAMkay/YuhN0NT0vzD/i7XtEqtRY4oGK ODGT+c5lkKYzPEbovZusXjxWM89Jw/B3TN9zfGkk86J7Qj40p00BQIa6sd8G94w3ymu5 7o6SGs3SUNl+OVPziGsXij1rKU7q10BthOlUd7HmeR2lahAPZZWCilsFkw4cP87bLn4j qoQera7Rin04SQ/HzHmhVnZk3AHJd5PKbk+CGfCmJlf0OHzJHLRoIFNdAjB7umcW63ZW aYfSgtHxcanSDnbXspRFMlhPqEhNoPLB7w7r1t9UY9LTM2kAa3U/sCAXdXRtEl5fjQc9 Qvgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gvKYMlTI/PyStbcEsIN6fCDNWadrcgXWAJ0DO2mXb/8=; b=eUCk7EMCgsh9kAJ3EzLuUtQ7wUDe+lcg8qzzukQheLPt+kHsuIoyRNqMwiEGhFZG3Q HSy90g+TC1HZyvOHxH2Mey6DgPeiao8X9+h71H1SAJlrVCnI6o/ZdfzQBt9gXhUnvDHo eHQO+NfmN15obPiG2flAhhR5U3j4XhBEL5vCQ2e9Dvix8Dl3KCRru7wI8ofuFFuanQCA w+ep64lUGgpPB3sleMwPKZFDC224zumaxvECQUWohYogcMrjTPd7sI3tXeWKn6yEdwBR Byw8OMff3upbAb4O+d8PABYQ0wA2Jl4PiZ+/bFo7zmTG6ND80GqajBtlcQZKaA6QtZd7 rX8A== X-Gm-Message-State: AKaTC03lYvRtab2Yqw+FSarHPS7lYftreK/hS5+bXe1+gFRr+FfkwVYQpNOCtDC2umi0jemY/HJxe7gqyyIebg== X-Received: by 10.129.81.78 with SMTP id f75mr22978915ywb.149.1480293842927; Sun, 27 Nov 2016 16:44:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sun, 27 Nov 2016 16:43:22 -0800 (PST) In-Reply-To: <10f701d2490f$5d933030$18b99090$@huitema.net> References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> <10b901d248f6$4df37040$e9da50c0$@huitema.net> <10f701d2490f$5d933030$18b99090$@huitema.net> From: Eric Rescorla Date: Sun, 27 Nov 2016 16:43:22 -0800 Message-ID: Subject: Re: Public reset PR To: Christian Huitema Content-Type: multipart/alternative; boundary=001a11456404abf2ac054251c4e2 Archived-At: Cc: Jim Roskind , Kyle Rose , IETF QUIC WG , Brian Trammell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 00:44:05 -0000 --001a11456404abf2ac054251c4e2 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 27, 2016 at 4:35 PM, Christian Huitema wrote: > On Sunday, November 27, 2016 12:13 PM, Eric Rescorla wrote: > > On Sun, Nov 27, 2016 at 1:36 PM, Christian Huitema huitema@huitema.net> wrote: > >> ... > >> Responding to Eric: I am not sure that I understand how the second > option works > >> for the "rebooted server" scenario. Sure, the rebooted server can use a > persistent > >> secret to compose the magic prefix of the encrypted payload. But what > about the > >> sequence number? If it is not within the range that the client expect, > the packet > >> will be dropped before processing the encrypted payload. > > > > Christian, can you elaborate on this? You are referring to the range of > the server's > > sequence numbers, right? > > Yes. If the rebooted server makes up a sequence number for the PR, the > packet could be rejected by sequence number testing prior to the decryption > attempt. Also, if a middlebox keeps track of sequence numbers it will > discover that the PR is out of sequence, which somehow breaks the design > goal that "The middlebox cannot distinguish the public reset from other > packets." > > > If so, it seems like that's fixed by modifying my algorithm to check the > prefix as the > > first thing on an incoming packet. But maybe I've missed something. > > That will work for the client, but an overactive middlebox could decide > that "this packet does not look to have the right sequence number" and drop > it. I suppose that we could work around that with a creative use of > sequence number compression. Mostly. > Good point. So it's not totally indistinguishable. Ugh. -Ekr > > -- Christian Huitema > > > > --001a11456404abf2ac054251c4e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 27, 2016 at 4:35 PM, Christian Huitema &l= t;huitema@huitema.= net> wrote:
On Sunday, Nove= mber 27, 2016 12:13 PM, Eric Rescorla wrote:
> On Sun, Nov 27, 2016 at 1:36 PM, Christian Huitema <mailto:huitema@huitema.net> wrote:
>> ...
>> Responding to Eric: I am not sure that I understa= nd how the second option works
>> for the "rebooted server" scenario. Sure, the rebooted s= erver can use a persistent
>> secret to compose the magic prefix of the encrypted payload. But w= hat about the
>> sequence number? If it is not within the range that the client exp= ect, the packet
>> will be dropped before processing the encrypted payload.
>
> Christian, can you elaborate on this? You are referring to the range o= f the server's
> sequence numbers, right?

Yes. If the rebooted server makes up a sequence number for the PR, t= he packet could be rejected by sequence number testing prior to the decrypt= ion attempt. Also, if a middlebox keeps track of sequence numbers it will d= iscover that the PR is out of sequence, which somehow breaks the design goa= l that "The middlebox cannot distinguish the public reset from other p= ackets."

> If so, it seems like that's fixed by modifying my algorithm to che= ck the prefix as the
> first thing on an incoming packet. But maybe I've missed something= .

That will work for the client, but an overactive middlebox could dec= ide that "this packet does not look to have the right sequence number&= quot; and drop it. I suppose that we could work around that with a creative= use of sequence number compression. Mostly.

Good point. So it's not totally indistinguishable. Ugh.

-Ekr
=C2=A0

-- Christian Huitema




--001a11456404abf2ac054251c4e2-- From nobody Sun Nov 27 22:10:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FC6128874 for ; Sun, 27 Nov 2016 22:10:12 -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 tDCObyXpP1iU for ; Sun, 27 Nov 2016 22:10:11 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003: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 021C312944D for ; Sun, 27 Nov 2016 22:10:11 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id y198so139293182oia.1 for ; Sun, 27 Nov 2016 22:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7hsX5SJlQ/wYHuVLrk28yZQdEQCPqA3eyV28jYE1nyQ=; b=eQkAW0V51CILpFj3L1CEbyhqDMOYaxklRu+4mscV4Ph85d69MQAB4hCvi2kLWrda46 27EGrJtxcsYTqOL/URt9kOoxTyTm28cTJRmvLfsWNbC1BkslzWGZfNnajLvsI5BCcHj+ SR9aIHSIv9QJE2OIR93ZlJIT8O0xRI7QEB/Isq4yw2219STN7wn2H+QFUD975Jsfbtu3 3ll4z1LmEjzJOTn3+oZBzkXzwai5a8DoMRHA5JKvQrrD4ybmVinIoY/HPCgOCJ91xDVD WxGlVYDk0edN/897J5XlkyKkjHix0zSc1rj0EbEbxLX56CNAPs040vvCn0xZ6ER+OW8o AswA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7hsX5SJlQ/wYHuVLrk28yZQdEQCPqA3eyV28jYE1nyQ=; b=VvSISZoAYzm4Sewucz1X/2+9oD5+bCX0XrDQymDWWLwjWgrzwDESat1S+rmp5jLNUG VUSe5Phd46OL7VoDJSQeIE91i48XmsPY9W5QgtxhHHaQA7XYSyqUW9pFEm1rPl+V43h1 jGnFxDzxfgWrcFw+Iz271VIvw//YXtJ/03pnC66Def2HgI0AFyF12yKsHK2IOt9On5SX Bz3mAnLgC1D/ebAS4pdCSGuyEwPwd3ZEE4kgzl1htf4VJEpLuKh7ZO1crvf39ddYz16J lD1c6O/8kZtIsudUtPnDHUUJVzggSdjBmq4104gRvNp3i+GEe7IE8cfbsktT4h/Njylm 4LPQ== X-Gm-Message-State: AKaTC01jTpmrgVVky3C3+I3Igl068AFoz759Tyt3I0IQ/npY4lcdZnoS8EeZgppfUdRnNDKKLnFCypnSKjVo0g== X-Received: by 10.157.1.181 with SMTP id e50mr10684707ote.258.1480313410267; Sun, 27 Nov 2016 22:10:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.6.7 with HTTP; Sun, 27 Nov 2016 22:10:09 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Martin Duke Date: Sun, 27 Nov 2016 22:10:09 -0800 Message-ID: Subject: Re: Public reset PR To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c03d05ef9adc20542565297 Archived-At: Cc: Jim Roskind , IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 06:10:13 -0000 --94eb2c03d05ef9adc20542565297 Content-Type: text/plain; charset=UTF-8 > > >> I guess I'm a little unclear as to the conditions of "the high entropy >> secret value R". Perhaps you could confirm the order of operations, which I >> construe as follows: >> >> 1) Endpoint computes a random secret for all connections for some period >> of time, and stores this somewhere that will survive reboots. >> 2) For a new connection, the endpoint performs some operation with the >> secret and the connection ID and includes the result R in an encrypted >> handshake message. >> 3) Endpoint reboots. >> 4) When the peer sends another packet, the endpoint uses the connection >> ID and its secret to figure R and make it the first 16 bytes of the cipher >> text. >> 5) Peer has the original connection state and can correctly interpret the >> reset. >> >> Is that accurate? >> > > Yes. > > -Ekr > Alright, I think this is a good start but I have some concerns: 1) The scheme's security is dependent on truly random connection IDs, because otherwise I can probe servers with garbage packets and certain likely connection IDs and obtain the corresponding R values. In particular, the current Chromium stateless reject model uses a server-recommended connection ID for the next connection, so a eavesdropper could in theory attack these connections. I have no idea if that "feature" will survive to the final spec. 2) Someone raised the load balancer question earlier but I don't think it ever got a satisfactory reply. There are many load balancer architectures, but a common one assigns connections to servers based on some strategy which is not necessarily a hash of the 4-tuple or 5-tuple. This sets up pretty simple scenarios for failure: the server behind the load balancer aborts the connection, which erases the state at the load balancer, but the public reset is lost in the network. The next client packet is assigned to a different server, which has a different secret and cannot send a valid reset. All that said, I don't have an alternative proposal that is not expensive (e.g. signing with the private key). Martin > > >> >> >>> >>> >>> >>> >>> >>> >>> >>>> On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema < >>>>>>> huitema@huitema.net> wrote: >>>>>>> >>>>>>>> On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: >>>>>>>> >>>>>>>> > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema >>>>>>> huitema@huitema.net> wrote: >>>>>>>> >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: >>>>>>>> >>> >>>>>>>> >>> ... (discussion of security properties and alternative >>>>>>>> design)... >>>>>>>> >> >>>>>>>> >>> Note that it might still independently be a good idea to allow >>>>>>>> middleboxes to see the >>>>>>>> >>> public reset, but I think that this demonstrates that that's a >>>>>>>> policy choice about the >>>>>>>> >>> design of the protocol, not something mandated by limitations >>>>>>>> in what we can design. >>>>>>>> > >>>>>>>> >> On limit of the pre-image design is that intermediaries cannot >>>>>>>> do the verification. Well, >>>>>>>> >> they could if the option was sent in clear text, and if they >>>>>>>> parsed the corresponding packet. >>>>>>>> > >>>>>>>> > Yes, that's correct; it's the assumption of this design that the >>>>>>>> would do so. If you think that >>>>>>>> > they won't then there are much simpler designs (like the one in >>>>>>>> the message you are >>>>>>>> > responding to). >>>>>>>> >>>>>>>> Do we really want to ask intermediaries to go parse options inside >>>>>>>> the TLS handshake inside stream 1? That does not strike me as too >>>>>>>> desirable. I am concerned of the potential there for ossification. I have >>>>>>>> visions of delaying the move to TLS 4.1 a couple years from now because >>>>>>>> intermediaries really expect TLS 1.3. >>>>>>>> >>>>>>>> Then, there is the potential for spoofing. If the verifier text is >>>>>>>> sent in clear text, it can be spoofed. What if the man on the side sends a >>>>>>>> new Server Hello, with a verifier option of its own choosing? OK, I suppose >>>>>>>> that if the spoofed packet wins the race with the authentic Server Hello, >>>>>>>> the client will just fail the connection. The spoofed Server Hello becomes >>>>>>>> the new weapon of the censors... But even if the spoofed packet does not >>>>>>>> win the race, how many intermediaries would just be fooled and accept the >>>>>>>> new verifier, and of course the spoofed public reset that follows? >>>>>>>> >>>>>>> >>>>>>> Hmm... I would ordinarily expect that clients would respond to a >>>>>>> bogus CH (e.g., one that's malformed or that >>>>>>> doesn't cryptographically verify) by hanging up the connection, so >>>>>>> I'm not sure that this would make the situation >>>>>>> that much worse. >>>>>>> >>>>>>> >>>>>>> I like the simpler design in which only the client can tell whether >>>>>>>> the public reset is authentic. >>>>>>>> >>>>>>> >>>>>>> Well, there are actually two designs: >>>>>>> >>>>>>> 1. The middlebox can see the public reset but not verify it >>>>>>> 2. The middlebox cannot distinguish the public reset from other >>>>>>> packets. >>>>>>> >>>>>>> I am concerned about #1 for the reasons indicated previously and I >>>>>>> originally did not see how to do #2 >>>>>>> without fairly significant client-side complexity. Now that I do, it >>>>>>> does seem like it's probably the leading >>>>>>> option absent some convincing policy argument that middleboxes >>>>>>> should be able to see these packets. >>>>>>> >>>>>>> -Ekr >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -- Christian Huitema >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --94eb2c03d05ef9adc20542565297 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I guess I'm a little unclear as to the conditi= ons of "the=C2=A0high entropy secret = value R". Perhaps you could confirm the order of operations, which I c= onstrue as follows:

<= /span>
1) Endpoint computes a ra= ndom secret for all connections for some period of time, and stores this so= mewhere that will survive reboots.
2) For a new connection, the endpoint performs some operation wit= h the secret and the connection ID and includes the result R in an encrypte= d handshake message.
3) E= ndpoint reboots.
4) When = the peer sends another packet, the endpoint uses the connection ID and its = secret to figure R and make it the first 16 bytes of the cipher text.
5) Peer has the original conne= ction state and can correctly interpret the reset.

Is that accurate?

Yes.

-Ekr


<= /div>
Alright, I think this is a good start but I have some concerns:

1) The scheme's security is dependent on truly = random connection IDs, because otherwise I can probe servers with garbage p= ackets and certain likely connection IDs and obtain the corresponding R val= ues. In particular, the current Chromium stateless reject model uses a serv= er-recommended connection ID for the next connection, so a eavesdropper cou= ld in theory attack these connections. I have no idea if that "feature= " will survive to the final spec.

2) Someone = raised the load balancer question earlier but I don't think it ever got= a satisfactory reply. There are many load balancer architectures, but a co= mmon one assigns connections to servers based on some strategy which is not= necessarily a hash of the 4-tuple or 5-tuple.

Thi= s sets up pretty simple scenarios for failure: the server behind the load b= alancer aborts the connection, which erases the state at the load balancer,= but the public reset is lost in the network. The next client packet is ass= igned to a different server, which has a different secret and cannot send a= valid reset.

All that said, I don't have an a= lternative proposal that is not expensive (e.g. signing with the private ke= y).

Martin
=C2=A0
=C2=A0




<= div>
=C2=A0
On Sat, Nov 26, 2016 at 6:23 PM, Er= ic Rescorla <ekr@rtfm.com> wrote:


<= div class=3D"gmail_quote">On Sat, Nov 26, 2016 at 6:17 PM, Christian = Huitema <huitema@huitema.net> wrote:
On Saturday, November 26, 2016 3:58 PM, Er= ic Rescorla wrote:

> On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema <mailto:huitema@huitema.net&g= t; wrote:
>> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote:
>>>
>>> ... (discussion of security properties and alternative design)= ...
>>
>>> Note that it might still independently be a good idea to allow= middleboxes to see the
>>> public reset, but I think that this demonstrates that that'= ;s a policy choice about the
>>> design of the protocol, not something mandated by limitations = in what we can design.
>
>> On limit of the pre-image design is that intermediaries cannot do = the verification. Well,
>> they could if the option was sent in clear text, and if they parse= d the corresponding packet.
>
> Yes, that's correct; it's the assumption of this design that t= he would do so. If you think that
> they won't then there are much simpler designs (like the one in th= e message you are
> responding to).

Do we really want to ask intermediaries to go parse options inside t= he TLS handshake inside stream 1? That does not strike me as too desirable.= I am concerned of the potential there for ossification. I have visions of = delaying the move to TLS 4.1 a couple years from now because intermediaries= really expect TLS 1.3.

Then, there is the potential for spoofing. If the verifier text is sent in = clear text, it can be spoofed. What if the man on the side sends a new Serv= er Hello, with a verifier option of its own choosing? OK, I suppose that if= the spoofed packet wins the race with the authentic Server Hello, the clie= nt will just fail the connection. The spoofed Server Hello becomes the new = weapon of the censors... But even if the spoofed packet does not win the ra= ce, how many intermediaries would just be fooled and accept the new verifie= r, and of course the spoofed public reset that follows?

Hmm... I would ordinarily expect that clients would= respond to a bogus CH (e.g., one that's malformed or that
do= esn't cryptographically verify) by hanging up the connection, so I'= m not sure that this would make the situation
that much worse.


I like the simpler design in which only the client can tell whether the pub= lic reset is authentic.

Well, th= ere are actually two designs:

1. The middlebox can= see the public reset but not verify it
2. The middlebox cannot d= istinguish the public reset from other packets.

I = am concerned about #1 for the reasons indicated previously and I originally= did not see how to do #2
without fairly significant client-side = complexity. Now that I do, it does seem like it's probably the leading<= /div>
option absent some convincing policy argument that middleboxes sh= ould be able to see these packets.

-Ekr
= =C2=A0

-- Christian Huitema











--94eb2c03d05ef9adc20542565297-- From nobody Sun Nov 27 22:15:51 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16080129563 for ; Sun, 27 Nov 2016 22:15:50 -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, 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 L0-71Raoo3i0 for ; Sun, 27 Nov 2016 22:15:48 -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 7C3ED1294F7 for ; Sun, 27 Nov 2016 22:15:48 -0800 (PST) Received: by mail-oi0-x229.google.com with SMTP id b126so139053239oia.2 for ; Sun, 27 Nov 2016 22:15:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=11QRJpc+zpejqLoo+7pK8yUZekrbYWz7w2q23taf5Fk=; b=h6kbwl8solnVLl76BLBa7VwIUPpV7xEEpi37P4MbMpHcOTvFRzL/9tS6ZC8jxPBXEp i9LuV2B+KZ2PEpMpOjgmZStKnnUBQbK3+bstSJhpRS6bKKc+Fp3QhTRBVJkh5aVkvvth 2GyucDWQo1DZQU5xHWssusgJocqcKBJ2fbc1Odq2rkcmn0cM3VS1Ejhksv2mCPgXZe8c 2MstsJPMYtwNUBEuACU8JNua8o/sQm42n4qYEbsSYlV2O6gNGT9sJYuqrGnemK5xdpkH dgfABKsZXtG0NWYAXzZOXJsNYYS0CiPv+UfFMdMJ6YwMWnlwjtHGCQyL0DPvkuNFW3HU cBiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=11QRJpc+zpejqLoo+7pK8yUZekrbYWz7w2q23taf5Fk=; b=X1i98J0PbhrgCdZI5GCsAcsNtDjqLQesuYSPag2HSl7rEt5x5Wjs/o9E1pgDvU6aWK TsPJX2LCXdwxk18Dv/lQf194zYsF4zVDXvmi2zL7/txpAvQ1JNhCe802bFHa+7e9AffK Wu4PwzMa2Ag4e5ibNOLnOhZvhUjT/l4YTnMsOD/pF4TAlDzQqTJm1WvtTZJM0ArHbaJE nmkuvNmZfxBpzFj7Y4hRYRVgeTAO8aGQkGxLdtLdldDOhRRjZoZZLGVDPj8Mzv2wDnZ/ FuwZ124WWQBTdB4/vpq4jo4D/+59x3IFHU4uRqjF5n6/IFs0KLy7laq6POxyM5GTGs8X UxTw== X-Gm-Message-State: AKaTC01Rt3/QlX6+kZsJ7W7R2wy1q1R62Zytj2Q7Vv6U711xTo1h05GzUe+vPqG+wX2CQjVO+XhyDg5gPILCRA== X-Received: by 10.157.38.151 with SMTP id l23mr10376004otb.97.1480313747919; Sun, 27 Nov 2016 22:15:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.6.7 with HTTP; Sun, 27 Nov 2016 22:15:47 -0800 (PST) In-Reply-To: <10f701d2490f$5d933030$18b99090$@huitema.net> References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> <10b901d248f6$4df37040$e9da50c0$@huitema.net> <10f701d2490f$5d933030$18b99090$@huitema.net> From: Martin Duke Date: Sun, 27 Nov 2016 22:15:47 -0800 Message-ID: Subject: Re: Public reset PR To: Christian Huitema Content-Type: multipart/alternative; boundary=001a1143042e19d8c0054256676e Archived-At: Cc: Jim Roskind , Eric Rescorla , Kyle Rose , IETF QUIC WG , Brian Trammell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 06:15:50 -0000 --001a1143042e19d8c0054256676e Content-Type: text/plain; charset=UTF-8 Public Reset Packets do not have Packet Numbers. There would be no way for a rebooted server to infer the correct packet number (as for sequence number in TCP) because the ACK frame is encrypted, and may not be present at all. The draft format does include the number of the packet that triggered the reset. This offers some protection against off-path attackers, but none against eavesdroppers. My understanding was this field was not in the proposal we are discussing. Martin On Sun, Nov 27, 2016 at 4:35 PM, Christian Huitema wrote: > On Sunday, November 27, 2016 12:13 PM, Eric Rescorla wrote: > > On Sun, Nov 27, 2016 at 1:36 PM, Christian Huitema huitema@huitema.net> wrote: > >> ... > >> Responding to Eric: I am not sure that I understand how the second > option works > >> for the "rebooted server" scenario. Sure, the rebooted server can use a > persistent > >> secret to compose the magic prefix of the encrypted payload. But what > about the > >> sequence number? If it is not within the range that the client expect, > the packet > >> will be dropped before processing the encrypted payload. > > > > Christian, can you elaborate on this? You are referring to the range of > the server's > > sequence numbers, right? > > Yes. If the rebooted server makes up a sequence number for the PR, the > packet could be rejected by sequence number testing prior to the decryption > attempt. Also, if a middlebox keeps track of sequence numbers it will > discover that the PR is out of sequence, which somehow breaks the design > goal that "The middlebox cannot distinguish the public reset from other > packets." > > > If so, it seems like that's fixed by modifying my algorithm to check the > prefix as the > > first thing on an incoming packet. But maybe I've missed something. > > That will work for the client, but an overactive middlebox could decide > that "this packet does not look to have the right sequence number" and drop > it. I suppose that we could work around that with a creative use of > sequence number compression. Mostly. > > -- Christian Huitema > > > > --001a1143042e19d8c0054256676e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Public Reset Packets do not have Packet Numbers. There wou= ld be no way for a rebooted server to infer the correct packet number (as f= or sequence number in TCP) because the ACK frame is encrypted, and may not = be present at all.

The draft format does include the num= ber of the packet that triggered the reset. This offers some protection aga= inst off-path attackers, but none against eavesdroppers. My understanding w= as this field was not in the proposal we are discussing.

Martin

On Sun, Nov 27, 2016 at 4:35 PM, Christian Huitema <huitema@huit= ema.net> wrote:
On Sunday, = November 27, 2016 12:13 PM, Eric Rescorla wrote:
> On Sun, Nov 27, 2016 at 1:36 PM, Christian Huitema <mailto:huitema@huitema.net> wrote:
>> ...
>> Responding to Eric: I am not sure that I understa= nd how the second option works
>> for the "rebooted server" scenario. Sure, the rebooted s= erver can use a persistent
>> secret to compose the magic prefix of the encrypted payload. But w= hat about the
>> sequence number? If it is not within the range that the client exp= ect, the packet
>> will be dropped before processing the encrypted payload.
>
> Christian, can you elaborate on this? You are referring to the range o= f the server's
> sequence numbers, right?

Yes. If the rebooted server makes up a sequence number for the PR, t= he packet could be rejected by sequence number testing prior to the decrypt= ion attempt. Also, if a middlebox keeps track of sequence numbers it will d= iscover that the PR is out of sequence, which somehow breaks the design goa= l that "The middlebox cannot distinguish the public reset from other p= ackets."

> If so, it seems like that's fixed by modifying my algorithm to che= ck the prefix as the
> first thing on an incoming packet. But maybe I've missed something= .

That will work for the client, but an overactive middlebox could dec= ide that "this packet does not look to have the right sequence number&= quot; and drop it. I suppose that we could work around that with a creative= use of sequence number compression. Mostly.

-- Christian Huitema




--001a1143042e19d8c0054256676e-- From nobody Sun Nov 27 22:26:44 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3FAF127078 for ; Sun, 27 Nov 2016 22:26:42 -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 qpTq6x2u0fdQ for ; Sun, 27 Nov 2016 22:26:41 -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 E555F129479 for ; Sun, 27 Nov 2016 22:26:40 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id i145so107808354ywg.2 for ; Sun, 27 Nov 2016 22:26:40 -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=PWsYopL9GOscXcIaD3dkU0x3FXV4KekIXOxYat+04Y8=; b=sGg8mJGGdBMCvgui39xFIpjoRPlnagR/atOP3elOOHIyGqLeVH7d4takKNTQDY33vC XNxRwbLeL3iZfsYaanHMxuDqkQRTcY5oGwjxJwWl2CFt+gd50JbePVvfJ2tKVlav5pDv FS2CTiYcwCAy+y2myLz1gCT7wAiS5kdwQOi+Z6yxpXZDrLoxwrsvEb2j5PIqnWfsbfBm b7kQYorleO3D5Vy7gI4/FJLQcflQigfu5s8euOBW+vRYY9VwR1eE2ezrw4fYFcTE/Enq XN6sB7FTSJ+6nsoExFgfw52ZX0YGIKn6rRi5DfI4njSKk77Mo/HZ7Wr2XKf9eaBxGRe/ +vqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PWsYopL9GOscXcIaD3dkU0x3FXV4KekIXOxYat+04Y8=; b=XH24R6djC/VFoBJwn1+hNf19dKXfKavMDsyvhL15m69Xf+rYIHNUyiudOzFuVXtJRF 4yZB3MdUPG2XznNmSrOxV2kFfmJ5Jm2S13reRruOgPTWrKsfF6Z7lpXN5g846S2Fo8n0 q584sQEZ4M3zqOYRQ/MvqEYoWWdbgG1I8KSrH3liq/Ip1ACZ2VPmTD8S58OPL2LA+QVU bg3qVZFL4fwLbLLtSDjbfNW00MpRL0XulY/Ekz/f1I1kz4ivnT+zlhSsG7e01WJ2Szzj 4xv8yIysPQ8ltGoBtBM4KRMbEhmqlg/iyI2DCiKWQY2P0OhmwSxtahhWVyrQitpvJ99N IdvA== X-Gm-Message-State: AKaTC007TkhKFlnLPNQS/USvJliqVFGZblydh3RXOvF+fPt32GOQ9Gwztu8dyHEKUqDeMHjMVDn3plR0Qsn1HQ== X-Received: by 10.129.59.9 with SMTP id i9mr27223298ywa.79.1480314400073; Sun, 27 Nov 2016 22:26:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sun, 27 Nov 2016 22:25:59 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Eric Rescorla Date: Mon, 28 Nov 2016 01:25:59 -0500 Message-ID: Subject: Re: Public reset PR To: Martin Duke Content-Type: multipart/alternative; boundary=001a114325bcf93bee0542568da8 Archived-At: Cc: Jim Roskind , IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 06:26:43 -0000 --001a114325bcf93bee0542568da8 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 28, 2016 at 1:10 AM, Martin Duke wrote: > >>> I guess I'm a little unclear as to the conditions of "the high entropy >>> secret value R". Perhaps you could confirm the order of operations, which I >>> construe as follows: >>> >>> 1) Endpoint computes a random secret for all connections for some period >>> of time, and stores this somewhere that will survive reboots. >>> 2) For a new connection, the endpoint performs some operation with the >>> secret and the connection ID and includes the result R in an encrypted >>> handshake message. >>> 3) Endpoint reboots. >>> 4) When the peer sends another packet, the endpoint uses the connection >>> ID and its secret to figure R and make it the first 16 bytes of the cipher >>> text. >>> 5) Peer has the original connection state and can correctly interpret >>> the reset. >>> >>> Is that accurate? >>> >> >> Yes. >> >> -Ekr >> > > > Alright, I think this is a good start but I have some concerns: > > 1) The scheme's security is dependent on truly random connection IDs, > because otherwise I can probe servers with garbage packets and certain > likely connection IDs and obtain the corresponding R values. In particular, > the current Chromium stateless reject model uses a server-recommended > connection ID for the next connection, so a eavesdropper could in theory > attack these connections. I have no idea if that "feature" will survive to > the final spec. > Good point. This requires the server to dictate at least part of the connection ID and that it not be repeated. I think I'd just forgotten that that was an undecided issue. It does not require that it be random, however. 2) Someone raised the load balancer question earlier but I don't think it > ever got a satisfactory reply. There are many load balancer architectures, > but a common one assigns connections to servers based on some strategy > which is not necessarily a hash of the 4-tuple or 5-tuple. > > This sets up pretty simple scenarios for failure: the server behind the > load balancer aborts the connection, which erases the state at the load > balancer, but the public reset is lost in the network. The next client > packet is assigned to a different server, which has a different secret and > cannot send a valid reset. > The assumption here is that all the devices behind the load balancer share a seed for generating the reset secret. -Ekr > All that said, I don't have an alternative proposal that is not expensive > (e.g. signing with the private key). > > Martin > >> >> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema < >>>>>>>> huitema@huitema.net> wrote: >>>>>>>> >>>>>>>>> On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: >>>>>>>>> >>>>>>>>> > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema >>>>>>>> huitema@huitema.net> wrote: >>>>>>>>> >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: >>>>>>>>> >>> >>>>>>>>> >>> ... (discussion of security properties and alternative >>>>>>>>> design)... >>>>>>>>> >> >>>>>>>>> >>> Note that it might still independently be a good idea to allow >>>>>>>>> middleboxes to see the >>>>>>>>> >>> public reset, but I think that this demonstrates that that's a >>>>>>>>> policy choice about the >>>>>>>>> >>> design of the protocol, not something mandated by limitations >>>>>>>>> in what we can design. >>>>>>>>> > >>>>>>>>> >> On limit of the pre-image design is that intermediaries cannot >>>>>>>>> do the verification. Well, >>>>>>>>> >> they could if the option was sent in clear text, and if they >>>>>>>>> parsed the corresponding packet. >>>>>>>>> > >>>>>>>>> > Yes, that's correct; it's the assumption of this design that the >>>>>>>>> would do so. If you think that >>>>>>>>> > they won't then there are much simpler designs (like the one in >>>>>>>>> the message you are >>>>>>>>> > responding to). >>>>>>>>> >>>>>>>>> Do we really want to ask intermediaries to go parse options inside >>>>>>>>> the TLS handshake inside stream 1? That does not strike me as too >>>>>>>>> desirable. I am concerned of the potential there for ossification. I have >>>>>>>>> visions of delaying the move to TLS 4.1 a couple years from now because >>>>>>>>> intermediaries really expect TLS 1.3. >>>>>>>>> >>>>>>>>> Then, there is the potential for spoofing. If the verifier text is >>>>>>>>> sent in clear text, it can be spoofed. What if the man on the side sends a >>>>>>>>> new Server Hello, with a verifier option of its own choosing? OK, I suppose >>>>>>>>> that if the spoofed packet wins the race with the authentic Server Hello, >>>>>>>>> the client will just fail the connection. The spoofed Server Hello becomes >>>>>>>>> the new weapon of the censors... But even if the spoofed packet does not >>>>>>>>> win the race, how many intermediaries would just be fooled and accept the >>>>>>>>> new verifier, and of course the spoofed public reset that follows? >>>>>>>>> >>>>>>>> >>>>>>>> Hmm... I would ordinarily expect that clients would respond to a >>>>>>>> bogus CH (e.g., one that's malformed or that >>>>>>>> doesn't cryptographically verify) by hanging up the connection, so >>>>>>>> I'm not sure that this would make the situation >>>>>>>> that much worse. >>>>>>>> >>>>>>>> >>>>>>>> I like the simpler design in which only the client can tell whether >>>>>>>>> the public reset is authentic. >>>>>>>>> >>>>>>>> >>>>>>>> Well, there are actually two designs: >>>>>>>> >>>>>>>> 1. The middlebox can see the public reset but not verify it >>>>>>>> 2. The middlebox cannot distinguish the public reset from other >>>>>>>> packets. >>>>>>>> >>>>>>>> I am concerned about #1 for the reasons indicated previously and I >>>>>>>> originally did not see how to do #2 >>>>>>>> without fairly significant client-side complexity. Now that I do, >>>>>>>> it does seem like it's probably the leading >>>>>>>> option absent some convincing policy argument that middleboxes >>>>>>>> should be able to see these packets. >>>>>>>> >>>>>>>> -Ekr >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> -- Christian Huitema >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --001a114325bcf93bee0542568da8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 28, 2016 at 1:10 AM, Martin Duke <martin.h.duke@gmai= l.com> wrote:
=
=

=
I guess I'm a little unclear as to the conditions of = "the=C2=A0high entropy secret value R= ". Perhaps you could confirm the order of operations, which I construe= as follows:

<= /div>
1) Endpoint computes a random se= cret for all connections for some period of time, and stores this somewhere= that will survive reboots.
2) For a new connection, the endpoint performs some operation with the s= ecret and the connection ID and includes the result R in an encrypted hands= hake message.
3) Endpoint= reboots.
4) When the pee= r sends another packet, the endpoint uses the connection ID and its secret = to figure R and make it the first 16 bytes of the cipher text.
=
5) Peer has the original connection s= tate and can correctly interpret the reset.

Is that accurate?

Yes.

-Ekr


Alright, I think this is a good start but I have some concerns:

1) The scheme's security is dependent on truly = random connection IDs, because otherwise I can probe servers with garbage p= ackets and certain likely connection IDs and obtain the corresponding R val= ues. In particular, the current Chromium stateless reject model uses a serv= er-recommended connection ID for the next connection, so a eavesdropper cou= ld in theory attack these connections. I have no idea if that "feature= " will survive to the final spec.
=

Good point. This requires the server to dictate at leas= t part of the connection ID and that it not be repeated. I think I'd ju= st forgotten that that was an undecided issue.
It does not requir= e that it be random, however.


2) Someone raised the load balancer question earlier = but I don't think it ever got a satisfactory reply. There are many load= balancer architectures, but a common one assigns connections to servers ba= sed on some strategy which is not necessarily a hash of the 4-tuple or 5-tu= ple.

This sets up pretty simple scenarios for fail= ure: the server behind the load balancer aborts the connection, which erase= s the state at the load balancer, but the public reset is lost in the netwo= rk. The next client packet is assigned to a different server, which has a d= ifferent secret and cannot send a valid reset.

The assumption here is that all the devices beh= ind the load balancer share a seed for generating the reset secret.

-Ekr

<= div dir=3D"ltr">
=
All that said, I don't have an alternative proposal that= is not expensive (e.g. signing with the private key).

Martin
<= div class=3D"gmail_extra">
=C2=A0
=C2=A0





=C2=A0
On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla <ekr@rtfm.com= > wrote:


On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema <huitema@h= uitema.net> wrote:
On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote:

> On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema <mailto:huitema@huitema.net&g= t; wrote:
>> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote:
>>>
>>> ... (discussion of security properties and alternative design)= ...
>>
>>> Note that it might still independently be a good idea to allow= middleboxes to see the
>>> public reset, but I think that this demonstrates that that'= ;s a policy choice about the
>>> design of the protocol, not something mandated by limitations = in what we can design.
>
>> On limit of the pre-image design is that intermediaries cannot do = the verification. Well,
>> they could if the option was sent in clear text, and if they parse= d the corresponding packet.
>
> Yes, that's correct; it's the assumption of this design that t= he would do so. If you think that
> they won't then there are much simpler designs (like the one in th= e message you are
> responding to).

Do we really want to ask intermediaries to go parse options inside t= he TLS handshake inside stream 1? That does not strike me as too desirable.= I am concerned of the potential there for ossification. I have visions of = delaying the move to TLS 4.1 a couple years from now because intermediaries= really expect TLS 1.3.

Then, there is the potential for spoofing. If the verifier text is sent in = clear text, it can be spoofed. What if the man on the side sends a new Serv= er Hello, with a verifier option of its own choosing? OK, I suppose that if= the spoofed packet wins the race with the authentic Server Hello, the clie= nt will just fail the connection. The spoofed Server Hello becomes the new = weapon of the censors... But even if the spoofed packet does not win the ra= ce, how many intermediaries would just be fooled and accept the new verifie= r, and of course the spoofed public reset that follows?

Hmm... I would ordinarily expect that clients would= respond to a bogus CH (e.g., one that's malformed or that
do= esn't cryptographically verify) by hanging up the connection, so I'= m not sure that this would make the situation
that much worse.


I like the simpler design in which only the client can tell whether the pub= lic reset is authentic.

Well, th= ere are actually two designs:

1. The middlebox can= see the public reset but not verify it
2. The middlebox cannot d= istinguish the public reset from other packets.

I = am concerned about #1 for the reasons indicated previously and I originally= did not see how to do #2
without fairly significant client-side = complexity. Now that I do, it does seem like it's probably the leading<= /div>
option absent some convincing policy argument that middleboxes sh= ould be able to see these packets.

-Ekr
= =C2=A0

-- Christian Huitema












--001a114325bcf93bee0542568da8-- From nobody Sun Nov 27 22:46:47 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6AA812957A for ; Sun, 27 Nov 2016 22:46:45 -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 SG0U9uQdKiwU for ; Sun, 27 Nov 2016 22:46:42 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::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 A239C129406 for ; Sun, 27 Nov 2016 22:46:42 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id w33so113779752qtc.3 for ; Sun, 27 Nov 2016 22:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4w+4vKqI4RRnHbex9FZwYufBOACThN80dpNOcpqIfws=; b=b1K8jvZJoDJjKP1+vWTIWSsiSnylCeg5u8SEPynYDQ+StWcZ3uhj1fB1nCwyBAmubV yrI25NvIy/rk/DG3TNoLh82IsZfwkjfUf9jS39zGD/Sz56okvvNmEFTWd0RUqzFxFOHE ByuhAzF9W+wOARh0ewg5/QKxoh+4qn3k68Z2KaN9iX2GocQL0OujbLEQrGaq9jozyZ0M iNbehRnAIddYvnoI11EI9jd5YUIzi+jDoit1CcbTL6J/GJhTuroJosYFJbvjg4UeY+SA JtKnsoDRc+7I6/3lL0eS2eHsEPRYlgpDWnOTLXsype4iWiZ0uhdpjMVJ4YFGidCki30/ tbwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4w+4vKqI4RRnHbex9FZwYufBOACThN80dpNOcpqIfws=; b=Xp3QRKURfO4WntbMlZulvte2j+ALhWACgvMFyluHPjameo8hKY7z7mX5AxeMuI9zX+ 7bDWozjwH4iFe4pfW6xPQyGKuDqb8uQn7GYHqLne9Ijqdw8BNbwI3kvFjup6J1bhxun3 NunjeFJPt2fuj1mdgvhZ/aLPGukZ8EQ2FlpHo7owNuQ4LhKamrS60DwWABKs27vj6CTX tvk7+UBw3c8baqD538CjWK4/v/NzG3/5VArxYUbiiQUXN2s2ksFqe8qLbWrovifu7oii jxLoulNSVax53w27eHgs/UlNdifunh3SLo/QhKRCTYKat7vxX7VDcy4MLej2HQC/fS6v duUw== X-Gm-Message-State: AKaTC01SwjHvHlvkUBWvaao+fuiCaxFwDx3xhmY5amCzL2vfgfc54LFHp5fzqUQy+42+QEYOl0ynbu+aWn5Y1A== X-Received: by 10.200.48.28 with SMTP id f28mr19382272qte.247.1480315601483; Sun, 27 Nov 2016 22:46:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Sun, 27 Nov 2016 22:46:40 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 28 Nov 2016 17:46:40 +1100 Message-ID: Subject: Re: Review of draft-thomson-quic-tls-01 To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 06:46:45 -0000 Jana, Ian, Thanks for the reviews. For the biggest issue here, I've been working on getting a better overview in. It's not 100% complete, because I've run into the issue with KEY_PHASE that I was going to discuss at the meeting. You can see where I'm at here: PR: https://github.com/quicwg/base-drafts/pull/30 HTML: https://quicwg.github.io/base-drafts/tls-interface-overview/draft-iet= f-quic-tls.html I've fix the obvious issues you identified, but I've also opened a ton of issues, either because the answer isn't easy or because I'm lazy and want to defer work. See inline. Ian, I've responded to your comments as well. On 12 November 2016 at 17:02, Jana Iyengar wrote: > - Section 2: (bullet 3) Version Negotiation is a type of packet, there ar= e > no frames in it. I've killed this section; it's too much effort to maintain. > - Section 3: "Prior to the completion of the TLS handshake, QUIC frames c= an > be exchanged. However, these frames are not authenticated or confidential= ity > protected." This is not true. 0-RTT data will be sent protected before th= e > handshake is completed. Yes, this was intended to capture the 1-RTT data. I've removed the offending text, but there are probably a few other things that need correcting too. I predict that what will catch us up is that 1-RTT keys are available before the handshake completes. I don't have a good fix for that yet. > - Section 3.1: What key is the packet encrypted with? The application key= ? I > recall the plan being packets containing handshake messages to go > unencrypted, but I don=E2=80=99t remember why. Is this still the plan? If= so, are > KeyUpdate messages sent later also sent in an unencrypted packet? Why not > just use the application key for encrypting the packet at all times? Several responses are needed here: The purpose of this section is to talk about QUIC packet protection. Regarding handshake encryption: There's a trick here, and I think that I've done a better job of fixing things to make it clear, let me know if I missed the mark. TLS protects its own handshake, but QUIC doesn't. That means that handshake encryption is at the TLS layer and the QUIC packet protection sees cleartext. This is simpler because it means that QUIC has one fewer key to deal with. Regarding KeyUpdate: The design for KeyUpdate was flawed in that version of the draft. I shared a version that describes how to use the scheme that Hannes Tschofenig proposed in his DTLS 1.3 document, which I think is more robust. That scheme doesn't require any packets on stream 1 to be exchanged, just an update to the in-use keys and a flip of the KEY_PHASE bit. > - What does =E2=80=9CQUIC provides a record protection layer=E2=80=9D mea= n? This is new > terminology at the least, so the =E2=80=9Crecord protection layer=E2=80= =9D should be > defined. Yes, we've agreed that it should be packet protection. That keeps the terminology cleanly separated from TLS: TLS uses *record* protection. > - Section 4.1 says: > =E2=80=9CThe KEY_PHASE bit allows a recipient to detect a change in ke= ying > material without needing to receive the message that triggers the > change. This avoids head-of-line blocking around transitions between > keys without relying on trial decryption.=E2=80=9D > How does this avoid head-of-line blocking around transitions? What > head-of-line blocking do you have in mind here? Or do you mean to say tha= t > this bit allows handling of reordered packets correctly without relying o= n > trial-decryption? Yes, that. There are some designs where the content of a KeyUpdate message would be required in order to get the next set of keys, which would cause there to be HOL blocking, but I haven't proposed that (and don't plan to). > - Why does the server need to send anything with a 0-RTT encrypter? Doesn= =E2=80=99t > the server move immediately to 1RTT keys for sending, but keeps 0RTT-key = and > 1RTT-key decrypters? Yeah, this is corrected in the latest version. > - I like the phase changes, but I=E2=80=99m still a bit nervous. I think = (I need to > think more) that it will work out ok, but some more text here will help, > especially on why a KEY_PHASE of 0 or 1 is unambiguous on both sides, 0-R= TT > or not, and why it is not possible to end up in strange states. (I now se= e > text that follows explains this. Perhaps add a forward pointer here.) I'm still working out how to properly explain this. It's even more complicated than I've managed to convey. More on this when I get a fix to the bug with KEY_PHASE and 0-RTT (issue #27). > - =E2=80=9C0-RTT keys SHOULD be retained until the handshake is complete.= =E2=80=9D Why=E2=80=99s > this a SHOULD and not a MUST? Why is this sentence required at all? When we originally implemented 0-RTT in TLS 1.3, we stopped sending early data as soon as we saw the ServerHello. But if we lost parts of the server's first flight of handshake messages, we might have processed the ServerHello a whole round trip (or more) before the rest of the messages that follow it. That meant dead air because we stopped sending early data but we couldn't send the fully-protected data yet because we hadn't finished with the handshake. It's more complicated code now, but we wait until the first flight is done before switching to 1-RTT. This won't be an issue with the fix I have in mind for #27. > - =E2=80=9CA client would be unable to decrypt retransmissions of a serve= r's > handshake messages that are protected using the 1-RTT keys, since the > calculation of the application data keys depends on the contents of > the handshake messages.=E2=80=9D > This is a confusing sentence. Since you=E2=80=99re talking about decrypti= on of > handshake messages, why do the application data keys matter? Yeah, it's definitely convoluted. The usual rules are that endpoints retransmit frames with the latest keys. If the server follows those rules, then it will encrypt retransmissions of its handshake messages with 1-RTT keys. But the client needs those handshake messages to derive the 1-RTT keys. I've put what I think is a clearer description in the latest. > - =E2=80=9CAs shown in Figure 3 and Figure 4, there is never a situation = where > there are more than two different sets of keying material that might > be received by a peer.=E2=80=9D > With reordering, I don=E2=80=99t think this statement is true. We need ru= les using > packet numbers, such that an old packet with a key phase matching the > current expected should not cause the connection to blow up. Yeah, you can't assume that because you have acked an update, you will have completely flushed out everything from 2 generations ago. https://github.com/quicwg/base-drafts/issues/32 https://github.com/quicwg/base-drafts/issues/33 The second one is a special one just because you assumed that we'd drop a connection if decryption failed. I assume that you didn't think about it very long, but we have to get this cemented into place: if it doesn't decrypt, it didn't exist (with exceptions, because all the best rules have exceptions). > - Section 4.1.2: I should probably go read about Key Updates in TLS 1.3 > before trying to understand the details in this section. If so, a pointer > somewhere would be useful. I wouldn't bother, it's a mess in that version of the document, the draft in the repo has a bunch of changes that (I think) make it much clearer. > - Section 4.3: =E2=80=9CThe nonce, N, for the AEAD is formed by combining= either the > Client > Write IV or Server Write IV with the sequence numbers.=E2=80=9D What=E2= =80=99s the > Client/Server Write IV? The next couple of paragraphs are quite confusing= . > Why is there no Associated Data? QUIC currently uses the unencrypted pack= et > header as Associated Data. The QUIC packet does not have frames following > the packet number=E2=80=A6. it=E2=80=99s not clear what it means for P to= be the =E2=80=9CQUIC frame > following the packet number=E2=80=9D? Write IV? Most of the confusion here is due to TLS terminology leakage. I hope. I've tried to fix that up. There is no associated data because we don't need it. That's nice because the packet protection design is exactly the same as the (D)TLS record protection design, and more efficient as a result. > - I=E2=80=99m surprised to see a TLS sequence number, A straight up mistake on my part. > - Section 5: =E2=80=9CImplementations MUST NOT exchange data on any strea= m other > than > stream 1 prior to the completion of the TLS handshake.=E2=80=9D This d= oes not > work, since 0-RTT data is sent on other streams before handshake completi= on. > > - Section 5.1.2: I would like an explicit requirement on ACKs to be > encrypted at the same level or higher as the packet that the ACK > acknowledges. Is that adequate for this section? Sounds like a great idea, but it's not easy to handle 0-RTT: https://github.com/quicwg/base-drafts/issues/34 > - Section 5.1.4: =E2=80=9CNote that > the client could retransmit its Finished message to the server, so > the server cannot reject such a message.=E2=80=9D Don=E2=80=99t unders= tand this sentence. Nor do I. Deleted. > - =E2=80=9CNever assume that because it isn't in the security considerati= ons > section it doesn't affect security. Most of this document does.=E2=80= =9D Seems > unnecessary. Also, seems silly to say that =E2=80=9Cmost=E2=80=9D of this= document affects > security, since =E2=80=9Call=E2=80=9D of it does. Yeah, it's my little response to the insistence that we have security considerations in every document, even the security ones. And it *is* only most of the document. On 13 November 2016 at 13:04, Ian Swett wrote: > Now that private flags are gone, there is no encrypted portion of the QUI= C > header. That being said, it's likely worth clarifying what envelope is. Yeah, I'm going to see if I can clobber that term instead. > Section 4.1 says: "The KEY_PHASE bit on the public flags is the most > significant bit (0x80)." I would suggest we use the current diversificat= ion > nonce bit.(0x04), as it is otherwise unused in the TLS 1.3 version of QUI= C. Yeah, https://github.com/quicwg/base-drafts/issues/26 > Section 4.5 goes into Packet Number reconstruction. I don't think it's > necessary to do this here(and there is a small error), though if you want= to > state properties of packet numbers(ie: monotonically increasing on the > sender side) that seems fine if it's helpful to the mapping doc. Already gone :) > Section 5.1.4 says "The ability to shadow packets means that an attacker > does not need to be on path." I believe the attacker must be on path, > unless I'm misunderstanding something? In regards to starting at a > randomized packet number, that does provide some level of protection, and > seems wise. It also reduces the chances of ossification on the handshake > packets always starting at packet number 1. The attacker needs to know the connection ID, I guess. And that means on-path, so I guess that randomization might not help there. https://github.com/quicwg/base-drafts/issues/36 Let's track the starting sequence number here: https://github.com/quicwg/base-drafts/issues/35 > I think "In addition to denying endpoints messages, an attacker to genera= te > packets that cause no state change in a recipient." needs to be reworded, > because I'm rather confused on what it's saying. Yeah, I'm trying to get at the classic DoS vector: cause someone to do something, but have them think that they did nothing so that they don't blame you for the wasted resources. If you have a message that causes busy work, but results in no change to state, sometimes that slips through the net. I've taken another stab at this. > Can you clarify "MUST reject empty TLS handshake records and any record t= hat > is not permitted by the TLS state machine". Should these packets be > ignored, under the assumption they're attack packets? Or should the > handshake fail? Handshake failure I think. We haven't gotten that bedded down yet: https://github.com/quicwg/base-drafts/issues/37 > 5.3 is confusing to me. For example, it says "Due to reordering and loss= , > protected packets might be received by an endpoint before the final > handshake messages are received. If these can be decrypted successfully, > such packets MAY be stored and used once the handshake is complete." I > think this deserves more specificity. In cases when the packets are > encrypted with 1RTT keys, may should be stored for later decryption, but > there's no chance of them being decrypted before the SHLO wasn't received= . > I'm a bit confused about what other cases you are thinking of in the > section? Yeah, this is actually wrong. There is only one case where you receive a packet that you can decrypt, but can't use. That is when you receive a 1-RTT packet at the server, but you haven't authenticated the connection (because the client Finished was delayed). I'm not 100% confident about the text here, so I've created a PR for this one: https://github.com/quicwg/base-drafts/pull/39 > 6.4 says "Even if the source IP address remains constant, the port number= is > likely to be different." between TCP and QUIC. In typical cases, the por= t > number is new for every connection anyway, so I'm not sure this is a > relevant concern. I would just remove that sentence. The point is to highlight that source address validation isn't portable between the two protocols. I think that's still a relevant point to make. > 7: clanger, though it looks like dangers, is not the same word :) Yep :) > 7.1: I think we need to loosen "A server SHOULD use a HelloRetryRequest i= f > the size of the handshake messages it sends is likely to exceed the size = of > the ClientHello." slightly to "a small multiple of the size of the > ClientHello", or something similar, because multipacket certs are extreme= ly > common. Yeah, the right answer will need some horse trading: https://github.com/quicwg/base-drafts/issues/38 From nobody Mon Nov 28 01:22:38 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CA0129731 for ; Mon, 28 Nov 2016 01:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_SLpviPoI9A for ; Mon, 28 Nov 2016 01:22:33 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 536DC129721 for ; Mon, 28 Nov 2016 01:22:28 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id w194so70152720vkw.2 for ; Mon, 28 Nov 2016 01:22:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F/4WZnF0M8ut9bKBC37DznNJ0Iuwl+BxkjJZCzzjkGE=; b=LYXMT1lfOuAymoD6Sf/61qn6Mpl4dU7LDh0RB5UXdcjyDxJ4SV62nG1pfDq/+vXmtX 2+M2mLGVc6sRlJB42j3cWIJ7LRMS0G0Fd8sypWbuGUcc6QGTcnVNvlslCgmEXT/xglEs CwBqpWsBllfCdoD0hCtTNPaialglNsvu9RkpQCEwN1W6h6097eQVNVQrSGXbYNR525Dj KUroakroursnnkkVQSQxyeU+dTI9U7LscJhb7cQsG8nI+ItvDslLeO6qXVsMMHZ+Xczu b1pAI6mbpQU/STgGazAy8Yp/R4dRlTupcTMKorh7iz5szRAERGrcD9836pDIInNv0GU3 8U5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F/4WZnF0M8ut9bKBC37DznNJ0Iuwl+BxkjJZCzzjkGE=; b=Wjr0juHl9bGobyjAQFNoXzuTRJgsoN6K4TUMkOdMHvBEvtvIUYJrKjDvAcUIb4L28s 9XDTzENDw9rn/ifhlvoBhn0E55mNq3O+xzJ4mTx+x8WdeI1wpYmxf6RQzzDTB01g+EBh vnPg8aplhl5+ENEO1EvUHn4IEe3lxEvaOnIKZrPefPZEw1CzKQAy+bGey4hn6K8+/kVQ WCjQ3PTnU3YjskDlaSruQS/fRL9Zu/n7jWRIiEeJWcaF2SeC01SMM5xx5Vlpta6o9w2W oXSjUOg5Sl4lOd9txXbbdVfpeHgPTFc+bf0DF1HnQqth9OagsZMxET+rZ16uH/1OU+8F WapQ== X-Gm-Message-State: AKaTC02F4z3C1BVOPLoTb4XdJCN8sziZb9RZ7diXiXdNAvsVf44Z0vpLH4C90nTyl8OG+6cUsgxQGnGl/fWu7T9w X-Received: by 10.31.52.145 with SMTP id b139mr5889785vka.151.1480324947236; Mon, 28 Nov 2016 01:22:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.14.69 with HTTP; Mon, 28 Nov 2016 01:22:26 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Jana Iyengar Date: Mon, 28 Nov 2016 01:22:26 -0800 Message-ID: Subject: Re: Public reset PR To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114348b6a254690542590235 Archived-At: Cc: Jim Roskind , IETF QUIC WG , Christian Huitema , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 09:22:36 -0000 --001a114348b6a254690542590235 Content-Type: text/plain; charset=UTF-8 (Just catching up on this thread after my vacation.) I really liked ekr's proposal for a completely private reset packet, until Christian pointed out the hole in it. It seems clear now that you cannot construct a (private) reset packet at a server when the server has no state about the connection. Given that, the best solution at this point seems to be the originally proposed one, where the client is the only one that can tell that the reset is authentic. Since the design leaves us with the possibility of spoofable packets that could still confuse intermediaries, I like Christian's suggestion of recommending a soft response of using a reduced timeout on a reset packet (say, 5 seconds.) As has been noted earlier, we do lose the ability to generate reset packets when the connection ID is not present in the received packet, but that seems reasonable since connection ID length is negotiated. If a peer wants to be able to generate a reset packet, it SHOULD negotiate a full-length connection ID on packets being sent to it. Intermediary-generated reset packets are quite a different beast and should be discussed separately, I think. - jana On Mon, Nov 28, 2016 at 3:25 PM, Eric Rescorla wrote: > > > On Mon, Nov 28, 2016 at 1:10 AM, Martin Duke > wrote: > >> >>>> I guess I'm a little unclear as to the conditions of "the high entropy >>>> secret value R". Perhaps you could confirm the order of operations, which I >>>> construe as follows: >>>> >>>> 1) Endpoint computes a random secret for all connections for some >>>> period of time, and stores this somewhere that will survive reboots. >>>> 2) For a new connection, the endpoint performs some operation with the >>>> secret and the connection ID and includes the result R in an encrypted >>>> handshake message. >>>> 3) Endpoint reboots. >>>> 4) When the peer sends another packet, the endpoint uses the connection >>>> ID and its secret to figure R and make it the first 16 bytes of the cipher >>>> text. >>>> 5) Peer has the original connection state and can correctly interpret >>>> the reset. >>>> >>>> Is that accurate? >>>> >>> >>> Yes. >>> >>> -Ekr >>> >> >> >> Alright, I think this is a good start but I have some concerns: >> >> 1) The scheme's security is dependent on truly random connection IDs, >> because otherwise I can probe servers with garbage packets and certain >> likely connection IDs and obtain the corresponding R values. In particular, >> the current Chromium stateless reject model uses a server-recommended >> connection ID for the next connection, so a eavesdropper could in theory >> attack these connections. I have no idea if that "feature" will survive to >> the final spec. >> > > Good point. This requires the server to dictate at least part of the > connection ID and that it not be repeated. I think I'd just forgotten that > that was an undecided issue. > It does not require that it be random, however. > > > 2) Someone raised the load balancer question earlier but I don't think it >> ever got a satisfactory reply. There are many load balancer architectures, >> but a common one assigns connections to servers based on some strategy >> which is not necessarily a hash of the 4-tuple or 5-tuple. >> >> This sets up pretty simple scenarios for failure: the server behind the >> load balancer aborts the connection, which erases the state at the load >> balancer, but the public reset is lost in the network. The next client >> packet is assigned to a different server, which has a different secret and >> cannot send a valid reset. >> > > The assumption here is that all the devices behind the load balancer share > a seed for generating the reset secret. > > -Ekr > > >> All that said, I don't have an alternative proposal that is not expensive >> (e.g. signing with the private key). >> >> Martin >> >>> >>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema < >>>>>>>>> huitema@huitema.net> wrote: >>>>>>>>> >>>>>>>>>> On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: >>>>>>>>>> >>>>>>>>>> > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema >>>>>>>>> huitema@huitema.net> wrote: >>>>>>>>>> >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: >>>>>>>>>> >>> >>>>>>>>>> >>> ... (discussion of security properties and alternative >>>>>>>>>> design)... >>>>>>>>>> >> >>>>>>>>>> >>> Note that it might still independently be a good idea to >>>>>>>>>> allow middleboxes to see the >>>>>>>>>> >>> public reset, but I think that this demonstrates that that's >>>>>>>>>> a policy choice about the >>>>>>>>>> >>> design of the protocol, not something mandated by limitations >>>>>>>>>> in what we can design. >>>>>>>>>> > >>>>>>>>>> >> On limit of the pre-image design is that intermediaries cannot >>>>>>>>>> do the verification. Well, >>>>>>>>>> >> they could if the option was sent in clear text, and if they >>>>>>>>>> parsed the corresponding packet. >>>>>>>>>> > >>>>>>>>>> > Yes, that's correct; it's the assumption of this design that >>>>>>>>>> the would do so. If you think that >>>>>>>>>> > they won't then there are much simpler designs (like the one in >>>>>>>>>> the message you are >>>>>>>>>> > responding to). >>>>>>>>>> >>>>>>>>>> Do we really want to ask intermediaries to go parse options >>>>>>>>>> inside the TLS handshake inside stream 1? That does not strike me as too >>>>>>>>>> desirable. I am concerned of the potential there for ossification. I have >>>>>>>>>> visions of delaying the move to TLS 4.1 a couple years from now because >>>>>>>>>> intermediaries really expect TLS 1.3. >>>>>>>>>> >>>>>>>>>> Then, there is the potential for spoofing. If the verifier text >>>>>>>>>> is sent in clear text, it can be spoofed. What if the man on the side sends >>>>>>>>>> a new Server Hello, with a verifier option of its own choosing? OK, I >>>>>>>>>> suppose that if the spoofed packet wins the race with the authentic Server >>>>>>>>>> Hello, the client will just fail the connection. The spoofed Server Hello >>>>>>>>>> becomes the new weapon of the censors... But even if the spoofed packet >>>>>>>>>> does not win the race, how many intermediaries would just be fooled and >>>>>>>>>> accept the new verifier, and of course the spoofed public reset that >>>>>>>>>> follows? >>>>>>>>>> >>>>>>>>> >>>>>>>>> Hmm... I would ordinarily expect that clients would respond to a >>>>>>>>> bogus CH (e.g., one that's malformed or that >>>>>>>>> doesn't cryptographically verify) by hanging up the connection, so >>>>>>>>> I'm not sure that this would make the situation >>>>>>>>> that much worse. >>>>>>>>> >>>>>>>>> >>>>>>>>> I like the simpler design in which only the client can tell >>>>>>>>>> whether the public reset is authentic. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Well, there are actually two designs: >>>>>>>>> >>>>>>>>> 1. The middlebox can see the public reset but not verify it >>>>>>>>> 2. The middlebox cannot distinguish the public reset from other >>>>>>>>> packets. >>>>>>>>> >>>>>>>>> I am concerned about #1 for the reasons indicated previously and I >>>>>>>>> originally did not see how to do #2 >>>>>>>>> without fairly significant client-side complexity. Now that I do, >>>>>>>>> it does seem like it's probably the leading >>>>>>>>> option absent some convincing policy argument that middleboxes >>>>>>>>> should be able to see these packets. >>>>>>>>> >>>>>>>>> -Ekr >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- Christian Huitema >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --001a114348b6a254690542590235 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Just catching up on this thread after my vacation.)
<= br>
I really liked ekr's proposal for a completely private re= set packet, until Christian pointed out the hole in it. It seems clear now = that you cannot construct a (private) reset packet at a server when the ser= ver has no state about the connection.

Given that,= the best solution at this point seems to be the originally proposed one, w= here the client is the only one that can tell that the reset is authentic. = Since the design leaves us with the possibility of spoofable packets that c= ould still confuse intermediaries, I like Christian's suggestion of rec= ommending a soft response of using a reduced timeout on a reset packet (say= , 5 seconds.)

As has been noted earlier, we do los= e the ability to generate reset packets when the connection ID is not prese= nt in the received packet, but that seems reasonable since connection ID le= ngth is negotiated. If a peer wants to be able to generate a reset packet, = it SHOULD negotiate a full-length connection ID on packets being sent to it= .

Intermediary-generated reset packets are quite a= different beast and should be discussed separately, I think.
- jana

On Mon, Nov 28, 2016 at 3:25 PM, Eric Rescorla <ekr@rtfm.com&g= t; wrote:


On = Mon, Nov 28, 2016 at 1:10 AM, Martin Duke <martin.h.duke@gmail.com> wrote:

I guess I'm a little unclear as to the conditions of "the=C2=A0<= span style=3D"font-size:12.8px">high entropy secret value R". Perhaps = you could confirm the order of operations, which I construe as follows:

1) Endpoint computes a random secret for all con= nections for some period of time, and stores this somewhere that will survi= ve reboots.
2) For a new = connection, the endpoint performs some operation with the secret and the co= nnection ID and includes the result R in an encrypted handshake message.
3) Endpoint reboots.=
4) When the peer sends another = packet, the endpoint uses the connection ID and its secret to figure R and = make it the first 16 bytes of the cipher text.
5) Peer has the original connection state and can cor= rectly interpret the reset.

Is that accurate?

Yes.

-Ekr


Alrigh= t, I think this is a good start but I have some concerns:

1) The scheme's security is dependent on truly random connectio= n IDs, because otherwise I can probe servers with garbage packets and certa= in likely connection IDs and obtain the corresponding R values. In particul= ar, the current Chromium stateless reject model uses a server-recommended c= onnection ID for the next connection, so a eavesdropper could in theory att= ack these connections. I have no idea if that "feature" will surv= ive to the final spec.

<= /span>
Good point. This requires the server to dictate at least part of= the connection ID and that it not be repeated. I think I'd just forgot= ten that that was an undecided issue.
It does not require that it= be random, however.


2) Someone raised the load balancer question = earlier but I don't think it ever got a satisfactory reply. There are m= any load balancer architectures, but a common one assigns connections to se= rvers based on some strategy which is not necessarily a hash of the 4-tuple= or 5-tuple.

This sets up pretty simple scenarios = for failure: the server behind the load balancer aborts the connection, whi= ch erases the state at the load balancer, but the public reset is lost in t= he network. The next client packet is assigned to a different server, which= has a different secret and cannot send a valid reset.




Martin
=C2=A0
=C2=A0

=




=C2=A0
=
On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla= <ek= r@rtfm.com> wrote:


On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema <= span dir=3D"ltr"><huitema@huitema.net> wrote:
On Saturday, November 26, 2016 3:58 PM, Eric Rescorl= a wrote:

> On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema <mailto:huitema@huitema.net&g= t; wrote:
>> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote:
>>>
>>> ... (discussion of security properties and alternative design)= ...
>>
>>> Note that it might still independently be a good idea to allow= middleboxes to see the
>>> public reset, but I think that this demonstrates that that'= ;s a policy choice about the
>>> design of the protocol, not something mandated by limitations = in what we can design.
>
>> On limit of the pre-image design is that intermediaries cannot do = the verification. Well,
>> they could if the option was sent in clear text, and if they parse= d the corresponding packet.
>
> Yes, that's correct; it's the assumption of this design that t= he would do so. If you think that
> they won't then there are much simpler designs (like the one in th= e message you are
> responding to).

Do we really want to ask intermediaries to go parse options inside t= he TLS handshake inside stream 1? That does not strike me as too desirable.= I am concerned of the potential there for ossification. I have visions of = delaying the move to TLS 4.1 a couple years from now because intermediaries= really expect TLS 1.3.

Then, there is the potential for spoofing. If the verifier text is sent in = clear text, it can be spoofed. What if the man on the side sends a new Serv= er Hello, with a verifier option of its own choosing? OK, I suppose that if= the spoofed packet wins the race with the authentic Server Hello, the clie= nt will just fail the connection. The spoofed Server Hello becomes the new = weapon of the censors... But even if the spoofed packet does not win the ra= ce, how many intermediaries would just be fooled and accept the new verifie= r, and of course the spoofed public reset that follows?

Hmm... I would ordinarily expect that clients would= respond to a bogus CH (e.g., one that's malformed or that
do= esn't cryptographically verify) by hanging up the connection, so I'= m not sure that this would make the situation
that much worse.


I like the simpler design in which only the client can tell whether the pub= lic reset is authentic.

Well, th= ere are actually two designs:

1. The middlebox can= see the public reset but not verify it
2. The middlebox cannot d= istinguish the public reset from other packets.

I = am concerned about #1 for the reasons indicated previously and I originally= did not see how to do #2
without fairly significant client-side = complexity. Now that I do, it does seem like it's probably the leading<= /div>
option absent some convincing policy argument that middleboxes sh= ould be able to see these packets.

-Ekr
= =C2=A0

-- Christian Huitema













--001a114348b6a254690542590235-- From nobody Mon Nov 28 01:41:05 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4E9129857 for ; Mon, 28 Nov 2016 01:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dXqTq2t6u5M4 for ; Mon, 28 Nov 2016 01:41:02 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0FE4512984B for ; Mon, 28 Nov 2016 01:41:02 -0800 (PST) Received: from [10.0.27.103] (dynamic-94-247-222-033.catv.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 3FF121A0046; Mon, 28 Nov 2016 10:41:00 +0100 (CET) Subject: Re: Public reset PR Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_102CFC53-78D0-44E8-804A-828790C77CDA"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <10b901d248f6$4df37040$e9da50c0$@huitema.net> Date: Mon, 28 Nov 2016 10:40:59 +0100 Message-Id: <27D11334-E39F-4750-8A6B-9D6E446182CB@trammell.ch> References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> <10b901d248f6$4df37040$e9da50c0$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jim Roskind , Eric Rescorla , Kyle Rose , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 09:41:04 -0000 --Apple-Mail=_102CFC53-78D0-44E8-804A-828790C77CDA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 27 Nov 2016, at 22:36, Christian Huitema = wrote: >=20 > On Sunday, November 27, 2016 5:20 AM, Kyle Rose wrote: >=20 >> The problem with #2 (and related proposals to hide all connection = state from path >> elements) is that it will encourage middleboxes to continue dropping = all UDP state >> with a short timeout, requiring frequent keepalives that (e.g.) = consume battery in >> mobile devices. >=20 > This is the SPUD/PLUS argument. But then, there is a long history of = protocols designed with high hopes of cooperation with middle boxes, = without an actual result. The difference here is that, unlike the litany of proposals in this = "long history", the path-verifiable reset proposal (as in PR #20 and = EKR's mail of 22:37 UTC on 23 Nov) is a design that interacts with very = widely deployed behaviors: a verifiable endpoint-initiated connection = termination provides equivalent assurance to an in-window FIN or RST in = TCP that a connection is actually going away (depending on how many bits = of the verifier are exposed), to move a NAT binding or firewall pinhole = from "long-timeout" to "short-timeout" state. This involves firewall and NAT vendors updating their boxes to use this = new signal to drive behaviors already deployed, not to enable the = deployment of entirely new behaviors. I suspect that a world with a = quarter of the Web's traffic running over QUIC, not at all an = unrealistic near-term scenario, would provide an incentive to update = these devices. The main win for the endpoints here is, as Kyle and the = -statefulness draft note, reducing the need over time for unproductive = keepalive traffic or state-reestablishment logic. The main win for = middlebox vendors is that their devices work better with QUIC. > So at a minimum we have to ensure that whatever solution is proposed = does not introduce new attacks, or undue complexity. The proposal (in the PR) is IMO not unduly complex. The most interesting attacks here are, as you noted, man-on-the-side = attacks. Using 128 bits for the verifier and proof values make these = impractical, though future versions will have to use more bits to defend = against potential precomputation. Cheers, Brian --Apple-Mail=_102CFC53-78D0-44E8-804A-828790C77CDA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYO/urAAoJEIoSt78L6kajvTgP/RMavQyoYfmhM8VdMf3jEXiw u5g3UPlO0taFGYDhmVQ7GZ2nbZdGJNNdW8gso1p7N4URaHcYBmFsnL7ck5YzYXUT rorjGBdmlCA46w1Nz124+xYbVMEeX8LlUDg4t0BhxpE04gpIcicDOJV2HAWAwxv8 aeA3GLFgAqcDU+O2qQfq5P2C9+Xk8VB+dGshQxR3caVf5HpN04NX639hTw5Vuk3Z /kqiZm9Q/te1vx8jkYE7H2LXmjaQw7S0ojA4JTO5esEWYfK6/lxgb7O22CfRA32T +TZDzxwcKhAOFiIf82nRzLj9xuFI08n27F0MZ5LOBdHGMUWecu0NhFTzHnu3Z6bC EFJNzHV/tbkEOXYcsxnSobFi+t+nGXJ9QJWwjz4Ba56IrLrpI5/vfyrwTpqLFlRs o17bXRxy+v1nI/0HoaB23t2V4WZV4c9sYBCzRG4C5TqYrBDlSrNY5iJ6ztMNExg9 RuWjW2UhpFfZUx1GqoMgI1aUg33mPHr1F6UOodR6rmCwK1Xe0F+RGYncsP2fpFmo STiBMKqyIoEztUVY9rfqT/03VprTK12K4wHtqqq+MP/BHdM4jYFDa/XONZsJKi/x aGEKT25JlDe4U8qlsaa1EYt1WDgx871SQq9F9ZpXnnVp/EDhgLQK6xFUHG+zN1ej Eo9fRUQg6ZTFV3I3SaD0 =TIoN -----END PGP SIGNATURE----- --Apple-Mail=_102CFC53-78D0-44E8-804A-828790C77CDA-- From nobody Mon Nov 28 01:47:49 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B621297BD for ; Mon, 28 Nov 2016 01:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.127 X-Spam-Level: X-Spam-Status: No, score=-2.127 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, URG_BIZ=0.573] 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 wYzSs_KCLRes for ; Mon, 28 Nov 2016 01:47:47 -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 B86D112946C for ; Mon, 28 Nov 2016 01:47:47 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n204so133886158qke.2 for ; Mon, 28 Nov 2016 01:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zMWSd7SsrjoLhWZUvavigGUsvWIP6qXC202g2R/yGVw=; b=GJIvRTzNJQTR+PuT0huTvvm8ArLr95ejGmnwH0KzxQVHyYdPe91v1uBXdmRkm/DBri 6heGGdIpkq0jqB7zdmHwpoSB0QxBK0o86G6tqIaWFbffxltJua8B22FrZ9haobuC3N/A 4o05uOb4KxPRQg14QG2ANLTE6Ibm+wtgCuJ3vaqhRupWN1PIOwVzXo62DodUefWFSY+4 g80V4MaaE1xIwnKohnyKTGdSa1mrl03M9ytgb4JubIJ8KjKv6RyXV7qFYsQ53m7dyKC5 ejzOmfMx8MKzq8Zr+WiNXcmt8+1v2ePNd7ebZE8PLqu19Tgmat3Ik0Ir7eTk2c3lQLfa 4UNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zMWSd7SsrjoLhWZUvavigGUsvWIP6qXC202g2R/yGVw=; b=R7viaOisBUSbRCPxIpU/8la7PDdLuBB0s26TLby6MfrGrI021uUumRbX3M40nJ2Cmw sOOL4UZyRAFa9M/7M9dT0evCRhrvD5lmCyiyJGJgA2FWtNBCXmIR8tvN+ih4XCJKRye4 c/Q33ixmDAau01FRoJ59RRqnP+WweyU+48vbakmUekVRJcwiOmmPueFjsNnBm42Dw6Jd eIAHennCd3iJqRlz8afd+aseJ3lePXZE8ISlY1Stpr2c9P8dX2GKs3SX1TYm40Ofsgnp K1mE4XFqNrew5hBUw7smoRFlw3jsT/vdY9b992fC3DDup12k2hk2jHPbBUhBjVZV08en bqrw== X-Gm-Message-State: AKaTC01tvsCB1jrgFmERk53cUkroH4+pbZrW7Q6PArbiBU8pDBXJUP6KnvyDqGRg8rEAeT/uPy42ftT+6pM2CA== X-Received: by 10.55.184.68 with SMTP id i65mr18966548qkf.5.1480326466914; Mon, 28 Nov 2016 01:47:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Mon, 28 Nov 2016 01:47:45 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Martin Thomson Date: Mon, 28 Nov 2016 20:47:45 +1100 Message-ID: Subject: Re: Public reset PR To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jim Roskind , Eric Rescorla , IETF QUIC WG , Christian Huitema , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 09:47:49 -0000 On 28 November 2016 at 20:22, Jana Iyengar wrote: > Given that, the best solution at this point seems to be the originally > proposed one, where the client is the only one that can tell that the reset > is authentic. Since the design leaves us with the possibility of spoofable > packets that could still confuse intermediaries, I like Christian's > suggestion of recommending a soft response of using a reduced timeout on a > reset packet (say, 5 seconds.) The downside there being that a spoofed reset will demand a (semi-)urgent response if the endpoint wants to avoid the intermediary timer from being reset. That is, assuming that we don't go with a design that can be verified by the intermediary. I think that the ekr's design allows for an unspoofable reset without the need to transition to short timer state if we accept that the intermediary can validate the reset as well. Sure, we can't hide it (thanks Christian), but all we need is for the reset commitment to be in the clear and an intermediary can choose to remember the value. On 28 November 2016 at 20:40, Brian Trammell wrote: > future versions will have to use more bits to defend against potential precomputation. I am not aware of any method of precomputation, short of a complete rainbow table, for hash preimages. From nobody Mon Nov 28 01:59:44 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972EA1299DD for ; Mon, 28 Nov 2016 01:59:42 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8fsJ-0gAdPe for ; Mon, 28 Nov 2016 01:59:40 -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 4306D129961 for ; Mon, 28 Nov 2016 01:57:19 -0800 (PST) X-AuditID: c1b4fb3a-d644398000007918-0e-583bff7dd783 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id AE.E7.31000.D7FFB385; Mon, 28 Nov 2016 10:57:17 +0100 (CET) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.66) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 28 Nov 2016 10:57:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=v4ypYgaFFx3OUZF+Fh/XBifTOj8eiO0wqRuyWdbXrcI=; b=gsQZ4JZSQ+ZQkBHIk8X7n+UDQsuNPRWePg9NZ2aXfSgOaJGzsQzIfmG+njoFqoaHslZkHRrm4Z47qpS1D9M9rqJczyyHUrrDdo0tZ7RUUn0ktMnwjqXklFace7g7onGNd3bSMDuJw72HB5c8qIPvZGKkNTBJNvIlcl+n1wvpPGI= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.5; Mon, 28 Nov 2016 09:57:09 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0747.015; Mon, 28 Nov 2016 09:57:09 +0000 From: Ingemar Johansson S To: "quic@ietf.org" Subject: Comments on draft-iyengar-quic-loss-recovery-01 Thread-Topic: Comments on draft-iyengar-quic-loss-recovery-01 Thread-Index: AdJJWlB6ZodzUmbpQLKyjZZC12MFDQ== Date: Mon, 28 Nov 2016 09:57:09 +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.89] x-ms-office365-filtering-correlation-id: ccbd02f8-f6c6-4c85-e85f-08d41774eb6e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB348; x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:r+YFuFeuQwV5b5LNqUrIljtfN0FMCoFVfDx6yc2/aUkf1Rbku33golVQgv24HtvAaGi6pWxiX8uGybndF1CRecYd+3MwZRf8FycZdkvrn3fBIsmSd/1jZ20qNnaYyaGArIDSBSM2N0LsLJOrWGmJuzjN6bs+eB5AIo/p+2OjdPrPOyG+VAI7Iz+9RW28T+rtbVJCC7ROj+KxpRotPn0Sp7jR2C0mh2yLHXzpVN4swDXi1W2KGpHNIsH5bxxxmrhJ89dYUWhDFbb/j3JTM/GY929mY3BD8eunsqe+LXXTnbFjV8iFOVfDH+RaCF9gGNDndyaP10jHX3bJi9dLMyZgdem+QgzZ5FRZ7NlVImfkRZ0kO5MHHTxTjCgkR4qjMY8W1PDU8JRtnguPYquVHlPI1oTumN20o1kWV7GMktLYS8iMbK7+mkG2aynYS/KMUaTw/0jdsboK64GuSIhXdWz6Qg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6045199)(6060326)(6040361)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(6061324)(20161123560025)(20161123555025)(20161123564025)(20161123562025); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 01401330D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(54094003)(199003)(189002)(8676002)(97736004)(4326007)(2501003)(66066001)(2906002)(81166006)(7846002)(68736007)(106356001)(1730700003)(9686002)(81156014)(76576001)(5660300001)(54356999)(7696004)(86362001)(50986999)(101416001)(6916009)(105586002)(8936002)(3280700002)(790700001)(33656002)(38730400001)(92566002)(110136003)(189998001)(9326002)(5630700001)(39400400001)(77096006)(39380400001)(3660700001)(5640700001)(2900100001)(102836003)(7736002)(39410400001)(122556002)(230783001)(3846002)(6116002)(19609705001)(2351001)(6506003)(606004)(39450400002)(74316002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3485AAD3F0072071176C6E6C28A0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2016 09:57:09.7820 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsUyM2K7k27tf+sIg+vdWhY/7+1ktZh0dCGL Rc8CbgdmjwWbSj2WLPnJFMAUxWWTkpqTWZZapG+XwJWx5chOxoIP/hXz2w0bGD+5dTFyckgI mEgsu7iZtYuRi0NIYB2jxLfHv5ghnBOMEpM7voBlWAR6mSUmnrzLBpGZyiSxdeFOJgjnGKNE /7EGFpBhbAI2EisPfWcEsUUElCXmLF3MDmIzC4RLrPx4GWgUB4ewgIXE8sUsECW2Eneb9zFD 2HoS/55sZQWxWQRUJW70NYK18gpESczrWQs2klFAVuL+93ssECPFJW49mc8E8YOAxJI955kh bFGJl4//sULUJ0t8utnLChFXkDi+4i0bhO0rsfLddxYI20fifcsKsMckBLpZJO7teANVlCnR cOcd1IJoiSnHuqDis5gkbu7ShrBlJG6vuc8K0fyRVaJr5UKwK4QEUiWWr20Fu1pYQEri7pVO KFtG4sWdvawQH+RLHG17xTiBUX0WkodmIUnNAgeAoMTJmU9YIOJ6EjemTmGDsLUlli18zQxh 60rM+HeIBVl8ASP7KkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAJHRwy2+rHYwHnzseYhTg YFTi4f3wxSpCiDWxrLgy9xCjBAezkgiv2T/rCCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8Zivv hwsJpCeWpGanphakFsFkmTg4pRoYe0t8Ct5dvR0bEhV3u+1MTHUk2wlmuYqfcvXZ4v8iRev4 F8oZ6Wm2ukecvXU3zT285VxD0JOUid68LR/3FaZUrrZ5GvTvcvLZZ+eXPNhXI5bxxXm7muaD tkK/Ayt6dO6oW8b8XndtXXz04pnMHq0qK0NTpV/P+mc1s/nPE581hkllcwqYX7krsRRnJBpq MRcVJwIAAgRpDT4DAAA= Archived-At: Cc: "Jana Iyengar \(jri@google.com\)" , Ian Swett X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 09:59:42 -0000 --_000_DB4PR07MB3485AAD3F0072071176C6E6C28A0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Thanks for submitting this draft, understand that this is early work but ne= vertheless, a few comments. Being an ECN geek, I wonder if ECN should be covered in this document. Ther= e is a fair amount of activites in this area so one follow up question is t= o what extent new work should be included (Alternate backoff, L4S...) The dependency on retransmittable packets confuses me, consider that QUIC = is modified for unreliable transmission mode, I would still guess that succ= essful reception of packets belonging to an unrealiable stream will still b= e ACKed to the sender, to keep the transmission and congestion control in h= ealthy condition. Lost packets detection: I was earlier under the impression that loss detect= ion in QUIC is time based (RACK). The document however makes me believe tha= t it is based on a reordering_threshold counted in packets. I guess I misun= derstood things here ? Section 2.1.2 No Reneging.. Despite having tried delve into the inner secrets of SACK and digging into = the Linux TCP stack I still cannot say that I really understand reneging an= d the implications of it. Is there a good source that explains this in more= detail ?. If so then first of all I am interested to read it and secondly = it could be good to reference. Section 3.1 "reordering_threshold" : It is here unclear if the unit is time or packets.= Given the rest of the text I assume that the unit is packets ?. /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 AB Wireless Access Networks Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com No, you can=B4t tell people anything You've got to show 'em 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_DB4PR07MB3485AAD3F0072071176C6E6C28A0DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Thanks for submitting this draft, understand that th= is is early work but nevertheless, a few comments.

 

Being an ECN geek, I wonder if ECN should be covered= in this document. There is a fair amount of activites in this area so one = follow up question is to what extent new work should be included (Alternate= backoff, L4S…)

 

The dependency on retransmittable packets  conf= uses me, consider that QUIC is modified for unreliable transmission mode, I= would still guess that successful reception of packets belonging to an unr= ealiable stream will still be ACKed to the sender, to keep the transmission and congestion control in healthy con= dition.

 

Lost packets detection: I was earlier under the impr= ession that loss detection in QUIC is time based (RACK). The document howev= er makes me believe that it is based on a reordering_threshold counted in p= ackets. I guess I misunderstood things here ?

 

Section 2.1.2 No Reneging..

Despite having tried delve into the inner secrets of= SACK and digging into the Linux TCP stack I still cannot say that I really= understand reneging and the implications of it. Is there a good source tha= t explains this in more detail ?. If so then first of all I am interested to read it and secondly it could &= nbsp;be good to reference.

 

Section 3.1

“reordering_threshold” : It is here uncl= ear if the unit is time or packets. Given the rest of the text I assume tha= t the unit is packets ?.

 

/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 AB<= /span>

Wireless Access Network= s

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

 =     No, you can=B4t tell people anything

 =         You’ve got to show ‘= em

 =              Br= uce 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_DB4PR07MB3485AAD3F0072071176C6E6C28A0DB4PR07MB348eurprd_-- From nobody Mon Nov 28 08:09:25 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8167912954A for ; Mon, 28 Nov 2016 08:09:24 -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 (1024-bit key) header.d=krose.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 t0IMjV_P1rlS for ; Mon, 28 Nov 2016 08:09:17 -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 48C641294D0 for ; Mon, 28 Nov 2016 08:09:16 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id w33so126434105qtc.3 for ; Mon, 28 Nov 2016 08:09:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HFdD7GGd71B+FlNtIG0Vt5WFKBmu967byxgXxiigB8U=; b=CgzmlOyZuEyXemJLlwfZET6pPE+ZX7WOs1xayLf4P5VRz27wDhtqB+kHnC99fZtV0R IJp8HvKRmfyR5Jwesw0odPLEobYnKPzEY8WjLtZavVObMggJZgygnKuHDeTK//W3pcEw TTwmSNeYusTl+EeiYVnhzoZAAgBlz2pvEZdWg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HFdD7GGd71B+FlNtIG0Vt5WFKBmu967byxgXxiigB8U=; b=GJVOhC3+HLE+7VA6GkDhoF+pgFpqSc2cCRc6RRy07BmmVNcpdJqMllIFt6QVh/K7mK H99fr9CnxUPi11wKfhMBTdC85hnDvs5y+zLHpQiBQ4UbIYi7/vDKaADEf++1+zN5pJ9e t+mLtrhNc5olc+dAH4iSbLvLo0jTfxGvKb0b9mM7I3gqyXfzFyX12qcTAXmcCMY97a8Q jpxSVLSJv8ic6ifmu0uHP75JufTn64O3+CTDEIMR8XE/hEdk1AAxbeCXu66C6xFvKkkx vef5T792i4XkVGHVYHVEczQ4BuDozq5Zu2Or9rS2LCdnl1tMR4p58F9imp7TkGD8UnUo OIyA== X-Gm-Message-State: AKaTC02Uay19G41l5lgbTY8mYFis5dhZqiiAeVl69533kcQbXTpuSpKjwG31/aMa7d13wS8/3qljfHx10ZRMlw== X-Received: by 10.200.57.71 with SMTP id t7mr21302104qtb.59.1480349355235; Mon, 28 Nov 2016 08:09:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.180.2 with HTTP; Mon, 28 Nov 2016 08:09:14 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Kyle Rose Date: Mon, 28 Nov 2016 11:09:14 -0500 Message-ID: Subject: Re: Public reset PR To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113eddc276906f05425eb1a4 Archived-At: Cc: Eric Rescorla , Christian Huitema , Jim Roskind , Jana Iyengar , IETF QUIC WG , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 16:09:24 -0000 --001a113eddc276906f05425eb1a4 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 28, 2016 at 4:47 AM, Martin Thomson wrote: > > I think that the ekr's design allows for an unspoofable reset without > the need to transition to short timer state if we accept that the > intermediary can validate the reset as well. Sure, we can't hide it > (thanks Christian), but all we need is for the reset commitment to be > in the clear and an intermediary can choose to remember the value. That's a lot of additional state to remember (128+ bits), and (if we're talking about the public reset including the verifier preimage) a lot of computation for boxes that normally just track NAT bindings and forward packets to perform under an attack scenario. It seems unlikely middlebox vendors are going to bother with the complexity or want to expose the additional attack surface of CPU usage: they'll just keep the timeout short all the time, which leaves us with the status quo around keepalives. It seems like the burden should be on the endpoint being attacked to mitigate the impact of public reset attacks, which the "no, I'm actually still here" response does. Combined with BCP 38, actual off-path spoofed public resets should be manageable; man-on-the-side results in increased traffic in responses (potentially mitigated by an indication by the endpoint of how long public resets should be ignored for that flow) instead of increased CPU usage in verifying public reset packets at every middlebox along the path; and on-path continues to be subject to every problem on-path attackers can cause. Kyle --001a113eddc276906f05425eb1a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 28, 2016 at 4:47 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:

I think that the ekr's design allows for an unspoofable reset without the need to transition to short timer state if we accept that the
intermediary can validate the reset as well.=C2=A0 Sure, we can't hide = it
(thanks Christian), but all we need is for the reset commitment to be
in the clear and an intermediary can choose to remember the value.

That's a lot of additional state to remember (1= 28+ bits), and (if we're talking about the public reset including the v= erifier preimage) a lot of computation for boxes that normally just track N= AT bindings and forward packets to perform under an attack scenario. It see= ms unlikely middlebox vendors are going to bother with the complexity or wa= nt to expose the additional attack surface of CPU usage: they'll just k= eep the timeout short all the time, which leaves us with the status quo aro= und keepalives.

It seems like the burden should be on the endpoint b= eing attacked to mitigate the impact of public reset attacks, which the &qu= ot;no, I'm actually still here" response does. Combined with BCP 3= 8, actual off-path spoofed public resets should be manageable; man-on-the-s= ide results in increased traffic in responses (potentially mitigated by an = indication by the endpoint of how long public resets should be ignored for = that flow) instead of increased CPU usage in verifying public reset packets= at every middlebox along the path; and on-path continues to be subject to = every problem on-path attackers can cause.

Kyle
=
--001a113eddc276906f05425eb1a4-- From nobody Mon Nov 28 12:31:21 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B612E129424 for ; Mon, 28 Nov 2016 12:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 vTurohOjtrsJ for ; Mon, 28 Nov 2016 12:31:17 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id BD68C127077 for ; Mon, 28 Nov 2016 12:31:17 -0800 (PST) Received: (qmail 4341 invoked by uid 0); 28 Nov 2016 20:31:10 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy6.mail.unifiedlayer.com with SMTP; 28 Nov 2016 20:31:10 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id DYX41u00Z2UhLwi01YX7RA; Mon, 28 Nov 2016 13:31:08 -0700 X-Authority-Analysis: v=2.1 cv=YNIMl32x c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=L24OOQBejmoA:10 a=1XWaLZrsAAAA:8 a=PYnjg3YJAAAA:8 a=ucoHQQzKJ1yaWohnVp8A:9 a=QEXdDO2ut3YA:10 a=w2FDxLsVxOQA:10 a=nJcEw6yWrPvoIXZ49MH8:22 a=96-UuAdfYG6OSYlHWuPe:22 Received: from c-73-202-80-238.hsd1.ca.comcast.net ([73.202.80.238]:63430 helo=[192.168.11.53]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1cBSZt-0007qo-SP for quic@ietf.org; Mon, 28 Nov 2016 13:31:05 -0700 From: =JeffH Subject: fyi: Analyzing and Fixing the QACCE Security of QUIC To: IETF QUIC WG Message-ID: <2455282f-5ea9-273a-b087-6c70e0bac5d4@KingsMountain.com> Date: Mon, 28 Nov 2016 12:31:05 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 73.202.80.238 X-Exim-ID: 1cBSZt-0007qo-SP X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: c-73-202-80-238.hsd1.ca.comcast.net ([192.168.11.53]) [73.202.80.238]:63430 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 28 Nov 2016 20:31:19 -0000 of possible interest, tho this paper seems to be more about the QACCE security model of QUIC than QUIC itself (YMMV)... Analyzing and Fixing the QACCE Security of QUIC Sakurada, Yoneyama, Hanatani, Yosihda Abstract: ... Lychev et al proposed a security model (QACCE model) to capture the security of QUIC. However, the QACCE model is very complicated, and it is not lcear if security requirements for QUIC are appropriately defined. In this paper, we show the first formal analysis result of QUIC using automated security verifiction tool ProVerif. Our symbolic model formalizes the QACCE model and the specification of QUIC. As a result of the verification, we find three attacks against QUIC in the QACCE model. ... we give a way to improve the QACCE model to exactly address the appropriate security requirements. see also.. http://csrc.nist.gov/groups/ST/ssr2016/accepted-papers.html From nobody Mon Nov 28 16:07:54 2016 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 B27DD12A195; Mon, 28 Nov 2016 16:07:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-transport-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148037806972.5530.13950006542574869115.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2016 16:07:49 -0800 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-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, 29 Nov 2016 00:07:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : QUIC: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-00.txt Pages : 45 Date : 2016-11-28 Abstract: QUIC is a multiplexed and secure transport protocol that runs on top of UDP. QUIC builds on past transport experience, and implements mechanisms that make it useful as a modern general-purpose transport protocol. Using UDP as the basis of QUIC is intended to address compatibility issues with legacy clients and middleboxes. QUIC authenticates all of its headers, preventing third parties from from changing them. QUIC encrypts most of its headers, thereby limiting protocol evolution to QUIC endpoints only. Therefore, middleboxes, in large part, are not required to be updated as new protocol versions are deployed. This document describes the core QUIC protocol, including the conceptual design, wire format, and mechanisms of the QUIC protocol for connection establishment, stream multiplexing, stream and connection-level flow control, and data reliability. Accompanying documents describe QUIC's loss recovery and congestion control, and the use of TLS 1.3 for key negotiation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-transport-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 Mon Nov 28 16:08:10 2016 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 EE06E12A198; Mon, 28 Nov 2016 16:07:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-recovery-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148037807197.5462.12789883225950531342.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2016 16:07:51 -0800 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-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, 29 Nov 2016 00:07:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-00.txt Pages : 11 Date : 2016-11-28 Abstract: QUIC is a new multiplexed and secure transport atop UDP. QUIC builds on decades of transport and security experience, and implements mechanisms that make it attractive as a modern general-purpose transport. QUIC implements the spirit of known TCP loss detection mechanisms, described in RFCs, various Internet-drafts, and also those prevalent in the Linux TCP implementation. This document describes QUIC loss detection and congestion control, and attributes the TCP equivalent in RFCs, Internet-drafts, academic papers, and TCP implementations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-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 Mon Nov 28 16:08:13 2016 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 180C812A192; Mon, 28 Nov 2016 16:07:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-tls-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148037807609.5402.13045628860649636096.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2016 16:07:56 -0800 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-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, 29 Nov 2016 00:07:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : Using Transport Layer Security (TLS) to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-00.txt Pages : 25 Date : 2016-11-28 Abstract: This document describes how Transport Layer Security (TLS) can be used to secure QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-tls-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 Mon Nov 28 16:08:17 2016 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 6BC5012A1A8; Mon, 28 Nov 2016 16:08:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Subject: I-D Action: draft-ietf-quic-http-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148037808243.5426.8536353945743004273.idtracker@ietfa.amsl.com> Date: Mon, 28 Nov 2016 16:08:02 -0800 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-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, 29 Nov 2016 00:08:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC of the IETF. Title : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-00.txt Pages : 11 Date : 2016-11-28 Abstract: The QUIC transport protocol has several features that are desirable in a transport for HTTP/2, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP/2 semantics over QUIC. Specifically, this document identifies HTTP/2 features that are subsumed by QUIC, and describes how the other features can be implemented atop QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-quic-http-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 Mon Nov 28 16:16:38 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABBC12A1B4 for ; Mon, 28 Nov 2016 16:16:36 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2mn1JjKsNvu for ; Mon, 28 Nov 2016 16:16:33 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 127A712A193 for ; Mon, 28 Nov 2016 16:16:18 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 48B2E22E259; Mon, 28 Nov 2016 19:16:10 -0500 (EST) From: Mark Nottingham Content-Type: multipart/alternative; boundary="Apple-Mail=_DBB777E4-F12B-46C4-9EE0-F5AB4225301C" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Fwd: New Version Notification for draft-ietf-quic-transport-00.txt Date: Tue, 29 Nov 2016 11:16:08 +1100 References: <148037806983.5530.15590119238530860455.idtracker@ietfa.amsl.com> To: IETF QUIC WG Message-Id: X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Lars Eggert X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 29 Nov 2016 00:16:36 -0000 --Apple-Mail=_DBB777E4-F12B-46C4-9EE0-F5AB4225301C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Everyone, The editors have submitted the -00 round of drafts, based upon the input = documents mentioned in our charter; as discussed in Seoul, these will be = our starting points, but that does not imply that we have consensus on = their contents. It's good to see that people have already started logging issues: https://github.com/quicwg/base-drafts/issues = As a reminder, this is the process for discussing and resolving those = issues, as discussed: https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.md = It's expected that there will be substantial changes in the first few = rounds of subsequent drafts, as the editors get them into shape for = further discussion. Please consider them to be a work-in-progress.=20 Cheers, > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-ietf-quic-transport-00.txt > Date: 29 November 2016 at 11:07:49 am AEDT > To: "Janardhan Iyengar" , "Martin Thomson" = , , "Jana Iyengar" = > Resent-From: > Resent-To: mnot@mnot.net, lars@netapp.com >=20 >=20 > A new version of I-D, draft-ietf-quic-transport-00.txt > has been successfully submitted by Martin Thomson and posted to the > IETF repository. >=20 > Name: draft-ietf-quic-transport > Revision: 00 > Title: QUIC: A UDP-Based Multiplexed and Secure = Transport > Document date: 2016-11-28 > Group: quic > Pages: 45 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-quic-transport-00.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-quic-transport-00 >=20 >=20 > Abstract: > QUIC is a multiplexed and secure transport protocol that runs on top > of UDP. QUIC builds on past transport experience, and implements > mechanisms that make it useful as a modern general-purpose transport > protocol. Using UDP as the basis of QUIC is intended to address > compatibility issues with legacy clients and middleboxes. QUIC > authenticates all of its headers, preventing third parties from from > changing them. QUIC encrypts most of its headers, thereby limiting > protocol evolution to QUIC endpoints only. Therefore, middleboxes, > in large part, are not required to be updated as new protocol > versions are deployed. This document describes the core QUIC > protocol, including the conceptual design, wire format, and > mechanisms of the QUIC protocol for connection establishment, stream > multiplexing, stream and connection-level flow control, and data > reliability. Accompanying documents describe QUIC's loss recovery > and congestion control, and the use of TLS 1.3 for key negotiation. >=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 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_DBB777E4-F12B-46C4-9EE0-F5AB4225301C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Everyone,

The editors have submitted the -00 round of drafts, based = upon the input documents mentioned in our charter; as discussed in = Seoul, these will be our starting points, but that does not imply that = we have consensus on their contents.

It's good to see that people have = already started logging issues:
  https://github.com/quicwg/base-drafts/issues

As a reminder, this is = the process for discussing and resolving those issues, as = discussed:
  https://github.com/quicwg/base-drafts/blob/master/CONTRIBUTING.= md

It's = expected that there will be substantial changes in the first few rounds = of subsequent drafts, as the editors get them into shape for further = discussion. Please consider them to be a = work-in-progress. 

Cheers,


Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-ietf-quic-transport-00.txt
Date: = 29 November 2016 at 11:07:49 am = AEDT
To: = "Janardhan Iyengar" <jri@google.com>, = "Martin Thomson" <martin.thomson@gmail.com>, <quic-chairs@ietf.org>, "Jana Iyengar" <jri@google.com>
Resent-From: <alias-bounces@ietf.org>
Resent-To: = mnot@mnot.net, lars@netapp.com


A new version = of I-D, draft-ietf-quic-transport-00.txt
has been = successfully submitted by Martin Thomson and posted to the
IETF repository.

Name: = draft-ietf-quic-transport
Revision: 00
Title:= = QUIC: A UDP-Based Multiplexed and Secure Transport
Document date: 2016-11-28
Group:= = quic
Pages: 45
URL: =            https://www.ietf.org/internet-drafts/draft-ietf-quic-transport-= 00.txt
Status: =         https://datatracker.ietf.org/doc/draft-ietf-quic-transport/=
Htmlized:       https://tools.ietf.org/html/draft-ietf-quic-transport-00

Abstract:
=   QUIC is a multiplexed and secure transport protocol that = runs on top
  of UDP.  QUIC builds on past = transport experience, and implements
=   mechanisms that make it useful as a modern general-purpose = transport
  protocol.  Using UDP as the = basis of QUIC is intended to address
=   compatibility issues with legacy clients and middleboxes. =  QUIC
  authenticates all of its headers, = preventing third parties from from
  changing = them.  QUIC encrypts most of its headers, thereby limiting
  protocol evolution to QUIC endpoints only. =  Therefore, middleboxes,
  in large part, = are not required to be updated as new protocol
=   versions are deployed.  This document describes the = core QUIC
  protocol, including the conceptual = design, wire format, and
  mechanisms of the = QUIC protocol for connection establishment, stream
=   multiplexing, stream and connection-level flow control, and = data
  reliability.  Accompanying = documents describe QUIC's loss recovery
  and = congestion control, and the use of TLS 1.3 for key negotiation.




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


--
Mark Nottingham =   https://www.mnot.net/

= --Apple-Mail=_DBB777E4-F12B-46C4-9EE0-F5AB4225301C-- From nobody Tue Nov 29 10:45:30 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CAFF129C24 for ; Tue, 29 Nov 2016 10:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WTvcyRYxjmC for ; Tue, 29 Nov 2016 10:45:27 -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 73152129649 for ; Tue, 29 Nov 2016 10:45:27 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id 20so187994160uak.0 for ; Tue, 29 Nov 2016 10:45:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lPV/I8+gl4MgzaYwVnkW+jwQGuyYsmzV0aCv1VOGNJM=; b=WtfQ6E/odP6GN1D64kb/0kMRlVwBZcY2nDtHY/OvE27IUtxyLZeanXsEDtC4ZXDaTu LAytCcIPhwhQlAsmEJ8M7L7nDm4DhRta8uhDUrccUY/eAKgBUtB9eJtL/wgqHHRLEhnD RfbJAIaJu2FOIxNsFqGcV5p0qymlOzxn9fijnz5jp+c0VcDl13j6rSAnzDgWh6CQL3MB JzJeKCm2CBMg/mKXTPsLqY7Ao7cvoNMBkXLeV0+k59krn3mCTWKQmP+0hdexuKI0fc/L hBPQWEn8+WPlmvrxP98A8BB8J/lFcHOChWKV3PlOBqPrU0SP5KDNYP/KieEow3Gumbu+ YKHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lPV/I8+gl4MgzaYwVnkW+jwQGuyYsmzV0aCv1VOGNJM=; b=VVtWNMRj71TotTbfQ1lnGlUlg39du5aZhQX/uXVhTSYJlfgIFUK6Lk6AhVSSWGSV9K TYzEjoJEjG6tEJptJU0fcaa9jAtU0lkK0+bSrGfmkSMWM4aFeJLYI5VmurOJmBdEmoTW nqEJlnmrGLJ+7y3wQl4XtARCyOySg10Dd73UvaUjjgCS0Jk25F4xvAYuKVxwxDWOlbtD 8FpqlnF4Mg/ynduQcv3JcoADI3DXhoZkpxOem9XKr/OQGm7krqcSynVDILsxibjF57I1 ez/wPuzTyitDHICqtlNw77+A4seyOyXQUeKrP5VHzlF8qqSaVUNVoQvMqavfhlG/wDFN uGMA== X-Gm-Message-State: AKaTC02+Zn4st6L9AmSftTz1MQ61e09aQdhHIjp9mdRbMZudtJ69O524EM2KxRPd0PeOOvAICkUV53FA3ZfC4vvo X-Received: by 10.176.83.100 with SMTP id y33mr21145729uay.130.1480445126521; Tue, 29 Nov 2016 10:45:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 29 Nov 2016 10:45:26 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 29 Nov 2016 10:45:26 -0800 Message-ID: Subject: Re: [QUIC] Why not be explicit about Stream 3 flow control exception? To: "Aron ." Content-Type: multipart/alternative; boundary=94eb2c192480e08b86054274fd62 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 29 Nov 2016 18:45:29 -0000 --94eb2c192480e08b86054274fd62 Content-Type: text/plain; charset=UTF-8 Hi Aron, Apologies for getting to this late -- the IETF kept me busy. [draft-hamilton-quic-transport-protocol-01] states (p. 35): > > o The crypto handshake stream, Stream 1, MUST NOT be subject to > congestion control or connection-level flow control, but MUST be > subject to stream-level flow control. > o An application MAY exclude specific stream IDs from connection-level > flow control. If so, these streams MUST NOT be subject to > connection-level flow control. > > The second bullet point is obviously about Stream 3. Seeing that there is > no way(?) to negotiate which streams are to be excluded, why not spell out > that Streams 1 and 3 are not subject to connection-level congestion control? > The second bullet point is about any application-chosen stream. An application may choose to not exempt any stream if there are no special streams. This need not be negotiated on the wire, but can be known for any given application. Specifically, the http-mapping draft is the document which, in the current design, should say that stream 3 should be excluded from connection-level flow control. - jana --94eb2c192480e08b86054274fd62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Aron,

Apologies for getting to this = late -- the IETF kept me busy.

[draft-hamilton-quic-transport-protocol-01] states (p. 35):

o The crypto handshake stream, Stream 1, MUST NOT be= subject to
congestion control or connection-level flow control, but MUS= T be
subject to stream-level flow control.
o An application MAY exclu= de specific stream IDs from connection-level
flow control. If so, these = streams MUST NOT be subject to
connection-level flow control.
=
The second bullet point is obviously about Stream 3.=C2=A0 S= eeing that there is no way(?) to negotiate which streams are to be excluded= , why not spell out that Streams 1 and 3 are not subject to connection-leve= l congestion control?

The secon= d bullet point is about any application-chosen stream. An application may c= hoose to not exempt any stream if there are no special streams.
<= br>
This need not be negotiated on the wire, but can be known for= any given application. Specifically, the http-mapping draft is the documen= t which, in the current design, should say that stream 3 should be excluded= from connection-level flow control.

- jana
<= div>=C2=A0
--94eb2c192480e08b86054274fd62-- From nobody Tue Nov 29 10:51:10 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AB63129C37 for ; Tue, 29 Nov 2016 10:51:08 -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 zTH6fsb1BiHo for ; Tue, 29 Nov 2016 10:51:07 -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 08AD9129C2F for ; Tue, 29 Nov 2016 10:51:07 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id a124so305865574ioe.2 for ; Tue, 29 Nov 2016 10:51:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xX94vGdXT99EKP/ITO3K3fzq7G+4odbhhWIG0HHGp7s=; b=lAvXC5rEqHKFvhXx8JB4wShoxlk4yUBR2oj9Tat1ycM0OW09dcUCx6Etk3ITi0+qkA ZCpAZmUbmVvwPsyEflCAPd1QZeYAx7uGSaCt58bRw7AglWXChFid/mzB3CBduA/YAIW5 WuOHVepl8icW1f+wFBlOcoEUzUQxwlY9i4CF3pO8lBPacHIykBCZ4u+xOireVbhjvsrZ dmUzKLNspSoe2tdEGSR9gxiSkYVX1nnJFX97dAbKmOOHbZuS6UFcREKX6dMDTyEDIFMz wLRxvwx1Jlj1HesrDsFxztAoQWHvSs0tfsF1CuHTYkvZHkidZLcLHFNTa1b39vwIf7Ib ICgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xX94vGdXT99EKP/ITO3K3fzq7G+4odbhhWIG0HHGp7s=; b=OsRKRC6n7ao4OEehMvLpyeoVTmdTiO2fbbJWknqJjRrxMFJdhJIKDfSK7qLu4u2EM6 auQHCF5WvSkh1aLlkECak1cPVIP4UONXCL1kcwJZmQWRZeDOYtWyHMiZlq0ZCe9GL1zn tuDEnLJI0hkifpaLh5mFJ0DR6xzcUWEwK+4NEDrSd/q7a1FHUcAl0iGsEC6fYomnwuRM cPjeBnCbAiY3wpSt6Elqc+TxoaRCUN+sBsNa3U+ciShEE/AaaDw3FiNaT5qsaLYfLsxE L0+IB1Oz+jlXDLnwwzyhSxV6OHhKWtnUKsM6gteHFW3kfoNnPuojcvUF2agUWn76V8mJ HZNA== X-Gm-Message-State: AKaTC02AAG4EDBcRJSmLo67+ZCasoh1wbeI7viDobMP6nzHrx+e5L3pQtu+Dv5QRfmUzFHvHlmWubBOXOMo1KQ== X-Received: by 10.36.7.85 with SMTP id f82mr25059583itf.10.1480445466296; Tue, 29 Nov 2016 10:51:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.12.81 with HTTP; Tue, 29 Nov 2016 10:51:05 -0800 (PST) In-Reply-To: References: From: "Aron ." Date: Tue, 29 Nov 2016 13:51:05 -0500 Message-ID: Subject: Re: [QUIC] Why not be explicit about Stream 3 flow control exception? To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a113f724c20c63f05427512b0 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 29 Nov 2016 18:51:08 -0000 --001a113f724c20c63f05427512b0 Content-Type: text/plain; charset=UTF-8 This is interesting. Is there a way for QUIC peer to tell which protocol over QUIC is used? In other words, at which point do I realize that it's not HTTP/QUIC I am talking to? Is it for upper-level code to figure out? On Tue, Nov 29, 2016 at 1:45 PM, Jana Iyengar wrote: > Hi Aron, > > Apologies for getting to this late -- the IETF kept me busy. > > [draft-hamilton-quic-transport-protocol-01] states (p. 35): >> >> o The crypto handshake stream, Stream 1, MUST NOT be subject to >> congestion control or connection-level flow control, but MUST be >> subject to stream-level flow control. >> o An application MAY exclude specific stream IDs from connection-level >> flow control. If so, these streams MUST NOT be subject to >> connection-level flow control. >> >> The second bullet point is obviously about Stream 3. Seeing that there >> is no way(?) to negotiate which streams are to be excluded, why not spell >> out that Streams 1 and 3 are not subject to connection-level congestion >> control? >> > > The second bullet point is about any application-chosen stream. An > application may choose to not exempt any stream if there are no special > streams. > > This need not be negotiated on the wire, but can be known for any given > application. Specifically, the http-mapping draft is the document which, in > the current design, should say that stream 3 should be excluded from > connection-level flow control. > > - jana > > --001a113f724c20c63f05427512b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is interesting.=C2=A0 Is there a way for QUIC peer to= tell which protocol over QUIC is used?=C2=A0 In other words, at which poin= t do=C2=A0I=C2=A0realize that it's not HTTP/QUIC I am talking to?=C2=A0= Is it for upper-level code to figure out?
=
On Tue, Nov 29, 2016 at 1:45 PM, Jana Iyenga= r <jri@google.com> wrote:
Hi Aron,

Apologies for getting to this lat= e -- the IETF kept me busy.

=
[dr= aft-hamilton-quic-transport-protocol-01] states (p. 35):
o The crypto handshake stream, Stream 1, MUST NOT be subject to=
congestion control or connection-level flow control, but MUST be
sub= ject to stream-level flow control.
o An application MAY exclude specific= stream IDs from connection-level
flow control. If so, these streams MUS= T NOT be subject to
connection-level flow control.

<= div>The second bullet point is obviously about Stream 3.=C2=A0 Seeing that = there is no way(?) to negotiate which streams are to be excluded, why not s= pell out that Streams 1 and 3 are not subject to connection-level congestio= n control?

The second bu= llet point is about any application-chosen stream. An application may choos= e to not exempt any stream if there are no special streams.

<= /div>
This need not be negotiated on the wire, but can be known for any= given application. Specifically, the http-mapping draft is the document wh= ich, in the current design, should say that stream 3 should be excluded fro= m connection-level flow control.

- jana
=C2=A0

--001a113f724c20c63f05427512b0-- From nobody Tue Nov 29 11:48:12 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DBD4129B6B for ; Tue, 29 Nov 2016 11:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKbcFoUr8lMp for ; Tue, 29 Nov 2016 11:48:07 -0800 (PST) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90488129B34 for ; Tue, 29 Nov 2016 11:48:07 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id d128so10842021ybh.2 for ; Tue, 29 Nov 2016 11:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sVELh3mZgGWtOH4B9zoxZSbzeuCSP8ldpq24Qww9BXQ=; b=gTWTUPyh22cgBIeZJpUCv5p7qId0uIy8yeeDzDptzQ4dQJ8KmRNGS41NbKZFx3BZNW fTLUHVZ708ZGRJ+h72p8dmh0bPNjSlODjeDIhfHh4SNToLzGLBMQYMDMH27k9se6bJGB AmjgfYqzS3LoYjSFnS1YHHpG40O/szVF6DB/cfmafdQgygu06elGFSJYosJl3R1qmtLw dmlgMay9ZNej5rECVq4LPAe0wyD2OcO2WCKWEp404LZ+hgCPtoyaYI7lIhwYC4ZQWXyY bJAhhB+Ng2vUib8iHnLW9iXvPWyfi1MsxePeqVKxEn35oDgPJ4razacpwlwW4AT7LN3m 1ldQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sVELh3mZgGWtOH4B9zoxZSbzeuCSP8ldpq24Qww9BXQ=; b=P3B+qjqnVJV+y5fuTnBJPzqfRUJMnM+Fw6k8cKZmY60j5qOs00w+e4uOSlvZgtfWav 9ZSSi3266q/Bf8q9Ptxc6ZKh0kKXnNVGzoyoV9DasGRImqbPvca8j2hvWei7eHOfLlwL 51qqNg7xCcfINf2Ad3BEDdYAQph8iv18Kumex5xiCO1KZ96Jw/Ok9GGOmtphkNIgYqOF 3sJ2ntaxTrOqcisRwzqHRiC+ff2fYTlxC21mSFYCMc21a54txIZLkUkPLLxYtilAxKsV hSsgRTaFVU18PomXkuC2ucsyrgwkgLkF2YUFK7zBi7rJ33o7OPuK5KXz8Y6rTuOLPcXK c3oQ== X-Gm-Message-State: AKaTC00lyZ6R1zGYrpY2QJ0+VIfJXpaKcGuW3jwTcKQ0t+oVkiiQL0j6go/sNe7Ot36siLxUbH7ru5lnDdCAud80 X-Received: by 10.37.173.78 with SMTP id l14mr5166663ybe.66.1480448886619; Tue, 29 Nov 2016 11:48:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Tue, 29 Nov 2016 11:47:46 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 29 Nov 2016 14:47:46 -0500 Message-ID: Subject: Re: Review of draft-thomson-quic-tls-01 To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045eb12cff477b054275dd7f Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 29 Nov 2016 19:48:10 -0000 --f403045eb12cff477b054275dd7f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your large update and all the new open issues. I'm adding a few more comments, but it's great progress. On Mon, Nov 28, 2016 at 1:46 AM, Martin Thomson wrote: > Jana, Ian, > > Thanks for the reviews. > > For the biggest issue here, I've been working on getting a better > overview in. It's not 100% complete, because I've run into the issue > with KEY_PHASE that I was going to discuss at the meeting. > > You can see where I'm at here: > > PR: https://github.com/quicwg/base-drafts/pull/30 > HTML: https://quicwg.github.io/base-drafts/tls-interface-overview/ > draft-ietf-quic-tls.html > > I've fix the obvious issues you identified, but I've also opened a ton > of issues, either because the answer isn't easy or because I'm lazy > and want to defer work. See inline. Ian, I've responded to your > comments as well. > > On 12 November 2016 at 17:02, Jana Iyengar wrote: > > - Section 2: (bullet 3) Version Negotiation is a type of packet, there > are > > no frames in it. > > I've killed this section; it's too much effort to maintain. > > > - Section 3: "Prior to the completion of the TLS handshake, QUIC frames > can > > be exchanged. However, these frames are not authenticated or > confidentiality > > protected." This is not true. 0-RTT data will be sent protected before > the > > handshake is completed. > > Yes, this was intended to capture the 1-RTT data. I've removed the > offending text, but there are probably a few other things that need > correcting too. > > I predict that what will catch us up is that 1-RTT keys are available > before the handshake completes. I don't have a good fix for that yet. > > > - Section 3.1: What key is the packet encrypted with? The application > key? I > > recall the plan being packets containing handshake messages to go > > unencrypted, but I don=E2=80=99t remember why. Is this still the plan? = If so, are > > KeyUpdate messages sent later also sent in an unencrypted packet? Why n= ot > > just use the application key for encrypting the packet at all times? > > Several responses are needed here: > > The purpose of this section is to talk about QUIC packet protection. > > Regarding handshake encryption: There's a trick here, and I think that > I've done a better job of fixing things to make it clear, let me know > if I missed the mark. TLS protects its own handshake, but QUIC > doesn't. That means that handshake encryption is at the TLS layer and > the QUIC packet protection sees cleartext. This is simpler because it > means that QUIC has one fewer key to deal with. > > Regarding KeyUpdate: The design for KeyUpdate was flawed in that > version of the draft. I shared a version that describes how to use > the scheme that Hannes Tschofenig proposed in his DTLS 1.3 document, > which I think is more robust. That scheme doesn't require any packets > on stream 1 to be exchanged, just an update to the in-use keys and a > flip of the KEY_PHASE bit. > > > - What does =E2=80=9CQUIC provides a record protection layer=E2=80=9D m= ean? This is new > > terminology at the least, so the =E2=80=9Crecord protection layer=E2=80= =9D should be > > defined. > > Yes, we've agreed that it should be packet protection. That keeps the > terminology cleanly separated from TLS: TLS uses *record* protection. > > > - Section 4.1 says: > > =E2=80=9CThe KEY_PHASE bit allows a recipient to detect a change in = keying > > material without needing to receive the message that triggers the > > change. This avoids head-of-line blocking around transitions betwee= n > > keys without relying on trial decryption.=E2=80=9D > > How does this avoid head-of-line blocking around transitions? What > > head-of-line blocking do you have in mind here? Or do you mean to say > that > > this bit allows handling of reordered packets correctly without relying > on > > trial-decryption? > > Yes, that. There are some designs where the content of a KeyUpdate > message would be required in order to get the next set of keys, which > would cause there to be HOL blocking, but I haven't proposed that (and > don't plan to). > > > - Why does the server need to send anything with a 0-RTT encrypter? > Doesn=E2=80=99t > > the server move immediately to 1RTT keys for sending, but keeps 0RTT-ke= y > and > > 1RTT-key decrypters? > > Yeah, this is corrected in the latest version. > > > - I like the phase changes, but I=E2=80=99m still a bit nervous. I thin= k (I need > to > > think more) that it will work out ok, but some more text here will help= , > > especially on why a KEY_PHASE of 0 or 1 is unambiguous on both sides, > 0-RTT > > or not, and why it is not possible to end up in strange states. (I now > see > > text that follows explains this. Perhaps add a forward pointer here.) > > I'm still working out how to properly explain this. It's even more > complicated than I've managed to convey. More on this when I get a > fix to the bug with KEY_PHASE and 0-RTT (issue #27). > > > - =E2=80=9C0-RTT keys SHOULD be retained until the handshake is complet= e.=E2=80=9D Why=E2=80=99s > > this a SHOULD and not a MUST? Why is this sentence required at all? > > When we originally implemented 0-RTT in TLS 1.3, we stopped sending > early data as soon as we saw the ServerHello. But if we lost parts of > the server's first flight of handshake messages, we might have > processed the ServerHello a whole round trip (or more) before the rest > of the messages that follow it. That meant dead air because we > stopped sending early data but we couldn't send the fully-protected > data yet because we hadn't finished with the handshake. It's more > complicated code now, but we wait until the first flight is done > before switching to 1-RTT. > > This won't be an issue with the fix I have in mind for #27. > > > - =E2=80=9CA client would be unable to decrypt retransmissions of a ser= ver's > > handshake messages that are protected using the 1-RTT keys, since th= e > > calculation of the application data keys depends on the contents of > > the handshake messages.=E2=80=9D > > This is a confusing sentence. Since you=E2=80=99re talking about decryp= tion of > > handshake messages, why do the application data keys matter? > > Yeah, it's definitely convoluted. > > The usual rules are that endpoints retransmit frames with the latest > keys. If the server follows those rules, then it will encrypt > retransmissions of its handshake messages with 1-RTT keys. But the > client needs those handshake messages to derive the 1-RTT keys. > > I've put what I think is a clearer description in the latest. > > > - =E2=80=9CAs shown in Figure 3 and Figure 4, there is never a situatio= n where > > there are more than two different sets of keying material that might > > be received by a peer.=E2=80=9D > > With reordering, I don=E2=80=99t think this statement is true. We need = rules > using > > packet numbers, such that an old packet with a key phase matching the > > current expected should not cause the connection to blow up. > > Yeah, you can't assume that because you have acked an update, you will > have completely flushed out everything from 2 generations ago. > > https://github.com/quicwg/base-drafts/issues/32 > https://github.com/quicwg/base-drafts/issues/33 > > The second one is a special one just because you assumed that we'd > drop a connection if decryption failed. I assume that you didn't > think about it very long, but we have to get this cemented into place: > if it doesn't decrypt, it didn't exist (with exceptions, because all > the best rules have exceptions). > > > - Section 4.1.2: I should probably go read about Key Updates in TLS 1.3 > > before trying to understand the details in this section. If so, a point= er > > somewhere would be useful. > > I wouldn't bother, it's a mess in that version of the document, the > draft in the repo has a bunch of changes that (I think) make it much > clearer. > > > - Section 4.3: =E2=80=9CThe nonce, N, for the AEAD is formed by combini= ng either > the > > Client > > Write IV or Server Write IV with the sequence numbers.=E2=80=9D What=E2= =80=99s the > > Client/Server Write IV? The next couple of paragraphs are quite > confusing. > > Why is there no Associated Data? QUIC currently uses the unencrypted > packet > > header as Associated Data. The QUIC packet does not have frames followi= ng > > the packet number=E2=80=A6. it=E2=80=99s not clear what it means for P = to be the =E2=80=9CQUIC > frame > > following the packet number=E2=80=9D? > > Write IV? Most of the confusion here is due to TLS terminology > leakage. I hope. I've tried to fix that up. > > There is no associated data because we don't need it. That's nice > because the packet protection design is exactly the same as the (D)TLS > record protection design, and more efficient as a result. > > > - I=E2=80=99m surprised to see a TLS sequence number, > > A straight up mistake on my part. > > > - Section 5: =E2=80=9CImplementations MUST NOT exchange data on any str= eam other > > than > > stream 1 prior to the completion of the TLS handshake.=E2=80=9D This= does not > > work, since 0-RTT data is sent on other streams before handshake > completion. > > > > - Section 5.1.2: I would like an explicit requirement on ACKs to be > > encrypted at the same level or higher as the packet that the ACK > > acknowledges. Is that adequate for this section? > > Sounds like a great idea, but it's not easy to handle 0-RTT: > https://github.com/quicwg/base-drafts/issues/34 > > > - Section 5.1.4: =E2=80=9CNote that > > the client could retransmit its Finished message to the server, so > > the server cannot reject such a message.=E2=80=9D Don=E2=80=99t unde= rstand this > sentence. > > Nor do I. Deleted. > > > - =E2=80=9CNever assume that because it isn't in the security considera= tions > > section it doesn't affect security. Most of this document does.=E2= =80=9D > Seems > > unnecessary. Also, seems silly to say that =E2=80=9Cmost=E2=80=9D of th= is document > affects > > security, since =E2=80=9Call=E2=80=9D of it does. > > Yeah, it's my little response to the insistence that we have security > considerations in every document, even the security ones. > > And it *is* only most of the document. > > On 13 November 2016 at 13:04, Ian Swett wrote: > > Now that private flags are gone, there is no encrypted portion of the > QUIC > > header. That being said, it's likely worth clarifying what envelope i= s. > > Yeah, I'm going to see if I can clobber that term instead. > > > Section 4.1 says: "The KEY_PHASE bit on the public flags is the most > > significant bit (0x80)." I would suggest we use the current > diversification > > nonce bit.(0x04), as it is otherwise unused in the TLS 1.3 version of > QUIC. > > Yeah, https://github.com/quicwg/base-drafts/issues/26 > > > Section 4.5 goes into Packet Number reconstruction. I don't think it's > > necessary to do this here(and there is a small error), though if you > want to > > state properties of packet numbers(ie: monotonically increasing on the > > sender side) that seems fine if it's helpful to the mapping doc. > > Already gone :) > > > Section 5.1.4 says "The ability to shadow packets means that an attacke= r > > does not need to be on path." I believe the attacker must be on path, > > unless I'm misunderstanding something? In regards to starting at a > > randomized packet number, that does provide some level of protection, a= nd > > seems wise. It also reduces the chances of ossification on the handsha= ke > > packets always starting at packet number 1. > > The attacker needs to know the connection ID, I guess. And that means > on-path, so I guess that randomization might not help there. > https://github.com/quicwg/base-drafts/issues/36 > > Let's track the starting sequence number here: > https://github.com/quicwg/base-drafts/issues/35 > > > I think "In addition to denying endpoints messages, an attacker to > generate > > packets that cause no state change in a recipient." needs to be reworde= d, > > because I'm rather confused on what it's saying. > > Yeah, I'm trying to get at the classic DoS vector: cause someone to do > something, but have them think that they did nothing so that they > don't blame you for the wasted resources. If you have a message that > causes busy work, but results in no change to state, sometimes that > slips through the net. I've taken another stab at this. > > > Can you clarify "MUST reject empty TLS handshake records and any record > that > > is not permitted by the TLS state machine". Should these packets be > > ignored, under the assumption they're attack packets? Or should the > > handshake fail? > > Handshake failure I think. We haven't gotten that bedded down yet: > https://github.com/quicwg/base-drafts/issues/37 > > > 5.3 is confusing to me. For example, it says "Due to reordering and > loss, > > protected packets might be received by an endpoint before the final > > handshake messages are received. If these can be decrypted successfully= , > > such packets MAY be stored and used once the handshake is complete." I > > think this deserves more specificity. In cases when the packets are > > encrypted with 1RTT keys, may should be stored for later decryption, bu= t > > there's no chance of them being decrypted before the SHLO wasn't > received. > > I'm a bit confused about what other cases you are thinking of in the > > section? > > Yeah, this is actually wrong. There is only one case where you > receive a packet that you can decrypt, but can't use. That is when > you receive a 1-RTT packet at the server, but you haven't > authenticated the connection (because the client Finished was > delayed). > > I'm not 100% confident about the text here, so I've created a PR for > this one: https://github.com/quicwg/base-drafts/pull/39 > > > 6.4 says "Even if the source IP address remains constant, the port > number is > > likely to be different." between TCP and QUIC. In typical cases, the > port > > number is new for every connection anyway, so I'm not sure this is a > > relevant concern. I would just remove that sentence. > > The point is to highlight that source address validation isn't > portable between the two protocols. I think that's still a relevant > point to make. > > > 7: clanger, though it looks like dangers, is not the same word :) > > Yep :) > > > 7.1: I think we need to loosen "A server SHOULD use a HelloRetryRequest > if > > the size of the handshake messages it sends is likely to exceed the siz= e > of > > the ClientHello." slightly to "a small multiple of the size of the > > ClientHello", or something similar, because multipacket certs are > extremely > > common. > > Yeah, the right answer will need some horse trading: > https://github.com/quicwg/base-drafts/issues/38 > > --f403045eb12cff477b054275dd7f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your large update and all the new open issues.= =C2=A0 I'm adding a few more comments, but it's great progress.

On Mon, Nov 28,= 2016 at 1:46 AM, Martin Thomson <martin.thomson@gmail.com><= /span> wrote:
Jana, Ian,

Thanks for the reviews.

For the biggest issue here, I've been working on getting a better
overview in.=C2=A0 It's not 100% complete, because I've run into th= e issue
with KEY_PHASE that I was going to discuss at the meeting.

You can see where I'm at here:

PR: https://github.com/quicwg/base-drafts/pull/30<= /a>
HTML: https://qu= icwg.github.io/base-drafts/tls-interface-overview/draft-ietf-quic= -tls.html

I've fix the obvious issues you identified, but I've also opened a = ton
of issues, either because the answer isn't easy or because I'm lazy=
and want to defer work.=C2=A0 See inline.=C2=A0 Ian, I've responded to = your
comments as well.

On 12 November 2016 at 17:02, Jana Iyengar <jri@google.com> wrote:
> - Section 2: (bullet 3) Version Negotiation is a type of packet, there= are
> no frames in it.

I've killed this section; it's too much effort to maintain.<= br>
> - Section 3: "Prior to the completion of the TLS handshake, QUIC = frames can
> be exchanged. However, these frames are not authenticated or confident= iality
> protected." This is not true. 0-RTT data will be sent protected b= efore the
> handshake is completed.

Yes, this was intended to capture the 1-RTT data.=C2=A0 I've rem= oved the
offending text, but there are probably a few other things that need
correcting too.

I predict that what will catch us up is that 1-RTT keys are available
before the handshake completes.=C2=A0 I don't have a good fix for that = yet.

> - Section 3.1: What key is the packet encrypted with? The application = key? I
> recall the plan being packets containing handshake messages to go
> unencrypted, but I don=E2=80=99t remember why. Is this still the plan?= If so, are
> KeyUpdate messages sent later also sent in an unencrypted packet? Why = not
> just use the application key for encrypting the packet at all times?
Several responses are needed here:

The purpose of this section is to talk about QUIC packet protection.

Regarding handshake encryption: There's a trick here, and I think that<= br> I've done a better job of fixing things to make it clear, let me know if I missed the mark.=C2=A0 TLS protects its own handshake, but QUIC
doesn't.=C2=A0 That means that handshake encryption is at the TLS layer= and
the QUIC packet protection sees cleartext.=C2=A0 This is simpler because it=
means that QUIC has one fewer key to deal with.

Regarding KeyUpdate:=C2=A0 The design for KeyUpdate was flawed in that
version of the draft.=C2=A0 I shared a version that describes how to use the scheme that Hannes Tschofenig proposed in his DTLS 1.3 document,
which I think is more robust.=C2=A0 That scheme doesn't require any pac= kets
on stream 1 to be exchanged, just an update to the in-use keys and a
flip of the KEY_PHASE bit.

> - What does =E2=80=9CQUIC provides a record protection layer=E2=80=9D = mean? This is new
> terminology at the least, so the =E2=80=9Crecord protection layer=E2= =80=9D should be
> defined.

Yes, we've agreed that it should be packet protection.=C2=A0 Tha= t keeps the
terminology cleanly separated from TLS: TLS uses *record* protection.

> - Section 4.1 says:
>=C2=A0 =C2=A0 =E2=80=9CThe KEY_PHASE bit allows a recipient to detect a= change in keying
>=C2=A0 =C2=A0 material without needing to receive the message that trig= gers the
>=C2=A0 =C2=A0 change.=C2=A0 This avoids head-of-line blocking around tr= ansitions between
>=C2=A0 =C2=A0 keys without relying on trial decryption.=E2=80=9D
> How does this avoid head-of-line blocking around transitions? What
> head-of-line blocking do you have in mind here? Or do you mean to say = that
> this bit allows handling of reordered packets correctly without relyin= g on
> trial-decryption?

Yes, that.=C2=A0 There are some designs where the content of a KeyUp= date
message would be required in order to get the next set of keys, which
would cause there to be HOL blocking, but I haven't proposed that (and<= br> don't plan to).

> - Why does the server need to send anything with a 0-RTT encrypter? Do= esn=E2=80=99t
> the server move immediately to 1RTT keys for sending, but keeps 0RTT-k= ey and
> 1RTT-key decrypters?

Yeah, this is corrected in the latest version.

> - I like the phase changes, but I=E2=80=99m still a bit nervous. I thi= nk (I need to
> think more) that it will work out ok, but some more text here will hel= p,
> especially on why a KEY_PHASE of 0 or 1 is unambiguous on both sides, = 0-RTT
> or not, and why it is not possible to end up in strange states. (I now= see
> text that follows explains this. Perhaps add a forward pointer here.)<= br>
I'm still working out how to properly explain this.=C2=A0 It'= ;s even more
complicated than I've managed to convey.=C2=A0 More on this when I get = a
fix to the bug with KEY_PHASE and 0-RTT (issue #27).

> - =E2=80=9C0-RTT keys SHOULD be retained until the handshake is comple= te.=E2=80=9D Why=E2=80=99s
> this a SHOULD and not a MUST? Why is this sentence required at all?
When we originally implemented 0-RTT in TLS 1.3, we stopped sending<= br> early data as soon as we saw the ServerHello.=C2=A0 But if we lost parts of=
the server's first flight of handshake messages, we might have
processed the ServerHello a whole round trip (or more) before the rest
of the messages that follow it.=C2=A0 That meant dead air because we
stopped sending early data but we couldn't send the fully-protected
data yet because we hadn't finished with the handshake.=C2=A0 It's = more
complicated code now, but we wait until the first flight is done
before switching to 1-RTT.

This won't be an issue with the fix I have in mind for #27.

> - =E2=80=9CA client would be unable to decrypt retransmissions of a se= rver's
>=C2=A0 =C2=A0 handshake messages that are protected using the 1-RTT key= s, since the
>=C2=A0 =C2=A0 calculation of the application data keys depends on the c= ontents of
>=C2=A0 =C2=A0 the handshake messages.=E2=80=9D
> This is a confusing sentence. Since you=E2=80=99re talking about decry= ption of
> handshake messages, why do the application data keys matter?

Yeah, it's definitely convoluted.

The usual rules are that endpoints retransmit frames with the latest
keys.=C2=A0 If the server follows those rules, then it will encrypt
retransmissions of its handshake messages with 1-RTT keys.=C2=A0 But the client needs those handshake messages to derive the 1-RTT keys.

I've put what I think is a clearer description in the latest.

> - =E2=80=9CAs shown in Figure 3 and Figure 4, there is never a situati= on where
>=C2=A0 =C2=A0 there are more than two different sets of keying material= that might
>=C2=A0 =C2=A0 be received by a peer.=E2=80=9D
> With reordering, I don=E2=80=99t think this statement is true. We need= rules using
> packet numbers, such that an old packet with a key phase matching the<= br> > current expected should not cause the connection to blow up.

Yeah, you can't assume that because you have acked an update, yo= u will
have completely flushed out everything from 2 generations ago.

https://github.com/quicwg/base-drafts/issues/32<= /a>
https://github.com/quicwg/base-drafts/issues/33<= /a>

The second one is a special one just because you assumed that we'd
drop a connection if decryption failed.=C2=A0 I assume that you didn't<= br> think about it very long, but we have to get this cemented into place:
if it doesn't decrypt, it didn't exist (with exceptions, because al= l
the best rules have exceptions).

> - Section 4.1.2: I should probably go read about Key Updates in TLS 1.= 3
> before trying to understand the details in this section. If so, a poin= ter
> somewhere would be useful.

I wouldn't bother, it's a mess in that version of the docume= nt, the
draft in the repo has a bunch of changes that (I think) make it much
clearer.

> - Section 4.3: =E2=80=9CThe nonce, N, for the AEAD is formed by combin= ing either the
> Client
> Write IV or Server Write IV with the sequence numbers.=E2=80=9D What= =E2=80=99s the
> Client/Server Write IV? The next couple of paragraphs are quite confus= ing.
> Why is there no Associated Data? QUIC currently uses the unencrypted p= acket
> header as Associated Data. The QUIC packet does not have frames follow= ing
> the packet number=E2=80=A6. it=E2=80=99s not clear what it means for P= to be the =E2=80=9CQUIC frame
> following the packet number=E2=80=9D?

Write IV?=C2=A0 Most of the confusion here is due to TLS terminology=
leakage.=C2=A0 I hope.=C2=A0 I've tried to fix that up.

There is no associated data because we don't need it.=C2=A0 That's = nice
because the packet protection design is exactly the same as the (D)TLS
record protection design, and more efficient as a result.

> - I=E2=80=99m surprised to see a TLS sequence number,

A straight up mistake on my part.

> - Section 5: =E2=80=9CImplementations MUST NOT exchange data on any st= ream other
> than
>=C2=A0 =C2=A0 stream 1 prior to the completion of the TLS handshake.=E2= =80=9D This does not
> work, since 0-RTT data is sent on other streams before handshake compl= etion.
>
> - Section 5.1.2: I would like an explicit=C2=A0 requirement on ACKs to= be
> encrypted at the same level or higher as the packet that the ACK
> acknowledges. Is that adequate for this section?

Sounds like a great idea, but it's not easy to handle 0-RTT:
https://github.com/quicwg/base-drafts/issues/34<= /a>

> - Section 5.1.4: =E2=80=9CNote that
>=C2=A0 =C2=A0 the client could retransmit its Finished message to the s= erver, so
>=C2=A0 =C2=A0 the server cannot reject such a message.=E2=80=9D Don=E2= =80=99t understand this sentence.

Nor do I.=C2=A0 Deleted.

> - =E2=80=9CNever assume that because it isn't in the security cons= iderations
>=C2=A0 =C2=A0 section it doesn't affect security.=C2=A0 Most of thi= s document does.=E2=80=9D Seems
> unnecessary. Also, seems silly to say that =E2=80=9Cmost=E2=80=9D of t= his document affects
> security, since =E2=80=9Call=E2=80=9D of it does.

Yeah, it's my little response to the insistence that we have sec= urity
considerations in every document, even the security ones.

And it *is* only most of the document.

On 13 November 2016 at 13:04, Ian Swett <ianswett@google.com> wrote:
> Now that private flags are gone, there is no encrypted portion of the = QUIC
> header.=C2=A0 =C2=A0That being said, it's likely worth clarifying = what envelope is.

Yeah, I'm going to see if I can clobber that term instead.

> Section 4.1 says: "The KEY_PHASE bit on the public flags is the m= ost
> significant bit (0x80)."=C2=A0 I would suggest we use the current= diversification
> nonce bit.(0x04), as it is otherwise unused in the TLS 1.3 version of = QUIC.

Yeah, https://github.com/quicwg/base-draf= ts/issues/26

> Section 4.5 goes into Packet Number reconstruction.=C2=A0 I don't = think it's
> necessary to do this here(and there is a small error), though if you w= ant to
> state properties of packet numbers(ie: monotonically increasing on the=
> sender side) that seems fine if it's helpful to the mapping doc.
Already gone :)

> Section 5.1.4 says "The ability to shadow packets means that an a= ttacker
> does not need to be on path."=C2=A0 I believe the attacker must b= e on path,
> unless I'm misunderstanding something?=C2=A0 In regards to startin= g at a
> randomized packet number, that does provide some level of protection, = and
> seems wise.=C2=A0 It also reduces the chances of ossification on the h= andshake
> packets always starting at packet number 1.

The attacker needs to know the connection ID, I guess.=C2=A0 And tha= t means
on-path, so I guess that randomization might not help there.
https://github.com/quicwg/base-drafts/issues/36<= /a>

Let's track the starting sequence number here:
https://github.com/quicwg/base-drafts/issues/35<= /a>

> I think "In addition to denying endpoints messages, an attacker t= o generate
> packets that cause no state change in a recipient." needs to be r= eworded,
> because I'm rather confused on what it's saying.

Yeah, I'm trying to get at the classic DoS vector: cause someone= to do
something, but have them think that they did nothing so that they
don't blame you for the wasted resources.=C2=A0 If you have a message t= hat
causes busy work, but results in no change to state, sometimes that
slips through the net.=C2=A0 I've taken another stab at this.

> Can you clarify "MUST reject empty TLS handshake records and any = record that
> is not permitted by the TLS state machine".=C2=A0 Should these pa= ckets be
> ignored, under the assumption they're attack packets?=C2=A0 Or sho= uld the
> handshake fail?

Handshake failure I think.=C2=A0 We haven't gotten that bedded d= own yet:
https://github.com/quicwg/base-drafts/issues/37<= /a>

> 5.3 is confusing to me.=C2=A0 For example, it says "Due to reorde= ring and loss,
> protected packets might be received by an endpoint before the final > handshake messages are received. If these can be decrypted successfull= y,
> such packets MAY be stored and used once the handshake is complete.&qu= ot;=C2=A0 I
> think this deserves more specificity.=C2=A0 In cases when the packets = are
> encrypted with 1RTT keys, may should be stored for later decryption, b= ut
> there's no chance of them being decrypted before the SHLO wasn'= ;t received.
> I'm a bit confused about what other cases you are thinking of in t= he
> section?

Yeah, this is actually wrong.=C2=A0 There is only one case where you=
receive a packet that you can decrypt, but can't use.=C2=A0 That is whe= n
you receive a 1-RTT packet at the server, but you haven't
authenticated the connection (because the client Finished was
delayed).

I'm not 100% confident about the text here, so I've created a PR fo= r
this one: https://github.com/quicwg/base-drafts/pu= ll/39

> 6.4 says "Even if the source IP address remains constant, the por= t number is
> likely to be different." between TCP and QUIC.=C2=A0 In typical c= ases, the port
> number is new for every connection anyway, so I'm not sure this is= a
> relevant concern.=C2=A0 I would just remove that sentence.

The point is to highlight that source address validation isn't portable between the two protocols.=C2=A0 I think that's still a releva= nt
point to make.

> 7: clanger, though it looks like dangers, is not the same word :)

Yep :)

> 7.1: I think we need to loosen "A server SHOULD use a HelloRetryR= equest if
> the size of the handshake messages it sends is likely to exceed the si= ze of
> the ClientHello." slightly to "a small multiple of the size = of the
> ClientHello", or something similar, because multipacket certs are= extremely
> common.

Yeah, the right answer will need some horse trading:
https://github.com/quicwg/base-drafts/issues/38<= /a>


--f403045eb12cff477b054275dd7f-- From nobody Tue Nov 29 15:08:26 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEB62124281 for ; Tue, 29 Nov 2016 15:08:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9sC5rnDMJ_t for ; Tue, 29 Nov 2016 15:08:18 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0132.outbound.protection.outlook.com [104.47.38.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6439129CC0 for ; Tue, 29 Nov 2016 15:08: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=+BsbD+aN/+Y/vWlOYGhclVEVeQOq3adyQjnKJ2Tqe9M=; b=Snmz+BsvbD93sdWZjjGesXVpb7vGqPwrrUclDXLG8xoa4NGw6LUCaad802SgQ+Ix5gePa/c/Qw/HkmHVETSfiy9hU9hdmPcqSr6AJkyH/8ejUyOO1n8lIPDk8PWImscTRbL/ewXOomWxBb4HkUPGVLSt2qkqfCSyRa0CZOGSYyI= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Tue, 29 Nov 2016 23:08:15 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0747.015; Tue, 29 Nov 2016 23:08:15 +0000 From: Mike Bishop To: "Aron ." , Jana Iyengar Subject: RE: [QUIC] Why not be explicit about Stream 3 flow control exception? Thread-Topic: [QUIC] Why not be explicit about Stream 3 flow control exception? Thread-Index: AQHSPrgGfIvDjV/wrUKopO/WTiVcT6DwZA8AgAABlICAAEZPUA== Date: Tue, 29 Nov 2016 23:08:15 +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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:2::d3] x-ms-office365-filtering-correlation-id: 66de8df4-1c31-4aa1-b6b0-08d418ac99bd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:b2EJxiDaDQKC7rEgSLaBELUTH39ZVzhY/eIY5+fkzWkl32I/yg4FZirKbF0FElsFuUgM1DbAzemzJ5bpwWWJdpzuzxXorC8bs8IExFBFrp6XZ+h69VfB+AW792Xry7i5s2bhzQT9YF6kD2cLz8u1kG7gKiLyYh2wOc/Fjt4eAmgzEwvJ2kYnl8v2LmsEZUy+LDJ7Ya4kkAMSuhAulEfxfvFtxgV5dtMY7/bUTozUiJdSmuLk07OVPVamPlg9he0djOEMVAYkifUMNNSjXgWMdSRSjpWMLkXJFAFDQbeQs6KYCCjXOyXXyQOHubgVDnTuXlgGp0a39ec0ya9Hrn35jConmXyYSGSpCmB5pcMmQLPINU0v9xzunNubLDvIyT+DfC5wEzsoV6C1QinPwxsSGD8MfLQNRPuN8JjBfE70Zb3Mt0vcnWHZ9Rmij0EKQhYy1B424uwDZ3KBzXx+3HAtgnWGmcbMv3ke+Y5nqrY72HY= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558021)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148)(6047074)(6042181); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 01415BB535 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(189002)(24454002)(377454003)(76576001)(105586002)(4326007)(5660300001)(8936002)(81156014)(106356001)(33656002)(9686002)(8676002)(92566002)(50986999)(68736007)(81166006)(189998001)(7696004)(97736004)(101416001)(54356999)(76176999)(99286002)(19609705001)(2950100002)(2906002)(86612001)(5005710100001)(10090500001)(10290500002)(5001770100001)(606004)(122556002)(790700001)(6506003)(86362001)(8990500004)(2900100001)(7736002)(3280700002)(77096006)(74316002)(38730400001)(106116001)(39060400001)(102836003)(3660700001)(229853002)(6116002)(7846002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708B678CB998FD85E8F070D878D0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2016 23:08:15.7089 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 29 Nov 2016 23:08:25 -0000 --_000_BN6PR03MB2708B678CB998FD85E8F070D878D0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJvdG9jb2wgbmVnb3RpYXRpb24gKGxpa2UgbWFueSBhcmVhcykgbmVlZHMgdG8gYmUgaXJvbmVk IG91dC4gIEkgc2VlIHNvbWUgb2J2aW91cyBwYXRocyBoZXJlOg0KDQogICogICBVc2UgQUxQTiBp biB0aGUgVExTIGhhbmRzaGFrZQ0KICAgICAqICAgSW1wbGllcyBhIGdlbmVyYWwgcmVxdWlyZW1l bnQgb24gdGhlIGNyeXB0byBoYW5kc2hha2UgdG8gc3VwcG9ydCBhcHAtbGF5ZXIgcHJvdG9jb2wg YWdyZWVtZW50DQogICogICBVc2UgcG9ydCBudW1iZXJzLCBsaWtlIFRDUC9VRFAgYWxyZWFkeSBk bw0KICAgICAqICAgUVVJQyBpcyBhIG5ldyB0cmFuc3BvcnQgdGhhdCBzaGFyZXMgdGhlIFVEUCBw b3J0IHNwYWNlOyBzYW1lIHJ1bGVzIGZvciBpbnRlcnByZXRpbmcgaW5jb21pbmcgbWVzc2FnZXMg Y2FuIGFwcGx5DQoNCkkgdGVuZCB0b3dhcmQgYSBjb21iaW5hdGlvbiBvZiB0aGUgdHdvLCBzaW5j ZSB3ZeKAmXZlIGFscmVhZHkgc2VlbiBIVFRQLzIgZ2V0IGludG8gdGhlIHBpY2tsZSB0aGF0IEkg c3RpbGwgbmVlZCB0byBkbyB2ZXJzaW9uIG5lZ290aWF0aW9uIGV2ZW4gb25jZSBJIGtub3cgaXTi gJlzIHNvbWUgZmxhdm9yIG9mIEhUVFAuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBcm9uIC4NClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVy IDI5LCAyMDE2IDEwOjUxIEFNDQpUbzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbT4NCkNj OiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1FVSUNdIFdoeSBu b3QgYmUgZXhwbGljaXQgYWJvdXQgU3RyZWFtIDMgZmxvdyBjb250cm9sIGV4Y2VwdGlvbj8NCg0K VGhpcyBpcyBpbnRlcmVzdGluZy4gIElzIHRoZXJlIGEgd2F5IGZvciBRVUlDIHBlZXIgdG8gdGVs bCB3aGljaCBwcm90b2NvbCBvdmVyIFFVSUMgaXMgdXNlZD8gIEluIG90aGVyIHdvcmRzLCBhdCB3 aGljaCBwb2ludCBkbyBJIHJlYWxpemUgdGhhdCBpdCdzIG5vdCBIVFRQL1FVSUMgSSBhbSB0YWxr aW5nIHRvPyAgSXMgaXQgZm9yIHVwcGVyLWxldmVsIGNvZGUgdG8gZmlndXJlIG91dD8NCg0KT24g VHVlLCBOb3YgMjksIDIwMTYgYXQgMTo0NSBQTSwgSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNv bTxtYWlsdG86anJpQGdvb2dsZS5jb20+PiB3cm90ZToNCkhpIEFyb24sDQoNCkFwb2xvZ2llcyBm b3IgZ2V0dGluZyB0byB0aGlzIGxhdGUgLS0gdGhlIElFVEYga2VwdCBtZSBidXN5Lg0KDQpbZHJh ZnQtaGFtaWx0b24tcXVpYy10cmFuc3BvcnQtcHJvdG9jb2wtMDFdIHN0YXRlcyAocC4gMzUpOg0K DQpvIFRoZSBjcnlwdG8gaGFuZHNoYWtlIHN0cmVhbSwgU3RyZWFtIDEsIE1VU1QgTk9UIGJlIHN1 YmplY3QgdG8NCmNvbmdlc3Rpb24gY29udHJvbCBvciBjb25uZWN0aW9uLWxldmVsIGZsb3cgY29u dHJvbCwgYnV0IE1VU1QgYmUNCnN1YmplY3QgdG8gc3RyZWFtLWxldmVsIGZsb3cgY29udHJvbC4N Cm8gQW4gYXBwbGljYXRpb24gTUFZIGV4Y2x1ZGUgc3BlY2lmaWMgc3RyZWFtIElEcyBmcm9tIGNv bm5lY3Rpb24tbGV2ZWwNCmZsb3cgY29udHJvbC4gSWYgc28sIHRoZXNlIHN0cmVhbXMgTVVTVCBO T1QgYmUgc3ViamVjdCB0bw0KY29ubmVjdGlvbi1sZXZlbCBmbG93IGNvbnRyb2wuDQoNClRoZSBz ZWNvbmQgYnVsbGV0IHBvaW50IGlzIG9idmlvdXNseSBhYm91dCBTdHJlYW0gMy4gIFNlZWluZyB0 aGF0IHRoZXJlIGlzIG5vIHdheSg/KSB0byBuZWdvdGlhdGUgd2hpY2ggc3RyZWFtcyBhcmUgdG8g YmUgZXhjbHVkZWQsIHdoeSBub3Qgc3BlbGwgb3V0IHRoYXQgU3RyZWFtcyAxIGFuZCAzIGFyZSBu b3Qgc3ViamVjdCB0byBjb25uZWN0aW9uLWxldmVsIGNvbmdlc3Rpb24gY29udHJvbD8NCg0KVGhl IHNlY29uZCBidWxsZXQgcG9pbnQgaXMgYWJvdXQgYW55IGFwcGxpY2F0aW9uLWNob3NlbiBzdHJl YW0uIEFuIGFwcGxpY2F0aW9uIG1heSBjaG9vc2UgdG8gbm90IGV4ZW1wdCBhbnkgc3RyZWFtIGlm IHRoZXJlIGFyZSBubyBzcGVjaWFsIHN0cmVhbXMuDQoNClRoaXMgbmVlZCBub3QgYmUgbmVnb3Rp YXRlZCBvbiB0aGUgd2lyZSwgYnV0IGNhbiBiZSBrbm93biBmb3IgYW55IGdpdmVuIGFwcGxpY2F0 aW9uLiBTcGVjaWZpY2FsbHksIHRoZSBodHRwLW1hcHBpbmcgZHJhZnQgaXMgdGhlIGRvY3VtZW50 IHdoaWNoLCBpbiB0aGUgY3VycmVudCBkZXNpZ24sIHNob3VsZCBzYXkgdGhhdCBzdHJlYW0gMyBz aG91bGQgYmUgZXhjbHVkZWQgZnJvbSBjb25uZWN0aW9uLWxldmVsIGZsb3cgY29udHJvbC4NCg0K LSBqYW5hDQoNCg0K --_000_BN6PR03MB2708B678CB998FD85E8F070D878D0BN6PR03MB2708namp_ 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 aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDoxNjI4NzI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0yMTIyNjcxMzUwIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4 Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlz dCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Qcm90b2NvbCBuZWdvdGlhdGlvbiAo bGlrZSBtYW55IGFyZWFzKSBuZWVkcyB0byBiZSBpcm9uZWQgb3V0LiZuYnNwOyBJIHNlZSBzb21l IG9idmlvdXMgcGF0aHMgaGVyZTo8bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRv cDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5Vc2UgQUxQTiBpbiB0aGUg VExTIGhhbmRzaGFrZTxvOnA+PC9vOnA+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBl PSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBsZm8xIj5JbXBsaWVzIGEgZ2VuZXJhbCByZXF1aXJl bWVudCBvbiB0aGUgY3J5cHRvIGhhbmRzaGFrZSB0byBzdXBwb3J0IGFwcC1sYXllciBwcm90b2Nv bCBhZ3JlZW1lbnQ8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij5Vc2UgcG9ydCBudW1iZXJzLCBsaWtlIFRDUC9VRFAgYWxyZWFkeSBkbzxvOnA+PC9vOnA+DQo8 dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMiBs Zm8xIj5RVUlDIGlzIGEgbmV3IHRyYW5zcG9ydCB0aGF0IHNoYXJlcyB0aGUgVURQIHBvcnQgc3Bh Y2U7IHNhbWUgcnVsZXMgZm9yIGludGVycHJldGluZyBpbmNvbWluZyBtZXNzYWdlcyBjYW4gYXBw bHk8bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0ZW5kIHRvd2Fy ZCBhIGNvbWJpbmF0aW9uIG9mIHRoZSB0d28sIHNpbmNlIHdl4oCZdmUgYWxyZWFkeSBzZWVuIEhU VFAvMiBnZXQgaW50byB0aGUgcGlja2xlIHRoYXQgSSBzdGlsbCBuZWVkIHRvIGRvIHZlcnNpb24g bmVnb3RpYXRpb24gZXZlbiBvbmNlIEkga25vdyBpdOKAmXMgc29tZSBmbGF2b3Igb2YgSFRUUC48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPkFyb24gLjxicj4NCjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAyOSwgMjAxNiAxMDo1MSBBTTxicj4NCjxiPlRvOjwvYj4g SmFuYSBJeWVuZ2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IElFVEYg UVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtR VUlDXSBXaHkgbm90IGJlIGV4cGxpY2l0IGFib3V0IFN0cmVhbSAzIGZsb3cgY29udHJvbCBleGNl cHRpb24/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGludGVyZXN0aW5n LiZuYnNwOyBJcyB0aGVyZSBhIHdheSBmb3IgUVVJQyBwZWVyIHRvIHRlbGwgd2hpY2ggcHJvdG9j b2wgb3ZlciBRVUlDIGlzIHVzZWQ/Jm5ic3A7IEluIG90aGVyIHdvcmRzLCBhdCB3aGljaCBwb2lu dCBkbyZuYnNwO0kmbmJzcDtyZWFsaXplIHRoYXQgaXQncyBub3QgSFRUUC9RVUlDIEkgYW0gdGFs a2luZyB0bz8mbmJzcDsgSXMgaXQgZm9yIHVwcGVyLWxldmVsIGNvZGUgdG8gZmlndXJlIG91dD88 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTm92 IDI5LCAyMDE2IGF0IDE6NDUgUE0sIEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpy aUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anJpQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgQXJvbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkFwb2xvZ2llcyBmb3IgZ2V0dGluZyB0byB0aGlzIGxhdGUgLS0gdGhlIElFVEYga2VwdCBtZSBi dXN5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+W2RyYWZ0LWhhbWlsdG9uLXF1aWMt dHJhbnNwb3J0LXByb3RvY29sLTAxXSBzdGF0ZXMgKHAuIDM1KTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+byBUaGUgY3J5cHRvIGhhbmRzaGFr ZSBzdHJlYW0sIFN0cmVhbSAxLCBNVVNUIE5PVCBiZSBzdWJqZWN0IHRvPGJyPg0KY29uZ2VzdGlv biBjb250cm9sIG9yIGNvbm5lY3Rpb24tbGV2ZWwgZmxvdyBjb250cm9sLCBidXQgTVVTVCBiZTxi cj4NCnN1YmplY3QgdG8gc3RyZWFtLWxldmVsIGZsb3cgY29udHJvbC48YnI+DQpvIEFuIGFwcGxp Y2F0aW9uIE1BWSBleGNsdWRlIHNwZWNpZmljIHN0cmVhbSBJRHMgZnJvbSBjb25uZWN0aW9uLWxl dmVsPGJyPg0KZmxvdyBjb250cm9sLiBJZiBzbywgdGhlc2Ugc3RyZWFtcyBNVVNUIE5PVCBiZSBz dWJqZWN0IHRvPGJyPg0KY29ubmVjdGlvbi1sZXZlbCBmbG93IGNvbnRyb2wuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBzZWNvbmQgYnVs bGV0IHBvaW50IGlzIG9idmlvdXNseSBhYm91dCBTdHJlYW0gMy4mbmJzcDsgU2VlaW5nIHRoYXQg dGhlcmUgaXMgbm8gd2F5KD8pIHRvIG5lZ290aWF0ZSB3aGljaCBzdHJlYW1zIGFyZSB0byBiZSBl eGNsdWRlZCwgd2h5IG5vdCBzcGVsbCBvdXQgdGhhdCBTdHJlYW1zIDEgYW5kIDMgYXJlIG5vdCBz dWJqZWN0IHRvIGNvbm5lY3Rpb24tbGV2ZWwgY29uZ2VzdGlvbiBjb250cm9sPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBzZWNvbmQgYnVsbGV0IHBvaW50IGlzIGFib3V0IGFueSBhcHBsaWNhdGlv bi1jaG9zZW4gc3RyZWFtLiBBbiBhcHBsaWNhdGlvbiBtYXkgY2hvb3NlIHRvIG5vdCBleGVtcHQg YW55IHN0cmVhbSBpZiB0aGVyZSBhcmUgbm8gc3BlY2lhbCBzdHJlYW1zLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIG5lZWQgbm90IGJl IG5lZ290aWF0ZWQgb24gdGhlIHdpcmUsIGJ1dCBjYW4gYmUga25vd24gZm9yIGFueSBnaXZlbiBh cHBsaWNhdGlvbi4gU3BlY2lmaWNhbGx5LCB0aGUgaHR0cC1tYXBwaW5nIGRyYWZ0IGlzIHRoZSBk b2N1bWVudCB3aGljaCwgaW4gdGhlIGN1cnJlbnQgZGVzaWduLCBzaG91bGQgc2F5IHRoYXQgc3Ry ZWFtIDMgc2hvdWxkIGJlIGV4Y2x1ZGVkIGZyb20gY29ubmVjdGlvbi1sZXZlbCBmbG93DQogY29u dHJvbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 Izg4ODg4OCI+LSBqYW5hPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR03MB2708B678CB998FD85E8F070D878D0BN6PR03MB2708namp_-- From nobody Tue Nov 29 17:18:07 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E143129D18 for ; Tue, 29 Nov 2016 17:18:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V_9lU2XwQPkL for ; Tue, 29 Nov 2016 17:18:02 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 619C6129D1D for ; Tue, 29 Nov 2016 17:17:49 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id 20so197861997uak.0 for ; Tue, 29 Nov 2016 17:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pVJJjHuLh+8c8FmeAQAmg3XZxGsghYyEgjphfPhR1JY=; b=I2gPWmEIuc+VggixraA8CYKhwNHQ/zpgJPmc1YTnjrAGH1dbYoUIWalSviEdA69JaM NgwUu3UPawAFHMxb22CePPpBHeSM+CsNxL9vsuEtd5eJjoATUDnTj6ibs07qbtPm3CyK eU1VpLhiu3M/1gwtfpXjK5bHs9b/TMsRZRGuqGKbUykRiOySFQyaTAY76Yx60Dup8vVT qC0KA+ehdUbJpxeZNiLLxxjUH7fHYeurFD4/DHHQrBAFs3ulpYR4tnEyc8Z+N102ha+I Q8vr6YypIHcCCI8olMDZpTXocmAYkcvPU2tnraJ6RD0buP3yaMYGfwVuyQGkljPbglXN +hcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pVJJjHuLh+8c8FmeAQAmg3XZxGsghYyEgjphfPhR1JY=; b=WFJ08q71SuKV51tvzubY6Bzmv5Yrb5gDBb/cL/+WzzI/UPNM5p98clwRbuqPYONIXN c/rTeQZwUqMPCoy9bDeg2vwNwRiFDo2QXsSU1+QW+s03RQWhN9ozOo8xfrenf8xFelnd 8csutakyAAu5dUEX27lR6PZga5lEwDrMqfFrMM6h7ANboAH4frHZ2e8w6N55qhD37LPF UbAsAYqdqgtQFfcYU/Cv54cHW75nTLjJX3m424zjEGQ86/sIQB9QH+xCRKStNyrDjaO9 WvNNQwi7WhIFxpeIPnPVCPb22vVV5fi/IDE5R4GoK53sUa+HfavbC8iwrkb6o5RRbICu Jkmw== X-Gm-Message-State: AKaTC01H9ZyZ1XmuX6ACraft5gBfxvUlRERBjtMBt80/DXkW+Al6MUGCC1ZZ9zLIJF1vNXjjr2Nn9E87uiAagBUI X-Received: by 10.176.1.112 with SMTP id 103mr18624928uak.154.1480468668423; Tue, 29 Nov 2016 17:17:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Tue, 29 Nov 2016 17:17:47 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 29 Nov 2016 17:17:47 -0800 Message-ID: Subject: Re: [QUIC] Why not be explicit about Stream 3 flow control exception? To: Mike Bishop Content-Type: multipart/alternative; boundary=001a113e2b5815937705427a7979 Archived-At: Cc: IETF QUIC WG , "Aron ." X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 30 Nov 2016 01:18:04 -0000 --001a113e2b5815937705427a7979 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right, agreed. On Tue, Nov 29, 2016 at 3:08 PM, Mike Bishop wrote: > Protocol negotiation (like many areas) needs to be ironed out. I see som= e > obvious paths here: > > - Use ALPN in the TLS handshake > - Implies a general requirement on the crypto handshake to support > app-layer protocol agreement > - Use port numbers, like TCP/UDP already do > - QUIC is a new transport that shares the UDP port space; same > rules for interpreting incoming messages can apply > > > > I tend toward a combination of the two, since we=E2=80=99ve already seen = HTTP/2 > get into the pickle that I still need to do version negotiation even once= I > know it=E2=80=99s some flavor of HTTP. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Aron . > *Sent:* Tuesday, November 29, 2016 10:51 AM > *To:* Jana Iyengar > *Cc:* IETF QUIC WG > *Subject:* Re: [QUIC] Why not be explicit about Stream 3 flow control > exception? > > > > This is interesting. Is there a way for QUIC peer to tell which protocol > over QUIC is used? In other words, at which point do I realize that it's > not HTTP/QUIC I am talking to? Is it for upper-level code to figure out? > > > > On Tue, Nov 29, 2016 at 1:45 PM, Jana Iyengar wrote: > > Hi Aron, > > > > Apologies for getting to this late -- the IETF kept me busy. > > > > [draft-hamilton-quic-transport-protocol-01] states (p. 35): > > > > o The crypto handshake stream, Stream 1, MUST NOT be subject to > congestion control or connection-level flow control, but MUST be > subject to stream-level flow control. > o An application MAY exclude specific stream IDs from connection-level > flow control. If so, these streams MUST NOT be subject to > connection-level flow control. > > > > The second bullet point is obviously about Stream 3. Seeing that there i= s > no way(?) to negotiate which streams are to be excluded, why not spell ou= t > that Streams 1 and 3 are not subject to connection-level congestion contr= ol? > > > > The second bullet point is about any application-chosen stream. An > application may choose to not exempt any stream if there are no special > streams. > > > > This need not be negotiated on the wire, but can be known for any given > application. Specifically, the http-mapping draft is the document which, = in > the current design, should say that stream 3 should be excluded from > connection-level flow control. > > > > - jana > > > > > --001a113e2b5815937705427a7979 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, agreed.

On Tue, Nov 29, 2016 at 3:08 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

Protocol negotiation (like many areas) needs to be i= roned out.=C2=A0 I see some obvious paths here:

  • Use ALPN in the TLS handshake
    • Implies a general requirement on the crypto handshake to support app-lay= er protocol agreement
  • Use port numbers, like TCP/UDP already do
    • QUIC is a new transport that shares the UDP port space; same rules for i= nterpreting incoming messages can apply

=C2=A0

I tend toward a combination of the two, since we=E2= =80=99ve already seen HTTP/2 get into the pickle that I still need to do ve= rsion negotiation even once I know it=E2=80=99s some flavor of HTTP.=

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Aron .
Sent: Tuesday, November 29, 2016 10:51 AM
To: Jana Iyengar <jri@google.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: [QUIC] Why not be explicit about Stream 3 flow control = exception?

=C2=A0

This is interesting.=C2=A0 Is there a way for QUIC p= eer to tell which protocol over QUIC is used?=C2=A0 In other words, at whic= h point do=C2=A0I=C2=A0realize that it's not HTTP/QUIC I am talking to?= =C2=A0 Is it for upper-level code to figure out?

=C2=A0

On Tue, Nov 29, 2016 at 1:45 PM, Jana Iyengar <jri@google.com> wr= ote:

Hi Aron,

=C2=A0

Apologies for getting to this late -- the IETF kept = me busy.

=C2=A0

[draft-hamilton-quic-transport-protocol-01] sta= tes (p. 35):

=C2=A0

o The crypto handshake stream, Stream 1, MUST NOT be= subject to
congestion control or connection-level flow control, but MUST be
subject to stream-level flow control.
o An application MAY exclude specific stream IDs from connection-level
flow control. If so, these streams MUST NOT be subject to
connection-level flow control.

=C2=A0

The second bullet point is obviously about Stream 3.= =C2=A0 Seeing that there is no way(?) to negotiate which streams are to be = excluded, why not spell out that Streams 1 and 3 are not subject to connect= ion-level congestion control?

=C2=A0

The second bullet point is about any application-cho= sen stream. An application may choose to not exempt any stream if there are= no special streams.

=C2=A0

This need not be negotiated on the wire, but can be = known for any given application. Specifically, the http-mapping draft is th= e document which, in the current design, should say that stream 3 should be= excluded from connection-level flow control.

=C2=A0

- jana

=C2=A0

=C2=A0


--001a113e2b5815937705427a7979-- From nobody Tue Nov 29 17:42:01 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77E7126FDC for ; Tue, 29 Nov 2016 17:41:59 -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 Df6O0WIUhWm7 for ; Tue, 29 Nov 2016 17:41:58 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 EA13C129CCD for ; Tue, 29 Nov 2016 17:41:57 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id p16so174015845qta.0 for ; Tue, 29 Nov 2016 17:41:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=jECYJiH38FTgkpMlf5f+6FVfmc4epeHnfeJ0y+VW7jg=; b=sOrAUOBdvU5begvhE2PQ982y56hYp8f9Jq31Y1scwMWK31G7f3BY9lShK8ANnIypkw bg3P1enNySRpqXLmkqwlolmDr2hleKhe+2P/6FJl0vko2PD/1oWPOzE5h7tc0mXeXnO/ tJMVOs9faOucSA75s6tgupjVu8P7gDWbqXJuguVUTeiF2/uw7MjShtvmTGg5d5dC2fq5 bFiR45+lXBQI+TW/1WkgduJHA5OBuYkraAVEg0BahUvmb5rZhmb3E+gEbfQuCgdhPYMh 0uw8CDnVIwFvhuNyTcYNbv5JxHyUnFQmtH76v0Fau/iKFw2VYO6Iddcn+qb7aWLa8HDS hbwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jECYJiH38FTgkpMlf5f+6FVfmc4epeHnfeJ0y+VW7jg=; b=ei1D1gckX4H8xgkJ4LPzQkZLUz7E2hFlWMTQSw54+fZnCqdapzIx109HWAN24KpDhm JyLL4WNRYe91Dmv/srrzgWfhiTx4P5a8LeynMNPJX81POQFTxBCY+jJYY8JT1iBecKoL NRZYSpZuLqTuOOY0yzloY8msxSgFl8hqJwP+vQBfVAJvH3djWaoGUH62XsatiThGgKwI qy8m902Sed+bcyT0y6E8j4YDC3qwFd9cV8Z1k3FPhVPW9hoOs6EotiGZzDhWPJ2ljwDq suvL46Ebjjtfjt+dxg0Vh/KwJLeczMhAubTRho/Pqc0wbmVphW4exfIrSkc3v3gryb8K exXQ== X-Gm-Message-State: AKaTC0267J/k4FjJP13o6poUdAMokhu4nD5IT9r4Qy7Hj0nnI4Vb0ELZ/OfBTDyfzuC4y7zldspLrnhK0QHR7Q== X-Received: by 10.200.48.28 with SMTP id f28mr30476156qte.247.1480470116887; Tue, 29 Nov 2016 17:41:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Tue, 29 Nov 2016 17:41:56 -0800 (PST) From: Martin Thomson Date: Wed, 30 Nov 2016 12:41:56 +1100 Message-ID: Subject: QUIC-TLS pull requests To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 30 Nov 2016 01:41:59 -0000 I've received a fair bit of feedback about the lack of TLS context in the -tls draft. To try to address that, I have done some work on improving things: https://github.com/quicwg/base-drafts/pull/30 Also, there were some serious issues with the use of KEY_PHASE in detecting which packets were protected with which key. I've made some progress on a second PR. This builds on the first one: https://github.com/quicwg/base-drafts/pull/43 Thanks to Dragana for pointing out that I was messing things up. There's a solution here, but I think that Ian's suggestion is better: use the VERSION bit to identify unprotected packets. I plan to create yet another pull request that makes that change. I hope to merge these in the next week or so. Feedback here or on the PRs would be welcome. From nobody Wed Nov 30 21:41:18 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C99129438 for ; Wed, 30 Nov 2016 21:41:15 -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 aKQS4ahcZNkH for ; Wed, 30 Nov 2016 21:41:11 -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 8AEFC126D74 for ; Wed, 30 Nov 2016 21:41:11 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id j65so399857924iof.0 for ; Wed, 30 Nov 2016 21:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Xp16fNI9tOktqvpc06b2a9SjdVUgYgd/+1dt0P6ZN98=; b=wFB/4Rh49dpq3loPI4PnSPPgbE500hYdgL5KsbwTUIX2CZHzSIV0e49wxu7kyQTrlS SLkfoa1a+TInc2+fKv8/C3E9+RA+AcbgQIzWxo8cUErM0Fmo3wUNTEeJ2W3rutkFcJs8 KdxZMVBgAPxtHJnnn5sAkTe2I4hAa7XxITK+Xs5LQK9CUZSk3C9Zk0XvAL3MZZrmkiqO s7iy3KMzmOW3JR8rzhnbGnR7YmTPNQ5VG/363tPTUBuzUvbwAB6loZlb6c28MASdKr2O /cGWxtV2LoXtDQG7so8qUIOzvLOCp+mE6S9cYgdYx6+mxaCLMHaiupcECWPS/fXQqg8a vxxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Xp16fNI9tOktqvpc06b2a9SjdVUgYgd/+1dt0P6ZN98=; b=XNhU5ZF/YzMGxgvVfHDm0cjxzRcqyPriKkBeGRqcLRByAipiJI4aRJkTVoHs1psu+O tKFASJW518z66Gfz/tYL4JHgwy2id2Za+aQnXwTblhqETemjheMq19guDLadRzyRPPVK dSMZxhL5cOWHOdVfuhkqbfVGpLkJndqVkwQRmD0Kj4OHQ2sur99E+zOd86hUBk8wFFNv RBsJdWWnPcrnwiTbiCOiAkW5EJKsiyQvEMtFZ5v/8RZPLCORNhRgCuFamEsMMS3gPt1P 2aj+h20yQQCJzXKfxEHOV7aohx8k1wslVRd+HawllmR6BxQ6yTjW1hzIiT2xLoeKL4AX HL5g== X-Gm-Message-State: AKaTC01zETOM/wnpGriZzTOFynPUO0xFd+AYWFCYGkk2UqAYJJEtRJcZxMUPp1MOTQB/OqT45aGtrI/7Y3F4ig== X-Received: by 10.157.34.198 with SMTP id y64mr15575362ota.225.1480570870621; Wed, 30 Nov 2016 21:41:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.48.56 with HTTP; Wed, 30 Nov 2016 21:41:10 -0800 (PST) From: Martin Duke Date: Wed, 30 Nov 2016 21:41:10 -0800 Message-ID: Subject: Comments on draft-ietf-quic-transport-00 To: IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c042120cee96405429244b4 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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 Dec 2016 05:41:15 -0000 --94eb2c042120cee96405429244b4 Content-Type: text/plain; charset=UTF-8 This draft has made a lot of progress in a short time. Most of my comments center around extensibility, a few DoS vulnerabilites, and a few minor details that make life hard on implementers. Substantive Issues: Section 4.1. Common Header. I know the flags are already changing pretty rapidly here, but it's important to reserve one of the bits to indicate that there is another byte of flags immediately following. This allows new versions that need more public flags to correctly parse the version negotiation fields. It is also appropriate to define exactly what can and cannot change in the public flags field between versions. New versions MUST NOT change the location or existence of the VERSION and MORE_FLAGS bits, as that will break version negotiation. All QUIC hosts, of any version, MUST process at least these two flags to remain compatible with other versions. The same would also be true of CONNECTION_ID were it not for the recommendation in Section 4.2 below. In the same spirit, it might make sense to alter the flow chart so that the VERSION flag is processed first. The PUBLIC_RESET strikes me as a packet that introduces some potential vulnerabilities, and therefore something that future versions might want to substantially revise. Section 4.2. Regular Packets. The version field should immediately follow the public flags, in case future versions mess with the length of the connection ID and the receiver must correctly parse the header to find the version. Regrettably, that means the connection ID will not always be 1 byte into the packet, but we already have to read the bits to find the conn ID. Section 4.2.1. Should receivers enforce that packet numbers are long enough? I don't feel strongly about this either way, but I'm somewhat concerned that sender and receiver may not quite agree what is "in flight" if a STOP_WAITING frame is in flight, lost, or otherwise delayed. For instance, if the sender sends a STOP_WAITING that moves the window by a large number of packets, which is lost, and then sends a packet with a truncated packet number, there could be issues. Perhaps we need to tighten up the language here. Section 4.2.2 Frame types. I think we need an "experimental" frame type, followed by a few bytes of additional identifiers, like option 254 in TCP. Use of these frames would be negotiated by COPT, though to be extra-careful we could also add a length frame (e.g., we might need a new frame during the handshake, before COPT negotiation). Section 4.4. Public Reset. There's been a lot of discussion of this on the list, and I've already said a lot there. Suffice it to say there's work to do to properly authenticate this packet, certainly against off-path attacks, and ideally against eavesdroppers as well. There was also talk of an optional waiting period before tearing down after a Reset, in case the reset is spoofed. Separately, what is the Connection ID we MUST use if the client never generated one? Section 5.1. Version Negotiation. This mechanism is completely vulnerable to DoS by eavesdropper at connection startup. An attacker can sniff the client hello and spoof a server version negotiation message that only advertises nonexistent versions, preventing connection. As with Public Resets, a short waiting period before abandoning the connection would solve the problem. Section 5.2.1. ICSL is missing here, even though it is listed as mandatory in 5.4. Section 5.2.2. You mention "stateless rejects" here, but the draft could really use a full section on it. In particular, it's not clear how QUIC would determine that the crypto handshake was incomplete after one message. I presume this is the case for the stateless reject? Section 5.3. Do we need an ADD_ADDR message to advertise additional addresses, in the event that address is unreachable from the peer's currently known addresses? Section 5.4. Why is ICSL required if there is a default? What is a "silent close option?" Is this negotiated or just a sysctl/sockopt? If negotiated, we need more details. Abrupt shutdown. "Commonly, a public reset is expected to be sent when a packet on an established connection is received by an endpoint that is unable decrypt the packet." I *think* you mean an endpoint should send a public reset should be sent when a packet arrives that does not initiate a handshake and is not associated with an established connection or handshake in progress. If an endpoint with an established connection were to reset on any decryption failure, that would allow an off-path attacker to tear down the connection with a garbage packet if it guesses the conn-id and a reasonable packet number. Section 6. Frame Formats. Another broad comment: one common task will be take a piece of a packet corresponding to a frame and passing it into some handling function. Similarly, we would want some basic sanity checks on frame length (i.e. <= remaining packet length) before starting processing. It would be helpful if it were easy to parse the first few bytes of the frame to find its length. Length computation requires reading the flags, and sometimes checking additional fields that are variable lengths from the start of the frame. This is very cumbersome to implement. If you're trying in plain old C, as I am, the macros are horrendous. Instead, I recommend that all fields necessary for frame length computation are first in the frame. For example, Section 6.1, stream frames: I recommend Data length, if present, comes right after the type field. In Section 6.2, ack frames, "Number Blocks" and "Num Timestamps" should move to the front of the frame. section 6.2 Ack frames: I am unclear about the procedure for including ACK blocks in a particular frame. Delivery of an ACK block a single time is sufficient, but ACK delivery is unreliable. So is a receiver supposed to repeat an ack block again and again, or do it once? I *think* the answer is that if a packet with ACK frame has itself been acknowledged, we need not end that ack block anymore. But it'd be good to explicitly state that. Section 7. PMTU discovery: RFC-Compliant ICMP PMTU messages include the oversize packet's IP header and the first 8 bytes of the transport. This allows TCP to demultiplex the ICMP to the relevant connection/path, and check that the echoed sequence number corresponds to an in-flight segment, and that the segment that would have violated the advertised MTU. As TCP windows increase, it's true that this may be less effective. For QUIC, these messages will contain only the UDP header. I believe this is sufficient to demux to the right connection (QUIC allows the same 4-tuple for multiple connection IDs, but it would be fine to apply it to all such connections), but I see no clear mechanism to prevent a blind attacker that guesses the 4-tuple from forcing a QUIC connection to revert to the min path MTU. Some possibilities: (a) Require routers to send more bytes. This is probably not deployable, and in any case because packet numbers always start at zero this doesn't add much security. (b) Store UDP or IP data. We could require QUIC to store the UDP checksum or IP ID in its send queue, thus allowing it to associate the returned headers with a packet in its queue. This is ugly from a layering perspective and may not be plausible with hardware offload of checksums, various middleboxes, etc. (c) Isolated DF packets. QUIC could pick a long time interval (10 seconds?) in which is sets DF on a single MTU-sized packet (which may have to be padded). QUIC would only accept ICMP messages within an RTT or so of having sent one of these MTU probe packets, or until it's acked. Thus the probabability an off-path attacker could time it correctly is (RTT / 10 sec). If there's an extended burst of ICMP to overcome this, that's probably an attack indication to handle either in IP, the firewall, or at worst in QUIC. I have some language to codify this, and if we agree this is the right approach I can share it. Section 9. Why are BLOCKED frames a MUST? They are sort of like TCP persist probes, but WINDOW_UPDATE messages are delivered reliably in QUIC, so BLOCKED has no input on operation. If the purpose is debugging only this ought to be no more than a SHOULD, and probably a MAY. 9.1. Similarly, I don't see how there can be deadlock if WINDOW_UPDATE MUST be retransmitted. Nits: Abstract: "from from" -> "from" Section 4. Packet Types and Formats. Per the consensus in Seoul, all values are now big-endian. Section 6.2 Ack Frame. "It is recommended for the sender to send the most recent largest packet it has received in an ack..." --> "It is recommended for the sender to send the most recent 'largest acked' field it has received in an ack..." Section 6.10 GOAWAY frame. "will likely be aborted..." -> "will likely be closed..." Section 7. Withholding packets to wait for more frames: I suggest some sort of bound on how long the sender can wait. Section 7: Retransmitted Frames. What is the force of "the sender SHOULD only send frames..." when the specifics below it cover all cases with MUST? --94eb2c042120cee96405429244b4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This draft has made a lot of progress in a short time= . Most of my comments center around extensibility, a few DoS vulnerabilites= , and a few minor details that make life hard on implementers.
Substantive Issues:
Section 4.1. Common Header. I kn= ow the flags are already changing pretty rapidly here, but it's importa= nt to reserve one of the bits to indicate that there is another byte of fla= gs immediately following. This allows new versions that need more public fl= ags to correctly parse the version negotiation fields.

=
It is also appropriate to define exactly what can and cannot change in= the public flags field between versions. New versions MUST NOT change the = location or existence of the VERSION and MORE_FLAGS bits, as that will brea= k version negotiation. All QUIC hosts, of any version, MUST process at leas= t these two flags to remain compatible with other versions. The same would = also be true of CONNECTION_ID were it not for the recommendation in Section= 4.2 below.

In the same spirit, it might make sens= e to alter the flow chart so that the VERSION flag is processed first. The = PUBLIC_RESET strikes me as a packet that introduces some potential vulnerab= ilities, and therefore something that future versions might want to substan= tially revise.

Section 4.2. Regular Packets. The v= ersion field should immediately follow the public flags, in case future ver= sions mess with the length of the connection ID and the receiver must corre= ctly parse the header to find the version. Regrettably, that means the conn= ection ID will not always be 1 byte into the packet, but we already have to= read the bits to find the conn ID.

Section 4.2.1.= Should receivers enforce that packet numbers are long enough? I don't = feel strongly about this either way, but I'm somewhat concerned that se= nder and receiver may not quite agree what is "in flight" if a ST= OP_WAITING frame is in flight, lost, or otherwise delayed. For instance, if= the sender sends a STOP_WAITING that moves the window by a large number of= packets, which is lost, and then sends a packet with a truncated packet nu= mber, there could be issues.=C2=A0

Perhaps we need= to tighten up the language here.

Section 4.2.2 Fr= ame types. I think we need an "experimental" frame type, followed= by a few bytes of additional identifiers, like option 254 in TCP. Use of t= hese frames would be negotiated by COPT, though to be extra-careful we coul= d also add a length frame (e.g., we might need a new frame during the hands= hake, before COPT negotiation).

Section 4.4. Publi= c Reset. There's been a lot of discussion of this on the list, and I= 9;ve already said a lot there. Suffice it to say there's work to do to = properly authenticate this packet, certainly against off-path attacks, and = ideally against eavesdroppers as well. There was also talk of an optional w= aiting period before tearing down after a Reset, in case the reset is spoof= ed.

Separately, what is the Connection ID we MUST = use if the client never generated one?

Section 5.1= . Version Negotiation. This mechanism is completely vulnerable to DoS by ea= vesdropper at connection startup. An attacker can sniff the client hello an= d spoof a server version negotiation message that only advertises nonexiste= nt versions, preventing connection.

As with Public= Resets, a short waiting period before abandoning the connection would solv= e the problem.

Section 5.2.1. ICSL is missing here= , even though it is listed as mandatory in 5.4.

Se= ction 5.2.2. You mention "stateless rejects" here, but the draft = could really use a full section on it. In particular, it's not clear ho= w QUIC would determine that the crypto handshake was incomplete after one m= essage. I presume this is the case for the stateless reject?

=
Section 5.3. Do we need an ADD_ADDR message to advertise additio= nal addresses, in the event that address is unreachable from the peer's= currently known addresses?

Section 5.4. Why is IC= SL required if there is a default?

What is a "= ;silent close option?" Is this negotiated or just a sysctl/sockopt? If= negotiated, we need more details.

Abrupt shutdown= . "Commonly, a public reset is expected to be sent when a
= =C2=A0 =C2=A0 =C2=A0 =C2=A0packet on an established connection is received = by an endpoint
=C2=A0 =C2=A0 =C2=A0 =C2=A0that is unable decrypt = the packet."

I *think* you mean an endpoint s= hould send a public reset should be sent when a packet arrives that does no= t initiate a handshake and is not associated with an established connection= or handshake in progress. If an endpoint with an established connection we= re to reset on any decryption failure, that would allow an off-path attacke= r to tear down the connection with a garbage packet if it guesses the conn-= id and a reasonable packet number.

Section 6. Fram= e Formats. Another broad comment: one common task will be take a piece of a= packet corresponding to a frame and passing it into some handling function= . Similarly, we would want some basic sanity checks on frame length (i.e. &= lt;=3D remaining packet length) before starting processing. It would be hel= pful if it were easy to parse the first few bytes of the frame to find its = length. Length computation requires reading the flags, and sometimes checki= ng additional fields that are variable lengths from the start of the frame.= This is very cumbersome to implement. If you're trying in plain old C,= as I am, the macros are horrendous.

Instead, I re= commend that all fields necessary for frame length computation are first in= the frame.

For example, Section 6.1, stream frame= s: I recommend Data length, if present, comes right after the type field.

In Section 6.2, ack frames, "Number Blocks&quo= t; and "Num Timestamps" should move to the front of the frame.

section 6.2 Ack frames: I am unclear about the proce= dure for including ACK blocks in a particular frame. Delivery of an ACK blo= ck a single time is sufficient, but ACK delivery is unreliable. So is a rec= eiver supposed to repeat an ack block again and again, or do it once? I *th= ink* the answer is that if a packet with ACK frame has itself been acknowle= dged, we need not end that ack block anymore. But it'd be good to expli= citly state that.

Section 7. PMTU discovery: RFC-C= ompliant ICMP PMTU messages include the oversize packet's IP header and= the first 8 bytes of the transport. This allows =C2=A0TCP to demultiplex t= he ICMP to the relevant connection/path, and check that the echoed sequence= number corresponds to an in-flight segment, and that the segment that woul= d have violated the advertised MTU. As TCP windows increase, it's true = that this may be less effective.

For QUIC, these m= essages will contain only the UDP header. I believe this is sufficient to d= emux to the right connection (QUIC allows the same 4-tuple for multiple con= nection IDs, but it would be fine to apply it to all such connections), but= I see no clear mechanism to prevent a blind attacker that guesses the 4-tu= ple from forcing a QUIC connection to revert to the min path MTU. Some poss= ibilities:
=C2=A0 =C2=A0 (a) Require routers to send more bytes. = This is probably not deployable, and in any case because packet numbers alw= ays start at zero this doesn't add much security.
=C2=A0 =C2= =A0 (b) Store UDP or IP data. We could require QUIC to store the UDP checks= um or IP ID in its send queue, thus allowing it to associate the returned h= eaders with a packet in its queue. This is ugly from a layering perspective= and may not be plausible with hardware offload of checksums, various middl= eboxes, etc.
=C2=A0 =C2=A0 (c) Isolated DF packets. QUIC could pi= ck a long time interval (10 seconds?) in which is sets DF on a single MTU-s= ized packet (which may have to be padded). QUIC would only accept ICMP mess= ages within an RTT or so of having sent one of these MTU probe packets, or = until it's acked. Thus the probabability an off-path attacker could tim= e it correctly is (RTT / 10 sec). If there's an extended burst of ICMP = to overcome this, that's probably an attack indication to handle either= in IP, the firewall, or at worst in QUIC.=C2=A0 I have some language to co= dify this, and if we agree this is the right approach I can share it.
=

Section 9. Why are BLOCKED frames a MUST? They are sort= of like TCP persist probes, but WINDOW_UPDATE messages are delivered relia= bly in QUIC, so BLOCKED has no input on operation. If the purpose is debugg= ing only this ought to be no more than a SHOULD, and probably a MAY.
<= div>
9.1. Similarly, I don't see how there can be deadloc= k if WINDOW_UPDATE MUST be retransmitted.

Nits:
Abstract: "from from" -> "from"
Section 4. Packet Types and Formats. Per the consensus in Seou= l, all values are now big-endian.

Section 6.2 Ack = Frame. "It is recommended for the sender to send the most recent large= st packet it has received in an ack..." -->

"It is recommended for the sender to send the most recent 'large= st acked' field it has received in an ack..."=C2=A0

=
Section 6.10 GOAWAY frame. "will likely be aborted..."= -> "will likely be closed..."

Sectio= n 7. Withholding packets to wait for more frames: I suggest some sort of bo= und on how long the sender can wait.

Section 7: Re= transmitted Frames. What is the force of "the sender SHOULD only send = frames..." when the specifics below it cover all cases with MUST?
--94eb2c042120cee96405429244b4-- From nobody Wed Nov 30 21:51:01 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6C5129671 for ; Wed, 30 Nov 2016 21:50:58 -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 tFVK3_hHylsx for ; Wed, 30 Nov 2016 21:50:56 -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 5875D129BDB for ; Wed, 30 Nov 2016 21:50:56 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id j65so400322462iof.0 for ; Wed, 30 Nov 2016 21:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uKNn2zg9adpV0IZ2XBo31GxCyA9aH7Zp7oae6O4Lpsw=; b=v88ruAobHM8OnvlcZVAjT6an6iw0VxG5bh58QLEIZZEaiSCd5wRMWalqJzfBAgGXnY DvGX8lFBylKwPSc01aRT5xeaj9kNO6/m/8eJiL3s2880d8tZiuQn+msGN5cHbcsxdK7a USYA4y9+ByU6CFW8YGm2F43L3E/1v/4wYR/esd5h0eJ15wAX/FFM2A+HJXHnAZ0pj4+t GG6OzHS5zMRcdWQK1kweVUA9f9wY/5RdizRBHiT4NSx8oqqKarTFshCrASDIS6pSkZ5X xlAAgAIpDbsQxfKdPVcbj4HuTbVBZxvNHRvA/sWHYt1GM4yBkY+MAEE28Ex3twyvTAsd ZzcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uKNn2zg9adpV0IZ2XBo31GxCyA9aH7Zp7oae6O4Lpsw=; b=V2Y4LIZkJwVLRaxt3TTb/vwhjkd2IxBMxbx8YZOsVsB3ARmHjFHzP+sgYijv+1UgKk MnJrG1yn2ryH9ZY3ct6CxyRtx7omzKQxS/WyTRa1cIUpaUDByANtzJ/AClG1OV5f45/s tvDf1wRxnQ7XAGd3eHFE38jlhpABubCK1RodD+S2GEwAog8p9fdA2xm+y61quzqd1KBM 4u/Y685REt22FMDeEx+YLE8LVTXOVkCT3EzML52dihwHVIk525P4dxCSiw/q5tjJNJie yYa5swmffl26oWiZwzwusWtfZCQ7EGzAHkqE+Dl7dDMOUWOrLt7DZyyjDkFWS0jvgE/D 4JCg== X-Gm-Message-State: AKaTC03QUjww0m9U4FdRbccMGL1km0+Ex47e5vAAC/K+s0I5ZzWs8d+wBFuWQJC/8ifPqUUE6OVZqO2YXEhijw== X-Received: by 10.202.96.197 with SMTP id u188mr17642250oib.30.1480571455761; Wed, 30 Nov 2016 21:50:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.48.56 with HTTP; Wed, 30 Nov 2016 21:50:55 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Wed, 30 Nov 2016 21:50:55 -0800 Message-ID: Subject: Re: QUIC-TLS pull requests To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113d3c5eaf73b0054292673f Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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 Dec 2016 05:50:59 -0000 --001a113d3c5eaf73b0054292673f Content-Type: text/plain; charset=UTF-8 The interface document is a huge improvement. What I think is missing is the various transport parameters that I believe the quic-transport document says QUIC will deliver to TLS to include in handshake messages, and similarly pull from TLS for processin when decrypted. On Tue, Nov 29, 2016 at 5:41 PM, Martin Thomson wrote: > I've received a fair bit of feedback about the lack of TLS context in > the -tls draft. To try to address that, I have done some work on > improving things: > > https://github.com/quicwg/base-drafts/pull/30 > > Also, there were some serious issues with the use of KEY_PHASE in > detecting which packets were protected with which key. I've made some > progress on a second PR. This builds on the first one: > > https://github.com/quicwg/base-drafts/pull/43 > > Thanks to Dragana for pointing out that I was messing things up. > There's a solution here, but I think that Ian's suggestion is better: > use the VERSION bit to identify unprotected packets. I plan to create > yet another pull request that makes that change. > > I hope to merge these in the next week or so. Feedback here or on the > PRs would be welcome. > > --001a113d3c5eaf73b0054292673f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The interface document is a huge improvement. What I think= is missing is the various transport parameters that I believe the quic-tra= nsport document says QUIC will deliver to TLS to include in handshake messa= ges, and similarly pull from TLS for processin when decrypted.

On Tue, Nov 29, 2016 at = 5:41 PM, Martin Thomson <martin.thomson@gmail.com> wr= ote:
I've received a fair bit of feed= back about the lack of TLS context in
the -tls draft.=C2=A0 To try to address that, I have done some work on
improving things:

https://github.com/quicwg/base-drafts/pull/30<= br>
Also, there were some serious issues with the use of KEY_PHASE in
detecting which packets were protected with which key.=C2=A0 I've made = some
progress on a second PR.=C2=A0 This builds on the first one:

https://github.com/quicwg/base-drafts/pull/43<= br>
Thanks to Dragana for pointing out that I was messing things up.
There's a solution here, but I think that Ian's suggestion is bette= r:
use the VERSION bit to identify unprotected packets.=C2=A0 I plan to create=
yet another pull request that makes that change.

I hope to merge these in the next week or so.=C2=A0 Feedback here or on the=
PRs would be welcome.


--001a113d3c5eaf73b0054292673f-- From nobody Wed Nov 30 22:00:48 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E8E129519 for ; Wed, 30 Nov 2016 22:00:47 -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 DyRCRn93olvx for ; Wed, 30 Nov 2016 22:00:45 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 29315126D74 for ; Wed, 30 Nov 2016 22:00:45 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id m5so262789924ioe.3 for ; Wed, 30 Nov 2016 22:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+7pMtVpiP0JSWbtEebiVDl5Zglzf7vN+5WNYKS5Gdsc=; b=zZjL88L+Q+vc8iOLkE3f5FG5Z6jehVhQvJQIBry1rBoluNOrjQ93041vypZMbabP++ cgQVFpa1LnawfjaYcjKonoUEc11oi/YIghTye0s4P9EDTH8KolT03f2oP/pQuq6kkqsU SMWaDbuq3Q6haKhrJ/HdSzi6Mljn/lc2a7m1TBRugurRuCmeuokpbVwQjZJPUIYpUr3q Pa+ZSewSv9PhcNZaZCdIdzSJ2n9yBXl75UfiRBy6qw5SgrhU+xJJHcW07sHYctj0J4hi cZuJ0LTegF44U0KEdnLOUXxOUT662ErA9qJVk9rT3nQTiNIfWErnY4k2WzBLWFgchBl8 WvFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+7pMtVpiP0JSWbtEebiVDl5Zglzf7vN+5WNYKS5Gdsc=; b=hjMqdrSWRzVFUt+Vd82xN85wYzd1pN7o6F9ZLwHHnHRyukaRV90VpUXFe+EytWqUy1 zlquBqmPsNBCpqfm+2jIu/W4pE+NsjDE8IL9QLJFjgJkNaai6QdYcKTI/cZkEipNjWBT E1iDuoeA1wAvd+m3HpKKx4IM7CE/A3NYVIc8vcGzvPGzeVbgFQzi4gK0QfAG70PYlLV+ eT1rKMZyolHSQZc0Mw0ogCzKFfmPa45TqreeaXzyAMeeafgCjJ6ZBtn+MxvTSQHE216I 1B2Eo9IXuEzEwPSsCqe3n4BvN0w/Kgpp+WATz0wz3aRX/lElUM9CohgozR986OIqDmDF T8lw== X-Gm-Message-State: AKaTC01qZhFzpIXDLq/mfs4IYQCeO1/DjrNuGainnICZ/72Ut5LdDlFh1oFON0QKNHzcx2Pml7Nfa8SZtW4C0w== X-Received: by 10.107.165.139 with SMTP id o133mr29907851ioe.42.1480572044523; Wed, 30 Nov 2016 22:00:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.12.81 with HTTP; Wed, 30 Nov 2016 22:00:44 -0800 (PST) In-Reply-To: References: From: "Aron ." Date: Thu, 1 Dec 2016 01:00:44 -0500 Message-ID: Subject: Re: Comments on draft-ietf-quic-transport-00 To: Martin Duke Content-Type: multipart/alternative; boundary=001a1141f18cc73f420542928a4e Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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 Dec 2016 06:00:47 -0000 --001a1141f18cc73f420542928a4e Content-Type: text/plain; charset=UTF-8 On Thu, Dec 1, 2016 at 12:41 AM, Martin Duke wrote: > Section 6. Frame Formats. Another broad comment: one common task will be > take a piece of a packet corresponding to a frame and passing it into some > handling function. Similarly, we would want some basic sanity checks on > frame length (i.e. <= remaining packet length) before starting processing. > It would be helpful if it were easy to parse the first few bytes of the > frame to find its length. Length computation requires reading the flags, > and sometimes checking additional fields that are variable lengths from the > start of the frame. This is very cumbersome to implement. If you're trying > in plain old C, as I am, the macros are horrendous. Have the frame handling function return the number of bytes it consumed or -1 on error. Aron. --001a1141f18cc73f420542928a4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1, 2016 at 12:= 41 AM, Martin Duke <martin.h.duke@gmail.com> wrote:=C2=A0
Section 6. Frame = Formats. Another broad comment: one common task will be take a piece of a p= acket corresponding to a frame and passing it into some handling function. = Similarly, we would want some basic sanity checks on frame length (i.e. <= ;=3D remaining packet length) before starting processing. It would be helpf= ul if it were easy to parse the first few bytes of the frame to find its le= ngth. Length computation requires reading the flags, and sometimes checking= additional fields that are variable lengths from the start of the frame. T= his is very cumbersome to implement. If you're trying in plain old C, a= s I am, the macros are horrendous.

Have the frame=C2=A0handling func= tion return the number of bytes it consumed or -1 on error.

=C2=A0 Aron.

--001a1141f18cc73f420542928a4e--
For what it's worth ...

=
On Tue, Nov 8, 2016 at 3:41 PM, Eric Rescorla <ekr@r= tfm.com> wrote:
On Tue, Nov 8, 2016 at 1:32 PM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
m= aybe just a wiki page for self-registration during the pre-rfc period would= suffice? permissionless is good.

A wiki seems fine here. If people are going to be malicious, they&#= 39;re going to be malicious.

-Ekr

I'm OK with the wiki page for s= elf-registration happening, but I'm hoping that experimental versions a= ren't widely deployed for long periods of time, which is what would jus= tify more elaborate version number allocation schemes.

I'm happy to listen to people explain to me that I have nothin= g to worry about, of course.

Spencer, as AD
<= /div>
--001a1140865a2eba8e0540d12949-- From nobody Tue Nov 8 14:14:53 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593EC1295DD for ; Tue, 8 Nov 2016 14:14:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pw1pugQ1g8Xr for ; Tue, 8 Nov 2016 14:14:51 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 146231295BC for ; Tue, 8 Nov 2016 14:14:51 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id p9so161241691vkd.3 for ; Tue, 08 Nov 2016 14:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1cL1yagqVKMncoDEMC+9EHluBVjivF6p5NjlYjsosr8=; b=oH+RKORyqyfHNLEf6ZA4PID+0JfOF/K5Y6VQk/pTftM6Vm3y4ga8b4qeb22DqymMD+ 10JtIBUNAi42BMQN57P06wt0xEZ9bQ95OvFeP2ajSgoVsqVkMq1iXjNRqV+irlbIRgjW KcjxDuoNig5zasEnIJYwNEXWzLWrwlk4LMLkET6SAlaDMgUkUa3nbFrQ2CG6AxX8b765 FrKwq2HlFT87Tzgxn/DqylPgu7iD4M9s1rcfQxc632pd2dssXALuitQfjF31b33gHBJH Wh2DKxipqYNgNBVoy+KzqWvuIfhbNZHW5n7VQW09+ZIafGZGN51VgShPxj7uTALjOG1S oojg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1cL1yagqVKMncoDEMC+9EHluBVjivF6p5NjlYjsosr8=; b=dtKjkzcaRXWPpElXQ3prvMq6ElYzFlOiQldIVzx7Vc0fJj/2KxqYzVXB4wxxRBl9ah PzvIEbq1tohWJTogs20Z5S05nDNfyGEsmLXvvV2rjyupUk+WwZb3Dr6Nd1VtpNQN19LR SQie2XQNdsoVetOjLFrx1ntkpRmN30IiXqRFM+WVjUht6hZrLW++HDsL1f8IDtF9C5lM IBzYiQuDKDlvtSCFu9zOnGQkL+yMNYTKYfPfgk+gQYAErXxvqoERNM6XH8nsFBAEkbnY 0fFv7F+cpMQBJ/XmR0SdT8UJ+2ydJ0foFN1XlqfFHS2k8yUQq/p/SbOfvpBx4hnGT7ES Pl5A== X-Gm-Message-State: ABUngvekUd/50ufA8QwW94kuvpFvgSsVJ2nRi0z6sTS+/O8fSF8s9ceffYAuN9aAkx3QP09IbIQax5WGuw+LFelT X-Received: by 10.31.188.141 with SMTP id m135mr9788937vkf.24.1478643290054; Tue, 08 Nov 2016 14:14:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Tue, 8 Nov 2016 14:14:49 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 8 Nov 2016 14:14:49 -0800 Message-ID: To: Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary=001a114397040e40810540d1788e Archived-At: Cc: Eric Rescorla , Ian Swett , Ted Hardie , Patrick McManus , quic@ietf.org, Martin Thomson Subject: Re: [QUIC] Protocol identifiers for drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 08 Nov 2016 22:14:52 -0000 --001a114397040e40810540d1788e Content-Type: text/plain; charset=UTF-8 Wiki SGTM, though honestly I don't think it's going to be useful. Let's be clear that we are talking about (i) folks who can change both servers and clients, and (ii) a space of ~4G versions, and the chances of version collision in this space are astronomically low. Spencer -- my expectation is that the experimental version space will be used for continued experimentation on QUIC, whcih will hopefully feed back into the standards process. This is useful now as we're working towards the first standards, but I expect this will be useful after the first standards are published for continued experimentation that can inform a subsequent QUIC standard version. If an experimental version is deployed for a longer period of time, that's still fine IMO, there's 4G versions in that space. We won't run out of versions for several lifetimes. On Tue, Nov 8, 2016 at 1:52 PM, Spencer Dawkins at IETF < spencerdawkins.ietf@gmail.com> wrote: > For what it's worth ... > > On Tue, Nov 8, 2016 at 3:41 PM, Eric Rescorla wrote: > >> On Tue, Nov 8, 2016 at 1:32 PM, Patrick McManus >> wrote: >> >>> maybe just a wiki page for self-registration during the pre-rfc period >>> would suffice? permissionless is good. >>> >> >> A wiki seems fine here. If people are going to be malicious, they're >> going to be malicious. >> >> -Ekr >> > > I'm OK with the wiki page for self-registration happening, but I'm hoping > that experimental versions aren't widely deployed for long periods of time, > which is what would justify more elaborate version number allocation > schemes. > > I'm happy to listen to people explain to me that I have nothing to worry > about, of course. > > Spencer, as AD > --001a114397040e40810540d1788e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Wiki SGTM, though honestly I don't think it's goin= g to be useful. Let's be clear that we are talking about (i) folks who = can change both servers and clients, and (ii) a space of ~4G versions, and = the chances of version collision in this space are astronomically low.
=
Spencer -- my expectation is that the experimental version s= pace will be used for continued experimentation on QUIC, whcih will hopeful= ly feed back into the standards process. This is useful now as we're wo= rking towards the first standards, but I expect this will be useful after t= he first standards are published for continued experimentation that can inf= orm a subsequent QUIC standard version. If an experimental version is deplo= yed for a longer period of time, that's still fine IMO, there's 4G = versions in that space. We won't run out of versions for several lifeti= mes.


On Tue, Nov 8, 2016 at 1:52 PM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
For what it's worth ...

On Tue, No= v 8, 2016 at 3:41 PM, Eric Rescorla <ekr@rtfm.com> wrote:
On Tue, Nov 8, 2016 at 1:32 PM, Patrick McManu= s <pmcmanus@mozilla.com> wrote:
maybe just a wiki page for self-registration duri= ng the pre-rfc period would suffice? permissionless is good.

A wiki seems fine here. If people are go= ing to be malicious, they're going to be malicious.

-Ekr

I= 'm OK with the wiki page for self-registration happening, but I'm h= oping that experimental versions aren't widely deployed for long period= s of time, which is what would justify more elaborate version number alloca= tion schemes.

I'm happy to listen to peopl= e explain to me that I have nothing to worry about, of course.
Spencer, as AD

--001a114397040e40810540d1788e-- From nobody Wed Nov 9 00:22:29 2016 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 0B4311296CF; Wed, 9 Nov 2016 00:22: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: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147867974901.25319.12391433719148448392.idtracker@ietfa.amsl.com> Date: Wed, 09 Nov 2016 00:22:29 -0800 Archived-At: Cc: quic@ietf.org, lars@netapp.com, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org Subject: [QUIC] quic - New Interim Meeting Request X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-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, 09 Nov 2016 08:22:29 -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-2017-quic-01 --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Lars Eggert City: Tokyo Country: JP Session 1: Date: 2017-01-24 Start Time: 09:30 Asia/Tokyo Duration: 07:30 Remote Participation Information: To be determined Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-17-01/arrangements.md Session 2: Date: 2017-01-25 Start Time: 09:30 Asia/Tokyo Duration: 07:30 Remote Participation Information: To be determined Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-17-01/arrangements.md Session 3: Date: 2017-01-26 Start Time: 09:30 Asia/Tokyo Duration: 07:30 Remote Participation Information: To be determined Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-17-01/arrangements.md --------------------------------------------------------- From nobody Wed Nov 9 04:20:37 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FDC12995F for ; Wed, 9 Nov 2016 04:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVAm7NcNf2MK for ; Wed, 9 Nov 2016 04:20:34 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 372BD129759 for ; Wed, 9 Nov 2016 04:20:34 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 872E01A0EF9; Wed, 9 Nov 2016 13:20:33 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_2D081CD2-A083-4DFC-A3E2-E51DBF4B0A40"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Wed, 9 Nov 2016 13:20:32 +0100 Message-Id: <76988FFC-CFA9-4B60-B60B-39F4ABCC6051@trammell.ch> References: To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: quic@ietf.org, Patrick McManus Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 09 Nov 2016 12:20:36 -0000 --Apple-Mail=_2D081CD2-A083-4DFC-A3E2-E51DBF4B0A40 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, all, > On 08 Nov 2016, at 08:08, Jana Iyengar wrote: >=20 > On Mon, Nov 7, 2016 at 8:13 PM, Patrick McManus = wrote: > hey Jana, >=20 > On Mon, Nov 7, 2016 at 6:30 PM, Jana Iyengar wrote: >=20 > It does. I still think, perhaps naively, that these wire formats are = separable. If QUIC version shows up in 3 places, it obeys the wire = format of the 3 places where it shows up. I can see how different = endian-nesses can leak though, but my point was that these could be = well-specified where there's confusion. That said, I think your point is = "avoid the confusion in the first place." This was my point, at least. Question for the design on the Google side: was this design choice taken = as self-evident, or is there benchmarking on the performance impact = in-protocol? The tradeoff between performance and the impact on = violation principle of least surprise on debugging effort would be = easier to evaluate with numbers in at least one column. :) > This may be worth a consensus call, since the spec says little-endian = currently, and we'll have to decide what to do upon adoption. Though I'm happily dancing around it, I agree with Martin about this = being a sarlacc pit. I guess those of us who have an opinion should find = a time before the WG meeting, then? Cheers, Brian --Apple-Mail=_2D081CD2-A083-4DFC-A3E2-E51DBF4B0A40 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYIxSRAAoJEIoSt78L6kajJJYQAIG2JeioJDIXBLwVQTuvo9xH Q8rV2sP3dcUDiceCU2V2sP4gxPLg12o1O9BPgM7LeZ3SQIYOZAKDMI7p6dueuGcZ KPV9DWsF3hGU241KRZUvbafao7P5hrzkzAz6RgYy6Qt/VL1thrgeLlhvMOTmPlsP dqdnCDqkYm7MCgxTLvejMCwc6q8v3Thd4njBt8tTQIaeESahCNHCTnhGKn3rwMQU E8HbC6h6FKUolyERSBfzQgzGn+ZdE23pDL6YsRXq3AK2U94DVWG8S9rNK185T+Ee f9WXSUx0RlwcTqPdU4KicUyZSA6qkk6lAHu0X7KwQpUTnZTN01KBxuuWax2i7pKW z3XaQNEBQmKSUFCUUY35HgfW4n31jpTU37f/onyYgEIFOh2QYRx2INSxbae4Jjng wPLFhI5sBOOJkuQqKHCf57cRv/ISIyNIQCnORg13r9AHyIB7v02WAT/v11ohroMo aSMWmI3Vf5ty9OCf1gWyI4udBr+0EGhjk/Xmei3MPxA9Vr/zfWYgjMXV2Ow3VWyZ nKXXSve/L1IoLqUpSV+N09zVgvOZtWkNwsgGigqdCR3I7xRoVeOUmjlQqIkoz9ZU ubSkRbyJ4pTiLqnZvmQt/fcQ0OH9radbJrCSVkLBkyLnRjUYyNcGNydFSDLCwyvK UsYy7A3JTOUArQ6Cw+e4 =JRxg -----END PGP SIGNATURE----- --Apple-Mail=_2D081CD2-A083-4DFC-A3E2-E51DBF4B0A40-- From nobody Wed Nov 9 09:00:57 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACA0129426 for ; Wed, 9 Nov 2016 09:00:55 -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 UsrTIv_OwehY for ; Wed, 9 Nov 2016 09:00:54 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002: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 ED156129446 for ; Wed, 9 Nov 2016 09:00:53 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id v78so80101130ybe.3 for ; Wed, 09 Nov 2016 09:00:53 -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=Lu4QarHq1EhUDcg+Z9LnxHYAIYavhzSVJS0rsEmpm3g=; b=0W/k9qkIlVt5mOxK68OEgAE2dcKdA5417J4eBcx3fcFnFaTAQlRZ8iNPUqTGqAfUqq OPyS9JR7FTvcvY+7NoVLXe9IRZmDuxmTdvk0V8sOwujQA71MxCFhfnE+38r4/XIuvIqP ZUFAod0K2FBUJG2KRdwuU3tUkkx1U7KYVfQBmCmNKQWyhn360CmAF2kS+yvmrMEgEITR pF6HYfvBpD+IiSHZmVpKIrFaAjWdfBhAFl3XDkDBs+Op7VsNNBht20l7UtKTz4FQ/tXS w8FY8kXTJnekBaEC44hdKt/vMIQOin0nm4OrMkJk+iLm3/OckM2AWqGrZ8zbCr35WOen +i/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lu4QarHq1EhUDcg+Z9LnxHYAIYavhzSVJS0rsEmpm3g=; b=kOXvaojK6DhfCAOprs6OPk6IFqiPzTppkwiXPo88QVabZCi2CNgODuUVZoK8Lqi72L jHWMn4LZJukTttRAS9YL7j031aOVPt2/D36X8f+rR5uRyBYgewxrc9hyzf7wfeAhAc+a nFHnYaVA5z3Y8bx8qLEFGrSDvSNQu523v9t710SFWTuqwKsJ8eeeg+K5E/q2cpwWS1qK M1JmOD+hc7BJtCiZgEa/GCVAHgZwQGSO/xC8tWDUDyq0BQ7iejxksOowe1snU1H1tgAA YMHoJ/KOMd20SPh32m75vVy08VaJ5tHTTLF3TChoZCagPt+zDIiJLRosC40thyniflpb vhFA== X-Gm-Message-State: ABUngvfdVuyXXdwvjbor7jHUTWzeO2Y4etubLg8R1AQfhDv7v8TK3l5kAPNi4B9sBo4movjESEUh3lkRL3EEjA== X-Received: by 10.37.171.169 with SMTP id v38mr574220ybi.80.1478710853239; Wed, 09 Nov 2016 09:00:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Wed, 9 Nov 2016 09:00:12 -0800 (PST) In-Reply-To: <76988FFC-CFA9-4B60-B60B-39F4ABCC6051@trammell.ch> References: <76988FFC-CFA9-4B60-B60B-39F4ABCC6051@trammell.ch> From: Eric Rescorla Date: Wed, 9 Nov 2016 09:00:12 -0800 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=94eb2c050f4a2266b60540e13360 Archived-At: Cc: Jana Iyengar , quic@ietf.org, Patrick McManus Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 09 Nov 2016 17:00:56 -0000 --94eb2c050f4a2266b60540e13360 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 9, 2016 at 4:20 AM, Brian Trammell wrote: > hi Jana, all, > > > On 08 Nov 2016, at 08:08, Jana Iyengar wrote: > > > > On Mon, Nov 7, 2016 at 8:13 PM, Patrick McManus > wrote: > > hey Jana, > > > > On Mon, Nov 7, 2016 at 6:30 PM, Jana Iyengar wrote: > > > > > > > It does. I still think, perhaps naively, that these wire formats are > separable. If QUIC version shows up in 3 places, it obeys the wire format > of the 3 places where it shows up. I can see how different endian-nesses > can leak though, but my point was that these could be well-specified where > there's confusion. That said, I think your point is "avoid the confusion in > the first place." > > This was my point, at least. > > Question for the design on the Google side: was this design choice taken > as self-evident, or is there benchmarking on the performance impact > in-protocol? The tradeoff between performance and the impact on violation > principle of least surprise on debugging effort would be easier to evaluate > with numbers in at least one column. :) > Given that every packet is encrypted and MACed I think some pretty extraordinary evidence is going to be required that little-endian has any significant performance improvement. -Ekr > > This may be worth a consensus call, since the spec says little-endian > currently, and we'll have to decide what to do upon adoption. > > Though I'm happily dancing around it, I agree with Martin about this being > a sarlacc pit. I guess those of us who have an opinion should find a time > before the WG meeting, then? > > Cheers, > > Brian > --94eb2c050f4a2266b60540e13360 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 9, 2016 at 4:20 AM, Brian Trammell <ietf@trammell.ch>= ; wrote:
hi Jana, all,

> On 08 Nov 2016, at 08:08, Jana Iyengar <jri@google.com> wrote:
>
> On Mon, Nov 7, 2016 at 8:13 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> hey Jana,
>
> On Mon, Nov 7, 2016 at 6:30 PM, Jana Iyengar <jri@google.com> wrote:
>

<snip>

> It does. I still think, perhaps naively, that these wire formats are s= eparable. If QUIC version shows up in 3 places, it obeys the wire format of= the 3 places where it shows up. I can see how different endian-nesses can = leak though, but my point was that these could be well-specified where ther= e's confusion. That said, I think your point is "avoid the confusi= on in the first place."

This was my point, at least.

Question for the design on the Google side: was this design choice taken as= self-evident, or is there benchmarking on the performance impact in-protoc= ol? The tradeoff between performance and the impact on violation principle = of least surprise on debugging effort would be easier to evaluate with numb= ers in at least one column. :)

Given th= at every packet is encrypted and MACed I think some pretty extraordinary ev= idence
is going to be required that little-endian has any signifi= cant performance improvement.

-Ekr

<= /div>

> This may be worth a consensus call, since the spec says little-endian = currently, and we'll have to decide what to do upon adoption.

Though I'm happily dancing around it, I agree with Martin about = this being a sarlacc pit. I guess those of us who have an opinion should fi= nd a time before the WG meeting, then?

Cheers,

Brian

--94eb2c050f4a2266b60540e13360-- From nobody Wed Nov 9 10:38:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56BDF129605 for ; Wed, 9 Nov 2016 10:38:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU6TAug7ZKdR for ; Wed, 9 Nov 2016 10:38:13 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2140B1295EA for ; Wed, 9 Nov 2016 10:38:13 -0800 (PST) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com [209.85.214.41]) by linode64.ducksong.com (Postfix) with ESMTPSA id 193343A020 for ; Wed, 9 Nov 2016 13:38:11 -0500 (EST) Received: by mail-it0-f41.google.com with SMTP id q124so288201934itd.1 for ; Wed, 09 Nov 2016 10:38:11 -0800 (PST) X-Gm-Message-State: ABUngvesD47COdIe24ej0jse7/65dZuCfh6aQgRY2oL6UhOP52LkK5SdkU6w51xyPs1FldiNuZPfgfiJSI2cbA== X-Received: by 10.107.12.229 with SMTP id 98mr2017131iom.183.1478716690589; Wed, 09 Nov 2016 10:38:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.84.71 with HTTP; Wed, 9 Nov 2016 10:38:10 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Wed, 9 Nov 2016 13:38:10 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a113f979410ef9b0540e28f0a Archived-At: Cc: quic@ietf.org, Patrick McManus Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 09 Nov 2016 18:38:14 -0000 --001a113f979410ef9b0540e28f0a Content-Type: text/plain; charset=UTF-8 On Mon, Nov 7, 2016 at 5:44 PM, Jana Iyengar wrote: > > > Gotcha. I think it makes sense to limit to QUIC and TCP at the moment > since there is a proposal to run HTTP over these, until such a time as > there is a need to define over another transport (let's call it Essy > Transport Protocol, you know, EssyTP). I suspect at that point the httpbis > wg (hey, that's you! :-)) can figure out how to define extensions over the > other transport. > > This isn't quite what I mean - I have enough trouble with the 2 we've already got :) As Mike mentioned, a 7540 extension can do almost anything it likes and that might mean a baked in assumption about the ordering of frames that is only valid on TCP. So I would sum the point of the issue to be raised here as "h2-mapping should say 7540 based extensions only apply to TCP and quic will maintain its own registry of extensions ala section 11 of 7540" --001a113f979410ef9b0540e28f0a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 7, 2016 at 5:44 PM, Jana Iyengar <jri@google.com> wrote= :

Gotcha. I think it makes sense to = limit to QUIC and TCP at the moment since there is a proposal to run HTTP o= ver these, until such a time as there is a need to define over another tran= sport (let's call it Essy Transport Protocol, you know, EssyTP). I susp= ect at that point the httpbis wg (hey, that's you! :-)) can figure out = how to define extensions over the other transport.


This isn't quite what I mean - I have enough tr= ouble with the 2 we've already got :) As Mike mentioned, a 7540 extensi= on can do almost anything it likes and that might mean a baked in assumptio= n about the ordering of frames that is only valid on TCP. So I would sum th= e point of the issue to be raised here as "h2-mapping should say 7540 = based extensions only apply to TCP and quic will maintain its own registry = of extensions ala section 11 of 7540"


--001a113f979410ef9b0540e28f0a-- From nobody Wed Nov 9 15:16:49 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0953D129A02 for ; Wed, 9 Nov 2016 15:16: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, 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 VTuCPGWwDqtS for ; Wed, 9 Nov 2016 15:16:45 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7521299ED for ; Wed, 9 Nov 2016 15:16:45 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id n21so165042984qka.3 for ; Wed, 09 Nov 2016 15:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4TjirmlsGOZb8vCucltOOTOU8Az6UG+qgZkfAE9D1aA=; b=tCaBSn7CCWdgsIjfXfY2KiYISlaIZEVaf8/16NsyPwmp7G8hA7y6sASofi8DC3TA+Z LIh9Bgm/8NGlxYsKAzxQpYRjQR4ZXt5Cq3vAw23lKZfF8FHGWB4o207vO2MtxrKiMXnv Ud7R1OekDfm6Fdq0YQkp8loQxhMcE6JbstQvzg6ABNhE1LJ2sToVgpeAp1tN3vgot1OO +2BL0rZqbJB5fSLjmzM6v0qTEW+6pxdF1EwIF1p4oQAdyMPPfdpaYhh1tm7ucAaQF9Pn 7hgJS5cw2d+XazsEvi3p8OY91bpfadTa7ocDalY41CWU0ePLRJ8DNA7XH8NCTSkFb9oY QjNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4TjirmlsGOZb8vCucltOOTOU8Az6UG+qgZkfAE9D1aA=; b=edl0/uzcEjA+PDxhpI9AnAZP1FqFZhr90AUxcSH8WmHMlMBO0hrNH5l8ybPTt2GAad uFhcyt8JR70dkZxU/6gxgBHpn4UZAn31hosh47PpJNWaiRTV0GTSNJNYbuq8jEjfY0UZ 8Rm0cbLq7Vid4ycokk9+6ChyDmScJMpq41wOljfIWKzbXXszpAt/W8h+MNu+IWg1eDbh Qrctnp47k9T79JFQWWo1xtALfuYY8NVnS3SK7xw0vFpV9k1vtkJppqTAf4ATx403GtbT zHiLi0a5hTyWtv81p6sDE9UnrQ1cbJ3vJzx4IFbvP9TwB4nFrUgK+YgDPFON+U8UMClg xG0Q== X-Gm-Message-State: ABUngve1hpPsuUhM08CG6nd1JhZ24F95861MQYiuR/YCja6NTc/kTJocJktoZFRY/xOH36muYyAzJAgz9hivxw== X-Received: by 10.55.12.2 with SMTP id 2mr2544528qkm.68.1478733404565; Wed, 09 Nov 2016 15:16:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 9 Nov 2016 15:16:44 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 10 Nov 2016 10:16:44 +1100 Message-ID: To: Patrick McManus Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jana Iyengar , quic@ietf.org Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 09 Nov 2016 23:16:47 -0000 On 10 November 2016 at 05:38, Patrick McManus wrote: > "h2-mapping should say 7540 based extensions only apply to TCP and quic will > maintain its own registry of extensions ala section 11 of 7540" ...or we insist on no assumption of absolute ordering between streams. The only thing that I'm aware of that has this assumption currently is HPACK. I would like it if h2 extensions were usable here, most likely will be. But I'd be happy to simply say, no portability unless explicitly noted. If you want to talk registries (my goodness, are we already doing that?) we could add a column to the registry that says "good for" and list the protocols. From nobody Wed Nov 9 16:22:30 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43CDC1296C6 for ; Wed, 9 Nov 2016 16:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBpdBTTm5nKV for ; Wed, 9 Nov 2016 16:22:26 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA467126BF7 for ; Wed, 9 Nov 2016 16:22:25 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E5FC322E1F3; Wed, 9 Nov 2016 19:22:12 -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 10.1 \(3251\)) Message-Id: <4C55E1BD-658B-475E-A2F6-350D2624E5EF@mnot.net> Date: Thu, 10 Nov 2016 11:22:10 +1100 To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Lars Eggert Subject: [QUIC] QUIC WG Interim Meeting -- 24-26 January 2017 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 00:22:28 -0000 The AD has approved our first interim, and the Secretariat should send = the formal announcement shortly. To give people the most time for planning, here's the arrangements page: = https://github.com/quicwg/wg-materials/blob/master/interim-17-01/arrangeme= nts.md If you'd like to attend, please register using the link there. Regards, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Nov 9 18:21:14 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BB3129862 for ; Wed, 9 Nov 2016 18:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxuyXaqsPqlm for ; Wed, 9 Nov 2016 18:21:10 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 7DF85129705 for ; Wed, 9 Nov 2016 18:21:10 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id 12so189928469uas.2 for ; Wed, 09 Nov 2016 18:21:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XftvUXql7PE9rE7tzhtH1gCELMB1a9HDPTaICyWs5Mw=; b=NfbJGoIlG4xZ9OUceXxS5FvSzDortKLhVORB/O+CVv8e9CWnS/swglzHgrtML85/8M IP/2Les3H97u5MhT8osOrlLMua7uzpWe+X/UVKA+UB3xplDil4I2+Jjxb+pcnWbp67HF DABaFBpk9CLpKU4NvOS699iQTyuEpBwdKOpkOKG5lAwkmwYsiFSH+z8JqbJFd3KjmAEm IJzVxPJu9iO1Y5EMYeMnPhx2v90u0GRtsBImEki3PnAXCkEQADbEn2DmR3ckAonPsHyW uvXK9PCPjGdCTnaEgI1LzDqjnFF8b6tRW1eSIkcZ4WkTJdF21z0gRLAADGTeGIGxSTHx sVmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XftvUXql7PE9rE7tzhtH1gCELMB1a9HDPTaICyWs5Mw=; b=fsJ+2eAToiGbjrpin3YGbiI5VL9qVcvl8I+tcaD0ZJFWHusIzj4piz6OoYqEcb9GAt ZX6fsxngHrae8QPNrP3lI/nHn/vj9i910OJfipPfVD8z0LyOrjsd9UUsghUcwLCGVf7B yf3a8lHbqoKwZyWQYyfIQIoIY9keXOb7ubjmzQM9a822On5P0JBJQwc9DPB0wL9XOyY4 6klG8RTUHbGbCxWQX3Dw7cb9RvsV2ZRb3w+o001+DdB8un+WPx7UOauJo/Udt4R2NLyP M3H4AaQLF45bE4DvaEUgu3A1ldE4bJW1hKA6ozpgn+GOajJb1u5Mp1Zm0fRTtVC+m595 U5mg== X-Gm-Message-State: ABUngvdGVVhriwMnW3KnG1CRooZvzLNjy1/DEuMuIrC7c1KOBNpWfWXcVcwXdpX7iDGUgKeIvVvRjYyPvIODoe0A X-Received: by 10.176.82.157 with SMTP id v29mr1721491uav.123.1478744469495; Wed, 09 Nov 2016 18:21:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Wed, 9 Nov 2016 18:21:08 -0800 (PST) In-Reply-To: References: <76988FFC-CFA9-4B60-B60B-39F4ABCC6051@trammell.ch> From: Jana Iyengar Date: Wed, 9 Nov 2016 18:21:08 -0800 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c18f88ad1ac9d0540e9064d Archived-At: Cc: Brian Trammell , quic@ietf.org, Patrick McManus Subject: Re: [QUIC] 2 issues for the hopper: terminology of packet vs sequence # and byte order X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 02:21:12 -0000 --94eb2c18f88ad1ac9d0540e9064d Content-Type: text/plain; charset=UTF-8 On Wed, Nov 9, 2016 at 9:00 AM, Eric Rescorla wrote: > > > On Wed, Nov 9, 2016 at 4:20 AM, Brian Trammell wrote: > >> hi Jana, all, >> >> > On 08 Nov 2016, at 08:08, Jana Iyengar wrote: >> > >> > On Mon, Nov 7, 2016 at 8:13 PM, Patrick McManus >> wrote: >> > hey Jana, >> > >> > On Mon, Nov 7, 2016 at 6:30 PM, Jana Iyengar wrote: >> > >> >> >> >> > It does. I still think, perhaps naively, that these wire formats are >> separable. If QUIC version shows up in 3 places, it obeys the wire format >> of the 3 places where it shows up. I can see how different endian-nesses >> can leak though, but my point was that these could be well-specified where >> there's confusion. That said, I think your point is "avoid the confusion in >> the first place." >> >> This was my point, at least. >> >> Question for the design on the Google side: was this design choice taken >> as self-evident, or is there benchmarking on the performance impact >> in-protocol? The tradeoff between performance and the impact on violation >> principle of least surprise on debugging effort would be easier to evaluate >> with numbers in at least one column. :) >> > > Given that every packet is encrypted and MACed I think some pretty > extraordinary evidence > is going to be required that little-endian has any significant performance > improvement. > No performance impact was measured. This choice was based on common-sense and the fact that Chrome runs only on little-endian platforms, which is, to a reasonable approximation, "all of them". > This may be worth a consensus call, since the spec says little-endian >> currently, and we'll have to decide what to do upon adoption. >> >> Though I'm happily dancing around it, I agree with Martin about this >> being a sarlacc pit. I guess those of us who have an opinion should find a >> time before the WG meeting, then? >> > I don't think this needs to become a sarlacc pit, since we aren't really arguing what universal choice of endianness is good. I suspect that a consensus call will show if more discussion is needed? Especially given that this is a change to the current draft, we'll need a call if adopted anyways. > Cheers, >> >> Brian >> > > --94eb2c18f88ad1ac9d0540e9064d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 9, 2016 at 9:00 AM, Eric Rescorla <ekr@rtfm.com> = wrote:


On Wed, Nov 9= , 2016 at 4:20 AM, Brian Trammell <ietf@trammell.ch> wrote:
hi Jana, all,

> On 08 Nov 2016, at 08:08, Jana Iyengar <jri@google.com> wrote:
>
> On Mon, Nov 7, 2016 at 8:13 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:=
> hey Jana,
>
> On Mon, Nov 7, 2016 at 6:30 PM, Jana Iyengar <jri@google.com> wrote:
>

<snip>

> It does. I still think, perhaps naively, that these wire formats are s= eparable. If QUIC version shows up in 3 places, it obeys the wire format of= the 3 places where it shows up. I can see how different endian-nesses can = leak though, but my point was that these could be well-specified where ther= e's confusion. That said, I think your point is "avoid the confusi= on in the first place."

This was my point, at least.

Question for the design on the Google side: was this design choice taken as= self-evident, or is there benchmarking on the performance impact in-protoc= ol? The tradeoff between performance and the impact on violation principle = of least surprise on debugging effort would be easier to evaluate with numb= ers in at least one column. :)

G= iven that every packet is encrypted and MACed I think some pretty extraordi= nary evidence
is going to be required that little-endian has any = significant performance improvement.

No performance impact was measured. This choice was based= on common-sense and the fact that Chrome runs only on little-endian platfo= rms, which is, to a reasonable approximation, "all of them".

> This may be worth a consensus call, since the s= pec says little-endian currently, and we'll have to decide what to do u= pon adoption.

Though I'm happily dancing around it, I agree with Martin about = this being a sarlacc pit. I guess those of us who have an opinion should fi= nd a time before the WG meeting, then?
<= /div>

I don't think this needs to becom= e a sarlacc pit, since we aren't really arguing what universal choice o= f endianness is good. I suspect that a consensus call will show if more dis= cussion is needed? Especially given that this is a change to the current dr= aft, we'll need a call if adopted anyways.
=C2=A0
Cheers,

Brian


--94eb2c18f88ad1ac9d0540e9064d-- From nobody Wed Nov 9 21:23:37 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEF31299D4 for ; Wed, 9 Nov 2016 21:23:35 -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 Hhazy70RrZSy for ; Wed, 9 Nov 2016 21:23:33 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 A49DE12943E for ; Wed, 9 Nov 2016 21:23:33 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id n6so140564031qtd.1 for ; Wed, 09 Nov 2016 21:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=nObpUTOwwTFCOEEekaAc0GxfoOT7ThFnEziteBb9Zfg=; b=q7R0GUMFh1ZnVqsT1wvCfbZmfxsnhKZwjyQ5v1VeK4wEFJwzupqFCarnJ+nViKSMLY EVlRWwHZvik3ruD8TKGisNDb8LD8q7YreeBCg5otgI8R58m37YT0uVzdZMk85kg05eYm udOaN4FXnubSFbA6nKl+dwBhQ/1VpimJY903n5UBCj59kbmCFbaSBBNd+QUoyuSuuBde T9wGm29W2iJx/YzT5r7KX1xWnlKRmMeAtZLZ9br0iRQUMBCkacAT9uQznMPn/IW8EEdg LxK3hsJGNt21qe9GCn61VN4aRsEN/ZvuNBavB6ZP6KOu/f8Np2blKWLOK4Zvw0l3Ukbg 4sHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nObpUTOwwTFCOEEekaAc0GxfoOT7ThFnEziteBb9Zfg=; b=Zb987KPocVqynOZNBmbdqw8sMw5Ke0DrNv1u45KGIEulexfnKxEFStsJviZJScj1fm GcfJwR/U3PAg6NcYv8lWBfa6Q5bBWiF67/Gs4Ml0yL1/rnI83+WVIjUUk8cQRQpq4oXa lu8kyv2cYib/9dDybABGGXpTa996wviEScqqCnqQbOVZr/j7zIMCnx2UWwybzb39a7Hj up93D06tt4ppr2AkktURd4zvhUyJoPCwfshnKpiS4VQsUyNoPb+nBc7I5iuGErr2PCOi /V4fk4QPaofk3DrEOksfzDa2IbywScnMPF6yLXG8JA6T6KvryDfJ0HJRhRFLjZLHwDyg RVIw== X-Gm-Message-State: ABUngveYJyJSudjXMT/l1Ms40tLpD084dAZwLTfOUPGfW1/gbFcqOBH/81pSOQhmNJ9ClnmXzPPGtQ5v7gl/jQ== X-Received: by 10.200.39.43 with SMTP id g40mr3648208qtg.58.1478755412566; Wed, 09 Nov 2016 21:23:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 9 Nov 2016 21:23:32 -0800 (PST) From: Martin Thomson Date: Thu, 10 Nov 2016 16:23:32 +1100 Message-ID: To: quic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [QUIC] Packet number recovery X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 05:23:35 -0000 Sayeth Section 4.2.1: a QUIC sender MUST NOT have more than 2^(packet_number_size - 2) in flight at any point in the connection and: Any truncated packet number received from a peer MUST be reconstructed as the value closest to the next expected packet number from that peer. (relatively) big questions: Q1 I don't think that this limit is necessary. The point is to use a packet number that is big enough that reordering won't cause an endpoint to recover the wrong packet number. I can see how you get here. You only predict backwards for 2^N-1 packets. You want to divide that into packets that were in the last RTT worth and packets that are in the next RTT worth. The former because you haven't received an ACK for those yet, and the latter because you are sending those. I think that's overly pessimistic by a factor of two because you only have one RTT plus delta unacknowledged packets at any instant (delta being the RTT variance plus any ack collation delays). Of course I'd be happy to see some data that proved me wrong. Q2 I don't think that this is the only possible algorithm, or even the best. For instance, before there was anything in the QUIC spec, I described an algorithm that looks exclusively backwards from the last received packet. If a packet with that number was already received, then it's in the future and add 2^(packet_number_size) to get the real number. Otherwise, look in the window around the predicted next value. Assuming low loss rates, this doubles the search space. I don't think that we need a MUST on the actual algorithm, just a suggestion about what to use. If someone wants to do something slightly different, then that's OK. For instance, I can imagine some crazy folks doing trial decryption to recover packet numbers over a larger window. I can also imagine very limited implementations that insist on monotonic packet numbers and drop older packets unconditionally, even if they are only microseconds late. Some of those options are especially suboptimal on various measures, but the key point is that none of them introduce interoperability failures. Lost frames are retransmitted as necessary and the world moves one. (Actually, that last one is probably a terrible idea because it would create a ridiculously high false loss signal that the congestion controller would react badly to, but I think that it is still not an interoperability failure.) (annoying) little questions: Q3 Please define "in flight". I've assumed that this means in the same RTT. I also realize that this is fuzzy. Jitter, buffering and other factors mean that you can end up with more or less packets in the air than your predictions lead you to expect. I still want a more concrete definition if we're going with a MUST here. I can think of several answers: in_flight = pn[last_sent] - pn[highest_acknowledged] in_flight = pn[last_sent] - pn[sent_at(now-RTT)] in_flight = pn[last_sent] - pn[sent_at((now-RTT)/2)] Q4 What happens if there are two equidistant options? This happens when abs(n[last_received] & (2^(packet_number_size)-1) - received_packet_number) == 2^(packet_number_size-1) e.g., the last received is 256 and the next one is an 8-bit 129. (Points off for looking at what Ian's code does.) From nobody Thu Nov 10 00:21:45 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85CF612946D for ; Thu, 10 Nov 2016 00:21:43 -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=lukasa-co-uk.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 sJzaEFWTKW9F for ; Thu, 10 Nov 2016 00:21:42 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1978A128B38 for ; Thu, 10 Nov 2016 00:21:42 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id a197so352601748wmd.0 for ; Thu, 10 Nov 2016 00:21:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GlGZvoWBO7K5iByTEFAQKxrB9DkYnk8BXbwzYzjB3Gw=; b=PV8a85mSJ+BUjkqWp+ESkOQtBaSf4dmLtD8eycfPiG6xZzpv2CcEr5KGm//1O0E6CG OmnS2yo7YV/z7bCvZOZwHbTxaXO3KXzHWVz7306VpswnJ4IQLjYBeRnE07CKyY+/nuJC W98wdATUzzPfK5uV+z758aL9EWgrBsYREb8JuZ1DaOaGlMeutUBd+sDyn3tEt9ShDxmZ iYBsuI/kloSRJfVAah3pkYbhOJgcvT2vp8UKPZ3T2Ue8/4bi9BIQu67ODQ2ZQRQrB3rJ K53iR3nFSlyYT3LJCytyzY8klFF2vSzbVVMZGJR/T98y5c596DeBKvZhDw232dPe//2I rQ3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=GlGZvoWBO7K5iByTEFAQKxrB9DkYnk8BXbwzYzjB3Gw=; b=Ic9V8yLAcxKUvh+L0VFVq9HXiW21eYTjc21+KwMu7XTiTdXyWE0nZ+CYrKup4D7CQz G7xqc3Ph+5jRyqUiNHqM/hakndkJwWpbtpnrTyAUGixNNf7Yfkq3KosIJU+XzkpueIhP O/HXswRxr6Re5hlRxdw8Ps6ggM051H9fHmuty95vAN8MlqxjmewZpJqtC50uFyb1akug AJODJ/cq8gHJVbeB43YgF/Eg6GO7fa8/L2u45oasohqdqEO84Wb84jMgkd+ut08tw6dW ba6xprZV3Row+4mgYSxOpQY5vdAp1nys5aHYrDsmVBIgcyDuY+6LREwPwQUHj6Xh6qlq zoYQ== X-Gm-Message-State: ABUngvcNnZYbb1JJsav6BjHERLHVYzlZzJB47l1dViKjZeuDUdlyvfBtMSfZ9wcAEnIrMg== X-Received: by 10.194.229.7 with SMTP id sm7mr3907276wjc.150.1478766100614; Thu, 10 Nov 2016 00:21:40 -0800 (PST) Received: from [192.168.1.5] (72.6.208.46.dyn.plus.net. [46.208.6.72]) by smtp.gmail.com with ESMTPSA id y4sm4118425wjp.0.2016.11.10.00.21.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Nov 2016 00:21:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3253\)) From: Cory Benfield In-Reply-To: Date: Thu, 10 Nov 2016 08:21:37 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> References: To: Martin Thomson X-Mailer: Apple Mail (2.3253) Archived-At: Cc: Jana Iyengar , quic@ietf.org, Patrick McManus Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 08:21:43 -0000 > On 9 Nov 2016, at 23:16, Martin Thomson = wrote: >=20 > On 10 November 2016 at 05:38, Patrick McManus = wrote: >> "h2-mapping should say 7540 based extensions only apply to TCP and = quic will >> maintain its own registry of extensions ala section 11 of 7540" >=20 >=20 > ...or we insist on no assumption of absolute ordering between streams. > The only thing that I'm aware of that has this assumption currently is > HPACK. I would like it if h2 extensions were usable here, most likely > will be. But I'd be happy to simply say, no portability unless > explicitly noted. If you want to talk registries (my goodness, are we > already doing that?) we could add a column to the registry that says > "good for" and list the protocols. Don=E2=80=99t SETTINGS frames also imply an absolute ordering between = stream 0 and every non-0 stream? Cory= From nobody Thu Nov 10 01:10:30 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54C112955E for ; Thu, 10 Nov 2016 01:10:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.418 X-Spam-Level: X-Spam-Status: No, score=-8.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bd-n0ZDWb3ML for ; Thu, 10 Nov 2016 01:10:23 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63540129576 for ; Thu, 10 Nov 2016 01:10:23 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.31,618,1473145200"; d="scan'208";a="155406162" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx143-out.netapp.com with ESMTP; 10 Nov 2016 01:04:44 -0800 Received: from VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Nov 2016 01:04:54 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 10 Nov 2016 01:04:54 -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=X7gEtXYcmTVKDx7SWsvyqLIrLgN0OwTJ+Cm+ghGAYlk=; b=oubXVJg/zD6tWIp7ZnFo6zapOhfI1e73hhCUq9dWHhgcHqU1HVV1+9pNNHGXHSibEMQECnw0qVGFR3wZm2w0FkaWHTAR8ATE/fIKTkDIvLnBb1bSHBNBcxeZZeFquwDH34bzBJ9rHO/NV/RkIqrNTEyYdvuXVQfENGKw0/gkqGU= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Thu, 10 Nov 2016 09:04:52 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0707.013; Thu, 10 Nov 2016 09:04:52 +0000 From: "Eggert, Lars" To: "quic@ietf.org" Thread-Topic: [QUIC] IETF-97 agenda planning Thread-Index: AQHSL1YdvpyKL/ttVkit4iWauChkWKDSBFCA Date: Thu, 10 Nov 2016 09:04:52 +0000 Message-ID: <0AEAE789-D67B-4878-BAC2-597C2104B433@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:YuU1qm6NCjLiwjv0G3mmydE5EOU4jB4wECd1lZ3PrpI6jslHOKkxq7SYT0RYs1dV6w4+2RGEPQilpLPTRTbZOA25pyj0aunMdx49PSeKqxvqKHHQm11w31hj1rP3T6uCKNT5s3jVvf/apcpddp5TNfc/Mi5gVcSG10svS+c42R0knblSDKtaQ+sZvO/mssljKJJJTEaPD0zpdep5O28/Uvc431VGudRs9x8jnWrRq9juujcL3jM1nmUT21A3R4l4DV8BWlYLoZubF+Q14+Xqk4MBJQhBj932UYKs/7TQfydgLKUsXJoKoOPu91Gx7397x8fy9tNvwq/ZxYpJlAWyMWCLBOSjob0ZdzaKEG1so6s= x-ms-office365-filtering-correlation-id: 419dcfa3-882c-43b2-f2e1-08d40948a200 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6043046)(6042046); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(189002)(199003)(377424004)(305945005)(7846002)(5660300001)(7736002)(6916009)(110136003)(8676002)(3846002)(50986999)(2950100002)(76176999)(2906002)(229853002)(36756003)(101416001)(66066001)(92566002)(107886002)(97736004)(189998001)(57306001)(4001150100001)(122556002)(586003)(33656002)(102836003)(6116002)(106116001)(5640700001)(105586002)(2351001)(99286002)(81156014)(106356001)(1730700003)(81166006)(2900100001)(450100001)(77096005)(3660700001)(2501003)(8936002)(83716003)(86362001)(3280700002)(82746002)(50226002)(68736007)(87936001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <4356179360BCCB478A0FA1AB2A7F50B2@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2016 09:04:52.3216 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [QUIC] IETF-97 agenda planning X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 09:10:29 -0000 Hi, On 2016-10-26, at 8:56, Eggert, Lars wrote: > we are TENTATIVELY scheduled for Tuesday, November 15, 2016 in the 9:30-1= 2:00 "Tuesday Morning session I" slot. =20 >=20 > Our current agenda is evolving on https://github.com/quicwg/wg-materials/= blob/master/ietf97/agenda.md. >=20 > If you would like to present during the session, please send an email to = quic-chairs@ietf.org, include a few sentences outlining your talk and give = us an estimate for how much presentation + discussion time you think is nee= ded. reminder that if you would like a slot, please request it ASAP. PDF preferr= ed. Also, if we have assigned you a slot, please email *final* slides to Mark a= nd me by Monday noon (KST). We'll likely be in a large room again, and will have many remote attendees.= Please keep that in mind when making slides, i.e., use large fonts for all= text, add slide numbers, avoid subtle colors, etc. Lars= From nobody Thu Nov 10 01:17:02 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6BF1295D0 for ; Thu, 10 Nov 2016 01:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.418 X-Spam-Level: X-Spam-Status: No, score=-8.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNrFF8uBzm-h for ; Thu, 10 Nov 2016 01:16:59 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [216.240.21.25]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94261295BF for ; Thu, 10 Nov 2016 01:16:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.31,618,1473145200"; d="scan'208";a="157038436" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx144-out.netapp.com with ESMTP; 10 Nov 2016 01:15:43 -0800 Received: from VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 10 Nov 2016 01:15:58 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 10 Nov 2016 01:15:58 -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=hzXsaL2TH5iBFnukUSn19p7R1HgjMo38OnjyXtB/v9k=; b=hI7IRA9hFbTkbwb8jvuRyYKD6JcdvD2oGiLPrk7mdBRttjMdk9bNvYbDvPbhP6LM6hcbFBKsOzGZXaW54CqkqCKqrBf/3EYFaO+Hwd3RXAIcRJey0SfVRcTqEeOyn3bSTda6imlflgOgos/TXvyvhQJgXkVEO6DWSIRHkHXG5Dw= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1155.namprd06.prod.outlook.com (10.160.157.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Thu, 10 Nov 2016 09:15:57 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0707.013; Thu, 10 Nov 2016 09:15:57 +0000 From: "Eggert, Lars" To: "quic@ietf.org" Thread-Topic: [QUIC] IETF-97 agenda planning Thread-Index: AQHSL1YdvpyKL/ttVkit4iWauChkWKDSBFCAgAADGQA= Date: Thu, 10 Nov 2016 09:15:57 +0000 Message-ID: <44AEFC3D-4641-4EF7-8D8E-41C0D20C0C62@netapp.com> References: <0AEAE789-D67B-4878-BAC2-597C2104B433@netapp.com> In-Reply-To: <0AEAE789-D67B-4878-BAC2-597C2104B433@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1155; 7:v4c7nvFjCV6kfV0VHW/KsevMaK2srJ0YfavpwxM6NCHXtcwJ245J8rz8p29jCjwB34XXtouSyhjBqGrsJ6akYgQf0bN2BZOZ8o1MTctor3GlaEVuJPH5I1Un/7ihvHcSIYUQP89GQ+2/pudrIzFqbSOOrnvXAgMvAT30VbE/pIhqyigMzsTjFoxxnDkyYuv5hAmvRjBJAWZOaPHDhYRRgV2SiXNl+D0E7riwY7B+wDK6kQfC3YvL0JMNy3XcS71aK3JGlYPDDa0+P0h0O9s9rq8BXP5E+G4aXo+Ixs+lTGP53L9QrfbkdE5P04M6TZmLrtFClpFZ9i4vpeFM/azFgoM8H3bU7QZn8PdQEtCkCFQ= x-ms-office365-filtering-correlation-id: 89ad9b6b-0d9c-4cd6-8860-08d4094a2e5f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6043046)(6042046); SRVR:BN3PR0601MB1155; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1155; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(377424004)(199003)(189002)(57306001)(50986999)(66066001)(8936002)(33656002)(76176999)(6116002)(102836003)(3846002)(305945005)(101416001)(7736002)(5660300001)(586003)(7846002)(3660700001)(2351001)(110136003)(3280700002)(99286002)(105586002)(2906002)(6916009)(106116001)(2950100002)(106356001)(68736007)(36756003)(77096005)(50226002)(107886002)(83716003)(87936001)(97736004)(4001150100001)(82746002)(450100001)(2501003)(189998001)(92566002)(2900100001)(86362001)(229853002)(5640700001)(1730700003)(8676002)(81156014)(122556002)(81166006)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1155; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2016 09:15:57.3643 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1155 X-OriginatorOrg: netapp.com Archived-At: Subject: Re: [QUIC] IETF-97 agenda planning X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 09:17:00 -0000 On 2016-11-10, at 10:04, Eggert, Lars wrote: > reminder that if you would like a slot, please request it ASAP. PDF prefe= rred. "PDF preferred" was supposed to be at the end of the next line. Need more c= offee: > Also, if we have assigned you a slot, please email *final* slides to Mark= and me by Monday noon (KST). Lars >=20 > We'll likely be in a large room again, and will have many remote attendee= s. Please keep that in mind when making slides, i.e., use large fonts for a= ll text, add slide numbers, avoid subtle colors, etc. >=20 > Lars From nobody Thu Nov 10 01:49:07 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0AA412963A for ; Thu, 10 Nov 2016 01:49:06 -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 6ffXkLNvBVre for ; Thu, 10 Nov 2016 01:49:05 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 0F290129505 for ; Thu, 10 Nov 2016 01:49:05 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id n6so143283365qtd.1 for ; Thu, 10 Nov 2016 01:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3RbGg01oclN/4umq5+rXzrKRAUGELKHDRhnuBDnX0zE=; b=cpw+WcOdXVEjO9NBjFilbxlZB1OC1CGCFiozokKjlhqDmJ2jzsP886V9G3jFZ/T6ff ofQE+SCTPXq0/C4U9/l4esfoMjjzkezuq1SFnR04vqh7vlQtby5qVx/51yZhOSeU54Tp EcFRB3hjJlMTQJZ9Kr2MruuU1WmnnwXFI1xYs/4oTaQHuNh4+BIJ+7lw1T8PuGLgBdQj v8D+t5vyTFyD56Fr2/N4FLA9nNDXMVgytF+iahHkVoJBU9IYNxzR/6D1bVMDrf2dEdj7 IYKUQfNnIsyLlLgyEs/HwMjaMtj2ClqwUmheAwqdE5ZRhlc9GTcuFyamUf5ST3FU00Yp M/Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3RbGg01oclN/4umq5+rXzrKRAUGELKHDRhnuBDnX0zE=; b=Lcj+6Caz7iv8yrCKqJNtFx8xM0gA1lPQSrcrHtitaxKROxN0gGVY22qS8CjutONpj3 EpsuIfGz/+Db2swAfPItUojV93SLvY8/V/g2ixUVDniYVNUNJTzpvFAEOWjZ0owH9kgW qmVjlQ16knIC/9j2O5DS37Cy6jLKzzR3KKdIx/p5rY8fSvPlTSXAsJIfv/CspTQMBulj 3t7ldS45YmRttPYaRS951OZkjGj5b4uXjxRrO8vuvQojjBKQ4zIUkGN532P8ulK+zQId NyPjlvZT5SlZ1FDqvxZ5SgiF1ymSQz/tc9YOaSy6l7VPhJ0m8P0Q9Xmy1rVjbJ0Bo3Wy PvQg== X-Gm-Message-State: ABUngvev30ZdbrigVkApewq9EiUKcUN7a0wMTy0elBNP7npGIbXOZgMH9CYC0NVPcjJTBbFDacwXJzIxZNiaEQ== X-Received: by 10.200.34.5 with SMTP id o5mr1727412qto.32.1478771344163; Thu, 10 Nov 2016 01:49:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 10 Nov 2016 01:49:03 -0800 (PST) In-Reply-To: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> From: Martin Thomson Date: Thu, 10 Nov 2016 20:49:03 +1100 Message-ID: To: Cory Benfield Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jana Iyengar , quic@ietf.org, Patrick McManus Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 09:49:06 -0000 On 10 November 2016 at 19:21, Cory Benfield wrote: > >> On 9 Nov 2016, at 23:16, Martin Thomson wrote= : >> >> On 10 November 2016 at 05:38, Patrick McManus wro= te: >>> "h2-mapping should say 7540 based extensions only apply to TCP and quic= will >>> maintain its own registry of extensions ala section 11 of 7540" >> >> >> ...or we insist on no assumption of absolute ordering between streams. >> The only thing that I'm aware of that has this assumption currently is >> HPACK. I would like it if h2 extensions were usable here, most likely >> will be. But I'd be happy to simply say, no portability unless >> explicitly noted. If you want to talk registries (my goodness, are we >> already doing that?) we could add a column to the registry that says >> "good for" and list the protocols. > > Don=E2=80=99t SETTINGS frames also imply an absolute ordering between str= eam 0 and every non-0 stream? You are right. I completely neglected that. Use of SETTINGS to initiate changes that affect streams requires a synchronization point. Presumably we will have to solve that in the HTTP mapping document somehow. Hopefully we can have a generic solution. From nobody Thu Nov 10 02:04:37 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E95311293D8 for ; Thu, 10 Nov 2016 02:04:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45SLXY98VeKo for ; Thu, 10 Nov 2016 02:04:34 -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 34E7B129418 for ; Thu, 10 Nov 2016 02:04:34 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id t125so233176438ywc.1 for ; Thu, 10 Nov 2016 02:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w41IDBSQ46v3v/TGn+oZ/3jIvNJJeiYBN5XG31tNlg0=; b=am2j/BeZuhJUOQghohy2BRmX8fF9URSQODQVDsOtQY3spL1ZBaF6CB92qgMM9xjGdS WdTmwreK5XqBTZ76PBMZjS3M/RjJ0S50U2y9DSQO13sp5sSFZpfb/LaFT8LOAUBdY+eQ hS8yFTbITHvmcDQ1CXOVM/QbpITdSCray0oOjFzRiiKnKgkHN8Iu2QJThHtPN1Ys3SAp /KdMkpVoTuJY/7KlA2LqgbE2YFt5mcROYs0XjFlunZli6tgBIps8TldjEtwTR8SQhwKO i3wrDWbbQoYAtLnqXJiT48zVmVRL9gFSCaZf/2nApL0FLyIYJWeOtlPAc7LcxJMqSGnt spBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w41IDBSQ46v3v/TGn+oZ/3jIvNJJeiYBN5XG31tNlg0=; b=LznNvVsQ1+eV/yHyQwGge6hirvbBTosOqFYEV9ztM4bfGqykigDd+joT4z+w32jsHf cZCiPzLElc8bFhZ93QFNLVV4TvAOk7mu0Wsgit2QSzqUOWokjzPpBqeAUOoPGaZIR9/c OSyOyJuEFhZeC9z5GM4SDp+EsAh7bDSwamtmMLDOkaIQy/qxG9FbpGV9huMUq9rZihso Xyc1QjrBehmr9irxCBjLv7/qCUIoSeslSu4u76A8HlLQv3b53txw06Mv2uKMdWdHR9I0 ZU7gQ09VXquELVPpUtgCqSsaim3EEOCnB9iKN3xvjpBcAM2+YLd6RY8+t/Fd6XUdLMh0 itpw== X-Gm-Message-State: ABUngvcUbeCswTHnCRevvVGW+fxH3J/WRxcX19XIsdmZBQc+pfXWTYOdnloo913hIwx//sn4MX9ovHOzhQ8U6+Bm X-Received: by 10.129.78.205 with SMTP id c196mr4500730ywb.63.1478772273387; Thu, 10 Nov 2016 02:04:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.203.69 with HTTP; Thu, 10 Nov 2016 02:04:12 -0800 (PST) In-Reply-To: References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> From: Ian Swett Date: Thu, 10 Nov 2016 05:04:12 -0500 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114db8ea0f5a060540ef80b2 Archived-At: Cc: Cory Benfield , quic@ietf.org, Patrick McManus , Jana Iyengar Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 10:04:36 -0000 --001a114db8ea0f5a060540ef80b2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If a single frame type always required in order delivery, but you didn't want HOL blocking on everything, you could use a stream per frame type. As such, any given HTTP/2 frame would need to specify if in-order delivery is necessary, and if so, they should be sent on a single stream. Otherwise, a stream per frame can be used. That seems fairly generalizable to me? On Thu, Nov 10, 2016 at 4:49 AM, Martin Thomson wrote: > On 10 November 2016 at 19:21, Cory Benfield wrote: > > > >> On 9 Nov 2016, at 23:16, Martin Thomson > wrote: > >> > >> On 10 November 2016 at 05:38, Patrick McManus > wrote: > >>> "h2-mapping should say 7540 based extensions only apply to TCP and > quic will > >>> maintain its own registry of extensions ala section 11 of 7540" > >> > >> > >> ...or we insist on no assumption of absolute ordering between streams. > >> The only thing that I'm aware of that has this assumption currently is > >> HPACK. I would like it if h2 extensions were usable here, most likely > >> will be. But I'd be happy to simply say, no portability unless > >> explicitly noted. If you want to talk registries (my goodness, are we > >> already doing that?) we could add a column to the registry that says > >> "good for" and list the protocols. > > > > Don=E2=80=99t SETTINGS frames also imply an absolute ordering between s= tream 0 > and every non-0 stream? > > You are right. I completely neglected that. Use of SETTINGS to > initiate changes that affect streams requires a synchronization point. > Presumably we will have to solve that in the HTTP mapping document > somehow. Hopefully we can have a generic solution. > > --001a114db8ea0f5a060540ef80b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If a single frame type always required in order delivery, = but you didn't want HOL blocking on everything, you could use a stream = per frame type.=C2=A0

As such, any given HTTP/2 frame wo= uld need to specify if in-order delivery is necessary, and if so, they shou= ld be sent on a single stream.=C2=A0 Otherwise, a stream per frame can be u= sed.=C2=A0 That seems fairly generalizable to me?

On Thu, Nov 10, 2016 at 4:49 AM= , Martin Thomson <martin.thomson@gmail.com> wrote:
On 10 November 2016 at 19:= 21, Cory Benfield <cory@lukasa.co.u= k> wrote:
>
>> On 9 Nov 2016, at 23:16, Martin Thomson <martin.thomson@gmail.com> wrote:
>>
>> On 10 November 2016 at 05:38, Patrick McManus <pmcmanus@mozilla.com> wrote:
>>> "h2-mapping should say 7540 based extensions only apply t= o TCP and quic will
>>> maintain its own registry of extensions ala section 11 of 7540= "
>>
>>
>> ...or we insist on no assumption of absolute ordering between stre= ams.
>> The only thing that I'm aware of that has this assumption curr= ently is
>> HPACK.=C2=A0 I would like it if h2 extensions were usable here, mo= st likely
>> will be.=C2=A0 But I'd be happy to simply say, no portability = unless
>> explicitly noted.=C2=A0 If you want to talk registries (my goodnes= s, are we
>> already doing that?) we could add a column to the registry that sa= ys
>> "good for" and list the protocols.
>
> Don=E2=80=99t SETTINGS frames also imply an absolute ordering between = stream 0 and every non-0 stream?

You are right.=C2=A0 I completely neglected that.=C2=A0 Use of SETTI= NGS to
initiate changes that affect streams requires a synchronization point.
Presumably we will have to solve that in the HTTP mapping document
somehow.=C2=A0 Hopefully we can have a generic solution.


--001a114db8ea0f5a060540ef80b2-- From nobody Thu Nov 10 02:09:52 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0581293D8 for ; Thu, 10 Nov 2016 02:09: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, 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=lukasa-co-uk.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 WquTOE-ofcyd for ; Thu, 10 Nov 2016 02:09:49 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B6CC1295BB for ; Thu, 10 Nov 2016 02:09:49 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id t79so20800232wmt.0 for ; Thu, 10 Nov 2016 02:09:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mLVKbV99sEGGGgphkEbtgWwsjOJPvUFjbfqG8NuqsDk=; b=aZL+5NfcnYSLTplTqm+ppv8hO96Z+SDIkrAboHgJKJ5GMbfwXEk9fSMGEOGxw7rAnV IZxtVYjLcrZTLDq3Ul4AsvqkIHbsJ/rvhIkbJcsxI/J3vVTWB/iMaKW9CKaDCMNWo8PH JlDCHDDNXlUWnMtGZ3A3z493KcEh/HMqZ17AwBc3YxFyKOH6PcQe7wH0jdZKy3KngGdj G0uFTva3Tt+/eq9X+dxd4eUcZsqkjpVAlA1jnjuX6FrFfK478yn9ri8TxutYV4d+Fr/Z mN4Pkk1dzBhfXQKCcicJadpA7g1BNdaY6vMKvDvG/vF7li2kyaQc49YQaiVYjwMNVL/F Petg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mLVKbV99sEGGGgphkEbtgWwsjOJPvUFjbfqG8NuqsDk=; b=IzAgaJQEDxGC11COCk8Yc6hBZWcF8lrEH0NOWj68vJkKgdOuCPbxI32AF6f8AxM+MD fM9jLQHSufxf5BKcZEmFPc0qrwKVaSgqWQLY8pB99UqodoVS2ydpElqYd96NoKMnJwgI xWrU8toxYfV0qmouoeEZhXId6MGRAMHCjnNgMayuMDrgsbi5MrE/xO5a2IhR/EH/GXG9 6jH0zmUXIbWgo/0/w7/d4nvWMiAMnBIm/13EkVbJ79dXjxflOxaHAL+gQH4S9N2LIwBB ASWmBZnhUusvKaMCV8yj6rYitg7AsdbFgJL7xi5L6D9t/kyVto6oDkzHC8LYvC2u9wtW sYuA== X-Gm-Message-State: ABUngveVPd0G+5o2KAOpixEBNNHuS560qVxzkhEL7ubfsjtrG/HqGifCw/5Cjl+pHThUbA== X-Received: by 10.28.132.202 with SMTP id g193mr5362267wmd.117.1478772587590; Thu, 10 Nov 2016 02:09:47 -0800 (PST) Received: from [192.168.1.5] (72.6.208.46.dyn.plus.net. [46.208.6.72]) by smtp.gmail.com with ESMTPSA id m9sm4328058wma.0.2016.11.10.02.09.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Nov 2016 02:09:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3254\)) From: Cory Benfield In-Reply-To: Date: Thu, 10 Nov 2016 10:09:45 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> To: Ian Swett X-Mailer: Apple Mail (2.3254) Archived-At: Cc: Jana Iyengar , quic@ietf.org, Martin Thomson , Patrick McManus Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 10:09:50 -0000 > On 10 Nov 2016, at 10:04, Ian Swett wrote: >=20 > If a single frame type always required in order delivery, but you = didn't want HOL blocking on everything, you could use a stream per frame = type.=20 >=20 > As such, any given HTTP/2 frame would need to specify if in-order = delivery is necessary, and if so, they should be sent on a single = stream. Otherwise, a stream per frame can be used. That seems fairly = generalizable to me? I don=E2=80=99t think it resolves SETTINGS though. H2=E2=80=99s SETTINGS = frame includes some connection-wide values that affect all other frames = (e.g. SETTINGS_MAX_FRAME_SIZE), so with SETTINGS as written in 7540 it = needs to be possible to sort all frames into =E2=80=9Cbefore ACK=E2=80=9D = and =E2=80=9Cafter ACK=E2=80=9D if that setting is changed: otherwise = it=E2=80=99s very difficult to police the frame size. A monotonic counter on SETTINGS could perhaps be used to this effect, = but it=E2=80=99d require that all frames carry that counter on them and = probably that frames from older settings regimes be discarded after a = certain period of time. I=E2=80=99m not entirely sure that that=E2=80=99s = a good plan, but it=E2=80=99s the first one that leaps out at me. Cory From nobody Thu Nov 10 02:16:33 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8DD12965F for ; Thu, 10 Nov 2016 02:16:32 -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 kTvq3UcbpJTD for ; Thu, 10 Nov 2016 02:16:30 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::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 BB72F129662 for ; Thu, 10 Nov 2016 02:16:30 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id c47so143370918qtc.2 for ; Thu, 10 Nov 2016 02:16:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=7F35Pk4bA8xS/bgT9oENy9jxHyMPnq8OzWg0aTCEC8M=; b=JvtHJod79GTppPHNWttyd1oVJ9bRtepZDlABY6lMew463GMjcNgyif/rg9M1pn3RPW YFANKz8E9K1E9SFXMDNg35PJix5bGhzEhvOE7hIRdOCE5bGWSC4eQhlv1mCuTZs+b6jM a+vV9+IpI7dMkMwmvMOeCSev22XV32dxkTmSbXfSVYhRezC99XclDsI/+DI1brOPLJ+c lshpz0TeBwXvXM45DHuWyDveuk9P8pZ/3X8gHjW67N/V2GVZCxwtUoSkuOVrB0djmfsy kHgj/D/MFGMHtzyVJ2LyeyOK6/LXc8N00lnmVpkpCaRh4RHOurohu5v7c5TfPVNlUoNQ i02w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7F35Pk4bA8xS/bgT9oENy9jxHyMPnq8OzWg0aTCEC8M=; b=K3wKac64eVtYL0FjcuZTfBQC9/pFHbYMygb5YkVRrI6ys5E6BXY1qVRUy5ZhEBYwQq 4VoGQRDzh18mLnPnMmoyonzJ0H9hIh6Y0rdyF8tmvFmGHnxwuHgUk1gm2gCTI2ZmpsjW G2F0jSKdZZ+ZnJd4/KLRuF4gVuZlhW/DgCLtpw3udjZ6L3RqY4AhtwwF0k3Y6x9Fem9C ZOLO7YCRR5gK/gk9e9MqJxCRp6fJNg2Ys/7rSQqB68NmyLl+SkvDmSEbDmCe/f1iKlpm ggdfi5Yt+xpCg4ir0413QXkXpQP/3y3wXeEQPhtxd5ECD8UxvmSVXqYem88YctnqOFhh 8c+w== X-Gm-Message-State: ABUngvdBUOYQbmBMlJ7dRhX0/c2JXGhd5IcjbxNAwSNY4cTy1u8BBXGEYAXHkMqM5e7e7nycaBF3yCI1Mkam7g== X-Received: by 10.237.53.56 with SMTP id a53mr2374982qte.85.1478772989611; Thu, 10 Nov 2016 02:16:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 10 Nov 2016 02:16:29 -0800 (PST) From: Martin Thomson Date: Thu, 10 Nov 2016 21:16:29 +1100 Message-ID: To: quic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [QUIC] quic-tls update X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 10:16:32 -0000 Because I didn't have time to update the draft based on discussion and draft-18 of TLS, I have done so today. You can get a preview: https://martinthomson.github.io/quic-tls/big_update/ https://github.com/martinthomson/quic-tls/pull/17 From nobody Thu Nov 10 02:20:47 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93BF12966F for ; Thu, 10 Nov 2016 02:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWwxzSA-K_ti for ; Thu, 10 Nov 2016 02:20:44 -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 044A812965F for ; Thu, 10 Nov 2016 02:20:43 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id i145so137411557ywg.2 for ; Thu, 10 Nov 2016 02:20:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0nYvNON41+sL2VF8R4fK/xBe6hD+gCHHAZchzGWw7PQ=; b=KiDpUkz1rhzDOFqy/VhCM1sQfgs4hrsfZDn54EMNkJnZFSO4kbkvw4mR9VkU553vRb L5TzMT2zkOh3AezDtb3xHiF+Yo6Kqm9mlHDtHFT1XlG2BiW2K763kCjVGlnohNjutVeZ 4lTINIO94mjIACvgmGjJ9xjCElp8UNzWodagcqvsf9uKRdXJgtH27Na1SfSdxD584xTM 8Fhdirq1iDPazMUCEPrLu/dBp+sV8ZGiN6BD/CQtX6+G7Gv8mRV44Ecdl0+jAK9ApXlW yvdVgOdrFTRuiPTJuAY2r0ne3u+trxRITdA+9QYLaCiXgm6/SOksuKV1NvX3T8GIKkTv fl7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0nYvNON41+sL2VF8R4fK/xBe6hD+gCHHAZchzGWw7PQ=; b=d3HJQ3k4xrKnow2LCeRVFR2rxfGBtCvNpagiijxsJ3Bwg/xZNFU1BnIuzvOHLG1TJn d1QUGv5fBOxkPgUKKP/2iH0MbA3tIzs4xqauWn83FwTRxSL7XprVjOQkcAY0ybbKGiP/ NweiYDM0MWoX+n2ZS2oAi6fwmLiWKzCpHSCxQlRAPV37EeMo5wxKvkKu65RDFqOg+0Py r2PZF9AIy4GVTldoKANlN6WVMicdq02K0xDQ+Jpjas/HFYwEFAoxsFuwsz5jKtXXdf8J B+EOGdHOzxtwu1b9tPJnSRgT8p2Iwjl4IV6Uq9cHlPtgcqGbplIaj7X6cTvflpJ2m/dB u8DQ== X-Gm-Message-State: ABUngvfu2qc8zO0yca3xEsSf3gDvPVNWzpvbkrp8JZ6nzgy9IlxU1CzuKiUCTxbI32XsiiK8XLLKYAjOQEb/dtna X-Received: by 10.13.210.198 with SMTP id u189mr3954718ywd.317.1478773243011; Thu, 10 Nov 2016 02:20:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.203.69 with HTTP; Thu, 10 Nov 2016 02:20:22 -0800 (PST) In-Reply-To: <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> From: Ian Swett Date: Thu, 10 Nov 2016 05:20:22 -0500 Message-ID: To: Cory Benfield Content-Type: multipart/alternative; boundary=001a114da73cdafd4f0540efb945 Archived-At: Cc: Jana Iyengar , quic@ietf.org, Martin Thomson , Patrick McManus Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 10:20:46 -0000 --001a114da73cdafd4f0540efb945 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable You're right, settings poses some unique challenges because of the implication on the connection. I don't think we want to add settings-specific machinery to every other frame, as that would seem to increase complexity greatly, though that epoch based approach would work. It may be possible to constrain mid-connection settings frames in a way that is not simple and practical. ie: increasing the max number of streams should always safe. A similar approach may be possible with frame size? On Thu, Nov 10, 2016 at 5:09 AM, Cory Benfield wrote: > > > On 10 Nov 2016, at 10:04, Ian Swett wrote: > > > > If a single frame type always required in order delivery, but you didn'= t > want HOL blocking on everything, you could use a stream per frame type. > > > > As such, any given HTTP/2 frame would need to specify if in-order > delivery is necessary, and if so, they should be sent on a single stream. > Otherwise, a stream per frame can be used. That seems fairly generalizab= le > to me? > > I don=E2=80=99t think it resolves SETTINGS though. H2=E2=80=99s SETTINGS = frame includes > some connection-wide values that affect all other frames (e.g. > SETTINGS_MAX_FRAME_SIZE), so with SETTINGS as written in 7540 it needs to > be possible to sort all frames into =E2=80=9Cbefore ACK=E2=80=9D and =E2= =80=9Cafter ACK=E2=80=9D if that > setting is changed: otherwise it=E2=80=99s very difficult to police the f= rame size. > > A monotonic counter on SETTINGS could perhaps be used to this effect, but > it=E2=80=99d require that all frames carry that counter on them and proba= bly that > frames from older settings regimes be discarded after a certain period of > time. I=E2=80=99m not entirely sure that that=E2=80=99s a good plan, but = it=E2=80=99s the first one > that leaps out at me. > > Cory > > --001a114da73cdafd4f0540efb945 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
You're right, settings poses some unique challenges be= cause of the implication on the connection.=C2=A0 I don't think we want= to add settings-specific machinery to every other frame, as that would see= m to increase complexity greatly, though that epoch based approach would wo= rk.

It may be possible to constrain mid-connection setti= ngs frames in a way that is not simple and practical. =C2=A0ie: increasing = the max number of streams should always safe.=C2=A0 A similar approach may = be possible with frame size?

On Thu, Nov 10, 2016 at 5:09 AM, Cory Benfield <cor= y@lukasa.co.uk> wrote:

> On 10 Nov 2016, at 10:04, Ian Swett <ianswett@google.com> wrote:
>
> If a single frame type always required in order delivery, but you didn= 't want HOL blocking on everything, you could use a stream per frame ty= pe.
>
> As such, any given HTTP/2 frame would need to specify if in-order deli= very is necessary, and if so, they should be sent on a single stream.=C2=A0= Otherwise, a stream per frame can be used.=C2=A0 That seems fairly general= izable to me?

I don=E2=80=99t think it resolves SETTINGS though. H2=E2=80=99s SETT= INGS frame includes some connection-wide values that affect all other frame= s (e.g. SETTINGS_MAX_FRAME_SIZE), so with SETTINGS as written in 7540 it ne= eds to be possible to sort all frames into =E2=80=9Cbefore ACK=E2=80=9D and= =E2=80=9Cafter ACK=E2=80=9D if that setting is changed: otherwise it=E2=80= =99s very difficult to police the frame size.

A monotonic counter on SETTINGS could perhaps be used to this effect, but i= t=E2=80=99d require that all frames carry that counter on them and probably= that frames from older settings regimes be discarded after a certain perio= d of time. I=E2=80=99m not entirely sure that that=E2=80=99s a good plan, b= ut it=E2=80=99s the first one that leaps out at me.

Cory


--001a114da73cdafd4f0540efb945-- From nobody Thu Nov 10 02:25:27 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9330129650 for ; Thu, 10 Nov 2016 02:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=DnlmrK1o; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=opwICOFW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edHTz8bjQa51 for ; Thu, 10 Nov 2016 02:25:24 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97AC512967C for ; Thu, 10 Nov 2016 02:25:23 -0800 (PST) Received: by mail.greenbytes.de (Postfix, from userid 117) id 0434115A0B4B; Thu, 10 Nov 2016 11:25:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1478773522; bh=Wd0QJUWZjyY4YriI0+RAvmqhtDFFU27fKQfA5Xfwni8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=DnlmrK1o+TtldZnsBt4HKRp8VLRv/cNr3Mixm8ryW3jdqhfMBMchzMvgSYP46u/2P 1t6TCDCb+Y5++u/aDJzNNFB1lk11Xh1QXhSVYG0IGhZX45cMz4P9j0n9+WJzhP2QtZ z/ccqpCenUzNMIJcGlXAm9vZAUeaEEnwjy7tSXp4= Received: from [192.168.1.175] (unknown [192.168.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id B3D5515A0048; Thu, 10 Nov 2016 11:25:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1478773518; bh=Wd0QJUWZjyY4YriI0+RAvmqhtDFFU27fKQfA5Xfwni8=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=opwICOFWpS9Er3XC6pD3ninAQHrhkXp8MKWJJaIo2m8dBbIbqneVKQvkFHT6f+wRJ tUPFiIOkuqxLZm5X+lV6d3yLhcjI3CdXxNkDaiDri2h132S6RcpqB7oxWJKaMbPIBH w5xSbDpPzIz0eVmETc8l2vaOMtV1lSB/3EingmPI= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Stefan Eissing In-Reply-To: <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> Date: Thu, 10 Nov 2016 11:25:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> To: Cory Benfield X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Jana Iyengar , Ian Swett , quic@ietf.org, Martin Thomson , Patrick McManus Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 10:25:26 -0000 > Am 10.11.2016 um 11:09 schrieb Cory Benfield : >=20 >=20 >> On 10 Nov 2016, at 10:04, Ian Swett wrote: >>=20 >> If a single frame type always required in order delivery, but you = didn't want HOL blocking on everything, you could use a stream per frame = type.=20 >>=20 >> As such, any given HTTP/2 frame would need to specify if in-order = delivery is necessary, and if so, they should be sent on a single = stream. Otherwise, a stream per frame can be used. That seems fairly = generalizable to me? >=20 > I don=E2=80=99t think it resolves SETTINGS though. H2=E2=80=99s = SETTINGS frame includes some connection-wide values that affect all = other frames (e.g. SETTINGS_MAX_FRAME_SIZE), so with SETTINGS as written = in 7540 it needs to be possible to sort all frames into =E2=80=9Cbefore = ACK=E2=80=9D and =E2=80=9Cafter ACK=E2=80=9D if that setting is changed: = otherwise it=E2=80=99s very difficult to police the frame size. >=20 > A monotonic counter on SETTINGS could perhaps be used to this effect, = but it=E2=80=99d require that all frames carry that counter on them and = probably that frames from older settings regimes be discarded after a = certain period of time. I=E2=80=99m not entirely sure that that=E2=80=99s = a good plan, but it=E2=80=99s the first one that leaps out at me. Urgh. But if there is no notion of "before" and "after" between frames = on different quic streams, as I understand it, the even this counter = would not help. As it affects all frames? or? This raises the question if the h2 framing layer can stay agnostic to = the actual transport (I doubt that). And that opens discussions about = how behaviour needs to change for these hop-by-hop properties of h2, = doesn't it? We are not talking about h2 over a tcp-to-quic gateway, = right? -Stefan= From nobody Thu Nov 10 02:27:19 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2196312967C for ; Thu, 10 Nov 2016 02:27:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=lukasa-co-uk.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 VGMp7ESNVk0h for ; Thu, 10 Nov 2016 02:27:15 -0800 (PST) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58146129650 for ; Thu, 10 Nov 2016 02:27:15 -0800 (PST) Received: by mail-wm0-x22e.google.com with SMTP id g23so31683183wme.1 for ; Thu, 10 Nov 2016 02:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lukasa-co-uk.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ByOFNc8opuLMP35c3UKE4hqw2wmcoaWE3HhnPkvcH9o=; b=qmcmLDSwUWdRMu9/ETvfH3jRkV4yQU/s5BjB/FdiD2JSr7QilQyEDfDLtZ9rdcv5Zj DYYAwGupy3LX0AtGki3fz1NnqrxyOZLFgOWx6yCGbzfJMogReYPIiK40cHDRe2xvv5hJ vHHWprLO0oCT5vSgm17yjNKwjNumYNbJOZHyszQjJcCB8ddfjSKPRIcf7vnehBNF+/cR cUUdjVBmZRPm5psqxw+R3IW6KujArOgSpkW8ILKMBMKDJx9HndEsgyeNFrCOzaR/88Oy znV0nkLAVixC2wQgHlRb/smRg/qMsHR3BN/qWz6TBHcj892sdaFRV6EHZJxP8RdWKbLT Kmow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ByOFNc8opuLMP35c3UKE4hqw2wmcoaWE3HhnPkvcH9o=; b=gewU4QTsvYc96CS6Z+QGSucCQtVUKjF4Q1ip3Ve9rPj1kHRa+dft6P6xvUMkUex+4G yd8aDRltbvsn26OT2Kc4yCY+1LPApm57fm6BRJOUaXoAPFjWZHAFmtrZ7sQME8R/qWXM iAphTtgd7Foa66spmTegmeP30s42cgje4tEvD80C3sZ4znkMC1IOAT+moZ11pXUH/Lca foFnynTccY4vdSNoEMhUasq3rwh871MF/F5eaLIi+bw3FUfZ/KBkCH76GyrQkGl2f4iI OfyPEvj69f9w08haZtORQycWDiCuXS5SZOcZKpFDdHJ9ZodysSUwV320pZ9ldOUAn3Le RT+A== X-Gm-Message-State: ABUngvchxoW3ljLQLohUpAPmEUvG0XLNJL4Pth5ZgnlZaC9P6+7wmKV0wXPViiKW8D7IDA== X-Received: by 10.28.111.70 with SMTP id k67mr24257336wmc.32.1478773633842; Thu, 10 Nov 2016 02:27:13 -0800 (PST) Received: from [192.168.1.5] (72.6.208.46.dyn.plus.net. [46.208.6.72]) by smtp.gmail.com with ESMTPSA id f76sm5354104wmd.15.2016.11.10.02.27.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Nov 2016 02:27:13 -0800 (PST) From: Cory Benfield Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C0CFAB34-FF10-4024-B920-0F7CE060578F" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3254\)) Date: Thu, 10 Nov 2016 10:26:56 +0000 In-Reply-To: To: Stefan Eissing References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> X-Mailer: Apple Mail (2.3254) Archived-At: Cc: Jana Iyengar , Ian Swett , quic@ietf.org, Martin Thomson , Patrick McManus Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 10:27:17 -0000 --Apple-Mail=_C0CFAB34-FF10-4024-B920-0F7CE060578F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Nov 2016, at 10:25, Stefan Eissing = wrote: >=20 >>=20 >> Am 10.11.2016 um 11:09 schrieb Cory Benfield : >>=20 >>=20 >>> On 10 Nov 2016, at 10:04, Ian Swett wrote: >>>=20 >>> If a single frame type always required in order delivery, but you = didn't want HOL blocking on everything, you could use a stream per frame = type.=20 >>>=20 >>> As such, any given HTTP/2 frame would need to specify if in-order = delivery is necessary, and if so, they should be sent on a single = stream. Otherwise, a stream per frame can be used. That seems fairly = generalizable to me? >>=20 >> I don=E2=80=99t think it resolves SETTINGS though. H2=E2=80=99s = SETTINGS frame includes some connection-wide values that affect all = other frames (e.g. SETTINGS_MAX_FRAME_SIZE), so with SETTINGS as written = in 7540 it needs to be possible to sort all frames into =E2=80=9Cbefore = ACK=E2=80=9D and =E2=80=9Cafter ACK=E2=80=9D if that setting is changed: = otherwise it=E2=80=99s very difficult to police the frame size. >>=20 >> A monotonic counter on SETTINGS could perhaps be used to this effect, = but it=E2=80=99d require that all frames carry that counter on them and = probably that frames from older settings regimes be discarded after a = certain period of time. I=E2=80=99m not entirely sure that that=E2=80=99s = a good plan, but it=E2=80=99s the first one that leaps out at me. >=20 > Urgh. But if there is no notion of "before" and "after" between frames = on different quic streams, as I understand it, the even this counter = would not help. As it affects all frames? or? The counter helps only because you identify what SETTINGS regime applies = to any given frame. This could also probably be done using some of QUICs = packet-tracking and loss-recovery mechanisms (when there are no more = frames under SETTINGS regime 3 undelivered we can now forget about = SETTINGS regime 3), but I agree: this is pretty gross and I don=E2=80=99t = think it=E2=80=99s a good idea. Just a strawman to kick around. --Apple-Mail=_C0CFAB34-FF10-4024-B920-0F7CE060578F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 10 Nov 2016, at 10:25, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:


Am 10.11.2016 um 11:09 schrieb Cory = Benfield <cory@lukasa.co.uk>:


On 10 Nov 2016, at = 10:04, Ian Swett <ianswett@google.com> wrote:

If a single frame type always required in order delivery, but = you didn't want HOL blocking on everything, you could use a stream per = frame type. 

As such, any given HTTP/2 frame would need to = specify if in-order delivery is necessary, and if so, they should be = sent on a single stream.  Otherwise, a stream per frame can be = used.  That seems fairly generalizable to me?

I don=E2=80=99t think it resolves = SETTINGS though. H2=E2=80=99s SETTINGS frame includes some = connection-wide values that affect all other frames (e.g. = SETTINGS_MAX_FRAME_SIZE), so with SETTINGS as written in 7540 it needs = to be possible to sort all frames into =E2=80=9Cbefore ACK=E2=80=9D and = =E2=80=9Cafter ACK=E2=80=9D if that setting is changed: otherwise it=E2=80= =99s very difficult to police the frame size.

A monotonic counter on SETTINGS could perhaps be used to this = effect, but it=E2=80=99d require that all frames carry that counter on = them and probably that frames from older settings regimes be discarded = after a certain period of time. I=E2=80=99m not entirely sure that = that=E2=80=99s a good plan, but it=E2=80=99s the first one that leaps = out at me.

Urgh. But if there is no notion of = "before" and "after" between frames on different quic streams, as I = understand it, the even this counter would not help. As it affects all = frames? or?

The counter = helps only because you identify what SETTINGS regime applies to any = given frame. This could also probably be done using some of QUICs = packet-tracking and loss-recovery mechanisms (when there are no more = frames under SETTINGS regime 3 undelivered we can now forget about = SETTINGS regime 3), but I agree: this is pretty gross and I don=E2=80=99t = think it=E2=80=99s a good idea. Just a strawman to kick around.


= --Apple-Mail=_C0CFAB34-FF10-4024-B920-0F7CE060578F-- From nobody Thu Nov 10 02:45:02 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9D51293D8 for ; Thu, 10 Nov 2016 02:45:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9zCGaxDjO5B for ; Thu, 10 Nov 2016 02:44:58 -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 7E4F11294C9 for ; Thu, 10 Nov 2016 02:44:58 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id t125so234084262ywc.1 for ; Thu, 10 Nov 2016 02:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FzsjTYAihYOuCCCzF9CGNuMfCSTQTyJF4KJi/4EZRSQ=; b=Ef03MXtvp9R3sAjptiEKRGKaQtdcNlBXqBVrfVtJLH0ElXToKEG63NpEYVua3Q5a44 XZGOE0VA0/a8Hsh9YnjBotIrJT7Ar18EUQqIgXVH3UGFj3srprbS+A3uC/C3dBjmRCoi 3bcrNyG9eLrme5SPzCav6k/NjPMFR2mGnsSCZ7KzzPn4WRWuc11cTkllneSFQmE/bTbm M23g7TDxfYY3eBTHxfGpCAQOwwZzqXH/4NY6ccM52ddTv7cfsdSgukXgevdHiBU6LfGH dahecQ1OUW8b2ze6NdzQbRxRYoSuLHwqvuI8OmzJNK8MQ/nQiM9bArwBqO9UnNf8WiqC MdKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FzsjTYAihYOuCCCzF9CGNuMfCSTQTyJF4KJi/4EZRSQ=; b=S5UlL6TuEHiXfcZCYcOphce/y20L5e79sRZY3wnqqBzcKDlidOtAeQGf/Tdpb3eGC8 Wj6EaO71Tmyd5iIkuwsS9NBgxPltNVcsumix3CHaz0/eSsPttxQ2PsH0L5V2q3ekAIGp 6yQ2pdbD//aBnIOzLdtSbcAPBo4blwM7M1de2Kh/5TaLmuhjii9FKu+13q6IsjTlpzHX o7HcFZqha8PjmPvJxB84KzNBbwRnSkn5m557UWmvM6yIUaWz1u2LHKNl/psyUM+RWDbq dH8x0I4hoh+xj5izHPMIPv0Zt+COmPYj19wwqh3sNUHoZhd7OgXGU/sKVMIJEQ1jIoZ0 T+1Q== X-Gm-Message-State: ABUngveL+D0+UPdD/K48y6DIqY/Q43A0MfsIglSwKh1l9SamSDnRVwJnkvqhBxDSLrut4W5i5B7fUBkg312B3ADe X-Received: by 10.129.116.195 with SMTP id p186mr4022412ywc.153.1478774697592; Thu, 10 Nov 2016 02:44:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.203.69 with HTTP; Thu, 10 Nov 2016 02:44:37 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 10 Nov 2016 05:44:37 -0500 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1147fc588ddb0f0540f01086 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Packet number recovery X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 10:45:01 -0000 --001a1147fc588ddb0f0540f01086 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 10, 2016 at 12:23 AM, Martin Thomson wrote: > Sayeth Section 4.2.1: > > a QUIC sender MUST NOT have more > than 2^(packet_number_size - 2) in flight at any point in the > connection > > and: > > Any truncated packet number received from a peer MUST be > reconstructed as the value closest to the next expected packet number > from that peer. > > (relatively) big questions: > > Q1 > I don't think that this limit is necessary. The point is to use a > packet number that is big enough that reordering won't cause an > endpoint to recover the wrong packet number. > Agreed, MUST here is completely unnecessary. I think it's a reasonable recommendation, however. > > I can see how you get here. You only predict backwards for 2^N-1 > packets. You want to divide that into packets that were in the last > RTT worth and packets that are in the next RTT worth. The former > because you haven't received an ACK for those yet, and the latter > because you are sending those. I think that's overly pessimistic by a > factor of two because you only have one RTT plus delta unacknowledged > packets at any instant (delta being the RTT variance plus any ack > collation delays). Of course I'd be happy to see some data that > proved me wrong. > > At some point we had FEC. FEC had a side-effect of limiting how often we could change the packet number length to once per FEC group. That and an abundance of caution was how this was chosen. We no longer have FEC, so it's a matter of how cautious we want to be. I will say that sometimes packets arrive more than one RTT out of order(crazy, but true), but it's possible we don't care about that case. > Q2 > I don't think that this is the only possible algorithm, or even the > best. For instance, before there was anything in the QUIC spec, I > described an algorithm that looks exclusively backwards from the last > received packet. If a packet with that number was already received, > then it's in the future and add 2^(packet_number_size) to get the real > number. Otherwise, look in the window around the predicted next > value. Assuming low loss rates, this doubles the search space. > > To be fully correct, this would require storing every previous packet number received. I think the larger concern is that if one or many packets in the past were missing, you'd have to do trial decryption every time the packet 2^(packet_number_size) greater was received, correct? I believe not doing trial decryption could end up with a stuck connection in worst case scenarios. > I don't think that we need a MUST on the actual algorithm, just a > suggestion about what to use. If someone wants to do something > slightly different, then that's OK. For instance, I can imagine some > crazy folks doing trial decryption to recover packet numbers over a > larger window. I can also imagine very limited implementations that > insist on monotonic packet numbers and drop older packets > unconditionally, even if they are only microseconds late. > > Some of those options are especially suboptimal on various measures, > but the key point is that none of them introduce interoperability > failures. Lost frames are retransmitted as necessary and the world > moves one. > > (Actually, that last one is probably a terrible idea because it would > create a ridiculously high false loss signal that the congestion > controller would react badly to, but I think that it is still not an > interoperability failure.) > Fair point, again the use of MUST on the decoding side seems strong. Of course, encoding the packet number is a MUST. Sure, the receiver would definitely get lower bandwidth, but that would be the tradeoff. > > (annoying) little questions: > > Q3 > Please define "in flight". I've assumed that this means in the same > RTT. I also realize that this is fuzzy. Jitter, buffering and other > factors mean that you can end up with more or less packets in the air > than your predictions lead you to expect. I still want a more > concrete definition if we're going with a MUST here. > > I can think of several answers: > in_flight = pn[last_sent] - pn[highest_acknowledged] > in_flight = pn[last_sent] - pn[sent_at(now-RTT)] > in_flight = pn[last_sent] - pn[sent_at((now-RTT)/2)] > The TCP draft(https://tools.ietf.org/html/rfc5681) defines flight size, which is typically known as inflight or inflight in my experience, but I realize QUIC should have it's own definition, since there's no cumulative acknowledgement point. FLIGHT SIZE: The amount of data that has been sent but not yet cumulatively acknowledged. I'll propose: The amount of data that has been sent but not yet acknowledged or declared lost. > Q4 > What happens if there are two equidistant options? This happens when > abs(n[last_received] & (2^(packet_number_size)-1) - > received_packet_number) == 2^(packet_number_size-1) e.g., the last > received is 256 and the next one is an 8-bit 129. (Points off for > looking at what Ian's code does.) > > Well, the approach should be changed to a SHOULD from a MUST, so maybe it doesn't matter :) In seriousness, if one is using a 4x cushion, then this should never be a problem, so I think either is fine. --001a1147fc588ddb0f0540f01086 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 10, 2016 at 12:23 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
Sayeth Section 4.2.1:

=C2=A0 =C2=A0a QUIC sender MUST NOT have more
=C2=A0 =C2=A0than 2^(packet_number_size - 2) in flight at any point in the<= br> =C2=A0 =C2=A0connection

and:

=C2=A0 =C2=A0Any truncated packet number received from a peer MUST be
=C2=A0 =C2=A0reconstructed as the value closest to the next expected packet= number
=C2=A0 =C2=A0from that peer.

(relatively) big questions:

Q1
I don't think that this limit is necessary.=C2=A0 The point is to use a=
packet number that is big enough that reordering won't cause an
endpoint to recover the wrong packet number.

Agreed, MUST here is completely unnecessary.=C2=A0 I think it's a= reasonable recommendation, however.
=C2=A0

I can see how you get here.=C2=A0 You only predict backwards for 2^N-1
packets.=C2=A0 You want to divide that into packets that were in the last RTT worth and packets that are in the next RTT worth.=C2=A0 The former
because you haven't received an ACK for those yet, and the latter
because you are sending those.=C2=A0 I think that's overly pessimistic = by a
factor of two because you only have one RTT plus delta unacknowledged
packets at any instant (delta being the RTT variance plus any ack
collation delays).=C2=A0 Of course I'd be happy to see some data that proved me wrong.

At some point we had FEC.=C2=A0 FEC had a side-effect= of limiting how often we could change the packet number length to once per= FEC group.=C2=A0 That and an abundance of caution was how this was chosen.= =C2=A0 We no longer have FEC, so it's a matter of how cautious we want = to be.

I will say that sometimes packets arrive mo= re than one RTT out of order(crazy, but true), but it's possible we don= 't care about that case.
=C2=A0
Q2
I don't think that this is the only possible algorithm, or even the
best.=C2=A0 For instance, before there was anything in the QUIC spec, I
described an algorithm that looks exclusively backwards from the last
received packet.=C2=A0 If a packet with that number was already received, then it's in the future and add 2^(packet_number_size) to get the real<= br> number.=C2=A0 Otherwise, look in the window around the predicted next
value.=C2=A0 Assuming low loss rates, this doubles the search space.

To be fully correct, this would require storing every= previous packet number received.=C2=A0 I think the larger concern is that = if one or many packets in the past were missing, you'd have to do trial= decryption every time the packet 2^(packet_number_size) greater was receiv= ed, correct?=C2=A0 I believe not doing trial decryption could end up with a= stuck connection in worst case scenarios.
=C2=A0
I don't think that we need a MUST on the actual algorithm, just a
suggestion about what to use.=C2=A0 If someone wants to do something
slightly different, then that's OK.=C2=A0 For instance, I can imagine s= ome
crazy folks doing trial decryption to recover packet numbers over a
larger window.=C2=A0 I can also imagine very limited implementations that insist on monotonic packet numbers and drop older packets
unconditionally, even if they are only microseconds late.

Some of those options are especially suboptimal on various measures,
but the key point is that none of them introduce interoperability
failures.=C2=A0 Lost frames are retransmitted as necessary and the world moves one.

(Actually, that last one is probably a terrible idea because it would
create a ridiculously high false loss signal that the congestion
controller would react badly to, but I think that it is still not an
interoperability failure.)

Fair point, = again the use of MUST on the decoding side seems strong.=C2=A0 Of course, e= ncoding the packet number is a MUST.

Sure, the rec= eiver would definitely get lower bandwidth, but that would be the tradeoff.=
=C2=A0

(annoying) little questions:

Q3
Please define "in flight".=C2=A0 I've assumed that this means= in the same
RTT. I also realize that this is fuzzy. Jitter, buffering and other
factors mean that you can end up with more or less packets in the air
than your predictions lead you to expect.=C2=A0 I still want a more
concrete definition if we're going with a MUST here.

I can think of several answers:
in_flight =3D pn[last_sent] - pn[highest_acknowledged]
in_flight =3D pn[last_sent] - pn[sent_at(now-RTT)]
in_flight =3D pn[last_sent] - pn[sent_at((now-RTT)/2)]

The TCP draft(https://tools.ietf.org/html/rfc5681) defines flight size, which is t= ypically known as inflight or inflight in my experience, but I realize QUIC= should have it's own definition, since there's no cumulative ackno= wledgement point. =C2=A0
=C2=A0
FLIGHT SIZE: The amount of data tha= t has been sent but not yet
=C2=A0 =C2=A0 =C2=A0 cumulatively acknowledg= ed.

I'll propose: The amount of data that has been sent but not = yet acknowledged or declared lost.


Q4
What happens if there are two equidistant options?=C2=A0 This happens when<= br> abs(n[last_received] & (2^(packet_number_size)-1) -
received_packet_number) =3D=3D 2^(packet_number_size-1)=C2=A0 e.g., the las= t
received is 256 and the next one is an 8-bit 129.=C2=A0 (Points off for
looking at what Ian's code does.)


Well, the approach = should be changed to a SHOULD from a MUST, so maybe it doesn't matter := )

In s= eriousness, if one is using a 4x cushion, then this should never be a probl= em, so I think either is fine.
--001a1147fc588ddb0f0540f01086-- From nobody Thu Nov 10 03:14:31 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53A6129555 for ; Thu, 10 Nov 2016 03:14: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, 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 ODaI640dBLbz for ; Thu, 10 Nov 2016 03:14:28 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AE4312952C for ; Thu, 10 Nov 2016 03:14:28 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id q130so291336149qke.1 for ; Thu, 10 Nov 2016 03:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ObCH0M+AfXb1Ep4UsJhF+HsspER3FJzYT9419L0MDBk=; b=g/ShfB9gY2yFhV8VVYbFV7/wP2K3M0A9z8aG9rh8jHdusMxDTwBPzAandyVqd5+xc1 7pVNXSVLV8D4MUWF+3qgaJ3WnVuNq0ngEq2/7g8vVcEZZwai2bKTw8x9xfV4IRAeYAwh 2+DLrTP9G+bMHTrohexcDQM29XHNbRr/wHyIsOOBFN3EKUaWCeRAYf5OXdg3g866MrbZ DNBMFVPtjBHA+0FARVOJ9mlEY5Vwo7JGGc3gln7ehJy76szBHeIAqTFKjI2c4+4q2X+W NZBGRdopnRIRshL6cXgOu06xIy40tAfCBhmY7o/RVdqJujl5XWryVYXdokvQP0alvOly mq6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ObCH0M+AfXb1Ep4UsJhF+HsspER3FJzYT9419L0MDBk=; b=VIkg+8UnSf4sQD1RRJiuVI0jD7PJkNQkI34klEX1s/3Ux1SerxJ3WRmfyjSThH4Ouk 8+YxJCRnqjvqF7ANCJ3MPbvftLV/m6mr6vFDD6y4jUGIOKMoFMdDqy9JzHkE81a/0LID g+CIVfzVMps+z8ljrbNwwmF/JA/StcVpi7V5bXXJuY2LCJamfh8+gpt6g38O5IBkyAby mFA/XllQuj7HBMXdUP8WT18XigSlc2Uz8F7FeCkPftd/boxPscNvgzpD3ZbVZSrPGtNL 0ovMwnOTKtTTBtPRb+Hn0X5nPcpEGJUnqeiUxYtkT5gLo7UPiFcmVZ0z3VSs5558VHfB eciw== X-Gm-Message-State: ABUngvfRXkDvp2OmMNbqHvy0sW5k2mWyhHKSyJJ5160n6vOuczn3TgRzc+gN2ya5PMKIckRtPVRAQVd4wg5KPA== X-Received: by 10.55.74.1 with SMTP id x1mr5303178qka.316.1478776467853; Thu, 10 Nov 2016 03:14:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 10 Nov 2016 03:14:27 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 10 Nov 2016 22:14:27 +1100 Message-ID: To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Packet number recovery X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 11:14:30 -0000 On 10 November 2016 at 21:44, Ian Swett wrote: > To be fully correct, this would require storing every previous packet number > received. I think the larger concern is that if one or many packets in the > past were missing, you'd have to do trial decryption every time the packet > 2^(packet_number_size) greater was received, correct? In our DTLS implementation, we track the last received packet and use a bit vector to mark the N packets that precede it. That was what I was thinking here. As long as N is greater than the number of packets in flight in most cases, this should work. Trial decryption isn't necessary, it just allows you to go even further into the future if you want. It lets you go further into the past if you want to repair gaps a long way back or you don't track received messages. From nobody Thu Nov 10 03:20:18 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE997129684 for ; Thu, 10 Nov 2016 03:20:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3ARbLwbUfbz for ; Thu, 10 Nov 2016 03:20:10 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 C937D1296A3 for ; Thu, 10 Nov 2016 03:20:09 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id d128so87129053ybh.2 for ; Thu, 10 Nov 2016 03:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bmmUdU6yTRfgGCl8QKSPyQ/FwA4K/Z65IRh9jbDhTEI=; b=csX8sQ7rnp9cii6bx8hC1W8FL/bsKATBOOoZejfC/m+FjbrqOIZQ/Tlw4YQqsIraNV /1Nje+jYYcUk2/4F1lZvnlDpCAIzavCgirKrMMUrgM3M7oyyZqwJ2jPoX+9Ds79PKV1z EYAPE0PHRdFgQsBUXRiGpg49hGSOgy7mHN+2CJYVNQNF4KCbVuxhBgYpo3mxX4TK8zXg 235iO/eFSYZWMZb3yehRBpVozeDbc5e9otzGln+L3ZGpp4LCBl5ijSIHPtppF8dBqxQO YX/vKUpSYSZM0pXlFuBw5cMWAAoFkgC3yXxEwFUOwGzTE9CC/sbHgkaB0yg3rsIsoQWy lghw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bmmUdU6yTRfgGCl8QKSPyQ/FwA4K/Z65IRh9jbDhTEI=; b=WyuLBCSK+2canWhLmDbZtJLTnS4Qwa97yKbhRtiWpMKjJkMzUkhkH9a0LgZ+61Z0km DCJb4aSxYTZsNXH7MCEu71qWMMbZCtTX8Q78BXI2EsFndVG7QqUjLLq1fiKNoq5DcmBb M5vwzGi3CsJqARXEiMR/h8wsROaruI+T8h+njp6gDPrXh3lEhLAbjyt0XaF/xSNgZpwi uyqXicDPIn6sST9VfbfztEznQQfMBy0F92/LHGdg7rgSSV5lWB2/NJVSw1o8vkihd2ka dHbNVYIuG0Z9oIYoAHOp2B4tUejaSRKqbBd7XJj7Sm40r0qdR0m4c4P1eBokikXO9xzB 0hNg== X-Gm-Message-State: ABUngvdWeHrN93lJfZN8qPPZsf+CBdDbOkpg9A3zYKeN+c5fDka8i6Z3+RiJFFFzobpgLIcyEC7uTpwfyaaZoLWj X-Received: by 10.37.58.196 with SMTP id h187mr4663681yba.73.1478776808834; Thu, 10 Nov 2016 03:20:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.203.69 with HTTP; Thu, 10 Nov 2016 03:19:48 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 10 Nov 2016 06:19:48 -0500 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114c71706544b50540f08e67 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Packet number recovery X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 11:20:16 -0000 --001a114c71706544b50540f08e67 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 10, 2016 at 6:14 AM, Martin Thomson wrote: > On 10 November 2016 at 21:44, Ian Swett wrote: > > To be fully correct, this would require storing every previous packet > number > > received. I think the larger concern is that if one or many packets in > the > > past were missing, you'd have to do trial decryption every time the > packet > > 2^(packet_number_size) greater was received, correct? > > In our DTLS implementation, we track the last received packet and use > a bit vector to mark the N packets that precede it. That was what I > was thinking here. As long as N is greater than the number of packets > in flight in most cases, this should work. > > Trial decryption isn't necessary, it just allows you to go even > further into the future if you want. It lets you go further into the > past if you want to repair gaps a long way back or you don't track > received messages. > It isn't strictly necessary, but if I have a 100 packet gap sometime in the past, then every time I receive a packet that lines up with that gap, I would try to decrypt it as the old packet number, which would fail, and then I'd either drop it or do trial decryption. Dropping it seems very problematic, as it creates 'echoes' of losses which could repeat indefinitely. Or possibly the above isn't what you had in mind? --001a114c71706544b50540f08e67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 10, 2016 at 6:14 AM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 10 November 2016 at 21:44, Ian Swett <ianswett@google.com> wrote:
> To be fully correct, this would require storing every previous packet = number
> received.=C2=A0 I think the larger concern is that if one or many pack= ets in the
> past were missing, you'd have to do trial decryption every time th= e packet
> 2^(packet_number_size) greater was received, correct?

In our DTLS implementation, we track the last received packet and us= e
a bit vector to mark the N packets that precede it.=C2=A0 That was what I was thinking here.=C2=A0 As long as N is greater than the number of packets=
in flight in most cases, this should work.

Trial decryption isn't necessary, it just allows you to go even
further into the future if you want.=C2=A0 It lets you go further into the<= br> past if you want to repair gaps a long way back or you don't track
received messages.

It isn't strict= ly necessary, but if I have a 100 packet gap sometime in the past, then eve= ry time I receive a packet that lines up with that gap, I would try to decr= ypt it as the old packet number, which would fail, and then I'd either = drop it or do trial decryption.=C2=A0 Dropping it seems very problematic, a= s it creates 'echoes' of losses which could repeat indefinitely.

Or possi= bly the above isn't what you had in mind?


--001a114c71706544b50540f08e67-- From nobody Thu Nov 10 03:51:21 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C3512963C for ; Thu, 10 Nov 2016 03:51:19 -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 BfAOy_inIjla for ; Thu, 10 Nov 2016 03:51:18 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 3AB5B1293F2 for ; Thu, 10 Nov 2016 03:51:18 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id w33so144492731qtc.3 for ; Thu, 10 Nov 2016 03:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mqwNXtuSZ1le9w/NnHJw0PpXaz1/KGb5fZ9uhyk8pPU=; b=D5vyOqk9HetmQTpeYZ40AHXiYVzabKyRqlggqGii+cyKP80krrRQSep4itLpJrLdNK X5ytuzw/QBc7fU62SprMdv5HocdlVrUZ073C/g78W8WxowV1k/zOhAT9tPHm6kFeUWyc 7+HgacD01PPhvBkIuV5kHDctFdDSk92GrdW7xUYYcAKdf1GEWZ77Pc2dVQmhDhXr5rhG QeUYBKI3tGUWxcMlLbHo6lIipUBdIrFdWQ5+ZkpF8S91l9Rd8039e9YIgrHWFyfBJTWa V4X/N93yjCRZUbOes3Ckr16MNAS+6EHDyijbc1cJlqJEk74DyKxrk0qLSRbkSJSxPSvz jhUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mqwNXtuSZ1le9w/NnHJw0PpXaz1/KGb5fZ9uhyk8pPU=; b=MQXBvFE1ZRA0PWZLRfY5Gk6jcPTw1DIf0MNO4Z6lWOXoUPdA6c/PG+cQzuuSLWz326 6vJSnpGqgBZkabEEFpbJWmQcw7W/u4sesyhf7a14uRPOzNu150vTxQEFv7Ic4iEzLcN8 QvK4lkQJs3B4eBO8vO5o7LUkJ7powGs5jyv4rmhYtcnUsjEsvFYnHRLcU8YrvYqvizpE 7MaIdmB2aBSmCk6ubGO8zJYBz0vCNyl60C7/NR6sE3lwQjRNsMFKqb6H/3ViT8HUg/k5 bYUXTo01qcS9Wvl2jpf1SMZV2be9J8Obj3W7p4DziFLYTIeUCeh8bua0ykqeZBlvgmzo fcbg== X-Gm-Message-State: ABUngvcvggGprzN5XqWJJlvH8J+3S8Wdf+ECj80MBrxrPKmzQYLbWIShTMybhIKSB1u7Y2i8ZxqQjUdYNA+Jew== X-Received: by 10.200.56.27 with SMTP id q27mr5442888qtb.116.1478778677229; Thu, 10 Nov 2016 03:51:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 10 Nov 2016 03:51:16 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 10 Nov 2016 22:51:16 +1100 Message-ID: To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Packet number recovery X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 11:51:19 -0000 On 10 November 2016 at 22:19, Ian Swett wrote: > It isn't strictly necessary, but if I have a 100 packet gap sometime in the > past, then every time I receive a packet that lines up with that gap, I > would try to decrypt it as the old packet number, which would fail, and then > I'd either drop it or do trial decryption. Dropping it seems very > problematic, as it creates 'echoes' of losses which could repeat > indefinitely. Ahh, so packet 1 is lost, but then packet 257 comes along as it identified as slotting into that hole, forcing it to be dropped. Even if that was the very next packet. The idea is bad because it effectively searches first in the range (last-2^sz, last-1). It commits to this range when there is packet loss, leading to the problem you identified. It can't be repaired without trial decryption: the thing I was hoping to avoid :(. From nobody Thu Nov 10 11:29:04 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D7F1295AC for ; Thu, 10 Nov 2016 11:29:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bxdh8ES3Pcvo for ; Thu, 10 Nov 2016 11:29:01 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0106.outbound.protection.outlook.com [104.47.38.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 B9538129697 for ; Thu, 10 Nov 2016 11:29:00 -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=85XGxptrTgAOVUe84T1eG4YXI4NNcfjb92iyZ/bei6U=; b=MopIxhr3EAW5PXKW2jgkzRstfNqqqOUJbMTmWnpjUfhkU41aoDZ//Z1Gm87C6RcRy0kCgbb8XEqSLIrKCMAQvJjseXOyIO3n8LiC9es82v6UpgfvtW80IGXdANIS30BXcdpdlnqBfzhYRtCAj7hdVoXtDkPJAkxyaNf7eGiXPlE= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Thu, 10 Nov 2016 19:28:58 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0707.006; Thu, 10 Nov 2016 19:28:58 +0000 From: Mike Bishop To: Cory Benfield , Stefan Eissing Thread-Topic: [QUIC] h2 mapping - extensions Thread-Index: AQHSNhrWVkwvFIuWr0eoGbjCghGjY6DN7XKAgAACUICAADTogIAC3/cAgABN1QCAAJg9gIAAGG2AgAAEPACAAAGNgIAABFgAgAAAdQCAAI4iYA== Date: Thu, 10 Nov 2016 19:28:58 +0000 Message-ID: References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> 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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8::3e4] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:JbrikXQ4WW5dAn0LNmiSULORPaKWOgRKW1eEj37mB61qEZAsTKch4pzG6eeeN/6UB5Tw3sAeqEAYX9v4h8pEj2SclzwrrAuV+Xe8TIcMqXawQXeeDMd9JlWRWCDBsgcqXsqe8JpW4FknfF9Npq649Grs6dFE3uf64rXWx1X+quIqxkg2OjDSj5IN/I+VnHEEZ7WDqufqObXNY/MIgMfNmn3foCXPveWPsgRle3vt7NFZsJSP5RS9XasClZFeA1pLrdup/UXwtDwYOWmLR3vaE2SdYor3bE7q29CHFeASGaCWlACUqlntPlK9FJ1qUGW3VGzkuSIB4hn+biDZemizyC9nzocHD5Hp1DzIosDa9kCyUFn7L4hK7tllHbGh/isI x-ms-office365-filtering-correlation-id: c370fb63-da55-4b20-4883-08d4099fd161 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(6060229)(6045074)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6061226); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 01221E3973 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(24454002)(377454003)(93886004)(87936001)(7696004)(92566002)(19609705001)(2906002)(8676002)(5660300001)(97736004)(76576001)(5005710100001)(10290500002)(8990500004)(5001770100001)(50986999)(105586002)(77096005)(99286002)(106356001)(81156014)(4326007)(106116001)(2950100002)(76176999)(54356999)(2900100001)(33656002)(81166006)(10090500001)(9686002)(7736002)(122556002)(7846002)(86362001)(101416001)(68736007)(6116002)(102836003)(189998001)(8936002)(790700001)(3660700001)(229853002)(3280700002)(586003)(86612001)(74316002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27084EA442F6464A6A85C51B87B80BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2016 19:28:58.2445 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: Jana Iyengar , Ian Swett , "quic@ietf.org" , Martin Thomson , Patrick McManus Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 19:29:04 -0000 --_000_BN6PR03MB27084EA442F6464A6A85C51B87B80BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXTigJlzICh1bmZvcnR1bmF0ZWx5KSBmYWlybHkgc2ltaWxhciB0byB3aGF0IEnigJl2ZSBiZWVu IGtpY2tpbmcgYXJvdW5kIHdpdGggcmVnYXJkIHRvIGxvb3NlbmluZyBIUEFDSy4gIFlvdSB1bHRp bWF0ZWx5IGhhdmUgdG8gaGF2ZSBidWlsZCBzb21lIHN5bmNocm9uaXphdGlvbiBwb2ludCB0byBr bm93IHdoZW4geW91IGNhbiBmcmVlIG1lbW9yeSBzYWZlbHksIGFuZCB0aGF0IHJlcXVpcmVzIGtu b3dpbmcgd2hlbiB5b3XigJlyZSBkb25lIHVzaW5nIHRoZSBvbGQgc3RhdGUuICBPciB5b3UgaGF2 ZSBzb21lIGxldmVsIG9mIG9wdGltaXNtIGFib3V0IGRpc2NhcmRpbmcgdGhpbmdzIGFuZCBoYXZl IGEgbm9uLWZhdGFsIGVycm9yIHRoYXQgZm9yY2VzIGEgcmUtc2VuZCBvbiBhIG5ldyBzdHJlYW0g d2l0aCB0aGUgbmV3IHN0YXRlLg0KDQpJdCBzZWVtcyBsaWtlIHRoZXJlIGFyZSBhIGNvdXBsZSBw YXRocyB3ZSBjYW4gZ28gaGVyZToNCg0KICAxLiAgSFRUUC8yIHJ1bnMgb3ZlciBhIFFVSUMgc3Ry ZWFtLCBtb2R1bG8gY2hhbmdlcw0KICAyLiAgRXZlcnkgcmVxdWVzdCBnZXRzIGEgc3RyZWFtOyBG cmFtZXMgcmVsYXRlZCB0byByZXF1ZXN0IG1haW50YWluIG9yZGVyDQoNCiAgICAgKiAgIFJlcXVp cmVzIGZyYW1pbmcgd2l0aGluIGVhY2ggc3RyZWFtDQogICAgICogICBSZXF1aXJlcyBjaGFuZ2Vz IHRvIEhQQUNLDQoNCiAgMS4gIEV2ZXJ5IGZyYW1lIHR5cGUgZ2V0cyBhIHN0cmVhbQ0KDQogICAg ICogICBDcm9zcy10eXBlIGRlcGVuZGVuY2llcyAoU0VUVElOR1MsIEhQQUNLKSBiZWNvbWUgcHJv YmxlbWF0aWMNCg0KICAxLiAgRXZlcnkgZnJhbWUgZ2V0cyBhIHN0cmVhbQ0KDQogICAgICogICBO ZXV0ZXJzIFFVSUPigJlzIHN0cmVhbS1iYXNlZCBmbG93IGNvbnRyb2wsIHNpbmNlIHlvdSBjYW4g bm8gbG9uZ2VyIHRocm90dGxlIGluZGl2aWR1YWwgcmVxdWVzdHMNCiAgICAgKiAgIE1lYW5zIGFy Yml0cmFyaWx5LWxhcmdlIEhUVFAvMiBmcmFtZXMgY291bGQgYmUgcGVybWl0dGVkIHdpdGhvdXQg YnJlYWtpbmcgbXVsdGlwbGV4aW5nDQoNClRoZSBwcmVzZW50IGRyYWZ0IGlzICMxLiAgQ29tYmlu aW5nICMzICYgIzQgZ2l2ZXMgc29tZSBmbGV4aWJpbGl0eSwgYnV0IHRoZW4gcmVxdWlyZXMga25v d2luZyBvbiBhIHBlci1mcmFtZSB0eXBlIGJlaGF2aW9yIHdoaWNoIGJlaGF2aW9yIGlzIG5lZWRl ZC4gIEkgY3VycmVudGx5IGxlYW4gdG93YXJkICMyLCBidXQgSeKAmW0gd2lsbGluZyB0byBiZSBj b252aW5jZWQgb3RoZXJ3aXNlLiAgVGFraW5nICMyIHRvIHRoZSBleHRyZW1lLCB5b3XigJlyZSBu byBsb25nZXIgY2FycnlpbmcgSFRUUC8yIG9yIGFueXRoaW5nIHRoYXQgcHJldGVuZHMgdG8gYmUg SFRUUC8yIOKAkyB5b3XigJlyZSBkZWZpbmluZyBhIGZyZXNoIHdheSB0byBjYXJyeSBIVFRQIHVz aW5nIGEgbmV3IHRyYW5zcG9ydCwgYW5kIG1vc3QgZXh0ZW5zaW9ucyBwcm9iYWJseSBuZWVkIHRv IGJlIHJlZGVmaW5lZCBpZiB0aGV5IHN0aWxsIGFwcGx5Lg0KDQpGcm9tOiBRVUlDIFttYWlsdG86 cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ29yeSBCZW5maWVsZA0KU2VudDog VGh1cnNkYXksIE5vdmVtYmVyIDEwLCAyMDE2IDI6MjcgQU0NClRvOiBTdGVmYW4gRWlzc2luZyA8 c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT4NCkNjOiBKYW5hIEl5ZW5nYXIgPGpyaUBnb29n bGUuY29tPjsgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgcXVpY0BpZXRmLm9yZzsg TWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IFBhdHJpY2sgTWNNYW51 cyA8cG1jbWFudXNAbW96aWxsYS5jb20+DQpTdWJqZWN0OiBSZTogW1FVSUNdIGgyIG1hcHBpbmcg LSBleHRlbnNpb25zDQoNCg0KT24gMTAgTm92IDIwMTYsIGF0IDEwOjI1LCBTdGVmYW4gRWlzc2lu ZyA8c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZTxtYWlsdG86c3RlZmFuLmVpc3NpbmdAZ3Jl ZW5ieXRlcy5kZT4+IHdyb3RlOg0KDQoNCkFtIDEwLjExLjIwMTYgdW0gMTE6MDkgc2NocmllYiBD b3J5IEJlbmZpZWxkIDxjb3J5QGx1a2FzYS5jby51azxtYWlsdG86Y29yeUBsdWthc2EuY28udWs+ PjoNCg0KDQoNCk9uIDEwIE5vdiAyMDE2LCBhdCAxMDowNCwgSWFuIFN3ZXR0IDxpYW5zd2V0dEBn b29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPj4gd3JvdGU6DQoNCklmIGEgc2lu Z2xlIGZyYW1lIHR5cGUgYWx3YXlzIHJlcXVpcmVkIGluIG9yZGVyIGRlbGl2ZXJ5LCBidXQgeW91 IGRpZG4ndCB3YW50IEhPTCBibG9ja2luZyBvbiBldmVyeXRoaW5nLCB5b3UgY291bGQgdXNlIGEg c3RyZWFtIHBlciBmcmFtZSB0eXBlLg0KDQpBcyBzdWNoLCBhbnkgZ2l2ZW4gSFRUUC8yIGZyYW1l IHdvdWxkIG5lZWQgdG8gc3BlY2lmeSBpZiBpbi1vcmRlciBkZWxpdmVyeSBpcyBuZWNlc3Nhcnks IGFuZCBpZiBzbywgdGhleSBzaG91bGQgYmUgc2VudCBvbiBhIHNpbmdsZSBzdHJlYW0uICBPdGhl cndpc2UsIGEgc3RyZWFtIHBlciBmcmFtZSBjYW4gYmUgdXNlZC4gIFRoYXQgc2VlbXMgZmFpcmx5 IGdlbmVyYWxpemFibGUgdG8gbWU/DQoNCkkgZG9u4oCZdCB0aGluayBpdCByZXNvbHZlcyBTRVRU SU5HUyB0aG91Z2guIEgy4oCZcyBTRVRUSU5HUyBmcmFtZSBpbmNsdWRlcyBzb21lIGNvbm5lY3Rp b24td2lkZSB2YWx1ZXMgdGhhdCBhZmZlY3QgYWxsIG90aGVyIGZyYW1lcyAoZS5nLiBTRVRUSU5H U19NQVhfRlJBTUVfU0laRSksIHNvIHdpdGggU0VUVElOR1MgYXMgd3JpdHRlbiBpbiA3NTQwIGl0 IG5lZWRzIHRvIGJlIHBvc3NpYmxlIHRvIHNvcnQgYWxsIGZyYW1lcyBpbnRvIOKAnGJlZm9yZSBB Q0vigJ0gYW5kIOKAnGFmdGVyIEFDS+KAnSBpZiB0aGF0IHNldHRpbmcgaXMgY2hhbmdlZDogb3Ro ZXJ3aXNlIGl04oCZcyB2ZXJ5IGRpZmZpY3VsdCB0byBwb2xpY2UgdGhlIGZyYW1lIHNpemUuDQoN CkEgbW9ub3RvbmljIGNvdW50ZXIgb24gU0VUVElOR1MgY291bGQgcGVyaGFwcyBiZSB1c2VkIHRv IHRoaXMgZWZmZWN0LCBidXQgaXTigJlkIHJlcXVpcmUgdGhhdCBhbGwgZnJhbWVzIGNhcnJ5IHRo YXQgY291bnRlciBvbiB0aGVtIGFuZCBwcm9iYWJseSB0aGF0IGZyYW1lcyBmcm9tIG9sZGVyIHNl dHRpbmdzIHJlZ2ltZXMgYmUgZGlzY2FyZGVkIGFmdGVyIGEgY2VydGFpbiBwZXJpb2Qgb2YgdGlt ZS4gSeKAmW0gbm90IGVudGlyZWx5IHN1cmUgdGhhdCB0aGF04oCZcyBhIGdvb2QgcGxhbiwgYnV0 IGl04oCZcyB0aGUgZmlyc3Qgb25lIHRoYXQgbGVhcHMgb3V0IGF0IG1lLg0KDQpVcmdoLiBCdXQg aWYgdGhlcmUgaXMgbm8gbm90aW9uIG9mICJiZWZvcmUiIGFuZCAiYWZ0ZXIiIGJldHdlZW4gZnJh bWVzIG9uIGRpZmZlcmVudCBxdWljIHN0cmVhbXMsIGFzIEkgdW5kZXJzdGFuZCBpdCwgdGhlIGV2 ZW4gdGhpcyBjb3VudGVyIHdvdWxkIG5vdCBoZWxwLiBBcyBpdCBhZmZlY3RzIGFsbCBmcmFtZXM/ IG9yPw0KDQpUaGUgY291bnRlciBoZWxwcyBvbmx5IGJlY2F1c2UgeW91IGlkZW50aWZ5IHdoYXQg U0VUVElOR1MgcmVnaW1lIGFwcGxpZXMgdG8gYW55IGdpdmVuIGZyYW1lLiBUaGlzIGNvdWxkIGFs c28gcHJvYmFibHkgYmUgZG9uZSB1c2luZyBzb21lIG9mIFFVSUNzIHBhY2tldC10cmFja2luZyBh bmQgbG9zcy1yZWNvdmVyeSBtZWNoYW5pc21zICh3aGVuIHRoZXJlIGFyZSBubyBtb3JlIGZyYW1l cyB1bmRlciBTRVRUSU5HUyByZWdpbWUgMyB1bmRlbGl2ZXJlZCB3ZSBjYW4gbm93IGZvcmdldCBh Ym91dCBTRVRUSU5HUyByZWdpbWUgMyksIGJ1dCBJIGFncmVlOiB0aGlzIGlzIHByZXR0eSBncm9z cyBhbmQgSSBkb27igJl0IHRoaW5rIGl04oCZcyBhIGdvb2QgaWRlYS4gSnVzdCBhIHN0cmF3bWFu IHRvIGtpY2sgYXJvdW5kLg0KDQoNCg== --_000_BN6PR03MB27084EA442F6464A6A85C51B87B80BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xp c3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0K CW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJ e21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjExOTc2NTUxOTsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEyMDg4NjM2MzYg Njc2OTg3MDMgNjc2OTg2ODkgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2 OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0 IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTU3ODkyNjQ0 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODQyOTkz MDY4IDY3Njk4NzAzIDY3Njk4Njg5IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZl bDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjk2Mjky Njg5NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA1 MDA5MTU0IDY3Njk4NzAzIDY3Njk4Njg5IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjps ZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDI6bGV2 ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwzDQoJe21zby1saXN0LWlkOjEz MTIxNzY0NjI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjEwMTk5MDQ2NTQgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMg Njc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDM6bGV2ZWwxDQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwzOmxldmVsNA0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwzOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpA bGlzdCBsMzpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTc3NDkzMzc5MjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTAxNTk3OTI2MiA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 Mzt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0 OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXTigJlzICh1bmZv cnR1bmF0ZWx5KSBmYWlybHkgc2ltaWxhciB0byB3aGF0IEnigJl2ZSBiZWVuIGtpY2tpbmcgYXJv dW5kIHdpdGggcmVnYXJkIHRvIGxvb3NlbmluZyBIUEFDSy4mbmJzcDsgWW91IHVsdGltYXRlbHkg aGF2ZSB0byBoYXZlIGJ1aWxkIHNvbWUgc3luY2hyb25pemF0aW9uIHBvaW50IHRvIGtub3cgd2hl biB5b3UgY2FuIGZyZWUgbWVtb3J5IHNhZmVseSwgYW5kIHRoYXQgcmVxdWlyZXMga25vd2luZyB3 aGVuIHlvdeKAmXJlDQogZG9uZSB1c2luZyB0aGUgb2xkIHN0YXRlLiZuYnNwOyBPciB5b3UgaGF2 ZSBzb21lIGxldmVsIG9mIG9wdGltaXNtIGFib3V0IGRpc2NhcmRpbmcgdGhpbmdzIGFuZCBoYXZl IGEgbm9uLWZhdGFsIGVycm9yIHRoYXQgZm9yY2VzIGEgcmUtc2VuZCBvbiBhIG5ldyBzdHJlYW0g d2l0aCB0aGUgbmV3IHN0YXRlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBzZWVtcyBsaWtl IHRoZXJlIGFyZSBhIGNvdXBsZSBwYXRocyB3ZSBjYW4gZ28gaGVyZTo8bzpwPjwvbzpwPjwvcD4N CjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMyBs ZXZlbDEgbGZvMiI+SFRUUC8yIHJ1bnMgb3ZlciBhIFFVSUMgc3RyZWFtLCBtb2R1bG8gY2hhbmdl czxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzIiPkV2ZXJ5IHJlcXVlc3QgZ2V0cyBh IHN0cmVhbTsgRnJhbWVzIHJlbGF0ZWQgdG8gcmVxdWVzdCBtYWludGFpbiBvcmRlcjxvOnA+PC9v OnA+PC9saT48L29sPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9 IjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2 ZWwyIGxmbzMiPlJlcXVpcmVzIGZyYW1pbmcgd2l0aGluIGVhY2ggc3RyZWFtPG86cD48L286cD48 L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMSBsZXZlbDIgbGZvMyI+UmVxdWlyZXMgY2hhbmdlcyB0byBIUEFDSzxvOnA+PC9v OnA+PC9saT48L3VsPg0KPC9vbD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIz IiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMyBsZXZlbDEgbGZvMiI+RXZlcnkgZnJhbWUgdHlwZSBnZXRzIGEg c3RyZWFtPG86cD48L286cD48L2xpPjwvb2w+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBz dGFydD0iMSIgdHlwZT0iMSI+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjtt c28tbGlzdDpsMCBsZXZlbDIgbGZvNCI+Q3Jvc3MtdHlwZSBkZXBlbmRlbmNpZXMgKFNFVFRJTkdT LCBIUEFDSykgYmVjb21lIHByb2JsZW1hdGljPG86cD48L286cD48L2xpPjwvdWw+DQo8L29sPg0K PG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjQiIHR5cGU9IjEiPg0KPGxpIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwzIGxl dmVsMSBsZm8yIj5FdmVyeSBmcmFtZSBnZXRzIGEgc3RyZWFtPG86cD48L286cD48L2xpPjwvb2w+ DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8dWwgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDIgbGZvNSI+TmV1 dGVycyBRVUlD4oCZcyBzdHJlYW0tYmFzZWQgZmxvdyBjb250cm9sLCBzaW5jZSB5b3UgY2FuIG5v IGxvbmdlciB0aHJvdHRsZSBpbmRpdmlkdWFsIHJlcXVlc3RzPG86cD48L286cD48L2xpPjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDps MiBsZXZlbDIgbGZvNSI+TWVhbnMgYXJiaXRyYXJpbHktbGFyZ2UgSFRUUC8yIGZyYW1lcyBjb3Vs ZCBiZSBwZXJtaXR0ZWQgd2l0aG91dCBicmVha2luZyBtdWx0aXBsZXhpbmc8bzpwPjwvbzpwPjwv bGk+PC91bD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwcmVzZW50IGRyYWZ0IGlzICMxLiZuYnNwOyBD b21iaW5pbmcgIzMgJmFtcDsgIzQgZ2l2ZXMgc29tZSBmbGV4aWJpbGl0eSwgYnV0IHRoZW4gcmVx dWlyZXMga25vd2luZyBvbiBhIHBlci1mcmFtZSB0eXBlIGJlaGF2aW9yIHdoaWNoIGJlaGF2aW9y IGlzIG5lZWRlZC4mbmJzcDsgSSBjdXJyZW50bHkgbGVhbiB0b3dhcmQgIzIsIGJ1dCBJ4oCZbSB3 aWxsaW5nIHRvIGJlIGNvbnZpbmNlZCBvdGhlcndpc2UuJm5ic3A7IFRha2luZyAjMiB0byB0aGUN CiBleHRyZW1lLCB5b3XigJlyZSBubyBsb25nZXIgY2FycnlpbmcgSFRUUC8yIG9yIGFueXRoaW5n IHRoYXQgcHJldGVuZHMgdG8gYmUgSFRUUC8yIOKAkyB5b3XigJlyZSBkZWZpbmluZyBhIGZyZXNo IHdheSB0byBjYXJyeSBIVFRQIHVzaW5nIGEgbmV3IHRyYW5zcG9ydCwgYW5kIG1vc3QgZXh0ZW5z aW9ucyBwcm9iYWJseSBuZWVkIHRvIGJlIHJlZGVmaW5lZCBpZiB0aGV5IHN0aWxsIGFwcGx5Ljxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJl aGFsZiBPZg0KPC9iPkNvcnkgQmVuZmllbGQ8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE5v dmVtYmVyIDEwLCAyMDE2IDI6MjcgQU08YnI+DQo8Yj5Ubzo8L2I+IFN0ZWZhbiBFaXNzaW5nICZs dDtzdGVmYW4uZWlzc2luZ0BncmVlbmJ5dGVzLmRlJmd0Ozxicj4NCjxiPkNjOjwvYj4gSmFuYSBJ eWVuZ2FyICZsdDtqcmlAZ29vZ2xlLmNvbSZndDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29v Z2xlLmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc7IE1hcnRpbiBUaG9tc29uICZsdDttYXJ0aW4udGhv bXNvbkBnbWFpbC5jb20mZ3Q7OyBQYXRyaWNrIE1jTWFudXMgJmx0O3BtY21hbnVzQG1vemlsbGEu Y29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1FVSUNdIGgyIG1hcHBpbmcgLSBleHRl bnNpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMCBO b3YgMjAxNiwgYXQgMTA6MjUsIFN0ZWZhbiBFaXNzaW5nICZsdDs8YSBocmVmPSJtYWlsdG86c3Rl ZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZSI+c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQt c2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3Bh Y2luZzowcHgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0K QW0gMTAuMTEuMjAxNiB1bSAxMTowOSBzY2hyaWViIENvcnkgQmVuZmllbGQgJmx0OzxhIGhyZWY9 Im1haWx0bzpjb3J5QGx1a2FzYS5jby51ayI+Y29yeUBsdWthc2EuY28udWs8L2E+Jmd0Ozo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIDEwIE5vdiAyMDE2LCBhdCAxMDowNCwgSWFu IFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSI+aWFuc3dldHRA Z29vZ2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCklmIGEgc2luZ2xlIGZyYW1lIHR5 cGUgYWx3YXlzIHJlcXVpcmVkIGluIG9yZGVyIGRlbGl2ZXJ5LCBidXQgeW91IGRpZG4ndCB3YW50 IEhPTCBibG9ja2luZyBvbiBldmVyeXRoaW5nLCB5b3UgY291bGQgdXNlIGEgc3RyZWFtIHBlciBm cmFtZSB0eXBlLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48YnI+DQo8YnI+DQpBcyBzdWNoLCBhbnkgZ2l2ZW4gSFRUUC8yIGZyYW1lIHdvdWxkIG5lZWQg dG8gc3BlY2lmeSBpZiBpbi1vcmRlciBkZWxpdmVyeSBpcyBuZWNlc3NhcnksIGFuZCBpZiBzbywg dGhleSBzaG91bGQgYmUgc2VudCBvbiBhIHNpbmdsZSBzdHJlYW0uICZuYnNwO090aGVyd2lzZSwg YSBzdHJlYW0gcGVyIGZyYW1lIGNhbiBiZSB1c2VkLiAmbmJzcDtUaGF0IHNlZW1zIGZhaXJseSBn ZW5lcmFsaXphYmxlIHRvIG1lPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkkgZG9u4oCZdCB0 aGluayBpdCByZXNvbHZlcyBTRVRUSU5HUyB0aG91Z2guIEgy4oCZcyBTRVRUSU5HUyBmcmFtZSBp bmNsdWRlcyBzb21lIGNvbm5lY3Rpb24td2lkZSB2YWx1ZXMgdGhhdCBhZmZlY3QgYWxsIG90aGVy IGZyYW1lcyAoZS5nLiBTRVRUSU5HU19NQVhfRlJBTUVfU0laRSksIHNvIHdpdGggU0VUVElOR1Mg YXMgd3JpdHRlbiBpbiA3NTQwIGl0IG5lZWRzIHRvIGJlIHBvc3NpYmxlIHRvIHNvcnQgYWxsIGZy YW1lcyBpbnRvIOKAnGJlZm9yZSBBQ0vigJ0NCiBhbmQg4oCcYWZ0ZXIgQUNL4oCdIGlmIHRoYXQg c2V0dGluZyBpcyBjaGFuZ2VkOiBvdGhlcndpc2UgaXTigJlzIHZlcnkgZGlmZmljdWx0IHRvIHBv bGljZSB0aGUgZnJhbWUgc2l6ZS48YnI+DQo8YnI+DQpBIG1vbm90b25pYyBjb3VudGVyIG9uIFNF VFRJTkdTIGNvdWxkIHBlcmhhcHMgYmUgdXNlZCB0byB0aGlzIGVmZmVjdCwgYnV0IGl04oCZZCBy ZXF1aXJlIHRoYXQgYWxsIGZyYW1lcyBjYXJyeSB0aGF0IGNvdW50ZXIgb24gdGhlbSBhbmQgcHJv YmFibHkgdGhhdCBmcmFtZXMgZnJvbSBvbGRlciBzZXR0aW5ncyByZWdpbWVzIGJlIGRpc2NhcmRl ZCBhZnRlciBhIGNlcnRhaW4gcGVyaW9kIG9mIHRpbWUuIEnigJltIG5vdCBlbnRpcmVseSBzdXJl IHRoYXQgdGhhdOKAmXMNCiBhIGdvb2QgcGxhbiwgYnV0IGl04oCZcyB0aGUgZmlyc3Qgb25lIHRo YXQgbGVhcHMgb3V0IGF0IG1lLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NClVyZ2guIEJ1dCBp ZiB0aGVyZSBpcyBubyBub3Rpb24gb2YgJnF1b3Q7YmVmb3JlJnF1b3Q7IGFuZCAmcXVvdDthZnRl ciZxdW90OyBiZXR3ZWVuIGZyYW1lcyBvbiBkaWZmZXJlbnQgcXVpYyBzdHJlYW1zLCBhcyBJIHVu ZGVyc3RhbmQgaXQsIHRoZSBldmVuIHRoaXMgY291bnRlciB3b3VsZCBub3QgaGVscC4gQXMgaXQg YWZmZWN0cyBhbGwgZnJhbWVzPyBvcj88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjb3VudGVyIGhl bHBzIG9ubHkgYmVjYXVzZSB5b3UgaWRlbnRpZnkgd2hhdCBTRVRUSU5HUyByZWdpbWUgYXBwbGll cyB0byBhbnkgZ2l2ZW4gZnJhbWUuIFRoaXMgY291bGQgYWxzbyBwcm9iYWJseSBiZSBkb25lIHVz aW5nIHNvbWUgb2YgUVVJQ3MgcGFja2V0LXRyYWNraW5nIGFuZCBsb3NzLXJlY292ZXJ5IG1lY2hh bmlzbXMgKHdoZW4gdGhlcmUgYXJlIG5vIG1vcmUgZnJhbWVzIHVuZGVyIFNFVFRJTkdTDQogcmVn aW1lIDMgdW5kZWxpdmVyZWQgd2UgY2FuIG5vdyBmb3JnZXQgYWJvdXQgU0VUVElOR1MgcmVnaW1l IDMpLCBidXQgSSBhZ3JlZTogdGhpcyBpcyBwcmV0dHkgZ3Jvc3MgYW5kIEkgZG9u4oCZdCB0aGlu ayBpdOKAmXMgYSBnb29kIGlkZWEuIEp1c3QgYSBzdHJhd21hbiB0byBraWNrIGFyb3VuZC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BN6PR03MB27084EA442F6464A6A85C51B87B80BN6PR03MB2708namp_-- From nobody Thu Nov 10 15:00:09 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE51812984A for ; Thu, 10 Nov 2016 15:00:07 -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 lwZ0EH5DD_np for ; Thu, 10 Nov 2016 15:00:05 -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 29AFE129431 for ; Thu, 10 Nov 2016 15:00:05 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n204so99428qke.2 for ; Thu, 10 Nov 2016 15:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NWxloeAjmM9HNTblU5DMHz1m23vJ1tAFQ0sq+hUpSug=; b=JFtSVkGHj3zB4XvDnnhNKSaLfsT11MrLqA4XCwieVRqq6zOb8+WXG5yvTDis7wfks1 Peyo2ThP7OC9SOf6yr87wbHDUPQf1nRBbVMO5E9pN297CC+ekQ9fOf2D0N856LX9/t9F 129d7ywm18gRwco5/cCcGZ5RwvMPiehIVRd9tv3zOY7P0U1XYgj3CHhu0ziEZmKxOh7Y 4rPvJqOeucrQkMxtAwraHD2GXly++9SfPpvihrc6jzh/pBGkNNxonclPuCrEYocqvJst rXKCpZ3Gag5beGCmVFKi6m2YcACTsd9r2AGY959kaTbScFcEA9sVAohI0gMfJ0bRhUHo /LTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=NWxloeAjmM9HNTblU5DMHz1m23vJ1tAFQ0sq+hUpSug=; b=WjaA1pBy2E48iUnTcasFeufFxRp+Ontnr+VaZGMGJGVxyofVBkuiK/U2LTsYBHmY8X Sajxp/peTgD3UvvXmZ8Bf52h8cTO/GRgj16g9z9lNtd+QzfYeDPMjFv/BbNGzTXuv3Vj asRKDeJUFV7r3ZM764iVtt+Kwn82sOdyJMSYp3SY/h2dHcV4tPIcZLBqAELv3xsAqDkY ujq7eBj4UymvMX1RlPifhLK5I9Eij3N/X3eHXGd1K4LYRS/Ix6q9JTtPz12aj29lFi6I E3tDb+YjkLcUQjbwpDrNGXP5NKVncubazEuLEUB5yEfVbe68zk5ZHabDhZsr5GqdBM9I RYXw== X-Gm-Message-State: ABUngveNeCEhc2K97IVXYL0i3EplEEJ+uyHpHlfiG/FDxmUipCB4R701dC5/No+IZwxV8kN4Tww6z4VVXUSbOw== X-Received: by 10.55.74.1 with SMTP id x1mr158682qka.316.1478818804321; Thu, 10 Nov 2016 15:00:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Thu, 10 Nov 2016 15:00:03 -0800 (PST) In-Reply-To: References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> From: Martin Thomson Date: Fri, 11 Nov 2016 10:00:03 +1100 Message-ID: To: Mike Bishop Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Stefan Eissing , Ian Swett , Cory Benfield , Patrick McManus , Jana Iyengar , "quic@ietf.org" Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 10 Nov 2016 23:00:07 -0000 On 11 November 2016 at 06:28, Mike Bishop wr= ote: > 2. Every request gets a stream; Frames related to request maintain order > > Requires framing within each stream > Requires changes to HPACK ... > I currently lean toward #2, but I=E2=80=99m willing to be convinced other= wise. Taking > #2 to the extreme, you=E2=80=99re no longer carrying HTTP/2 or anything t= hat > pretends to be HTTP/2 =E2=80=93 you=E2=80=99re defining a fresh way to ca= rry HTTP using a > new transport, and most extensions probably need to be redefined if they > still apply. I also would prefer having everything for a single request on a stream. I think that HPACK (and SETTINGS) changes are the small piece here in terms of absolute magnitude of changes. That could only need small adjustments to get right. A few extra pieces, such as a SETTINGS_ACK on every active stream might let you use SETTINGS reliably, though it's probably a bit unwieldy (and you would need some special accounting for both past and future streams to make the feature complete). From nobody Fri Nov 11 01:49:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EDE129515 for ; Fri, 11 Nov 2016 01:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=greenbytes.de header.b=HkMyHdPQ; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=DhFvNxmK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ep-EJPFZ66RZ for ; Fri, 11 Nov 2016 01:49:37 -0800 (PST) Received: from mail.greenbytes.de (mail.greenbytes.de [5.10.171.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0523128B44 for ; Fri, 11 Nov 2016 01:49:36 -0800 (PST) Received: by mail.greenbytes.de (Postfix, from userid 117) id A099E15A0EEA; Fri, 11 Nov 2016 10:49:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1478857774; bh=Q+zJxET0XCQ836sqo1ChyjZXvg7/XdK7r3lORaB2etg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=HkMyHdPQnlGh1207DSpehNWVLSWU4I27vMXMBT6Ffhi/GeGb56UyvH9oN5PprFdv6 5891UYzrF9tnwrCqZTDa+rw38t28rI/yWdlJmYOjQfLVyfQXvuJ83/An02KQ2QD3Ql 4itpkOz/hur/AMSS7cHk9n3/1yW5OUlPSAC0tpg0= Received: from [192.168.1.175] (unknown [192.168.1.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 8594715A059A; Fri, 11 Nov 2016 10:49:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1478857773; bh=Q+zJxET0XCQ836sqo1ChyjZXvg7/XdK7r3lORaB2etg=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=DhFvNxmKwBMY75p3HokcbyUuPS7m6Dj18sLtLYzZmH/JntRDCxiv7+0HICMm4qYg9 CDMC0/jSR7JEVpltdAilPkFeGN15dEXtYo/7i3nuqlL7FckyVnFM/cnPv5vNaalenh MXN6Q0TapRsxPOaj6RiHgQL+64s7ORHUTBaZ1JfE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Stefan Eissing In-Reply-To: Date: Fri, 11 Nov 2016 10:49:33 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <927B27C6-473C-483D-A13F-DD7FDEC05723@greenbytes.de> References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> To: Mike Bishop X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Ian Swett , Cory Benfield , Patrick McManus , Jana Iyengar , "quic@ietf.org" , Martin Thomson Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 11 Nov 2016 09:49:39 -0000 > Am 10.11.2016 um 20:28 schrieb Mike Bishop = : > [...] > It seems like there are a couple paths we can go here: > =E2=80=A2 HTTP/2 runs over a QUIC stream, modulo changes > =E2=80=A2 Every request gets a stream; Frames related to request = maintain order > =E2=80=A2 Requires framing within each stream > =E2=80=A2 Requires changes to HPACK > =E2=80=A2 Every frame type gets a stream > =E2=80=A2 Cross-type dependencies (SETTINGS, HPACK) = become problematic > =E2=80=A2 Every frame gets a stream > =E2=80=A2 Neuters QUIC=E2=80=99s stream-based flow = control, since you can no longer throttle individual requests > =E2=80=A2 Means arbitrarily-large HTTP/2 frames could be = permitted without breaking multiplexing > =20 > The present draft is #1. Combining #3 & #4 gives some flexibility, = but then requires knowing on a per-frame type behavior which behavior is = needed. I currently lean toward #2, but I=E2=80=99m willing to be = convinced otherwise. Taking #2 to the extreme, you=E2=80=99re no longer = carrying HTTP/2 or anything that pretends to be HTTP/2 =E2=80=93 = you=E2=80=99re defining a fresh way to carry HTTP using a new transport, = and most extensions probably need to be redefined if they still apply. I think #2 is the only way forward on this list that will end up with a = HTTP transport that has comprehensible properties for the caller. (Well, = apart from #1 maybe, but who wants that?) For completeness sake, there is also #5: - Every request is done in HTTP/1.1 format on a QUIC stream - A special QUIC stream is used for signalling only > =20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Cory Benfield > Sent: Thursday, November 10, 2016 2:27 AM > To: Stefan Eissing > Cc: Jana Iyengar ; Ian Swett ; = quic@ietf.org; Martin Thomson ; Patrick = McManus > Subject: Re: [QUIC] h2 mapping - extensions > =20 > =20 > On 10 Nov 2016, at 10:25, Stefan Eissing = wrote: > =20 >=20 > Am 10.11.2016 um 11:09 schrieb Cory Benfield : >=20 >=20 >=20 > On 10 Nov 2016, at 10:04, Ian Swett wrote: >=20 > If a single frame type always required in order delivery, but you = didn't want HOL blocking on everything, you could use a stream per frame = type.=20 >=20 > As such, any given HTTP/2 frame would need to specify if in-order = delivery is necessary, and if so, they should be sent on a single = stream. Otherwise, a stream per frame can be used. That seems fairly = generalizable to me? >=20 > I don=E2=80=99t think it resolves SETTINGS though. H2=E2=80=99s = SETTINGS frame includes some connection-wide values that affect all = other frames (e.g. SETTINGS_MAX_FRAME_SIZE), so with SETTINGS as written = in 7540 it needs to be possible to sort all frames into =E2=80=9Cbefore = ACK=E2=80=9D and =E2=80=9Cafter ACK=E2=80=9D if that setting is changed: = otherwise it=E2=80=99s very difficult to police the frame size. >=20 > A monotonic counter on SETTINGS could perhaps be used to this effect, = but it=E2=80=99d require that all frames carry that counter on them and = probably that frames from older settings regimes be discarded after a = certain period of time. I=E2=80=99m not entirely sure that that=E2=80=99s = a good plan, but it=E2=80=99s the first one that leaps out at me. >=20 > Urgh. But if there is no notion of "before" and "after" between frames = on different quic streams, as I understand it, the even this counter = would not help. As it affects all frames? or? > =20 > The counter helps only because you identify what SETTINGS regime = applies to any given frame. This could also probably be done using some = of QUICs packet-tracking and loss-recovery mechanisms (when there are no = more frames under SETTINGS regime 3 undelivered we can now forget about = SETTINGS regime 3), but I agree: this is pretty gross and I don=E2=80=99t = think it=E2=80=99s a good idea. Just a strawman to kick around. From nobody Fri Nov 11 10:10:59 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900B7129C0E for ; Fri, 11 Nov 2016 10:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ux9DeuoKjrx for ; Fri, 11 Nov 2016 10:10:50 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0117.outbound.protection.outlook.com [104.47.42.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A450129C0F for ; Fri, 11 Nov 2016 10:10:50 -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=dtkRacf5xpkMLnTXqFtqIXan0/XWHSg9QZ+a9C2pQnU=; b=Cg8cfQNp9w9VwqCm2uyu8eYuUmKQ832V5QOW07mZ+esEq/mjB8ggWkKXh0xiIG7Fb5Ewsv4fKA4W2yYFn6FnV5t/WoAiaygwuHLlIegNBRjJK3n2c+hZ54rGXuFO5nn0a1iHxqBgjczYMVUhnC6p4fDCPW6goBmrWW5kTcG1iTo= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.6; Fri, 11 Nov 2016 18:10:46 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0707.006; Fri, 11 Nov 2016 18:10:46 +0000 From: Mike Bishop To: Stefan Eissing Thread-Topic: [QUIC] h2 mapping - extensions Thread-Index: AQHSNhrWVkwvFIuWr0eoGbjCghGjY6DN7XKAgAACUICAADTogIAC3/cAgABN1QCAAJg9gIAAGG2AgAAEPACAAAGNgIAABFgAgAAAdQCAAI4iYIAA+cGAgACK3+A= Date: Fri, 11 Nov 2016 18:10:46 +0000 Message-ID: References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> <927B27C6-473C-483D-A13F-DD7FDEC05723@greenbytes.de> In-Reply-To: <927B27C6-473C-483D-A13F-DD7FDEC05723@greenbytes.de> 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=Michael.Bishop@microsoft.com; x-originating-ip: [198.134.93.254] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:H2kG25mrjUBfS75JnvGqdTTKRThRBpu0iMlmCn6pujLZtRHhdQiEXvEX5C5Ui/253aGCIGcYDTAq7/olaG68jxB1ZeeYZETIw7qL31uiNjNyjbkdHpUhAcWWerP1oVIAxB1fWxu1mclClyJ7F2yH7aOjns4+q6e6joiEtQFe5KXXkfguUBrdfTRb/pGUWwCEHGS/cVWleIDRk08Gs/TEZjHEjZroceHDWzXnf2hyEA1k55BifffyUnmHZPN1DQpX5niyKSY+eWXk1qBK8mjov1YpPbnKh08/OI6c+F5bHiUwUd/1Oa1knOLgjw4AU3aAqZVPdDxhoRfPKmrfk4qOvoWlW1qxRm85zWNslOSdOQQZuxM3GsRT7jdvA35EUc11 x-ms-office365-filtering-correlation-id: a29e484a-fd17-464d-2550-08d40a5e0f34 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2708; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6040176)(6060229)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6061226); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 012349AD1C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(189002)(24454002)(199003)(13464003)(7846002)(99286002)(110136003)(586003)(305945005)(50986999)(5660300001)(76176999)(229853002)(9686002)(6916009)(68736007)(81156014)(97736004)(4326007)(7696004)(8936002)(3846002)(87936001)(74316002)(6116002)(2906002)(33656002)(102836003)(101416001)(2950100002)(77096005)(81166006)(10090500001)(66066001)(10290500002)(7736002)(189998001)(8676002)(92566002)(54356999)(2900100001)(5005710100001)(3280700002)(93886004)(3660700001)(8990500004)(86362001)(105586002)(106116001)(76576001)(86612001)(106356001)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.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) 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-originalarrivaltime: 11 Nov 2016 18:10:46.1829 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Cc: Ian Swett , Cory Benfield , Patrick McManus , Jana Iyengar , "quic@ietf.org" , Martin Thomson Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 11 Nov 2016 18:10:57 -0000 WWVzLCAjNSBpcyBiYXNpY2FsbHkgZHJhZnQtbmF0YXJhamFuLWh0dHAtb3Zlci1zY3RwIHdpdGgg YSBiZXR0ZXIgbXVsdGktc3RyZWFtLWJhc2VkIHRyYW5zcG9ydC4gIDotKSAgQW5kIHdoaWxlIGl0 J3MgYSB2YWxpZCBvcHRpb24sIHRoZXJlJ3MgYmVlbiBlbm91Z2ggY2xhaW1lZCBiZW5lZml0IGZy b20gaGVhZGVyIGNvbXByZXNzaW9uIGFuZCBhIGJpbmFyeSBmb3JtYXQgdGhhdCBpdCdzIGFsc28g bm90IG15IHByZWZlcmVuY2UuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBT dGVmYW4gRWlzc2luZyBbbWFpbHRvOnN0ZWZhbi5laXNzaW5nQGdyZWVuYnl0ZXMuZGVdIA0KU2Vu dDogRnJpZGF5LCBOb3ZlbWJlciAxMSwgMjAxNiAxOjUwIEFNDQpUbzogTWlrZSBCaXNob3AgPE1p Y2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpDYzogQ29yeSBCZW5maWVsZCA8Y29yeUBsdWth c2EuY28udWs+OyBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPjsgSWFuIFN3ZXR0IDxpYW5z d2V0dEBnb29nbGUuY29tPjsgcXVpY0BpZXRmLm9yZzsgTWFydGluIFRob21zb24gPG1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT47IFBhdHJpY2sgTWNNYW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+ DQpTdWJqZWN0OiBSZTogW1FVSUNdIGgyIG1hcHBpbmcgLSBleHRlbnNpb25zDQoNCg0KPiBBbSAx MC4xMS4yMDE2IHVtIDIwOjI4IHNjaHJpZWIgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1p Y3Jvc29mdC5jb20+Og0KPiBbLi4uXQ0KPiBJdCBzZWVtcyBsaWtlIHRoZXJlIGFyZSBhIGNvdXBs ZSBwYXRocyB3ZSBjYW4gZ28gaGVyZToNCj4gCeKAoiBIVFRQLzIgcnVucyBvdmVyIGEgUVVJQyBz dHJlYW0sIG1vZHVsbyBjaGFuZ2VzDQo+IAnigKIgRXZlcnkgcmVxdWVzdCBnZXRzIGEgc3RyZWFt OyBGcmFtZXMgcmVsYXRlZCB0byByZXF1ZXN0IG1haW50YWluIG9yZGVyDQo+IAkJ4oCiIFJlcXVp cmVzIGZyYW1pbmcgd2l0aGluIGVhY2ggc3RyZWFtDQo+IAkJ4oCiIFJlcXVpcmVzIGNoYW5nZXMg dG8gSFBBQ0sNCj4gCeKAoiBFdmVyeSBmcmFtZSB0eXBlIGdldHMgYSBzdHJlYW0NCj4gCQnigKIg Q3Jvc3MtdHlwZSBkZXBlbmRlbmNpZXMgKFNFVFRJTkdTLCBIUEFDSykgYmVjb21lIHByb2JsZW1h dGljDQo+IAnigKIgRXZlcnkgZnJhbWUgZ2V0cyBhIHN0cmVhbQ0KPiAJCeKAoiBOZXV0ZXJzIFFV SUPigJlzIHN0cmVhbS1iYXNlZCBmbG93IGNvbnRyb2wsIHNpbmNlIHlvdSBjYW4gbm8gbG9uZ2Vy IHRocm90dGxlIGluZGl2aWR1YWwgcmVxdWVzdHMNCj4gCQnigKIgTWVhbnMgYXJiaXRyYXJpbHkt bGFyZ2UgSFRUUC8yIGZyYW1lcyBjb3VsZCBiZSBwZXJtaXR0ZWQgd2l0aG91dCBicmVha2luZyBt dWx0aXBsZXhpbmcNCj4gIA0KPiBUaGUgcHJlc2VudCBkcmFmdCBpcyAjMS4gIENvbWJpbmluZyAj MyAmICM0IGdpdmVzIHNvbWUgZmxleGliaWxpdHksIGJ1dCB0aGVuIHJlcXVpcmVzIGtub3dpbmcg b24gYSBwZXItZnJhbWUgdHlwZSBiZWhhdmlvciB3aGljaCBiZWhhdmlvciBpcyBuZWVkZWQuICBJ IGN1cnJlbnRseSBsZWFuIHRvd2FyZCAjMiwgYnV0IEnigJltIHdpbGxpbmcgdG8gYmUgY29udmlu Y2VkIG90aGVyd2lzZS4gIFRha2luZyAjMiB0byB0aGUgZXh0cmVtZSwgeW914oCZcmUgbm8gbG9u Z2VyIGNhcnJ5aW5nIEhUVFAvMiBvciBhbnl0aGluZyB0aGF0IHByZXRlbmRzIHRvIGJlIEhUVFAv MiDigJMgeW914oCZcmUgZGVmaW5pbmcgYSBmcmVzaCB3YXkgdG8gY2FycnkgSFRUUCB1c2luZyBh IG5ldyB0cmFuc3BvcnQsIGFuZCBtb3N0IGV4dGVuc2lvbnMgcHJvYmFibHkgbmVlZCB0byBiZSBy ZWRlZmluZWQgaWYgdGhleSBzdGlsbCBhcHBseS4NCg0KSSB0aGluayAjMiBpcyB0aGUgb25seSB3 YXkgZm9yd2FyZCBvbiB0aGlzIGxpc3QgdGhhdCB3aWxsIGVuZCB1cCB3aXRoIGEgSFRUUCB0cmFu c3BvcnQgdGhhdCBoYXMgY29tcHJlaGVuc2libGUgcHJvcGVydGllcyBmb3IgdGhlIGNhbGxlci4g KFdlbGwsIGFwYXJ0IGZyb20gIzEgbWF5YmUsIGJ1dCB3aG8gd2FudHMgdGhhdD8pDQoNCkZvciBj b21wbGV0ZW5lc3Mgc2FrZSwgdGhlcmUgaXMgYWxzbyAjNToNCi0gRXZlcnkgcmVxdWVzdCBpcyBk b25lIGluIEhUVFAvMS4xIGZvcm1hdCBvbiBhIFFVSUMgc3RyZWFtDQotIEEgc3BlY2lhbCBRVUlD IHN0cmVhbSBpcyB1c2VkIGZvciBzaWduYWxsaW5nIG9ubHkNCg0KPiAgDQo+IEZyb206IFFVSUMg W21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDb3J5IEJlbmZpZWxk DQo+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAxMCwgMjAxNiAyOjI3IEFNDQo+IFRvOiBTdGVm YW4gRWlzc2luZyA8c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT4NCj4gQ2M6IEphbmEgSXll bmdhciA8anJpQGdvb2dsZS5jb20+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBx dWljQGlldGYub3JnOyBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPjsg UGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbT4NCj4gU3ViamVjdDogUmU6IFtR VUlDXSBoMiBtYXBwaW5nIC0gZXh0ZW5zaW9ucw0KPiAgDQo+ICANCj4gT24gMTAgTm92IDIwMTYs IGF0IDEwOjI1LCBTdGVmYW4gRWlzc2luZyA8c3RlZmFuLmVpc3NpbmdAZ3JlZW5ieXRlcy5kZT4g d3JvdGU6DQo+ICANCj4gDQo+IEFtIDEwLjExLjIwMTYgdW0gMTE6MDkgc2NocmllYiBDb3J5IEJl bmZpZWxkIDxjb3J5QGx1a2FzYS5jby51az46DQo+IA0KPiANCj4gDQo+IE9uIDEwIE5vdiAyMDE2 LCBhdCAxMDowNCwgSWFuIFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPiB3cm90ZToNCj4gDQo+ IElmIGEgc2luZ2xlIGZyYW1lIHR5cGUgYWx3YXlzIHJlcXVpcmVkIGluIG9yZGVyIGRlbGl2ZXJ5 LCBidXQgeW91IGRpZG4ndCB3YW50IEhPTCBibG9ja2luZyBvbiBldmVyeXRoaW5nLCB5b3UgY291 bGQgdXNlIGEgc3RyZWFtIHBlciBmcmFtZSB0eXBlLiANCj4gDQo+IEFzIHN1Y2gsIGFueSBnaXZl biBIVFRQLzIgZnJhbWUgd291bGQgbmVlZCB0byBzcGVjaWZ5IGlmIGluLW9yZGVyIGRlbGl2ZXJ5 IGlzIG5lY2Vzc2FyeSwgYW5kIGlmIHNvLCB0aGV5IHNob3VsZCBiZSBzZW50IG9uIGEgc2luZ2xl IHN0cmVhbS4gIE90aGVyd2lzZSwgYSBzdHJlYW0gcGVyIGZyYW1lIGNhbiBiZSB1c2VkLiAgVGhh dCBzZWVtcyBmYWlybHkgZ2VuZXJhbGl6YWJsZSB0byBtZT8NCj4gDQo+IEkgZG9u4oCZdCB0aGlu ayBpdCByZXNvbHZlcyBTRVRUSU5HUyB0aG91Z2guIEgy4oCZcyBTRVRUSU5HUyBmcmFtZSBpbmNs dWRlcyBzb21lIGNvbm5lY3Rpb24td2lkZSB2YWx1ZXMgdGhhdCBhZmZlY3QgYWxsIG90aGVyIGZy YW1lcyAoZS5nLiBTRVRUSU5HU19NQVhfRlJBTUVfU0laRSksIHNvIHdpdGggU0VUVElOR1MgYXMg d3JpdHRlbiBpbiA3NTQwIGl0IG5lZWRzIHRvIGJlIHBvc3NpYmxlIHRvIHNvcnQgYWxsIGZyYW1l cyBpbnRvIOKAnGJlZm9yZSBBQ0vigJ0gYW5kIOKAnGFmdGVyIEFDS+KAnSBpZiB0aGF0IHNldHRp bmcgaXMgY2hhbmdlZDogb3RoZXJ3aXNlIGl04oCZcyB2ZXJ5IGRpZmZpY3VsdCB0byBwb2xpY2Ug dGhlIGZyYW1lIHNpemUuDQo+IA0KPiBBIG1vbm90b25pYyBjb3VudGVyIG9uIFNFVFRJTkdTIGNv dWxkIHBlcmhhcHMgYmUgdXNlZCB0byB0aGlzIGVmZmVjdCwgYnV0IGl04oCZZCByZXF1aXJlIHRo YXQgYWxsIGZyYW1lcyBjYXJyeSB0aGF0IGNvdW50ZXIgb24gdGhlbSBhbmQgcHJvYmFibHkgdGhh dCBmcmFtZXMgZnJvbSBvbGRlciBzZXR0aW5ncyByZWdpbWVzIGJlIGRpc2NhcmRlZCBhZnRlciBh IGNlcnRhaW4gcGVyaW9kIG9mIHRpbWUuIEnigJltIG5vdCBlbnRpcmVseSBzdXJlIHRoYXQgdGhh dOKAmXMgYSBnb29kIHBsYW4sIGJ1dCBpdOKAmXMgdGhlIGZpcnN0IG9uZSB0aGF0IGxlYXBzIG91 dCBhdCBtZS4NCj4gDQo+IFVyZ2guIEJ1dCBpZiB0aGVyZSBpcyBubyBub3Rpb24gb2YgImJlZm9y ZSIgYW5kICJhZnRlciIgYmV0d2VlbiBmcmFtZXMgb24gZGlmZmVyZW50IHF1aWMgc3RyZWFtcywg YXMgSSB1bmRlcnN0YW5kIGl0LCB0aGUgZXZlbiB0aGlzIGNvdW50ZXIgd291bGQgbm90IGhlbHAu IEFzIGl0IGFmZmVjdHMgYWxsIGZyYW1lcz8gb3I/DQo+ICANCj4gVGhlIGNvdW50ZXIgaGVscHMg b25seSBiZWNhdXNlIHlvdSBpZGVudGlmeSB3aGF0IFNFVFRJTkdTIHJlZ2ltZSBhcHBsaWVzIHRv IGFueSBnaXZlbiBmcmFtZS4gVGhpcyBjb3VsZCBhbHNvIHByb2JhYmx5IGJlIGRvbmUgdXNpbmcg c29tZSBvZiBRVUlDcyBwYWNrZXQtdHJhY2tpbmcgYW5kIGxvc3MtcmVjb3ZlcnkgbWVjaGFuaXNt cyAod2hlbiB0aGVyZSBhcmUgbm8gbW9yZSBmcmFtZXMgdW5kZXIgU0VUVElOR1MgcmVnaW1lIDMg dW5kZWxpdmVyZWQgd2UgY2FuIG5vdyBmb3JnZXQgYWJvdXQgU0VUVElOR1MgcmVnaW1lIDMpLCBi dXQgSSBhZ3JlZTogdGhpcyBpcyBwcmV0dHkgZ3Jvc3MgYW5kIEkgZG9u4oCZdCB0aGluayBpdOKA mXMgYSBnb29kIGlkZWEuIEp1c3QgYSBzdHJhd21hbiB0byBraWNrIGFyb3VuZC4NCg0K From nobody Fri Nov 11 21:41:03 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4B851298AE for ; Fri, 11 Nov 2016 21:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4oheIBeOVb5 for ; Fri, 11 Nov 2016 21:41:01 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c: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 E73F01298C0 for ; Fri, 11 Nov 2016 21:41:00 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id a197so12647462wmd.0 for ; Fri, 11 Nov 2016 21:41:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nWZDIBSDHtcUHrK6YUeJmWGJfs1mEZAT6dFwuAyDqGI=; b=SDVqbsem0rlCzlm8ga4BQXfNr1WQkwXErHMF6WlrmdWkbnUKUUexNYkz/zTP5nPQQn 8V0xKHja1FrhucOvW0XkiSgY4eV4EepqrX8l5f3fBiyJT9wCJG3xLiW+Ly3ZypMCauUv UgPNzBIrGoNoLYaZ+PbQUh5umYjc6oMiAsK3+NFl5vHsHmrGW6XmEV4mlZS/adZIt0K4 oCsJvvn/Wuec24odQF8okljXiCJ6RiYpJefQoqi7MHkFuasZpyCj3rxX3MYPogTsIrhb eEYO7DyM4i5W/h1QdugkgLgzQRSpExUP2at4Y1elq97ZiLSpB3uNr6nHmKXFuevMFTGp Sydw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nWZDIBSDHtcUHrK6YUeJmWGJfs1mEZAT6dFwuAyDqGI=; b=iyiuJYZJTo8p2Y76nI+oXnLfPFoxGUoImQM8XjBZhv7P9L+LIkq5lkAuiS7gtTL8hG s2ko2KFbjr/0w66Zn6wRrb9OqpsEXtsCyXtgY6ij12wNgkVDUqttgVHLPiTqOLFvHJyK b1B0R9zxF2evtzVjVfIp26l2n1oTtgaAK3c1INO4iHMzJ+gacOhLqW8xcpkSUniScR1S E5KJHKb6VxWSWpG52TRGfEx0pmAimwyWTkQLvxcjJ3rhfDjHBmIXCiWiri/rKRm2VtSD NsHTcfh4X5lHhCNTRuMnNDMicsMbUj5uT1bWYY84X3LsMGRvW23ZzaAyDyxaBINmBLMn 1/rg== X-Gm-Message-State: ABUngvfdTpt1s2i9kL2DeQQTbwsrpiKMCHq2SUUhugOShbVaNcJ+Sn6b0CIjiS1cdsOf6ifHJxMLQ1jJOwxb1YOM X-Received: by 10.28.50.66 with SMTP id y63mr1134232wmy.44.1478929259300; Fri, 11 Nov 2016 21:40:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.152.70 with HTTP; Fri, 11 Nov 2016 21:40:58 -0800 (PST) In-Reply-To: <927B27C6-473C-483D-A13F-DD7FDEC05723@greenbytes.de> References: <027EDB63-EE7D-4318-B6B7-F2D7F3566FB9@lukasa.co.uk> <059ACE09-87F2-4705-BDA7-7A2EF712AE25@lukasa.co.uk> <927B27C6-473C-483D-A13F-DD7FDEC05723@greenbytes.de> From: Ryan Hamilton Date: Fri, 11 Nov 2016 21:40:58 -0800 Message-ID: To: Stefan Eissing Content-Type: multipart/alternative; boundary=001a1140d754266d4b0541140da9 Archived-At: Cc: Mike Bishop , Ian Swett , Cory Benfield , Patrick McManus , Jana Iyengar , "quic@ietf.org" , Martin Thomson Subject: Re: [QUIC] h2 mapping - extensions X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 12 Nov 2016 05:41:02 -0000 --001a1140d754266d4b0541140da9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Nov 11, 2016 at 1:49 AM, Stefan Eissing < stefan.eissing@greenbytes.de> wrote: > > Am 10.11.2016 um 20:28 schrieb Mike Bishop >: > > [...] > > It seems like there are a couple paths we can go here: > > =E2=80=A2 HTTP/2 runs over a QUIC stream, modulo changes > > =E2=80=A2 Every request gets a stream; Frames related to request = maintain > order > > =E2=80=A2 Requires framing within each stream > > =E2=80=A2 Requires changes to HPACK > > =E2=80=A2 Every frame type gets a stream > > =E2=80=A2 Cross-type dependencies (SETTINGS, HPACK) becom= e > problematic > > =E2=80=A2 Every frame gets a stream > > =E2=80=A2 Neuters QUIC=E2=80=99s stream-based flow contro= l, since you can > no longer throttle individual requests > > =E2=80=A2 Means arbitrarily-large HTTP/2 frames could be = permitted > without breaking multiplexing > > > > The present draft is #1. Combining #3 & #4 gives some flexibility, but > then requires knowing on a per-frame type behavior which behavior is > needed. I currently lean toward #2, but I=E2=80=99m willing to be convin= ced > otherwise. Taking #2 to the extreme, you=E2=80=99re no longer carrying H= TTP/2 or > anything that pretends to be HTTP/2 =E2=80=93 you=E2=80=99re defining a f= resh way to carry > HTTP using a new transport, and most extensions probably need to be > redefined if they still apply. > > I think #2 is the only way forward on this list that will end up with a > HTTP transport that has comprehensible properties for the caller. (Well, > apart from #1 maybe, but who wants that?) > > For completeness sake, there is also #5: > - Every request is done in HTTP/1.1 format on a QUIC stream > - A special QUIC stream is used for signalling only > =E2=80=8BThat's basically what QUIC does today, right?=E2=80=8B --001a1140d754266d4b0541140da9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 11, 2016 at 1:49 AM, Stefan Eissing <stefan.eissing@greenbytes.de> wrote:
> A= m 10.11.2016 um 20:28 schrieb Mike Bishop <Michael.Bishop@microsoft.com>:
> [...]
> It seems like there are a couple paths we can go here:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 HTTP/2 runs over a QUIC stream, mo= dulo changes
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Every request gets a stream; Frame= s related to request maintain order
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=E2=80=A2 Requires framing within each stream
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Requir= es changes to HPACK
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Every frame type gets a str= eam
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Cross-= type dependencies (SETTINGS, HPACK) become problematic
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Every frame gets a stream
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Neuter= s QUIC=E2=80=99s stream-based flow control, since you can no longer throttl= e individual requests
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Means = arbitrarily-large HTTP/2 frames could be permitted without breaking multipl= exing
>
> The present draft is #1.=C2=A0 Combining #3 & #4 gives some flexib= ility, but then requires knowing on a per-frame type behavior which behavio= r is needed.=C2=A0 I currently lean toward #2, but I=E2=80=99m willing to b= e convinced otherwise.=C2=A0 Taking #2 to the extreme, you=E2=80=99re no lo= nger carrying HTTP/2 or anything that pretends to be HTTP/2 =E2=80=93 you= =E2=80=99re defining a fresh way to carry HTTP using a new transport, and m= ost extensions probably need to be redefined if they still apply.

I think #2 is the only way forward on this list that will end up with a HTT= P transport that has comprehensible properties for the caller. (Well, apart= from #1 maybe, but who wants that?)

For completeness sake, there is also #5:
- Every request is done in HTTP/1.1 format on a QUIC stream
- A special QUIC stream is used for signalling only
<= /div>
=E2=80=8BThat's basically what QUIC does today, ri= ght?=E2=80=8B

--001a1140d754266d4b0541140da9-- From nobody Fri Nov 11 22:02:18 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E2B1293DA for ; Fri, 11 Nov 2016 22:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ro1IdV4v4U5H for ; Fri, 11 Nov 2016 22:02:15 -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 E535B129952 for ; Fri, 11 Nov 2016 22:02:14 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id b35so28821529uaa.3 for ; Fri, 11 Nov 2016 22:02:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=R86udjTBjv6CyJ7bH93UjRHOC/dHFSJDDcTkiQGv+R0=; b=Wm3MVPEV1srcd7n1M6e0OG4kEGF3yknCpXAkG3RMWaNkTaGwQ9dmJaqXoG6zlwdhKz n3wGfPoKKcJVLzn4dxkbiQxwpVmpcRvBIFLvvC0gGu+wglSJ2v/iqIcio4WWNhaJIMIU 7/q3rtOfu5rx3mbqWVJtHdU/ir/F3unyvp8rHVm3e/s38JbLKej+YRurxyK0CwOwFdUk URzmv48QLnq1btQ/S3tbN4OJAPGT3SM3lGEKzGIqGNIk58P3tbkB7KY7DyAl8uqtvjLf knMAhNvGQrVdkqRN6YntoCjfZIT9hDgc3TS4eJdoa5DDyD0ZPKINmLTvaueMi4XzRazD ZtIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=R86udjTBjv6CyJ7bH93UjRHOC/dHFSJDDcTkiQGv+R0=; b=f9uWMmzzXc6Ify7dmKM/IspyXsQHDTt5yQpL053Xn/y64IKH5XH4XI2Ou22Rop1cbu goG3J/vYXi2lp8omfIdosG7456VYFgfwesG2/foDHERzm+IJZsQTx12aV9nqQGLwwZOs Lepww+YRK5Th/nt8g9KbaapBl7Otx24hNZP4F02pp9yxfEcmXmKdDjREDOLvNAe2Fo6l YHRC2XIBzTpKpyAfCOryBIFGRnkl2K6+5AkF1lEENjxMSxzL+KMTLLI6VNx8eGZwBGrC ZbQmYlqJTkncH8sSknWHHyGJyOLTHAo7cDu8WZ8sWPAnHbvolrj7HoIh4LZ9x4z5iNK8 R7lA== X-Gm-Message-State: ABUngvceQpCOxuzBkPwzog0bQjVWjrRIMDEbLrixxL+IlkXkXRwIXsKoHhqc/+jumEpQte05kwGrZw2X++CJhOS8 X-Received: by 10.176.6.132 with SMTP id g4mr4355004uag.103.1478930533843; Fri, 11 Nov 2016 22:02:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Fri, 11 Nov 2016 22:02:13 -0800 (PST) From: Jana Iyengar Date: Fri, 11 Nov 2016 22:02:13 -0800 Message-ID: To: Martin Thomson , Ryan Hamilton Content-Type: multipart/alternative; boundary=94eb2c1239001e5da30541145992 Archived-At: Cc: quic@ietf.org Subject: [QUIC] Review of draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 12 Nov 2016 06:02:17 -0000 --94eb2c1239001e5da30541145992 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for your work so far -- this is an important document, so thanks for the work you've put in! Overall, I keep having to check what TLS 1.3 mechanisms and messages are being referred to in the draft. Just as you have a QUIC overview I would add a TLS 1.3 overview. Since there are two encryptors at play (packet and tls messages), the document should probably explain this more clearly, including in key transitions. I remain confused about which packets are encrypted in this proposal. More detailed comments below. - Section 2: (bullet 3) Version Negotiation is a type of packet, there are no frames in it. - Section 2: (bullet 4) "Framing" is used when perhaps you mean to say "Frames"? Usage of QUIC frames is not framing; at least it's not been defined in that way. It's also confusing since framing is generally used more commonly to refer to wire formats. I would reword. - Section 2: (bullet 5) There's confidentiality and integrity protection for the entire packet, not just for frames. - Fig 1 is confusing. Specifically, abstractions, framing, and functions are all present in the same layered picture which makes it confusing. For eg., a "Stream" is an abstraction, "congestion control" is a function, and "frames" refer to wire format representation. I'm not sure this picture helps clarify how various functions are layered. - Fig 1: What is "Envelope"? Is this the QUIC header? If so, some of it is currently encrypted, which means encryption cannot be above it. - Section 3: "Prior to the completion of the TLS handshake, QUIC frames can be exchanged. However, these frames are not authenticated or confidentiality protected." This is not true. 0-RTT data will be sent protected before the handshake is completed. - Section 3.1: What key is the packet encrypted with? The application key? I recall the plan being packets containing handshake messages to go unencrypted, but I don=E2=80=99t remember why. Is this still the plan? If s= o, are KeyUpdate messages sent later also sent in an unencrypted packet? Why not just use the application key for encrypting the packet at all times? - What does =E2=80=9CQUIC provides a record protection layer=E2=80=9D mean?= This is new terminology at the least, so the =E2=80=9Crecord protection layer=E2=80=9D = should be defined. - Section 4.1 says: =E2=80=9CThe KEY_PHASE bit allows a recipient to detect a change in keyi= ng material without needing to receive the message that triggers the change. This avoids head-of-line blocking around transitions between keys without relying on trial decryption.=E2=80=9D How does this avoid head-of-line blocking around transitions? What head-of-line blocking do you have in mind here? Or do you mean to say that this bit allows handling of reordered packets correctly without relying on trial-decryption? - Why does the server need to send anything with a 0-RTT encrypter? Doesn= =E2=80=99t the server move immediately to 1RTT keys for sending, but keeps 0RTT-key and 1RTT-key decrypters? - I like the phase changes, but I=E2=80=99m still a bit nervous. I think (I= need to think more) that it will work out ok, but some more text here will help, especially on why a KEY_PHASE of 0 or 1 is unambiguous on both sides, 0-RTT or not, and why it is not possible to end up in strange states. (I now see text that follows explains this. Perhaps add a forward pointer here.) - =E2=80=9C0-RTT keys SHOULD be retained until the handshake is complete.= =E2=80=9D Why=E2=80=99s this a SHOULD and not a MUST? Why is this sentence required at all? - =E2=80=9CA client would be unable to decrypt retransmissions of a server'= s handshake messages that are protected using the 1-RTT keys, since the calculation of the application data keys depends on the contents of the handshake messages.=E2=80=9D This is a confusing sentence. Since you=E2=80=99re talking about decryption= of handshake messages, why do the application data keys matter? - =E2=80=9CAs shown in Figure 3 and Figure 4, there is never a situation wh= ere there are more than two different sets of keying material that might be received by a peer.=E2=80=9D With reordering, I don=E2=80=99t think this statement is true. We need rule= s using packet numbers, such that an old packet with a key phase matching the current expected should not cause the connection to blow up. - Section 4.1.2: I should probably go read about Key Updates in TLS 1.3 before trying to understand the details in this section. If so, a pointer somewhere would be useful. - Section 4.3: =E2=80=9CThe nonce, N, for the AEAD is formed by combining e= ither the Client Write IV or Server Write IV with the sequence numbers.=E2=80=9D What=E2=80= =99s the Client/Server Write IV? The next couple of paragraphs are quite confusing. Why is there no Associated Data? QUIC currently uses the unencrypted packet header as Associated Data. The QUIC packet does not have frames following the packet number=E2=80=A6. it=E2=80=99s not clear what it means for P to b= e the =E2=80=9CQUIC frame following the packet number=E2=80=9D? - I=E2=80=99m surprised to see a TLS sequence number, given that QUIC has o= ne (and currently uses just that.) It seems like this may be for Key Updates later in the connection. I=E2=80=99d like to understand this better. In particula= r, it=E2=80=99s not clear to me why reusing sequence numbers is better than not. I=E2=80=99= m also curious to understand how important Key Update is, given that 0-RTT connection establishment nearly eliminates the cost of re-establishing a QUIC connection. - Section 5: =E2=80=9CImplementations MUST NOT exchange data on any stream = other than stream 1 prior to the completion of the TLS handshake.=E2=80=9D This doe= s not work, since 0-RTT data is sent on other streams before handshake completion= . - Section 5.1.2: I would like an explicit requirement on ACKs to be encrypted at the same level or higher as the packet that the ACK acknowledges. Is that adequate for this section? - Section 5.1.4: =E2=80=9CNote that the client could retransmit its Finished message to the server, so the server cannot reject such a message.=E2=80=9D Don=E2=80=99t understa= nd this sentence. - =E2=80=9CNever assume that because it isn't in the security consideration= s section it doesn't affect security. Most of this document does.=E2=80= =9D Seems unnecessary. Also, seems silly to say that =E2=80=9Cmost=E2=80=9D of this d= ocument affects security, since =E2=80=9Call=E2=80=9D of it does. --94eb2c1239001e5da30541145992 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for your work so far -- this is an important d= ocument, so thanks for the work you've put in!

=
Overall, I keep having to check what TLS 1.3 mechanisms and messa= ges are being referred to in the draft. Just as you have a QUIC overview I = would add a TLS 1.3 overview.=C2=A0

Since there ar= e two encryptors at play (packet and tls messages), the document should pro= bably explain this more clearly, including =C2=A0in key transitions. I rema= in confused about which packets are encrypted in this proposal.
<= br>
More detailed comments below.

- Sect= ion 2: (bullet 3) Version Negotiation is a type of packet, there are no fra= mes in it.

- Section 2: (bullet 4) "= Framing" is used when perhaps you mean to say "Frames"? Usag= e of QUIC frames is not framing; at least it's not been defined in that= way. It's also confusing since framing is generally used more commonly= to refer to wire formats. I would reword.

-= Section 2: (bullet 5) There's confidentiality and integrity protection= for the entire packet, not just for frames.=C2=A0

- Fig 1 is confusing. Specifically, abstractions, framing, and functions a= re all present in the same layered picture which makes it confusing. For eg= ., a "Stream" is an abstraction, "congestion control" i= s a function, and "frames" refer to wire format representation. I= 'm not sure this picture helps clarify how various functions are layere= d.=C2=A0

- Fig 1: What is "Envelope"? Is= this the QUIC header? If so, some of it is currently encrypted, which mean= s encryption cannot be above it.

- Section 3: &quo= t;Prior to the completion of the TLS handshake, QUIC frames can be exchange= d. However, these frames are not authenticated or confidentiality protected= ." This is not true. 0-RTT data will be sent protected before the hand= shake is completed.=C2=A0

- Section 3.1: What key = is the packet encrypted with? The application key? I recall the plan being = packets containing handshake messages to go unencrypted, but I don=E2=80=99= t remember why. Is this still the plan? If so, are KeyUpdate messages sent = later also sent in an unencrypted packet? Why not just use the application = key for encrypting the packet at all times?

- What= does =E2=80=9CQUIC provides a record protection layer=E2=80=9D mean? This = is new terminology at the least, so the =E2=80=9Crecord protection layer=E2= =80=9D should be defined.

- Section 4.1 says:
=C2=A0 =C2=A0=E2=80=9CThe KEY_PHASE bit allows a recipient to detect = a change in keying
=C2=A0 =C2=A0material without needing to recei= ve the message that triggers the
=C2=A0 =C2=A0change.=C2=A0 This = avoids head-of-line blocking around transitions between
=C2=A0 = =C2=A0keys without relying on trial decryption.=E2=80=9D
How does= this avoid head-of-line blocking around transitions? What head-of-line blo= cking do you have in mind here? Or do you mean to say that this bit allows = handling of reordered packets correctly without relying on trial-decryption= ?

- Why does the server need to send anything with= a 0-RTT encrypter? Doesn=E2=80=99t the server move immediately to 1RTT key= s for sending, but keeps 0RTT-key and 1RTT-key decrypters?

- I like the phase changes, but I=E2=80=99m still a bit nervous. I= think (I need to think more) that it will work out ok, but some more text = here will help, especially on why a KEY_PHASE of 0 or 1 is unambiguous on b= oth sides, 0-RTT or not, and why it is not possible to end up in strange st= ates. (I now see text that follows explains this. Perhaps add a forward poi= nter here.)

- =E2=80=9C0-RTT keys SHOULD be retain= ed until the handshake is complete.=E2=80=9D Why=E2=80=99s this a SHOULD an= d not a MUST? Why is this sentence required at all?

- =E2=80=9CA client would be unable to decrypt retransmissions of a serve= r's
=C2=A0 =C2=A0handshake messages that are protected using = the 1-RTT keys, since the
=C2=A0 =C2=A0calculation of the applica= tion data keys depends on the contents of
=C2=A0 =C2=A0the handsh= ake messages.=E2=80=9D=C2=A0
This is a confusing sentence. Since = you=E2=80=99re talking about decryption of handshake messages, why do the a= pplication data keys matter?

- =E2=80=9CAs shown i= n Figure 3 and Figure 4, there is never a situation where
=C2=A0 = =C2=A0there are more than two different sets of keying material that might<= /div>
=C2=A0 =C2=A0be received by a peer.=E2=80=9D=C2=A0
With= reordering, I don=E2=80=99t think this statement is true. We need rules us= ing packet numbers, such that an old packet with a key phase matching the c= urrent expected should not cause the connection to blow up.

<= /div>
- Section 4.1.2: I should probably go read about Key Updates in T= LS 1.3 before trying to understand the details in this section. If so, a po= inter somewhere would be useful.

- Section 4.3: = =E2=80=9CThe nonce, N, for the AEAD is formed by combining either the Clien= t
Write IV or Server Write IV with the sequence numbers.=E2=80=9D= What=E2=80=99s the Client/Server Write IV? The next couple of paragraphs a= re quite confusing. Why is there no Associated Data? QUIC currently uses th= e unencrypted packet header as Associated Data. The QUIC packet does not ha= ve frames following the packet number=E2=80=A6. it=E2=80=99s not clear what= it means for P to be the =E2=80=9CQUIC frame following the packet number= =E2=80=9D?

- I=E2=80=99m surprised to see a TLS se= quence number, given that QUIC has one (and currently uses just that.) It s= eems like this may be for Key Updates later in the connection. I=E2=80=99d = like to understand this better. In particular, it=E2=80=99s not clear to me= why reusing sequence numbers is better than not. I=E2=80=99m also curious = to understand how important Key Update is, given that 0-RTT connection esta= blishment nearly eliminates the cost of re-establishing a QUIC connection.<= /div>

- Section 5: =E2=80=9CImplementations MUST NOT exc= hange data on any stream other than
=C2=A0 =C2=A0stream 1 prior t= o the completion of the TLS handshake.=E2=80=9D This does not work, since 0= -RTT data is sent on other streams before handshake completion.
<= br>
- Section 5.1.2: I would like an explicit =C2=A0requirement o= n ACKs to be encrypted at the same level or higher as the packet that the A= CK acknowledges. Is that adequate for this section?

- Section 5.1.4: =E2=80=9CNote that
=C2=A0 =C2=A0the client cou= ld retransmit its Finished message to the server, so
=C2=A0 =C2= =A0the server cannot reject such a message.=E2=80=9D Don=E2=80=99t understa= nd this sentence.

- =E2=80=9CNever assume that bec= ause it isn't in the security considerations
=C2=A0 =C2=A0sec= tion it doesn't affect security.=C2=A0 Most of this document does.=E2= =80=9D Seems unnecessary. Also, seems silly to say that =E2=80=9Cmost=E2=80= =9D of this document affects security, since =E2=80=9Call=E2=80=9D of it do= es.

--94eb2c1239001e5da30541145992-- From nobody Sat Nov 12 18:04:50 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 612CA1294DF for ; Sat, 12 Nov 2016 18:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqldtMr_O8lo for ; Sat, 12 Nov 2016 18:04:46 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 B95361294B2 for ; Sat, 12 Nov 2016 18:04:45 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id v78so15430833ybe.3 for ; Sat, 12 Nov 2016 18:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oxixYtMNkEMNL3j4OmyBpdMd//jmL9NVCHYqnJ0bVew=; b=YYe/+2NhZHkIZGIgsMguNCdBx8i0mAR7LV9KxKsEuCHpkyqkVBw0wZjsCMkvUrX59F ieYiYjVmHyNWMgP8/eAcV19/zYdbFfyvDSUGFohoYJ+83kVoIy/0yPox2JNr3kaCl0TT LET2jvk7pDMiwRF/COgAWIP2tEOpP/+M7GswDdQQhUeugI2AFLuSPzULFSFlT3nmmfDV EaVZWBZjUP7O8j1vs/ZR3DuzNzAGHnObuqAa1J4zdB9fq9P3BnnMlcCHi0sLCwoz4lTP tioh4eR922wPfdM1QnabS/gPsno6tJ9G44Idtggor+wsSqPY34nd4x4cYoEYHyAxejtP OeLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oxixYtMNkEMNL3j4OmyBpdMd//jmL9NVCHYqnJ0bVew=; b=SagEMmtedRtkP4Z8XfbrOn9KXYpSxNvB04UZ/VRjKM6AJLq4qE7f1kQ+XheR4SFVDr SMhkcAFVevZDkL9QuyBWiQtAFsMajwqzYu68YWHnc/iGFu9VtX0PU21Wf68wGu0+bUjI Loo+NX7zb1O3ZOBIKzqkRnOxfCavsR9GyWtlWm2BaWqi/ImTgBGgMBVjTGRjs0alRTFe kgN9miMmGExGTrO4IDJERpO94KBWT0uWplCkNwLj+JF866ZDtZouBDflgcNQAedOZn9a e5o4NP1L8MaCNb5ZnQ7OC9VEpfDDyyHRKdltd64pNx1zI9tjCCGWwYo+HQ672FoUUE+a P6gg== X-Gm-Message-State: ABUngvfI5GeaQ21JCaKbf0Fu0UhFuMBC6c10TwYO6xcooLK2P+y9PITc6ZxtbZ+YWJh8l+hLYDuDC9OQSMu4zmDW X-Received: by 10.37.173.70 with SMTP id l6mr8091837ybe.174.1479002684805; Sat, 12 Nov 2016 18:04:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.203.69 with HTTP; Sat, 12 Nov 2016 18:04:24 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Sat, 12 Nov 2016 21:04:24 -0500 Message-ID: To: Jana Iyengar Content-Type: multipart/alternative; boundary=f403045ec9fca68ab205412525a0 Archived-At: Cc: quic@ietf.org, Martin Thomson , Ryan Hamilton Subject: Re: [QUIC] Review of draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 13 Nov 2016 02:04:48 -0000 --f403045ec9fca68ab205412525a0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the great progress on this document. It's definitely getting much closer. I had some of the same comments as Jana and added some notes and a few new comments. On Sat, Nov 12, 2016 at 1:02 AM, Jana Iyengar wrote: > Thanks for your work so far -- this is an important document, so thanks > for the work you've put in! > > Overall, I keep having to check what TLS 1.3 mechanisms and messages are > being referred to in the draft. Just as you have a QUIC overview I would > add a TLS 1.3 overview. > > Since there are two encryptors at play (packet and tls messages), the > document should probably explain this more clearly, including in key > transitions. I remain confused about which packets are encrypted in this > proposal. > > More detailed comments below. > > - Section 2: (bullet 3) Version Negotiation is a type of packet, there ar= e > no frames in it. > > - Section 2: (bullet 4) "Framing" is used when perhaps you mean to say > "Frames"? Usage of QUIC frames is not framing; at least it's not been > defined in that way. It's also confusing since framing is generally used > more commonly to refer to wire formats. I would reword. > > - Section 2: (bullet 5) There's confidentiality and integrity protection > for the entire packet, not just for frames. > > - Fig 1 is confusing. Specifically, abstractions, framing, and functions > are all present in the same layered picture which makes it confusing. For > eg., a "Stream" is an abstraction, "congestion control" is a function, an= d > "frames" refer to wire format representation. I'm not sure this picture > helps clarify how various functions are layered. > > - Fig 1: What is "Envelope"? Is this the QUIC header? If so, some of it i= s > currently encrypted, which means encryption cannot be above it. > Now that private flags are gone, there is no encrypted portion of the QUIC header. That being said, it's likely worth clarifying what envelope is. > > - Section 3: "Prior to the completion of the TLS handshake, QUIC frames > can be exchanged. However, these frames are not authenticated or > confidentiality protected." This is not true. 0-RTT data will be sent > protected before the handshake is completed. > > - Section 3.1: What key is the packet encrypted with? The application key= ? > I recall the plan being packets containing handshake messages to go > unencrypted, but I don=E2=80=99t remember why. Is this still the plan? If= so, are > KeyUpdate messages sent later also sent in an unencrypted packet? Why not > just use the application key for encrypting the packet at all times? > > - What does =E2=80=9CQUIC provides a record protection layer=E2=80=9D mea= n? This is new > terminology at the least, so the =E2=80=9Crecord protection layer=E2=80= =9D should be > defined. > > - Section 4.1 says: > =E2=80=9CThe KEY_PHASE bit allows a recipient to detect a change in ke= ying > material without needing to receive the message that triggers the > change. This avoids head-of-line blocking around transitions between > keys without relying on trial decryption.=E2=80=9D > How does this avoid head-of-line blocking around transitions? What > head-of-line blocking do you have in mind here? Or do you mean to say tha= t > this bit allows handling of reordered packets correctly without relying o= n > trial-decryption? > > - Why does the server need to send anything with a 0-RTT encrypter? > Doesn=E2=80=99t the server move immediately to 1RTT keys for sending, but= keeps > 0RTT-key and 1RTT-key decrypters? > > - I like the phase changes, but I=E2=80=99m still a bit nervous. I think = (I need > to think more) that it will work out ok, but some more text here will hel= p, > especially on why a KEY_PHASE of 0 or 1 is unambiguous on both sides, 0-R= TT > or not, and why it is not possible to end up in strange states. (I now se= e > text that follows explains this. Perhaps add a forward pointer here.) > > - =E2=80=9C0-RTT keys SHOULD be retained until the handshake is complete.= =E2=80=9D Why=E2=80=99s > this a SHOULD and not a MUST? Why is this sentence required at all? > > - =E2=80=9CA client would be unable to decrypt retransmissions of a serve= r's > handshake messages that are protected using the 1-RTT keys, since the > calculation of the application data keys depends on the contents of > the handshake messages.=E2=80=9D > This is a confusing sentence. Since you=E2=80=99re talking about decrypti= on of > handshake messages, why do the application data keys matter? > > - =E2=80=9CAs shown in Figure 3 and Figure 4, there is never a situation = where > there are more than two different sets of keying material that might > be received by a peer.=E2=80=9D > With reordering, I don=E2=80=99t think this statement is true. We need ru= les using > packet numbers, such that an old packet with a key phase matching the > current expected should not cause the connection to blow up. > > - Section 4.1.2: I should probably go read about Key Updates in TLS 1.3 > before trying to understand the details in this section. If so, a pointer > somewhere would be useful. > > - Section 4.3: =E2=80=9CThe nonce, N, for the AEAD is formed by combining= either > the Client > Write IV or Server Write IV with the sequence numbers.=E2=80=9D What=E2= =80=99s the > Client/Server Write IV? The next couple of paragraphs are quite confusing= . > Why is there no Associated Data? QUIC currently uses the unencrypted pack= et > header as Associated Data. The QUIC packet does not have frames following > the packet number=E2=80=A6. it=E2=80=99s not clear what it means for P to= be the =E2=80=9CQUIC > frame following the packet number=E2=80=9D? > > - I=E2=80=99m surprised to see a TLS sequence number, given that QUIC has= one (and > currently uses just that.) It seems like this may be for Key Updates late= r > in the connection. I=E2=80=99d like to understand this better. In particu= lar, it=E2=80=99s > not clear to me why reusing sequence numbers is better than not. I=E2=80= =99m also > curious to understand how important Key Update is, given that 0-RTT > connection establishment nearly eliminates the cost of re-establishing a > QUIC connection. > > - Section 5: =E2=80=9CImplementations MUST NOT exchange data on any strea= m other > than > stream 1 prior to the completion of the TLS handshake.=E2=80=9D This d= oes not > work, since 0-RTT data is sent on other streams before handshake completi= on. > > - Section 5.1.2: I would like an explicit requirement on ACKs to be > encrypted at the same level or higher as the packet that the ACK > acknowledges. Is that adequate for this section? > I think that's what this section says, but it could be a bit more direct about it. > > - Section 5.1.4: =E2=80=9CNote that > the client could retransmit its Finished message to the server, so > the server cannot reject such a message.=E2=80=9D Don=E2=80=99t unders= tand this > sentence. > > - =E2=80=9CNever assume that because it isn't in the security considerati= ons > section it doesn't affect security. Most of this document does.=E2=80= =9D Seems > unnecessary. Also, seems silly to say that =E2=80=9Cmost=E2=80=9D of this= document affects > security, since =E2=80=9Call=E2=80=9D of it does. > > Section 4.1 says: "The KEY_PHASE bit on the public flags is the most significant bit (0x80)." I would suggest we use the current diversification nonce bit.(0x04), as it is otherwise unused in the TLS 1.3 version of QUIC. Section 4.5 goes into Packet Number reconstruction. I don't think it's necessary to do this here(and there is a small error), though if you want to state properties of packet numbers(ie: monotonically increasing on the sender side) that seems fine if it's helpful to the mapping doc. Section 5.1.4 says "The ability to shadow packets means that an attacker does not need to be on path." I believe the attacker must be on path, unless I'm misunderstanding something? In regards to starting at a randomized packet number, that does provide some level of protection, and seems wise. It also reduces the chances of ossification on the handshake packets always starting at packet number 1. I think "In addition to denying endpoints messages, an attacker to generate packets that cause no state change in a recipient." needs to be reworded, because I'm rather confused on what it's saying. Can you clarify "MUST reject empty TLS handshake records and any record that is not permitted by the TLS state machine". Should these packets be ignored, under the assumption they're attack packets? Or should the handshake fail? 5.3 is confusing to me. For example, it says "Due to reordering and loss, protected packets might be received by an endpoint before the final handshake messages are received. If these can be decrypted successfully, such packets MAY be stored and used once the handshake is complete." I think this deserves more specificity. In cases when the packets are encrypted with 1RTT keys, may should be stored for later decryption, but there's no chance of them being decrypted before the SHLO wasn't received. I'm a bit confused about what other cases you are thinking of in the section? 6.4 says "Even if the source IP address remains constant, the port number is likely to be different." between TCP and QUIC. In typical cases, the port number is new for every connection anyway, so I'm not sure this is a relevant concern. I would just remove that sentence. 7: clanger, though it looks like dangers, is not the same word :) 7.1: I think we need to loosen "A server SHOULD use a HelloRetryRequest if the size of the handshake messages it sends is likely to exceed the size of the ClientHello." slightly to "a small multiple of the size of the ClientHello", or something similar, because multipacket certs are extremely common. --f403045ec9fca68ab205412525a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the great progress on this document.=C2=A0= It's definitely getting much closer.

I had some of= the same comments as Jana and added some notes and a few new comments. =C2= =A0

On Sat, No= v 12, 2016 at 1:02 AM, Jana Iyengar <jri@google.com> wrote:
=
Tha= nks for your work so far -- this is an important document, so thanks for th= e work you've put in!

Overall, I keep= having to check what TLS 1.3 mechanisms and messages are being referred to= in the draft. Just as you have a QUIC overview I would add a TLS 1.3 overv= iew.=C2=A0

Since there are two encryptors at play = (packet and tls messages), the document should probably explain this more c= learly, including =C2=A0in key transitions. I remain confused about which p= ackets are encrypted in this proposal.

More detail= ed comments below.

- Section 2: (bullet 3) Version= Negotiation is a type of packet, there are no frames in it.
=

- Section 2: (bullet 4) "Framing" is used whe= n perhaps you mean to say "Frames"? Usage of QUIC frames is not f= raming; at least it's not been defined in that way. It's also confu= sing since framing is generally used more commonly to refer to wire formats= . I would reword.

- Section 2: (bullet 5) Th= ere's confidentiality and integrity protection for the entire packet, n= ot just for frames.=C2=A0

- Fig 1 is confusing. Sp= ecifically, abstractions, framing, and functions are all present in the sam= e layered picture which makes it confusing. For eg., a "Stream" i= s an abstraction, "congestion control" is a function, and "f= rames" refer to wire format representation. I'm not sure this pict= ure helps clarify how various functions are layered.=C2=A0

- Fig 1: What is "Envelope"? Is this the QUIC header? If= so, some of it is currently encrypted, which means encryption cannot be ab= ove it.

Now that private = flags are gone, there is no encrypted portion of the QUIC header. =C2=A0 Th= at being said, it's likely worth clarifying what envelope is.
- Section 3: "Prior to the completion of the TLS handshak= e, QUIC frames can be exchanged. However, these frames are not authenticate= d or confidentiality protected." This is not true. 0-RTT data will be = sent protected before the handshake is completed.=C2=A0

- Section 3.1: What key is the packet encrypted with? The application= key? I recall the plan being packets containing handshake messages to go u= nencrypted, but I don=E2=80=99t remember why. Is this still the plan? If so= , are KeyUpdate messages sent later also sent in an unencrypted packet? Why= not just use the application key for encrypting the packet at all times?

- What does =E2=80=9CQUIC provides a record protect= ion layer=E2=80=9D mean? This is new terminology at the least, so the =E2= =80=9Crecord protection layer=E2=80=9D should be defined.

- Section 4.1 says:
=C2=A0 =C2=A0=E2=80=9CThe KEY_PHASE b= it allows a recipient to detect a change in keying
=C2=A0 =C2=A0m= aterial without needing to receive the message that triggers the
= =C2=A0 =C2=A0change.=C2=A0 This avoids head-of-line blocking around transit= ions between
=C2=A0 =C2=A0keys without relying on trial decryptio= n.=E2=80=9D
How does this avoid head-of-line blocking around tran= sitions? What head-of-line blocking do you have in mind here? Or do you mea= n to say that this bit allows handling of reordered packets correctly witho= ut relying on trial-decryption?

- Why does the ser= ver need to send anything with a 0-RTT encrypter? Doesn=E2=80=99t the serve= r move immediately to 1RTT keys for sending, but keeps 0RTT-key and 1RTT-ke= y decrypters?

- I like the phase changes, but I=E2= =80=99m still a bit nervous. I think (I need to think more) that it will wo= rk out ok, but some more text here will help, especially on why a KEY_PHASE= of 0 or 1 is unambiguous on both sides, 0-RTT or not, and why it is not po= ssible to end up in strange states. (I now see text that follows explains t= his. Perhaps add a forward pointer here.)

- =E2=80= =9C0-RTT keys SHOULD be retained until the handshake is complete.=E2=80=9D = Why=E2=80=99s this a SHOULD and not a MUST? Why is this sentence required a= t all?

- =E2=80=9CA client would be unable to decr= ypt retransmissions of a server's
=C2=A0 =C2=A0handshake mess= ages that are protected using the 1-RTT keys, since the
=C2=A0 = =C2=A0calculation of the application data keys depends on the contents of
=C2=A0 =C2=A0the handshake messages.=E2=80=9D=C2=A0
This= is a confusing sentence. Since you=E2=80=99re talking about decryption of = handshake messages, why do the application data keys matter?

=
- =E2=80=9CAs shown in Figure 3 and Figure 4, there is never a s= ituation where
=C2=A0 =C2=A0there are more than two different set= s of keying material that might
=C2=A0 =C2=A0be received by a pee= r.=E2=80=9D=C2=A0
With reordering, I don=E2=80=99t think this sta= tement is true. We need rules using packet numbers, such that an old packet= with a key phase matching the current expected should not cause the connec= tion to blow up.

- Section 4.1.2: I should probabl= y go read about Key Updates in TLS 1.3 before trying to understand the deta= ils in this section. If so, a pointer somewhere would be useful.
=
- Section 4.3: =E2=80=9CThe nonce, N, for the AEAD is formed= by combining either the Client
Write IV or Server Write IV with = the sequence numbers.=E2=80=9D What=E2=80=99s the Client/Server Write IV? T= he next couple of paragraphs are quite confusing. Why is there no Associate= d Data? QUIC currently uses the unencrypted packet header as Associated Dat= a. The QUIC packet does not have frames following the packet number=E2=80= =A6. it=E2=80=99s not clear what it means for P to be the =E2=80=9CQUIC fra= me following the packet number=E2=80=9D?

- I=E2=80= =99m surprised to see a TLS sequence number, given that QUIC has one (and c= urrently uses just that.) It seems like this may be for Key Updates later i= n the connection. I=E2=80=99d like to understand this better. In particular= , it=E2=80=99s not clear to me why reusing sequence numbers is better than = not. I=E2=80=99m also curious to understand how important Key Update is, gi= ven that 0-RTT connection establishment nearly eliminates the cost of re-es= tablishing a QUIC connection.=C2=A0

- Section 5: =E2=80=9CImplementations MUST NOT exchange data on any= stream other than
=C2=A0 =C2=A0stream 1 prior to the completion = of the TLS handshake.=E2=80=9D This does not work, since 0-RTT data is sent= on other streams before handshake completion.

- S= ection 5.1.2: I would like an explicit =C2=A0requirement on ACKs to be encr= ypted at the same level or higher as the packet that the ACK acknowledges. = Is that adequate for this section?

<= /div>
I think that's what this section says, but it could be a bit = more direct about it.
=C2=A0

- Section 5.1.= 4: =E2=80=9CNote that
=C2=A0 =C2=A0the client could retransmit it= s Finished message to the server, so
=C2=A0 =C2=A0the server cann= ot reject such a message.=E2=80=9D Don=E2=80=99t understand this sentence.<= /div>

- =E2=80=9CNever assume that because it isn't = in the security considerations
=C2=A0 =C2=A0section it doesn'= t affect security.=C2=A0 Most of this document does.=E2=80=9D Seems unneces= sary. Also, seems silly to say that =E2=80=9Cmost=E2=80=9D of this document= affects security, since =E2=80=9Call=E2=80=9D of it does.


Section 4.1 says: &= quot;The KEY_PHASE bit on the public flags is the most significant bit (0x8= 0)." =C2=A0I would suggest we use the current diversification nonce bi= t.(0x04), as it is otherwise unused in the TLS 1.3 version of QUIC.

Section 4= .5 goes into Packet Number reconstruction.=C2=A0 I don't think it's= necessary to do this here(and there is a small error), though if you want = to state properties of packet numbers(ie: monotonically increasing on the s= ender side) that seems fine if it's helpful to the mapping doc.

Section 5.1.4= says "The ability to shadow packets means that an attacker does not n= eed to be on path." =C2=A0I believe the attacker must be on path, unle= ss I'm misunderstanding something?=C2=A0 In regards to starting at a ra= ndomized packet number, that does provide some level of protection, and see= ms wise.=C2=A0 It also reduces the chances of ossification on the handshake= packets always starting at packet number 1.

I think "In addi= tion to denying endpoints messages, an attacker to generate packets that ca= use no state change in a recipient." needs to be reworded,=C2=A0becaus= e I'm rather confused on what it's saying.

Can you clarify &= quot;MUST reject empty TLS handshake records and any record that is not per= mitted by the TLS state machine".=C2=A0 Should these packets be ignore= d, under the assumption they're attack packets?=C2=A0 Or should the han= dshake fail?

5.3 is confusing to me.=C2=A0 For example, = it says "Due to reordering and loss, protected packets might be receiv= ed by an endpoint before the final handshake messages are received. If thes= e can be decrypted successfully, such packets MAY be stored and used once t= he handshake is complete." =C2=A0I think this deserves more specificit= y.=C2=A0 In cases when the packets are encrypted with 1RTT keys, may should= be stored for later decryption, but there's no chance of them being de= crypted before the SHLO wasn't received.=C2=A0 I'm a bit confused a= bout what other cases you are thinking of in the section?=C2=A0

6.= 4 says "Even if the source IP address remains constant, the port numbe= r is likely to be different." between TCP and QUIC.=C2=A0 In typical c= ases, the port number is new for every connection anyway, so I'm not su= re this is a relevant concern.=C2=A0 I would just remove that sentence.
7: clanger, though it looks like dangers, is not the same w= ord :)

7.1: I think we need to loosen "A serv= er SHOULD use a HelloRetryRequest if the size of the handshake messages it = sends is likely to exceed the size of the ClientHello." slightly to &q= uot;a small multiple of the size of the ClientHello", or something sim= ilar, because multipacket certs are extremely common.


--f403045ec9fca68ab205412525a0-- From nobody Sat Nov 12 18:22:42 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7D81294BB for ; Sat, 12 Nov 2016 18:22:40 -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 f5r3m20EusoT for ; Sat, 12 Nov 2016 18:22:38 -0800 (PST) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::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 5172B129460 for ; Sat, 12 Nov 2016 18:22:38 -0800 (PST) Received: by mail-qk0-x241.google.com with SMTP id n204so6530882qke.2 for ; Sat, 12 Nov 2016 18:22:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2e1dksz174IGzuuDSqJsvITt+OAr5ykUYta2Co8WgT0=; b=AERPOkogfQJtFc4yTBGxZxtOjC5w4f8cyanIVSDUZVguJST6YEiTD5U2LPvVmf8TRL +X2nPyZBihqlnEe9JrjSBHtdMnADaC8b0Zsesmki5YnhaEntSw3TNkjjmWK8j9lV/jJw Jo4V1PUGTdq2fTmfJ0kNVDcM3kzXoGO3cBWVI+Wmxj7btSQg9YTGR7KlmY7ZyCcXhIS4 zlBrWzHAbyluP4aRtTFCiCvmaMkiAieWKFhbednc/y0qcLDQrd5G0ird9jNcLNAXQbaC mdpbTam5/qVvrPCLnR+dpeFst7sNaX3nf3xzW2Oy9pCQQ+l9OsS+zcd2ETXM68BhVx2/ /Ksw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2e1dksz174IGzuuDSqJsvITt+OAr5ykUYta2Co8WgT0=; b=Ixoy6vT5QRweTPJZ2yRGYk3o4fYh9vAufXkrGjKrnMJjPkNP2G6BBr7+k6nKkw3Eip tAY7RIU5EUJYGPjiR927Ha++du39lony5CwCRMsbY4JzE6fHMizRNPnGzp+iHgoHptEG pLRC6Rk7XfhOi3IXmGBE8oc4StUntak0w8GWbbVfRbKxlozqwzRA1g1wypu3gQXtUCA/ paE2sfoSNp/mQifLkAbwoxgKiLH3AR7YbTK86oTgmLeMuZQT4TSVhVFJwRVwBWVNDc3Z nJcLaN4YUayCw5ZrBbpcZ9w0678jc6EyJbSI0Gk/RIGF/91e/fdpOnrTs3UDxrnvKhwj MM9g== X-Gm-Message-State: ABUngvdeCFECqavZtHVj/d6k8+XrTo9QDP8FgPy8Eg/3WuAaegNgdy3M3ut7d24F4HhPxlxxvXNUT9RFyCBUww== X-Received: by 10.55.158.199 with SMTP id h190mr11653514qke.202.1479003757330; Sat, 12 Nov 2016 18:22:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sat, 12 Nov 2016 18:22:36 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Sun, 13 Nov 2016 11:22:36 +0900 Message-ID: To: Ian Swett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jana Iyengar , quic@ietf.org, Ryan Hamilton Subject: Re: [QUIC] Review of draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 13 Nov 2016 02:22:40 -0000 Thanks guys, as you might imagine, I'm a little busy this week, but I will look at your comments and respond when I have more time. I hope that I can also update the doc. Ian, clangers AND dangers, sometimes even both, sometimes the latter because of the former :) On 13 November 2016 at 11:04, Ian Swett wrote: > Thanks for the great progress on this document. It's definitely getting > much closer. > > I had some of the same comments as Jana and added some notes and a few ne= w > comments. > > On Sat, Nov 12, 2016 at 1:02 AM, Jana Iyengar wrote: >> >> Thanks for your work so far -- this is an important document, so thanks >> for the work you've put in! >> >> Overall, I keep having to check what TLS 1.3 mechanisms and messages are >> being referred to in the draft. Just as you have a QUIC overview I would= add >> a TLS 1.3 overview. >> >> Since there are two encryptors at play (packet and tls messages), the >> document should probably explain this more clearly, including in key >> transitions. I remain confused about which packets are encrypted in this >> proposal. >> >> More detailed comments below. >> >> - Section 2: (bullet 3) Version Negotiation is a type of packet, there a= re >> no frames in it. >> >> - Section 2: (bullet 4) "Framing" is used when perhaps you mean to say >> "Frames"? Usage of QUIC frames is not framing; at least it's not been >> defined in that way. It's also confusing since framing is generally used >> more commonly to refer to wire formats. I would reword. >> >> - Section 2: (bullet 5) There's confidentiality and integrity protection >> for the entire packet, not just for frames. >> >> - Fig 1 is confusing. Specifically, abstractions, framing, and functions >> are all present in the same layered picture which makes it confusing. Fo= r >> eg., a "Stream" is an abstraction, "congestion control" is a function, a= nd >> "frames" refer to wire format representation. I'm not sure this picture >> helps clarify how various functions are layered. >> >> - Fig 1: What is "Envelope"? Is this the QUIC header? If so, some of it = is >> currently encrypted, which means encryption cannot be above it. > > > Now that private flags are gone, there is no encrypted portion of the QUI= C > header. That being said, it's likely worth clarifying what envelope is. >> >> >> - Section 3: "Prior to the completion of the TLS handshake, QUIC frames >> can be exchanged. However, these frames are not authenticated or >> confidentiality protected." This is not true. 0-RTT data will be sent >> protected before the handshake is completed. >> >> - Section 3.1: What key is the packet encrypted with? The application ke= y? >> I recall the plan being packets containing handshake messages to go >> unencrypted, but I don=E2=80=99t remember why. Is this still the plan? I= f so, are >> KeyUpdate messages sent later also sent in an unencrypted packet? Why no= t >> just use the application key for encrypting the packet at all times? >> >> - What does =E2=80=9CQUIC provides a record protection layer=E2=80=9D me= an? This is new >> terminology at the least, so the =E2=80=9Crecord protection layer=E2=80= =9D should be >> defined. >> >> - Section 4.1 says: >> =E2=80=9CThe KEY_PHASE bit allows a recipient to detect a change in k= eying >> material without needing to receive the message that triggers the >> change. This avoids head-of-line blocking around transitions between >> keys without relying on trial decryption.=E2=80=9D >> How does this avoid head-of-line blocking around transitions? What >> head-of-line blocking do you have in mind here? Or do you mean to say th= at >> this bit allows handling of reordered packets correctly without relying = on >> trial-decryption? >> >> - Why does the server need to send anything with a 0-RTT encrypter? >> Doesn=E2=80=99t the server move immediately to 1RTT keys for sending, bu= t keeps >> 0RTT-key and 1RTT-key decrypters? >> >> - I like the phase changes, but I=E2=80=99m still a bit nervous. I think= (I need >> to think more) that it will work out ok, but some more text here will he= lp, >> especially on why a KEY_PHASE of 0 or 1 is unambiguous on both sides, 0-= RTT >> or not, and why it is not possible to end up in strange states. (I now s= ee >> text that follows explains this. Perhaps add a forward pointer here.) >> >> - =E2=80=9C0-RTT keys SHOULD be retained until the handshake is complete= .=E2=80=9D Why=E2=80=99s >> this a SHOULD and not a MUST? Why is this sentence required at all? >> >> - =E2=80=9CA client would be unable to decrypt retransmissions of a serv= er's >> handshake messages that are protected using the 1-RTT keys, since the >> calculation of the application data keys depends on the contents of >> the handshake messages.=E2=80=9D >> This is a confusing sentence. Since you=E2=80=99re talking about decrypt= ion of >> handshake messages, why do the application data keys matter? >> >> - =E2=80=9CAs shown in Figure 3 and Figure 4, there is never a situation= where >> there are more than two different sets of keying material that might >> be received by a peer.=E2=80=9D >> With reordering, I don=E2=80=99t think this statement is true. We need r= ules using >> packet numbers, such that an old packet with a key phase matching the >> current expected should not cause the connection to blow up. >> >> - Section 4.1.2: I should probably go read about Key Updates in TLS 1.3 >> before trying to understand the details in this section. If so, a pointe= r >> somewhere would be useful. >> >> - Section 4.3: =E2=80=9CThe nonce, N, for the AEAD is formed by combinin= g either >> the Client >> Write IV or Server Write IV with the sequence numbers.=E2=80=9D What=E2= =80=99s the >> Client/Server Write IV? The next couple of paragraphs are quite confusin= g. >> Why is there no Associated Data? QUIC currently uses the unencrypted pac= ket >> header as Associated Data. The QUIC packet does not have frames followin= g >> the packet number=E2=80=A6. it=E2=80=99s not clear what it means for P t= o be the =E2=80=9CQUIC frame >> following the packet number=E2=80=9D? >> >> - I=E2=80=99m surprised to see a TLS sequence number, given that QUIC ha= s one (and >> currently uses just that.) It seems like this may be for Key Updates lat= er >> in the connection. I=E2=80=99d like to understand this better. In partic= ular, it=E2=80=99s >> not clear to me why reusing sequence numbers is better than not. I=E2=80= =99m also >> curious to understand how important Key Update is, given that 0-RTT >> connection establishment nearly eliminates the cost of re-establishing a >> QUIC connection. >> >> >> - Section 5: =E2=80=9CImplementations MUST NOT exchange data on any stre= am other >> than >> stream 1 prior to the completion of the TLS handshake.=E2=80=9D This = does not >> work, since 0-RTT data is sent on other streams before handshake complet= ion. >> >> - Section 5.1.2: I would like an explicit requirement on ACKs to be >> encrypted at the same level or higher as the packet that the ACK >> acknowledges. Is that adequate for this section? > > > I think that's what this section says, but it could be a bit more direct > about it. > >> >> >> - Section 5.1.4: =E2=80=9CNote that >> the client could retransmit its Finished message to the server, so >> the server cannot reject such a message.=E2=80=9D Don=E2=80=99t under= stand this >> sentence. >> >> - =E2=80=9CNever assume that because it isn't in the security considerat= ions >> section it doesn't affect security. Most of this document does.=E2= =80=9D Seems >> unnecessary. Also, seems silly to say that =E2=80=9Cmost=E2=80=9D of thi= s document affects >> security, since =E2=80=9Call=E2=80=9D of it does. >> > > Section 4.1 says: "The KEY_PHASE bit on the public flags is the most > significant bit (0x80)." I would suggest we use the current diversificat= ion > nonce bit.(0x04), as it is otherwise unused in the TLS 1.3 version of QUI= C. > > Section 4.5 goes into Packet Number reconstruction. I don't think it's > necessary to do this here(and there is a small error), though if you want= to > state properties of packet numbers(ie: monotonically increasing on the > sender side) that seems fine if it's helpful to the mapping doc. > > Section 5.1.4 says "The ability to shadow packets means that an attacker > does not need to be on path." I believe the attacker must be on path, > unless I'm misunderstanding something? In regards to starting at a > randomized packet number, that does provide some level of protection, and > seems wise. It also reduces the chances of ossification on the handshake > packets always starting at packet number 1. > > I think "In addition to denying endpoints messages, an attacker to genera= te > packets that cause no state change in a recipient." needs to be reworded, > because I'm rather confused on what it's saying. > > Can you clarify "MUST reject empty TLS handshake records and any record t= hat > is not permitted by the TLS state machine". Should these packets be > ignored, under the assumption they're attack packets? Or should the > handshake fail? > > 5.3 is confusing to me. For example, it says "Due to reordering and loss= , > protected packets might be received by an endpoint before the final > handshake messages are received. If these can be decrypted successfully, > such packets MAY be stored and used once the handshake is complete." I > think this deserves more specificity. In cases when the packets are > encrypted with 1RTT keys, may should be stored for later decryption, but > there's no chance of them being decrypted before the SHLO wasn't received= . > I'm a bit confused about what other cases you are thinking of in the > section? > > 6.4 says "Even if the source IP address remains constant, the port number= is > likely to be different." between TCP and QUIC. In typical cases, the por= t > number is new for every connection anyway, so I'm not sure this is a > relevant concern. I would just remove that sentence. > > 7: clanger, though it looks like dangers, is not the same word :) > > 7.1: I think we need to loosen "A server SHOULD use a HelloRetryRequest i= f > the size of the handshake messages it sends is likely to exceed the size = of > the ClientHello." slightly to "a small multiple of the size of the > ClientHello", or something similar, because multipacket certs are extreme= ly > common. > > From nobody Sat Nov 12 22:07:11 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DA3129585 for ; Sat, 12 Nov 2016 22:07:10 -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 (1024-bit key) header.d=krose.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 JJcjd4fFQIoP for ; Sat, 12 Nov 2016 22:07:07 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 B3C79128874 for ; Sat, 12 Nov 2016 22:07:06 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id n204so64059005qke.2 for ; Sat, 12 Nov 2016 22:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+JSoWXdehGSBqomW6+ExAfAvhY+XKWVN4sqXsKs4wBA=; b=SwPB2rEQNz7oPy19rtwb/jrmXRmUBVyrRNIsY7ueJKwXp6wLCecn9a+Zy/z+rnY3lW qLwsmkhc2lHCnvGiyzOkMezdapFLMaxd2oMDkZf2nqZHdxNkorSs2TcXDGFSMZCoyMgk ED1wPfSZ9RiyEvMTl9DcEm1p6yePK798uo6s4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+JSoWXdehGSBqomW6+ExAfAvhY+XKWVN4sqXsKs4wBA=; b=CX7YuiOSKdzS17uo5rdJxxbZvA5SEz9UXo7c5KRcvKO7sBLJSVH5npJNL1hdpL7YHZ Vi8w+KAsWZA5clS9Q/zAUUptHqBeIIKIuOjug5KguiwlbDH/FdTrWmXrYl5uw1YIbbk2 4cGg/vgoUBCPquNu8kTp/XM5PfLr/7oDgOHShTGkzKCHcD2imbSVKVnbsmULV3J/Q01l FBh3k19URcZWQ2RW5HpDXKB6PA/8DyjCtsYkr09nel+uJIwb2a6xdB9cXx9J0H/O4L4F FWnXUs0DTKeoASPX9FZEWkXc/yh19xNE6c3EWb7U0fVD+gxXqwNFHBVu/IpDgLQs5p6q 9Fyg== X-Gm-Message-State: ABUngvfYqXMtY4EmEQIQPqOYbZPjuu404aX9E+p/TswnGhq2oivAwn2TQyJ5sZPl64Zq63n4nAlE2oeQBAQZoA== X-Received: by 10.55.25.78 with SMTP id k75mr10632881qkh.247.1479017225856; Sat, 12 Nov 2016 22:07:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.180.2 with HTTP; Sat, 12 Nov 2016 22:07:04 -0800 (PST) X-Originating-IP: [2001:67c:370:144:5067:bb50:1e73:948c] In-Reply-To: References: From: Kyle Rose Date: Sun, 13 Nov 2016 15:07:04 +0900 Message-ID: To: Ian Swett Content-Type: multipart/alternative; boundary=001a114739485d2dd90541288861 Archived-At: Cc: quic@ietf.org, Martin Thomson Subject: Re: [QUIC] Packet number recovery X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 13 Nov 2016 06:07:10 -0000 --001a114739485d2dd90541288861 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 10, 2016 at 7:44 PM, Ian Swett wrote: > The TCP draft(https://tools.ietf.org/html/rfc5681) defines flight size, > which is typically known as inflight or inflight in my experience, but I > realize QUIC should have it's own definition, since there's no cumulative > acknowledgement point. > > FLIGHT SIZE: The amount of data that has been sent but not yet > cumulatively acknowledged. > > I'll propose: The amount of data that has been sent but not yet > acknowledged or declared lost. > Is "amount of data" the right way to phrase this? To avoid ambiguity in reconstructing the (full) packet number, isn't the limit around the range of packet numbers that have been unacked? Given that a packet can be arbitrarily delayed, there's no way to guarantee that a failed trial decryption based on the wrong reconstructed (full) packet number won't ever happen; but with the right property around the sender's behavior, I think you can limit a packet to a single decryption, at which point it's either accepted or obsolete. The desired property seems to be that the sender and receiver will not disagree on which (full) packet number a partial* packet number represents when the corresponding packet would not have already have been considered lost. (*truncated? windowed? I'd like a term to make this more precise so algorithms making use of either full or partial packet numbers are unambiguous.) Given the following: n = packet_number_size M = largest (full) packet number sent L = largest acked (full) packet number from most recently-received ACK frame O = receiver's largest-observed (full) packet number R = half-size of reordering window (i.e., at any time, receiver will accept packets with (full) packet number in interval (O-R, O+R)) Then: Sender knows that L <= O <= M => Sender can choose a (full) packet number in interval [M+1, L+R) and know that (if received timely) the receiver will be accept it: O will eventually advance to at most L+R-1, at which point (full) packet numbers in the interval (L-1, L+2R-1) will be accepted, which includes all of [M+1, L+R) => Max number of packets that can be safely sent until L advances is L+R-(M+1) <= M+R-M-1 < R If we set 2R = 2^{n-1}, then: * When O = L < M+1, the reordering window is (L-2^{n-2}, L+2^{n-2}) * When O = L+R-1, this window is (L-1, L+2^{n-1}-1) * The union of these intervals is (L-2^{n-2}, L+2^{n-1}-1) The size of this union is 2^{n-1}+2^{n-2}-1 < 2^n, so (full) packet numbers can be unambiguously reconstructed from partial packet numbers mod 2^n if they are within a 2^{n-1}-sized reordering window; and if they're not within that window, the corresponding packets would have been thrown away anyway. Assuming I haven't botched something someplace, I conclude two things about this scheme: (1) The number of packets in flight (actually max delta from currently-known last acked) should be < 2^{n-2}. (2) Only one decryption should be necessary, with one exception. This scheme is not robust to jumps in O of R or more, as the receiver would either correctly reconstruct the (full) packet number and throw away the packet as too far in the future (which seems dumb?) or would reconstruct the wrong (full) packet number and also throw away the packet. Some of these cases (e.g., a flood of packets are sent and a few are received wildly out of order) will correct themselves, but others seem unrecoverable. In particular, a byzantine case is one in which a middlebox drops >= 2^n packets: there is no way for the receiver to reconstruct the correct (full) packet number without doing multiple (and potentially unbounded) trial decryptions: is the right number O+2^n? Or O+2*2^n? O+3*2^n? Etc. IMO at some point you have to throw up your hands in these cases, and requiring multiple trial decryptions seems like a good place to draw the line. In the process of going through all of this I began to worry more and more about the sender and receiver getting out of sync on (full) packet number reconstruction in places where the (full) packet number isn't authenticated, such as in ACK frames. Is it possible for the sender to reconstruct the a different largest acked from what the receiver intended, for instance? I don't think so, as the sender would presumably have stopped sending packets if it hadn't received an ACK frame in a long time, but I am starting to think there should be some proof (not necessarily in the draft, just documented somewhere) that both endpoints are speaking in the same subset of the packet number space. Kyle --001a114739485d2dd90541288861 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 10, 2016 at 7:44 PM, Ian Swett <iansw= ett@google.com> wrote:
The TCP draft(https://tools.ietf.org/html/rfc5681)= defines flight size, which is typically known as inflight or inflight in m= y experience, but I realize QUIC should have it's own definition, since= there's no cumulative acknowledgement point. =C2=A0
=C2=A0
FLI= GHT SIZE: The amount of data that has been sent but not yet
=C2=A0 =C2= =A0 =C2=A0 cumulatively acknowledged.

I'll propose: The amount o= f data that has been sent but not yet acknowledged or declared lost.
<= /div>

Is "amount of data" the ri= ght way to phrase this? To avoid ambiguity in reconstructing the (full) pac= ket number, isn't the limit around the range of packet numbers that hav= e been unacked?

Given that a packet can be arbitrarily delayed= , there's no way to guarantee that a failed trial decryption based on t= he wrong reconstructed (full) packet number won't ever happen; but with= the right property around the sender's behavior, I think you can limit= a packet to a single decryption, at which point it's either accepted o= r obsolete. The desired property seems to be that the sender and receiver w= ill not disagree on which (full) packet number a partial* packet number rep= resents when the corresponding packet would not have already have been cons= idered lost.

(*truncated? windowed? I'd like a term to make this= more precise so=20 algorithms making use of either full or partial packet numbers are=20 unambiguous.)

Given the following:<= br>
n =3D packet_number_size
<= div class=3D"gmail_extra">M =3D largest (full) packet number sent
= L =3D largest acked (full) packet number from most recently-received ACK fr= ame
O =3D receiver's largest-observed (full) packet numbe= r
R =3D half-size of reordering window (i.e., at any time, receive= r will accept packets with (full) packet number in interval (O-R, O+R))
=

Then:

Sender knows that L <= =3D O <=3D M
=3D> Sender can choo= se a (full) packet number in interval [M+1, L+R) and know that (if received= timely) the receiver will be accept it: O will eventually advance to at mo= st L+R-1, at which point (full) packet numbers in the interval (L-1, L+2R-1= ) will be accepted, which includes all of [M+1, L+R)
=3D> Max number of packets that can be safely sent until L= advances is L+R-(M+1) <=3D M+R-M-1 < R

If we set 2R =3D 2^{n-1}, then:

=C2=A0* When O =3D L < M+1, the reordering window is (L-2^{n-2},= L+2^{n-2})
=C2=A0* When O =3D L+R-1, t= his window is (L-1, L+2^{n-1}-1)
=C2=A0= * The union of these intervals is (L-2^{n-2}, L+2^{n-1}-1)

The size of this u= nion is 2^{n-1}+2^{n-2}-1 < 2^n, so (full) packet numbers can be unambig= uously reconstructed from partial packet numbers mod 2^n if they are within= a 2^{n-1}-sized reordering window; and if they're not within that wind= ow, the corresponding packets would have been thrown away anyway. Assuming = I haven't botched something someplace, I conclude two things about this= scheme:

(1) The number of packets in flight (actually max delta fro= m currently-known last acked) should be < 2^{n-2}.
(2) Only one decry= ption should be necessary, with one exception.

This scheme is = not robust to jumps in O of R or more, as the receiver would either correct= ly reconstruct the (full) packet number and throw away the packet as too fa= r in the future (which seems dumb?) or would reconstruct the wrong (full) p= acket number and also throw away the packet. Some of these cases (e.g., a f= lood of packets are sent and a few are received wildly out of order) will c= orrect themselves, but others seem unrecoverable.

In particular, a b= yzantine case is one in which a middlebox drops >=3D 2^n packets: there = is no way for the receiver to reconstruct the correct (full) packet number = without doing multiple (and potentially unbounded) trial decryptions: is th= e right number O+2^n? Or O+2*2^n? O+3*2^n? Etc.

IMO at some point yo= u have to throw up your hands in these cases, and requiring multiple trial = decryptions seems like a good place to draw the line.

In = the process of going through all of this I began to worry more and more abo= ut the sender and receiver getting out of sync on (full) packet number reco= nstruction in places where the (full) packet number isn't authenticated= , such as in ACK frames. Is it possible for the sender to reconstruct the a= different largest acked from what the receiver intended, for instance? I d= on't think so, as the sender would presumably have stopped sending pack= ets if it hadn't received an ACK frame in a long time, but I am startin= g to think there should be some proof (not necessarily in the draft, just d= ocumented somewhere) that both endpoints are speaking in the same subset of= the packet number space.

Kyle
--001a114739485d2dd90541288861-- From nobody Sat Nov 12 22:13:39 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B19491295C0 for ; Sat, 12 Nov 2016 22:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuPWS1V7Jrnk for ; Sat, 12 Nov 2016 22:13:36 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61FD1294B4 for ; Sat, 12 Nov 2016 22:13:35 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id 137so42868035vkl.0 for ; Sat, 12 Nov 2016 22:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bVJfEuMfdu2SSw9TFE0Hfqxrfn+SlsFMNun+WVgJp8g=; b=Hljt8FJyWSdc2LTMMesZiuBZUUiGub8yy4r+kXBsIt3403BjV2IhonADq6EovtYayZ xoIk1HHIwef1D1iZgmU2c73ZV3tlilXj0u+O+wbVPvgbFI02BB/Vu1SQOXyl54LeK1Uf 42GsA1AGwuxgIuP3ayZu6H+n2zweFtx9639kIeg8exoM3ephR6BJILyGBPeIZ8hSd4XK CgSm/2Xlwo+6SupqotdLAjRniVc/AED0N6ouFS4mXvCKdv6ji6XVae4cobIq6Ink2yzT MOzRVYK/IPDaBTgvCiqwf62QvAA0i9/LWaO5z7BJhzAhS/nfJ4cuGvW/ObHGQDgDJOu3 pgjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bVJfEuMfdu2SSw9TFE0Hfqxrfn+SlsFMNun+WVgJp8g=; b=hZt2cr9eHXSYtzH2n6nsQs2CBNe7+fAV2JCfWFaqOvfJNmQb0jsi4H3oBWTmskWyba HKyYq9Amm4zg5fyAu0JYlojKneTTmdzfszXuQIlsof1rfMtzv958jpdJx73JYFep428I aGQYIw9KNXmznwVttsuvrLIOPyRRwjysw30ZHj8QzaeI2fQmwkU39ca1xh4R7OT/5FLs pa1ngsLickjMY8gjT2/0qLzSoTiOa35FfUGBYEPOhHFE5jRZq9f6rCD4B8CrFUmSe+2h Yl+G543R8PiYOxzEPV72WiDdxk7Mp2Fw2L+yXH1SfVWieP/UWwe/8ezHLvPIyuEctXjH aNEg== X-Gm-Message-State: ABUngvdAcTPWYepZR9XbbD0nExXRc/snCNltoRA0XqZSnJlm2NiYxjaALFlMDAFKN9/OR6XaoeIuHyf8uUx4ryHI X-Received: by 10.31.178.66 with SMTP id b63mr6602958vkf.70.1479017614858; Sat, 12 Nov 2016 22:13:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.82.68 with HTTP; Sat, 12 Nov 2016 22:13:34 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Sat, 12 Nov 2016 22:13:34 -0800 Message-ID: To: Ian Swett Content-Type: multipart/alternative; boundary=001a114392328d1d990541289f98 Archived-At: Cc: quic@ietf.org, Martin Thomson , Ryan Hamilton Subject: Re: [QUIC] Review of draft-thomson-quic-tls-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 13 Nov 2016 06:13:38 -0000 --001a114392328d1d990541289f98 Content-Type: text/plain; charset=UTF-8 > - Fig 1: What is "Envelope"? Is this the QUIC header? If so, some of it is >> currently encrypted, which means encryption cannot be above it. >> > > Now that private flags are gone, there is no encrypted portion of the QUIC > header. That being said, it's likely worth clarifying what envelope is. > Good point -- I forgot that we didn't have private flags anymore. --001a114392328d1d990541289f98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0
- Fig 1: What is &qu= ot;Envelope"? Is this the QUIC header? If so, some of it is currently = encrypted, which means encryption cannot be above it.

Now that private flags are gone, there is= no encrypted portion of the QUIC header. =C2=A0 That being said, it's = likely worth clarifying what envelope is.

Good point -- I forgot that we didn't have priva= te flags anymore.

--001a114392328d1d990541289f98-- From nobody Sun Nov 13 20:33:03 2016 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 C350212961B; Sun, 13 Nov 2016 20:33:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147909798179.10397.8359965777529442796.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 20:33:01 -0800 Archived-At: Cc: quic@ietf.org Subject: [QUIC] QUIC (quic) WG Interim Meeting: 2017-01-24 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-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, 14 Nov 2016 04:33:01 -0000 The QUIC (quic) Working Group will hold a multi-day interim meeting. Session 1: 2017-01-24 09:30 to 17:00 Asia/Tokyo Session 2: 2017-01-25 09:30 to 17:00 Asia/Tokyo Session 3: 2017-01-26 09:30 to 17:00 Asia/Tokyo Meeting Location: Tokyo, JP Agenda: (No agenda submitted) Information about remote participation: To be determined https://github.com/quicwg/wg-materials/blob/master/interim-17-01/arrangements.md From nobody Mon Nov 14 06:03:37 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E155A1296F5 for ; Mon, 14 Nov 2016 06:03:35 -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, NORMAL_HTTP_TO_IP=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 (1024-bit key) header.d=krose.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 GR2JrZ0aANWn for ; Mon, 14 Nov 2016 06:03:32 -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 11BF8129418 for ; Mon, 14 Nov 2016 06:03:32 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id c47so47436480qtc.2 for ; Mon, 14 Nov 2016 06:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=bg4O39bPVoaYGff7IVE8CSC37zmiBc67enYTV3vNNsk=; b=B0O27tDUz4IqqN5YK1w6eezTSzq4ZWSOvF+k8F9OGMa314OQgHJ2LrsjlkOwHAQ4nv yMT2CDOlgGKjRKTetj0W1pB4T0QBh2NuEU6j3frD4mU4UnYo2sZYHmXWl1S8+Lkb3sEL FY90Hb6r2GHh7fJS5bW6JlJ6v7l8v585/56eM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bg4O39bPVoaYGff7IVE8CSC37zmiBc67enYTV3vNNsk=; b=A9FFBW6wWyyh+85AePCDAn8tzsz6eVHjh5WX9YAqDfH67Sz9qdj5QpyJVAoFJWH07i bjE7gJdjP+8+baorV3cxWLnUqqtLh2QUot+8X48bo8/gMXSU2mlkkIqmBwJDenxbakP2 yrqG4ysmXXGFeNFqpJifB6XzcAldy0HUxEi4w71AJVbN5n7ektzY7XaXJKQ1zSH9UmyQ JZV8S/uqHaiM0UCbPbzGxkIjiMEa/GCV8i6WWbe6FkwRWth2yHNtJbvKyLBleixJ/HcP shDV45HGPB9xyqFY9S7NlrqGGYhJZws+OHSMi6JdFu3QrlsjOTYaVqjUgVGXggWSM7VY PvEg== X-Gm-Message-State: ABUngvceFvPs+0Mp/YHrZCUeYYSupbzjLzgcpv7Oap3t19WcJKjk4ePisMdBP1jS3Kwr10CYggMo0s/Npb9MQQ== X-Received: by 10.237.37.60 with SMTP id v57mr11875676qtc.135.1479132210779; Mon, 14 Nov 2016 06:03:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.180.2 with HTTP; Mon, 14 Nov 2016 06:03:30 -0800 (PST) X-Originating-IP: [2001:67c:370:144:8806:9eca:6f2f:8f7b] From: Kyle Rose Date: Mon, 14 Nov 2016 23:03:30 +0900 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114125e0ffedee0541434dd8 Archived-At: Subject: [QUIC] Review of draft-hamilton-quic-transport-protocol-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 14 Nov 2016 14:03:36 -0000 --001a114125e0ffedee0541434dd8 Content-Type: text/plain; charset=UTF-8 In general, the spec is pretty clear and easy to follow. The most confusing bit is that it's not entirely clear from this spec which things are encrypted/authenticated and when. Maybe an additional state diagram detailing encryption/authentication keys at various stages of connection establishment would help. 3.7. I know there will be much discussion of the connection ID as a tracking cookie. I'm willing to bet there's some reduction from public key cryptography to any scheme for sending omega(1) cryptographically-independent identifying tokens (e.g., table indices) based on O(1) shared data, so until PKC is cheap enough, we're probably stuck with either issuing enough connection IDs that we can be assured of a unique ID per packet, or living with some degree of trackability across client address changes. 4.2. Packet number is authenticated but not encrypted? Is there a good reason not to encrypt it to the degree possible? (I.e., with a traffic key derived from the best shared secret we know at any particular point in connection establishment.) The same goes for ACKs. See also: section 11.1. 4.2.1. See the discussion in the "Packet number recovery" thread. Slight addendum: about 10 seconds after hitting "send" on my message, I realized that one of the doom scenarios I posited (K*2^n) couldn't happen given some of the earlier assumptions I made about how the sender must choose packet numbers, i.e. that such large packet numbers couldn't be used without largest acked advancing. 5.1. Is it possible for the mandatory version negotiation response behavior to be an amplification vector for spoofed packets? 5.2.1.3: How is the client to know that it doesn't need a connection ID? What if there's an SNAT close to the server? A synthetic example would be a lab environment that needs to use all public IP space, and so NATs connections from external IPs to a specific gateway IP. 5.2.3: Is it intended for the STK to be folded into the TLS session ticket? I haven't gotten to Martin's draft yet. 5.2.3: "The crypto handshake MUST ensure that the final negotiated key is distinct for every connection between two endpoints.": trivially unachievable if both ends cooperate. Maybe want to say something like "The crypto handshake MUST ensure that the final negotiated key is distinct for every connection between two endpoints if at least one endpoint desires this property." 5.2.3: TLS hasn't had to deal with amplification attacks of this sort because of the TCP 3WHS. I'm not sure compression is enough here, but I also don't know if there's a good universal mitigation to the spoofing problem. 6.2: I would move the "It is recommended for the sender to send the most recent largest acked packet [number]...." out of the normative protocol description. I would also explain why this is the recommended strategy, because it isn't obvious to me why you'd want to do this or why this wouldn't result in spurious retransmits from slightly out-of-order delivery. 6.2: I would mostly eliminate opportunistic ACK attacks by authenticating all ACKs to the degree possible (as suggested above). See also: section 11.1. 6.2: "The two 'LL/MM' bits encode..." A normative mapping from two bits to {1,2,4,6} is required IMO. 6.2: Num Blocks: So, the value is actually number of additional ACK blocks minus 1? 6.2: "...between the largest acked and the first packet whose timestamp is being reported." By "first" you mean "latest"? It seems they must go in reverse order, so I think "first" might be confusing terminology here. 6.2: Is there ever a situation in which it might be valuable not to include packets in the explicit ACK list if they are also included in the timestamp section? If the packets in the timestamp section are sparse, then introducing gaps would make the ACK frame strictly larger, but if every packet appears in both places it could reduce the size of the ACK frame somewhat. I'm willing to concede that this may be an optimization that is more complicated than it is worth. 6.5: Is there a situation in which a BLOCKED frame could inform the recipient that the sender missed a WINDOW_UPDATE frame? This would presumably fix itself eventually via retransmission, anyway. 7: "A sender SHOULD minimize per-packet bandwidth and computational costs by bundling as many frames as possible within a QUIC packet." This directly conflicts with the earlier recommendation "An implementation is therefore advised to bundle as few streams as necessary in outgoing packets without losing transmission efficiency to underfilled packets." Heuristics around frame packing would be helpful here: surely, for streams A and B you never want to send packets A_1||B_1 and A_2||B_2 when you could send A_1||A_2 and B_1||B_2 with the same latency, but whether you want to send A and B in separate packets or as A||B depends on some function of overhead and loss. 7: "...a receiver MUST NOT generate an ACK in response to every packet containing only ACK frames *or padding*". 7: Is the goal of sending an ACK-of-ACKs just to update largest ACKed? 8: One potential problem with QUIC streams as a message abstraction is that the stream ID space is pretty limited at 2^32. 8.1: I think "recv FIN" on the transition from "half closed (remote)" to "closed" and "send FIN" on the transition from "half closed (local)" to "closed" are reversed. Should there also be a transition from "idle" to "closed" for "recv RST"? 8.1.6: Given the requirement to send a RST immediately after receiving an unsolicited RST, should there also be a "remote reset" state whenever "recv RST" occurs first, followed immediately by "send RST" and a transition to "closed"? Or does this just complicate the diagram for no good reason? 8.4: Is triggered delivery prohibited? I.e., is it out-of-spec for a sender to send a series of packets containing the bytes 1-65535 of a message and then trigger instantaneous application delivery of this blob by sending byte 0 in the last packet? Surely this can happen by accident, but doing it intentionally is somewhat different. 9.1.1: Should a RST with a lower offset than highest data offset already seen for a stream result in a connection error? Otherwise, the sender and receiver could have inconsistent views of the flow control state. 9.1.4: "...it is generally considered best to not let the sender go into quiescence if avoidable." Should this be "an active sender"? 11.1: I again feel like there's no reason to allow unauthenticated ACKs when authentication is possible. Nits: (Maybe will be PRs if this ends up in Github) 5.2. "crypto stream": forward reference? 6.1: I would move things like the "Implementation note" out of the normative protocol description into some other section describing recommendations/best practices for optimization. 6.9. "QuicErrorCode": forward reference? Kyle --001a114125e0ffedee0541434dd8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In general, the spec is pretty clear and easy to foll= ow. The most confusing bit is that it's not entirely clear from this sp= ec which things are encrypted/authenticated and when. Maybe an additional s= tate diagram detailing encryption/authentication keys at various stages of = connection establishment would help.


3.7. I know ther= e will be much discussion of the connection ID as a tracking cookie. I'= m willing to bet there's some reduction from public key cryptography to= any scheme for sending omega(1) cryptographically-independent identifying = tokens (e.g., table indices) based on O(1) shared data, so until PKC is che= ap enough, we're probably stuck with either issuing enough connection I= Ds that we can be assured of a unique ID per packet, or living with some de= gree of trackability across client address changes.

4.2. Packet numb= er is authenticated but not encrypted? Is there a good reason not to encryp= t it to the degree possible? (I.e., with a traffic key derived from the bes= t shared secret we know at any particular point in connection establishment= .) The same goes for ACKs. See also: section 11.1.

4.2.1. See the di= scussion in the "Packet number recovery" thread. Slight addendum:= about 10 seconds after hitting "send" on my message, I realized = that one of the doom scenarios I posited (K*2^n) couldn't happen given = some of the earlier assumptions I made about how the sender must choose pac= ket numbers, i.e. that such large packet numbers couldn't be used witho= ut largest acked advancing.

5.1. Is it possible for the mandatory ve= rsion negotiation response behavior to be an amplification vector for spoof= ed packets?

5.2.1.3: How is the clien= t to know that it doesn't need a connection ID? What if there's an = SNAT close to the server? A synthetic example would be a lab environment th= at needs to use all public IP space, and so NATs connections from external = IPs to a specific gateway IP.

5.2.3: Is it intended for the STK to b= e folded into the TLS session ticket? I haven't gotten to Martin's = draft yet.

5.2.3: "The crypto handshake MUST ensure that the fi= nal negotiated key is distinct for every connection between two endpoints.&= quot;: trivially unachievable if both ends cooperate. Maybe want to say som= ething like "The crypto handshake MUST ensure that the final negotiate= d key is distinct for every connection between two endpoints if at least on= e endpoint desires this property."

5.2.3: TLS hasn't had to= deal with amplification attacks of this sort because of the TCP 3WHS. I= 9;m not sure compression is enough here, but I also don't know if there= 's a good universal mitigation to the spoofing problem.

6.2: I w= ould move the "It is recommended for the sender to send the most recen= t largest acked packet [number]...." out of the normative protocol des= cription. I would also explain why this is the recommended strategy, becaus= e it isn't obvious to me why you'd want to do this or why this woul= dn't result in spurious retransmits from slightly out-of-order delivery= .

6.2: I would mostly eliminate opportunistic ACK attacks by authent= icating all ACKs to the degree possible (as suggested above). See also: sec= tion 11.1.

6.2: "The two 'LL/MM' bits encode..." A= normative mapping from two bits to {1,2,4,6} is required IMO.

6.2: = Num Blocks: So, the value is actually number of additional ACK blocks minus= 1?

6.2: "...between the largest acked and the first packet who= se timestamp is being reported." By "first" you mean "l= atest"? It seems they must go in reverse order, so I think "first= " might be confusing terminology here.

6.2: Is there ever a sit= uation in which it might be valuable not to include packets in the explicit= ACK list if they are also included in the timestamp section? If the packet= s in the timestamp section are sparse, then introducing gaps would make the= ACK frame strictly larger, but if every packet appears in both places it c= ould reduce the size of the ACK frame somewhat. I'm willing to concede = that this may be an optimization that is more complicated than it is worth.=

6.5: Is there a situation in which a BLOCKED frame could inform the= recipient that the sender missed a WINDOW_UPDATE frame? This would presuma= bly fix itself eventually via retransmission, anyway.

7: "A sen= der SHOULD minimize per-packet bandwidth and computational costs by bundlin= g as many frames as possible within a QUIC packet." This directly conf= licts with the earlier recommendation "An implementation is therefore = advised to bundle as few streams as necessary in outgoing packets without l= osing transmission efficiency to underfilled packets." Heuristics arou= nd frame packing would be helpful here: surely, for streams A and B you nev= er want to send packets A_1||B_1 and A_2||B_2 when you could send A_1||A_2 = and B_1||B_2 with the same latency, but whether you want to send A and B in= separate packets or as A||B depends on some function of overhead and loss.=

7: "...a receiver MUST NOT generate an ACK in response to ever= y packet containing only ACK frames *or padding*".

7: Is the go= al of sending an ACK-of-ACKs just to update largest ACKed?

8: One po= tential problem with QUIC streams as a message abstraction is that the stre= am ID space is pretty limited at 2^32.

8.1: I think "recv FIN&q= uot; on the transition from "half closed (remote)" to "close= d" and "send FIN" on the transition from "half closed (= local)" to "closed" are reversed. Should there also be a tra= nsition from "idle" to "closed" for "recv RST"= ;?

8.1.6: Given the requirement to send a RST immediately after rece= iving an unsolicited RST, should there also be a "remote reset" s= tate whenever "recv RST" occurs first, followed immediately by &q= uot;send RST" and a transition to "closed"? Or does this jus= t complicate the diagram for no good reason?

8.4: Is triggered deliv= ery prohibited? I.e., is it out-of-spec for a sender to send a series of pa= ckets containing the bytes 1-65535 of a message and then trigger instantane= ous application delivery of this blob by sending byte 0 in the last packet?= Surely this can happen by accident, but doing it intentionally is somewhat= different.

9.1.1: Should a RST with a lower offset than highest dat= a offset already seen for a stream result in a connection error? Otherwise,= the sender and receiver could have inconsistent views of the flow control = state.

9.1.4: "...it is generally considered best to not let th= e sender go into quiescence if avoidable." Should this be "an act= ive sender"?

11.1: I again feel like there's no reason to a= llow unauthenticated ACKs when authentication is possible.


Nits:= (Maybe will be PRs if this ends up in Github)

5.2. "crypto str= eam": forward reference?

6.1: I would move things like the &quo= t;Implementation note" out of the normative protocol description into = some other section describing recommendations/best practices for optimizati= on.

6.9. "QuicErrorCode": forward reference?


Kyle
--001a114125e0ffedee0541434dd8-- From nobody Mon Nov 14 12:45:18 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEA0129449 for ; Mon, 14 Nov 2016 12:45:16 -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 rWfr1xg4AIX2 for ; Mon, 14 Nov 2016 12:45:15 -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 C2A18129606 for ; Mon, 14 Nov 2016 12:45:15 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id q124so22788395itd.1 for ; Mon, 14 Nov 2016 12:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=iwQlFWZcUlATdGvWTANc0Gis028io7vh4m3ocEEOKuE=; b=eBXGyUx/CP7nUlYHccrJ4W/ghEPTE1PdvZouYPYbCwVpBjuEi7hrylqHtKRBj92csx uVySiG2bNt9DTRTsTeZ0kJrJi7/6oVCyq5g/oUoSUj0+XsmmmEPjb366PkxP51rPPGPh UShor18d2pyYwVMKLY2NfrH5KEChs43S4sGY5rhD/qzaXxmeTHuZCdgrfFigQAZvd0EQ LXYWYg/6oQsegprtu0wuUCBsf8A+JoCOFG1fzmbhZLpRuuyppZiGEvQU61tlvWtb0L8u GXGRucphXaGvXYpWqNZPVFgdNbIWBUUjuijEtdd95yIaJd0CAV/qDDXRFookgTCmi/4o jpiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iwQlFWZcUlATdGvWTANc0Gis028io7vh4m3ocEEOKuE=; b=CREfmMUi9Aa0dbZsfTLMuDvWmJxSsCmxDiYevYg22LrCAOCBRAmBFYd2MpNAkV2fus h5ROYTD5x20xHIBPrCEk341O9VKKnAaf6Ym5O+IlY9tSPVKT88BSLLw47ZX/XFKf99Gt atqY7o+sRZ0NRcjvz9SmdtjuFj81JO1Ip2QZgMXolGX6h1cFS3X3leoQ9g8CQYGPGbuk olIBloWn+0ZgV3SAyQLt8aHM/k1iJTeJ2qm00dPlOaJIFnJ4DpcYmiqeLJLtMDZj+hy1 xbGxO7jRYfK1ICiP6FNOVTvIulcYBeV+gMSwuMWaMJwsHWLD/lqILdgbjX8giEWXgWoQ TtYw== X-Gm-Message-State: ABUngvdGDq1bZB4x56iUnxmRotbFfYg3rcuXyM3OGcESs4WTK1g44lkjpwFGsNgwf7diEDyn0ksGxu1t7ccCLg== X-Received: by 10.107.165.139 with SMTP id o133mr22111694ioe.42.1479156314937; Mon, 14 Nov 2016 12:45:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.125.138 with HTTP; Mon, 14 Nov 2016 12:45:14 -0800 (PST) From: "Aron ." Date: Mon, 14 Nov 2016 15:45:14 -0500 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a1141f18cb81f8a054148eae8 Archived-At: Subject: [QUIC] Why not be explicit about Stream 3 flow control exception? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 14 Nov 2016 20:45:17 -0000 --001a1141f18cb81f8a054148eae8 Content-Type: text/plain; charset=UTF-8 Hello, [draft-hamilton-quic-transport-protocol-01] states (p. 35): o The crypto handshake stream, Stream 1, MUST NOT be subject to congestion control or connection-level flow control, but MUST be subject to stream-level flow control. o An application MAY exclude specific stream IDs from connection-level flow control. If so, these streams MUST NOT be subject to connection-level flow control. The second bullet point is obviously about Stream 3. Seeing that there is no way(?) to negotiate which streams are to be excluded, why not spell out that Streams 1 and 3 are not subject to connection-level congestion control? Aron. --001a1141f18cb81f8a054148eae8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

[draft-hamilton-quic-= transport-protocol-01] states (p. 35):

o The crypt= o handshake stream, Stream 1, MUST NOT be subject to
congestion control = or connection-level flow control, but MUST be
subject to stream-level fl= ow control.
o An application MAY exclude specific stream IDs from connec= tion-level
flow control. If so, these streams MUST NOT be subject to
= connection-level flow control.

The second bullet p= oint is obviously about Stream 3.=C2=A0 Seeing that there is no way(?) to n= egotiate which streams are to be excluded, why not spell out that Streams 1= and 3 are not subject to connection-level congestion control?
=C2=A0 Aron.
--001a1141f18cb81f8a054148eae8-- From nobody Mon Nov 14 13:29:23 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7791295AF for ; Mon, 14 Nov 2016 13:29:21 -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 0MSNPwGNI4ja for ; Mon, 14 Nov 2016 13:29:20 -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 450F912957F for ; Mon, 14 Nov 2016 13:29:19 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id a10so78768579ywa.3 for ; Mon, 14 Nov 2016 13:29:19 -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=y1JMGENYoiU0crr0nP2IMM1+pgcUd3lVYMV6i43YO1Q=; b=pJCkf0XpzfRptFHmDbs+dGLmh+m5XGT/RueiMq/EqaFkAmEn635PrdM3Pw4l4zGW5x 2mu8JkGXRQrfumRIsn8Vyn5cKzVJ+XMpj88Uvwyc9d4pLQYzvYuL/zFuwNyPwf9FB6xZ 5s05SaCeKrLa6itLVslIeiovUcKs6WwmjBHex2yq1DqP5Rkn+e/htnbe9m49B0ZRfx/9 DlAWCo8Oaz28XxmpUq2Il0+hhsDsiuA3+msi2VwbdtKHREsBEurhKfmQ4TGxs8Ae3b3Y dywIpS1jWshgIN7eGSLQbVLyfoc2OlJTZ2B7kG33meigN+AJw5yxoJgdqaS5ERwhBIHu HOXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=y1JMGENYoiU0crr0nP2IMM1+pgcUd3lVYMV6i43YO1Q=; b=jeExhqZWfQJAWB24mb7yMks9ORCqrmLtCj6yg4WnYjbmpiV5TM72QfqnJVjhaDSoPB ltjuSzwZ0vO2ekGvYDHlK/DAiSDIMOEGEU18t76SdE6ZvvPutQ6avWRe3kbOv5EPL0V4 scGoF8rxekQfh9+w3pG2xAm20/oxWGmJLbYCZQwXv89TnDrfJpyFC/aH0/HWAhDBm9kH HYZ5fXfKQfiEcU9ZXFhMQ0CvxI8t4d7opQZ2OtoZrDftLp9Utwq5mhw+vZ51+8zxAA2x FqmMAvY9i36UL3kmx51UUSQe6KCwe2eF+mEMXf8qid6Z7pp+yBokbmiGm1lJaRM4jCrc iaIA== X-Gm-Message-State: ABUngvd1YL9DREQiufWOt0iovXVwciqBkxVaGacLz+UeFz8zwaZdW482eVPsNGvoY0IVdfqPqu2DqIxbtScf9Q== X-Received: by 10.129.125.215 with SMTP id y206mr15818097ywc.234.1479158958255; Mon, 14 Nov 2016 13:29:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 14 Nov 2016 13:28:37 -0800 (PST) From: Eric Rescorla Date: Tue, 15 Nov 2016 06:28:37 +0900 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a11492dfa461ce8054149888c Archived-At: Subject: [QUIC] Comments on draft-thomson-quic-tls- X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 14 Nov 2016 21:29:21 -0000 --001a11492dfa461ce8054149888c Content-Type: text/plain; charset=UTF-8 Thanks for doing this document. I think it's looking pretty good. You and I talked offline about changing the key update pattern a bit, so I omit those comments here. I notice that this document does not cover stateless reject (and draft-hamilton is a bit vague too). That seems like something that wouldbe good to address. SUBSTANTIVE S 4.4. It's kind of gross to tie key updates to ACKs as you do here. As I understand it, if you make the changes we discussed F2F to the key update schedule, you can remove this restriction. S 5.1.3. I would suggest just never sending ACKs with 0-RTT keys. That would make life a lot simpler. One point that you may need to address here is what key the server uses for acks of CH. Consider the case where the CH is one packet but SH..SFin are several. The keys you need to decrypt the ACKs cannot be computed until you have SFIN. I think the right answer may be to actually make a stricter requirement than the one you do: - ACKs for unprotected data other than ACKs, which IIRC are ACKed are unprotected - ACKs for protected data are protected. EDITORIAL I don't think the reductions of HKDF-Expand to HMAC in 4.2.2 are helpful. People should just call HKDF-Expand. It's not like they don't have a TLS stack. --001a11492dfa461ce8054149888c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for doing this document. I think it's look= ing pretty good.

You and I talked offline about ch= anging the key update pattern a bit,
so I omit those comments her= e.

I notice that this document does not cover stat= eless reject (and
draft-hamilton is a bit vague too). That seems = like something that
wouldbe good to address.

=

SUBSTANTIVE
S 4.4.
It's kind of= gross to tie key updates to ACKs as you do here. As I
understand= it, if you make the changes we discussed F2F to the
key update s= chedule, you can remove this restriction.

S 5.1.3.=
I would suggest just never sending ACKs with 0-RTT keys. That wo= uld
make life a lot simpler.

One point t= hat you may need to address here is what key the server
uses for = acks of CH. Consider the case where the CH is one packet
but SH..= SFin are several. The keys you need to decrypt the ACKs
cannot be= computed until you have SFIN. I think the right answer
may be to= actually make a stricter requirement than the one you do:

- ACKs for unprotected data other than ACKs, which IIRC are ACKed<= /div>
=C2=A0 are unprotected
- ACKs for protected data are pr= otected.



EDITORIAL
I don't think the reductions of HKDF-Expand to HMAC in 4.2.2 a= re helpful.
People should just call HKDF-Expand. It's not lik= e they don't have
a TLS stack.


<= /div>
--001a11492dfa461ce8054149888c-- From nobody Mon Nov 14 14:05:57 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AD97129602 for ; Mon, 14 Nov 2016 14:05:56 -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 uqxDpVPcqC2R for ; Mon, 14 Nov 2016 14:05:55 -0800 (PST) Received: from mail-yb0-x22e.google.com (mail-yb0-x22e.google.com [IPv6:2607:f8b0:4002:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 004BC12941A for ; Mon, 14 Nov 2016 14:05:55 -0800 (PST) Received: by mail-yb0-x22e.google.com with SMTP id a184so29365287ybb.0 for ; Mon, 14 Nov 2016 14:05:54 -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=ulMtnKvO8n28VJWNzRQ+FcShV8Sbg2kBITQEu0e+ywI=; b=wyC+2kMojVo+0KzfL3tlxbdJjo33yz+75P6o06G4YVg2rxLE0RfPfXIU8dYWNm3HBb ev3yzbYSks4shb3F6pukVmYMOQbp0AlVwnfXneTJnBsVC8ECNjwyy/z569/juS9+GeZ9 mbLWPboddzVe1omxLY+VFWbFM4K8Y0fX6+PkPe+XAYOu/WYdICZD1w4DkLQXfkI40Pw7 urgfI3PfgM+01dKQ12Ht/4iEv3PwgZCbrAHaoJMjcVGff3XHUGMoeCgDi3HWt1JWcOa+ aR6Dd7NA4kcnvxFvt4F4K/3xb4O1XvEMAntaxADkmOJy6pybSYN+1wO9nBLQlNhzEmCX +sxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ulMtnKvO8n28VJWNzRQ+FcShV8Sbg2kBITQEu0e+ywI=; b=kyhF5APJsw/ydz02RKz3+kx50IFNKmy5vokwyC7t4/oBWsWhO6/b4jLeQipp6bKkkH koelGycEDcwkwrON68+qCeG6f4EdmtukJD1DtLEfDAvh6wxThFDHAla87MHi8y+eFsVt ZqXK6JYr4dOj1zgXxAHgaNfLgnpjaYCcovevySOmVbqnzdFHNznklCnUnfXMjlrAkIxj H6oUX3HNDt32r5oWTbeCpSq0iW+Vfna0uGNd6G3u2EvfbjvkkO2BrP1SB0QbH4sC1HVs 2yS38eLCZ9+u95Yik6urW3tCwqLGWrfaSVEGx4WiWseUaW43uh1/DbGygrmJKeK8WmcU bEtQ== X-Gm-Message-State: ABUngvfrrkaIYpiaoLDdg0uIQ05P1DoPvTGXD3BPSaG1DFQjFw0r+XfIQOlOwvnczBmsqmQWgGZPboyk+vzANw== X-Received: by 10.37.171.169 with SMTP id v38mr15898111ybi.80.1479161153493; Mon, 14 Nov 2016 14:05:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 14 Nov 2016 14:05:12 -0800 (PST) From: Eric Rescorla Date: Tue, 15 Nov 2016 07:05:12 +0900 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=94eb2c050f4a1ed01a05414a0b51 Archived-At: Subject: [QUIC] Comments on draft-hamilton-quic-transport X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 14 Nov 2016 22:05:57 -0000 --94eb2c050f4a1ed01a05414a0b51 Content-Type: text/plain; charset=UTF-8 Sorry about the late review. I just got around to writing up my comments. SUSTANTIVE You make a lot of attempts to shave a byte off here or there by variable length encodings. I'm not sure this isn't more trouble than it's worth. S 3.4. QUIC acknowledgments also explicitly encode the delay between the receipt of a packet and its acknowledgment being sent, This seems like it might make offload boxes harder to build. S 3.7. I'm not sure I'm convinced by this story about the conn-id and NAT rebinding. The issue is that the lifetime of the incoming NAT pinhole and the NAT address binding are basically the same. To take HTTP as a use case, as I understand it there are three common traffic patterns. - The client is making requests and getting responses - The client has made a bunch of requests and is downloading a big pile of data. - The client is just waiting for a server to send something (long poll, websockets) for things like incoming VoIP calls. In the first two cases, the NAT won't rebind because there is traffic flowing. In the third the connection is idle, so the NAT rebinds, but the server speaks first (to send the message), so the conn-id doesn't help. In order to keep the NAT pinhole alive, the client needs to send keepalives, but then the NAT doesn't rebind the conn-id isn't needed for the server to match the new connection because the binding persists. I think there are probably edge cases where the client does keepalives but is wrong about the binding lifetime and this helps, but those just seem like edge cases. Given that the conn-id has privacy implications this seems like it needs serious consideration. This is just a placeholder that I, like others, think we need to revisit conn-id. S 4.1. I know we're considering changing conn id but if you're going to say "random", I believe "cryptographically random" is the requirement S 4.4. This section is pretty incomplete: what is the threat model that public reset is supposed to fit into? How is RNON computed? What's a "tag-value map"? It's never defined. Are you still using this? S 5.2. This version negotiation scheme seems fine in itself, but I think you also need to specify some kind of options handshake. Experience tends to show that just revving the version number every time you want to change features doesn't work well. When the client receives a Version Negotiation packet from the server, it should select an acceptable protocol version. If such a version is found, the client MUST resend all packets using the new version, and the resent packets MUST use new packet numbers. These packets MUST continue to have the VERSION flag set and MUST include the new negotiated protocol version. This text isn't going to work. Say, for instance that QUIC version n+1 has a totally different HTTP binding, you would need to send new packets. The idea here, I think, is 'this is a re-start' but the semantics of that are a lot more complicated than that's here. S 5.2.1.1. QUIC encodes the transport parameters and options as tag-value pairs, all as 7-bit ASCII strings. QUIC parameter tags are listed below. As noted, you don't define this, and it doesn't in fact seem like the values here are 7-bit ASCII strings. I believe that certificate compression is a good idea, and TLS has a weaker version of this (cached-info). However, I also know that the version in fielded QUIC is pretty Google-specific so I think this SHOULD needs to be more of a "should consider" until we demonstrate that a good general version is possible. S 6.1. It's sorta gross to have a FIN bit which is wased on every packet but only used very occasionally (at the end of the stream). I wonder if it would be better to just require that once FIN has been sent on a stream, any mention of that stream in a packet also come with some sort of FIN-frame. Then you don't have any per-packet overhead during the lifetime of the stream. If designed properly, it would also have the property that you could *pre-advertise* FIN like HTTP content length. S 6.2. This document really should include guidance about how to generate ACKs well, not just point that to loss recovery. I'm unpersuaded by this ACK-skipping defense. It seems like it's going to chew up ACK bandwidth for not too much value, and so senders won't do it. I would instead suggest that the ACK block just include a signature of all the packets being ACKed (which both sides need to know anyway). This can be something fast and order-dependent like XOR and then the receiver of the ACK can validate it and terminate the entire connection if it detects shenanigans. S 6.5. Please give some guidance on "BLOCKED" as written, it seems like if stream X is blocked but the app is still writing to send BLOCKED frames up to the overall connection window. That's not what we want, right? S 6.7. Rather than have a padding frame, I would suggest adopting a TLS 1.3-style padding scheme at the encryption layer. S 9.1.1. To avoid this de-synchronization, a RST_STREAM sender MUST include the final byte offset sent on the stream in the RST_STREAM frame. On receiving a RST_STREAM frame, a receiver definitively knows how many bytes were sent on that stream before the RST_STREAM frame, and the receiver MUST use the final offset to account for all bytes sent on the stream in its connection level flow controller. I find this text hard to read wrt to which direction. Is this about the last byte sent by the RST_STREAM sender or the last byte received by the sender before he sent the RST_STREAM. EDITORIAL There are a lot of places in this document where I had questions that were answered later. Some restructuring might help. At the risk of self-citing, I would suggest an RFC4101-style overview at the beginning. If the editors are willing to accept a PR, I would be willing to provide this. Please do whatever you need to do to make section numbers work. It's a pain to read a document where every xref is "Section XXX". S 3.7. you never define "rebound client". S 6.2. I get the rationale for this backward-delta scheme, but as written it's pretty hard to understand. I know this is kind of a vague comment; once this is up on Github, I will attempt to provide some text. S 6.4. Please say here that you can't retract window advertisements, not just later. S 7. All application data sent in STREAM frames MUST be retransmitted, with one exception. When an endpoint sends a RST_STREAM frame, data outstanding on that stream SHOULD NOT be retransmitted, since subsequent data on this stream is expected to not be delivered by the receiver. This applies to both directions, right. I.e., "when an endpoint has sent or received an RST_STREAM frame" S 8. This is an example of text that would improve the document by being earlier so people have the overview. S 9. receiver advertises the maximum absolute byte offset in the stream or "absolute byte offset" is weird. Maybe "abolute byte position"? --94eb2c050f4a1ed01a05414a0b51 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry about the late review. I just got around to wri= ting up my comments.

SUSTANTIVE
You make= a lot of attempts to shave a byte off here or there by variable
= length encodings. I'm not sure this isn't more trouble than it'= s worth.

S 3.4.
=C2=A0 =C2=A0QUIC acknow= ledgments also explicitly encode the delay
=C2=A0 =C2=A0between t= he receipt of a packet and its acknowledgment being sent,

This seems like it might make offload boxes harder to build.
<= div>
S 3.7.
I'm not sure I'm convinced by t= his story about the conn-id and
NAT rebinding. The issue is that = the lifetime of the incoming
NAT pinhole and the NAT address bind= ing are basically the same.

To take HTTP as a use = case, as I understand it there are three common
traffic patterns.=

- The client is making requests and getting respo= nses=C2=A0
- The client has made a bunch of requests and is downl= oading
=C2=A0 a big pile of data.
- The client is just = waiting for a server to send something
=C2=A0 (long poll, websock= ets) for things like incoming VoIP calls.

In the f= irst two cases, the NAT won't rebind because there is traffic
flowing. In the third the connection is idle, so the NAT rebinds, but
the server speaks first (to send the message), so the conn-id doesn&#= 39;t
help. In order to keep the NAT pinhole alive, the client nee= ds to send
keepalives, but then the NAT doesn't rebind the co= nn-id isn't needed
for the server to match the new connection= because the binding
persists.=C2=A0

I t= hink there are probably edge cases where the client does keepalives
but is wrong about the binding lifetime and this helps, but those just
seem like edge cases. Given that the conn-id has privacy implicati= ons
this seems like it needs serious consideration.
This is just a placeholder that I, like others, think we need t= o
revisit conn-id.


S 4.1.=
I know we're considering changing conn id but if you're = going to say
"random", I believe "cryptographicall= y random" is the requirement


<= br>
S 4.4.
This section is pretty incomplete: what is t= he threat model that
public reset is supposed to fit into? How is= RNON computed?=C2=A0 What's a
"tag-value map"? It&= #39;s never defined. Are you still using this?

S 5.2.
This version negotiation scheme seems fine in = itself, but I think
you also need to specify some kind of options= handshake. Experience
tends to show that just revving the versio= n number every time you
want to change features doesn't work = well.

=C2=A0 =C2=A0When the client receives a Vers= ion Negotiation packet from the
=C2=A0 =C2=A0server, it should se= lect an acceptable protocol version.=C2=A0 If such a
=C2=A0 =C2= =A0version is found, the client MUST resend all packets using the new
=
=C2=A0 =C2=A0version, and the resent packets MUST use new packet numbe= rs.=C2=A0 These
=C2=A0 =C2=A0packets MUST continue to have the VE= RSION flag set and MUST include
=C2=A0 =C2=A0the new negotiated p= rotocol version.

This text isn't going to work= . Say, for instance that QUIC version
n+1 has a totally different= HTTP binding, you would need to send
new packets. The idea here,= I think, is 'this is a re-start' but
the semantics of th= at are a lot more complicated than that's here.



S 5.2.1.1.

=C2=A0 = =C2=A0 QUIC encodes the transport parameters and options as tag-value pairs= ,
=C2=A0 =C2=A0 all as 7-bit ASCII strings.=C2=A0 QUIC parameter = tags are listed below.=C2=A0

As noted, you don'= ;t define this, and it doesn't in fact seem like the
values h= ere are 7-bit ASCII strings.

I believe that certif= icate compression is a good idea, and TLS has
a weaker version of= this (cached-info). However, I also know that the
version in fie= lded QUIC is pretty Google-specific so I think this
SHOULD needs = to be more of a "should consider" until we demonstrate that
=
a good general version is possible.


S 6.1.
It's sorta gross to have a FIN bit which is wase= d on every packet
but only used very occasionally (at the end of = the stream).
I wonder if it would be better to just require that = once FIN has been
sent on a stream, any mention of that stream in= a packet also come
with some sort of FIN-frame. Then you don'= ;t have any per-packet overhead
during the lifetime of the stream= . If designed properly, it would
also have the property that you = could *pre-advertise* FIN like
HTTP content length.

S 6.2.
This document really should inc= lude guidance about how to generate ACKs
well, not just point tha= t to loss recovery.

I'm unpersuaded by this AC= K-skipping defense. It seems like it's going
to chew up ACK b= andwidth for not too much value, and so senders won't
do it. = I would instead suggest that the ACK block just include a signature
of all the packets being ACKed (which both sides need to know anyway).
This can be something fast and order-dependent like XOR and then
the receiver of the ACK can validate it and terminate the entire c= onnection
if it detects shenanigans.

S 6= .5.
Please give some guidance on "BLOCKED" as written, = it seems like if stream
X is blocked but the app is still writing= to send BLOCKED frames up to the
overall connection window. That= 's not what we want, right?

S 6.7.
R= ather than have a padding frame, I would suggest adopting a TLS 1.3-style
padding scheme at the encryption layer.

S= 9.1.1.
=C2=A0 =C2=A0To avoid this de-synchronization, a RST_STRE= AM sender MUST include
=C2=A0 =C2=A0the final byte offset sent on= the stream in the RST_STREAM frame.=C2=A0 On
=C2=A0 =C2=A0receiv= ing a RST_STREAM frame, a receiver definitively knows how many
= =C2=A0 =C2=A0bytes were sent on that stream before the RST_STREAM frame, an= d the
=C2=A0 =C2=A0receiver MUST use the final offset to account = for all bytes sent on
=C2=A0 =C2=A0the stream in its connection l= evel flow controller.

I find this text hard to rea= d wrt to which direction. Is this about
the last byte sent by the= RST_STREAM sender or the last byte received
by the sender before= he sent the RST_STREAM.


EDITORIAL<= /div>
There are a lot of places in this document where I had questions<= /div>
that were answered later. Some restructuring might help. At the r= isk
of self-citing, I would suggest an RFC4101-style overview at = the beginning.
If the editors are willing to accept a PR, I would= be willing to provide this.

Please do whatever yo= u need to do to make section numbers work. It's
a pain to rea= d a document where every xref is "Section XXX".

S 3.7.
you never define "rebound client".
=

S 6.2.
I get the rationale for this backward-= delta scheme, but as written
it's pretty hard to understand. = I know this is kind of a vague
comment; once this is up on Github= , I will attempt to provide some
text.

S= 6.4.
Please say here that you can't retract window advertise= ments, not just
later.

S =C2=A07.
<= div>=C2=A0 =C2=A0 =C2=A0 All application data sent in STREAM frames MUST be= retransmitted,
=C2=A0 =C2=A0 =C2=A0 with one exception.=C2=A0 Wh= en an endpoint sends a RST_STREAM frame,
=C2=A0 =C2=A0 =C2=A0 dat= a outstanding on that stream SHOULD NOT be retransmitted, since
= =C2=A0 =C2=A0 =C2=A0 subsequent data on this stream is expected to not be d= elivered by
=C2=A0 =C2=A0 =C2=A0 the receiver.

This applies to both directions, right. I.e., "when an endpoint= has sent
or received an RST_STREAM frame"

S 8.
This is an example of text that would improve the do= cument by being
earlier so people have the overview.
S 9.
=C2=A0 =C2=A0 =C2=A0 receiver advertises the ma= ximum absolute byte offset in the stream or

"= absolute byte offset" is weird. Maybe "abolute byte position"= ;?


--94eb2c050f4a1ed01a05414a0b51-- From nobody Mon Nov 14 14:29:39 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D27129417 for ; Mon, 14 Nov 2016 14:29:37 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDg972hEyC3T for ; Mon, 14 Nov 2016 14:29:30 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0129.outbound.protection.outlook.com [104.47.42.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11AD1129602 for ; Mon, 14 Nov 2016 14:29: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=us7bINHwgQYmXU2REAAjP/JFTIn9zaIy58MemJOBJ28=; b=YSxW7wAfnMSlZ0Y/1fzEO9mqNsazm8tFmomyqXwbC8Yr5aIzB6Gsbyzm6Q7z+ogCckev7OxhRI9yiflihHtPuI7tIX7IF5mrJz7dOE8UWa0tTsfUzJ+Wx6ZGGAX80WkHhK22IVnRUj1EnYWFo7mv2A3lXYKwfcfr99+WjGpPxTA= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Mon, 14 Nov 2016 22:29:27 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0707.015; Mon, 14 Nov 2016 22:29:27 +0000 From: Mike Bishop To: Eric Rescorla , "quic@ietf.org" Thread-Topic: [QUIC] Comments on draft-hamilton-quic-transport Thread-Index: AQHSPsNKYmaFK3SWOUGge8UW1hyrZaDZDu1w Date: Mon, 14 Nov 2016 22:29:27 +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=Michael.Bishop@microsoft.com; x-originating-ip: [31.133.144.196] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:LInV9h5Lcd2GoS+p6RknhuEZ6OQMdgWbcDQnHSyQFNz5AmNYa3i+9ajZLu8Df6JH9E3n1XntDeQMzsZZp6RdnNoBiRVu/BKUBjLFOVfjZwLuQH5s7aWLgEtkXKyy9Y9BOjTn481kcCsQvcZ++0JK0fW5JHqQU/NAUWylbj5td3Kt3XlLDVX/RRbDgxFx3V4ubityQ/Zuh5eaFMq1uuUvFm/TaocPUewTXqOkGxMRXnutX7gF96F5rEJwxmHUsv05nJK221uTpzRaNpSLnFmTBrBHTRIJIx6HcBNA/8jWssZ5pBY9bDuqDIAE9E2EQm8fWh7AirkDrr5zo3iJJFTkgRPuB2+8vlnlzYUTSaYv++Cahg1Lk0nPUA1J67uGi//b x-ms-office365-filtering-correlation-id: 74dd31c1-c751-407a-1f58-08d40cddb1e4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6045074)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6061324); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(199003)(54094003)(66066001)(10090500001)(5660300001)(106116001)(105586002)(99286002)(106356001)(81156014)(81166006)(8936002)(7846002)(230783001)(3846002)(2501003)(33656002)(87936001)(10290500002)(9686002)(6116002)(68736007)(8676002)(7736002)(5005710100001)(102836003)(790700001)(2906002)(86612001)(101416001)(8990500004)(97736004)(74316002)(92566002)(5001770100001)(3280700002)(3660700001)(2950100002)(86362001)(76176999)(2900100001)(54356999)(229853002)(122556002)(50986999)(7696004)(189998001)(77096005)(76576001)(107886002)(21314002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708B05B61DA370D238507A387BC0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2016 22:29:27.5683 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Subject: Re: [QUIC] Comments on draft-hamilton-quic-transport X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 14 Nov 2016 22:29:37 -0000 --_000_BN6PR03MB2708B05B61DA370D238507A387BC0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSBhYm91dCB0aGUgcHJpdmFjeSBpbXBsaWNhdGlvbnMuICBIb3dldmVyLCBvbiBvdXIg bm90aWZpY2F0aW9uIGNoYW5uZWwsIHdl4oCZdmUgaGFkIHRvIGltcGxlbWVudCBsb2dpYyB0byBo ZXVyaXN0aWNhbGx5IGRldGVybWluZSB0aGUgbGlmZXRpbWUgb2YgaWRsZSBwb3J0IG1hcHBpbmdz IGFuZCB0aW1lIG91ciBrZWVwLWFsaXZlcyBhcHByb3ByaWF0ZSB0byB0aGUgbmV0d29yay4gIFRo ZSBxdWVzdGlvbiBoZXJlIHNlZW1zIHRvIGJlIHdoYXQgaGFwcGVucyB3aGVuIHRoZSBjbGllbnQg ZGlzY292ZXJzIHRoYXQgdGhlIHBvcnQgaGFzIGJlZW4gc2NhdmVuZ2VkLiAgSSBkb27igJl0IHRo aW5rIGl04oCZcyBhbiBlZGdlIGNhc2UsIGJ1dCBhbiBleHBlY3RlZCBvbmUg4oCTIGF0IGxlYXN0 IHVudGlsIHRoZSBjbGllbnQgY2FuIGRldGVybWluZSB0aGUgYXBwcm9wcmlhdGUga2VlcC1hbGl2 ZSBmcmVxdWVuY3kuDQoNClBlcmhhcHMgd2UganVzdCBtYW5kYXRlIGtlZXAtYWxpdmVzIG9mdGVu IGVub3VnaCB0aGF0IHdlIHRoaW5rIHRoaXMgd2lsbCBuZXZlciBoYXBwZW4sIGJ1dCB0aGF0IGFs c28gaGFzIHBvd2VyIGltcGxpY2F0aW9ucy4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IFR1ZXNkYXks IE5vdmVtYmVyIDE1LCAyMDE2IDc6MDUgQU0NClRvOiBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBb UVVJQ10gQ29tbWVudHMgb24gZHJhZnQtaGFtaWx0b24tcXVpYy10cmFuc3BvcnQNCg0KU29ycnkg YWJvdXQgdGhlIGxhdGUgcmV2aWV3LiBJIGp1c3QgZ290IGFyb3VuZCB0byB3cml0aW5nIHVwIG15 IGNvbW1lbnRzLg0KDQpTVVNUQU5USVZFDQpZb3UgbWFrZSBhIGxvdCBvZiBhdHRlbXB0cyB0byBz aGF2ZSBhIGJ5dGUgb2ZmIGhlcmUgb3IgdGhlcmUgYnkgdmFyaWFibGUNCmxlbmd0aCBlbmNvZGlu Z3MuIEknbSBub3Qgc3VyZSB0aGlzIGlzbid0IG1vcmUgdHJvdWJsZSB0aGFuIGl0J3Mgd29ydGgu DQoNClMgMy40Lg0KICAgUVVJQyBhY2tub3dsZWRnbWVudHMgYWxzbyBleHBsaWNpdGx5IGVuY29k ZSB0aGUgZGVsYXkNCiAgIGJldHdlZW4gdGhlIHJlY2VpcHQgb2YgYSBwYWNrZXQgYW5kIGl0cyBh Y2tub3dsZWRnbWVudCBiZWluZyBzZW50LA0KDQpUaGlzIHNlZW1zIGxpa2UgaXQgbWlnaHQgbWFr ZSBvZmZsb2FkIGJveGVzIGhhcmRlciB0byBidWlsZC4NCg0KUyAzLjcuDQpJJ20gbm90IHN1cmUg SSdtIGNvbnZpbmNlZCBieSB0aGlzIHN0b3J5IGFib3V0IHRoZSBjb25uLWlkIGFuZA0KTkFUIHJl YmluZGluZy4gVGhlIGlzc3VlIGlzIHRoYXQgdGhlIGxpZmV0aW1lIG9mIHRoZSBpbmNvbWluZw0K TkFUIHBpbmhvbGUgYW5kIHRoZSBOQVQgYWRkcmVzcyBiaW5kaW5nIGFyZSBiYXNpY2FsbHkgdGhl IHNhbWUuDQoNClRvIHRha2UgSFRUUCBhcyBhIHVzZSBjYXNlLCBhcyBJIHVuZGVyc3RhbmQgaXQg dGhlcmUgYXJlIHRocmVlIGNvbW1vbg0KdHJhZmZpYyBwYXR0ZXJucy4NCg0KLSBUaGUgY2xpZW50 IGlzIG1ha2luZyByZXF1ZXN0cyBhbmQgZ2V0dGluZyByZXNwb25zZXMNCi0gVGhlIGNsaWVudCBo YXMgbWFkZSBhIGJ1bmNoIG9mIHJlcXVlc3RzIGFuZCBpcyBkb3dubG9hZGluZw0KICBhIGJpZyBw aWxlIG9mIGRhdGEuDQotIFRoZSBjbGllbnQgaXMganVzdCB3YWl0aW5nIGZvciBhIHNlcnZlciB0 byBzZW5kIHNvbWV0aGluZw0KICAobG9uZyBwb2xsLCB3ZWJzb2NrZXRzKSBmb3IgdGhpbmdzIGxp a2UgaW5jb21pbmcgVm9JUCBjYWxscy4NCg0KSW4gdGhlIGZpcnN0IHR3byBjYXNlcywgdGhlIE5B VCB3b24ndCByZWJpbmQgYmVjYXVzZSB0aGVyZSBpcyB0cmFmZmljDQpmbG93aW5nLiBJbiB0aGUg dGhpcmQgdGhlIGNvbm5lY3Rpb24gaXMgaWRsZSwgc28gdGhlIE5BVCByZWJpbmRzLCBidXQNCnRo ZSBzZXJ2ZXIgc3BlYWtzIGZpcnN0ICh0byBzZW5kIHRoZSBtZXNzYWdlKSwgc28gdGhlIGNvbm4t aWQgZG9lc24ndA0KaGVscC4gSW4gb3JkZXIgdG8ga2VlcCB0aGUgTkFUIHBpbmhvbGUgYWxpdmUs IHRoZSBjbGllbnQgbmVlZHMgdG8gc2VuZA0Ka2VlcGFsaXZlcywgYnV0IHRoZW4gdGhlIE5BVCBk b2Vzbid0IHJlYmluZCB0aGUgY29ubi1pZCBpc24ndCBuZWVkZWQNCmZvciB0aGUgc2VydmVyIHRv IG1hdGNoIHRoZSBuZXcgY29ubmVjdGlvbiBiZWNhdXNlIHRoZSBiaW5kaW5nDQpwZXJzaXN0cy4N Cg0KSSB0aGluayB0aGVyZSBhcmUgcHJvYmFibHkgZWRnZSBjYXNlcyB3aGVyZSB0aGUgY2xpZW50 IGRvZXMga2VlcGFsaXZlcw0KYnV0IGlzIHdyb25nIGFib3V0IHRoZSBiaW5kaW5nIGxpZmV0aW1l IGFuZCB0aGlzIGhlbHBzLCBidXQgdGhvc2UganVzdA0Kc2VlbSBsaWtlIGVkZ2UgY2FzZXMuIEdp dmVuIHRoYXQgdGhlIGNvbm4taWQgaGFzIHByaXZhY3kgaW1wbGljYXRpb25zDQp0aGlzIHNlZW1z IGxpa2UgaXQgbmVlZHMgc2VyaW91cyBjb25zaWRlcmF0aW9uLg0KDQpUaGlzIGlzIGp1c3QgYSBw bGFjZWhvbGRlciB0aGF0IEksIGxpa2Ugb3RoZXJzLCB0aGluayB3ZSBuZWVkIHRvDQpyZXZpc2l0 IGNvbm4taWQuDQoNCg0KUyA0LjEuDQpJIGtub3cgd2UncmUgY29uc2lkZXJpbmcgY2hhbmdpbmcg Y29ubiBpZCBidXQgaWYgeW91J3JlIGdvaW5nIHRvIHNheQ0KInJhbmRvbSIsIEkgYmVsaWV2ZSAi Y3J5cHRvZ3JhcGhpY2FsbHkgcmFuZG9tIiBpcyB0aGUgcmVxdWlyZW1lbnQNCg0KDQoNClMgNC40 Lg0KVGhpcyBzZWN0aW9uIGlzIHByZXR0eSBpbmNvbXBsZXRlOiB3aGF0IGlzIHRoZSB0aHJlYXQg bW9kZWwgdGhhdA0KcHVibGljIHJlc2V0IGlzIHN1cHBvc2VkIHRvIGZpdCBpbnRvPyBIb3cgaXMg Uk5PTiBjb21wdXRlZD8gIFdoYXQncyBhDQoidGFnLXZhbHVlIG1hcCI/IEl0J3MgbmV2ZXIgZGVm aW5lZC4gQXJlIHlvdSBzdGlsbCB1c2luZyB0aGlzPw0KDQoNClMgNS4yLg0KVGhpcyB2ZXJzaW9u IG5lZ290aWF0aW9uIHNjaGVtZSBzZWVtcyBmaW5lIGluIGl0c2VsZiwgYnV0IEkgdGhpbmsNCnlv dSBhbHNvIG5lZWQgdG8gc3BlY2lmeSBzb21lIGtpbmQgb2Ygb3B0aW9ucyBoYW5kc2hha2UuIEV4 cGVyaWVuY2UNCnRlbmRzIHRvIHNob3cgdGhhdCBqdXN0IHJldnZpbmcgdGhlIHZlcnNpb24gbnVt YmVyIGV2ZXJ5IHRpbWUgeW91DQp3YW50IHRvIGNoYW5nZSBmZWF0dXJlcyBkb2Vzbid0IHdvcmsg d2VsbC4NCg0KICAgV2hlbiB0aGUgY2xpZW50IHJlY2VpdmVzIGEgVmVyc2lvbiBOZWdvdGlhdGlv biBwYWNrZXQgZnJvbSB0aGUNCiAgIHNlcnZlciwgaXQgc2hvdWxkIHNlbGVjdCBhbiBhY2NlcHRh YmxlIHByb3RvY29sIHZlcnNpb24uICBJZiBzdWNoIGENCiAgIHZlcnNpb24gaXMgZm91bmQsIHRo ZSBjbGllbnQgTVVTVCByZXNlbmQgYWxsIHBhY2tldHMgdXNpbmcgdGhlIG5ldw0KICAgdmVyc2lv biwgYW5kIHRoZSByZXNlbnQgcGFja2V0cyBNVVNUIHVzZSBuZXcgcGFja2V0IG51bWJlcnMuICBU aGVzZQ0KICAgcGFja2V0cyBNVVNUIGNvbnRpbnVlIHRvIGhhdmUgdGhlIFZFUlNJT04gZmxhZyBz ZXQgYW5kIE1VU1QgaW5jbHVkZQ0KICAgdGhlIG5ldyBuZWdvdGlhdGVkIHByb3RvY29sIHZlcnNp b24uDQoNClRoaXMgdGV4dCBpc24ndCBnb2luZyB0byB3b3JrLiBTYXksIGZvciBpbnN0YW5jZSB0 aGF0IFFVSUMgdmVyc2lvbg0KbisxIGhhcyBhIHRvdGFsbHkgZGlmZmVyZW50IEhUVFAgYmluZGlu ZywgeW91IHdvdWxkIG5lZWQgdG8gc2VuZA0KbmV3IHBhY2tldHMuIFRoZSBpZGVhIGhlcmUsIEkg dGhpbmssIGlzICd0aGlzIGlzIGEgcmUtc3RhcnQnIGJ1dA0KdGhlIHNlbWFudGljcyBvZiB0aGF0 IGFyZSBhIGxvdCBtb3JlIGNvbXBsaWNhdGVkIHRoYW4gdGhhdCdzIGhlcmUuDQoNCg0KDQpTIDUu Mi4xLjEuDQoNCiAgICBRVUlDIGVuY29kZXMgdGhlIHRyYW5zcG9ydCBwYXJhbWV0ZXJzIGFuZCBv cHRpb25zIGFzIHRhZy12YWx1ZSBwYWlycywNCiAgICBhbGwgYXMgNy1iaXQgQVNDSUkgc3RyaW5n cy4gIFFVSUMgcGFyYW1ldGVyIHRhZ3MgYXJlIGxpc3RlZCBiZWxvdy4NCg0KQXMgbm90ZWQsIHlv dSBkb24ndCBkZWZpbmUgdGhpcywgYW5kIGl0IGRvZXNuJ3QgaW4gZmFjdCBzZWVtIGxpa2UgdGhl DQp2YWx1ZXMgaGVyZSBhcmUgNy1iaXQgQVNDSUkgc3RyaW5ncy4NCg0KSSBiZWxpZXZlIHRoYXQg Y2VydGlmaWNhdGUgY29tcHJlc3Npb24gaXMgYSBnb29kIGlkZWEsIGFuZCBUTFMgaGFzDQphIHdl YWtlciB2ZXJzaW9uIG9mIHRoaXMgKGNhY2hlZC1pbmZvKS4gSG93ZXZlciwgSSBhbHNvIGtub3cg dGhhdCB0aGUNCnZlcnNpb24gaW4gZmllbGRlZCBRVUlDIGlzIHByZXR0eSBHb29nbGUtc3BlY2lm aWMgc28gSSB0aGluayB0aGlzDQpTSE9VTEQgbmVlZHMgdG8gYmUgbW9yZSBvZiBhICJzaG91bGQg Y29uc2lkZXIiIHVudGlsIHdlIGRlbW9uc3RyYXRlIHRoYXQNCmEgZ29vZCBnZW5lcmFsIHZlcnNp b24gaXMgcG9zc2libGUuDQoNCg0KUyA2LjEuDQpJdCdzIHNvcnRhIGdyb3NzIHRvIGhhdmUgYSBG SU4gYml0IHdoaWNoIGlzIHdhc2VkIG9uIGV2ZXJ5IHBhY2tldA0KYnV0IG9ubHkgdXNlZCB2ZXJ5 IG9jY2FzaW9uYWxseSAoYXQgdGhlIGVuZCBvZiB0aGUgc3RyZWFtKS4NCkkgd29uZGVyIGlmIGl0 IHdvdWxkIGJlIGJldHRlciB0byBqdXN0IHJlcXVpcmUgdGhhdCBvbmNlIEZJTiBoYXMgYmVlbg0K c2VudCBvbiBhIHN0cmVhbSwgYW55IG1lbnRpb24gb2YgdGhhdCBzdHJlYW0gaW4gYSBwYWNrZXQg YWxzbyBjb21lDQp3aXRoIHNvbWUgc29ydCBvZiBGSU4tZnJhbWUuIFRoZW4geW91IGRvbid0IGhh dmUgYW55IHBlci1wYWNrZXQgb3ZlcmhlYWQNCmR1cmluZyB0aGUgbGlmZXRpbWUgb2YgdGhlIHN0 cmVhbS4gSWYgZGVzaWduZWQgcHJvcGVybHksIGl0IHdvdWxkDQphbHNvIGhhdmUgdGhlIHByb3Bl cnR5IHRoYXQgeW91IGNvdWxkICpwcmUtYWR2ZXJ0aXNlKiBGSU4gbGlrZQ0KSFRUUCBjb250ZW50 IGxlbmd0aC4NCg0KDQpTIDYuMi4NClRoaXMgZG9jdW1lbnQgcmVhbGx5IHNob3VsZCBpbmNsdWRl IGd1aWRhbmNlIGFib3V0IGhvdyB0byBnZW5lcmF0ZSBBQ0tzDQp3ZWxsLCBub3QganVzdCBwb2lu dCB0aGF0IHRvIGxvc3MgcmVjb3ZlcnkuDQoNCkknbSB1bnBlcnN1YWRlZCBieSB0aGlzIEFDSy1z a2lwcGluZyBkZWZlbnNlLiBJdCBzZWVtcyBsaWtlIGl0J3MgZ29pbmcNCnRvIGNoZXcgdXAgQUNL IGJhbmR3aWR0aCBmb3Igbm90IHRvbyBtdWNoIHZhbHVlLCBhbmQgc28gc2VuZGVycyB3b24ndA0K ZG8gaXQuIEkgd291bGQgaW5zdGVhZCBzdWdnZXN0IHRoYXQgdGhlIEFDSyBibG9jayBqdXN0IGlu Y2x1ZGUgYSBzaWduYXR1cmUNCm9mIGFsbCB0aGUgcGFja2V0cyBiZWluZyBBQ0tlZCAod2hpY2gg Ym90aCBzaWRlcyBuZWVkIHRvIGtub3cgYW55d2F5KS4NClRoaXMgY2FuIGJlIHNvbWV0aGluZyBm YXN0IGFuZCBvcmRlci1kZXBlbmRlbnQgbGlrZSBYT1IgYW5kIHRoZW4NCnRoZSByZWNlaXZlciBv ZiB0aGUgQUNLIGNhbiB2YWxpZGF0ZSBpdCBhbmQgdGVybWluYXRlIHRoZSBlbnRpcmUgY29ubmVj dGlvbg0KaWYgaXQgZGV0ZWN0cyBzaGVuYW5pZ2Fucy4NCg0KUyA2LjUuDQpQbGVhc2UgZ2l2ZSBz b21lIGd1aWRhbmNlIG9uICJCTE9DS0VEIiBhcyB3cml0dGVuLCBpdCBzZWVtcyBsaWtlIGlmIHN0 cmVhbQ0KWCBpcyBibG9ja2VkIGJ1dCB0aGUgYXBwIGlzIHN0aWxsIHdyaXRpbmcgdG8gc2VuZCBC TE9DS0VEIGZyYW1lcyB1cCB0byB0aGUNCm92ZXJhbGwgY29ubmVjdGlvbiB3aW5kb3cuIFRoYXQn cyBub3Qgd2hhdCB3ZSB3YW50LCByaWdodD8NCg0KUyA2LjcuDQpSYXRoZXIgdGhhbiBoYXZlIGEg cGFkZGluZyBmcmFtZSwgSSB3b3VsZCBzdWdnZXN0IGFkb3B0aW5nIGEgVExTIDEuMy1zdHlsZQ0K cGFkZGluZyBzY2hlbWUgYXQgdGhlIGVuY3J5cHRpb24gbGF5ZXIuDQoNClMgOS4xLjEuDQogICBU byBhdm9pZCB0aGlzIGRlLXN5bmNocm9uaXphdGlvbiwgYSBSU1RfU1RSRUFNIHNlbmRlciBNVVNU IGluY2x1ZGUNCiAgIHRoZSBmaW5hbCBieXRlIG9mZnNldCBzZW50IG9uIHRoZSBzdHJlYW0gaW4g dGhlIFJTVF9TVFJFQU0gZnJhbWUuICBPbg0KICAgcmVjZWl2aW5nIGEgUlNUX1NUUkVBTSBmcmFt ZSwgYSByZWNlaXZlciBkZWZpbml0aXZlbHkga25vd3MgaG93IG1hbnkNCiAgIGJ5dGVzIHdlcmUg c2VudCBvbiB0aGF0IHN0cmVhbSBiZWZvcmUgdGhlIFJTVF9TVFJFQU0gZnJhbWUsIGFuZCB0aGUN CiAgIHJlY2VpdmVyIE1VU1QgdXNlIHRoZSBmaW5hbCBvZmZzZXQgdG8gYWNjb3VudCBmb3IgYWxs IGJ5dGVzIHNlbnQgb24NCiAgIHRoZSBzdHJlYW0gaW4gaXRzIGNvbm5lY3Rpb24gbGV2ZWwgZmxv dyBjb250cm9sbGVyLg0KDQpJIGZpbmQgdGhpcyB0ZXh0IGhhcmQgdG8gcmVhZCB3cnQgdG8gd2hp Y2ggZGlyZWN0aW9uLiBJcyB0aGlzIGFib3V0DQp0aGUgbGFzdCBieXRlIHNlbnQgYnkgdGhlIFJT VF9TVFJFQU0gc2VuZGVyIG9yIHRoZSBsYXN0IGJ5dGUgcmVjZWl2ZWQNCmJ5IHRoZSBzZW5kZXIg YmVmb3JlIGhlIHNlbnQgdGhlIFJTVF9TVFJFQU0uDQoNCg0KRURJVE9SSUFMDQpUaGVyZSBhcmUg YSBsb3Qgb2YgcGxhY2VzIGluIHRoaXMgZG9jdW1lbnQgd2hlcmUgSSBoYWQgcXVlc3Rpb25zDQp0 aGF0IHdlcmUgYW5zd2VyZWQgbGF0ZXIuIFNvbWUgcmVzdHJ1Y3R1cmluZyBtaWdodCBoZWxwLiBB dCB0aGUgcmlzaw0Kb2Ygc2VsZi1jaXRpbmcsIEkgd291bGQgc3VnZ2VzdCBhbiBSRkM0MTAxLXN0 eWxlIG92ZXJ2aWV3IGF0IHRoZSBiZWdpbm5pbmcuDQpJZiB0aGUgZWRpdG9ycyBhcmUgd2lsbGlu ZyB0byBhY2NlcHQgYSBQUiwgSSB3b3VsZCBiZSB3aWxsaW5nIHRvIHByb3ZpZGUgdGhpcy4NCg0K UGxlYXNlIGRvIHdoYXRldmVyIHlvdSBuZWVkIHRvIGRvIHRvIG1ha2Ugc2VjdGlvbiBudW1iZXJz IHdvcmsuIEl0J3MNCmEgcGFpbiB0byByZWFkIGEgZG9jdW1lbnQgd2hlcmUgZXZlcnkgeHJlZiBp cyAiU2VjdGlvbiBYWFgiLg0KDQpTIDMuNy4NCnlvdSBuZXZlciBkZWZpbmUgInJlYm91bmQgY2xp ZW50Ii4NCg0KUyA2LjIuDQpJIGdldCB0aGUgcmF0aW9uYWxlIGZvciB0aGlzIGJhY2t3YXJkLWRl bHRhIHNjaGVtZSwgYnV0IGFzIHdyaXR0ZW4NCml0J3MgcHJldHR5IGhhcmQgdG8gdW5kZXJzdGFu ZC4gSSBrbm93IHRoaXMgaXMga2luZCBvZiBhIHZhZ3VlDQpjb21tZW50OyBvbmNlIHRoaXMgaXMg dXAgb24gR2l0aHViLCBJIHdpbGwgYXR0ZW1wdCB0byBwcm92aWRlIHNvbWUNCnRleHQuDQoNClMg Ni40Lg0KUGxlYXNlIHNheSBoZXJlIHRoYXQgeW91IGNhbid0IHJldHJhY3Qgd2luZG93IGFkdmVy dGlzZW1lbnRzLCBub3QganVzdA0KbGF0ZXIuDQoNClMgIDcuDQogICAgICBBbGwgYXBwbGljYXRp b24gZGF0YSBzZW50IGluIFNUUkVBTSBmcmFtZXMgTVVTVCBiZSByZXRyYW5zbWl0dGVkLA0KICAg ICAgd2l0aCBvbmUgZXhjZXB0aW9uLiAgV2hlbiBhbiBlbmRwb2ludCBzZW5kcyBhIFJTVF9TVFJF QU0gZnJhbWUsDQogICAgICBkYXRhIG91dHN0YW5kaW5nIG9uIHRoYXQgc3RyZWFtIFNIT1VMRCBO T1QgYmUgcmV0cmFuc21pdHRlZCwgc2luY2UNCiAgICAgIHN1YnNlcXVlbnQgZGF0YSBvbiB0aGlz IHN0cmVhbSBpcyBleHBlY3RlZCB0byBub3QgYmUgZGVsaXZlcmVkIGJ5DQogICAgICB0aGUgcmVj ZWl2ZXIuDQoNClRoaXMgYXBwbGllcyB0byBib3RoIGRpcmVjdGlvbnMsIHJpZ2h0LiBJLmUuLCAi d2hlbiBhbiBlbmRwb2ludCBoYXMgc2VudA0Kb3IgcmVjZWl2ZWQgYW4gUlNUX1NUUkVBTSBmcmFt ZSINCg0KUyA4Lg0KVGhpcyBpcyBhbiBleGFtcGxlIG9mIHRleHQgdGhhdCB3b3VsZCBpbXByb3Zl IHRoZSBkb2N1bWVudCBieSBiZWluZw0KZWFybGllciBzbyBwZW9wbGUgaGF2ZSB0aGUgb3ZlcnZp ZXcuDQoNClMgOS4NCiAgICAgIHJlY2VpdmVyIGFkdmVydGlzZXMgdGhlIG1heGltdW0gYWJzb2x1 dGUgYnl0ZSBvZmZzZXQgaW4gdGhlIHN0cmVhbSBvcg0KDQoiYWJzb2x1dGUgYnl0ZSBvZmZzZXQi IGlzIHdlaXJkLiBNYXliZSAiYWJvbHV0ZSBieXRlIHBvc2l0aW9uIj8NCg0KDQo= --_000_BN6PR03MB2708B05B61DA370D238507A387BC0BN6PR03MB2708namp_ 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 b3JtYWwiPkkgYWdyZWUgYWJvdXQgdGhlIHByaXZhY3kgaW1wbGljYXRpb25zLiZuYnNwOyBIb3dl dmVyLCBvbiBvdXIgbm90aWZpY2F0aW9uIGNoYW5uZWwsIHdl4oCZdmUgaGFkIHRvIGltcGxlbWVu dCBsb2dpYyB0byBoZXVyaXN0aWNhbGx5IGRldGVybWluZSB0aGUgbGlmZXRpbWUgb2YgaWRsZSBw b3J0IG1hcHBpbmdzIGFuZCB0aW1lIG91ciBrZWVwLWFsaXZlcyBhcHByb3ByaWF0ZSB0byB0aGUg bmV0d29yay4mbmJzcDsgVGhlIHF1ZXN0aW9uDQogaGVyZSBzZWVtcyB0byBiZSB3aGF0IGhhcHBl bnMgPGk+d2hlbjwvaT4gdGhlIGNsaWVudCBkaXNjb3ZlcnMgdGhhdCB0aGUgcG9ydCBoYXMgYmVl biBzY2F2ZW5nZWQuJm5ic3A7IEkgZG9u4oCZdCB0aGluayBpdOKAmXMgYW4gZWRnZSBjYXNlLCBi dXQgYW4gZXhwZWN0ZWQgb25lIOKAkyBhdCBsZWFzdCB1bnRpbCB0aGUgY2xpZW50IGNhbiBkZXRl cm1pbmUgdGhlIGFwcHJvcHJpYXRlIGtlZXAtYWxpdmUgZnJlcXVlbmN5LjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5QZXJoYXBzIHdlIGp1c3QgbWFuZGF0ZSBrZWVwLWFsaXZlcyBvZnRlbiBlbm91 Z2ggdGhhdCB3ZSB0aGluayB0aGlzIHdpbGwgbmV2ZXIgaGFwcGVuLCBidXQgdGhhdCBhbHNvIGhh cyBwb3dlciBpbXBsaWNhdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxvOnA+Jm5ic3A7PC9vOnA+PC9hPjwvcD4NCjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+RXJpYyBSZXNjb3JsYTxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNiA3OjA1IEFNPGJyPg0KPGI+VG86PC9iPiBxdWlj QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtRVUlDXSBDb21tZW50cyBvbiBkcmFmdC1o YW1pbHRvbi1xdWljLXRyYW5zcG9ydDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNvcnJ5IGFib3V0IHRoZSBsYXRlIHJldmlldy4gSSBqdXN0IGdvdCBhcm91bmQgdG8gd3Jp dGluZyB1cCBteSBjb21tZW50cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U1VTVEFOVElWRTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WW91IG1ha2UgYSBsb3Qgb2YgYXR0ZW1wdHMgdG8gc2hh dmUgYSBieXRlIG9mZiBoZXJlIG9yIHRoZXJlIGJ5IHZhcmlhYmxlPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5sZW5ndGggZW5jb2RpbmdzLiBJJ20g bm90IHN1cmUgdGhpcyBpc24ndCBtb3JlIHRyb3VibGUgdGhhbiBpdCdzIHdvcnRoLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TIDMuNC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDtRVUlDIGFja25vd2xlZGdtZW50cyBhbHNvIGV4cGxpY2l0bHkgZW5jb2RlIHRoZSBkZWxh eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwO2JldHdlZW4gdGhlIHJlY2VpcHQgb2YgYSBwYWNrZXQgYW5kIGl0cyBhY2tub3ds ZWRnbWVudCBiZWluZyBzZW50LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGlzIHNlZW1zIGxpa2UgaXQgbWlnaHQgbWFrZSBvZmZsb2FkIGJv eGVzIGhhcmRlciB0byBidWlsZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+UyAzLjcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IHN1cmUgSSdtIGNvbnZpbmNlZCBieSB0aGlzIHN0 b3J5IGFib3V0IHRoZSBjb25uLWlkIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TkFUIHJlYmluZGluZy4gVGhlIGlzc3VlIGlzIHRoYXQgdGhl IGxpZmV0aW1lIG9mIHRoZSBpbmNvbWluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TkFUIHBpbmhvbGUgYW5kIHRoZSBOQVQgYWRkcmVzcyBiaW5k aW5nIGFyZSBiYXNpY2FsbHkgdGhlIHNhbWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIHRha2UgSFRUUCBhcyBhIHVzZSBjYXNlLCBhcyBJ IHVuZGVyc3RhbmQgaXQgdGhlcmUgYXJlIHRocmVlIGNvbW1vbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dHJhZmZpYyBwYXR0ZXJucy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBUaGUgY2xp ZW50IGlzIG1ha2luZyByZXF1ZXN0cyBhbmQgZ2V0dGluZyByZXNwb25zZXMmbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVGhlIGNsaWVu dCBoYXMgbWFkZSBhIGJ1bmNoIG9mIHJlcXVlc3RzIGFuZCBpcyBkb3dubG9hZGluZzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGEgYmln IHBpbGUgb2YgZGF0YS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPi0gVGhlIGNsaWVudCBpcyBqdXN0IHdhaXRpbmcgZm9yIGEgc2VydmVyIHRvIHNl bmQgc29tZXRoaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgKGxvbmcgcG9sbCwgd2Vic29ja2V0cykgZm9yIHRoaW5ncyBsaWtlIGlu Y29taW5nIFZvSVAgY2FsbHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkluIHRoZSBmaXJzdCB0d28gY2FzZXMsIHRoZSBOQVQgd29uJ3QgcmVi aW5kIGJlY2F1c2UgdGhlcmUgaXMgdHJhZmZpYzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Zmxvd2luZy4gSW4gdGhlIHRoaXJkIHRoZSBjb25uZWN0 aW9uIGlzIGlkbGUsIHNvIHRoZSBOQVQgcmViaW5kcywgYnV0PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgc2VydmVyIHNwZWFrcyBmaXJzdCAo dG8gc2VuZCB0aGUgbWVzc2FnZSksIHNvIHRoZSBjb25uLWlkIGRvZXNuJ3Q8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmhlbHAuIEluIG9yZGVyIHRv IGtlZXAgdGhlIE5BVCBwaW5ob2xlIGFsaXZlLCB0aGUgY2xpZW50IG5lZWRzIHRvIHNlbmQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmtlZXBhbGl2 ZXMsIGJ1dCB0aGVuIHRoZSBOQVQgZG9lc24ndCByZWJpbmQgdGhlIGNvbm4taWQgaXNuJ3QgbmVl ZGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5m b3IgdGhlIHNlcnZlciB0byBtYXRjaCB0aGUgbmV3IGNvbm5lY3Rpb24gYmVjYXVzZSB0aGUgYmlu ZGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ cGVyc2lzdHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhlcmUgYXJlIHByb2JhYmx5IGVkZ2UgY2FzZXMgd2hlcmUg dGhlIGNsaWVudCBkb2VzIGtlZXBhbGl2ZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBpcyB3cm9uZyBhYm91dCB0aGUgYmluZGluZyBsaWZl dGltZSBhbmQgdGhpcyBoZWxwcywgYnV0IHRob3NlIGp1c3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNlZW0gbGlrZSBlZGdlIGNhc2VzLiBHaXZl biB0aGF0IHRoZSBjb25uLWlkIGhhcyBwcml2YWN5IGltcGxpY2F0aW9uczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhpcyBzZWVtcyBsaWtlIGl0 IG5lZWRzIHNlcmlvdXMgY29uc2lkZXJhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBqdXN0IGEgcGxhY2Vob2xkZXIgdGhh dCBJLCBsaWtlIG90aGVycywgdGhpbmsgd2UgbmVlZCB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmV2aXNpdCBjb25uLWlkLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlMgNC4xLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBrbm93IHdl J3JlIGNvbnNpZGVyaW5nIGNoYW5naW5nIGNvbm4gaWQgYnV0IGlmIHlvdSdyZSBnb2luZyB0byBz YXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZx dW90O3JhbmRvbSZxdW90OywgSSBiZWxpZXZlICZxdW90O2NyeXB0b2dyYXBoaWNhbGx5IHJhbmRv bSZxdW90OyBpcyB0aGUgcmVxdWlyZW1lbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlMgNC40LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzZWN0aW9uIGlzIHByZXR0eSBpbmNv bXBsZXRlOiB3aGF0IGlzIHRoZSB0aHJlYXQgbW9kZWwgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cHVibGljIHJlc2V0IGlzIHN1cHBvc2Vk IHRvIGZpdCBpbnRvPyBIb3cgaXMgUk5PTiBjb21wdXRlZD8mbmJzcDsgV2hhdCdzIGE8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZxdW90O3RhZy12 YWx1ZSBtYXAmcXVvdDs/IEl0J3MgbmV2ZXIgZGVmaW5lZC4gQXJlIHlvdSBzdGlsbCB1c2luZyB0 aGlzPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlMgNS4yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhpcyB2ZXJzaW9uIG5lZ290aWF0aW9uIHNjaGVtZSBzZWVtcyBmaW5lIGluIGl0c2Vs ZiwgYnV0IEkgdGhpbms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnlvdSBhbHNvIG5lZWQgdG8gc3BlY2lmeSBzb21lIGtpbmQgb2Ygb3B0aW9ucyBo YW5kc2hha2UuIEV4cGVyaWVuY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRlbmRzIHRvIHNob3cgdGhhdCBqdXN0IHJldnZpbmcgdGhlIHZlcnNp b24gbnVtYmVyIGV2ZXJ5IHRpbWUgeW91PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj53YW50IHRvIGNoYW5nZSBmZWF0dXJlcyBkb2Vzbid0IHdvcmsg d2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwO1doZW4gdGhlIGNsaWVudCByZWNlaXZlcyBhIFZlcnNpb24gTmVnb3Rp YXRpb24gcGFja2V0IGZyb20gdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7c2VydmVyLCBpdCBzaG91bGQgc2VsZWN0IGFu IGFjY2VwdGFibGUgcHJvdG9jb2wgdmVyc2lvbi4mbmJzcDsgSWYgc3VjaCBhPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7dmVy c2lvbiBpcyBmb3VuZCwgdGhlIGNsaWVudCBNVVNUIHJlc2VuZCBhbGwgcGFja2V0cyB1c2luZyB0 aGUgbmV3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7dmVyc2lvbiwgYW5kIHRoZSByZXNlbnQgcGFja2V0cyBNVVNUIHVzZSBu ZXcgcGFja2V0IG51bWJlcnMuJm5ic3A7IFRoZXNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7cGFja2V0cyBNVVNUIGNvbnRp bnVlIHRvIGhhdmUgdGhlIFZFUlNJT04gZmxhZyBzZXQgYW5kIE1VU1QgaW5jbHVkZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw O3RoZSBuZXcgbmVnb3RpYXRlZCBwcm90b2NvbCB2ZXJzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHRleHQgaXNuJ3QgZ29pbmcg dG8gd29yay4gU2F5LCBmb3IgaW5zdGFuY2UgdGhhdCBRVUlDIHZlcnNpb248bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm4mIzQzOzEgaGFzIGEgdG90 YWxseSBkaWZmZXJlbnQgSFRUUCBiaW5kaW5nLCB5b3Ugd291bGQgbmVlZCB0byBzZW5kPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5uZXcgcGFja2V0 cy4gVGhlIGlkZWEgaGVyZSwgSSB0aGluaywgaXMgJ3RoaXMgaXMgYSByZS1zdGFydCcgYnV0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgc2Vt YW50aWNzIG9mIHRoYXQgYXJlIGEgbG90IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiB0aGF0J3MgaGVy ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlMgNS4yLjEuMS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBRVUlDIGVuY29kZXMgdGhlIHRyYW5zcG9ydCBwYXJh bWV0ZXJzIGFuZCBvcHRpb25zIGFzIHRhZy12YWx1ZSBwYWlycyw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgYWxsIGFzIDct Yml0IEFTQ0lJIHN0cmluZ3MuJm5ic3A7IFFVSUMgcGFyYW1ldGVyIHRhZ3MgYXJlIGxpc3RlZCBi ZWxvdy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QXMgbm90ZWQsIHlvdSBkb24ndCBkZWZpbmUgdGhpcywgYW5kIGl0IGRvZXNuJ3Qg aW4gZmFjdCBzZWVtIGxpa2UgdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj52YWx1ZXMgaGVyZSBhcmUgNy1iaXQgQVNDSUkgc3RyaW5ncy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBiZWxp ZXZlIHRoYXQgY2VydGlmaWNhdGUgY29tcHJlc3Npb24gaXMgYSBnb29kIGlkZWEsIGFuZCBUTFMg aGFzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5h IHdlYWtlciB2ZXJzaW9uIG9mIHRoaXMgKGNhY2hlZC1pbmZvKS4gSG93ZXZlciwgSSBhbHNvIGtu b3cgdGhhdCB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnZlcnNpb24gaW4gZmllbGRlZCBRVUlDIGlzIHByZXR0eSBHb29nbGUtc3BlY2lmaWMg c28gSSB0aGluayB0aGlzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5TSE9VTEQgbmVlZHMgdG8gYmUgbW9yZSBvZiBhICZxdW90O3Nob3VsZCBjb25z aWRlciZxdW90OyB1bnRpbCB3ZSBkZW1vbnN0cmF0ZSB0aGF0PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIGdvb2QgZ2VuZXJhbCB2ZXJzaW9uIGlz IHBvc3NpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlMgNi4xLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SXQncyBzb3J0YSBncm9zcyB0byBoYXZlIGEgRklOIGJpdCB3aGljaCBpcyB3 YXNlZCBvbiBldmVyeSBwYWNrZXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmJ1dCBvbmx5IHVzZWQgdmVyeSBvY2Nhc2lvbmFsbHkgKGF0IHRoZSBl bmQgb2YgdGhlIHN0cmVhbSkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHdvbmRlciBpZiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8ganVzdCByZXF1 aXJlIHRoYXQgb25jZSBGSU4gaGFzIGJlZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNlbnQgb24gYSBzdHJlYW0sIGFueSBtZW50aW9uIG9mIHRo YXQgc3RyZWFtIGluIGEgcGFja2V0IGFsc28gY29tZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+d2l0aCBzb21lIHNvcnQgb2YgRklOLWZyYW1lLiBU aGVuIHlvdSBkb24ndCBoYXZlIGFueSBwZXItcGFja2V0IG92ZXJoZWFkPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kdXJpbmcgdGhlIGxpZmV0aW1l IG9mIHRoZSBzdHJlYW0uIElmIGRlc2lnbmVkIHByb3Blcmx5LCBpdCB3b3VsZDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YWxzbyBoYXZlIHRoZSBw cm9wZXJ0eSB0aGF0IHlvdSBjb3VsZCAqcHJlLWFkdmVydGlzZSogRklOIGxpa2U8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhUVFAgY29udGVudCBs ZW5ndGguPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UyA2LjIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGlzIGRvY3VtZW50IHJlYWxseSBzaG91bGQgaW5jbHVkZSBndWlkYW5jZSBhYm91 dCBob3cgdG8gZ2VuZXJhdGUgQUNLczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+d2VsbCwgbm90IGp1c3QgcG9pbnQgdGhhdCB0byBsb3NzIHJlY292 ZXJ5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JJ20gdW5wZXJzdWFkZWQgYnkgdGhpcyBBQ0stc2tpcHBpbmcgZGVmZW5zZS4gSXQgc2VlbXMg bGlrZSBpdCdzIGdvaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj50byBjaGV3IHVwIEFDSyBiYW5kd2lkdGggZm9yIG5vdCB0b28gbXVjaCB2YWx1 ZSwgYW5kIHNvIHNlbmRlcnMgd29uJ3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmRvIGl0LiBJIHdvdWxkIGluc3RlYWQgc3VnZ2VzdCB0aGF0IHRo ZSBBQ0sgYmxvY2sganVzdCBpbmNsdWRlIGEgc2lnbmF0dXJlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vZiBhbGwgdGhlIHBhY2tldHMgYmVpbmcg QUNLZWQgKHdoaWNoIGJvdGggc2lkZXMgbmVlZCB0byBrbm93IGFueXdheSkuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGNhbiBiZSBzb21l dGhpbmcgZmFzdCBhbmQgb3JkZXItZGVwZW5kZW50IGxpa2UgWE9SIGFuZCB0aGVuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgcmVjZWl2ZXIg b2YgdGhlIEFDSyBjYW4gdmFsaWRhdGUgaXQgYW5kIHRlcm1pbmF0ZSB0aGUgZW50aXJlIGNvbm5l Y3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PmlmIGl0IGRldGVjdHMgc2hlbmFuaWdhbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlMgNi41LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGxlYXNlIGdpdmUgc29tZSBndWlkYW5jZSBvbiAm cXVvdDtCTE9DS0VEJnF1b3Q7IGFzIHdyaXR0ZW4sIGl0IHNlZW1zIGxpa2UgaWYgc3RyZWFtPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5YIGlzIGJs b2NrZWQgYnV0IHRoZSBhcHAgaXMgc3RpbGwgd3JpdGluZyB0byBzZW5kIEJMT0NLRUQgZnJhbWVz IHVwIHRvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+b3ZlcmFsbCBjb25uZWN0aW9uIHdpbmRvdy4gVGhhdCdzIG5vdCB3aGF0IHdlIHdhbnQs IHJpZ2h0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5TIDYuNy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJhdGhlciB0aGFuIGhhdmUgYSBwYWRkaW5nIGZyYW1lLCBJIHdvdWxkIHN1Z2dlc3Qg YWRvcHRpbmcgYSBUTFMgMS4zLXN0eWxlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5wYWRkaW5nIHNjaGVtZSBhdCB0aGUgZW5jcnlwdGlvbiBsYXll ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UyA5LjEuMS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDtUbyBhdm9pZCB0aGlzIGRlLXN5bmNocm9uaXphdGlvbiwgYSBSU1Rf U1RSRUFNIHNlbmRlciBNVVNUIGluY2x1ZGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0aGUgZmluYWwgYnl0ZSBvZmZzZXQg c2VudCBvbiB0aGUgc3RyZWFtIGluIHRoZSBSU1RfU1RSRUFNIGZyYW1lLiZuYnNwOyBPbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZu YnNwO3JlY2VpdmluZyBhIFJTVF9TVFJFQU0gZnJhbWUsIGEgcmVjZWl2ZXIgZGVmaW5pdGl2ZWx5 IGtub3dzIGhvdyBtYW55PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Ynl0ZXMgd2VyZSBzZW50IG9uIHRoYXQgc3RyZWFtIGJl Zm9yZSB0aGUgUlNUX1NUUkVBTSBmcmFtZSwgYW5kIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO3JlY2VpdmVyIE1VU1Qg dXNlIHRoZSBmaW5hbCBvZmZzZXQgdG8gYWNjb3VudCBmb3IgYWxsIGJ5dGVzIHNlbnQgb248bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDt0aGUgc3RyZWFtIGluIGl0cyBjb25uZWN0aW9uIGxldmVsIGZsb3cgY29udHJvbGxlci48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBm aW5kIHRoaXMgdGV4dCBoYXJkIHRvIHJlYWQgd3J0IHRvIHdoaWNoIGRpcmVjdGlvbi4gSXMgdGhp cyBhYm91dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+dGhlIGxhc3QgYnl0ZSBzZW50IGJ5IHRoZSBSU1RfU1RSRUFNIHNlbmRlciBvciB0aGUgbGFz dCBieXRlIHJlY2VpdmVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5ieSB0aGUgc2VuZGVyIGJlZm9yZSBoZSBzZW50IHRoZSBSU1RfU1RSRUFNLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVE SVRPUklBTDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlcmUgYXJlIGEgbG90IG9mIHBsYWNlcyBpbiB0aGlzIGRvY3VtZW50IHdoZXJlIEkgaGFk IHF1ZXN0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+dGhhdCB3ZXJlIGFuc3dlcmVkIGxhdGVyLiBTb21lIHJlc3RydWN0dXJpbmcgbWlnaHQg aGVscC4gQXQgdGhlIHJpc2s8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPm9mIHNlbGYtY2l0aW5nLCBJIHdvdWxkIHN1Z2dlc3QgYW4gUkZDNDEwMS1z dHlsZSBvdmVydmlldyBhdCB0aGUgYmVnaW5uaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIGVkaXRvcnMgYXJlIHdpbGxpbmcgdG8g YWNjZXB0IGEgUFIsIEkgd291bGQgYmUgd2lsbGluZyB0byBwcm92aWRlIHRoaXMuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBkbyB3 aGF0ZXZlciB5b3UgbmVlZCB0byBkbyB0byBtYWtlIHNlY3Rpb24gbnVtYmVycyB3b3JrLiBJdCdz PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hIHBh aW4gdG8gcmVhZCBhIGRvY3VtZW50IHdoZXJlIGV2ZXJ5IHhyZWYgaXMgJnF1b3Q7U2VjdGlvbiBY WFgmcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlMgMy43LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+eW91IG5ldmVyIGRlZmluZSAmcXVvdDtyZWJvdW5kIGNsaWVudCZxdW90Oy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UyA2LjIu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGdl dCB0aGUgcmF0aW9uYWxlIGZvciB0aGlzIGJhY2t3YXJkLWRlbHRhIHNjaGVtZSwgYnV0IGFzIHdy aXR0ZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pml0J3MgcHJldHR5IGhhcmQgdG8gdW5kZXJzdGFuZC4gSSBrbm93IHRoaXMgaXMga2luZCBvZiBh IHZhZ3VlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5jb21tZW50OyBvbmNlIHRoaXMgaXMgdXAgb24gR2l0aHViLCBJIHdpbGwgYXR0ZW1wdCB0byBw cm92aWRlIHNvbWU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnRleHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlMgNi40LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+UGxlYXNlIHNheSBoZXJlIHRoYXQgeW91IGNhbid0IHJldHJhY3Qgd2luZG93 IGFkdmVydGlzZW1lbnRzLCBub3QganVzdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+bGF0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlMgJm5ic3A7Ny48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7IEFsbCBh cHBsaWNhdGlvbiBkYXRhIHNlbnQgaW4gU1RSRUFNIGZyYW1lcyBNVVNUIGJlIHJldHJhbnNtaXR0 ZWQsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgJm5ic3A7ICZuYnNwOyB3aXRoIG9uZSBleGNlcHRpb24uJm5ic3A7IFdoZW4gYW4gZW5k cG9pbnQgc2VuZHMgYSBSU1RfU1RSRUFNIGZyYW1lLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZGF0YSBvdXRz dGFuZGluZyBvbiB0aGF0IHN0cmVhbSBTSE9VTEQgTk9UIGJlIHJldHJhbnNtaXR0ZWQsIHNpbmNl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7ICZuYnNwOyBzdWJzZXF1ZW50IGRhdGEgb24gdGhpcyBzdHJlYW0gaXMgZXhwZWN0 ZWQgdG8gbm90IGJlIGRlbGl2ZXJlZCBieTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhlIHJlY2VpdmVyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlz IGFwcGxpZXMgdG8gYm90aCBkaXJlY3Rpb25zLCByaWdodC4gSS5lLiwgJnF1b3Q7d2hlbiBhbiBl bmRwb2ludCBoYXMgc2VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+b3IgcmVjZWl2ZWQgYW4gUlNUX1NUUkVBTSBmcmFtZSZxdW90OzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TIDguPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIGFu IGV4YW1wbGUgb2YgdGV4dCB0aGF0IHdvdWxkIGltcHJvdmUgdGhlIGRvY3VtZW50IGJ5IGJlaW5n PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5lYXJs aWVyIHNvIHBlb3BsZSBoYXZlIHRoZSBvdmVydmlldy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UyA5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgcmVjZWl2 ZXIgYWR2ZXJ0aXNlcyB0aGUgbWF4aW11bSBhYnNvbHV0ZSBieXRlIG9mZnNldCBpbiB0aGUgc3Ry ZWFtIG9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZxdW90O2Fic29sdXRlIGJ5dGUgb2Zmc2V0JnF1b3Q7IGlzIHdlaXJkLiBNYXliZSAmcXVv dDthYm9sdXRlIGJ5dGUgcG9zaXRpb24mcXVvdDs/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB2708B05B61DA370D238507A387BC0BN6PR03MB2708namp_-- From nobody Mon Nov 14 14:32:23 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28216129417 for ; Mon, 14 Nov 2016 14:32:22 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qB0NBotOKk6q for ; Mon, 14 Nov 2016 14:32:20 -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 E4A6412941A for ; Mon, 14 Nov 2016 14:32: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=s34vxbvtI++3hWnKwDIWpUv851jqSFkYCHfb3BYaqw4=; b=frrtvWhcyGqHIrKR8iHMcZE0lqNDoPDOgiXkENKadEuf33yysn//IMQy6OYdUzEQkwSHkhA4bCOqMiIpwsC1dJTJnJFIPkJqeyMOtLMlchakA7FZG5tgMv2NDsop16FEaWrierYXVvCmoX65kp2/a+RRICQIIpDpFk8P6wj5DVI= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Mon, 14 Nov 2016 22:32:17 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0707.015; Mon, 14 Nov 2016 22:32:16 +0000 From: Mike Bishop To: "Aron ." , "quic@ietf.org" Thread-Topic: [QUIC] Why not be explicit about Stream 3 flow control exception? Thread-Index: AQHSPrgGfIvDjV/wrUKopO/WTiVcT6DZD+aA Date: Mon, 14 Nov 2016 22:32:16 +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=Michael.Bishop@microsoft.com; x-originating-ip: [31.133.144.196] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:9igOCT6WtzpRrg4VBcWASekbEW7K61MD4UYwbmBFVnted+sFJDog12CYhlCmUCJbZJ19GeiWjaApDDtNdXv9Z9K924EsmHF0W9eDY8RKyQ9W/AAyx7MgQCpunglYCRf8mC7t/lU+NLZ/wIzHcVdzLt8NQ2IsYyVlbK8xqU0sCMrSqLCswshQFWnVkMdLVPWVc7U+Ydb+2ar7TS7eunB58fPqLcRvu/ZuXRPztTrSAqtj+xPEeYlX3+uTBpozPd7FCKlcfwOIxbZi/va50RrZgfxJBKohLoX9dPvsXu3PGfW0HzahjxrrPOU6tzmmU3CloLcDZEfTdoYxk+V7Gt3oRGPd/1UQco32VcMMOPMBEBER+4FQcrF+Qvi4JdyJlPKS x-ms-office365-filtering-correlation-id: 56c53f8c-52f8-492d-6c0e-08d40cde16ba x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6045074)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6061324); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(199003)(66066001)(10090500001)(5660300001)(106116001)(105586002)(99286002)(106356001)(81156014)(81166006)(8936002)(7846002)(3846002)(2501003)(33656002)(87936001)(10290500002)(9686002)(6116002)(68736007)(8676002)(7736002)(5005710100001)(102836003)(790700001)(2906002)(86612001)(101416001)(8990500004)(97736004)(74316002)(92566002)(5001770100001)(3280700002)(3660700001)(2950100002)(86362001)(76176999)(2900100001)(54356999)(229853002)(122556002)(50986999)(7696004)(189998001)(77096005)(76576001)(107886002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB27089D89B29AAED5C6758CB187BC0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2016 22:32:16.7399 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Subject: Re: [QUIC] Why not be explicit about Stream 3 flow control exception? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 14 Nov 2016 22:32:22 -0000 --_000_BN6PR03MB27089D89B29AAED5C6758CB187BC0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJlc3VtYWJseSBiZWNhdXNlIG90aGVyIHByb3RvY29scyBtaWdodCBuZWVkIG1vcmUsIG9yIGRp ZmZlcmVudCwgb3Igbm8sIHN0cmVhbXMgdG8gYmUgZXhlbXB0ZWQuICBUaGUgdGhpbmcgdGhhdOKA mXMgYWN0dWFsbHkgbWlzc2luZyBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhIG1lY2hhbmlzbSBmb3Ig dGhlIGFwcGxpY2F0aW9uIHByb3RvY29sIHRvIHRlbGwgdGhlIHRyYW5zcG9ydCB3aGljaCBzdHJl YW1zIHRvIGV4Y2x1ZGUuICAoQW5kIEnigJlkIGJlIGluY2xpbmVkIHRvIGhhdmUgc29tZXRoaW5n IHNlbnQgb24gdGhlIHdpcmUgc28gdGhlIG90aGVyIHNpZGUga25vd3Mgd2hhdCB5b3XigJlyZSBk b2luZywgdGhvdWdoIHRoZXJl4oCZcyBhIGNhc2UgdG8gYmUgbWFkZSB0aGF0IGFwcGxpY2F0aW9u IHByb3RvY29sIGFncmVlbWVudCBpbmNsdWRlcyBib3RoIHNpZGVzIGFncmVlaW5nIHRvIG1ha2Ug dGhlIHNhbWUgY2FsbCBpbnRvIHRoZWlyIFFVSUMgc3RhY2suKQ0KDQpGcm9tOiBRVUlDIFttYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQXJvbiAuDQpTZW50OiBUdWVz ZGF5LCBOb3ZlbWJlciAxNSwgMjAxNiA1OjQ1IEFNDQpUbzogcXVpY0BpZXRmLm9yZw0KU3ViamVj dDogW1FVSUNdIFdoeSBub3QgYmUgZXhwbGljaXQgYWJvdXQgU3RyZWFtIDMgZmxvdyBjb250cm9s IGV4Y2VwdGlvbj8NCg0KSGVsbG8sDQoNCltkcmFmdC1oYW1pbHRvbi1xdWljLXRyYW5zcG9ydC1w cm90b2NvbC0wMV0gc3RhdGVzIChwLiAzNSk6DQoNCm8gVGhlIGNyeXB0byBoYW5kc2hha2Ugc3Ry ZWFtLCBTdHJlYW0gMSwgTVVTVCBOT1QgYmUgc3ViamVjdCB0bw0KY29uZ2VzdGlvbiBjb250cm9s IG9yIGNvbm5lY3Rpb24tbGV2ZWwgZmxvdyBjb250cm9sLCBidXQgTVVTVCBiZQ0Kc3ViamVjdCB0 byBzdHJlYW0tbGV2ZWwgZmxvdyBjb250cm9sLg0KbyBBbiBhcHBsaWNhdGlvbiBNQVkgZXhjbHVk ZSBzcGVjaWZpYyBzdHJlYW0gSURzIGZyb20gY29ubmVjdGlvbi1sZXZlbA0KZmxvdyBjb250cm9s LiBJZiBzbywgdGhlc2Ugc3RyZWFtcyBNVVNUIE5PVCBiZSBzdWJqZWN0IHRvDQpjb25uZWN0aW9u LWxldmVsIGZsb3cgY29udHJvbC4NCg0KVGhlIHNlY29uZCBidWxsZXQgcG9pbnQgaXMgb2J2aW91 c2x5IGFib3V0IFN0cmVhbSAzLiAgU2VlaW5nIHRoYXQgdGhlcmUgaXMgbm8gd2F5KD8pIHRvIG5l Z290aWF0ZSB3aGljaCBzdHJlYW1zIGFyZSB0byBiZSBleGNsdWRlZCwgd2h5IG5vdCBzcGVsbCBv dXQgdGhhdCBTdHJlYW1zIDEgYW5kIDMgYXJlIG5vdCBzdWJqZWN0IHRvIGNvbm5lY3Rpb24tbGV2 ZWwgY29uZ2VzdGlvbiBjb250cm9sPw0KDQogIEFyb24uDQo= --_000_BN6PR03MB27089D89B29AAED5C6758CB187BC0BN6PR03MB2708namp_ 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 b3JtYWwiPlByZXN1bWFibHkgYmVjYXVzZSBvdGhlciBwcm90b2NvbHMgbWlnaHQgbmVlZCBtb3Jl LCBvciBkaWZmZXJlbnQsIG9yIG5vLCBzdHJlYW1zIHRvIGJlIGV4ZW1wdGVkLiZuYnNwOyBUaGUg dGhpbmcgdGhhdOKAmXMgYWN0dWFsbHkgbWlzc2luZyBpcyB0aGUgZGVmaW5pdGlvbiBvZiBhIG1l Y2hhbmlzbSBmb3IgdGhlIGFwcGxpY2F0aW9uIHByb3RvY29sIHRvIHRlbGwgdGhlIHRyYW5zcG9y dCB3aGljaCBzdHJlYW1zIHRvIGV4Y2x1ZGUuJm5ic3A7DQogKEFuZCBJ4oCZZCBiZSBpbmNsaW5l ZCB0byBoYXZlIHNvbWV0aGluZyBzZW50IG9uIHRoZSB3aXJlIHNvIHRoZSBvdGhlciBzaWRlIGtu b3dzIHdoYXQgeW914oCZcmUgZG9pbmcsIHRob3VnaCB0aGVyZeKAmXMgYSBjYXNlIHRvIGJlIG1h ZGUgdGhhdCBhcHBsaWNhdGlvbiBwcm90b2NvbCBhZ3JlZW1lbnQgaW5jbHVkZXMgYm90aCBzaWRl cyBhZ3JlZWluZyB0byBtYWtlIHRoZSBzYW1lIGNhbGwgaW50byB0aGVpciBRVUlDIHN0YWNrLik8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29t cG9zZSI+PG86cD4mbmJzcDs8L286cD48L2E+PC9wPg0KPHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YN CjwvYj5Bcm9uIC48YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgMTUsIDIwMTYg NTo0NSBBTTxicj4NCjxiPlRvOjwvYj4gcXVpY0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9i PiBbUVVJQ10gV2h5IG5vdCBiZSBleHBsaWNpdCBhYm91dCBTdHJlYW0gMyBmbG93IGNvbnRyb2wg ZXhjZXB0aW9uPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bZHJh ZnQtaGFtaWx0b24tcXVpYy10cmFuc3BvcnQtcHJvdG9jb2wtMDFdIHN0YXRlcyAocC4gMzUpOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vIFRo ZSBjcnlwdG8gaGFuZHNoYWtlIHN0cmVhbSwgU3RyZWFtIDEsIE1VU1QgTk9UIGJlIHN1YmplY3Qg dG88YnI+DQpjb25nZXN0aW9uIGNvbnRyb2wgb3IgY29ubmVjdGlvbi1sZXZlbCBmbG93IGNvbnRy b2wsIGJ1dCBNVVNUIGJlPGJyPg0Kc3ViamVjdCB0byBzdHJlYW0tbGV2ZWwgZmxvdyBjb250cm9s Ljxicj4NCm8gQW4gYXBwbGljYXRpb24gTUFZIGV4Y2x1ZGUgc3BlY2lmaWMgc3RyZWFtIElEcyBm cm9tIGNvbm5lY3Rpb24tbGV2ZWw8YnI+DQpmbG93IGNvbnRyb2wuIElmIHNvLCB0aGVzZSBzdHJl YW1zIE1VU1QgTk9UIGJlIHN1YmplY3QgdG88YnI+DQpjb25uZWN0aW9uLWxldmVsIGZsb3cgY29u dHJvbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhlIHNlY29uZCBidWxsZXQgcG9pbnQgaXMgb2J2aW91c2x5IGFib3V0IFN0cmVhbSAzLiZu YnNwOyBTZWVpbmcgdGhhdCB0aGVyZSBpcyBubyB3YXkoPykgdG8gbmVnb3RpYXRlIHdoaWNoIHN0 cmVhbXMgYXJlIHRvIGJlIGV4Y2x1ZGVkLCB3aHkgbm90IHNwZWxsIG91dCB0aGF0IFN0cmVhbXMg MSBhbmQgMyBhcmUgbm90IHN1YmplY3QgdG8gY29ubmVjdGlvbi1sZXZlbCBjb25nZXN0aW9uIGNv bnRyb2w/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyBBcm9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_BN6PR03MB27089D89B29AAED5C6758CB187BC0BN6PR03MB2708namp_-- From nobody Mon Nov 14 15:01:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0771293E9 for ; Mon, 14 Nov 2016 15:01:21 -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 MNS9shCy0PHZ for ; Mon, 14 Nov 2016 15:01:20 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 D32C91294A7 for ; Mon, 14 Nov 2016 15:01:19 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 20so74962268uak.0 for ; Mon, 14 Nov 2016 15:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UN/MVAv0puj0mhn5PSJHy/3c/yvYUz2XV5nxklu6MOE=; b=BZffAN4ad2OhUWkds5mgzgaRAHZJlghuYInThrtzKk+dEnl3iRT5to5DLO3CBoy+uE nJLQYthR8GFiL4zUheoCyroo+brluhUayemJTSrBN77uKOUDTlPzK7Eok3gyN5hsYsFZ jNZVw8vxXtWWPXgMI3PEYylulZVF0dXt650AGe2gvRBMUAJi4vkeWfOQd1x1/b1Tx9tB gxrFQGbHmkNLd/0q7+HA1Bgbebx9nVRd9BgT0T8lahW+5Y2ymHa6OnX3JnbzNpRNkA3G V57mELV8BO88NpJrozRjq14ZoGtTYdgv0SFkxYtxZJns2tEEXZH+tJZdfo7ZsFE8DIl7 lzdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UN/MVAv0puj0mhn5PSJHy/3c/yvYUz2XV5nxklu6MOE=; b=k7rJZ21+PiDQ8WmkOQv7OiU3K7mQuTRKJ07eh13J2apyWxSZVSpuZ6NpurIe5zlS2R kF6C9hoQJazqSPQ94Q4X+0QfVdpoF+Rj8FYnKQe8Q9auiLN8K+cDeJM2yGtrV5sOvGAk 1TRCWyDP82bJiBGceLK+2ETpxtEnUohP61Xjs6dRgCrcvDWmyn2WUpH+owx6Fzc6NvSL tGz4bae4AfRktyXxoChDDqHU1Fk3/zydd5shlYoJ3mi3VypysYMRUIdoBlKBmXWJ4a/Q SuiyC9jlWeeQO4S+CjfpQMZPBeGX9Jq90osJIwlTiqv4uJ2Dm2Lg8hbojMbgV2T+uYxb V0cQ== X-Gm-Message-State: ABUngvcwbtLXS0/acb4rWhXne5wDXi4D5DJ+sS5wPRtsxW7ZbSQ7ho0WWdl+MqiXvMPwYEVUTT4wGprj9XkOxw== X-Received: by 10.176.2.110 with SMTP id 101mr11800553uas.8.1479164478967; Mon, 14 Nov 2016 15:01:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.10.130 with HTTP; Mon, 14 Nov 2016 15:01:18 -0800 (PST) In-Reply-To: References: From: Dragana Damjanovic Date: Tue, 15 Nov 2016 00:01:18 +0100 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113d1ad055545a05414ad193 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Comments on draft-thomson-quic-tls- X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 14 Nov 2016 23:01:21 -0000 --001a113d1ad055545a05414ad193 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 14, 2016 at 10:28 PM, Eric Rescorla wrote: > > > S 5.1.3. > I would suggest just never sending ACKs with 0-RTT keys. That would > make life a lot simpler. > > One point that you may need to address here is what key the server > uses for acks of CH. Consider the case where the CH is one packet > but SH..SFin are several. The keys you need to decrypt the ACKs > cannot be computed until you have SFIN. I think the right answer > may be to actually make a stricter requirement than the one you do: > > - ACKs for unprotected data other than ACKs, which IIRC are ACKed > are unprotected > - ACKs for protected data are protected. > > In my opinion data encrypted with 0-RTT keys needs to be acked in cleartext that is needed to ensure prompt retransmits. The server can start encrypting acks when it receives the client finish message or a packet that is encrypted with 1-RTT keys. dragana --001a113d1ad055545a05414ad193 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 14, 2016 at 10:28 PM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:


S 5.1.3.
I would suggest just never sending ACKs with 0-= RTT keys. That would
make life a lot simpler.

One point that you may need to address here is what key the server
uses for acks of CH. Consider the case where the CH is one packet
but SH..SFin are several. The keys you need to decrypt the ACKs
cannot be computed until you have SFIN. I think the right answer
may be to actually make a stricter requirement than the one you do:=

- ACKs for unprotected data other than ACKs, whic= h IIRC are ACKed
=C2=A0 are unprotected
- ACKs for prot= ected data are protected.


<= /div>
In my opinion data encrypted with 0-RTT keys needs to be acked in= cleartext that is needed to ensure prompt retransmits. The server can star= t encrypting acks when it receives the client=C2=A0 finish message or a pac= ket that is encrypted with 1-RTT keys.


=C2=A0dragana<= br>
--001a113d1ad055545a05414ad193-- From nobody Mon Nov 14 15:14:51 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CEC129497 for ; Mon, 14 Nov 2016 15:14:50 -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 3lWIRw3SdEkx for ; Mon, 14 Nov 2016 15:14:48 -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 8D9F7129528 for ; Mon, 14 Nov 2016 15:14:48 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id r204so81464667ywb.0 for ; Mon, 14 Nov 2016 15:14:48 -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=sPA/IRtgjnxhh5V2KlQ1LDc08U/tEKLTZPmzI+EHtvA=; b=CSJES2zgRLfSwnxYmX8zKbTiF2qpR7/ofBe4d9Yf9MMyouwY5Vy2nnAtycsirvZUlJ R53V85qLxNe9uddvcR+rORHRTkbWeyalPherrp2VmbQcsuDOwZ7+rY6wPkNO1ayfg4N7 kKDsrZQbGXmQckjw8cNuoBA5fuG6BeGuskqjaojYx7YdQm/B7jnJW9IqLcxr8+hZaOy8 D9dcSGSef0MQGSN6f84L/ZyYxnymw2FNT6xWjMJ1NZxK1bMPlLicuaB31tNdH+/LnCVx A/jeXJiiSddL1u2NzKn+2EKRM9LmkMkFAg2PzQmzwlIyrWvHi1wP4/MiShAEB+3xK6+r DzdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sPA/IRtgjnxhh5V2KlQ1LDc08U/tEKLTZPmzI+EHtvA=; b=OnSLbhaF0+JFYOP+7hD3CxxGv1ajd8fmz477zgQam1ngFXtjDhDiZBKWyDmr33MMS4 3hk0G635qE+DRceneTYfJXdrNN3F5Jqhu3Oiybi0lOjhrtaRHZ5sIIiD8P9TAixAi3Q8 xCbQRfFqygLng8oEdJ0sAx1SmimJELLsl7ogqUKVgt1I4OBxBLLvL1+Cq+xNUSFz/HLA VZdoX+EWvP22RtGA3rV0YQJKys3MDT9ka9bzMa0sb/NhnIvdC7FL7jCf2Y+m73qWiuHl CPgZASyErN7QavvK0xcf7ITvRqNx1XtKkPu60huN8Cv0i6qwLKtkgdKgDgD7RYO0dAzV Qlfg== X-Gm-Message-State: ABUngvfYtDgz7jNI2xaUnlosD91pzirkEbeVpt+vbnRSw8P1wYcsWz2uFt/VccD3hQmQzC/7nFgej4WxtXMUpQ== X-Received: by 10.129.78.71 with SMTP id c68mr16957007ywb.21.1479165287870; Mon, 14 Nov 2016 15:14:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 14 Nov 2016 15:14:07 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 15 Nov 2016 08:14:07 +0900 Message-ID: To: Dragana Damjanovic Content-Type: multipart/alternative; boundary=001a114dac9c8c6ac705414b01a3 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Comments on draft-thomson-quic-tls- X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 14 Nov 2016 23:14:50 -0000 --001a114dac9c8c6ac705414b01a3 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 15, 2016 at 8:01 AM, Dragana Damjanovic < dragana.damjano@gmail.com> wrote: > > > On Mon, Nov 14, 2016 at 10:28 PM, Eric Rescorla wrote: > >> >> >> S 5.1.3. >> I would suggest just never sending ACKs with 0-RTT keys. That would >> make life a lot simpler. >> >> One point that you may need to address here is what key the server >> uses for acks of CH. Consider the case where the CH is one packet >> but SH..SFin are several. The keys you need to decrypt the ACKs >> cannot be computed until you have SFIN. I think the right answer >> may be to actually make a stricter requirement than the one you do: >> >> - ACKs for unprotected data other than ACKs, which IIRC are ACKed >> are unprotected >> - ACKs for protected data are protected. >> >> > In my opinion data encrypted with 0-RTT keys needs to be acked in > cleartext that is needed to ensure prompt retransmits. The server can start > encrypting acks when it receives the client finish message or a packet > that is encrypted with 1-RTT keys. > Maybe. This is only really an issue when; (a) some 0-RTT data is lost (otherwise you don't need it) (b) pieces of the server's first flight (SH...SFIN) are lost and therefore the client can't compute the server's 1-RTT keys. At this point it seems like it's not exactly a crisis if you don't get super-prompt retransmission of the 0-RTT data. -Ekr --001a114dac9c8c6ac705414b01a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 15, 2016 at 8:01 AM, Dragana Damjanovic &= lt;dragana.d= amjano@gmail.com> wrote:


On Mon, Nov 14, 2016 at 10:28 PM, Eric Rescorla &= lt;ekr@rtfm.com> wrote:

S 5.1.3.
I would suggest just never sending ACKs wit= h 0-RTT keys. That would
make life a lot simpler.

<= /div>
One point that you may need to address here is what key the serve= r
uses for acks of CH. Consider the case where the CH is one pack= et
but SH..SFin are several. The keys you need to decrypt the ACK= s
cannot be computed until you have SFIN. I think the right answe= r
may be to actually make a stricter requirement than the one you= do:

- ACKs for unprotected data other than ACKs, = which IIRC are ACKed
=C2=A0 are unprotected
- ACKs for = protected data are protected.

<= br>
In my opinion data encrypted with 0-RTT keys needs to = be acked in cleartext that is needed to ensure prompt retransmits. The serv= er can start encrypting acks when it receives the client=C2=A0 finish messa= ge or a packet that is encrypted with 1-RTT keys.

Maybe. This is only really an issue when;

(a) some 0-RTT data is lost (otherwise you don't= need it)
(b) pieces of the server's first flight (SH...SFIN)= are lost and therefore the client can't compute the server's 1-RTT= keys.=C2=A0

At this point it seems like it's = not exactly a crisis if you don't get super-prompt retransmission of th= e 0-RTT data.

-Ekr
=C2=A0
--001a114dac9c8c6ac705414b01a3-- From nobody Mon Nov 14 15:41:41 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A50129593 for ; Mon, 14 Nov 2016 15:41:38 -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 uIhw8PJMT0fy for ; Mon, 14 Nov 2016 15:41:37 -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 4D6A3129426 for ; Mon, 14 Nov 2016 15:41:37 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id i145so82242398ywg.2 for ; Mon, 14 Nov 2016 15:41:37 -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; bh=iKHALVRllJ1XVOUK8S7yzKtmAELVJ2BYyN2gAC069CY=; b=rVFbs9PHZ+ClpjROZ+KqM1yb6t3VvIQCVpBKJ1sGKqV/avNMNCehVCRkxnjxJzQrZq l6VHtwTsEHYRdKb+sMvWFOTbbX9Gx+RgPDMSUEXzhgifh4+3dPd8jJSsSDglypV636da H5z5BqjqAH/SWhzkPc9vdRDlbBKpyFloSVfpbltgnP4bw9c1lAYAqbVmFqSXPDIfdU+N jhcNVNWbHDT66QtnsqxOceci+3pF7m6IkcItF4qDJIRJ2PdXk4fH+CoOApTZHduWIFku wy8sQVLETd5qcfTewy+KshSJhTy0M/DDM8n/ArvXP1+bTNDgIYkHRIgBfvJ6ELUptRza K5oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=iKHALVRllJ1XVOUK8S7yzKtmAELVJ2BYyN2gAC069CY=; b=BjqRL1EZzeqV6Q8wwKDs5Vn17CsD+Z+uXOGmPtb0s9fHz6gECToEeIwFYiVu8iin+N fw0ewW+nzkZpYpDzDVPkJwWqvH/j0Lqh4bQl4tYNxCKKDpQZsHs3mIJ509gsntGVaC2P QEd+4QGClpXPt6feCjH3VVMCQ88baJId4VfXjFHEOgC9KIqHAEleznk/MrCiUXCYBiNy QNoebKeHbKrctlOXREVuWCD0LEWszOgaBJbwIolJlJ194O6GpQnyTeNUzD8/w2bfpKzI ThafIntH5rI5Vh+p4PZ6qwyfBkWmn2SPadnAAPAPhBFGz0wRTYd/nWVPkm4p0uELWetc glfQ== X-Gm-Message-State: ABUngvfpMxyuU/6t6u9P/QoB52da+BgmzWVhXiVbd+/jLmeHp2KZdOL5scVZKcgpvzXq8N5l+AlUdl/VUBZhHQ== X-Received: by 10.129.78.71 with SMTP id c68mr17040929ywb.21.1479166895961; Mon, 14 Nov 2016 15:41:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 14 Nov 2016 15:40:55 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 15 Nov 2016 08:40:55 +0900 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114dac9c65e8ed05414b61e4 Archived-At: Subject: Re: [QUIC] Comments on draft-hamilton-quic-transport X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 14 Nov 2016 23:41:39 -0000 --001a114dac9c65e8ed05414b61e4 Content-Type: text/plain; charset=UTF-8 > > > S 6.2. > This document really should include guidance about how to generate ACKs > well, not just point that to loss recovery. > > I'm unpersuaded by this ACK-skipping defense. It seems like it's going > to chew up ACK bandwidth for not too much value, and so senders won't > do it. I would instead suggest that the ACK block just include a signature > of all the packets being ACKed (which both sides need to know anyway). > This can be something fast and order-dependent like XOR and then > the receiver of the ACK can validate it and terminate the entire connection > if it detects shenanigans. > Replying to myself, this isn't going to work as I wrote it. Will ponder a bit about whether there's a way to do it that does. -Ekr --001a114dac9c65e8ed05414b61e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

S 6.2.
This document really should include guidance about how to generate AC= Ks
well, not just point that to loss recovery.

I'm unpersuaded by this ACK-skipping defense. It seems like it&#= 39;s going
to chew up ACK bandwidth for not too much value, and s= o senders won't
do it. I would instead suggest that the ACK b= lock just include a signature
of all the packets being ACKed (whi= ch both sides need to know anyway).
This can be something fast an= d order-dependent like XOR and then
the receiver of the ACK can v= alidate it and terminate the entire connection
if it detects shen= anigans.

Replying to myself, th= is isn't going to work as I wrote it. Will ponder a bit about
whether there's a way to do it that does.

-Ek= r




=C2=A0
--001a114dac9c65e8ed05414b61e4-- From nobody Mon Nov 14 17:10:09 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEA1B1293FC for ; Mon, 14 Nov 2016 17:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-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 WZ1uA0nXhCpc for ; Mon, 14 Nov 2016 17:10:06 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id B9B2D129558 for ; Mon, 14 Nov 2016 17:10:06 -0800 (PST) Received: (qmail 23860 invoked by uid 0); 15 Nov 2016 01:10:04 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 15 Nov 2016 01:10:04 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id 81A11u00L2UhLwi011A4pY; Mon, 14 Nov 2016 18:10:04 -0700 X-Authority-Analysis: v=2.1 cv=K/+xQUmI c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=L24OOQBejmoA:10 a=48vgC7mUAAAA:8 a=NEAV23lmAAAA:8 a=2PvCw-1qiRXGssA_f-kA:9 a=QEXdDO2ut3YA:10 a=XLWzqBMNZ4EA:10 a=rKrVYePj7rwA:10 a=VlZU0XKO32wA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=Bn2pgwyD2vrAyMmN8A2t:22 Received: from dhcp-8f06.meeting.ietf.org ([31.133.143.6]:59937) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1c6SG8-0000MD-W1 for quic@ietf.org; Mon, 14 Nov 2016 18:10:01 -0700 To: IETF QUIC WG From: =JeffH Message-ID: Date: Tue, 15 Nov 2016 10:09:58 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 31.133.143.6 X-Exim-ID: 1c6SG8-0000MD-W1 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-8f06.meeting.ietf.org [31.133.143.6]:59937 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [QUIC] "No such list quic-issues" ? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 01:10:08 -0000 fyi/fwiw, clicking on "issue announce list" just now within yielded "No such list quic-issues" please advise... HTH, =JeffH From nobody Mon Nov 14 17:31:51 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005F7129657 for ; Mon, 14 Nov 2016 17:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jVsdHIaYIuM for ; Mon, 14 Nov 2016 17:31:45 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 6ADAF129656 for ; Mon, 14 Nov 2016 17:31:45 -0800 (PST) Received: (qmail 23165 invoked by uid 0); 15 Nov 2016 01:31:45 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 15 Nov 2016 01:31:45 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id 81Xh1u00L2UhLwi011XkjL; Mon, 14 Nov 2016 18:31:45 -0700 X-Authority-Analysis: v=2.1 cv=Zpp+dbLG c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=L24OOQBejmoA:10 a=NEAV23lmAAAA:8 a=h9fvwNikAAAA:8 a=5ZdmHoKS9vMPr6PL3ncA:9 a=QEXdDO2ut3YA:10 a=Bn2pgwyD2vrAyMmN8A2t:22 a=FtDhlDV5sdB6JbnI9c3R:22 Received: from dhcp-8f06.meeting.ietf.org ([31.133.143.6]:60728) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1c6Sb7-0001ZV-3t for quic@ietf.org; Mon, 14 Nov 2016 18:31:41 -0700 From: =JeffH To: IETF QUIC WG Message-ID: Date: Tue, 15 Nov 2016 10:31:29 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 31.133.143.6 X-Exim-ID: 1c6Sb7-0001ZV-3t X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-8f06.meeting.ietf.org [31.133.143.6]:60728 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 2 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 01:31:50 -0000 > As discussed previously, we plan on using Github to manage our > documents and issues list. > > To help people understand how that will work, we've started to write > down a contribution policy, based upon the process that was used to > develop HTTP/2 successfully. Please take a moment and read: > > https://github.com/quicwg/wg-materials/blob/master/CONTRIBUTING.md > > If you have any suggestions, questions or concerns, please raise them > on the mailing list, or against that repo. Note that the separate > "issues" mailing list hasn't yet been activated until we confirm this > process with the WG. One question is whether the quic specs will all be placed in the repo, or whether y'all will create another repo (under ithub.com/quicwg) for all the specs, or a separate repo for each draft, or... ? HTH, =JeffH From nobody Mon Nov 14 17:37:09 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F16129662 for ; Mon, 14 Nov 2016 17:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7AokEOJFF90T for ; Mon, 14 Nov 2016 17:37:06 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 5E98412964C for ; Mon, 14 Nov 2016 17:37:06 -0800 (PST) Received: (qmail 32278 invoked by uid 0); 15 Nov 2016 01:37:06 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy10.mail.unifiedlayer.com with SMTP; 15 Nov 2016 01:37:06 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw4 with id 81d31u00A2UhLwi011d6nY; Mon, 14 Nov 2016 18:37:06 -0700 X-Authority-Analysis: v=2.1 cv=Zpp+dbLG c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=L24OOQBejmoA:10 a=48vgC7mUAAAA:8 a=WHWPI5CdPylWT9zw3isA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 Received: from dhcp-8f06.meeting.ietf.org ([31.133.143.6]:60929) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1c6SgI-00042n-OQ for quic@ietf.org; Mon, 14 Nov 2016 18:37:03 -0700 To: IETF QUIC WG From: =JeffH Message-ID: Date: Tue, 15 Nov 2016 10:36:57 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 31.133.143.6 X-Exim-ID: 1c6SgI-00042n-OQ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-8f06.meeting.ietf.org [31.133.143.6]:60929 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 3 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: [QUIC] QUIC datatracker issues wrt mailing lists X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 01:37:08 -0000 just a few loose ends i noticed in the QUIC datatracker wrt mailing lists... in , the (not yet created?) quic-issues@ietf.org mailing list is not listed in the "mailing list" section. Also, in the quick-issues list archive ought to be additionally listed HTH, =JeffH From nobody Mon Nov 14 18:49:37 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9E51294F7 for ; Mon, 14 Nov 2016 18:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.418 X-Spam-Level: X-Spam-Status: No, score=-8.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vq-pfFzRXsk6 for ; Mon, 14 Nov 2016 18:49:34 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19EF11294A3 for ; Mon, 14 Nov 2016 18:49:30 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.31,640,1473145200"; d="scan'208";a="162446201" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx141-out.netapp.com with ESMTP; 14 Nov 2016 18:44:16 -0800 Received: from VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Nov 2016 18:44:25 -0800 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Mon, 14 Nov 2016 18:44:25 -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=PreH/4ADhsVAOyxXbORqhNAEGc+EqLeYA/Sgo2TotW8=; b=C+C5d5OF+JOOOtOIYbE9fHrmf+yAqlX7zZVMEJLuWeJNpVNvz6ojnJ43moNL8OP6iaCo3RsOa6vNaQl43vs1dPdzPWExNGPkwN4g86e2AM5PIAs7b1+XxLipyIpdy8UUxSkljXyBKdyf8EmpNld9rahF4/8uavMRE/0XGi34QXA= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1154.namprd06.prod.outlook.com (10.160.157.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Tue, 15 Nov 2016 02:44:24 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0721.015; Tue, 15 Nov 2016 02:44:24 +0000 From: "Eggert, Lars" To: =JeffH Thread-Topic: [QUIC] "No such list quic-issues" ? Thread-Index: AQHSPt0RKrSWvfHyvEeLtnkB6a2xkqDZVp6A Date: Tue, 15 Nov 2016 02:44:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.134.6] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1154; 7:KHGaL7PW+lng7FDnpvKiUVcXFgTNaf/iXFwyh5llzcxpHbEErer+s27iwx3JMwombP9lFKSBMou2lVZs0c0ynWGNRqAmdK6bvFquUIcEHuAjWqbBg3ak7Pd0RFO0DuuOYp/gGpKECbGwojMUTsysP6mXlauNlNbK82RK4BeUsGie+alk2hXvNGmeSrd9EewhYyOlshMv4l/iAvRwwIz5LqSUaz8dHVM/3oh9ntLhS/vmGGY29E7QQwoFvwNEVGO/ucJ4AH576hDMbTXiKjXJefdIFv7qQl3qStOAolo+0kh5mct8wktwxvOBgnzKg2b/ra0frf5WRAyrPT0jMX2LxKsb2lq8LhCuOp4PkLyH794= x-ms-office365-filtering-correlation-id: 307bdb09-65bf-43d3-2f53-08d40d014f3b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061324)(6043046); SRVR:BN3PR0601MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1154; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(199003)(377424004)(189002)(5660300001)(82746002)(189998001)(7846002)(7736002)(6916009)(97736004)(2950100002)(83716003)(3660700001)(33656002)(87936001)(3280700002)(110136003)(8676002)(2900100001)(305945005)(57306001)(101416001)(4001150100001)(8936002)(68736007)(81156014)(81166006)(36756003)(229853002)(4326007)(558084003)(77096005)(92566002)(122556002)(76176999)(6116002)(50986999)(66066001)(99286002)(2906002)(102836003)(106116001)(106356001)(86362001)(3846002)(50226002)(105586002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1154; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2016 02:44:23.9338 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1154 X-OriginatorOrg: netapp.com Archived-At: Cc: IETF QUIC WG Subject: Re: [QUIC] "No such list quic-issues" ? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 02:49:36 -0000 On 2016-11-15, at 10:09, =3DJeffH wrote: > fyi/fwiw, clicking on "issue announce list" just now within yielded "No such list quic-issues" The list has not been set up yet. Hang tight. Lars= From nobody Mon Nov 14 18:49:45 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DE31294A3 for ; Mon, 14 Nov 2016 18:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.417 X-Spam-Level: X-Spam-Status: No, score=-8.417 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFbXxi5MPFxP for ; Mon, 14 Nov 2016 18:49:34 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BF941299B6 for ; Mon, 14 Nov 2016 18:49:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.31,640,1473145200"; d="scan'208,217";a="162446429" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx141-out.netapp.com with ESMTP; 14 Nov 2016 18:46:16 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Nov 2016 18:46:25 -0800 Received: from NAM03-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.1210.3 via Frontend Transport; Mon, 14 Nov 2016 18:46:25 -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=5sqXzkGYBQrn7cXzNsBqkvrP/3zYhwV72cs/7GrUbcE=; b=E2qsjMCsyUqRQuLHBivFEFCAUzciKHQb98DT+ABXcLWGWxyNirjnJxiylQ2Udq/U6UmXApmKpzQFIcoJlWQYxH3oYLuEkBIDSTWL7340FJdRYX1Bch/kysIigdEfmB+g83JpJaHzCQPFYnRcF6VNx3WMt9tZZc1NifPxPDGK1tY= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1154.namprd06.prod.outlook.com (10.160.157.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Tue, 15 Nov 2016 02:46:23 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0721.015; Tue, 15 Nov 2016 02:46:23 +0000 From: "Eggert, Lars" To: =JeffH Thread-Topic: [QUIC] Working process / contribution policy for the QUIC WG -- comments? Thread-Index: AQHSPuAWXo5ajTyzIUqdtQWTCinwd6DZVyUA Date: Tue, 15 Nov 2016 02:46:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.134.6] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1154; 7:Zz+DXtLIrztrOwwzrSyd1AFybRde9lHm/yo8Ww/EmnQV5qaFL8Y7DiGt4SS9bheaCMjVkFvK/VyTOtITnTwObyxkk/AvrelRQtfxOcBU15IOu89gV8tFlWqaOcOtyVoRpPZV/Kxp/mYwfSg3rW0Ie0B5i7P64eAA2iloN94Z4r5V+d2sIx91AcUj/SsMwfkCKWAQ9at6OcTiCngIoss91wX8APPcSMCGIvogqizcJCNpNkW4Q0dei9cufv15ynX/F1m1+zRaV7N+f3XxAWvq+2S/QBV47r6/MtxXS0/SmmWjACNyVbg6G9ukxiUAlAwP2lKJdG9lemBDEtZ1BB6D+McOTWEc50ClvbdQY997BBY= x-ms-office365-filtering-correlation-id: 4884ced7-f0d6-46cf-7e42-08d40d0196a7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061324)(6043046); SRVR:BN3PR0601MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1154; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(24454002)(199003)(377424004)(189002)(5660300001)(82746002)(189998001)(7846002)(7736002)(6916009)(97736004)(2950100002)(83716003)(3660700001)(7906003)(33656002)(87936001)(3280700002)(110136003)(8676002)(2900100001)(57306001)(101416001)(4001150100001)(15395725005)(8936002)(68736007)(81156014)(81166006)(36756003)(229853002)(4326007)(77096005)(92566002)(122556002)(76176999)(6116002)(50986999)(66066001)(99286002)(2906002)(102836003)(106116001)(106356001)(86362001)(3846002)(50226002)(105586002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1154; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DFE7F00AF65445E99B9FA63D47DA64ABnetappcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2016 02:46:23.7838 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1154 X-OriginatorOrg: netapp.com Archived-At: Cc: IETF QUIC WG Subject: Re: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 02:49:39 -0000 --_000_DFE7F00AF65445E99B9FA63D47DA64ABnetappcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 2016-11-15, at 10:31, =3DJeffH > wrote: One question is whether the quic specs will all be placed in the repo, or whether y'all will create another = repo (under ithub.com/quicwg) for all the specs, o= r a separate repo for each draft, or... ? Current thinking is one repo (and a common document format, e.g. Markdown) = for the four heavily intertwined initial documents (since text may move and= issues may affect multiple ones). Additional separate repos for other IDs = that are more standalone. Lars --_000_DFE7F00AF65445E99B9FA63D47DA64ABnetappcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable On 2016-11-15, at 10:31, =3DJeffH <Jeff.Hodges@KingsMountain.com> wrote:

One question is whether the quic specs will all be placed in the <https://github.com/quicwg/wg-materials/> repo, or whether y'all will create another repo (under ithub.com/quicwg) for all the specs, or a separate repo for each draft, or... ?

Current thinking is one repo (and a common document format,= e.g. Markdown) for the four heavily intertwined initial documents (since t= ext may move and issues may affect multiple ones). Additional separate repo= s for other IDs that are more standalone.

Lars
--_000_DFE7F00AF65445E99B9FA63D47DA64ABnetappcom_-- From nobody Mon Nov 14 18:51:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D361299F0 for ; Mon, 14 Nov 2016 18:51: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, 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 95Q5Nqock28d for ; Mon, 14 Nov 2016 18:51:03 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6326E129677 for ; Mon, 14 Nov 2016 18:51:03 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id 189so33038509pfz.3 for ; Mon, 14 Nov 2016 18:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=LATE9qIr6+uCnIhUkySAPm/1KUYSvGrwnr5SbJIGRRo=; b=mvCKETHcoa2k1hkakjAPCyVlN6/oBsfnMDs+0eqbmr+n3G1moOVqFYFAcoLonLgEKE ywBcJvZWlKO7c67yL27v+eNABvrhUw5Fnc/Ia393zXMa1la0lI6C3/kL4SeOlJLCz+pD f3YuRGoI4QuxpPZYawjSByWflnxWelOvc3S39CO1LB1wxbrnoypH0bO0/AGC5IsFFl+i TfJZDOw9KmnSpKz73JPCb48Yf3DvZqYGixEinyEd24Z1wXMDfV1LemtCwPMhdiAAL36+ 4tUeXS2fN4GZDi1+WHQKc1gZlFf+O7Mp19S6TKoDNpH0tKkxErWb6n1PfcoFp8aTL6yv IkpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=LATE9qIr6+uCnIhUkySAPm/1KUYSvGrwnr5SbJIGRRo=; b=aDWyIlb6BocKg/bFHUiK2oKJCLxvZUtOqhbf79mmw1tl/Cy/JCI4kv4OnqLGcJbByn IEXbstsDfJ+6SLr+CXxFXipeaFEGUMsYX3wsQ+BKkHGCTkhC8/YEq0F/rdbXB3/NVBK4 mU/6KBECYkMAOT4Tn3l4/W7kb50Z9TJQcFNmjHt15J6xkNVTZvWv5E8RuP8JPJJFaReu BjbfLzKkIfjVDwF1C/G8Vy5tzz5AvSQPF/vYDjkQDRwkENeljnpVGCFj2wjT5nG4L896 RL9uwX50WVqmR4M3IP7hAwWDu4YMHI5GLYVrvtncgZyIBeNeujzrFbZX3V1y0rMlpnbN 7TKg== X-Gm-Message-State: ABUngvcp5RPVArDkfRmaWvynMHAgjzMCj9OBNpEBR7eXsiIScBgqJevE5TGqJN4bkaz6Jw== X-Received: by 10.98.81.70 with SMTP id f67mr41795367pfb.179.1479178262798; Mon, 14 Nov 2016 18:51:02 -0800 (PST) Received: from t2001067c037001289c72f3a1c049dfcc.v6.meeting.ietf.org ([2001:67c:370:128:9c72:f3a1:c049:dfcc]) by smtp.gmail.com with ESMTPSA id y2sm38329900pay.10.2016.11.14.18.51.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 18:51:02 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: <72DBD44E-9629-43A7-8D22-A2DB8F72A810@gmail.com> Date: Tue, 15 Nov 2016 11:50:57 +0900 To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [QUIC] QUIC and firewalls X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 02:51:05 -0000 Hi. Since this came up in the discussion at the WG session, I wanted to = clarify some things Firewalls are mostly reactive. They are built to handle the traffic that = exists on the Internet. So a typical firewall today will not have a = classifier function for QUIC. That does not mean that firewalls can not = allow QUIC. You can always make a rule like this (and apologies in = advance for using my employer=E2=80=99s proprietary terminology): Src: Any; Dst: Google; Protocol:UDP-with-dest-port-443; Action: Allow This is fine, but there are two drawbacks as far as firewall users are = concerned. First, is that it requires them to specify the port and IP = protocol manually, and second, that this opens a hole through which an = endpoint can send anything to a Google server as long as it=E2=80=99s on = UDP port 443. In this case the firewall doesn=E2=80=99t make any = validation of the content of this traffic to make sure that it is really = =E2=80=9CQUIC=E2=80=9D. Depending on how the firewall rule is written, the firewall may drop all = packets from Google servers with source port 443 because they are out of = state until state is successfully created by a packet with a destination = port of 443 and a destination IP that is identified as =E2=80=9CGoogle=E2=80= =9D. This state can be thought of as a quintuple (source, source port; = dest, dest port, ipp), What firewall vendors would like to do is to allow users to configure a = rule like this: Src: Any; Dst: Google; Protocol:QUIC; action:Allow Having this label could mean as little as just a macro for = UDP-with-dest-port-443, but we=E2=80=99d like better to have more = validation. As long as we don=E2=80=99t have protocol-specific parsers = for QUIC, we have to maintain state according to BEHAVE recommendations. = and that means keeping the state alive for many minutes after traffic = has stopped. With a parser we have a better idea of when a = =E2=80=9Cconnection=E2=80=9D started, when it ends, and how long we have = to wait before timing it out. So firewall vendors will read the specs and implement a parser, but only = if we have a good reason to believe that this is something that is going = to appear on the Internet.=20 Hope this helps, Yoav (with firewall vendor hat on)= From nobody Mon Nov 14 19:46:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CE81294AE for ; Mon, 14 Nov 2016 19:46:39 -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 bPLnoAEpTWFh for ; Mon, 14 Nov 2016 19:46:37 -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 62C64129473 for ; Mon, 14 Nov 2016 19:46:37 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n204so121389306qke.2 for ; Mon, 14 Nov 2016 19:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QDx+IvIt00k/6vH6me9p0GbzunsVMKuZKVgvHphX0O8=; b=uwSdm7ykxVTQ19e4BxJJLo9eNRA7OxWixRUsNeZGNYUEnWxfv8AW7JgawxW4xv82fV 5ygrF+nWUtnAZ2H1sQiI0WMnlqYyzGNBlHzhusacuMYp8i6cHIO/40fr894xBWHD0B3V Z4FuyGoJaiXjVJlcxgqU0mNre8ybhLmd4W/SUZdEHa/hA4b7FvndLx/4WYx/ips7vdZD +pTBog0/aOTv8os98Fng3tYbtsAG+8uMdg1tcHXiN0CFmbv4wmgMh8qg8Sze5wfRb00F ucslsfQe8Zm7sbHS1+Wasj39Q6ole8A2gSvShZRG0FRRTYQp+qBhkEn9k7T3F6gxPWnr RKIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QDx+IvIt00k/6vH6me9p0GbzunsVMKuZKVgvHphX0O8=; b=YhVai3LGgMjQcLO+aJAxc3sbdF16N6ImPujZR7aYwibPPX/F3rT0nGe0YR5uRlX1A7 /t2rR7Qtf/Q9wMARWR97iTEZPkXHG3EEe5y0zN54xCPX3xHlQW6D/X8ZgZcMy93YN6nu 0DJi/eTZOyEH59S+eKPY8bzenHNsGFtMDU3z3iD1+FwMlw33dhJbjxscsVDlHSQNGe1C X1TPnle9RePTunQEmNwRX2HoQdyDzDHr1XwxGzLMOutuOMVOAq1kWVUAFMwqgt2CD4w3 pflYS205bsTfpc7E3lMlnA7M81Pjk/0mIAl8w0YxUbh4c9wen9g7f9KdGhqZ5KUTvO0n VcLg== X-Gm-Message-State: ABUngve7xz4TySzoNffMNvJwSIEeyE5IY8RbBwty5hV7mmFUbNi0HuAP/mxG6hXl5OXWUWS3QpOiRNZsYoZvew== X-Received: by 10.55.150.131 with SMTP id y125mr20269319qkd.115.1479181596555; Mon, 14 Nov 2016 19:46:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 14 Nov 2016 19:46:36 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 15 Nov 2016 12:46:36 +0900 Message-ID: To: "Eggert, Lars" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG , =JeffH Subject: Re: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 03:46:39 -0000 On 15 November 2016 at 11:46, Eggert, Lars wrote: > Current thinking is one repo (and a common document format, e.g. Markdown) > for the four heavily intertwined initial documents (since text may move and > issues may affect multiple ones). Additional separate repos for other IDs > that are more standalone. Jeff identified the repo that is for working group materials. In HTTP, we kept meeting agendas, minutes, slides, and other material like that in a repo like wg-materials, separate from the working documents. Concentrating drafts and their issues in the same repo helps a lot. From nobody Mon Nov 14 19:49:57 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B22F129473 for ; Mon, 14 Nov 2016 19:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JivUvAiX-C7K for ; Mon, 14 Nov 2016 19:49:53 -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 E1EFA1293F3 for ; Mon, 14 Nov 2016 19:49:52 -0800 (PST) Received: from mail-it0-f51.google.com (mail-it0-f51.google.com [209.85.214.51]) by linode64.ducksong.com (Postfix) with ESMTPSA id F2D993A047 for ; Mon, 14 Nov 2016 22:49:51 -0500 (EST) Received: by mail-it0-f51.google.com with SMTP id q124so145753889itd.1 for ; Mon, 14 Nov 2016 19:49:51 -0800 (PST) X-Gm-Message-State: ABUngvdvSFU6oD/mLoSXIn0EGDDFe0J7ZF1x9eLj8MaLwe7g3uscFlQm75s61uWpcvfuQwhFNw8o4SsQjFAJrw== X-Received: by 10.107.205.13 with SMTP id d13mr32181872iog.8.1479181791600; Mon, 14 Nov 2016 19:49:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.84.71 with HTTP; Mon, 14 Nov 2016 19:49:50 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Tue, 15 Nov 2016 12:49:50 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c187b403f4ca905414ed9f4 Archived-At: Cc: IETF QUIC WG , "Eggert, Lars" , =JeffH Subject: Re: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 03:49:55 -0000 --94eb2c187b403f4ca905414ed9f4 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 15, 2016 at 12:46 PM, Martin Thomson wrote: > On 15 November 2016 at 11:46, Eggert, Lars wrote: > > Current thinking is one repo (and a common document format, e.g. > Markdown) > > for the four heavily intertwined initial documents (since text may move > and > > issues may affect multiple ones). Additional separate repos for other IDs > > that are more standalone. > > Jeff identified the repo that is for working group materials. In > HTTP, we kept meeting agendas, minutes, slides, and other material > like that in a repo like wg-materials, separate from the working > documents. > > Concentrating drafts and their issues in the same repo helps a lot. > > +1 quic folk might like to look at the current HTTPbis example https://github.com/httpwg/http-extensions which houses a number of current active drafts and their issue lists --94eb2c187b403f4ca905414ed9f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 15, 2016 at 12:46 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
On 15 November 2016 at 11:46, Eggert, La= rs <lars@netapp.com> wrote: > Current thinking is one repo (and a common document format, e.g. Markd= own)
> for the four heavily intertwined initial documents (since text may mov= e and
> issues may affect multiple ones). Additional separate repos for other = IDs
> that are more standalone.

Jeff identified the repo that is for working group materials.=C2=A0 = In
HTTP, we kept meeting agendas, minutes, slides, and other material
like that in a repo like wg-materials, separate from the working
documents.

Concentrating drafts and their issues in the same repo helps a lot.

+1

quic folk mig= ht like to look at the current HTTPbis example https://github.com/httpwg/http-extensions whi= ch houses a number of current active drafts and their issue lists

--94eb2c187b403f4ca905414ed9f4-- From nobody Mon Nov 14 20:39:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2CF1129467 for ; Mon, 14 Nov 2016 20:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.417 X-Spam-Level: X-Spam-Status: No, score=-8.417 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IjoApOhJGGnx for ; Mon, 14 Nov 2016 20:39:11 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69401293EE for ; Mon, 14 Nov 2016 20:39:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.31,640,1473145200"; d="scan'208,217";a="152129311" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx142-out.netapp.com with ESMTP; 14 Nov 2016 20:38:46 -0800 Received: from VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Nov 2016 20:38:47 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Mon, 14 Nov 2016 20:38:47 -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=iec/gnHx/MAftzOfN/hDyskLf5hRDjnEfm1/PrA1IQM=; b=R7Y8/9uRpGkFITV5acg2KF82DGGzn9UjEottLxBjST4qj9Ei7lxxf9LWSDStxhRROyKWpEsXxq5CZB2DWcHqgSGLnMM+WMdlG/S/ss/dhbYdOOz27bSJByCFLy7WUqFzVaeywD2Yiuzd44MpoVrblAulBepr7gOjj8GsSPt1K+g= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1155.namprd06.prod.outlook.com (10.160.157.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Tue, 15 Nov 2016 04:38:44 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0721.015; Tue, 15 Nov 2016 04:38:44 +0000 From: "Eggert, Lars" To: Martin Thomson Thread-Topic: [QUIC] Working process / contribution policy for the QUIC WG -- comments? Thread-Index: AQHSPuAWXo5ajTyzIUqdtQWTCinwd6DZVyUAgAAQ1QCAAA6NgA== Date: Tue, 15 Nov 2016 04:38:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.134.6] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1155; 7:n0Ce0vfUDUSSwz7q9mWtTQ5CwxhR2VtEKfo4oqOEOgnY+rH6EFLoVTJEAqNwCqpd7GXmMdzUSqhJ0i8YiPk/0SZ17et6tieJW4LAHlzeReEjyoyPaHgs5gn8lwO863bKi8O0ZBH1sC1woiB4LTqSAVZjbohfmKDjI20dnlZUoVAFUlfyaaWluU7+l+hjYYoitkhTArC96jqADUj5akTVciRn6R/fbjbY9G6zhZe84J4aIqkh7TsowWpYyzWC6v58DGgtWd9SKFVcb/KkeaAU94BTTeJQy6QsFIq6rFjJQrlurv7qd3fao8LGfZYVfryifWmanXAuT4mvm7ywnCuPay/oTWruEelWzysJxFqwB8U= x-ms-office365-filtering-correlation-id: 06aa4e12-f648-428e-a415-08d40d11485d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061324)(6043046); SRVR:BN3PR0601MB1155; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1155; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(377424004)(22804003)(189002)(24454002)(199003)(4326007)(106356001)(66066001)(68736007)(87936001)(229853002)(81156014)(83716003)(8676002)(2906002)(189998001)(82746002)(8936002)(4001150100001)(97736004)(92566002)(50226002)(36756003)(99286002)(2900100001)(50986999)(5660300001)(81166006)(86362001)(102836003)(3660700001)(6116002)(3846002)(33656002)(106116001)(77096005)(105586002)(7736002)(110136003)(2950100002)(6916009)(7846002)(7906003)(3280700002)(76176999)(122556002)(57306001)(101416001)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1155; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_A9F6F9C5CB75433A914C596893C43862netappcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2016 04:38:43.9138 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1155 X-OriginatorOrg: netapp.com Archived-At: Cc: IETF QUIC WG , =JeffH Subject: Re: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 04:39:13 -0000 --_000_A9F6F9C5CB75433A914C596893C43862netappcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 2016-11-15, at 12:46, Martin Thomson > wrote: On 15 November 2016 at 11:46, Eggert, Lars > wrote: Current thinking is one repo (and a common document format, e.g. Markdown) for the four heavily intertwined initial documents (since text may move and issues may affect multiple ones). Additional separate repos for other IDs that are more standalone. Jeff identified the repo that is for working group materials. In HTTP, we kept meeting agendas, minutes, slides, and other material like that in a repo like wg-materials, separate from the working documents. That would be https://github.com/quicwg/wg-materials Concentrating drafts and their issues in the same repo helps a lot. There was some concerns that once there are many drafts, having just a sing= le repo for drafts would make it very noisy. Hence the intent to try and do= some sort of loose grouping. Lars --_000_A9F6F9C5CB75433A914C596893C43862netappcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable On 2016-11-15, at 12:46, Martin Thomson <martin.thomson@gmail.com> wrote:

On 15 November 2016 at 11:46, Eggert, Lars <lars@netapp.com> wrote:
Current thinking is one repo (and a co= mmon document format, e.g. Markdown)
for the four heavily intertwined initial documents (since text may move and=
issues may affect multiple ones). Additional separate repos for other IDs that are more standalone.

Jeff identified the repo that is for working group materials.  In
HTTP, we kept meeting agendas, minutes, slides, and other material
like that in a repo like wg-materials, separate from the working
documents.


Concentrating drafts and their issues in the same repo help= s a lot.

There was some concerns that once there are many drafts, having just a= single repo for drafts would make it very noisy. Hence the intent to try a= nd do some sort of loose grouping.

Lars
--_000_A9F6F9C5CB75433A914C596893C43862netappcom_-- From nobody Mon Nov 14 21:48:00 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A9B1299E3 for ; Mon, 14 Nov 2016 21:47:59 -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 o5wwxbWq4Dxw for ; Mon, 14 Nov 2016 21:47:57 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 B4241129615 for ; Mon, 14 Nov 2016 21:47:56 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id x190so123562051qkb.0 for ; Mon, 14 Nov 2016 21:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=abqYAyCaMYQ/03F7jyFVIJkSbASkd9hgeUIBzpMt60w=; b=xiqARtC6+4MrqZwgXJXL/DhnPhYZe1u6+SwT/0gS30TGfFHhnzYQWvaJDfs0SbYfQN LfsvLY9hmd0uQwNrVieiGU3BY7+pxBQkCMg/kY4CJXVRG2rjPf2Hf5xBtgHLFZg9YfDe O5zk9nipHzzEBgx8QHOEkLiqwPOss13ontAetmTX1r3/RC21VwmBT/ElLlDxpwu1uHs5 +qqTAjN+u4w1I5XOyU5bn6F1BaTzzZimAZ3dIK7dCews92u6++BWn/uhtVMbmzm4dXdZ Jb7JGuENWhosUaLgNOMuXgW35f1hl1jX1c5RGY4gFh6stHJ/wW2MmKbanR+VdnWuoa7U KjBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=abqYAyCaMYQ/03F7jyFVIJkSbASkd9hgeUIBzpMt60w=; b=Eq6nsNrTS90It6kPSw1MUBhZZEcJesnuws0Ee0fe0Gu0mfiZfnRO/c3LDff5fmXQUW uIeTqZraOTnl6IF8bd+UwgJPhPPYnsZmksP+5Jc7aoUP9Pt7fzMKjXHJpI8UXarw+wUD QzLbVp3W8nxMjgZcmYyo/q8lI4F8VYQ0fKjzpcNMXDhtj/6LwDG322CX8E5oZ8jPKJ35 abIro8wNZTDk70OID3W5sg587+aLlLLzsF64C63YJpS9ZH7RaspNK1lntxPRfexizJrV vckCXi2os/YOiDai/KzZgRG+FT4dOY51sBRr3f0PHscXkkXR8EVQJF9V035RdoK8bZdI +ToQ== X-Gm-Message-State: ABUngvePqf8KumZwsFRgFKvtoif7PUl8feFjXAkyB20PaaOURnvqCy0jbnUKF+OC5s6Iu6wGgMlLM2RT+bsP7Q== X-Received: by 10.55.150.131 with SMTP id y125mr20596862qkd.115.1479188875808; Mon, 14 Nov 2016 21:47:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 14 Nov 2016 21:47:55 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 15 Nov 2016 14:47:55 +0900 Message-ID: To: "Eggert, Lars" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG , =JeffH Subject: Re: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 05:47:59 -0000 On 15 November 2016 at 13:38, Eggert, Lars wrote: > There was some concerns that once there are many drafts, having just a > single repo for drafts would make it very noisy. Hence the intent to try and > do some sort of loose grouping. I believe that what we discussed was having a single repo for the four drafts we proto-adopted today (five if the HTTP part gets split). Yes, there is a concern that the level of noise might be high with issues and traffic for all of those documents on the same repo, but having them in the same place allows us a bit of flexibility and coherence that separate repos might make difficult. For instance, we can more easily move text between documents, make changes to multiple drafts in a single change set, and track issues that cover multiple documents. When it comes time to do an operational challenges/requirements/discussion document, I will likely argue to have that in a separate repo. From nobody Mon Nov 14 22:02:02 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 184C1129A34 for ; Mon, 14 Nov 2016 22:02:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.418 X-Spam-Level: X-Spam-Status: No, score=-8.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id do1bHZochyQ4 for ; Mon, 14 Nov 2016 22:01:58 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [216.240.21.12]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B32129A33 for ; Mon, 14 Nov 2016 22:01:54 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.31,640,1473145200"; d="scan'208";a="162471949" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx141-out.netapp.com with ESMTP; 14 Nov 2016 21:56:39 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Nov 2016 21:56:48 -0800 Received: from NAM03-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.1210.3 via Frontend Transport; Mon, 14 Nov 2016 21:56:48 -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=eL8vOyCQy1C4PWtgz87KC3+HuXxEGMWzMivsz68H1XA=; b=JQqxYqEwXHzJXa35UyOFnIMIKx6JxhR/rffjJlG5xaWAkpwxkaI7HjtQYq7QzE2XVlBoi6XiQWntFFyyqM6Dw85Rdk92oT/UojbjDEl8ocrzWFtWJWCet96Dx1qrILuE8/iSzJx21X1jQMvCw9lIXEFSJC7RPxZgBFVfWeb9iwY= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Tue, 15 Nov 2016 05:56:47 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0721.015; Tue, 15 Nov 2016 05:56:47 +0000 From: "Eggert, Lars" To: Martin Thomson Thread-Topic: [QUIC] Working process / contribution policy for the QUIC WG -- comments? Thread-Index: AQHSPuAWXo5ajTyzIUqdtQWTCinwd6DZVyUAgAAQ1QCAAA6NgIAAE1iAgAACeIA= Date: Tue, 15 Nov 2016 05:56:47 +0000 Message-ID: <801D8EFD-B12A-4EAE-ADE6-7C70D4736462@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:128:a4:91cb:4fee:85c3] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:do46NlBNHZ0VbvEudMx51+9jA9kt1B4JdT5EHZ9pOsZ/fkqIESMhtHmsUaOFOMwCA+/6WtS47h/U93hJD9lTwYpEdy5Wgu3KKf49MmStv2EOiSMYNPO1IUu6t0eZIW/zgQNqxb9pnDmOTOhXlJiUh2t2hyje1rx/at6tV+BizscEglrv+WlrwI17t4owl6lGMBqZ0gPvK9IWrXlJGQeBZOToBlf5ITrW658Fde3jNZJtK8NnhP4LQ+oodA/c7VIUnADmzPymDlD8XQe47hy5/KOiSOhFodQ53iLoKurGJNqhNBGJ8DXLPfK9Hds3Vs9nHQjjxKdAZKfgGCNVrG9x2XZJy6l7i/OW6POJO38L8rY= x-ms-office365-filtering-correlation-id: 6358af82-d7ea-4fb6-ed3d-08d40d1c2f7a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061324)(6043046); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(189002)(199003)(377424004)(92566002)(33656002)(86362001)(68736007)(3280700002)(189998001)(81166006)(81156014)(122556002)(4326007)(229853002)(110136003)(97736004)(4001150100001)(6916009)(2950100002)(5660300001)(6116002)(99286002)(105586002)(106356001)(102836003)(106116001)(93886004)(2906002)(36756003)(83716003)(8936002)(57306001)(77096005)(87936001)(82746002)(305945005)(101416001)(3660700001)(50226002)(76176999)(2900100001)(50986999)(7736002)(7846002)(8676002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <11D5AA4E78706943BB5D8DFDD5C16386@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2016 05:56:47.1261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Cc: IETF QUIC WG , =JeffH Subject: Re: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 06:02:00 -0000 On 2016-11-15, at 14:47, Martin Thomson wrote: >=20 > On 15 November 2016 at 13:38, Eggert, Lars wrote: >> There was some concerns that once there are many drafts, having just a >> single repo for drafts would make it very noisy. Hence the intent to try= and >> do some sort of loose grouping. >=20 >=20 > I believe that what we discussed was having a single repo for the four > drafts we proto-adopted today (five if the HTTP part gets split). > Yes, there is a concern that the level of noise might be high with > issues and traffic for all of those documents on the same repo, but > having them in the same place allows us a bit of flexibility and > coherence that separate repos might make difficult. For instance, we > can more easily move text between documents, make changes to multiple > drafts in a single change set, and track issues that cover multiple > documents. Sorry for being unclear - I believe four (or five) is a small enough number= that those issues - should they even arise - are very manageable. What I m= eant to express was that we shouldn't necessarily put all other future docu= ments into the same repo by default, but instead make that a conscious deci= sion, with a preference for separate repos. > When it comes time to do an operational > challenges/requirements/discussion document, I will likely argue to > have that in a separate repo. We are aligned. Lars= From nobody Mon Nov 14 23:08:39 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B5AF129A14 for ; Mon, 14 Nov 2016 23:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02wgWEa3I7zX for ; Mon, 14 Nov 2016 23:08:35 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id E4696129A30 for ; Mon, 14 Nov 2016 23:08:31 -0800 (PST) Received: from fifthhorseman.net (dhcp-85a7.meeting.ietf.org [31.133.133.167]) by che.mayfirst.org (Postfix) with ESMTPSA id 93EA6F99A; Tue, 15 Nov 2016 02:08:30 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id E93652018D; Tue, 15 Nov 2016 15:45:24 +0900 (KST) From: Daniel Kahn Gillmor To: "Eggert\, Lars" , "\=JeffH" In-Reply-To: References: Date: Tue, 15 Nov 2016 15:45:24 +0900 Message-ID: <877f85b5rv.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: IETF QUIC WG Subject: Re: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 07:08:37 -0000 On Tue 2016-11-15 11:46:23 +0900, Eggert, Lars wrote: > On 2016-11-15, at 10:31, =JeffH wrote: > >> One question is whether the quic specs will all be placed in the >> https://github.com/quicwg/wg-materials/ repo Also, there is apparently https://github.com/ietf-quic, which contains (i think) an older version of the charter. Could we consolidate all these repos under a single github "organization" so that it's not a hunting game to find the relevant repos? --dkg From nobody Mon Nov 14 23:37:01 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0E8129647 for ; Mon, 14 Nov 2016 23:36:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.417 X-Spam-Level: X-Spam-Status: No, score=-8.417 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id isQkweEIoWBA for ; Mon, 14 Nov 2016 23:36:58 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37FAE1294AD for ; Mon, 14 Nov 2016 23:36:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.31,641,1473145200"; d="scan'208,217";a="152154700" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 14 Nov 2016 23:36:36 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 14 Nov 2016 23:36:37 -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.1210.3 via Frontend Transport; Mon, 14 Nov 2016 23:36:37 -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=9jxJ0tpsUSlXgqbA3MJhJgzBKylzpTW7cxGntDA4W8E=; b=DiQ4lP650WvhCr4miHwzRQTIsm0xR6Kec4frcgErPYc2lieVLDwNwx6W3VRLG/EOzJ2QKfwUkii8Nh4xWfusNqp14we0PWuL1j7wQz3blirYpGCuag4I0yZN/OCHypiyX2vXOolulADwsuyzAZf8VL8Q9P/ulS62QnRdvUGHHJE= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1154.namprd06.prod.outlook.com (10.160.157.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Tue, 15 Nov 2016 07:36:35 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0721.015; Tue, 15 Nov 2016 07:36:35 +0000 From: "Eggert, Lars" To: Daniel Kahn Gillmor Thread-Topic: [QUIC] Working process / contribution policy for the QUIC WG -- comments? Thread-Index: AQHSPuAWXo5ajTyzIUqdtQWTCinwd6DZVyUAgABCyQCAAA5KAA== Date: Tue, 15 Nov 2016 07:36:35 +0000 Message-ID: <9ECEB2F9-3EB3-484E-A78D-0DAE7484B04D@netapp.com> References: <877f85b5rv.fsf@alice.fifthhorseman.net> In-Reply-To: <877f85b5rv.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.134.6] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1154; 7:ga4MJRGEr79HshiJ9iGyEIAK8psmERdYrmD/7VlL6s7T6IsoS47S1ImJny5GsCLSez5WEZC76goFbGh298PgoIIx476O8fo0CQ/Hx42BfRIm4LlrspfPCUZ+OQMpTgtb7AhfUdmDI3Uig+khlXAsaYJkSvdgT12mQkCaZDSXavgSK9Rj0mqpciXfrwcXDof8EZuL6Y4DhlHuXQInci9iBAi0Cte7obwNDxFDLmRzKbjhzTqforPgcpz+hDC0qg5nG1++MBd1SNx5kJKrEfImMLEOG77JSWKYrpaEtEs/AoNLX5qoduRlbEGYHVE/EOaVhqJm9xWDb0VREzRCM1e0jx0WBBO2ekgqPvDv4s+fSRg= x-ms-office365-filtering-correlation-id: c0243e33-57ca-41a9-8fa4-08d40d2a20b9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1154; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061324)(6043046); SRVR:BN3PR0601MB1154; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1154; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(377424004)(24454002)(199003)(36756003)(81156014)(81166006)(229853002)(4326007)(558084003)(4001150100001)(101416001)(68736007)(8936002)(106356001)(102836003)(77096005)(57306001)(86362001)(105586002)(50226002)(3846002)(106116001)(92566002)(6116002)(76176999)(122556002)(99286002)(2906002)(66066001)(50986999)(2950100002)(7736002)(97736004)(83716003)(6916009)(5660300001)(7846002)(82746002)(189998001)(3280700002)(110136003)(8676002)(2900100001)(3660700001)(7906003)(87936001)(33656002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1154; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9ECEB2F93EB3484EA78D0DAE7484B04Dnetappcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2016 07:36:35.2309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1154 X-OriginatorOrg: netapp.com Archived-At: Cc: IETF QUIC WG , =JeffH Subject: Re: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 07:37:00 -0000 --_000_9ECEB2F93EB3484EA78D0DAE7484B04Dnetappcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On 2016-11-15, at 15:45, Daniel Kahn Gillmor > wrote: Also, there is apparently https://github.com/ietf-quic, which contains (i think) an older version of the charter. IMO we can just delete that. Lars --_000_9ECEB2F93EB3484EA78D0DAE7484B04Dnetappcom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable On 2016-11-15, at 15:45, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
Also, there is apparently https://github.com/ietf-quic, which contains
(i think) an older version of the charter.

IMO we can just delete that.

Lars
--_000_9ECEB2F93EB3484EA78D0DAE7484B04Dnetappcom_-- From nobody Tue Nov 15 00:26:29 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3871294E3 for ; Tue, 15 Nov 2016 00:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.418 X-Spam-Level: X-Spam-Status: No, score=-8.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FbyCkUq6sdcj for ; Tue, 15 Nov 2016 00:26:27 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BD141294F3 for ; Tue, 15 Nov 2016 00:26:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.31,641,1473145200"; d="scan'208";a="156464703" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx143-out.netapp.com with ESMTP; 15 Nov 2016 00:21:15 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Nov 2016 00:21:26 -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.1210.3 via Frontend Transport; Tue, 15 Nov 2016 00:21:26 -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=PT5vgtCmo5zELq4McZ7hRQ2vUG1NnR+vdTkLN+P0AAQ=; b=kfu/V/SGn1BBZKEQK1S+fr4r+oIMXZ4tNWjplmwmoxCpiYahXGLSsleTiit9g2/KxUCDELuZbMe7jcoJSHAOFpctY/XP1XZeeqY+pNtJxx2igQTQEvN2NIg52ubwA05OQtzad8adfNfpx3kWtC8EG9ni9bLQ8DYOpWZICde6eWc= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1155.namprd06.prod.outlook.com (10.160.157.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Tue, 15 Nov 2016 08:21:23 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0721.015; Tue, 15 Nov 2016 08:21:23 +0000 From: "Eggert, Lars" To: =JeffH Thread-Topic: [QUIC] QUIC datatracker issues wrt mailing lists Thread-Index: AQHSPuDNfa8nEUfkf0SUHoaK/Yb6rqDZtLsA Date: Tue, 15 Nov 2016 08:21:23 +0000 Message-ID: <14D10094-5B32-450E-9DB9-6E655D5E7541@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.134.6] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1155; 7:Ni1xzS1op9JMugs1smz/QEjfdjLQZptHL1AOR85OCGNgZ6ksYkSN8KA/q7GCjSVENcD1ptrcwuA++qMluMgpPDydtfphRIDya3Pf7CzHreqOIGL9BFVjCPid1Lkb6748S3oi4gya8qM65Woyjmx2gldSIZphxuKPzaUpTO7LnpRuX6Glcsx5D8hU9B/FvN1pEXoIibUefmKCTNmjuEqJwqCj9qIjvWaATWD1PQr6uolmZrUnOTL1QhtcpmR6FFR0VRpK/4wBQcUgXckuhUhwNS4Q0zW+XUlo3ef+fg6VqGTo4N/6ALWGug3uy8NZmbJSlMvCZNd7bmu2pWcpmVdMQpJmy4WhK1cDBGh+1o6QCFI= x-ms-office365-filtering-correlation-id: 042dd8e3-7c4f-45de-62b0-08d40d306300 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6061324)(6043046); SRVR:BN3PR0601MB1155; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1155; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(377424004)(189002)(24454002)(199003)(4326007)(106356001)(66066001)(229853002)(68736007)(87936001)(81156014)(83716003)(8676002)(77096005)(2906002)(4001150100001)(8936002)(97736004)(92566002)(82746002)(189998001)(50226002)(36756003)(105586002)(99286002)(2900100001)(50986999)(5660300001)(81166006)(86362001)(106116001)(102836003)(3660700001)(3846002)(6116002)(33656002)(7736002)(110136003)(305945005)(2950100002)(7846002)(3280700002)(6916009)(76176999)(122556002)(57306001)(101416001)(197153002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1155; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <35A26B71B0E0B04291D553F3BC24FC01@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2016 08:21:23.5292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1155 X-OriginatorOrg: netapp.com Archived-At: Cc: IETF QUIC WG Subject: Re: [QUIC] QUIC datatracker issues wrt mailing lists X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 08:26:28 -0000 Hi, On 2016-11-15, at 10:36, =3DJeffH wrote: > in , the (not yet creat= ed?) quic-issues@ietf.org mailing list is not listed in the "mailing list" = section. >=20 > Also, in the quick-is= sues list archive ought to be additionally listed AFAIK, the datatracker cannot handle multiple mailig lists in that way (i.e= ., show them and their archive under the "Mailing list" section. I have however added the new quic-issues@ list under "More info" now. Lars= From nobody Tue Nov 15 00:26:33 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0161294E3 for ; Tue, 15 Nov 2016 00:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.418 X-Spam-Level: X-Spam-Status: No, score=-8.418 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8eyhQo9Lx5d for ; Tue, 15 Nov 2016 00:26:27 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BC1012954E for ; Tue, 15 Nov 2016 00:26:27 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.31,641,1473145200"; d="scan'208";a="156465042" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx143-out.netapp.com with ESMTP; 15 Nov 2016 00:24:15 -0800 Received: from VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 15 Nov 2016 00:24:27 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Tue, 15 Nov 2016 00:24:26 -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=LJrC6hQAQutpW9tluiKTv01MDeRrKLSmL4zLzg9l8/A=; b=ZwoqaiqURRZOJPXkDCrikYK1r84ITcXItk8ghBv7z2csrsaVTv2u5SPMNiLWZhJ2p1y6vNnTwGoHnd5VpwdIqq0wGz5R/eRDzXiUj+Zcil2JRJhwtk8y7RWjdLYMeA3JypBGrHjFugjHNzz8S4JYL7QvNv3F8LeoKOm2xYWcR9g= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Tue, 15 Nov 2016 08:24:23 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0721.015; Tue, 15 Nov 2016 08:24:23 +0000 From: "Eggert, Lars" To: IETF QUIC WG Thread-Topic: quic-issues@ list created Thread-Index: AQHSPxmrE8MLxqk7gEiuDbfGHlrxjg== Date: Tue, 15 Nov 2016 08:24:23 +0000 Message-ID: <9D3A7D9A-FBE2-49FA-B332-C5B425FE48A9@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3251) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:128:6107:406e:fcd7:d47] x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1153; 7:EPnEyeqYz7unhaxlW3Vusne0gNZ/mqWh4N/BkKxrO4R3E4Qs7+isgX82f5S3oOxLOxP7lzUGvJZ98+mu3LEkUENaFJz6t0ACLmjHHFoTZVeH2nQwOydhaztZL8s266OY7J13IrSwfMbdD0sfJlvqW4W557TFFB2Y1B7f3CqlcC7ajepmFhurXN2KOxwtVHGYjfzlCZmtpBgSI/GDMVHPWNuAPMexgd+3LB4B8eMQyCpD2LvDlKhGfY/i5k5o6zYCzxZQgdrCsdgvb5oM9JAZtT6YmfY9YhPIYiEEd2DUtFa5l7as9hIeoaYA6NbyJDpRPlgUiB/UNclP6UBzasH9khMBlt58Pmf6kZfn09U8Ois= x-ms-office365-filtering-correlation-id: 6af0398e-6069-415c-ab04-08d40d30ce6e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1153; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6061324)(6043046); SRVR:BN3PR0601MB1153; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1153; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(199003)(92566002)(33656002)(86362001)(68736007)(3280700002)(189998001)(81166006)(81156014)(122556002)(558084003)(110136003)(97736004)(6916009)(6116002)(99286002)(105586002)(102836003)(106356001)(106116001)(5660300001)(450100001)(2906002)(8936002)(83716003)(36756003)(57306001)(77096005)(87936001)(107886002)(305945005)(3660700001)(101416001)(50226002)(50986999)(82746002)(2900100001)(7736002)(7846002)(8676002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1153; H:BN3PR0601MB1153.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <26B114005716FC4E8B1A873A599830E9@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2016 08:24:23.6771 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1153 X-OriginatorOrg: netapp.com Archived-At: Subject: [QUIC] quic-issues@ list created X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 08:26:29 -0000 Hi, the quic-issues@ mailing list is now live: https://www.ietf.org/mailman/lis= tinfo/quic-issues It is configured as a read-only mailing lists to receive GitHub event notif= ications. Lars= From nobody Tue Nov 15 02:18:17 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100791294DF for ; Tue, 15 Nov 2016 02:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jL_M5KIyxlKt for ; Tue, 15 Nov 2016 02:18:10 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0123.outbound.protection.outlook.com [104.47.42.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDE871294F1 for ; Tue, 15 Nov 2016 02:18:09 -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=bj14vmwB0koF9ivYQcwNNk2dF9yg0xxuLaOCAv3cEI8=; b=Bi/CwTSTZfOchmI2z/20DhibmIinJlwq7jAzgwPBE4wafXYqw4aPw/uGDxdnYZj4Z/gHbuQiXQXllAUJxJk8E8wcx8OkbfgplSNwhb+njsYldjO5flabMn+JDPxpkvG4QZ/vBGTntSD0klVu4mlVf4Pt//VGssJ2i5FnKv38xxE= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Tue, 15 Nov 2016 10:18:07 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0707.015; Tue, 15 Nov 2016 10:18:06 +0000 From: Mike Bishop To: "quic@ietf.org" Thread-Topic: New Version Notification for draft-bishop-quic-http-and-qpack-00.txt Thread-Index: AQHSPykNDprlTo121UGgpILZftfThKDZ1Ebw Date: Tue, 15 Nov 2016 10:18:06 +0000 Message-ID: References: <147920486641.10264.16135823379017926039.idtracker@ietfa.amsl.com> In-Reply-To: <147920486641.10264.16135823379017926039.idtracker@ietfa.amsl.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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:67c:370:128:1400:dead:5db9:3be8] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:MieKo0AtUoNCd9cQAe+evA4fGe03InF/rUF7YiRuHZXAOIwo0r47fnQh6yDAK/U/i0j85i1lTrbZGWrdL8CdkgEUvDj4XyDpXLH8SLmPqlsbLB/TdEaBXgNC/aukFz+STClWy/mJyGAtdb6SEuwKd7tqITiUKuOtzDvIyZczO1a666ywKokHexj10FSe74sw0/2K9k936YhlxHzdAa9TWixgAY/pAiNwgUraYN8XjQfoitZL8RdcuAq2fFk7NY5xZrOfxvGsdjjSxZ+ipRjeMCtRc1tlFoNnoJtb6aftQgUhmLzXwtgue94P5eAaeTSI7UpO66j3wGZ4Eo/3i7VJRTOrzwcmz8FibUViELKjjKsWkqsrE58ErJfLLl6b6wck x-ms-office365-filtering-correlation-id: 52332996-2b5a-4777-df9f-08d40d40b140 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2706; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6045074)(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6061324)(6046074); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 012792EC17 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(377424004)(377454003)(2473002)(189002)(7696004)(229853002)(5660300001)(5005710100001)(10290500002)(86612001)(122556002)(10090500001)(8990500004)(99286002)(106116001)(81166006)(76176999)(6916009)(2950100002)(106356001)(9686002)(101416001)(8936002)(81156014)(1730700003)(54356999)(2351001)(50986999)(33656002)(105586002)(68736007)(5640700001)(3660700001)(87936001)(97736004)(305945005)(7846002)(110136003)(74316002)(3280700002)(450100001)(7736002)(189998001)(107886002)(15650500001)(4001150100001)(76576001)(2906002)(2900100001)(86362001)(102836003)(6116002)(77096005)(230783001)(92566002)(8676002)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.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) 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-originalarrivaltime: 15 Nov 2016 10:18:06.6056 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: Subject: [QUIC] FW: New Version Notification for draft-bishop-quic-http-and-qpack-00.txt X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 10:18:15 -0000 QXMgcHJvbWlzZWQsIEkndmUgcHVsbGVkIHNvbWUgb2YgbXkgdGhvdWdodHMgYW5kIHRoZSBvdXRw dXQgb2Ygc2V2ZXJhbCBzaWRlIGNvbnZlcnNhdGlvbnMgaW50byBhIGRyYWZ0LiAgRmVlZGJhY2sg d2VsY29tZS4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBU dWVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNiA3OjE0IFBNDQpUbzogTWlrZSBCaXNob3AgPE1pY2hh ZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRp b24gZm9yIGRyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrLTAwLnR4dA0KDQoNCkEgbmV3 IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjay0wMC50eHQN CmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTWlrZSBCaXNob3AgYW5kIHBvc3Rl ZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtYmlzaG9wLXF1aWMtaHR0 cC1hbmQtcXBhY2sNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlIVFRQIG92ZXIgUVVJQyAtIE1hcHBp bmcgYW5kIEhlYWRlciBDb21wcmVzc2lvbg0KRG9jdW1lbnQgZGF0ZToJMjAxNi0xMS0xNQ0KR3Jv dXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTUNClVSTDogICAgICAgICAgICBo dHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmlzaG9wLXF1aWMtaHR0 cC1hbmQtcXBhY2stMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtYmlzaG9wLXF1aWMtaHR0cC1hbmQtcXBhY2svDQpIdG1saXplZDog ICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpc2hvcC1xdWljLWh0dHAt YW5kLXFwYWNrLTAwDQoNCg0KQWJzdHJhY3Q6DQogICBIVFRQLzIgW1JGQzc1NDBdIHVzZXMgSFBB Q0sgW1JGQzc1NDFdIGZvciBoZWFkZXIgY29tcHJlc3Npb24uDQogICBIb3dldmVyLCBIUEFDSyBy ZWxpZXMgb24gdGhlIGluLW9yZGVyIG1lc3NhZ2UtYmFzZWQgc2VtYW50aWNzIG9mIHRoZQ0KICAg SFRUUC8yIGZyYW1pbmcgbGF5ZXIgaW4gb3JkZXIgdG8gZnVuY3Rpb24uICBNZXNzYWdlcyBjYW4g b25seSBiZQ0KICAgc3VjY2Vzc2Z1bGx5IGRlY29kZWQgaWYgcHJvY2Vzc2VkIGJ5IHRoZSByZWNl aXZlciBpbiB0aGUgc2FtZSBvcmRlcg0KICAgYXMgZ2VuZXJhdGVkIGJ5IHRoZSBzZW5kZXIuICBU aGlzIGRyYWZ0IHJlZmluZXMgSFBBQ0sgdG8gbG9vc2VuIHRoZQ0KICAgb3JkZXJpbmcgcmVxdWly ZW1lbnRzIGZvciB1c2Ugb3ZlciBRVUlDDQogICBbSS1ELmhhbWlsdG9uLXF1aWMtdHJhbnNwb3J0 LXByb3RvY29sXSBhbmQgZGVzY3JpYmVzIGNoYW5nZXMgdG8NCiAgIFtJLUQuc2hhZGUtcXVpYy1o dHRwMi1tYXBwaW5nXSB0byBsZXZlcmFnZSB0aGUgbmV3IGNvbXByZXNzaW9uLg0KDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRt bGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0K DQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Tue Nov 15 03:43:23 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A54C12957A for ; Tue, 15 Nov 2016 03:43: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 rTnYuswQ0k4k for ; Tue, 15 Nov 2016 03:43:20 -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 7A8DF129494 for ; Tue, 15 Nov 2016 03:43:20 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id r204so91356095ywb.0 for ; Tue, 15 Nov 2016 03:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Hb8SRAV3+w1B8nZ/KbOUX+nBWYZWkSU8Q0x5IrDgZTA=; b=LDipEI2D2DYim8L7eIZ7ud30N4Y5JLdFs3orBLXxN/RerWwavZpynI8ZNfiuvtv98E pXvmBZQCnWjbyVUIOALSjeP6btOFYSEjBsre5wC1h1XE9G9h/0wJrBgug22eR5aeqGlT 5wOxFoFvzY0mDv0LatM5nPHX24cKzbGmMRqrL+imvEpkwbeB4dRFxY3KxHtYrPUMLPC6 I2fpri8+beFM1petyAlGXFlxe9nPoNRILLkhjCPEl/W2L8eeD2Yo7NnuXZ5zalSP5j64 lsTT4zQ2thVbbmE7ZaAgj2cFqgxNj4hFeU6a4NOb0DlJJO+tbdkiCDVnlTzq+drgx9Zp 1Ewg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Hb8SRAV3+w1B8nZ/KbOUX+nBWYZWkSU8Q0x5IrDgZTA=; b=I4zoQpLBxupBQKur8tdpIhpfTmO3YdOt2vwkkiw/77ik5UwsWfCYyMTy4r4cnp8fjL Lluc94/ravW5k3ZFhrNLfzXEYCXA1i18R5uuXWE1ziFjRQaLvbLyev76gKAdzjhmJ08l MgXMEt2jXVTmMqBL966jTkEPQe9uQU3JnjOngWgennv8JsQON2rxFIYU1s/xxSqo1Gf4 K1Dtrr2a6Abp/Fn4DBi/76xoKd8fWFxi00iK9xW38UGb5b/OQmLXwe0eWHKdsgva0jwe +FoA4GQgg3lwYCp6NkRTcZe8CDte0V+nqoy3ob8wxUHSAhn/CKtaXzAcGzz8M+wDy9au 35Uw== X-Gm-Message-State: ABUngvfB6yLT8biB426eGLzRnCSRJFXKJDjTgPK9JOlAivI9ezDxShNWiDQDEh/x++E8yyalRxue9um//UrBmg== X-Received: by 10.13.231.129 with SMTP id q123mr1284396ywe.19.1479210199791; Tue, 15 Nov 2016 03:43:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.170.79 with HTTP; Tue, 15 Nov 2016 03:43:19 -0800 (PST) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Tue, 15 Nov 2016 20:43:19 +0900 Message-ID: To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=94eb2c07639281bf7505415576cf Archived-At: Cc: IETF QUIC WG , =JeffH Subject: Re: [QUIC] "No such list quic-issues" ? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 11:43:22 -0000 --94eb2c07639281bf7505415576cf Content-Type: text/plain; charset=UTF-8 And just to be clear ... On Tue, Nov 15, 2016 at 11:44 AM, Eggert, Lars wrote: > On 2016-11-15, at 10:09, =JeffH wrote: > > fyi/fwiw, clicking on "issue announce list" < > https://www.ietf.org/mailman/listinfo/quic-issues> just now within < > https://github.com/quicwg/wg-materials/blob/master/CONTRIBUTING.md> > yielded "No such list quic-issues" > > The list has not been set up yet. Hang tight. I asked Lars and Mark to wait until the community heard about the github plan to set up the mailing list, in case there were strong objections. I've never met anyone at the IETF who looks forward to https://en.wikipedia.org/wiki/Fait_Accompli. I approved it less than one minute after Lars requested it. Spencer, as responsible AD --94eb2c07639281bf7505415576cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
And just to be clear ...

On Tue, Nov 15, 2016 at 11:44 AM, Eggert, Lars <lars= @netapp.com> wrote:
On 2016-11-15, at 10:09, =3DJeffH <Je= ff.Hodges@KingsMountain.com> wrote:
> fyi/fwiw, clicking on "issue announce list" <https://www.ietf.org/mailman/listinfo/quic-issues> = just now within <https://github= .com/quicwg/wg-materials/blob/master/CONTRIBUTING.md> yiel= ded "No such list quic-issues"

The list has not been set up yet. Hang tight.

<= /div>
I asked Lars and Mark to wait until the community heard about the= github plan to set up the mailing list, in case there were strong objectio= ns.

I've never met anyone at the IETF who look= s forward to https:= //en.wikipedia.org/wiki/Fait_Accompli.

I appro= ved it less than one minute after Lars requested it.

Spencer, as responsible AD
--94eb2c07639281bf7505415576cf-- From nobody Tue Nov 15 05:17:58 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357C4129540 for ; Tue, 15 Nov 2016 05:17:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gqpkgfsfRpph for ; Tue, 15 Nov 2016 05:17:54 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (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 B6A36129460 for ; Tue, 15 Nov 2016 05:17:54 -0800 (PST) Received: from dhcp-91b4.meeting.ietf.org (unknown [31.133.145.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6429750A88; Tue, 15 Nov 2016 08:17:50 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Mark Nottingham In-Reply-To: <9ECEB2F9-3EB3-484E-A78D-0DAE7484B04D@netapp.com> Date: Tue, 15 Nov 2016 22:17:46 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: <877f85b5rv.fsf@alice.fifthhorseman.net> <9ECEB2F9-3EB3-484E-A78D-0DAE7484B04D@netapp.com> To: Lars Eggert X-Mailer: Apple Mail (2.3251) Archived-At: Cc: IETF QUIC WG , =JeffH Hodges , Daniel Kahn Gillmor Subject: Re: [QUIC] Working process / contribution policy for the QUIC WG -- comments? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 15 Nov 2016 13:17:57 -0000 +1 > On 15 Nov. 2016, at 4:36 pm, Eggert, Lars wrote: > > On 2016-11-15, at 15:45, Daniel Kahn Gillmor wrote: >> Also, there is apparently https://github.com/ietf-quic, which contains >> (i think) an older version of the charter. > > IMO we can just delete that. > > Lars -- Mark Nottingham https://www.mnot.net/ From nobody Tue Nov 15 18:53:27 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF902129566 for ; Tue, 15 Nov 2016 18:53:25 -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, 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 dRo7BZGa8Kze for ; Tue, 15 Nov 2016 18:53:23 -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 2F926129529 for ; Tue, 15 Nov 2016 18:53:23 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id r204so115887800ywb.0 for ; Tue, 15 Nov 2016 18:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to; bh=Eyd2JDPAl0nAMYBMGd0UNkq5e+7527MQ1npo5uuBUrc=; b=T+mE2tk6Rl/APAZ0YR2J3NWTEjdPGc1j0ubKElfHx5J50nsYzhWibxsURgnobSGdEF E127FvuRb4bcFqAJM6uRBq2c/VUxTcXNSYVJHcmwKoaVBf2iMRA5olthKikBb1lJWFsg dJ2eFqFnNhAEclg8ZPt02lo0dctCnCjwJsihlEuhb9jIwG025W5oCqdCWYGYVod53oC2 grQrh7apQQNd7ASNcgZlKv4jiUFeBLYG+y1ptSJ/KtYCx8R02dmj976djWvNJ9lAZ1c1 L+Xwebf87BSEkN1ceqaGJhZQW5vUo57FmEwqfK8hWjF+MPPtAapZPuq1hVgrJYEzGREc 39vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=Eyd2JDPAl0nAMYBMGd0UNkq5e+7527MQ1npo5uuBUrc=; b=i7DLSbHWK0pGZJW/CLWtCwoL35kSC+dnlKOQqQUiFJ532vqkzcMzajJgeG0Jfk9/bG 2CVR4Lxh9HJf1NIfaPpGiXN+CENPXi+fEn52bvDdfeyUTJ6jX1VfmL6fqbEMh5uuC0cP cjULA8jFPSVAieADH/qhy8QXNDfSUc8tapX7Sj9EcY/IeSfCiKxl60NQNJijsqFadh52 0Uj9UHQNt1DTm/g4fIl/OcU9U5f/qYTykehab3B68qHr/MqrqtCZqvejjR+u+wowWeEF 4v9YDWtEuh8+5QF/cLUj4J+dqXQNMUz5ggxqCy8iv7rKxF57ZFHImBwW6B0dt7JodZWR MeXA== X-Gm-Message-State: ABUngveEyzjWVbDoHfTAxnrwzbIGawRye/nIAaRXO7xQZSm9SQFu3nNAZ62aGsbaGNB2QTsNP4dm1XBnb1x0Nw== X-Received: by 10.129.53.194 with SMTP id c185mr458748ywa.205.1479264802133; Tue, 15 Nov 2016 18:53:22 -0800 (PST) MIME-Version: 1.0 Sender: jim.roskind@gmail.com Received: by 10.129.91.136 with HTTP; Tue, 15 Nov 2016 18:53:21 -0800 (PST) From: Jim Roskind Date: Tue, 15 Nov 2016 18:53:21 -0800 X-Google-Sender-Auth: uRI1g2BAe5P-0kKBKupcTXKrIj8 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114214780f5b0e0541622d95 Archived-At: Subject: [QUIC] Review of draft-hamilton-quic-transport-protocol-01 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 16 Nov 2016 02:53:26 -0000 --001a114214780f5b0e0541622d95 Content-Type: text/plain; charset=UTF-8 I've provided a set of section comments below, separated by lines of hyphens. As I've mentioned, I'd be pleased to serve as an an additional editor for this document, especially considering the years I spent working on this protocol. Although I don't expect to be present at the impending IETF meeting, I'm hopeful that I'll be able to attend future meetings and continue my participation. Thanks, Jim Note: Opinions expressed are mine, and not that of my employer. ------------------ Section 3: A QUIC Overview One of the key features of QUIC is missing from the list: "QUIC (UDP) packets are individually encrypted, and decryptable." This is in sharp contrast with routine use of TLS over TCP, where encryption blocks are not aligned with IP packet boundaries. This QUIC feature of aligning expected loss of packets (full UDP packets generally survive, or are lost) is critical to avoiding head-of-line blocking, in the face of packet loss. Section 3.3 discusses head-of-line blocking in the context of TCP streaming, but but does not mention the potential impact of (larger) encryption blocks on packet loss recovery. Even if TCP did not require sequential exposure of the stream (inducing head-of-line blocking), the requirement for full TLS blocks to be decrypted would generally cause even a single IP packet loss to delay data contained in a multitude of related packets. It is plausible that the above information should be added to section 3.3, but I'd suggest that it merits a separate bullet point, and section. It represents a rather significant and innovative intertwining of the encryption activity, with the packetization (relative to the status quo). Section 3.3 currently only discusses the intertwining of stream multiplexing, with packetization. It is also plausible that mention should be made of the fact that QUIC uses encryption algorithms that don't use cipher-block-chaining, which is again critical to the independent decryption of each packet (independent of losses of other packets). I'd argue that this point should be mentioned in the same section, which ever one that is. -------------------- Section 3.4 doesn't expand on another key element: "When a QUIC packet is lost, rather than retransmitting the now aging packet with its old packet number, the data in missing packet is optionally rebundled in a future packets with a new packet number." This feature allows a QUIC transmitter to significantly compress specification of a packet number in a QUIC packet header, supplying only the low-order-bits of a packet number. When combined with the cryptographic authentication which keys on the complete packet number, any old, resurrected, or previously assumed-to-be-lost packet, routinely fails authentication, and is automatically discarded. The above is hinted at with the second section of 3.4, but it is pretty important to understanding QUIC, and probably should be pulled out to either a new section, or a second paragraph of the existing overview section. -------------------- Section 3.7 probably overstates and understates aspects of a Connection ID. The understatement should perhaps expand to note that the connection ID serves to encode the name of the connection and all state (negotiated version, crypto settlement, congestion avoidance algorithm agreement, etc.), independent of changes in transport details, such as source IP or port number. This compact encoding allows ongoing data packets to be very efficiently packed, without need for perpetual restatement of the state. The possible overstatement is that "The connection ID remains consistent across ..." The intent of the design of QUIC was for the connection ID to encode the state, but it may, upon agreement by both endpoints, it may vary across the life of the connection. It could be that later discussion in section 4.1 discussion is enough, but I suspect that the current use of the singular phrase: "The connection ID" along with the word "consistent," suggests that the connection ID is "invariant," which would be confusing to readers of this overview. Suggestion: Perhaps remove the entire trailing sentence in section 3.7. Perhaps change the sentence to optionally pluralize the subject, and use a word other than "consistent," such as: "The connection ID(s) used in a QUIC connection can specify a connection independent of changes in the client's and the server's network addresses." -------------------- Section 4.2.1: IMO, the four bullets are confusing, because they are written backwards from the what I consider the intent. For example, the fourth bullet would read better as: "When a sender has more than (2^6) packets in flight, it MUST set the PACKET_SIZE_NUMBER to 01, 10, or 11." The point is that the decision about the PACKET_NUMBER_SIZE is based upon the current amount of potential ambiguity in the packet number interpretation. I found reading it the other way (as currently written) confusing, though it may be logically equivalent. ------------------- Section 4.2.1: Consider removing the DISCUSS comment asking "Should a receiver enforce ..." If the receiver is able to authenticate and decrypt a packet, then it should dod so. I would note that the algorithm for extending a truncated packet number to a complete packet number is given explicitly, so I don't believe any heroic efforts should be taken beyond that algorithm (though if some better(?) quality implementation emerges, there seems no reason to preclude it). Given the potential loss of packets, it probably becomes untestable to standardize on such a "receiver enforcement rule." Old packets can arrive at any time in the future, but the receiver should not take enforcement actions (e.g., connection termination? signal an error?) when they are observed. -------------------- Section 5.2.2: There should be discussion about when a STK can be reused at more than one site (for more than one hostname). This feature, significantly accelerating connectivity to applicable hosts, is visible in the open source code of Chromium, but appears unmentioned in the this document. -------------------- Section 5.2.3: I think it is too strong to say "The crypto handshake MUST ensure that the final negotiated key is unique for every connection between two endpoints." This should be a probabilistic guarantee, and should not require saving all keys for all time, to achieve currently stated result (re: unique). -------------------- section 5.2.3: Discussion should be included of packet padding in the first packet sent, as this combats any amplification attack. Specifically, "The CHLO packet MUST be at least NNNN bytes, whether due to data content, or via padding." I'd suggest adding it as one of the bullets, as it should be independent of the encryption method used. -------------------- Section 5.4: Item 3: A public reset was not intended for use in the given example, where a machine reboots and loses cryptographic state. Public reset was intended for use when the crypto state is known, and can affirmatively be indicated with an authenticated Public Reset. When folks eventually(?) get around to supporting an authenticated Public reset (authentication required!), this example will be unachievable. As a result, it should probably be removed. -------------------- Section 6.2: The indicated defense against an opportunistic ack attack, via skipping packets, is potentially very expensive in terms of bandwidth in the reverse direction. It should be hoped that such defense will only be employed when the congestion window is large, and hence when many responsive ACK frames are in flight. In such a case, an honest client will waste a fair amount of bandwidth in the reverse direction (all ACKs for the duration of one RTT will specify the missing packet). Is this desirable? -------------------- Section 7, Paragraph 1. I don't believe RFC4821 (PMTU) is generally workable, as I don't believe ICMP packets would be properly routed to the host computer (recall there is only a potentially NATed UDP connection), and the host computer generally does not even expect ICMP packets to arrive that relate to a UDP sequence (I haven't seen library calls that could access such data in the OS). I think PMTU is only (currently) applicable to TCP. Discussion can/should/could be added to indicate that QUIC can perform MTU exploration, but I don't believe ICMP (and PMTU) would come into play. -------------------- Section 8.4, bullet 2: Please provide some motivation for excluding additional streams from both stream and connection flow control. -------------------- Section 9.1: Can you explain how the deadlock can be achieved, other than by a faulty implementation? Notification of available window space should eventually be acked, or retransmitted. What is the issue here? If this is not possible, with a working implementation, it probably should not be mentioned. -------------------- Section 11.1: line 2: typo s/attacked/attacker/ -------------------- Section 14.3: The reference to my design document is sadly encoded with a flavor of a TinyURL. Please add the following text (analogously to the way that QUIC-CRYPTO is referenced 2 lines above): [1] Roskind, J. "QUIC: Design Document and Specification Rationale", May 2015 https://goo.gl/dMVtFi - -------------------------- Thanks! --001a114214780f5b0e0541622d95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've provided a set of section comments below, se= parated by lines of hyphens.

As I've mentioned= , I'd be pleased to serve as an an additional editor for this document,= especially considering the years I spent working on this protocol.

Although I don't expect to be present at the impendin= g IETF meeting, I'm hopeful that I'll be able to attend future meet= ings and continue my participation.

Thanks,
<= div>
Jim

Note: Opinions expressed ar= e mine, and not that of my employer.


------------------

Section 3: A QUIC Overview
One of the key features of QUIC is missing from the list:=C2=A0=

"QUIC (UDP) packets are individually encrypt= ed, and decryptable."

This is in sharp contra= st with routine use of TLS over TCP, where encryption blocks are not aligne= d with IP packet boundaries.=C2=A0 This QUIC feature of aligning expected l= oss of packets (full UDP packets generally survive, or are lost) is critica= l to avoiding head-of-line blocking, in the face of packet loss.=C2=A0

Section 3.3 discusses head-of-line blocking in the con= text of TCP streaming, but but does not mention the potential impact of (la= rger) encryption blocks on packet loss recovery.=C2=A0 Even if TCP did not = require sequential exposure of the stream (inducing head-of-line blocking),= the requirement for full TLS blocks to be decrypted would generally cause = even a single IP packet loss to delay data contained in a multitude of rela= ted packets.

It is plausible that the above inform= ation should be added to section 3.3, but I'd suggest that it merits a = separate bullet point, and section. It represents a rather significant and = innovative intertwining of the encryption activity, with the packetization = (relative to the status quo).=C2=A0 Section 3.3 currently only discusses th= e intertwining of stream multiplexing, with packetization.

It is also plausible that mention should be made of the fact that = QUIC uses encryption algorithms that don't use cipher-block-chaining, w= hich is again critical to the independent decryption of each packet (indepe= ndent of losses of other packets). I'd argue that this point should be = mentioned in the same section, which ever one that is.

=
--------------------

Section 3.4 doesn't = expand on another key element:=C2=A0

"When a = QUIC packet is lost, rather than retransmitting the now aging packet with i= ts old packet number, the data in missing packet is optionally rebundled in= a future packets with a new packet number."

= This feature allows a QUIC transmitter to significantly compress specificat= ion of a packet number in a QUIC packet header, supplying only the low-orde= r-bits of a packet number.=C2=A0 When combined with the cryptographic authe= ntication which keys on the complete packet number, any old, resurrected, o= r previously assumed-to-be-lost packet, routinely fails authentication, and= is automatically discarded.

The above is hinted a= t with the second section of 3.4, but it is pretty important to understandi= ng QUIC, and probably should be pulled out to either a new section, or a se= cond paragraph of the existing overview section.

-= -------------------

Section 3.7 probably overs= tates and understates aspects of a Connection ID. =C2=A0

The understatement should perhaps expand to note that the connection= ID serves to encode the name of the connection and all state (negotiated v= ersion, crypto settlement, congestion avoidance algorithm agreement, etc.),= independent of changes in transport details, such as source IP or port num= ber.=C2=A0 This compact encoding allows ongoing data packets to be very eff= iciently packed, without need for perpetual restatement of the state.
=

The possible overstatement is that=C2=A0

=
"The connection ID remains consistent across ..." =C2= =A0

The intent of the design of QUIC was for the c= onnection ID to encode the state, but it may, upon agreement by both endpoi= nts, it may vary across the life of the connection.=C2=A0 It could be that = later discussion in section 4.1 discussion is enough, but I suspect that th= e current use of the singular phrase:

"The co= nnection ID"=C2=A0

along with the word "= consistent," suggests that the connection ID is "invariant,"= which would be confusing to readers of this overview. =C2=A0
Suggestion: Perhaps =C2=A0remove the entire trailing sentence i= n section 3.7. =C2=A0 Perhaps change the sentence to optionally pluralize t= he subject, and use a word other than "consistent," such as:=C2= =A0

"The connection ID(s) used in a QUIC conn= ection can specify a connection independent of changes in the client's = and the server's network addresses."

----= ----------------

Section 4.2.1: IMO, the four = bullets are confusing, because they are written backwards from the what I c= onsider the intent.=C2=A0 For example, the fourth bullet would read better = as:

"When a sender has more than (2^6) packet= s in flight, it MUST set the PACKET_SIZE_NUMBER to 01, 10, or 11."

The point is that the decision about the PACKET_NUMBE= R_SIZE is based upon the current amount of potential ambiguity in the packe= t number interpretation. I found reading it the other way (as currently wri= tten) confusing, though it may be logically equivalent.

-------------------

Section 4.2.1: Consider = removing the =C2=A0DISCUSS comment =C2=A0asking "Should a receiver enf= orce ..."

If the receiver is able to authenti= cate and decrypt a packet, then it should dod so.=C2=A0 I would note that t= he algorithm for extending a truncated packet number to a complete packet n= umber is given explicitly, so I don't believe any heroic efforts should= be taken beyond that algorithm (though if some better(?) quality implement= ation emerges, there seems no reason to preclude it). Given the potential l= oss of packets, it probably becomes untestable to standardize on such a &qu= ot;receiver enforcement rule." =C2=A0Old packets can arrive at any tim= e in the future, but the receiver should not take enforcement actions (e.g.= , connection termination? signal an error?) when they are observed.


--------------------

Section 5.2.2: There should be discussion about when a STK can be r= eused at more than one site (for more than one hostname).=C2=A0 This featur= e, significantly accelerating connectivity to applicable hosts, is visible = in the open source code of Chromium, but appears unmentioned in the this do= cument.

--------------------

Section 5.2.3: I think it is too strong to say "The crypto han= dshake MUST ensure that the final negotiated key is unique for every connec= tion between two endpoints." =C2=A0This should be a probabilistic guar= antee, and should not require saving all keys for all time, to achieve curr= ently stated result (re: unique).


-= -------------------

section 5.2.3: Discus= sion should be included of packet padding in the first packet sent, as this= combats any amplification attack.=C2=A0 Specifically, "The CHLO packe= t MUST be at least NNNN bytes, whether due to data content, or via padding.= " I'd suggest adding it as one of the bullets, as it should be ind= ependent of the encryption method used.

= --------------------


Section 5.= 4: Item 3: A public reset was not intended for use in the given example, wh= ere a machine reboots and loses cryptographic state. Public reset was inten= ded for use when the crypto state is known, and can affirmatively be indica= ted with an authenticated Public Reset. When folks eventually(?) get around= to supporting an authenticated Public reset (authentication required!), th= is example will be unachievable.=C2=A0 As a result, it should probably be r= emoved.


--------------------

Section 6.2: =C2=A0The indicated defense against an = opportunistic ack attack, via skipping packets, is potentially very expensi= ve in terms of bandwidth in the reverse direction.=C2=A0 It should be hoped= that such defense will only be employed =C2=A0when the congestion window i= s large, and hence when many responsive ACK frames are in flight.=C2=A0 In = such a case, an honest client will waste a fair amount of bandwidth in the = reverse direction (all ACKs for the duration of one RTT will specify the mi= ssing packet).=C2=A0 Is this desirable?

----------= ----------

Section 7, Paragraph 1.=C2=A0 I don= 't believe RFC4821 (PMTU) is generally workable, as I don't believe= ICMP packets would be properly routed to the host computer (recall there i= s only a potentially NATed UDP connection), and the host computer generally= does not even expect ICMP packets to arrive that relate to a UDP sequence = (I haven't seen library calls that could access such data in the OS).= =C2=A0 I think PMTU is only (currently) applicable to TCP.

Discussion can/should/could be added to indicate that QUIC can per= form MTU exploration, but I don't believe ICMP (and PMTU) would come in= to play.


--------------------
Section 8.4, bullet 2: Please provide some motivation for excl= uding additional streams from both stream and connection flow control.

--------------------

Sect= ion 9.1: Can you explain how the deadlock can be achieved, other than by a = faulty implementation?=C2=A0 Notification of available window space should = eventually be acked, or retransmitted.=C2=A0 What is the issue here? If thi= s is not possible, with a working implementation, it probably should not be= mentioned.


--------------------

Section 11.1: line 2: typo =C2=A0 s/attacked/att= acker/

--------------------


Section 14.3: =C2=A0The reference to my design docume= nt is sadly encoded with a flavor of a TinyURL.=C2=A0 Please add the follow= ing text (analogously to the way that QUIC-CRYPTO is referenced 2 lines abo= ve):

[1]
=C2=A0 =C2=A0 =C2=A0 Roskind, J= . "QUIC: Design Document and Specification Rationale", May 2015
=C2=A0 =C2=A0 =C2=A0=C2=A0https://goo.gl/dMVtFi


---------------------------


= Thanks!






















--001a114214780f5b0e0541622d95-- From nobody Tue Nov 15 21:26:05 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD211295A0 for ; Tue, 15 Nov 2016 21:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gc9hebiWYhK for ; Tue, 15 Nov 2016 21:26:02 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FC312950E for ; Tue, 15 Nov 2016 21:26:02 -0800 (PST) Received: from dhcp-8ca2.meeting.ietf.org (unknown [31.133.140.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 1953B22E253 for ; Wed, 16 Nov 2016 00:25:55 -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 10.1 \(3251\)) Message-Id: <66EE74A0-C892-4BBD-9F88-70F3D9AC0BA4@mnot.net> Date: Wed, 16 Nov 2016 14:25:53 +0900 To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [QUIC] Adopting four drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 16 Nov 2016 05:26:05 -0000 As discussed in the Working Group meeting yesterday, we believe we're = ready to adopt the input documents mentioned in our charter as a = starting point for our work: - draft-hamilton-quic-transport-protocol-01 - draft-iyengar-quic-loss-recovery-01 - draft-thomson-quic-tls-01 - draft-shade-quic-http2-mapping-00 We saw a high level of consensus in the room for adopting all of them = (with noted discussions around the potential need to make significant = changes and fill in details). Our charter states that the contents of these documents will *not* have = assumed consensus; we are merely deciding to use them as a starting = point, and their contents can (and will) change substantially as we = gather it. Please raise any concerns about doing so on list soon; we'd like to get = started, and as stated above, agreeing to adopt these isn't conferring = any special status upon their contents, other than being the starting = point for our discussions. Cheers, Your chairs, Mark and Lars From nobody Tue Nov 15 21:28:00 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BF0A129472 for ; Tue, 15 Nov 2016 21:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] 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 FMwq7aNSyOr0 for ; Tue, 15 Nov 2016 21:27:57 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91636129467 for ; Tue, 15 Nov 2016 21:27:57 -0800 (PST) Received: from dhcp-87bd.meeting.ietf.org (dhcp-87bd.meeting.ietf.org [31.133.135.189]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 2377F2421249; Wed, 16 Nov 2016 05:27:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Jim Reid In-Reply-To: <66EE74A0-C892-4BBD-9F88-70F3D9AC0BA4@mnot.net> Date: Wed, 16 Nov 2016 05:27:51 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <7FF1C170-31A1-4C04-BE00-F0A2CFA89C2D@rfc1035.com> References: <66EE74A0-C892-4BBD-9F88-70F3D9AC0BA4@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3124) Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Adopting four drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 16 Nov 2016 05:27:58 -0000 > On 16 Nov 2016, at 05:25, Mark Nottingham wrote: >=20 > As discussed in the Working Group meeting yesterday, we believe we're = ready to adopt the input documents mentioned in our charter as a = starting point for our work: >=20 > - draft-hamilton-quic-transport-protocol-01 > - draft-iyengar-quic-loss-recovery-01 > - draft-thomson-quic-tls-01 > - draft-shade-quic-http2-mapping-00 I support the adoption of all four drafts as initial work items for the = WG. From nobody Tue Nov 15 21:35:56 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2EF1294D4 for ; Tue, 15 Nov 2016 21:35:54 -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 3fdAUitfetm4 for ; Tue, 15 Nov 2016 21:35:53 -0800 (PST) Received: from mx0a-00115401.pphosted.com (mx0a-00115401.pphosted.com [67.231.145.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 86EC0129481 for ; Tue, 15 Nov 2016 21:35:52 -0800 (PST) Received: from pps.filterd (m0000553.ppops.net [127.0.0.1]) by mx0a-00115401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uAG5XohC027481; Wed, 16 Nov 2016 00:35:52 -0500 Received: from hnse9.hns.com ([208.236.67.251]) by mx0a-00115401.pphosted.com with ESMTP id 26p4xqexh8-1 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Wed, 16 Nov 2016 00:35:52 -0500 Received: from mail.hughes.com ([139.85.53.235]) by hnse9.hns.com (Sentrion-MTA-4.2.0/Sentrion-MTA-4.2.0) with ESMTP id uAG5ZZuv022731 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 16 Nov 2016 00:35:35 -0500 Received: from EXPEXCHYB1.hughes.com (139.85.53.235) by EXPEXCHYB1.hughes.com (139.85.53.235) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Wed, 16 Nov 2016 00:35:35 -0500 Received: from EXPEXCCAS3.hughes.com (139.85.53.23) by EXPEXCHYB1.hughes.com (139.85.53.235) with Microsoft SMTP Server (TLS) id 15.0.1156.6 via Frontend Transport; Wed, 16 Nov 2016 00:35:35 -0500 Received: from EXCMAIL3.hughes.com ([fe80::d5f:115:6cf:7c1f]) by EXPEXCCAS3.hughes.com ([2002:8b55:3517::8b55:3517]) with mapi id 14.03.0279.002; Wed, 16 Nov 2016 00:35:35 -0500 From: "Border, John" To: Mark Nottingham Thread-Topic: [QUIC] Adopting four drafts Thread-Index: AQHSP8oAFU4oi0bpOE6BG6Ebg8RpRqDbaJaA//+uQRA= Date: Wed, 16 Nov 2016 05:35:33 +0000 Message-ID: <8593B383C0D0EF41ACD6832A6C051AA314F4FADB@EXCMAIL3.hughes.com> References: <66EE74A0-C892-4BBD-9F88-70F3D9AC0BA4@mnot.net> <7FF1C170-31A1-4C04-BE00-F0A2CFA89C2D@rfc1035.com> In-Reply-To: <7FF1C170-31A1-4C04-BE00-F0A2CFA89C2D@rfc1035.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.15.254] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-15_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611160097 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Adopting four drafts X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 16 Nov 2016 05:35:54 -0000 +1 -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jim Reid Sent: Wednesday, November 16, 2016 12:28 AM To: Mark Nottingham Cc: quic@ietf.org Subject: Re: [QUIC] Adopting four drafts > On 16 Nov 2016, at 05:25, Mark Nottingham wrote: >=20 > As discussed in the Working Group meeting yesterday, we believe we're rea= dy to adopt the input documents mentioned in our charter as a starting poin= t for our work: >=20 > - draft-hamilton-quic-transport-protocol-01 > - draft-iyengar-quic-loss-recovery-01 > - draft-thomson-quic-tls-01 > - draft-shade-quic-http2-mapping-00 I support the adoption of all four drafts as initial work items for the WG. From nobody Fri Nov 18 01:51:32 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D065B129670 for ; Fri, 18 Nov 2016 01:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm80LVPWqwSA for ; Fri, 18 Nov 2016 01:51:27 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 189C6129674 for ; Fri, 18 Nov 2016 01:51:27 -0800 (PST) Received: from [192.168.220.46] (unknown [116.84.50.28]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 637B322E1F3; Fri, 18 Nov 2016 04:51:08 -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 10.1 \(3251\)) Message-Id: <192E53E7-30D3-4DF0-99E6-6F82A09A171F@mnot.net> Date: Fri, 18 Nov 2016 18:51:04 +0900 To: IETF QUIC WG X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Lars Eggert Subject: [QUIC] ROUGH minutes from IETF97 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 18 Nov 2016 09:51:30 -0000 ... are at: https://github.com/quicwg/wg-materials/blob/master/ietf97/minutes.md Please have a look and suggest any corrections to the list (or as pull = requests). Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Nov 22 03:35:17 2016 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 A06F6129DD3; Tue, 22 Nov 2016 03:35:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147981451465.9291.11411938103210777210.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2016 03:35:14 -0800 Archived-At: Subject: [QUIC] The QUIC WG has placed draft-hamilton-quic-transport-protocol in state "Candidate for WG Adoption" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-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, 22 Nov 2016 11:35:15 -0000 The QUIC WG has placed draft-hamilton-quic-transport-protocol in state Candidate for WG Adoption (entered by Lars Eggert) The document is available at https://datatracker.ietf.org/doc/draft-hamilton-quic-transport-protocol/ From nobody Tue Nov 22 03:35:43 2016 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 AE91E129DE9; Tue, 22 Nov 2016 03:35:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147981454071.9163.17641049600195895548.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2016 03:35:40 -0800 Archived-At: Subject: [QUIC] The QUIC WG has placed draft-iyengar-quic-loss-recovery in state "Candidate for WG Adoption" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-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, 22 Nov 2016 11:35:41 -0000 The QUIC WG has placed draft-iyengar-quic-loss-recovery in state Candidate for WG Adoption (entered by Lars Eggert) The document is available at https://datatracker.ietf.org/doc/draft-iyengar-quic-loss-recovery/ From nobody Tue Nov 22 03:36:09 2016 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 00F471295AA; Tue, 22 Nov 2016 03:36:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147981456499.9171.1516000017390241364.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2016 03:36:04 -0800 Archived-At: Subject: [QUIC] The QUIC WG has placed draft-shade-quic-http2-mapping in state "Candidate for WG Adoption" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-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, 22 Nov 2016 11:36:05 -0000 The QUIC WG has placed draft-shade-quic-http2-mapping in state Candidate for WG Adoption (entered by Lars Eggert) The document is available at https://datatracker.ietf.org/doc/draft-shade-quic-http2-mapping/ From nobody Tue Nov 22 03:36:46 2016 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 58E95129DF2; Tue, 22 Nov 2016 03:36:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.38.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147981459535.9243.18284431270166535130.idtracker@ietfa.amsl.com> Date: Tue, 22 Nov 2016 03:36:35 -0800 Archived-At: Subject: [QUIC] The QUIC WG has placed draft-thomson-quic-tls in state "Candidate for WG Adoption" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-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, 22 Nov 2016 11:36:35 -0000 The QUIC WG has placed draft-thomson-quic-tls in state Candidate for WG Adoption (entered by Lars Eggert) The document is available at https://datatracker.ietf.org/doc/draft-thomson-quic-tls/ From nobody Tue Nov 22 07:09:15 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73624129A47 for ; Tue, 22 Nov 2016 07:09: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, 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 tJVNsOQGJxMb for ; Tue, 22 Nov 2016 07:09:13 -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 48E1312966C for ; Tue, 22 Nov 2016 07:09:13 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id j65so69612501iof.0 for ; Tue, 22 Nov 2016 07:09:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=+mIOeip4EyeAQFI300ffA5pK+T43rtPmpj+CgeUSxRg=; b=0TMiF8pzy1y8CxriCdwJTL5YQK+83Dhzt0Ya6x9Aq5rIMVg+l5Z+KKzS1k/gKyC5Ry vkfZlq3hLWs7PGTfMj/ul+Qv1RS8c4+q8f5a9EcMGSbpdMr6SfJbD9kTD5WhJvA/YpDB 66C0qCZXUkfCHSvY685SUrPmDqhI5j6TUhG6roIElOJLZe1vemvCIH1NlwMpq8A8AHdS r8gcx2t8olnPQoSV+GXHJG3/VeorqyPZOzwy0qMRx/F6JDdw6rQ/0xDN0ugAr1Vnr1Ep +HBOe5lDCUPYk4ykvLnM1jHkJ6ngEwk15fv2qbngteiu8lUbQumNAjwcHEDQ4YRaVEM1 hPXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+mIOeip4EyeAQFI300ffA5pK+T43rtPmpj+CgeUSxRg=; b=jf+1QT1eHOf8np9gYyF/MjDgPXKvUKDRRpT/NsdHUZmZ44CnVbmg8vnK4AN5YYU1oH Xv/Cn84kEdJb7bciIcvp+Q1W7Jc8mJDbF0YyKmtI7cnEGZkydcNm7lXy6lDhU2cBWoGZ A3sQtgzvF5XkTGNwiZxFth24yC/H1gwjTN+6b3gfJ5+bQWQ89lMzxcNKdBzCMLk4a3B8 yKx13Lp9ghBP+jjRcQhLJko2kcrAuZvuyEgaIDbzbkDX5brGzv4SoMMjHRdjMmcOZBlY eTOx2bpinzY7aNJJGpDCrBxXON0lQA1J5D+sGwqvqTlRXyOKwADKW/SFXeGPo41/NI++ /OCg== X-Gm-Message-State: AKaTC02mFBRtoHda867Mze8kTb6mz+nDJjOOZ60BsGvzv1sqvv95fvPZseWoXl1t31PK9zfMV2btMYIGAaNdHQ== X-Received: by 10.107.22.6 with SMTP id 6mr19519539iow.8.1479827352457; Tue, 22 Nov 2016 07:09:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.125.138 with HTTP; Tue, 22 Nov 2016 07:09:12 -0800 (PST) From: "Aron ." Date: Tue, 22 Nov 2016 10:09:12 -0500 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=94eb2c05b4eeac17ab0541e52744 Archived-At: Subject: [QUIC] Stream ID: 32 or 31 bits? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 22 Nov 2016 15:09:14 -0000 --94eb2c05b4eeac17ab0541e52744 Content-Type: text/plain; charset=UTF-8 Hello, Section 8.2 (pp. 33-34) of [draft-hamilton-quic-transport-protocol-01] states: Streams are identified by an unsigned 32-bit integer, referred to as the > StreamID. Section 5.1.1 (p. 21) of RFC 7540 says that Streams are identified with an unsigned 31-bit integer. The format of frames QUIC uses on Stream 3 is the same as in HTTP/2, seemingly creating a conflict. Is this a conflict? If so, how do we resolve it? Thanks, Aron. --94eb2c05b4eeac17ab0541e52744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Section 8.2 (pp. 33-3= 4) of [draft-hamilton-quic-transport-protocol-01] states:

Streams are identified by an unsigned 32-bit integer, r= eferred to as the StreamID.

Se= ction 5.1.1 (p. 21) of RFC 7540 says that

Streams are identified with an unsigned 31-bit integer.

The format of frames QUIC uses on Strea= m 3 is the same as in HTTP/2, seemingly creating a conflict.

=
Is this a conflict?=C2=A0 If so, how do we resolve it?

Thanks,

=C2=A0 Aron.
--94eb2c05b4eeac17ab0541e52744-- From nobody Tue Nov 22 09:43:34 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B292F129A65 for ; Tue, 22 Nov 2016 09:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Zm78gGZ46Ph for ; Tue, 22 Nov 2016 09:43:27 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97ED0129A2D for ; Tue, 22 Nov 2016 09:43:27 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id i145so20737151ywg.2 for ; Tue, 22 Nov 2016 09:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hJ46/INr0zSOV+aultU6sy3uTSRdiT821lBq4Kv57Fc=; b=EjbBj/43B2/Kr+tAizjLSdZBhNUMDV8IowmnuVLoj2fTHizMWiZtgwMnimHJSQOAY4 bSyyUFiwlSAutsj7Aq07utb3PGMEeUv2Q8sj+kPeRELyEpczBxub9diUY/6bLxhCjw8A vPuaseG2lgITRSSm6AKd7mW6Jr1tVI7wF6u9FydNhktYyUn6d0eh+PCiU0QpO+pDs6F3 +ie8o46TovVOc4nv2ViuQFwkbZKzys7kkTwUGYWPKnZpn+mg5c1Sis2vwHQNWAlz3lN4 p+MaINJV38V2ZyOFeMXi5cBWUCO20CGw5BHAz+uP6uVHl47aWmGZ9zYOm0QmMrfIoxdI CYwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hJ46/INr0zSOV+aultU6sy3uTSRdiT821lBq4Kv57Fc=; b=H1JYb5kCLozGcVZ0qhz0HsBIcD5IucbmJ87v8/CI8M6uYTNQVb68ZZEY30zw5OAIyc joI3MqRvbLwdvIDApvZixrk/0sqvm2a7hbPlfhyWWTGJ/rEDdbtME97ARi8Ihpg2ER3X PaK9ktyQFtTfMWqZvir1BC60cQ2uAUTP20ybTI0PaPcx3/K21cAuApuEMPgBHA7aIiCW wGkxE2NYMjGc5hPGzClKhXIm6yuiVB39FxrxIocE5ikohrGpB0DysYHcrtUdtXaulLQJ rUHGv6MHayn+oyADCT103PoJEcR5AOPzRKcQFDuXgzXR9Ml1Of5g/3pHjiVPQyTlYOOH Zg4w== X-Gm-Message-State: AKaTC01Ss99QlsoSCfpovMnm99Q6gCmQJmFCASaGd3cnCTMiVYpjXjoMPHD1zbpAallV+phMjeGA1G1ZImy9YFXL X-Received: by 10.129.168.131 with SMTP id f125mr24241680ywh.215.1479836606726; Tue, 22 Nov 2016 09:43:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Tue, 22 Nov 2016 09:43:05 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Tue, 22 Nov 2016 12:43:05 -0500 Message-ID: To: "Aron ." Content-Type: multipart/alternative; boundary=94eb2c13cbe24578700541e74f8c Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] Stream ID: 32 or 31 bits? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 22 Nov 2016 17:43:33 -0000 --94eb2c13cbe24578700541e74f8c Content-Type: text/plain; charset=UTF-8 I think that is something for the HTTP2 mapping document to answer. As long as QUIC has more than enough stream ids to represent the full 31 bit space, I don't anticipate any problems. On Tue, Nov 22, 2016 at 10:09 AM, Aron . wrote: > Hello, > > Section 8.2 (pp. 33-34) of [draft-hamilton-quic-transport-protocol-01] > states: > > Streams are identified by an unsigned 32-bit integer, referred to as the >> StreamID. > > > Section 5.1.1 (p. 21) of RFC 7540 says that > > Streams are identified with an unsigned 31-bit integer. > > > The format of frames QUIC uses on Stream 3 is the same as in HTTP/2, > seemingly creating a conflict. > > Is this a conflict? If so, how do we resolve it? > > Thanks, > > Aron. > --94eb2c13cbe24578700541e74f8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think that is something for the HTTP2 mapping document t= o answer.=C2=A0 As long as QUIC has more than enough stream ids to represen= t the full 31 bit space, I don't anticipate any problems.

On Tue, Nov 22, 2016 at 1= 0:09 AM, Aron . <aron.schats@gmail.com> wrote:
Hello,

<= div>Section 8.2 (pp. 33-34) of [draft-hamilton-quic-transport-protocol= -01] states:

Streams are identified by= an unsigned 32-bit integer, referred to as the StreamID.

Section 5.1.1 (p. 21) of RFC 7540 says that

Streams are identified with an unsigned 3= 1-bit integer.

The forma= t of frames QUIC uses on Stream 3 is the same as in HTTP/2, seemingly creat= ing a conflict.

Is this a conflict?=C2=A0 If so, h= ow do we resolve it?

Thanks,

<= div>=C2=A0 Aron.

--94eb2c13cbe24578700541e74f8c-- From nobody Tue Nov 22 10:41:30 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B413E1294E9 for ; Tue, 22 Nov 2016 10:41:28 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y32TPE_aAIqI for ; Tue, 22 Nov 2016 10:41:27 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0090.outbound.protection.outlook.com [104.47.37.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 31D7B129446 for ; Tue, 22 Nov 2016 10:41: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=iY7fsZI7lwyfeLB5l3kIZWhYqwHd8mbIQkot2pF/PJU=; b=LogAdZ/WtWxtcvXzmQGoa9JrVU/HgiEJqzxYur4Pd35BshktmHwR5C4WV1P8qKwJcJoV/lfLZ4KRkIOfLgRlL293RUpkzkewiZe9f5Q64/u+MWoEPHjN/thIXqOVA5dmYxuEME5BVlZOuxixTNPQBpEDo2Q8UhpApApoSinRj60= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2707.namprd03.prod.outlook.com (10.173.144.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Tue, 22 Nov 2016 18:41:20 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0734.014; Tue, 22 Nov 2016 18:41:20 +0000 From: Mike Bishop To: "Aron ." , "quic@ietf.org" Thread-Topic: [QUIC] Stream ID: 32 or 31 bits? Thread-Index: AQHSRNJoueiQR7WXVES5dhOM17cIwaDlVmNz Date: Tue, 22 Nov 2016 18:41:20 +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=Michael.Bishop@microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [67.197.26.33] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2707; 7:79EdZQKZInUC78QbNbsYyG6B0kJ92c8VghpqJGKl3+uuPeixM/KZRQ4K5UtrjzoAjWrl5Wn2nInvesMLaqe2dmJEaSco6c6QqDVOP8e8S7WtTqfANNyK3TuzU8ASc4sAGrwAiWSwoK+75iwBybd80iuY/wkLzTXjUwA/hqDOg+DuFt7eIU76MZRxNVoRd8LNUJbnO94mrX4eAro3HtrlHC7YHqf1zgpFqQSDq4Pa1yxRlYcFalqP/mlZsyRX+jcihhJb2BuV/KPG0MfWM+GgwSStMu615g29VT/EotZPzHJg2Nhl7u+BZdro7Xjypiv1lS/K/ilDLxA0xYOIqZTkquHKMfDhTcnWa9qKbtzO8496xxy00LEw9A+N0JBk+eix x-ms-office365-filtering-correlation-id: 1388a8b5-4617-4823-e6b8-08d4130726dd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2707; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6040307)(6045199)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6061324)(6041248)(6046074)(6047074)(6072148)(6042181); SRVR:BN6PR03MB2707; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2707; x-forefront-prvs: 0134AD334F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(189002)(105586002)(50986999)(77096005)(106116001)(7696004)(97736004)(106356001)(8990500004)(92566002)(2906002)(76176999)(99286002)(107886002)(3660700001)(33656002)(54356999)(3900700001)(3280700002)(81156014)(102836003)(8676002)(2900100001)(81166006)(6116002)(10090500001)(5005710100001)(10290500002)(3846002)(5660300001)(229853002)(8936002)(5001770100001)(189998001)(6506003)(606004)(101416001)(7736002)(66066001)(2950100002)(7846002)(9686002)(86612001)(122556002)(86362001)(76576001)(68736007)(74316002)(2501003)(38730400001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2707; H:BN6PR03MB2708.namprd03.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708234BAE15E5C73C4F6D2087B40BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2016 18:41:20.1165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2707 Archived-At: Subject: Re: [QUIC] Stream ID: 32 or 31 bits? X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 22 Nov 2016 18:41:29 -0000 --_000_BN6PR03MB2708234BAE15E5C73C4F6D2087B40BN6PR03MB2708namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Only somewhat =96 there are QUIC streams that will never be referenced by t= he current mapping, but since the reverse isn=92t true, that=92s merely sub= -optimal. In my opinion, we fix that by getting rid of the HTTP/2 muxing layer entire= ly and updating the other frames that reference streams to match the size o= f QUIC streams. But we'll need to discuss that. Sent from my Windows 10 phone From: Aron . Sent: Tuesday, November 22, 2016 10:09 AM To: quic@ietf.org Subject: [QUIC] Stream ID: 32 or 31 bits? Hello, Section 8.2 (pp. 33-34) of [draft-hamilton-quic-transport-protocol-01] stat= es: Streams are identified by an unsigned 32-bit integer, referred to as the St= reamID. Section 5.1.1 (p. 21) of RFC 7540 says that Streams are identified with an unsigned 31-bit integer. The format of frames QUIC uses on Stream 3 is the same as in HTTP/2, seemin= gly creating a conflict. Is this a conflict? If so, how do we resolve it? Thanks, Aron. --_000_BN6PR03MB2708234BAE15E5C73C4F6D2087B40BN6PR03MB2708namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Only somewhat =96 there are QUIC streams that will n= ever be referenced by the current mapping, but since the reverse isn=92t tr= ue, that=92s merely sub-optimal.

 

In my opinion, we fix that by getting rid of the HTT= P/2 muxing layer entirely and updating the other frames that reference stre= ams to match the size of QUIC streams.  But we'll need to discuss that= .

 

Sent from my Windows 10 phone

 

From: Aron .
Sent: Tuesday, November 22, 2016 10:09 AM
To: quic@ietf.org
Subject: [QUIC] Stream ID: 32 or 31 bits?

 

Hello,

Section 8.2 (pp. 33-34) of [draft-hamilton-quic-transport-protocol-01]= states:

Streams are identified by an unsigned 32-bit integer, referred to as the St= reamID.

Section 5.1.1 (p. 21) of RFC 7540 says that

Streams are identified with an unsigned 31-bit integer.

The format of frames QUIC uses on Stream 3 is the same as in HTTP/2, s= eemingly creating a conflict.

Is this a conflict?  If so, how do we resolve it?

Thanks,

  Aron.
--_000_BN6PR03MB2708234BAE15E5C73C4F6D2087B40BN6PR03MB2708namp_-- From nobody Tue Nov 22 17:23:04 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A92712950A for ; Tue, 22 Nov 2016 17:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tvwxGWDfbJi for ; Tue, 22 Nov 2016 17:22:59 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 707061293E4 for ; Tue, 22 Nov 2016 17:22:59 -0800 (PST) Received: from [192.168.4.130] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id ABC1222E1F3; Tue, 22 Nov 2016 20:22:46 -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 10.1 \(3251\)) Message-Id: Date: Wed, 23 Nov 2016 12:22:43 +1100 To: IETF QUIC WG X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Lars Eggert Subject: [QUIC] REMINDER: January Interim Registration X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 23 Nov 2016 01:23:02 -0000 If you're coming to the January Interim meeting (details at <>), please = register as soon as possible, using: http://doodle.com/poll/ma78wgcecbcin4fz If you've already registered, please have a look and confirm that your = name is on that list (some people may have filled out the poll for the = time and place, mistakenly thinking that was registration). Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Nov 22 17:27:49 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44F3712953F for ; Tue, 22 Nov 2016 17:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TGq7sJpGvHn0 for ; Tue, 22 Nov 2016 17:27:46 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5391296B3 for ; Tue, 22 Nov 2016 17:27:37 -0800 (PST) Received: from [192.168.4.130] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 0D08822E1F3; Tue, 22 Nov 2016 20:27:35 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Mark Nottingham In-Reply-To: Date: Wed, 23 Nov 2016 12:27:35 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: IETF QUIC WG X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Lars Eggert Subject: Re: [QUIC] REMINDER: January Interim Registration X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 23 Nov 2016 01:27:47 -0000 > On 23 Nov. 2016, at 12:22 pm, Mark Nottingham wrote: >=20 > If you're coming to the January Interim meeting (details at <>) Missing link: = https://github.com/quicwg/wg-materials/blob/master/interim-17-01/arrangeme= nts.md > , please register as soon as possible, using: >=20 > http://doodle.com/poll/ma78wgcecbcin4fz >=20 > If you've already registered, please have a look and confirm that your = name is on that list (some people may have filled out the poll for the = time and place, mistakenly thinking that was registration). >=20 > Cheers, >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Nov 23 02:03:45 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD9D129855 for ; Wed, 23 Nov 2016 02:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCy97OfPlYy3 for ; Wed, 23 Nov 2016 02:03:40 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B706D129BB8 for ; Wed, 23 Nov 2016 02:03:37 -0800 (PST) Received: from [192.168.4.130] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 15E9822E256; Wed, 23 Nov 2016 05:03:24 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: [QUIC] Adopting four drafts From: Mark Nottingham In-Reply-To: <66EE74A0-C892-4BBD-9F88-70F3D9AC0BA4@mnot.net> Date: Wed, 23 Nov 2016 21:03:21 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <66EE74A0-C892-4BBD-9F88-70F3D9AC0BA4@mnot.net> To: quic@ietf.org X-Mailer: Apple Mail (2.3251) Archived-At: Cc: Lars Eggert X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 23 Nov 2016 10:03:43 -0000 With no pushback on the list, we'll adopt these drafts. The editors have = already started work getting -00 drafts ready, and collecting issues: https://github.com/quicwg/base-drafts/issues Let's see how much we can get done by January! > On 16 Nov. 2016, at 4:25 pm, Mark Nottingham wrote: >=20 > As discussed in the Working Group meeting yesterday, we believe we're = ready to adopt the input documents mentioned in our charter as a = starting point for our work: >=20 > - draft-hamilton-quic-transport-protocol-01 > - draft-iyengar-quic-loss-recovery-01 > - draft-thomson-quic-tls-01 > - draft-shade-quic-http2-mapping-00 >=20 > We saw a high level of consensus in the room for adopting all of them = (with noted discussions around the potential need to make significant = changes and fill in details). >=20 > Our charter states that the contents of these documents will *not* = have assumed consensus; we are merely deciding to use them as a starting = point, and their contents can (and will) change substantially as we = gather it. >=20 > Please raise any concerns about doing so on list soon; we'd like to = get started, and as stated above, agreeing to adopt these isn't = conferring any special status upon their contents, other than being the = starting point for our discussions. >=20 > Cheers, >=20 > Your chairs, Mark and Lars >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Wed Nov 23 14:37:11 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6435127076 for ; Wed, 23 Nov 2016 14:37:09 -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 FSyxGJpjBOqa for ; Wed, 23 Nov 2016 14:37:08 -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 BBDD9129404 for ; Wed, 23 Nov 2016 14:37:07 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id t125so24180264ywc.1 for ; Wed, 23 Nov 2016 14:37:07 -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=N+G7jMMZHI0GTxgU49Gn1lFXJhyRaxN1hxFijq3YqIs=; b=D4viFj+Lj5j3tffqKig5HQ99iUjluIOe0jGL+C3jjVfP/avYpl0y/6OufqM7ANPdIT PfzuTFesmYWee5WPsSRCM2CtV0HR3yQkKJkMYeUihG7haSDKMhe1TWMDo57VcewgL69U 8azQ0fuhjce1K50k1q5jVWtJMkvBSnLKPKmclAxlwvIuvfQbBxWnoHBNCsXCoIUJlf+d 7AGbBFacaa70NXPxiJ//lj5sTA8MkdFg/3GsioBq1gVb6ivvXGYwln7is3rWYcQ/prDZ t8XrdP9hUEhR0uy4R4P3FJhCtUHtN70r32+RC6eUqAnGpU/t/M6hm0pg++6bE8FU1enL Ka2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=N+G7jMMZHI0GTxgU49Gn1lFXJhyRaxN1hxFijq3YqIs=; b=PBRgwSMyRktbeo7RCLk/eHbO7Wd6q/OXpuLUpwR1SIrXBoMh1tmfVeJPweT+wYgoJD fwxcTAASEN53pURdUc1SzNIRg95RPY3LyeMAOrV/tZxzG5ersoVvP7PC1skQbG+V0PnW wThdUk5SgFBYX2NrlpQa66iO0zf41Xvg4sCzAZ6oqQXQ1A86AHXAodRI4GRi7gpxuwSt TPtdJrGI5wtM2ByagQmAIv6D3gu4GQ1rAofVaauu7Fybu1I3rrFh+iA2CD8pQhD1g+2K QVo5PvNTEvTePkZaRcXTIs1mRjEGiOEOJE86ZgqrdtpAdDi1VHcUV8y0PARnjnQQunWK X4Dg== X-Gm-Message-State: AKaTC01husKHLkrpcsA72CnJGc4O2svv80tCfb2OKARybp54RfS1ZvOFSNsTrntzGrQuukPiOIfHK30xzNP7kw== X-Received: by 10.129.108.216 with SMTP id h207mr6326887ywc.52.1479940626765; Wed, 23 Nov 2016 14:37:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Wed, 23 Nov 2016 14:36:26 -0800 (PST) From: Eric Rescorla Date: Wed, 23 Nov 2016 14:36:26 -0800 Message-ID: Subject: Public reset PR To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114dd36e5934040541ff8795 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 23 Nov 2016 22:37:10 -0000 --001a114dd36e5934040541ff8795 Content-Type: text/plain; charset=UTF-8 https://github.com/quicwg/base-drafts/pull/20 Hi folks, I just posted a PR to flesh out the Public Reset packet, which is somewhat underspecified in the current document. First, let me lay out what I think are the desirable properties, with "requirements" having *s and "desiderata" marked with "+". Opinions may vary on the line here. 1. Allow one side to lose connection state (e.g., reboot) and still terminate the connection (*) 2. Prevent off-path attackers from terminating the connection (*) 3. Don't require a public key operation for each termination (*) 4. Prevent on-path attackers from terminating the connection (+) 5. Allow on-path elements to determine when a connection was (+) terminated [I've marked this with "+" but I recognize that some might mark it with "-"] #5 seems like the most questionable property, but here's my rationale. Because network elements (Firewalls, NATs, etc.) can detect that a packet is a Public Reset from the header, they may opt to destroy their internal state upon receiving one. If the Public Reset isn't verifiable by them, then they may just opt to destroy the state based on seeing something with the right header. This opens up an on-path attack where the attacker forges a Public Reset and thus blocks traffic at the middlebox even though the connection is still live at the endpoints. The design in this PR is based on hash preimages [1]. At the beginning of the connection the server supplies a Verifier value which is computed as the Hash of a proof value, like so: Verifier = Hash(Proof). The Verifer is established at the beginning of the connection and stored with the connection record. When you want to reset a connection, you simply send a reset packet that contains Proof. The peer verifies that Hash(Proof) == Verifier and if so tears down the connection. As is this fulfills 2, 3, and 4 and optionally 5 if you expose the RVV to on-path elements during the handshake (or even periodically during the connection). This isn't completely stateless, but you can get away without per-connection state by computing the per-connection Proof from the conn_id and some secret stored on the server. I.e., Proof_conn = PRF(K_m, conn_id) Note that because Proof_conn does not itself leak K_m, seeing one connection reset doesn't allow resetting other connections. K_m can be stored and can survive reboots. I've tried to mimic the style of the document as best I can but I'm sure there's some stuff wrong here. Comments welcome. -Ekr [1] Note that the QUIC Design Document and Rationale describes a slightly simpler mechanis that uses the same state-handling trick I describe here but uses what sounds like a MAC instead of a hash preimage. If you think that requirement #5 is a bad requirement then that's probably a better design. Happy to write this up if it's the WG consensus. --001a114dd36e5934040541ff8795 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= https://github.com/quicwg/base-drafts/pull/20

Hi folks,

I just posted a PR to flesh out the P= ublic Reset packet, which is
somewhat underspecified in the curre= nt document.

First, let me lay out what I think ar= e the desirable properties, with
"requirements" having = *s and "desiderata" marked with "+". Opinions
may vary on the line here.

1. Allow one side to l= ose connection state (e.g., reboot) and still
=C2=A0 =C2=A0termin= ate the connection (*)
2. Prevent off-path attackers from termina= ting the connection (*)
3. Don't require a public key operati= on for each termination (*)
4. Prevent on-path attackers from ter= minating the connection (+)
5. Allow on-path elements to determin= e when a connection was (+)
=C2=A0 =C2=A0terminated [I've mar= ked this with "+" but I recognize that
=C2=A0 =C2=A0som= e might mark it with "-"]

#5 seems like = the most questionable property, but here's my rationale.
Beca= use network elements (Firewalls, NATs, etc.) can detect that a
pa= cket is a Public Reset from the header, they may opt to destroy
t= heir internal state upon receiving one. If the Public Reset isn't
=
verifiable by them, then they may just opt to destroy the state based<= /div>
on seeing something with the right header.=C2=A0 This opens up an= on-path
attack where the attacker forges a Public Reset and thus= blocks
traffic at the middlebox even though the connection is st= ill live at the
endpoints.

The design in= this PR is based on hash preimages [1]. At the beginning
of the = connection the server supplies a Verifier value which is
computed= as the Hash of a proof value, like so:

=C2=A0 =C2= =A0Verifier =3D Hash(Proof).

The Verifer is establ= ished at the beginning of the connection and
stored with the conn= ection record. When you want to reset a
connection, you simply se= nd a reset packet that contains Proof. The
peer verifies that Has= h(Proof) =3D=3D Verifier and if so tears down the
connection. As = is this fulfills 2, 3, and 4 and optionally 5 if you
expose the R= VV to on-path elements during the handshake (or even
periodically= during the connection).

This isn't completely= stateless, but you can get away without
per-connection state by = computing the per-connection Proof from the
conn_id and some secr= et stored on the server. I.e.,

=C2=A0 =C2=A0Proof_= conn =3D PRF(K_m, conn_id)

Note that because Proof= _conn does not itself leak K_m, seeing one
connection reset doesn= 't allow resetting other connections. K_m
can be stored and c= an survive reboots.

I've tried to mimic the st= yle of the document as best I can but I'm
sure there's so= me stuff wrong here.

Comments welcome.
-= Ekr



[1] Note that th= e QUIC Design Document and Rationale describes a
slightly simpler= mechanis that uses the same state-handling trick I
describe here= but uses what sounds like a MAC instead of a hash
preimage. If y= ou think that requirement #5 is a bad requirement then
that's= probably a better design. Happy to write this up if it's the WG
<= div>consensus.

--001a114dd36e5934040541ff8795-- From nobody Wed Nov 23 14:49:16 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C24F4129515 for ; Wed, 23 Nov 2016 14:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7AHl63C8-Zt for ; Wed, 23 Nov 2016 14:49:12 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CBED129437 for ; Wed, 23 Nov 2016 14:49:09 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id a197so95525123wmd.0 for ; Wed, 23 Nov 2016 14:49:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1IzwQ+tgXqv3TEw3a08MtHok0Z4fjFeaTZpS80cVcTA=; b=hUKpIJOPcTFrrHKyWor22QSDaLd4vHpcTE8Nbi1icmI5WkpzqpVz0c9U3oXsaGSB52 n55F64JarbdJaiv9UnwwlTHdz3nROMTf10LeTJibS6j1E/pstUKQ43BeRNNp+Xh8Kgzf LIA2ViRKQrBX/oL3vENkWCGKFfiHshM28yVymg9KWBRdxFuYntk3Hkd43cx7baYL2Gx4 /xmADUxE16OB+UJQXHDvGi6jWXaPvi4yK1rBvNm1RizFJr2MtbiCSlPSNXyhaWhc6nPj gV7plAeGudcOcC3/2q+rtHZkGC05SOaC77z6T8NopnBdSgzkTMJTdafjffBOiYRYgtg0 xyzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1IzwQ+tgXqv3TEw3a08MtHok0Z4fjFeaTZpS80cVcTA=; b=hXWEhblvIzg+5d1ofM0u5Pn9NlPN67CWbxUlq6HXrivXDH08JCqu0C6YOaRPVADbCR IgMJpNEdYt39hq65rrSBX3NN35WorA3V7V8RLkUz380oy7vWJU7oD6r9kWm8c7EYTNGm kYRPINNQ6pvUbMAucvPcLwSAKC+TNwquwITAfACRmH2GKtHjtNxq96p7M0rFnIWUza9v xWsCDdLhTXGUyAKPhbY3cFlbE6cT3+Jix/hciG2eYkrysaDrBDnlwetxSQmSwm+OzYrR 2mdpzHvMTTlsxxP81rm+6OtylY7iHtcwe7BtmF+TFZh9PiUbVtM1aYwWxI+rGOnCDb2i N+xg== X-Gm-Message-State: AKaTC03hQ5fyI9gJBIxPS96rj3E9vLYw6GltF7e6i+2TQucKGeNx+xMxPcHOcgD6U07PFXibjookIqiR+nLGBbPU X-Received: by 10.28.95.197 with SMTP id t188mr109572wmb.99.1479941347764; Wed, 23 Nov 2016 14:49:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.22 with HTTP; Wed, 23 Nov 2016 14:49:07 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Wed, 23 Nov 2016 14:49:07 -0800 Message-ID: Subject: Re: Public reset PR To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1148f2f652cde00541ffb29e Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 23 Nov 2016 22:49:15 -0000 --001a1148f2f652cde00541ffb29e Content-Type: text/plain; charset=UTF-8 Sounds great to me. I agree that having public reset packets visible to middleboxes but unverifiable by them is problematic. On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla wrote: > https://github.com/quicwg/base-drafts/pull/20 > > Hi folks, > > I just posted a PR to flesh out the Public Reset packet, which is > somewhat underspecified in the current document. > > First, let me lay out what I think are the desirable properties, with > "requirements" having *s and "desiderata" marked with "+". Opinions > may vary on the line here. > > 1. Allow one side to lose connection state (e.g., reboot) and still > terminate the connection (*) > 2. Prevent off-path attackers from terminating the connection (*) > 3. Don't require a public key operation for each termination (*) > 4. Prevent on-path attackers from terminating the connection (+) > 5. Allow on-path elements to determine when a connection was (+) > terminated [I've marked this with "+" but I recognize that > some might mark it with "-"] > > #5 seems like the most questionable property, but here's my rationale. > Because network elements (Firewalls, NATs, etc.) can detect that a > packet is a Public Reset from the header, they may opt to destroy > their internal state upon receiving one. If the Public Reset isn't > verifiable by them, then they may just opt to destroy the state based > on seeing something with the right header. This opens up an on-path > attack where the attacker forges a Public Reset and thus blocks > traffic at the middlebox even though the connection is still live at the > endpoints. > > The design in this PR is based on hash preimages [1]. At the beginning > of the connection the server supplies a Verifier value which is > computed as the Hash of a proof value, like so: > > Verifier = Hash(Proof). > > The Verifer is established at the beginning of the connection and > stored with the connection record. When you want to reset a > connection, you simply send a reset packet that contains Proof. The > peer verifies that Hash(Proof) == Verifier and if so tears down the > connection. As is this fulfills 2, 3, and 4 and optionally 5 if you > expose the RVV to on-path elements during the handshake (or even > periodically during the connection). > > This isn't completely stateless, but you can get away without > per-connection state by computing the per-connection Proof from the > conn_id and some secret stored on the server. I.e., > > Proof_conn = PRF(K_m, conn_id) > > Note that because Proof_conn does not itself leak K_m, seeing one > connection reset doesn't allow resetting other connections. K_m > can be stored and can survive reboots. > > I've tried to mimic the style of the document as best I can but I'm > sure there's some stuff wrong here. > > Comments welcome. > -Ekr > > > > [1] Note that the QUIC Design Document and Rationale describes a > slightly simpler mechanis that uses the same state-handling trick I > describe here but uses what sounds like a MAC instead of a hash > preimage. If you think that requirement #5 is a bad requirement then > that's probably a better design. Happy to write this up if it's the WG > consensus. > > --001a1148f2f652cde00541ffb29e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sounds great to me. I agree that having public reset packe= ts visible to middleboxes but unverifiable by them is problematic.

On Wed, Nov 23= , 2016 at 2:36 PM, Eric Rescorla <ekr@rtfm.com> wrote:
https://github.com/quicwg/ba= se-drafts/pull/20

Hi folks,

<= /div>
I just posted a PR to flesh out the Public Reset packet, which is=
somewhat underspecified in the current document.

<= /div>
First, let me lay out what I think are the desirable properties, = with
"requirements" having *s and "desiderata"= ; marked with "+". Opinions
may vary on the line here.<= /div>

1. Allow one side to lose connection state (e.g., = reboot) and still
=C2=A0 =C2=A0terminate the connection (*)
=
2. Prevent off-path attackers from terminating the connection (*)
3. Don't require a public key operation for each termination (*)<= /div>
4. Prevent on-path attackers from terminating the connection (+)<= /div>
5. Allow on-path elements to determine when a connection was (+)<= /div>
=C2=A0 =C2=A0terminated [I've marked this with "+" = but I recognize that
=C2=A0 =C2=A0some might mark it with "-= "]

#5 seems like the most questionable proper= ty, but here's my rationale.
Because network elements (Firewa= lls, NATs, etc.) can detect that a
packet is a Public Reset from = the header, they may opt to destroy
their internal state upon rec= eiving one. If the Public Reset isn't
verifiable by them, the= n they may just opt to destroy the state based
on seeing somethin= g with the right header.=C2=A0 This opens up an on-path
attack wh= ere the attacker forges a Public Reset and thus blocks
traffic at= the middlebox even though the connection is still live at the
en= dpoints.

The design in this PR is based on hash pr= eimages [1]. At the beginning
of the connection the server suppli= es a Verifier value which is
computed as the Hash of a proof valu= e, like so:

=C2=A0 =C2=A0Verifier =3D Hash(Proof).=

The Verifer is established at the beginning of th= e connection and
stored with the connection record. When you want= to reset a
connection, you simply send a reset packet that conta= ins Proof. The
peer verifies that Hash(Proof) =3D=3D Verifier and= if so tears down the
connection. As is this fulfills 2, 3, and 4= and optionally 5 if you
expose the RVV to on-path elements durin= g the handshake (or even
periodically during the connection).

This isn't completely stateless, but you can get = away without
per-connection state by computing the per-connection= Proof from the
conn_id and some secret stored on the server. I.e= .,

=C2=A0 =C2=A0Proof_conn =3D PRF(K_m, conn_id)

Note that because Proof_conn does not itself leak K= _m, seeing one
connection reset doesn't allow resetting other= connections. K_m
can be stored and can survive reboots.

I've tried to mimic the style of the document as best = I can but I'm
sure there's some stuff wrong here.

Comments welcome.
-Ekr



[1] Note that the QUIC Design Document and R= ationale describes a
slightly simpler mechanis that uses the same= state-handling trick I
describe here but uses what sounds like a= MAC instead of a hash
preimage. If you think that requirement #5= is a bad requirement then
that's probably a better design. H= appy to write this up if it's the WG
consensus.

--001a1148f2f652cde00541ffb29e-- From nobody Wed Nov 23 14:55:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9776A129481 for ; Wed, 23 Nov 2016 14:55:06 -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 vFAc19S-MYHS for ; Wed, 23 Nov 2016 14:55:05 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 C3B1D129430 for ; Wed, 23 Nov 2016 14:55:04 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id p16so25399535qta.0 for ; Wed, 23 Nov 2016 14:55:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xXS4DwS2EksgUQoHEBOIPCve6Q/srbgwbaCDKLnMWIM=; b=S9J2dEtxggI6faJwfK4mqatiIHmrOsC1IsfNb9cjW5pF+aaVEQThzNxIZYXPNGIGz4 nZz9kcQJnkyIher263mFroscXmQIw6xV1wLqCkut+K4n//Nc91b2gayN0H4wOgOcUGAU Zd2orFTJwkOjLyzi1cm874S88BzMbvN9EIuaKdY7ri3f5abpFEYQ0lbg9O61bBT2ZaT6 z2CujxpEsL6OlHgs9r4SYuKMLPq1RI5KiS2L/GoMlMrax2NsfGThtbnGvWPaAK23JxLT Rl5aSCn04YWg+GffDEAb/laVZq40WZANajIfrSDPCCvQNr7L9jwrHPZ7d2r1oClaq1vL GzbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xXS4DwS2EksgUQoHEBOIPCve6Q/srbgwbaCDKLnMWIM=; b=E/qcptc9MVMq9pnHm/hWjHjRMsAgDzakh3gFeKTPaXkmMWENTpeQxgHlqIK2wzF4n1 szuB+tF254haOysMvK2XNWryo1uuYnwKPp2MELk6bYno1UhAXn5h6IXV6+JTzWPPN6Gz SCfZ4NZU44wRzSeXVfUUm7kn3wbfbgj4p5R7jW4Okd7HblS8b/FQk5JXKstFZ9KfEdrg J/6FJh+MfuoaSpMJitinVZB3aIkuUp9cB56s+eKKTXAbCrtDjlPTTRhS3PTUMFt2/BDd AbEafoFoZsgb2NWvsLCUxCbD08VtIwEXdlNjvQ2NKew3WI/3kDMfRLgo9gCUjOzWEzbG 8Ilg== X-Gm-Message-State: AKaTC03ehbNRqA+hFfUg2KkQJIMKGuOv3E3YULTOJlcP+U0MOMvtwGl5+n5ZEFGPA+dQKSA9B8+GkQfj7guc+Q== X-Received: by 10.200.46.249 with SMTP id i54mr4777401qta.13.1479941703870; Wed, 23 Nov 2016 14:55:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Wed, 23 Nov 2016 14:55:03 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 24 Nov 2016 09:55:03 +1100 Message-ID: Subject: Re: Public reset PR To: Ryan Hamilton Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 23 Nov 2016 22:55:06 -0000 So this seems to only be feasible for a server. That's something that needs to be articulated somehow. That means that clients are unable to construct a public reset. FWIW, there is currently no way to carry the verifier value. We'll need to work on that. On 24 November 2016 at 09:49, Ryan Hamilton wrote: > Sounds great to me. I agree that having public reset packets visible to > middleboxes but unverifiable by them is problematic. > > On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla wrote: >> >> https://github.com/quicwg/base-drafts/pull/20 >> >> Hi folks, >> >> I just posted a PR to flesh out the Public Reset packet, which is >> somewhat underspecified in the current document. >> >> First, let me lay out what I think are the desirable properties, with >> "requirements" having *s and "desiderata" marked with "+". Opinions >> may vary on the line here. >> >> 1. Allow one side to lose connection state (e.g., reboot) and still >> terminate the connection (*) >> 2. Prevent off-path attackers from terminating the connection (*) >> 3. Don't require a public key operation for each termination (*) >> 4. Prevent on-path attackers from terminating the connection (+) >> 5. Allow on-path elements to determine when a connection was (+) >> terminated [I've marked this with "+" but I recognize that >> some might mark it with "-"] >> >> #5 seems like the most questionable property, but here's my rationale. >> Because network elements (Firewalls, NATs, etc.) can detect that a >> packet is a Public Reset from the header, they may opt to destroy >> their internal state upon receiving one. If the Public Reset isn't >> verifiable by them, then they may just opt to destroy the state based >> on seeing something with the right header. This opens up an on-path >> attack where the attacker forges a Public Reset and thus blocks >> traffic at the middlebox even though the connection is still live at the >> endpoints. >> >> The design in this PR is based on hash preimages [1]. At the beginning >> of the connection the server supplies a Verifier value which is >> computed as the Hash of a proof value, like so: >> >> Verifier = Hash(Proof). >> >> The Verifer is established at the beginning of the connection and >> stored with the connection record. When you want to reset a >> connection, you simply send a reset packet that contains Proof. The >> peer verifies that Hash(Proof) == Verifier and if so tears down the >> connection. As is this fulfills 2, 3, and 4 and optionally 5 if you >> expose the RVV to on-path elements during the handshake (or even >> periodically during the connection). >> >> This isn't completely stateless, but you can get away without >> per-connection state by computing the per-connection Proof from the >> conn_id and some secret stored on the server. I.e., >> >> Proof_conn = PRF(K_m, conn_id) >> >> Note that because Proof_conn does not itself leak K_m, seeing one >> connection reset doesn't allow resetting other connections. K_m >> can be stored and can survive reboots. >> >> I've tried to mimic the style of the document as best I can but I'm >> sure there's some stuff wrong here. >> >> Comments welcome. >> -Ekr >> >> >> >> [1] Note that the QUIC Design Document and Rationale describes a >> slightly simpler mechanis that uses the same state-handling trick I >> describe here but uses what sounds like a MAC instead of a hash >> preimage. If you think that requirement #5 is a bad requirement then >> that's probably a better design. Happy to write this up if it's the WG >> consensus. >> > From nobody Wed Nov 23 15:07:20 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F25E3129446 for ; Wed, 23 Nov 2016 15:07:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1devSW0ixJV for ; Wed, 23 Nov 2016 15:07:17 -0800 (PST) Received: from mail-wj0-x231.google.com (mail-wj0-x231.google.com [IPv6:2a00:1450:400c:c01::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 6D04D129576 for ; Wed, 23 Nov 2016 15:07:15 -0800 (PST) Received: by mail-wj0-x231.google.com with SMTP id xy5so19690797wjc.0 for ; Wed, 23 Nov 2016 15:07:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=re7yaxwuMq94xHoH9pfR3Ga5fYHCWOTq88Fh7rGDOAo=; b=AQDdYwW6j2kTD6xBX3BpOeNnpvLisRZItOK5pKI7LQwu7O2l96ikyXC5cZS8RP1lXu NJwf8HYeAVroZaSpoph2PDDN2Yil8kmzS+EgfoZMWMR2iP0xPzJkLbQvlm/dppA75nb7 hhmr5VFz+Uk8mNa5VcYHJPRd9m03P5yn50NJ4LOd7SCpCYg//0wLKlpStOT3OoOghXvw BsoHg00ywQYFQnlEMCTs5B4Wjzpkz3is9xny+PJ+Bo4+5nWt3/jpDoEhCRqDtQsI1bpl LFB8PT3OlUFRirASoQAEYfdyI8wXUXAHLDC6h3XsHeBVF7dIPksQafFtmT1cCHvncelK OZCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=re7yaxwuMq94xHoH9pfR3Ga5fYHCWOTq88Fh7rGDOAo=; b=C3vh4C0WU8CTYmzTFuv8G4Wu1kcL7BSfyB7rYs0mC4+22RedgL0xJYubjIubZKKF1d 5D/QobxH+BQQBqBTwf0Ztah2Fa6svnwpYImcSdzcb70SpmrXlDrXe6IPTAJ1HGIBz71J XOR6gLEFl+iWSM66L+c6mGpzPIAVpbZT/ZaTkktzteZVZBF3apkifJt2K4c6azW/ma2V w6vEuvPxZ5x6IlsK8ksSEla82TEQff+yWu+ggkSqTwrOPkCXVXLFkXakO7q8akzqZbfc n30lWi/1AWutuf8RfzuprJFrYGcr6GvfJrc1fFolEqIWCd7oeJJ5un1e2iGI0IPCZrPj Q3/Q== X-Gm-Message-State: AKaTC00UjBKEXkmKUCdORw/G3s7+/gmQtNir2XgYD/bBUa26IC4dG8Ci19IRIc+JWACuqavJGLJPqJhgsglrb6Qt X-Received: by 10.194.109.42 with SMTP id hp10mr5227904wjb.167.1479942433804; Wed, 23 Nov 2016 15:07:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.22 with HTTP; Wed, 23 Nov 2016 15:07:12 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Wed, 23 Nov 2016 15:07:12 -0800 Message-ID: Subject: Re: Public reset PR To: Martin Thomson Content-Type: multipart/alternative; boundary=089e0102d8000e7d3d0541fff393 Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 23 Nov 2016 23:07:19 -0000 --089e0102d8000e7d3d0541fff393 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 23, 2016 at 2:55 PM, Martin Thomson wrote: > So this seems to only be feasible for a server. That's something that > needs to be articulated somehow. That means that clients are unable > to construct a public reset. > =E2=80=8BCurrently, public reset packets are only sent from servers to clie= nt. But that being said, if we wanted clients to be able to send public reset packets, could not the client perform the same operation described here? FWIW, there is currently no way to carry the verifier value. We'll > need to work on that. > > On 24 November 2016 at 09:49, Ryan Hamilton wrote: > > Sounds great to me. I agree that having public reset packets visible to > > middleboxes but unverifiable by them is problematic. > > > > On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla wrote: > >> > >> https://github.com/quicwg/base-drafts/pull/20 > >> > >> Hi folks, > >> > >> I just posted a PR to flesh out the Public Reset packet, which is > >> somewhat underspecified in the current document. > >> > >> First, let me lay out what I think are the desirable properties, with > >> "requirements" having *s and "desiderata" marked with "+". Opinions > >> may vary on the line here. > >> > >> 1. Allow one side to lose connection state (e.g., reboot) and still > >> terminate the connection (*) > >> 2. Prevent off-path attackers from terminating the connection (*) > >> 3. Don't require a public key operation for each termination (*) > >> 4. Prevent on-path attackers from terminating the connection (+) > >> 5. Allow on-path elements to determine when a connection was (+) > >> terminated [I've marked this with "+" but I recognize that > >> some might mark it with "-"] > >> > >> #5 seems like the most questionable property, but here's my rationale. > >> Because network elements (Firewalls, NATs, etc.) can detect that a > >> packet is a Public Reset from the header, they may opt to destroy > >> their internal state upon receiving one. If the Public Reset isn't > >> verifiable by them, then they may just opt to destroy the state based > >> on seeing something with the right header. This opens up an on-path > >> attack where the attacker forges a Public Reset and thus blocks > >> traffic at the middlebox even though the connection is still live at t= he > >> endpoints. > >> > >> The design in this PR is based on hash preimages [1]. At the beginning > >> of the connection the server supplies a Verifier value which is > >> computed as the Hash of a proof value, like so: > >> > >> Verifier =3D Hash(Proof). > >> > >> The Verifer is established at the beginning of the connection and > >> stored with the connection record. When you want to reset a > >> connection, you simply send a reset packet that contains Proof. The > >> peer verifies that Hash(Proof) =3D=3D Verifier and if so tears down th= e > >> connection. As is this fulfills 2, 3, and 4 and optionally 5 if you > >> expose the RVV to on-path elements during the handshake (or even > >> periodically during the connection). > >> > >> This isn't completely stateless, but you can get away without > >> per-connection state by computing the per-connection Proof from the > >> conn_id and some secret stored on the server. I.e., > >> > >> Proof_conn =3D PRF(K_m, conn_id) > >> > >> Note that because Proof_conn does not itself leak K_m, seeing one > >> connection reset doesn't allow resetting other connections. K_m > >> can be stored and can survive reboots. > >> > >> I've tried to mimic the style of the document as best I can but I'm > >> sure there's some stuff wrong here. > >> > >> Comments welcome. > >> -Ekr > >> > >> > >> > >> [1] Note that the QUIC Design Document and Rationale describes a > >> slightly simpler mechanis that uses the same state-handling trick I > >> describe here but uses what sounds like a MAC instead of a hash > >> preimage. If you think that requirement #5 is a bad requirement then > >> that's probably a better design. Happy to write this up if it's the WG > >> consensus. > >> > > > --089e0102d8000e7d3d0541fff393 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 2= 3, 2016 at 2:55 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
= So this seems to only be feasible for a server.=C2=A0 That's something = that
needs to be articulated somehow.=C2=A0 That means that clients are unable to construct a public reset.


FWIW, th= ere is currently no way to carry the verifier value.=C2=A0 We'll
need to work on that.

On 24 November 2016 at 09:49, Ryan Hamilton <rch@google.com> wrote:
> Sounds great to me. I agree that having public reset packets visible t= o
> middleboxes but unverifiable by them is problematic.
>
> On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> https://github.com/quicwg/base-drafts/pull/20
>>
>> Hi folks,
>>
>> I just posted a PR to flesh out the Public Reset packet, which is<= br> >> somewhat underspecified in the current document.
>>
>> First, let me lay out what I think are the desirable properties, w= ith
>> "requirements" having *s and "desiderata" mark= ed with "+". Opinions
>> may vary on the line here.
>>
>> 1. Allow one side to lose connection state (e.g., reboot) and stil= l
>>=C2=A0 =C2=A0 terminate the connection (*)
>> 2. Prevent off-path attackers from terminating the connection (*)<= br> >> 3. Don't require a public key operation for each termination (= *)
>> 4. Prevent on-path attackers from terminating the connection (+) >> 5. Allow on-path elements to determine when a connection was (+) >>=C2=A0 =C2=A0 terminated [I've marked this with "+" b= ut I recognize that
>>=C2=A0 =C2=A0 some might mark it with "-"]
>>
>> #5 seems like the most questionable property, but here's my ra= tionale.
>> Because network elements (Firewalls, NATs, etc.) can detect that a=
>> packet is a Public Reset from the header, they may opt to destroy<= br> >> their internal state upon receiving one. If the Public Reset isn&#= 39;t
>> verifiable by them, then they may just opt to destroy the state ba= sed
>> on seeing something with the right header.=C2=A0 This opens up an = on-path
>> attack where the attacker forges a Public Reset and thus blocks >> traffic at the middlebox even though the connection is still live = at the
>> endpoints.
>>
>> The design in this PR is based on hash preimages [1]. At the begin= ning
>> of the connection the server supplies a Verifier value which is >> computed as the Hash of a proof value, like so:
>>
>>=C2=A0 =C2=A0 Verifier =3D Hash(Proof).
>>
>> The Verifer is established at the beginning of the connection and<= br> >> stored with the connection record. When you want to reset a
>> connection, you simply send a reset packet that contains Proof. Th= e
>> peer verifies that Hash(Proof) =3D=3D Verifier and if so tears dow= n the
>> connection. As is this fulfills 2, 3, and 4 and optionally 5 if yo= u
>> expose the RVV to on-path elements during the handshake (or even >> periodically during the connection).
>>
>> This isn't completely stateless, but you can get away without<= br> >> per-connection state by computing the per-connection Proof from th= e
>> conn_id and some secret stored on the server. I.e.,
>>
>>=C2=A0 =C2=A0 Proof_conn =3D PRF(K_m, conn_id)
>>
>> Note that because Proof_conn does not itself leak K_m, seeing one<= br> >> connection reset doesn't allow resetting other connections. K_= m
>> can be stored and can survive reboots.
>>
>> I've tried to mimic the style of the document as best I can bu= t I'm
>> sure there's some stuff wrong here.
>>
>> Comments welcome.
>> -Ekr
>>
>>
>>
>> [1] Note that the QUIC Design Document and Rationale describes a >> slightly simpler mechanis that uses the same state-handling trick = I
>> describe here but uses what sounds like a MAC instead of a hash >> preimage. If you think that requirement #5 is a bad requirement th= en
>> that's probably a better design. Happy to write this up if it&= #39;s the WG
>> consensus.
>>
>

--089e0102d8000e7d3d0541fff393-- From nobody Wed Nov 23 15:11:01 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5264D12957B for ; Wed, 23 Nov 2016 15:11:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zw4EUFmNfRvW for ; Wed, 23 Nov 2016 15:10:57 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0131.outbound.protection.outlook.com [104.47.38.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 8E90A1294AC for ; Wed, 23 Nov 2016 15:10:57 -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=9teTu69VBG7ITcC7xPkPHlNpC6WZ0I5RogjAle/ObJA=; b=m7m+TbPMgSJFk/+lOMK6+7wsD0MVEYtAfhRx62oeP9pZvKUTaSOvrYhuzODq4S5PNpzsRASlo1gOi2rZqlxquztkH7AIJ4w7YfY2oYjtEWWuvyNYF0JLbZGSwa7XGHy2T5PfuytdAXzI7CsTGTEm6kkucTosuFwu/bp38alM6xY= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Wed, 23 Nov 2016 23:10:55 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0734.014; Wed, 23 Nov 2016 23:10:55 +0000 From: Mike Bishop To: Martin Thomson , Ryan Hamilton Subject: RE: Public reset PR Thread-Topic: Public reset PR Thread-Index: AQHSRdolEq83wEaQGkWX3U052kKzMKDnK+OAgAABqYCAAARv1g== Date: Wed, 23 Nov 2016 23:10:55 +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=Michael.Bishop@microsoft.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [67.197.26.33] x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:A8J1Jhl+uvmNt8jb1pbXMBW8tkAa7Ikxtm+Noi7PFUhZH2r37lpgq6lqogApJBycHx5c1GeTc8WF2GO5feguz6oUqO9OJv7zoSO/wNfEmuRXobkwMrFTGQ6+5YU+WbE8M6ePh0RfXSrhTv21uyIA8F1gvyP3mv5zbZApu5baLJmV9h/r3uYs45f+s3049iRAVB+0WVVlMF4H+mFJnEtqKG6B1K6nZuRlOBaVgBO09uyHH2Ek3HISGndCG/RcFj6gpNnsd7a4leVl6oRPt/Xh2tqB1CBKlVZYk0bpvBg5GeZhKiSJtUVcQVu3T/yHz6m0q8sXUWPyE9I0PF0AGi18NCnKABsJF+osDxMI1G4LF8ypgqlV5fhAj5G/44thN4qZ x-ms-office365-filtering-correlation-id: 47e66a87-0732-4e20-d81f-08d413f5fa78 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:BN6PR03MB2705; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(131327999870524)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6060326)(6040307)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(6061324)(6046074)(6047074)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 013568035E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(377454003)(199003)(24454002)(189002)(54356999)(189998001)(8676002)(101416001)(50986999)(10090500001)(97736004)(7846002)(33656002)(606004)(76576001)(74316002)(76176999)(77096005)(7906003)(66066001)(8990500004)(10290500002)(6116002)(8936002)(102836003)(7736002)(38730400001)(81156014)(81166006)(7696004)(5005710100001)(2950100002)(3846002)(3900700001)(3480700004)(86612001)(86362001)(6506003)(68736007)(9686002)(99286002)(106356001)(106116001)(92566002)(105586002)(7116003)(122556002)(3280700002)(2906002)(5660300001)(2900100001)(229853002)(3660700001)(4326007)(5001770100001)(39060400001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.namprd03.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) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708D58180E1D489254519B887B70BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2016 23:10:55.3279 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 23 Nov 2016 23:11:00 -0000 --_000_BN6PR03MB2708D58180E1D489254519B887B70BN6PR03MB2708namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I semi-disagree with one element of your requirements list. It seems valua= ble to enable on-path network infrastructure (indistinguishable from on-pat= h attackers) to notify the peers of an intention to interrupt something abo= ut the connection. At the least, we need to discuss that point rather than= assuming it. Sent from my Windows 10 phone From: Martin Thomson Sent: Wednesday, November 23, 2016 5:55 PM To: Ryan Hamilton Cc: Eric Rescorla; IETF QUIC WG Subject: Re: Public reset PR So this seems to only be feasible for a server. That's something that needs to be articulated somehow. That means that clients are unable to construct a public reset. FWIW, there is currently no way to carry the verifier value. We'll need to work on that. On 24 November 2016 at 09:49, Ryan Hamilton wrote: > Sounds great to me. I agree that having public reset packets visible to > middleboxes but unverifiable by them is problematic. > > On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla wrote: >> >> https://github.com/quicwg/base-drafts/pull/20 >> >> Hi folks, >> >> I just posted a PR to flesh out the Public Reset packet, which is >> somewhat underspecified in the current document. >> >> First, let me lay out what I think are the desirable properties, with >> "requirements" having *s and "desiderata" marked with "+". Opinions >> may vary on the line here. >> >> 1. Allow one side to lose connection state (e.g., reboot) and still >> terminate the connection (*) >> 2. Prevent off-path attackers from terminating the connection (*) >> 3. Don't require a public key operation for each termination (*) >> 4. Prevent on-path attackers from terminating the connection (+) >> 5. Allow on-path elements to determine when a connection was (+) >> terminated [I've marked this with "+" but I recognize that >> some might mark it with "-"] >> >> #5 seems like the most questionable property, but here's my rationale. >> Because network elements (Firewalls, NATs, etc.) can detect that a >> packet is a Public Reset from the header, they may opt to destroy >> their internal state upon receiving one. If the Public Reset isn't >> verifiable by them, then they may just opt to destroy the state based >> on seeing something with the right header. This opens up an on-path >> attack where the attacker forges a Public Reset and thus blocks >> traffic at the middlebox even though the connection is still live at the >> endpoints. >> >> The design in this PR is based on hash preimages [1]. At the beginning >> of the connection the server supplies a Verifier value which is >> computed as the Hash of a proof value, like so: >> >> Verifier =3D Hash(Proof). >> >> The Verifer is established at the beginning of the connection and >> stored with the connection record. When you want to reset a >> connection, you simply send a reset packet that contains Proof. The >> peer verifies that Hash(Proof) =3D=3D Verifier and if so tears down the >> connection. As is this fulfills 2, 3, and 4 and optionally 5 if you >> expose the RVV to on-path elements during the handshake (or even >> periodically during the connection). >> >> This isn't completely stateless, but you can get away without >> per-connection state by computing the per-connection Proof from the >> conn_id and some secret stored on the server. I.e., >> >> Proof_conn =3D PRF(K_m, conn_id) >> >> Note that because Proof_conn does not itself leak K_m, seeing one >> connection reset doesn't allow resetting other connections. K_m >> can be stored and can survive reboots. >> >> I've tried to mimic the style of the document as best I can but I'm >> sure there's some stuff wrong here. >> >> Comments welcome. >> -Ekr >> >> >> >> [1] Note that the QUIC Design Document and Rationale describes a >> slightly simpler mechanis that uses the same state-handling trick I >> describe here but uses what sounds like a MAC instead of a hash >> preimage. If you think that requirement #5 is a bad requirement then >> that's probably a better design. Happy to write this up if it's the WG >> consensus. >> > --_000_BN6PR03MB2708D58180E1D489254519B887B70BN6PR03MB2708namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I semi-disagree with one element of your requireme= nts list.  It seems valuable to enable on-path network infrastructure = (indistinguishable from on-path attackers) to notify the peers of an intent= ion to interrupt something about the connection.  At the least, we need to discuss that point rather than assuming it.

 

Sent from my Windows 10 phone

 

From: Martin Thomson
Sent: Wednesday, November 23, 2016 5:55 PM
To: Ryan Hamilton
Cc: Eric Rescorla; IETF QUIC WG
Subject: Re: Public reset PR

 

So this seems to only be feasible for a server.&nb= sp; That's something that
needs to be articulated somehow.  That means that clients are unable to construct a public reset.

FWIW, there is currently no way to carry the verifier value.  We'll need to work on that.

On 24 November 2016 at 09:49, Ryan Hamilton <rch@google.com> wrote: > Sounds great to me. I agree that having public reset packets visible t= o
> middleboxes but unverifiable by them is problematic.
>
> On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla <ekr@rtfm.com> wr= ote:
>>
>> https://= github.com/quicwg/base-drafts/pull/20
>>
>> Hi folks,
>>
>> I just posted a PR to flesh out the Public Reset packet, which is<= br> >> somewhat underspecified in the current document.
>>
>> First, let me lay out what I think are the desirable properties, w= ith
>> "requirements" having *s and "desiderata" mark= ed with "+". Opinions
>> may vary on the line here.
>>
>> 1. Allow one side to lose connection state (e.g., reboot) and stil= l
>>    terminate the connection (*)
>> 2. Prevent off-path attackers from terminating the connection (*)<= br> >> 3. Don't require a public key operation for each termination (*) >> 4. Prevent on-path attackers from terminating the connection (+= ;)
>> 5. Allow on-path elements to determine when a connection was (+= ;)
>>    terminated [I've marked this with "+&qu= ot; but I recognize that
>>    some might mark it with "-"]
>>
>> #5 seems like the most questionable property, but here's my ration= ale.
>> Because network elements (Firewalls, NATs, etc.) can detect that a=
>> packet is a Public Reset from the header, they may opt to destroy<= br> >> their internal state upon receiving one. If the Public Reset isn't=
>> verifiable by them, then they may just opt to destroy the state ba= sed
>> on seeing something with the right header.  This opens up an = on-path
>> attack where the attacker forges a Public Reset and thus blocks >> traffic at the middlebox even though the connection is still live = at the
>> endpoints.
>>
>> The design in this PR is based on hash preimages [1]. At the begin= ning
>> of the connection the server supplies a Verifier value which is >> computed as the Hash of a proof value, like so:
>>
>>    Verifier =3D Hash(Proof).
>>
>> The Verifer is established at the beginning of the connection and<= br> >> stored with the connection record. When you want to reset a
>> connection, you simply send a reset packet that contains Proof. Th= e
>> peer verifies that Hash(Proof) =3D=3D Verifier and if so tears dow= n the
>> connection. As is this fulfills 2, 3, and 4 and optionally 5 if yo= u
>> expose the RVV to on-path elements during the handshake (or even >> periodically during the connection).
>>
>> This isn't completely stateless, but you can get away without
>> per-connection state by computing the per-connection Proof from th= e
>> conn_id and some secret stored on the server. I.e.,
>>
>>    Proof_conn =3D PRF(K_m, conn_id)
>>
>> Note that because Proof_conn does not itself leak K_m, seeing one<= br> >> connection reset doesn't allow resetting other connections. K_m >> can be stored and can survive reboots.
>>
>> I've tried to mimic the style of the document as best I can but I'= m
>> sure there's some stuff wrong here.
>>
>> Comments welcome.
>> -Ekr
>>
>>
>>
>> [1] Note that the QUIC Design Document and Rationale describes a >> slightly simpler mechanis that uses the same state-handling trick = I
>> describe here but uses what sounds like a MAC instead of a hash >> preimage. If you think that requirement #5 is a bad requirement th= en
>> that's probably a better design. Happy to write this up if it's th= e WG
>> consensus.
>>
>

 --_000_BN6PR03MB2708D58180E1D489254519B887B70BN6PR03MB2708namp_-- From nobody Wed Nov 23 15:23:06 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12FC129482 for ; Wed, 23 Nov 2016 15:23:05 -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 CDC1GGc2CYsO for ; Wed, 23 Nov 2016 15:23:03 -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 97F64128DF6 for ; Wed, 23 Nov 2016 15:23:03 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id r204so25105984ywb.0 for ; Wed, 23 Nov 2016 15:23:03 -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=4miJRdk+D7jLqI+iwHaq8zjHqRx/muRNO904i4Ysx0Q=; b=rODeed6RFTw1xGHI+dXuuRE5UaLg+sQsxIfSbAKQLLg06gOkZzUbC8E1A8KanKsJS7 uXW21V8Vjav7/pCvXgGeGHoT8mFlxVp67+Q2YGFJjcNcSfsHccgyRfVjQSEqFVrbBCgL VxBoazts+k3+ApCEmkgkLaI3fNojpAQfpARCvUm6Q/KDReigQ4c0d1s1fGuEFnQz0sfv 9zGwQryOvljH9RhvfkuwvWEhv293j+n4ZiMRl3vJd38ifwDwcf2fObKee/MLXx+AQsnF 5I7tVEEDjTB0bGv+0HpqnyEJT6hndcVdHSHAJ9c3WbXhw/aDeQdOmRUwOWTduFtut2PC oztQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4miJRdk+D7jLqI+iwHaq8zjHqRx/muRNO904i4Ysx0Q=; b=IhTxnvVHV8IwOPk+UqXQNxMBHj1w7vDOK41VzZH/rNpVq0RGjqXdQ6iGeVPbl86xvo GEuX39Y2djACZjohRyOSxHQ+/kruxJRIMqq4vUq1T8IA68BX2Y0aYF5d4HZxgZJ7+xer COCAkpx4H0+gH4jyx4rixFPLTjGfNTzSSQ0RM/jkwnr2ok5eChrQ7FIhRspQyfIfn4Z1 gveND1NWQM0Q2p6uQXboBpS6CBJ+zib8h9f8eXMlCFa0+yKgjAqv61Z6fVs5WEeSAkqC qENHXxmWqkoYtuRQCxFlKtFrmH2AmE/X22HpO8JYAUswniNS6HVXPFdX37FZNyyykGxP 4MRw== X-Gm-Message-State: AKaTC02fnBplwDOXNW++88XnW0YZga45Jb9vwepdLCQVI9pNUMckmJLxDBs/KJtQh7/LtXqJRJeTLY4lFpyxNw== X-Received: by 10.129.121.1 with SMTP id u1mr6355734ywc.146.1479943382909; Wed, 23 Nov 2016 15:23:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Wed, 23 Nov 2016 15:22:22 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 23 Nov 2016 15:22:22 -0800 Message-ID: Subject: Re: Public reset PR To: Ryan Hamilton Content-Type: multipart/alternative; boundary=94eb2c0a8f82a07a810542002b25 Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 23 Nov 2016 23:23:06 -0000 --94eb2c0a8f82a07a810542002b25 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 23, 2016 at 3:07 PM, Ryan Hamilton wrote: > On Wed, Nov 23, 2016 at 2:55 PM, Martin Thomson > wrote: > >> So this seems to only be feasible for a server. That's something that >> needs to be articulated somehow. That means that clients are unable >> to construct a public reset. >> > > =E2=80=8BCurrently, public reset packets are only sent from servers to cl= ient. But > that being said, if we wanted clients to be able to send public reset > packets, could not the client perform the same operation described here? > I think that would work fine, though we would require the client to supply the Verifier which, as Martin says, is another problem we'd need to solve. -Ekr > > FWIW, there is currently no way to carry the verifier value. We'll >> need to work on that. >> >> On 24 November 2016 at 09:49, Ryan Hamilton wrote: >> > Sounds great to me. I agree that having public reset packets visible t= o >> > middleboxes but unverifiable by them is problematic. >> > >> > On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla wrote: >> >> >> >> https://github.com/quicwg/base-drafts/pull/20 >> >> >> >> Hi folks, >> >> >> >> I just posted a PR to flesh out the Public Reset packet, which is >> >> somewhat underspecified in the current document. >> >> >> >> First, let me lay out what I think are the desirable properties, with >> >> "requirements" having *s and "desiderata" marked with "+". Opinions >> >> may vary on the line here. >> >> >> >> 1. Allow one side to lose connection state (e.g., reboot) and still >> >> terminate the connection (*) >> >> 2. Prevent off-path attackers from terminating the connection (*) >> >> 3. Don't require a public key operation for each termination (*) >> >> 4. Prevent on-path attackers from terminating the connection (+) >> >> 5. Allow on-path elements to determine when a connection was (+) >> >> terminated [I've marked this with "+" but I recognize that >> >> some might mark it with "-"] >> >> >> >> #5 seems like the most questionable property, but here's my rationale= . >> >> Because network elements (Firewalls, NATs, etc.) can detect that a >> >> packet is a Public Reset from the header, they may opt to destroy >> >> their internal state upon receiving one. If the Public Reset isn't >> >> verifiable by them, then they may just opt to destroy the state based >> >> on seeing something with the right header. This opens up an on-path >> >> attack where the attacker forges a Public Reset and thus blocks >> >> traffic at the middlebox even though the connection is still live at >> the >> >> endpoints. >> >> >> >> The design in this PR is based on hash preimages [1]. At the beginnin= g >> >> of the connection the server supplies a Verifier value which is >> >> computed as the Hash of a proof value, like so: >> >> >> >> Verifier =3D Hash(Proof). >> >> >> >> The Verifer is established at the beginning of the connection and >> >> stored with the connection record. When you want to reset a >> >> connection, you simply send a reset packet that contains Proof. The >> >> peer verifies that Hash(Proof) =3D=3D Verifier and if so tears down t= he >> >> connection. As is this fulfills 2, 3, and 4 and optionally 5 if you >> >> expose the RVV to on-path elements during the handshake (or even >> >> periodically during the connection). >> >> >> >> This isn't completely stateless, but you can get away without >> >> per-connection state by computing the per-connection Proof from the >> >> conn_id and some secret stored on the server. I.e., >> >> >> >> Proof_conn =3D PRF(K_m, conn_id) >> >> >> >> Note that because Proof_conn does not itself leak K_m, seeing one >> >> connection reset doesn't allow resetting other connections. K_m >> >> can be stored and can survive reboots. >> >> >> >> I've tried to mimic the style of the document as best I can but I'm >> >> sure there's some stuff wrong here. >> >> >> >> Comments welcome. >> >> -Ekr >> >> >> >> >> >> >> >> [1] Note that the QUIC Design Document and Rationale describes a >> >> slightly simpler mechanis that uses the same state-handling trick I >> >> describe here but uses what sounds like a MAC instead of a hash >> >> preimage. If you think that requirement #5 is a bad requirement then >> >> that's probably a better design. Happy to write this up if it's the W= G >> >> consensus. >> >> >> > >> > > --94eb2c0a8f82a07a810542002b25 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 23, 2016 at 3:07 PM, Ryan Hamilton <rch@google.com> wrote:
On Wed, Nov 23, 2016 at 2:55 PM, Martin Thomson = <martin.thomson@gmail.com> wrote:
So this seems to only be feasible for a server.=C2=A0 That's = something that
needs to be articulated somehow.=C2=A0 That means that clients are unable to construct a public reset.

=E2=80=8BCurren= tly, public reset packets are only sent from servers to client. But that be= ing said, if we wanted clients to be able to send public reset packets, cou= ld not the client perform the same operation described here?

I think that would work fin= e, though we would require the client to supply the Verifier which, as Mart= in says, is another problem we'd need to solve.

-Ekr
=C2=A0

FWIW, there is currently no way to carry t= he verifier value.=C2=A0 We'll
need to work on that.

On 24 November 2016 at 09:49, Ryan Hamilton <rch@google.c= om> wrote:
> Sounds great to me. I agree that having public reset packets visible t= o
> middleboxes but unverifiable by them is problematic.
>
> On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla <ekr@rt= fm.com> wrote:
>>
>> https://= github.com/quicwg/base-drafts/pull/20
>>
>> Hi folks,
>>
>> I just posted a PR to flesh out the Public Reset packet, which is<= br> >> somewhat underspecified in the current document.
>>
>> First, let me lay out what I think are the desirable properties, w= ith
>> "requirements" having *s and "desiderata" mark= ed with "+". Opinions
>> may vary on the line here.
>>
>> 1. Allow one side to lose connection state (e.g., reboot) and stil= l
>>=C2=A0 =C2=A0 terminate the connection (*)
>> 2. Prevent off-path attackers from terminating the connection (*)<= br> >> 3. Don't require a public key operation for each termination (= *)
>> 4. Prevent on-path attackers from terminating the connection (+) >> 5. Allow on-path elements to determine when a connection was (+) >>=C2=A0 =C2=A0 terminated [I've marked this with "+" b= ut I recognize that
>>=C2=A0 =C2=A0 some might mark it with "-"]
>>
>> #5 seems like the most questionable property, but here's my ra= tionale.
>> Because network elements (Firewalls, NATs, etc.) can detect that a=
>> packet is a Public Reset from the header, they may opt to destroy<= br> >> their internal state upon receiving one. If the Public Reset isn&#= 39;t
>> verifiable by them, then they may just opt to destroy the state ba= sed
>> on seeing something with the right header.=C2=A0 This opens up an = on-path
>> attack where the attacker forges a Public Reset and thus blocks >> traffic at the middlebox even though the connection is still live = at the
>> endpoints.
>>
>> The design in this PR is based on hash preimages [1]. At the begin= ning
>> of the connection the server supplies a Verifier value which is >> computed as the Hash of a proof value, like so:
>>
>>=C2=A0 =C2=A0 Verifier =3D Hash(Proof).
>>
>> The Verifer is established at the beginning of the connection and<= br> >> stored with the connection record. When you want to reset a
>> connection, you simply send a reset packet that contains Proof. Th= e
>> peer verifies that Hash(Proof) =3D=3D Verifier and if so tears dow= n the
>> connection. As is this fulfills 2, 3, and 4 and optionally 5 if yo= u
>> expose the RVV to on-path elements during the handshake (or even >> periodically during the connection).
>>
>> This isn't completely stateless, but you can get away without<= br> >> per-connection state by computing the per-connection Proof from th= e
>> conn_id and some secret stored on the server. I.e.,
>>
>>=C2=A0 =C2=A0 Proof_conn =3D PRF(K_m, conn_id)
>>
>> Note that because Proof_conn does not itself leak K_m, seeing one<= br> >> connection reset doesn't allow resetting other connections. K_= m
>> can be stored and can survive reboots.
>>
>> I've tried to mimic the style of the document as best I can bu= t I'm
>> sure there's some stuff wrong here.
>>
>> Comments welcome.
>> -Ekr
>>
>>
>>
>> [1] Note that the QUIC Design Document and Rationale describes a >> slightly simpler mechanis that uses the same state-handling trick = I
>> describe here but uses what sounds like a MAC instead of a hash >> preimage. If you think that requirement #5 is a bad requirement th= en
>> that's probably a better design. Happy to write this up if it&= #39;s the WG
>> consensus.
>>
>


--94eb2c0a8f82a07a810542002b25-- From nobody Wed Nov 23 15:32:26 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FFE1293DA for ; Wed, 23 Nov 2016 15:32:25 -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 eKm6PbCf-rkB for ; Wed, 23 Nov 2016 15:32:23 -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 D6D3512941D for ; Wed, 23 Nov 2016 15:32:21 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id i145so25213513ywg.2 for ; Wed, 23 Nov 2016 15:32:21 -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=Bnh9IOFLuzp3m5/CmuF0AgvaNg0ZZxuy2GgQZp9QYZg=; b=xtbqhlCdRMSEwl6eyL+sZOWW12kPe3mT+5KA/+yzTlAGrPOPpOiHYfU6Hk9jFeibrc 59VB7RMwWieGvvsnwUqXRkOzgczrvM9ZlUT2pWRTA6UOOa8O5WACjQycCi1Np2RBMqzN BAWvQJCPi96Pp4W/fCu+mmnzYgNvpS2pmEx03PYm4HtjNHAVnpiI9WP6Xo8dlRwND7L9 LFhr4owyKYjYA9G+4DtEPFp8TUyun9lMJW2XW+qYHbDFuZbJRNKFyFlyNGI7IKt0KoLz Ga7MWS+yvAhTsLD+/psZ8aoPBZPOBgIEBu2AQwrhHkYQ827O768azlezy4bwxPe8SDMA EVog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bnh9IOFLuzp3m5/CmuF0AgvaNg0ZZxuy2GgQZp9QYZg=; b=KYx+/rMO2VrxvwYc1G9QuO0yTMFYXNMk3zcOy47fEfYBVmB8zi9frYFabcbEjkzB2M I6VYdRMnWSMTYDtNvHnjfJGuwyHGzIl4hR0WgoVAjK59kZHKfNk3nab8IfKdu1si0lUm e/AlloZMsaEgxnKUHIvkUmsoZ27j4ekJqIR34JxnwhAurXN0aMkofVwTXamywf4Yd42a Lm+BRJv5I89qIze5EG4XMl3EbxDuiCBKiwprQ1PmJcRrqcsf1mqMddVy2Da9REPxRYOW /K97CB5CDvq2Chv3Kh3OEvEdMUylznpZvFQzrUctSOPBjdVDjsbqrMEhoYv3nydE2NdM Nxbg== X-Gm-Message-State: AKaTC02+d8DKhR7zzMz0fbxLzbkQ9svzx68e1Z86rbj7VdkWmPMvvHuKjSwz34lZd38EW/Lnp/gxbS6kfEmDtw== X-Received: by 10.129.81.78 with SMTP id f75mr6421474ywb.149.1479943941061; Wed, 23 Nov 2016 15:32:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Wed, 23 Nov 2016 15:31:40 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 23 Nov 2016 15:31:40 -0800 Message-ID: Subject: Re: Public reset PR To: Mike Bishop Content-Type: multipart/alternative; boundary=001a11456404e54dd80542004cbf Archived-At: Cc: IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 23 Nov 2016 23:32:25 -0000 --001a11456404e54dd80542004cbf Content-Type: text/plain; charset=UTF-8 On Wed, Nov 23, 2016 at 3:10 PM, Mike Bishop wrote: > I semi-disagree with one element of your requirements list. It seems > valuable to enable on-path network infrastructure (indistinguishable from > on-path attackers) to notify the peers of an intention to interrupt > something about the connection. At the least, we need to discuss that > point rather than assuming it. > As you say, this is a requirements question. It seems like there are three possible points in this design space: - Only allow endpoint resets - Allow both endpoint and on-path resets but they are distinguishable - On-path resets are indistinguishable from endpoint resets So the WG needs to decide on this. As far as technical design, the way you do an on-path-only reset is to have it contain some value that was in the packet being reset and have that be high entropy. The good news is that all the encrypted packets are already high entropy (we may need to deal with the handshake packets a bit) so you can just include a digest of the packet you are rejecting from. If you want to have both kinds of reset and have them be distinguishable, you could use a type bit, or have both values present but the Proof be all zeroes or something... -Ekr > > Sent from my Windows 10 phone > > > > *From: *Martin Thomson > *Sent: *Wednesday, November 23, 2016 5:55 PM > *To: *Ryan Hamilton > *Cc: *Eric Rescorla ; IETF QUIC WG > *Subject: *Re: Public reset PR > > > So this seems to only be feasible for a server. That's something that > needs to be articulated somehow. That means that clients are unable > to construct a public reset. > > FWIW, there is currently no way to carry the verifier value. We'll > need to work on that. > > On 24 November 2016 at 09:49, Ryan Hamilton wrote: > > Sounds great to me. I agree that having public reset packets visible to > > middleboxes but unverifiable by them is problematic. > > > > On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla wrote: > >> > >> https://github.com/quicwg/base-drafts/pull/20 > >> > >> Hi folks, > >> > >> I just posted a PR to flesh out the Public Reset packet, which is > >> somewhat underspecified in the current document. > >> > >> First, let me lay out what I think are the desirable properties, with > >> "requirements" having *s and "desiderata" marked with "+". Opinions > >> may vary on the line here. > >> > >> 1. Allow one side to lose connection state (e.g., reboot) and still > >> terminate the connection (*) > >> 2. Prevent off-path attackers from terminating the connection (*) > >> 3. Don't require a public key operation for each termination (*) > >> 4. Prevent on-path attackers from terminating the connection (+) > >> 5. Allow on-path elements to determine when a connection was (+) > >> terminated [I've marked this with "+" but I recognize that > >> some might mark it with "-"] > >> > >> #5 seems like the most questionable property, but here's my rationale. > >> Because network elements (Firewalls, NATs, etc.) can detect that a > >> packet is a Public Reset from the header, they may opt to destroy > >> their internal state upon receiving one. If the Public Reset isn't > >> verifiable by them, then they may just opt to destroy the state based > >> on seeing something with the right header. This opens up an on-path > >> attack where the attacker forges a Public Reset and thus blocks > >> traffic at the middlebox even though the connection is still live at the > >> endpoints. > >> > >> The design in this PR is based on hash preimages [1]. At the beginning > >> of the connection the server supplies a Verifier value which is > >> computed as the Hash of a proof value, like so: > >> > >> Verifier = Hash(Proof). > >> > >> The Verifer is established at the beginning of the connection and > >> stored with the connection record. When you want to reset a > >> connection, you simply send a reset packet that contains Proof. The > >> peer verifies that Hash(Proof) == Verifier and if so tears down the > >> connection. As is this fulfills 2, 3, and 4 and optionally 5 if you > >> expose the RVV to on-path elements during the handshake (or even > >> periodically during the connection). > >> > >> This isn't completely stateless, but you can get away without > >> per-connection state by computing the per-connection Proof from the > >> conn_id and some secret stored on the server. I.e., > >> > >> Proof_conn = PRF(K_m, conn_id) > >> > >> Note that because Proof_conn does not itself leak K_m, seeing one > >> connection reset doesn't allow resetting other connections. K_m > >> can be stored and can survive reboots. > >> > >> I've tried to mimic the style of the document as best I can but I'm > >> sure there's some stuff wrong here. > >> > >> Comments welcome. > >> -Ekr > >> > >> > >> > >> [1] Note that the QUIC Design Document and Rationale describes a > >> slightly simpler mechanis that uses the same state-handling trick I > >> describe here but uses what sounds like a MAC instead of a hash > >> preimage. If you think that requirement #5 is a bad requirement then > >> that's probably a better design. Happy to write this up if it's the WG > >> consensus. > >> > > > > --001a11456404e54dd80542004cbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 23, 2016 at 3:10 PM, Mike Bishop <Michael.Bishop@micros= oft.com> wrote:

I semi-disagree with one ele= ment of your requirements list.=C2=A0 It seems valuable to enable on-path n= etwork infrastructure (indistinguishable from on-path attackers) to notify = the peers of an intention to interrupt something about the connection.=C2= =A0 At the least, we need to discuss that point rather than assuming it.

As you say, this is a requirements questi= on. It seems like there are three possible points in
this design = space:

- Only allow endpoint resets
- Al= low both endpoint and on-path resets but they are distinguishable
- On-path resets are indistinguishable from endpoint resets
=
So the WG needs to decide on this.

= As far as technical design, the way you do an on-path-only reset is to have= it contain
some value that was in the packet being reset and hav= e that be high entropy. The
good news is that all the encrypted p= ackets are already high entropy (we may need
to deal with the han= dshake packets a bit) so you can just include a digest of the
pac= ket you are rejecting from. If you want to have both kinds of reset and hav= e
them be distinguishable, you could use a type bit, or have both= values present
but the Proof be all zeroes or something...
=

-Ekr



=

=C2=A0

Sent from my Windows 10 phon= e

=C2=A0

From: Martin Thomson
Sent: Wednesday, November 23, 2016 5:55 PM
To: Ryan Hamilto= n
Cc: Eric Rescorla<= /a>; IETF QUIC WG
Subject: Re: Public reset PR

=C2=A0

So this seems to only be fea= sible for a server.=C2=A0 That's something that
needs to be articulated somehow.=C2=A0 That means that clients are unable to construct a public reset.

FWIW, there is currently no way to carry the verifier value.=C2=A0 We'l= l
need to work on that.

On 24 November 2016 at 09:49, Ryan Hamilton <rch@google.com> wrote:
> Sounds great to me. I agree that having public reset packets visible t= o
> middleboxes but unverifiable by them is problematic.
>
> On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>>
>> https://github.com/quicwg/base-drafts/pull/20
>>
>> Hi folks,
>>
>> I just posted a PR to flesh out the Public Reset packet, which is<= br> >> somewhat underspecified in the current document.
>>
>> First, let me lay out what I think are the desirable properties, w= ith
>> "requirements" having *s and "desiderata" mark= ed with "+". Opinions
>> may vary on the line here.
>>
>> 1. Allow one side to lose connection state (e.g., reboot) and stil= l
>>=C2=A0=C2=A0=C2=A0 terminate the connection (*)
>> 2. Prevent off-path attackers from terminating the connection (*)<= br> >> 3. Don't require a public key operation for each termination (= *)
>> 4. Prevent on-path attackers from terminating the connection (+) >> 5. Allow on-path elements to determine when a connection was (+) >>=C2=A0=C2=A0=C2=A0 terminated [I've marked this with "+&qu= ot; but I recognize that
>>=C2=A0=C2=A0=C2=A0 some might mark it with "-"]
>>
>> #5 seems like the most questionable property, but here's my ra= tionale.
>> Because network elements (Firewalls, NATs, etc.) can detect that a=
>> packet is a Public Reset from the header, they may opt to destroy<= br> >> their internal state upon receiving one. If the Public Reset isn&#= 39;t
>> verifiable by them, then they may just opt to destroy the state ba= sed
>> on seeing something with the right header.=C2=A0 This opens up an = on-path
>> attack where the attacker forges a Public Reset and thus blocks >> traffic at the middlebox even though the connection is still live = at the
>> endpoints.
>>
>> The design in this PR is based on hash preimages [1]. At the begin= ning
>> of the connection the server supplies a Verifier value which is >> computed as the Hash of a proof value, like so:
>>
>>=C2=A0=C2=A0=C2=A0 Verifier =3D Hash(Proof).
>>
>> The Verifer is established at the beginning of the connection and<= br> >> stored with the connection record. When you want to reset a
>> connection, you simply send a reset packet that contains Proof. Th= e
>> peer verifies that Hash(Proof) =3D=3D Verifier and if so tears dow= n the
>> connection. As is this fulfills 2, 3, and 4 and optionally 5 if yo= u
>> expose the RVV to on-path elements during the handshake (or even >> periodically during the connection).
>>
>> This isn't completely stateless, but you can get away without<= br> >> per-connection state by computing the per-connection Proof from th= e
>> conn_id and some secret stored on the server. I.e.,
>>
>>=C2=A0=C2=A0=C2=A0 Proof_conn =3D PRF(K_m, conn_id)
>>
>> Note that because Proof_conn does not itself leak K_m, seeing one<= br> >> connection reset doesn't allow resetting other connections. K_= m
>> can be stored and can survive reboots.
>>
>> I've tried to mimic the style of the document as best I can bu= t I'm
>> sure there's some stuff wrong here.
>>
>> Comments welcome.
>> -Ekr
>>
>>
>>
>> [1] Note that the QUIC Design Document and Rationale describes a >> slightly simpler mechanis that uses the same state-handling trick = I
>> describe here but uses what sounds like a MAC instead of a hash >> preimage. If you think that requirement #5 is a bad requirement th= en
>> that's probably a better design. Happy to write this up if it&= #39;s the WG
>> consensus.
>>
>

--001a11456404e54dd80542004cbf-- From nobody Thu Nov 24 06:44:16 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BE4129461 for ; Thu, 24 Nov 2016 06:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvkgB-1g3qbs for ; Thu, 24 Nov 2016 06:44:13 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id BAB57129428 for ; Thu, 24 Nov 2016 06:44:12 -0800 (PST) Received: from [10.183.85.85] (host108-2.natpool.mwn.de [138.246.2.108]) by trammell.ch (Postfix) with ESMTPSA id 9B1391A0589; Thu, 24 Nov 2016 15:44:11 +0100 (CET) Subject: Re: Public reset PR Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_5405F0A2-A340-434A-B1AE-DB827C83BDA8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Thu, 24 Nov 2016 15:44:10 +0100 Message-Id: <024A81A9-567F-4C64-B2CE-F29F5209FFBB@trammell.ch> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Mike Bishop , IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 24 Nov 2016 14:44:15 -0000 --Apple-Mail=_5405F0A2-A340-434A-B1AE-DB827C83BDA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 24 Nov 2016, at 00:31, Eric Rescorla wrote: >=20 > On Wed, Nov 23, 2016 at 3:10 PM, Mike Bishop = wrote: > I semi-disagree with one element of your requirements list. It seems = valuable to enable on-path network infrastructure (indistinguishable = from on-path attackers) to notify the peers of an intention to interrupt = something about the connection. At the least, we need to discuss that = point rather than assuming it. >=20 > As you say, this is a requirements question. It seems like there are = three possible points in > this design space: >=20 > - Only allow endpoint resets > - Allow both endpoint and on-path resets but they are distinguishable Note that since an on-path device that's also forwarding packets has the = ability to drop the packets, "allow only endpoint resets" simply has the = effect of making on-path resets invisible to the endpoints, while = increasing the amount of state an on-path device needs to keep in order = to "enforce" its reset. > - On-path resets are indistinguishable from endpoint resets This seems undesirable. > So the WG needs to decide on this. >=20 > As far as technical design, the way you do an on-path-only reset is to = have it contain > some value that was in the packet being reset and have that be high = entropy. The > good news is that all the encrypted packets are already high entropy = (we may need > to deal with the handshake packets a bit) so you can just include a = digest of the > packet you are rejecting from. If you want to have both kinds of reset = and have > them be distinguishable, you could use a type bit, or have both values = present > but the Proof be all zeroes or something... I like this proposal -- it makes on-path and endpoint resets = distinguishable as well as making on-path resets verifiable by on-path = devices as well as endpoints, without requiring any durable state in the = on-path device. Thanks, cheers, Brian >=20 > -Ekr >=20 >=20 >=20 >=20 > Sent from my Windows 10 phone >=20 >=20 > From: Martin Thomson > Sent: Wednesday, November 23, 2016 5:55 PM > To: Ryan Hamilton > Cc: Eric Rescorla; IETF QUIC WG > Subject: Re: Public reset PR >=20 >=20 > So this seems to only be feasible for a server. That's something that > needs to be articulated somehow. That means that clients are unable > to construct a public reset. >=20 > FWIW, there is currently no way to carry the verifier value. We'll > need to work on that. >=20 > On 24 November 2016 at 09:49, Ryan Hamilton wrote: > > Sounds great to me. I agree that having public reset packets visible = to > > middleboxes but unverifiable by them is problematic. > > > > On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla wrote: > >> > >> https://github.com/quicwg/base-drafts/pull/20 > >> > >> Hi folks, > >> > >> I just posted a PR to flesh out the Public Reset packet, which is > >> somewhat underspecified in the current document. > >> > >> First, let me lay out what I think are the desirable properties, = with > >> "requirements" having *s and "desiderata" marked with "+". Opinions > >> may vary on the line here. > >> > >> 1. Allow one side to lose connection state (e.g., reboot) and still > >> terminate the connection (*) > >> 2. Prevent off-path attackers from terminating the connection (*) > >> 3. Don't require a public key operation for each termination (*) > >> 4. Prevent on-path attackers from terminating the connection (+) > >> 5. Allow on-path elements to determine when a connection was (+) > >> terminated [I've marked this with "+" but I recognize that > >> some might mark it with "-"] > >> > >> #5 seems like the most questionable property, but here's my = rationale. > >> Because network elements (Firewalls, NATs, etc.) can detect that a > >> packet is a Public Reset from the header, they may opt to destroy > >> their internal state upon receiving one. If the Public Reset isn't > >> verifiable by them, then they may just opt to destroy the state = based > >> on seeing something with the right header. This opens up an = on-path > >> attack where the attacker forges a Public Reset and thus blocks > >> traffic at the middlebox even though the connection is still live = at the > >> endpoints. > >> > >> The design in this PR is based on hash preimages [1]. At the = beginning > >> of the connection the server supplies a Verifier value which is > >> computed as the Hash of a proof value, like so: > >> > >> Verifier =3D Hash(Proof). > >> > >> The Verifer is established at the beginning of the connection and > >> stored with the connection record. When you want to reset a > >> connection, you simply send a reset packet that contains Proof. The > >> peer verifies that Hash(Proof) =3D=3D Verifier and if so tears down = the > >> connection. As is this fulfills 2, 3, and 4 and optionally 5 if you > >> expose the RVV to on-path elements during the handshake (or even > >> periodically during the connection). > >> > >> This isn't completely stateless, but you can get away without > >> per-connection state by computing the per-connection Proof from the > >> conn_id and some secret stored on the server. I.e., > >> > >> Proof_conn =3D PRF(K_m, conn_id) > >> > >> Note that because Proof_conn does not itself leak K_m, seeing one > >> connection reset doesn't allow resetting other connections. K_m > >> can be stored and can survive reboots. > >> > >> I've tried to mimic the style of the document as best I can but I'm > >> sure there's some stuff wrong here. > >> > >> Comments welcome. > >> -Ekr > >> > >> > >> > >> [1] Note that the QUIC Design Document and Rationale describes a > >> slightly simpler mechanis that uses the same state-handling trick I > >> describe here but uses what sounds like a MAC instead of a hash > >> preimage. If you think that requirement #5 is a bad requirement = then > >> that's probably a better design. Happy to write this up if it's the = WG > >> consensus. > >> > > >=20 >=20 --Apple-Mail=_5405F0A2-A340-434A-B1AE-DB827C83BDA8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYNvy7AAoJEIoSt78L6kajkWgQAKA2tWWPMmx1hNIGUDR6fXmo Y+QX3ubn1aOC27kfWTmtEgvh/UPk6h9P2ntl/DY9DN8pMlwUTKmn5BwzISSdzJdZ +KFEtiA5lG6iWK1ClTNUtT6LZWvJ1HZdlpy24/Jt6227ZbQx84S70JhAG8kvFAh1 R7x6v35Gas9zvDY1O0K5MQV4yM3zisplUGUVyAxUVbQc4pcdtyVs4Y+qh6tU2Z+v RicwNFdiute83Tf6tX5xAC6IUxeP88ry8hY8u7lmutrUR6lrLNf/rodCqNIvlqbr kMa2tssUwS2jxbUO7f5OnKHsSMtwyOgT53LQuI67tdEzx1A66+cyiGHdiDYzXkYg FFxKI++MAslCGt8uAyELcd/QDpuNq7ahdHpd9bNMJbA8oejzt0PObC7NWqsPusAk KLqSYHT8K0KshPs5luFd0Q+aWv0BL7xRN8rkBW7n/RoMBwQIn6ECZLE8LHfQUoFq WccK/1XVKpbW99v9jd1woyyod692+Q1Ee59l2CUCwUvdJ3R2AOzb0iAZDTJNAO2R NvJ8nbrOYC0yWYeamE2XetUR6AqVGwehUjx/pp4a/C89Y4+VcSxsGu9aku2ybFz4 rhrmIIFD9gQhBRKUQv4+oZND8Ok7WRO57vD/sKagR/HyX2VEhOTSBY/ydFaWofa1 Ble5VvN+aZ7vfNvh577b =m3kc -----END PGP SIGNATURE----- --Apple-Mail=_5405F0A2-A340-434A-B1AE-DB827C83BDA8-- From nobody Thu Nov 24 07:46:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26AE9129644 for ; Thu, 24 Nov 2016 07:46:39 -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 oSTH3vowDRE5 for ; Thu, 24 Nov 2016 07:46:35 -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 849111293F9 for ; Thu, 24 Nov 2016 07:46:35 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id p16so43398650qta.0 for ; Thu, 24 Nov 2016 07:46:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=J+I/2L1Qor5PNMMc29vEj2jpDgA6uAWTpcDQkjeMwQ4=; b=XtmtwT9nvHFwVS5TVt/LIk/3NVAB55pwUCvVnA9fhM+v6FiVVnGQrXIbi3bdys65V1 g5ef1HNHGxMxZLVT+TNAjkw61WcDKAHOorCPIjyRluQsuVw1RK5offsc5bTYsL7JdztT 2gKG4padLJSVFZRwtXHe1+UO9pjWp4A2VIbr3tB9yC6eNK4LlVSr+RwYYpk7mFa8TDoY qyPmdznVYm1OPmjENLNEJqYAy/lcgpawJH6fdLlIrAF0DnRg0uPJTr8EqyKgtgmSr+j3 FXQhVXFrNoGG747Tw/sD4aeY9Ay4/XS/E+Wyr34qXjNjUDmZ/o1REqsgafmmARvuRH+l yjag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=J+I/2L1Qor5PNMMc29vEj2jpDgA6uAWTpcDQkjeMwQ4=; b=Yw7N0hTI8o+0qbXYx8nLOCGhvy6npfIJ9061hYe7pppZy7pR3WyqAS9b0nc4tQeYLh QFNFlqJGTQtnjdu0CNAVy7ZsKHtMxjpqhcaeb1xK1nEo0IN5OFnSX6ixYua1sRSx2NQu peF1EMA2cmWekTqL1zSzjZ5Fy3S2lPOb+NWXN2qr2eSf5CQ63vCrKKgBC75Ypji73DUt OOkNWLB2aFvKPvl7J8DVKFj/89ISsBY0MBPgwjeQ+SnVO+JPwan8WaKGPwTfyv1EvSK0 58+xeUkoTx+OwfZ1ya6Pqtl9r38T1KlPdALMVjL3kczodDkRnrHVNpOVxLDlndZudL90 Uh5w== X-Gm-Message-State: AKaTC01GBh9Xsp1zFmY1uU+2Ms8cd4ZUmnP9Hn2+xkhlgdviYr3yyjbQ3wamCb6TNNFHAY90uENr6UHlPtnVIA== X-Received: by 10.200.36.171 with SMTP id s40mr2462347qts.142.1480002394505; Thu, 24 Nov 2016 07:46:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.226 with HTTP; Thu, 24 Nov 2016 07:46:14 -0800 (PST) From: Tatsuhiro Tsujikawa Date: Fri, 25 Nov 2016 00:46:14 +0900 Message-ID: Subject: [quic-protocol] "outstanding data" retransmission To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a11403342fdc80205420de856 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 24 Nov 2016 15:46:39 -0000 --001a11403342fdc80205420de856 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have a question regarding "outstanding data" retransmission specifically, https://tools.ietf.org/html/draft-hamilton-quic-transport-protocol-01#secti= on-7 """ A packet may contain frames and/or application data, only some of which may require reliability. When a packet is detected as lost, the sender SHOULD only resend frames that require retransmission. o All application data sent in STREAM frames MUST be retransmitted, with one exception. When an endpoint sends a RST_STREAM frame, data outstanding on that stream SHOULD NOT be retransmitted, since subsequent data on this stream is expected to not be delivered by the receiver. """ First bullet states that endpoint should not retransmit data outstanding on the stream where it sent RST_STREAM. The question is: what "data outstanding" actually means? Is the STREAM frame that has been sent before sending RST_STREAM and not ACKed yet? Or it the STREAM frame which has not sent yet? Or both? I suspect that it means the STREAM frame that has been sent before RST_STREAM but not ACKed yet. This is because the above text uses "retransmitted" which indicates that they have been sent once. And sending STREAM frame after RST_STREAM is obviously protocol error. If it is correct, and if we assume that RST_STREAM of HTTP/2 is directly mapped to quic's RST_STREAM (well, this is not mentioned in h2 mapping document, not sure why), we might miss the valid use case described in RFC 7540, section 8.1: https://tools.ietf.org/html/rfc7540#section-8.1 """ An HTTP response is complete after the server sends -- or the client receives -- a frame with the END_STREAM flag set (including any CONTINUATION frames needed to complete a header block). A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending a complete response (i.e., a frame with the END_STREAM flag). Clients MUST NOT discard responses as a result of receiving such a RST_STREAM, though clients can always discard responses at their discretion for other reasons. """ If packet containing STREAM and RST_STREAM frames is lost, then we will retransmit, but we =E2=80=8Bare =E2=80=8B only allowed to retransmit RST_STREAM. We can still send RST_STREAM after getting ACK against STREAM frame from peer, but it incurs latency, and it is unnecessarily complicated. Over TCP, we just send them in one packet, and it works fine. Best regards, Tatsuhiro Tsujikawa --001a11403342fdc80205420de856 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have a question regarding "outstanding d= ata" retransmission specifically,
https://tools.ie= tf.org/html/draft-hamilton-quic-transport-protocol-01#section-7

= """
=C2=A0=C2=A0 A packet may contain frames and/or appli= cation data, only some of
=C2=A0=C2=A0 which may require reliability.=C2= =A0 When a packet is detected as lost,
=C2=A0=C2=A0 the sender SHOULD on= ly resend frames that require retransmission.

=C2=A0=C2=A0 o=C2=A0 A= ll application data sent in STREAM frames MUST be retransmitted,
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 with one exception.=C2=A0 When an endpoint sends a= RST_STREAM frame,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 data outstanding on th= at stream SHOULD NOT be retransmitted, since
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 subsequent data on this stream is expected to not be delivered by
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 the receiver.
"""

F= irst bullet states that endpoint should not retransmit data
outstanding = on the stream where it sent RST_STREAM.

The question is: what "= data outstanding" actually means?=C2=A0 Is the
STREAM frame that ha= s been sent before sending RST_STREAM and not
ACKed yet?=C2=A0 Or it the= STREAM frame which has not sent yet?=C2=A0 Or
both?

I suspect th= at it means the STREAM frame that has been sent
before RST_STREAM but no= t ACKed yet.=C2=A0 This is because the above
text uses "retransmitt= ed" which indicates that they have been
sent once.=C2=A0 And sendin= g STREAM frame after RST_STREAM is
obviously protocol error.

If i= t is correct, and if we assume that RST_STREAM of HTTP/2 is
directly map= ped to quic's RST_STREAM (well, this is not mentioned
in h2 mapping = document, not sure why), we might miss the
valid use case described in R= FC 7540, section 8.1:

https://tools.ietf.org/html/rfc7540#section-8.1

&q= uot;""
=C2=A0=C2=A0 An HTTP response is complete after the ser= ver sends -- or the client
=C2=A0=C2=A0 receives -- a frame with the END= _STREAM flag set (including any
=C2=A0=C2=A0 CONTINUATION frames needed = to complete a header block).=C2=A0 A server can
=C2=A0=C2=A0 send a comp= lete response prior to the client sending an entire
=C2=A0=C2=A0 request= if the response does not depend on any portion of the request
=C2=A0=C2= =A0 that has not been sent and received.=C2=A0 When this is true, a server = MAY
=C2=A0=C2=A0 request that the client abort transmission of a request= without error
=C2=A0=C2=A0 by sending a RST_STREAM with an error code o= f NO_ERROR after sending
=C2=A0=C2=A0 a complete response (i.e., a frame= with the END_STREAM flag).
=C2=A0=C2=A0 Clients MUST NOT discard respon= ses as a result of receiving such a
=C2=A0=C2=A0 RST_STREAM, though clie= nts can always discard responses at their
=C2=A0=C2=A0 discretion for ot= her reasons.
"""

If packet containing STREAM and R= ST_STREAM frames is lost, then
we will retransmit, but we
=E2=80=8Bare =E2=80=8B
only allowed to retransmit = RST_STREAM.
We can still send RST_STREAM after getting ACK against STREA= M
frame from peer, but it incurs latency, and it is unnecessarily
com= plicated.=C2=A0 Over TCP, we just send them in one packet, and it
works = fine.



Best regards,
Tatsuhiro Tsujikawa

--001a11403342fdc80205420de856-- From nobody Thu Nov 24 07:57:04 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1464129961 for ; Thu, 24 Nov 2016 07:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lenoC9BTo38V for ; Thu, 24 Nov 2016 07:57:01 -0800 (PST) Received: from mail-wj0-x234.google.com (mail-wj0-x234.google.com [IPv6:2a00:1450:400c:c01::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 6FFC4129461 for ; Thu, 24 Nov 2016 07:57:01 -0800 (PST) Received: by mail-wj0-x234.google.com with SMTP id v7so36661362wjy.2 for ; Thu, 24 Nov 2016 07:57:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IT1LJIM/LzsPTEDix0RdpxPpeJzsYiQH0l8qOOljhJk=; b=mWy4M7H8wbsGojyd0nl+bhr+5Q/lc/kVFxhxcGN4OG3641w+Uj9f8Hww+aILRgODz2 LfQEvG53BbehKk0Awfa3d0YphsA+mUoCsHKZ704DCpZrJFWb0F5u2Eh3mtTfaQhWoXxD 66dBColIbAZ7b4Qm4hpoA8PG9xGO29Gieljw/cP0Mfu+nsEIDWxIcWqdp1iz2s8VZCJt oESmGlO3mSE8bLV33bTZKoHvOIhzXTD2bjpKpihjIzdorNNlebRff+jtRMasUnC6/ZkZ 8sX03Dt0v7dSqEo8+czpFPdF/aUdlUZ0NuHZSlJNURcoR0kcCwaffsHL8w972wY4NuGo 8raA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IT1LJIM/LzsPTEDix0RdpxPpeJzsYiQH0l8qOOljhJk=; b=RK7y8n3eac13+zwk416jgfBK8/3rtlD67CzvHY8Ntb7ROUXX1ZCXjxIpxQFm9jnTk1 JmONAC64mYMWeRA7WqtIfnDWfLEFayn/J3v6o8rD4wjN7LDJzCrikHgN4mQOsyoSkfHa h3MaZr+7/B/dkHiH8tPjcWRn2sHSEk1GwYcQxI1vPZ2trKTNQWXiirBMjxltSm3l7JvK oG4mTQIv7Lfr2nkpsY19LfptKZ1IWQwU2EuCgnXWRRhUxwokQ+joMm46aauEMRaQgHno 7C/vP2JLu4t8KFhEJfBJZAGlU8XOJ5aW6lwPKHnPxVAVS3/TyXbhQPzaVEcRU6XKtnPZ M2BA== X-Gm-Message-State: AKaTC02azgwVGdTdub6E+5orM5nXkJZ0cyokT0jfjlPZAOxR7pZGMSKIox4s8tXv56nMI+PYY03K6jOfBeu6bQE6 X-Received: by 10.194.109.42 with SMTP id hp10mr2937098wjb.167.1480003019864; Thu, 24 Nov 2016 07:56:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.22 with HTTP; Thu, 24 Nov 2016 07:56:59 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 24 Nov 2016 07:56:59 -0800 Message-ID: Subject: Re: [quic-protocol] "outstanding data" retransmission To: Tatsuhiro Tsujikawa Content-Type: multipart/alternative; boundary=089e0102d80044536105420e0eec Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 24 Nov 2016 15:57:03 -0000 --089e0102d80044536105420e0eec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 24, 2016 at 7:46 AM, Tatsuhiro Tsujikawa wrote: > If it is correct, and if we assume that RST_STREAM of HTTP/2 is > directly mapped to quic's RST_STREAM (well, this is not mentioned > in h2 mapping document, not sure why), we might miss the > valid use case described in RFC 7540, section 8.1: > =E2=80=8BIndeed, when a RST_STREAM NO_ERROR is sent the endpoint should con= tinue retransmitting outstanding data. --089e0102d80044536105420e0eec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Nov 24, 2016 at 7:46 AM, Tatsuhiro Tsujikawa <= tatsuhiro.t@gmail.com> wrote:
If it is correct, and if we assume that RST_STREAM of = HTTP/2 is
directly mapped to quic's RST_STREAM (well, this is not me= ntioned
in h2 mapping document, not sure why), we might miss the
vali= d use case described in RFC 7540, section 8.1:
=
=E2=80=8BIndeed, when a RST_STREAM NO_ERROR is sent the end= point should continue retransmitting outstanding data.

--089e0102d80044536105420e0eec-- From nobody Thu Nov 24 11:52:41 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15DC129AF1 for ; Thu, 24 Nov 2016 11:52: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 vgNrVWK96jP6 for ; Thu, 24 Nov 2016 11:52:38 -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 39EE5129AD8 for ; Thu, 24 Nov 2016 11:52:38 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id i145so46776172ywg.2 for ; Thu, 24 Nov 2016 11:52:38 -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=HDnrdN58EYtmoQhrbncX9EpNfIYdMq2yzg6MsJ6KXPc=; b=KIsuzernLXJCz+3h0d1PzyM78CDZSDw8tdSLKzdV+UvNXzyI9HG06bPThrtdeczOMm UFnZKj6IEs1asMAKTYZFD029miBbZiZ5kdd7QtOsRSjChpaN4zwsGV6iDAHbCGVRBzRf HBWHHDAUUYUjb+xMxTNEJ0kkNY5kCQXQQ4dK7rveRxbzSx+mEoeLt8NSgJ/CZxxpBjMP g6gFDjmjJMyhD9vJ97HV6nCiqveDwlLhnErGCYA8boz1YrI7Ec5XMbSoKjzVCZ5/fiGJ 9q6o/fDuv4Si4fTZIkwOXpHf7g57JHAeSlmO+1ntYRaE/rXWgknh6jFqTbU0Bc+RNExK yE9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HDnrdN58EYtmoQhrbncX9EpNfIYdMq2yzg6MsJ6KXPc=; b=G0klWfgDqFgUWJ735uX5pmPAma2uCE83rqacNGtcKtvCZV1YV+RvnCqOPqtfXkmKXs +1jbR9uI5gFsMBcqI14i6FO/ucURWtfIiOOm0TNiYO12IijliarPMC5ftryLiBCemKFa u2mIfp/qwvOb8/+71O90rtH+k/j5Q5tLNGMAO5qlaywcRYGnvLC9ZsNzuY01JIY/ZzQB iAv5zJHyaquJdlvcCbzgjoyI7UB8XzTgQpG23X1kmvsGijvLfJqlvs+iv2SkdmvuL+/X GFD2VQnFYh1cj9i8X8b7/Hp0ouUF8tJtFVuAI8cY2oRzkBjT+e5GdPehzMK9c55xkL0Y qRKw== X-Gm-Message-State: AKaTC01GJW1aOD28BvG/NrXfxFA8M7UhPfI99ax56Fdv4jZ4El4Kubp4evDOi511Ei5YO+WFK1nTVEWsMihyig== X-Received: by 10.129.78.71 with SMTP id c68mr5095405ywb.21.1480017157416; Thu, 24 Nov 2016 11:52:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Thu, 24 Nov 2016 11:51:56 -0800 (PST) In-Reply-To: <024A81A9-567F-4C64-B2CE-F29F5209FFBB@trammell.ch> References: <024A81A9-567F-4C64-B2CE-F29F5209FFBB@trammell.ch> From: Eric Rescorla Date: Thu, 24 Nov 2016 11:51:56 -0800 Message-ID: Subject: Re: Public reset PR To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114dac9cee33ba0542115800 Archived-At: Cc: Mike Bishop , IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 24 Nov 2016 19:52:40 -0000 --001a114dac9cee33ba0542115800 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 24, 2016 at 6:44 AM, Brian Trammell wrote: > > > On 24 Nov 2016, at 00:31, Eric Rescorla wrote: > > > > On Wed, Nov 23, 2016 at 3:10 PM, Mike Bishop < > Michael.Bishop@microsoft.com> wrote: > > I semi-disagree with one element of your requirements list. It seems > valuable to enable on-path network infrastructure (indistinguishable from > on-path attackers) to notify the peers of an intention to interrupt > something about the connection. At the least, we need to discuss that > point rather than assuming it. > > > > As you say, this is a requirements question. It seems like there are > three possible points in > > this design space: > > > > - Only allow endpoint resets > > - Allow both endpoint and on-path resets but they are distinguishable > > Note that since an on-path device that's also forwarding packets has the > ability to drop the packets, "allow only endpoint resets" simply has the > effect of making on-path resets invisible to the endpoints, while > increasing the amount of state an on-path device needs to keep in order to > "enforce" its reset. > This is true for on-path devices that are forwarding, but other devices (e.g., on wireless networks) can be on-path but not forwarding. For such devices, making it difficult for them to force a reset might provide some security benefit to the endpoint. > > - On-path resets are indistinguishable from endpoint resets > > This seems undesirable. I agree. > > > So the WG needs to decide on this. > > > > As far as technical design, the way you do an on-path-only reset is to > have it contain > > some value that was in the packet being reset and have that be high > entropy. The > > good news is that all the encrypted packets are already high entropy (we > may need > > to deal with the handshake packets a bit) so you can just include a > digest of the > > packet you are rejecting from. If you want to have both kinds of reset > and have > > them be distinguishable, you could use a type bit, or have both values > present > > but the Proof be all zeroes or something... > > I like this proposal -- it makes on-path and endpoint resets > distinguishable as well as making on-path resets verifiable by on-path > devices as well as endpoints, without requiring any durable state in the > on-path device. > I'll await the judgement of the chairs and the editors as to how they want this PR to look and adjust accordingly. -Ekr > Thanks, cheers, > > Brian > > > > > -Ekr > > > > > > > > > > Sent from my Windows 10 phone > > > > > > From: Martin Thomson > > Sent: Wednesday, November 23, 2016 5:55 PM > > To: Ryan Hamilton > > Cc: Eric Rescorla; IETF QUIC WG > > Subject: Re: Public reset PR > > > > > > So this seems to only be feasible for a server. That's something that > > needs to be articulated somehow. That means that clients are unable > > to construct a public reset. > > > > FWIW, there is currently no way to carry the verifier value. We'll > > need to work on that. > > > > On 24 November 2016 at 09:49, Ryan Hamilton wrote: > > > Sounds great to me. I agree that having public reset packets visible to > > > middleboxes but unverifiable by them is problematic. > > > > > > On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla wrote: > > >> > > >> https://github.com/quicwg/base-drafts/pull/20 > > >> > > >> Hi folks, > > >> > > >> I just posted a PR to flesh out the Public Reset packet, which is > > >> somewhat underspecified in the current document. > > >> > > >> First, let me lay out what I think are the desirable properties, with > > >> "requirements" having *s and "desiderata" marked with "+". Opinions > > >> may vary on the line here. > > >> > > >> 1. Allow one side to lose connection state (e.g., reboot) and still > > >> terminate the connection (*) > > >> 2. Prevent off-path attackers from terminating the connection (*) > > >> 3. Don't require a public key operation for each termination (*) > > >> 4. Prevent on-path attackers from terminating the connection (+) > > >> 5. Allow on-path elements to determine when a connection was (+) > > >> terminated [I've marked this with "+" but I recognize that > > >> some might mark it with "-"] > > >> > > >> #5 seems like the most questionable property, but here's my rationale. > > >> Because network elements (Firewalls, NATs, etc.) can detect that a > > >> packet is a Public Reset from the header, they may opt to destroy > > >> their internal state upon receiving one. If the Public Reset isn't > > >> verifiable by them, then they may just opt to destroy the state based > > >> on seeing something with the right header. This opens up an on-path > > >> attack where the attacker forges a Public Reset and thus blocks > > >> traffic at the middlebox even though the connection is still live at > the > > >> endpoints. > > >> > > >> The design in this PR is based on hash preimages [1]. At the beginning > > >> of the connection the server supplies a Verifier value which is > > >> computed as the Hash of a proof value, like so: > > >> > > >> Verifier = Hash(Proof). > > >> > > >> The Verifer is established at the beginning of the connection and > > >> stored with the connection record. When you want to reset a > > >> connection, you simply send a reset packet that contains Proof. The > > >> peer verifies that Hash(Proof) == Verifier and if so tears down the > > >> connection. As is this fulfills 2, 3, and 4 and optionally 5 if you > > >> expose the RVV to on-path elements during the handshake (or even > > >> periodically during the connection). > > >> > > >> This isn't completely stateless, but you can get away without > > >> per-connection state by computing the per-connection Proof from the > > >> conn_id and some secret stored on the server. I.e., > > >> > > >> Proof_conn = PRF(K_m, conn_id) > > >> > > >> Note that because Proof_conn does not itself leak K_m, seeing one > > >> connection reset doesn't allow resetting other connections. K_m > > >> can be stored and can survive reboots. > > >> > > >> I've tried to mimic the style of the document as best I can but I'm > > >> sure there's some stuff wrong here. > > >> > > >> Comments welcome. > > >> -Ekr > > >> > > >> > > >> > > >> [1] Note that the QUIC Design Document and Rationale describes a > > >> slightly simpler mechanis that uses the same state-handling trick I > > >> describe here but uses what sounds like a MAC instead of a hash > > >> preimage. If you think that requirement #5 is a bad requirement then > > >> that's probably a better design. Happy to write this up if it's the WG > > >> consensus. > > >> > > > > > > > > > --001a114dac9cee33ba0542115800 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 24, 2016 at 6:44 AM, Brian Trammell <<= a href=3D"mailto:ietf@trammell.ch" target=3D"_blank">ietf@trammell.ch&g= t; wrote:

> On 24 Nov 2016, at 00:31, Eric Rescorla <ekr@rtfm.com> wrote:
>
> On Wed, Nov 23, 2016 at 3:10 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> I semi-disagree with one element of your requirements list.=C2=A0 It s= eems valuable to enable on-path network infrastructure (indistinguishable f= rom on-path attackers) to notify the peers of an intention to interrupt som= ething about the connection.=C2=A0 At the least, we need to discuss that po= int rather than assuming it.
>
> As you say, this is a requirements question. It seems like there are t= hree possible points in
> this design space:
>
> - Only allow endpoint resets
> - Allow both endpoint and on-path resets but they are distinguishable<= br>
Note that since an on-path device that's also forwarding packets= has the ability to drop the packets, "allow only endpoint resets"= ; simply has the effect of making on-path resets invisible to the endpoints= , while increasing the amount of state an on-path device needs to keep in o= rder to "enforce" its reset.

= This is true for on-path devices that are forwarding, but other devices (e.= g., on wireless networks) can be on-path but not forwarding. For such devic= es, making it difficult for them to force a reset might provide some securi= ty benefit to the endpoint.

=C2=A0
> - On-path resets are indistinguishable from endpoint resets

This seems undesirable.

I agree.

=C2=A0

> So the WG needs to decide on this.
>
> As far as technical design, the way you do an on-path-only reset is to= have it contain
> some value that was in the packet being reset and have that be high en= tropy. The
> good news is that all the encrypted packets are already high entropy (= we may need
> to deal with the handshake packets a bit) so you can just include a di= gest of the
> packet you are rejecting from. If you want to have both kinds of reset= and have
> them be distinguishable, you could use a type bit, or have both values= present
> but the Proof be all zeroes or something...

I like this proposal -- it makes on-path and endpoint resets disting= uishable as well as making on-path resets verifiable by on-path devices as = well as endpoints, without requiring any durable state in the on-path devic= e.

I'll await the judgement of the = chairs and the editors as to how they want this PR to look and adjust accor= dingly.

-Ekr


Thanks, cheers,

Brian

>
> -Ekr
>
>
>
>
> Sent from my Windows 10 phone
>
>
> From: Martin Thomson
> Sent: Wednesday, November 23, 2016 5:55 PM
> To: Ryan Hamilton
> Cc: Eric Rescorla; IETF QUIC WG
> Subject: Re: Public reset PR
>
>
> So this seems to only be feasible for a server.=C2=A0 That's somet= hing that
> needs to be articulated somehow.=C2=A0 That means that clients are una= ble
> to construct a public reset.
>
> FWIW, there is currently no way to carry the verifier value.=C2=A0 We&= #39;ll
> need to work on that.
>
> On 24 November 2016 at 09:49, Ryan Hamilton <rch@google.com> wrote:
> > Sounds great to me. I agree that having public reset packets visi= ble to
> > middleboxes but unverifiable by them is problematic.
> >
> > On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> >>
> >> https://github.com/quicwg/base-draft= s/pull/20
> >>
> >> Hi folks,
> >>
> >> I just posted a PR to flesh out the Public Reset packet, whic= h is
> >> somewhat underspecified in the current document.
> >>
> >> First, let me lay out what I think are the desirable properti= es, with
> >> "requirements" having *s and "desiderata"= marked with "+". Opinions
> >> may vary on the line here.
> >>
> >> 1. Allow one side to lose connection state (e.g., reboot) and= still
> >>=C2=A0 =C2=A0 terminate the connection (*)
> >> 2. Prevent off-path attackers from terminating the connection= (*)
> >> 3. Don't require a public key operation for each terminat= ion (*)
> >> 4. Prevent on-path attackers from terminating the connection = (+)
> >> 5. Allow on-path elements to determine when a connection was = (+)
> >>=C2=A0 =C2=A0 terminated [I've marked this with "+&qu= ot; but I recognize that
> >>=C2=A0 =C2=A0 some might mark it with "-"]
> >>
> >> #5 seems like the most questionable property, but here's = my rationale.
> >> Because network elements (Firewalls, NATs, etc.) can detect t= hat a
> >> packet is a Public Reset from the header, they may opt to des= troy
> >> their internal state upon receiving one. If the Public Reset = isn't
> >> verifiable by them, then they may just opt to destroy the sta= te based
> >> on seeing something with the right header.=C2=A0 This opens u= p an on-path
> >> attack where the attacker forges a Public Reset and thus bloc= ks
> >> traffic at the middlebox even though the connection is still = live at the
> >> endpoints.
> >>
> >> The design in this PR is based on hash preimages [1]. At the = beginning
> >> of the connection the server supplies a Verifier value which = is
> >> computed as the Hash of a proof value, like so:
> >>
> >>=C2=A0 =C2=A0 Verifier =3D Hash(Proof).
> >>
> >> The Verifer is established at the beginning of the connection= and
> >> stored with the connection record. When you want to reset a > >> connection, you simply send a reset packet that contains Proo= f. The
> >> peer verifies that Hash(Proof) =3D=3D Verifier and if so tear= s down the
> >> connection. As is this fulfills 2, 3, and 4 and optionally 5 = if you
> >> expose the RVV to on-path elements during the handshake (or e= ven
> >> periodically during the connection).
> >>
> >> This isn't completely stateless, but you can get away wit= hout
> >> per-connection state by computing the per-connection Proof fr= om the
> >> conn_id and some secret stored on the server. I.e.,
> >>
> >>=C2=A0 =C2=A0 Proof_conn =3D PRF(K_m, conn_id)
> >>
> >> Note that because Proof_conn does not itself leak K_m, seeing= one
> >> connection reset doesn't allow resetting other connection= s. K_m
> >> can be stored and can survive reboots.
> >>
> >> I've tried to mimic the style of the document as best I c= an but I'm
> >> sure there's some stuff wrong here.
> >>
> >> Comments welcome.
> >> -Ekr
> >>
> >>
> >>
> >> [1] Note that the QUIC Design Document and Rationale describe= s a
> >> slightly simpler mechanis that uses the same state-handling t= rick I
> >> describe here but uses what sounds like a MAC instead of a ha= sh
> >> preimage. If you think that requirement #5 is a bad requireme= nt then
> >> that's probably a better design. Happy to write this up i= f it's the WG
> >> consensus.
> >>
> >
>
>


--001a114dac9cee33ba0542115800-- From nobody Thu Nov 24 16:25:56 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB1612A08B for ; Thu, 24 Nov 2016 16:25: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, 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 ys9pCz7qsJJh for ; Thu, 24 Nov 2016 16:25:53 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 8A73D12A08A for ; Thu, 24 Nov 2016 16:25:53 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id w33so52581807qtc.3 for ; Thu, 24 Nov 2016 16:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AG0T14kx6sYVLlwyy6y7/i3gU/rZzaryGndEIul++YU=; b=Zwfsq2BOWbpf++Vwl3wOuwCOeG5jBE8bS5+EH0Zn2/ffzxHfZR3cJg4fr7Qzk56knl UYOr2obHX0xlc+vbjGRTfDMXBYFwp3YTI6H48EBxjGyplTtcw5yp7qjxBOLyW4beWwEh fEAFwnTfnMqS+hWd0c85k1XHcqH9q/pKqxW0Tmtjo4+IpCR9R0M2hs2EZWCvAH4vTKdn WMJBH5rpaaKJ4sQqC3AsF8RBc2PlUSCUT0eJuAEg2zT5OvJRoeL2QW8NDnmqxf5TTN/5 c/R8g8r7BQm+ECMuwRihoTd/v+QRAIGiUzEv7pO/ZcYpF5MtsN6K+9NWP+Q/CRrWCGaX ExZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AG0T14kx6sYVLlwyy6y7/i3gU/rZzaryGndEIul++YU=; b=ZXb97RHFELvwNlP6OkzqQ5Quioy1xWyIZTdF33PL01749BDMFDTihMv44M+fT/omQw w6F1HiJrlGtIRdZrfhxplNbqmD//vXOyzHegMaLL81u1+EKvlH89HNXm2XIzekwnnwG0 ndC/C0O1xVoDVe4/Ol48RvAHu2/KpDGj3IjRvY+dojBEdlhv/omeY9Gy9gutw7IRalDZ KlnLpr8zW8jITyfJZJAjGkbPzo2Up8lIDMfzTlY2MACModgvuzRBlLFRwiFbVve4hKFi +FNMmL/7p8miPK9n6IecUd2+bDKhUj3ukeq3k9a3DkGMgNYU3BsuQgMf8viHBcDcYLsW 1/GA== X-Gm-Message-State: AKaTC03LdI3evMszVDUrnZnCh8eg7M56cOvbr50Q/1V2u0nvQi8tqaetjA0rClFg+n0jvuZpdW8z0UVqIgw8qQ== X-Received: by 10.200.44.27 with SMTP id d27mr4798653qta.278.1480033552609; Thu, 24 Nov 2016 16:25:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Thu, 24 Nov 2016 16:25:52 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 25 Nov 2016 11:25:52 +1100 Message-ID: Subject: Re: [quic-protocol] "outstanding data" retransmission To: Ryan Hamilton Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG , Tatsuhiro Tsujikawa X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Nov 2016 00:25:55 -0000 On 25 November 2016 at 02:56, Ryan Hamilton wrote: > Indeed, when a RST_STREAM NO_ERROR is sent the endpoint should continue > retransmitting outstanding data. That's a fairly ugly exception to an otherwise clean function (kill this stream). Now you have a code that is (half-kill this stream). The reason that this works in HTTP/2 is that we don't really have any option to give up on retransmission. I would prefer to find a cleaner solution for this. If that's an error code, then we should make an explicit half-reset code. From nobody Thu Nov 24 23:40:03 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DC6912A22B for ; Thu, 24 Nov 2016 23:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WzKPT-zuD3d for ; Thu, 24 Nov 2016 23:40:01 -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 CD409129458 for ; Thu, 24 Nov 2016 23:40:00 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cAB70-0001kw-FC for quic@ietf.org; Fri, 25 Nov 2016 08:39:59 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cAB6x-000552-CU for quic@ietf.org; Fri, 25 Nov 2016 02:39:56 -0500 Received: (qmail 6027 invoked from network); 25 Nov 2016 07:39:54 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Nov 2016 07:39:53 -0000 From: "Christian Huitema" To: "'Eric Rescorla'" , "'Brian Trammell'" References: <024A81A9-567F-4C64-B2CE-F29F5209FFBB@trammell.ch> In-Reply-To: Date: Thu, 24 Nov 2016 21:39:47 -1000 Message-ID: <0b8601d246ef$1b7d4bd0$5277e370$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJonVXnL4d4ZG4Opi5oOnyTDTVr/wJvncQxAz5a9joCs7Hw5AJdpixSAf0cU24CBkXNNZ9Gi09g Content-Language: en-us Subject: RE: Public reset PR X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD3zo l45E/Xpg1VM02YHJsiNybXwdSyjxrIG0znRh5PzrdcmtTcWSOKD5RASVzg27isfnUU8Aq9Xij6e6 U5pAs/95kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRmy8/mf/DspQWi85NPXhrZIMQOp+UtDOd2Xrp4Ao XsNbR5gKbK3xJI2P/mgJSlQCjwjMM1GqS8P5ezXBIcd52+jeNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxNnmFCUctm6OHeH6tWPSXJE7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRYE83tH9htpyVATiooT/rJiGHIfgXXvuhI9vwJN89WVO9R0tarUwIt7i7NiVJNL9jNC r2VPLfZa8ts/I6OTYjIAMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.230 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.08) X-Classification: not-spam/combined X-Recommended-Action: accept Archived-At: Cc: 'Mike Bishop' , 'IETF QUIC WG' , 'Martin Thomson' , 'Ryan Hamilton' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Nov 2016 07:40:02 -0000 On Thursday, November 24, 2016 9:52 AM, Eric Rescorla wrote: > > This is true for on-path devices that are forwarding, but other = devices (e.g., on wireless=20 > networks) can be on-path but not forwarding. For such devices, making = it difficult for > them to force a reset might provide some security benefit to the = endpoint. Yes. The "false reset" denial of service attack from a "man on the side" = is a real problem. But then, the flip side of that is the "rebooted = server". It just rebooted, it doesn't remember the previous connections, = and it receives a QUIC packet for a connection it does not recognize. = That's the standard justification for a TCP RST. Notice that in that = scenario, the "rebooted server" does not know anything that the "man on = the side" does not also know. What do we want? Do we agree that the = "rebooted server" is a very rare scenario, which we should not try = optimize?=20 -- Christian Huitema From nobody Fri Nov 25 02:05:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E9D12962E for ; Fri, 25 Nov 2016 02:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdvoettdmThm for ; Fri, 25 Nov 2016 02:05:32 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2AD12962A for ; Fri, 25 Nov 2016 02:05:28 -0800 (PST) Received: from [10.183.85.85] (host108-2.natpool.mwn.de [138.246.2.108]) by trammell.ch (Postfix) with ESMTPSA id 242D11A0F44; Fri, 25 Nov 2016 11:05:27 +0100 (CET) Subject: Re: Public reset PR Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_185C296F-61B4-41DC-8765-42F1DE9EAFD2"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <0b8601d246ef$1b7d4bd0$5277e370$@huitema.net> Date: Fri, 25 Nov 2016 11:05:26 +0100 Message-Id: References: <024A81A9-567F-4C64-B2CE-F29F5209FFBB@trammell.ch> <0b8601d246ef$1b7d4bd0$5277e370$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Mike Bishop , Eric Rescorla , IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Nov 2016 10:05:38 -0000 --Apple-Mail=_185C296F-61B4-41DC-8765-42F1DE9EAFD2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 25 Nov 2016, at 08:39, Christian Huitema = wrote: >=20 > On Thursday, November 24, 2016 9:52 AM, Eric Rescorla wrote: >>=20 >> This is true for on-path devices that are forwarding, but other = devices (e.g., on wireless >> networks) can be on-path but not forwarding. For such devices, making = it difficult for >> them to force a reset might provide some security benefit to the = endpoint. >=20 > Yes. The "false reset" denial of service attack from a "man on the = side" is a real problem. The big difference between a man-on-the-side reset in TCP and a = man-on-the-side reset with the space of mechanisms we're currently = discussing is that in the latter, the endpoint(s) can distinguish a man = on the side from an endpoint-initiated reset. This makes endpoint = defense against path resets more feasible than in the TCP case (e.g., by = quickly re-establishing the session; in a future multipath environment, = perhaps on a different interface). > But then, the flip side of that is the "rebooted server". It just = rebooted, it doesn't remember the previous connections, and it receives = a QUIC packet for a connection it does not recognize. That's the = standard justification for a TCP RST. Notice that in that scenario, the = "rebooted server" does not know anything that the "man on the side" does = not also know. What do we want? Do we agree that the "rebooted server" = is a very rare scenario, which we should not try optimize? I don't know how rare the rebooted server case is. But, similar: a server sends a public reset for a spoofed garbage = packet. This would be a reflection vector (without amplification), as = well as a minor resource DoS on the target (which would need to compute = the digest of the garbage packet to generate the public reset). If = there's value in an endpoint sending an equivalent-to-on-path public = reset, then it would need to have safeguards (rate limiting, etc.) to = reduce its usefulness as an attack vector. Cheers, Brian > -- Christian Huitema >=20 >=20 >=20 >=20 --Apple-Mail=_185C296F-61B4-41DC-8765-42F1DE9EAFD2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYOAzmAAoJEIoSt78L6kajIaQQAKCkHFRvnpiUQ2ruOemzPwo9 Sxzio3E11gfM+cjtMHr5jOHsRBVY0GvyMJzokHrlOiiRURltbU24pTg/AC+ILUEy xoSXCcjQEeT59UR+UsJ1VRMFNqJg6prqo4Aha/LjOpbZSaQ/AV8GdBb2cALVibbr tEwDQQLq0bA8TFdUoPjEGUPX56q1XkRkkqLG9fwIOJPtWMZOn5QrZmSHzgaO56IT WvI06sItZK2HqrwtYJ6/zZ44Jt4RWforMAIBp/GR9Q5e/rbj4qq4K9zmd4QNWSMn 0JDhiBuyMVe/y6dAfCQwk7jGeGrvqawMyWzgze129A4IYQZu+g6D/yVKh5L4I0Eu 3+neyUE/QaAveqMpjNjbB5XLPDyY/I6lGVNyoxKX5opSaX/es/NJfAs5A+K4GDYT EWyjy0Q5JP1Ez/7/W+4JDaChoO+2CnQ9WBfZ2piM6oUbo1/Is61mD/+N/xmGcnpQ BFPSMwziJ/M+z5tVQ46G3c5dpNjrdKybtSWtTG4IuyOq5N90RtOAM0fpFgQ4BL3f 6eMVVHtU6d/S8LqR6NElSjhtttGYp7DFKf59s1/jwlljfURDo4sXOLbGMWHA5/G7 uIA+Pmhu3u7AjVOZFJc5uANOTPn6hT+EBYqdVhwkG+rxQ22f617INiUif/bt+rNl pdNbcGxWAhOYZB4mhb+Y =Qxkw -----END PGP SIGNATURE----- --Apple-Mail=_185C296F-61B4-41DC-8765-42F1DE9EAFD2-- From nobody Fri Nov 25 02:23:48 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA724129A11 for ; Fri, 25 Nov 2016 02:23:47 -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, 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 B6iyysSL-t3Y for ; Fri, 25 Nov 2016 02:23:41 -0800 (PST) Received: from mail-wj0-x241.google.com (mail-wj0-x241.google.com [IPv6:2a00:1450:400c: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 896FA1299FE for ; Fri, 25 Nov 2016 02:23:32 -0800 (PST) Received: by mail-wj0-x241.google.com with SMTP id jb2so5025721wjb.3 for ; Fri, 25 Nov 2016 02:23:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JeoqlnoaUq4t2WVXbqCOc2debtGqg42986STO8J36EU=; b=BpP5pi4tkJSP/Bj0f3ui894dAAI535f7zXFQNQPYZcX2xtTVhxtM0zUTOZll2Q/XCO pQWb/JC4EzV3lSvyBhhvNAXrS3KvIX1La7/tpgTqs5tF3TLTZ5KsiRn8171YvsoAz2y4 mp0eITlVFayEDXhF+frgrpb2ehRljiIHcRSpJi0I/vyPGTgMxVd7IZocz6RV3eaRtcja W9zX9KQMqaF//2dV8lVCSQEpvJuchmoAuON13jAi2yja7TA+alzj7uBDYYEdWZpgmHEB 8lnrQfvabW9v3E1DJMyjjbHB7nou+x30LVkSX5abXxYeSUAeZW2tgRW8rkHNL3SxCFKL 2VSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:from:date:message-id:subject:to:cc; bh=JeoqlnoaUq4t2WVXbqCOc2debtGqg42986STO8J36EU=; b=DmK4ULEjM5LMcFUm1j/LYQySo9Kt4uTPInv56938Na/7ol1mqKEkFMYwzzCcgA4Ikd KEgwdSVQdoC9KxitvTCxqYOqem/jOqOxnO3Xu7yTdSMLYGYxq1prfAIaAanEuFtnGicv Mu4filziSjY/c+lp1itegsSHKkJ2mn1Zv9pPGEE4QkLQn8EH+aCZCseztRRTPoDwqcCT 5zERDXOH3A4+5oKczIbk/siOF6KW1GwvM9bgJJVwTMleBe5gHTIyn3tPk5fkbIs5JS45 fQv+buaiIFzxNc2a9ChLlr/RmOhboOYa15E7r1hWpYZ46eyPsRB6FrqIIA65GwmRs8Be +umw== X-Gm-Message-State: AKaTC02DZlfVVQykS544fqIHs50WYRH7rIsKB93B7oQ3c3IFhG2C2m5EmEa1kQ7g4FJW0tozEt0lvPTFFFJyQw== X-Received: by 10.194.75.227 with SMTP id f3mr6276813wjw.19.1480069410844; Fri, 25 Nov 2016 02:23:30 -0800 (PST) MIME-Version: 1.0 Sender: prolag@gmail.com Received: by 10.28.187.195 with HTTP; Fri, 25 Nov 2016 02:23:30 -0800 (PST) In-Reply-To: References: <024A81A9-567F-4C64-B2CE-F29F5209FFBB@trammell.ch> <0b8601d246ef$1b7d4bd0$5277e370$@huitema.net> From: Alexis La Goutte Date: Fri, 25 Nov 2016 11:23:30 +0100 X-Google-Sender-Auth: YCKsDSx7kAq_mB2bPcj79VJXpm4 Message-ID: Subject: Re: Public reset PR To: Brian Trammell Content-Type: multipart/alternative; boundary=047d7bb04c1479f73f05421d8309 Archived-At: Cc: Mike Bishop , Eric Rescorla , Ryan Hamilton , Christian Huitema , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: alexis.lagoutte@gmail.com List-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, 25 Nov 2016 10:23:48 -0000 --047d7bb04c1479f73f05421d8309 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 25, 2016 at 11:05 AM, Brian Trammell wrote: > > > On 25 Nov 2016, at 08:39, Christian Huitema wrote: > > > > On Thursday, November 24, 2016 9:52 AM, Eric Rescorla wrote: > >> > >> This is true for on-path devices that are forwarding, but other devices > (e.g., on wireless > >> networks) can be on-path but not forwarding. For such devices, making > it difficult for > >> them to force a reset might provide some security benefit to the > endpoint. > > > > Yes. The "false reset" denial of service attack from a "man on the side" > is a real problem. > > The big difference between a man-on-the-side reset in TCP and a > man-on-the-side reset with the space of mechanisms we're currently > discussing is that in the latter, the endpoint(s) can distinguish a man on > the side from an endpoint-initiated reset. This makes endpoint defense > against path resets more feasible than in the TCP case (e.g., by quickly > re-establishing the session; in a future multipath environment, perhaps on > a different interface). > > > But then, the flip side of that is the "rebooted server". It just > rebooted, it doesn't remember the previous connections, and it receives a > QUIC packet for a connection it does not recognize. That's the standard > justification for a TCP RST. Notice that in that scenario, the "rebooted > server" does not know anything that the "man on the side" does not also > know. What do we want? Do we agree that the "rebooted server" is a very > rare scenario, which we should not try optimize? > > I don't know how rare the rebooted server case is. > > There is always the case how there is a load balance and send to a another server not ? > But, similar: a server sends a public reset for a spoofed garbage packet. > This would be a reflection vector (without amplification), as well as a > minor resource DoS on the target (which would need to compute the digest of > the garbage packet to generate the public reset). If there's value in an > endpoint sending an equivalent-to-on-path public reset, then it would need > to have safeguards (rate limiting, etc.) to reduce its usefulness as an > attack vector. > > Cheers, > > Brian > > > > > -- Christian Huitema > > > > > > > > > > --047d7bb04c1479f73f05421d8309 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Nov 25, 2016 at 11:05 AM, Brian Trammell <= ietf@trammell.ch&= gt; wrote:

> On 25 Nov 2016, at 08:39, Christian Huitema <huitema@huitema.net> wrote:
>
> On Thursday, November 24, 2016 9:52 AM, Eric Rescorla wrote:
>>
>> This is true for on-path devices that are forwarding, but other de= vices (e.g., on wireless
>> networks) can be on-path but not forwarding. For such devices, mak= ing it difficult for
>> them to force a reset might provide some security benefit to the e= ndpoint.
>
> Yes. The "false reset" denial of service attack from a "= ;man on the side" is a real problem.

The big difference between a man-on-the-side reset in TCP and a man-= on-the-side reset with the space of mechanisms we're currently discussi= ng is that in the latter, the endpoint(s) can distinguish a man on the side= from an endpoint-initiated reset. This makes endpoint defense against path= resets more feasible than in the TCP case (e.g., by quickly re-establishin= g the session; in a future multipath environment, perhaps on a different in= terface).

> But then, the flip side of that is the "rebooted server". It= just rebooted, it doesn't remember the previous connections, and it re= ceives a QUIC packet for a connection it does not recognize. That's the= standard justification for a TCP RST. Notice that in that scenario, the &q= uot;rebooted server" does not know anything that the "man on the = side" does not also know. What do we want? Do we agree that the "= rebooted server" is a very rare scenario, which we should not try opti= mize?

I don't know how rare the rebooted server case is.

There is always the case how there is a load balance = and send to a another server not ?
=C2=A0
But, similar: a server sends a public reset for a spoofed garbage packet. T= his would be a reflection vector (without amplification), as well as a mino= r resource DoS on the target (which would need to compute the digest of the= garbage packet to generate the public reset). If there's value in an e= ndpoint sending an equivalent-to-on-path public reset, then it would need t= o have safeguards (rate limiting, etc.) to reduce its usefulness as an atta= ck vector.

Cheers,

Brian



> -- Christian Huitema
>
>
>
>


--047d7bb04c1479f73f05421d8309-- From nobody Fri Nov 25 04:26:08 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4BD129874 for ; Fri, 25 Nov 2016 04:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cshLRhw4-35N for ; Fri, 25 Nov 2016 04:26:05 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id F3B721299BC for ; Fri, 25 Nov 2016 04:00:01 -0800 (PST) Received: from [10.183.85.85] (host108-2.natpool.mwn.de [138.246.2.108]) by trammell.ch (Postfix) with ESMTPSA id A45CD1A05E2; Fri, 25 Nov 2016 13:00:00 +0100 (CET) Subject: Re: Public reset PR Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_88D4EF11-CD34-4036-8B79-8E4A39FDEF67"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Fri, 25 Nov 2016 12:59:59 +0100 Message-Id: <3D84E6A1-C3EA-4DCF-8F95-20B8FE262AFE@trammell.ch> References: <024A81A9-567F-4C64-B2CE-F29F5209FFBB@trammell.ch> <0b8601d246ef$1b7d4bd0$5277e370$@huitema.net> To: alexis.lagoutte@gmail.com X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Nov 2016 12:26:07 -0000 --Apple-Mail=_88D4EF11-CD34-4036-8B79-8E4A39FDEF67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Alexis, > On 25 Nov 2016, at 11:23, Alexis La Goutte = wrote: >=20 >>> > But then, the flip side of that is the "rebooted server". It just = rebooted, it doesn't remember the previous connections, and it receives = a QUIC packet for a connection it does not recognize. That's the = standard justification for a TCP RST. Notice that in that scenario, the = "rebooted server" does not know anything that the "man on the side" does = not also know. What do we want? Do we agree that the "rebooted server" = is a very rare scenario, which we should not try optimize? >>=20 >> I don't know how rare the rebooted server case is. >=20 > There is always the case how there is a load balance and send to a = another server not ? How QUIC interacts with load balancers is something we'll have to = discuss in more detail, but I suppose that the load balancer would have = enough information from the 5-tuple and connection ID to not misdirect = QUIC packets to servers that don't have appropriate state; i.e. this = shouldn't happen in the normal case. Cheers, Brian --Apple-Mail=_88D4EF11-CD34-4036-8B79-8E4A39FDEF67 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYOCe/AAoJEIoSt78L6kaj5KgQAJrHLqUtIH2VyIbPuPBXROmt qybP6J6ebKhZXNq14eoS0J7IOUFgFLRi4F+bhMRT69mEIgaxld7FzVw14p+pimab qMnV9ehRlnv4irdH+EhBdrB7DhBa3Y8zVpvobh7jyj5WeJMruG4nwPVOn9k/pBq7 CJSika8ZY9ggUNPGg9a2l52UuM1PwC+wYWxmNnLAErOay2+kurhNlH4mCEZ7QV23 1B1FyRhmjLilzVfZNw0hNmRPXujDrqkKsG466MY07vM9zWyepFoviR6ArKcTlbgI R49H868OaVftB11V365JjW9LFJshQtH9dv0DGQwTSQ8vQEsAmQovJmS7U82ypToA MLX0Wui0xBn5rz3VOKHib9BEQc9kzI8JZTNU0LQugpCA7kgJ/Qy9cXGel7QANgRp 0Q5M6UJ0uFTsEMbAbWAxyRMWYSvg1cd4qULYMFjCDNn5VmmbVDNI7dbj2h3HPs0S Sb+In7msOgBYiWlXoTqUXuzgk1MFdQdmQKIvrAoTLpeQ4DZoSz0gBzsL6Fbmql4f AkcSmeqaCSyBquPR4CVcR9UzhraexjcPiXqVI00zM3qLvJafq8+KOyWqKJFbIbcT krB9QC45V9C3yRzzYRkqGCLUCA09eD8EeBX0g+XzQrue4K0K3Usd94HeCxyajePY lUJ4YVcrxGEfYb9FY5Wb =cAh+ -----END PGP SIGNATURE----- --Apple-Mail=_88D4EF11-CD34-4036-8B79-8E4A39FDEF67-- From nobody Fri Nov 25 06:43:58 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7BD1298AE for ; Fri, 25 Nov 2016 06:43:57 -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 rqt4l7N9N1Yu for ; Fri, 25 Nov 2016 06:43:52 -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 9174F12A398 for ; Fri, 25 Nov 2016 06:17:38 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id r204so64120539ywb.0 for ; Fri, 25 Nov 2016 06:17:38 -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=PxryQpvOHGy0TIDBAN0bD9n65FD/pRWZDIUkOHHm+9g=; b=jGbyLP7P2P4M0cqUtOvR+ZRFgDokN+NlJBWQm6bMpA+4Uhm4HHdlCHiNaOMuzvCGHD z73lZcidczl+MrGjeQ6RwJuELAR8FULDKvtaO11jSH77EPgXK0uBKCR2ObhwDTkC8J+9 IyVmQiv5+vH8JQ3ZyToe0YeAYvJUwbu7U9YrzdwHLjEn4esK9V3Nv1JvOj6XnZuTxw8M Kl+7WImSMsFrmQMbYeTXJqgPI2Qyyz2pHqNrQpzLL0GaS/lEif+04S7v08odzErSATKy ZnshnOTUuhh1y6FrgQOklTscfra5VjMCv+1QEXzVdRGgTwjSvpEYdhJSzVBczYYX7DaK II9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PxryQpvOHGy0TIDBAN0bD9n65FD/pRWZDIUkOHHm+9g=; b=joa3VijrjxAUz5aUaBLHtfieSNPHVPz7lITPe0LtIi56smCGHXjCZL9P8LCSo/vufy Sl4C3kU6IF6yXzZ39+hzh5BuAYX3z//1hDw/pfmrhmVtAM1nrqMcJCHTuSdVrP0r26Ej ds6fOLKlxqe/Y+zzI6miBq9GRgvJtRlC9Omj9mGG5y8z2YKwaP0PfYq7Y96IYK6zZ/ol AWZv+ISddKYGz2DsS+jIiuZyy96PZGAiCK+tcD+olqEfDM6lQaz0Pk6aBoXsxZJ++tga 5HJNLrQ1/IfOhAnXy0L90Vii5SDsoMt0WVo8KpnLhxGElAVUBzdK1b/GqWFM0MtcUTMd FxPw== X-Gm-Message-State: AKaTC02U54llG7BFw/5qODbxm0XuNCzq+xAXRjeP1yP+ujFpq9eqfomXkPVoeHrUZj36tmbK58Ev9W/670j16A== X-Received: by 10.129.53.194 with SMTP id c185mr10034704ywa.205.1480083457880; Fri, 25 Nov 2016 06:17:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Fri, 25 Nov 2016 06:16:57 -0800 (PST) In-Reply-To: <0b8601d246ef$1b7d4bd0$5277e370$@huitema.net> References: <024A81A9-567F-4C64-B2CE-F29F5209FFBB@trammell.ch> <0b8601d246ef$1b7d4bd0$5277e370$@huitema.net> From: Eric Rescorla Date: Fri, 25 Nov 2016 06:16:57 -0800 Message-ID: Subject: Re: Public reset PR To: Christian Huitema Content-Type: multipart/alternative; boundary=001a11421478befc6b054220c82f Archived-At: Cc: Brian Trammell , IETF QUIC WG , Martin Thomson , Ryan Hamilton , Mike Bishop X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Nov 2016 14:43:57 -0000 --001a11421478befc6b054220c82f Content-Type: text/plain; charset=UTF-8 On Thu, Nov 24, 2016 at 11:39 PM, Christian Huitema wrote: > On Thursday, November 24, 2016 9:52 AM, Eric Rescorla wrote: > > > > This is true for on-path devices that are forwarding, but other devices > (e.g., on wireless > > networks) can be on-path but not forwarding. For such devices, making it > difficult for > > them to force a reset might provide some security benefit to the > endpoint. > > Yes. The "false reset" denial of service attack from a "man on the side" > is a real problem. But then, the flip side of that is the "rebooted > server". It just rebooted, it doesn't remember the previous connections, > and it receives a QUIC packet for a connection it does not recognize. > That's the standard justification for a TCP RST. Notice that in that > scenario, the "rebooted server" does not know anything that the "man on the > side" does not also know. What do we want? Do we agree that the "rebooted > server" is a very rare scenario, which we should not try optimize? > As you say, there is a tradeoff here that there doesn't seem to be an ideal solution for. This particular design is intended to allow servers to have no per-connection state and only a single fixed persistent value, which by hypothesis they already know how to do because it can store the private key [0]. So it's an attempt to cater to the rebooted server case byt not optimize for it. -Ekr [0] Note: there is a solution which *only* requires private key storage, namely digitally sign each PR packet, but that obviously has negative performance consequences. You can ameliorate this by batching signatures (e.g., by using a Merkle hash tree) but the consensus of the group which discussed this previously was that that was too complicated for people to actually be willing to implement. -- Christian Huitema > > > > > --001a11421478befc6b054220c82f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Nov 24, 2016 at 11:39 PM, Christian Huitema &= lt;huitema@huitema= .net> wrote:
On Thursday, November 24, 2016 9:52 AM, Eric Rescorla wrote:
>
> This is true for on-path devices that are forwarding, but other device= s (e.g., on wireless
> networks) can be on-path but not forwarding. For such devices, making = it difficult for
> them to force a reset might provide some security benefit to the endpo= int.

Yes. The "false reset" denial of service attack from a &qu= ot;man on the side" is a real problem. But then, the flip side of that= is the "rebooted server". It just rebooted, it doesn't remem= ber the previous connections, and it receives a QUIC packet for a connectio= n it does not recognize. That's the standard justification for a TCP RS= T. Notice that in that scenario, the "rebooted server" does not k= now anything that the "man on the side" does not also know. What = do we want? Do we agree that the "rebooted server" is a very rare= scenario, which we should not try optimize?

As you say, there is a tradeoff here that there doesn't seem to b= e an ideal solution for.

This particular design is= intended to allow servers to have no per-connection state and only
a single fixed persistent value, which by hypothesis they already know h= ow to do because
it can store the private key [0]. So it's an= attempt to cater to the rebooted server case byt
not optimize fo= r it.

-Ekr

[0] Note: ther= e is a solution which *only* requires private key storage, namely digitally=
sign each PR packet, but that obviously has negative performance= consequences. You
can ameliorate this by batching signatures (e.= g., by using a Merkle hash tree) but the
consensus of the group w= hich discussed this previously was that that was too complicated
= for people to actually be willing to implement.

-- Christian Huitema





--001a11421478befc6b054220c82f-- From nobody Fri Nov 25 13:19:28 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48C931296E9 for ; Fri, 25 Nov 2016 13:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kotU7ojGnc7u for ; Fri, 25 Nov 2016 13:19:25 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EC431296F5 for ; Fri, 25 Nov 2016 13:19:25 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cANtz-0006oX-Io for quic@ietf.org; Fri, 25 Nov 2016 22:19:25 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cANty-0008Sd-4T for quic@ietf.org; Fri, 25 Nov 2016 16:19:22 -0500 Received: (qmail 23396 invoked from network); 25 Nov 2016 21:19:19 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Nov 2016 21:19:19 -0000 From: "Christian Huitema" To: "'Eric Rescorla'" References: <024A81A9-567F-4C64-B2CE-F29F5209FFBB@trammell.ch> <0b8601d246ef$1b7d4bd0$5277e370$@huitema.net> In-Reply-To: Date: Fri, 25 Nov 2016 11:19:14 -1000 Message-ID: <0d5d01d24761$944bc880$bce35980$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJonVXnL4d4ZG4Opi5oOnyTDTVr/wJvncQxAz5a9joCs7Hw5AJdpixSAf0cU24CBkXNNQH+nLrFAZtDt1qfKqE4IA== Content-Language: en-us Subject: RE: Public reset PR X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMDymc /fXAgQeYVOw1uXpBx0lxO6RXCctSEdn7CNjkJx2VdcmtTcWSOKD5RASVzg27isAXVRQgHbLLzV7b 3SwTZqt5kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRucORJzL3o1PImT0GNRxIHUMQOp+UtDOd2Xrp4Ao XsNbR5gKbK3xJI2P/mgJSlQCj8ajQpZU2HoSraNABsQx+TneNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxMwo0ageKMXcNstrfyg5gXa7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRZKVzLoodJpOhZOhElZeeZ68HN1XtUyhw3DgxLaLBwUGYIHhtpcaYbh91FuaKgJHE3L es7Q3TWr9wD5RALyObfQMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.232 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.18) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: 'Mike Bishop' , 'Brian Trammell' , 'IETF QUIC WG' , 'Martin Thomson' , 'Ryan Hamilton' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Nov 2016 21:19:27 -0000 On Friday, November 25, 2016 4:17 AM, Eric Rescorla wrote: > > As you say, there is a tradeoff here that there doesn't seem to be an = ideal solution for. > > This particular design is intended to allow servers to have no = per-connection state and only > a single fixed persistent value, which by hypothesis they already know = how to do because > it can store the private key [0]. So it's an attempt to cater to the = rebooted server case byt > not optimize for it. Your solution works as long as the server receiving the errant packet = knows the value sent in the initial handshake. That's probably OK for = most use case, but if the same proof is used for multiple connections = there is an obvious replay attack. The other issue that I have with the design is the interaction between = handshake protocol and packet layer. I think of the public reset as a = connection-wide packet layer message, logically "stream zero". The = crypto handshake is on stream 1. The formal API has the handshake logic = passing keys to the global "packet layer". Logically, the same API = should provision the reset proof. -- Christian Huitema From nobody Fri Nov 25 13:55:22 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E81A129682 for ; Fri, 25 Nov 2016 13:55:20 -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 nr3rHMbmpVdl for ; Fri, 25 Nov 2016 13:55:18 -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 9A5E0129550 for ; Fri, 25 Nov 2016 13:55:18 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id t125so71684392ywc.1 for ; Fri, 25 Nov 2016 13:55:18 -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=KcNnFpf654TLRrzKqqZu36DsnEhBZESUJGGhvWF4eW8=; b=itJ21SnjTjoMGkKnTMQNexEmst8D1To46GMt0wf6hHnwzR/X7BT5iB9NebjAgzAIoV iLkqJndsx944Il33EvNoENznpvjM0AfnEo3D1FeLfat0ymfLzGR231hLk+GSAjXibjQP qZmQcMLOA6quPYDRtufTmdAthAYBJ7ZYvuE7PUb5Gg9YR68+dSr2MYRvUNcICwIDjS0O oQg1Z+a94IiKjBhJmQ3bZbdNrtwTHIKCG0yp9IwSpj3qIAKmbbygy5zEuS6Y50LhKzZm qMHdOfSkyX545tid16CSkCCPpzGykkcBdID+KCvUHlTgQrW0Zn7UJ6XJTPcGroqJ5a+J G+dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KcNnFpf654TLRrzKqqZu36DsnEhBZESUJGGhvWF4eW8=; b=cmBLL66IOfr13asJCLBtAieNI3i6S5aet0cgUaEvNTS1zR5gObM6lJ3sy3l3PhWQoS jKMSH9gyJDsiBuqUxFRxjPGKPfBJFGPaVw1MI1DBxPNz0ZG1PXlqgRauFnLCy7WJCiBW U8cmCvBfljfSy6SF3tPpNck04UkrIwJDnj3ptIs1fcMcoEz3awmslna5dSNR08pJFLrT 8YLBGdJpAGr4WBMaanVL06UvJCmD7mDD/tzPMEzZgFR5wLxBzaoF8TOk0zjeT/6d3ckj YfwJNSh3UdX55uoJpaDVv8XGR6dUeHQd7ajZGdmQSwcxzUaHC4SYGjd3sVbmxQjQGVIy bBRw== X-Gm-Message-State: AKaTC010LIvmUTrqrEaJ3HayzhKGpCfJlKD6BBoI+U1UXRbZ6aC2IGv6qGvqvm2bxcEFp0FNUalmbN6O4qOpvw== X-Received: by 10.129.81.78 with SMTP id f75mr12398245ywb.149.1480110917880; Fri, 25 Nov 2016 13:55:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Fri, 25 Nov 2016 13:54:37 -0800 (PST) In-Reply-To: <0d5d01d24761$944bc880$bce35980$@huitema.net> References: <024A81A9-567F-4C64-B2CE-F29F5209FFBB@trammell.ch> <0b8601d246ef$1b7d4bd0$5277e370$@huitema.net> <0d5d01d24761$944bc880$bce35980$@huitema.net> From: Eric Rescorla Date: Fri, 25 Nov 2016 13:54:37 -0800 Message-ID: Subject: Re: Public reset PR To: Christian Huitema Content-Type: multipart/alternative; boundary=001a114564047d3cf80542272db6 Archived-At: Cc: Mike Bishop , Brian Trammell , IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 25 Nov 2016 21:55:20 -0000 --001a114564047d3cf80542272db6 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 25, 2016 at 1:19 PM, Christian Huitema wrote: > On Friday, November 25, 2016 4:17 AM, Eric Rescorla wrote: > > > > As you say, there is a tradeoff here that there doesn't seem to be an > ideal solution for. > > > > This particular design is intended to allow servers to have no > per-connection state and only > > a single fixed persistent value, which by hypothesis they already know > how to do because > > it can store the private key [0]. So it's an attempt to cater to the > rebooted server case byt > > not optimize for it. > > Your solution works as long as the server receiving the errant packet > knows the value sent in the initial handshake. That's probably OK for most > use case, but if the same proof is used for multiple connections there is > an obvious replay attack. Correct. In this case, the Proof is intended to be 1:1 with the connection ID (using the PRF trick to avoid storing a pile of proof values). So I believe that this PR has that property as long as connection-IDs are random. > The other issue that I have with the design is the interaction between > handshake protocol and packet layer. I think of the public reset as a > connection-wide packet layer message, logically "stream zero". The crypto > handshake is on stream 1. The formal API has the handshake logic passing > keys to the global "packet layer". Logically, the same API should provision > the reset proof. > That was my intent. Namely to have it be in a TLS extension which is then provided to the packet layer. -Ekr > > -- Christian Huitema > > > > > --001a114564047d3cf80542272db6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Fri, Nov 25, 2016 at 1:19 PM, Christian Huitema <huitema@huitema.net<= /a>> wrote:
On= Friday, November 25, 2016 4:17 AM, Eric Rescorla wrote:
>
> As you say, there is a tradeoff here that there doesn't seem to be= an ideal solution for.
>
> This particular design is intended to allow servers to have no per-con= nection state and only
> a single fixed persistent value, which by hypothesis they already know= how to do because
> it can store the private key [0]. So it's an attempt to cater to t= he rebooted server case byt
> not optimize for it.

Your solution works as long as the server receiving the errant packe= t knows the value sent in the initial handshake. That's probably OK for= most use case, but if the same proof is used for multiple connections ther= e is an obvious replay attack.

Correct. In = this case, the Proof is intended to be 1:1 with the connection ID (using th= e PRF trick to avoid storing a pile of proof values). So I believe that thi= s PR has that property as long as connection-IDs are random.

=
=C2=A0
The other issue that I have with the design is the interaction between hand= shake protocol and packet layer. I think of the public reset as a connectio= n-wide packet layer message, logically "stream zero". The crypto = handshake is on stream 1. The formal API has the handshake logic passing ke= ys to the global "packet layer". Logically, the same API should p= rovision the reset proof.

That was my i= ntent. Namely to have it be in a TLS extension which is then provided to th= e packet layer.

-Ekr
=C2=A0

-- Christian Huitema





--001a114564047d3cf80542272db6-- From nobody Sat Nov 26 10:26:57 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE5831294B9 for ; Sat, 26 Nov 2016 10:26:55 -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 kKSIQWlz5YMO for ; Sat, 26 Nov 2016 10:26:53 -0800 (PST) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::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 614C112952B for ; Sat, 26 Nov 2016 10:26:53 -0800 (PST) Received: by mail-yw0-x244.google.com with SMTP id s68so6144404ywg.0 for ; Sat, 26 Nov 2016 10:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=o8ABq6fgg5BuOyZp3hBs9mIdzGbrO48/rPL3Bu7eHeo=; b=Ir2Xkw/WnToWzR/Eo02jFZK7xtS12O+Em6+xxe8Oj+64XrnZ1I9Hgab21UwKyVr8/j srCMqEhB9zlkwXoZpbohstpL7sELsfgAmTIMgbjIcyEGHIRbGo+aLViDX9t9hVZavesI wSJ/WLU4BTn2EZ3ry0TB+OKFeX8+nl5USSVqfUiCPPyWqBagyFuxRxKD+Fs2x4CZa9Bl +VGjudJwOhdqRDLzxUW6y/EtkHOsF58QcbVU1rrMVOARQljHRkz5bFJTsb2Ml2tQQ5sE rvSKle5YUx4vC43l7kMn/1tQfmhquUvyFfXdmNqsSeFO6V1676AhFnxf3CGBePpfFY57 z9vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=o8ABq6fgg5BuOyZp3hBs9mIdzGbrO48/rPL3Bu7eHeo=; b=laXrgNMZ7uBd8BK5DEFXbJcpYSqeDGW8OWzhj1c2kSfnO40IbU1TcOAhXYe8L5CHwD +rH34D6UQv/tagEz7PpJPwqQ7juQkFgy2/BnbrnHq3K+LTxW++feftGQimqcaEmq4D/S T4X7bvbSJwla2ysnyP3jsIVvnRfeRPCLTYxdoBnAdKlgDgfEirJgwGJpsCfrzSDixSIP MqjNv/SYyZqL8JyEZOVgqsvaVG+kYdUi7ATwygBJ2H8Ak2I91dNmSSCdgu9AdDgCsAJx KIPmB0Gn0gow6oRtJgPkmklAvHvoCgjWAGslQwsGCjvap+5TQ2lX/VjkizupjlaIN+rF /QkQ== X-Gm-Message-State: AKaTC01wN/Nb5ub3YMB1VTgnUSsjwybApV7kalhOHP+sbBqzobaweO6FuNWQgs1y9Sn/L1GNyWD4GRzg/BaIjg== X-Received: by 10.129.77.7 with SMTP id a7mr17483138ywb.58.1480184812459; Sat, 26 Nov 2016 10:26:52 -0800 (PST) MIME-Version: 1.0 Sender: jim.roskind@gmail.com Received: by 10.13.249.134 with HTTP; Sat, 26 Nov 2016 10:26:51 -0800 (PST) In-Reply-To: References: From: Jim Roskind Date: Sat, 26 Nov 2016 10:26:51 -0800 X-Google-Sender-Auth: XCl49FQhgv7yjAnlXmWJVPc2o_4 Message-ID: Subject: Re: Public reset PR To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140bc76f2dd5f05423861b3 Archived-At: Cc: quic@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 26 Nov 2016 18:26:56 -0000 --001a1140bc76f2dd5f05423861b3 Content-Type: text/plain; charset=UTF-8 FWIW: I like the proposal. The major (ab)use case I was trying to deal with in the QUIC Rationale involved nation states that could trivially reset connections. My hope was that the somewhat authenticated reset packets would "raise the level of effort" for intermediaries that wanted to deny connection service. It is obvious that a full-blown intermediary, such as a router, can deny service by consistently dropping packets, but at least such methodical dropping was much more effort than a mere TCP RST transmission. In addition, a mere RST attack leaves plausible deniability, as it is hard to tell who sent the RST, and why, while packet dropping can be (more) easily blamed on a specific node. I had not considered trying to notify middle boxes of termination, though I have discussed having "more trusted" middle boxes that could report the fact that packets in a sequence were missing (never arrived at a way point). Given my experiences and experimentation with NATs and such, it seemed reasonable that the current time-out (LRU?) status quo might well continue, and QUIC would instead "work around" such unbindings. Is there a lot of real world pressure to do better? I'm trying to understand your 5 listed cases. Am I correct that in your terms, "on path" attackers are folks that can listen to traffic, as well as send, while "off path" attackers must send in the blind? What do you call a "full blown intermediary," that can drop or mutate/replace packets? Thanks, Jim Opinions expressed are mine, and not that of my company. On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla wrote: > https://github.com/quicwg/base-drafts/pull/20 > > Hi folks, > > I just posted a PR to flesh out the Public Reset packet, which is > somewhat underspecified in the current document. > > First, let me lay out what I think are the desirable properties, with > "requirements" having *s and "desiderata" marked with "+". Opinions > may vary on the line here. > > 1. Allow one side to lose connection state (e.g., reboot) and still > terminate the connection (*) > 2. Prevent off-path attackers from terminating the connection (*) > 3. Don't require a public key operation for each termination (*) > 4. Prevent on-path attackers from terminating the connection (+) > 5. Allow on-path elements to determine when a connection was (+) > terminated [I've marked this with "+" but I recognize that > some might mark it with "-"] > > #5 seems like the most questionable property, but here's my rationale. > Because network elements (Firewalls, NATs, etc.) can detect that a > packet is a Public Reset from the header, they may opt to destroy > their internal state upon receiving one. If the Public Reset isn't > verifiable by them, then they may just opt to destroy the state based > on seeing something with the right header. This opens up an on-path > attack where the attacker forges a Public Reset and thus blocks > traffic at the middlebox even though the connection is still live at the > endpoints. > > The design in this PR is based on hash preimages [1]. At the beginning > of the connection the server supplies a Verifier value which is > computed as the Hash of a proof value, like so: > > Verifier = Hash(Proof). > > The Verifer is established at the beginning of the connection and > stored with the connection record. When you want to reset a > connection, you simply send a reset packet that contains Proof. The > peer verifies that Hash(Proof) == Verifier and if so tears down the > connection. As is this fulfills 2, 3, and 4 and optionally 5 if you > expose the RVV to on-path elements during the handshake (or even > periodically during the connection). > > This isn't completely stateless, but you can get away without > per-connection state by computing the per-connection Proof from the > conn_id and some secret stored on the server. I.e., > > Proof_conn = PRF(K_m, conn_id) > > Note that because Proof_conn does not itself leak K_m, seeing one > connection reset doesn't allow resetting other connections. K_m > can be stored and can survive reboots. > > I've tried to mimic the style of the document as best I can but I'm > sure there's some stuff wrong here. > > Comments welcome. > -Ekr > > > > [1] Note that the QUIC Design Document and Rationale describes a > slightly simpler mechanis that uses the same state-handling trick I > describe here but uses what sounds like a MAC instead of a hash > preimage. If you think that requirement #5 is a bad requirement then > that's probably a better design. Happy to write this up if it's the WG > consensus. > > --001a1140bc76f2dd5f05423861b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWIW: I like the proposal.

The major (a= b)use case I was trying to deal with in the QUIC Rationale involved nation = states that could trivially reset connections.=C2=A0 My hope was that the s= omewhat authenticated reset packets would "raise the level of effort&q= uot; for intermediaries that wanted to deny connection service.
<= br>
It is obvious that a full-blown intermediary, such as a route= r, can deny service by consistently dropping packets, but at least such met= hodical dropping was much more effort than a mere TCP RST transmission.=C2= =A0 In addition, a mere RST attack leaves plausible deniability, as it is h= ard to tell who sent the RST, and why, while packet dropping can be (more) = easily blamed on a specific node.

I had not co= nsidered trying to notify middle boxes of termination, though I have discus= sed having "more trusted" middle boxes that could report the fact= that packets in a sequence were missing (never arrived at a way point).=C2= =A0 Given my experiences and experimentation with NATs and such, it seemed = reasonable that the current time-out (LRU?) status quo might well continue,= and QUIC would instead "work around" such unbindings.=C2=A0 Is t= here a lot of real world pressure to do better?

I&= #39;m trying to understand your 5 listed cases.=C2=A0 Am I correct that in = your terms, "on path" attackers are folks that can listen to traf= fic, as well as send, while "off path" attackers must send in the= blind?=C2=A0 What do you call a "full blown intermediary," that = can drop or mutate/replace packets?

Thanks,
<= div>
Jim

Opinions expressed are mine= , and not that of my company.



On Wed, Nov 23, 2016 = at 2:36 PM, Eric Rescorla <ekr@rtfm.com> wrote:
https://github.com/quicwg/base-draf= ts/pull/20

Hi folks,

I just posted a PR to flesh out the Public Reset packet, which is
<= div>somewhat underspecified in the current document.

First, let me lay out what I think are the desirable properties, with
"requirements" having *s and "desiderata" marke= d with "+". Opinions
may vary on the line here.

1. Allow one side to lose connection state (e.g., reboot)= and still
=C2=A0 =C2=A0terminate the connection (*)
2.= Prevent off-path attackers from terminating the connection (*)
3= . Don't require a public key operation for each termination (*)
4. Prevent on-path attackers from terminating the connection (+)
5. Allow on-path elements to determine when a connection was (+)
=C2=A0 =C2=A0terminated [I've marked this with "+" but I r= ecognize that
=C2=A0 =C2=A0some might mark it with "-"]=

#5 seems like the most questionable property, but= here's my rationale.
Because network elements (Firewalls, NA= Ts, etc.) can detect that a
packet is a Public Reset from the hea= der, they may opt to destroy
their internal state upon receiving = one. If the Public Reset isn't
verifiable by them, then they = may just opt to destroy the state based
on seeing something with = the right header.=C2=A0 This opens up an on-path
attack where the= attacker forges a Public Reset and thus blocks
traffic at the mi= ddlebox even though the connection is still live at the
endpoints= .

The design in this PR is based on hash preimages= [1]. At the beginning
of the connection the server supplies a Ve= rifier value which is
computed as the Hash of a proof value, like= so:

=C2=A0 =C2=A0Verifier =3D Hash(Proof).
<= div>
The Verifer is established at the beginning of the conne= ction and
stored with the connection record. When you want to res= et a
connection, you simply send a reset packet that contains Pro= of. The
peer verifies that Hash(Proof) =3D=3D Verifier and if so = tears down the
connection. As is this fulfills 2, 3, and 4 and op= tionally 5 if you
expose the RVV to on-path elements during the h= andshake (or even
periodically during the connection).
=
This isn't completely stateless, but you can get away wi= thout
per-connection state by computing the per-connection Proof = from the
conn_id and some secret stored on the server. I.e.,

=C2=A0 =C2=A0Proof_conn =3D PRF(K_m, conn_id)

Note that because Proof_conn does not itself leak K_m, see= ing one
connection reset doesn't allow resetting other connec= tions. K_m
can be stored and can survive reboots.

<= /div>
I've tried to mimic the style of the document as best I can b= ut I'm
sure there's some stuff wrong here.

=
Comments welcome.
-Ekr



[1] Note that the QUIC Design Document and Rational= e describes a
slightly simpler mechanis that uses the same state-= handling trick I
describe here but uses what sounds like a MAC in= stead of a hash
preimage. If you think that requirement #5 is a b= ad requirement then
that's probably a better design. Happy to= write this up if it's the WG
consensus.

=

--001a1140bc76f2dd5f05423861b3-- From nobody Sat Nov 26 11:10:35 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6611295F9 for ; Sat, 26 Nov 2016 11:10:34 -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 CwDvQGqwLn-O for ; Sat, 26 Nov 2016 11:10:31 -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 A6D061295F7 for ; Sat, 26 Nov 2016 11:10:31 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id i145so85890338ywg.2 for ; Sat, 26 Nov 2016 11:10:31 -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=p30N2Pg30XJSCQsl5A1AGgEJMcMZn/xaCN/Z1UfPYaY=; b=WfF4WkxG/hnKcXiS3ZSiAZtB0j0zHzyU13sT6i/xR7YudAB4bSzAArSxezaP6hVk67 7DzUdn2bNgc/YNOjjzNYI1ZdFsO776yiLqd1Vt9IjLBfznq8fsEl3AHqXWqDkcWFQkK0 X9ZUgV5FC3IDi20J6JDd8RwYdKNnF+eP+hoxKZaow+0Spa6r2ag19luVx+6CxHOnsYoM OSsy3NvToxVmrihX+qUI0t49Duw2cxWo3sNSkbkuLw9CfTHQ/MExjbH0x6Y3kpNb0V1D Tg0kXJDPNtWRcN1iGwqzj7AdSxXIUmKD6waJK9vSPb9/IU8xIR4q/WTF3/+FxabfPA6a hVFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p30N2Pg30XJSCQsl5A1AGgEJMcMZn/xaCN/Z1UfPYaY=; b=hw5joer7lYK89Ci2Jk9ysuVMXvNWvG1gpiJeD679jS+g3sKtw1bN6Z41xNh+vciNFt h8W2sqHiIP4OBkEiYYhDuUN9G/LduZ66SjU0PDNl1/RDlwYR/VhFMPzfJ19IYcaMV82z 6HjrW8lIwOdXOYrWSNEx4oukn6NGbs3hkGPPRtL1aD82TfSHGwJKX6Rcgq18qHOMuSbz yN51Adj91+dFYjo5/3PBvi+t+rUMforapzs0NAhFvfFTtHaZB7gkT3ggcHRKWID+W3gG ZCB52uIuWWtOXycVobwsPb4h6XJ2y1y5R0iaiHIkgJAoZx5CtSJ3wyG/KMmrhMRLBsja 7DWg== X-Gm-Message-State: AKaTC03WxGPvrAYrbmuA1h2wcMnVxs0WcGimEZHJr5ggCrZosqNWZ/AzhyGztTfJlrW7wHQGg2gZX8BfH3n+YA== X-Received: by 10.129.53.194 with SMTP id c185mr17398531ywa.205.1480187430922; Sat, 26 Nov 2016 11:10:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sat, 26 Nov 2016 11:09:50 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sat, 26 Nov 2016 11:09:50 -0800 Message-ID: Subject: Re: Public reset PR To: Jim Roskind Content-Type: multipart/alternative; boundary=001a1142147805a077054238fea7 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 26 Nov 2016 19:10:34 -0000 --001a1142147805a077054238fea7 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 26, 2016 at 10:26 AM, Jim Roskind wrote: > FWIW: I like the proposal. > > The major (ab)use case I was trying to deal with in the QUIC Rationale > involved nation states that could trivially reset connections. My hope was > that the somewhat authenticated reset packets would "raise the level of > effort" for intermediaries that wanted to deny connection service. > > It is obvious that a full-blown intermediary, such as a router, can deny > service by consistently dropping packets, but at least such methodical > dropping was much more effort than a mere TCP RST transmission. In > addition, a mere RST attack leaves plausible deniability, as it is hard to > tell who sent the RST, and why, while packet dropping can be (more) easily > blamed on a specific node. > > I had not considered trying to notify middle boxes of termination, though > I have discussed having "more trusted" middle boxes that could report the > fact that packets in a sequence were missing (never arrived at a way > point). Given my experiences and experimentation with NATs and such, it > seemed reasonable that the current time-out (LRU?) status quo might well > continue, and QUIC would instead "work around" such unbindings. Is there a > lot of real world pressure to do better? > I'm not sure. I have heard a number of people suggest that this would be a good idea, but it's not clear whether it really would be. FWIW, that was not my motivation for property #5. Rather, my motivation was that it seemed difficult to prevent middleboxes which aren't really attackers (e.g., your local NAT) from seeing the public reset and deciding to blow away their NAT bindings even though they can't validate it. So, it seemed better to let them validate it so that the could keep state if it didn't validate. With that said, as I write this, it occurs to me that there's an other alternative. Instead of sending a verifier value in the initial handshake, just send a high entropy secret value R (128 bits is plenty). In order to generate a public reset, generate a QUIC encrypted packet which is formatted correctly but where the payload is: R || Pad Where the Pad is randomly generated and of arbitrary length. Then the receiver can check the first 16 bytes of each packet against R and if it matches, then it knows it's a reset [0]. I.e., the algorithm is: - If first bytes are R, tear down the connection - If not, decrypt the packet. - If decryption is successful, deliver the packet - If decryption is unsuccessful, drop the packet. Note that it might still independently be a good idea to allow middleboxes to see the public reset, but I think that this demonstrates that that's a policy choice about the design of the protocol, not something mandated by limitations in what we can design. I'm trying to understand your 5 listed cases. Am I correct that in your > terms, "on path" attackers are folks that can listen to traffic, as well as > send, while "off path" attackers must send in the blind? > Correct. > What do you call a "full blown intermediary," that can drop or > mutate/replace packets? > That seems like a special case of on-path attacker. I think your term is fine. -Ekr [0] I had previously considered encrypting the public reset with the shared key, but this requires trial decryption on the receiver side, which is much less efficient than this algorithm. Thanks, > > Jim > > Opinions expressed are mine, and not that of my company. > > > > On Wed, Nov 23, 2016 at 2:36 PM, Eric Rescorla wrote: > >> https://github.com/quicwg/base-drafts/pull/20 >> >> Hi folks, >> >> I just posted a PR to flesh out the Public Reset packet, which is >> somewhat underspecified in the current document. >> >> First, let me lay out what I think are the desirable properties, with >> "requirements" having *s and "desiderata" marked with "+". Opinions >> may vary on the line here. >> >> 1. Allow one side to lose connection state (e.g., reboot) and still >> terminate the connection (*) >> 2. Prevent off-path attackers from terminating the connection (*) >> 3. Don't require a public key operation for each termination (*) >> 4. Prevent on-path attackers from terminating the connection (+) >> 5. Allow on-path elements to determine when a connection was (+) >> terminated [I've marked this with "+" but I recognize that >> some might mark it with "-"] >> >> #5 seems like the most questionable property, but here's my rationale. >> Because network elements (Firewalls, NATs, etc.) can detect that a >> packet is a Public Reset from the header, they may opt to destroy >> their internal state upon receiving one. If the Public Reset isn't >> verifiable by them, then they may just opt to destroy the state based >> on seeing something with the right header. This opens up an on-path >> attack where the attacker forges a Public Reset and thus blocks >> traffic at the middlebox even though the connection is still live at the >> endpoints. >> >> The design in this PR is based on hash preimages [1]. At the beginning >> of the connection the server supplies a Verifier value which is >> computed as the Hash of a proof value, like so: >> >> Verifier = Hash(Proof). >> >> The Verifer is established at the beginning of the connection and >> stored with the connection record. When you want to reset a >> connection, you simply send a reset packet that contains Proof. The >> peer verifies that Hash(Proof) == Verifier and if so tears down the >> connection. As is this fulfills 2, 3, and 4 and optionally 5 if you >> expose the RVV to on-path elements during the handshake (or even >> periodically during the connection). >> >> This isn't completely stateless, but you can get away without >> per-connection state by computing the per-connection Proof from the >> conn_id and some secret stored on the server. I.e., >> >> Proof_conn = PRF(K_m, conn_id) >> >> Note that because Proof_conn does not itself leak K_m, seeing one >> connection reset doesn't allow resetting other connections. K_m >> can be stored and can survive reboots. >> >> I've tried to mimic the style of the document as best I can but I'm >> sure there's some stuff wrong here. >> >> Comments welcome. >> -Ekr >> >> >> >> [1] Note that the QUIC Design Document and Rationale describes a >> slightly simpler mechanis that uses the same state-handling trick I >> describe here but uses what sounds like a MAC instead of a hash >> preimage. If you think that requirement #5 is a bad requirement then >> that's probably a better design. Happy to write this up if it's the WG >> consensus. >> >> > --001a1142147805a077054238fea7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 26, 2016 at 10:26 AM, Jim Roskind <JimRoskind@gmail.com= > wrote:
FWIW: I like the proposal.

The major (= ab)use case I was trying to deal with in the QUIC Rationale involved nation= states that could trivially reset connections.=C2=A0 My hope was that the = somewhat authenticated reset packets would "raise the level of effort&= quot; for intermediaries that wanted to deny connection service.
=
It is obvious that a full-blown intermediary, such as a rout= er, can deny service by consistently dropping packets, but at least such me= thodical dropping was much more effort than a mere TCP RST transmission.=C2= =A0 In addition, a mere RST attack leaves plausible deniability, as it is h= ard to tell who sent the RST, and why, while packet dropping can be (more) = easily blamed on a specific node.

I had not co= nsidered trying to notify middle boxes of termination, though I have discus= sed having "more trusted" middle boxes that could report the fact= that packets in a sequence were missing (never arrived at a way point).=C2= =A0 Given my experiences and experimentation with NATs and such, it seemed = reasonable that the current time-out (LRU?) status quo might well continue,= and QUIC would instead "work around" such unbindings.=C2=A0 Is t= here a lot of real world pressure to do better?

I'm not sure. I have heard a number of people suggest = that this would be a good idea, but it's not clear whether it really wo= uld be. FWIW, that was not my motivation for property #5. Rather, my motiva= tion was that it seemed difficult to prevent middleboxes which aren't r= eally attackers (e.g., your local NAT) from seeing the public reset and dec= iding to blow away their NAT bindings even though they can't validate i= t. So, it seemed better to let them validate it so that the could keep stat= e if it didn't validate.

With that said, as I = write this, it occurs to me that there's an other alternative. Instead = of sending a verifier value in the initial handshake, just send a high entr= opy secret value R (128 bits is plenty). In order to generate a public rese= t, generate a QUIC encrypted packet which is formatted correctly but where = the payload is:

=C2=A0 R || Pad

Where the Pad is randomly generated and of arbitrary length. Then th= e receiver can check the first 16 bytes of each packet against R and if it = matches, then it knows it's a reset [0]. I.e., the algorithm is:
<= div>
- If first bytes are R, tear down the connection
- If not, decrypt the packet.
=C2=A0 - If decryption is succes= sful, deliver the packet
=C2=A0 - If decryption is unsuccessful, = drop the packet.

Note that it might still independ= ently be a good idea to allow middleboxes to see the public reset, but I th= ink that this demonstrates that that's a policy choice about the design= of the protocol, not something mandated by limitations in what we can desi= gn.


I'm trying to understand your 5 lis= ted cases.=C2=A0 Am I correct that in your terms, "on path" attac= kers are folks that can listen to traffic, as well as send, while "off= path" attackers must send in the blind?=C2=A0

Correct.

=C2=A0
What do yo= u call a "full blown intermediary," that can drop or mutate/repla= ce packets?

That seems like a s= pecial case of on-path attacker. I think your term is fine.

<= /div>
-Ekr

[0] I had previously considered enc= rypting the public reset with the shared key, but this requires trial decry= ption on the receiver side, which is much less efficient than this algorith= m.


Thanks,

Jim

Opinions expressed are mine, and not that of my compa= ny.


On Wed, Nov 23, 2016 at = 2:36 PM, Eric Rescorla <ekr@rtfm.com> wrote:
https://github.com/quicwg/base-drafts/pull/20
=
Hi folks,

I just posted a PR t= o flesh out the Public Reset packet, which is
somewhat underspeci= fied in the current document.

First, let me lay ou= t what I think are the desirable properties, with
"requireme= nts" having *s and "desiderata" marked with "+". O= pinions
may vary on the line here.

1. Al= low one side to lose connection state (e.g., reboot) and still
= =C2=A0 =C2=A0terminate the connection (*)
2. Prevent off-path att= ackers from terminating the connection (*)
3. Don't require a= public key operation for each termination (*)
4. Prevent on-path= attackers from terminating the connection (+)
5. Allow on-path e= lements to determine when a connection was (+)
=C2=A0 =C2=A0termi= nated [I've marked this with "+" but I recognize that
=C2=A0 =C2=A0some might mark it with "-"]

=
#5 seems like the most questionable property, but here's my ration= ale.
Because network elements (Firewalls, NATs, etc.) can detect = that a
packet is a Public Reset from the header, they may opt to = destroy
their internal state upon receiving one. If the Public Re= set isn't
verifiable by them, then they may just opt to destr= oy the state based
on seeing something with the right header.=C2= =A0 This opens up an on-path
attack where the attacker forges a P= ublic Reset and thus blocks
traffic at the middlebox even though = the connection is still live at the
endpoints.

The design in this PR is based on hash preimages [1]. At the beginni= ng
of the connection the server supplies a Verifier value which i= s
computed as the Hash of a proof value, like so:

<= /div>
=C2=A0 =C2=A0Verifier =3D Hash(Proof).

T= he Verifer is established at the beginning of the connection and
= stored with the connection record. When you want to reset a
conne= ction, you simply send a reset packet that contains Proof. The
pe= er verifies that Hash(Proof) =3D=3D Verifier and if so tears down the
=
connection. As is this fulfills 2, 3, and 4 and optionally 5 if you
expose the RVV to on-path elements during the handshake (or even
periodically during the connection).

This = isn't completely stateless, but you can get away without
per-= connection state by computing the per-connection Proof from the
c= onn_id and some secret stored on the server. I.e.,

=C2=A0 =C2=A0Proof_conn =3D PRF(K_m, conn_id)

Not= e that because Proof_conn does not itself leak K_m, seeing one
co= nnection reset doesn't allow resetting other connections. K_m
can be stored and can survive reboots.

I've t= ried to mimic the style of the document as best I can but I'm
sure there's some stuff wrong here.

Comments = welcome.
-Ekr



<= div>[1] Note that the QUIC Design Document and Rationale describes a
<= div>slightly simpler mechanis that uses the same state-handling trick I
describe here but uses what sounds like a MAC instead of a hash
preimage. If you think that requirement #5 is a bad requirement then<= /div>
that's probably a better design. Happy to write this up if it= 's the WG
consensus.



--001a1142147805a077054238fea7-- From nobody Sat Nov 26 17:31:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892831293DC for ; Sat, 26 Nov 2016 17:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.221 X-Spam-Level: X-Spam-Status: No, score=-1.221 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89FohQiSrFUc for ; Sat, 26 Nov 2016 17:31:37 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18112127071 for ; Sat, 26 Nov 2016 17:31:36 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cAoJa-0005Ki-UI for quic@ietf.org; Sun, 27 Nov 2016 02:31:36 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cAoJ5-0001sc-31 for quic@ietf.org; Sat, 26 Nov 2016 20:31:33 -0500 Received: (qmail 16554 invoked from network); 27 Nov 2016 01:31:01 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Nov 2016 01:31:00 -0000 From: "Christian Huitema" To: "'Eric Rescorla'" , "'Jim Roskind'" References: In-Reply-To: Date: Sat, 26 Nov 2016 15:30:55 -1000 Message-ID: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJonVXnL4d4ZG4Opi5oOnyTDTVr/wFxK6dxAjaMj8ifohsRgA== Content-Language: en-us Subject: RE: Public reset PR X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD1QA paOkzlH4rQyGAaOPY7vlTVT+fmNDEnMzSCeYMvKodcmtTcWSOKD5RASVzg27iuke3OQ7qBRQtKLx pF+RUIJ5kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRqXa47Vo1qFTfGB0/rJ7K6cMQOp+UtDOd2Xrp4Ao XsNbR5gKbK3xJI2P/mgJSlQCjyLMGiRMluEO+CO+gv6r2T/eNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxMwo0ageKMXcNstrfyg5gXa7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRZKVzLoodJpOhZOhElZeeZ68HN1XtUyhw3DgxLaLBwUGYIHhtpcaYbh91FuaKgJHE3L es7Q3TWr9wD5RALyObfQMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.11) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: 'IETF QUIC WG' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 01:31:38 -0000 On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: > > ... (discussion of security properties and alternative design)... > > Note that it might still independently be a good idea to allow = middleboxes to see the=20 > public reset, but I think that this demonstrates that that's a policy = choice about the=20 > design of the protocol, not something mandated by limitations in what = we can design. On limit of the pre-image design is that intermediaries cannot do the = verification. Well, they could if the option was sent in clear text, and = if they parsed the corresponding packet. But then, attackers could send = spoofed handshake messages that contain a fake verifier. They won't fool = the client, but they can confuse the intermediaries. I suppose we could = try piling turtles to try prevent that, but we are better off assuming = that intermediaries won't be able to tell spoofed reset from the true = ones.=20 Can the client really detect the spoofed reset? Not sure. The attacker = can probably play games with TTL so the spoofed packet is dropped before = the client sees it.=20 The better defense is probably to "qualify" the reset, and tell = intermediaries to treat it as a soft signal. Instead of clearing the = connection context, intermediaries could just drop the "expiration = timer" of the context to a short value. Make that value not too short, = at least several RTT. If a new packet from the server arrives at the = intermediary, reset the expiration timer to a natural value. If the = client receives a spoofed reset, it can send a ping to the server and = trigger a response. -- Christian Huitema From nobody Sat Nov 26 17:58:25 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D48CE129420 for ; Sat, 26 Nov 2016 17:58:23 -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 0AGyXFe5Ea0o for ; Sat, 26 Nov 2016 17:58:22 -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 BD06E1293FE for ; Sat, 26 Nov 2016 17:58:22 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id a10so89479133ywa.3 for ; Sat, 26 Nov 2016 17:58:22 -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=JNl1qSYMmvG1+9aL3WdV4gMnS+aRxlhTX7nHVQJwzPs=; b=KkDPbTid6sLj13fYme1S1VMNyqpmmRPRuAa9AlRUreNAshuaxa5P2GYiarA+/qvos/ UWqNQav5T5sNKnGJ1w8BbxBGNWoNXQ+69W0URQfSQLUaW4KEQNluFp+Mh84m6R/8+n6X kCRWv+pI6Q1viT5egjtRLQ9EFxMispv2Lusv82AOoN2o5xoprt7bxdNFuF79Ozh4GAxH YJCOSGdMgNpRhSrCmMnhX6XhBhYfcSCQMm6+C+D5OBzyiLe5sTH7+zdE/0A2Og6BTMGJ 29lw4QxMWStzSDkKFKcRgpY2NB+xAvY80AGEmvKn0cDOwCBVsHknAIS6f0BE5uxy6T8q a/7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JNl1qSYMmvG1+9aL3WdV4gMnS+aRxlhTX7nHVQJwzPs=; b=ZcJZ8Mue0+KQcKXRTGTsgZlEWWoT64lINEU/8UmraipJ4YkcIA0+B7g5Xh8OWd8oBZ atJXqzw4wlAqdlkuJ31XnXKfHOgZg7QH7r75DVNCdQORP4V9jX99xyA451I7vnPBF0iQ bRMuqnh3FVWJ9slG8xpsf2kjJMUS4GmiTbxrcDeNmlJXma0nKnLcSiMlGAFhaXxVxz+Y uohY1peWVJ36+FpRKFjL/VgC2bWofW9KMr/kcP2e9+RHrRt+h424UDcO0cYEs7fz9mQ0 7XN6d3Wpft+SRMsNNv8kgI9T96VlQ0D8lUbkRua4vrbUvanAzSerNQQhn+g9O2B737tp Dd7g== X-Gm-Message-State: AKaTC01tJ8igt9FI7ta9DRyFkn/n6c4bqbcZeVae86AXcN+hyJvVkHsFyA6ikXk6JPvIkovfl/QcN6/ribRthQ== X-Received: by 10.129.81.78 with SMTP id f75mr18349944ywb.149.1480211902014; Sat, 26 Nov 2016 17:58:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sat, 26 Nov 2016 17:57:41 -0800 (PST) In-Reply-To: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> From: Eric Rescorla Date: Sat, 26 Nov 2016 17:57:41 -0800 Message-ID: Subject: Re: Public reset PR To: Christian Huitema Content-Type: multipart/alternative; boundary=001a114564049cd84805423eb0f5 Archived-At: Cc: Jim Roskind , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 01:58:24 -0000 --001a114564049cd84805423eb0f5 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema wrote: > On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: > > > > ... (discussion of security properties and alternative design)... > > > > Note that it might still independently be a good idea to allow > middleboxes to see the > > public reset, but I think that this demonstrates that that's a policy > choice about the > > design of the protocol, not something mandated by limitations in what we > can design. > > On limit of the pre-image design is that intermediaries cannot do the > verification. Well, they could if the option was sent in clear text, and if > they parsed the corresponding packet. Yes, that's correct; it's the assumption of this design that the would do so. If you think that they won't then there are much simpler designs (like the one in the message you are responding to). -Ekr > But then, attackers could send spoofed handshake messages that contain a > fake verifier. They won't fool the client, but they can confuse the > intermediaries. I suppose we could try piling turtles to try prevent that, > but we are better off assuming that intermediaries won't be able to tell > spoofed reset from the true ones. > > Can the client really detect the spoofed reset? Not sure. The attacker can > probably play games with TTL so the spoofed packet is dropped before the > client sees it. > > The better defense is probably to "qualify" the reset, and tell > intermediaries to treat it as a soft signal. Instead of clearing the > connection context, intermediaries could just drop the "expiration timer" > of the context to a short value. Make that value not too short, at least > several RTT. If a new packet from the server arrives at the intermediary, > reset the expiration timer to a natural value. If the client receives a > spoofed reset, it can send a ping to the server and trigger a response. > > -- Christian Huitema > > > > > > > > --001a114564049cd84805423eb0f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema &l= t;huitema@huitema.= net> wrote:
On Saturday, No= vember 26, 2016 9:10 AM, Eric Rescorla wrote:
>
> ... (discussion of security properties and alternative design)...
>
> Note that it might still independently be a good idea to allow middleb= oxes to see the
> public reset, but I think that this demonstrates that that's a pol= icy choice about the
> design of the protocol, not something mandated by limitations in what = we can design.

On limit of the pre-image design is that intermediaries cannot do th= e verification. Well, they could if the option was sent in clear text, and = if they parsed the corresponding packet.

Y= es, that's correct; it's the assumption of this design that the wou= ld do so. If you think that they won't then there are much simpler desi= gns (like the one in the message you are responding to).

-Ekr


=C2=A0
But then, attackers could send spoofed handshake messag= es that contain a fake verifier. They won't fool the client, but they c= an confuse the intermediaries. I suppose we could try piling turtles to try= prevent that, but we are better off assuming that intermediaries won't= be able to tell spoofed reset from the true ones.

Can the client really detect the spoofed reset? Not sure. The attacker can = probably play games with TTL so the spoofed packet is dropped before the cl= ient sees it.

The better defense is probably to "qualify" the reset, and tell i= ntermediaries to treat it as a soft signal. Instead of clearing the connect= ion context, intermediaries could just drop the "expiration timer"= ; of the context to a short value. Make that value not too short, at least = several RTT. If a new packet from the server arrives at the intermediary, r= eset the expiration timer to a natural value. If the client receives a spoo= fed reset, it can send a ping to the server and trigger a response.



-- Christian Huitema








--001a114564049cd84805423eb0f5-- From nobody Sat Nov 26 18:17:50 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F08129475 for ; Sat, 26 Nov 2016 18:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uzwkz1xt_oO for ; Sat, 26 Nov 2016 18:17:47 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D067127735 for ; Sat, 26 Nov 2016 18:17:47 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cAp2H-0000cl-Tk for quic@ietf.org; Sun, 27 Nov 2016 03:17:46 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cAp2G-0005xJ-C7 for quic@ietf.org; Sat, 26 Nov 2016 21:17:45 -0500 Received: (qmail 10626 invoked from network); 27 Nov 2016 02:17:42 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Nov 2016 02:17:42 -0000 From: "Christian Huitema" To: "'Eric Rescorla'" References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> In-Reply-To: Date: Sat, 26 Nov 2016 16:17:40 -1000 Message-ID: <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJonVXnL4d4ZG4Opi5oOnyTDTVr/wFxK6dxAjaMj8gCk11JPgK0p11kn3frQ5A= Content-Language: en-us Subject: RE: Public reset PR X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dBh2p/C8aQaWg6305Dhewuo0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD0Dl h1O7t1p8MLviCE5jfZHcgyinAH5P+hgbEvmLSma/dcmtTcWSOKD5RASVzg27iuke3OQ7qBRQtKLx pF+RUIJ5kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRqXa47Vo1qFTfGB0/rJ7K6cMQOp+UtDOd2Xrp4Ao XsNbR5gKbK3xJI2P/mgJSlQCjyLMGiRMluEO+CO+gv6r2T/eNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxMwo0ageKMXcNstrfyg5gXa7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRZKVzLoodJpOhZOhElZeeZ68HN1XtUyhw3DgxLaLBwUGYIHhtpcaYbh91FuaKgJHE3L es7Q3TWr9wD5RALyObfQMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.05) X-Classification: not-spam/combined X-Recommended-Action: accept Archived-At: Cc: 'Jim Roskind' , 'IETF QUIC WG' X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 02:17:49 -0000 On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema = wrote: >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: >>> >>> ... (discussion of security properties and alternative design)... >> >>> Note that it might still independently be a good idea to allow = middleboxes to see the >>> public reset, but I think that this demonstrates that that's a = policy choice about the >>> design of the protocol, not something mandated by limitations in = what we can design. > >> On limit of the pre-image design is that intermediaries cannot do the = verification. Well,=20 >> they could if the option was sent in clear text, and if they parsed = the corresponding packet.=20 > > Yes, that's correct; it's the assumption of this design that the would = do so. If you think that=20 > they won't then there are much simpler designs (like the one in the = message you are=20 > responding to). Do we really want to ask intermediaries to go parse options inside the = TLS handshake inside stream 1? That does not strike me as too desirable. = I am concerned of the potential there for ossification. I have visions = of delaying the move to TLS 4.1 a couple years from now because = intermediaries really expect TLS 1.3.=20 Then, there is the potential for spoofing. If the verifier text is sent = in clear text, it can be spoofed. What if the man on the side sends a = new Server Hello, with a verifier option of its own choosing? OK, I = suppose that if the spoofed packet wins the race with the authentic = Server Hello, the client will just fail the connection. The spoofed = Server Hello becomes the new weapon of the censors... But even if the = spoofed packet does not win the race, how many intermediaries would just = be fooled and accept the new verifier, and of course the spoofed public = reset that follows? I like the simpler design in which only the client can tell whether the = public reset is authentic. -- Christian Huitema From nobody Sat Nov 26 18:24:31 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF0912940A for ; Sat, 26 Nov 2016 18:24:30 -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] 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 blRhzeOb8TRP for ; Sat, 26 Nov 2016 18:24:28 -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 DBED11293E0 for ; Sat, 26 Nov 2016 18:24:28 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id r204so90058913ywb.0 for ; Sat, 26 Nov 2016 18:24:28 -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=jvpT5pNiL8WM9ez06YP9QEEFdUTHcZ3RZcbeIa4XMuI=; b=m0XwZEKZB/iuy8eBqhZldphciQDO9dcbDDuFg0qFk8Qqtj+TNF5YR4EJ0iMbm7B4dl PVVYv/qgGuANdb0zkpX1W6cT57EKA1SUBfbzUK6BvYXoy99yZV6Phpdqr7zjHY/d0g2n nVxR9Xss9xiE9rSoxj1oZJHz40457vnsTPfYVNkMkYNXHIxiRLcZRMPdta6Xv9RyK+Ue R2GP8x4+DH6+JHO0Rjg0y1FnzS52krm8goR/4E3Rbycmhi/J9FCuyTcs0rIfi5MR8mBN B0xJS8P7uq/YrXTpOFTD8fLTycU3HARXXDy81036t6fS0JlKKqiv8ynefOdP7F+CVE/V WWJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jvpT5pNiL8WM9ez06YP9QEEFdUTHcZ3RZcbeIa4XMuI=; b=YeMIDWVDnbn5fJcbanA9V6uf48wkmXlDIRLIiSLBKGThCnbSZA0x4prD6k+9uovyWO peyoozrpIDFpdk2CLHLn9uvsWGgyAN08ptlZsQtTmbPXxJ7m/kAEz4Yw5sCQvzNFPV+O xjcvNkJ596QuPf69SRPGDe0Jotsaq4J3OaIWHm4+7JZe7g8/sIlNvlwY7zF6CBFStV+a PAIYpEAJ441YJs56RuVXuPRk8a/rE9onyIdBCKt7m/cN9cB4GznotwrEjnflCvsLorgR wbbJbTWmVeyA6xVpuLnQjBw8kJcfb35KGTLvM/0l0Vbj1ieoRc8gBRI0kL1QygFx7oIT lyjg== X-Gm-Message-State: AKaTC02LxjIXgBHijq3jmA8vKxuGBmRR62nvJ0fCofxC92hb4D1wvgC6pF7sblNBAPA0P7wudifReGfpRD2H8A== X-Received: by 10.129.125.215 with SMTP id y206mr17999605ywc.234.1480213468113; Sat, 26 Nov 2016 18:24:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sat, 26 Nov 2016 18:23:47 -0800 (PST) In-Reply-To: <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Eric Rescorla Date: Sat, 26 Nov 2016 18:23:47 -0800 Message-ID: Subject: Re: Public reset PR To: Christian Huitema Content-Type: multipart/alternative; boundary=001a11492dfaf59e3705423f0d62 Archived-At: Cc: Jim Roskind , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 02:24:30 -0000 --001a11492dfaf59e3705423f0d62 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema wrote: > On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: > > > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema huitema@huitema.net> wrote: > >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: > >>> > >>> ... (discussion of security properties and alternative design)... > >> > >>> Note that it might still independently be a good idea to allow > middleboxes to see the > >>> public reset, but I think that this demonstrates that that's a policy > choice about the > >>> design of the protocol, not something mandated by limitations in what > we can design. > > > >> On limit of the pre-image design is that intermediaries cannot do the > verification. Well, > >> they could if the option was sent in clear text, and if they parsed the > corresponding packet. > > > > Yes, that's correct; it's the assumption of this design that the would > do so. If you think that > > they won't then there are much simpler designs (like the one in the > message you are > > responding to). > > Do we really want to ask intermediaries to go parse options inside the TLS > handshake inside stream 1? That does not strike me as too desirable. I am > concerned of the potential there for ossification. I have visions of > delaying the move to TLS 4.1 a couple years from now because intermediaries > really expect TLS 1.3. > > Then, there is the potential for spoofing. If the verifier text is sent in > clear text, it can be spoofed. What if the man on the side sends a new > Server Hello, with a verifier option of its own choosing? OK, I suppose > that if the spoofed packet wins the race with the authentic Server Hello, > the client will just fail the connection. The spoofed Server Hello becomes > the new weapon of the censors... But even if the spoofed packet does not > win the race, how many intermediaries would just be fooled and accept the > new verifier, and of course the spoofed public reset that follows? > Hmm... I would ordinarily expect that clients would respond to a bogus CH (e.g., one that's malformed or that doesn't cryptographically verify) by hanging up the connection, so I'm not sure that this would make the situation that much worse. I like the simpler design in which only the client can tell whether the > public reset is authentic. > Well, there are actually two designs: 1. The middlebox can see the public reset but not verify it 2. The middlebox cannot distinguish the public reset from other packets. I am concerned about #1 for the reasons indicated previously and I originally did not see how to do #2 without fairly significant client-side complexity. Now that I do, it does seem like it's probably the leading option absent some convincing policy argument that middleboxes should be able to see these packets. -Ekr > > -- Christian Huitema > > > > --001a11492dfaf59e3705423f0d62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema &l= t;huitema@huitema.= net> wrote:
On Saturday, No= vember 26, 2016 3:58 PM, Eric Rescorla wrote:

> On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema <mailto:huitema@huitema.net> wrote:
>> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote:
>>>
>>> ... (discussion of security properties and alternative design)= ...
>>
>>> Note that it might still independently be a good idea to allow= middleboxes to see the
>>> public reset, but I think that this demonstrates that that'= ;s a policy choice about the
>>> design of the protocol, not something mandated by limitations = in what we can design.
>
>> On limit of the pre-image design is that intermediaries cannot do = the verification. Well,
>> they could if the option was sent in clear text, and if they parse= d the corresponding packet.
>
> Yes, that's correct; it's the assumption of this design that t= he would do so. If you think that
> they won't then there are much simpler designs (like the one in th= e message you are
> responding to).

Do we really want to ask intermediaries to go parse options inside t= he TLS handshake inside stream 1? That does not strike me as too desirable.= I am concerned of the potential there for ossification. I have visions of = delaying the move to TLS 4.1 a couple years from now because intermediaries= really expect TLS 1.3.

Then, there is the potential for spoofing. If the verifier text is sent in = clear text, it can be spoofed. What if the man on the side sends a new Serv= er Hello, with a verifier option of its own choosing? OK, I suppose that if= the spoofed packet wins the race with the authentic Server Hello, the clie= nt will just fail the connection. The spoofed Server Hello becomes the new = weapon of the censors... But even if the spoofed packet does not win the ra= ce, how many intermediaries would just be fooled and accept the new verifie= r, and of course the spoofed public reset that follows?

Hmm... I would ordinarily expect that clients would respon= d to a bogus CH (e.g., one that's malformed or that
doesn'= ;t cryptographically verify) by hanging up the connection, so I'm not s= ure that this would make the situation
that much worse.


I like the simpler design in which only the client can tell whether the pub= lic reset is authentic.

Well, there are= actually two designs:

1. The middlebox can see th= e public reset but not verify it
2. The middlebox cannot distingu= ish the public reset from other packets.

I am conc= erned about #1 for the reasons indicated previously and I originally did no= t see how to do #2
without fairly significant client-side complex= ity. Now that I do, it does seem like it's probably the leading
option absent some convincing policy argument that middleboxes should be= able to see these packets.

-Ekr
=C2=A0<= /div>

-- Christian Huitema




--001a11492dfaf59e3705423f0d62-- From nobody Sat Nov 26 20:06:12 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AEB81293E3 for ; Sat, 26 Nov 2016 20:06:11 -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=unavailable 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 awLpOkN4Vz8W for ; Sat, 26 Nov 2016 20:06:10 -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 1216F126CD8 for ; Sat, 26 Nov 2016 19:57:28 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id y198so117960579oia.1 for ; Sat, 26 Nov 2016 19:57:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0usNo/lrfWIF8KBqUtpwu4BRYC8j0MELHFO53o9gRHc=; b=NOwpW9CfyHWFbzh53CblSnKRHII5Fr1sXfSsgnSyg2qTHvRpwEoQDJdySkaSNkSpby dfPATqT3v/Ex80euRFTX+fax0QceXRAFvHOaFKIbuq6Pqe725R14nfAzh8yWiGyn+onQ nEE2ItRcVaohwFcnAVilpCBbcHeQuJMmDS6He75PLmW6ItvKSiZDhOESa2cKtRj4dwik P+YP7wNInNP0HMN/VDUHR/xvLiawfxSLEDLDDUUBPev4MpSHMH/Yn0z46tbXi2C36IjA h7zFyvXLw/QLDkxYW5JV6m8vsXM2P95TvpwUMEDRLnzAeWB8G0sEoMuOsu2Meq1oh61G OESQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0usNo/lrfWIF8KBqUtpwu4BRYC8j0MELHFO53o9gRHc=; b=lWvf0NzmhN4QMGWVqQQr1Iz6vTn3biols4ug4Ikqlzk3atuU8FaoOHBwHvK7U0GYom EmSzRAML+y2bsaCqiEQbkx5Yv9E0veCTk4EmwkwENuhgl0h2dQlsV7WAbo9Uj90ggsEi Mu/4NmxbuSWT0ozwCNTWnHcECl4SVuFE3uPsbjICdM5Pxpx0OgmmPOdZsDBPLLNH1RLe LcG+Sq4sTWw9Qw3V5YeDpBMAuJIKekoFFEjFdVr4oB2doatoFz9dp5cVq3QAh5QMVN5a pV+zwVFgw4E0tadb4ahsm1bmCvbRTGPo8aqrjL6qX9DzH8f4ue5Zo5RpFv7B131nBnPS iL8A== X-Gm-Message-State: AKaTC00ZmNVROcj17N0dgrTx5v0J8dzRiLGZC0wvREEyos9xb+7C2tOYM05xCvrGTc80HQ2uv3hZTI6oLYdg3g== X-Received: by 10.157.1.181 with SMTP id e50mr8476422ote.258.1480219047390; Sat, 26 Nov 2016 19:57:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.6.7 with HTTP; Sat, 26 Nov 2016 19:57:26 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Martin Duke Date: Sat, 26 Nov 2016 19:57:26 -0800 Message-ID: Subject: Re: Public reset PR To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c03d05e82732b0542405a6d Archived-At: Cc: Jim Roskind , IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 04:06:11 -0000 --94eb2c03d05e82732b0542405a6d Content-Type: text/plain; charset=UTF-8 To combine some of the ideas in this thread. I think we should have two different kinds of Resets: 1) A message that is authenticated/encrypted as coming from the peer endpoint. The receiver of this kind of reset MUST tear down the connection immediately, and should only happen with connections that the sender regards as fully established. This could be encrypted if it includes whatever mechanism the WG eventually chooses to signal to middleboxes that CONNECTION_CLOSE is hidden in the encryption. A much simpler mechanism would be to sign a plaintext Public Reset with the sender's private key, which might not be too expensive in the context of an existing connection. 2) An unauthenticated reset, which might be due to a rebooted peer, reset during initial handshake, generated by a middlebox, etc. - The receiver of this message MAY (SHOULD?) retain connection state for some period of time to see if additional non-reset packets arrive from the peer. Additional incoming resets MUST NOT restart this reset timer. - I am open to some sort of restriction on continuing to send packets while retaining state, but there are tradeoffs here. A middlebox might apply the timer to all public resets. If we choose the private-key option, it at least has the option of properly verifying the reset. This is probably a better resource decision than preserving connection state. Martin On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla wrote: > > > On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema > wrote: > >> On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: >> >> > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema > huitema@huitema.net> wrote: >> >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: >> >>> >> >>> ... (discussion of security properties and alternative design)... >> >> >> >>> Note that it might still independently be a good idea to allow >> middleboxes to see the >> >>> public reset, but I think that this demonstrates that that's a policy >> choice about the >> >>> design of the protocol, not something mandated by limitations in what >> we can design. >> > >> >> On limit of the pre-image design is that intermediaries cannot do the >> verification. Well, >> >> they could if the option was sent in clear text, and if they parsed >> the corresponding packet. >> > >> > Yes, that's correct; it's the assumption of this design that the would >> do so. If you think that >> > they won't then there are much simpler designs (like the one in the >> message you are >> > responding to). >> >> Do we really want to ask intermediaries to go parse options inside the >> TLS handshake inside stream 1? That does not strike me as too desirable. I >> am concerned of the potential there for ossification. I have visions of >> delaying the move to TLS 4.1 a couple years from now because intermediaries >> really expect TLS 1.3. >> >> Then, there is the potential for spoofing. If the verifier text is sent >> in clear text, it can be spoofed. What if the man on the side sends a new >> Server Hello, with a verifier option of its own choosing? OK, I suppose >> that if the spoofed packet wins the race with the authentic Server Hello, >> the client will just fail the connection. The spoofed Server Hello becomes >> the new weapon of the censors... But even if the spoofed packet does not >> win the race, how many intermediaries would just be fooled and accept the >> new verifier, and of course the spoofed public reset that follows? >> > > Hmm... I would ordinarily expect that clients would respond to a bogus CH > (e.g., one that's malformed or that > doesn't cryptographically verify) by hanging up the connection, so I'm not > sure that this would make the situation > that much worse. > > > I like the simpler design in which only the client can tell whether the >> public reset is authentic. >> > > Well, there are actually two designs: > > 1. The middlebox can see the public reset but not verify it > 2. The middlebox cannot distinguish the public reset from other packets. > > I am concerned about #1 for the reasons indicated previously and I > originally did not see how to do #2 > without fairly significant client-side complexity. Now that I do, it does > seem like it's probably the leading > option absent some convincing policy argument that middleboxes should be > able to see these packets. > > -Ekr > > >> >> -- Christian Huitema >> >> >> >> > --94eb2c03d05e82732b0542405a6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
To combine some of the ideas in this thread. I think we sh= ould have two different kinds of Resets:

1) A message th= at is authenticated/encrypted as coming from the peer endpoint. The receive= r of this kind of reset MUST tear down the connection immediately, and shou= ld only happen with connections that the sender regards as fully establishe= d.

This could be encrypted if it includes whatever= mechanism the WG eventually chooses to signal to middleboxes that CONNECTI= ON_CLOSE is hidden in the encryption. A much simpler mechanism would be to = sign a plaintext Public Reset with the sender's private key, which migh= t not be too expensive in the context of an existing connection.
=
2) An unauthenticated reset, which might be due to a reboote= d peer, reset during initial handshake, generated by a middlebox, etc.=C2= =A0
- I am open to some sort of restriction on continuing to send packets = while retaining state, but there are tradeoffs here.

A = middlebox might apply the timer to all public resets. If we choose the priv= ate-key option, it at least has the option of properly verifying the reset.= This is probably a better resource decision than preserving connection sta= te.

=
Martin

On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla &l= t;ekr@rtfm.com> wrote:


On Sat, = Nov 26, 2016 at 6:17 PM, Christian Huitema <huitema@huitema.net><= /span> wrote:
On Saturday, November 26, 2= 016 3:58 PM, Eric Rescorla wrote:

> On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema <mailto:huitema@huitema.net&g= t; wrote:
>> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote:
>>>
>>> ... (discussion of security properties and alternative design)= ...
>>
>>> Note that it might still independently be a good idea to allow= middleboxes to see the
>>> public reset, but I think that this demonstrates that that'= ;s a policy choice about the
>>> design of the protocol, not something mandated by limitations = in what we can design.
>
>> On limit of the pre-image design is that intermediaries cannot do = the verification. Well,
>> they could if the option was sent in clear text, and if they parse= d the corresponding packet.
>
> Yes, that's correct; it's the assumption of this design that t= he would do so. If you think that
> they won't then there are much simpler designs (like the one in th= e message you are
> responding to).

Do we really want to ask intermediaries to go parse options inside t= he TLS handshake inside stream 1? That does not strike me as too desirable.= I am concerned of the potential there for ossification. I have visions of = delaying the move to TLS 4.1 a couple years from now because intermediaries= really expect TLS 1.3.

Then, there is the potential for spoofing. If the verifier text is sent in = clear text, it can be spoofed. What if the man on the side sends a new Serv= er Hello, with a verifier option of its own choosing? OK, I suppose that if= the spoofed packet wins the race with the authentic Server Hello, the clie= nt will just fail the connection. The spoofed Server Hello becomes the new = weapon of the censors... But even if the spoofed packet does not win the ra= ce, how many intermediaries would just be fooled and accept the new verifie= r, and of course the spoofed public reset that follows?

Hmm... I would ordinarily expect that clients would= respond to a bogus CH (e.g., one that's malformed or that
do= esn't cryptographically verify) by hanging up the connection, so I'= m not sure that this would make the situation
that much worse.


I like the simpler design in which only the client can tell whether the pub= lic reset is authentic.

Well, th= ere are actually two designs:

1. The middlebox can= see the public reset but not verify it
2. The middlebox cannot d= istinguish the public reset from other packets.

I = am concerned about #1 for the reasons indicated previously and I originally= did not see how to do #2
without fairly significant client-side = complexity. Now that I do, it does seem like it's probably the leading<= /div>
option absent some convincing policy argument that middleboxes sh= ould be able to see these packets.

-Ekr
= =C2=A0

-- Christian Huitema





--94eb2c03d05e82732b0542405a6d-- From nobody Sat Nov 26 20:10:07 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6591129469 for ; Sat, 26 Nov 2016 20:10:06 -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 8xvg8D5xjqfX for ; Sat, 26 Nov 2016 20:10:05 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4315126CD8 for ; Sat, 26 Nov 2016 20:10:04 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id i145so90988731ywg.2 for ; Sat, 26 Nov 2016 20:10:04 -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=jllwXpUcc/c8nK9jgNrqt3CAitNOuj3DjQ3lAl+AUyY=; b=zekaJS23+mM3fOHBdojR/EF0j8LB+3nLEyynLU4QfgFUi7hqTDwthhsd6IMXvXxrDi opsv4pbjloor8yvSFh5qMXRoHW8NejrTRTdnqBtGZdXgtVwNL1MI226lZY+ixlxIamCI t9b4XElrRF6c0KTm4QY/F8OK96QeKUy7lg2rKK4e3WldgSWKG3MqZP5ZeSJ3YIwo/sJ2 RgqLdr1w/19QTpWtxwtQtYpkNXmoYg7K1LKUPiUZ437zGA2VG9F6I96vQYV+ZJJ8zC76 bdzTPW8k2GApswU/Cdl/K/dwfYnH5EHcaFEkXbhXnwafrkvMC82cNUWkjSZCLn1VfPjz MaYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jllwXpUcc/c8nK9jgNrqt3CAitNOuj3DjQ3lAl+AUyY=; b=FCq0Nw/jFwsmwn8YTKbgI/wvGajLKjh5C6wZq6mwe4yosesNlMrenOq1u5qzFGoPvB xl3SFVdVaoFXQhdiYcDBdXA27ke1cr5SXAUevfV0jEpQFGydCsAY3Ou319G58rxEvpwR Lmv/FP6BPx8FeM9pmviKuvXlEfO7ei6xa8uDdtdm13Jcxq1v0YoVvoiVwfzPm5chWYNf wbp/GbO9RcIWPdH3SztzI+3GkkE4k/2Kx8JoAVs4kuxDzL0RQpyJD35fvjfJDr0ZRfXz vk6S5Rj8kov+N6zzKUks+9FaZott9VwO9eN736NVvsiBIGDlXSLGeA5iOL+sXHKrqIu6 TrpA== X-Gm-Message-State: AKaTC00Crsqx5A7s97mcUTBEijysW4g7Yve7ArpxqyNhzDr93NU5aVU2rs2azpWxVpUaY+PREuSsFTcf3ZU3cw== X-Received: by 10.129.108.216 with SMTP id h207mr19427434ywc.52.1480219804190; Sat, 26 Nov 2016 20:10:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sat, 26 Nov 2016 20:09:23 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Eric Rescorla Date: Sat, 26 Nov 2016 20:09:23 -0800 Message-ID: Subject: Re: Public reset PR To: Martin Duke Content-Type: multipart/alternative; boundary=001a114dd36e9e7a1305424087d0 Archived-At: Cc: Jim Roskind , IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 04:10:07 -0000 --001a114dd36e9e7a1305424087d0 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 26, 2016 at 7:57 PM, Martin Duke wrote: > To combine some of the ideas in this thread. I think we should have two > different kinds of Resets: > > 1) A message that is authenticated/encrypted as coming from the peer > endpoint. The receiver of this kind of reset MUST tear down the connection > immediately, and should only happen with connections that the sender > regards as fully established. > Unless I misunderstand, this is what CONNECTION_CLOSE already is. > This could be encrypted if it includes whatever mechanism the WG > eventually chooses to signal to middleboxes that CONNECTION_CLOSE is hidden > in the encryption. A much simpler mechanism would be to sign a plaintext > Public Reset with the sender's private key, which might not be too > expensive in the context of an existing connection. > CONNECTION_CLOSE is already covered under the traffic key. This is easier and more efficient than signing it. It also works from the client to the server when the client does not have a key pair. > 2) An unauthenticated reset, which might be due to a rebooted peer, reset > during initial handshake, generated by a middlebox, etc. > > - The receiver of this message MAY (SHOULD?) retain connection state for > some period of time to see if additional non-reset packets arrive from the > peer. Additional incoming resets MUST NOT restart this reset timer. > > - I am open to some sort of restriction on continuing to send packets > while retaining state, but there are tradeoffs here. > > A middlebox might apply the timer to all public resets. If we choose the > private-key option, it at least has the option of properly verifying the > reset. This is probably a better resource decision than preserving > connection state. > This seems to implicitly assume that on-path elements should be able to terminate the connection with a single packet. That seems like an open policy question for the WG. We should probably try to decide that before designing mechanisms to achieve it. -Ekr > Martin > > On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla wrote: > >> >> >> On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema >> wrote: >> >>> On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: >>> >>> > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema >> huitema@huitema.net> wrote: >>> >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: >>> >>> >>> >>> ... (discussion of security properties and alternative design)... >>> >> >>> >>> Note that it might still independently be a good idea to allow >>> middleboxes to see the >>> >>> public reset, but I think that this demonstrates that that's a >>> policy choice about the >>> >>> design of the protocol, not something mandated by limitations in >>> what we can design. >>> > >>> >> On limit of the pre-image design is that intermediaries cannot do the >>> verification. Well, >>> >> they could if the option was sent in clear text, and if they parsed >>> the corresponding packet. >>> > >>> > Yes, that's correct; it's the assumption of this design that the would >>> do so. If you think that >>> > they won't then there are much simpler designs (like the one in the >>> message you are >>> > responding to). >>> >>> Do we really want to ask intermediaries to go parse options inside the >>> TLS handshake inside stream 1? That does not strike me as too desirable. I >>> am concerned of the potential there for ossification. I have visions of >>> delaying the move to TLS 4.1 a couple years from now because intermediaries >>> really expect TLS 1.3. >>> >>> Then, there is the potential for spoofing. If the verifier text is sent >>> in clear text, it can be spoofed. What if the man on the side sends a new >>> Server Hello, with a verifier option of its own choosing? OK, I suppose >>> that if the spoofed packet wins the race with the authentic Server Hello, >>> the client will just fail the connection. The spoofed Server Hello becomes >>> the new weapon of the censors... But even if the spoofed packet does not >>> win the race, how many intermediaries would just be fooled and accept the >>> new verifier, and of course the spoofed public reset that follows? >>> >> >> Hmm... I would ordinarily expect that clients would respond to a bogus CH >> (e.g., one that's malformed or that >> doesn't cryptographically verify) by hanging up the connection, so I'm >> not sure that this would make the situation >> that much worse. >> >> >> I like the simpler design in which only the client can tell whether the >>> public reset is authentic. >>> >> >> Well, there are actually two designs: >> >> 1. The middlebox can see the public reset but not verify it >> 2. The middlebox cannot distinguish the public reset from other packets. >> >> I am concerned about #1 for the reasons indicated previously and I >> originally did not see how to do #2 >> without fairly significant client-side complexity. Now that I do, it does >> seem like it's probably the leading >> option absent some convincing policy argument that middleboxes should be >> able to see these packets. >> >> -Ekr >> >> >>> >>> -- Christian Huitema >>> >>> >>> >>> >> > --001a114dd36e9e7a1305424087d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 26, 2016 at 7:57 PM, Martin Duke <martin.h.duke@gmai= l.com> wrote:
To combine some of the ideas in this thread. I think we should have two= different kinds of Resets:

1) A message that is authent= icated/encrypted as coming from the peer endpoint. The receiver of this kin= d of reset MUST tear down the connection immediately, and should only happe= n with connections that the sender regards as fully established.

Unless I misunderstand, this is what CONN= ECTION_CLOSE already is.

=C2=A0
This could be encrypted if it i= ncludes whatever mechanism the WG eventually chooses to signal to middlebox= es that CONNECTION_CLOSE is hidden in the encryption. A much simpler mechan= ism would be to sign a plaintext Public Reset with the sender's private= key, which might not be too expensive in the context of an existing connec= tion.

CONNECTION_CLOSE is alrea= dy covered under the traffic key. This is easier and more efficient than si= gning it. It also works from the client to the server when the client does = not have a key pair.


2) An unauthenticated reset, which might = be due to a rebooted peer, reset during initial handshake, generated by a m= iddlebox, etc.=C2=A0
- The receiver of this message MAY (SHOULD?) retain= connection state for some period of time to see if additional non-reset pa= ckets arrive from the peer. Additional incoming resets MUST NOT restart thi= s reset timer.
- I am open to some sort of restriction on continuing= to send packets while retaining state, but there are tradeoffs here.
A middlebox might apply the timer to all public resets. If w= e choose the private-key option, it at least has the option of properly ver= ifying the reset. This is probably a better resource decision than preservi= ng connection state.

This seems t= o implicitly assume that on-path elements should be able to terminate the c= onnection with a single packet. That seems like an open policy question for= the WG. We should probably try to decide that before designing mechanisms = to achieve it.

-Ekr


Martin

On Sat, N= ov 26, 2016 at 6:23 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Sat, Nov 26, 2016 at 6:17 PM, Chr= istian Huitema <huitema@huitema.net> wrote:
On Saturday, November 26, 2016 3:58 PM, Eric Rescorla w= rote:

> On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema <mailto:huitema@huitema.net&g= t; wrote:
>> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote:
>>>
>>> ... (discussion of security properties and alternative design)= ...
>>
>>> Note that it might still independently be a good idea to allow= middleboxes to see the
>>> public reset, but I think that this demonstrates that that'= ;s a policy choice about the
>>> design of the protocol, not something mandated by limitations = in what we can design.
>
>> On limit of the pre-image design is that intermediaries cannot do = the verification. Well,
>> they could if the option was sent in clear text, and if they parse= d the corresponding packet.
>
> Yes, that's correct; it's the assumption of this design that t= he would do so. If you think that
> they won't then there are much simpler designs (like the one in th= e message you are
> responding to).

Do we really want to ask intermediaries to go parse options inside t= he TLS handshake inside stream 1? That does not strike me as too desirable.= I am concerned of the potential there for ossification. I have visions of = delaying the move to TLS 4.1 a couple years from now because intermediaries= really expect TLS 1.3.

Then, there is the potential for spoofing. If the verifier text is sent in = clear text, it can be spoofed. What if the man on the side sends a new Serv= er Hello, with a verifier option of its own choosing? OK, I suppose that if= the spoofed packet wins the race with the authentic Server Hello, the clie= nt will just fail the connection. The spoofed Server Hello becomes the new = weapon of the censors... But even if the spoofed packet does not win the ra= ce, how many intermediaries would just be fooled and accept the new verifie= r, and of course the spoofed public reset that follows?

Hmm... I would ordinarily expect that clients would= respond to a bogus CH (e.g., one that's malformed or that
do= esn't cryptographically verify) by hanging up the connection, so I'= m not sure that this would make the situation
that much worse.


I like the simpler design in which only the client can tell whether the pub= lic reset is authentic.

Well, th= ere are actually two designs:

1. The middlebox can= see the public reset but not verify it
2. The middlebox cannot d= istinguish the public reset from other packets.

I = am concerned about #1 for the reasons indicated previously and I originally= did not see how to do #2
without fairly significant client-side = complexity. Now that I do, it does seem like it's probably the leading<= /div>
option absent some convincing policy argument that middleboxes sh= ould be able to see these packets.

-Ekr
= =C2=A0

-- Christian Huitema






--001a114dd36e9e7a1305424087d0-- From nobody Sat Nov 26 20:23:59 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C89126CD8 for ; Sat, 26 Nov 2016 20:23:57 -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 pxDqpH_H9Wzk for ; Sat, 26 Nov 2016 20:23:55 -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 8B7F61293E3 for ; Sat, 26 Nov 2016 20:23:55 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id b126so117945258oia.2 for ; Sat, 26 Nov 2016 20:23:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2ls8ys/fV1z17i3vLAVp8JvfYA5xpJGhIGKh3D7hMss=; b=t5PNyg+Xyo4nSfvdH3KUDE25vi8x6oHfznm3A92Ky8NW370lnpLLBnpe0rZpmHrFId ROp9xDqAhYyR5bTF15/4/speq49mMbD7RSS0n8YY2tcc7/CdpcwpyI7NdfXFLhC5ATSI b1em3W2pL+XbUaCt51zl0wEiWOU2I2xCDuwQ6SKaqwpWfIJ5FsThqDs9tqgWDGKXSNzG 7hQfehSAzx7VooRjFOsTwH8HbCkFEZLdvTyRG7dwGgxBOBpaEIzjx+I7HN0hk5ZnB89d gmLRHHFNl9n0if+QVswlXKQ3GZXq7cNZizUJoy0oMObnS2vDl1OccgEc0YDWeBXbO1Tj maBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2ls8ys/fV1z17i3vLAVp8JvfYA5xpJGhIGKh3D7hMss=; b=K8xIe7BBpC9bDo49B4QlsgbOe5Mj6zUeSwcrtki6ZCPme2u53Yt4IRvbJEo2rWv1gp CgGJuVeOnvNSUxGvVJH+lnBos/W6Jr3UzNswHLcWo+LhN8NGUdUir3QruVc1pUiXZn3m MpoKDC7uegTv9FykOR3UAF+UeLRZPkomI4CPmRMmdMaIKVKj3CGyPeBuDmkg9EHTViWx 1jUfHVrAg/JFttsdqZj1OypInKW8c66LX6exvizOcJn6K1ykEkACkNxeSwRKZVW8BL1U jaDovBZxEUZZkBFwLQj0VRU2Gj+hdrCSyO8TAvbSXG4Cs59oSZTH+wlThH7iH9/43WOr Tgig== X-Gm-Message-State: AKaTC028LcRoYkPnyD9VdT1Uc9v5YKQRxKaZB9RygQItsccxVgq0jbBGHtA8zlFjutgxQxLk1Swinjb77FUlKg== X-Received: by 10.157.20.176 with SMTP id d45mr8376401ote.2.1480220634923; Sat, 26 Nov 2016 20:23:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.6.7 with HTTP; Sat, 26 Nov 2016 20:23:54 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Martin Duke Date: Sat, 26 Nov 2016 20:23:54 -0800 Message-ID: Subject: Re: Public reset PR To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114403322247e2054240b971 Archived-At: Cc: Jim Roskind , IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 04:23:57 -0000 --001a114403322247e2054240b971 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 26, 2016 at 8:09 PM, Eric Rescorla wrote: > > > Unless I misunderstand, this is what CONNECTION_CLOSE already is. > > CONNECTION_CLOSE is only sent, according to the latest draft, when all streams have been properly closed. It is the equivalent of the FIN flag in a TCP connection, to the best of my knowledge. It is not the same thing as the authenticated/encrypted public reset we're discussing here. > This seems to implicitly assume that on-path elements should be able to > terminate the connection with a single packet. That seems like an open > policy question for the WG. We should probably try to decide that before > designing mechanisms to achieve it. > > -Ekr > As we've already established, an on-path forwarder can already block a connection by simply dropping packets. This is simply a cleaner way to handle it. What the timer does is address eavesdroppers. If I'm at the coffee shop with you, I can send unauthenticated Public Resets to try to terminate your connection, but if the real server responds within the timeout these resets will have no effect. This is a significant improvement on TCP, in my opinion. Martin > > >> Martin >> >> On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla wrote: >> >>> >>> >>> On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema >>> wrote: >>> >>>> On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: >>>> >>>> > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema >>> huitema@huitema.net> wrote: >>>> >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: >>>> >>> >>>> >>> ... (discussion of security properties and alternative design)... >>>> >> >>>> >>> Note that it might still independently be a good idea to allow >>>> middleboxes to see the >>>> >>> public reset, but I think that this demonstrates that that's a >>>> policy choice about the >>>> >>> design of the protocol, not something mandated by limitations in >>>> what we can design. >>>> > >>>> >> On limit of the pre-image design is that intermediaries cannot do >>>> the verification. Well, >>>> >> they could if the option was sent in clear text, and if they parsed >>>> the corresponding packet. >>>> > >>>> > Yes, that's correct; it's the assumption of this design that the >>>> would do so. If you think that >>>> > they won't then there are much simpler designs (like the one in the >>>> message you are >>>> > responding to). >>>> >>>> Do we really want to ask intermediaries to go parse options inside the >>>> TLS handshake inside stream 1? That does not strike me as too desirable. I >>>> am concerned of the potential there for ossification. I have visions of >>>> delaying the move to TLS 4.1 a couple years from now because intermediaries >>>> really expect TLS 1.3. >>>> >>>> Then, there is the potential for spoofing. If the verifier text is sent >>>> in clear text, it can be spoofed. What if the man on the side sends a new >>>> Server Hello, with a verifier option of its own choosing? OK, I suppose >>>> that if the spoofed packet wins the race with the authentic Server Hello, >>>> the client will just fail the connection. The spoofed Server Hello becomes >>>> the new weapon of the censors... But even if the spoofed packet does not >>>> win the race, how many intermediaries would just be fooled and accept the >>>> new verifier, and of course the spoofed public reset that follows? >>>> >>> >>> Hmm... I would ordinarily expect that clients would respond to a bogus >>> CH (e.g., one that's malformed or that >>> doesn't cryptographically verify) by hanging up the connection, so I'm >>> not sure that this would make the situation >>> that much worse. >>> >>> >>> I like the simpler design in which only the client can tell whether the >>>> public reset is authentic. >>>> >>> >>> Well, there are actually two designs: >>> >>> 1. The middlebox can see the public reset but not verify it >>> 2. The middlebox cannot distinguish the public reset from other packets. >>> >>> I am concerned about #1 for the reasons indicated previously and I >>> originally did not see how to do #2 >>> without fairly significant client-side complexity. Now that I do, it >>> does seem like it's probably the leading >>> option absent some convincing policy argument that middleboxes should be >>> able to see these packets. >>> >>> -Ekr >>> >>> >>>> >>>> -- Christian Huitema >>>> >>>> >>>> >>>> >>> >> > --001a114403322247e2054240b971 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Nov 26, 2016 at 8:09 PM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>

<= div class=3D"gmail_extra">
Unless I misunderstand, this is what CONNECTION_CLOSE already is.=


CONNECTION_CLOSE is only s= ent, according to the latest draft, when all streams have been properly clo= sed. It is the equivalent of the FIN flag in a TCP connection, to the best = of my knowledge. It is not the same thing as the authenticated/encrypted pu= blic reset we're discussing here.



This seems to implicitly assume that on-path element= s should be able to terminate the connection with a single packet. That see= ms like an open policy question for the WG. We should probably try to decid= e that before designing mechanisms to achieve it.

= -Ekr

As we've a= lready established, an on-path forwarder can already block a connection by = simply dropping packets. This is simply a cleaner way to handle it.

What the timer does is address eavesdroppers. If I'm = at the coffee shop with you, I can send unauthenticated Public Resets to tr= y to terminate your connection, but if the real server responds within the = timeout these resets will have no effect. This is a significant improvement= on TCP, in my opinion.

Martin
=C2=A0


Martin

On Sat, Nov 26, 2016 at= 6:23 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Sat, Nov 26, 2016 at 6:17 PM= , Christian Huitema <huitema@huitema.net> wrote:
On Saturday, November 26, 2016 = 3:58 PM, Eric Rescorla wrote:

> On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema <mailto:huitema@huitema.net&g= t; wrote:
>> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote:
>>>
>>> ... (discussion of security properties and alternative design)= ...
>>
>>> Note that it might still independently be a good idea to allow= middleboxes to see the
>>> public reset, but I think that this demonstrates that that'= ;s a policy choice about the
>>> design of the protocol, not something mandated by limitations = in what we can design.
>
>> On limit of the pre-image design is that intermediaries cannot do = the verification. Well,
>> they could if the option was sent in clear text, and if they parse= d the corresponding packet.
>
> Yes, that's correct; it's the assumption of this design that t= he would do so. If you think that
> they won't then there are much simpler designs (like the one in th= e message you are
> responding to).

Do we really want to ask intermediaries to go parse options inside t= he TLS handshake inside stream 1? That does not strike me as too desirable.= I am concerned of the potential there for ossification. I have visions of = delaying the move to TLS 4.1 a couple years from now because intermediaries= really expect TLS 1.3.

Then, there is the potential for spoofing. If the verifier text is sent in = clear text, it can be spoofed. What if the man on the side sends a new Serv= er Hello, with a verifier option of its own choosing? OK, I suppose that if= the spoofed packet wins the race with the authentic Server Hello, the clie= nt will just fail the connection. The spoofed Server Hello becomes the new = weapon of the censors... But even if the spoofed packet does not win the ra= ce, how many intermediaries would just be fooled and accept the new verifie= r, and of course the spoofed public reset that follows?

Hmm... I would ordinarily expect that clients would= respond to a bogus CH (e.g., one that's malformed or that
do= esn't cryptographically verify) by hanging up the connection, so I'= m not sure that this would make the situation
that much worse.


I like the simpler design in which only the client can tell whether the pub= lic reset is authentic.

Well, th= ere are actually two designs:

1. The middlebox can= see the public reset but not verify it
2. The middlebox cannot d= istinguish the public reset from other packets.

I = am concerned about #1 for the reasons indicated previously and I originally= did not see how to do #2
without fairly significant client-side = complexity. Now that I do, it does seem like it's probably the leading<= /div>
option absent some convincing policy argument that middleboxes sh= ould be able to see these packets.

-Ekr
= =C2=A0

-- Christian Huitema







--001a114403322247e2054240b971-- From nobody Sat Nov 26 20:50:24 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8A8129491 for ; Sat, 26 Nov 2016 20:50:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPr75gRgirTi for ; Sat, 26 Nov 2016 20:50:22 -0800 (PST) Received: from mail-wj0-x234.google.com (mail-wj0-x234.google.com [IPv6:2a00:1450:400c:c01::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 1824D1204D9 for ; Sat, 26 Nov 2016 20:50:22 -0800 (PST) Received: by mail-wj0-x234.google.com with SMTP id xy5so88793978wjc.0 for ; Sat, 26 Nov 2016 20:50:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7pv44wQMUjHDmwjrHJJswfoPp4J50INqvM/Nyw2QJxE=; b=ct+G0xSjdFNjsLwX27qzGOr+HH0PIWZrRI5e34kbKHnu3njwK26dl8XMGt+VEpsryc 04CjQJc24c9ov8TVAPiY/uPlLrjSr5D0MLeqTMQVd6hNR1C0daBOiLpvbUU0pvlA9Yao omzqm9uOY0Ojx3/qlKjP33KMfcYy5ZKivAogvHdwAvLroMsYXD+DjGg8Sy3QsROmxTFg WRxCdVzsLmnz+NiIgDQbiyRKh2tH5B33Rw3yGU8aAY0SIi50pGyhY9FxuFh4HU9/pmLP R6x2m23uDOpecrRYlgTuPGAADFB/0oiV28DZiLPrx3UlZHLh6yJxgrhlywmFl++oCIFb nAzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7pv44wQMUjHDmwjrHJJswfoPp4J50INqvM/Nyw2QJxE=; b=KWj8QJPbtVW407r+MzNvYfmFny4UzTMp6Accuqk5BJNttJiffHBAS/+bINFpWfnTeE 7Rh2xjEtFkRTn0WFvtuKQRZIpnXJY3mZnzhSsGrrEv33QhYjAyyDAM9Lnqyp429AJacd Sgvr4uSUlD5oKW0GlYEV9Mov1/UgOR9NIGhWj9uqbllWaDJnSrfIeGxaQJzHpCrriW1O xcywb5Je+u9S22HnVnXYZuvqjpUzQ0JOBXLoziExKYJcjKvwO5nnEZBEfz9DgumlzVsA ncm/KqXE59N+vv87zlaFlSOIUByOrvMf5QX0sA5ekIdkoATqlgMS7bpph1/cROEzl49d +NWQ== X-Gm-Message-State: AKaTC02r1y+DYhkRzX2k54PzIskp9oac9sFgCQHmvC6KEkl5ww9hGQQOma6HN5sJabCc1R4nfkXd31r75AQL14Ay X-Received: by 10.194.15.37 with SMTP id u5mr13039415wjc.117.1480222220495; Sat, 26 Nov 2016 20:50:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.22 with HTTP; Sat, 26 Nov 2016 20:50:19 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Ryan Hamilton Date: Sat, 26 Nov 2016 20:50:19 -0800 Message-ID: Subject: Re: Public reset PR To: Martin Duke Content-Type: multipart/alternative; boundary=089e0149482aa47d6a05424117cf Archived-At: Cc: Jim Roskind , Eric Rescorla , IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 04:50:23 -0000 --089e0149482aa47d6a05424117cf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Nov 26, 2016 at 8:23 PM, Martin Duke wrote: > On Sat, Nov 26, 2016 at 8:09 PM, Eric Rescorla wrote: > >> >> Unless I misunderstand, this is what CONNECTION_CLOSE already is. >> > > CONNECTION_CLOSE is only sent, according to the latest draft, when all > streams have been properly closed. It is the equivalent of the FIN flag i= n > a TCP connection, to the best of my knowledge. It is not the same thing a= s > the authenticated/encrypted public reset we're discussing here. > That is definitely not the intent of the spec. If it says that, then we should fix it :) For example, CONNECTION_CLOSE is sent when an endpoint detects an error. This causes the connection to be terminated regardless of the number or status of open streams.=E2=80=8B --089e0149482aa47d6a05424117cf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Sat, Nov 26, 2016 at 8:23 PM, Martin Duke <martin.h.duke@gmail.c= om> wrote:
On Sat, Nov 26, 2016 at 8:09 PM, Eric Rescorla <ekr@rtfm.com> wr= ote:
=

Unless I misunderstand, this is what CONNE= CTION_CLOSE already is.

CONNECTION_CLOSE is only sent, according to the latest draft, when a= ll streams have been properly closed. It is the equivalent of the FIN flag = in a TCP connection, to the best of my knowledge. It is not the same thing = as the authenticated/encrypted public reset we're discussing here.

That= is definitely not the intent of the spec. If it says that, then we should = fix it :) For example, CONNECTION_CLOSE is sent when an endpoint detects an= error. This causes the connection to be terminated regardless of the numbe= r or status of open streams.=E2=80=8B

--089e0149482aa47d6a05424117cf-- From nobody Sat Nov 26 21:39:55 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08A4128874 for ; Sat, 26 Nov 2016 21:39:54 -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 JFflaz5q2zy5 for ; Sat, 26 Nov 2016 21:39:53 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::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 1899C120727 for ; Sat, 26 Nov 2016 21:39:53 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id a10so91342460ywa.3 for ; Sat, 26 Nov 2016 21:39:53 -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=dh8rSx5tuBbLrryRHeQQ5AQE7NV2zsw+hlt0QTXIRdk=; b=hnr11lwcUaMGmi5OZYerw2AD9Qv5ywfhLo7YgXjDb4c3GnJvG3XFrJmczdUc7I2KIX XXdCGAXCnF/WuTjiGJzwOr4VBKOegRc1s7QcmVxOJHmf7jSGh58z1E5Bj2esNZAZYedq X+inc97CWpot9lJneXBbmOzCkbeuN3qIOJksP7BqcTecX7cV7ss460uEu5cf7UawyE1h APfYsGENgQT6KWcxuUyD3UxfYJZUM2zArSdM0ElW/u5ziEJw1HtZsWdg/Ukq4ignqFq9 sKMwU0M0nejuGdy5An+zgptaXNGvEcnt/7CsUR7N+875RPQSMyPoIdqwG4OvH1uPynq9 +TgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dh8rSx5tuBbLrryRHeQQ5AQE7NV2zsw+hlt0QTXIRdk=; b=XCNmLupweMPIf1vbstXyPzQcNFSphP7da5sKSOZT4MiwtsU4AGQNeZn2bsii8JNW4W tlWEc0yHHClV6b2lA3qYgwoREUGhaPObn91Yzb6twS0lIHHurjkQmDJ82DDS+kqNwW4u 1p6rFrtoXwtSgTsAY9bz0HXEJHSUdofe0xJWvzfmg2W9c4ifZ6ofgXUsKIzwBi6rDXWF /rnbNs8/0he+Mw5opOowHnSHgB2cSsJgdXBUvU6XvWeLDH6viMmxFN793FQEt+E/kb2U JSsPn4QjW79zybPOZNJKQhIxjEr1ca0KvVikpeRKp+ryz3HgN4LNXQ0b7m/8mtXBzG87 Tevw== X-Gm-Message-State: AKaTC032TmzsQIR58lxwr2/o5GOG4QpMcjTeNH2XupC8FAsGJBMA6D+Jtnd1MRynJRYHcGRm9aQUsi9haBFIDQ== X-Received: by 10.129.108.216 with SMTP id h207mr19660607ywc.52.1480225192332; Sat, 26 Nov 2016 21:39:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sat, 26 Nov 2016 21:39:11 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Eric Rescorla Date: Sat, 26 Nov 2016 21:39:11 -0800 Message-ID: Subject: Re: Public reset PR To: Martin Duke Content-Type: multipart/alternative; boundary=001a114dd36ec72837054241c8b5 Archived-At: Cc: Jim Roskind , IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 05:39:54 -0000 --001a114dd36ec72837054241c8b5 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 26, 2016 at 8:23 PM, Martin Duke wrote: > As we've already established, an on-path forwarder can already block a > connection by simply dropping packets. This is simply a cleaner way to > handle it. > I think the policy question is whether we wish to have a cleaner way to handle it or whether we want to require on-path attackers to drop every packet. > What the timer does is address eavesdroppers. If I'm at the coffee shop > with you, I can send unauthenticated Public Resets to try to terminate your > connection, but if the real server responds within the timeout these resets > will have no effect. This is a significant improvement on TCP, in my > opinion. > Unless I'm missing something, the mechanism I proposed earlier today (having a secret per-connection reset token which you use in place of the ciphertext) also addresses this problem: - No endpoint will accept a bogus public reset - There is no externally visible signal of a public reset for innocent middleboxes to process. -Ekr > On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla wrote: >>> >>>> >>>> >>>> On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema >>> > wrote: >>>> >>>>> On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: >>>>> >>>>> > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema >>>> huitema@huitema.net> wrote: >>>>> >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: >>>>> >>> >>>>> >>> ... (discussion of security properties and alternative design)... >>>>> >> >>>>> >>> Note that it might still independently be a good idea to allow >>>>> middleboxes to see the >>>>> >>> public reset, but I think that this demonstrates that that's a >>>>> policy choice about the >>>>> >>> design of the protocol, not something mandated by limitations in >>>>> what we can design. >>>>> > >>>>> >> On limit of the pre-image design is that intermediaries cannot do >>>>> the verification. Well, >>>>> >> they could if the option was sent in clear text, and if they parsed >>>>> the corresponding packet. >>>>> > >>>>> > Yes, that's correct; it's the assumption of this design that the >>>>> would do so. If you think that >>>>> > they won't then there are much simpler designs (like the one in the >>>>> message you are >>>>> > responding to). >>>>> >>>>> Do we really want to ask intermediaries to go parse options inside the >>>>> TLS handshake inside stream 1? That does not strike me as too desirable. I >>>>> am concerned of the potential there for ossification. I have visions of >>>>> delaying the move to TLS 4.1 a couple years from now because intermediaries >>>>> really expect TLS 1.3. >>>>> >>>>> Then, there is the potential for spoofing. If the verifier text is >>>>> sent in clear text, it can be spoofed. What if the man on the side sends a >>>>> new Server Hello, with a verifier option of its own choosing? OK, I suppose >>>>> that if the spoofed packet wins the race with the authentic Server Hello, >>>>> the client will just fail the connection. The spoofed Server Hello becomes >>>>> the new weapon of the censors... But even if the spoofed packet does not >>>>> win the race, how many intermediaries would just be fooled and accept the >>>>> new verifier, and of course the spoofed public reset that follows? >>>>> >>>> >>>> Hmm... I would ordinarily expect that clients would respond to a bogus >>>> CH (e.g., one that's malformed or that >>>> doesn't cryptographically verify) by hanging up the connection, so I'm >>>> not sure that this would make the situation >>>> that much worse. >>>> >>>> >>>> I like the simpler design in which only the client can tell whether the >>>>> public reset is authentic. >>>>> >>>> >>>> Well, there are actually two designs: >>>> >>>> 1. The middlebox can see the public reset but not verify it >>>> 2. The middlebox cannot distinguish the public reset from other packets. >>>> >>>> I am concerned about #1 for the reasons indicated previously and I >>>> originally did not see how to do #2 >>>> without fairly significant client-side complexity. Now that I do, it >>>> does seem like it's probably the leading >>>> option absent some convincing policy argument that middleboxes should >>>> be able to see these packets. >>>> >>>> -Ekr >>>> >>>> >>>>> >>>>> -- Christian Huitema >>>>> >>>>> >>>>> >>>>> >>>> >>> >> > --001a114dd36ec72837054241c8b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= at, Nov 26, 2016 at 8:23 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
As = we've already established, an on-path forwarder can already block a con= nection by simply dropping packets. This is simply a cleaner way to handle = it.

<= div>



-Ekr





=C2=A0
=
On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla <= span dir=3D"ltr"><ekr@= rtfm.com> wrote:


On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema <= span dir=3D"ltr"><huitema@huitema.net> wrote:
On Saturday, November 26, 2016 3:58 PM, Eric Rescorl= a wrote:

> On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema <mailto:huitema@huitema.net&g= t; wrote:
>> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote:
>>>
>>> ... (discussion of security properties and alternative design)= ...
>>
>>> Note that it might still independently be a good idea to allow= middleboxes to see the
>>> public reset, but I think that this demonstrates that that'= ;s a policy choice about the
>>> design of the protocol, not something mandated by limitations = in what we can design.
>
>> On limit of the pre-image design is that intermediaries cannot do = the verification. Well,
>> they could if the option was sent in clear text, and if they parse= d the corresponding packet.
>
> Yes, that's correct; it's the assumption of this design that t= he would do so. If you think that
> they won't then there are much simpler designs (like the one in th= e message you are
> responding to).

Do we really want to ask intermediaries to go parse options inside t= he TLS handshake inside stream 1? That does not strike me as too desirable.= I am concerned of the potential there for ossification. I have visions of = delaying the move to TLS 4.1 a couple years from now because intermediaries= really expect TLS 1.3.

Then, there is the potential for spoofing. If the verifier text is sent in = clear text, it can be spoofed. What if the man on the side sends a new Serv= er Hello, with a verifier option of its own choosing? OK, I suppose that if= the spoofed packet wins the race with the authentic Server Hello, the clie= nt will just fail the connection. The spoofed Server Hello becomes the new = weapon of the censors... But even if the spoofed packet does not win the ra= ce, how many intermediaries would just be fooled and accept the new verifie= r, and of course the spoofed public reset that follows?

Hmm... I would ordinarily expect that clients would= respond to a bogus CH (e.g., one that's malformed or that
do= esn't cryptographically verify) by hanging up the connection, so I'= m not sure that this would make the situation
that much worse.


I like the simpler design in which only the client can tell whether the pub= lic reset is authentic.

Well, th= ere are actually two designs:

1. The middlebox can= see the public reset but not verify it
2. The middlebox cannot d= istinguish the public reset from other packets.

I = am concerned about #1 for the reasons indicated previously and I originally= did not see how to do #2
without fairly significant client-side = complexity. Now that I do, it does seem like it's probably the leading<= /div>
option absent some convincing policy argument that middleboxes sh= ould be able to see these packets.

-Ekr
= =C2=A0

-- Christian Huitema








--001a114dd36ec72837054241c8b5-- From nobody Sat Nov 26 22:20:53 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E61D1293E9 for ; Sat, 26 Nov 2016 22:20:52 -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 wfYZZyaIV3s9 for ; Sat, 26 Nov 2016 22:20:50 -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 3A49A120727 for ; Sat, 26 Nov 2016 22:20:50 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id w63so119540932oiw.0 for ; Sat, 26 Nov 2016 22:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LRNtJun+/Ni6O8Shdi1f3wARhkyLxCUWqhu2svDUkQ4=; b=FsuOtJfgUZ65TQw6FCIwn7zraHe5TwmE94rVA3iVtPub9a9PB0iZONPcSl5p2Vwuxz 0UGLuF959Qso2OAgWEi7b1xfenZLli3eL5Lf5JjPyYJn3ziBhhH19L+Bv54aLJw9Be+x rtBe2YHoPk3xD169mYQaCQ8uy98b6EZiMk81xBRNBTXaKQ4MpJ5iICNZP7yCNh+ZRGUg TtemfPFqRVRv/sq5CV+VFy2I4qiW/HCPHDPHpUpPEoFZ493P6oMwlkoC0PEF7mcTK0kg OKwvxgCaqoyIYe2knDuFelYTK2Rsutl+XOXN9RqOQm/48J1cRUFnZo4xc9rtfcXzoJxw bjGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LRNtJun+/Ni6O8Shdi1f3wARhkyLxCUWqhu2svDUkQ4=; b=HoYPuXo/lZSS8pxi+kk7+b072+Y1BQw5NTONqOb+kRj3x5AZ/NbnUw7U2YVMjx4FUb 8tDF49UeVvdRdUcF05NMb8ifer9N1X/HzgNvOH7ZZ6MxHg5g3YZJpcHmlDVKJWDdfSY/ PnOSxeJo8f49eEMmTF/2dHnvqNcagA9iwIfDMSr62EbKuWI+ucO18b8xSd3BVvEZbzSh jXCoq78amakvIlELeXgQKdqHtdRPKy+JySV0H784SSkYWJtoqTnvJTBifkdAOdGYyZyg pgNpWxWc9CnzjKUuKfsjJ1Ei15toXvdAzM94DAO9NsTqSK1xTn2jLZZE30HQf7yxoFgN c0Vg== X-Gm-Message-State: AKaTC00C4iI/iq6nkvtj/CSdC1LVoU0m/vrLDbDRo8yEOUYQsCH9w7iLd0d5IzZ+b2okrqFD7cyDCRaFjtAOnw== X-Received: by 10.202.86.134 with SMTP id k128mr8728315oib.212.1480227649566; Sat, 26 Nov 2016 22:20:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.6.7 with HTTP; Sat, 26 Nov 2016 22:20:48 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Martin Duke Date: Sat, 26 Nov 2016 22:20:48 -0800 Message-ID: Subject: Re: Public reset PR To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113de2bc3d3e9a0542425bd3 Archived-At: Cc: Jim Roskind , IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 06:20:52 -0000 --001a113de2bc3d3e9a0542425bd3 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 26, 2016 at 9:39 PM, Eric Rescorla wrote: > On Sat, Nov 26, 2016 at 8:23 PM, Martin Duke > wrote: > >> As we've already established, an on-path forwarder can already block a >> connection by simply dropping packets. This is simply a cleaner way to >> handle it. >> > > I think the policy question is whether we wish to have a cleaner way to > handle it or whether we want to require on-path attackers to drop every > packet. > > Merely dropping packets seems *more* malicious than resetting, because it consumes more endpoint resources than it takes to drop the packets. The purpose of the reset is to allow "legitimate" middlebox connection droppers to free those resources while not enabling eavesdroppers or (of course) off-path DoS. > > >> What the timer does is address eavesdroppers. If I'm at the coffee shop >> with you, I can send unauthenticated Public Resets to try to terminate your >> connection, but if the real server responds within the timeout these resets >> will have no effect. This is a significant improvement on TCP, in my >> opinion. >> > > Unless I'm missing something, the mechanism I proposed earlier today > (having a secret per-connection reset token which you use in place of the > ciphertext) also addresses this problem: > > - No endpoint will accept a bogus public reset > - There is no externally visible signal of a public reset for innocent > middleboxes to process. > I guess I'm a little unclear as to the conditions of "the high entropy secret value R". Perhaps you could confirm the order of operations, which I construe as follows: 1) Endpoint computes a random secret for all connections for some period of time, and stores this somewhere that will survive reboots. 2) For a new connection, the endpoint performs some operation with the secret and the connection ID and includes the result R in an encrypted handshake message. 3) Endpoint reboots. 4) When the peer sends another packet, the endpoint uses the connection ID and its secret to figure R and make it the first 16 bytes of the cipher text. 5) Peer has the original connection state and can correctly interpret the reset. Is that accurate? > > > > > > > >> On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla wrote: >>>> >>>>> >>>>> >>>>> On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema < >>>>> huitema@huitema.net> wrote: >>>>> >>>>>> On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: >>>>>> >>>>>> > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema >>>>> huitema@huitema.net> wrote: >>>>>> >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: >>>>>> >>> >>>>>> >>> ... (discussion of security properties and alternative design)... >>>>>> >> >>>>>> >>> Note that it might still independently be a good idea to allow >>>>>> middleboxes to see the >>>>>> >>> public reset, but I think that this demonstrates that that's a >>>>>> policy choice about the >>>>>> >>> design of the protocol, not something mandated by limitations in >>>>>> what we can design. >>>>>> > >>>>>> >> On limit of the pre-image design is that intermediaries cannot do >>>>>> the verification. Well, >>>>>> >> they could if the option was sent in clear text, and if they >>>>>> parsed the corresponding packet. >>>>>> > >>>>>> > Yes, that's correct; it's the assumption of this design that the >>>>>> would do so. If you think that >>>>>> > they won't then there are much simpler designs (like the one in the >>>>>> message you are >>>>>> > responding to). >>>>>> >>>>>> Do we really want to ask intermediaries to go parse options inside >>>>>> the TLS handshake inside stream 1? That does not strike me as too >>>>>> desirable. I am concerned of the potential there for ossification. I have >>>>>> visions of delaying the move to TLS 4.1 a couple years from now because >>>>>> intermediaries really expect TLS 1.3. >>>>>> >>>>>> Then, there is the potential for spoofing. If the verifier text is >>>>>> sent in clear text, it can be spoofed. What if the man on the side sends a >>>>>> new Server Hello, with a verifier option of its own choosing? OK, I suppose >>>>>> that if the spoofed packet wins the race with the authentic Server Hello, >>>>>> the client will just fail the connection. The spoofed Server Hello becomes >>>>>> the new weapon of the censors... But even if the spoofed packet does not >>>>>> win the race, how many intermediaries would just be fooled and accept the >>>>>> new verifier, and of course the spoofed public reset that follows? >>>>>> >>>>> >>>>> Hmm... I would ordinarily expect that clients would respond to a bogus >>>>> CH (e.g., one that's malformed or that >>>>> doesn't cryptographically verify) by hanging up the connection, so I'm >>>>> not sure that this would make the situation >>>>> that much worse. >>>>> >>>>> >>>>> I like the simpler design in which only the client can tell whether >>>>>> the public reset is authentic. >>>>>> >>>>> >>>>> Well, there are actually two designs: >>>>> >>>>> 1. The middlebox can see the public reset but not verify it >>>>> 2. The middlebox cannot distinguish the public reset from other >>>>> packets. >>>>> >>>>> I am concerned about #1 for the reasons indicated previously and I >>>>> originally did not see how to do #2 >>>>> without fairly significant client-side complexity. Now that I do, it >>>>> does seem like it's probably the leading >>>>> option absent some convincing policy argument that middleboxes should >>>>> be able to see these packets. >>>>> >>>>> -Ekr >>>>> >>>>> >>>>>> >>>>>> -- Christian Huitema >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > --001a113de2bc3d3e9a0542425bd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 26, 2016 at 9:39 PM, Eric Rescorla <ekr@rtfm.com>= wrote:
On Sat, Nov 26, 2016 at 8:23 PM, Martin Duke <martin.h.duke@gma= il.com> wrote:
As we've already established, an on-path forwarder can al= ready block a connection by simply dropping packets. This is simply a clean= er way to handle it.

I think the policy question is whether we wish to have a cl= eaner way to handle it or whether we want to require on-path attackers to d= rop every packet.

<= /div>

Merely dropping packets seems <= i>more=C2=A0malicious than resetting, because it consumes more endpoint= resources than it takes to drop the packets. The purpose of the reset is t= o allow "legitimate" middlebox connection droppers to free those = resources while not enabling eavesdroppers or (of course) off-path DoS.
=C2=A0
=C2=A0
What the timer does is address eavesdroppers. If I= 9;m at the coffee shop with you, I can send unauthenticated Public Resets t= o try to terminate your connection, but if the real server responds within = the timeout these resets will have no effect. This is a significant improve= ment on TCP, in my opinion.

Unless I'm missing something, the mechanism I proposed = earlier today (having a secret per-connection reset token which you use in = place of the ciphertext) also addresses this problem:

<= div>- No endpoint will accept a bogus public reset
- There is no = externally visible signal of a public reset for innocent middleboxes to pro= cess.

I guess I'= ;m a little unclear as to the conditions of "the=C2=A0high entropy secret value R". Perhaps you could confi= rm the order of operations, which I construe as follows:
<= span style=3D"font-size:12.8px">
1) Endpoint computes a random secret for all connections for so= me period of time, and stores this somewhere that will survive reboots.
2) For a new connection, the= endpoint performs some operation with the secret and the connection ID and= includes the result R in an encrypted handshake message.
= 3) Endpoint reboots.
4) When the peer sends another packet, the end= point uses the connection ID and its secret to figure R and make it the fir= st 16 bytes of the cipher text.
5) Peer has the original connection state and can correctly interpre= t the reset.

<= /div>
Is that accurate?
=C2=A0


<= /div>



=C2=A0
=
On Sat, Nov 26, 2016 at 6= :23 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Sat, Nov 26, 2016 at 6:17 PM,= Christian Huitema <huitema@huitema.net> wrote:
On Saturday, November 26, 2016 3= :58 PM, Eric Rescorla wrote:

> On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema <mailto:huitema@huitema.net&g= t; wrote:
>> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote:
>>>
>>> ... (discussion of security properties and alternative design)= ...
>>
>>> Note that it might still independently be a good idea to allow= middleboxes to see the
>>> public reset, but I think that this demonstrates that that'= ;s a policy choice about the
>>> design of the protocol, not something mandated by limitations = in what we can design.
>
>> On limit of the pre-image design is that intermediaries cannot do = the verification. Well,
>> they could if the option was sent in clear text, and if they parse= d the corresponding packet.
>
> Yes, that's correct; it's the assumption of this design that t= he would do so. If you think that
> they won't then there are much simpler designs (like the one in th= e message you are
> responding to).

Do we really want to ask intermediaries to go parse options inside t= he TLS handshake inside stream 1? That does not strike me as too desirable.= I am concerned of the potential there for ossification. I have visions of = delaying the move to TLS 4.1 a couple years from now because intermediaries= really expect TLS 1.3.

Then, there is the potential for spoofing. If the verifier text is sent in = clear text, it can be spoofed. What if the man on the side sends a new Serv= er Hello, with a verifier option of its own choosing? OK, I suppose that if= the spoofed packet wins the race with the authentic Server Hello, the clie= nt will just fail the connection. The spoofed Server Hello becomes the new = weapon of the censors... But even if the spoofed packet does not win the ra= ce, how many intermediaries would just be fooled and accept the new verifie= r, and of course the spoofed public reset that follows?

Hmm... I would ordinarily expect that clients would= respond to a bogus CH (e.g., one that's malformed or that
do= esn't cryptographically verify) by hanging up the connection, so I'= m not sure that this would make the situation
that much worse.


I like the simpler design in which only the client can tell whether the pub= lic reset is authentic.

Well, th= ere are actually two designs:

1. The middlebox can= see the public reset but not verify it
2. The middlebox cannot d= istinguish the public reset from other packets.

I = am concerned about #1 for the reasons indicated previously and I originally= did not see how to do #2
without fairly significant client-side = complexity. Now that I do, it does seem like it's probably the leading<= /div>
option absent some convincing policy argument that middleboxes sh= ould be able to see these packets.

-Ekr
= =C2=A0

-- Christian Huitema









--001a113de2bc3d3e9a0542425bd3-- From nobody Sun Nov 27 06:13:03 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16888129490 for ; Sun, 27 Nov 2016 06:13: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 Q_fbpvbPVprr for ; Sun, 27 Nov 2016 06:13:00 -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 83CEE1293D9 for ; Sun, 27 Nov 2016 06:13:00 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id i145so96284269ywg.2 for ; Sun, 27 Nov 2016 06:13: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=N6+q1WTWF85gZBcbb4sZ58f7HxC88LyxBqOzQeiI2wc=; b=v1cWsEMTyJVaVQyxBQCC6ehVseCL3HcvO1DNXhy3/CEL9mQdEQr4MYOib5/jNIe0X7 6wmcREKSCzHJcXallT6hresU6dNIRccnO3VwsLZCbBHhefNpQq+E2HV+YV/JGFBbc8fc s4uaEAQA+4FAPh22FUwVcKNS+bG2DfuyRfGrySwqpuwznsPIsphvOMslKFep8J0Q43Hh 8CLSMNz1o8Z43Ywb0pFN7mzAla8+Wl7Hg6JUmDxrLacxiOsFFAl6WPKvZoOZNrNKezT5 ELKaz2s4VGrIxa69Omrpaq8HRpBvYndpUJn0QEhZHjJAD07dHzX/lXbYQZ1rmttEwCU+ o9Bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N6+q1WTWF85gZBcbb4sZ58f7HxC88LyxBqOzQeiI2wc=; b=J32DuYMgzN/Sz7AMDxJg80BYEnZ+2ISMzQnMx15Mu4ZPkUizra/JgBOEYMnjGEzou4 mbBncFoeutC/pAN76p4SNckipj8vaUgbBAqglveYcrLdQGq3R8NWf1Xmhi4x9UhX2h7h A/VAviKMU4ttd82BPjPd7OMOKr+ZqlfxKy3E4EyonxLTLlKRDkS9sgpS28lAVmns9K3Z qcYm3T2XjkIbPVPjSSg9+BbSHepo1wCVuQQKCrUEFXTzPzWcqm37HtO9KxfPLL+NZFPO 6UUzsX0vb7CworNx7nfOKiCBGe5P6GbG9aqMYfkfP/LyNB24c+NcbgZFqM1dE+I4GMZj 6zDQ== X-Gm-Message-State: AKaTC00EFTh0Tl4pZDTXBz28ycJ61tauSthQAm0QYBJDU7SjazE1baTE21/ZZKedgnmEhM5kCjYatl800DBumg== X-Received: by 10.129.108.216 with SMTP id h207mr21391487ywc.52.1480255979797; Sun, 27 Nov 2016 06:12:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sun, 27 Nov 2016 06:12:19 -0800 (PST) In-Reply-To: References: <0f0d01d2484d$e91d0300$bb570900$@huitema.net> <0f4601d24854$6eca9a70$4c5fcf50$@huitema.net> From: Eric Rescorla Date: Sun, 27 Nov 2016 06:12:19 -0800 Message-ID: Subject: Re: Public reset PR To: Martin Duke Content-Type: multipart/alternative; boundary=001a114dd36eda7641054248f398 Archived-At: Cc: Jim Roskind , IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-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, 27 Nov 2016 14:13:02 -0000 --001a114dd36eda7641054248f398 Content-Type: text/plain; charset=UTF-8 On Sat, Nov 26, 2016 at 10:20 PM, Martin Duke wrote: > > > On Sat, Nov 26, 2016 at 9:39 PM, Eric Rescorla wrote: > >> On Sat, Nov 26, 2016 at 8:23 PM, Martin Duke >> wrote: >> >>> As we've already established, an on-path forwarder can already block a >>> connection by simply dropping packets. This is simply a cleaner way to >>> handle it. >>> >> >> I think the policy question is whether we wish to have a cleaner way to >> handle it or whether we want to require on-path attackers to drop every >> packet. >> >> > Merely dropping packets seems *more* malicious than resetting, because it > consumes more endpoint resources than it takes to drop the packets. The > purpose of the reset is to allow "legitimate" middlebox connection droppers > to free those resources while not enabling eavesdroppers or (of course) > off-path DoS. > There is some debate about whether we in fact wish to have such a mechanism. > What the timer does is address eavesdroppers. If I'm at the coffee shop >>> with you, I can send unauthenticated Public Resets to try to terminate your >>> connection, but if the real server responds within the timeout these resets >>> will have no effect. This is a significant improvement on TCP, in my >>> opinion. >>> >> >> Unless I'm missing something, the mechanism I proposed earlier today >> (having a secret per-connection reset token which you use in place of the >> ciphertext) also addresses this problem: >> >> - No endpoint will accept a bogus public reset >> - There is no externally visible signal of a public reset for innocent >> middleboxes to process. >> > > I guess I'm a little unclear as to the conditions of "the high entropy > secret value R". Perhaps you could confirm the order of operations, which I > construe as follows: > > 1) Endpoint computes a random secret for all connections for some period > of time, and stores this somewhere that will survive reboots. > 2) For a new connection, the endpoint performs some operation with the > secret and the connection ID and includes the result R in an encrypted > handshake message. > 3) Endpoint reboots. > 4) When the peer sends another packet, the endpoint uses the connection ID > and its secret to figure R and make it the first 16 bytes of the cipher > text. > 5) Peer has the original connection state and can correctly interpret the > reset. > > Is that accurate? > Yes. -Ekr > > >> >> >> >> >> >> >> >>> On Sat, Nov 26, 2016 at 6:23 PM, Eric Rescorla wrote: >>>>> >>>>>> >>>>>> >>>>>> On Sat, Nov 26, 2016 at 6:17 PM, Christian Huitema < >>>>>> huitema@huitema.net> wrote: >>>>>> >>>>>>> On Saturday, November 26, 2016 3:58 PM, Eric Rescorla wrote: >>>>>>> >>>>>>> > On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema >>>>>> huitema@huitema.net> wrote: >>>>>>> >> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote: >>>>>>> >>> >>>>>>> >>> ... (discussion of security properties and alternative design)... >>>>>>> >> >>>>>>> >>> Note that it might still independently be a good idea to allow >>>>>>> middleboxes to see the >>>>>>> >>> public reset, but I think that this demonstrates that that's a >>>>>>> policy choice about the >>>>>>> >>> design of the protocol, not something mandated by limitations in >>>>>>> what we can design. >>>>>>> > >>>>>>> >> On limit of the pre-image design is that intermediaries cannot do >>>>>>> the verification. Well, >>>>>>> >> they could if the option was sent in clear text, and if they >>>>>>> parsed the corresponding packet. >>>>>>> > >>>>>>> > Yes, that's correct; it's the assumption of this design that the >>>>>>> would do so. If you think that >>>>>>> > they won't then there are much simpler designs (like the one in >>>>>>> the message you are >>>>>>> > responding to). >>>>>>> >>>>>>> Do we really want to ask intermediaries to go parse options inside >>>>>>> the TLS handshake inside stream 1? That does not strike me as too >>>>>>> desirable. I am concerned of the potential there for ossification. I have >>>>>>> visions of delaying the move to TLS 4.1 a couple years from now because >>>>>>> intermediaries really expect TLS 1.3. >>>>>>> >>>>>>> Then, there is the potential for spoofing. If the verifier text is >>>>>>> sent in clear text, it can be spoofed. What if the man on the side sends a >>>>>>> new Server Hello, with a verifier option of its own choosing? OK, I suppose >>>>>>> that if the spoofed packet wins the race with the authentic Server Hello, >>>>>>> the client will just fail the connection. The spoofed Server Hello becomes >>>>>>> the new weapon of the censors... But even if the spoofed packet does not >>>>>>> win the race, how many intermediaries would just be fooled and accept the >>>>>>> new verifier, and of course the spoofed public reset that follows? >>>>>>> >>>>>> >>>>>> Hmm... I would ordinarily expect that clients would respond to a >>>>>> bogus CH (e.g., one that's malformed or that >>>>>> doesn't cryptographically verify) by hanging up the connection, so >>>>>> I'm not sure that this would make the situation >>>>>> that much worse. >>>>>> >>>>>> >>>>>> I like the simpler design in which only the client can tell whether >>>>>>> the public reset is authentic. >>>>>>> >>>>>> >>>>>> Well, there are actually two designs: >>>>>> >>>>>> 1. The middlebox can see the public reset but not verify it >>>>>> 2. The middlebox cannot distinguish the public reset from other >>>>>> packets. >>>>>> >>>>>> I am concerned about #1 for the reasons indicated previously and I >>>>>> originally did not see how to do #2 >>>>>> without fairly significant client-side complexity. Now that I do, it >>>>>> does seem like it's probably the leading >>>>>> option absent some convincing policy argument that middleboxes should >>>>>> be able to see these packets. >>>>>> >>>>>> -Ekr >>>>>> >>>>>> >>>>>>> >>>>>>> -- Christian Huitema >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > --001a114dd36eda7641054248f398 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Nov 26, 2016 at 10:20 PM, Martin Duke <martin.h.duke@gma= il.com> wrote:


On Sat, Nov 26, 2016 at 9:39 PM, Eric Rescorla &= lt;ekr@rtfm.com> wrote:
On Sat, Nov 26, 2016 at 8:23 PM, Martin D= uke <martin.h.duke@gmail.com> wrote:
As we've already established= , an on-path forwarder can already block a connection by simply dropping pa= ckets. This is simply a cleaner way to handle it.
<= /div>

I think the policy question is= whether we wish to have a cleaner way to handle it or whether we want to r= equire on-path attackers to drop every packet.

=

Merely dropping packets seems more=C2=A0m= alicious than resetting, because it consumes more endpoint resources than i= t takes to drop the packets. The purpose of the reset is to allow "leg= itimate" middlebox connection droppers to free those resources while n= ot enabling eavesdroppers or (of course) off-path DoS.

There is some debate about whether we i= n fact wish to have such a mechanism.


=C2=A0
What the timer does = is address eavesdroppers. If I'm at the coffee shop with you, I can sen= d unauthenticated Public Resets to try to terminate your connection, but if= the real server responds within the timeout these resets will have no effe= ct. This is a significant improvement on TCP, in my opinion.

Unless I'm missing som= ething, the mechanism I proposed earlier today (having a secret per-connect= ion reset token which you use in place of the ciphertext) also addresses th= is problem:

- No endpoint will accept a bogus publ= ic reset
- There is no externally visible signal of a public rese= t for innocent middleboxes to process.
=

I guess I'm a little unclear as to the condi= tions of "the=C2=A0high entropy secre= t value R". Perhaps you could confirm the order of operations, which I= construe as follows:
1) Endpoint computes a = random secret for all connections for some period of time, and stores this = somewhere that will survive reboots.
2) For a new connection, the endpoint performs some operation w= ith the secret and the connection ID and includes the result R in an encryp= ted handshake message.
3)= Endpoint reboots.
4) Whe= n the peer sends another packet, the endpoint uses the connection ID and it= s secret to figure R and make it the first 16 bytes of the cipher text.
5) Peer has the original con= nection state and can correctly interpret the reset.

Is that accurate?

Yes.

<= div>-Ekr
=C2=A0
=C2=A0
=





=C2=A0
On Sat, Nov 26,= 2016 at 6:23 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Sat, Nov 26, 2016 = at 6:17 PM, Christian Huitema <huitema@huitema.net> wrote:=
On Saturday, November= 26, 2016 3:58 PM, Eric Rescorla wrote:

> On Sat, Nov 26, 2016 at 5:30 PM, Christian Huitema <mailto:huitema@huitema.net&g= t; wrote:
>> On Saturday, November 26, 2016 9:10 AM, Eric Rescorla wrote:
>>>
>>> ... (discussion of security properties and alternative design)= ...
>>
>>> Note that it might still independently be a good idea to allow= middleboxes to see the
>>> public reset, but I think that this demonstrates that that'= ;s a policy choice about the
>>> design of the protocol, not something mandated by limitations = in what we can design.
>
>> On limit of the pre-image design is that intermediaries cannot do = the verification. Well,
>> they could if the option was sent in clear text, and if they parse= d the corresponding packet.
>
> Yes, that's correct; it's the assumption of this design that t= he would do so. If you think that
> they won't then there are much simpler designs (like the one in th= e message you are
> responding to).

Do we really want to ask intermediaries to go parse options inside t= he TLS handshake inside stream 1? That does not strike me as too desirable.= I am concerned of the potential there for ossification. I have visions of = delaying the move to TLS 4.1 a couple years from now because intermediaries= really expect TLS 1.3.

Then, there is the potential for spoofing. If the verifier text is sent in = clear text, it can be spoofed. What if the man on the side sends a new Serv= er Hello, with a verifier option of its own choosing? OK, I suppose that if= the spoofed packet wins the race with the authentic Server Hello, the clie= nt will just fail the connection. The spoofed Server Hello becomes the new = weapon of the censors... But even if the spoofed packet does not win the ra= ce, how many intermediaries would just be fooled and accept the new verifie= r, and of course the spoofed public reset that follows?

Hmm... I would ordinarily expect that clients would= respond to a bogus CH (e.g., one that's malformed or that
do= esn't cryptographically verify) by hanging up the connection, so I'= m not sure that this would make the situation
that much worse.


I like the simpler design in which only the client can tell whether the pub= lic reset is authentic.

Well, th= ere are actually two designs:

1. The middlebox can= see the public reset but not verify it
2. The middlebox cannot d= istinguish the public reset from other packets.

I = am concerned about #1 for the reasons indicated previously and I originally= did not see how to do #2
without fairly significant client-side = complexity. Now that I do, it does seem like it's probably the leading<= /div>
option absent some convincing policy argument that middleboxes sh= ould be able to see these packets.

-Ekr
= =C2=A0

-- Christian Huitema