Subject: Connection IDs

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Mar 2018 12:54:34 +1100

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://mailarchive.ietf.org/arch/msg/quic/l_b1NnBmQpQGCxCfQteOMkft-lE

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 4 Mar 2018 19:30:07 -0800

Unsurprisingly, I think this is moving int he right direction. I think we
are getting close to being ready to do some bit twiddling :)

-Ekr

---

From: Patrick McManus <[email-masked]>
Date: Mon, 5 Mar 2018 08:05:48 -0500

big picture this is good.

---

From: Ian Swett <[email-masked]>
Date: Mon, 05 Mar 2018 14:01:13 +0000

Agreed, I unsurprisingly think this is the right direction.

On Mon, Mar 5, 2018 at 8:05 AM Patrick McManus <[email-masked]> wrote:

>> [1]
>> https://mailarchive.ietf.org/arch/msg/quic/l_b1NnBmQpQGCxCfQteOMkft-lE
>>
>>
>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 5 Mar 2018 17:04:03 -0800

+1 to this is the direction we're all converging on.

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 5 Mar 2018 17:04:03 -0800

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Mar 2018 07:19:02 +1100

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 <[email-masked]> wrote:
> On Mon, Mar 5, 2018 at 6:01 AM, Ian Swett
> <ianswett=[email-masked]> wrote:
>>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Mar 2018 07:19:02 +1100

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 7 Mar 2018 20:26:27 +0000

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 <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Sent: Wednesday, March 7, 2018 12:19:02 PM
To: Jana Iyengar
Cc: IETF QUIC WG; Patrick McManus; Ian Swett
Subject: Re: Connection IDs

On Tue, Mar 6, 2018 at 12:04 PM, Jana Iyengar <[email-masked]> wrote:
>>>> 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=
>>>>
>>>
>

---

From: Subodh Iyengar <[email-masked]>
Date: Wed, 7 Mar 2018 20:26:27 +0000

Subodh

---

From: Nick Banks <[email-masked]>
Date: Wed, 7 Mar 2018 20:30:01 +0000

I personally like this proposed design as well.

- Nick

From: QUIC <[email-masked]> On Behalf Of Subodh Iyengar
Sent: Wednesday, March 7, 2018 12:26 PM
To: Martin Thomson <[email-masked]>; Jana Iyengar <[email-masked]>
Cc: Ian Swett <[email-masked]>; IETF QUIC WG <[email-masked]>; Patrick McManus <[email-masked]>
Subject: Re: Connection IDs

Subodh

From: QUIC <[email-masked]<mailto:[email-masked]>> on behalf of Martin Thomson <[email-masked]<mailto:[email-masked]>>

Ian opened https://github.com/quicwg/base-drafts/issue/1166<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fissue%2F1166&data=04%7C01%7Cnibanks%40microsoft.com%7C389eff7e4dfa4eaca41708d58469bcb6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636560512053683616%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-2&sdata=uK7ct2umJZknXLMHwziR6FqLRmE5o9It4X5IcW%2FHWU0%3D&reserved=0> which
suggests moving the Version field into a fixed location.

To that end: https://github.com/quicwg/base-drafts/pull/1167<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F1167&data=04%7C01%7Cnibanks%40microsoft.com%7C389eff7e4dfa4eaca41708d58469bcb6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636560512053693620%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-2&sdata=lqdb8bCHckVrIakeo2V%2Fq%2Flt%2BTQEA2M8ezl9bl278Xw%3D&reserved=0>

On Tue, Mar 6, 2018 at 12:04 PM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:
> <ianswett=[email-masked]<mailto:ianswett=[email-masked]>> wrote:
>>
>> On Mon, Mar 5, 2018 at 8:05 AM Patrick McManus <[email-masked]<mailto:[email-masked]>>
>> wrote:
>>>
>>> On Sun, Mar 4, 2018 at 8:54 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>>
>>> wrote:
>>>>
>>>> https://github.com/quicwg/base-drafts/pull/1151<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fquicwg%2Fbase-drafts%2Fpull%2F1151&data=04%7C01%7Cnibanks%40microsoft.com%7C389eff7e4dfa4eaca41708d58469bcb6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636560512053693620%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-2&sdata=86WR%2B5tzroJ4D6DfHFm2ARJbglAU%2FjJe4nVB1FE5IIU%3D&reserved=0>
>>>>
>>>> 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=<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__mailarchive.ietf.org_arch_msg_quic_l-5Fb1NnBmQpQGCxCfQteOMkft-2DlE%26d%3DDwIBaQ%26c%3D5VD0RTtNlTh3ycd41b3MUw%26r%3Dh3Ju9EBS7mHtwg-wAyN7fQ%26m%3Dtfbg3BLo-IK9aUKrHNiK-A7EBi5XuVtoq9cZsYYBwbA%26s%3D50Q1gLhlSOcRuTmcpkgAnBusZim2NElvKAFN6IIX2Ec%26e%3D&data=04%7C01%7Cnibanks%40microsoft.com%7C389eff7e4dfa4eaca41708d58469bcb6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636560512053693620%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-2&sdata=SJV2xnzuXi4nyTTnv2fYP4eZD9HAWeR22xXKU5g9A0Q%3D&reserved=0>
>>>>
>>>
>

