Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

<Ruediger.Geib@telekom.de> Wed, 20 February 2019 16:07 UTC

Return-Path: <Ruediger.Geib@telekom.de>
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 930AD130E63 for <tsvwg@ietfa.amsl.com>; Wed, 20 Feb 2019 08:07:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de
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 fC-Lh6e0l_HR for <tsvwg@ietfa.amsl.com>; Wed, 20 Feb 2019 08:07:19 -0800 (PST)
Received: from mailout21.telekom.de (MAILOUT21.telekom.de [194.25.225.215]) (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 A5123130E57 for <tsvwg@ietf.org>; Wed, 20 Feb 2019 08:07:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1550678838; x=1582214838; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=+T+N5e/VKLH3CfbMMjPYTLHJ1U6VoXFbdIJcKyJhd7U=; b=dx1waSWassAc5iLnLrOHL3D0meLwvVRUnneVbOyfa624rGuTrfQuIev1 hgTWcPSytU9E4i1F1XXVgBW9+AgBDeoZXnA4KUyocsbm0ygstDT0iq0yl w7Q58S5VIGRqmm2QxNlAj06CBnr0Cg9tK4V5mhvB45Mhe9nCF4tHpzBc/ OIv8wsM5yL34+Ae53nNme79/8CLIijHHIfevLwDZr9oCP7ohj+At935ks ruHxnWDbow3FN7o6Tip+zB3k6U2EdxjtHeRZllry3ned4n3Ex6m+1IL3e zbIwtAqNSE0hYVZ7VFhdJC8nVD/kqHuBl0pIj0qnqHEvEs2IwYlEnV+jN Q==;
Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2019 17:07:16 +0100
X-IronPort-AV: E=Sophos;i="5.58,391,1544482800"; d="scan'208";a="230643796"
Received: from he101951.emea1.cds.t-internal.com ([10.169.118.77]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/AES256-SHA; 20 Feb 2019 17:07:15 +0100
Received: from HE106162.EMEA1.cds.t-internal.com (10.169.118.73) by HE101951.emea1.cds.t-internal.com (10.169.118.77) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Feb 2019 17:07:15 +0100
Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE106162.EMEA1.cds.t-internal.com (10.169.118.73) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 20 Feb 2019 17:07:15 +0100
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.16) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 20 Feb 2019 17:07:10 +0100
Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.153) by LEJPR01MB0458.DEUPRD01.PROD.OUTLOOK.DE (10.158.142.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1622.19; Wed, 20 Feb 2019 16:07:14 +0000
Received: from LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::849c:7800:cb78:e940]) by LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE ([fe80::849c:7800:cb78:e940%5]) with mapi id 15.20.1622.020; Wed, 20 Feb 2019 16:07:14 +0000
From: <Ruediger.Geib@telekom.de>
To: <tom@herbertland.com>
CC: <gorry@erg.abdn.ac.uk>, <tsvwg@ietf.org>
Thread-Topic: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt
Thread-Index: AQHUyRZ5QALK2xYK3keZ6ppDOdPifKXonVUwgAAz0QCAAAEY8A==
Date: Wed, 20 Feb 2019 16:07:14 +0000
Message-ID: <LEJPR01MB0460EF67D703C8340A976DF39C7D0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE>
References: <155052226474.25978.1700439564007128149@ietfa.amsl.com> <CALx6S34o08DY-v-1S59VAerwpnf3wD6puNGe-Jq90aswYdK8Xw@mail.gmail.com> <5C6C3F9C.1070601@erg.abdn.ac.uk> <CALx6S35WuRra0njfY=HOCaF8v9ampkTG612nbjKwid=CHQNumQ@mail.gmail.com> <072547E4-D84D-4313-BEEE-0CB66A3C6A1C@csperkins.org> <LEJPR01MB0460F9AB6E2113F4CBF246EA9C7D0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE> <CALx6S37RjKafmj9V3CifCDVSTK7Xz+kWfJGmAbq6udWHJzTGxQ@mail.gmail.com>
In-Reply-To: <CALx6S37RjKafmj9V3CifCDVSTK7Xz+kWfJGmAbq6udWHJzTGxQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [164.19.3.230]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b371b5f5-1de4-4c8f-19c3-08d6974d7aa8
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:LEJPR01MB0458;
x-ms-traffictypediagnostic: LEJPR01MB0458:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <LEJPR01MB0458012E7ADCB4A62A53ACE29C7D0@LEJPR01MB0458.DEUPRD01.PROD.OUTLOOK.DE>
x-forefront-prvs: 0954EE4910
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(376002)(366004)(396003)(346002)(199004)(189003)(53546011)(6306002)(102836004)(9686003)(72206003)(486006)(11346002)(446003)(478600001)(68736007)(476003)(6346003)(54906003)(53936002)(55016002)(8936002)(93886005)(6916009)(316002)(76176011)(71190400001)(85182001)(52396003)(66574012)(7696005)(14444005)(86362001)(5024004)(256004)(966005)(2906002)(5660300002)(71200400001)(33656002)(106356001)(85202003)(105586002)(66066001)(74482002)(4326008)(81156014)(186003)(305945005)(81166006)(7736002)(14454004)(6116002)(97736004)(26005)(3846002)(8676002)(75402003)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEJPR01MB0458; H:LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtMRUpQUjAxTUIwNDU4OzIzOjRkZXc1QmpXdFkxSm9XQWlVRXpmMzFqcnF4?= =?utf-8?B?Ym1KdkhsMDA3SDBmU2tQcEhyNmtMSk9nalJaRm5CQTdEQUVKWTRGWGV3bXpW?= =?utf-8?B?QVord2s1R3ppL2lFYi9pNExYMXJPYUl2OG1pb2c5WlRuNGNhdGVsNXo4eTE3?= =?utf-8?B?ZGIxREJZRTRnUk9BNDA5N3hPaWgycjRUOTdxSVVQU1VyOWUzTjRGVjA3VGdq?= =?utf-8?B?NmhzQnJ6ODcrWlNwNnljekkwM0J5bEhwVFVmZE12c0lVN1U0S0JHb3kzL2RY?= =?utf-8?B?YTJWZGNLQW1yeTNKL2FkSVlNSXNUUjJ5ZnV5bjZyUWljL3NySHZUbjlqT2o1?= =?utf-8?B?OTI5aXdraTdlWkMxZHZXdXFKWFBqeEMydHJuMno2Q3N2WWdZb2RYZDlQc2lh?= =?utf-8?B?MUI1V1NFTmdveExJMHVmaG1QNm1GaXN3OU4wV0h6cXNTMmdPTkVZbGRLUkpO?= =?utf-8?B?OGJrcGREcWxvNVEyMU1JbnhRbiszdUR3K1o3TVY5bXJ6T202Q0UwYW1iMFRU?= =?utf-8?B?akxvR21tNUZLZTNpOFJPNVpUUnRnaEVxTjhBUVBDRGNyeCt0aDB3SUZ6bWhK?= =?utf-8?B?eThONzhoc0VKa3YwOFNNQTVOZWlpVXVWWlJET0kyWjMyQXRYUk45VG1hSk1E?= =?utf-8?B?KytwdFU5Z2ZXQnNTY2h1alFhSVhjS0xPRW1wZkMvTnpzem8zdC9HQTh1UmVY?= =?utf-8?B?cjlZcm56YVo3eVluWDY1ak5iTjlNZUNuTkNVblpwWmxDUkRPUndhQkFkbm5l?= =?utf-8?B?R0NqbU1xTkw2YUF5UFBhTVBjdW5rQlZ4c1ROakhQK3N1OHJPU2d5azlucWVT?= =?utf-8?B?b0VlTENlTFFLUklmVUYvaUJYY3c3RHRGTXNZNmJkQ0tTZEJJbzNNdVpnVXJN?= =?utf-8?B?czUyNzVKY2Z0U3Z3VmVKcnFUc0dpQ2grZ1c1NFg3TWlkek05NkJqY1F4Y3po?= =?utf-8?B?Wk51NmFGeTlINDl3ZXlqN3JRemQrMi9zTGhCaHdlNzBuZSt1d2RiSXBPRS90?= =?utf-8?B?R1VoNnh3TEw3SkJLbkxzdlBjOFN2cFRBWmQ2Y3ZWUWpnVjdzcWg0NE5DWHg0?= =?utf-8?B?TjVyNXlZUy85RUJETldxMHNtb2lSVU9qd1NVSjZKR3lVZmg3c3l1WGYrbGk5?= =?utf-8?B?ZG5SbXRFaS9HcmRMbTU4dnZhR1RtQnV4WGsybHlUdWczZWNOMHRiUFJ1a2cy?= =?utf-8?B?bHBEeGdCQi9iZkRVNllEZENhRXlPbndRV09SaFk0akFPcUJyQWNBdkRZK0Fl?= =?utf-8?B?ODlqQU9yYVhFSnVsbGNQbi9FZStZVGRTNFBZTkhrcWRwSE1wV3RZSVpVcmxX?= =?utf-8?B?VDMwU2pRWUkybEhRTC9XZlBGZk9keVN6MXNJZ1NMZ0d5c2pwTVYvd3V1cVpU?= =?utf-8?B?UWdwc0VvcENqYTdnWENmT29xWmNRNS9PenpIS2tUUmYzZ0pyQmI2ckgwUVlJ?= =?utf-8?B?eHMzVmYxUFNnamI2ZGROekhKRDMzSDl5cE40ZGxVZjJ2NzBLdVhhU3lqWk9H?= =?utf-8?B?d3lCRFlycEpmUFJvOWhiOHpMWU5vVkxQa1VOa290cFFVL24vS1dGTGxFSXdX?= =?utf-8?B?MFpFcXphVU5KdkJJV1VoMjlPWmJSTldtZVRlTGJYMjk2aE9zVFdZQWo2WmJ2?= =?utf-8?B?R0c1MXgrNjdkZ2dKdWtNbThmV3hXQ051eFRpYkk2WWZLR3R4Z1RMaGZ3am9q?= =?utf-8?B?Y3pqcCtHanNGRHhjdXNFVmVwUkVaSnlkUUhrUWgxVVcxRHFRVUVaMW5ZcVlU?= =?utf-8?B?STRMWVNKU2dBeWRQQUlOSm8xS0NOSUdDcHBSQ0x3MXZEU1ZHbHUrWVhKUTBn?= =?utf-8?B?Z3N4REpKSDlEQnRUb3RKanA0a0pqTDZlUTEyRVhlemp0NVE9PQ==?=
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ua0Ke7+YeBSyysdxKPH0g1kE3G72sn8B54Kmmv069W+VZgtAhxEYQ9s049I8sa4z2mt7RtcKDed0h/5CmYKTRTAU2v5ElLIWa/lScZ/ms3yAtgC6NUpDATq2nQXxvD2G5P4OpUktHzu9zqTTzI6QZUEcmhakJsIwYL+zriVqUQoBwj2Bd2+8+11X4cWatjK71G86fUO76GpNosNRok43ISu5JLY/VxmEGr+X6pkh3YIAL7+28fkIAaqxRL46dbWMVbF6hpRO1KF/w8mX8FhlT+fTSAJ3ISKGm2OvC3R/OQA/B9FQ/3hQ2CA2+Ya6PXyuuqy+zApvouDVfn6+i5DbwBTP1h0rCN3O9+2VqgCVdpwErq7ITR5HCsi2EtO5K/jlKqSI7Ak0rc4BcoJnV/+M1hIZUi4SzdR02XsZOUSQi+o=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: b371b5f5-1de4-4c8f-19c3-08d6974d7aa8
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2019 16:07:14.5266 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEJPR01MB0458
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/uYwO2NW3DC1uphSupFOwqG3mDGk>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt
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: Wed, 20 Feb 2019 16:07:23 -0000

