From nobody Mon Dec 5 07:12:11 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74873129512; Mon, 5 Dec 2016 06:55:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.116 X-Spam-Level: X-Spam-Status: No, score=-7.116 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896] 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 hcIKtYf8xpKI; Mon, 5 Dec 2016 06:55:18 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F4C129A21; Mon, 5 Dec 2016 06:55:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id 502C8D9305; Mon, 5 Dec 2016 15:45:28 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9-xGMlqJmonr; Mon, 5 Dec 2016 15:45:28 +0100 (MET) Received: from [192.168.178.33] (p5DEC2FCB.dip0.t-ipconnect.de [93.236.47.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 0D7A1D9304; Mon, 5 Dec 2016 15:45:28 +0100 (MET) From: =?utf-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Mon, 5 Dec 2016 15:45:27 +0100 To: spud X-Mailer: Apple Mail (2.3251) Archived-At: X-Mailman-Approved-At: Mon, 05 Dec 2016 07:12:10 -0800 Cc: plus@ietf.org, Brian Trammell Subject: [Plus] New PLUS mailing list, side meeting and future steps X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 14:55:21 -0000 Hi all, as previously announced on this list, we had a side meeting on PLUS at = IETF-97. We had about 20 people attending and showing continued interest = in working in this space. The discussion was mostly centered around = draft-hardie-path-signals, which describes the concept of path signals = as currently used by on-path devices; as well as = draft-trammell-plus-statefulness, which describes a = transport-independent state machine for on-path state management, the = basis for any flow-based path signaling. There was detailed discussion on the state machine as proposed in the = -00 version of the draft starting from the need for a clear definition = of what a stateful middlebox is, and expectations about the deployment = of such middleboxes. It was further noted that for each signal that is = exposed to a middlebox, a clear benefit must be shown. This further led = to more discuss about the need and use of the stop/close signal and if = it would be needed to also have cancel-stop signal if the close signal = was detected by the receiver to be spoofed. This discussion is on-going, = and related to current discussion on the quic list. We have submitted a revision of draft-trammell-plus-statefulness has = been published, based mainly on discussion after the side meeting. See: https://datatracker.ietf.org/doc/draft-trammell-plus-statefulness/ Based on such a basic mechanism for state management, there was interest = in using PLUS mechanisms for time-out exposure to optimize keep-alive = traffic for mobile devices as well as providing input for network = troubleshooting in a transport-independent way. To allow for future = experimentation, the next step is to write a specification that = describes the assumed wire image. There was interest in participating in = this work from several attendees as well as a request for providing = middlebox guidelines on how to interpret and use such a = transport-independent wire image. While the work on these approaches are continuing, we did not decide on = any concrete plans for another attempt to start a working group in the = IETF (e.g. having a BoF in the near future). With this mail, we would = like to move future discussion over to the plus@ietf.org mailing list. = This new mailing list is intended to be used for work and discussion on = path layer signaling as indicated by the mailing list description: https://www.ietf.org/mailman/listinfo/plus If you are continuously interested in this work, please subscript to the = plus list. We will close the spud list as we see the spud experiment on = examining the tussle between in-network assumptions and stack evolution = as started at the IAB SEMI workshop as finished, moving forward to = concrete experimentation starting from basic in-network state = management. We will announce new work and updates on the plus list only. = Please feel free to use the plus list for any discussion related to path = signaling! Mirja and Brian From nobody Wed Dec 7 00:59:27 2016 Return-Path: X-Original-To: plus@ietf.org Delivered-To: plus@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 222C7129611; Mon, 5 Dec 2016 15:32:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148098072009.9576.14992911155022613690.idtracker@ietfa.amsl.com> Date: Mon, 05 Dec 2016 15:32:00 -0800 Archived-At: X-Mailman-Approved-At: Wed, 07 Dec 2016 00:59:25 -0800 Cc: ietf@trammell.ch, mirja.kuehlewind@tik.ee.ethz.ch, plus@ietf.org Subject: [Plus] New Non-WG Mailing List: plus -- Discussion of a Path Layer UDP Substrate (PLUS) protocol for in-band management of in-network state for UDP-encapsulated transport protocols. X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 23:32:00 -0000 A new IETF non-working group email list has been created. List address: plus@ietf.org Archive: https://mailarchive.ietf.org/arch/search/?email_list=plus To subscribe: https://www.ietf.org/mailman/listinfo/plus Purpose: PLUS aims to define a new Path Layer UDP Substrate (PLUS) protocol, that supports in-band management of in-network state (e.g. on firewalls and NAT boxes) in a transport-independent way. PLUS will, in effect, provide a common "wire image" for new, encrypted transport protocols. PLUS is intended to be deployed underneath encrypted transport protocols, which protect the confidentiality of their payloads and most of their headers, and can protect the integrity of those headers exposed to the network. Given current deployment practices and the constraints they impose on deploying new protocols, PLUS will be defined as a shim layer, on top of UDP and underneath the actual transport protocol. For additional information, please contact the list administrators. From nobody Wed Dec 7 07:12:21 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92986129441 for ; Wed, 7 Dec 2016 07:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 y0oqvVc1NCDU for ; Wed, 7 Dec 2016 07:12:18 -0800 (PST) Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C40012940D for ; Wed, 7 Dec 2016 07:12:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id A0ED0D93FD for ; Wed, 7 Dec 2016 16:12:16 +0100 (MET) X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nP6i5B2PUylc for ; Wed, 7 Dec 2016 16:12:16 +0100 (MET) Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id 74828D93EE for ; Wed, 7 Dec 2016 16:12:16 +0100 (MET) To: plus@ietf.org From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <6850cb85-6b26-e5b8-50a9-7565c39b0c28@tik.ee.ethz.ch> Date: Wed, 7 Dec 2016 16:12:16 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Plus] Blog post on quic and tou X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 15:12:20 -0000 hi all, here is an interesting blog post on middleboxes: https://www.snellman.net/blog/archive/2016-12-01-quic-tou/ Mirja From nobody Wed Dec 7 13:35:41 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF382129C02 for ; Wed, 7 Dec 2016 13:35:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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=-2.896, 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 d50KCkp86LpL for ; Wed, 7 Dec 2016 13:35:37 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 882D7129BF5 for ; Wed, 7 Dec 2016 13:35:36 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id x186so219585377vkd.1 for ; Wed, 07 Dec 2016 13:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+q2JDVdBUqwIhPtOv8mwCff76dbLKahTCc+cIzVf3wU=; b=GHkAzXgsS8co3WryQRZbwJZ77F6yj8xEW+9J2VusiiuIv5rAZe5wnTRTyEL+cHmHrB UYQiFLjSzMqO5QERHvK1/ZQMjejR2ES1Mp8JeMlDt7tCJ4UcmoXVOPS5t2vRGNqzpqGW Vlm40AastpOglRfW6HqL4WhHf0yBIjBWNY//6kNFdV0LXw6YaQ4VYEuX0VpURPbqhOef X5wH2Kj1YX+hNB6lfhHmz+mWUKa7y8Zfw8XxSibGiM/Cd5RD3/Z4eylVMiQJgA/svUGD 0XAJtEY6wmpTykNBNG0ZiJ7y0Y+XOSCuscVl9C7uy5k0O0qWREXlApQkIOYZcca6VKzF BDeQ== 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=+q2JDVdBUqwIhPtOv8mwCff76dbLKahTCc+cIzVf3wU=; b=fyFYJ9E1eALKX0/o3oTIULWZGswt1cyfPXXCwJuSPfK+eM+Nof5tAkmwjJ9N+CSdSG cMCLuGEQ9stvLy0e4GDACFoyfZhI7hxdCcztejNJTH6pMGCjsJwuqWilT1KWBYxZmZHv Q+v+7SJ1FeESUHq1Iqt8MOk/CE7mNU5aUI6nJl0NJgBnBIy5zx6jnDwe5sJoqcDeoZsa vpTjI3uq+rzzpODO7SjKBMYs7VU1mhVeKY7WZaCf9aVqGleuwW5NVsxcosjJqoHl/MTn YBhZ6DZ2ikkJfsHTRD2wQGJ10Nu1FRBtRg/KgUik1Wk9M8eIttvfb58fzlrCgqKSukHT uSdw== X-Gm-Message-State: AKaTC02cTWjiK4PtJ4KKn+JGE4JPBP5bsQM2rhz+wqAxw3+C6kqbkJrLMa0k2Pv7qoEl3oACcwMeXgGwyWwp5+aO X-Received: by 10.31.52.145 with SMTP id b139mr22720681vka.151.1481146535307; Wed, 07 Dec 2016 13:35:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Wed, 7 Dec 2016 13:35:34 -0800 (PST) In-Reply-To: <6850cb85-6b26-e5b8-50a9-7565c39b0c28@tik.ee.ethz.ch> References: <6850cb85-6b26-e5b8-50a9-7565c39b0c28@tik.ee.ethz.ch> From: Jana Iyengar Date: Wed, 7 Dec 2016 13:35:34 -0800 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a114348b6196f2a0543184d2d Archived-At: Cc: plus@ietf.org Subject: Re: [Plus] Blog post on quic and tou X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 21:35:40 -0000 --001a114348b6196f2a0543184d2d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for forwarding the article. I'll offer some thoughts (and some corrections.) There's surely a solid argument to be made about network monitoring, as this blog post makes. Operators' needs are real, and we need to ensure that they are able to reasonably do the things that they need to do. At least for QUIC, exposing a small additional bit of information addresses ~80% of the use cases mentioned in the document: a "largest acked" ack number on all packets (or at least packets that contain acks). I won't design this mechanism on this list, but I'll note that it's a conversation that's happening in several corners in the QUIC wg. It needs to be aired and discussed, and I expect it to happen relatively soon. The article though looks at real needs and current tools that operators have, and over-generalizes to saying that the "entire header" should be visible. My argument remains that only what is absolutely required should be exposed, and that every bit exposed should be debated. This is not a security argument, it's an ossification one. The whole point of ossification is that there are third parties that are unresponsive to changes in allegedly e2e protocols. Middleboxes are reactive. If they see traffic shifting a particular way, they'll go build something in response -- I've seen this happen several times. But, they are not proactive. This creates a serious "deployment impossibility cycle" where deploying a protocol change widely requires it to work through a huge range of middleboxes, but even high-end middleboxes will not change behavior in response until the protocol change is widely deployed. To the extent that we want to be able to deploy end-to-end changes, unfortunately, encryption is the only way to ensure that bits that ought not to be used by a middlebox -- for fear of ossification -- should not be used by one. In Ad= am Langley's words , "The end-to-end principle is important, and cryptography is its strongest guardian." Having been deeply involved in both the TFO and QUIC efforts in Chrome, I want to correct some things that the post mentions. First, even if they end up taking the same amount of time to deploy, yield outcomes with substantially different scales of benefit. After ~4 years of deployment work, QUIC is now an open area for experimentation, but TFO is still exactly one feature. Note that TFO is not yet deployed as widely as QUIC, see Christoph Paasch's presentation at NANOG for more. On rollout: "[1] There seems to be a bit of a difference in how this is rolled out. If you want TCP Fast Open in Chrome, you'll need to enable it via a flag. Meanwhile my understanding is that QUIC is effectively rolled out by geographical regions; the flip that's getting switched is server side. Presumably the latter rollout procedureincludes working with the main service providers in that area to make sure any problems get fixed in advance. A process like that would be a lot more tractable than trying to fix the whole world at once." This is incorrect. They were both rolled out using the exact same framework. TFO and QUIC are both also available as flags for the user to play with, but the experimentation framework is the same and rollout is the same. Chrome pulled back TFO for a number of reasons. This is of course still a WIP, and the hope is that we'll get TFO more deployed sooner than later, but that hasn't happened yet. On middleboxes: "[0] Whoops, that's not quite accurate. There is one specific kind of middlebox that a company like Google or Facebook needs: a load balancer. And very conveniently, both protocols introduce a new field containing the information a load balancer needs, and give it special treatment as the one field that gets to live outside the encryption envelope." The load-balancer needs to see the connection ID, but the load-balancer is a trusted part of the serving infrastructure. Specifically, from a crypto point-of-view, this load-balancer has access to various server keys. This is quite different than an arbitrary middlebox. More importantly, from an ossification perspective, a load-balancer ossifying would be equivalent to the server ossifying. - jana On Wed, Dec 7, 2016 at 7:12 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > hi all, > > here is an interesting blog post on middleboxes: > > https://www.snellman.net/blog/archive/2016-12-01-quic-tou/ > > Mirja > > _______________________________________________ > Plus mailing list > Plus@ietf.org > https://www.ietf.org/mailman/listinfo/plus > --001a114348b6196f2a0543184d2d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for forwarding the article. I'll offer som= e thoughts (and some corrections.)

There's sur= ely a solid argument to be made about network monitoring, as this blog post= makes. Operators' needs are real, and we need to ensure that they are = able to reasonably do the things that they need to do. At least for QUIC, e= xposing a small additional bit of information addresses ~80% of the use cas= es mentioned in the document: a "largest acked" ack number on all= packets (or at least packets that contain acks). I won't design this m= echanism on this list, but I'll note that it's a conversation that&= #39;s happening in several corners in the QUIC wg. It needs to be aired and= discussed, and I expect it to happen relatively soon.

=
The article though looks at real needs and current tools that operator= s have, and over-generalizes to saying that the "entire header" s= hould be visible. My argument remains that only what is absolutely required= should be exposed, and that every bit exposed should be debated. This is n= ot a security argument, it's an ossification one.

<= div>The whole point of ossification is that there are third parties that ar= e unresponsive to changes in allegedly e2e protocols. Middleboxes are react= ive. If they see traffic shifting a particular way, they'll go build so= mething in response -- I've seen this happen several times. But, they a= re not proactive. This creates a serious "deployment impossibility cyc= le" where deploying a protocol change widely requires it to work throu= gh a huge range of middleboxes, but even high-end middleboxes will not chan= ge behavior in response until the protocol change is widely deployed. To th= e extent that we want to be able to deploy end-to-end changes, unfortunatel= y, encryption is the only way to ensure that bits that ought not to be used= by a middlebox -- for fear of ossification -- should not be used by one. I= n Adam Langley's words, "The end-to-end principle is impor= tant, and cryptography is its strongest guardian."

Having been deeply involved in both the TFO and QUIC efforts in Chrom= e, I want to correct some things that the post mentions. First, even if the= y end up taking the same amount of time to deploy, yield outcomes with subs= tantially different scales of benefit. After ~4 years of deployment work, Q= UIC is now an open area for experimentation, but TFO is still exactly one f= eature. Note that TFO is not yet deployed as widely as QUIC, see=C2=A0Christoph Paasch's presentation at NANOG=C2=A0for more.
=
On rollout:

"[1] There se= ems to be a bit of a difference in how this is rolled out. If you want TCP = Fast Open in Chrome, you'll need to enable it via a flag. Meanwhile my = understanding is that QUIC is effectively rolled out by geographical region= s; the flip that's getting switched is server side. Presumably the latt= er rollout procedureincludes working with the main service providers in tha= t area to make sure any problems get fixed in advance. A process like that = would be a lot more tractable than trying to fix the whole world at once.&q= uot;

This is incorrect. They were both rolled out = using the exact same framework. TFO and QUIC are both also available as fla= gs for the user to play with, but the experimentation framework is the same= and rollout is the same. Chrome pulled back TFO for a number of reasons. T= his is of course still a WIP, and the hope is that we'll get TFO more d= eployed sooner than later, but that hasn't happened yet.=C2=A0

On middleboxes:

"[0] W= hoops, that's not quite accurate. There is one specific kind of middleb= ox that a company like Google or Facebook needs: a load balancer. And very = conveniently, both protocols introduce a new field containing the informati= on a load balancer needs, and give it special treatment as the one field th= at gets to live outside the encryption envelope."

=
The load-balancer needs to see the connection ID, but the load-balance= r is a trusted part of the serving infrastructure. Specifically, from a cry= pto point-of-view, this load-balancer has access to various server keys. Th= is is quite different than an arbitrary middlebox. More importantly, from a= n ossification perspective, a load-balancer ossifying would be equivalent t= o the server ossifying.

- jana

On Wed, Dec 7, 2016 at 7:= 12 AM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch= > wrote:
hi all,

here is an interesting blog post on middleboxes:

https://www.snellman.net/blog/archiv= e/2016-12-01-quic-tou/

Mirja

_______________________________________________
Plus mailing list
Plus@ietf.org
https://www.ietf.org/mailman/listinfo/plus

--001a114348b6196f2a0543184d2d-- From nobody Thu Dec 8 01:36:38 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E99129416 for ; Thu, 8 Dec 2016 01:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 5e5CfwWtfT9k for ; Thu, 8 Dec 2016 01:36:34 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5AA1293F4 for ; Thu, 8 Dec 2016 01:36:32 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::10d6] (unknown [IPv6:2001:67c:10ec:2a49:8000::10d6]) by trammell.ch (Postfix) with ESMTPSA id 58C1D1A0651; Thu, 8 Dec 2016 10:36:00 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B9225138-CD8E-4BFF-8AA9-68C45BDA2094"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Thu, 8 Dec 2016 10:35:59 +0100 Message-Id: References: <6850cb85-6b26-e5b8-50a9-7565c39b0c28@tik.ee.ethz.ch> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: plus@ietf.org, =?utf-8?Q?Mirja_K=C3=BChlewind?= Subject: Re: [Plus] Blog post on quic and tou X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 09:36:36 -0000 --Apple-Mail=_B9225138-CD8E-4BFF-8AA9-68C45BDA2094 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, > On 07 Dec 2016, at 22:35, Jana Iyengar wrote: >=20 > Thanks for forwarding the article. I'll offer some thoughts (and some = corrections.) >=20 > There's surely a solid argument to be made about network monitoring, = as this blog post makes. Operators' needs are real, and we need to = ensure that they are able to reasonably do the things that they need to = do. At least for QUIC, exposing a small additional bit of information = addresses ~80% of the use cases mentioned in the document: a "largest = acked" ack number on all packets (or at least packets that contain = acks). I won't design this mechanism on this list, (...noting that this list exists *precisely* for designing this = mechanism ;) but yes, details should happen on the quic@ list...) > but I'll note that it's a conversation that's happening in several = corners in the QUIC wg. It needs to be aired and discussed, and I expect = it to happen relatively soon. For those not familiar with the details of IETF-quic (which AFAIK from = others' implementation reports diverges somewhat from the version of = QUIC deployed by Google right now, and will diverge more during the WG's = work): the packet number is already exposed. Together with highest-ack, = this allows one-observation-point split-RTT measurement with an unknown = responder delay term, equivalent to TCP; two-observation-point = approaches for loss measurement; and one-observation-point approaches = for loss estimation to work with more information about the dynamics of = the particular version of QUIC running, also similar to TCP. I personally think we can do a good deal better than this with epsilon = more complexity and overhead, without either constraining QUIC's = transport dynamics or requiring measurement devices to know about the = details of those dynamics. Need to do a bit more work before I can say = how small epsilon is, though. Missing is more detailed information about TCP dynamics mentioned in the = post. Many of these are TCP (and CC algorithm) specific, so it doesn't = make much sense to expose the same information, though each of the = requirements implicit in the list is worth evaluating separately for its = ossification/security/utility tradeoff. One requirement from that list that seems quite useful, though I don't = know how to solve in the general case or in QUIC specifically: = "determine [if] the software on the client or the server is the = bottleneck". This is a very common triage task in network operations: = does this problem indicate a misconfiguration of my network, or (more = cynically) can I demonstrate that it's not my fault and therefore not my = problem? Requiring access to one or both endpoint machines to answer = that... seems like a question for a future Internet architecture = research project. > The article though looks at real needs and current tools that = operators have, and over-generalizes to saying that the "entire header" = should be visible. My argument remains that only what is absolutely = required should be exposed, and that every bit exposed should be = debated. I would go further (again, this is the philosophical underpinning of = PLUS, to the extent that it has one): the design of the header that is = exposed unencrypted to the network (which constitutes its "wire image") = should be treated as an entirely separate endeavour than the design of = the transport protocol machinery. > This is not a security argument, it's an ossification one. The whole = point of ossification is that there are third parties that are = unresponsive to changes in allegedly e2e protocols. Middleboxes are = reactive. If they see traffic shifting a particular way, they'll go = build something in response -- I've seen this happen several times. But, = they are not proactive. This creates a serious "deployment impossibility = cycle" where deploying a protocol change widely requires it to work = through a huge range of middleboxes, but even high-end middleboxes will = not change behavior in response until the protocol change is widely = deployed. My (possibly starry-eyed optimistic) hope is that a deliberately = designed wire image will create a path of least resistance for middlebox = designs to (reactively) follow. A well-designed wire image should be so = obvious that the in-network reaction will be the one desired by the = designers evenfor middleboxes built by people who didn't read the spec. Cheers, Brian --Apple-Mail=_B9225138-CD8E-4BFF-8AA9-68C45BDA2094 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 iQIcBAEBCgAGBQJYSSmAAAoJEIoSt78L6kaj0lkP/R2jkdQnwPVT9gTDrV+rOTMn jRS5ynplwqCiZ8PBFIYtCBbe4gjqaIFabkKHM+yjIEGj2wM0Xu9//8rssmKjMNek 2n8BNZ+UeuaVSdmPo2D60N/RsO6LBfpDaRjHJtAqaSJebCS5w+N5lfPT/CLKwtgE YlWyUYinTIM71Gi9apOUNdqf0gETB61MsZsp0npP7t+C35FB3YaSKJ684CtoLXuh qyq9ViZaOxOgTe+7ydocQeBpqKWhpHqhNj5b4R7oD9f460AHNOdUernLqulcw8+d x8vjYG1Q+8R6rWtNM84xrVGTxJaUfHGVgwRhd1j01ncjlorBp3iicgNkTlAWInzt 3Vy2iyQDl5FYm1OPe3YrM+wSmSr26+pS+20Bkz2WaZcWvAFsoG4VbGI7hpye9eOa gtxCv6YAFHZUmFuwH0TMde3OGqnAy2m0Ab/hMZwVc2/pWpDzWlYs7iBjuhkDFm96 hwMK5qCDxdNx4QmVXS8ve7h0twH0AVYNFwriMjtVsNDe/IhpWvJzDP6qKSoPylGE pPBEWoByneMTX+k4BBEewqc6xq8Pyz18EmvF+KS9s63ZijBrVHkCGiCi9/aS3DYr uqFGxmHVqLA2hZRQBr18yx9j7ecsZc8bDoHb7UlgZWhvHe0nu4cKC7Z9qQ86pfht Q8+SNEahb71cc0VC5dpn =aBQ+ -----END PGP SIGNATURE----- --Apple-Mail=_B9225138-CD8E-4BFF-8AA9-68C45BDA2094-- From nobody Thu Dec 8 09:39:20 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8836129AA2 for ; Thu, 8 Dec 2016 09:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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=-2.896, 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 NW22sOfLtD1H for ; Thu, 8 Dec 2016 09:39:15 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E534128B44 for ; Thu, 8 Dec 2016 09:39:15 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id w194so232766060vkw.2 for ; Thu, 08 Dec 2016 09:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eoHGxaZ73619KsxIWn9w0a3NTP56xWn2ZaWnKgu/pbs=; b=YpySxKMyvnTCHlCwNlddzY29O5+kB6fx2vLMA6A4BX/UgwVN+lOfs/0SLpRAhASJ/2 sqmdA+eGH6TVmUskf/LQbHF8Hx9EqTVcX4ZNLGDRVBGQ5SgVod0NsGtjCJdMl0NHN8Ba cybusb8VJXDfPmgACj+30WNEYc8gC2ADzqw4GBPLEtDs6hQ0Ba4e0gUuAxHpC8RfKUH2 1aM/aur6YAMFGQaWV0vBf0UC1ziAEiWoomCtC9BGjt87duhbMTdnVqyUyVseqWD1A1wz QXEZC4W0gcqiLlLOLb9YV3shIQV5f5BDj0dU/r3DPOlXXRBjQ2OmDojwniIo94WT7F4q UIDA== 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=eoHGxaZ73619KsxIWn9w0a3NTP56xWn2ZaWnKgu/pbs=; b=b364QBa57bkMl2oxFWPVw/w3laPqM7rY5QWj9vaH+RnNkKvpoUuGqPNQnx8flrWL4/ ILGLU2aq/LISQS9ApSLhvqTPZ+tVElgVc0/U7xKA5caUngiG73BZl630jTSmAHrNKj2P baRPwHnh2PXWvh5pnEc3EMsOZMweOt6oug6bPXDXoZ4fZnF2+cbAiDEgRGiTW8z9REeR EC/MWfItfxpkrgYfoFiTwinuuOiIk8QkoNDEeWSL1xk0hpkxREUflOCTL09Gjnxq4NNw UR3ixpmbpESfCJln7lK36a60Jv7KAMSkLps8wkvdKCIy7aO2MnMy+1vDlznH4nwOmRfi 7IWA== X-Gm-Message-State: AKaTC02D7Ua8NRHcPQwit/3gvpS7ezN8aPyyH3ZweigJKutcVP4xxyKmWzvOAXjWu3tDUrLWL2YHMe4LIX2HIMNY X-Received: by 10.31.218.68 with SMTP id r65mr25382567vkg.28.1481218754382; Thu, 08 Dec 2016 09:39:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Thu, 8 Dec 2016 09:39:13 -0800 (PST) In-Reply-To: References: <6850cb85-6b26-e5b8-50a9-7565c39b0c28@tik.ee.ethz.ch> From: Jana Iyengar Date: Thu, 8 Dec 2016 09:39:13 -0800 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=94eb2c07b01cb0d8540543291d69 Archived-At: Cc: plus@ietf.org, =?UTF-8?Q?Mirja_K=C3=BChlewind?= Subject: Re: [Plus] Blog post on quic and tou X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 17:39:19 -0000 --94eb2c07b01cb0d8540543291d69 Content-Type: text/plain; charset=UTF-8 Hi Brian, I'm largely in agreement; a couple of thoughts inline. On Thu, Dec 8, 2016 at 1:35 AM, Brian Trammell wrote: > hi Jana, > > > On 07 Dec 2016, at 22:35, Jana Iyengar wrote: > > > > Thanks for forwarding the article. I'll offer some thoughts (and some > corrections.) > > > > There's surely a solid argument to be made about network monitoring, as > this blog post makes. Operators' needs are real, and we need to ensure that > they are able to reasonably do the things that they need to do. At least > for QUIC, exposing a small additional bit of information addresses ~80% of > the use cases mentioned in the document: a "largest acked" ack number on > all packets (or at least packets that contain acks). I won't design this > mechanism on this list, > > (...noting that this list exists *precisely* for designing this mechanism > ;) but yes, details should happen on the quic@ list...) > > > but I'll note that it's a conversation that's happening in several > corners in the QUIC wg. It needs to be aired and discussed, and I expect it > to happen relatively soon. > > For those not familiar with the details of IETF-quic (which AFAIK from > others' implementation reports diverges somewhat from the version of QUIC > deployed by Google right now, and will diverge more during the WG's work): > the packet number is already exposed. Together with highest-ack, this > allows one-observation-point split-RTT measurement with an unknown > responder delay term, equivalent to TCP; two-observation-point approaches > for loss measurement; and one-observation-point approaches for loss > estimation to work with more information about the dynamics of the > particular version of QUIC running, also similar to TCP. > > I personally think we can do a good deal better than this with epsilon > more complexity and overhead, without either constraining QUIC's transport > dynamics or requiring measurement devices to know about the details of > those dynamics. Need to do a bit more work before I can say how small > epsilon is, though. > > Missing is more detailed information about TCP dynamics mentioned in the > post. Many of these are TCP (and CC algorithm) specific, so it doesn't make > much sense to expose the same information, though each of the requirements > implicit in the list is worth evaluating separately for its > ossification/security/utility tradeoff. > > One requirement from that list that seems quite useful, though I don't > know how to solve in the general case or in QUIC specifically: "determine > [if] the software on the client or the server is the bottleneck". This is a > very common triage task in network operations: does this problem indicate a > misconfiguration of my network, or (more cynically) can I demonstrate that > it's not my fault and therefore not my problem? Requiring access to one or > both endpoint machines to answer that... seems like a question for a future > Internet architecture research project. This can be done by measuring at ingress and egress. A simplistic design, at a high level, is: (i) use packet number / ack number to measure queue buildup and loss downstream of the ingress point, measured at the ingress. (ii) use packet number / ack number to measure queue buildup and loss downstream of the egress point, measured at the egress. (iii) subtract (ii) from (i) to find queue buildup and loss in the network. That at least gets you as far as identifying the problem as in the network or outside it. > The article though looks at real needs and current tools that operators > have, and over-generalizes to saying that the "entire header" should be > visible. My argument remains that only what is absolutely required should > be exposed, and that every bit exposed should be debated. > > I would go further (again, this is the philosophical underpinning of PLUS, > to the extent that it has one): the design of the header that is exposed > unencrypted to the network (which constitutes its "wire image") should be > treated as an entirely separate endeavour than the design of the transport > protocol machinery. > > > This is not a security argument, it's an ossification one. The whole > point of ossification is that there are third parties that are unresponsive > to changes in allegedly e2e protocols. Middleboxes are reactive. If they > see traffic shifting a particular way, they'll go build something in > response -- I've seen this happen several times. But, they are not > proactive. This creates a serious "deployment impossibility cycle" where > deploying a protocol change widely requires it to work through a huge range > of middleboxes, but even high-end middleboxes will not change behavior in > response until the protocol change is widely deployed. > > My (possibly starry-eyed optimistic) hope is that a deliberately designed > wire image will create a path of least resistance for middlebox designs to > (reactively) follow. A well-designed wire image should be so obvious that > the in-network reaction will be the one desired by the designers evenfor > middleboxes built by people who didn't read the spec. > The problem that remains is that once middeboxes react to certain bits, deployment of changes to those bits requires herculean effort, as we see with TFO. But this is exactly the tradeoff -- every bit that is exposed may help the operator, but loses agility. --94eb2c07b01cb0d8540543291d69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Brian,

I'm largely in agreement;= a couple of thoughts inline.=C2=A0

On Thu, Dec 8, 2016 at 1:35 AM, Brian Trammell <ietf@= trammell.ch> wrote:
hi Jana,

> On 07 Dec 2016, at 22:35, Jana Iyengar <jri@google.com> wrote:
>
> Thanks for forwarding the article. I'll offer some thoughts (and s= ome corrections.)
>
> There's surely a solid argument to be made about network monitorin= g, as this blog post makes. Operators' needs are real, and we need to e= nsure that they are able to reasonably do the things that they need to do. = At least for QUIC, exposing a small additional bit of information addresses= ~80% of the use cases mentioned in the document: a "largest acked&quo= t; ack number on all packets (or at least packets that contain acks). I won= 't design this mechanism on this list,

(...noting that this list exists *precisely* for designing this mech= anism ;) but yes, details should happen on the quic@ list...)

