Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

"Black, David" <David.Black@dell.com> Tue, 07 April 2020 16:20 UTC

Return-Path: <David.Black@dell.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 88FF63A0DE6 for <tsvwg@ietfa.amsl.com>; Tue, 7 Apr 2020 09:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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=dell.com header.b=XGCttRhs; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=erwIcz/U
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 Nnva7631yV9P for <tsvwg@ietfa.amsl.com>; Tue, 7 Apr 2020 09:20:41 -0700 (PDT)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 901873A0DDD for <tsvwg@ietf.org>; Tue, 7 Apr 2020 09:20:41 -0700 (PDT)
Received: from pps.filterd (m0170390.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 037GHCCX000896; Tue, 7 Apr 2020 12:20:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=awuQghGNesxvY0YSJemzQ7ovVvW67U3i1rZneQ9MmEU=; b=XGCttRhsdiHGAiecPiSgyCnpH2rQNg/A1o1saaPni+baVeKKZdffzFbshcKBjcJ3Wjmp mba/ZjR4fqwykmZW6of3KHB9e189C2uZhGCU2mU6eeBrTaQ2TM8UV4dWjhDgnjYvj+Ti QPjgKsCRIM223RVMCuoyZxcOTEeGNh3De+JlHqc9GGhPJ+ukb2VvOWSsMM//VQzhtnPI L9PURU+XZyTC6GdNqOjyAbZWs2HENVNk42PoyKSHUPL1/xc30ZPUm46VK7Dn89PmYm04 xIyIQUH8gf3Eg3yPE09wb47GKCzjpJioyEAt41LETPj3IiS0kEVpKlWjoLPKgAqvaCVg xw==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com with ESMTP id 306na4ytyx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Apr 2020 12:20:36 -0400
Received: from pps.filterd (m0144102.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 037GJxA4111208; Tue, 7 Apr 2020 12:20:35 -0400
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2170.outbound.protection.outlook.com [104.47.59.170]) by mx0b-00154901.pphosted.com with ESMTP id 306mgvmtsp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 07 Apr 2020 12:20:35 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZApB8G4Y3929C7ix4i+iaADUKD4GXimz+gtKT5Mw7IHTbaILfAvfVD2wzMqm0hJmegcqnWBtNwHLeZrGemoFBYYw//vEzVXAgT4uZ4fL66FP5WlGicw9OSft1gxfo9rI5svypiJyxFrFbNimQBg+PAPjExSWyDg/kcyjh3YBRZ12TSqi4yYlLva9Mk30amtTFCWrZNhVaaQ4Q6L/B1NmQ0l9yrH5e4R8tKVCAB8IvgikJEuaLgwLcc44UTi2coHXjIF81mGFe7DKVM2lFwrOp6bhbFzALPGyc/sMdWM4X/nB1CqKW/tZQMSaVRqauXKMQea3POGalEmr4b/wUTHsLw==
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=awuQghGNesxvY0YSJemzQ7ovVvW67U3i1rZneQ9MmEU=; b=HACHZOTDG95HhzjCS7lxWom/4Uq4mkxH2B7AnFw0znIrIkhfrt54q017yDSYpmr+ROJqTvLqvKlaESWsjV52rzIdTLVUpv1Dizwzc9jD5aeW5/zUI/+kGQStmHLpWD2tmGHfiBgVapeQxpQC+e6XGHyOzAGlPMOrhQl0yzN4ZGa9J24odjGGT3YGguYp5YMMT/o9KmsC8zq5+ZgW7T9yY0lyo4HgGsEQ8PRtV/dut2jOFbjz1n7DSt94UNz6LW5nMPukxc+w/YMwdJSw0JQv7ZDXpL81QnTF7HYEDntFYxXAy+JPeKtWUdttuLcmqzlmlklorlksbsiMgobMPgTCew==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dell.onmicrosoft.com; s=selector1-Dell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=awuQghGNesxvY0YSJemzQ7ovVvW67U3i1rZneQ9MmEU=; b=erwIcz/UIkE8ps35TA1h6FavOQ/83IYEZC+y3aLi5I1gR+TuJJH9I57fAF10zN/QWTijzqC0nPiiiPaSnI/kDex1YFyBomkz5dxCX9QnVzVU+buPedR+ZKw/6bHNC1W+YGQTR6j767Jms7d8a84uH4H7wz++aTl8JjGu+6Bw9dY=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB2557.namprd19.prod.outlook.com (2603:10b6:208:101::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Tue, 7 Apr 2020 16:20:33 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::8d12:8a24:ccb2:b2bd%3]) with mapi id 15.20.2878.018; Tue, 7 Apr 2020 16:20:33 +0000
From: "Black, David" <David.Black@dell.com>
To: Joseph Touch <touch@strayalpha.com>, Tom Herbert <tom@herbertland.com>
CC: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tsvwg <tsvwg@ietf.org>, "Black, David" <David.Black@dell.com>
Thread-Topic: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
Thread-Index: AQHWCdfN95tAuqnQEUqYW+PFgtwk/qhnvS9QgABYMACAAAPy4IAAdAOAgAKKKXCAAA4cAIAAwYaAgABNRwCAABfxgIAAm5SAgADZSgCAAAjZAIAABleAgAACWYCAAAPXcA==
Date: Tue, 7 Apr 2020 16:20:33 +0000
Message-ID: <MN2PR19MB404509A876B1A187755202AD83C30@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <CALx6S345Ta5LjSkZ+XmNmH8dxKnM++VRCej2iGxfdUqDc+M-Jw@mail.gmail.com> <MN2PR19MB4045652C80DB5348A5A3505F83C70@MN2PR19MB4045.namprd19.prod.outlook.com> <CALx6S36yzDTLaxUhWibZjmK5Cxu2zfzxiawFRCbVn9aPF4rs1A@mail.gmail.com> <MN2PR19MB4045E873D0908044343F8C2283C40@MN2PR19MB4045.namprd19.prod.outlook.com> <42914e6a-5602-7911-7447-e400d36eb0e6@erg.abdn.ac.uk> <MN2PR19MB404585DB4796DD1EF29FDF0C83C50@MN2PR19MB4045.namprd19.prod.outlook.com> <6CC67993-37FF-4B02-A45A-4F30E9D6686C@strayalpha.com> <fc94ff59-4972-3960-7c25-85f8953463f9@erg.abdn.ac.uk> <62B8E2A9-2347-44E2-8B14-DD3CD81937AB@strayalpha.com> <737cf948-065b-0702-ca15-6cc216d73bc9@erg.abdn.ac.uk> <10E067D5-0C17-400B-BA7F-3CB49C2C94B6@strayalpha.com> <CALx6S36_HGekVYSBTiP-=uDigk+nzf2Yw2AtqopPrK5Y1gozgQ@mail.gmail.com> <2856BD08-BFCD-476D-AD1E-FE1EA94C92C7@strayalpha.com> <CALx6S34vazUp+ttxqqJ2S6U_uN8oRNt-MATdGgKvbLRFz=BLsA@mail.gmail.com> <7CC3D01B-8E86-4898-BED4-A93149D13666@strayalpha.com>
In-Reply-To: <7CC3D01B-8E86-4898-BED4-A93149D13666@strayalpha.com>
Accept-Language: en-US
Content-Language: en-US
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-04-07T15:57:32.5296087Z; 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
x-originating-ip: [72.74.71.221]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a8d34e5a-ae5a-4bbf-3a5d-08d7db0f9921
x-ms-traffictypediagnostic: MN2PR19MB2557:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB25576106FDC5DE50A7D2C62283C30@MN2PR19MB2557.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 036614DD9C
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(39860400002)(346002)(366004)(396003)(376002)(136003)(7696005)(186003)(9686003)(52536014)(55016002)(26005)(5660300002)(107886003)(2906002)(81166006)(64756008)(8676002)(66556008)(76116006)(6506007)(53546011)(8936002)(66946007)(66446008)(66476007)(81156014)(86362001)(478600001)(316002)(33656002)(4326008)(71200400001)(786003)(110136005)(54906003); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: dell.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 7R3SBDApgJ3C0vxrrthM0sy40nnCqkWGuqla4qBZdIVvB+iZpn34/UJu6cHXbTJhgd6KoHYk5XSD09xx3QdMKZMUDHW/5cNr9Gv+V0TlGx+9sZXNT6K6Ipxn4N8h0ZTn7mCmPQ9EPCYqw7S+5OGV1GHkz5U1V2CDfSvzg2mmX/koR9ejkB09nqrnBNVb/Oy3JVKSAqASvpm95Ero0vMNK2dWs93qY0ddj/6hfzg13MNg6CPkbFVeMiFae1loEbyMo5ZGSE/a9iIao6dKxL142JLQBHJ+m4luQYEUTkKyL5AI7fRUNFD6V6za0q04vkz9R4dpNOYlIMtTpMocTkjvBVtfySrJ9Vg+t+uGaUckz6tLPzoITWwcgOGVv4hUJidd32DTgDGU7jdGbnSF7MfP/mqOhI3u7yeFdbCr/iXfQcCSz5RKoN5Y0No+c2HQ17Fr
x-ms-exchange-antispam-messagedata: u8jtmJBFEsGiHlqcokH7s8/AgkzCAqjHfM+ZAPnt7sUf2G/VR1u8/tXm7ejbNxDdWO7VWJ47pTRj1d3CempX9M1wpVsV8Jo7fKYxjJmdHU+8tXK+QdUzTaGP3wAopAxdjO4oBpns+6Fl1F3F42VtEA==
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB404509A876B1A187755202AD83C30MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a8d34e5a-ae5a-4bbf-3a5d-08d7db0f9921
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Apr 2020 16:20:33.4695 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZZufOQp64Imt2DEOnQLoetjnBVAEZVhcxLWaVlCw7bO8xI0z+RQ+irHwoxYzHtgQMI41Jn9il4jns/E95X+oWA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB2557
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-07_07:2020-04-07, 2020-04-07 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 adultscore=0 malwarescore=0 phishscore=0 impostorscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 spamscore=0 mlxlogscore=999 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004070132
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 spamscore=0 priorityscore=1501 suspectscore=0 bulkscore=0 mlxlogscore=999 impostorscore=0 mlxscore=0 malwarescore=0 phishscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004070132
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/3iwp265RkdG1HqYor0EAAlR1qrE>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
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, 07 Apr 2020 16:20:44 -0000

