Re: [Plus] Supporting connection tracking and basic diagnostics: a minimal PLUS

"Christian Huitema" <huitema@huitema.net> Sun, 11 December 2016 06:33 UTC

Return-Path: <huitema@huitema.net>
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 <plus@ietfa.amsl.com>; 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 <plus@ietfa.amsl.com>; 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 <plus@ietf.org>; 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 <huitema@huitema.net>) 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 <huitema@huitema.net>) 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 <huitema@huitema.net>) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ianswett@google.com>; 11 Dec 2016 06:33:42 -0000
From: "Christian Huitema" <huitema@huitema.net>
To: "'Tommy Pauly'" <tpauly@apple.com>, "'Ian Swett'" <ianswett@google.com>, "'Brian Trammell'" <ietf@trammell.ch>
References: <83EEC537-3486-4864-ACA2-911F570D0C57@trammell.ch> <15261501-1F9C-41CA-87D0-4E8FCD862044@trammell.ch> <CAKcm_gMzw9Z=XnFy9vYfxOOG+eO6XJ2bSNeboQYjxW+MOUwa9g@mail.gmail.com> <E4BB21D8-9747-409C-BCF7-E62029897282@apple.com>
In-Reply-To: <E4BB21D8-9747-409C-BCF7-E62029897282@apple.com>
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: <https://mailarchive.ietf.org/arch/msg/plus/UrLBi8Z_XDReYNevrdHYn3GkHk4>
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." <plus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/plus>, <mailto:plus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/plus/>
List-Post: <mailto:plus@ietf.org>
List-Help: <mailto:plus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/plus>, <mailto:plus-request@ietf.org?subject=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 
> 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.

> 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...

-- Christian Huitema