> but I'll note that it's a conversation that's happening in= several corners in the QUIC wg. It needs to be aired and discussed, and I = expect it to happen relatively soon.

For those not familiar with the details of IETF-quic (which AFAIK fr= om others' implementation reports diverges somewhat from the version of= QUIC deployed by Google right now, and will diverge more during the WG'= ;s work): the packet number is already exposed. Together with highest-ack, = this allows one-observation-point split-RTT measurement with an unknown res= ponder delay term, equivalent to TCP; two-observation-point approaches for = loss measurement; and one-observation-point approaches for loss estimation = to work with more information about the dynamics of the particular version = of QUIC running, also similar to TCP.

I personally think we can do a good deal better than this with epsilon more= complexity and overhead, without either constraining QUIC's transport = dynamics or requiring measurement devices to know about the details of thos= e dynamics. Need to do a bit more work before I can say how small epsilon i= s, though.

Missing is more detailed information about TCP dynamics mentioned in the po= st. Many of these are TCP (and CC algorithm) specific, so it doesn't ma= ke much sense to expose the same information, though each of the requiremen= ts implicit in the list is worth evaluating separately for its ossification= /security/utility tradeoff.

One requirement from that list that seems quite useful, though I don't = know how to solve in the general case or in QUIC specifically: "determ= ine [if] the software on the client or the server is the bottleneck". = This is a very common triage task in network operations: does this problem = indicate a misconfiguration of my network, or (more cynically) can I demons= trate that it's not my fault and therefore not my problem? Requiring ac= cess to one or both endpoint machines to answer that... seems like a questi= on for a future Internet architecture research project.
This can be done by measuring at ingress and egress. A simplis= tic design, at a high level, is:
(i) use packet number / ack numb= er to measure queue buildup and loss downstream of the ingress point, measu= red at the ingress.
(ii) use packet number / ack number to measur= e queue buildup and loss downstream of the egress point, measured at the eg= ress.
(iii) subtract (ii) from (i) to find queue buildup and loss= in the network.

That at least gets you as far as = identifying the problem as in the network or outside it.=C2=A0
> The article though looks at real needs and current tools that operator= s have, and over-generalizes to saying that the "entire header" s= hould be visible. My argument remains that only what is absolutely required= should be exposed, and that every bit exposed should be debated.

