[tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-06

[Thomas Fossati <[e-mail]>]

Hi Gorry, Colin,

I have read your fine draft and gathered a few comments for your
consideration.

I think the intro material (Sections 1 and 2) could be slimmed down
substantially:
- There's a bit of repetition (sometimes literally, e.g.: 2nd and 3rd
  para of the intro section carry the same exact information);
- Content-wise, with regards to setting the context, there seems to be
  good overlap with a few already published RFCs - for example both
  Path signals [RFC8558] and Wire image [RFC8546] could be used to
  factor out a bunch of text here?  Just a suggestion.

The rest is really good material with the right balance of breadth and
depth (IMHO).

However, one of the raison d'etre of the document, as I interpret it, is
to describe which tools & techniques are available to network operators
that can survive transports that mux and prioritise inside an encrypted
envelope.

And while the document does a very good job identifying what *doesn't*
work anymore, the "every time a transport field is encrypted, a passive
measurement tool gets his wings" story, while factually accurate, only
tells one half of the tale.

In that respect, I think the draft should also consider any emerging
techniques & tools.  In particular, ML solutions (especially RNN and
reinforcement learning architectures) look like one very plausible way
this is going to evolve.

Which is not to say these methods are in all cases mature enough for
production.  On the contrary, I think currently very few of them would
be ready for prime time.  But this is one line of work that has shown,
in published research at least, encouraging levels of precision &
accuracy (even with encrypted traffic), while dealing with all the
typical scenarios a network operator faces.  (I've seen ML applied to
fault detection and localisation, QoE/QoS measurements in both real-time
comms and adaptive video, anomalies / misuse / intrusion detection, the
whole lot.)

The thing is that if ML or like approaches are not good enough or not
mature enough, the risk that MiTM and forced fall-back to TCP become a
practical and effective tool in the hands of network operators increases
substantially, which would be pretty unfortunate.  (And yes, we could
have handled the transition more graciously, cf. SPUD/PLUS, but we
decided not to, so here we are.)  In this respect, I think it's critical
to create a shared understanding of what the challenges are and what
concrete actions can be taken to accelerate / incentivise the
development and adoption of ML in this venerable field.  To this end,
it'd be great if the document provided (even succinctly) a critical look
on ML that highlights the potential and actual successes, its
limitations (both in general, and specifically WRT encrypted transports)
as well as the current gaps.

For example, one thing that becomes quickly apparent once you start
surveying the existing literature is that comparing different
ML-for-network-traffic experiments is quite problematic.  The lack of
uniform evaluation metrics as well as standardised labelled datasets
(which is only aggravated by ML's sensitivity on training and validation
data) looks like a gap that urgently needs filling and one where the
IETF is ideally placed to help reducing the observed fragmentation.

OK, I'll stop here - I wanted this to be short and snappy but I got
carried away somehow.  Hopefully my points are still visible above the
noise line.

Thanks again for the great job gathering 20+ years of collective
knowledge and experience.

Cheers, t

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.