RE: Andrew Alston's Discuss on draft-ietf-quic-bit-grease-04: (with DISCUSS)

[Andrew Alston - IETF <[e-mail]>]

Hi Martin,

I prefer the more complete text – just makes it easier for people to parse during implementation in my view.

So if you’re ok with that I will go ahead and clear my discuss once that’s pushed

Thanks

Andrew


From: Martin Thomson <[e-mail]>
Sent: Tuesday, July 5, 2022 2:21 AM
To: Andrew Alston - IETF <andrew-ietf=[e-mail]>; Lucas Pardue <[e-mail]>
Cc: Andrew Alston - IETF <[e-mail]>; The IESG <[e-mail]>; [e-mail]; WG Chairs <[e-mail]>; QUIC WG <[e-mail]>
Subject: Re: Andrew Alston's Discuss on draft-ietf-quic-bit-grease-04: (with DISCUSS)

I've prepared two versions:

Something like what Lucas said: https://github.com/quicwg/quic-bit-grease/pull/30<https://github.com/quicwg/quic-bit-grease/pull/30>
Minimal: https://github.com/quicwg/quic-bit-grease/pull/29<https://github.com/quicwg/quic-bit-grease/pull/29>

I'll leave this to those that had more trouble with the language to let me know what they prefer.


On Mon, Jul 4, 2022, at 19:07, Andrew Alston - IETF wrote:
> Sorry for the delayed response,
>
> I think Lucas’s statement is fair here – so if we can agree on t hat –
> I’d be ok with clearing my discuss on this one
>
> Thanks
>
> Andrew
>
>
> *From:* Lucas Pardue <[e-mail]<mailto:[e-mail]>>
> *Sent:* Friday, July 1, 2022 3:58 AM
> *To:* Martin Thomson <[e-mail]<mailto:[e-mail]>>
> *Cc:* Andrew Alston - IETF <[e-mail]<mailto:[e-mail]>>; The IESG
> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; WG Chairs
> <[e-mail]<mailto:[e-mail]>>; QUIC WG <[e-mail]<mailto:[e-mail]>>
> *Subject:* Re: Andrew Alston's Discuss on
> draft-ietf-quic-bit-grease-04: (with DISCUSS)
>
> Hey Martin, all,
>
> I think you're correct in pointing out that the term unpredictable is a
> term of art within the context of QUIC that this draft operates.
> However, I find also in RFC 9000 that supporting text for various
> unpredictable elements usually provides a justification or some
> guidance. Arguably, the justification _is_ the entire document, but in
> the context of other grease-like mechanisms in the IETF, it seems a
> single bit might need a more holistic approach beyond just the value
> itself.
>
> The closest parallel, for me, is the spin bit text that goes so far as saying
>> [if your TPs let you randomize] It is RECOMMENDED that
> endpoints set the spin bit to a random value either chosen
> independently for each packet or chosen independently for each
> connection ID.
>
> Stating explicitly that the unpredictability can be per connection or
> per packet might be all that's need to make the intent crystal clear,
> while leaving the actual decisions to implementations.
> Cheers
> Lucas
>
>
> On Fri, Jul 1, 2022 at 12:45 AM Martin Thomson <[e-mail]<mailto:[e-mail]>> wrote:
>> I'm surprised at this question. We used the word "unpredictable" in RFC 9000 a few times, with exactly this meaning and had no issue. See for example:
>>
>> > When an Initial packet is sent by a client that has not previously received an Initial or Retry packet from the server, the client populates the Destination Connection ID field with an unpredictable value.
>>
>> Or
>>
>> > To initiate path validation, an endpoint sends a PATH_CHALLENGE frame containing an unpredictable payload on the path to be validated.
>>
>> Or
>>
>> Stateless Reset {
>> Fixed Bits (2) = 1,
>> Unpredictable Bits (38..),
>> Stateless Reset Token (128),
>> }
>>
>> As you say, a bit can assume one of two values, 0 or 1. Setting a bit to a predictable value would mean choosing 0 or 1 in a way that someone might be able to guess the next value. Always 1, always 0, or alternating 0 and 1 are examples of predictable methods of selecting a value. Setting a bit to an unpredictable value would mean setting it to either 0 or 1 such that someone else is unlikely to correctly guess the next value. A random draw is unpredictable, but there are other methods that would also be unpredictable.
>>
>> On Thu, Jun 30, 2022, at 22:52, Andrew Alston via Datatracker wrote:
>> > Andrew Alston has entered the following ballot position for
>> > draft-ietf-quic-bit-grease-04: Discuss
>> >
>> > When responding, please keep the subject line intact and reply to all
>> > email addresses included in the To and CC lines. (Feel free to cut this
>> > introductory paragraph, however.)
>> >
>> >
>> > Please refer to
>> > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/<https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions>
>> > for more information about how to handle DISCUSS and COMMENT positions.
>> >
>> >
>> > The document, along with other ballot positions, can be found here:
>> > https://datatracker.ietf.org/doc/draft-ietf-quic-bit-grease/<https://datatracker.ietf.org/doc/draft-ietf-quic-bit-grease>
>> >
>> >
>> >
>> > ----------------------------------------------------------------------
>> > DISCUSS:
>> > ----------------------------------------------------------------------
>> >
>> > Thanks for the work on this document,
>> >
>> > Hopefully this discuss will be relatively easy to resolve - and may result from
>> > a lack of understanding - but -
>> >
>> > Endpoints that receive the grease_quic_bit transport parameter from a
>> > peer SHOULD set the QUIC Bit to an unpredictable value unless another
>> > extension assigns specific meaning to the value of the bit.
>> >
>> > Now, this is in reference to a bit - which can only be 0 or 1 - and the
>> > document further goes on to clarify certain situations where this bit should be
>> > set or unset - so I am not at all sure what this paragraph really means and
>> > hoping this can be clarified because I'm not sure how this will be interpreted
>> > on implementation.