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

[Tom Herbert <[e-mail]>]

On Mon, Jun 17, 2019 at 8:54 AM Thomas Fossati <[e-mail]>
wrote:

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

Thomas,

ML requires massive amounts of data to be most effect effective, but strong
security mandates that we only expose the minimal amount of data we need
to. So this is the tussle. If someone were to say we need uniform metrics
exposed in transport protocols in the Internet, then the first question to
be asked is "what information about transport protocols is _required_ to be
exposed to the network?" Architecturally and from a position of security,
the answer to this question in the Internet is none. A better question to
ask might be what information would be useful and optional to expose and
how can we limit the exposure to only trusted parties (for instance, I
might trust my local network more than I trust the Internet, so I may be
willing to expose data to the local network if there are sufficient
mechanisms to scope it). That implies the need for a mechanism whereby
hosts can signal the network with ancilary scoped information attached to
packets. IMO the mechanism for this should be Hop-by-Hop options.

Tom



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