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

Eliot Lear <lear@cisco.com> Tue, 18 June 2019 11:03 UTC

Return-Path: <lear@cisco.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEB6120146; Tue, 18 Jun 2019 04:03:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74Bu0pUXDsFq; Tue, 18 Jun 2019 04:03:31 -0700 (PDT)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0F0212013C; Tue, 18 Jun 2019 04:03:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5908; q=dns/txt; s=iport; t=1560855811; x=1562065411; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=3IXr5X/lN4yXEZBSxS20UXd8Hw0OafX9FrD+REe1h3A=; b=TefpAbNAbKBhFmLXshYvx9onKcg3inFoWs8lA+4s4xnbURMNHDKZQzbl 61/K5mtvJcsf0kbGeT020hYGxGrFHeQsgt1zLkakhJDESVjNRQDMjE82x 6BCN/KMifblinafEDWeZftQZG/uVDwcGEyyBqBlOr9A97KUf1sfV1kOBT k=;
X-Files: signature.asc : 195
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAAC7wwhd/xbLJq1hBRoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVQCAQEBAQsBAYFlKmpRASASKIQWiHuLZSWYeIFnAgcBAQE?= =?us-ascii?q?JAwEBGxQBAYRAAoJzNwYOAQMBAQQBAQIBBG0cDEIBEAGEdgEBAQECAQ4VQgI?= =?us-ascii?q?GAwkFCwsOCioCAlcGExsBgwYBgXsPqSyBMYVHhFcKBoE0AYFQiG+BAAE0gX8?= =?us-ascii?q?maycME4FOfj6EEQESARODFjKCJgSLUhkKiDSUTWoJghKCG4EHgyaIUYQ6G4I?= =?us-ascii?q?nL4ZXhAqJfYxUh22MO4MIAgQGBQIVgWYiZ3EzGggbFWUBgkE+gnYBAgeHVYV?= =?us-ascii?q?BPQMwiBOFFA0XB4IlAQE?=
X-IronPort-AV: E=Sophos;i="5.63,388,1557187200"; d="asc'?scan'208";a="13237233"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Jun 2019 11:03:28 +0000
Received: from dhcp-10-61-102-117.cisco.com (dhcp-10-61-102-117.cisco.com [10.61.102.117]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5IB3R8L015533 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Jun 2019 11:03:28 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <001CAE89-4DD9-4149-8D51-4CA74E05DD27@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_F01723FC-DD77-490D-A6B5-A643D6C453EE"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 18 Jun 2019 13:03:26 +0200
In-Reply-To: <98A10145-5020-4CCA-ABEB-72411A03A3B2@csperkins.org>
Cc: Thomas Fossati <Thomas.Fossati@arm.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>, "draft-ietf-tsvwg-transport-encrypt@ietf.org" <draft-ietf-tsvwg-transport-encrypt@ietf.org>
To: Colin Perkins <csp@csperkins.org>
References: <E0BAA0EC-4D2D-4578-A2A1-45B3DA831911@arm.com> <98A10145-5020-4CCA-ABEB-72411A03A3B2@csperkins.org>
X-Mailer: Apple Mail (2.3445.104.11)
X-Outbound-SMTP-Client: 10.61.102.117, dhcp-10-61-102-117.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/XRdihrs8wYKKJurEWsUkakbhrso>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-06
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Jun 2019 11:03:35 -0000

+1.  Of course pointers to real world ML solutions (and other solutions as well) should be included.  I like the draft.  Very well written.

Eliot

> On 18 Jun 2019, at 12:46, Colin Perkins <csp@csperkins.org>; wrote:
> 
> Hi Thomas,
> 
> Thanks for your feedback.
> 
> I agree with your comments on the introductory sections; there’s certainly scope to tighten up that text.
> 
> As for the rest, I don’t disagree that machine learning will be important, but I’m not the right person to write about it. I’m also not clear where such material would fit in the document. It might be better to have a separate document, that this can maybe refer to, that starts to discuss solutions to the issues identified.
> 
> Cheers,
> Colin
> 
> 
>> On 17 Jun 2019, at 16:53, Thomas Fossati <Thomas.Fossati@arm.com>; 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.
>> 
>> 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.
> 
> 
> 
> --
> Colin Perkins
> https://csperkins.org/
> 
> 
> 
>