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

[Christian Huitema <[e-mail]>]

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