IETF Logo Mail Archive

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

Colin Perkins <csp@csperkins.org> Wed, 20 February 2019 12:18 UTC

Return-Path: <csp@csperkins.org>
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 75EE712DDA3 for <tsvwg@ietfa.amsl.com>; Wed, 20 Feb 2019 04:18:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 336TajocX-4R for <tsvwg@ietfa.amsl.com>; Wed, 20 Feb 2019 04:18:32 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 EB65112D7F8 for <tsvwg@ietf.org>; Wed, 20 Feb 2019 04:18:31 -0800 (PST)
Received: from [130.209.157.51] (port=35085 helo=glaroam2-141-109.wireless.gla.ac.uk) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <csp@csperkins.org>) id 1gwQpV-0005md-UP; Wed, 20 Feb 2019 12:18:30 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Colin Perkins <csp@csperkins.org>
In-Reply-To: <CALx6S35WuRra0njfY=HOCaF8v9ampkTG612nbjKwid=CHQNumQ@mail.gmail.com>
Date: Wed, 20 Feb 2019 12:18:19 +0000
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <072547E4-D84D-4313-BEEE-0CB66A3C6A1C@csperkins.org>
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>
To: Tom Herbert <tom@herbertland.com>
X-Mailer: Apple Mail (2.3273)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/KnChBtmK5xAz0b5drRUpsmUh8dM>
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 12:18:33 -0000

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

v2.23.0 | Report a Bug | By Email