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

Tom Herbert <tom@herbertland.com> Wed, 20 February 2019 15:33 UTC

Return-Path: <tom@herbertland.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 7EE16130DD3 for <tsvwg@ietfa.amsl.com>; Wed, 20 Feb 2019 07:33:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 dFPTKDTO2wyv for <tsvwg@ietfa.amsl.com>; Wed, 20 Feb 2019 07:33:57 -0800 (PST)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C67BD12D826 for <tsvwg@ietf.org>; Wed, 20 Feb 2019 07:33:56 -0800 (PST)
Received: by mail-qt1-x82d.google.com with SMTP id p25so27368637qtb.3 for <tsvwg@ietf.org>; Wed, 20 Feb 2019 07:33:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QuNk+FAaYOaTENBfyPItlS8ce5uH3ZS8l9bPHaaLZN8=; b=POcTDewzDv3ixGngtCdHIcdxj3JOEMePER/QhXrXXIZVqPWqk1jYPea51Rs4HLVNeM GGswvHLl0uo1zJf18Hj2XA92gN1OzbuYFpPksloO5immSex4NzIez+stWD/Op6onhZ/4 EcxZjLq7S30fM72ydv+D5x5hdrWD+9raKkK5Zxo56+X0bkPb35oesx9GECoHDy28f9kB BspaYcjifLB2GlaMgFNVnKlgp3mFYHX24imz9YeJj+7hPpVFG4984u+IC6sLRKBqNnul bXb7m7d/j/3UxkDS2mwjfDKa610OQ2MfRj9MwAjTbpLByzzGZLhTQeIyUFOG8ZV+Ia6q kbcA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QuNk+FAaYOaTENBfyPItlS8ce5uH3ZS8l9bPHaaLZN8=; b=MpX9H4BjPBqISNb0zUdpg6OEUWiGqzYNsNZMgt81F3nVrijl5HpSaxtM9xZqMOxFGW Gk1YynQYS9RUHni0XMdxBMhdLLpUCKTuflmbUK/LQYlP4/EkzzPJnjjOAUiPMutaJ/zK c2TXy1BtbVLPBsNMln4PfHj9lUgLYaHcAZteER4A9idi0Z5VmJIalVhX/STZ2d6MXxiT 8wD98ej+i4xus7FyLddCu0pCzn3t2imKko3njJZySqPEYWvcmp02lFeNiAVMNaHQJ7hC 358JYvvwtcLUlgx269ja5CqLxDEZ5Da5EpiL4fRdGFqPLsiVP6+noiJayV/92lGFa7Gr L8Ug==
X-Gm-Message-State: AHQUAuY4SIhztVGchwNApuTad1jfsuKgosUZs/NehBbKlat5YwpwPuY/ d/12esNv3bZcMqZxvVlkWqaL8ZlDBMyMphAV3JZAVg==
X-Google-Smtp-Source: AHgI3IbT/308C2c+Ik8x82GIZsc+/0ezW2Vl8Fedefbg0j1AZ0UcWbYfOtnE7yuByRcr/OBn4vJK3GNHfhm0PrGni/o=
X-Received: by 2002:ac8:3928:: with SMTP id s37mr2406347qtb.246.1550676835742; Wed, 20 Feb 2019 07:33:55 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <LEJPR01MB0460F9AB6E2113F4CBF246EA9C7D0@LEJPR01MB0460.DEUPRD01.PROD.OUTLOOK.DE>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 20 Feb 2019 07:33:44 -0800
Message-ID: <CALx6S37RjKafmj9V3CifCDVSTK7Xz+kWfJGmAbq6udWHJzTGxQ@mail.gmail.com>
To: Ruediger.Geib@telekom.de
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/K4KlJhYuLrpe4r4HdS_v9iAeUcA>
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 15:34:00 -0000

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/
>
>
>
>