Re: Connection IDs

Jana Iyengar <jri.ietf@gmail.com> Wed, 07 March 2018 21:48 UTC

Return-Path: <jri.ietf@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 11E0912D959 for <quic@ietfa.amsl.com>; Wed, 7 Mar 2018 13:48:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ZlZifroEnUDc for <quic@ietfa.amsl.com>; Wed, 7 Mar 2018 13:48:40 -0800 (PST)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (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 28D7212D950 for <quic@ietf.org>; Wed, 7 Mar 2018 13:48:37 -0800 (PST)
Received: by mail-wm0-x243.google.com with SMTP id t3so7579520wmc.2 for <quic@ietf.org>; Wed, 07 Mar 2018 13:48:37 -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=p9GNrp1o5u/4O4Zf0s3Daco4nBN4aa29mDN1J1Tvfp0=; b=MM4uXgSfT7L5HRw5BLyY2/AQJ2bhOiYDHQ3JpHrF2TuPAXhuIrs7ZAMf6BUJVakv+r 73HwAX/Q8a3w/NK1On6tHbKKQyp7IEw9Dgj97Q0AkrtkPvuuhx7dp4IqSGI0GGsRZYsi mXkLHqgCNr5KbuDbrT4LokGtCVrRz2PEvGrPhM4nZ4qpzhvRvAJ4BIfKvV4XJu/br75K Oo/YLJiOLsKjg4cCzICD6rJLLWcrC0ETry/zXvJ8wmeSp9tYw0UpHr02JzAZF5EKLont a9vwlYc080IYZxTDSuzK3bL28HPLUbeDyyZK75+AYjD7PCwWrF7LBElpmaJkFxFvRL+u HvvQ==
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=p9GNrp1o5u/4O4Zf0s3Daco4nBN4aa29mDN1J1Tvfp0=; b=MGy3u+9uIm91G0WW4bBI5FrVUUxgb0dfFYSwxBWTHy/G4YzcdYRk8irWBN8lDYnNYP JzP0PfO9OGpAMMLRmcUI9UKAFRLfJhn7T23FJCSZVWtRXDktp52tErcrwjuOlsMkrGfI b6t7OY9bS/e8uV26i05B4TlUubWJzaIt4ddziPiRBzR/mBCher4mrbnvugw4xGXfN9bn LRXn0H5sEeV4YfAN84NjLK5T2VwHl73Oeb03s2qczvgx92VogGB1JNf6TpYU35XqElHq V2t03/C7qyMb2BJIxTkWnRCYR+fpHOHIRNA6Ozfzs/PfpMBwqsPtRD/4yn6bYyyDJr51 pvGQ==
X-Gm-Message-State: AElRT7GPgGA+4JuWWKyjdGjukJ0AxVMPpMILLV/SIWC/pkzsGq9ok3yB RJHcQPtPV0BBNY9YQim9zYarPP8M8uWB8hW3I6ioFA==
X-Google-Smtp-Source: AG47ELsOnq4+ij/FDzuuZ5S+oKNziIz5WDc2Hqnmy14AQIIydH7b9B1K2Y7VoSzemF5A78KhPp3R/j12f+iEtPXZTQk=
X-Received: by 10.28.235.4 with SMTP id j4mr16614444wmh.52.1520459315716; Wed, 07 Mar 2018 13:48:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.195.139 with HTTP; Wed, 7 Mar 2018 13:48:35 -0800 (PST)
In-Reply-To: <SN1PR08MB1854C45248CD637877C50FACDAD80@SN1PR08MB1854.namprd08.prod.outlook.com>
References: <CABkgnnVSCnmzjWOZwQM+ctTxFXVzsVYe6Q3Zzk4yj3LNTYUtHw@mail.gmail.com> <CAOdDvNo9qmZqmEXBGM4bM6q3EO1FGuUxLSSWsVhNEYsn5u9puQ@mail.gmail.com> <CAKcm_gMR070JUegQbDw--RNr+0XYiBMwaTM3MBmqUo21u922TQ@mail.gmail.com> <CACpbDccpuNWnX=Y+gKaPxLEjUOnvu+hr9FqH+R6ZspwOfUq-qg@mail.gmail.com> <CABkgnnUPJYG-QE4qxfOd-6AoHHgxVq4K=EyRfoxkcvdDF=oaZA@mail.gmail.com> <MWHPR15MB18215C39DCB3DC5398778EC6B6D80@MWHPR15MB1821.namprd15.prod.outlook.com> <SN1PR08MB1854C45248CD637877C50FACDAD80@SN1PR08MB1854.namprd08.prod.outlook.com>
From: Jana Iyengar <jri.ietf@gmail.com>
Date: Wed, 7 Mar 2018 13:48:35 -0800
Message-ID: <CACpbDccER27gggsst4DPf-JhtZNDQGdYMX8neaHVcfR19T3hzA@mail.gmail.com>
Subject: Re: Connection IDs
To: Mike Bishop <mbishop@evequefou.be>
Cc: Subodh Iyengar <subodh@fb.com>, Martin Thomson <martin.thomson@gmail.com>, Ian Swett <ianswett@google.com>, IETF QUIC WG <quic@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>
Content-Type: multipart/alternative; boundary="089e083101b468a82b0566d9859a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/Do8l9oPi8BlE-xPmN5dePjk82NM>
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, 07 Mar 2018 21:48:43 -0000

I approved the design earlier and I still approve the design, employer
notwithstanding :-)
I have comments, which I've left on the PR.

