Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging

Christian Huitema <huitema@huitema.net> Sun, 13 October 2019 21:17 UTC

Return-Path: <huitema@huitema.net>
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 10EF0120047 for <tsvwg@ietfa.amsl.com>; Sun, 13 Oct 2019 14:17:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 EVUj-NGNxdlW for <tsvwg@ietfa.amsl.com>; Sun, 13 Oct 2019 14:17:16 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263A0120019 for <tsvwg@ietf.org>; Sun, 13 Oct 2019 14:17:16 -0700 (PDT)
Received: from xse166.mail2web.com ([66.113.196.166] helo=xse.mail2web.com) by mx114.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1iJlEo-000k4Y-Rl for tsvwg@ietf.org; Sun, 13 Oct 2019 23:17:16 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 46rvdp0gFpzDSx for <tsvwg@ietf.org>; Sun, 13 Oct 2019 14:17:02 -0700 (PDT)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1iJlEb-000547-VU for tsvwg@ietf.org; Sun, 13 Oct 2019 14:17:01 -0700
Received: (qmail 25479 invoked from network); 13 Oct 2019 21:17:01 -0000
Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.46.167]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <tsvwg@ietf.org>; 13 Oct 2019 21:17:00 -0000
To: gorry@erg.abdn.ac.uk
Cc: "Black, David" <David.Black@dell.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <CE03DB3D7B45C245BCA0D2432779493630766752@MX307CL04.corp.emc.com> <e8c30f3f-606f-0c0d-a7dd-b2bb6f31a9fd@huitema.net> <5DA18567.9060400@erg.abdn.ac.uk>
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <961598c0-252d-7a85-baa1-7e2033a4b823@huitema.net>
Date: Sun, 13 Oct 2019 14:17:00 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2
MIME-Version: 1.0
In-Reply-To: <5DA18567.9060400@erg.abdn.ac.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.166
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.166/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.166/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ezqdolHG91LK5q2HN6uCHCpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDAxcDYLQWPWOwvKJpm+ErX5j9 EvBvwu01uVCaGVBWGqtJlgFSGevKvE69SUmJcvCL2rBNMmEsKEibQwSU1xBeOHButNDpi1WUXRkr He1vFsZaZad0VL/QynhFAlbT36L8gakDNOEjZtTrJySrajRbqAZ6weYgSzquK2hxskqXvy8woCTx LKweTbuJ+19zsyHVGVmhMAaQ/AfCRwRe7yHm5oY+NYmsSGn+svMubxnbgm1cr18FZBEPC2/c16Xd 7sC9aC4xteE1WLqGS9YoqrsZ2DyteN0e+ECCv9/f+GPymkgDVo7QBKA4MctKq4ifYPcXFRL2K3LA EfDXVOdt7wDbuhdxf5Dwg9wMBX5ckCo48ayVGvgdM/14NhEhsQ0jllqEE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilUN7TTX3qb0a 8RNcOLCOSd5csd6/DQyP1F2MXqSxFa+Q6mXkhvlDxqr+flmMCynNStH3dcxmjCSM6oL17DyvFvgM 7OYFXYdC3tRq275m/U3VQ1606WXtQXOLrUGCMN/gaLdCp3Zd9clP8wSiJZWbJCj+xRrjVmRxpGtS cvUmgj1LqatFdsHcL0CIBrLcbiUTc12jZAOanSBpz6Rja2u/0jLtx16qELpAkS/6k9NSHMnDTZYh Llri23ia6HDqcuNUS/ysta6u1iHEyuS7GD1uvcpx1QaNwk4M7XGgz09h3YYsJOYIJd4MvQ0Nf4Ec bvHO1diDanHV9KirFAIIecsyj+YNTo81GR+jDXFsz/ZQnbbTizvwlZsrbltGiZoUh+c+5pFVgpT1 b21uZVckGp0ccOa2XhkGbmsUNPNkere1WheNsVXmhO8BzADiszcWR9bz/SDtF09JpSbuuCeiIDK0 C/0=
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/jcGZjZMKeaVI-eRxDX35vspMcV4>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging
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: Sun, 13 Oct 2019 21:17:19 -0000