I've been describing the general state of the art of QoE measurements based on network QoS parameters. I've been picking TCP as an example. The change from unencrypted TCP transport to TLS is a fair example how to increase the difficulties to judge QoE based on network QoS parameters. QUIC has been encrypted from start on.

Please briefly describe how to reliably determine per packet end-to-end RTT as could be done by TCP Ack screening replacing the latter by IOAM. I didn't follow IOAM closely. Is that generally possible by now or does it depend on options which have to be supported by equipment owned by different stakeholders?

Network QoS based QoE estimation us done for the mass market, if a network provider serves it. SCTP and tunnels and the like are corner case transport options. Further, I don't recollect that research cared too much about different TCP dialects.

I don't think the approach to have a single solution to monitor all transport options is feasible. It will likely be too generic to provide useful input if it works end-to-end or it will be too specific to work end-to-end in a majority of cases, I guess. It's also a little hard to understand why an extra overhead should to be attached to a packet if the same information could be exposed within existing packet headers. I'm not talking about breaking consumer privacy here. 

Regards,

Ruediger 

-----Ursprüngliche Nachricht-----
Von: Tom Herbert <tom@herbertland.com>; 
Gesendet: Mittwoch, 20. Februar 2019 16:34
An: Geib, Rüdiger <Ruediger.Geib@telekom.de>;
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>;; tsvwg <tsvwg@ietf.org>;
Betreff: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