I would go further (again, this is the philosophical underpinning of= PLUS, to the extent that it has one): the design of the header that is exp= osed unencrypted to the network (which constitutes its "wire image&quo= t;) should be treated as an entirely separate endeavour than the design of = the transport protocol machinery.

> This is not a security argument, it's an ossification one. The who= le point of ossification is that there are third parties that are unrespons= ive to changes in allegedly e2e protocols. Middleboxes are reactive. If the= y see traffic shifting a particular way, they'll go build something in = response -- I've seen this happen several times. But, they are not proa= ctive. This creates a serious "deployment impossibility cycle" wh= ere deploying a protocol change widely requires it to work through a huge r= ange of middleboxes, but even high-end middleboxes will not change behavior= in response until the protocol change is widely deployed.

My (possibly starry-eyed optimistic) hope is that a deliberately des= igned wire image will create a path of least resistance for middlebox desig= ns to (reactively) follow. A well-designed wire image should be so obvious = that the in-network reaction will be the one desired by the designers evenf= or middleboxes built by people who didn't read the spec.

The problem that remains is that once middeboxes reac= t to certain bits, deployment of changes to those bits requires herculean e= ffort, as we see with TFO. But this is exactly the tradeoff -- every bit th= at is exposed may help the operator, but loses agility.

--94eb2c07b01cb0d8540543291d69-- From nobody Thu Dec 8 12:40:16 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EF201296C9 for ; Thu, 8 Dec 2016 12:40:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 2Y_BPPdhi682 for ; Thu, 8 Dec 2016 12:40:12 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id D62061296CB for ; Thu, 8 Dec 2016 12:40:07 -0800 (PST) Received: from [10.0.27.103] (dynamic-94-247-222-033.glattnet.ch [94.247.222.33]) by trammell.ch (Postfix) with ESMTPSA id 46F951A00B8; Thu, 8 Dec 2016 21:40:06 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8B59904D-7909-4E3A-A525-5BA65773307D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Thu, 8 Dec 2016 21:40:05 +0100 Message-Id: <641657F3-1D8A-420E-94D4-19D5FAA61715@trammell.ch> References: <6850cb85-6b26-e5b8-50a9-7565c39b0c28@tik.ee.ethz.ch> To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: plus@ietf.org, =?utf-8?Q?Mirja_K=C3=BChlewind?= Subject: Re: [Plus] Blog post on quic and tou X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 20:40:14 -0000 --Apple-Mail=_8B59904D-7909-4E3A-A525-5BA65773307D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, (inline, trimmed where appropriate) > On 08 Dec 2016, at 18:39, Jana Iyengar wrote: >=20 > Hi Brian, >=20 > I'm largely in agreement; a couple of thoughts inline. >=20 >> One requirement from that list that seems quite useful, though I = don't know how to solve in the general case or in QUIC specifically: = "determine [if] the software on the client or the server is the = bottleneck". This is a very common triage task in network operations: = does this problem indicate a misconfiguration of my network, or (more = cynically) can I demonstrate that it's not my fault and therefore not my = problem? Requiring access to one or both endpoint machines to answer = that... seems like a question for a future Internet architecture = research project. >>=20 > This can be done by measuring at ingress and egress. A simplistic = design, at a high level, is: > (i) use packet number / ack number to measure queue buildup and loss = downstream of the ingress point, measured at the ingress. > (ii) use packet number / ack number to measure queue buildup and loss = downstream of the egress point, measured at the egress. > (iii) subtract (ii) from (i) to find queue buildup and loss in the = network. >=20 > That at least gets you as far as identifying the problem as in the = network or outside it. This requires a few properties, all of which would be satisfied by a = QUIC that exports a packet number that always increments by one, even = for zero-payload and packets with retransmitted frame (which I note it = does unless I'm reading wrong), and exported an ack number that's really = more of a "max packet number echo" (since the heuristics to make this = work with TCP require you to ignore ACKs under loss conditions). (A = delta term Note that this is a two-point measurement methodology, which requires a = far more elaborate measurement infrastructure than a one-point = methodology, which basically just needs wireshark. The infrastructure = requirements for diagnosis of a particular problem given a particular = wire image are also a point to consider in the tradeoff space. (Or, more = cynically again, as someone who's spent a lot of time building = measurement infrastructures, thank you for pointing out a business = opportunity. :) ) >> My (possibly starry-eyed optimistic) hope is that a deliberately = designed wire image will create a path of least resistance for middlebox = designs to (reactively) follow. A well-designed wire image should be so = obvious that the in-network reaction will be the one desired by the = designers evenfor middleboxes built by people who didn't read the spec. >=20 > The problem that remains is that once middeboxes react to certain = bits, deployment of changes to those bits requires herculean effort, as = we see with TFO. But this is exactly the tradeoff -- every bit that is = exposed may help the operator, but loses agility. Agree here completely. This isn't a "problem", rather it indicates a = hard requirement to keep that wire image as minimal as possible. Cheers, Brian --Apple-Mail=_8B59904D-7909-4E3A-A525-5BA65773307D 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 iQIcBAEBCgAGBQJYScUmAAoJEIoSt78L6kajWesQAMQWjdXY9j3Q3AXrnpexXX5d +cbT8Ywu+St+QbMUHMTUGRH/+8rfk7bLbCFngDHlZvDqThd3o7WyDV41tZcqIUBh rqmS7yGq6/Jt1R15ZMB4swDgQSe1kLpzuaDvhh7R+jdw0kUADPk2HwhTSdA2CPAv xAH93X7BY3823X/AKnMHE1cjdiGdNrCglOtFAzdeBminiVnSeZ7+/fAS5Ozs4WTX c00UKAjPw7D02Ru30KhILC1Dkvcx1aAYQKSiN1Yizz9ugJpmgbhOfNa3krO8RS8V H+nt2Zknf/WmwbFltQUkvofDzJEkauABsAieoZaLu7Jzn0rTu5ZzivxHymSvzwu8 PbrbeaHRNccCH+HY6P2BM2mCqKWRwtXZ2ZAR838EfBnQ3B9S7QyswUdiP29l5rBI TEUKUnR14MUmuwizc9xCkVt0IR+88KVup/IWkHB6KXOP2gwlEe6pyNaKBYfN0s8V LSfIdUOutnh1JTfx5Z/zZpTIqtKwmoDIMEweDr4/CmAo2xbI6gTVkcZMYaA/OTHn kC2IhKUusGkCqv2ePLzxc7ZQM7zN/LmtUP5TXAOTwI8fBpyB0MSp5p0ZQTUtSUom 6fwblvTjU7iZtALFUXAN3cnfPXluwPo0Kw/Wc3xEDjyzxxVooNApQc1/+gnuTsqY IkbrQGJnGnOQhP7A+mZt =rWSn -----END PGP SIGNATURE----- --Apple-Mail=_8B59904D-7909-4E3A-A525-5BA65773307D-- From jsnell@gmail.com Fri Dec 9 01:05:39 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DE012A285 for ; Fri, 9 Dec 2016 01:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 PUaYuK7YWKgU for ; Fri, 9 Dec 2016 01:05:37 -0800 (PST) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B679B12A280 for ; Fri, 9 Dec 2016 01:05:37 -0800 (PST) Received: by mail-io0-x244.google.com with SMTP id p13so5500866ioi.0 for ; Fri, 09 Dec 2016 01:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vtdOpoM+ez1h8kPyGyk18EN1adLvyfnMkObPIr7Gwr0=; b=jqc3cz3rng8nltjcej3sb9MytdB4da/6hBFe8C4DZE8/cLHVw24Nozly6R3DvPnNNk 4wfR4VOasxaba2xSpNG6oChvjcE3VZKYyNoT76kWVmc41sYDj2KDUOTP4nKLrqILH04O sofN/KH0bNRTOHEbEVM5Rq8dN1bQB35Hst8cKEa2bjKT7SP1AH2lu2HjfbSPvfjFTON5 8P2mdvQmb/Slch/p3kPVUq3LGZNYOaLyVisHj9ftCl3bu9258BfFFR7w2JAYnKz28mQK yT3WYFR1vOge7abPPvH2ivrinnSPgktdwNSzQi9qIE8lg1heDm7K+VzO2/rHycJGSR9V huQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vtdOpoM+ez1h8kPyGyk18EN1adLvyfnMkObPIr7Gwr0=; b=CdJoZfZaYtXd7WfhvJKo8kobhwDdOEf0PdypheLgzr7Xx6mE9RWMe8KFDGiBLtb0JL 3cv6oJxq4xW2ItgbWvG7Ba/PYgmh8PwudrEGs0TeGYw3u9lyRLjeyr6Mh42kKSRQkaOV w4/YC+mzjuXP8tDyVEQ95LjnNg5WfiN8MHDRM4U8V//G31jdyY5ilXa+Qk8y08skzYvD ZOr99vWidG23ivtjU/8IVndChAFcM8ff5ePvx6fpjuth3JzgUp5/6kxB0iOFRvF7IB/g 4mxyobA/fR7t494JqB73pmA65dxlwccbF3yHyxwCSAfej0/NITJ2/4vavr1G/SEHeIRh KghQ== X-Gm-Message-State: AKaTC03L5M6xtzxWH9EBPMjur2+39nCUoWZJ4AqRHVACf/SuaTB0aNIB/gbLgqfjetKhYu6KXD3IPHwOB1SyOg== X-Received: by 10.36.104.146 with SMTP id v140mr5792254itb.65.1481274337028; Fri, 09 Dec 2016 01:05:37 -0800 (PST) MIME-Version: 1.0 Sender: jsnell@gmail.com Received: by 10.64.81.67 with HTTP; Fri, 9 Dec 2016 01:05:36 -0800 (PST) In-Reply-To: <641657F3-1D8A-420E-94D4-19D5FAA61715@trammell.ch> References: <6850cb85-6b26-e5b8-50a9-7565c39b0c28@tik.ee.ethz.ch> <641657F3-1D8A-420E-94D4-19D5FAA61715@trammell.ch> From: Juho Snellman Date: Fri, 9 Dec 2016 10:05:36 +0100 X-Google-Sender-Auth: hyCFfxfAFfIe_4I-xC0b-5EBNLU Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a1143ff7aac70830543360e28 Archived-At: Cc: Jana Iyengar , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , plus@ietf.org Subject: Re: [Plus] Blog post on quic and tou X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 09:09:48 -0000 --001a1143ff7aac70830543360e28 Content-Type: text/plain; charset=UTF-8 Hi, On 8 December 2016 at 21:40, Brian Trammell wrote: > > Note that this is a two-point measurement methodology, which requires a > far more elaborate measurement infrastructure than a one-point methodology, > which basically just needs wireshark. The infrastructure requirements for > diagnosis of a particular problem given a particular wire image are also a > point to consider in the tradeoff space. (Or, more cynically again, as > someone who's spent a lot of time building measurement infrastructures, > thank you for pointing out a business opportunity. :) ) > With measurements from all points in the network the encryption becomes a non-issue anyway; we'd simply match up the packets between the traces. So exposing information that's only useful in a multi-point context doesn't seem all that compelling to me. My experience is that there's a huge difference in the amount of effort needed to get a single point trace vs. multiple traces. The first one has basically no lead time, and can be just part of normal operating procedure when investigating a problem report. The second tends to require careful coordination across multiple groups, often a lead time of several days, and gets routinely botched when traffic isn't being routed exactly as expected. (I'm not aware of any easy to use tools for doing multi-trace analysis either. That'd of course change if such tools become a necessity instead of a luxury). A packet number + ack number would indeed be the most useful thing to expose, since it gives downstream RTTs and upstream packet loss. It doesn't really do much for downstream packet loss though, which is a pretty important component. For that, I think you'd want one of the following (in order of preference): - All the nack blocks - The latest nack block - The number of nack blocks - A "this packet is a retransmission" bit in data packets. (Though this would have other uses than just monitoring). - A "there is at least one nack block" bit (this is weak enough that you'd probably need a lot of heuristics) After packet numbers, acks, and some kind of a reliable nack signal, diminishing returns start to kick in, at least for the purpose of finding network level problems. I wouldn't be quite as cynical about client / server problems as you were, though :) It's not simply a way to close a case as "not my problem"; it's that it's easier and faster to prove a specific component is the problem than to prove that the network as a whole isn't. > The problem that remains is that once middeboxes react to certain bits, > deployment of changes to those bits requires herculean effort, as we see > with TFO. But this is exactly the tradeoff -- every bit that is exposed may > help the operator, but loses agility. > > Agree here completely. This isn't a "problem", rather it indicates a hard > requirement to keep that wire image as minimal as possible. > Sure. When writing that post, I wasn't aware there was a discussion about having more information outside the encryption envelope. So the contrast was between "everything readable" vs. "nothing is readable". Of course I'd always love to have more data available :) But if there's a sweet spot that exposes just enough information, that'd be great. -- Juho Snellman --001a1143ff7aac70830543360e28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On 8 December 2016 at 21:40, Brian Trammell <<= a href=3D"mailto:ietf@trammell.ch" target=3D"_blank">ietf@trammell.ch&g= t; wrote:
Note that this is a two-point measurement methodology, which requires a far= more elaborate measurement infrastructure than a one-point methodology, wh= ich basically just needs wireshark. The infrastructure requirements for dia= gnosis of a particular problem given a particular wire image are also a poi= nt to consider in the tradeoff space. (Or, more cynically again, as someone= who's spent a lot of time building measurement infrastructures, thank = you for pointing out a business opportunity. :) )

=
With measurements from all points in the network the encryp= tion becomes a non-issue anyway; we'd simply match up the packets betwe= en the traces. So exposing information that's only useful in a multi-po= int context doesn't seem all that compelling to me.

My experience is that there's a huge difference in the amount of = effort needed to get a single point trace vs. multiple traces. The first on= e has basically no lead time, and can be just part of normal operating proc= edure when investigating a problem report. The second tends to require care= ful coordination across multiple groups, often a lead time of several days,= and gets routinely botched when traffic isn't being routed exactly as = expected. (I'm not aware of any easy to use tools for doing multi-trace= analysis either. That'd of course change if such tools become a necess= ity instead of a luxury).

A packet number + ack nu= mber would indeed be the most useful thing to expose, since it gives downst= ream RTTs and upstream packet loss. It doesn't really do much for downs= tream packet loss though, which is a pretty important component. For that, = I think you'd want one of the following (in order of preference):
=

- All the nack blocks
- The latest nack block=
- The number of nack blocks
- A "this packet is a= retransmission" bit in data packets. (Though this would have other us= es than just monitoring).
- A "there is at least one nack bl= ock" bit (this is weak enough that you'd probably need a lot of he= uristics)

After packet numbers, acks, and some kin= d of a reliable nack signal, diminishing returns start to kick in, at least= for the purpose of finding network level problems.

I wouldn't be quite as cynical about client / server problems as you = were, though :) It's not simply a way to close a case as "not my p= roblem"; it's that it's easier and faster to prove a specific = component is the problem than to prove that the network as a whole isn'= t.=C2=A0

> The problem that remains is that once middeboxes react to certain bits= , deployment of changes to those bits requires herculean effort, as we see = with TFO. But this is exactly the tradeoff -- every bit that is exposed may= help the operator, but loses agility.

Agree here completely. This isn't a "problem", rather = it indicates a hard requirement to keep that wire image as minimal as possi= ble.

Sure. When = writing that post, I wasn't aware there was a discussion about having m= ore information outside the encryption envelope. So the contrast was betwee= n "everything readable" vs. "nothing is readable". Of c= ourse I'd always love to have more data available :) But if there's= a sweet spot that exposes just enough information, that'd be great.

--
Juho Snellman
--001a1143ff7aac70830543360e28-- From nobody Fri Dec 9 04:09:12 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F206129FC6 for ; Fri, 9 Dec 2016 04:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 vZQB6F5KbWrG for ; Fri, 9 Dec 2016 04:09:07 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC412A516 for ; Fri, 9 Dec 2016 03:55:48 -0800 (PST) Received: from public-docking-etx-0900.ethz.ch (public-docking-pat-etx-mapped-0019.ethz.ch [195.176.110.244]) by trammell.ch (Postfix) with ESMTPSA id CC2301A086B for ; Fri, 9 Dec 2016 12:55:15 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_1FD89851-1AF6-4733-BC55-98FAF6B53D5D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> Date: Fri, 9 Dec 2016 12:55:15 +0100 Message-Id: <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> To: plus@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 12:09:11 -0000 --Apple-Mail=_1FD89851-1AF6-4733-BC55-98FAF6B53D5D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We were sitting around a whiteboard yesterday, thinking about (1) how to = implement the signals required to drive the state machine outlined in = the -plus-statefulness-01 draft, and (2) how to provide on-path = diagnosability as we're discussing in the thread on Juho's blog post. = Indeed, we think these two use cases are by far the most important for = PLUS, in that they provide equivalent-to-TCP support for basic = operations and troubleshooting practices for encrypted, UDP-encapsulated = transports like QUIC, and one could implement either of them in QUIC = directly without much disruption. We came up with two implementation sketches, both of which use the same = header fields to drive the association and confirmation signals as well = as basic measurability. The simpler one is pretty much the design Jana alluded to in his = previous message. It looks kind of like TCP on the wire, and has = basically the same properties.It uses three header fields: a connection = ID which appears in packets of both directions and is chosen by the = connection initiator; a packet serial number (PSN) whose initial value = in each direction is chosen randomly by the sender (like the TCP = sequence number, and as under discussion for QUIC) and is incremented by = one for each packet sent regardless of content or lack thereof (like the = QUIC packet number); and a maximum packet serial echo, which is the = highest packet number received by the sender before a packet was sent. This provides an association signal on the initial echo of the = initiator's PSN, and a confirmation signal on the initiator's initial = echo of the responder's PSN -- just like the ack numbers on the SYN/ACK = and ACK legs of the TCP handshake. The connection ID here simply = provides additional bits of protection against completely off-path = attempts to force the state machine to tick over. Note there's no need = for SYN or ACK flags -- the association and confirmation signals = continually demonstrate that each side has seen packets from the other = side. A stop signal is considered authentic if it has a correct connection ID = and a plausible PSN. This is path-verifiable, but provides no protection = against on-path or path-side injection attacks against state on = middleboxes (though, note that since even unencrypted headers are = authenticated, the endpoint can always detect an attempt to inject a = stop). A variation of the mechanism described in statefulness-01 would = use a two-way stop signal: a stop is only considered valid along the = path if one endpoint sends a stop signal in reply to the other = endpoint's stop signal. This would make the path-side injection much = harder to perform: in order to remove state on a given middlebox = (presuming said middlebox isn't stupid about accepting packets from = anywhere), the attacker would need to be able to inject packets on the = interfaces facing both endpoints. One-point measurement of the PSN and echo streams gives you two-sided = RTT and upstream loss and reordering. Coordinated two-point analysis = gives you a lot more. As noted, though, two-point analysis is far more = complex. This approach has the advantage of being extremely simple (it meets the = "someone with wireshark could reverse-engineer this in an hour or so" = requirement), and very close to what's there in QUIC right now. If = implemented with a small number of possible header layouts (preferably = one) the wire image could be trivially offloaded to hardware. It all of the disadvantages as SEQ/ACK tracking in TCP, and of = resistance to off-path meddling that TCP sequence numbers do, though it = does give better RTT indication on lossy links (since the echo is always = the max packet number, not the highest continuous ack), and two-side = stop is better than RST at resisting path-side attacks. The definition = of "plausible" next PSN or "plausible" echo when seen at a midpoint = device is fuzzy, which could lead to difficult to debug problems with = middleboxes that try to drop packets with implausible values (as some = state-tracking TCP firewalls do now). The second one replaces the packet number and the echo with a token and = a nonce. The connection initiator chooses an initial random token and a = nonce. The connection responder applies a function to the token and = nonce to generate its own token, and chooses a random nonce. Each side = generates a new token from the token and nonce it receives each time the = token it receives changes. Like the simpler implementation, this one = provides continual association and confirmation signals. It also = provides one-point measurement of RTT, since the token change is an = RTT-clocked signal. The RTT clock would also behave odd ways under = high-reordering situations, and additional complexity (which involves = remembering a few past tokens, but which we didn't work through) would = be needed to fix that. The token and nonce could be separate from an additional connection ID, = or the connection ID and the token could be the same -- though this = would require much more state to be kept everywhere in order to allow = the connection ID to be useful for NAT rebinding and injection defense = purposes. The main advantage over the simpler approach is that the fuzziness = around plausible PSNs and echoes goes away, as does the predictability = of association and confirmation values after the initial connection = establishment. However, it does not provide loss measurement without = additional information, and it places more state and processing = requirements on endpoints. Either of these mechanisms could used together with a path-and-endpoint = verifiable, on-path and side-path attack resistant stop signal: during = connection setup each endpoint generates a random value, and exposes the = result of the application of a hash function to that random value as its = stop signal proof. To send a stop signal, it reveals the random value as = a stop signal verification (this is the essence of PR#20 on QUIC). Any = endpoint or on-path device can verify that the hash of the verification = is the proof. Of course, devices that don't keep the proof value (or = never saw it) can't verify it. The tradeoff here is additional = complexity versus additional resistance against path-side injection = meddling with state on middleboxes. Simple packet number and echo signaling for association and confirmation = signaling with two-way stop seems to us like a reasonable "minimal = functionality set" at the moment. Thoughts? Cheers, Brian and Mirja --Apple-Mail=_1FD89851-1AF6-4733-BC55-98FAF6B53D5D 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 iQIcBAEBCgAGBQJYSpujAAoJEIoSt78L6kajhLsP/08TqiMVc0XhRNoGDqsiGs2W Kgt3nVbq7FLFlA+R8Yv2Haeol7lbVE5ZscGyw22bzYgJlTLqTPybZJYGSDSaQaIL nIzeie7mpc0IaEkKqC5rzo1KsK2Qqkjk3wv2nBRxD8ns7Ut1fccQsKiNSCprXFOV /ZYbk3ySRr3aM4fymjTKTYHUbxW+iBDYheH8TrXHIggJ9OrCd90kXNYc69QNS++P OGejxqdr+OTgf5znnuhfLubDxnEOdOiLxWsENjLVL5D86Vp7n2AIWOvKwYLKWxLg U2OsNt7I9uXQjQBLFOE7C54x1xkcol1k66mf/p/HUmNz6fhOZDrVz0oIEgUTtppO 6Wa0OyPfJ99uF6Ghy7FK4NJLJ8gGLvgpCqY/PDVriRWcF2VctE5IXeoYvO8dsm/D pxQXtvWZ+AFCm/7TswLnblqgtQx+6n4voCNkgLKUSOEV1ICqKvh9nus+9miKSY+C zaPONgXSBFttyFgJzrTDqkmD10IsCBkylqaKQHvAWn2Fh0lmZpQaI6ehbuJ9ms9U Sj6ZOqaoGoAP5Nb2EMwk6nn0VcSLq4knRdNTo0HbuxlBkClugVPje8oVIsnAwGTv OsDkZg3qC4TWZIQTRY1YYBj87gwXgsXib08pu1y659KPQUlqBB+gm3PVbUJV6yOR F3DE/dVdWnog7fj6Q4Kr =jHYq -----END PGP SIGNATURE----- --Apple-Mail=_1FD89851-1AF6-4733-BC55-98FAF6B53D5D-- From nobody Fri Dec 9 07:41:25 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59152129460 for ; Fri, 9 Dec 2016 07:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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=-2.896, 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 CmWgaPKWRtzM for ; Fri, 9 Dec 2016 07:41:15 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E84112945F for ; Fri, 9 Dec 2016 07:41:15 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id i145so17157821ywg.2 for ; Fri, 09 Dec 2016 07:41:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ahqJuICsvS1mnlyOZ9Du1xerlxvz6mirEPaaXPdSz2Q=; b=VdlPMvKsBhe3rTVxW2rPYXjjBoqRI5OuqQoliQ3x8wITvALllHyNQN54HyrNlh5HXz QYvW4Cj+flcU2zVs2N9Y9RZAbpPtViMq8vBwNPhxKCwHP1tOhztpA2IzUrQHFcUURmQj fJbXzTJXGqUhwxbgdYiSiOwzPEjD/vCDEc0Pn8s/1v6nBUBkw9+E32nxPtkmDwhZwr0J NdJ41CGXZwnXs8bJC9nnLOJTp4rwjrXy9OYUhcy7MKtKtSJsJI3DbURsigCV2D5DIN+P WAgd9ZzvmFZ2jBI5ZunvOmbRwprL3SWy/0YTjMYv7kN+LPtg3fskOL8IrGtO5em9VCbX 0Efg== 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=ahqJuICsvS1mnlyOZ9Du1xerlxvz6mirEPaaXPdSz2Q=; b=l7UM/+7uorwEpINS+l5aT7wR9xkfpkY+uP0FbtWphTAhD/hE2tTnQarUcAjsH7QV26 HFP2pPbM5poBtex2a+z62KD8Qzh7EyblqtUP89VhvTRB42HUbSWCjATZFUunaAcxm9Nv lYLnYpxJFh7QXu8uFbcgDE5KDS1ci3Tf5HPEBpCOZfFPwFqJc3vnLLLKVitg5GGYz43S FjsP35LIpTFrQT3cLI1H5di/3mEEbgP5Zytd3AU7Qr4J81tLIkAPalUd7xUih0UVDzO3 /ClcepYsS4eE8eNfatCcWIMlnQ23gC1jKmX2b9sxzKV+sNP+fnRfOEU2u6O21Luz+lsv f5Eg== X-Gm-Message-State: AKaTC01wXWr3NMtwUBz4W88U24cjkbZDeEEUzW4J8WLVVqTkvgy4O/RZunW+OJYQwM6pfpZoj1/f6vDNd3+3Wp5I X-Received: by 10.129.78.205 with SMTP id c196mr79647305ywb.63.1481298074368; Fri, 09 Dec 2016 07:41:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Fri, 9 Dec 2016 07:40:53 -0800 (PST) In-Reply-To: <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> From: Ian Swett Date: Fri, 9 Dec 2016 10:40:53 -0500 Message-ID: To: Brian Trammell Content-Type: multipart/alternative; boundary=001a114db8ea88143705433b9572 Archived-At: Cc: plus@ietf.org Subject: Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Dec 2016 15:41:23 -0000 --001a114db8ea88143705433b9572 Content-Type: text/plain; charset=UTF-8 I have been discussing the first option with people for a while, and everyone has indicated it's relatively simple to implement, potentially even in hardware, and provides quite a bit of extra useful information(RTT, approximate bandwidth) over QUIC's status quo. I believe packet numbers being in order makes the first case both easier to implement and provides some valuable extra information(it's easy to infer upstream loss and reordering), so I think it's definitely a better approach. Also, given an equal number of bytes spent on the echo, I think they both have about the same fuzziness properties. For example, if 2 bytes were used in the first case, assuming this echo must be monotonically increasing, an ack or packet gap of over 65,000 packets would have to occur for the signal to be misinterpreted. If we're getting 65,000 packet gaps, we might be outside the realm of QUIC's wire format to help you diagnose your network issues, to put it mildly. On Fri, Dec 9, 2016 at 6:55 AM, Brian Trammell wrote: > Greetings, all, > > We were sitting around a whiteboard yesterday, thinking about (1) how to > implement the signals required to drive the state machine outlined in the > -plus-statefulness-01 draft, and (2) how to provide on-path diagnosability > as we're discussing in the thread on Juho's blog post. Indeed, we think > these two use cases are by far the most important for PLUS, in that they > provide equivalent-to-TCP support for basic operations and troubleshooting > practices for encrypted, UDP-encapsulated transports like QUIC, and one > could implement either of them in QUIC directly without much disruption. > > We came up with two implementation sketches, both of which use the same > header fields to drive the association and confirmation signals as well as > basic measurability. > > > The simpler one is pretty much the design Jana alluded to in his previous > message. It looks kind of like TCP on the wire, and has basically the same > properties.It uses three header fields: a connection ID which appears in > packets of both directions and is chosen by the connection initiator; a > packet serial number (PSN) whose initial value in each direction is chosen > randomly by the sender (like the TCP sequence number, and as under > discussion for QUIC) and is incremented by one for each packet sent > regardless of content or lack thereof (like the QUIC packet number); and a > maximum packet serial echo, which is the highest packet number received by > the sender before a packet was sent. > > This provides an association signal on the initial echo of the initiator's > PSN, and a confirmation signal on the initiator's initial echo of the > responder's PSN -- just like the ack numbers on the SYN/ACK and ACK legs of > the TCP handshake. The connection ID here simply provides additional bits > of protection against completely off-path attempts to force the state > machine to tick over. Note there's no need for SYN or ACK flags -- the > association and confirmation signals continually demonstrate that each side > has seen packets from the other side. > > A stop signal is considered authentic if it has a correct connection ID > and a plausible PSN. This is path-verifiable, but provides no protection > against on-path or path-side injection attacks against state on middleboxes > (though, note that since even unencrypted headers are authenticated, the > endpoint can always detect an attempt to inject a stop). A variation of the > mechanism described in statefulness-01 would use a two-way stop signal: a > stop is only considered valid along the path if one endpoint sends a stop > signal in reply to the other endpoint's stop signal. This would make the > path-side injection much harder to perform: in order to remove state on a > given middlebox (presuming said middlebox isn't stupid about accepting > packets from anywhere), the attacker would need to be able to inject > packets on the interfaces facing both endpoints. > > One-point measurement of the PSN and echo streams gives you two-sided RTT > and upstream loss and reordering. Coordinated two-point analysis gives you > a lot more. As noted, though, two-point analysis is far more complex. > > This approach has the advantage of being extremely simple (it meets the > "someone with wireshark could reverse-engineer this in an hour or so" > requirement), and very close to what's there in QUIC right now. If > implemented with a small number of possible header layouts (preferably one) > the wire image could be trivially offloaded to hardware. > > It all of the disadvantages as SEQ/ACK tracking in TCP, and of resistance > to off-path meddling that TCP sequence numbers do, though it does give > better RTT indication on lossy links (since the echo is always the max > packet number, not the highest continuous ack), and two-side stop is better > than RST at resisting path-side attacks. The definition of "plausible" next > PSN or "plausible" echo when seen at a midpoint device is fuzzy, which > could lead to difficult to debug problems with middleboxes that try to drop > packets with implausible values (as some state-tracking TCP firewalls do > now). > > > The second one replaces the packet number and the echo with a token and a > nonce. The connection initiator chooses an initial random token and a > nonce. The connection responder applies a function to the token and nonce > to generate its own token, and chooses a random nonce. Each side generates > a new token from the token and nonce it receives each time the token it > receives changes. Like the simpler implementation, this one provides > continual association and confirmation signals. It also provides one-point > measurement of RTT, since the token change is an RTT-clocked signal. The > RTT clock would also behave odd ways under high-reordering situations, and > additional complexity (which involves remembering a few past tokens, but > which we didn't work through) would be needed to fix that. > > The token and nonce could be separate from an additional connection ID, or > the connection ID and the token could be the same -- though this would > require much more state to be kept everywhere in order to allow the > connection ID to be useful for NAT rebinding and injection defense purposes. > > The main advantage over the simpler approach is that the fuzziness around > plausible PSNs and echoes goes away, as does the predictability of > association and confirmation values after the initial connection > establishment. However, it does not provide loss measurement without > additional information, and it places more state and processing > requirements on endpoints. > > > Either of these mechanisms could used together with a path-and-endpoint > verifiable, on-path and side-path attack resistant stop signal: during > connection setup each endpoint generates a random value, and exposes the > result of the application of a hash function to that random value as its > stop signal proof. To send a stop signal, it reveals the random value as a > stop signal verification (this is the essence of PR#20 on QUIC). Any > endpoint or on-path device can verify that the hash of the verification is > the proof. Of course, devices that don't keep the proof value (or never saw > it) can't verify it. The tradeoff here is additional complexity versus > additional resistance against path-side injection meddling with state on > middleboxes. > > > Simple packet number and echo signaling for association and confirmation > signaling with two-way stop seems to us like a reasonable "minimal > functionality set" at the moment. > > Thoughts? > > Cheers, > > Brian and Mirja > > > _______________________________________________ > Plus mailing list > Plus@ietf.org > https://www.ietf.org/mailman/listinfo/plus > > --001a114db8ea88143705433b9572 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have been discussing the first option with people for a = while, and everyone has indicated it's relatively simple to implement, = potentially even in hardware, and provides quite a bit of extra useful info= rmation(RTT, approximate bandwidth) over QUIC's status quo.

I believe packet numbers being in order makes the first case both e= asier to implement and provides some valuable extra information(it's ea= sy to infer upstream loss and reordering), so I think it's definitely a= better approach.

Also, given an equal number of b= ytes spent on the echo, I think they both have about the same fuzziness pro= perties.=C2=A0 For example, if 2 bytes were used in the first case, assumin= g this echo must be monotonically increasing, an ack or packet gap of over = 65,000 packets would have to occur for the signal to be misinterpreted.=C2= =A0 If we're getting 65,000 packet gaps, we might be outside the realm = of QUIC's wire format to help you diagnose your network issues, to put = it mildly.=C2=A0



On Fri, Dec 9, 2016 at 6:55 AM, Br= ian Trammell <ietf@trammell.ch> wrote:
Greetings, all,

We were sitting around a whiteboard yesterday, thinking about (1) how to im= plement the signals required to drive the state machine outlined in the -pl= us-statefulness-01 draft, and (2) how to provide on-path diagnosability as = we're discussing in the thread on Juho's blog post. Indeed, we thin= k these two use cases are by far the most important for PLUS, in that they = provide equivalent-to-TCP support for basic operations and troubleshooting = practices for encrypted, UDP-encapsulated transports like QUIC, and one cou= ld implement either of them in QUIC directly without much disruption.

We came up with two implementation sketches, both of which use the same hea= der fields to drive the association and confirmation signals as well as bas= ic measurability.


The simpler one is pretty much the design Jana alluded to in his previous m= essage. It looks kind of like TCP on the wire, and has basically the same p= roperties.It uses three header fields: a connection ID which appears in pac= kets of both directions and is chosen by the connection initiator; a packet= serial number (PSN) whose initial value in each direction is chosen random= ly by the sender (like the TCP sequence number, and as under discussion for= QUIC) and is incremented by one for each packet sent regardless of content= or lack thereof (like the QUIC packet number); and a maximum packet serial= echo, which is the highest packet number received by the sender before a p= acket was sent.

This provides an association signal on the initial echo of the initiator= 9;s PSN, and a confirmation signal on the initiator's initial echo of t= he responder's PSN -- just like the ack numbers on the SYN/ACK and ACK = legs of the TCP handshake. The connection ID here simply provides additiona= l bits of protection against completely off-path attempts to force the stat= e machine to tick over. Note there's no need for SYN or ACK flags -- th= e association and confirmation signals continually demonstrate that each si= de has seen packets from the other side.

A stop signal is considered authentic if it has a correct connection ID and= a plausible PSN. This is path-verifiable, but provides no protection again= st on-path or path-side injection attacks against state on middleboxes (tho= ugh, note that since even unencrypted headers are authenticated, the endpoi= nt can always detect an attempt to inject a stop). A variation of the mecha= nism described in statefulness-01 would use a two-way stop signal: a stop i= s only considered valid along the path if one endpoint sends a stop signal = in reply to the other endpoint's stop signal. This would make the path-= side injection much harder to perform: in order to remove state on a given = middlebox (presuming said middlebox isn't stupid about accepting packet= s from anywhere), the attacker would need to be able to inject packets on t= he interfaces facing both endpoints.

One-point measurement of the PSN and echo streams gives you two-sided RTT a= nd upstream loss and reordering. Coordinated two-point analysis gives you a= lot more. As noted, though, two-point analysis is far more complex.

This approach has the advantage of being extremely simple (it meets the &qu= ot;someone with wireshark could reverse-engineer this in an hour or so"= ; requirement), and very close to what's there in QUIC right now. If im= plemented with a small number of possible header layouts (preferably one) t= he wire image could be trivially offloaded to hardware.

It all of the disadvantages as SEQ/ACK tracking in TCP, and of resistance t= o off-path meddling that TCP sequence numbers do, though it does give bette= r RTT indication on lossy links (since the echo is always the max packet nu= mber, not the highest continuous ack), and two-side stop is better than RST= at resisting path-side attacks. The definition of "plausible" ne= xt PSN or "plausible" echo when seen at a midpoint device is fuzz= y, which could lead to difficult to debug problems with middleboxes that tr= y to drop packets with implausible values (as some state-tracking TCP firew= alls do now).


The second one replaces the packet number and the echo with a token and a n= once. The connection initiator chooses an initial random token and a nonce.= The connection responder applies a function to the token and nonce to gene= rate its own token, and chooses a random nonce. Each side generates a new t= oken from the token and nonce it receives each time the token it receives c= hanges. Like the simpler implementation, this one provides continual associ= ation and confirmation signals. It also provides one-point measurement of R= TT, since the token change is an RTT-clocked signal. The RTT clock would al= so behave odd ways under high-reordering situations, and additional complex= ity (which involves remembering a few past tokens, but which we didn't = work through) would be needed to fix that.

The token and nonce could be separate from an additional connection ID, or = the connection ID and the token could be the same -- though this would requ= ire much more state to be kept everywhere in order to allow the connection = ID to be useful for NAT rebinding and injection defense purposes.

The main advantage over the simpler approach is that the fuzziness around p= lausible PSNs and echoes goes away, as does the predictability of associati= on and confirmation values after the initial connection establishment. Howe= ver, it does not provide loss measurement without additional information, a= nd it places more state and processing requirements on endpoints.


Either of these mechanisms could used together with a path-and-endpoint ver= ifiable, on-path and side-path attack resistant stop signal: during connect= ion setup each endpoint generates a random value, and exposes the result of= the application of a hash function to that random value as its stop signal= proof. To send a stop signal, it reveals the random value as a stop signal= verification (this is the essence of PR#20 on QUIC). Any endpoint or on-pa= th device can verify that the hash of the verification is the proof. Of cou= rse, devices that don't keep the proof value (or never saw it) can'= t verify it. The tradeoff here is additional complexity versus additional r= esistance against path-side injection meddling with state on middleboxes.

Simple packet number and echo signaling for association and confirmation si= gnaling with two-way stop seems to us like a reasonable "minimal funct= ionality set" at the moment.

Thoughts?

Cheers,

Brian and Mirja


_______________________________________________
Plus mailing list
Plus@ietf.org
https://www.ietf.org/mailman/listinfo/plus


--001a114db8ea88143705433b9572-- From nobody Sat Dec 10 16:35:28 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD91129552 for ; Sat, 10 Dec 2016 16:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C18qFTwTSjDp for ; Sat, 10 Dec 2016 16:35:24 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D0AA12947E for ; Sat, 10 Dec 2016 16:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1481416524; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4uyGDk8QrRWNhRVkYDP13ed1dQBz+MlN+aQz7bybCJs=; b=fc3zJFUyvunxtU1Ud/6ER/2OX785z9KFepWFweLeCsnX1tFIwUjeA6pxPNFCeJiv hkhz5EK++1L+4TYCJnZ8NL9ivR4+FbfcKe8RsQCEzXuGwYFLadkjUb3DrXT1aKk/ oKNILtwIq7PNryPpJwTzYwbRPVgEB2vvM8jA4meRS+V8iuqBm9Az3TZFsRCkp9I2 P+8rdp/owKSi67Ye+RwLr/qB3rUi1Pju7BSi1KQTdObvwiQt9GeAR+uzVolqKCN9 lcABj1W/8bct1WtZAcibPyQyyd9y8C4fg09CFsMz50eTmkSK1og8Od1t5ignTqdF jQjfrH7R7Q2qSsTOD35SIw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id F8.D5.22504.B4F9C485; Sat, 10 Dec 2016 16:35:24 -0800 (PST) X-AuditID: 11973e13-8abfb700000057e8-f0-584c9f4bd781 Received: from nwk-mmpp-sz06.apple.com (nwk-mmpp-sz06.apple.com [17.128.115.234]) by relay5.apple.com (Apple SCV relay) with SMTP id 09.1F.27929.B4F9C485; Sat, 10 Dec 2016 16:35:23 -0800 (PST) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_yHWucY0a6CaFdWvW7bLerA)" Received: from [17.153.31.41] (unknown [17.153.31.41]) by nwk-mmpp-sz06.apple.com (Oracle Communications Messaging Server 8.0.1.1.0 64bit (built Jun 15 2016)) with ESMTPSA id <0OHZ00DDDWAYLF20@nwk-mmpp-sz06.apple.com>; Sat, 10 Dec 2016 16:35:23 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: Date: Sat, 10 Dec 2016 16:35:22 -0800 In-reply-to: To: Ian Swett , Brian Trammell References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> X-Mailer: Apple Mail (2.3252) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi2FAYoesz3yfCYPN+Rouf93ayWmxsecdm 0dyc78DssWBTqceSJT+ZPJ7sn8kSwBzFZZOSmpNZllqkb5fAlbFs8iP2gjVLGSuO79zE1sD4 poOxi5GDQ0LARGLNdI4uRi4OIYG9jBKHZ75m7mLkBIs3vFvHBJE4xCgxp+MCWIJXQFDix+R7 LCA2s0CYxN0pv9ghijqYJNoWNTOBTBUWkJDYvCcRpIZNQEXi+LcNUL02Eqdmz2EFsYUFoiSm rT0ANodFQFVi6eKNYDanQLDEw13fWCHmC0qcnX4ZrFdEwE1i7/+NUAftYpR4OOc3O8SlshIr n25kBUlICExnl7jwq4N5AqPQLCTHzkJy7Cyg+5gF1CWmTMmFCGtLPHl3gRXCVpNY+HsRE7L4 Aka2VYxCuYmZObqZeaZ6iQUFOal6yfm5mxhB8THdTngH4+lVVocYBTgYlXh4XzT6RAixJpYV V+YeYpTmYFES5+118o4QEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwNh6fBfbs2a/urKIw9IP TH99Xy2lH3D1181lK6eLJJxblha65Wzjl6W8TyNZAkzW+WhbvK3aGFs0596UOffUfrXx2vZf XRmW2hXDcez4Ab1D7rUHrm76+sr9/9sM3fmKIUvabXn/me/afNDo8aNzWyRkJVim2Go+4du2 cOaTJzK/omXzjSLW3WpQYinOSDTUYi4qTgQAM4/hVHACAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsUi2FD8Std7vk+EwakWQ4uf93ayWmxsecdm 0dyc78DssWBTqceSJT+ZPJ7sn8kSwBxlbZOWX1SeWJSiUJRcUGKrVJyRmJJfHm9pbGTqkFhQ kJOql5yfq6RvZ5OSmpNZllqEzEqwzlg2+RF7wZqljBXHd25ia2B808HYxcjJISFgItHwbh0T hC0mceHeerYuRi4OIYFDjBJzOi4wgyR4BQQlfky+xwJiMwuESdyd8osdoqiDSaJtUTNQNweH sICExOY9iSA1bAIqEse/bYDqtZE4NXsOK4gtLBAlMW3tAbA5LAKqEksXbwSzOQWCJR7u+sYK MV9Q4uz0y2C9IgJuEnv/b2SC2LWLUeLhnN/sEJfKSqx8upF1AqPALCT3zUJy3yygk5gF1CWm TMmFCGtLPHl3gRXCVpNY+HsRE7L4Aka2VYwCRak5iZWmevDQ3MQIjqXCiB2M/5dZHWIU4GBU 4uF90egTIcSaWFZcmQsMJA5mJRHeWTOAQrwpiZVVqUX58UWlOanFhxj3MwJ9OZFZSjQ5Hxjp eSXxhsYWxpYmFgYGJpZmJoSFTUwMTIyNzYyNzU3MaSmsJM5r4ewdISSQnliSmp2aWpBaBPMC EwenVAPjlOlTXIuqs/lTDLQ65R9M+/113pPz/p8eu4a55ZxREynZbn+gxV7K4NQn7udKyq0K hf9s5y8snLj40tKP+y7eqdSz9z8Wks1wqObvFCMtK6ZVBw4teZiRu2DSnR9BKWcjBB0zagQP WkQcXHO+ruU567NC4zdp2422hSRKSPw9XJPMes/WKi9AiQWY1g21mIuKEwGVhHoARgMAAA== Archived-At: Cc: plus@ietf.org Subject: Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 00:35:27 -0000 --Boundary_(ID_yHWucY0a6CaFdWvW7bLerA) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable I agree with Ian that the first option is probably easier and more = viable as a solution. The second option is attractive in how it makes = the association and confirmation values less predictable, and thus more = trustworthy. However, the extra state required to debug and reconstruct = the flow does seem too high if want wide adoption. When we are looking at the first option, you mentioned strategies to = avoid on-path injection attacks of stops. Is there any attack that could = be made regarding the PSN? If the attacker can modify PSN values or = inject packets with higher PSN values in either direction, what side = effects can we see? I'm assuming that the endpoints themselves will be = able to validate the authenticity of the fields, but could a middle box = that is trying to monitor the plausible-ness of the PSN get thrown off? = Or does it only ever adjust its plausibility window when it sees a PSN = acknowledged? (To that end, if an acknowledgment value is faked, what = does that do?) =E2=80=94Tommy > On Dec 9, 2016, at 7:40 AM, Ian Swett wrote: >=20 > I have been discussing the first option with people for a while, and = everyone has indicated it's relatively simple to implement, potentially = even in hardware, and provides quite a bit of extra useful = information(RTT, approximate bandwidth) over QUIC's status quo. >=20 > I believe packet numbers being in order makes the first case both = easier to implement and provides some valuable extra information(it's = easy to infer upstream loss and reordering), so I think it's definitely = a better approach. >=20 > Also, given an equal number of bytes spent on the echo, I think they = both have about the same fuzziness properties. For example, if 2 bytes = were used in the first case, assuming this echo must be monotonically = increasing, an ack or packet gap of over 65,000 packets would have to = occur for the signal to be misinterpreted. If we're getting 65,000 = packet gaps, we might be outside the realm of QUIC's wire format to help = you diagnose your network issues, to put it mildly.=20 >=20 >=20 >=20 > On Fri, Dec 9, 2016 at 6:55 AM, Brian Trammell > wrote: > Greetings, all, >=20 > We were sitting around a whiteboard yesterday, thinking about (1) how = to implement the signals required to drive the state machine outlined in = the -plus-statefulness-01 draft, and (2) how to provide on-path = diagnosability as we're discussing in the thread on Juho's blog post. = Indeed, we think these two use cases are by far the most important for = PLUS, in that they provide equivalent-to-TCP support for basic = operations and troubleshooting practices for encrypted, UDP-encapsulated = transports like QUIC, and one could implement either of them in QUIC = directly without much disruption. >=20 > We came up with two implementation sketches, both of which use the = same header fields to drive the association and confirmation signals as = well as basic measurability. >=20 >=20 > The simpler one is pretty much the design Jana alluded to in his = previous message. It looks kind of like TCP on the wire, and has = basically the same properties.It uses three header fields: a connection = ID which appears in packets of both directions and is chosen by the = connection initiator; a packet serial number (PSN) whose initial value = in each direction is chosen randomly by the sender (like the TCP = sequence number, and as under discussion for QUIC) and is incremented by = one for each packet sent regardless of content or lack thereof (like the = QUIC packet number); and a maximum packet serial echo, which is the = highest packet number received by the sender before a packet was sent. >=20 > This provides an association signal on the initial echo of the = initiator's PSN, and a confirmation signal on the initiator's initial = echo of the responder's PSN -- just like the ack numbers on the SYN/ACK = and ACK legs of the TCP handshake. The connection ID here simply = provides additional bits of protection against completely off-path = attempts to force the state machine to tick over. Note there's no need = for SYN or ACK flags -- the association and confirmation signals = continually demonstrate that each side has seen packets from the other = side. >=20 > A stop signal is considered authentic if it has a correct connection = ID and a plausible PSN. This is path-verifiable, but provides no = protection against on-path or path-side injection attacks against state = on middleboxes (though, note that since even unencrypted headers are = authenticated, the endpoint can always detect an attempt to inject a = stop). A variation of the mechanism described in statefulness-01 would = use a two-way stop signal: a stop is only considered valid along the = path if one endpoint sends a stop signal in reply to the other = endpoint's stop signal. This would make the path-side injection much = harder to perform: in order to remove state on a given middlebox = (presuming said middlebox isn't stupid about accepting packets from = anywhere), the attacker would need to be able to inject packets on the = interfaces facing both endpoints. >=20 > One-point measurement of the PSN and echo streams gives you two-sided = RTT and upstream loss and reordering. Coordinated two-point analysis = gives you a lot more. As noted, though, two-point analysis is far more = complex. >=20 > This approach has the advantage of being extremely simple (it meets = the "someone with wireshark could reverse-engineer this in an hour or = so" requirement), and very close to what's there in QUIC right now. If = implemented with a small number of possible header layouts (preferably = one) the wire image could be trivially offloaded to hardware. >=20 > It all of the disadvantages as SEQ/ACK tracking in TCP, and of = resistance to off-path meddling that TCP sequence numbers do, though it = does give better RTT indication on lossy links (since the echo is always = the max packet number, not the highest continuous ack), and two-side = stop is better than RST at resisting path-side attacks. The definition = of "plausible" next PSN or "plausible" echo when seen at a midpoint = device is fuzzy, which could lead to difficult to debug problems with = middleboxes that try to drop packets with implausible values (as some = state-tracking TCP firewalls do now). >=20 >=20 > The second one replaces the packet number and the echo with a token = and a nonce. The connection initiator chooses an initial random token = and a nonce. The connection responder applies a function to the token = and nonce to generate its own token, and chooses a random nonce. Each = side generates a new token from the token and nonce it receives each = time the token it receives changes. Like the simpler implementation, = this one provides continual association and confirmation signals. It = also provides one-point measurement of RTT, since the token change is an = RTT-clocked signal. The RTT clock would also behave odd ways under = high-reordering situations, and additional complexity (which involves = remembering a few past tokens, but which we didn't work through) would = be needed to fix that. >=20 > The token and nonce could be separate from an additional connection = ID, or the connection ID and the token could be the same -- though this = would require much more state to be kept everywhere in order to allow = the connection ID to be useful for NAT rebinding and injection defense = purposes. >=20 > The main advantage over the simpler approach is that the fuzziness = around plausible PSNs and echoes goes away, as does the predictability = of association and confirmation values after the initial connection = establishment. However, it does not provide loss measurement without = additional information, and it places more state and processing = requirements on endpoints. >=20 >=20 > Either of these mechanisms could used together with a = path-and-endpoint verifiable, on-path and side-path attack resistant = stop signal: during connection setup each endpoint generates a random = value, and exposes the result of the application of a hash function to = that random value as its stop signal proof. To send a stop signal, it = reveals the random value as a stop signal verification (this is the = essence of PR#20 on QUIC). Any endpoint or on-path device can verify = that the hash of the verification is the proof. Of course, devices that = don't keep the proof value (or never saw it) can't verify it. The = tradeoff here is additional complexity versus additional resistance = against path-side injection meddling with state on middleboxes. >=20 >=20 > Simple packet number and echo signaling for association and = confirmation signaling with two-way stop seems to us like a reasonable = "minimal functionality set" at the moment. >=20 > Thoughts? >=20 > Cheers, >=20 > Brian and Mirja >=20 >=20 > _______________________________________________ > Plus mailing list > Plus@ietf.org > https://www.ietf.org/mailman/listinfo/plus = >=20 >=20 > _______________________________________________ > Plus mailing list > Plus@ietf.org > https://www.ietf.org/mailman/listinfo/plus --Boundary_(ID_yHWucY0a6CaFdWvW7bLerA) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable
I agree with Ian that the first option is = probably easier and more viable as a solution. The second option is = attractive in how it makes the association and confirmation values less = predictable, and thus more trustworthy. However, the extra state = required to debug and reconstruct the flow does seem too high if want = wide adoption.

When we are looking at the first option, you mentioned = strategies to avoid on-path injection attacks of stops. Is there any = attack that could be made regarding the PSN? If the attacker can modify = PSN values or inject packets with higher PSN values in either direction, = what side effects can we see? I'm assuming that the endpoints themselves = will be able to validate the authenticity of the fields, but could a = middle box that is trying to monitor the plausible-ness of the PSN get = thrown off? Or does it only ever adjust its plausibility window when it = sees a PSN acknowledged? (To that end, if an acknowledgment value is = faked, what does that do?)

=E2=80=94Tommy

On Dec 9, 2016, at 7:40 AM, Ian = Swett <ianswett@google.com> wrote:

I have been discussing the first option with people for a = while, and everyone has indicated it's relatively simple to implement, = potentially even in hardware, and provides quite a bit of extra useful = information(RTT, approximate bandwidth) over QUIC's status quo.

I believe packet numbers = being in order makes the first case both easier to implement and = provides some valuable extra information(it's easy to infer upstream = loss and reordering), so I think it's definitely a better = approach.

Also, = given an equal number of bytes spent on the echo, I think they both have = about the same fuzziness properties.  For example, if 2 bytes were = used in the first case, assuming this echo must be monotonically = increasing, an ack or packet gap of over 65,000 packets would have to = occur for the signal to be misinterpreted.  If we're getting 65,000 = packet gaps, we might be outside the realm of QUIC's wire format to help = you diagnose your network issues, to put it mildly. 



On Fri, Dec 9, 2016 at 6:55 AM, Brian Trammell = <ietf@trammell.ch> wrote:
Greetings, all,

We were sitting around a whiteboard yesterday, thinking about (1) how to = implement the signals required to drive the state machine outlined in = the -plus-statefulness-01 draft, and (2) how to provide on-path = diagnosability as we're discussing in the thread on Juho's blog post. = Indeed, we think these two use cases are by far the most important for = PLUS, in that they provide equivalent-to-TCP support for basic = operations and troubleshooting practices for encrypted, UDP-encapsulated = transports like QUIC, and one could implement either of them in QUIC = directly without much disruption.

We came up with two implementation sketches, both of which use the same = header fields to drive the association and confirmation signals as well = as basic measurability.


The simpler one is pretty much the design Jana alluded to in his = previous message. It looks kind of like TCP on the wire, and has = basically the same properties.It uses three header fields: a connection = ID which appears in packets of both directions and is chosen by the = connection initiator; a packet serial number (PSN) whose initial value = in each direction is chosen randomly by the sender (like the TCP = sequence number, and as under discussion for QUIC) and is incremented by = one for each packet sent regardless of content or lack thereof (like the = QUIC packet number); and a maximum packet serial echo, which is the = highest packet number received by the sender before a packet was = sent.

This provides an association signal on the initial echo of the = initiator's PSN, and a confirmation signal on the initiator's initial = echo of the responder's PSN -- just like the ack numbers on the SYN/ACK = and ACK legs of the TCP handshake. The connection ID here simply = provides additional bits of protection against completely off-path = attempts to force the state machine to tick over. Note there's no need = for SYN or ACK flags -- the association and confirmation signals = continually demonstrate that each side has seen packets from the other = side.

A stop signal is considered authentic if it has a correct connection ID = and a plausible PSN. This is path-verifiable, but provides no protection = against on-path or path-side injection attacks against state on = middleboxes (though, note that since even unencrypted headers are = authenticated, the endpoint can always detect an attempt to inject a = stop). A variation of the mechanism described in statefulness-01 would = use a two-way stop signal: a stop is only considered valid along the = path if one endpoint sends a stop signal in reply to the other = endpoint's stop signal. This would make the path-side injection much = harder to perform: in order to remove state on a given middlebox = (presuming said middlebox isn't stupid about accepting packets from = anywhere), the attacker would need to be able to inject packets on the = interfaces facing both endpoints.

One-point measurement of the PSN and echo streams gives you two-sided = RTT and upstream loss and reordering. Coordinated two-point analysis = gives you a lot more. As noted, though, two-point analysis is far more = complex.

This approach has the advantage of being extremely simple (it meets the = "someone with wireshark could reverse-engineer this in an hour or so" = requirement), and very close to what's there in QUIC right now. If = implemented with a small number of possible header layouts (preferably = one) the wire image could be trivially offloaded to hardware.

It all of the disadvantages as SEQ/ACK tracking in TCP, and of = resistance to off-path meddling that TCP sequence numbers do, though it = does give better RTT indication on lossy links (since the echo is always = the max packet number, not the highest continuous ack), and two-side = stop is better than RST at resisting path-side attacks. The definition = of "plausible" next PSN or "plausible" echo when seen at a midpoint = device is fuzzy, which could lead to difficult to debug problems with = middleboxes that try to drop packets with implausible values (as some = state-tracking TCP firewalls do now).


The second one replaces the packet number and the echo with a token and = a nonce. The connection initiator chooses an initial random token and a = nonce. The connection responder applies a function to the token and = nonce to generate its own token, and chooses a random nonce. Each side = generates a new token from the token and nonce it receives each time the = token it receives changes. Like the simpler implementation, this one = provides continual association and confirmation signals. It also = provides one-point measurement of RTT, since the token change is an = RTT-clocked signal. The RTT clock would also behave odd ways under = high-reordering situations, and additional complexity (which involves = remembering a few past tokens, but which we didn't work through) would = be needed to fix that.

The token and nonce could be separate from an additional connection ID, = or the connection ID and the token could be the same -- though this = would require much more state to be kept everywhere in order to allow = the connection ID to be useful for NAT rebinding and injection defense = purposes.

The main advantage over the simpler approach is that the fuzziness = around plausible PSNs and echoes goes away, as does the predictability = of association and confirmation values after the initial connection = establishment. However, it does not provide loss measurement without = additional information, and it places more state and processing = requirements on endpoints.


Either of these mechanisms could used together with a path-and-endpoint = verifiable, on-path and side-path attack resistant stop signal: during = connection setup each endpoint generates a random value, and exposes the = result of the application of a hash function to that random value as its = stop signal proof. To send a stop signal, it reveals the random value as = a stop signal verification (this is the essence of PR#20 on QUIC). Any = endpoint or on-path device can verify that the hash of the verification = is the proof. Of course, devices that don't keep the proof value (or = never saw it) can't verify it. The tradeoff here is additional = complexity versus additional resistance against path-side injection = meddling with state on middleboxes.


Simple packet number and echo signaling for association and confirmation = signaling with two-way stop seems to us like a reasonable "minimal = functionality set" at the moment.

Thoughts?

Cheers,

Brian and Mirja


_______________________________________________
Plus mailing list
Plus@ietf.org
https://www.ietf.org/mailman/listinfo/plus


_______________________________________________
Plus = mailing list
Plus@ietf.org
https://www.ietf.org/mailman/listinfo/plus

= --Boundary_(ID_yHWucY0a6CaFdWvW7bLerA)-- From nobody Sat Dec 10 22:33:54 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963971294A3 for ; Sat, 10 Dec 2016 22:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SD3576YrkDKP for ; Sat, 10 Dec 2016 22:33:49 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B71A129477 for ; Sat, 10 Dec 2016 22:33:49 -0800 (PST) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cFxhi-0003Rr-L5 for plus@ietf.org; Sun, 11 Dec 2016 07:33:47 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cFxhf-0004nG-Rz for plus@ietf.org; Sun, 11 Dec 2016 01:33:44 -0500 Received: (qmail 1131 invoked from network); 11 Dec 2016 06:33:43 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.108]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Dec 2016 06:33:42 -0000 From: "Christian Huitema" To: "'Tommy Pauly'" , "'Ian Swett'" , "'Brian Trammell'" References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> In-Reply-To: Date: Sat, 10 Dec 2016 22:33:35 -0800 Message-ID: <02ec01d25378$83799550$8a6cbff0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGJFALV+PXWIFNIHBFUeBJpGWH6CgJHaNbDAfmdZJABvOyTr6Fk00QA Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dIiv9E4wCVrhoZyL4oGkN7E0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMD7df q4zPIPqp32yWlVtvZmJXmshtzyZDgNZ7TnNFLwPNdcmtTcWSOKD5RASVzg27in97Vz6IRLbhBYyX 7lr6B6d5kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRpn6l0+oVSca42DfTgAp5GAMQOp+UtDOd2Xrp4Ao XsNbs9GlEri3u8HlNkgl5XdomwjMM1GqS8P5ezXBIcd52+jeNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxNnmFCUctm6OHeH6tWPSXJE7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRYE83tH9htpyVATiooT/rJiGHIfgXXvuhI9vwJN89WVO9R0tarUwIt7i7NiVJNL9jNC r2VPLfZa8ts/I6OTYjIAMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.234 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.22) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: plus@ietf.org Subject: Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 06:33:51 -0000 On Saturday, December 10, 2016 4:35 PM, Tommy Pauly wrote: > > I agree with Ian that the first option is probably easier and more = viable as a=20 > solution. The second option is attractive in how it makes the = association and=20 > confirmation values less predictable, and thus more trustworthy. = However,=20 > the extra state required to debug and reconstruct the flow does seem = too high > if want wide adoption. I too think that the first option is more practical. I am a bit = concerned that the "token" suggested in the second option does not have = any link to the mechanism of the transport protocol. That means lazy = implementation could take their sweet time and "rotate the token" once = in a blue moon, making it seriously unfit for RTT assessment.=20 In the first option, the echo is the "last seen sequence number" that = would otherwise be carried in the ACK frame. If we move it out of the = ACK frame and into the header, then we have pretty much a guarantee that = applications will do it right. I like that. I also like that the scheme = does not make the "connection start" special, and works just as well = after a rerouting or a NAT state change. OTOH, there is going to be a "feature interaction" between this = sequence+echo scheme and the senders' strategy of skipping some sequence = numbers in order to verify that the recipients are not making up ACKS. = The intermediate boxes will have no way to distinguish between a packet = number voluntarily skipped by the sender, and a packet loss between the = sender and the middlebox. I hope this won't affect the "wireshark = diagnostics" too much. > When we are looking at the first option, you mentioned strategies to = avoid on-path > injection attacks of stops.=20 I like the "two ways stop". It definitely increases the robustness. = Also, sending the sequence number and last seen in "clear text" solves = the "guess the sequence number" issue for the "rebooted server." Maybe = we can use EKR's scheme after all. > ... Is there any attack that could be made regarding the PSN? If the = attacker can modify=20 > PSN values or inject packets with higher PSN values in either = direction, what side effects > can we see? I'm assuming that the endpoints themselves will be able to = validate the > authenticity of the fields, but could a middle box that is trying to = monitor the=20 > plausible-ness of the PSN get thrown off? Or does it only ever adjust = its plausibility > window when it sees a PSN acknowledged? (To that end, if an = acknowledgment > value is faked, what does that do?) That's a very good observation, and in fact it applies to current QUIC = as well. A man-on-the side can inject a series of plausible packets = before the sender does. The "real" packets coming from the sender will = repeat packet numbers that are 'already seen'. A middlebox that is too = clever might drop those in an attempt to "remove duplicates." We can = always say that middleboxes should not try to be too clever, but that's = a bit like saying that the bubonic plague should be nicer... -- Christian Huitema From nobody Sun Dec 11 06:51:31 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EFE129413 for ; Sun, 11 Dec 2016 06:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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=-2.896, 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 aYU0YNzMfq6L for ; Sun, 11 Dec 2016 06:51:27 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BB4126FDC for ; Sun, 11 Dec 2016 06:51:27 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id t125so47615893ywc.1 for ; Sun, 11 Dec 2016 06:51:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ul59HQWnSE4zIr3oQTXP25xQcO+/rktnRIMhlSefo9U=; b=IIiGhyRCLmfBR/EUQzjiZIi1de27dCM+YT1IqA0WMqbfjyDoDtJKU++9cDdWUCNNsh 2gRThuoq3QoqQZ7oCaP3YmrjNFOjir2DzD/5jqc2QXh3xvO6uSPIGygNfkWzYQkO8euI i1FT7uk+JhsPuawAjY07/RbphAuyfQpEH0oeG9delTOhZa1SXjtQdxh8q3eoYI+J3u5K aovQXdh3IdKbLV4Sjx81BH3Vfe2ZYHHEXYsfmIZahc3QJ75QfZtJ2Lkcc5dLV4y1JKxr ya8Fukoc3P1ExCDWJCA8l4+n/mLgQ8Ym4GdVRDQMlFfzw+JBPKJXFnhTFy3HJTEfXyOX QGSA== 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=ul59HQWnSE4zIr3oQTXP25xQcO+/rktnRIMhlSefo9U=; b=I4oM3Ni7MsLn9bd3zcsDdhm68hRNOd9kYdDMM5EWD4+26+fN4kPDcVfb1Ll+uPGxBl CP2SVEZk0YsmMicJd9Wbh6jQlr9U4rKDsmj1VBWFT42yIi1yjZ/sZqcCwxRzzwhoLOm+ RmWRxTpCe6UupRDHhLoJGLdHQYKE6OlwRr3lA9mw02YgIqltkhx2R0SllnzzFVOgba4n OSr1YeTqy0XFtQzZc92PUY47hh7Y1t36kFxCGbVM6r+z83ZL8Jxkn0S6Kgl2sMcUYOkv LAh8D2VJwVYw25wSZSLVgHtKd95ud8UUhNqk0/Zjj2OADwgcKMoxxUrqk3OAIzLyQA2h 9DJw== X-Gm-Message-State: AKaTC03/POmR4mkzbK+STRtLPm3ai1ghErz3bQUAR3WFbl+cR16zeo6EQKhRxEr7ipUSHMwUJ/DswTOoCVpcssKk X-Received: by 10.13.245.199 with SMTP id e190mr81331829ywf.317.1481467886909; Sun, 11 Dec 2016 06:51:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Sun, 11 Dec 2016 06:51:06 -0800 (PST) In-Reply-To: <02ec01d25378$83799550$8a6cbff0$@huitema.net> References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> <02ec01d25378$83799550$8a6cbff0$@huitema.net> From: Ian Swett Date: Sun, 11 Dec 2016 09:51:06 -0500 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=94eb2c032e702593a20543631f35 Archived-At: Cc: Brian Trammell , Tommy Pauly , plus@ietf.org Subject: Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 14:51:30 -0000 --94eb2c032e702593a20543631f35 Content-Type: text/plain; charset=UTF-8 On Sun, Dec 11, 2016 at 1:33 AM, Christian Huitema wrote: > On Saturday, December 10, 2016 4:35 PM, Tommy Pauly wrote: > > > > I agree with Ian that the first option is probably easier and more > viable as a > > solution. The second option is attractive in how it makes the > association and > > confirmation values less predictable, and thus more trustworthy. However, > > the extra state required to debug and reconstruct the flow does seem too > high > > if want wide adoption. > > I too think that the first option is more practical. I am a bit concerned > that the "token" suggested in the second option does not have any link to > the mechanism of the transport protocol. That means lazy implementation > could take their sweet time and "rotate the token" once in a blue moon, > making it seriously unfit for RTT assessment. > > In the first option, the echo is the "last seen sequence number" that > would otherwise be carried in the ACK frame. If we move it out of the ACK > frame and into the header, then we have pretty much a guarantee that > applications will do it right. I like that. I also like that the scheme > does not make the "connection start" special, and works just as well after > a rerouting or a NAT state change. > > OTOH, there is going to be a "feature interaction" between this > sequence+echo scheme and the senders' strategy of skipping some sequence > numbers in order to verify that the recipients are not making up ACKS. The > intermediate boxes will have no way to distinguish between a packet number > voluntarily skipped by the sender, and a packet loss between the sender and > the middlebox. I hope this won't affect the "wireshark diagnostics" too > much. > We could specify that if a peer wants to skip packet numbers, it should be by more than 256, assuming 256 packet gaps are rare(which they are, though they do happen). Or some other known approach that is relatively simple to identify. > > When we are looking at the first option, you mentioned strategies to > avoid on-path > > injection attacks of stops. > > I like the "two ways stop". It definitely increases the robustness. Also, > sending the sequence number and last seen in "clear text" solves the "guess > the sequence number" issue for the "rebooted server." Maybe we can use > EKR's scheme after all. > > > ... Is there any attack that could be made regarding the PSN? If the > attacker can modify > > PSN values or inject packets with higher PSN values in either direction, > what side effects > > can we see? I'm assuming that the endpoints themselves will be able to > validate the > > authenticity of the fields, but could a middle box that is trying to > monitor the > > plausible-ness of the PSN get thrown off? Or does it only ever adjust > its plausibility > > window when it sees a PSN acknowledged? (To that end, if an > acknowledgment > > value is faked, what does that do?) > > That's a very good observation, and in fact it applies to current QUIC as > well. A man-on-the side can inject a series of plausible packets before the > sender does. The "real" packets coming from the sender will repeat packet > numbers that are 'already seen'. A middlebox that is too clever might drop > those in an attempt to "remove duplicates." We can always say that > middleboxes should not try to be too clever, but that's a bit like saying > that the bubonic plague should be nicer... > > Agreed. Since QUIC does not reuse packet numbers, the only times a middlebox would expect to see duplicate PSNs is if the network duplicates them(insanely rare) or if there is an attack. In both cases, the best course of action is to do nothing and not remove duplicates, since only endpoints know which packets are valid, so there is no practical incentive for a middlebox to do that. That being said, this and many other points may need to be documented to reduce the chances of someone trying to be clever. > -- Christian Huitema > > > > --94eb2c032e702593a20543631f35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Dec 11, 2016 at 1:33 AM, Christian Huitema <huitema@huitema.net&= gt; wrote:
On Sat= urday, December 10, 2016 4:35 PM, Tommy Pauly wrote:
>
> I agree with Ian that the first option is probably easier and more via= ble as a
> solution. The second option is attractive in how it makes the associat= ion and
> confirmation values less predictable, and thus more trustworthy. Howev= er,
> the extra state required to debug and reconstruct the flow does seem t= oo high
> if want wide adoption.

I too think that the first option is more practical. I am a bit conc= erned that the "token" suggested in the second option does not ha= ve any link to the mechanism of the transport protocol. That means lazy imp= lementation could take their sweet time and "rotate the token" on= ce in a blue moon, making it seriously unfit for RTT assessment.

In the first option, the echo is the "last seen sequence number" = that would otherwise be carried in the ACK frame. If we move it out of the = ACK frame and into the header, then we have pretty much a guarantee that ap= plications will do it right. I like that. I also like that the scheme does = not make the "connection start" special, and works just as well a= fter a rerouting or a NAT state change.

OTOH, there is going to be a "feature interaction" between this s= equence+echo scheme and the senders' strategy of skipping some sequence= numbers in order to verify that the recipients are not making up ACKS. The= intermediate boxes will have no way to distinguish between a packet number= voluntarily skipped by the sender, and a packet loss between the sender an= d the middlebox. I hope this won't affect the "wireshark diagnosti= cs" too much.

We could specify tha= t if a peer wants to skip packet numbers, it should be by more than 256, as= suming 256 packet gaps are rare(which they are, though they do happen). =C2= =A0 =C2=A0Or some other known approach that is relatively simple to identif= y.


> When we are looking at the first option, you mentioned strategies to a= void on-path
> injection attacks of stops.

I like the "two ways stop". It definitely increases the ro= bustness. Also, sending the sequence number and last seen in "clear te= xt" solves the "guess the sequence number" issue for the &qu= ot;rebooted server." Maybe we can use EKR's scheme after all.

> ... Is there any attack that could be made regarding the PSN? If the a= ttacker can modify
> PSN values or inject packets with higher PSN values i= n either direction, what side effects
> can we see? I'm assuming that the endpoints themselves will be abl= e to validate the
> authenticity of the fields, but could a middle box that is trying to m= onitor the
> plausible-ness of the PSN get thrown off? Or does it only ever adjust = its plausibility
> window when it sees a PSN acknowledged? (To that end, if an acknowledg= ment
> value is faked, what does that do?)

That's a very good observation, and in fact it applies to curren= t QUIC as well. A man-on-the side can inject a series of plausible packets = before the sender does. The "real" packets coming from the sender= will repeat packet numbers that are 'already seen'. A middlebox th= at is too clever might drop those in an attempt to "remove duplicates.= " We can always say that middleboxes should not try to be too clever, = but that's a bit like saying that the bubonic plague should be nicer...=


Agreed.=C2=A0 Since QUIC does not reuse packet numbe= rs, the only times a middlebox would expect to see duplicate PSNs is if the= network duplicates them(insanely rare) or if there is an attack.=C2=A0 In = both cases, the best course of action is to do nothing and not remove dupli= cates, since only endpoints know which packets are valid, so there is no pr= actical incentive for a middlebox to do that.=C2=A0 That being said, this a= nd many other points may need to be documented to reduce the chances of som= eone trying to be clever.
=C2=A0
-- Christian Huitema




--94eb2c032e702593a20543631f35-- From nobody Sun Dec 11 08:47:20 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992D012945D for ; Sun, 11 Dec 2016 08:47:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S1aIjPWGOXSp for ; Sun, 11 Dec 2016 08:47:15 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1144129435 for ; Sun, 11 Dec 2016 08:47:15 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cG7HN-0000fD-V9 for plus@ietf.org; Sun, 11 Dec 2016 17:47:14 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cG7HK-0001kN-G5 for plus@ietf.org; Sun, 11 Dec 2016 11:47:13 -0500 Received: (qmail 16164 invoked from network); 11 Dec 2016 16:47:10 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[172.56.39.108]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Dec 2016 16:47:09 -0000 From: "Christian Huitema" To: "'Ian Swett'" References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> <02ec01d25378$83799550$8a6cbff0$@huitema.net> In-Reply-To: Date: Sun, 11 Dec 2016 08:47:05 -0800 Message-ID: <003801d253ce$35b13520$a1139f60$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGJFALV+PXWIFNIHBFUeBJpGWH6CgJHaNbDAfmdZJABvOyTrwFvjL+CAeMgNGqhSu2qMA== Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dIiv9E4wCVrhoZyL4oGkN7E0HbLcIXRK+rCYHS2Pxr4sUvWQm1ERVuodk8O3ETzMDwo/ Uh1jmurWq+/2Ie7U7sqADc7ZY3EztL6tInZj92mvdcmtTcWSOKD5RASVzg27inXh5noZfH+Ue/bn p6ZbxyV5kYwBFjHSX1ySASMY7Q8kB9L5ZtBNVI+9Qx1iUeEDv6vlm5bIS/7+niZp9XBOa3yfIyPa B+nRnOnncyxSbUjNQcVc7DCeSlpKhzvl7ajXRoSu7p0hkXmiYaBEmzJokiIMQOp+UtDOd2Xrp4Ao XsNbEJwIm+oR/p+Hz0PC9yfr2G8fBbNd2aWQ6zxe7udZZr7eNHk15VolAGHS5rCXQKDy7WmLSP+L g+ESZWbM7Yv2tv4nD/5nJ2uhobXclUauFd2nNgqa/CCGIrC+9iFtJySZiR3bHfnMCIEU+nrglojK wD9TAOxA+4LNeua6YnevHxMwo0ageKMXcNstrfyg5gXa7T02ZXdoQxMs//iOE4FlhnMcN6qoXPje nLhIOF1oeRZKVzLoodJpOhZOhElZeeZ68HN1XtUyhw3DgxLaLBwUGYIHhtpcaYbh91FuaKgJHE3L es7Q3TWr9wD5RALyObfQMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.17) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: 'Brian Trammell' , 'Tommy Pauly' , plus@ietf.org Subject: Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 16:47:17 -0000 On Sunday, December 11, 2016 6:51 AM, Ian Swett wrote: > On Sun, Dec 11, 2016 at 1:33 AM, Christian Huitema = wrote: >> ...OTOH, there is going to be a "feature interaction" between this = sequence+echo scheme and=20 >> the senders' strategy of skipping some sequence numbers in order to = verify that the recipients >> are not making up ACKS. The intermediate boxes will have no way to = distinguish between a=20 >> packet number voluntarily skipped by the sender, and a packet loss = between the sender and >> the middlebox. I hope this won't affect the "wireshark diagnostics" = too much. > > We could specify that if a peer wants to skip packet numbers, it = should be by more than 256, > assuming 256 packet gaps are rare(which they are, though they do = happen). Or some other=20 > known approach that is relatively simple to identify. If you make it easier to identify, then you defeat the purpose of the = packet skipping. Suppose a bad receiver, intent on setting a DOS attack. = Its strategy is to ACK as quickly as possible, regardless of losses. The = sender detects ACK of packets that were not sent, and aborts the = connection. But if the skipping is easy to detect by middleboxes, it is = also easy to detect by the bad receiver, which will suspend its ACK = everything strategy if it detects a test... -- Christian Huitema From nobody Sun Dec 11 09:08:42 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE3F1296A2 for ; Sun, 11 Dec 2016 09:08:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-Sm4LOMTcVo for ; Sun, 11 Dec 2016 09:08:39 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D641293FF for ; Sun, 11 Dec 2016 09:08:39 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id r204so49115003ywb.0 for ; Sun, 11 Dec 2016 09:08:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RIj5nFLeUygoN1YGpNbogUnZlGQdd+Nc5ziKVHAiilM=; b=UXPkIDhY9EmNqzWzu5ggtMfSJmqgFG4kEo1xpjp90LK5vDO4oPJqGOn32gHKgb9ziQ 757KSO6gkg2WE5M+fCRyEOVMzQ44DqXHVY4inQBtLAo6V4rWWLiPh2P2vPBJeuEqKZnK 2hVc8I5vUSQ6AGbrHS/Ql3CwY2s3UrQZiLLBtd+p2seD6qSYGzJAmIixOO4wb+NEvbFP d7XY/xKJedgAv6OlmQKU7bJcCPPHdq+geMFoQezOASQ4qaAnBIkhPJb+g1enLTkG8k7h tcPL2IEneZH6Kiubvh3w+KafwAoV2569PwW7xfddTcGtsU3THoNIEKzw6oX+oFqVDGRv OCnQ== 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=RIj5nFLeUygoN1YGpNbogUnZlGQdd+Nc5ziKVHAiilM=; b=L8qThOasy+WFdkbgt79oLfJ9yO9XClZ9Zzc0T2j3uxSZXrQ7g7tlJ93yhREn1X9sfV Wjddui6mKff4VQdMVkrHbGSDPNdJUGY83QWpqQQ72lzPUcFMQi+rhaGN7dVnmz8JjZKm 8d/e3m2Z0tOPibXe5w3FZrKj2ZQoMCoM8hA32yvnWclZ0TeM5iZjEVDGGTqXjdYlH78i rdGFIe8ihzaLoCsiq1n3AjpUzcTXawsXbPvAA3VIs8PfXaGjMLgVSxGejzuj3SmOr6uQ LmvpHnJfL96IFdBfEdCszkvKuEUYiB784jWDD1gk70JHqO4vJRVEDREqTI7VUwqpZYJP tNSQ== X-Gm-Message-State: AKaTC02QwfzcUz17Vu0oE0Z2xREiMfRREFeLi/d96y1ihgzOH1iwNh/QQS9OyE2BPnc+UA8EIZNsGEYJJ2xKaUJF X-Received: by 10.129.117.215 with SMTP id q206mr90944437ywc.143.1481476118931; Sun, 11 Dec 2016 09:08:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.4.88 with HTTP; Sun, 11 Dec 2016 09:08:18 -0800 (PST) In-Reply-To: <003801d253ce$35b13520$a1139f60$@huitema.net> References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> <02ec01d25378$83799550$8a6cbff0$@huitema.net> <003801d253ce$35b13520$a1139f60$@huitema.net> From: Ian Swett Date: Sun, 11 Dec 2016 12:08:18 -0500 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a1147f9ced07ce505436509b2 Archived-At: Cc: Brian Trammell , Tommy Pauly , plus@ietf.org Subject: Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 17:08:41 -0000 --001a1147f9ced07ce505436509b2 Content-Type: text/plain; charset=UTF-8 Good point, though they'd only know it afterwards. At which point the connection would be torn down. I'm not sure it's critical the receiver is unaware they're being tested or not. And if the connection is suddenly torn down, presumably they'll realize they were being tested anyway? On Sun, Dec 11, 2016 at 11:47 AM, Christian Huitema wrote: > On Sunday, December 11, 2016 6:51 AM, Ian Swett wrote: > > On Sun, Dec 11, 2016 at 1:33 AM, Christian Huitema huitema@huitema.net> wrote: > >> ...OTOH, there is going to be a "feature interaction" between this > sequence+echo scheme and > >> the senders' strategy of skipping some sequence numbers in order to > verify that the recipients > >> are not making up ACKS. The intermediate boxes will have no way to > distinguish between a > >> packet number voluntarily skipped by the sender, and a packet loss > between the sender and > >> the middlebox. I hope this won't affect the "wireshark diagnostics" too > much. > > > > We could specify that if a peer wants to skip packet numbers, it should > be by more than 256, > > assuming 256 packet gaps are rare(which they are, though they do > happen). Or some other > > known approach that is relatively simple to identify. > > If you make it easier to identify, then you defeat the purpose of the > packet skipping. Suppose a bad receiver, intent on setting a DOS attack. > Its strategy is to ACK as quickly as possible, regardless of losses. The > sender detects ACK of packets that were not sent, and aborts the > connection. But if the skipping is easy to detect by middleboxes, it is > also easy to detect by the bad receiver, which will suspend its ACK > everything strategy if it detects a test... > > -- Christian Huitema > > > > > --001a1147f9ced07ce505436509b2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Good point, though they'd only know it afterwards.=C2= =A0 At which point the connection would be torn down.

I&= #39;m not sure it's critical the receiver is unaware they're being = tested or not.=C2=A0 And if the connection is suddenly torn down, presumabl= y they'll realize they were being tested anyway?

On Sun, Dec 11, 2016 at 11:= 47 AM, Christian Huitema <huitema@huitema.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On Sunday, December 11, 2016 6:51 AM, Ian Swe= tt wrote:
> On Sun, Dec 11, 2016 at 1:33 AM, Christian Huitema <mailto:huitema@huitema.net> wrote:
>> ...OTOH, there is going to be a "feature interaction" be= tween this sequence+echo scheme and
>> the senders' strategy of skipping some sequen= ce numbers in order to verify that the recipients
>> are not making up ACKS. The intermediate boxes will have no way to= distinguish between a
>> packet number voluntarily skipped by the sender, and a packet loss= between the sender and
>> the middlebox. I hope this won't affect the "wireshark di= agnostics" too much.
>
> We could specify that if a peer wants to skip packet numbers, it shoul= d be by more than 256,
> assuming 256 packet gaps are rare(which they are, though they do happe= n).=C2=A0 =C2=A0 Or some other
> known approach that is relatively simple to identify.

If you make it easier to identify, then you defeat the purpose of th= e packet skipping. Suppose a bad receiver, intent on setting a DOS attack. = Its strategy is to ACK as quickly as possible, regardless of losses. The se= nder detects ACK of packets that were not sent, and aborts the connection. = But if the skipping is easy to detect by middleboxes, it is also easy to de= tect by the bad receiver, which will suspend its ACK everything strategy if= it detects a test...

-- Christian Huitema





--001a1147f9ced07ce505436509b2-- From nobody Mon Dec 12 01:44:55 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE6B129599 for ; Mon, 12 Dec 2016 01:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 TYvlVlIq_YC8 for ; Mon, 12 Dec 2016 01:44:51 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 63D5E129514 for ; Mon, 12 Dec 2016 01:44:51 -0800 (PST) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id 18AA51A06FF; Mon, 12 Dec 2016 10:44:20 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_31530657-B595-4D9C-B65E-AF5A4A498439"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: Date: Mon, 12 Dec 2016 10:44:19 +0100 Message-Id: <494DE77E-7066-4399-B610-200EB49BAB4E@trammell.ch> References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> To: Ian Swett X-Mailer: Apple Mail (2.3124) Archived-At: Cc: plus@ietf.org Subject: Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 09:44:54 -0000 --Apple-Mail=_31530657-B595-4D9C-B65E-AF5A4A498439 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Ian, > On 09 Dec 2016, at 16:40, Ian Swett wrote: >=20 > I have been discussing the first option with people for a while, and = everyone has indicated it's relatively simple to implement, potentially = even in hardware, and provides quite a bit of extra useful = information(RTT, approximate bandwidth) over QUIC's status quo. >=20 > I believe packet numbers being in order makes the first case both = easier to implement and provides some valuable extra information(it's = easy to infer upstream loss and reordering), so I think it's definitely = a better approach. >=20 > Also, given an equal number of bytes spent on the echo, I think they = both have about the same fuzziness properties. For example, if 2 bytes = were used in the first case, assuming this echo must be monotonically = increasing, an ack or packet gap of over 65,000 packets would have to = occur for the signal to be misinterpreted. If we're getting 65,000 = packet gaps, we might be outside the realm of QUIC's wire format to help = you diagnose your network issues, to put it mildly. Indeed. However, there are two issues to consider here: (1) ways in which the PSN/echo can fail in terms of exposing information = for measurement. Agreed, 16 bits is more than enough here. (2) ways in which the PSN/echo can fail in terms of exposing information = for on-path state maintenance, and this is the fuzziness I was referring = to. On further consideration, it's not clear to me this is all that = important, though: if you have sufficient bits in the connection ID (and = the connection ID appears on each packet), then the additional bits of = resistance to off path injection window plausibility checks give you = probably aren't worth the effort. (You do need plausible values for PKT and ECHO on close bits, but since = the close packet should be the last packet in sequence in each = direction, there's no fuzziness in the window at all). Cheers, Brian >=20 >=20 > On Fri, Dec 9, 2016 at 6:55 AM, Brian Trammell = wrote: > Greetings, all, >=20 > We were sitting around a whiteboard yesterday, thinking about (1) how = to implement the signals required to drive the state machine outlined in = the -plus-statefulness-01 draft, and (2) how to provide on-path = diagnosability as we're discussing in the thread on Juho's blog post. = Indeed, we think these two use cases are by far the most important for = PLUS, in that they provide equivalent-to-TCP support for basic = operations and troubleshooting practices for encrypted, UDP-encapsulated = transports like QUIC, and one could implement either of them in QUIC = directly without much disruption. >=20 > We came up with two implementation sketches, both of which use the = same header fields to drive the association and confirmation signals as = well as basic measurability. >=20 >=20 > The simpler one is pretty much the design Jana alluded to in his = previous message. It looks kind of like TCP on the wire, and has = basically the same properties.It uses three header fields: a connection = ID which appears in packets of both directions and is chosen by the = connection initiator; a packet serial number (PSN) whose initial value = in each direction is chosen randomly by the sender (like the TCP = sequence number, and as under discussion for QUIC) and is incremented by = one for each packet sent regardless of content or lack thereof (like the = QUIC packet number); and a maximum packet serial echo, which is the = highest packet number received by the sender before a packet was sent. >=20 > This provides an association signal on the initial echo of the = initiator's PSN, and a confirmation signal on the initiator's initial = echo of the responder's PSN -- just like the ack numbers on the SYN/ACK = and ACK legs of the TCP handshake. The connection ID here simply = provides additional bits of protection against completely off-path = attempts to force the state machine to tick over. Note there's no need = for SYN or ACK flags -- the association and confirmation signals = continually demonstrate that each side has seen packets from the other = side. >=20 > A stop signal is considered authentic if it has a correct connection = ID and a plausible PSN. This is path-verifiable, but provides no = protection against on-path or path-side injection attacks against state = on middleboxes (though, note that since even unencrypted headers are = authenticated, the endpoint can always detect an attempt to inject a = stop). A variation of the mechanism described in statefulness-01 would = use a two-way stop signal: a stop is only considered valid along the = path if one endpoint sends a stop signal in reply to the other = endpoint's stop signal. This would make the path-side injection much = harder to perform: in order to remove state on a given middlebox = (presuming said middlebox isn't stupid about accepting packets from = anywhere), the attacker would need to be able to inject packets on the = interfaces facing both endpoints. >=20 > One-point measurement of the PSN and echo streams gives you two-sided = RTT and upstream loss and reordering. Coordinated two-point analysis = gives you a lot more. As noted, though, two-point analysis is far more = complex. >=20 > This approach has the advantage of being extremely simple (it meets = the "someone with wireshark could reverse-engineer this in an hour or = so" requirement), and very close to what's there in QUIC right now. If = implemented with a small number of possible header layouts (preferably = one) the wire image could be trivially offloaded to hardware. >=20 > It all of the disadvantages as SEQ/ACK tracking in TCP, and of = resistance to off-path meddling that TCP sequence numbers do, though it = does give better RTT indication on lossy links (since the echo is always = the max packet number, not the highest continuous ack), and two-side = stop is better than RST at resisting path-side attacks. The definition = of "plausible" next PSN or "plausible" echo when seen at a midpoint = device is fuzzy, which could lead to difficult to debug problems with = middleboxes that try to drop packets with implausible values (as some = state-tracking TCP firewalls do now). >=20 >=20 > The second one replaces the packet number and the echo with a token = and a nonce. The connection initiator chooses an initial random token = and a nonce. The connection responder applies a function to the token = and nonce to generate its own token, and chooses a random nonce. Each = side generates a new token from the token and nonce it receives each = time the token it receives changes. Like the simpler implementation, = this one provides continual association and confirmation signals. It = also provides one-point measurement of RTT, since the token change is an = RTT-clocked signal. The RTT clock would also behave odd ways under = high-reordering situations, and additional complexity (which involves = remembering a few past tokens, but which we didn't work through) would = be needed to fix that. >=20 > The token and nonce could be separate from an additional connection = ID, or the connection ID and the token could be the same -- though this = would require much more state to be kept everywhere in order to allow = the connection ID to be useful for NAT rebinding and injection defense = purposes. >=20 > The main advantage over the simpler approach is that the fuzziness = around plausible PSNs and echoes goes away, as does the predictability = of association and confirmation values after the initial connection = establishment. However, it does not provide loss measurement without = additional information, and it places more state and processing = requirements on endpoints. >=20 >=20 > Either of these mechanisms could used together with a = path-and-endpoint verifiable, on-path and side-path attack resistant = stop signal: during connection setup each endpoint generates a random = value, and exposes the result of the application of a hash function to = that random value as its stop signal proof. To send a stop signal, it = reveals the random value as a stop signal verification (this is the = essence of PR#20 on QUIC). Any endpoint or on-path device can verify = that the hash of the verification is the proof. Of course, devices that = don't keep the proof value (or never saw it) can't verify it. The = tradeoff here is additional complexity versus additional resistance = against path-side injection meddling with state on middleboxes. >=20 >=20 > Simple packet number and echo signaling for association and = confirmation signaling with two-way stop seems to us like a reasonable = "minimal functionality set" at the moment. >=20 > Thoughts? >=20 > Cheers, >=20 > Brian and Mirja >=20 >=20 > _______________________________________________ > Plus mailing list > Plus@ietf.org > https://www.ietf.org/mailman/listinfo/plus >=20 >=20 --Apple-Mail=_31530657-B595-4D9C-B65E-AF5A4A498439 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 iQIcBAEBCgAGBQJYTnFzAAoJEIoSt78L6kajLs8P/0tWvTHeTcnz2/tTcIcZ1BNb x0146QTr6Sa8pdrISEjLhGaDHF/HtGaZ7veLeudSuTkKyB8S8celNI3QAmCfZhC5 47+dvJMIsjNrXUKmE9v6zy+3xleWmv2iojQ/6yBGEjxijv+x+1zEHUv+wU0Pj3DT /2t9fGSfutXjVtcC4GTAs3W2Y2erYe4j1BszLbI2qs8cjOtfLgPbmGcnKXSEkrCy EdsvrgU4mqJZH1WGm4H7l/nps2emoOoM4MybHQAFqzB2QkyhYQwMEm/5Bgm3yrOV VOb/2h9N9rYE+wwY6OWnIyJwiS5k5oC3lPnoUZhFn+m8vE1sFfd4hfHQeM8BUB9S g6U6CtM3uD0FTFmFFCKxwMQ+T2asiwwovQi2Ce6841osvaXk5frkWJF5uwRLprFu XP0/oq/RvpZpA+qmUaONS8/As1yMkOBZMfhyEVJyv7LrcJ9mLEo4YuHL6hJ52NWl TvZhCoRxI2obZ98FViLXD/MZHuOzxLdCdoDYtG8xRBjppVsaxF+qp3TzAkg+HZQY O42jLyUBA0LRmEHqIP2UC5jLYSP5BHU4BuoouYCQTOAsfnzNLgJf+JBAlTiQEzSS UD0aw8I3fhw2vphioJi/kMC2vQ8l8swIhxzAG58UBTLq0/wWuLgaJ0dp6N3Kg1RU kXNc/jbFacvaRA2WKJ3K =sAkp -----END PGP SIGNATURE----- --Apple-Mail=_31530657-B595-4D9C-B65E-AF5A4A498439-- From nobody Mon Dec 12 02:08:06 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A01B91295A8 for ; Mon, 12 Dec 2016 02:08:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, 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 Ga2OvZUo5YmX for ; Mon, 12 Dec 2016 02:08:02 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 380C1129587 for ; Mon, 12 Dec 2016 02:08:01 -0800 (PST) Received: from [IPv6:2001:470:26:9c2::7ea] (unknown [IPv6:2001:470:26:9c2::7ea]) by trammell.ch (Postfix) with ESMTPSA id 8D90B1A1078; Mon, 12 Dec 2016 11:07:30 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_994CE9AE-B9EE-4A35-A2F3-3249FA425291"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Brian Trammell In-Reply-To: <02ec01d25378$83799550$8a6cbff0$@huitema.net> Date: Mon, 12 Dec 2016 11:07:29 +0100 Message-Id: <5BED4FE3-0F20-4155-AEA3-407BE533E0C6@trammell.ch> References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> <02ec01d25378$83799550$8a6cbff0$@huitema.net> To: Christian Huitema X-Mailer: Apple Mail (2.3124) Archived-At: Cc: plus@ietf.org, Ian Swett , Tommy Pauly Subject: Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 10:08:04 -0000 --Apple-Mail=_994CE9AE-B9EE-4A35-A2F3-3249FA425291 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Christian, all, > On 11 Dec 2016, at 07:33, Christian Huitema = wrote: >=20 > On Saturday, December 10, 2016 4:35 PM, Tommy Pauly wrote: >>=20 >> I agree with Ian that the first option is probably easier and more = viable as a >> solution. The second option is attractive in how it makes the = association and >> confirmation values less predictable, and thus more trustworthy. = However, >> the extra state required to debug and reconstruct the flow does seem = too high >> if want wide adoption. >=20 > I too think that the first option is more practical. Having had a weekend to think a bit more about both of them, I'll add my = voice to this chorus. > I am a bit concerned that the "token" suggested in the second option = does not have any link to the mechanism of the transport protocol. That = means lazy implementation could take their sweet time and "rotate the = token" once in a blue moon, making it seriously unfit for RTT = assessment. There are other ways in which the RTT assessment can go awry. You need a = little more state (and, on path, an extra addition) to do RTT = measurement with the first option, but it has the advantage over its TCP = counterpart that the packet number *always* increments, even for ACKs, = and the echo number is always the max packet number seen, so you can get = good upstream RTT component measurements even if all the client sends is = ACKs. > In the first option, the echo is the "last seen sequence number" that = would otherwise be carried in the ACK frame. If we move it out of the = ACK frame and into the header, then we have pretty much a guarantee that = applications will do it right. I like that. Well, to be fair, the first option also allows two endpoints running a = private transport protocol to collude to lie to the path about their RTT = by agreeing to manipulate echo numbers. I'm not sure it's either = possible or useful to prevent that, though. > I also like that the scheme does not make the "connection start" = special, and works just as well after a rerouting or a NAT state change. That was a hard requirement of our design exercise. It's also the main = problem I can see with the revealed-hash stop signal: you need to send = the proof value somewhen, and the exposure of that proof is a special = "connection start", unless it is exposed periodically (which comes with = a cost in overhead). > OTOH, there is going to be a "feature interaction" between this = sequence+echo scheme and the senders' strategy of skipping some sequence = numbers in order to verify that the recipients are not making up ACKS. = The intermediate boxes will have no way to distinguish between a packet = number voluntarily skipped by the sender, and a packet loss between the = sender and the middlebox. I hope this won't affect the "wireshark = diagnostics" too much. >=20 >> When we are looking at the first option, you mentioned strategies to = avoid on-path >> injection attacks of stops. >=20 > I like the "two ways stop". It definitely increases the robustness. = Also, sending the sequence number and last seen in "clear text" solves = the "guess the sequence number" issue for the "rebooted server." Maybe = we can use EKR's scheme after all. The two-way stop and the revealed-hash stop are independent, so you = could also do both if you wanted to. >> ... Is there any attack that could be made regarding the PSN? If the = attacker can modify >> PSN values or inject packets with higher PSN values in either = direction, what side effects >> can we see? I'm assuming that the endpoints themselves will be able = to validate the >> authenticity of the fields, but could a middle box that is trying to = monitor the >> plausible-ness of the PSN get thrown off? Or does it only ever adjust = its plausibility >> window when it sees a PSN acknowledged? (To that end, if an = acknowledgment >> value is faked, what does that do?) >=20 > That's a very good observation, and in fact it applies to current QUIC = as well. A man-on-the side can inject a series of plausible packets = before the sender does. The "real" packets coming from the sender will = repeat packet numbers that are 'already seen'. A middlebox that is too = clever might drop those in an attempt to "remove duplicates." We can = always say that middleboxes should not try to be too clever, but that's = a bit like saying that the bubonic plague should be nicer... This might be an argument for recommending against plausibility checks = for middleboxes for anything other than the two-way stop. Unlike with = TCP, in any case they cannot assume anything about window dynamics based = upon assumed knowledge of the reliability or congestion control schemes = in place. Whether this recommendation would be widely followed is a = different question. Since the endpoints should be able to detect a middlebox-injected packet = (at least as long as there's a requirement that *every* packet have an = (encrypted) transport header above the common unencrypted header, which, = IMO, there is), really these attacks are all about middleboxes messing = with each other. If the endpoint can always detect, then it can also = close and attempt to reinitiate, or at least throw up a "your network is = messing with you" error. Cheers, Brian --Apple-Mail=_994CE9AE-B9EE-4A35-A2F3-3249FA425291 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 iQIcBAEBCgAGBQJYTnbiAAoJEIoSt78L6kajuvMP/2cIX7UWL5BI3pFLhCzrgwAx UxxKpGEkTDfN88NXvw+T6WH8vJHW1nWSNPrvBY2WbttFH8M/Gbwj3+Em/Bl5lkVM 9bpeiJgcwS1oIUsqO9C2h7hzrwJixNXYPl/Bh9+frQgaMW2/YqbtrRyf8GoYabFX kuoxJ6tM9hNvmjU4wkFYRIOflu36FOao5JwTDz4ofcvSbcQaL4fK8pWD/p34Kyd5 QRYJyYDzH5ujl6v9/nT68JiUSw0focQHmfeJtDd25jZpb8+rN9a7AZfqc/0AAY2/ +voj9IIIPt7dZmOqV2SFvk9wgm0WVqNnmXJ4p6MDFVp7eoVeQgDOofck2cWCBJXP tbBwcHBgcIllq11oGdn2MhOwe1glPrSqwnmnb/pSgjGaw0JtzOO/fvxPFMslUfIL tkZmjpFtSVDdHVMz9Vcds2s1nDD09UZ+UYuESDI/N/FMG0g0/ioln/C8EmCxWnZL E9Vb5ftBpjzfW7PDZ27zCYS9sZqCU7LrLE32bjZZOGDh51i82bEol/9HQ7Me2Juq 0llvCKuq5dthv5CXcTdi3wbfF7Ng+HScRl6icTzv0SBWdRSAH99eRiopKY8Ns005 2Wr8Nw7RMrPzWcSr4MATMe0pCPUozyHY86x4kisabjaWirPDfAY18AsB/CbFNK+Y gbrGkPm/vaoq23n7LLp5 =YTbE -----END PGP SIGNATURE----- --Apple-Mail=_994CE9AE-B9EE-4A35-A2F3-3249FA425291-- From nobody Thu Dec 22 07:46:39 2016 Return-Path: X-Original-To: plus@ietfa.amsl.com Delivered-To: plus@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF18C129421 for ; Thu, 22 Dec 2016 07:46:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, 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 eNCDeusbidfr for ; Thu, 22 Dec 2016 07:46:36 -0800 (PST) Received: from trammell.ch (trammell.ch [5.148.172.66]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB8E12941A for ; Thu, 22 Dec 2016 07:46:36 -0800 (PST) Received: from [IPv6:2001:67c:10ec:2a49:8000::b9] (unknown [IPv6:2001:67c:10ec:2a49:8000::b9]) by trammell.ch (Postfix) with ESMTPSA id 49F191A02A3 for ; Thu, 22 Dec 2016 16:46:05 +0100 (CET) From: Brian Trammell X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_7F042059-DE20-497D-B313-49C3CC028DA7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 22 Dec 2016 16:46:04 +0100 References: <148241999966.22456.8024129697268793977.idtracker@ietfa.amsl.com> To: plus@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [Plus] Fwd: New Version Notification for draft-trammell-plus-statefulness-02.txt X-BeenThere: plus@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of a Path Layer UDP Substrate \(PLUS\) protocol for in-band management of in-network state for UDP-encapsulated transport protocols." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 15:46:38 -0000 --Apple-Mail=_7F042059-DE20-497D-B313-49C3CC028DA7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've posted a new version of the statefulness draft, updating the state = machine to support the two-way stop discussed on list. Cheers, Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-trammell-plus-statefulness-02.txt > Date: 22 December 2016 at 16:19:59 GMT+1 > To: "Mirja Kuehlewind" , "Brian = Trammell" , "Joe Hildebrand" >=20 >=20 > A new version of I-D, draft-trammell-plus-statefulness-02.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Name: draft-trammell-plus-statefulness > Revision: 02 > Title: Transport-Independent Path Layer State = Management > Document date: 2016-12-22 > Group: Individual Submission > Pages: 17 > URL: = https://www.ietf.org/internet-drafts/draft-trammell-plus-statefulness-02.t= xt > Status: = https://datatracker.ietf.org/doc/draft-trammell-plus-statefulness/ > Htmlized: = https://tools.ietf.org/html/draft-trammell-plus-statefulness-02 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-trammell-plus-statefulness-02 >=20 > Abstract: > This document describes a simple state machine for stateful network > devices on a path between two endpoints to associate state with > traffic traversing them on a per-flow basis, as well as abstract > signaling mechanisms for driving the state machine. This state > machine is intended to replace the de-facto use of the TCP state > machine or incomplete forms thereof by stateful network devices in a > transport-independent way, while still allowing for fast state > timeout of non-established or undesirable flows. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_7F042059-DE20-497D-B313-49C3CC028DA7 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 iQIcBAEBCgAGBQJYW/U9AAoJEIoSt78L6kaj8dsQAKveSnJG+iWQGK+QrutTqHAi Rewzdq1E6cTXmmfMea2yRf7h4tqiF0fHEUmQSepRMf2tn/9pUirequyu4g89wyGX DCXWSSDYtI6SVQJV7fjEIizH0UGvlF8ACjfl+GXz50q/kEurXQlNa5Mv6NtC/5l4 tsaYb3IkxSTjF4REgOrjnB8MAwzXwUN6EJ9kVwOlqLZI/IbW6iAEQNimKZTs+aam DF/RKNgop2r3h09OfCH2N0O3jOQ23iQzhITI7B3SiEcGKRWQvfqwQw2BD+tTw6uH GW6ZdIZ6u4TC9hYZ7+WKpUUIEc0u2hhtYNCF6qWTDjRh75cTXDcnJ7crLZIP2tDs jno39Y2B+cgdt1cqFvM3sJMrDKaO4St6oNY1rsAV3WGuYkYc9bQMn9Vymwbopo8Z Y+1t0fPypy/dHQb8tDN8BERZveEVbGDOv2wGAkw4+3eNxy8rAsArXiOYbYcP5fQA G9eFF3r+8twqdzJw16xtXCEtuYungqYWPE54jnCfuwwQEwXucPqZXdJYLh/Gm3QY huW9zPznZ+x18VTVGcPbYv5MxmbcAWMXGyeemA+0FuRgPWaQ4I8ZFG4gj1t41/47 0nlrMYg1r/46IQk4vOOCAt4Nkhsa8EcEG06GYuFFhpBin0jmf2K++sQHTaZWz26A OwSEhRlERRJep8T1IpuH =HnMz -----END PGP SIGNATURE----- --Apple-Mail=_7F042059-DE20-497D-B313-49C3CC028DA7--