IETF Logo Mail Archive

Re: Packet number encryption

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Wed, 31 January 2018 07:44 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 BBC9812F4C5 for <quic@ietfa.amsl.com>; Tue, 30 Jan 2018 23:44:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 1GjUfxhHpS55 for <quic@ietfa.amsl.com>; Tue, 30 Jan 2018 23:44:44 -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 77E48131962 for <quic@ietf.org>; Tue, 30 Jan 2018 23:44:44 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3zWZyg0kDsz15N8b; Wed, 31 Jan 2018 08:44:43 +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 mTEMfu5hWQ7M; Wed, 31 Jan 2018 08:44:41 +0100 (CET)
X-MtScore: NO score=0
Received: from [172.20.10.5] (ip-109-40-2-39.web.vodafone.de [109.40.2.39]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 31 Jan 2018 08:44:40 +0100 (CET)
Content-Type: text/plain; charset="utf-8"
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: <CABkgnnWRQSAufwPss+qf=xAzCwRYeNNH8XLPm3yFaHxOb+ba4g@mail.gmail.com>
Date: Wed, 31 Jan 2018 07:44:32 +0000
Cc: Christian Huitema <huitema@huitema.net>, Brian Trammell <ietf@trammell.ch>, Eric Rescorla <ekr@rtfm.com>, QUIC WG <quic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BF80500A-6277-45DC-8525-9C3FE138B76D@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>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/F7yVJn0BMdlBY20m_LhX5Qu4kNk>
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: Wed, 31 Jan 2018 07:44:47 -0000


> Am 31.01.2018 um 04:08 schrieb Martin Thomson <martin.thomson@gmail.com>:
> 
> On Wed, Jan 31, 2018 at 8:00 AM, Christian Huitema <huitema@huitema.net> wrote:
>>> (1) An unprivileged on-path device that sees a packet from a flow that is
>>> migrated on purpose by an endpoint (i.e., due to connection migration or
>>> multipath) should not be able to associate that packet to the prior flow.
>> 
>> Yes.
> 
> Agreed.  This remains the primary target.  I don't think that there
> are any negatives with this design with respect to this use case (or
> at least I found nothing in Brian's email on this point).

If that is the goal, I think the complexity of the proposed solution is not justified. Just select a new random offset when you migrate but increase the packet number monotonously otherwise to support manageability.

I’m really concerned about complexity here. Even though this scheme is not very complex, any complexity is a potential source for future implementation errors which can also led to restrictions in what changes can be deploy with future versions. Making a protocol as simple as possible and thereby the spec as easy understandable as possible is also key for deployment. If we add complexity here without making it clear what the goal or additional benefit is of the complexity, I think that is just wrong.

My 2c.
Mirja

v2.23.0 | Report a Bug | By Email