- jana

On Wed, Mar 7, 2018 at 12:35 PM, Mike Bishop <mbishop@evequefou.be> wrote:

> I think Christian’s concerns were addressed.  Language was added to
> require that if you see a CID change, you also need to move to the next CID
> you have available.  An issue was opened to track the “what if you run
> out?” question.
>
>
>
> There was briefly language added saying that if you see the peer change
> addresses without changing CIDs, you should change CIDs for them.  However,
> if we do that, an on-path attacker can start rewriting source addresses on
> packets to drain your pool of allocated CIDs and force you into the
> newly-opened issue.
>
>
>
> However, Christian should confirm whether these resolve his concerns.
>
>
>
> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Subodh Iyengar
> *Sent:* Wednesday, March 7, 2018 12:26 PM
> *To:* Martin Thomson <martin.thomson@gmail.com>om>; Jana Iyengar <
> jri.ietf@gmail.com>
> *Cc:* Ian Swett <ianswett@google.com>om>; IETF QUIC WG <quic@ietf.org>rg>;
> Patrick McManus <pmcmanus@mozilla.com>
> *Subject:* Re: Connection IDs
>
>
>
> Unsurprisingly I am positive on the direction of this as well and the PR
> looks good to me
>
>
>
> Note: I do not work for mozilla or google :), but was a part of the connid
> design
>
>
>
> IIRC there was one unresolved question by Christian about both clients and
> servers needing to change the connids to enforce linkability, was that
> resolved?
>
>
>
> Subodh
> ------------------------------
>
> *From:* QUIC <quic-bounces@ietf.org> on behalf of Martin Thomson <
> martin.thomson@gmail.com>
> *Sent:* Wednesday, March 7, 2018 12:19:02 PM
> *To:* Jana Iyengar
> *Cc:* IETF QUIC WG; Patrick McManus; Ian Swett
> *Subject:* Re: Connection IDs
>
>
>
> Just to add to this and bring this list up to speed...
>
> Ian opened https://github.com/quicwg/base-drafts/issue/1166 which
> suggests moving the Version field into a fixed location.
>
> To that end: https://github.com/quicwg/base-drafts/pull/1167
>
> Does anyone have anything more to add (perhaps someone who does not
> work for Mozilla or Google) here?  The feedback I've received is
> overwhelmingly positive thus far and my hope is to merge this ahead of
> the editors starting an extended editing session next week.
>
>
> On Tue, Mar 6, 2018 at 12:04 PM, Jana Iyengar <jri.ietf@gmail.com> wrote:
> > +1 to this is the direction we're all converging on.
> >
> > On Mon, Mar 5, 2018 at 6:01 AM, Ian Swett
> > <ianswett=40google.com@dmarc.ietf.org> wrote:
> >>
> >> Agreed, I unsurprisingly think this is the right direction.
> >>
> >>
> >> On Mon, Mar 5, 2018 at 8:05 AM Patrick McManus <pmcmanus@mozilla.com>
> >> wrote:
> >>>
> >>> big picture this is good.
> >>>
> >>> On Sun, Mar 4, 2018 at 8:54 PM, Martin Thomson <
> martin.thomson@gmail.com>
> >>> wrote:
> >>>>
> >>>> I've written up a PR that enacts the changes suggested by the design
> >>>> team [1].
> >>>>
> >>>> https://github.com/quicwg/base-drafts/pull/1151
> >>>>
> >>>> This adds two connection IDs to the long header.  An explicit length
> >>>> is added for each.
> >>>>
> >>>> The short header includes the raw connection ID without any C bit or
> >>>> length.
> >>>>
> >>>> I've tried to explain the limitations of the design where they apply.
> >>>> That includes stateless reset.
> >>>>
> >>>> This PR necessarily includes some choices about less critical aspects,
> >>>> such as how connection ID lengths are encoded.  I ask that you try to
> >>>> separate objections about minor issues like this from more serious
> >>>> structural concerns.  I'm happy to discuss details, but I'm most
> >>>> interested in whether this is broadly the right direction first.
> >>>>
> >>>> Cheers,
> >>>> Martin
> >>>>
> >>>> p.s., happy draft submission deadline day
> >>>>
> >>>> [1]
> >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__
> mailarchive.ietf.org_arch_msg_quic_l-5Fb1NnBmQpQGCxCfQteOMkft-2DlE&
> d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=
> tfbg3BLo-IK9aUKrHNiK-A7EBi5XuVtoq9cZsYYBwbA&s=
> 50Q1gLhlSOcRuTmcpkgAnBusZim2NElvKAFN6IIX2Ec&e=
> >>>>
> >>>
> >
>