---

From: Mike Bishop <[email-masked]>
Date: Wed, 7 Mar 2018 20:30:03 +0000

I am content with this model, and I do not work for Google or Mozilla, nor have I in the past.  😉

-----Original Message-----
From: QUIC [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Wednesday, March 7, 2018 12:19 PM
To: Jana Iyengar <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Patrick McManus <[email-masked]>; Ian Swett <ianswett=[email-masked]>
Subject: Re: Connection IDs

Ian opened https://github.com/quicwg/base-drafts/issue/1166 which suggests moving the Version field into a fixed location.

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 <[email-masked]> wrote:
>>>> This adds two connection IDs to the long header.  An explicit 
>>>> length is added for each.
>>>>
>>>> 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
>>>>

---

From: Mike Bishop <[email-masked]>
Date: Wed, 7 Mar 2018 20:30:03 +0000

---

From: Mike Bishop <[email-masked]>
Date: Wed, 7 Mar 2018 20:35:22 +0000

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:[email-masked]] On Behalf Of Subodh Iyengar

Subodh

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 7 Mar 2018 13:48:35 -0800

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 <[email-masked]> 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.
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Subodh Iyengar
> *Sent:* Wednesday, March 7, 2018 12:26 PM
> *To:* Martin Thomson <[email-masked]>; Jana Iyengar <
> [email-masked]>
> *Cc:* Ian Swett <[email-masked]>; IETF QUIC WG <[email-masked]>;
> Patrick McManus <[email-masked]>
> *Subject:* Re: Connection IDs
>
>
>
> 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 <[email-masked]> on behalf of Martin Thomson <
> [email-masked]>
> *Sent:* Wednesday, March 7, 2018 12:19:02 PM
> *To:* Jana Iyengar
> *Cc:* IETF QUIC WG; Patrick McManus; Ian Swett
> *Subject:* Re: Connection IDs
>
>
>
> >>>> 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=
> >>>>
> >>>
> >
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Mar 2018 09:37:43 +1100

Comments are always appreciated :)

On Thu, Mar 8, 2018 at 8:48 AM, Jana Iyengar <[email-masked]> wrote:
>> you have available.  An issue was opened to track the “what if you run out?”
>> question.
>>
>>
>>
>> >>>> aspects,

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 8 Mar 2018 00:36:47 +0000

+1 for the connid direction from someone from an "eligible" employer.

That said, the proposal precludes load balancers from using Conn ID possibly present in ICMP TooBig payload for routing the ICMP TooBig back to the server, so I am looking forward to "PMTUD for QUIC" talks in QUIC and TSVWG.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, March 07, 2018 5:38 PM
To: Jana Iyengar <[email-masked]>
Cc: Ian Swett <[email-masked]>; Subodh Iyengar <[email-masked]>; Mike Bishop <[email-masked]>; Patrick McManus <[email-masked]>; IETF QUIC WG <[email-masked]>
Subject: Re: Connection IDs

On Thu, Mar 8, 2018 at 8:48 AM, Jana Iyengar <[email-masked]> wrote:
> notwithstanding :-) I have comments, which I've left on the PR.
>
> - jana
>
>> 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.
>>
>>
>>
>> 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
>>
>> overwhelmingly positive thus far and my hope is to merge this ahead 
>> of the editors starting an extended editing session next week.
>>
>>
>> >> On Mon, Mar 5, 2018 at 8:05 AM Patrick McManus 
>> >> <[email-masked]>
>> >> wrote:
>> >>>
>> >>>> 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
>> >>>>
>> >>>> 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-IK
>> >>>> 9aUKrHNiK-A7EBi5XuVtoq9cZsYYBwbA&s=50Q1gLhlSOcRuTmcpkgAnBusZim2N
>> >>>> ElvKAFN6IIX2Ec&e=
>> >>>>
>> >>>
>> >
>
>

---

From: Christian Huitema <[email-masked]>
Date: Wed, 7 Mar 2018 16:45:45 -0800

> That said, the proposal precludes load balancers from using Conn ID possibly present in ICMP TooBig payload for routing the ICMP TooBig back to the server, so I am looking forward to "PMTUD for QUI…
Funny, Patrick and I were just discussing preparing a draft based on the
experience with PMTU discovery in our implementation. Both work by
sending PMTU probes composed or PING and/or PAD.

I think that this kind of probing strategy is a good fit for an
encrypted transport like QUIC. I would not want to let cleartext ICMP
packets change the state of the connection. But this is a different thread.