>> Also, a corollary should be the hard requirement:
>> "Intermediate nodes MUST NOT ever modify transport payload”.

> As a general principle, yes - agreed. There’s always the caveat that it’s always OK
> *with the consent of the endpoints*, e.g., if an enterprise wants to set up the
> network that way for their users. But in the arbitrary “middle” of the network, it
> *should* IMO always be MUST NOT.

As a general requirement, that’s fine, but it should be stated somewhere other than in this draft, e.g., as this draft is intended to become an Informational RFC.

Thanks, --David (as draft shepherd)

From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Joseph Touch
Sent: Tuesday, April 7, 2020 11:43 AM
To: Tom Herbert
Cc: Gorry Fairhurst; tsvwg
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14


[EXTERNAL EMAIL]



On Apr 7, 2020, at 8:34 AM, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote:

On Tue, Apr 7, 2020 at 8:12 AM Joseph Touch <touch@strayalpha.com<mailto:touch@strayalpha.com>> wrote:


Hi, Tom,


On Apr 7, 2020, at 7:40 AM, Tom Herbert <tom@herbertland.com<mailto:tom@herbertland.com>> wrote:

On Mon, Apr 6, 2020 at 6:42 PM Joseph Touch <touch@strayalpha.com<mailto:touch@strayalpha.com>> wrote:


