RE: Robert Wilton's Discuss on draft-ietf-quic-bit-grease-04: (with DISCUSS and COMMENT)

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Martin,

> -----Original Message-----
> From: Martin Thomson <[e-mail]>
> Sent: 01 July 2022 01:05
> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; WG Chairs <[e-mail]>;
> [e-mail]; Lucas Pardue <[e-mail]>
> Subject: Re: Robert Wilton's Discuss on draft-ietf-quic-bit-grease-04: (with
> DISCUSS and COMMENT)
> 
> Hi Rob,
> 
> On Thu, Jun 30, 2022, at 19:15, Robert Wilton via Datatracker wrote:
> > (1) The purpose of having a fixed value is to allow QUIC to be
> >    efficiently distinguished from other protocols;
> >
> > This sentence seems inconsistent with draft-ietf-quic-manageability that
> states
> > that this bit cannot be used reliably to indicate QUIC traffic.
> 
> That appears to be a misreading of the text.  The failing here is that this text
> doesn't say *by whom*.  It only refers to RFC 7983[bis].  I thought that was
> sufficient.
> 
> Would this be clearer?

Yes, definitely.


> 
> > The purpose of having a fixed value is to allow endpoints to efficiently
> distinguish QUIC from other protocols; [...]
> 
> Note that this is only *mostly* correct.  Endpoints can cooperate with
> intermediaries to disable this extension if identification or demultiplexing is
> useful.  I believe that this is what Google's current deployment does, for
> example.  That's independent of the RFC 7983-related use, where the same is
> also possible.

Martin Duke has a somewhat similar explanation in the IESG telechat, that I thought was really helpful.

So, perhaps consider whether "... endpoint and cooperating intermediaries to efficiently ..." may be better.

But I'll leave this to you to decide, I'll clear my discuss on this either way.


> 
> > Ultimately, for QUIC, it isn't really clear to me whether:
> > (i) Intermediates nodes are not expected to be able to efficiently identify
> > QUIC traffic. (ii) Intermediate nodes are expected to efficiently identify
> QUIC
> > v1 traffic only.
> >
> > Assuming that the quic bit grease extension ends up with reasonable
> deployment
> > then I think that we end up with (i).  Is that correct and the intention?
> 
> Yes.
> 
> > (2)
> > This document already has a comment in the security section about the
> potential
> > security impact of using this extension.  I think that this document could
> > benefit from an Operational Considerations section to highlight that using
> this
> > extension is likely to impact the ability of intermediate devices to identify
> > QUIC packets which may change how the network handles QUIC packets,
> either by
> > giving them special treatment compared to other UDP traffic, or
> categorizing
> > them and handling them the same as all other UDP traffic.  Or perhaps the
> > security section paragraph could be expanded to cover this point (although
> it
> > isn't really security, but observed functionality).
> 
> I'm happy to add a pointer to the manageability draft to that text.  That
> covers all of that material much better than any new section I could write
> might.
> 
> See https://github.com/quicwg/quic-bit-grease/pull/28 for the two tweaks
> mentioned.

Yes, I think that a reference to the Manageability draft is probably helpful.  As per the pull request, I would suggest that it would be helpful to point them explicitly to section 3.1 that covers identifying QUIC traffic.

But either way, I'll leave it to you/the WG to decide.

Thanks,
Rob