Thanks, Gorry. First, let me say that I appreciate your approach to not
start a debate about whether encryption is good or bad, but rather to
assume that encryption is deployed, and then study how we perform a set
of functions.

On 10/12/2019 12:48 AM, Gorry Fairhurst wrote:
> I'm intrigued by how far we can understand opportunities for open
> client logs to replace pcap dumps, and would like to delve a little
> deeper into what we understand - there seem many possible actors and
> that may be interesting to look at a few viewpoints:
>
> * a user of a transport protocol (e.g., understanding cost/benefit of
> feature choices);

I don't understand this specific use case very well. Do you mean an
application developer, or an end user? If you do mean an application
developer, then the features will be selected by using options exposed
by the API of a protocol implementation. I assume that the
implementations have a logging option, ideally providing a standard
logging format like Qlog. This is somewhat similar to the protocol
developer problem listed below.

> * a protocol developer (e.g.,  debugging transport interactions end to
> end);

We do have a fair bit of experience handling that issue during the
development of QUIC. At the very beginning, each implementation had its
own logging format. During tests, we would turn on logging at both the
client and the server, study the traces, and rapidly find the causes of
the interoperability problems -- and potentially add additional logging
options to the code if we could not find the issue.

As we progressed, the tests became more complex, looking for example at
debugging issues in error recovery and congestion control. We saw the
development of two tools:

1) Plugins for Wireshark, and an API between the plugin and protocol
stacks. The API provides the plug-in with the decryption key, so
Wireshark traces can include complete traces of the protocol.

2) Standardized log formats such as Qlog, and then a set of tools for
visualizing this traces and obtain graphs similar to those common with TCP.

The QUIC interop tests involve 20 different implementations, so I would
say that developers have been quite successful using these tools.

I assume that the "student" use case mentioned later in the thread is
very similar to the developer use case.

> * a service provider (e.g., trying to understand performance
> impairments in the network);

I think we need to split that scenario in two: debugging following a
customer complaint, and general network monitoring.

For the client case, the solution would be to gather logs on the
client's machine. For example, using Chrome, turn on the Quic logging
options and then send these logs to the support center. This supposes
that the applications used by the client do have an option to turn on
logging, similar to what Chrome does. Calling for that support in the
draft could be useful!

For general network monitoring, tools like Netflow will provide
statistics at the 5-tuple granularity. We have seen work reported in the
Quic WG about using the spin bit to monitor end to end delays in that
scenario. Then there are of course tools developed in the IPPM working
group, such as OWAMP and TWAMP. If I understand correctly these tools
enable measurements between test points without requiring observation of
transport headers in transit.

> * researchers/equipment developers seeking to correlate/tune transport
> timing with network policies (e.g., interactions between congestion
> control and link scheduling);

This seems quite similar to the protocol developer problem.

> * exploring traffic archives (e.g., trends in what is supported or
> determine when an anomoly appeared).

Some traffic properties are observable on the encrypted flow. Timing of
connection establishment, duration of sessions,  or volume of data are
obvious to measure. The spin bit can also be observed. Fingerprinting
techniques can be used to identify application profiles. It should even
be possible to assess application timing. That's probably enough to
detect macroscopic changes and flag anomalies.

Of course, you will not see which specific features the encrypted
transport deploys, not by simply taking traffic traces. But those
features can probably be obtained by other means, such as instrumenting
servers.

>
> I've taken all of these viewpoints at some time using pcap to look at
> TCP.
>
> Clearly when we use QUIC, there can be alternatives and there is now
> some experience with client (and server) logs, what do you think we
> can usefully say in addition to or instead of what the draft says
> about logging (currently mentioned only briefly in section 6.1) ?
>
> The text on spin-bit could indeed be developed a little (the present
> text predates the spin bit being incorporated as an optional part of
> the base spec). What do you think should be said (currently at the end
> of 6.4)? 

I would need to write a detailed review of your draft. That will take
some time...

-- Christian Huitema