Re: Packet number encryption

Martin Duke <martin.h.duke@gmail.com> Fri, 02 February 2018 00:47 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9475126E3A for <quic@ietfa.amsl.com>; Thu, 1 Feb 2018 16:47:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gU3TOviPS1ok for <quic@ietfa.amsl.com>; Thu, 1 Feb 2018 16:47:20 -0800 (PST)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84508126DED for <quic@ietf.org>; Thu, 1 Feb 2018 16:47:19 -0800 (PST)
Received: by mail-wm0-x22d.google.com with SMTP id 141so9113744wme.3 for <quic@ietf.org>; Thu, 01 Feb 2018 16:47:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KgkwxcQSqb7sTUGCxGjHt3Pg7/MhTqlyw7qHX1C3itA=; b=Jal2nZRE2f3Vt88SyBq3kiTJfz8/8Tj+yPYRmxdYQZQA5RqTNJoAv3OUu+oqR8tgWr e0aJkC4z2rzr9k0+NLoDrgOWNqQzLa0uHpFH9uKTPfnJBHjaKdB+nkG568WxQVEeB3fM Ms1xo8qcMSnfSqGc4Hpeci6rAIM3CcwMJPx5vW8o40kI/VjC+QSx3hASrpnEd/qdGf05 pe+p2ar6GTJu8DvP8KoGEWywiMc5hV+iN1HouipUSp9alOEYXL1+1is6CqDiTO3QjJRe negTcti3LT9c7KqYiBBpJVT945V74LSGi2N1BYC/z0ZPpVr/5d0B5cVxbsCboPpmO/r+ Icww==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KgkwxcQSqb7sTUGCxGjHt3Pg7/MhTqlyw7qHX1C3itA=; b=TUJMKYsEUCA9fIzDbbeWzOe9z8fcizpZS3gqjC1qKvusuGOZaTHn0OOyPl0k+91uog GDvex9EpfVw4sq1TtR3HIqRhRfBG5YTMn3kYaVDjyUyO4AJT/U+wu2dAiQRlGnbxHdBK 7tjWX7YnAoq5CDv3rQauvL4UZxLXt6+7QyZ8YTeTtGDXqH7fIVMqD9Jut1MY63+20dd0 CVYfV8m+YzhSv3wr1mlodaqxcJl8dj3/VNkQTkfGlWBzuQJUdx28+S6xS4JgTJtT2QAN ttLye68ZDtu6xdv4sbLkEwqr/Mz2X3+W1OCc/5kYft5FxArqaxdnu/3cX8tDtY7jRe1Y OkqQ==
X-Gm-Message-State: AKwxytfoMsNLmAlXZk4tZnV25sPgVNVop5lJOuQRgD2hk5eNvYkwnA3Q v3RxfPPSTx/+RAZEhIatnx/u/JssEF4S5upx9VQ=
X-Google-Smtp-Source: AH8x227spuDpe8vD+FoGTbqX3yjLuhZXMQ9M+avCmDHxviIR/9R2viFaUOsQw+h1OPU3Vch8l8RAJn7hMdKUSiwOSuo=
X-Received: by 10.28.150.86 with SMTP id y83mr21336400wmd.42.1517532438038; Thu, 01 Feb 2018 16:47:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.208.130 with HTTP; Thu, 1 Feb 2018 16:47:17 -0800 (PST)
Received: by 10.223.208.130 with HTTP; Thu, 1 Feb 2018 16:47:17 -0800 (PST)
In-Reply-To: <CAM4esxR_L9OvkEQ3G8z=yK1VgPQDJTMWeB2ts7CSgtV_de9MiQ@mail.gmail.com>
References: <CABkgnnVyo3MmWtVULiV=FJTnR528qfY8-OmKGWAs0bCvri-a_g@mail.gmail.com> <1F7FB3B8-A94C-4354-9944-FB09FB8DB68B@trammell.ch> <CABcZeBMbwdwyC9TxxHBLYaZKfNB-FG2wCGjqUZ_mNR-A1R47FA@mail.gmail.com> <9096e5ec-581e-875a-b1dd-bff0b05206fd@huitema.net> <CABkgnnWRQSAufwPss+qf=xAzCwRYeNNH8XLPm3yFaHxOb+ba4g@mail.gmail.com> <BF80500A-6277-45DC-8525-9C3FE138B76D@tik.ee.ethz.ch> <827BA6F8-5CA8-420A-B18B-60D8BC134A46@fb.com> <CA+9kkMDvp64NspznEuVy2tu8Eh1xmFkXu5S0AtDwbZKQ9Kq2fA@mail.gmail.com> <7F0C8A1D-1CE8-44E1-B3A4-ACFCB19D1F12@fb.com> <CABkgnnVsx9ohKO95bsDbYpM+bgWb-HQiVW2Yn=XWG458uzNgtg@mail.gmail.com> <CAGD1bZbH2qz2WL0YsOJJ=j7V-Lkt_V6K1RQ+5ZhMAzOWEAvdGQ@mail.gmail.com> <A236CE0B-24C1-41F0-A80D-7DD966D291B7@trammell.ch> <CAM4esxTj6Jv4nv975SDzczx9QEG-18WNm7UC7WxDcjyN+PeVgA@mail.gmail.com> <CAM4esxR_L9OvkEQ3G8z=yK1VgPQDJTMWeB2ts7CSgtV_de9MiQ@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 01 Feb 2018 16:47:17 -0800
Message-ID: <CAM4esxRVecQUJZwSv-+fV43CyTER-OY7H7WZGAKU0yT84qn6aA@mail.gmail.com>
Subject: Re: Packet number encryption
To: Brian Trammell <ietf@trammell.ch>
Cc: Jana Iyengar <jri@google.com>, Ted Hardie <ted.ietf@gmail.com>, Roberto Peon <fenix@fb.com>, Christian Huitema <huitema@huitema.net>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Eric Rescorla <ekr@rtfm.com>, QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="001a114b33e4e790530564300df2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/A9YDKtQUD5OLnVVfEUzxKVJYCNY>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Feb 2018 00:47:23 -0000

