IETF Logo Mail Archive

Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

Ruediger.Geib@telekom.de Tue, 24 March 2020 08:06 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 997DA3A10B2 for <tsvwg@ietfa.amsl.com>; Tue, 24 Mar 2020 01:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] 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 NTiHVqHrUPwH for <tsvwg@ietfa.amsl.com>; Tue, 24 Mar 2020 01:06:45 -0700 (PDT)
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 46F253A10B4 for <tsvwg@ietf.org>; Tue, 24 Mar 2020 01:06:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1585037205; x=1616573205; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=GRXtaQs3R3IKK3nHE0MB8HUF+fpqR7zvWVVSv8S+J8M=; b=NJIGrr6NzZKQduvM5r+XG3e4i8kxF3cB/l1MBq6QwkkgsGNM+8JP3+iV lZTdcgBsmOvG/PqGPEwiHBOsU684IFHIwRaJTaAK5sGk9tBbXxHPazSEj wXf/a4KkpaIXdKSCdHBs7BZyJLcGpg9EzYG5wF/PD1hh+0OqtyLjiK8zR HTWnlnmMJs3N4txLtBOvdakEwXIcbtkLVjJjeXjytDdXVYHE7d3Gx35dl rhTYJXBWgJB5UgmjIKELjKObHmLr09wrGIL2mtoctEFl/qnnScQklhogJ KWHIAhkoSpkW+2vqOKY6NtgP05yh1FNcyEHFUxLcVbThb2VEVQzZLZeVK g==;
IronPort-SDR: abuUQ8ECEvp0TbVlFxlE2Tr6QXtejCvgkIfiuAP4DMLq+F+kAY3Q2gOgwxQiCSylZWOGfUXmEh ebpDPJmVHIAg==
Received: from qde9xy.de.t-internal.com ([10.171.254.32]) by MAILOUT21.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Mar 2020 09:06:43 +0100
IronPort-SDR: yzN9G7wqqAiSx6c/URz6I+E4C0dJ/B0GYuV/LoQnNM6idWTUL2BHM0+YIAhmO6Pc8GMsq8Fc27 LYUONidAIl9dR2tW6Y92xcTqK5ikvRalI=
X-IronPort-AV: E=Sophos; i="5.72,299,1580770800"; d="scan'208,217"; a="70848132"
X-MGA-submission: MDHIT13BQvv6NFFHpJTBnrJrhH0yOJt2qXVgrx2DF9MXsgQ4AURKq4To5xlUqfb0a1fAl9KQkMdsjP93jlinW6LgLAdAGS8lZlANz4S6XWJy8C1ZOHAkuqL2WO7aFLtPGuBkJvls9nBHNOPAFyy6XMi6AvJd3DZ4WZhDLgEaLjcflw==
Received: from he199744.emea1.cds.t-internal.com ([10.169.119.52]) by QDE9Y1.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 24 Mar 2020 09:06:42 +0100
Received: from HE199743.EMEA1.cds.t-internal.com (10.169.119.51) by HE199744.emea1.cds.t-internal.com (10.169.119.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Mar 2020 09:06:42 +0100
Received: from HE104162.emea1.cds.t-internal.com (10.171.40.37) by HE199743.EMEA1.cds.t-internal.com (10.169.119.51) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 24 Mar 2020 09:06:41 +0100
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.20) by O365mail04.telekom.de (172.30.0.231) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Mar 2020 09:06:39 +0100
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Oy657DpcnImKB3UrJWq14PK/DIh0+D5gmn5VIPigAuDSLZs4JTm+p1kA/RJj0LbnFb+OwE3+BOdXky3JkKyM7VrFyFQSXfJ6SxbDCZgRvb256Db7MdeQdhry4xgteZxTyjfRCe6QQCt/his14o2ADNhRDAE6OqtcHkbSY8xQ/08yYVj2mU8jIhBZR+CVdwj5uUDDPbn5L/yQD28n3lNfORynnxmB/3ywIEYJUDNr91T+U4AB0neAlUBsm6mE1oqA6j3tOO0VjuGGtwzH8Mm9OXf+yU4YkGm2MBRZbczM7I66jvSPI7Z7spMaUcXg3Q6b+TYco9pT5OEIZcWucadT9w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GRXtaQs3R3IKK3nHE0MB8HUF+fpqR7zvWVVSv8S+J8M=; b=it1bfs7eT4lIpmyFGxUGpovdtGx0KsGBbY4CGUMuJAifo+mpDdn0l7MmMnqbLXpNorM4ooFuLHXVX/iao2p2NH2ve/rzWj1io5FBgtqbhIZXhzkO7006s5fKFZ33VomrPkdbMGuDCaEKe5hbXt0cCLonBH3iAyZWngD66x8/kwxSiw7EX87GK1zEHCnK1hHHHOCqbdyvwrDIYMyx+za5iw6W9rOHeQDAO4OMYEAcsGmZqJbVgwi14m9dQ49vHNASxYlJXoLtxn6KKnOtAYlDMloHoRruBRjBdAbAxnhKPoVgFCQz700vM9ouZyLGtVGNnmLEnhIRO9logCHu8EWVPQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none
Received: from LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE (10.158.167.12) by LEXPR01MB0381.DEUPRD01.PROD.OUTLOOK.DE (10.158.165.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2835.22; Tue, 24 Mar 2020 08:06:31 +0000
Received: from LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE ([fe80::9458:b28e:6131:52eb]) by LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE ([fe80::9458:b28e:6131:52eb%7]) with mapi id 15.20.2835.023; Tue, 24 Mar 2020 08:06:31 +0000
From: Ruediger.Geib@telekom.de
To: David.Black@dell.com
CC: tsvwg@ietf.org
Thread-Topic: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
Thread-Index: AQHWASYRrsp4tumnS0yev/1OnP0COahWSsQAgAB1L4CAAJf5UA==
Date: Tue, 24 Mar 2020 08:06:31 +0000
Message-ID: <LEXPR01MB05108C754317E0CB677D5AE39CF10@LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE>
References: <CALx6S349SE2Ho0V2bJPSE7dh3+2f5Wiw1AofMke0RY4FwF=ebw@mail.gmail.com> <679FAA73-401E-499D-87CB-10F973E05DD6@strayalpha.com> <MN2PR19MB40455E00DB52880A38EB494C83F00@MN2PR19MB4045.namprd19.prod.outlook.com>
In-Reply-To: <MN2PR19MB40455E00DB52880A38EB494C83F00@MN2PR19MB4045.namprd19.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2020-03-23T22:18:08.2613541Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.4.48]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 25dfdb13-e190-4267-49b0-08d7cfca433f
x-ms-traffictypediagnostic: LEXPR01MB0381:
x-microsoft-antispam-prvs: <LEXPR01MB0381800E9498BDFD335D89899CF10@LEXPR01MB0381.DEUPRD01.PROD.OUTLOOK.DE>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 03524FBD26
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(39860400002)(136003)(396003)(66476007)(66556008)(66946007)(53546011)(9686003)(66446008)(7696005)(55016002)(2906002)(76116006)(6916009)(33656002)(64756008)(5660300002)(478600001)(19627235002)(85182001)(4326008)(85202003)(186003)(8676002)(81156014)(8936002)(71200400001)(66574012)(81166006)(316002)(86362001)(26005)(777600001); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0381; H:LEXPR01MB0510.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: I71AnqaB404cQo/8LMQrNJbFCqu48cf6+1r7ZwG7wbF2BN8U6v5d6AHP4fwHR7pVy5KXPrBRp2tOko1/c5/UjycQ6+J54eFBTAs3c7Ug5dSpoefXOuyBAjJbOmg5SEpMu/4PBjdOjjCty2TV+he4HerbebrZmgFxbqotOaKvxglW/dDrMC8AAeVEGJ93Pf5gIj0OXAXf1hf8QdUNOdoG7SyFTx3YJ/7dixL79b/2b74LKDo8ruh9+A5mBRcOIm8FzM+BqMDIVT+MRVebIByKjq0g9oxjaU1Xk2T0sVQHQUgAJrSJaAOEFTcSKXacF+Y5Ypg6eq6CR/gj8Isir9LX68aBXCpZU55+v1eF2sA0SIHqlhioEavim0QYzeypCVu+nObCI7Fa6YRg8lsy9dtYC9mS07nn95tYdKlZUbruNYrHwNG1brQH8BTfH2xR0rx/HObK3BV6CUeCNosznFPbA6anUmfa+UWZqb24tbq9QyzzId+AUd0r7ikImP7QGxGK
x-ms-exchange-antispam-messagedata: 26oqAWogOLWi9aBA8qhQ5gVkC+KsIoFKaZakRatYrCLCIFuVx/RhxIlBAL+9VC/WV7dYe5cTcH7bpZCre0tfB6EyWAi5WbXLLEcPfrmMRsukRtnkqGUQzpZl+PFs7kLC/M2ftSzGNUnROBrCFJkVvg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_LEXPR01MB05108C754317E0CB677D5AE39CF10LEXPR01MB0510DEUP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 25dfdb13-e190-4267-49b0-08d7cfca433f
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2020 08:06:31.4139 (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-CrossTenant-userprincipalname: LTu0rjJI6CRMiyH6TJe8ikc3IuEyt+fVY9mnVAGyB4Kne/GYs9nofoELBr7c/ZjGKdazGuummmBwl3x5T0FBTPe+Nw11nzyKWOIWEtb8fR4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0381
X-TM-SNTS-SMTP: C2C3BD9FF35536411D628890704ABF28A3035B6083FC9A45F37CAE02E4B017912000:8
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/sTHGDeg_YxRE8ZdRHv-MilongTc>
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
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: Tue, 24 Mar 2020 08:06:49 -0000

David,

don’t know, where this is heading to. Two observations, shared earlier on this list:


  *   I’ve distributed a link to a publication where Google gives advice to operators how to optimize access policer configuration. This optimization requires transport layer performance information.
  *   One result of encryption that I’m aware of are measurement applications residing in dedicated and consumer terminals, reporting results back to central servers. Reporting transport performance is one aspect.

Regards,

Ruediger

Von: tsvwg <tsvwg-bounces@ietf.org> Im Auftrag von Black, David
Gesendet: Montag, 23. März 2020 23:20
An: Joseph Touch <touch@strayalpha.com>; Tom Herbert <tom@herbertland.com>
Cc: tsvwg <tsvwg@ietf.org>
Betreff: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

[writing as draft shepherd]

Point taken – would it be reasonable to rework that paragraph to observe that there should be incentives for endpoints to expose transport information, e.g., otherwise implementers may simply not bother?

Thanks, --David

From: tsvwg <tsvwg-bounces@ietf.org<mailto:tsvwg-bounces@ietf.org>> On Behalf Of Joseph Touch
Sent: Monday, March 23, 2020 11:20 AM
To: Tom Herbert
Cc: tsvwg
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13


[EXTERNAL EMAIL]


On Mar 23, 2020, at 7:58 AM, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote:

Fundamentally, transport layer is end-to-end information. There is no
contract between end hosts and the network that hosts have to be
honest or correct in setting information in the transport layer-- the
only contract is between the endpoints.

+1

Another point worth mentioning:

- if endpoints can lie or mislead about transport info to get their way, they can, will, and IMO *SHOULD*.

That goes for using port 53 for nearly anything anyone wants to. Transport info isn’t there to make things nice for network operators - that’s what the network layer is for.

Oh, yeah, I know - network operators don’t want “heavy” stuff in *their* headers because it slows them down when they don’t want it. Too bad, IMO. If they want the info, they need to deal with the pain.

Joe

v2.23.0 | Report a Bug | By Email