On Wed, Feb 20, 2019 at 4:51 AM <Ruediger.Geib@telekom.de>; wrote:
>
> I support Colin's view. Estimation of application QoE based on lower layer QoS measurements in general benefits from transport layer information. As an example, IP layer performance measurements are insufficient to estimate streaming QoE. QoE estimation based on TCP/TLS is challenging already.  As far as I can judge, the result is that QoE monitoring solutions which are based on applications running on consumer equipment are promoted. To gain representative data, the number of involved active receivers must be sufficiently high in any network section to be monitored.

That reflects the myopic view of some network operators that TCP is the only protocol you'll ever need. Or more specifically, that the world is compose of simple TCP over IP packets without options. It discounts the possibility of using SCTP, QUIC, DCCP, UDP applications, etc. or at least the possiblility for using them with advanced network services like measurement monitoring that need transport layer info.
Furthermore, a TCP packet that is encpasulated or encrypted in a tunnel won't be visible to the network anyone, so that case doesn't get the good service as well.

If QoE, receive window manipulation, timing packet in a flow, etc. is important and potentially valuable to users then that's great. But please, consider how to make these a generic protocol so that ALL transport protocols, ALL use cases of TCP, and in the end ALL users can take advantage of these features. The best answer is put the necessary transport information in Hop-by-Hop or modifiable Hop-by-Hop options. As an example, see
https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-options-01
which would provide in-situ OAM for IPv6 regardless of transport protocol being carried.