And yes, by the way, I do like the new Connection IDs.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Wed, 7 Mar 2018 16:45:45 -0800

-- Christian Huitema

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 08 Mar 2018 08:18:18 +0000

Christian,

Do you see anything different here for QUIC compared to any other 
datagram transport?

It looks like the same problem for probing for PMTU for any UDP-based 
transport, and the ICMP issue with load-balancing is well-known (at 
least was discussed in the context of ECMP). I'd be interested in 
understanding experience with QUIC.

Gorry

---

From: Rui Paulo <[email-masked]>
Date: Thu, 08 Mar 2018 09:54:29 -0800

> the editors starting an extended editing session next week.

I think this change is an improvement.

—
Rui Paulo

---

From: Rui Paulo <[email-masked]>
Date: Thu, 08 Mar 2018 09:54:29 -0800

—
Rui Paulo

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 8 Mar 2018 10:11:35 -0800

I have been nudging for something like this for almost a year now, so I
couldn’t be any happier.
It deals with so many different issues in an elegant way.

The only thing is that I am little uneasy about Stateless Reset - is it
really needed?

Mikkel

On 8 March 2018 at 18.54.43, Rui Paulo ([email-masked]) wrote:

—
Rui Paulo

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 8 Mar 2018 10:11:35 -0800

Mikkel

—
Rui Paulo

---

From: Patrick McManus <[email-masked]>
Date: Thu, 8 Mar 2018 13:17:34 -0500

> The only thing is that I am little uneasy about Stateless Reset - is it
I feel the same way.. let it timeout.

---

From: Patrick McManus <[email-masked]>
Date: Thu, 8 Mar 2018 13:17:34 -0500

---

From: Ian Swett <[email-masked]>
Date: Thu, 08 Mar 2018 18:24:59 +0000

GQUIC inadvertently broke public reset(the predecessor to stateless reset)
for a period of time and it had a very visible effect on average latency,
so I would like to keep it.

More importantly, I think we should separate the conversation about
stateless reset from the this Connection ID one.  Those that want to keep
stateless reset are ok with the potential reduction in effectiveness this
change can cause and those that want to get rid of it don't care.

On Thu, Mar 8, 2018 at 1:17 PM Patrick McManus <[email-masked]> wrote:

>
>
> On Thu, Mar 8, 2018 at 1:11 PM, Mikkel Fahnøe Jørgensen <
> [email-masked]> wrote:
>
>>

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 8 Mar 2018 19:55:52 +0000

I agree about keeping the conversations separate and I’m in favor of keeping stateless reset or some form of fast error mechanism.

Subodh

On Mar 8, 2018, at 10:25 AM, Ian Swett <ianswett=[email-masked]<mailto:ianswett=[email-masked]>> wrote:

GQUIC inadvertently broke public reset(the predecessor to stateless reset) for a period of time and it had a very visible effect on average latency, so I would like to keep it.

More importantly, I think we should separate the conversation about stateless reset from the this Connection ID one.  Those that want to keep stateless reset are ok with the potential reduction in effectiveness this change can cause and those that want to get rid of it don't care.

On Thu, Mar 8, 2018 at 1:17 PM Patrick McManus <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Mar 8, 2018 at 1:11 PM, Mikkel Fahnøe Jørgensen <[email-masked]<mailto:[email-masked]>> wrote:

The only thing is that I am little uneasy about Stateless Reset - is it really needed?

---

From: Subodh Iyengar <[email-masked]>
Date: Thu, 8 Mar 2018 19:55:52 +0000

Subodh

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 8 Mar 2018 18:01:11 -0800

Removing stateless reset has the downside that clients will take longer to
retry potentially failed requests. However, that's not the question in this
PR, and I'd suggest opening an issue if anyone wants to discuss it.

On Thu, Mar 8, 2018 at 11:55 AM, Subodh Iyengar <[email-masked]> wrote:

> I agree about keeping the conversations separate and I’m in favor of
> keeping stateless reset or some form of fast error mechanism.
>
> Subodh
>
> On Mar 8, 2018, at 10:25 AM, Ian Swett <ianswett=40google.com@dmarc.
> ietf.org> wrote:
>

---

From: Jana Iyengar <[email-masked]>
Date: Thu, 8 Mar 2018 18:01:11 -0800

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 9 Mar 2018 00:17:29 -0800

I did not mean to start a long discussion on resets here, but I created an
issue as suggested. I will note though, that asymmetric Connection ID's do
make stateless reset more vulnerable to off-path attacks, unless I am
mistaken.

https://github.com/quicwg/base-drafts/issues/1177

Mikkel

On 9 March 2018 at 03.01.12, Jana Iyengar ([email-masked]) wrote:

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 9 Mar 2018 00:17:29 -0800

Mikkel