Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
"Black, David" <David.Black@dell.com> Sun, 05 April 2020 22:32 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 A181B3A0F50 for <tsvwg@ietfa.amsl.com>; Sun, 5 Apr 2020 15:32:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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=jZo+bIkh; dkim=pass (1024-bit key) header.d=dell.onmicrosoft.com header.b=G5NlvUKL
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 G5dPw07RLJl4 for <tsvwg@ietfa.amsl.com>; Sun, 5 Apr 2020 15:32:42 -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 EB3EF3A0F57 for <tsvwg@ietf.org>; Sun, 5 Apr 2020 15:32:41 -0700 (PDT)
Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 035MMXZT018733; Sun, 5 Apr 2020 18:32:37 -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=LmjP5oIV0UHAEE7G/RkX78eKg5FF1grtspQ09139tlo=; b=jZo+bIkhA30OwMkpSM4gGew6R3/nttjx3zDSLzcPEOEjIBeSw5/UgK0htEXUj7kJSE/Q /mYhukNBYsxAzxvU5rcynqCnijHUlW0qpuT9+7vaNDHFrszSAw4CNxo4hkaNep4z/f/K SbcpF6dZV2SwX75Pfsvvmath9QXEMPr3M8Ft9uCQr2awegk3gLHgTGGiRc/q9iWpNdG0 cDkbJ1TCF+5zdR3Gog/yymCxAyLyi/3kHNZ8anMkSsKM0zmcsUNjaBeP0DS1L0CmZ1Rl PhPMQ05py6bH4f566T//5JC9308bvwi1/yiVaOWIwSFxlVl2YD1Ah1Hfo1lf7xmmu20L KA==
Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0a-00154904.pphosted.com with ESMTP id 306p8mdcvm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 05 Apr 2020 18:32:36 -0400
Received: from pps.filterd (m0134746.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 035MTHT0166081; Sun, 5 Apr 2020 18:32:36 -0400
Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2109.outbound.protection.outlook.com [104.47.58.109]) by mx0a-00154901.pphosted.com with ESMTP id 306m3sfp68-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 05 Apr 2020 18:32:36 -0400
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bXOLkZBkjil5R3xMSvQDOE9a+okbRB62WcRW7aztUUH2n8zkX/fa7HGMKvUYX/e2083vM48aRYTpW3ZNpSVV/vAa6CzGqZJDv5VGbzU/jVCx5l0cUEqtFx3AhrNub9a8fp1VI8+dCEU8gIE2Csh9xsPdmrcegQ6tgf9AK0DjGbyuTBqwnaTTXvewCEU7DqEiz4mrC6YjaL8XySKL7mVEObJK29jPAsyHA9sb90pWGcL3yM8MdbSw4z4izaHbOoVe9RUGl8GCom3BLTdi7myl/ab4UQCLGpavDgRM2dtpXR0IUmdcgT3m0sbL/DR0Kyrywcp+iN1dWannpb1lMawHGQ==
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=LmjP5oIV0UHAEE7G/RkX78eKg5FF1grtspQ09139tlo=; b=A6VDFofuFJYx12BO2WX9Bu/Xn7l37EASJCj3BCTwFY7rDkmGllVKacsydrKRegjmt7jvg0Rf7HwzL1OPAFWmc6wthqwJH/K1mIfP0GDDWBnhyQDnuq3g1jmcaSluWnI1F2wXlGmt5l0tQC6sOBujg8XWIEl4rsXE2eqlAUuhY2BYjm7vn+P0BXH1l+5RDZfRlbW0Ehz6p1XJAq+Po2m/c5I0GBmSag4Z0QL8PMQhuWTOK7nnezuxCmfleSgSIGGd4IGehIiAARv9nygetPGan80QFe0M6BRy6B7KtBt3f8ikSjtY43tifEMtakqyqJGInVeNXhuOdqMFtV4+58TnOg==
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=LmjP5oIV0UHAEE7G/RkX78eKg5FF1grtspQ09139tlo=; b=G5NlvUKLjS1sZpJwNRh/viB/0fAc85vyIT6lw6120CmHKULhQHQCdNMoiy6NgUsKgtzRULE4PdkbGMZ8CU380+AHUAthjOMl+pO+1NTp4dEJclPdpMaQvWmIpl3yCuFtfCu1//Nnlyds9Vu0SRSneZSaN1qMdj8MFXmvr/gGuqU=
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by MN2PR19MB3245.namprd19.prod.outlook.com (2603:10b6:208:13b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2878.20; Sun, 5 Apr 2020 22:32:34 +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; Sun, 5 Apr 2020 22:32:34 +0000
From: "Black, David" <David.Black@dell.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Tom Herbert <tom@herbertland.com>
CC: 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/qhnvS9QgABYMACAAAPy4IAAdAOAgAKKKXA=
Date: Sun, 05 Apr 2020 22:32:34 +0000
Message-ID: <MN2PR19MB404585DB4796DD1EF29FDF0C83C50@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>
In-Reply-To: <42914e6a-5602-7911-7447-e400d36eb0e6@erg.abdn.ac.uk>
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-05T22:01:35.4564205Z; 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: 47c50058-f73d-4865-c2cd-08d7d9b13c78
x-ms-traffictypediagnostic: MN2PR19MB3245:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MN2PR19MB3245463FAB4AF35949E607D383C50@MN2PR19MB3245.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:5797;
x-forefront-prvs: 03648EFF89
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)(376002)(39860400002)(366004)(346002)(136003)(396003)(110136005)(54906003)(186003)(296002)(9686003)(4326008)(2906002)(33656002)(786003)(26005)(30864003)(316002)(478600001)(52536014)(86362001)(81156014)(81166006)(8676002)(107886003)(5660300002)(76116006)(71200400001)(66556008)(66446008)(7696005)(66946007)(66476007)(6506007)(64756008)(8936002)(53546011)(55016002); 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: OWNnvcQJ9yn2avVDWuDWOIDpou4y3zYJZOx8gE6GI5wuxJ9vi569hBfXChTnpSTRNz5XRukkaMlSbthw/IWaq4ZVfG3VFw/9wbvdYF3QdKa3eo4IwwHIIiv/Aj2KlmKt9yTzZxKOxyf5e38hP1kS7HuYftGNjVvIcxhSea+aVL5mMHlGLrw60iUSg374RHADg/n2TUn9xnxE4XWYc2V2NRX1x/OrkmqikrRL6CNgrR0MF2MBUwvhAGylJDQZdhiUeDYhUGFveoT3LbAXEb3yLZlozlAEWUV+3lf9oyyVhKm23bP6/rz5N6FRyUzRppc8jCEuwnyW265M4PfF1e0Q2XDOLXUGqDzcO0pQaQLdj3fj3QAynHScTdFHf8CFgUkhrhpdW/9cJvDFstAW0pKnyOFRMpaNdBZQvXY3cgxQbUqdnj5cO37Bdk8IkCeTZJ5V
x-ms-exchange-antispam-messagedata: 7CQ2nZS8HAwu2EiSl6wWdSyKHuXJHP6sfDbYfm5BoXm+b4AymCBSuqk9C7FSYqEeiwd0BvgX2+KslyyCnPY79W9ceaMaqYjcbwW4tMj5qdnaff3Le/pVoAFvgZjJo7RLmid0CmMU83/pGXsixhQffQ==
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB404585DB4796DD1EF29FDF0C83C50MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 47c50058-f73d-4865-c2cd-08d7d9b13c78
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2020 22:32:34.2483 (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: JITY55OCosFm55V9KZsCN8FnPBpbc1jDvpJ8ObXC1NppPCsm00gu5Jz3bHVMQpMTNFGAOvlGhXnamqOX/1lNug==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR19MB3245
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.676 definitions=2020-04-05_11:2020-04-03, 2020-04-05 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 suspectscore=0 mlxlogscore=999 phishscore=0 priorityscore=1501 bulkscore=0 impostorscore=0 adultscore=0 spamscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004050201
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 clxscore=1015 mlxlogscore=999 suspectscore=0 spamscore=0 mlxscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004050201
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/zov1DC1fgwt-G4IXgpCE_ryk2bk>
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: Sun, 05 Apr 2020 22:32:49 -0000
The text on ports is in Section 3.1.1 of the draft - it makes a lot of sense to refer to it rather than cover the same territory again, so mea culpa for overlooking that text. Also, in 20/20 hindsight, “more effort” was not the right word choice to convey “more involved” or “more complex” – besides, it’s better to simply point out that the transport protocol has to be identified in order to use its headers. Trying again on the new paragraph, much of it can be replaced by just citing Network-layer optional headers explicitly indicate the information that is exposed, whereas use of exposed transport header information requires identifying the transport protocol. See Section 3.1.1 for further discussion of transport protocol identification. That’s shorter, crisper text that shifts the discussion to Section 3.1.1, where a reference to RFC 7605 makes a lot of sense to me, along with a minor edit to this paragraph: In some uses, a low-numbered (well-known) transport port number can identify the protocol. However, port information alone is not sufficient to guarantee identification. Applications can use arbitrary ports, multiple sessions can be multiplexed on a single port, and ports can be re-used by subsequent sessions. UDP-based protocols often do not use well-known port numbers. Some flows can be identified by observing signalling protocol data (e.g., [RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of magic numbers placed in the first byte(s) of the datagram payload [RFC7983]. OLD UDP-based protocols often do not use well-known port numbers. NEW UDP-based protocols often do not use well-known port numbers, and use of a well-known port number is not limited to the protocol for which the port is well known [RFC7605]. This approach looks significantly better than what I originally wrote. Thanks, --David (still as draft shepherd) From: Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sent: Saturday, April 4, 2020 3:13 AM To: Black, David; Tom Herbert Cc: tsvwg Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14 [EXTERNAL EMAIL] See below on (2). On 04/04/2020 01:35, Black, David wrote: Tom, Ok, 1 issue settled, 1 more to go ... [1] Suggested revised text: The usefulness of this information would be enhanced if the exposed information could be verified to match the protocol's actual behavior, e.g., by observing whether the network traffic sent by the protocol is consistent with the exposed information in that traffic. But then that would be akin to making inferences encrypted data, and preventing such inferences in the network is precisely one of the reasons the transport header is being encrypted by the end hosts. I think that response is overdone for several reasons: 1. A decision to expose some transport header information is a decision to allow this sort of inference from observations (sorry, there's no free lunch available here). 2. What is being inferred is protocol functional behavior, not the specific contents of the encrypted headers that the protocol is using as part of producing that behavior, so characterizing this as somehow reversing part of the encryption is a stretch. 3. Beyond that, if one is determined to prevent all inference of protocol functional behavior, not exposing any transport protocol information does not suffice to frustrate all traffic analysis (e.g., set a few CE marks on packets inbound to a protocol receiver that supports ECN, sit back and watch what happens). There's been extensive security work on traffic analysis countermeasures which is (IMHO) not germane to this draft. [2] Add this paragraph: Network-layer optional headers explicitly indicate the information that is exposed, whereas more effort may be required for a network device to determine whether a packet contains a partially encrypted transport header. A particular concern is UDP-encapsulated protocols because the UDP ports do not definitively indicate which protocol has been encapsulated, even though some protocols are the predominant usage of specific UDP destination ports (e.g., a packet sent to UDP port 4500 is highly likely to contain UDP-encapsulated IKE [RFC3948] or IKEv2 [RFC7296]). Would that work? That's good, but I think there should be a reference to RFC7605 also. Ok, I think the factual statement suffices, but I won't object to a reference to RFC7605. Thanks, --David The phrase "whereas more effort may be required" is speculation. It could be that hardware in routers, etc has been designed and optimised for network-header extensions to allow metrics to be extracted, or it could be that it hasn't, or that this is only true from some vendors or some models of equipment. It's possible to say that about many things. I don't think we should speculate here, unless we can point to references that have observed this. I think we already have covered the ground for the second part of the additonal text.The current text on ports is: In some uses, a low-numbered (well-known) transport port number can identify the protocol. However, port information alone is not sufficient to guarantee identification. Applications can use arbitrary ports, multiple sessions can be multiplexed on a single port, and ports can be re-used by subsequent sessions. UDP-based protocols often do not use well-known port numbers. Some flows can be identified by observing signalling protocol data (e.g., [RFC3261], [I-D.ietf-rtcweb-overview]) or through the use of magic numbers placed in the first byte(s) of the datagram payload [RFC7983]. I do agree with Tom that this could benefit from the addition of a reference to RFC7605! I do not personally buy this: "A particular concern is UDP-encapsulated protocols". To me, this has little to do with encryption, but we could say something more here if there is a need to say more. This seems true of other protocols. They can be layered also, we see many services over HTTP/TCP and people shouldn't disect traffic based only on a TCP port. -----Original Message----- From: Tom Herbert <tom@herbertland.com><mailto:tom@herbertland.com> Sent: Friday, April 3, 2020 8:04 PM To: Black, David Cc: tsvwg Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14 [EXTERNAL EMAIL] On Fri, Apr 3, 2020 at 1:06 PM Black, David <David.Black@dell.com><mailto:David.Black@dell.com> wrote: Hi Tom, [writing as draft shepherd] [1] I don't understand this statement from the draft: "The value of this information would be enhanced if the exposed information could be verified to match the internal state of the transport by observing the transport behaviour." I assume this means that the network nodes would need to understand the internal state of transport protocols. How would this work? Oops, that's not a good assumption - in 20/20 hindsight, the quoted text should focus on protocol behavior rather than internal state. Suggested revised text: The usefulness of this information would be enhanced if the exposed information could be verified to match the protocol's actual behavior, e.g., by observing whether the network traffic sent by the protocol is consistent with the exposed information in that traffic. But then that would be akin to making inferences encrypted data, and preventing such inferences in the network is precisely one of the reasons the transport header is being encrypted by the end hosts. Beyond that, one could (partially) infer protocol state from observed traffic behavior, but I don't think it's important to say that. [2] >From the draft: "An endpoint/protocol could choose to expose transport header information to optimise the benefit it gets from the network [RFC8558]." There is also the possibility that the endpoints didn't expose transport layer information, but the network incorrectly thinks it did. The network may simply misinterpret bits in packets as being transport layer information when in fact the data can be something completely different and unrelated. The canonical example of this is QUIC or any transport encapsulated in UDP payload. That's actually an observation about transport-layer vs. network-layer information exposure that would be better addressed slightly earlier in the draft where both of those layers are discussed. After the first paragraph in Section 6.1 (Exposing Transport Information in Extension Headers) looks like a good place to make that observation. After this paragraph: At the network-layer, packets can carry optional headers (similar to Section 5) that may be used to explicitly expose transport header information to the on-path devices operating at the network layer (Section 3.1.3). For example, an endpoint that sends an IPv6 Hop-by- Hop option [RFC8200] can provide explicit transport layer information that can be observed and used by network devices on the path. Add this paragraph: Network-layer optional headers explicitly indicate the information that is exposed, whereas more effort may be required for a network device to determine whether a packet contains a partially encrypted transport header. A particular concern is UDP-encapsulated protocols because the UDP ports do not definitively indicate which protocol has been encapsulated, even though some protocols are the predominant usage of specific UDP destination ports (e.g., a packet sent to UDP port 4500 is highly likely to contain UDP-encapsulated IKE [RFC3948] or IKEv2 [RFC7296]). Would that work? That's good, but I think there should be a reference to RFC7605 also. Tom Thanks, --David -----Original Message----- From: tsvwg <tsvwg-bounces@ietf.org><mailto:tsvwg-bounces@ietf.org> On Behalf Of Tom Herbert Sent: Friday, April 3, 2020 12:49 PM To: tsvwg Subject: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14 [EXTERNAL EMAIL] Hi, a few comments. I don't understand this statement from the draft: "The value of this information would be enhanced if the exposed information could be verified to match the internal state of the transport by observing the transport behaviour." I assume this means that the network nodes would need to understand the internal state of transport protocols. How would this work? If the idea is that the exposed information is somehow verified with the endpoints that securely provide the information then maybe I understand that. But, if the idea is that intermediate nodes need to autonomously deduce the internal state themselves, I think that is problematic. Aside from all the known problems that stateful network devices have caused, there seems to be a circular dependency here. AFAIK the only way to deduce the internal state of a transport connection in the network would be by inspecting the exposed transport information, but this statement seems to be saying the exposed information can't be trusted unless the internal state has been deduced. Am I missing something? >From the draft: "An endpoint/protocol could choose to expose transport header information to optimise the benefit it gets from the network [RFC8558]." There is also the possibility that the endpoints didn't expose transport layer information, but the network incorrectly thinks it did. The network may simply misinterpret bits in packets as being transport layer information when in fact the data can be something completely different and unrelated. The canonical example of this is QUIC or any transport encapsulated in UDP payload. Per, RFC7605, transport port numbers only have meaning at end points. So for example a network device may think a packet with UDP destination port 80 is QUIC, when in fact it is something completely different, hence the network device may misinterpret the payload as being QUIC. I suspect it's unlikely that this situation will benefit the user, and more likely the network would not treat such packets well. There's been some work on this problem, like magic numbers in SPUD or analysis to mitigate the effects of misinterpretation like done for QUIC spin bit, but I don't believe anyone has proposed a general solution (other than moving the necessary information into the network layer and have intermediate nodes stop doing DPI). I believe this problem should be mentioned in the draft with a reference to RFC7605 . Tom
- [tsvwg] Comments on draft-ietf-tsvwg-transport-en… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Black, David
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Black, David
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Gorry Fairhurst
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Black, David
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Joseph Touch
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Gorry Fairhurst
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Joseph Touch
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Gorry Fairhurst
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Joseph Touch
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Gorry Fairhurst
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Joseph Touch
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Joseph Touch
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Black, David
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Gorry Fairhurst
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Spencer Dawkins at IETF
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Spencer Dawkins at IETF
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Gorry Fairhurst
- Re: [tsvwg] Comments on draft-ietf-tsvwg-transpor… Spencer Dawkins at IETF