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

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 1 Mar 2022 18:49:09 +0000

Hi Al,

thanks again! See below!

On 27.02.22, 19:50, "MORTON JR., AL" <[email-masked]> wrote:

[snip]

    >     >     2.4.  The QUIC Handshake
    >     >
    >     >     ...
    >     >
    >     >        Client                                    Server
    >     >          |                                          |
    >     >          +----Client Initial----------------------->|
    >     >          +----(zero or more 0RTT)------------------>|
    >     >          |                                          |
    >     >          |<-----------------------Server Initial----+
    >     >          |<---------(1RTT encrypted data starts)----+
    >     >          |                                          |
    >     >          +----Client Completion-------------------->|
    >     >          +----(1RTT encrypted data starts)--------->|
    >     >          |                                          |
    >     >          |<--------------------Server Completion----+
    >     >          |                                          |
    >     >
    >     >        Figure 1: General communication pattern visible in the QUIC
    > handshake
    >     >
    >     >        As shown here, the client can send 0-RTT data as soon as it has
    > sent
    >     >        its Client Hello, and the server can send 1-RTT data as soon as
    > it
    >     >        has sent its Server Hello.  The Client Completion flight contains
    > at
    >     >        least one Handshake packet and could also include an Initial
    > packet.
    >     >        QUIC packets in separate contexts during the handshake can be
    >     >        coalesced (see Section 2.2) in order to reduce the number of UDP
    >     >        datagrams sent during the handshake.  QUIC packets can be lost
    > and
    >     >        reordered, so packets within a flight might not be sent close in
    >     >        time, though the sequence of the flights will not change, because
    > one
    >     >        flight depends upon the peer's previous flight.
    >     >
    >     >     [acm]
    >     >     It's great to add some Not-Sunny-Day info in the description,
    > thanks!
    >     >     But can you add a little more?  For example:
    >     >     Is it possible that network reordering can cause the handshake to
    > fail?
    >     >     What rerodering extent (yes, that's a metric) would be required to
    > cause
    >     >     failure or unnecessary retransmission? Lost packets would result in
    > time-outs
    >     >     and retransmission, so what are the default time-outs? Is there a
    > paper where
    >     >     some/all of the above have been investigated, that you could
    > reference to save
    >     >     some work?
    >     >
    >     > [MK] I don't think I have a good answer to these questions. However, I
    > don't
    >     > think these questions are necessarily QUIC specific. Reordering in
    > itself is
    >     > not a problem for the QUIC handshake, however, if some packets are also
    >     > delayed a lot and therefore detected as loss, it might get the handshake
    > to
    >     > fail. How long you keep state to wait for delayed packets in mostly
    >     > implementation specific, however, as I said this is also not a unique
    > problem
    >     > to the QUIC handshake.
    >     [acm]
    >     You've partly answered the questions above, and with help from Gorry and
    > Martin's replies let me suggest the following (mostly stuff I didn't know
    > about QUIC yet):
    > 
    >     Whether packet reordering affects/can be observed on the handshake depends
    > on the timeout period (which varies, but might be 10s or 30s in common cases),
    > the constraints implemented in a server (whether to take on arbitrary state
    > based on the first packet), and the extent of reordering incurred on the path.
    > Reordering having sufficient extent might inferred as packet loss, as with any
    > protocol.
    > 
    > [Mk] Okay I ended up with the following:
    > 
    > "Handshake packets can arrive out-of-order without impacting the handshake as
    > long as the reordering did not cause extensive delays which would be consider
    > as loss by either side. If QUIC packets get lost or reordered, packets
    > belonging
    > to the same flight might not be observed in close in time, though the sequence
    > of the flights will not change, because one flight depends upon the peer's
    > previous flight."
    > 
    > [Mk] Does that work?
    > 
    > [MK] See also: https://urldefense.com/v3/__https://github.com/quicwg/ops-
    > drafts/pull/458/files__;!!BhdT!jhSx83YqoVthpH2tB3oiivf7HPOhFDpLtxuPvRpfshchNQL
    > nnC-HGSULZeODPj6SGXmzIGgVEiIrCIQg5OBu0NjH$
    > 
    [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://github.com/quicwg/ops-drafts/pull/459/files

    > 
    >     >
    >     >     [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?

    > 
    >     >
    >     >     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://github.com/quicwg/ops-drafts/pull/460/files

---

From: "MORTON JR., AL" <[email-masked]>
Date: Sat, 5 Mar 2022 16:01:57 +0000

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

> -----Original Message-----
> From: Mirja Kuehlewind <[email-masked]>
> Sent: Tuesday, March 1, 2022 1:49 PM
> To: MORTON JR., AL <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14
> 
> Hi Al,
> 
> thanks again! See below!
> 
...
>     [acm] I see that there was additional editing since you wrote last Monday,
> so I made a comment and suggestions on GitHub.
> 
> should
> [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.
 
>     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.
> [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)

> 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.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 16 Mar 2022 14:39:37 +0000

Hi Al,

as you might have seen we merged the remaining PRs and submitted a new version last week.
But unfortunately, I don't think we were able to address your comment below fully.

Regarding use of version number I believe the text in the draft reflects the group consensus, so we only made my editorial change to make if clearer.

Regarding when the handshake fails, I'm not sure if it would be correct to say anything more here. You can always just not see some of the packets on the path, or the handshake could even change with a new version or an extension I guess. Again I'm also not really sure what to do with that information either. If you don't see any further packets flowing at any time, incl. right after the handshake, something went either wrong or the transmission is just done. It's really hard to make any assumption from the network here.

Mirja

On 05.03.22, 17:02, "MORTON JR., AL" <[email-masked]> wrote:

    ...
    > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-0c8d12cf3c8f69d3&q=1&e=0560674f-fb74-4ca7-afd2-16c2148a7129&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2Fquicwg%2Fops-
    [acm]

    [acm] 

    > https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-0c8d12cf3c8f69d3&q=1&e=0560674f-fb74-4ca7-afd2-16c2148a7129&u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fgithub.com%2Fquicwg%2Fops-
    [acm]

---

From: "MORTON JR., AL" <[email-masked]>
Date: Wed, 16 Mar 2022 19:23:08 +0000

Hi Mirja,

> Sent: Wednesday, March 16, 2022 10:40 AM
> Regarding use of version number I believe the text in the draft reflects the
> group consensus, so we only made my editorial change to make if clearer.
[acm] 
Your draft and WG consensus discourages use of the version field for admission purposes.
This is a question of whether any WG should state a consensus that expressed a *policy* for network managers and operators in an IETF RFC. If the same intent was stated as a conclusion reached by the WG, it would be far more palatable, and I offered alternative text as an example.

So, let's consider this issue as needing further discussion in a wider venue.
 
> 
> Regarding when the handshake fails, I'm not sure if it would be correct to say
> anything more here. You can always just not see some of the packets on the
> path, or the handshake could even change with a new version or an extension I
> guess. Again I'm also not really sure what to do with that information either.
> If you don't see any further packets flowing at any time, incl. right after
> the handshake, something went either wrong or the transmission is just done.
> It's really hard to make any assumption from the network here.
[acm] 
The case I cited was an operator that wants to support QUIC, and wants to identify when QUIC setup fails and how frequently failure occurs, to support analysis and troubleshooting and properly manage their network. I also note the dependency on knowing the version number in your paragraph above (when attempting to understand the handshake), as hint to accomplishing this management goal (by relating the version to a published specification). 

I think that a supporting operator (like the one above) is the most-likely reader of your memo, so it will help them to add a few sentences about non-Figure 1 handshakes. Even if the sentences are something like this (based on what you said above):

	If the handshake in Figure 1 is truncated or missing packets, many actual outcomes are possible (and not necessarily handshake failure). The end-points may have switched to a different version and handshake, switched to a different path, implemented fallback, terminated the attempt as the end-points intended, or other outcome. 
-=-=-=-=-=-=-=-=-=-

Over time, observers will likely develop heuristics to mitigate these uncertainties and draw probable conclusions (like they did with TCP), but you don't need to add that aspect. Just indicate the possibilities and try to improve the manageability of QUIC.

Al

>     >     >     >        experimental and IETF standard versions, will be
> deployed
>     > on the
>     >     >     >        layer protocols.  Using a particular version number
> to
>     > recognize
>     >     >     >     [acm] Where "valid traffic" is the focus, I agree, let
> it
>     > flow.
>     >     >     >     But the Operator's focus may instead be "admissible
> traffic",
>     > where
>     >     >     >     also Pervasive", to put a different spin on 7258. [acm]
> See
>     > also the
>     >     > comment in
>     >     >     >     3.4.1.
>     >     >     >
>     >     >     > 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?
>     >     >     >
>     >     >     >        protocol, devices that attempt to distinguish QUIC
> traffic
>     > from
>     >     > non-
>     >     >     I think it is clear, and at the same time, it is aspirational
> for
>     > many
>     >     > networks.
>     >     > [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
> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=31323334-
> 501d5122-313273af-454445555731-0c8d12cf3c8f69d3&q=1&e=0560674f-fb74-4ca7-afd2-
> 16c2148a7129&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fgithub.com*
> 2Fquicwg*2Fops-
> __;JSUlJSUlJSUlJQ!!BhdT!iHzaYKyN6pGji70tbHntNd77OXfIU4uuz7yrrrdyIBk1xF8H4AbY4b
> Yu77k6OuH_qZ54CWUksfGvL7zx23VlQpdp$
>     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...)
>     >     >     >
>     >     >     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.
>     >     > carries, I don't think you can make any assumption about fallback.
> If
>     > you want
>     >     If no, then the passive observation procedure will mostly be
> governed by
>     > heuristics.
>     >
>     >     >     >     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.
>     >     >     >
>     >     >     >     ...
>     >     >     >
>     >     >     >        packet to 1.  However, it is expected that these
> versions
>     > will
>     >     >     >     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
>     >     >     > Versioning is only one extension mechanism. So basically
> even if
>     > you see
>     >     > the
>     >     >     > no chance for the operator to know about this. Is this not
> clear
>     > in the
>     >     >     Then, I'm responding to your reply more than the paragraph in
> the
>     > draft
>     >     > now:
>     >     >     Harboring old notions of what operators cannot do will not sit
> well
>     > with
>     >     > your audience...
>     >     >
>     >     >     But traffic that doesn't conform *might* be considered
> nefarious.
>     > That's
>     >     > [MK] I think the point is actually rather that we want to say
> here: if
>     > you
> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=31323334-
> 501d5122-313273af-454445555731-0c8d12cf3c8f69d3&q=1&e=0560674f-fb74-4ca7-afd2-
> 16c2148a7129&u=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2F*2Fgithub.com*
> 2Fquicwg*2Fops-
> __;JSUlJSUlJSUlJQ!!BhdT!iHzaYKyN6pGji70tbHntNd77OXfIU4uuz7yrrrdyIBk1xF8H4AbY4b
> Yu77k6OuH_qZ54CWUksfGvL7zx23VlQpdp$

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Mar 2022 12:57:29 -0700

mirja, et al, in reviewing manageability-15, i see this text:

>    The QUIC wire image is not specifically designed to be
>    distinguishable from other UDP traffic by a passive observer in the
>    network.

i think this has an excluded middle problem, and should be changed to:

<<The QUIC wire image is specifically designed to be indistinguishable 
from other UDP traffic by a passive observer in the network.>>

this follows from RFC 7258, and is uncontroversial in the light thereof.

further to this point, i'd like to suggest adding a paragraph to the end 
of section 3.1 (Identifying QUIC Traffic):

<<Management of QUIC traffic can never be reliable, and if it becomes so 
over time, then the QUIC wire image would be forced to evolve. Therefore 
a heuristic along the lines of "any unrecognizable UDP traffic could be 
QUIC" is the least unappealing way for a network operator to 
characterize their network's UDP traffic in the QUIC era.>>

thanks in advance for your consideration.

vixie

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 22 Mar 2022 13:53:04 +0100

Hi Paul,

Thanks for the comments… a couple of points in reply inline...

> On 16 Mar 2022, at 20:57, Paul Vixie <paul=[email-masked]> wrote:
> 
> <<The QUIC wire image is specifically designed to be indistinguishable from other UDP traffic by a passive observer in the network.>> 
> 

It’s a bit more subtle than this, I think. There is a bit of distance between the QUIC wire image and “indistinguishable from other UDP traffic” in practice. udp/443 gets you most H3 traffic, the V1 wire image has a QUIC bit designed for multiplexing, etc. A truly observation-resistant wire image would have different properties.

What the design of QUIC does do is purposefully eliminate the role of intermediary third parties that do not cooperate with either endpoint, with a background understanding that the opportunities for abuse in this case outweigh the benefits to the first and second parties. It does this by reducing the observable surface (and eliminating the mutable surface) of that wire image. If a non-cooperative intermediate third party wants to interact with the mechanics of an application running over QUIC, it has the option of blocking QUIC, since all such applications must have a fallback to run on networks where UDP is blocked anyway. 

IOW, if you want to run a firewall protecting QUIC servers, you'll need to integrate that functionality with the front-end or load balancers. If you want to run a firewall protecting QUIC clients, or of protecting yourself from QUIC clients (exfil), you'll need to do that integrated with the clients, or through proxies. If you're not in a position to cooperate with either endpoint, then you're not part of the security architecture anymore, aside from forcing fallback to TCP or UDP.

But from a wire image standpoint, I believe the existing text is more accurate than the proposed change.

> further to this point, i'd like to suggest adding a paragraph to the end of section 3.1 (Identifying QUIC Traffic):
> 
> <<Management of QUIC traffic can never be reliable, and if it becomes so over time, then the QUIC wire image would be forced to evolve. Therefore a heuristic along the lines of "any unrecognizable UDP traffic could be QUIC" is the least unappealing way for a network operator to characterize their network's UDP traffic in the QUIC era.>>

This formulation seems to make the following assumptions:

- that management of other traffic can be reliable for some definition thereof, 
- that there is a implementably precise definition of “recognizable UDP traffic”,
- that traffic manageability necessarily requires uncooperative third-party intermediaries to be part of the security architecture,
- that the QUIC WG pursues as a matter of policy that QUIC be indistinguishable from UDP background and would evolve the protocol to protect against changes to that.

I’m not sure that any of those assumptions hold.

Thanks, cheers,

Brian

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Tue, 22 Mar 2022 15:42:41 +0100

Hi Al,

> On 16 Mar 2022, at 20:23, MORTON JR., AL <[email-masked]> wrote:
> 
> Hi Mirja,
> 
>> From: Mirja Kuehlewind <[email-masked] <mailto:[email-masked]>>
>> To: MORTON JR., AL <[email-masked] <mailto:[email-masked]>>
>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>;
>> [email-masked] <mailto:[email-masked]>; [email-masked] <mailto:[email-masked]>

I don’t think we’re stating a policy here, we’re stating a recommendation.

Note that QUIC v2 is mostly done; it’s a minimal change to the wire image meant to exercise the versioning mechanism. A network that admits only QUIC v1 (which, indeed, seems mostly reasonable from the standpoint of an operator used to the last few decades of the use and abuse of extensions in the Internet) will, at that point, reject ~half of QUIC traffic for ~no benefit to the operator or its users. The recommendation is meant to avoid that sort of silliness.

The reason behind this version agility is, in turn, to maintain the deployability of new versions. Networks are of course free to admit any traffic they want; the point of this language is to point out the mostly-negative tradeoff of doing so.

> So, let's consider this issue as needing further discussion in a wider venue.

I think we’re having that discussion on [email-masked] <mailto:[email-masked]> right now. :)

> The case I cited was an operator that wants to support QUIC, and wants to identify when QUIC setup fails and how frequently failure occurs, to support analysis and troubleshooting and properly manage their network.

There seems to be a tacit assumption here that holds in the TCP case that does not necessarily hold in the QUIC case: that an operator can helpfully debug the operation and performance of a transport protocol within their network. One of the reasons this is a useful (indeed, essential) role of network operators in the TCP world is that there is often an unavoidable, unintentional, transport-dependent differential impact of an operator’s own network on different traffic flows, where the remedy is often only actionable by the operator itself.

I’d submit that the main reason this happens with protocols like TCP is that the TCP wire image is path-observable and path-mutable. Without this path-observability and path-mutability, the set of possible flow-dependent impacts is necessarily reduced, if not eliminated. Without operator-actionable problems on the network, the observability of internal protocol dynamics from non-cooperative third parties becomes less important.

In other words, the set of wire image features that can cause differential treatment in an operator's network is equal to the set of wire image features that are freely observable by that operator.

Cheers,

Brian

> I also note the dependency on knowing the version number in your paragraph above (when attempting to understand the handshake), as hint to accomplishing this management goal (by relating the version to a published specification). 
> 
>> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=31323334- <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=31323334->
>> 16c2148a7129&u=https*3A*2F*2Furldefense.com <http://2furldefense.com/>*2Fv3*2F__https*3A*2F*2Fgithub.com <http://2fgithub.com/>*
>> 2Fquicwg*2Fops-
>> https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=31323334- <https://urldefense.com/v3/__https://protect2.fireeye.com/v1/url?k=31323334->
>> 16c2148a7129&u=https*3A*2F*2Furldefense.com <http://2furldefense.com/>*2Fv3*2F__https*3A*2F*2Fgithub.com <http://2fgithub.com/>*
>> 2Fquicwg*2Fops-

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Mar 2022 09:25:25 -0700

> Thanks for the comments… a couple of points in reply inline...

thank you! see also my response, inline.

>> ... in reviewing manageability-15, i see this text:
>>
>> <<The QUIC wire image is specifically designed to be
>> indistinguishable from other UDP traffic by a passive observer in the
>> network.>>
>>

i should have added that while the revised wording is not to my liking, 
it is intended to copy the structure of the existing wording, and thus 
be easier to evaluate. in particular, distinguishability is the wrong 
rubric for the revised language. more on that below.

> It’s a bit more subtle than this, I think. There is a bit of distance between the QUIC wire image and “indistinguishable from other UDP traffic” in practice. udp/443 gets you most H3 traffic, the V…

the properties of the V1 wire image already make it unidentifiable for 
purposes such as "allow QUIC V1 traffic through the firewall" or "deny 
QUIC V1 through the firewall" or "change the IP TOS for QUIC V1 
traffic." since that impact is neither accidental or incidental, the 
existing wording of the first paragraph of [3.1] is inaccurate.

> ... If a non-cooperative intermediate third party wants to interact with the mechanics of an application running over QUIC, it has the option of blocking QUIC, since all such applications must have a fallback to run on networks where UDP is blocked anyway.

an edge network operator _does not_ have the option of managing QUIC 
(for example, as you say, to block it). both [3.1] and all of [3] 
explain in detail that there is no reliable way to identify QUIC 
traffic. absent such identification, there can be no management. the 
opening paragraph of [3.1] should economically explain that this is so, 
and accurately describe the reason why that is so.

> IOW, if you want to run a firewall protecting QUIC servers, you'll need to integrate that functionality with the front-end or load balancers. If you want to run a firewall protecting QUIC clients, or of protecting yourself from QUIC clients (exfil), you'll need to do that integrated with the clients, or through proxies. ...

this ("need to do that integrated with the clients") is what i mean by 
"_does not_ have the option" above. for clarity, there is not a secure 
reliable proxy discovery protocol, and little incentive to create one. 
if the only "option of blocking QUIC" is to "integrate with the clients" 
then there is no actual option.

> ... If you're not in a position to cooperate with either endpoint, then you're not part of the security architecture anymore, aside from forcing fallback to TCP or UDP.

there is no reliable way to force fallback to TCP, or even to exempt 
QUIC from an otherwise blanket prohibition against wide area UDP. the 
opening paragraph of [3.1] should be clear about this limitation and 
about the reasons (not accidental, not incidental) why this is so.

> But from a wire image standpoint, I believe the existing text is more accurate than the proposed change.

if we can alter the structure of the opening paragraph of [3.1], then my 
proposed revision would change. something along these lines might be a 
better fit for the facts and for your concerns:

<<The QUIC wire image is designed to be unidentifiable and thus 
unmanageable by third parties such as gateway or firewall or network 
operators. As enumerated below, there are no durable data patterns 
visible "on the wire" and thus the only parties who can manage QUIC 
traffic patterns are the endpoints.>>

> I’m not sure that any of those assumptions hold.

as to management and recognition:

current generation firewall technology can allow some UDP protocols by 
looking for a well known port and validating the structure of the 
datagram to test for "exfil". NTP, SNMP, and DNS come to mind here. 
while it is far more common to allow or deny based on the port number 
alone, and in the deny case to therefore require and enforce the use of 
local services, secure private networks today have many options open to 
their operators. QUIC treats this as "oldthink" and deliberately 
obviates the practice. that effect, and its intentionality, ought to be 
called out in this document.

as to cooperation:

cooperation cannot be presumed on a managed private network. for 
example, IoT devices are often distributed cells in the corporate body 
of their makers. in a network of networks, each of the networks can be 
expected to use every means at its operators disposal to detect or 
prevent communication by uncooperative devices, apps, intruders, or 
insiders. QUIC's wire image effectively, and non-accidentally, forbids 
this. as a subjective matter, that forbiddence may seem good or evil, 
but that's out of scope for this document. as an objective matter, that 
forbiddence is real, and deliberate, which is in-scope for this document.

as to evolution, i agree that my proposed summary is a bridge too far.

perhaps this wording will be if lesser concern to you:

<<Identification of QUIC traffic by on-path actors such as network 
operators is not reliable. Therefore a heuristic along the lines of "any 
unrecognizable UDP traffic could be QUIC" is the least unappealing way 
for a network operator to characterize their network's UDP traffic in 
the QUIC era.>>

> Brian

and to you, sir.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 22 Mar 2022 09:54:03 -0700

> Hi Al,

not al, but see inline.

>>> [mk]
>>> Regarding when the handshake fails, I'm not sure if it would be 
>>> correct to say anything more here. You can always just not see
>>> some of the packets on the path, or the handshake could even
>>> change with a new version or an extension I guess. Again I'm also
>>> not really sure what to do with that information either. If you
>>> don't see any further packets flowing at any time, incl. right 
>>> after the handshake, something went either wrong or the
>>> transmission is just done. It's really hard to make any
>>> assumption from the network here.
>> [acm]
>> The case I cited was an operator that wants to support QUIC, and wants 
>> to identify when QUIC setup fails and how frequently failure occurs, 
>> to support analysis and troubleshooting and properly manage their network.
> [bt]
> There seems to be a tacit assumption here that holds in the TCP case 
> that does not necessarily hold in the QUIC case: that an operator can 
> helpfully debug the operation and performance of a transport protocol 
> within their network. ...

perhaps not necessarily, but often, it does hold.

> ... One of the reasons this is a useful (indeed, essential) role of
> network operators in the TCP world is that there is often an
> unavoidable, unintentional, transport-dependent differential impact
> of an operator’s own network on different traffic flows, where the
> remedy is often only actionable by the operator itself.

that is indeed one of the reasons, but there are others, including the 
one given by al above, and including debugging of PMTUD (now PLPMTUD) 
where the damage may be occurring upstream (far from "the operator 
himself" who in this story is trying to diagnose setup fails. we could 
try to enumerate a much larger set of reasons, but i don't think that 
would be helpful.

> I’d submit that the main reason this happens with protocols like TCP is 
> that the TCP wire image is path-observable and path-mutable. Without 
> this path-observability and path-mutability, the set of possible 
> flow-dependent impacts is necessarily reduced, if not eliminated. ...

i'd agree that the "main reason" that the thing you narrowed earlier 
("differential impact of an operator's own network") is made possible 
only by TCP's path-observability and path-mutability. however, that's 
both a tautology in its own right, and a straw man dismissal of what al 
actually said.

> In other words, the set of wire image features that can cause 
> differential treatment in an operator's network is equal to the set of 
> wire image features that are freely observable by that operator.
see above. there are many reasons a network operator would look at her 
packets in order to diagnose problems not of her making.

-- 
P Vixie

---

From: "MORTON JR., AL" <[email-masked]>
Date: Tue, 22 Mar 2022 19:51:13 +0000

scroll down...
> From: Paul Vixie <[email-masked]>
> Sent: Tuesday, March 22, 2022 12:54 PM
> To: Brian Trammell (IETF) <[email-masked]>
> Cc: MORTON JR., AL <[email-masked]>; [email-masked]; draft-ietf-quic-
> [email-masked]; [email-masked]; [email-masked]; Mirja Kuehlewind
> <[email-masked]>
[acm] 

I think Paul is on the right track with this last sentence. There are several limiting assumptions in this thread about operator activities:

+ mid-path observations are only one of many ways to contribute to network management. Launching QUIC connections from hosts under operator control is another. Successful QUIC analysis seems to require different methods than with TCP, and that's fine.

+ the "operator that wants to support QUIC" case seems to be an unexpected role (so far). It would be useful to embrace this case in the manageability draft, IMO.

Al

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 23 Mar 2022 11:00:34 +0100

Hi Al,

(Snipping a bit of context)

> On 22 Mar 2022, at 20:51, MORTON JR., AL <[email-masked]> wrote:
> 

This is entirely missing; indeed, the document treats active measurement techniques (which I think are quite promising for management of encrypted transports) as implicitly out of scope. I’m not sure it makes sense to expand the scope of this doc (intended as a user’s guide to the wire image) in last call, but perhaps we should add text to make this scope explicit.

> + the "operator that wants to support QUIC" case seems to be an unexpected role (so far). It would be useful to embrace this case in the manageability draft, IMO.

The disconnect in this thread, I think, is related to how large we think the set of useful passive measurement actions requiring access to data not in the wire image is. I think that most of these tasks are things we think are useful with analogy to TCP, because we are *so used* to debugging TCP dynamics that we have unseen biases toward doing things that way. Indeed, I think the actual set tends toward empty, in part due to the (theoretical, perhaps tautological, but not at all meant as a straw man dismissal, apologies as it came off as such) analysis that the wire image you can see to troubleshoot is the same wire image your devices can see to break things. 

It would be interesting to dig into specifics to see how wrong I am. I’m not sure that’s in scope *this* document, though.

Thanks, cheers,

Brian

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 23 Mar 2022 11:17:04 +0100

Hi Paul,

Cutting a bit to try to get this to concrete actions on the document; will follow up on the other points in a subsequent message...

> On 22 Mar 2022, at 17:25, Paul Vixie <[email-masked]> wrote:
> <snip>
> <<Identification of QUIC traffic by on-path actors such as network operators is not reliable. Therefore a heuristic along the lines of "any unrecognizable UDP traffic could be QUIC" is the least unappealing way for a network operator to characterize their network's UDP traffic in the QUIC era.>>

 I don’t think this fits editorially with the rest of the document. However, I do see your point that “not designed to be distinguishable” is maybe not strong enough. I also note that there’s something hiding in the rest of Section 3.1 that we should maybe make more explicit: “this traffic is definitely QUIC” is probabilistically doable, but there are better heuristics on a per-application basis.

How about something like:

<<The QUIC wire image is not specifically designed to be distinguishable from other UDP traffic by a passive observer in the network. While certain QUIC applications may be heuristically identifiable on a per-application basis, there is no general method for distinguishing QUIC traffic from otherwise-unclassifiable UDP traffic on a given link. Any unrecognized UDP traffic may therefore be QUIC traffic.>>

?

Cheers,

Brian

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 23 Mar 2022 11:26:35 +0100

> It would be interesting to dig into specifics to see how wrong I am. I’m not sure that’s in scope *this* document, though.

If it helps: One possible way to deal with could be to describe the 
scope within the QUIC WG for this document, and then note that there are 
other operations-related considerations around the sort of transport 
header confidentiality provided by QUIC and reference RFC 9065 as a list 
of some considerations in this space.

Trying to be helpful,

Gorry

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 23 Mar 2022 11:43:59 +0100

For the record, this is now in https://github.com/quicwg/ops-drafts/pull/463

> On 23 Mar 2022, at 11:17, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Hi Paul,
>

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Wed, 23 Mar 2022 11:44:31 +0100

Explicit scoping is now in https://github.com/quicwg/ops-drafts/pull/464

> On 23 Mar 2022, at 11:00, Brian Trammell (IETF) <[email-masked]> wrote:
> 
> Hi Al,
>

---

From: "MORTON JR., AL" <[email-masked]>
Date: Wed, 23 Mar 2022 20:37:22 +0000

goto end
> From: Gorry Fairhurst <[email-masked]>
> Sent: Wednesday, March 23, 2022 6:27 AM
> To: Brian Trammell (IETF) <[email-masked]>; MORTON JR., AL
> <[email-masked]>
> Cc: [email-masked]; Paul Vixie <[email-masked]>; [email-masked];
> [email-masked]; Mirja Kuehlewind
> <[email-masked]>; [email-masked]
> >> I think Paul is on the right track with this last sentence. There are
> several limiting assumptions in this thread about operator activities:
> >>
> >> + mid-path observations are only one of many ways to contribute to network
> management. Launching QUIC connections from hosts under operator control is
> another. Successful QUIC analysis seems to require different methods than with
> TCP, and that's fine.
> > This is entirely missing; indeed, the document treats active measurement
> techniques (which I think are quite promising for management of encrypted
> transports) as implicitly out of scope. I’m not sure it makes sense to expand
> the scope of this doc (intended as a user’s guide to the wire image) in last
> call, but perhaps we should add text to make this scope explicit.
> >
> >> + the "operator that wants to support QUIC" case seems to be an unexpected
> role (so far). It would be useful to embrace this case in the manageability
> draft, IMO.
> > The disconnect in this thread, I think, is related to how large we think the
> set of useful passive measurement actions requiring access to data not in the
> wire image is. I think that most of these tasks are things we think are useful
> with analogy to TCP, because we are *so used* to debugging TCP dynamics that
> we have unseen biases toward doing things that way. Indeed, I think the actual
> set tends toward empty, in part due to the (theoretical, perhaps tautological,
> but not at all meant as a straw man dismissal, apologies as it came off as
> such) analysis that the wire image you can see to troubleshoot is the same
> wire image your devices can see to break things.
[acm] 
The context of this point is only 10 lines away, but it seems it was quickly overlooked.
The "operator that wants to support QUIC" doesn't want to break things. More below.

> >
> > It would be interesting to dig into specifics to see how wrong I am. I’m not
> sure that’s in scope *this* document, though.
> >
> > Thanks, cheers,
> >
> > Brian
> 

[acm] 
Multiple points here, thanks for continuing the discussion, friends. I'll try to be brief:

+ The scope limit that Brian is proposing PR#464 stops too short IMO, so:
	This document also focuses solely on network management
	practices that interact with traffic on the wire; replacement of
	troubleshooting based on observation with active measurement techniques, for
	example, is therefore out of scope.
ADD something like:
       Augmentation of passive observation using active measurement techniques, and simple 
       heuristics for management with observations at lower layers is for further study.
       <plus cite Gorry and Colin's RFC 9094, section 2.4 at least)  

+ The sentence above the PR#464 proposal:  

	This document therefore does not make any specific
	recommendations as to which practices should or should not be applied; 
	for each practice, it describes what is and is not possible with the 
     QUIC transport protocol as defined.

This might be pointing the way home for the "don't specify policy" objection/discussion.
Brian, you indicated that this text:
    ...purposes of network admission control should not rely on the version number
    field. Instead it is recommended to admit all QUIC traffic regardless...
is only a recommendation.

But the scope says your memo is not making recommendations on practices.
Network admission control is enforcement of policy. 

But it sounds like a version number is one of the few wire image features that the protocol designers deliberately revealed,  so when Section 4 of RFC 8558 recommends: 

   o  Anything exposed to the path should be done with the intent that
      it be used by the network elements on the path. ...

So, w.r.t. the wire image, the set of features that might support management "tends toward empty" but it's not zero and what's exposed might well be used by observers.

Al

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 24 Mar 2022 01:01:39 +0100

Hi,

Responses in line (from a chair that's been quietly observing)

>        <plus cite Gorry and Colin's RFC 9094, section 2.4 at least)

RFC 9094 seems like a typo, unless there's something about QUIC and
switched optical networks I don't know
:-)

Regardless, speculating how people might choose to combine information
about QUIC and other stuff doesn't strike me as super useful. We should
just accept that it is given that the Internet and its management evolves.
People can try to evolve that how they want given the things we do take the
time to define.

> But it sounds like a version number is one of the few wire image features
> that the protocol designers deliberately revealed,  so when Section 4 of
> RFC 8558 recommends:
>
> So, w.r.t. the wire image, the set of features that might support
> management "tends toward empty" but it's not zero and what's exposed might
> well be used by observers.
>

To my knowledge, nether QUIC v1 or the invariants (RFC 9000 and 8999
respectively) reference RFC 8558. So I would be very careful in inferring
the what and how about the intention of the visible portions. The version
is only carried in QUIC long packets and there are reasons for doing so
that benefit QUIC. RFC 8999 goes so far as saying about the version field "
This value can be used by endpoints to identify a QUIC version".

The space of definable versions is vast, and the possible behaviours
between endpoints are large. Throw in also QUIC extensions that are not
exposed in the wire image. These combine to limitless possibilities.
Attempting predictions of behaviour based on version in a small part of the
QUIC connection lifetime nets out as an insurmountable activity. What would
observers hope to achieve? Use of version for any management is a game of
whack-a-mole.

Cheers
Lucas

---

From: "Brian Trammell (IETF)" <[email-masked]>
Date: Thu, 24 Mar 2022 16:33:05 +0100

Hi Al,

Top-posting a summary: I think these are all interesting questions, I think we as a community should continue working to answer them. I’m still not sure they’re all in scope for this document. Some details inline…

> On 23 Mar 2022, at 21:37, MORTON JR., AL <[email-masked]> wrote:
> 

I think we’re talking past each other here, which makes me sad.

I’m not saying the that the "operator that wants to support QUIC” wants to break things. 

I’m saying that the properties of QUIC’s wire image make fixing things through passive measurement oriented troubleshooting less necessary, because the wire image itself has less surface for *unintentional* breakage.

> <plus cite Gorry and Colin's RFC 9094, section 2.4 at least) 

I agree with this point wholeheartedly… 

I’m not sure where the line on the scope of the document is if we add this, though — because then it would be reasonable to say we should point out all other areas for further work.

> So, w.r.t. the wire image, the set of features that might support management "tends toward empty" but it's not zero and what's exposed might well be used by observers.

So that’s a very interesting question… IMO the exposure of the version number is an evolutionarily-conserved feature predating the publication of that advice in 8558, as our understanding of the properties of wire images as a community has evolved with our experience designing and deploying QUIC. Maybe the WG should have made different choices, but for now I think the advice in the document stands…

Thanks, cheers,

Brian

---

From: "MORTON JR., AL" <[email-masked]>
Date: Fri, 25 Mar 2022 15:23:47 +0000

Hi Lucas, response below.

From: Lucas Pardue <[email-masked]>
Sent: Wednesday, March 23, 2022 8:02 PM
To: MORTON JR., AL <[email-masked]>
Cc: Gorry Fairhurst <[email-masked]>; Brian Trammell (IETF) <[email-masked]>; [email-masked]; Paul Vixie <[email-masked]>; [email-masked]; [email-masked]; Mirja Kuehlewind <[email-masked]>; QUIC WG <[email-masked]>
Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14

Hi,

Responses in line (from a chair that's been quietly observing)
On Wed, 23 Mar 2022, 21:38 MORTON JR., AL, <[email-masked]<mailto:[email-masked]>> wrote:
goto end
> From: Gorry Fairhurst <[email-masked]<mailto:[email-masked]>>
> To: Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>>; MORTON JR., AL
> <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; Paul Vixie <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; Mirja Kuehlewind
> <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> >> On 22 Mar 2022, at 20:51, MORTON JR., AL <[email-masked]<mailto:[email-masked]>> wrote:
> >>
[acm]

[acm]

RFC 9094 seems like a typo, unless there's something about QUIC and switched optical networks I don't know
:-)

Regardless, speculating how people might choose to combine information about QUIC and other stuff doesn't strike me as super useful. We should just accept that it is given that the Internet and its management evolves. People can try to evolve that how they want given the things we do take the time to define.

To my knowledge, nether QUIC v1 or the invariants (RFC 9000 and 8999 respectively) reference RFC 8558. So I would be very careful in inferring the what and how about the intention of the visible portions. The version is only carried in QUIC long packets and there are reasons for doing so that benefit QUIC. RFC 8999 goes so far as saying about the version field " This value can be used by endpoints to identify a QUIC version".

The space of definable versions is vast, and the possible behaviours between endpoints are large. Throw in also QUIC extensions that are not exposed in the wire image. These combine to limitless possibilities. Attempting predictions of behaviour based on version in a small part of the QUIC connection lifetime nets out as an insurmountable activity. What would observers hope to achieve? Use of version for any management is a game of whack-a-mole.

Cheers
Lucas
[acm]
Given the case "operator that wants to support QUIC" we are discussing,
Whack-a-Mole is the worst-analogy-ever.

"don't specify policy" is a separate but overlapping issue.
Admission control is enforcement of policy. Don’t try to specify operator policy. Re-word the (wg consensus) statement concerning version numbers.

The memo (scope) stops way-short of describing active management activities that have potential benefit, given the many intentional difficulties with passive observation that are present (with due respect to the management possibilities discussed in sections 3 and 4 of the memo). It would be good to summarize only the productive (passive) observations in a table or list for the intended audience.
The case "operator that wants to support QUIC" seems to have been under-represented during development (and it needs frequent reminders in this discussion).
And that’s one reason IETF has OPS-DIR Reviews.

Al

---

From: Lucas Pardue <[email-masked]>
Date: Fri, 25 Mar 2022 16:59:08 +0100

Hey Al,

Response in line

On Fri, 25 Mar 2022, 16:26 MORTON JR., AL, <[email-masked]> wrote:

> *From:* Lucas Pardue <[email-masked]>
> *Sent:* Wednesday, March 23, 2022 8:02 PM
> *To:* MORTON JR., AL <[email-masked]>
> *Cc:* Gorry Fairhurst <[email-masked]>; Brian Trammell (IETF) <
> [email-masked]>; [email-masked]; Paul Vixie <[email-masked]>;
> [email-masked]; [email-masked]; Mirja
> Kuehlewind <[email-masked]>; QUIC WG <[email-masked]>
> *Subject:* Re: Opsdir last call review of draft-ietf-quic-manageability-14
>
>
>
> Hi,
>
>
>
> *[acm] *

QUIC is for endpoints, so I don't really know what a operator that wants to
support QUIC is supposed to do other than allow that traffic or try to an
endpoint.

For non-QUIC endpoints, conflating QUIC version fields with the behaviour
of the QUIC protocol and/the QUIC connection flows is bad. There are too
many variables, beyond the version, and within the encryption layer, that
affect behavior. Under this context I'd stand by the analogy.

> Admission control is enforcement of policy. Don’t try to specify operator
> policy. Re-word the (wg consensus) statement concerning version numbers.
>

In that case, all I can suggest is to say fewer words. For exakple,
converting the last para in section 2.8 to say only

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. Similarly, it is not recommended
to use the version to distinguish QUIC traffic from non-QUIC traffic.
Applying these suggestions could, for example, allow all QUIC traffic
regardless of version, which in turn would support continious version-based
evolution and avoid unnecessary delays for endpoints that wish to deploy
new versions.

But I'm not sure if that actually addresses your point.

>
>
> The memo (scope) stops way-short of describing active management
> activities that have potential benefit, given the many intentional
> difficulties with passive observation that are present (with due respect to
> the management possibilities discussed in sections 3 and 4 of the memo). It
> would be good to summarize only the productive (passive) observations in a
> table or list for the intended audience.
>
> The case "operator that wants to support QUIC" seems to have been
> under-represented during development (and it needs frequent reminders in
> this discussion).
>

We appreciate your review and feedback specially, and the wider IETF
reviews in general. Thanks.

Cheers
Lucas

---

From: "MORTON JR., AL" <[email-masked]>
Date: Mon, 28 Mar 2022 14:46:07 +0000

Hi Lucas,
There seems to be a persistent indent at the points where I replied, so look for acm2.
Al

Sent: Friday, March 25, 2022 11:59 AM

Hey Al,

Response in line

On Fri, 25 Mar 2022, 16:26 MORTON JR., AL, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Lucas, response below.

From: Lucas Pardue <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 23, 2022 8:02 PM
To: MORTON JR., AL <[email-masked]<mailto:[email-masked]>>
Cc: Gorry Fairhurst <[email-masked]<mailto:[email-masked]>>; Brian Trammell (IETF) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Paul Vixie <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Mirja Kuehlewind <[email-masked]<mailto:[email-masked]>>; QUIC WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14

Hi,

[acm]

[acm]

Cheers
Lucas
[acm]

QUIC is for endpoints, so I don't really know what a operator that wants to support QUIC is supposed to do other than allow that traffic or try to an endpoint.
[acm2]
Try to *operate* an endpoint? Yes, exactly. If the operator sees the same symptoms as a user reported, then the trouble-shooting continue on that basis. This is virtually always the simplest first step: can we reproduce the issue? It’s easier than packet trace analysis.

For non-QUIC endpoints, conflating QUIC version fields with the behaviour of the QUIC protocol and/the QUIC connection flows is bad. There are too many variables, beyond the version, and within the encryption layer, that affect behavior. Under this context I'd stand by the analogy.
[acm2]
Sure, but the version field with a published specification might narrow the possibilities.

In the "operator that wants to support QUIC", no one holds a hammer and no one gets whacked.

But if you insist on this analogy, know that I lived on the New Jersey Shore for 65 years and spent a lot of time in arcades. I have friends and family who are absolute savants at Whack-a-Mole.

In that case, all I can suggest is to say fewer words. For exakple, converting the last para in section 2.8 to say only

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. Similarly, it is not recommended to use the version to distinguish QUIC traffic from non-QUIC traffic. Applying these suggestions could, for example, allow all QUIC traffic regardless of version, which in turn would support continious version-based evolution and avoid unnecessary delays for endpoints that wish to deploy new versions.

But I'm not sure if that actually addresses your point.
[acm2]
That’s mostly fine: the sentences with the phrase “not recommended” don’t follow (in IMO) the part of the scope that says:

and these could be re-worded as statements of fact/future direction.

We appreciate your review and feedback specially, and the wider IETF reviews in general. Thanks.

Cheers
Lucas