Tom

>
> I welcome content encryption. I personally doubt that consumer security is improved by applications on consumer devices which "call home". To me, finding a reasonable balance between commodity network provider concerns like flow QoS based QoE estimation and encryption of contents would be helpful, if security is the concern.
>
> Regards,
>
> Ruediger
>
> -----Ursprüngliche Nachricht-----
> Von: tsvwg <tsvwg-bounces@ietf.org>; Im Auftrag von Colin Perkins
> Gesendet: Mittwoch, 20. Februar 2019 13:18
> An: Tom Herbert <tom@herbertland.com>;
> Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>;; tsvwg <tsvwg@ietf.org>;
> Betreff: Re: [tsvwg] I-D Action: 
> draft-ietf-tsvwg-transport-encrypt-04.txt
>
> > On 19 Feb 2019, at 18:10, Tom Herbert <tom@herbertland.com>; wrote:
> …
> > Conversely, the draft floats the idea of purposely not encrypting 
> > certain fields of a transport header for the purposes that 
> > intermediate devices can parse them. What is the deployment 
> > experience of that? What transport protocols been retrofitted that do that?
>
> Secure RTP is one example, where the payload is encrypted but the headers are left in the clear. One of the main motivations for that was to support hop-by-hop RTP/UDP/IP header compression, but it also allows middleboxes to monitor flow QoE.
>
>
> --
> Colin Perkins
> https://csperkins.org/
>
>
>
>