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

Ian Swett <ianswett@google.com> Sun, 11 December 2016 14:51 UTC

Return-Path: <ianswett@google.com>
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 <plus@ietfa.amsl.com>; 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 <plus@ietfa.amsl.com>; 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 <plus@ietf.org>; Sun, 11 Dec 2016 06:51:27 -0800 (PST)
Received: by mail-yw0-x234.google.com with SMTP id t125so47615893ywc.1 for <plus@ietf.org>; 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> <CAKcm_gMzw9Z=XnFy9vYfxOOG+eO6XJ2bSNeboQYjxW+MOUwa9g@mail.gmail.com> <E4BB21D8-9747-409C-BCF7-E62029897282@apple.com> <02ec01d25378$83799550$8a6cbff0$@huitema.net>
From: Ian Swett <ianswett@google.com>
Date: Sun, 11 Dec 2016 09:51:06 -0500
Message-ID: <CAKcm_gPHUQ-EYrC1SHEXj6vpSMdEqmqZufdWLpxJxnVLZ0ZwYg@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Content-Type: multipart/alternative; boundary=94eb2c032e702593a20543631f35
Archived-At: <https://mailarchive.ietf.org/arch/msg/plus/cfhn7Hm34bcbwhw778K1yoBTikM>
Cc: Brian Trammell <ietf@trammell.ch>, Tommy Pauly <tpauly@apple.com>, 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 14:51:30 -0000

On Sun, Dec 11, 2016 at 1:33 AM, Christian Huitema <huitema@huitema.net>
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
>
>
>
>