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, 07 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>; Jana Iyengar < > jri.ietf@gmail.com> > *Cc:* Ian Swett <ianswett@google.com>; IETF QUIC WG <quic@ietf.org>; > 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= > >>>> > >>> > > >
- Connection IDs Martin Thomson
- Re: Connection IDs Eric Rescorla
- Re: Connection IDs Patrick McManus
- Re: Connection IDs Ian Swett
- Re: Connection IDs Jana Iyengar
- Re: Connection IDs Martin Thomson
- Re: Connection IDs Subodh Iyengar
- RE: Connection IDs Nick Banks
- RE: Connection IDs Mike Bishop
- RE: Connection IDs Mike Bishop
- Re: Connection IDs Jana Iyengar
- Re: Connection IDs Martin Thomson
- RE: Connection IDs Lubashev, Igor
- Re: Connection IDs Christian Huitema
- Re: Connection IDs Gorry Fairhurst
- Re: Connection IDs Rui Paulo
- Re: Connection IDs Mikkel Fahnøe Jørgensen
- Re: Connection IDs Patrick McManus
- Re: Connection IDs Ian Swett
- Re: Connection IDs Subodh Iyengar
- Re: Connection IDs Jana Iyengar
- Re: Connection IDs Mikkel Fahnøe Jørgensen