Re: Connection IDs

[Jana Iyengar <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] *On Behalf Of *Subodh Iyengar
> *Sent:* Wednesday, March 7, 2018 12:26 PM
> *To:* Martin Thomson <[e-mail]>; Jana Iyengar <
> [e-mail]>
> *Cc:* Ian Swett <[e-mail]>; IETF QUIC WG <[e-mail]>;
> Patrick McManus <[e-mail]>
> *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 <[e-mail]> on behalf of Martin Thomson <
> [e-mail]>
> *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 <[e-mail]> wrote:
> > +1 to this is the direction we're all converging on.
> >
> > On Mon, Mar 5, 2018 at 6:01 AM, Ian Swett
> > <ianswett=[e-mail]> wrote:
> >>
> >> Agreed, I unsurprisingly think this is the right direction.
> >>
> >>
> >> On Mon, Mar 5, 2018 at 8:05 AM Patrick McManus <[e-mail]>
> >> wrote:
> >>>
> >>> big picture this is good.
> >>>
> >>> On Sun, Mar 4, 2018 at 8:54 PM, Martin Thomson <
> [e-mail]>
> >>> 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=
> >>>>
> >>>
> >
>