Subject: Big TP codespace

From: Martin Duke <[email-masked]>
Date: Mon, 13 May 2019 13:58:12 -0700

Here's an annoying part of the transport parameter spec:

There are 2^16 possible TPs and I should handle them all gracefully, but
the highest standard one is 13. I also MUST blow up the connection if
there's a duplicate TP. For 13 TPs, I can very easily check for duplicates
with a 16-bit field. But to meet this requirement, I need an 8KB field or a
fancier, more time-consuming data structure, which is really cumbersome.

If I'm actually supporting a handful of experimental TPs, it's easy to
track those by exception. What I'd propose is that we MUST end the
connection if there's a duplicate of any of the TPs I actually support.

What do people think?

---

From: Matt Joras <[email-masked]>
Date: Mon, 13 May 2019 14:05:42 -0700

On Mon, May 13, 2019 at 1:58 PM Martin Duke <[email-masked]> wrote:
> There are 2^16 possible TPs and I should handle them all gracefully, but the highest standard one is 13. I also MUST blow up the connection if there's a duplicate TP. For 13 TPs, I can very easily check for duplicates with a 16-bit field. But to meet this requirement, I need an 8KB field or a fancier, more time-consuming data structure, which is really cumbersome.
>
> If I'm actually supporting a handful of experimental TPs, it's easy to track those by exception. What I'd propose is that we MUST end the connection if there's a duplicate of any of the TPs I actually support.
>
> What do people think?

Isn't this covered by https://github.com/quicwg/base-drafts/issues/2689?

Matt Joras

---

From: Christian Huitema <[email-masked]>
Date: Mon, 13 May 2019 14:06:35 -0700

> On May 13, 2019, at 1:58 PM, Martin Duke <[email-masked]> wrote:
> 
> What do people think?

I think the general rule of protocol policing should be "MUST NOT" do dastardly stuff, and "MAY" drop the connection when that happens.

-- Christian Huitema

---

From: David Schinazi <[email-masked]>
Date: Mon, 13 May 2019 17:19:21 -0700

Our implementation checks for duplicates only for the transport parameters
it supports. I think #2691
<https://github.com/quicwg/base-drafts/pull/2691/files> is the correct
solution.

+1 to the design principle of encouraging but not requiring detection of
errors like this

David

On Mon, May 13, 2019 at 2:06 PM Christian Huitema <[email-masked]>
wrote:

> I think the general rule of protocol policing should be "MUST NOT" do
> dastardly stuff, and "MAY" drop the connection when that happens.
>
> -- Christian Huitema
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 May 2019 17:21:11 -0700

What's the bigger principle you are endorsing? What errors "like this" are
we not requiring detection of?

On Mon, May 13, 2019 at 5:19 PM David Schinazi <[email-masked]>
wrote:

> On Mon, May 13, 2019 at 2:06 PM Christian Huitema <[email-masked]
> <huitema@huitema..net>> wrote:
>
>>
>>

---

From: Mike Bishop <[email-masked]>
Date: Wed, 15 May 2019 17:20:35 +0000

We agreed in Tokyo that we would not mandate that implementations check for improper peer behavior when doing so required substantial extra work.  Implementations MUST error out on easily-detected errors, but only SHOULD/MAY error on things they would have to actively check (unless they’re already required to actively check for security reasons, in which case there’s no extra work).

From: QUIC <[email-masked]> On Behalf Of Eric Rescorla
Sent: Tuesday, May 14, 2019 5:21 PM
To: David Schinazi <[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Christian Huitema <[email-masked]>; Martin Duke <[email-masked]>
Subject: Re: Big TP codespace

What's the bigger principle you are endorsing? What errors "like this" are we not requiring detection of?

On Mon, May 13, 2019 at 5:19 PM David Schinazi <[email-masked]<mailto:[email-masked]>> wrote:
Our implementation checks for duplicates only for the transport parameters it supports. I think #2691<https://github.com/quicwg/base-drafts/pull/2691/files> is the correct solution.

+1 to the design principle of encouraging but not requiring detection of errors like this

David

On Mon, May 13, 2019 at 2:06 PM Christian Huitema <[email-masked]<mailto:huitema@huitema..net>> wrote:

> On May 13, 2019, at 1:58 PM, Martin Duke <[email-masked]<mailto:[email-masked]>> wrote:
>
> What do people think?

-- Christian Huitema

---

From: David Schinazi <[email-masked]>
Date: Wed, 15 May 2019 10:44:15 -0700

@ekr, the principle I was endorsing is the one Mike mentioned.

On Wed, May 15, 2019 at 10:20 AM Mike Bishop <[email-masked]> wrote:

> We agreed in Tokyo that we would not mandate that implementations check
> for improper peer behavior when doing so required substantial extra work.
> Implementations MUST error out on easily-detected errors, but only
> SHOULD/MAY error on things they would have to actively check (unless
> they’re already required to actively check for security reasons, in which
> case there’s no *extra* work).
>
>
>
> *From:* QUIC <[email-masked]> *On Behalf Of * Eric Rescorla
> *Sent:* Tuesday, May 14, 2019 5:21 PM
> *To:* David Schinazi <[email-masked]>
> *Cc:* IETF QUIC WG <[email-masked]>; Christian Huitema <[email-masked]>;
> Martin Duke <[email-masked]>
> *Subject:* Re: Big TP codespace
>
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 15 May 2019 18:47:10 -0700

Martin, the text in #2691 supports what you want to accomplish, but doesn't
require everyone to do the same thing. I think that's all we need.

On Wed, May 15, 2019 at 10:44 AM David Schinazi <[email-masked]>
wrote:

>> *Cc:* IETF QUIC WG <[email-masked]>; Christian Huitema <
>> [email-masked]>; Martin Duke <[email-masked]>
>> Our implementation checks for duplicates only for the transport
>> parameters it supports. I think #2691
>> On Mon, May 13, 2019 at 2:06 PM Christian Huitema <huitema@huitema..net>
>> wrote:
>>
>>
>>

---

From: Martin Duke <[email-masked]>
Date: Thu, 16 May 2019 12:01:32 -0700

yep, i'm conversing in there.

On Wed, May 15, 2019 at 6:47 PM Jana Iyengar <[email-masked]> wrote:

> Martin, the text in #2691 supports what you want to accomplish, but
> doesn't require everyone to do the same thing. I think that's all we need.
>