From nobody Fri Jul 1 02:19: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 1375012D513 for ; Fri, 1 Jul 2016 02:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 GPCOvMv8CpWn for ; Fri, 1 Jul 2016 02:19:43 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4612612D512 for ; Fri, 1 Jul 2016 02:19:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,556,1459839600"; d="asc'?scan'208,217";a="120685886" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 01 Jul 2016 02:18:40 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 1 Jul 2016 02:18:37 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Fri, 1 Jul 2016 02:18:37 -0700 From: "Eggert, Lars" To: Ted Hardie Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0qC2EnDpyDuvnE+IfLnz6AoxiKACO70AgABHNQCAACe0AIABGIsA Date: Fri, 1 Jul 2016 09:18:36 +0000 Message-ID: References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.34] Content-Type: multipart/signed; boundary="Apple-Mail=_63F7E163-E42B-4C58-B9F3-AC7C3993D3C2"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: Brian Trammell , "quic@ietf.org" , "DRUTA, DAN" Subject: Re: [QUIC] Network Path Requirements for QUIC 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: Fri, 01 Jul 2016 09:19:45 -0000 --Apple-Mail=_63F7E163-E42B-4C58-B9F3-AC7C3993D3C2 Content-Type: multipart/alternative; boundary="Apple-Mail=_CC302C3E-88F3-45CA-8302-F9BCC58E2F37" --Apple-Mail=_CC302C3E-88F3-45CA-8302-F9BCC58E2F37 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2016-06-30, at 18:34, Ted Hardie wrote: >=20 > On Thu, Jun 30, 2016 at 7:12 AM, Eggert, Lars > wrote: > (And - pet peeve - there is really no need for binding timeouts for = TCP or UDP to begin with. No binding needs to be timed out until the = middlebox runs out of memory, because as long as there are sufficient = resources, why bother managing all these timeouts? ) >=20 > If I understand this correctly, this is largely because many of these = are NAT+FW boxes which combine the binding and the firewall permission; = leaving them up for long periods of time leaves the pinhole up. If you = really relied on state exhaustion, it might never happen at all for = small networks. Eliminating the firewall permission to receive traffic = and leaving the binding to send would be odd, so they don't. Well, they could leave the binding up and check whether inbound traffic = after idle still elicits response traffic. But I think I took us down = the rathole of building a better mousetrap (how's that for an analogy = :-) Lars >=20 > Joe H. might well be able to get you better and fersher data, but = that's why I think the timers were put in in the first place. >=20 > Ted >=20 >=20 >=20 >=20 --Apple-Mail=_CC302C3E-88F3-45CA-8302-F9BCC58E2F37 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On 2016-06-30, at 18:34, Ted Hardie <ted.ietf@gmail.com> = wrote:

On Thu, Jun 30, 2016 at 7:12 AM, = Eggert, Lars <lars@netapp.com> wrote:
(And - pet peeve - there is really no need for = binding timeouts for TCP or UDP to begin with. No binding needs to be = timed out until the middlebox runs out of memory, because as long as = there are sufficient resources, why bother managing all these timeouts? = <snip>)

If I understand this correctly, this is largely = because many of  these are NAT+FW boxes which combine the binding = and the firewall permission; leaving them up for long periods of time = leaves the pinhole up.  If you really relied on state exhaustion, = it might never happen at all for small networks.  Eliminating the = firewall permission to receive traffic and leaving the binding to send = would be odd, so they don't.

