Re: [Last-Call] [OPS-DIR] Opsdir last call review of draft-ietf-quic-manageability-14

[Warren Kumari <[e-mail]>]

Hi Brian, Al, Mirja, et al,

Just a quick note to say thank you to all for this conversation and working
towards some sort of consensus.

I personally think that the PRs that Brian has created are helpful, and are
looking good. There is a definite, and ongoing tension between the
operators' need to see into the traffic for management/filtering/malware
protection/etc;  and the users' needs for privacy - this tension makes
these sorts of discussions somewhat fraught, and I'd like to thank everyone
again for trying to see each other's viewpoints, and work towards text / a
solution that we can all live with.

While this compromise might not be perfect, is it good enough that we can
all live with it?
W


On Tue, Apr 05, 2022 at 7:04 AM, Brian Trammell <[e-mail]> wrote:

> Hi Al, Lucas, all,
>
> I think I’ve distilled down this thread into two PRs: https://github.com/
> quicwg/ops-drafts/pull/466 on “recommendation” language generally, and
> https://github.com/quicwg/ops-drafts/pull/467 rephrasing recommendations
> not to switch on version into an analysis of the tradeoffs (thanks Lucas
> for your help with these!). Please have a look and let me know whether
> those resolve this discussion.
>
> Thanks, cheers,
>
> Brian
>
> On 28 Mar 2022, at 16:46, MORTON JR., AL <[e-mail]> wrote:
>
> Hi Lucas,
> There seems to be a persistent indent at the points where I replied, so
> look for acm2.
> Al
>
> *From:* Lucas Pardue <[e-mail]>
> *Sent:* Friday, March 25, 2022 11:59 AM
> *To:* MORTON JR., AL <[e-mail]>
> *Cc:* Gorry Fairhurst <[e-mail]>uk>; Brian Trammell (IETF) <ietf@
> trammell.ch>; [e-mail]; Paul Vixie <[e-mail]>rg>; last-call@
> ietf.org; [e-mail]; Mirja Kuehlewind <
> [e-mail]>gt;; QUIC WG <[e-mail]>
> *Subject:* Re: Opsdir last call review of draft-ietf-quic-manageability-14
>
> Hey Al,
>
> Response in line
>
>
> On Fri, 25 Mar 2022, 16:26 MORTON JR., AL, <[e-mail]> wrote:
>
> Hi Lucas, response below.
>
> *From:* Lucas Pardue <[e-mail]>
> *Sent:* Wednesday, March 23, 2022 8:02 PM
> *To:* MORTON JR., AL <[e-mail]>
> *Cc:* Gorry Fairhurst <[e-mail]>uk>; Brian Trammell (IETF) <ietf@
> trammell.ch>; [e-mail]; Paul Vixie <[e-mail]>rg>; last-call@
> ietf.org; [e-mail]; Mirja Kuehlewind <
> [e-mail]>gt;; QUIC WG <[e-mail]>
> *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, <[e-mail]> wrote:
>
> goto end
> > -----Original Message-----
> > From: Gorry Fairhurst <[e-mail]>
> > Sent: Wednesday, March 23, 2022 6:27 AM
> > To: Brian Trammell (IETF) <[e-mail]>ch>; MORTON JR., AL
> > <[e-mail]>
> > Cc: [e-mail]; Paul Vixie <[e-mail]>rg>; [e-mail];
> > [e-mail]; Mirja Kuehlewind
> > <[e-mail]>om>; [e-mail]
> > Subject: Re: Opsdir last call review of draft-ietf-quic-manageability-14
> >
> > On 23/03/2022 11:00, Brian Trammell (IETF) wrote:
> > > Hi Al,
> > >
> > > (Snipping a bit of context)
> > >
> > >> On 22 Mar 2022, at 20:51, MORTON JR., AL <[e-mail]> wrote:
> > >>
> > >>>> 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
> > >> [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.
> > > 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
> >
> > 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
> >
>
> [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)
>
>
> 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.
>
>
>
> + 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.
>
>
> 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.
>
>
> 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.
>
>
> "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.
>
>
> 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:
>
>         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.
>
> and these could be re-worded as statements of fact/future direction.
>
>
> 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.
>
>
> We appreciate your review and feedback specially, and the wider IETF
> reviews in general. Thanks.
>
> Cheers
> Lucas
>
>
> _______________________________________________
> OPS-DIR mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ops-dir
>