Re: Packet number encryption

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 02 February 2018 12:27 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 9D9A0129C6B for <quic@ietfa.amsl.com>; Fri, 2 Feb 2018 04:27:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 lUrnybBqLdVK for <quic@ietfa.amsl.com>; Fri, 2 Feb 2018 04:27:36 -0800 (PST)
Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB2112D7E4 for <quic@ietf.org>; Fri, 2 Feb 2018 04:27:36 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zXx8735F1z15N44; Fri, 2 Feb 2018 13:27:35 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch
Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPiADAyikPwm; Fri, 2 Feb 2018 13:27:34 +0100 (CET)
X-MtScore: NO score=0
Received: from [192.168.178.33] (i577BCE83.versanet.de [87.123.206.131]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 2 Feb 2018 13:27:34 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Subject: Re: Packet number encryption
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <CAGD1bZbH2qz2WL0YsOJJ=j7V-Lkt_V6K1RQ+5ZhMAzOWEAvdGQ@mail.gmail.com>
Date: Fri, 02 Feb 2018 13:27:33 +0100
Cc: Martin Thomson <martin.thomson@gmail.com>, Roberto Peon <fenix@fb.com>, Ted Hardie <ted.ietf@gmail.com>, Eric Rescorla <ekr@rtfm.com>, Christian Huitema <huitema@huitema.net>, Brian Trammell <ietf@trammell.ch>, QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5DB817B8-3B9B-43B8-8949-1ABF8F9A1BF8@tik.ee.ethz.ch>
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>
To: Jana Iyengar <jri@google.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/SdnTYQPA16ZfVFXDHRD6qZWekGk>
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 12:27:38 -0000

Hi Jana,

one point below, just to clarify this explicitly.

> Am 01.02.2018 um 03:46 schrieb Jana Iyengar <jri@google.com>:
> 
> 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.
> 
> 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. 
> 
> I see it as a clean separation of concerns, with consequent simplification in implementation and an additional degree of freedom.

You also have this with an random offset. You internally start with 0 or 1 and just add or remove the offset from the PN in the wire image. Done. I like this separation a lot and think that is a  great change as it does make implementation easier and reduces overhead. However, these are two different things. There is no need to encrypt the PM just for that.

Mirja



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