Brian, I can come up with a middlebox design that is trying to be "helpful"
but ends up causing PN ossification, but as you suggest this requires the
box to be dumb about versions. So, meh.

The other benefit of this scheme is that acks can go back to 1 byte PNs in
ack frames for many connections, as the true packet number will start at 0
(boo!) or 1 (yay!).

On Feb 1, 2018 12:09 AM, "Brian Trammell (IETF)" <ietf@trammell.ch> wrote:

hi Jana, all,

> On 1 Feb 2018, at 03:46, Jana Iyengar <jri@google.com> wrote:
>
> I like this proposal for the ossification reason that Roberto described,
but I also like it because it really simplifies things from an
implementation perspective.

There seems to be a largely unquestioned assumption that packet number
encryption has utility for ossification prevention. I am not convinced of
this.

Our experience with TLS greasing shows that placing random values in fields
that would otherwise largely be static over the lifetime of the protocol
improves the ability to use those fields later. Packet number encryption is
greasing only by analogy. "Field X has value Y" is a fundamentally
different observation than "The values of field X over time are governed by
function F", and I'm not sure that intuition in the simpler case applies
directly to the more complicated one.

Specifically, for packet number encryption, the assumption appears to be
that in-network devices will deploy during the operational lifetime of QUIC
v1 that will make use of the observation that packet numbers monotonically
increase, in a way that will impair the deployment of QUIC vN > 1 that does
not have packet numbers that monotonically increase, or packet numbers that
appear at a different location in the header. In other words, these devices
will fail on this new version of QUIC in such a way that it will impair
service to endpoints using QUIC vN.

Analogies to the TCP sequence number here are a bit flawed. The most
important difference is that the open nature of TCP's wire image means that
usage of the sequence number isn't limited to observation: on-path devices
can change it, and forge or delay ACKs based on it. The only thing an
on-path device can do with a QUIC packet with a packet number it doesn't
like is to drop it. This function might have some utility as part of an
in-network QUIC garbage filter, as part of an anti-DDoS system, but any
such device would need to track the version number as well (indeed,
tracking version negotiation and handshaking would be a useful primitive
here in its own right), and would therefore have enough information to not
break on new versions it knows about.