Hi, Gorry,

I’d suggest as follows (just to follow through on the changes):


In some uses, an assigned transport port (e.g., 0..49151) can identify the protocol [RFC7605]. However, port information alone is not sufficient to guarantee identification. Applications can use arbitrary ports and do not need to use assigned port numbers. The use of an assigned port number is also not limited to the protocol for which the port is intended.

Joe,

RFC7605 acknowledges that port numbers are used to identify the
application protocol, but clearly doesn't condone the practice. I
suggest the text should just paraphrase RFC7605:’

I don’t quite understand the above, esp. the use of “condone”. Port numbers are assigned *exactly* for endpoints to identify application protocols *in the absence of any other more explicit coordination* (the draft doesn’t say it so directly, but that’s the summary).
Joe,

I meant by using port numbers at intermediate nodes for identifying
application protocols.

Oh, sorry. I didn’t get that from the text, but agreed.


For example, QUIC is assigned UDP port number
80 and the spinbit was created to be visible and processed by
intermediate nodes. The only generic way intermediate nodes can
identify QUIC is by matching the assigned UDP port number. RFC7605
says that such matching may not be correct, so consideration needs to
be taken what happens if things are misinterpreted (IIRC, processing
of spinbit for a packet misinterpreted as being QUIC is considered
innocuous).

Agreed.


Also, a corollary should be the hard requirement: "Intermediate nodes
MUST NOT ever modify transport payload”.

As a general principle, yes - agreed. There’s always the caveat that it’s always OK *with the consent of the endpoints*, e.g., if an enterprise wants to set up the network that way for their users. But in the arbitrary “middle” of the network, it *should* IMO always be MUST NOT.


I don't believe this draft
mentions the fact that some intermediate nodes modify unencrypted
transport layer headers in flight, but this does happen. For instance,
there are devices that will modify the TCP receive window to optimize
traffic flow (I believe there are some routers for satellite links
that do this).

Yes, and they then complain that mechanisms like IPsec “interfere” with that “feature”. Some of what they do might be relatively innocuous, but some - esp. forging ACKs to reduce endpoint-perceived RTT - runs a significant risk of undermining TCP semantics of reliable delivery.


If this technique were applied to QUIC where the
network modified some "exposed" fields in the QUIC header then this
would risk systematic data corruption for UDP packets misinterpreted
as QUIC (putting the transport layer in a modifiable HBH option would
not have this problem).

Tom



That said, I was OK with the resolved text I had suggested, with or without the text below - which is also fine.

Joe



"Port numbers are sometimes used by intermediate devices on a network
path to interpret transport protocol payload, however any
interpretation of port numbers -- except at the endpoints -- may be
incorrect, because port numbers are
meaningful only at the endpoints [RFC7605]."

Tom




Joe