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

"Scharf, Michael" <> Sun, 13 October 2019 05:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 443701200CC for <>; Sat, 12 Oct 2019 22:58:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o_quDKqlm55R for <>; Sat, 12 Oct 2019 22:58:53 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02551120025 for <>; Sat, 12 Oct 2019 22:58:52 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 190A825A13; Sun, 13 Oct 2019 07:58:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1570946331; bh=ofugNl11UaLeCZ1YnoWYFuK+uiWQJELWvBEEDBd/EIY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=F9jfkh7UE5eN4kRL397ggHm4k3+W/Q0F5qwllLdWgdnVrks2simF+UBJRz27csVN5 QMjTkGdq6WQdMQIzdA4ms5790g/rKsgTAVdcGt9rkJlQCMs9NAEWB6Rq5nqvfuViEe LQZbpyiiRMf+Fp/1wDaKZblzdNqL7BZYY4JnyJFQ=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zuB9hIS-hAmy; Sun, 13 Oct 2019 07:58:49 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Sun, 13 Oct 2019 07:58:49 +0200 (CEST)
Received: from ([]) by ([fe80::bd73:d6a9:24d7:95f1%10]) with mapi id 14.03.0468.000; Sun, 13 Oct 2019 07:58:49 +0200
From: "Scharf, Michael" <>
To: "" <>, Christian Huitema <>
CC: "" <>
Thread-Topic: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging
Thread-Index: AQHVgNGSDIfjAjkL+kK7oTbHLS/7PKdYFOwZ
Date: Sun, 13 Oct 2019 05:58:48 +0000
Message-ID: <>
References: <> <>, <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
Content-Type: multipart/alternative; boundary="_000_6EC6417807D9754DA64F3087E2E2E03E2D499E66rznt8114rzntrzd_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 13 Oct 2019 05:58:56 -0000

+ Students

I guess many generations of young engineers and future software developers have learnt TCP/IP by looking at the IP and TCP headers in PCAP files. Apparently, it has worked to some extend in the last 35 years or so… Of course, there are alternatives in teaching transport protocols to those who are not on IETF e-mail list (so far). But do we really know whether it will work well?

Anyway, Gorry and others on the list may understand that „use case“ much better than me ;-) So I’ll better shut up.


Von: Gorry Fairhurst<>
Gesendet: Samstag, 12. Oktober 2019 09:49
An: Christian Huitema<>
Betreff: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging

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);
* a protocol developer (e.g.,  debugging transport interactions end to end);
* a service provider (e.g., trying to understand performance impairments
in the network);
* researchers/equipment developers seeking to correlate/tune transport
timing with network policies (e.g., interactions between congestion
control and link scheduling);
* exploring traffic archives (e.g., trends in what is supported or
determine when an anomoly appeared).

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)?


On 09/10/2019, 15:32, Christian Huitema wrote:
> As the draft mentions:
>     The use of transport layer authentication and encryption exposes a
>     tussle between middlebox vendors, operators, applications developers
>     and users
> Much of the draft reads like a lamentation of the horrible
> consequences of encrypting transport headers, which looks very much
> like embracing the point of view of the middlebox vendors. Expressing
> that point of view is of course fine, and it might be enough to change
> the title, abstract and introduction to reflect that this is an
> opinion piece. But as a transport working group document I would like
> something a bit more balanced. It should spend more time acknowledging
> the ossification and privacy issues. It should ideally lay the ground
> work for alternative management solutions, such as controlled exposure
> like the spin bit in QUIC, IP header information, or standardized logs
> like the QLOG effort.
> -- Christian Huitema
> On 10/8/2019 2:08 PM, Black, David wrote:
>> FYI – some OPS area and SEC area eyes on this TSVWG draft now (during
>> WGLC) would be a good thing ;-).
>> Thanks, --David (TSVWG co-chair)
>> *From:* Black, David <>
>> *Sent:* Tuesday, October 8, 2019 5:06 PM
>> *To:*
>> *Cc:* Black, David
>> *Subject:* WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23
>> October 2019
>> This email announces a TSVWG Working Group Last Call (WGLC) on:
>> The Impact of Transport Header Confidentiality on Network Operation and
>>                        Evolution of the Internet
>>                  draft-ietf-tsvwg-transport-encrypt-08
>> This draft is intended to become an Informational RFC.
>> This WGLC will run through the end of the day on Wednesday, October 23.
>> That should allow time before the Singapore draft submission cutoff for
>> the authors to revise the draft with any changes that result from WGLC.
>> Comments should be sent to the <>
>> list, although purely
>> editorial comments may be sent directly to the authors. Please cc: the
>> WG chairs at <>  if
>> you would like the chairs to
>> track such editorial comments as part of the WGLC process.
>> No IPR disclosures have been submitted directly on this draft.
>> Thanks,
>> David, Gorry and Wes
>> (TSVWG Co-Chairs)
>> _______________________________________________
>> saag mailing list