(Note we specifically don't care about the case where devices making use of
this observation stop working in a way that the end-to-end properties of
QUIC vN are preserved: the invariants as of a given version are the public
wire-image interface to the protocol, anything else is at-your-own-risk,
no-user-servicable-parts-inside).

I suspect that similar arguments can be had about all but the simplest
proposed applications of greasing to functions more complex than "the value
of field X is always Y or Z". The example of packet number tracking points
to an anti-ossification approach that I have much more confidence in,
though:

The vigorous and meaningful exercise of the version negotiation and version
coexistence systems built into QUIC would force agility on on-path devices.
The earlier we do this, the more effective it would be. I've already said
this in other contexts, but I'll explicitly suggest it here: let's do QUIC
2, and soon (say, July 2019?), and use version negotiation *itself* as a
method to "grease" the version negotiation mechanism along with the rest of
the header.

> We currently have packet number gaps to be used with new CIDs, but these
are the same packet numbers on the wire as within the transport. So, when
used with connection migration or after quiescence, the sender and receiver
of ACKs has to deal with potentially large gaps... this is encodable on the
wire, sure, but these gaps are unnecessary within the transport.
>
> Encrypting packet numbers reduces complexity in that you get a packet
number gap on the wire without having to explicitly model it inside the
transport. The transport machinery starts packet numbers at 0, increments
it by 1 irrespective of migration or quiescence, and the ACK frames
similarly carry the plaintext packet number. Separating what's used within
the transport and what's visible on the wire allows you to do things like
use multiple CIDs within the same 5-tuple.

This is a more convincing argument for packet number encryption -- it does
seem hard to get this elegance in the transport while having a
non-trivially-linkable wire image without it.

> I see it as a clean separation of concerns, with consequent
simplification in implementation and an additional degree of freedom.
>
> I'm not convinced of the value of packet number in measuring reordering
degree, since this can be trivially done by looking at the IP ID field for
packets on the same 5-tuple.

For IPv4 packets, on implementations where IPID is not randomized, yes. I
don't have numbers on how prevalent these are; in any case, where it isn't
randomized, that's arguably a bug that should be fixed. Should the guidance
in the manageability draft, then, be "use IPv4 if you care about loss and
reordering detection"? I am not optimistic about the chances of that
getting past the IESG. ;)

Cheers,

Brian

> On Wed, Jan 31, 2018 at 6:00 PM, Martin Thomson <martin.thomson@gmail.com>
wrote:
> With some light editing for quoting purposes...
>
> On Thu, Feb 1, 2018 at 12:02 PM, Roberto Peon <fenix@fb.com> wrote:
> >> Or do you mean CIDs 1-3 may be used on any of the 5-tuples A-C, for
the same
> >> communicating peers  Alice'sPhone and Bob'sBankServer93?
> >
> > The latter assuming we allow the server to specify it.
>
> I find "assuming we allow the server to specify *it*" to be strangely
cryptic.
>
> To be clear, my operating assumption is while that servers can provide
> multiple connection IDs, those connection IDs need to be usable on any
> 5-tuple.  Are you suggesting that a server might need to signal where
> a connection is usable?  (I can see how that might make sense, but it
> isn't possible with the protocol as specified.)  Or are you suggesting
> that there might need to be some signal that allows clients to
> distinguish between connection IDs that are for concurrent use? That
> is, as opposed to what you might assume to be sequential use based on
> the current specification.
>
> FWIW, it should be possible to remove the sequencing field from
> NEW_CONNECTION_ID after making this change.  The only reason left for
> sequential connection ID use is to give the server the ability to know
> when certain connection IDs no longer need to be available.  A server
> might then be able to clean up associated state and even reuse them.
>
> Of course, that likely only makes sense if the server is creating
> explicit mappings for each, which - as discussed at the interim -
> isn't super practical in many deployments.  Right now, I think that
> the assumption is an assumption only, and that relying on strictly
> linear use of connection IDs would be unwise.
>
>