Re: Connection IDs

[Martin Thomson <[e-mail]>]

Comments are always appreciated :)

On Thu, Mar 8, 2018 at 8:48 AM, Jana Iyengar <[e-mail]> wrote:
> 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=
>> >>>>
>> >>>
>> >
>
>