RE: Opsdir last call review of draft-ietf-quic-manageability-14

["MORTON JR., AL" <[e-mail]>]

Hi Mirja, thanks for your replies and PRs.
please see replies below, I clipped discussions we have closed.
Al

> -----Original Message-----
> From: Mirja Kuehlewind <[e-mail]>
> Sent: Tuesday, March 1, 2022 1:49 PM
> To: MORTON JR., AL <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14
> 
> Hi Al,
> 
> thanks again! See below!
> 
> On 27.02.22, 19:50, "MORTON JR., AL" <[e-mail]> wrote:
> 
> [snip]
...
>     [acm] I see that there was additional editing since you wrote last Monday,
> so I made a comment and suggestions on GitHub.
> 
> [MK] Thx! Added you suggestions!
> 
> [snip]
> 
> 
>     >     >
>     >     >     2.8.  Version Negotiation and Greasing
>     >     >
>     >     >     ...
>     >     >        QUIC is expected to evolve rapidly, so new versions, both
>     >     >        experimental and IETF standard versions, will be deployed
> on the
>     >     >        Internet more often than with traditional Internet- and
>     > transport-
>     >     >        layer protocols.  Using a particular version number to
> recognize
>     >     >        valid QUIC traffic is likely to persistently miss a
> fraction of
>     > QUIC
>     >     >        flows and completely fail in the near future, and is
> therefore
>     > not
>     >     >        recommended.
>     >     >     [acm] Where "valid traffic" is the focus, I agree, let it
> flow.
>     >     >     But the Operator's focus may instead be "admissible traffic",
> where
>     >     >     experimental traffic is not wanted or allowed. IOW, only
> traffic
>     > that is
>     >     >     understood to conform to <RFC list> shall pass, because
> "Active
>     > Attacks are
>     >     >     also Pervasive", to put a different spin on 7258. [acm] See
> also the
>     > comment in
>     >     >     3.4.1.
>     >     >
>     >     > [MK] This is not about experimentation.
>     >     [acm]
>     >     OK, let's just say unexpected traffic.
>     >
>     >     > The expectation is that QUIC versions
>     >     > will change often, e.g. we already have a draft for a new version
>     > adopted in
>     >     > the group and there might be another RFC some time this year. So
> if you
>     >     > "manually" have to allow for new versions in all your equipment
> that
>     > will
>     >     > delay deployment of new versions (or even hinder them because
> there is
>     > always
>     >     > one box that doesn't get updated). Therefore we strongly recommend
> to
>     > not use
>     >     > the version to filter QUIC traffic. Is that not clear enough in
> the
>     > text?
>     >     >
>     >     >        In addition, due to the speed of evolution of the
>     >     >        protocol, devices that attempt to distinguish QUIC traffic
> from
>     > non-
>     >     >        QUIC traffic for purposes of network admission control
> should
>     > admit
>     >     >        all QUIC traffic regardless of version.
>     >     [acm]
>     >     I think it is clear, and at the same time, it is aspirational for
> many
>     > networks.
>     >     This sentence informs, but then strays into policy.
>     >
>     >     Maybe this will work:
>     >           ...devices that attempt to distinguish QUIC traffic from non-
>     >            QUIC traffic for purposes of network admission control should
> not
>     > rely
>     >            on the version field alone.
>     >
>     > [MK] I think your proposal is not correct because the whole point is
> that you
>     > really should not use the version field _at all_. I know that people
> will
>     > still do that, but I think we should at least spell it out clearly here
> that
>     > this is problematic and hinders evolution.
>     [acm]
>     Evolution is what happens when a succeeding RFC is approved.
>     Experimentation is the many months between approvals.
> 
>     	...devices that attempt to distinguish QUIC traffic from non-
>          QUIC traffic for purposes of network admission control
>     *** should admit all QUIC traffic regardless of version.***
>     The last phrase attempts to define operator policy.
>     Don't do that.
>     The version field exists. It's specified in a standard.
>     If you simply say,
>     "The version field will change in the future." no one will be surprised.
> 
> [MK] Okay I got your point about policy. However, this document is meant to
> provide guidance/recommendations to operators. I also see now that this in the
> "background" part which is also rather to explain QUIC than give
> recommendations. However, I think this is actually one of the essential
> recommendations of the document, so I would like to still spell this out
> clearly and as early/often as possible. I tried a slightly different wording
> in a new PR on github. Is that any better?
> 
> https://urldefense.com/v3/__https://github.com/quicwg/ops-
> drafts/pull/459/files__;!!BhdT!mOHh0CyPDRUf9uvgZfIrDspADvFLupiMn-
> 5czo4ercUtLNr7_gQJcuGTzI0cYadmIRktrtZrgoTKCp4DmqHssizC$
> 
[acm]
Not yet. Maybe we can compose your message to operators *without* making it sound like you are trying to set policy.  I suggested text in the PR like this:

Developers would prefer admission of all QUIC traffic regardless of version in order to support continuous version-based evolution. However, all parties understand the value of versions with a corresponding, fully-approved standard.
 
> 
>     >
>     >     >
>     >     >     [acm] I was hoping to see a description of fallback to TCP (I
> see
>     > that fallback
>     >     >     is mentioned briefly at the end of section 4.2., and later,
> fail
>     > over and
>     >     >     failover. pick one...)
>     >     >
>     >     >     How can Network Operators observe when a QUIC setup has
> failed, and
>     > the
>     >     >     corresponding TCP fallback connection(s) succeeded?
>     >     >
>     >     > [MK] There is no unified way how and if fallback is implemented.
>     > However, why
>     >     > do you think a network operator would need that information?
>     >     [acm]
>     >     To affirm that their admission policy is working properly, for one
> reason.
>     >
>     > [MK] However, there is really no guarantee that all QUIC will have a
> fallback.
>     > Without further knowledge about what higher layer service the QUIC
> transport
>     > carries, I don't think you can make any assumption about fallback. If
> you want
>     > to support evolution, you need to support QUIC and not rely on any
> potentially
>     > fallbacks.
>     [acm]
>     I chose example carefully: the operator wants to support QUIC, but has
> reports that QUIC setup is failing and needs to make measurements to gather
> symptoms & info. Experience will indicate the circumstances where QUIC setup
> failure is accompanied by fallback, and other possibilities. Repeated
> experiences become heuristics for passive observation.
>     No assumptions necessary.
>     Has QUIC setup failed if the exchanges in Figure 1 are incomplete?
>     I think there might be a yes or no answer...
>     If no, then the passive observation procedure will mostly be governed by
> heuristics.
> 
> [MK] I think I lost the point now. If QUIC fails even if there is a fallback,
> that's still not great because the original intention was obviously to use
> QUIC. Is there anything we need to say in the draft that is missing?
[acm] 
Without getting into fallback in any way, 
Help the operator determine when a QUIC setup has failed by providing a little more info.
It would be useful to know:
What QUIC messages would accompany a QUIC setup failure? (other than those in Figure 1)
OR
A statement like: 
If the exchange in Figure 1 is incomplete, then the QUIC setup has failed.
(IF that is true)


> 
>     >
>     >     >
>     >     >     Is there a reference available with this info, to save effort
> here?
>     >     >
>     >     > [MK] As I said this is rather implementation specific, so I would
> say
>     > no.
>     >     >
>     >     >     ...
>     >     >
>     >     >     3.4.1.  Extracting Server Name Indication (SNI) Information
>     >     >
>     >     >     ...
>     >     >
>     >     >        Note that proprietary QUIC versions, that have been
> deployed
>     > before
>     >     >        standardization, might not set the first bit in a QUIC long
>     > header
>     >     >        packet to 1.  However, it is expected that these versions
> will
>     >     >        gradually disappear over time.
>     >     >     [acm]
>     >     >     And some networks may prefer not to admit experimental
> traffic. The
>     > goal of the
>     >     >     experiment may be problematic for the network operator and/or
> their
>     >     >     subscribers. I think this is legitimate operator behavior, and
> worth
>     > a few more
>     >     >     words in the draft.
>     >     >
>     >     > [MK] To be honest I don't understand this point. How would an
> operator
>     > even
>     >     > know if an experiment would be problematic or no? QUIC is fully
>     > encrypted.
>     >     > Versioning is only one extension mechanism. So basically even if
> you see
>     > the
>     >     > same version number, the QUIC behind that could behave very
> differently
>     >     > depending on which extensions are used and because of the
> encryption,
>     > there is
>     >     > no chance for the operator to know about this. Is this not clear
> in the
>     >     > document? Do we need to state this more clearly?
>     >     [acm]
>     >     First, let's say s/experimental/unexpected/ or
> s/experimental/proprietary/
>     >     Then, I'm responding to your reply more than the paragraph in the
> draft
>     > now:
>     >     Network operators are also end users, and often act on their
> subscriber's
>     > behalf. Observations are not strictly limited to mid-points, where
> encryption
>     > is present.
>     >     Harboring old notions of what operators cannot do will not sit well
> with
>     > your audience...
>     >
>     >     So, (in the paragraph above) you've informed operators that some
>     > proprietary QUIC versions remain in use as of this writing.
>     >     But traffic that doesn't conform *might* be considered nefarious.
> That's
>     > all. It's a message for everyone involved.
>     >
>     > [MK] I think the point is actually rather that we want to say here: if
> you
>     > don't support these old versions that will not be a problem in the near
>     > future.
>     [acm]
>     Ok, say that in the draft, please.
> 
> [MK] Okay started a PR on github. Is that more clear now?
> 
> https://urldefense.com/v3/__https://github.com/quicwg/ops-
> drafts/pull/460/files__;!!BhdT!mOHh0CyPDRUf9uvgZfIrDspADvFLupiMn-
> 5czo4ercUtLNr7_gQJcuGTzI0cYadmIRktrtZrgoTKCp4DmqkDVmpL$
> 
> 
[acm] 
I'm ok with this one, thanks.

>