Well, they could leave the binding up and check = whether inbound traffic after idle still elicits response traffic. But I = think I took us down the rathole of building a better mousetrap (how's = that for an analogy :-)

Lars


Joe H. might well be able to = get you better and fersher data, but that's why I think the timers were = put in in the first place.

Ted





= --Apple-Mail=_CC302C3E-88F3-45CA-8302-F9BCC58E2F37-- --Apple-Mail=_63F7E163-E42B-4C58-B9F3-AC7C3993D3C2 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----- iQIcBAEBCAAGBQJXdjVvAAoJEFS1wwm/cMFXMhAP/Arp58YXaix74igKATbwAV/m uzgwIC0Lkivsq0u49sOiYKeUm+91mU+CLi6P3g2kTqgs8XdeqStbqNsNgktT3ukD 2540v6uTnlxfkDPCXw24nCIsk15O7FQC90cRzZTJ31XM5iX/KihQGhAifp8Jbhk7 0f0RqsdvRqoXY34YXzHwaW0vREp7ufhRDaxqZz+Dl7T8cVB4zaT13WCuht07av6T s2zqK3ScXtXt/Zz7hyW40fs19spM1bjhvr1c6hzqYYGht12ktcUXZ0hhkUjTOtXL GRKSUcSJiS6bTzPjH/hdky0MWk+kZAa5Fpadjk3V4C7LhMw2mZRST9iUzIpHA129 kUFV+JwIGHBq2aOzEtXkyC1Hrz8mIv8rsSoN/rAtls2ntBJuqT+Eo9XJaSIDwuE+ 8OFdAeyqVl5WMfELD0/jfwavsPchklwkqaoVkXBskTtFehNBst+Z4dqTohqVABxa D+eEMPvB4OPML9RqybqFXCh2/91jz+3GXkjzUC4diXD5s/gY8yJQp2IdXWMB+G7K lnxv2xdbjms8nUMQw7be+TmW8nUM+q7T+SyFJFvV7JU9t5Uqx/9fUEH0kLzjXJx5 m4NpHnhBDq8/JNsZCf7VSCBCuojVHHrNg7PLanI8ozWlhOJBEqHNaWbojQ1DWny4 bSCx5Wk14BNANxvhTb3v =SZO6 -----END PGP SIGNATURE----- --Apple-Mail=_63F7E163-E42B-4C58-B9F3-AC7C3993D3C2-- From nobody Fri Jul 1 04:19: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 AEE3412B041 for ; Fri, 1 Jul 2016 04:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.347 X-Spam-Level: X-Spam-Status: No, score=-8.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 1Oh0YQlUM-OR for ; Fri, 1 Jul 2016 04:19:35 -0700 (PDT) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AD6912D0F0 for ; Fri, 1 Jul 2016 04:19:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.26,556,1459839600"; d="asc'?scan'208";a="120700762" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx142-out.netapp.com with ESMTP; 01 Jul 2016 04:18:58 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Fri, 1 Jul 2016 04:18:54 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::837:3f3:c8b1:8d6f%21]) with mapi id 15.00.1156.000; Fri, 1 Jul 2016 04:18:54 -0700 From: "Eggert, Lars" To: "Joe Hildebrand (jhildebr)" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0qC2EnDpyDuvnE+IfLnz6AoxiKACO70AgABHNQCAAAltAIAACdSAgAAWzgCAATfLgA== Date: Fri, 1 Jul 2016 11:18:53 +0000 Message-ID: References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> <826872D6-FB13-499D-B134-EB5005DE9ACA@cisco.com> In-Reply-To: <826872D6-FB13-499D-B134-EB5005DE9ACA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.37] Content-Type: multipart/signed; boundary="Apple-Mail=_4B9C8921-C402-438D-8F4C-E67F3935E500"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , Brian Trammell Subject: Re: [QUIC] Network Path Requirements for QUIC 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: Fri, 01 Jul 2016 11:19:38 -0000 --Apple-Mail=_4B9C8921-C402-438D-8F4C-E67F3935E500 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2016-06-30, at 18:42, Joe Hildebrand (jhildebr) = wrote: > On Jun 30, 2016, at 9:21 AM, Eggert, Lars wrote: >> On 2016-06-30, at 16:46, DRUTA, DAN wrote: >>> What's important is to understand and capture the reasons why IT = Administrators are blocking UDP. Some are as you pointed out not related = to the technology but we need to make sure they get the right level of = manageability with QUIC in order troubleshooting legitimate traffic and = prevent attacks. >>=20 >> again: why? We're talking about less than 10% of the paths, and HTTPS = over TCP readily available as an alternative on those paths, supposedly = with all the manageability that IT admins need. >=20 > We're talking about less than 10% of the paths that were measured by = one experiment. I don't yet know how reproducible that is. fair point. I hope we hear from Akamai and others who are experimenting = with QUIC currently. > Again, it's 100% of the flows on my network, and on that of many = other enterprise networks where I have deployed software in the past. I don't debate that - you're part of the less-than-10% though. > I guarantee that we will deploy new software for our firewall if it's = possible to do so in a way that we don't have to update for every = newly-popular version number that someone in the QUIC world decides to = deploy. That's both encouraging and discouraging. Encouraging, because better = software is better. Discouraging because one of the stated strong points = of QUIC is rapid deployment of improved versions, and limiting future = evolvability of part of the protocol because "corporate middleboxes need = to do stuff" isn't a really good starter here. > Mostly, I would like to see the assumptions that folks are making = about how the path might interact with the bits that are already = explicitly exposed to the path by the current protocol be discussed, = then written down. I'm with you on that. Writing down assumptions makes design decisions = clearer. >=20 >> I'd be open to the WG reviewing concrete proposals someone may have = in this space once the WG is underway, but I wouldn't want to see = charter text making it a requirement for QUIC to do anything about such = paths, since we really don't know what fulfilling this requirement may = actually entail. >=20 > Brian's proposed text here: >=20 > https://github.com/IETF-QUIC/Charter/pull/14/files >=20 > says "This work will consider deployability, manageability and = diagnosability of the wire format, including how the wire format will be = processed by devices on path". I don't think that makes doing anything = for the path required, but it does make it possible to have the = conversation. If we're worried about this language requiring changes to = the protocol, rather than allowing for the conversation, we can of = course continue to tweak the language. That's at least my personal worry - that text is pretty broad. I'd be = happier with a statement along the lines you stated above, i.e., that = the WG may document assumptions about how boxes along the path might = interact with exposed protocol information. That - to me - makes it = clearer that it isn't a goal to make protocol changes in the hopes of = making it comply with whatever enterprise IT admins may define as = policy, based on the knobs their middlebox software is at the moment = exposing. > =46rom a previous message of yours: >=20 >> And - pet peeve - there is really no need for binding timeouts for = TCP or UDP to begin with. No binding needs to be timed out until the = middlebox runs out of memory, because as long as there are sufficient = resources, why bother managing all these timeouts? >=20 > One of the reasons people give for this is the concern that traffic = will be allowed in from the outside to boxes and applications that are = no longer expecting the traffic. Since they believe that many older UDP = protocols don't have adequate security measures in place to = authenticate, authorize, or sessionize traffic, they just block it all = except for the protocols where they do deeper inspection, such as DNS. = It is not because these administrators are idiots, or because they have = misconfigured their boxes unintentionally. I didn't mean to imply that - they use the knobs they have. But there = are other ways to mitigate the attack surface here, such as rate = limiting inbound traffic on idle bindings, only fully activating idle = bindings after outbound traffic indicates an active listener, etc. > Many of the folks that block UDP *do* update their firewall software = often, and do review their security stance on blocked protocols = periodically. They will want their users to be able to take advantage = of the benefits of QUIC, so they will have incentives to do the review. = We need to at least provide them with the tools to do this review, such = as security considerations that tell an administrator how to continue to = protect their network from unknown UDP protocols while allowing QUIC. But "we need to at least provide the tools" again sounds like the intent = here is that QUIC will need to change to satisfy some currently = under-defined requirements, rather than documenting assumptions about = how boxes along the path might interact with exposed protocol = information (my attempt to summarize what you wrote above). Personally, I'd like to understand in much more detail what these "tools = to do this review" are and how they would change the current QUIC = protocol, before I'd feel comfortable adding this to the charter as = anything more than a thought experiment the WG may undertake (and, do we = really need this in the charter? WGs can always discuss work related to = their chartered work). Once we have some clarity here - maybe also = because PLUS will have gotten chartered and we've gained some = understanding through that effort - a future version of QUIC could = decide to incorporate those changes. Lars --Apple-Mail=_4B9C8921-C402-438D-8F4C-E67F3935E500 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----- iQIcBAEBCAAGBQJXdlGgAAoJEFS1wwm/cMFXuTsP/0NRAU/RdQHpPekajq6oHs25 MmJbmw/oBVCtLwZn7XWRUka0yCUruqMoz6DVTghnbTVA/rkPuATRNrMs04+csKBw rqX5osYmp89CMqerkYYZ8+gc+MKF+7CFJtpjCVr3R/WvP3R9XTZz46P5PZAWIfHD dr9OseHWlNrSgciZwZIB2eEEd2aKutbpnfYgUr/+Ajv29NsjMx3aXlBzchl/+WEi 0FX9T5I1/nICSrTXnxy4nmd7QY1J6y5xY4v5rbcIq1SP7CgBU7qZIPOA09uDLJfQ ZiVD34vB8ZKJLJNjxUiZ1sf5T1jgsoyCkttHrSOtApWTwcLQqlun/23vjONnHW/c dC3fjPvIxTSbWvCzCKCEe395XYDUS7JFPJ4LKa+1XtRmklMDbe+QNd8R0uGed/r2 8m6OInpSA1JRjOczT8vqyJXtQ/FIjxkx1HKqaTLREOevfkh33ZIQ5+MWwcP8GMTJ FCx5bCtYfa9I31hj6r1ETj250ADtVNMELlmhqu2Lt1h5LPjMTd8rU96sIh3HKKwj rNyOPxqtyPYruGzGBKj5fNnBeAKfo4RCYh3/uQefvxUblToJO8w3/ihbcsR/XnHt o7hfDTIVntP9uXiEukNjIOX3Iz7lsAG2msMOkx8xMYEk1C6cWfOKtex2ZUOmdxaF +UnqPzKoMNOVMfSBURll =Ilba -----END PGP SIGNATURE----- --Apple-Mail=_4B9C8921-C402-438D-8F4C-E67F3935E500-- From nobody Fri Jul 1 05:52: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 0D07412D5C3 for ; Fri, 1 Jul 2016 05:52:10 -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 3ono--e4HGKb for ; Fri, 1 Jul 2016 05:52:06 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD1112D5BC for ; Fri, 1 Jul 2016 05:52:05 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id j2so145243632qkf.3 for ; Fri, 01 Jul 2016 05:52:05 -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=slL8SVqLTtrjFtYYnihLH5sbHK6y6bIgHdoLgH+lTEo=; b=PF5Ylt5i47TuZtBDZ7MYoEd2j7V5C42t+Ez+uvyNB3hzNqYuYZW6F6yCUc1PQ7jADy z/Hf0EZNY0ICiZjA0WP8BA3JgnzIIXu33zWRnqKDjyAvNnLtTHupLut1omikVDioyoj4 L8dsnTuXZEISNSZYxqHWYt+kdL6oXl8LEOc9AWKBGJJhvnTFZnhJv67aySS+pbjy5dNR DLpHinyVk5YCaOs7Ha95KxLvscOLsfS/35OOyEcpEM85tQN1gvXsl9DO6trOA1ssDOjl JMo152kSDSASZjxJPNwXzLUeUqBdFbOQHE7uHrGdIQx0Xj3XB2+OoFqYq9Q/eG7iD2lI 9blQ== 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=slL8SVqLTtrjFtYYnihLH5sbHK6y6bIgHdoLgH+lTEo=; b=ZNVxHkThsqJYdxXvBLpyS0TwAlFvFqPSV74OURuZFULf6fpeO2MxOIAOyeRPMdXqjg 7fpoDX4iYDAtUEiq5zacoyxA2b2NLl1ShVWeBq+DGnz86qd8tv7gSHiL3p5bu7Lh+rY7 CmJHTdJYczupmJHYPfZSZT8hs3G9GO7KGd2VS6L+ecuBZFKknXbPEH2074PxHEzAm+SS 1QaEkySFnN95LHeZivhpMGNfnBefl4yde3zEYuOZPHkuTO3T7oZddqLL7pk1ajwutMq0 OUb44EbyDKeFQ+XXjwHVXDY6VeWr9dyQvAm3jkjx4HoJAl9dQRmsutFhuHLLAQVHs/ds qUFw== X-Gm-Message-State: ALyK8tJsPwsORubbeO9yUSBtQg7zVwwu8cftYiDl/RGO8wFzpmaIUq7uqPBNoceXcUlIXQondFYS/ACgdAYxBQ== X-Received: by 10.37.123.6 with SMTP id w6mr9165114ybc.90.1467377524900; Fri, 01 Jul 2016 05:52:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.125.134 with HTTP; Fri, 1 Jul 2016 05:52:04 -0700 (PDT) In-Reply-To: References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> <826872D6-FB13-499D-B134-EB5005DE9ACA@cisco.com> From: Spencer Dawkins at IETF Date: Fri, 1 Jul 2016 07:52:04 -0500 Message-ID: To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=001a114e1a3c1f8ca50536927481 Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , "Joe Hildebrand \(jhildebr\)" , Brian Trammell Subject: Re: [QUIC] Network Path Requirements for QUIC 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: Fri, 01 Jul 2016 12:52:10 -0000 --001a114e1a3c1f8ca50536927481 Content-Type: text/plain; charset=UTF-8 So, I'm not typing much, as folks prepare for the BOF, but I am current on what other people are typing ... so, a couple of questions ... On Fri, Jul 1, 2016 at 6:18 AM, Eggert, Lars wrote: > Hi, > > > On 2016-06-30, at 18:42, Joe Hildebrand (jhildebr) > wrote: > > On Jun 30, 2016, at 9:21 AM, Eggert, Lars wrote: > >> On 2016-06-30, at 16:46, DRUTA, DAN wrote: > >>> What's important is to understand and capture the reasons why IT > Administrators are blocking UDP. Some are as you pointed out not related to > the technology but we need to make sure they get the right level of > manageability with QUIC in order troubleshooting legitimate traffic and > prevent attacks. > >> > >> again: why? We're talking about less than 10% of the paths, and HTTPS > over TCP readily available as an alternative on those paths, supposedly > with all the manageability that IT admins need. > > > > We're talking about less than 10% of the paths that were measured by one > experiment. I don't yet know how reproducible that is. > > fair point. I hope we hear from Akamai and others who are experimenting > with QUIC currently. > > > Again, it's 100% of the flows on my network, and on that of many other > enterprise networks where I have deployed software in the past. > > I don't debate that - you're part of the less-than-10% though. > > > I guarantee that we will deploy new software for our firewall if it's > possible to do so in a way that we don't have to update for every > newly-popular version number that someone in the QUIC world decides to > deploy. > > That's both encouraging and discouraging. Encouraging, because better > software is better. Discouraging because one of the stated strong points of > QUIC is rapid deployment of improved versions, and limiting future > evolvability of part of the protocol because "corporate middleboxes need to > do stuff" isn't a really good starter here. One of the reasons I was given for not just sending QUIC to the ISE so there's an RFC that describes what's deployed, was the desire to support new functionality without bumping a protocol version number (an easy way to evolve the protocol when you control the QUIC implementation at both endpoints and centralize software development, but one that doesn't scale to support evolving protocols the way we do that, at IETF). The current charter talks about both versioning and option negotiation. I had assumed, perhaps incorrectly, that most experimentation would make use of option negotiation, and bumping the version number would be possible, but relatively rare. The first two extensions I saw proposed were multipath and FEC, and I understood both of those to be possible to implement using option negotiation. Am I misunderstanding what the intention is here? Thanks, Spencer > > Mostly, I would like to see the assumptions that folks are making about > how the path might interact with the bits that are already explicitly > exposed to the path by the current protocol be discussed, then written down. > > I'm with you on that. Writing down assumptions makes design decisions > clearer. > > > > >> I'd be open to the WG reviewing concrete proposals someone may have in > this space once the WG is underway, but I wouldn't want to see charter text > making it a requirement for QUIC to do anything about such paths, since we > really don't know what fulfilling this requirement may actually entail. > > > > Brian's proposed text here: > > > > https://github.com/IETF-QUIC/Charter/pull/14/files > > > > says "This work will consider deployability, manageability and > diagnosability of the wire format, including how the wire format will be > processed by devices on path". I don't think that makes doing anything for > the path required, but it does make it possible to have the conversation. > If we're worried about this language requiring changes to the protocol, > rather than allowing for the conversation, we can of course continue to > tweak the language. > > That's at least my personal worry - that text is pretty broad. I'd be > happier with a statement along the lines you stated above, i.e., that the > WG may document assumptions about how boxes along the path might interact > with exposed protocol information. That - to me - makes it clearer that it > isn't a goal to make protocol changes in the hopes of making it comply with > whatever enterprise IT admins may define as policy, based on the knobs > their middlebox software is at the moment exposing. > > > From a previous message of yours: > > > >> And - pet peeve - there is really no need for binding timeouts for TCP > or UDP to begin with. No binding needs to be timed out until the middlebox > runs out of memory, because as long as there are sufficient resources, why > bother managing all these timeouts? > > > > One of the reasons people give for this is the concern that traffic will > be allowed in from the outside to boxes and applications that are no longer > expecting the traffic. Since they believe that many older UDP protocols > don't have adequate security measures in place to authenticate, authorize, > or sessionize traffic, they just block it all except for the protocols > where they do deeper inspection, such as DNS. It is not because these > administrators are idiots, or because they have misconfigured their boxes > unintentionally. > > I didn't mean to imply that - they use the knobs they have. But there are > other ways to mitigate the attack surface here, such as rate limiting > inbound traffic on idle bindings, only fully activating idle bindings after > outbound traffic indicates an active listener, etc. > > > Many of the folks that block UDP *do* update their firewall software > often, and do review their security stance on blocked protocols > periodically. They will want their users to be able to take advantage of > the benefits of QUIC, so they will have incentives to do the review. We > need to at least provide them with the tools to do this review, such as > security considerations that tell an administrator how to continue to > protect their network from unknown UDP protocols while allowing QUIC. > > But "we need to at least provide the tools" again sounds like the intent > here is that QUIC will need to change to satisfy some currently > under-defined requirements, rather than documenting assumptions about how > boxes along the path might interact with exposed protocol information (my > attempt to summarize what you wrote above). > > Personally, I'd like to understand in much more detail what these "tools > to do this review" are and how they would change the current QUIC protocol, > before I'd feel comfortable adding this to the charter as anything more > than a thought experiment the WG may undertake (and, do we really need this > in the charter? WGs can always discuss work related to their chartered > work). Once we have some clarity here - maybe also because PLUS will have > gotten chartered and we've gained some understanding through that effort - > a future version of QUIC could decide to incorporate those changes. > > Lars > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --001a114e1a3c1f8ca50536927481 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So, I'm not typing much, as folks prepare for the BOF,= but I am current on what other people are typing ... so, a couple of quest= ions ...

On Fri, J= ul 1, 2016 at 6:18 AM, Eggert, Lars <lars@netapp.com> wrote:
Hi,


On 2016-06-30, at 18:42, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
> On Jun 30, 2016, at 9:21 AM, Eggert, Lars <lars@netapp.com> wrote:
>> On 2016-06-30, at 16:46, DRUTA, DAN <dd5826@att.com> wrote:
>>> What's important is to understand and capture the reasons = why IT Administrators are blocking UDP. Some are as you pointed out not rel= ated to the technology but we need to make sure they get the right level of= manageability with QUIC in order troubleshooting legitimate traffic and pr= event attacks.
>>
>> again: why? We're talking about less than 10% of the paths, an= d HTTPS over TCP readily available as an alternative on those paths, suppos= edly with all the manageability that IT admins need.
>
> We're talking about less than 10% of the paths that were measured = by one experiment.=C2=A0 I don't yet know how reproducible that is.

fair point. I hope we hear from Akamai and others who are experiment= ing with QUIC currently.

>=C2=A0 Again, it's 100% of the flows on my network, and on that of = many other enterprise networks where I have deployed software in the past.<= br>
I don't debate that - you're part of the less-than-10% thoug= h.

> I guarantee that we will deploy new software for our firewall if it= 9;s possible to do so in a way that we don't have to update for every n= ewly-popular version number that someone in the QUIC world decides to deplo= y.

That's both encouraging and discouraging. Encouraging, because b= etter software is better. Discouraging because one of the stated strong poi= nts of QUIC is rapid deployment of improved versions, and limiting future e= volvability of part of the protocol because "corporate middleboxes nee= d to do stuff" isn't a really good starter here.
=
One of the reasons I was given for not just sending QUIC to = the ISE so there's an RFC that describes what's deployed, was the d= esire to support new functionality without bumping a protocol version numbe= r (an easy way to evolve the protocol when you control the QUIC implementat= ion at both endpoints and centralize software development, but one that doe= sn't scale to support evolving protocols the way we do that, at IETF).<= /div>

The current charter talks about both versioning an= d option negotiation.

I had assumed, perhaps incor= rectly, that most experimentation would make use of option negotiation, and= bumping the version number would be possible, but relatively rare. The fir= st two extensions I saw proposed were multipath and FEC, and I understood b= oth of those to be possible to implement using option negotiation.

Am I misunderstanding what the intention is here?

Thanks,

Spencer
=C2=A0<= /div>
> Mostly, I would l= ike to see the assumptions that folks are making about how the path might i= nteract with the bits that are already explicitly exposed to the path by th= e current protocol be discussed, then written down.

I'm with you on that. Writing down assumptions makes design deci= sions clearer.

>
>> I'd be open to the WG reviewing concrete proposals someone may= have in this space once the WG is underway, but I wouldn't want to see= charter text making it a requirement for QUIC to do anything about such pa= ths, since we really don't know what fulfilling this requirement may ac= tually entail.
>
> Brian's proposed text here:
>
> https://github.com/IETF-QUIC/Charter/pull/14/= files
>
> says "This work will consider deployability, manageability and di= agnosability of the wire format, including how the wire format will be proc= essed by devices on path".=C2=A0 I don't think that makes doing an= ything for the path required, but it does make it possible to have the conv= ersation.=C2=A0 If we're worried about this language requiring changes = to the protocol, rather than allowing for the conversation, we can of cours= e continue to tweak the language.

That's at least my personal worry - that text is pretty broad. I= 'd be happier with a statement along the lines you stated above, i.e., = that the WG may document assumptions about how boxes along the path might i= nteract with exposed protocol information. That - to me - makes it clearer = that it isn't a goal to make protocol changes in the hopes of making it= comply with whatever enterprise IT admins may define as policy, based on t= he knobs their middlebox software is at the moment exposing.

> From a previous message of yours:
>
>> And - pet peeve - there is really no need for binding timeouts for= TCP or UDP to begin with. No binding needs to be timed out until the middl= ebox runs out of memory, because as long as there are sufficient resources,= why bother managing all these timeouts?
>
> One of the reasons people give for this is the concern that traffic wi= ll be allowed in from the outside to boxes and applications that are no lon= ger expecting the traffic.=C2=A0 Since they believe that many older UDP pro= tocols don't have adequate security measures in place to authenticate, = authorize, or sessionize traffic, they just block it all except for the pro= tocols where they do deeper inspection, such as DNS.=C2=A0 It is not becaus= e these administrators are idiots, or because they have misconfigured their= boxes unintentionally.

I didn't mean to imply that - they use the knobs they have. But = there are other ways to mitigate the attack surface here, such as rate limi= ting inbound traffic on idle bindings, only fully activating idle bindings = after outbound traffic indicates an active listener, etc.

> Many of the folks that block UDP *do* update their firewall software o= ften, and do review their security stance on blocked protocols periodically= .=C2=A0 They will want their users to be able to take advantage of the bene= fits of QUIC, so they will have incentives to do the review.=C2=A0 We need = to at least provide them with the tools to do this review, such as security= considerations that tell an administrator how to continue to protect their= network from unknown UDP protocols while allowing QUIC.

But "we need to at least provide the tools" again sounds l= ike the intent here is that QUIC will need to change to satisfy some curren= tly under-defined requirements, rather than documenting assumptions about h= ow boxes along the path might interact with exposed protocol information (m= y attempt to summarize what you wrote above).

Personally, I'd like to understand in much more detail what these "= ;tools to do this review" are and how they would change the current QU= IC protocol, before I'd feel comfortable adding this to the charter as = anything more than a thought experiment the WG may undertake (and, do we re= ally need this in the charter? WGs can always discuss work related to their= chartered work). Once we have some clarity here - maybe also because PLUS = will have gotten chartered and we've gained some understanding through = that effort - a future version of QUIC could decide to incorporate those ch= anges.

Lars

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


--001a114e1a3c1f8ca50536927481-- From nobody Fri Jul 1 08:34: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 A019612D6B2 for ; Fri, 1 Jul 2016 08:34:44 -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 jKIomVftTMVu for ; Fri, 1 Jul 2016 08:34:42 -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 8C3C912D738 for ; Fri, 1 Jul 2016 08:34:37 -0700 (PDT) Received: by mail-oi0-x22b.google.com with SMTP id f189so115507432oig.3 for ; Fri, 01 Jul 2016 08:34:37 -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=jKL3VxVKGS80W7IQ1kq6q2aduGzCdtpA9V71bcZfTSU=; b=nHLuzvmA0zK3DqDrtp0Ozxirub6ciUf3CGBb7zi2iMqjdQMiDomjOo5NHw0kWCZPnc 7d9G1yEmJBmqFYYUOYBVSrgObU8iD+F3Xa93foqxX9aOPzgLOVVTOQcjdmet+GoGMjdG ltv14Ajt+bH1JaqPM/MF+yrlT9hPK13TXPYgqUNHqGE2TuEXiCvu1UJ+JZZTO/R4UjCM 9INNoxZ1sSc8InMjZLzsJpU2QlY6jzn5uEdHjyYucbFkC4KjAuuL21bI7K4JlbcreDly IFuHUBmzuSvC32h506Pb6bDTQIIgDWgQxpLA46UPEVi7hPANOpYbvPy7yfJpiYS/xPus +K8g== 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=jKL3VxVKGS80W7IQ1kq6q2aduGzCdtpA9V71bcZfTSU=; b=VP+B0WFHA+KkHQIfyY5poxDdhiutS+mX2Y4o4Oa133rJ5oOUDOt6gK+XsBxtrFkFVB Zkq0+vm/9bCPaAlXS52D0uUCrZyffdF0dBmkuWZnJVYPND4iFJITK7KWGlrwh/FBCKK2 dvg/5YZKAv81+tQxG2Fs3K2bLTkL3BXnHFXulLgPHWm7xC018t5YzkcPSgBVfnfkad// TdU67sqxFFpPJrwH2g6DKhQKw/uiC3b1Agtmz5NHm50KG50nVfkNyGYA2D5Vf7OsXWaw vzhwxEc6JK83OTUde6xo1dR5ApSgd0t28HRzngHow68WBifJ3zl4BZGzbUG4I4qtCrWB gMEQ== X-Gm-Message-State: ALyK8tKCg85xc8RCB5hj1JlXvbTBweY4Nyzw3vi93aQQQdur2tDI07QBpRh+kpgCJZrPsbADrAB5WItk8o1Q7Q== X-Received: by 10.202.218.215 with SMTP id r206mr13198481oig.55.1467387276840; Fri, 01 Jul 2016 08:34:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.171.146 with HTTP; Fri, 1 Jul 2016 08:34:07 -0700 (PDT) In-Reply-To: References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> From: Ted Hardie Date: Fri, 1 Jul 2016 08:34:07 -0700 Message-ID: To: "Eggert, Lars" Content-Type: multipart/alternative; boundary=001a113d2b7862553f053694b929 Archived-At: Cc: Brian Trammell , "quic@ietf.org" , "DRUTA, DAN" Subject: Re: [QUIC] Network Path Requirements for QUIC 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: Fri, 01 Jul 2016 15:34:44 -0000 --001a113d2b7862553f053694b929 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 1, 2016 at 2:18 AM, Eggert, Lars wrote: > On 2016-06-30, at 18:34, Ted Hardie wrote: > > > On Thu, Jun 30, 2016 at 7:12 AM, Eggert, Lars wrote: > >> (And - pet peeve - there is really no need for binding timeouts for TCP >> or UDP to begin with. No binding needs to be timed out until the middlebox >> runs out of memory, because as long as there are sufficient resources, why >> bother managing all these timeouts? ) >> > > If I understand this correctly, this is largely because many of these are > NAT+FW boxes which combine the binding and the firewall permission; leaving > them up for long periods of time leaves the pinhole up. If you really > relied on state exhaustion, it might never happen at all for small > networks. Eliminating the firewall permission to receive traffic and > leaving the binding to send would be odd, so they don't. > > > Well, they could leave the binding up and check whether inbound traffic > after idle still elicits response traffic. > Given that the risk here is partly that attack traffic would elicit responses (/trigger memory overflows/allow the device to be owned/etc), allowing the inbound traffic that would enable this check is exactly what they're trying to limit. > But I think I took us down the rathole of building a better mousetrap > (how's that for an analogy :-) > > I can think of no better place to trap a rodent than in that rodent's hole, but I can think of several places that would be better places to have the "what should a firewall do, really?" conversation. Perhaps over a beer in Berlin we can discuss them. Ted > Lars > > > Joe H. might well be able to get you better and fersher data, but that's > why I think the timers were put in in the first place. > > Ted > > > > > > --001a113d2b7862553f053694b929 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jul 1, 2016 at 2:18 AM, Eggert, Lars <lars@netapp.c= om> wrote:
<= span class=3D"">On 2016-06-30, at 18:34, Ted Hardie <ted.ietf@gmail.com> wrote:
<= /span>

On Thu, Jun 30, 2016 at 7:12 AM, Eggert, Lars <lars@netapp.com><= /span> wrote:
(And - pet peeve - there is really no need for b= inding timeouts for TCP or UDP to begin with. No binding needs to be timed = out until the middlebox runs out of memory, because as long as there are su= fficient resources, why bother managing all these timeouts? <snip>)

If I understand t= his correctly, this is largely because many of=C2=A0 these are NAT+FW boxes= which combine the binding and the firewall permission; leaving them up for= long periods of time leaves the pinhole up.=C2=A0 If you really relied on = state exhaustion, it might never happen at all for small networks.=C2=A0 El= iminating the firewall permission to receive traffic and leaving the bindin= g to send would be odd, so they don't.

Well, they could leave the binding up and chec= k whether inbound traffic after idle still elicits response traffic.
=

Given that the risk here is pa= rtly that attack traffic would elicit responses (/trigger memory overflows/= allow the device to be owned/etc), allowing the inbound traffic that would = enable this check is exactly what they're trying to limit.
=C2=A0
But I think I took us down the rathole of building a better= mousetrap (how's that for an analogy :-)
<= font color=3D"#888888">

I can think of no better place to trap a rodent than in that rodent&= #39;s hole, but I can think of several places that would be better places t= o have the "what should a firewall do, really?" conversation.=C2= =A0 Perhaps over a beer in Berlin we can discuss them.

Te= d
=C2=A0
Lars


Joe H. might well be able to get you better and fershe= r data, but that's why I think the timers were put in in the first plac= e.

Ted






--001a113d2b7862553f053694b929-- From nobody Tue Jul 5 14:03: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 23229128E18 for ; Tue, 5 Jul 2016 14:03:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il4BmZ3ReZtU for ; Tue, 5 Jul 2016 14:03:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDB41127078 for ; Tue, 5 Jul 2016 14:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9063; q=dns/txt; s=iport; t=1467752591; x=1468962191; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fF3LceN6lAnztsIxW/+THMbnOaHyMXOrGni70WBT/7Q=; b=VNgdf+m6HFKkQAkCkm3VK4iMla6W+dDMFoxAYjgxzEPBr3dYsi5i69Ec IyjGFb46NHoEhqoqVjMQAdy3EBs5/sMH0xlQ6noX14AnRroppCg+tep42 FjyyknMrwhlBDq+466//3AH/LU0pZpFu0PgGY1d6LlAj+f/F47/roENfm Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAgDnH3xX/51dJa1cgz5WfAa3M4IPg?= =?us-ascii?q?Xcigj+DNwKBNTgUAQEBAQEBAWUnhEwBAQQBOisHDQULAgEIGB4QMiUCBA4FiCg?= =?us-ascii?q?IDrtMAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWGJ4F4CIJNhECDLIIvBYgdkHYBh?= =?us-ascii?q?giIPoFqhFaIaoZXiTIBHjaCAwUcgUxuh1V/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,315,1464652800"; d="scan'208";a="126180823" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 21:03:10 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u65L3APe009527 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Jul 2016 21:03:10 GMT Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 5 Jul 2016 17:03:09 -0400 Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1210.000; Tue, 5 Jul 2016 17:03:09 -0400 From: "Joe Hildebrand (jhildebr)" To: "Eggert, Lars" Thread-Topic: [QUIC] Network Path Requirements for QUIC Thread-Index: AQHR0qGNJsGpNQB40EWqiuBvsm2ewqACCXAAgABHOYCAAAlqAIAACdSAgAAWywCAATfLgIAG7JEA Date: Tue, 5 Jul 2016 21:03:09 +0000 Message-ID: References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> <826872D6-FB13-499D-B134-EB5005DE9ACA@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.203.22] Content-Type: text/plain; charset="us-ascii" Content-ID: <831800D045C76042AD830E4597609CE0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , Brian Trammell Subject: Re: [QUIC] Network Path Requirements for QUIC 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: Tue, 05 Jul 2016 21:03:14 -0000 > On Jul 1, 2016, at 5:18 AM, Eggert, Lars wrote: >=20 >> Again, it's 100% of the flows on my network, and on that of many other e= nterprise networks where I have deployed software in the past. >=20 > I don't debate that - you're part of the less-than-10% though. Which is why it's understandable that I'd want to talk about these issues. = I'll note that I'm not alone in having the problem, and there are probably= lots of different networks involved even in the 10% that was measured. >> I guarantee that we will deploy new software for our firewall if it's po= ssible to do so in a way that we don't have to update for every newly-popul= ar version number that someone in the QUIC world decides to deploy. >=20 > That's both encouraging and discouraging. Encouraging, because better sof= tware is better. Discouraging because one of the stated strong points of QU= IC is rapid deployment of improved versions, and limiting future evolvabili= ty of part of the protocol because "corporate middleboxes need to do stuff"= isn't a really good starter here. It could also provide a guideline for how to design the version negotiation= in a slightly different way. Anything that we expose to the path will ossify in the short term. Plannin= g for that, rather than fighting against human nature might get us further. For example (note: here I'm proposing a protocol change, but not saying tha= t this is something that we should do, just providing an example of the sor= t of discussion we might have), we could set the version number that is cur= rently exposed to the path to a constant, to be used like the SPUD magic nu= mber. We could then provide version negotiation inside the crypto boundary= . I bet this approach wouldn't meet the needs of load balancers, so more e= ngineering would be required. >> Mostly, I would like to see the assumptions that folks are making about = how the path might interact with the bits that are already explicitly expos= ed to the path by the current protocol be discussed, then written down. >=20 > I'm with you on that. Writing down assumptions makes design decisions cle= arer. >=20 >>=20 >>> I'd be open to the WG reviewing concrete proposals someone may have in = this space once the WG is underway, but I wouldn't want to see charter text= making it a requirement for QUIC to do anything about such paths, since we= really don't know what fulfilling this requirement may actually entail. >>=20 >> Brian's proposed text here: >>=20 >> https://github.com/IETF-QUIC/Charter/pull/14/files >>=20 >> says "This work will consider deployability, manageability and diagnosab= ility of the wire format, including how the wire format will be processed b= y devices on path". I don't think that makes doing anything for the path r= equired, but it does make it possible to have the conversation. If we're w= orried about this language requiring changes to the protocol, rather than a= llowing for the conversation, we can of course continue to tweak the langua= ge. >=20 > That's at least my personal worry - that text is pretty broad. I'd be hap= pier with a statement along the lines you stated above, i.e., that the WG m= ay document assumptions about how boxes along the path might interact with = exposed protocol information. That - to me - makes it clearer that it isn't= a goal to make protocol changes in the hopes of making it comply with what= ever enterprise IT admins may define as policy, based on the knobs their mi= ddlebox software is at the moment exposing. Can you propose text that you would find appropriate, please? >> From a previous message of yours: >>=20 >>> And - pet peeve - there is really no need for binding timeouts for TCP = or UDP to begin with. No binding needs to be timed out until the middlebox = runs out of memory, because as long as there are sufficient resources, why = bother managing all these timeouts? >>=20 >> One of the reasons people give for this is the concern that traffic will= be allowed in from the outside to boxes and applications that are no longe= r expecting the traffic. Since they believe that many older UDP protocols = don't have adequate security measures in place to authenticate, authorize, = or sessionize traffic, they just block it all except for the protocols wher= e they do deeper inspection, such as DNS. It is not because these administ= rators are idiots, or because they have misconfigured their boxes unintenti= onally. >=20 > I didn't mean to imply that - they use the knobs they have. But there are= other ways to mitigate the attack surface here, such as rate limiting inbo= und traffic on idle bindings, only fully activating idle bindings after out= bound traffic indicates an active listener, etc. These sorts of approaches would need security analysis, which would likely = only come after the approach had be thought through and documented. If the= re are generic versions of these that we think might work, a potential PLUS= working group might be a good place to get the analysis done. >> Many of the folks that block UDP *do* update their firewall software oft= en, and do review their security stance on blocked protocols periodically. = They will want their users to be able to take advantage of the benefits of= QUIC, so they will have incentives to do the review. We need to at least = provide them with the tools to do this review, such as security considerati= ons that tell an administrator how to continue to protect their network fro= m unknown UDP protocols while allowing QUIC. >=20 > But "we need to at least provide the tools" again sounds like the intent = here is that QUIC will need to change to satisfy some currently under-defin= ed requirements, rather than documenting assumptions about how boxes along = the path might interact with exposed protocol information (my attempt to su= mmarize what you wrote above). Later in that sentence, I said "such as security considerations". The doc = will certainly have to change, but whether the protocol will have to change= will rely on what we learn in the discussion. As to whether draft-wing-quic-network-req is under-defined, of course it is= . It's a -00 draft for a topic that hasn't had any public discussion yet. = It talks about the ways that people have treated TCP in the past, and I ho= pe asks the question whether any of the things we've learned from TCP might= be applied to QUIC.=20 > Personally, I'd like to understand in much more detail what these "tools = to do this review" are and how they would change the current QUIC protocol,= before I'd feel comfortable adding this to the charter as anything more th= an a thought experiment the WG may undertake (and, do we really need this i= n the charter? WGs can always discuss work related to their chartered work)= . Once we have some clarity here - maybe also because PLUS will have gotten= chartered and we've gained some understanding through that effort - a futu= re version of QUIC could decide to incorporate those changes. I guess I'll repeat myself then: - Is this traffic QUIC? Can a firewall try to advantage it over all of the= other UDP that I'm blocking or deep-queueing? - Is this QUIC connection being initiated from inside the firewall? Does i= t imply an intent-to-receive? - Is this QUIC traffic coming in the firewall from outside related to a pre= vious intent-to-receive? Should the firewall allow it in because of that? - Is this QUIC connection finished? Can the firewall release the state it = is holding? If not, when? - A firewall or application got some QUIC traffic I wasn't expecting, and a= m willing to return an error. What do I do? - A firewall or application got an ICMP related to a QUIC connection. What= do I do? - (optional) A firewall or load balancer is releasing the state for this QU= IC connection due to a timeout. Should it tell anyone? - (optional) Suppose QUIC got multi-path capabilities. Do all of the above = still work when part of the connection is through a new firewall? - As an application, my network connection changed. What do I do? If I do= nothing, will the firewall on the new path just work? Will it let me know= that I need to do something to re-establish the connection? That list seems pretty short. We can argue over whether there needs to be = more or less stuff on it. Much of it just requires us writing down the ass= umptions that the protocol designers made. Some of the discussion about qu= estions like these may lead us to wanting to tweak the protocol slightly, b= ut that's true of any discussion in a potential working group. Some of the work that QUIC would need to do might be informed by things we = learn about in a potential PLUS working group, but that doesn't mean that t= he working group shouldn't be responsible for having the conversation. --=20 Joe Hildebrand From nobody Tue Jul 5 16:44: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 EC53D12B032 for ; Tue, 5 Jul 2016 16:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.426, 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 zd77yGkXiJWL for ; Tue, 5 Jul 2016 16:43:55 -0700 (PDT) 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 E64C212D520 for ; Tue, 5 Jul 2016 16:43:54 -0700 (PDT) Received: by mail-yw0-x22d.google.com with SMTP id l125so74796056ywb.2 for ; Tue, 05 Jul 2016 16:43:54 -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=6jggiH2EwgNStwtvOPLWTcpjkVa9MmrIA1bOaI8NGxo=; b=c/ABOtbKDQyw229kt0iM32GQVTGLdUnbIyuGVBsWKkYMs7Bk/VQsMOc6IgK54iwyze /iFtElfyIEfK36MUAuZrV8y0m2BzVm+A61T18KzxT57nTSOqbfFZjg5jWblThpCuiQxr EG6WM0dEDc05uKVQTZqZ3oc9EoJNb9hLcCvykY6bfr87VUJvcIKbyLJHRCQ7Py7YExE3 E0tyeDT794b1tPo1r9/eQiihle9li4Xriq9ZVXKG3K1nN2FB7L35EnIa6tulsy96R3qV Xriw5sJ38kD8bJU3Un7dpCdnyqWOQA8jdsggn+sOGkMJrK2Y48wiOMjoFJk4ldPPEGfS IyqQ== 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=6jggiH2EwgNStwtvOPLWTcpjkVa9MmrIA1bOaI8NGxo=; b=jM2WxGg9xxkFx3xf/GHxFun9uzdr7XTFcESw7ScRuSOV2+styIAgLNi3zlp2jWM5zx yLHcTH2K1cJ2b5o/C71iKpJMyLPJJ2CrdjAxxLzYrUZh8MYp3nDDV8NvbyU/QRmMynPT b7PeaaGorSdUY/4M7Ni7I+6ETKAlmSDT5bsGfzAwYYZ8SzHsjyw7o6XlBDSXafXL+GYC Ta/FmTX8l1J2i7uzcIqg8AeRH1Q71LAP9LT9/WI7RXLdqhU0TMgQa+pD3nV37OkUliQX VIJH1f98Ph+7hvPchvYGcK6BasfNpYb0D1+it0CLbf6jX0MdXIzxPegMg4JgzJPsihoa lm1g== X-Gm-Message-State: ALyK8tKDAhVPIztKsZP58/LH/OlSCcMqOGhfAkcRyiSmlaHrfN/UcBzmgkbM9NUcsGejUU1jZasEfJldJB+lZ/UC X-Received: by 10.129.72.10 with SMTP id v10mr13301489ywa.110.1467762233993; Tue, 05 Jul 2016 16:43:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.211.65 with HTTP; Tue, 5 Jul 2016 16:43:53 -0700 (PDT) In-Reply-To: References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> <826872D6-FB13-499D-B134-EB5005DE9ACA@cisco.com> From: Jana Iyengar Date: Tue, 5 Jul 2016 16:43:53 -0700 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a114dcd6a92d4e90536ec0663 Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , "Eggert, Lars" , Brian Trammell Subject: Re: [QUIC] Network Path Requirements for QUIC 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: Tue, 05 Jul 2016 23:43:59 -0000 --001a114dcd6a92d4e90536ec0663 Content-Type: text/plain; charset=UTF-8 A couple of things that were raised in this thread that Id like to clarify: - As I wrote earlier, the 94% reachability in the client-server scenario has been independently verified by WebRTC deployments, by measuring the percentage of connections that go over a TURN server. This ends up being ~15%, which is makes sense given that it's p2p and therefore encounters ~2x the number of middleboxes than client-server connections do. - Calling the current QUIC deployment "one unrepeatable experiment" is technically accurate, but doesn't really reflect the scale of things. Most Chrome->Google traffic flows over QUIC, and that's a pretty massive and diverse population. - The network-requirements draft has two separable parts: (i) which middlebox behaviors are important, and (ii) what information is necessary for that middlebox behavior to be implemented. (ii) makes no sense without (i), and we do not have consensus on (i)... and that discussion should happen elsewhere, not in the QUIC wg, since any of these considerations ought to apply to *any* protocol over UDP, including WebRTC's SRTP/UDP or SCTP/DTLS/UDP stacks, Tom Herbert's Transports-over-UDP stacks, and also proprietary FaceTime, RTMFP, Skype, Xbox protocols. More thoughts inline: On Tue, Jul 5, 2016 at 2:03 PM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > > On Jul 1, 2016, at 5:18 AM, Eggert, Lars wrote: > > > >> Again, it's 100% of the flows on my network, and on that of many other > enterprise networks where I have deployed software in the past. > > > > I don't debate that - you're part of the less-than-10% though. > > Which is why it's understandable that I'd want to talk about these > issues. I'll note that I'm not alone in having the problem, and there are > probably lots of different networks involved even in the 10% that was > measured. > > >> I guarantee that we will deploy new software for our firewall if it's > possible to do so in a way that we don't have to update for every > newly-popular version number that someone in the QUIC world decides to > deploy. > > > > That's both encouraging and discouraging. Encouraging, because better > software is better. Discouraging because one of the stated strong points of > QUIC is rapid deployment of improved versions, and limiting future > evolvability of part of the protocol because "corporate middleboxes need to > do stuff" isn't a really good starter here. > > It could also provide a guideline for how to design the version > negotiation in a slightly different way. > > Anything that we expose to the path will ossify in the short term. > Planning for that, rather than fighting against human nature might get us > further. > > For example (note: here I'm proposing a protocol change, but not saying > that this is something that we should do, just providing an example of the > sort of discussion we might have), we could set the version number that is > currently exposed to the path to a constant, to be used like the SPUD magic > number. We could then provide version negotiation inside the crypto > boundary. I bet this approach wouldn't meet the needs of load balancers, > so more engineering would be required. > > >> Mostly, I would like to see the assumptions that folks are making about > how the path might interact with the bits that are already explicitly > exposed to the path by the current protocol be discussed, then written down. > > > > I'm with you on that. Writing down assumptions makes design decisions > clearer. > > > >> > >>> I'd be open to the WG reviewing concrete proposals someone may have in > this space once the WG is underway, but I wouldn't want to see charter text > making it a requirement for QUIC to do anything about such paths, since we > really don't know what fulfilling this requirement may actually entail. > >> > >> Brian's proposed text here: > >> > >> https://github.com/IETF-QUIC/Charter/pull/14/files > >> > >> says "This work will consider deployability, manageability and > diagnosability of the wire format, including how the wire format will be > processed by devices on path". I don't think that makes doing anything for > the path required, but it does make it possible to have the conversation. > If we're worried about this language requiring changes to the protocol, > rather than allowing for the conversation, we can of course continue to > tweak the language. > > > > That's at least my personal worry - that text is pretty broad. I'd be > happier with a statement along the lines you stated above, i.e., that the > WG may document assumptions about how boxes along the path might interact > with exposed protocol information. That - to me - makes it clearer that it > isn't a goal to make protocol changes in the hopes of making it comply with > whatever enterprise IT admins may define as policy, based on the knobs > their middlebox software is at the moment exposing. > > Can you propose text that you would find appropriate, please? I agree with Lars, but there's something else that's implicit in here which I don't think we have a handle on. Which interactions are important to describe? Personally, I don't think this is the right working group to have that discussion, modulo the considerations that will happen organically anyways (as I said, similar to what happened with MPTCP.) I still don't think it's necessary to have that language in the charter to "protect" that conversation. OTOH, I worry as Lars that leaving broad text will cause folks to bring up various middlebox-related conversations that really shouldn't be in this wg. PLUS is a great place to have the conversation about which middlebox interactions are important to describe; any outcomes of that wg will naturally influence QUIC later. >> From a previous message of yours: > >> > >>> And - pet peeve - there is really no need for binding timeouts for TCP > or UDP to begin with. No binding needs to be timed out until the middlebox > runs out of memory, because as long as there are sufficient resources, why > bother managing all these timeouts? > >> > >> One of the reasons people give for this is the concern that traffic > will be allowed in from the outside to boxes and applications that are no > longer expecting the traffic. Since they believe that many older UDP > protocols don't have adequate security measures in place to authenticate, > authorize, or sessionize traffic, they just block it all except for the > protocols where they do deeper inspection, such as DNS. It is not because > these administrators are idiots, or because they have misconfigured their > boxes unintentionally. > > > > I didn't mean to imply that - they use the knobs they have. But there > are other ways to mitigate the attack surface here, such as rate limiting > inbound traffic on idle bindings, only fully activating idle bindings after > outbound traffic indicates an active listener, etc. > > These sorts of approaches would need security analysis, which would likely > only come after the approach had be thought through and documented. If > there are generic versions of these that we think might work, a potential > PLUS working group might be a good place to get the analysis done. > > >> Many of the folks that block UDP *do* update their firewall software > often, and do review their security stance on blocked protocols > periodically. They will want their users to be able to take advantage of > the benefits of QUIC, so they will have incentives to do the review. We > need to at least provide them with the tools to do this review, such as > security considerations that tell an administrator how to continue to > protect their network from unknown UDP protocols while allowing QUIC. > > > > But "we need to at least provide the tools" again sounds like the intent > here is that QUIC will need to change to satisfy some currently > under-defined requirements, rather than documenting assumptions about how > boxes along the path might interact with exposed protocol information (my > attempt to summarize what you wrote above). > > Later in that sentence, I said "such as security considerations". The doc > will certainly have to change, but whether the protocol will have to change > will rely on what we learn in the discussion. > ... and as I said earlier, that discussion should happen elsewhere, not in the QUIC wg, since any of these considerations ought to apply to *any* transport protocol. As to whether draft-wing-quic-network-req is under-defined, of course it > is. It's a -00 draft for a topic that hasn't had any public discussion > yet. It talks about the ways that people have treated TCP in the past, and > I hope asks the question whether any of the things we've learned from TCP > might be applied to QUIC. > > > Personally, I'd like to understand in much more detail what these "tools > to do this review" are and how they would change the current QUIC protocol, > before I'd feel comfortable adding this to the charter as anything more > than a thought experiment the WG may undertake (and, do we really need this > in the charter? WGs can always discuss work related to their chartered > work). Once we have some clarity here - maybe also because PLUS will have > gotten chartered and we've gained some understanding through that effort - > a future version of QUIC could decide to incorporate those changes. > > I guess I'll repeat myself then: > > - Is this traffic QUIC? Can a firewall try to advantage it over all of > the other UDP that I'm blocking or deep-queueing? > > - Is this QUIC connection being initiated from inside the firewall? Does > it imply an intent-to-receive? > > - Is this QUIC traffic coming in the firewall from outside related to a > previous intent-to-receive? Should the firewall allow it in because of > that? > > - Is this QUIC connection finished? Can the firewall release the state it > is holding? If not, when? > > - A firewall or application got some QUIC traffic I wasn't expecting, and > am willing to return an error. What do I do? > > - A firewall or application got an ICMP related to a QUIC connection. > What do I do? > > - (optional) A firewall or load balancer is releasing the state for this > QUIC connection due to a timeout. Should it tell anyone? > > - (optional) Suppose QUIC got multi-path capabilities. Do all of the above > still work when part of the connection is through a new firewall? > > - As an application, my network connection changed. What do I do? If I > do nothing, will the firewall on the new path just work? Will it let me > know that I need to do something to re-establish the connection? > > That list seems pretty short. We can argue over whether there needs to be > more or less stuff on it. Much of it just requires us writing down the > assumptions that the protocol designers made. Some of the discussion about > questions like these may lead us to wanting to tweak the protocol slightly, > but that's true of any discussion in a potential working group. > I'll repeat myself on my response to your list from an earlier email in this thread. Some of these questions will be raised naturally, simply because it's unavoidable for a deployable protocol to engage with some of these. Agreeing on a list of such behaviors however is problematic on at least two counts: (i) it needs consensus on which behaviors are important, and (ii) QUIC is not the only protocol that will need to answer these questions. This list applies to UDP-based transports, and as such, the conversation belongs not just with one protocol. As I've pointed out repeatedly in the past, you are trying to argue that certain middlebox behaviors are important and should be addressed in protocol design. I completely agree that we should have that conversation at the IETF, but the venue has to be broader than the QUIC wg. Some of the work that QUIC would need to do might be informed by things we > learn about in a potential PLUS working group, but that doesn't mean that > the working group shouldn't be responsible for having the conversation. Having the same conversation in two places does not make sense. QUIC wg's work will naturally be influenced by ones happening in PLUS or elsewhere about extant middlebox behaviors. But deriving a list of such behaviors should happen elsewhere. - jana > -- > Joe Hildebrand > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a114dcd6a92d4e90536ec0663 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A couple of things that were raised in this thread that Id= like to clarify:

- As I wrote earlier, the 94% reachabi= lity in the client-server scenario has been independently verified by WebRT= C deployments, by measuring the percentage of connections that go over a TU= RN server. This ends up being ~15%, which is makes sense given that it'= s p2p and therefore encounters ~2x the number of middleboxes than client-se= rver connections do.

- Calling the current QUIC de= ployment "one unrepeatable experiment" is technically accurate, b= ut doesn't really reflect the scale of things. Most Chrome->Google t= raffic flows over QUIC, and that's a pretty massive and diverse populat= ion.

- The network-requirements draft has two sepa= rable parts: (i) which middlebox behaviors are important, and (ii) what inf= ormation is necessary for that middlebox behavior to be implemented. =C2=A0= (ii) makes no sense without (i), and we do not have consensus on (i)... and= that discussion should happen elsewhere, not in the QUIC wg, since any of = these considerations ought to apply to *any* protocol over UDP, including W= ebRTC's SRTP/UDP or SCTP/DTLS/UDP stacks, Tom Herbert's=C2=A0Transp= orts-over-UDP stacks, and also proprietary FaceTime, RTMFP, Skype, Xbox pro= tocols.

More thoughts inline:

On Tue, Jul 5, 2016 at 2:03= PM, Joe Hildebrand (jhildebr) <jhildebr@cisco.com> wrote:
> On Jul 1, 2016, at 5:18 AM, Eggert, Lars <= lars@netapp.com> wrote:
>
>> Again, it's 100% of the flows on my network, and on that of ma= ny other enterprise networks where I have deployed software in the past. >
> I don't debate that - you're part of the less-than-10% though.=

Which is why it's understandable that I'd want to talk about= these issues.=C2=A0 I'll note that I'm not alone in having the pro= blem, and there are probably lots of different networks involved even in th= e 10% that was measured.

>> I guarantee that we will deploy new software for our firewall if i= t's possible to do so in a way that we don't have to update for eve= ry newly-popular version number that someone in the QUIC world decides to d= eploy.
>
> That's both encouraging and discouraging. Encouraging, because bet= ter software is better. Discouraging because one of the stated strong point= s of QUIC is rapid deployment of improved versions, and limiting future evo= lvability of part of the protocol because "corporate middleboxes need = to do stuff" isn't a really good starter here.

It could also provide a guideline for how to design the version nego= tiation in a slightly different way.

Anything that we expose to the path will ossify in the short term.=C2=A0 Pl= anning for that, rather than fighting against human nature might get us fur= ther.

For example (note: here I'm proposing a protocol change, but not saying= that this is something that we should do, just providing an example of the= sort of discussion we might have), we could set the version number that is= currently exposed to the path to a constant, to be used like the SPUD magi= c number.=C2=A0 We could then provide version negotiation inside the crypto= boundary.=C2=A0 I bet this approach wouldn't meet the needs of load ba= lancers, so more engineering would be required.

>> Mostly, I would like to see the assumptions that folks are making = about how the path might interact with the bits that are already explicitly= exposed to the path by the current protocol be discussed, then written dow= n.
>
> I'm with you on that. Writing down assumptions makes design decisi= ons clearer.
>
>>
>>> I'd be open to the WG reviewing concrete proposals someone= may have in this space once the WG is underway, but I wouldn't want to= see charter text making it a requirement for QUIC to do anything about suc= h paths, since we really don't know what fulfilling this requirement ma= y actually entail.
>>
>> Brian's proposed text here:
>>
>> https://github.com/IETF-QUIC/Charter/pull/14/files
>>
>> says "This work will consider deployability, manageability an= d diagnosability of the wire format, including how the wire format will be = processed by devices on path".=C2=A0 I don't think that makes doin= g anything for the path required, but it does make it possible to have the = conversation.=C2=A0 If we're worried about this language requiring chan= ges to the protocol, rather than allowing for the conversation, we can of c= ourse continue to tweak the language.
>
> That's at least my personal worry - that text is pretty broad. I&#= 39;d be happier with a statement along the lines you stated above, i.e., th= at the WG may document assumptions about how boxes along the path might int= eract with exposed protocol information. That - to me - makes it clearer th= at it isn't a goal to make protocol changes in the hopes of making it c= omply with whatever enterprise IT admins may define as policy, based on the= knobs their middlebox software is at the moment exposing.

Can you propose text that you would find appropriate, please?

I agree with Lars, but there's something else= that's implicit in here which I don't think we have a handle on. W= hich interactions are important to describe? Personally, I don't think = this is the right working group to have that discussion, modulo the conside= rations that will happen organically anyways (as I said, similar to what ha= ppened with MPTCP.) I still don't think it's necessary to have that= language in the charter to "protect" that conversation. OTOH, I = worry as Lars that leaving broad text will cause folks to bring up various = middlebox-related conversations that really shouldn't be in this wg.

PLUS is a great place to have the conversation about= which middlebox interactions are important to describe; any outcomes of th= at wg will naturally influence QUIC later.

>> From a previous message of yours:
>>
>>> And - pet peeve - there is really no need for binding timeouts= for TCP or UDP to begin with. No binding needs to be timed out until the m= iddlebox runs out of memory, because as long as there are sufficient resour= ces, why bother managing all these timeouts?
>>
>> One of the reasons people give for this is the concern that traffi= c will be allowed in from the outside to boxes and applications that are no= longer expecting the traffic.=C2=A0 Since they believe that many older UDP= protocols don't have adequate security measures in place to authentica= te, authorize, or sessionize traffic, they just block it all except for the= protocols where they do deeper inspection, such as DNS.=C2=A0 It is not be= cause these administrators are idiots, or because they have misconfigured t= heir boxes unintentionally.
>
> I didn't mean to imply that - they use the knobs they have. But th= ere are other ways to mitigate the attack surface here, such as rate limiti= ng inbound traffic on idle bindings, only fully activating idle bindings af= ter outbound traffic indicates an active listener, etc.

These sorts of approaches would need security analysis, which would = likely only come after the approach had be thought through and documented.= =C2=A0 If there are generic versions of these that we think might work, a p= otential PLUS working group might be a good place to get the analysis done.=

>> Many of the folks that block UDP *do* update their firewall softwa= re often, and do review their security stance on blocked protocols periodic= ally.=C2=A0 They will want their users to be able to take advantage of the = benefits of QUIC, so they will have incentives to do the review.=C2=A0 We n= eed to at least provide them with the tools to do this review, such as secu= rity considerations that tell an administrator how to continue to protect t= heir network from unknown UDP protocols while allowing QUIC.
>
> But "we need to at least provide the tools" again sounds lik= e the intent here is that QUIC will need to change to satisfy some currentl= y under-defined requirements, rather than documenting assumptions about how= boxes along the path might interact with exposed protocol information (my = attempt to summarize what you wrote above).

Later in that sentence, I said "such as security considerations= ".=C2=A0 The doc will certainly have to change, but whether the protoc= ol will have to change will rely on what we learn in the discussion.

... and as I said earlier, that discussion sh= ould happen elsewhere, not in the QUIC wg, since any of these consideration= s ought to apply to *any* transport protocol.

As to whether draft-wing-quic-network-req is under-defined, of course it is= .=C2=A0 It's a -00 draft for a topic that hasn't had any public dis= cussion yet.=C2=A0 It talks about the ways that people have treated TCP in = the past, and I hope asks the question whether any of the things we've = learned from TCP might be applied to QUIC.

> Personally, I'd like to understand in much more detail what these = "tools to do this review" are and how they would change the curre= nt QUIC protocol, before I'd feel comfortable adding this to the charte= r as anything more than a thought experiment the WG may undertake (and, do = we really need this in the charter? WGs can always discuss work related to = their chartered work). Once we have some clarity here - maybe also because = PLUS will have gotten chartered and we've gained some understanding thr= ough that effort - a future version of QUIC could decide to incorporate tho= se changes.

I guess I'll repeat myself then:

- Is this traffic QUIC?=C2=A0 Can a firewall try to advantage it over all o= f the other UDP that I'm blocking or deep-queueing?

- Is this QUIC connection being initiated from inside the firewall?=C2=A0 D= oes it imply an intent-to-receive?

- Is this QUIC traffic coming in the firewall from outside related to a pre= vious intent-to-receive?=C2=A0 Should the firewall allow it in because of t= hat?

- Is this QUIC connection finished?=C2=A0 Can the firewall release the stat= e it is holding?=C2=A0 If not, when?

- A firewall or application got some QUIC traffic I wasn't expecting, a= nd am willing to return an error.=C2=A0 What do I do?

- A firewall or application got an ICMP related to a QUIC connection.=C2=A0= What do I do?

- (optional) A firewall or load balancer is releasing the state for this QU= IC connection due to a timeout.=C2=A0 Should it tell anyone?

- (optional) Suppose QUIC got multi-path capabilities. Do all of the above = still work when part of the connection is through a new firewall?

- As an application, my network connection changed.=C2=A0 What do I do?=C2= =A0 If I do nothing, will the firewall on the new path just work?=C2=A0 Wil= l it let me know that I need to do something to re-establish the connection= ?

That list seems pretty short.=C2=A0 We can argue over whether there needs t= o be more or less stuff on it.=C2=A0 Much of it just requires us writing do= wn the assumptions that the protocol designers made.=C2=A0 Some of the disc= ussion about questions like these may lead us to wanting to tweak the proto= col slightly, but that's true of any discussion in a potential working = group.

I'll repeat myself on my res= ponse to your list from an earlier email in this thread. Some of these ques= tions will be raised naturally, simply because it's unavoidable for a d= eployable protocol to engage with some of these. Agreeing on a list of such= behaviors however is problematic =C2=A0on at least two counts: (i) it need= s consensus on which behaviors are important, and (ii) QUIC is not the only= protocol that will need to answer these questions. This list applies to UD= P-based transports, and as such, the conversation belongs not just with one= protocol.=C2=A0

As I've pointed out repeatedl= y in the past, you are trying to argue that certain middlebox behaviors are= important and should be addressed in protocol design. I completely agree t= hat we should have that conversation at the IETF, but the venue has to be b= roader than the QUIC wg.

Some of the work that QUIC would need to do might be informed by things we = learn about in a potential PLUS working group, but that doesn't mean th= at the working group shouldn't be responsible for having the conversati= on.

Having the same conversation in two pla= ces does not make sense. QUIC wg's work will naturally be influenced by= ones happening in PLUS or elsewhere about extant middlebox behaviors. But = deriving a list of such behaviors should happen elsewhere.

- jana


--
Joe Hildebrand

_______________________________________________
QUIC mailing list
QUIC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/quic

--001a114dcd6a92d4e90536ec0663-- From nobody Tue Jul 5 17:05: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 D285112D50B for ; Tue, 5 Jul 2016 17:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.426, 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 M0PEKv0Us_Pt for ; Tue, 5 Jul 2016 17:05:39 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B1A12D0CA for ; Tue, 5 Jul 2016 17:05:37 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id i12so74731819ywa.1 for ; Tue, 05 Jul 2016 17:05:37 -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=vJk+YFNQ1Mj5CGZivs/xYbaTakoKTpsY0f7zE8RqsaQ=; b=biFpY5Ka+y5LSkVRaxvZBEspjrv4kcqGnkL6oheNfGlgS3bv86i7Plxghf6gyHwlIe nXF4UpkB3qUBwvD29NC5c5nOVdez/+LCBSHnsZgPuD/GfvhhipjxGbZb77w5wX+CM8js eHO8s2v/oXih+pXJvpX4oqtZXIMRB6/552uRX5YcaKgBD12pL2Z/nx33bcUIq57FWxnk X1E/cM8TgDxUvLSrME3fK2k70yzPkNZ9qewsvq+iEALPFoI7PCuMbNdcMEUKWLDJkvtc Cfoh5qZQgxJeNJba9GFhzjE+HqEK+jWlUlEGBuFz+eOloo2wnCLW1jorTChbQoRQfAf/ Pxzg== 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=vJk+YFNQ1Mj5CGZivs/xYbaTakoKTpsY0f7zE8RqsaQ=; b=hd+ILBA36NuJP9NISvzYBA4KRuh2iV/2D83YR1y2BqcniJTu0wVzM3ajKzSRGrhLho gGg2oPNaRTMYb0C/cgwMW0v5PgXpL6BzAUTeAeUwO9iz0HASE6Zs3gYb0ouzYqKvf8gV vQ1LSr5NXEL69rHeaty+p0nk5ZFrldZHsO9n4GNJ8wAhAS5WXSwIkTpZCGF1g96M1Afd PKF16cwRZRg79hffejX4fqb9IY+0LZtUZN8ZKD7thdNUt3+Ycs/KfjlCMb947D/HNL13 owmaMS9l5QhsmSGRam2cEbZzEtWOjaM/UGnexMr8GL58dwH3hyV2vWCG5oBGkgVtCvX1 pEBQ== X-Gm-Message-State: ALyK8tJvxibNj4ZASijJIw6GymWakOiQRTfBbO42a7Rhdf3ZhfmsqhPT9y1qerbirhOjTnC0o/40jdC7AxrNPJx4 X-Received: by 10.13.193.68 with SMTP id c65mr13114521ywd.42.1467763536812; Tue, 05 Jul 2016 17:05:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.211.65 with HTTP; Tue, 5 Jul 2016 17:05:35 -0700 (PDT) In-Reply-To: <826872D6-FB13-499D-B134-EB5005DE9ACA@cisco.com> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> <826872D6-FB13-499D-B134-EB5005DE9ACA@cisco.com> From: Jana Iyengar Date: Tue, 5 Jul 2016 17:05:35 -0700 Message-ID: To: "Joe Hildebrand (jhildebr)" Content-Type: multipart/alternative; boundary=001a114e6c003a48190536ec5403 Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , "Eggert, Lars" , Brian Trammell Subject: Re: [QUIC] Network Path Requirements for QUIC 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, 06 Jul 2016 00:05:43 -0000 --001a114e6c003a48190536ec5403 Content-Type: text/plain; charset=UTF-8 On Thu, Jun 30, 2016 at 9:42 AM, Joe Hildebrand (jhildebr) < jhildebr@cisco.com> wrote: > > > On Jun 30, 2016, at 9:21 AM, Eggert, Lars wrote: > > > > Hi, > > > > On 2016-06-30, at 16:46, DRUTA, DAN wrote: > >> What's important is to understand and capture the reasons why IT > Administrators are blocking UDP. Some are as you pointed out not related to > the technology but we need to make sure they get the right level of > manageability with QUIC in order troubleshooting legitimate traffic and > prevent attacks. > > > > again: why? We're talking about less than 10% of the paths, and HTTPS > over TCP readily available as an alternative on those paths, supposedly > with all the manageability that IT admins need. > > We're talking about less than 10% of the paths that were measured by one > experiment. I don't yet know how reproducible that is. Again, it's 100% > of the flows on my network, and on that of many other enterprise networks > where I have deployed software in the past. > > I guarantee that we will deploy new software for our firewall if it's > possible to do so in a way that we don't have to update for every > newly-popular version number that someone in the QUIC world decides to > deploy. > > > My personal viewpoint is that I wouldn't want to complicate the protocol > or even slightly weaken its security for such a small subset of paths (some > of which may end up unblocking UDP port 443 anyway.) > > If QUIC was only ever going to be used on 443/udp, some of the detection > issues would be easier. Right now, the prototype code I've seen for the > QUIC state tracker hardcodes individual version numbers to look for the > traffic that needs to be tracked - but the developer is just trying to > intuit what he's supposed to do from what has been written so far. > > I don't think anyone has proposed weakening QUIC's security yet. If they > did, the working group should have a thoughtful discussion of the tradeoffs > involved, and I would expect security to win out almost every time. It may > be that certain security measures could be implemented in different ways to > solve multiple problems, for instance. > > Mostly, I would like to see the assumptions that folks are making about > how the path might interact with the bits that are already explicitly > exposed to the path by the current protocol be discussed, then written down. > > > I'd be open to the WG reviewing concrete proposals someone may have in > this space once the WG is underway, but I wouldn't want to see charter text > making it a requirement for QUIC to do anything about such paths, since we > really don't know what fulfilling this requirement may actually entail. > > Brian's proposed text here: > > https://github.com/IETF-QUIC/Charter/pull/14/files > > says "This work will consider deployability, manageability and > diagnosability of the wire format, including how the wire format will be > processed by devices on path". I don't think that makes doing anything for > the path required, but it does make it possible to have the conversation. > If we're worried about this language requiring changes to the protocol, > rather than allowing for the conversation, we can of course continue to > tweak the language. > > From a previous message of yours: > > > And - pet peeve - there is really no need for binding timeouts for TCP > or UDP to begin with. No binding needs to be timed out until the middlebox > runs out of memory, because as long as there are sufficient resources, why > bother managing all these timeouts? > > One of the reasons people give for this is the concern that traffic will > be allowed in from the outside to boxes and applications that are no longer > expecting the traffic. Since they believe that many older UDP protocols > don't have adequate security measures in place to authenticate, authorize, > or sessionize traffic, they just block it all except for the protocols > where they do deeper inspection, such as DNS. It is not because these > administrators are idiots, or because they have misconfigured their boxes > unintentionally. > It's fairly straightforward to work around NAT binding timeouts by considering the 4-tuple as transient over the lifetime of a connection. We routinely see NAT rebindings during live QUIC connections, and as long as the server infrastructure routes based on ConnectionID and not on the 4-tuple, things ought to work out just fine. Resilence to NAT rebindings will be required anyways, since no matter what you specify NATs do, there will be a long and heavy tail of those that will continue to drop bindings. Geoff Huston pointed out a little while ago that there is a localized preponderance of NATs (don't recall exactly where) that currently drop bindings every some seconds. QUIC, or any transport for that matter, will have to handle the common case of NATs that don't follow any specified behavior or constants. - jana > Many of the folks that block UDP *do* update their firewall software > often, and do review their security stance on blocked protocols > periodically. They will want their users to be able to take advantage of > the benefits of QUIC, so they will have incentives to do the review. We > need to at least provide them with the tools to do this review, such as > security considerations that tell an administrator how to continue to > protect their network from unknown UDP protocols while allowing QUIC. > > -- > Joe Hildebrand > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --001a114e6c003a48190536ec5403 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jun 30, 2016 at 9:42 AM, Joe Hildeb= rand (jhildebr) <jhildebr@cisco.com> wrote:

> On Jun 30, 2016, at 9:21 AM, Eggert, Lars <lars@netapp.com> wrote:
>
> Hi,
>
> On 2016-06-30, at 16:46, DRUTA, DAN <dd5826@att.com> wrote:
>> What's important is to understand and capture the reasons why = IT Administrators are blocking UDP. Some are as you pointed out not related= to the technology but we need to make sure they get the right level of man= ageability with QUIC in order troubleshooting legitimate traffic and preven= t attacks.
>
> again: why? We're talking about less than 10% of the paths, and HT= TPS over TCP readily available as an alternative on those paths, supposedly= with all the manageability that IT admins need.

We're talking about less than 10% of the paths that were measure= d by one experiment.=C2=A0 I don't yet know how reproducible that is.= =C2=A0 Again, it's 100% of the flows on my network, and on that of many= other enterprise networks where I have deployed software in the past.

I guarantee that we will deploy new software for our firewall if it's p= ossible to do so in a way that we don't have to update for every newly-= popular version number that someone in the QUIC world decides to deploy.
> My personal viewpoint is that I wouldn't want to complicate the pr= otocol or even slightly weaken its security for such a small subset of path= s (some of which may end up unblocking UDP port 443 anyway.)

If QUIC was only ever going to be used on 443/udp, some of the detec= tion issues would be easier.=C2=A0 Right now, the prototype code I've s= een for the QUIC state tracker hardcodes individual version numbers to look= for the traffic that needs to be tracked - but the developer is just tryin= g to intuit what he's supposed to do from what has been written so far.=

I don't think anyone has proposed weakening QUIC's security yet.=C2= =A0 If they did, the working group should have a thoughtful discussion of t= he tradeoffs involved, and I would expect security to win out almost every = time.=C2=A0 It may be that certain security measures could be implemented i= n different ways to solve multiple problems, for instance.

Mostly, I would like to see the assumptions that folks are making about how= the path might interact with the bits that are already explicitly exposed = to the path by the current protocol be discussed, then written down.

> I'd be open to the WG reviewing concrete proposals someone may hav= e in this space once the WG is underway, but I wouldn't want to see cha= rter text making it a requirement for QUIC to do anything about such paths,= since we really don't know what fulfilling this requirement may actual= ly entail.

Brian's proposed text here:

https://github.com/IETF-QUIC/Charter/pull/14/files

says "This work will consider deployability, manageability and diagnos= ability of the wire format, including how the wire format will be processed= by devices on path".=C2=A0 I don't think that makes doing anythin= g for the path required, but it does make it possible to have the conversat= ion.=C2=A0 If we're worried about this language requiring changes to th= e protocol, rather than allowing for the conversation, we can of course con= tinue to tweak the language.

>From a previous message of yours:

> And - pet peeve - there is really no need for binding timeouts for TCP= or UDP to begin with. No binding needs to be timed out until the middlebox= runs out of memory, because as long as there are sufficient resources, why= bother managing all these timeouts?

One of the reasons people give for this is the concern that traffic = will be allowed in from the outside to boxes and applications that are no l= onger expecting the traffic.=C2=A0 Since they believe that many older UDP p= rotocols don't have adequate security measures in place to authenticate= , authorize, or sessionize traffic, they just block it all except for the p= rotocols where they do deeper inspection, such as DNS.=C2=A0 It is not beca= use these administrators are idiots, or because they have misconfigured the= ir boxes unintentionally.

It's fair= ly straightforward to work around NAT binding timeouts by considering the 4= -tuple as transient over the lifetime of a connection. We routinely see NAT= rebindings during live QUIC connections, and as long as the server infrast= ructure routes based on ConnectionID and not on the 4-tuple, things ought t= o work out just fine.

Resilence to NAT rebindings will b= e required anyways, since no matter what you specify NATs do, there will be= a long and heavy tail of those that will continue to drop bindings. Geoff = Huston pointed out a little while ago that there is a localized preponderan= ce of NATs (don't recall exactly where) that currently drop bindings ev= ery some seconds. QUIC, or any transport for that matter, will have to hand= le the common case of NATs that don't follow any specified behavior or = constants.

- jana
= =C2=A0
Many of the folks that block UDP *do* update their firewall software often,= and do review their security stance on blocked protocols periodically.=C2= =A0 They will want their users to be able to take advantage of the benefits= of QUIC, so they will have incentives to do the review.=C2=A0 We need to a= t least provide them with the tools to do this review, such as security con= siderations that tell an administrator how to continue to protect their net= work from unknown UDP protocols while allowing QUIC.

--
Joe Hildebrand


_______________________________________________
QUIC mailing list
QUIC@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/quic


--001a114e6c003a48190536ec5403-- From nobody Wed Jul 6 00:09: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 CC5D612D68F for ; Wed, 6 Jul 2016 00:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.328 X-Spam-Level: X-Spam-Status: No, score=-3.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426, 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 b2TIz1UDCLvu for ; Wed, 6 Jul 2016 00:09:09 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA7E12D67E for ; Wed, 6 Jul 2016 00:09:09 -0700 (PDT) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id B796C1A02BE; Wed, 6 Jul 2016 09:08:37 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_EA59B14C-EE67-4D1F-9886-B9843B8F3AD3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Wed, 6 Jul 2016 09:08:39 +0200 Message-Id: <06F0F633-5050-4DA3-9BE3-1EDC84355D38@trammell.ch> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> <826872D6-FB13-499D-B134-EB5005DE9ACA@cisco.com> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , "Eggert, Lars" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [QUIC] Network Path Requirements for QUIC 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, 06 Jul 2016 07:09:12 -0000 --Apple-Mail=_EA59B14C-EE67-4D1F-9886-B9843B8F3AD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, One tiny point, inline... (All: note that quoting is completely hosed by some long-standing = incompatibility between Gmail and Apple's MUA that I *really* wish = someone would fix already. Refer to other messages in the thread on = quic@ietf.org to figure out who said what.) > On 06 Jul 2016, at 01:43, Jana Iyengar wrote: > - As I wrote earlier, the 94% reachability in the client-server = scenario has been independently verified by WebRTC deployments, by = measuring the percentage of connections that go over a TURN server. This = ends up being ~15%, which is makes sense given that it's p2p and = therefore encounters ~2x the number of middleboxes than client-server = connections do. >=20 > - Calling the current QUIC deployment "one unrepeatable experiment" is = technically accurate, but doesn't really reflect the scale of things. = Most Chrome->Google traffic flows over QUIC, and that's a pretty massive = and diverse population. >=20 > - The network-requirements draft has two separable parts: (i) which = middlebox behaviors are important, and (ii) what information is = necessary for that middlebox behavior to be implemented. (ii) makes no = sense without (i), and we do not have consensus on (i)... and that = discussion should happen elsewhere, not in the QUIC wg, since any of = these considerations ought to apply to *any* protocol over UDP, = including WebRTC's SRTP/UDP or SCTP/DTLS/UDP stacks, Tom Herbert's = Transports-over-UDP stacks, and also proprietary FaceTime, RTMFP, Skype, = Xbox protocols. > >> Brian's proposed text here: > >> > >> https://github.com/IETF-QUIC/Charter/pull/14/files > >> > >> says "This work will consider deployability, manageability and = diagnosability of the wire format, including how the wire format will be = processed by devices on path". I don't think that makes doing anything = for the path required, but it does make it possible to have the = conversation. If we're worried about this language requiring changes to = the protocol, rather than allowing for the conversation, we can of = course continue to tweak the language. > > > > That's at least my personal worry - that text is pretty broad. I'd = be happier with a statement along the lines you stated above, i.e., that = the WG may document assumptions about how boxes along the path might = interact with exposed protocol information. That - to me - makes it = clearer that it isn't a goal to make protocol changes in the hopes of = making it comply with whatever enterprise IT admins may define as = policy, based on the knobs their middlebox software is at the moment = exposing. >=20 > Can you propose text that you would find appropriate, please? >=20 > I agree with Lars, but there's something else that's implicit in here = which I don't think we have a handle on. Which interactions are = important to describe? Personally, I don't think this is the right = working group to have that discussion, modulo the considerations that = will happen organically anyways (as I said, similar to what happened = with MPTCP.) I still don't think it's necessary to have that language in = the charter to "protect" that conversation. OTOH, I worry as Lars that = leaving broad text will cause folks to bring up various = middlebox-related conversations that really shouldn't be in this wg. >=20 > PLUS is a great place to have the conversation about which middlebox = interactions are important to describe; any outcomes of that wg will = naturally influence QUIC later. I completely and wholeheartedly agree! There seems to be a concern here about the = effects of QUIC deployment on currently deployed middleboxes used in = network operations, and the operational practices surrounding them, as = well as the effects devices currently deployed will have on QUIC when = QUIC servers are widely operated by more than a single content provider. = Consensus on the details of the problem, I agree, are much wider than = QUIC, and as such should happen elsewhere. But addressing this concern = *within the scope of the QUIC protocol design* seems to be very much in = the scope of a QUIC WG. Using your terminology above, if (ii) depends on = (i), even if (i) is out of scope, this does not automatically absolve = the QUIC WG of responsibility to address (ii) with respect to QUIC. = (On the "single content provider" point: I buy your argument that Chrome = represents a relatively diverse client population. I strongly suspect = that Chrome->Google traffic is comparatively blind to precisely the kind = of managed access environments that Joe is concerned about: you have = zero data about networks where users are not allowed by policy to = install Chrome, for example. But there is an implicit assumption made in = QUIC's detection and fallback mechanisms that the problem lies close to = the client, which is completely valid in Google's case. Diversity of = server environments will test this assumption, and will need to be = considered in protocol design.) Since we've identified PLUS as a great place to have this conversation, = we could also anchor that in the charter to address this concern. If = PLUS had already been chartered was a running WG, and had a milestone to = define the properties of middlebox functions with which transports = should cooperate (which I note the draft PLUS charter does not yet), we = could do this with a reference thereto in the QUIC charter: NEW (new para 10 inserted after para 9, beginning with "Note that = consensus is required..."): The working group will consider the output of the PLUS working group in = determining how the protocol will interact with devices on path. (Perhaps with a reference to QUIC in the PLUS charter to make it clear = to the future PLUS WG that they should play nice, too. :) ) But (1) PLUS isn't chartered yet, and (2) we won't even know how likely = it is to be chartered until after the PLUS BoF, which takes place after = the QUIC BoF. Further, (3) this would add a dependency on a working = group we have reason to suspect will take longer to come to consensus on = (i) than QUIC should be willing to wait on. Of course, versioning allows = us to tweak the protocol to be more explicitly cooperative in the future = (unless, of course, as Joe points out, on-path abuse of the versioning = mechanism makes it difficult to actually use in practice, which may = require ), so a future QUIC can certainly depend on PLUS. None of this = fixes the problem today, though, which is why I proposed PR #14. If there's concern that PR #14 opens the door to doing things in QUIC = that really are outside the scope of making QUIC widely deployable, then = I'd also like to see a counterproposal. I've been staring at it for a = while and can't come up with a meaningful way to restrict it without = losing its essence: "QUIC's design should consider how it interacts with = current operational practice and the subset of stuff on path that it = makes sense to interact with." (Indeed, IMO that phrasing is a good deal = less restrictive, because "current operational practice" can be = interpreted to well beyond "manageability and diagnosability".) Cheers, Brian --Apple-Mail=_EA59B14C-EE67-4D1F-9886-B9843B8F3AD3 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 iQIcBAEBCgAGBQJXfK54AAoJEIoSt78L6kajesgP/0WMyT30G0U0eGV0D70StSTe KD3nfc0CWe6k/h30cnMFvbBCgnfhFa2NaLt3DyxN1bxlBHYyQV/ImNuA10wFlmVM BDt2vCW4sFWqMtz9dx1hL842bed5C8TfdcvTwvU/moLaAENzdYaKuajb0M7DT4l1 oJ0b4Xu+lC8foWPJoSvgUhODmZMJos2oToDMAR56u6FKslD4X1oWmLQfQnIme2gj KX5rccgciGSOrGLjzwB9KBCnUY2XAsEiH1+b3Ttr0r0Q53ui8gn9EYI0CS/qhNU4 YhEe32+oeO3k0sX1hV0AMvKZmcwuCZ99kyUVQbuLhNWHSm/Qnh2xIbsMcgTLv2vl De6qSmItrXm4Go2Wv9nJnc9ueSzp1XKZePWpFLTRZvjYN5rkCPuQlRQJfdcjRjZd oFRccfltaJxXSxLvAW1CCqzNSjjXN6Opsi4BUmr12tRF5RTkr4MBSgj6ZNr8pKji BqssIhh/GmL0Mn8zgkp+bMAQ9lzWn3cOc5LvOQEvD8P7uhMRss9LP3hCtRQwu+mL qrazqLrUCAIdYFvaklcF/e2dKOR2UGEv5EGp3cQdPvtyUbzPnabR57zVCWy/fC6W ukO2bMzDMtZoFNgHe8dOa1V1z0Bi0ZQaE/8oCbl4Yr/HG4kaojGIdLFM2NrjQ2bK 7E4Aiu/3FjPXLzFQhUDt =TXrp -----END PGP SIGNATURE----- --Apple-Mail=_EA59B14C-EE67-4D1F-9886-B9843B8F3AD3-- From nobody Fri Jul 8 15:53: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 891F912D1D5 for ; Fri, 8 Jul 2016 15:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.126 X-Spam-Level: X-Spam-Status: No, score=-4.126 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.426, 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 JmRtPTAS04CO for ; Fri, 8 Jul 2016 15:53:30 -0700 (PDT) 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 8E77712B050 for ; Fri, 8 Jul 2016 15:53:30 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id j17so49190392ywg.0 for ; Fri, 08 Jul 2016 15:53:30 -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=j27an4Ww4Xu/dLhlBm7ybsUAGD2FEu99ekyvibKoWlo=; b=fxo41AEX2KeSKUp4Dc/jNcd9GJEnoB+wIdytGp2C2VOKU1jTEAcwhWWBso1s/pAdqX 26IVCugaQmGQRLEdy1JtvRRaX0LTDlOzm8nvaXQeqCk36iAvlTYfi6y57vYartQWvKqW AH4RNBiECatpU3R0O7VJtMh1zNUA0Azktq2mh0tPFLlf+yFOydxNii+TyQxDt/X6iA/R mxv0CyBM+TE7Elcl23NZuOMtoI+adqdwXPcx12VzMJmkzUQAsSYZJog36g6qnMhmJgOA BVjFJGIsG/HbEbJkxPRHorNUlBlZaSAJ9YXf5OUcWF2YQvb0+ZwOyrG+1MyUkyPeJf55 uETA== 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=j27an4Ww4Xu/dLhlBm7ybsUAGD2FEu99ekyvibKoWlo=; b=P+LQrHeF/ur5ID9+kp7xW4Avq1g75syzpRlNgSusFeJnq7XHcYQlkWt0dcEq6d7Jr4 ke8xplHo5I7lKCaxfrZreZsoQP+XBUazVL+L/Dltmv0xOM5wZcoGiZjxTHur5JkxB922 fb2iZkUd4NViKYhkGyhvniM/htp7ZXcmufN4zW76tAvIskEya3YKaFSbHs1S7BEza49p m9dMmDkS7QOoE2MVr7q2GKLcdrOsYw0arFLX+25B3H8FyLk7BdrjrA8l8vtRabBs4eGt 1q5pPfPKONY9+o89OFeRrNvTQ7THWO3lwq/Y3Tmat4NP4ePcS5icRFMrp/WvGopMYyTf EWWg== X-Gm-Message-State: ALyK8tI0pEW8AiPdMIF0nAFKOpHOoUky6RKHsykQskYmxWuQcACCXfkUWijJySiszXZ+GdL4UgQTymkxY0qgdaXV X-Received: by 10.129.161.86 with SMTP id y83mr6145577ywg.190.1468018409602; Fri, 08 Jul 2016 15:53:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.211.65 with HTTP; Fri, 8 Jul 2016 15:53:29 -0700 (PDT) From: Jana Iyengar Date: Fri, 8 Jul 2016 15:53:29 -0700 Message-ID: To: quic@ietf.org Content-Type: multipart/alternative; boundary=001a114f8d26d47c56053727abd1 Archived-At: Subject: [QUIC] New set of QUIC drafts 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: Fri, 08 Jul 2016 22:53:32 -0000 --001a114f8d26d47c56053727abd1 Content-Type: text/plain; charset=UTF-8 Dear all, We have a new set of drafts that describes the various constituent parts of QUIC: QUIC transport protocol draft: https://datatracker.ietf.org/doc/draft-hamilton-quic-transport-protocol/ QUIC congestion control and loss recovery draft: https://datatracker.ietf.org/doc/draft-iyengar-quic-loss-recovery/ The use of QUIC as a transport for HTTP/2 is described in: https://datatracker.ietf.org/doc/draft-shade-quic-http2-mapping/ In addition, the use of TLS1.3 for QUIC's crypto handshake is described in: https://datatracker.ietf.org/doc/draft-thomson-quic-tls - jana (The earlier monolithic QUIC draft has been renamed, and is here: https://datatracker.ietf.org/doc/draft-hamilton-early-deployment-quic/) --001a114f8d26d47c56053727abd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=

We have a new set of drafts that describes the va= rious constituent parts of QUIC:
QUIC congestion control and loss recovery d= raft:=C2=A0https://datatracker.ietf.org/doc/draft-iyengar-quic-loss-rec= overy/
The use of QUIC as a transport for HTTP/2 is desc= ribed in:=C2=A0https://datatracker.ietf.org/doc/draft-shade-quic-http2-ma= pping/=C2=A0

In addition, the use of= TLS1.3 for QUIC's crypto handshake is described in:=C2=A0https://datatracker.= ietf.org/doc/draft-thomson-quic-tls

- jana
=

(The earlier monolithic QUIC draft has been = renamed, and is here:=C2=A0https://datatracker.ietf.org/doc/draft-h= amilton-early-deployment-quic/)


--001a114f8d26d47c56053727abd1-- From nobody Fri Jul 15 09:14: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 5E3AA12D7EA for ; Fri, 15 Jul 2016 09:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=verizon.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pFiVkGdvP75 for ; Fri, 15 Jul 2016 09:14:18 -0700 (PDT) Received: from omzsmtpe02.verizonbusiness.com (omzsmtpe02.verizonbusiness.com [199.249.25.209]) (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 4BF1512D7F7 for ; Fri, 15 Jul 2016 09:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1468599258; x=1500135258; h=from:to:cc:date:subject:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rGbJbtdAezCGYJWZVIVzvkulIGDzyf07HnAk3W8ipik=; b=Vz3iRMse/y07Up8DNcaPOerAaEsKNJInasL48d+txOevK1ZnJrKCTlXQ 9eDBvj9TjgVruNkLPbH2YlrMW9RahOce2Um07++3OKGikbTIpTuHlm2Kw yN6OB5f2BxM8OTAN1fJQOzCAaDBL1LqzeJNRDqmu/rndSemBOhMbnr2eh A=; X-IronPort-Anti-Spam-Filtered: false Received: from omzsmtpi02.vzbi.com ([165.122.46.172]) by omzsmtpe02.verizonbusiness.com with ESMTP; 15 Jul 2016 16:14:17 +0000 From: "Mishra, Sanjay" X-IronPort-AV: E=Sophos;i="5.28,368,1464652800"; d="scan'208";a="726153344" Received: from fhdp1lumxc7hb04.verizon.com (HELO FHDP1LUMXC7HB04.us.one.verizon.com) ([166.68.59.191]) by omzsmtpi02.vzbi.com with ESMTP; 15 Jul 2016 16:14:14 +0000 Received: from fhdp1lumxc7v23.us.one.verizon.com ([166.68.59.159]) by FHDP1LUMXC7HB04.us.one.verizon.com ([166.68.59.191]) with mapi; Fri, 15 Jul 2016 12:14:14 -0400 To: Brian Trammell , Jana Iyengar Date: Fri, 15 Jul 2016 12:14:12 -0400 Thread-Topic: [E] Re: [QUIC] Network Path Requirements for QUIC Thread-Index: AdHXVU9b5Izn7XiuR6GT7TRH79rVLAHXdXjQ Message-ID: <900A1E2059ADB149B905E3C8FA0046A62CED176926@FHDP1LUMXC7V23.us.one.verizon.com> References: <4AA3A95D6033ED488F8AE4E45F474487723C76D7@CAFRFD1MSGUSRJC.ITServices.sbc.com> <1CCE2DB5-E2F7-42D0-8F6C-37E1FABD6E21@netapp.com> <7E36DA9E-71C1-4017-83C4-6C5F5AD07E2C@trammell.ch> <4AA3A95D6033ED488F8AE4E45F474487723D402B@CAFRFD1MSGUSRJI.ITServices.sbc.com> <3901AE95-7289-4A32-BB73-8B3788785E05@netapp.com> <826872D6-FB13-499D-B134-EB5005DE9ACA@cisco.com> <06F0F633-5050-4DA3-9BE3-1EDC84355D38@trammell.ch> In-Reply-To: <06F0F633-5050-4DA3-9BE3-1EDC84355D38@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "DRUTA, DAN" , "quic@ietf.org" , "Eggert, Lars" , "Joe Hildebrand \(jhildebr\)" Subject: Re: [QUIC] [E] Re: Network Path Requirements for QUIC 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: Fri, 15 Jul 2016 16:14:20 -0000 Agree with Brian's statement below: ".... But addressing this concern *within the scope of the QUIC protocol de= sign* seems to be very much in the scope of a QUIC WG. Using your terminolo= gy above, if (ii) depends on (i), even if (i) is out of scope, this does no= t automatically absolve the QUIC WG of responsibility to address (ii) with = respect to QUIC. ". It is best to ensure the working group (if formed) charters its position th= at lays foundation for QUIC evolution and importantly quicker deployment. -Sanjay -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell Sent: Wednesday, July 06, 2016 3:09 AM To: Jana Iyengar Cc: DRUTA, DAN; quic@ietf.org; Eggert, Lars; Joe Hildebrand (jhildebr) Subject: [E] Re: [QUIC] Network Path Requirements for QUIC hi Jana, One tiny point, inline... (All: note that quoting is completely hosed by some long-standing incompati= bility between Gmail and Apple's MUA that I *really* wish someone would fix= already. Refer to other messages in the thread on quic@ietf.org to figure = out who said what.) > On 06 Jul 2016, at 01:43, Jana Iyengar wrote: > - As I wrote earlier, the 94% reachability in the client-server scenario = has been independently verified by WebRTC deployments, by measuring the per= centage of connections that go over a TURN server. This ends up being ~15%,= which is makes sense given that it's p2p and therefore encounters ~2x the = number of middleboxes than client-server connections do. >=20 > - Calling the current QUIC deployment "one unrepeatable experiment" is te= chnically accurate, but doesn't really reflect the scale of things. Most Ch= rome->Google traffic flows over QUIC, and that's a pretty massive and diver= se population. >=20 > - The network-requirements draft has two separable parts: (i) which middl= ebox behaviors are important, and (ii) what information is necessary for th= at middlebox behavior to be implemented. (ii) makes no sense without (i), = and we do not have consensus on (i)... and that discussion should happen el= sewhere, not in the QUIC wg, since any of these considerations ought to app= ly to *any* protocol over UDP, including WebRTC's SRTP/UDP or SCTP/DTLS/UDP= stacks, Tom Herbert's Transports-over-UDP stacks, and also proprietary Fac= eTime, RTMFP, Skype, Xbox protocols. > >> Brian's proposed text here: > >> > >> https://github.com/IETF-QUIC/Charter/pull/14/files > >> > >> says "This work will consider deployability, manageability and diagnos= ability of the wire format, including how the wire format will be processed= by devices on path". I don't think that makes doing anything for the path= required, but it does make it possible to have the conversation. If we're= worried about this language requiring changes to the protocol, rather than= allowing for the conversation, we can of course continue to tweak the lang= uage. > > > > That's at least my personal worry - that text is pretty broad. I'd be h= appier with a statement along the lines you stated above, i.e., that the WG= may document assumptions about how boxes along the path might interact wit= h exposed protocol information. That - to me - makes it clearer that it isn= 't a goal to make protocol changes in the hopes of making it comply with wh= atever enterprise IT admins may define as policy, based on the knobs their = middlebox software is at the moment exposing. >=20 > Can you propose text that you would find appropriate, please? >=20 > I agree with Lars, but there's something else that's implicit in here whi= ch I don't think we have a handle on. Which interactions are important to d= escribe? Personally, I don't think this is the right working group to have = that discussion, modulo the considerations that will happen organically any= ways (as I said, similar to what happened with MPTCP.) I still don't think = it's necessary to have that language in the charter to "protect" that conve= rsation. OTOH, I worry as Lars that leaving broad text will cause folks to = bring up various middlebox-related conversations that really shouldn't be i= n this wg. >=20 > PLUS is a great place to have the conversation about which middlebox inte= ractions are important to describe; any outcomes of that wg will naturally = influence QUIC later. I completely and wholeheartedly agree! There seems to be a concern here about the effects = of QUIC deployment on currently deployed middleboxes used in network operat= ions, and the operational practices surrounding them, as well as the effect= s devices currently deployed will have on QUIC when QUIC servers are widely= operated by more than a single content provider. Consensus on the details = of the problem, I agree, are much wider than QUIC, and as such should happe= n elsewhere. But addressing this concern *within the scope of the QUIC prot= ocol design* seems to be very much in the scope of a QUIC WG. Using your te= rminology above, if (ii) depends on (i), even if (i) is out of scope, this = does not automatically absolve the QUIC WG of responsibility to address (ii= ) with respect to QUIC. (On the "single content provider" point: I buy your argument that Chrome re= presents a relatively diverse client population. I strongly suspect that Ch= rome->Google traffic is comparatively blind to precisely the kind of manage= d access environments that Joe is concerned about: you have zero data about= networks where users are not allowed by policy to install Chrome, for exam= ple. But there is an implicit assumption made in QUIC's detection and fallb= ack mechanisms that the problem lies close to the client, which is complete= ly valid in Google's case. Diversity of server environments will test this = assumption, and will need to be considered in protocol design.) Since we've identified PLUS as a great place to have this conversation, we = could also anchor that in the charter to address this concern. If PLUS had = already been chartered was a running WG, and had a milestone to define the = properties of middlebox functions with which transports should cooperate (w= hich I note the draft PLUS charter does not yet), we could do this with a r= eference thereto in the QUIC charter: NEW (new para 10 inserted after para 9, beginning with "Note that consensus= is required..."): The working group will consider the output of the PLUS working group in det= ermining how the protocol will interact with devices on path. (Perhaps with a reference to QUIC in the PLUS charter to make it clear to t= he future PLUS WG that they should play nice, too. :) ) But (1) PLUS isn't chartered yet, and (2) we won't even know how likely it = is to be chartered until after the PLUS BoF, which takes place after the QU= IC BoF. Further, (3) this would add a dependency on a working group we have= reason to suspect will take longer to come to consensus on (i) than QUIC s= hould be willing to wait on. Of course, versioning allows us to tweak the p= rotocol to be more explicitly cooperative in the future (unless, of course,= as Joe points out, on-path abuse of the versioning mechanism makes it diff= icult to actually use in practice, which may require ), so a future QUIC ca= n certainly depend on PLUS. None of this fixes the problem today, though, w= hich is why I proposed PR #14. If there's concern that PR #14 opens the door to doing things in QUIC that = really are outside the scope of making QUIC widely deployable, then I'd als= o like to see a counterproposal. I've been staring at it for a while and ca= n't come up with a meaningful way to restrict it without losing its essence= : "QUIC's design should consider how it interacts with current operational = practice and the subset of stuff on path that it makes sense to interact wi= th." (Indeed, IMO that phrasing is a good deal less restrictive, because "c= urrent operational practice" can be interpreted to well beyond "manageabili= ty and diagnosability".) Cheers, Brian From nobody Mon Jul 18 10:05: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 EF59112D8B5 for ; Mon, 18 Jul 2016 10:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.188 X-Spam-Level: X-Spam-Status: No, score=-8.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, 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 05_jYezrcsJK for ; Mon, 18 Jul 2016 10:05:10 -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 AC5311288B8 for ; Mon, 18 Jul 2016 10:05:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,384,1464678000"; d="asc'?scan'208";a="128000121" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx143-out.netapp.com with ESMTP; 18 Jul 2016 10:00:07 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 18 Jul 2016 10:00:07 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::2c76:6bc2:2216:a24d%21]) with mapi id 15.00.1210.000; Mon, 18 Jul 2016 10:00:07 -0700 From: "Eggert, Lars" To: "quic@ietf.org" Thread-Topic: Wanted: Note takers and jabber watchers for the BOF Thread-Index: AQHR4RXWmG5Gqyc6t0GpkkfMpT6BBg== Date: Mon, 18 Jul 2016 17:00:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_230D9CF4-DBD9-48F2-82C3-53EC480B182B"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: [QUIC] Wanted: Note takers and jabber watchers for the BOF 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: Mon, 18 Jul 2016 17:05:17 -0000 --Apple-Mail=_230D9CF4-DBD9-48F2-82C3-53EC480B182B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I'd be great if we could line up at least one note taker and one jabber = watcher for the QUIC BOF. Any volunteers? Thanks, Lars --Apple-Mail=_230D9CF4-DBD9-48F2-82C3-53EC480B182B 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----- iQIcBAEBCAAGBQJXjQsYAAoJEFS1wwm/cMFX1vgQAMdqSnooCEdrt27/4G/iXFzT qwPI0Hx4Ow8gLLYSDjDcHFLd422fbnd45InijPfv9oyjnvVD9p8ODePjhGxohaZ4 3KwDzFpRS2D+vI8Ke23TkoI2I9lnY2Pf9Kvj80pW3qsBYFQUoaEFt/8386FwpJLT ZvnYzEsa/ueRnJN5hgsaRWXflRBxnhv7lFId2nR34ewNgMF1prINMMiK09+hRipY U3Ymuw8ygCP2k7Wv/NUV+WE6VKcmtykwPNyp1oWhwb9K8qOlgvdP/0Qj+KtBk9yC BBfOJhx0zf4VszRz8z/X24F8ujw7REDeM4/DEhhdpavWRRNo4ivV/PObtDOdwlKs MVQjUMDsDa36Vvwcwn0krv+D2kJagDVSQnDP3YDlFSoQbWk+l7PBX9+vKD7CUhIp 98MrdCxelohpDk+3IKfqWopoYUsfBI0KcGF6EfUBkB/xYS/RjwYimJdMFZ5mSKRy 31SjP8FW/ISyRmM9jP7vkBlPieReq5QFSxIAcplSrg8Wj/xaS+tO2IzS6FYIFVis h5HrgJ5R2kYqDU5defxQNI1wPdDAw12WARVXRhcF2qSEpVK3P++3xoE1e3cDO1YV zNbAbE167G+5uB6bHF8TBzfR77gXFYNb/+exdjaVqw7OB/4LhNN8XqXJUOEzleZN 5j3viCPh0DCGudiC0ntP =JJXZ -----END PGP SIGNATURE----- --Apple-Mail=_230D9CF4-DBD9-48F2-82C3-53EC480B182B-- From nobody Mon Jul 18 10:18: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 A9EAB12D0FA for ; Mon, 18 Jul 2016 10:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.188 X-Spam-Level: X-Spam-Status: No, score=-8.188 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287, 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 G2o94kXKMxCy for ; Mon, 18 Jul 2016 10:18:53 -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 054C012B053 for ; Mon, 18 Jul 2016 10:18:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.28,384,1464678000"; d="asc'?scan'208";a="128003632" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx143-out.netapp.com with ESMTP; 18 Jul 2016 10:13:51 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com (10.122.105.40) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 18 Jul 2016 10:13:50 -0700 Received: from HIOEXCMBX07-PRD.hq.netapp.com ([::1]) by hioexcmbx07-prd.hq.netapp.com ([fe80::2c76:6bc2:2216:a24d%21]) with mapi id 15.00.1210.000; Mon, 18 Jul 2016 10:13:51 -0700 From: "Eggert, Lars" To: "quic@ietf.org" Thread-Topic: [QUIC] Wanted: Note takers and jabber watchers for the BOF Thread-Index: AQHR4RXWGEtzGcEnxE+sdOiXXhD9LqAe4q+A Date: Mon, 18 Jul 2016 17:13:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.120.60.36] Content-Type: multipart/signed; boundary="Apple-Mail=_D585E0AE-3899-419A-BCEC-B28AEF8D3B88"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [QUIC] Wanted: Note takers and jabber watchers for the BOF 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: Mon, 18 Jul 2016 17:18:55 -0000 --Apple-Mail=_D585E0AE-3899-419A-BCEC-B28AEF8D3B88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii We got our volunteers! On 2016-07-18, at 19:00, Eggert, Lars wrote: >=20 > Hi, >=20 > I'd be great if we could line up at least one note taker and one = jabber watcher for the QUIC BOF. Any volunteers? >=20 > Thanks, > Lars > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic --Apple-Mail=_D585E0AE-3899-419A-BCEC-B28AEF8D3B88 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----- iQIcBAEBCAAGBQJXjQ5QAAoJEFS1wwm/cMFXUYgP/2vVrPVZUscYpcJcBscngqw8 GwWP6DQkiKsvaiZWigL7BBoBfRMShPj4VmR18diiii4nFbKMiHzmYq05OwSg6DRt Ta/otVFhjPIRVXWHRc4TrB3K8riMqy/2rmpRP1S1uAJhBJCiBFdKL9KB7q9BA0vr WR+yDeoyasrf11QNoQPpOcn4+/bMGbtPpYBg1offW3Ct5XVOipuD2MbVvphKhsw7 FpX9sA9zAipd30EDP4BZvMmpHu9DrTTy/uFGoc65WV/LTO2+ZNVwAprl3Dnd9BEY eRhlplVggDtMPijXwNHzj0ClyzJ6LSG7bZdVftCb0EtGH+gYC/n5hu1hmXzKGWzJ D/n+COCsazwlVyM5yucalxYK65bskdyWIFUPQ3jbynuafAWXxTFOT/sEZRKm915f HGQRLLALER10olBYeWlxvVDf28BWXdlc/qzwOg6kzwow3ZOQWt3snjqv2c80NSLi hdEY3ANcRggXp2K7QnMcK6xiTw+48Do5v2AwnsRpU/uQbIysnq/VI70X9fVtrmrM 6OKmTuzoaCs3bA/dWiJWYmcXARZ/FkwyPFd+snb+37WTSAX8U1s0pP8wsaGXI9QJ oY5h9Wscfar6OuotQB2W93D4Qjf/nLd1HDL937L9tBIeu1UFOfUzqfztLtMT0m73 hzcMBgfnosSqjyNNuF73 =OR2h -----END PGP SIGNATURE----- --Apple-Mail=_D585E0AE-3899-419A-BCEC-B28AEF8D3B88-- From nobody Wed Jul 20 08:58: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 4BC4812D7C6 for ; Wed, 20 Jul 2016 08:58:12 -0700 (PDT) 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, 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=ytti-fi.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 Hu9CMEr03mtJ for ; Wed, 20 Jul 2016 08:58:10 -0700 (PDT) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D76F812D661 for ; Wed, 20 Jul 2016 08:58:06 -0700 (PDT) Received: by mail-it0-x241.google.com with SMTP id u186so3737126ita.1 for ; Wed, 20 Jul 2016 08:58:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ytti-fi.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Aw9Smf6T4U4IORyi2TkzFFHF9NYgjBwFRxlEcYAnVmY=; b=GPfwwh3KLUPaOSdEJxA/dJSxVlmV6vdldllWavFACnMcx6Z+uV4ER1Ams0ORDssugq i+sZyHRQj3b4PEcLFTteVpQCZfPj2qLEgq5WOrF/jg2LU1sO2oF0IM2JNWiJ6KNHahxF T+lrbhOuFgqQrA6Yn2YRFieEJRBVQzdk3y6LKPkK/1RyvbK4F4KjRqdwXzrxJ1V27UE0 hDuLKuAKy0RC0AVUnY0aSEWUz2LMqJBDJDsLl77c9WSQeugt3B8yprzvvz8bHVnG9FCD nj9WsLb+D5kSM49evn1Fsua92gAuWQmlOXFuK8Wt7y1QmMZfT0+3cM5YaLN53dn4zlyR vbRQ== 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=Aw9Smf6T4U4IORyi2TkzFFHF9NYgjBwFRxlEcYAnVmY=; b=EqBzD/aKPviCnjs7JKWzaZZqL0IROcQUcmqQuPDCegRltYCSjubo8CmlTP0xgDmWER EAkodukCgw0dOvmBnAimf5cjnQLZV9nPs6u1R2te/Aq0oOQP238hnX7jr8bal6aGpynC l6Ike8wB3dRYHC6iDNFDUVaCQvRd8nJLSMz4bYOurBnqqkqm2AIPTxYdxdY3MZyOtt3a VsgSzubDXEHYJBJdC575PA5E+InVhHwbaHtzS1zCHsQe5w+FZC+7eifktBHWpiq7HMKh 7zxaHeQwbu3RC1UTFILNON+fb1IReRF/+l50HBNdBRCtMnsRI6VZqjQFKei0wekPzcwX 3WMA== X-Gm-Message-State: ALyK8tJ+p5vg9BP93pKMTESW2Aqn9767ConEYQ76IwnioS9gf+FOrUpTtqo2s/UQXdC0gZmSxshA4pwAbQoXMA== X-Received: by 10.36.188.65 with SMTP id n62mr61830496ite.61.1469030285903; Wed, 20 Jul 2016 08:58:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.19.74 with HTTP; Wed, 20 Jul 2016 08:58:05 -0700 (PDT) From: Saku Ytti Date: Wed, 20 Jul 2016 18:58:05 +0300 Message-ID: To: quic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [QUIC] QUIC, what features we need? 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, 20 Jul 2016 15:58:12 -0000 I really like QUIC, I think new L4 is key to great many advantages - It separates location (IP) and ID (encryption signature), allowing 'mosh' like mobility for all applications - it gives us 0 RTT UDP like behaviour, without amplification potential - it does packet pacing, removing need for expensive large packet buffers in the network - FEC seems like great idea, why is it being dropped? Too complex? MinimaLT has at least one feature QUIC does not have, it can present client a puzzle, before servicing client. Would this be useful in mitigating DDoS attacks? Could middlebox present the puzzles? Should/could QUIC provide VPN like behaviour? Imagine my employer gives me public key to sign my QUIC packets with. This signature is verified by my employers border router at wire-rate, it cannot decrypt anything, but it could verify the signature. If signature is OK, border router allows QUIC packet, otherwise it does not. Now in my linux box I could do something like ip route add 91.198.120.0/24 192.0.2.42 quic-sign XYZ. Or perhaps I'll do quic-sign policy based on process name. Of course protocol does not care how the signature ended up there, but I wanted to share what kind of possibilities it would open. If such signature capability would be added. Should it be deployable by NPU's shipping now or shipping soon? Some NPUs will support MacSec, could same hardware verify QUIC signature? -- ++ytti From nobody Wed Jul 20 09:02: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 58FCE12D824 for ; Wed, 20 Jul 2016 09:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.986 X-Spam-Level: X-Spam-Status: No, score=-3.986 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, RP_MATCHES_RCVD=-1.287, 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 aONXtH8EfE0r for ; Wed, 20 Jul 2016 09:02:33 -0700 (PDT) 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 9707F12D842 for ; Wed, 20 Jul 2016 09:02:33 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id j124so54534175ith.1 for ; Wed, 20 Jul 2016 09:02:33 -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=Yo3aWkMGxpN/RW0QrCkmCpsW7gMxuvXwgEKdWKk1MP4=; b=mQS1Pj7E8d/boZHpdv4xFnljSJ9zDTBUIYGvoSsxGh5TO+Nj2SVI0fF7ImMhheovy+ QbvYnrqkEoGPbJzY3mI+BzHH3Jm5Eg/L9PyQFh2NABX5bcDpTDwgDMgoy3q5E9JWU1Kf E68n94bCaWQfETpt8PFWeUZVJ8IzF96sXKbkfMqrdZhxpOdSslAHBMRVKq8KCxQTIGZ3 skz+YDE89c4YN887eKEHTXF0UBvDKZvrrX8GYpQILv/DJxjDEAsZRNuVJoLoL7GieWe6 viDhUUEMqpgnUDqHKomQgg5oaiLuEZz2o85RTvp8vl9NSllUITZYmlkYpffvqL5EMUsd pJcg== 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=Yo3aWkMGxpN/RW0QrCkmCpsW7gMxuvXwgEKdWKk1MP4=; b=MuHKVNL2ZMkLiVel1Kz4oJLGpy6LG/llVv4N8VADjbSBwF0rMNQWDAnuKzjGlxfoFm HV3w05kDNnTvF4KmD2c/LpLPIwQmOBKsf5hIIqnQR9UCVKHSw78j+yRY7U+5f3l2OCo/ G55FgsUrCE8ddnywH8RrjO/H78h6BlFFIPCSolC+MHI5FRgjR1B5+1zpM2T9PTMSjFAP dnaIO+fVuA1Km3qHnrchAHJfDeNIE9Qv3owOOjmR2XNGqYwSj+KLcvpOgbtQ2L2idDBJ 71PH6UF0R56g3lBqK663dTSNz5kDiBG3GyA75V90x7SXiNwPDvNHP6MdOVIllNf/9YJd Olfg== X-Gm-Message-State: ALyK8tIk0Lg6wAxwzgNUkDYhHITt21WE8sEibsYmJT/p4DB5fpcUpLQDq4e5+U55CzgHusyhnUvH4f/i6GQ97MMM X-Received: by 10.36.62.133 with SMTP id s127mr10557005its.98.1469030552689; Wed, 20 Jul 2016 09:02:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.15.73 with HTTP; Wed, 20 Jul 2016 09:02:13 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Wed, 20 Jul 2016 12:02:13 -0400 Message-ID: To: Saku Ytti Content-Type: multipart/alternative; boundary=001a113fe08c4279ff0538135470 Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] QUIC, what features we need? 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, 20 Jul 2016 16:02:40 -0000 --001a113fe08c4279ff0538135470 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 20, 2016 at 11:58 AM, Saku Ytti wrote: > I really like QUIC, I think new L4 is key to great many advantages > > - It separates location (IP) and ID (encryption signature), allowing > 'mosh' like mobility for all applications > - it gives us 0 RTT UDP like behaviour, without amplification potential > - it does packet pacing, removing need for expensive large packet > buffers in the network > - FEC seems like great idea, why is it being dropped? Too complex? > FEC is not being dropped permanently, only the original incarnation of FEC in QUIC, which only supported recovery of a single packet via XOR. See the FEC v1 summary for more details: https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit > > MinimaLT has at least one feature QUIC does not have, it can present > client a puzzle, before servicing client. Would this be useful in > mitigating DDoS attacks? Could middlebox present the puzzles? > > Should/could QUIC provide VPN like behaviour? Imagine my employer > gives me public key to sign my QUIC packets with. This signature is > verified by my employers border router at wire-rate, it cannot decrypt > anything, but it could verify the signature. If signature is OK, > border router allows QUIC packet, otherwise it does not. > Now in my linux box I could do something like ip route add > 91.198.120.0/24 192.0.2.42 quic-sign XYZ. Or perhaps I'll do quic-sign > policy based on process name. Of course protocol does not care how the > signature ended up there, but I wanted to share what kind of > possibilities it would open. > > If such signature capability would be added. Should it be deployable > by NPU's shipping now or shipping soon? Some NPUs will support MacSec, > could same hardware verify QUIC signature? > > -- > ++ytti > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > --001a113fe08c4279ff0538135470 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 20, 2016 at 11:58 AM, Saku Ytti <saku@ytti.fi> wrote:
=
I really like QUIC, I thi= nk new L4 is key to great many advantages

- It separates location (IP) and ID (encryption signature), allowing
'mosh' like mobility for all applications
- it gives us 0 RTT UDP like behaviour, without amplification potential
- it does packet pacing, removing need for expensive large packet
buffers in the network
- FEC seems like great idea, why is it being dropped? Too complex?

FEC is not being dropped permanently, only the = original incarnation of FEC in QUIC, which only supported recovery of a sin= gle packet via XOR.

=C2=A0

MinimaLT has at least one feature QUIC does not have, it can present
client a puzzle, before servicing client. Would this be useful in
mitigating DDoS attacks? Could middlebox present the puzzles?

Should/could QUIC provide VPN like behaviour? Imagine my employer
gives me public key to sign my QUIC packets with. This signature is
verified by my employers border router at wire-rate, it cannot decrypt
anything, but it could verify the signature. If signature is OK,
border router allows QUIC packet, otherwise it does not.
Now in my linux box I could do something like ip route add
91.= 198.120.0/24 192.0.2.42 quic-sign XYZ. Or perhaps I'll do quic-sign=
policy based on process name. Of course protocol does not care how the
signature ended up there, but I wanted to share what kind of
possibilities it would open.

If such signature capability would be added. Should it be deployable
by NPU's shipping now or shipping soon? Some NPUs will support MacSec,<= br> could same hardware verify QUIC signature?

--
=C2=A0 ++ytti

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

--001a113fe08c4279ff0538135470-- From nobody Wed Jul 20 09:15: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 B981412D83D for ; Wed, 20 Jul 2016 09:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 (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 knMV6_C95cw7 for ; Wed, 20 Jul 2016 09:15:28 -0700 (PDT) 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 3E65312D743 for ; Wed, 20 Jul 2016 09:15:28 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id j12so42654271ywb.2 for ; Wed, 20 Jul 2016 09:15:28 -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=upIHyH5a10xsjR1WOA2ZUNyREv132dBrdBpz/MaGsFw=; b=OtU6XOf6CQUZlOpR7Ds9l87jrALX0Yq80qiD4nMHFoNgkeqRQXzPUihO7QhQq7tPeN Ous8dV1h+ao77U4vact7/aDf08Xd3jRAOGkqp5uu/1naCZFYdp4qip3373j/+noZncmx 9gT2c74BxvtmT8K3lfNnltbIXU/g6jLzjclY9J5KSWXIR8Os/AvLieYV80IkYW7hQr0O Q/uXWRDnuEGEc7B/b/OOhhOLu/dB70ztHiCLt/HMRJgmlfnC+n0QYqN0njMK9oo3Kw7b D2FHRnVi4neMZvMrZ+cBPz6ce1FhSwtIcZ1MbkX6yq92dp1LzF//cvbgu6kvg1qqs+vC KDXg== 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=upIHyH5a10xsjR1WOA2ZUNyREv132dBrdBpz/MaGsFw=; b=GbSr7AN31/4LVF7Tipp4Ea9ABaa3xKHh+lGbzPcFxO92b+zXAPwYAqDZViUWE/8TCl QcA4jfEx8q5ThMr3vLKQaofLd4Bpm5nlfaNmigXHw/Af8P1ApiO9kWjHXRaJsYyGX9DM TyXohfUNJFCylJj+e2tiv3QPzLhDG7zBxhEDEKOQqzs4xEEXoonZ000yAjiAxqcNP1t6 12wKk/W/lAVVrwZQp6hRmtcEPxN+Pb1R3Q+HHoF9AVx2t+TyWcWxLsIqhewRXnQw8T61 ftqlfdCrAFjR7c4VdiCKY6hktyzfYGggT+oesF3hA+O58OjVQr/HH1r8nTXT/+jC7Mu4 K6nA== X-Gm-Message-State: ALyK8tLTGqWy5jjEH3Lppy974UBo/ICQpe2G7osmXidggNvkQIxwpLtBxFcpbZTSUoSUiWm7uoC+f0SPYdLMbg== X-Received: by 10.129.94.133 with SMTP id s127mr31888332ywb.69.1469031327234; Wed, 20 Jul 2016 09:15:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.231.20 with HTTP; Wed, 20 Jul 2016 09:15:26 -0700 (PDT) In-Reply-To: References: From: Spencer Dawkins at IETF Date: Wed, 20 Jul 2016 18:15:26 +0200 Message-ID: To: Ian Swett Content-Type: multipart/alternative; boundary=001a1149173c6c7d80053813829f Archived-At: Cc: Saku Ytti , quic@ietf.org Subject: Re: [QUIC] QUIC, what features we need? 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, 20 Jul 2016 16:15:31 -0000 --001a1149173c6c7d80053813829f Content-Type: text/plain; charset=UTF-8 Just to provide one more detail ... On Wed, Jul 20, 2016 at 6:02 PM, Ian Swett wrote: > On Wed, Jul 20, 2016 at 11:58 AM, Saku Ytti wrote: > >> I really like QUIC, I think new L4 is key to great many advantages >> >> - It separates location (IP) and ID (encryption signature), allowing >> 'mosh' like mobility for all applications >> - it gives us 0 RTT UDP like behaviour, without amplification potential >> - it does packet pacing, removing need for expensive large packet >> buffers in the network >> - FEC seems like great idea, why is it being dropped? Too complex? >> > > FEC is not being dropped permanently, only the original incarnation of FEC > in QUIC, which only supported recovery of a single packet via XOR. > One of the biggest reasons I sponsored the QUIC BOF was that the proposed charter includes an extension mechanism, so that extensions like FEC can be developed without bumping the QUIC version number. Once the extension mechanism is defined, things get easier. Spencer > See the FEC v1 summary for more details: > https://docs.google.com/document/d/1Hg1SaLEl6T4rEU9j-isovCo8VEjjnuCPTcLNJewj7Nk/edit > > >> >> MinimaLT has at least one feature QUIC does not have, it can present >> client a puzzle, before servicing client. Would this be useful in >> mitigating DDoS attacks? Could middlebox present the puzzles? >> >> Should/could QUIC provide VPN like behaviour? Imagine my employer >> gives me public key to sign my QUIC packets with. This signature is >> verified by my employers border router at wire-rate, it cannot decrypt >> anything, but it could verify the signature. If signature is OK, >> border router allows QUIC packet, otherwise it does not. >> Now in my linux box I could do something like ip route add >> 91.198.120.0/24 192.0.2.42 quic-sign XYZ. Or perhaps I'll do quic-sign >> policy based on process name. Of course protocol does not care how the >> signature ended up there, but I wanted to share what kind of >> possibilities it would open. >> >> If such signature capability would be added. Should it be deployable >> by NPU's shipping now or shipping soon? Some NPUs will support MacSec, >> could same hardware verify QUIC signature? >> >> -- >> ++ytti >> >> _______________________________________________ >> QUIC mailing list >> QUIC@ietf.org >> https://www.ietf.org/mailman/listinfo/quic >> > > > _______________________________________________ > QUIC mailing list > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --001a1149173c6c7d80053813829f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just to provide one more detail ...

On Wed, Jul 20, 2016 at 6:02 PM, Ian Swe= tt <ianswett@google.com> wrote:
On Wed, Jul 20, 2016 at 11:58 AM, Saku Ytti <saku@ytti.fi= > wrote:
I really like QUIC, I think new L4 is key to great many advantages

- It separates location (IP) and ID (encryption signature), allowing
'mosh' like mobility for all applications
- it gives us 0 RTT UDP like behaviour, without amplification potential
- it does packet pacing, removing need for expensive large packet
buffers in the network
- FEC seems like great idea, why is it being dropped? Too complex?

FEC is not being dropped permanently, on= ly the original incarnation of FEC in QUIC, which only supported recovery o= f a single packet via XOR.

One of the biggest reasons I sponsored the QUIC BOF was that the pr= oposed charter includes an extension mechanism, so that extensions like FEC= can be developed without bumping the QUIC version number.

Once the extension mechanism is defined, things get easier.
<= div>
Spencer
=C2=A0
=C2=A0

MinimaLT has at least one feature QUIC does not have, it can present
client a puzzle, before servicing client. Would this be useful in
mitigating DDoS attacks? Could middlebox present the puzzles?

Should/could QUIC provide VPN like behaviour? Imagine my employer
gives me public key to sign my QUIC packets with. This signature is
verified by my employers border router at wire-rate, it cannot decrypt
anything, but it could verify the signature. If signature is OK,
border router allows QUIC packet, otherwise it does not.
Now in my linux box I could do something like ip route add
91.= 198.120.0/24 192.0.2.42 quic-sign XYZ. Or perhaps I'll do quic-sign=
policy based on process name. Of course protocol does not care how the
signature ended up there, but I wanted to share what kind of
possibilities it would open.

If such signature capability would be added. Should it be deployable
by NPU's shipping now or shipping soon? Some NPUs will support MacSec,<= br> could same hardware verify QUIC signature?

--
=C2=A0 ++ytti

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


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


--001a1149173c6c7d80053813829f-- From nobody Wed Jul 20 09:34: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 D6CAF12D155 for ; Wed, 20 Jul 2016 02:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=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 zFObFD4rYEY8 for ; Wed, 20 Jul 2016 02:42:44 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 DEEF912D110 for ; Wed, 20 Jul 2016 02:34:07 -0700 (PDT) Received: from [10.47.60.74] (dhcp-b17d.meeting.ietf.org [31.133.177.125]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id u6K9Y3ED005183 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 20 Jul 2016 02:34:06 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host dhcp-b17d.meeting.ietf.org [31.133.177.125] claimed to be [10.47.60.74] From: "Paul Hoffman" To: quic@ietf.org Date: Wed, 20 Jul 2016 11:34:01 +0200 Message-ID: <1D661F17-68EE-4963-987B-8CC220990997@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: X-Mailman-Approved-At: Wed, 20 Jul 2016 09:34:53 -0700 Subject: [QUIC] Application semantic mapping 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, 20 Jul 2016 09:42:46 -0000 At the mic in the BoF, someone suggested that we add to the "Application semantic mapping: initial focus on HTTP/2" for other protocols. The current charter text is "The first mapping will be a description of HTTP/2 semantics using QUIC...". After that sentence, I propose "Additional mappings might be considered during the initial discussions, including DNS". --Paul Hoffman From nobody Wed Jul 20 09:41: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 8509612D8AD for ; Wed, 20 Jul 2016 09:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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 Ju1afCHrmT6N for ; Wed, 20 Jul 2016 09:41:38 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0111.outbound.protection.outlook.com [104.47.34.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 B394A12D8AB for ; Wed, 20 Jul 2016 09:41:37 -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=Zoc7Iigm8s/q3mNUG+J4DB0BWPYLIX8B60Mwlp+IES4=; b=fJ4mJPmBB7He7uEqSuluTfJQSSTr6xelRkPotgQillTXwS8oMQnLGNbAHLzv6BnHuNHzXShwlvUHQYokmEwMTkGOHdBP5l5VSudc2938+W5/ZL+32XEbefY7SMmhvBOGahSvItttXVTVQBPD1QhKG9xMVJWN6fqxdTEGexnVYcU= Received: from BLUPR03MB1330.namprd03.prod.outlook.com (10.163.80.20) by BLUPR03MB1330.namprd03.prod.outlook.com (10.163.80.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Wed, 20 Jul 2016 16:41:35 +0000 Received: from BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) by BLUPR03MB1330.namprd03.prod.outlook.com ([10.163.80.20]) with mapi id 15.01.0544.014; Wed, 20 Jul 2016 16:41:35 +0000 From: Mike Bishop To: Paul Hoffman , "quic@ietf.org" Thread-Topic: [QUIC] Application semantic mapping Thread-Index: AQHR4qSnwjz+/MuLKUSYgcLN/u0AV6AhhXww Date: Wed, 20 Jul 2016 16:41:34 +0000 Message-ID: References: <1D661F17-68EE-4963-987B-8CC220990997@vpnc.org> In-Reply-To: <1D661F17-68EE-4963-987B-8CC220990997@vpnc.org> 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:176:2039:4f7c:39e:1feb] x-ms-office365-filtering-correlation-id: 5dab0ca1-2cb6-4855-e62a-08d3b0bcb685 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1330; 6:1yIHgcSPr7/eg1WGBCCtH6uW5JRLQj/dqZdCmOmYXQvROxY7VRrty7stMN76SOe99fr7Kv9mbWyjQyCl1RxZZMISSgO3jTHAfoOSGLJr2jpYLFAyMbCW6bNKvKcuXVhjkwYsKzu+i5nbnJ+knW/GmGjuukEvOlZBpmZ6nzwgX723EQbZJnezcUP4wznpcKIJST2pTwoXZIO4pG5iLteT9G/Exlzf95Kra/Gh6ISTUvkG4YnBGkGS/uHo50SySoUFdXCP1cHt3sWadct2P+A/Z9I4gNioU3d6PyxwShz0cpXcANBTNogHdHOnEunkmTa+6Dsc51FwSf4elBSvVRNR6w==; 5:wyVBGkeNdSBl5NwSJtls0N0dbxh16BJynmQRWFdQ5OXjEcI+jre0mRgY2nWT1VaPJb7nBdDmf/5V/JGweCbzEdC1yQrST3UxwCYJCgPIARR2ogWn1JUMWeBecMaeNTspSLdLQH5+czmcD7UGwPKGqg==; 24:3zoJoS5TmYGNHPnkYIve8+JNNtvccS5/t1gHVg9E7ZDXO5QY2eQo4A5Yxr3TvvtfhYT8m2XLArRFELoVTQProOZiAjIFeoF74jF8LCvKRYU=; 7:XDOu5/yWMPma1mxrYk8vTc7KYk0OU9Q1UEqx4LugkutBnbcEtO8vmmIcR1ffIQqOL6QWyU7eHjyU/5LLddrdQ3bCIIqIWX/ou10ppkMvJwlKH1UU7n7W571lTmT7pqofcVShseAc/Rs6T4BB9skoROiUqdNBCGl05+SAfhzZ7PZPY6+kqnQfEUvdqyjE0mDi4T32wl/z2V+MHoc+trYUUfx5q6NX2DDsXMXrFQYvKdBn1G/4XU6pBM5z4kWhFSaS x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1330; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BLUPR03MB1330; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1330; x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(377454003)(13464003)(189002)(10090500001)(81166006)(81156014)(8676002)(8936002)(15975445007)(2501003)(33656002)(105586002)(586003)(11100500001)(77096005)(102836003)(6116002)(87936001)(2900100001)(2950100001)(99286002)(9686002)(19580405001)(19580395003)(10400500002)(10290500002)(86362001)(5002640100001)(3660700001)(54356999)(76176999)(97736004)(68736007)(5005710100001)(2906002)(122556002)(305945005)(101416001)(76576001)(92566002)(8990500004)(50986999)(5001770100001)(86612001)(74316002)(106356001)(7696003)(3280700002)(5003600100003)(7846002)(7736002)(107886002)(106116001)(189998001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1330; H:BLUPR03MB1330.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2016 16:41:34.9318 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1330 Archived-At: Subject: Re: [QUIC] Application semantic mapping 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, 20 Jul 2016 16:41:40 -0000 Perhaps make that more normative, requiring the working group to consider a= t least one additional application mapping? -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Wednesday, July 20, 2016 11:34 AM To: quic@ietf.org Subject: [QUIC] Application semantic mapping At the mic in the BoF, someone suggested that we add to the "Application se= mantic mapping: initial focus on HTTP/2" for other protocols. The current c= harter text is "The first mapping will be a description of HTTP/2 semantics using QUIC...". After that sentence, I propose "Additional= mappings might be considered during the initial discussions, including DNS= ". --Paul Hoffman _______________________________________________ QUIC mailing list QUIC@ietf.org https://www.ietf.org/mailman/listinfo/quic From nobody Thu Jul 21 06:30: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 1084B12D098 for ; Thu, 21 Jul 2016 06:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 CXTHhCanfVRY for ; Thu, 21 Jul 2016 06:30:13 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB47F12D1AC for ; Thu, 21 Jul 2016 06:30:12 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-61-5790ce61188e Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 45.09.18043.16EC0975; Thu, 21 Jul 2016 15:30:09 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.294.0; Thu, 21 Jul 2016 15:30:08 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8AfLtHEaiuYBGM+mvkHRu2T0VRXPuHHdMo/f5EeyRNc=; b=MoBgjq07m5vvcbzNt/njF7gccgQFOyej5AVwhr+rNO3u5rJ06MdCIMYiWymX3Cu4dbC0ozPrY3YsJ5woRdfGK0/xKUmNptFHvhrH8JBFdED40lpZmW4talls8tKo2dzB3D4dUhNt7IkXVYQH5ofcyHnNQOymsmbdr2XFEsArzWQ= Received: from AM3PR07MB292.eurprd07.prod.outlook.com (10.242.108.153) by AM3PR07MB290.eurprd07.prod.outlook.com (10.242.108.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Thu, 21 Jul 2016 13:30:06 +0000 Received: from AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::d44d:8d93:bcea:3b92]) by AM3PR07MB292.eurprd07.prod.outlook.com ([fe80::d44d:8d93:bcea:3b92%17]) with mapi id 15.01.0539.021; Thu, 21 Jul 2016 13:30:06 +0000 From: Zaheduzzaman Sarker To: "quic@ietf.org" Thread-Topic: clarification on multi-path migration Thread-Index: AdHjTk9V4KPAta5NQ6WEgjfR64+MWw== Date: Thu, 21 Jul 2016 13:30:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=zaheduzzaman.sarker@ericsson.com; x-originating-ip: [2001:67c:370:160:1069:d783:bafe:d31e] x-ms-office365-filtering-correlation-id: e5088442-a9a2-445f-e2a4-08d3b16b216c x-microsoft-exchange-diagnostics: 1; AM3PR07MB290; 6:pIxhq5APAj1MWw1Ogz5zwwy8IgBmeSrTRX314SiIe1uD+mAj+gt10WyuvA8aNhwvY9P0VtdGR3sKIvuhSTyImPLJYMqbk8usf4CBFcXZBUamasJ0h/C5TX+X1q3fRIAbQorcNcxsV3+ysiFgVCehlVG66dR9FzSroZlQrYmvV3eaZGUAD6cEHuYaGg7a7j9sgk8AFiWkaWRQ5SIRTHccsJ7adYCDz77MYiY4g0717iOSb8pgZrPga/luLwf2aRtsuAPPX2LBD0ywgecUwiuS374Y4K3nccUAf5zIPRvG7Xc=; 5:1If7uPnHs/QmDb2t0veM4pmKLf3lmnY9+TiHOHcONtwL7Lwa+zcRV99G4no9ZRj+pwps72TvKsL+I44MENCzKantsWlGux6gx6+7FPXohdBcYa6FFykGrJq/UwXb0JMFaeB8AMv6UISYhnm+3mQaaA==; 24:qsHWiKBVdWoesd+T6F/hXzQQeWJQMriQiyEBqrOqoDnrnCVnXPInIm2CH1UooH+uBWEyYf4IXPZRbpEP7pVULqBJqNDqQN9yAVBk6bTVZto=; 7:U6NGzsEX7PjSAtRcs/Gb0LRjbc3gzsyCCCDMyXhGqSYlhRfAPxWSb/hOOVi+AyR2jlx6wZZsOI0jdv6J33FFM+YDHPclfQrMdc5Rd9uBP036p3f9ZqWmuKZB9TGn1/c6WOtD3clUbbmeqHn4440x8mgpMSr9FZRqEamGFLAKwhFEGpwbawI2HNdbwEMi1yfgUtkCgqPjwBVrZWtghGcDhePJCByRbGKaFO/WiHUcCSy/lI/Ae3pZHwGPKcVGNMIb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB290; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AM3PR07MB290; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB290; x-forefront-prvs: 0010D93EFE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(2906002)(5002640100001)(105586002)(1730700003)(3660700001)(81156014)(8676002)(107886002)(110136002)(81166006)(6116002)(9686002)(15974865002)(33656002)(2900100001)(3280700002)(68736007)(3480700004)(15975445007)(189998001)(5640700001)(305945005)(74316002)(87936001)(7846002)(5003600100003)(7736002)(7696003)(97736004)(5250100002)(8936002)(229853001)(50986999)(86362001)(102836003)(92566002)(101416001)(450100001)(11100500001)(76576001)(586003)(106356001)(2501003)(54356999)(2351001)(19580395003)(19580405001)(3826002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB290; H:AM3PR07MB292.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_AM3PR07MB292F23F9541C6DAF0CC48049F090AM3PR07MB292eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jul 2016 13:30:06.7981 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB290 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUyM2J7iG7iuQnhBhd+61v0LOB2YPRYsuQn UwBjFJdNSmpOZllqkb5dAlfG5fkRBRuVKvbufcjUwLhTrouRg0NCwESiY6JSFyMnkCkmceHe erYuRi4OIYEjjBLzzrxgAUkICZxglPjxwwAkwSLQyyzxYM5lqKppTBJLTx1gg6h6yChxe7Iw yFQ2ARuJx4v9QMIiAsoSc5YuZgexhQX0JO5OWc0OETeWWHfmACuErScxue8BmM0ioCpxcs5j MJtXIEri47o+ZhCbEei676fWMIHYzALiEreezGeCuFpAYsme88wQtqjEy8f/WCHqkyWmfm1l g4hbSPxfN4kRwvaVuHT1LlTvWzaJA08CIWxXibuHzrFCAiVT4vnDSohwtMSUY11g70oIrGWU +LXyGNQcGYmuRweZIBL3WCU2zNgLDYdUieVrWxkhHpaSuHulE8qWkXhxZy8rxAP5ElNa1zJN YFSfheSfWUhSs8D+F5Q4OfMJC0RcT+LG1ClsELa2xLKFr5khbF2JGf8OsSCLL2BkX8UoWpxa XJybbmSkl1qUmVxcnJ+nl5dasokRmGAObvlttYPx4HPHQ4wCHIxKPLwKe/rDhVgTy4orcw8x SnAwK4nwLjs2IVyINyWxsiq1KD++qDQntfgQozQHi5I4r/9LxXAhgfTEktTs1NSC1CKYLBMH p1QDo7SbSYZ63KrWe9Ghve45i5dsv/Xs6jWu3NfsE7R3JD4rjkspEK/YHlBg4dlofXh2Pcvs y1yP5ptrR5n2b3+31Gn16baJgRoHVOcrGtZ4+H8VOWxw0T5x8bm8Ex8Pzeu3yc+aufmu4Iep HG9uNYXfmrt7kZdCQLHzy39XqiyjOrmybFZs2TxrixJLcUaioRZzUXEiANIkzP4sAwAA Archived-At: Subject: [QUIC] clarification on multi-path migration 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: Thu, 21 Jul 2016 13:30:18 -0000 --_000_AM3PR07MB292F23F9541C6DAF0CC48049F090AM3PR07MB292eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, what exactly does "connection migration" mean in the charter in the context= of current QUIC design? As I can see in the current QUIC design, a QUIC connection is identified by= a connection ID. Hence, there will be no need to migrate the connection bu= t change data send/receive over different interface/path. Also I would like to know what does the "migration" mean in the context of = multi-path in the charter? BR Zahed =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D ANM ZAHEDUZZAMAN SARKER Services, Media and Network Features Eircsson Research Ericsson Laboratoriegr=E4nd 11 97128 Lule=E5, Sweden Phone +46 10 717 37 43 Mobile +46 76 115 37 43 Office +46 76 115 37 43 Fax +46 920 996 21 zaheduzzaman.sarker@ericsson.com www.ericsson.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=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_AM3PR07MB292F23F9541C6DAF0CC48049F090AM3PR07MB292eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
what exactly does “connection migration” mean in the chart= er in the context of current QUIC design?
 
As I can see in the current QUIC design, a QUIC connection is identifi= ed by a connection ID. Hence, there will be no need to migrate the connecti= on but change data send/receive over different interface/path.
 
Also I would like to know what does the “migration” mean i= n the context of multi-path in the charter?
 
BR
 
Zahed
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D
ANM ZAHEDUZZAMAN SARKER

Services, Media and Network Features
Eircsson Research

Ericsson=
Laboratoriegr=E4nd 11
97128 Lule=E5, Sweden
Phone +46 10 717 37 43
Mobile +46 76 115 37 43
Office +46 76 115 37 43
Fax +46 920 996 21
zaheduzzaman.sarker@ericsson.com
www.ericsson.com<= /u>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=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_AM3PR07MB292F23F9541C6DAF0CC48049F090AM3PR07MB292eurprd_-- From nobody Fri Jul 22 06: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 E861C12D621 for ; Fri, 22 Jul 2016 06:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 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.287, 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=d3+jM/9s; dkim=pass (1024-bit key) header.d=greenbytes.de header.b=d3+jM/9s Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DEgZxcCNvyUT for ; Fri, 22 Jul 2016 06:07:20 -0700 (PDT) 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 0616B12D5E7 for ; Fri, 22 Jul 2016 06:07:19 -0700 (PDT) Received: by mail.greenbytes.de (Postfix, from userid 117) id 56E6A15A041A; Fri, 22 Jul 2016 15:07:18 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1469192838; bh=hhWJ2t053rxuwrJIASFI4UjPH2FZnn180+Gols+nb84=; h=Subject:To:References:From:Date:In-Reply-To:From; b=d3+jM/9sRIkRRkmxMFBdwEihykXZlAtJeFvbWMSE9bVwWo5DLUxoegGFETF8ooDGt Gi7ixAqjCEfcwK6Ud3MBQzcZtRR7fG9oIezaXIcb6k9njhybQxB3isousSlE7EyfQ2 Km1EdZyjwf+e38DWvMKadSd6ZIcXEdQ0OG5ho6YM= Received: from [192.168.43.32] (unknown [89.204.139.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail.greenbytes.de (Postfix) with ESMTPSA id 6BC4D15A041A; Fri, 22 Jul 2016 15:06:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=greenbytes.de; s=mail; t=1469192838; bh=hhWJ2t053rxuwrJIASFI4UjPH2FZnn180+Gols+nb84=; h=Subject:To:References:From:Date:In-Reply-To:From; b=d3+jM/9sRIkRRkmxMFBdwEihykXZlAtJeFvbWMSE9bVwWo5DLUxoegGFETF8ooDGt Gi7ixAqjCEfcwK6Ud3MBQzcZtRR7fG9oIezaXIcb6k9njhybQxB3isousSlE7EyfQ2 Km1EdZyjwf+e38DWvMKadSd6ZIcXEdQ0OG5ho6YM= To: Jana Iyengar , quic@ietf.org References: From: Julian Reschke Message-ID: Date: Fri, 22 Jul 2016 14:54:11 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [QUIC] draft-shade-quic-http2-mapping 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: Fri, 22 Jul 2016 13:07:23 -0000 Hi there, thanks for splitting the documents. Here are some early comments on draft-shade-quic-http2-mapping. At some point we'll need to decide what HTTP/2-over-Quic is. Is it just a mapping to a different mapping to a different transport, or is it the next major revision of HTTP, thus essentially HTTP/3. I'm asking because these seem to be conflicting goals, and it would be good to clarify that as soon as possible. That said: The slides showed in the IETF Berlin Bof session specifically mentioned that a client success rate of 93% might be good enough (or close to that), as we can always fall back to HTTP/2-over-TLS. I do not disagree with that, but it essentially means that the client-visible semantics MUST be the same as for HTTP/2 (in particular as HTTP/2 over TLS in theory could fall back to HTTP/1.1 over TLS). The impact of this might be different for a browser such as Chrome compare to other users of HTTP. Now looking at Section 2, "QUIC advertisement", specifically: > 2. QUIC advertisement > > A server advertises that it can speak HTTP/2-over-QUIC via the Alt- > Svc HTTP response header. It does so by including the header in any > response sent over a non-QUIC (e.g. HTTP/2 over TLS) connection: > > Alt-Svc: quic=":443" Well, you'd need to register an ALPN identifiers "quic" for that. The problem is that (AFAIU) APLN tokens in theory are used to negotiate protocols over TLS, which is not the case here. I know that there are precedents with that, but if we really want to turn ALPN identifiers into a generic protocol negotiation mechanism, we really should talk to the TLS WG and potentially revise RFC 7301. (Alternatively, we could revise Alt-Svc, in which case you should talk to the HTTPbis WG). > In addition, the list of QUIC versions supported by the server can be > specified by the v= parameter. For example, if a server supported > both version 33 and 34 it would specify the following header: > > Alt-Svc: quic=":443"; v="34,33" That would require registration in the "Alt-Svc Parameter Registry" (RFC 7838, Section 7.3). That said, while working on HTTP/2 we did *not* use the final ALPN token, but just used the draft names as tokens; that seems to be much simpler, more robust, and doesn't require (a) registering an extension parameter and (b) properly parsing it. > ... Best regards, Julian From nobody Fri Jul 22 07:40: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 289B012D5CE for ; Fri, 22 Jul 2016 07:40:20 -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 ieAAkH6Vqq8h for ; Fri, 22 Jul 2016 07:40:17 -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 85A2012DB08 for ; Fri, 22 Jul 2016 07:40:17 -0700 (PDT) Received: from dhcp-b2b0.meeting.ietf.org (unknown [31.133.178.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 01DC422E256; Fri, 22 Jul 2016 10:40:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mark Nottingham In-Reply-To: Date: Fri, 22 Jul 2016 16:40:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0C259459-718A-46BD-B78D-F4FAFFA35AA4@mnot.net> References: To: "Julian F. Reschke" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , quic@ietf.org Subject: Re: [QUIC] draft-shade-quic-http2-mapping 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: Fri, 22 Jul 2016 14:40:20 -0000 > On 22 Jul 2016, at 2:54 PM, Julian Reschke = wrote: >=20 > Hi there, >=20 > thanks for splitting the documents. Here are some early comments on = draft-shade-quic-http2-mapping. >=20 > At some point we'll need to decide what HTTP/2-over-Quic is. Is it = just a mapping to a different mapping to a different transport, or is it = the next major revision of HTTP, thus essentially HTTP/3. >=20 > I'm asking because these seem to be conflicting goals, and it would be = good to clarify that as soon as possible. That said: >=20 > The slides showed in the IETF Berlin Bof session specifically = mentioned that a client success rate of 93% might be good enough (or = close to that), as we can always fall back to HTTP/2-over-TLS. I do not = disagree with that, but it essentially means that the client-visible = semantics MUST be the same as for HTTP/2 (in particular as HTTP/2 over = TLS in theory could fall back to HTTP/1.1 over TLS). The impact of this = might be different for a browser such as Chrome compare to other users = of HTTP. To be more explicit -- this turned out to be a sticky point in the = HTTP/2 work; because we were chartered to be suitable for all common = uses of HTTP, we needed to support it for both HTTP and HTTPS URLs, to = the disappointment of those who felt that the new protocol was only = suitable for HTTPS. A fair amount of confusion / wrangling could be saved by some thoughtful = chartering here, I suspect... By the way, I wouldn't say "fall back to HTTP/1" -- it's more "fail to = upgrade to HTTP/2." Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Sat Jul 23 01: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 B326E12B056 for ; Sat, 23 Jul 2016 01:46:05 -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 GE21x3FepGC3 for ; Sat, 23 Jul 2016 01:46:04 -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 00E2912D5BF for ; Sat, 23 Jul 2016 01:46:03 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id s63so120205005qkb.2 for ; Sat, 23 Jul 2016 01:46:03 -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=4ObYXmtoV4gqfc1ffcInl9txJii/8f6MXwfN0aFkVDQ=; b=IAVFxP+Q1hl/MmBNBQE3JPw2uc5Ds40HWV0TXC7Jn+d0EfYz0tjZEek1xPGwtaoNLS e4HVTUwkInUMEpaVXJs4NgglTwGYqMuHCAPxT1uVl4NTIAFgBjcRj5sJQELWDewg2Wg0 HwTtESu6pUsYubFkG7FtmdeAvnnvAmLKvAsupAhPYG77JwvbM/dvDcY+r7055N3PlGeo CBCsyJuIY7iilsi1dNeHM0IDjX6rW6uR9mjRUaPBlS78AgPFFG4V97Od9eyUmPeE1CsH sIUzxgnYNsyzdgpYGWmAVHCM+vWYmvHFUVcOuz3lDR1Os4lEmDqFODa2jTRM/ucSkGTE OG9Q== 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=4ObYXmtoV4gqfc1ffcInl9txJii/8f6MXwfN0aFkVDQ=; b=fpwZD53y3qlcRJaFeiU2V2h43Vef9lagH+PH9lYCAEdljwloK6F6ZKQWBfBQCYADbO LaH+NCo2LkreB72G6KsOW5TcaGtSuBk8q25hWE9ARszdXijAIbm5KNjaorfWR9ERm6aQ FeLQXmr9EAI+eakOwff/dmFYQ2ICcI2COXiHBIHjGMpCOWBPFDBF3rkvpJEqRU0AhZIf QkjqW66SFXjNF5i0XpUauJlyaD2HWv6A2X5zvcp64jkd+Gqljqwn3jHbN2MHrqtoTD37 MiHeWnsoZfwtO4PtoVJkm08HT2fqytxetTKtFJsUP1k1jVl6KFXTK+K8374wa5qGJkzH QzQw== X-Gm-Message-State: AEkoouu/vYwjU2z7MgFFVU9bOYSP0x1fOEQwxAA27czrohTMFU+iYFmKSHzZ9BJCxKvWP3PKNSgu/qe7dg1TdQ== X-Received: by 10.55.203.156 with SMTP id u28mr10189304qkl.116.1469263563147; Sat, 23 Jul 2016 01:46:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Sat, 23 Jul 2016 01:46:02 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Sat, 23 Jul 2016 10:46:02 +0200 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jana Iyengar , quic@ietf.org Subject: Re: [QUIC] draft-shade-quic-http2-mapping 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: Sat, 23 Jul 2016 08:46:05 -0000 On 22 July 2016 at 14:54, Julian Reschke wrote: >> Alt-Svc: quic=":443" > > > Well, you'd need to register an ALPN identifiers "quic" for that. The > problem is that (AFAIU) APLN tokens in theory are used to negotiate > protocols over TLS, which is not the case here. I know that there are > precedents with that, but if we really want to turn ALPN identifiers into a > generic protocol negotiation mechanism, we really should talk to the TLS WG > and potentially revise RFC 7301. (Alternatively, we could revise Alt-Svc, in > which case you should talk to the HTTPbis WG). Since we plan to use TLS, and to use ALPN for performing the integrity check on version negotiation, this is OK in my view. I think that in the short term we will want to have something more specific than just "quic". I believe that someone at the BoF pointed out that getting version negotiation in place early is important, and I agree with that. The draft numbering stuff we did with HTTP/2 might be something we can lean on a little (as you point out). From nobody Mon Jul 25 04:49: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 5FC0712D7D2 for ; Mon, 25 Jul 2016 04:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.189 X-Spam-Level: X-Spam-Status: No, score=-3.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287, 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 U4s6UZRgQsxF for ; Mon, 25 Jul 2016 04:49:32 -0700 (PDT) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 5998C12D7CC for ; Mon, 25 Jul 2016 04:49:31 -0700 (PDT) Received: from public-docking-cx-2148.ethz.ch (public-docking-pat-cx-mapped-0004.ethz.ch [195.176.111.5]) by trammell.ch (Postfix) with ESMTPSA id 5E4EF1A0F8A for ; Mon, 25 Jul 2016 13:49:30 +0200 (CEST) From: Brian Trammell X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_223781E4-BB18-4E68-B4CE-9E312C6B7093"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 25 Jul 2016 13:49:29 +0200 Message-Id: To: quic@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [QUIC] QUIC BoF draft minutes 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: Mon, 25 Jul 2016 11:49:33 -0000 --Apple-Mail=_223781E4-BB18-4E68-B4CE-9E312C6B7093 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, Draft minutes for last Thursday's QUIC BoF in the form of the unedited = Etherpad transcript have been posted to = https://www.ietf.org/proceedings/96/minutes/minutes-96-quic. Many thanks = to Aaron Falk and Patrick McManus as note-takers! Please read, and send = any necessary corrections or useful clarifications to me and Lars. Cheers, Brian --Apple-Mail=_223781E4-BB18-4E68-B4CE-9E312C6B7093 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 iQIcBAEBCgAGBQJXlfzKAAoJEIoSt78L6kajlaQP/jmTu1J1WWYs5l4/IjHAB92J MdRExvBiQZ9Kqn6WPUhGnouRBDfPG7T5mRzOG/mPytSazOXgX5NqF22F2d2kpkPW FXdHZnA7PcApSoSLH/XECDtwEv6qwRH2AnwaYSReeywvye55SmsuFkv78Mnvd4z0 j4aQr6mkF1G3R7iN8ErDdK9ndfHrAR1hdPpLc1DCz6W+RUTQekvUgDVzyfXDqxdv P0/zAh6nvaLz55u5wLtk+9MjSJsLHgVw6Qtvd+89f2mP8MO4RYKjjYJhRZiBdNXU 43vBJ45YEC/T7Dicj5ZTK32hI28RiKVaeDzG1mJcagJyCXFVZ/JnzMYEn1yRZDtQ 4agcDtmlQyYxA+m1CdCWpNSrZzVCtlwv1si6IUe8cIF2ACTQATKwGx6HvlnoigJP rbMgtcwGyhptYk+0MDlWz4Gu6reb3PrDB7lE9m03Gk943kGS0+KV28sXwaPED3/B hPNsHQ9w0azIAJnCYRWv8WBY+we5lhnfxjE7Lag+bgDPOpkUDVOsw+2cFRY+caod iKH8rBflsf6DUH5vQeRjFhPF6IfbilT5chrPOP+LiCNATOtU59OA2nedj/je6doY DacpC0vr3Er9VjbqDosym/yuf9ot1P6G794F+72Kz0K0LNp599ExQoUWMYOdkfTH WhU/4zmglLwAcuNDkLSg =iEh/ -----END PGP SIGNATURE----- --Apple-Mail=_223781E4-BB18-4E68-B4CE-9E312C6B7093-- From nobody Tue Jul 26 18:51: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 18B9C12DD0C for ; Tue, 26 Jul 2016 18:51:25 -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 iITSinZ0PB7m for ; Tue, 26 Jul 2016 18:51:22 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611F812DD0B for ; Tue, 26 Jul 2016 18:51:21 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id r9so43314413ywg.0 for ; Tue, 26 Jul 2016 18:51: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; bh=ypo3pUX9aWf/QlaNTC1qMg60SQs8Cx1HbYmREVNwRd4=; b=Mm5Z3OUHu7C+dxt98d0Re3XC96riX5oIZ0B6t8jpfsvIQz1lay8nuUHMhWXcIC9l7M XABDUuLt5zVLBS/Td19/15YiAavLGqCtNk3PWus7NJa9ENOJHD2q1+NP8hr+7sCi02fp mQbu4daDDo7TtUfwMMgEXxRa3kyFAlDMAgiXCOejkT9PHoqihfCiJd6wskLvNr60z3k7 WxoT8bWr6sHFpVlX7cXIHKWcZerhcq1yr896EfAXMCwBmNd0el++mwkHMIrKAgFPuQSy Rsfl2Uflcwk6w5xJFpH6pNpOwS9CEB1DyAYnivbnB7UzO9dciFCHUhy+73Zf92853WmS p7ag== 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=ypo3pUX9aWf/QlaNTC1qMg60SQs8Cx1HbYmREVNwRd4=; b=fc+DPyvTOkV7NlH+4LDhzuB8jGaRIzDCVqDDJVl+17EJS4x7SHTjsIaUzWHSWLdT7B KkFtihutQtSEX9MnRQ7d+rrfYiiyBQ4AvZSrRwSXtBo5w+IXBDC4fY3xLS3neI2WAQ03 vX7IpLCyQeFYRZm2sQiqztixAFq/s0O80ont5YkNROCMuj9XXEromLyb0CHjdBitNf9g qOu4RF+Xfj1JJJU/AzcJ5i3y4aOd+Il4a5zvh+ylPyviQkkl6Ng4yRCWSmtoBGwdvU3C JTLM1eInhK7xQ8ePgsGgWz14t339mzjs1dNFjScaDv2I/EKbPpBy/YA8rNm/xWm1tNH1 hX+A== X-Gm-Message-State: AEkoouvzQPepzYRXAtVwDDOycJIiJQW0I0fbl1UVCBdvj2UjHs6pbjk4JKMnmlK0cLvN1eKlMRtVvnJK604FcQ== X-Received: by 10.31.125.4 with SMTP id y4mr9842017vkc.57.1469584280609; Tue, 26 Jul 2016 18:51:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Tue, 26 Jul 2016 18:51:20 -0700 (PDT) From: Watson Ladd Date: Tue, 26 Jul 2016 18:51:20 -0700 Message-ID: To: quic@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [QUIC] TLS in QUIC problems 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, 27 Jul 2016 01:51:25 -0000 Dear all, As we all know, formats write their own exploits. The more complicated a parsing operation is, the easier it is to screw up, and the more it is screwed up, the more exploits. TLS has a rather complicated format combining fixed length and length prefixed fields with several layers of nesting, and the result is all kinds of latent bugs in implementations that harm extensibility as well as security. QUIC very carefully chose to use a uniform TLV format, with only one layer of nesting permitted. The result is that this is easy to completely parse into a structure that contains all the relevant information, and ignoring unused fields is easy. TLS implementations don't do this, instead resorting to shotgun parsing with consequent catastrophe. The proposals I've seen to use the TLS handshake in QUIC abandon this. What do we gain vs. having a sane reencoding of the data structures used in the TLS handshake? Sincerely, Watson Ladd From nobody Wed Jul 27 10:30: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 0CCF112D518 for ; Wed, 27 Jul 2016 10:30:33 -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 tBL4uvclHgvS for ; Wed, 27 Jul 2016 10:30:28 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CF012D196 for ; Wed, 27 Jul 2016 10:30:28 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id f65so221948048wmi.0 for ; Wed, 27 Jul 2016 10:30:27 -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=2nOi+7TULVEmvEC+Pf+/YE2p29/MncQT04THfIewPh4=; b=lDEoe1n26Pu9TJLrQyLpCAndYyrm06cRSu52scyx7grudTt+c3uLeN550G4kmrArUa 13l1Gb0Lfrh5RGDmRT5gmM6gRstiBvpoPq6rKQPV1gBJz9unsgW0577MW+s/Ww1ff25W r0h6Abo7321B2EZ924wb7CODG4NNDpHAc46aZ6lP5HrsBJ94YuHlqxccml/Pk7ktO6EF iMwtDE10pEaHs3KVOMXnRG7nSkEcbPRhBLS48ZJXjZqDLIIQIiYbzzO+OabHiXoNbw2e FvFxbg3nFkdr3ojt9x0rnQMqbgrIeCiDWIWKgHkBUKDxSChJpUn9b65VBU2/BiELjzoo uFJA== 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=2nOi+7TULVEmvEC+Pf+/YE2p29/MncQT04THfIewPh4=; b=d1zWmSV7AIz1Z10qCZLGr/NZOm7bM5IEFQ/C2XRPQgrs2rLOXRyx/RXxst4G8XH6sf /0o3FLKLcpxL4weBesTxCqbKqAKF4dF+OYb17Fb3Q2U4fgqp1zFdf4X8zkqn87wb09xO QMYIxVkf0kAcGj2NDLCAdonEpXSCFkdpEbvH5vVms+2+ZqzSRLOZPRdU+5PunfGVsNpd nSmW6cat6FWC9agU9d7wp9/w8Ya483WusEw4gEXSg2fwjNPHuUswKj8iJlfvpTUQeV7n S5Gp5t2pwTEAKthVFauf1974WK1Ooo8krudx+ypyBbKs+Q7ylseuoIuYHtnuzZrwBA7k /Sbg== X-Gm-Message-State: ALyK8tIM9K61EpsbXIolBxIf9oT9lnBWqq2h7O9hmxXqCcowzQQQvt1JMK/+G4/pv0MEGg== X-Received: by 10.28.232.145 with SMTP id f17mr52820415wmi.15.1469640626559; Wed, 27 Jul 2016 10:30:26 -0700 (PDT) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id gw4sm7366008wjc.45.2016.07.27.10.30.25 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 27 Jul 2016 10:30:26 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Yoav Nir In-Reply-To: Date: Wed, 27 Jul 2016 20:30:23 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <08FACD6D-5A31-48B6-BB4B-78BEC52DD510@gmail.com> References: To: Watson Ladd X-Mailer: Apple Mail (2.3124) Archived-At: Cc: quic@ietf.org Subject: Re: [QUIC] TLS in QUIC problems 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, 27 Jul 2016 17:30:33 -0000 > On 27 Jul 2016, at 4:51 AM, Watson Ladd wrote: >=20 > Dear all, > As we all know, formats write their own exploits. The more complicated > a parsing operation is, the easier it is to screw up, and the more it > is screwed up, the more exploits. TLS has a rather complicated format > combining fixed length and length prefixed fields with several layers > of nesting, and the result is all kinds of latent bugs in > implementations that harm extensibility as well as security. >=20 > QUIC very carefully chose to use a uniform TLV format, with only one > layer of nesting permitted. The result is that this is easy to > completely parse into a structure that contains all the relevant > information, and ignoring unused fields is easy. TLS implementations > don't do this, instead resorting to shotgun parsing with consequent > catastrophe. >=20 > The proposals I've seen to use the TLS handshake in QUIC abandon this. > What do we gain vs. having a sane reencoding of the data structures > used in the TLS handshake? Code re-use. If OpenSSL, BoringSSL and a few others get it right, your = QUIC implementation can just use that. If these libraries have horrible security bugs, we=E2=80=99re screwed = anyway because we use them for old-fashioned HTTPS. Yoav From nobody Wed Jul 27 10:49: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 1A38112D108 for ; Wed, 27 Jul 2016 10:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.012 X-Spam-Level: X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 CCh-KvbpevrF for ; Wed, 27 Jul 2016 10:49:25 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0122.outbound.protection.outlook.com [104.47.41.122]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A9F412D0FD for ; Wed, 27 Jul 2016 10:49:25 -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=arAOPnxgO/J4pbo3s+dt4ERj6Q0Qe8iuvSHmh3oAAw4=; b=jApApWyCHAHZEqRQ2UQlJ3Whs2ZXXc58sDwg2xQ1kWWuvYzU8B5pkXhAAyh/ugUOsNw1yMkQ9BdIokyo3ZB25MBC0ZIMTp13ZA9f5ZPAeUI9zx8d57+Me4vf2DcY0njCYCApfdtLIuY8fWJS2vAGhO/VnrT7gdEo4eAqBavInWk= Received: from BN6PR03MB2675.namprd03.prod.outlook.com (10.173.143.150) by BN6PR03MB2674.namprd03.prod.outlook.com (10.173.143.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.549.15; Wed, 27 Jul 2016 17:49:22 +0000 Received: from BN6PR03MB2675.namprd03.prod.outlook.com ([10.173.143.150]) by BN6PR03MB2675.namprd03.prod.outlook.com ([10.173.143.150]) with mapi id 15.01.0549.016; Wed, 27 Jul 2016 17:49:22 +0000 From: Christian Huitema To: Yoav Nir , Watson Ladd Thread-Topic: [QUIC] TLS in QUIC problems Thread-Index: AQHR56lkWNZi38Bng0aHaFsL+TDQt6AsicmAgAAELuA= Date: Wed, 27 Jul 2016 17:49:22 +0000 Message-ID: References: <08FACD6D-5A31-48B6-BB4B-78BEC52DD510@gmail.com> In-Reply-To: <08FACD6D-5A31-48B6-BB4B-78BEC52DD510@gmail.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=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:e::14d] x-ms-office365-filtering-correlation-id: 82bb3736-1b83-4eff-9d85-08d3b64657e1 x-microsoft-exchange-diagnostics: 1; BN6PR03MB2674; 6:gPe1Ne38XJhhnu8gE5gmPkXSdtzqS+2Hd9HvTmNkH7pJpxPb05XC+6jPHB0oNeC80q8c5yvYN28amXItdcgLxMqHFNfbDHE9FTdOzAx6mnrO+HJwb3Zq4HAUErdtNB9yz/GncXUEnrKJAKMnS+trt/Mg2XX+K8MQNSZsXwr/b7oZ2yjQZah8RDb2IhU5/V1bs/nyth3nH77IB7cDX9JoN67JICAKVlafVgQBE4n+Rks9oF8n+TospPMCVqszVu2eNWnFmMwKRO9fHpvs4StkjFkRxc6bW230YpRaAqnLEFkfsdFSQJ7ovEHeXO1hQu8Nk7V6z/6HDLQgtyunUNEYZA==; 5:ms2v8puMmo0mSUKDejaF1lZULvo3bGwRHs8UjyauTKAHsL9cGf44ZxrAMiLRQk/OgjL3Q44akyIKQ7ApW13BSOXJtYtYLTEvbkIlL+ssTXsUAq2UxD4eoBq/cfY4cvWypAf4BSjTx/HbQS8RWiuRMw==; 24:l/rl9GSQG7TJEKEfr/g+YWhne/ZTV6m45qWiIvboKLkJMBs7UFOTX3bezcss2vnuMfzPvWfyZ/jMQFF6mkr0ltQYCZCyuYWrW82/gFVP/QI=; 7:sVkY5gZCiRxwazurK/mDlTA4IOonPOuI00LcOw3QwdWrdsxKd2gU4vNzBklx4OeztRu758vWtrH4gb/ZB2U7sRQeFVzGcdgoeUC9Bes4LjuX0arIy34dWEeD3UcLn76KIxVYQ8/rQQcIwHB40hwz0saTibZRnWNRLb2/1Pa/SDvYfu6hGuQxPgMi66YDDAPlH3NvzDaHC6+h8LKWOS31e0ULLkPvwey9oWYo2jopJlMulNyXO3F8jOb95ZdNVSxw x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN6PR03MB2674; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(266576461109395); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:BN6PR03MB2674; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2674; x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(189002)(199003)(377454003)(10090500001)(106356001)(86612001)(87936001)(33656002)(5002640100001)(106116001)(122556002)(74316002)(2900100001)(50986999)(8990500004)(101416001)(19580405001)(54356999)(76576001)(10400500002)(5005710100001)(10290500002)(76176999)(19580395003)(86362001)(189998001)(11100500001)(6116002)(102836003)(81156014)(105586002)(8676002)(92566002)(5001770100001)(5003600100003)(99286002)(81166006)(586003)(4326007)(97736004)(8936002)(9686002)(2950100001)(305945005)(7846002)(77096005)(7736002)(3660700001)(68736007)(2906002)(7696003)(3280700002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2674; H:BN6PR03MB2675.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: 27 Jul 2016 17:49:22.3928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2674 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] TLS in QUIC problems 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, 27 Jul 2016 17:49:27 -0000 T24gV2VkbmVzZGF5LCBKdWx5IDI3LCAyMDE2IDEwOjMwIEFNLCBZb2F2IE5pciB3cm90ZToNCj4g PiBPbiAyNyBKdWwgMjAxNiwgYXQgNDo1MSBBTSwgV2F0c29uIExhZGQgPHdhdHNvbmJsYWRkQGdt YWlsLmNvbT4gd3JvdGU6DQo+ID4gLi4uDQo+ID4gUVVJQyB2ZXJ5IGNhcmVmdWxseSBjaG9zZSB0 byB1c2UgYSB1bmlmb3JtIFRMViBmb3JtYXQsIHdpdGggb25seSBvbmUNCj4gPiBsYXllciBvZiBu ZXN0aW5nIHBlcm1pdHRlZC4gVGhlIHJlc3VsdCBpcyB0aGF0IHRoaXMgaXMgZWFzeSB0bw0KPiA+ IGNvbXBsZXRlbHkgcGFyc2UgaW50byBhIHN0cnVjdHVyZSB0aGF0IGNvbnRhaW5zIGFsbCB0aGUg cmVsZXZhbnQNCj4gPiBpbmZvcm1hdGlvbiwgYW5kIGlnbm9yaW5nIHVudXNlZCBmaWVsZHMgaXMg ZWFzeS4gVExTIGltcGxlbWVudGF0aW9ucw0KPiA+IGRvbid0IGRvIHRoaXMsIGluc3RlYWQgcmVz b3J0aW5nIHRvIHNob3RndW4gcGFyc2luZyB3aXRoIGNvbnNlcXVlbnQNCj4gPiBjYXRhc3Ryb3Bo ZS4NCj4gPg0KPiA+IFRoZSBwcm9wb3NhbHMgSSd2ZSBzZWVuIHRvIHVzZSB0aGUgVExTIGhhbmRz aGFrZSBpbiBRVUlDIGFiYW5kb24gdGhpcy4NCj4gPiBXaGF0IGRvIHdlIGdhaW4gdnMuIGhhdmlu ZyBhIHNhbmUgcmVlbmNvZGluZyBvZiB0aGUgZGF0YSBzdHJ1Y3R1cmVzDQo+ID4gdXNlZCBpbiB0 aGUgVExTIGhhbmRzaGFrZT8NCj4gDQo+IENvZGUgcmUtdXNlLiBJZiBPcGVuU1NMLCBCb3JpbmdT U0wgYW5kIGEgZmV3IG90aGVycyBnZXQgaXQgcmlnaHQsIHlvdXIgUVVJQw0KPiBpbXBsZW1lbnRh dGlvbiBjYW4ganVzdCB1c2UgdGhhdC4NCj4gDQo+IElmIHRoZXNlIGxpYnJhcmllcyBoYXZlIGhv cnJpYmxlIHNlY3VyaXR5IGJ1Z3MsIHdl4oCZcmUgc2NyZXdlZCBhbnl3YXkgYmVjYXVzZSB3ZQ0K PiB1c2UgdGhlbSBmb3Igb2xkLWZhc2hpb25lZCBIVFRQUy4NCg0KTm90IGp1c3QgY29kZSByZXVz ZSwgYnV0IGFsc28gYXR0YWNrIHN1cmZhY2UgcmVkdWN0aW9uLiBJbiBhbGwgcmVhbGlzdGljIHNj ZW5hcmlvcywgYnJvd3NlcnMgYW5kIHNlcnZlcnMgd2lsbCBzdXBwb3J0IGJvdGggSFRUUFMgYW5k IFFVSUMuIElmIHdlIGhhdmUgdHdvIGRpZmZlcmVudCBzZWN1cml0eSBzdGFja3MsIHdlIGhhdmUg dG8gYmUgd29ycmllZCBhYm91dCB0aGUgY29tYmluZWQgc3VyZmFjZSBvZiBib3RoIHN0YWNrcy4N Cg0KLS0gQ2hyaXN0aWFuIEh1aXRlbWENCg0KDQogDQo= From nobody Thu Jul 28 20:16: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 F392212D176 for ; Thu, 28 Jul 2016 20:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 iqWUYJEFbitS for ; Thu, 28 Jul 2016 20:16:25 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 9B04B12D10C for ; Thu, 28 Jul 2016 20:16:25 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 35so53338833uap.1 for ; Thu, 28 Jul 2016 20:16:25 -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:content-transfer-encoding; bh=GS+mPLZC3BhVmoBdXKKR4P+iBpFmaNAKyqnP5dRWs5I=; b=ubSBOdyk7DDOzcthVGqLIJCs0aptV+mL13kcNt/1apz6uhWcQdDfBEYq0KhevFXipF bJWxuYuuRCzAX0zMkvo2KVW3z9enR2I20wEibkC4M9k5CpkaA2rCRDBBaMpMi95yB0eG L/pTrg1C4gD4UKNjVn5OgZ2KAqJNAksYzLP6biDn6dEHUVIkGJ/1E0p6LnpK2i1awMlz 4Wzy01GFDKu5y3AzdSoxOFgUoxJcpcPCqJpnn3i/vHvgMWUQKcw9g9oEjf/yhWzg2Ho5 XvfancKFsePf9FdAgQufA/FRRnlwlX+bTJrwK0LDr/mUMKPIAqqThCheFniIlYuJR4o2 onnQ== 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=GS+mPLZC3BhVmoBdXKKR4P+iBpFmaNAKyqnP5dRWs5I=; b=PelY81dPgHBKmVg/WPmbsDzuB1h70PLc8bQEkhlm910TfleutTx7sFSYdwitWkwebP cBBwGq1wHY8bowss3RvPxiJA/sNZHEh/9HWpc16RifXDNrxWjgBlZ4UdhMhxbjzHmUpi GgQW/AMc2wDO5IK/gBAW5Ih0RqEwQRlJD/XHJ1IYBzNoAm2zHkHQaPod3qQ9s8W/46i8 NZQMGJ7EDwb+BWjSG74qy8SDcW7Pznr50vpP7F9rwHUASKekphN15KPOvtiKfM1VR6NN R4/D3eR5gm42E0YjfxXNPyG4spUArIwdaaSnWyHTiYW1IJoRdmCC7R/7GBsxyiVFSOMk 674g== X-Gm-Message-State: AEkoout8bs+1r6m+nM6gvgKdLF+VJSanZwtef7Q0Lnb5z15X0JTWzvk+cAkWs7e7y0LHOT0eHQcteRqVHdFgsw== X-Received: by 10.176.4.101 with SMTP id 92mr14737104uav.56.1469762184617; Thu, 28 Jul 2016 20:16:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.39.194 with HTTP; Thu, 28 Jul 2016 20:16:24 -0700 (PDT) In-Reply-To: References: <08FACD6D-5A31-48B6-BB4B-78BEC52DD510@gmail.com> From: Watson Ladd Date: Thu, 28 Jul 2016 20:16:24 -0700 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "quic@ietf.org" , Yoav Nir Subject: Re: [QUIC] TLS in QUIC problems 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: Fri, 29 Jul 2016 03:16:27 -0000 On Wed, Jul 27, 2016 at 10:49 AM, Christian Huitema wrote: > On Wednesday, July 27, 2016 10:30 AM, Yoav Nir wrote: >> > On 27 Jul 2016, at 4:51 AM, Watson Ladd wrote: >> > ... >> > QUIC very carefully chose to use a uniform TLV format, with only one >> > layer of nesting permitted. The result is that this is easy to >> > completely parse into a structure that contains all the relevant >> > information, and ignoring unused fields is easy. TLS implementations >> > don't do this, instead resorting to shotgun parsing with consequent >> > catastrophe. >> > >> > The proposals I've seen to use the TLS handshake in QUIC abandon this. >> > What do we gain vs. having a sane reencoding of the data structures >> > used in the TLS handshake? >> >> Code re-use. If OpenSSL, BoringSSL and a few others get it right, your Q= UIC >> implementation can just use that. >> >> If these libraries have horrible security bugs, we=E2=80=99re screwed an= yway because we >> use them for old-fashioned HTTPS. > > Not just code reuse, but also attack surface reduction. In all realistic = scenarios, browsers and servers will support both HTTPS and QUIC. If we hav= e two different security stacks, we have to be worried about the combined s= urface of both stacks. This cost applies to any new transport layer or any other protocol, yet we still pay it. Even granting the facts under your argument, it would say that we must never introduce simple security protocols, as the more complex ones will still be around and the new alternatives will therefore increase the attack surface. This is clearly antithetical to any improvement in the situation. Of course, the facts underlying your comment are wrong. Lots of devices beyond browsers and servers use TLS. In many cases both ends of a communication are under control of a single entity, making switching protocols easier. Your QUIC implementation cannot just use OpenSSL. OpenSSL wants to drive the IO on the sockets handed to it, and expects TLS records to come in, not TLS handshake records. Of course there are dirty hacks around it. Or perhaps you don't have the resources to use OpenSSL, have licensing problems that make distributing it with your software hard, or don't feel like 0.9.8.zz is the pinacle of software correctness. Simplicity and ease of implementation are virtues. > -- Christian Huitema > > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau.