From nobody Fri Feb 12 10:05:44 2021 Return-Path: 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 B58EB3A1848; Fri, 12 Feb 2021 10:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.125 X-Spam-Level: X-Spam-Status: No, score=-0.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_06_12=1.543, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net 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 BHPZIsucWRUe; Fri, 12 Feb 2021 10:05:40 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (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 275D83A1847; Fri, 12 Feb 2021 10:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1613153122; bh=iR5cIUYp+ZRsiOEgFqMDSoWEr5JFEw6viIVGxYxvyJA=; h=X-UI-Sender-Class:Date:In-Reply-To:References:Subject:To:CC:From; b=bdUfoX1y1FBGNLXZJItcvXsif89V0aoqW7LaJjT26JN6ZzVEasXABYafPNTjkv1t3 Qh52UKMV75VB3e/zhz3BL4yu//2kK+N49k8nlhBz/26ij+BipU7BYLD7Tgu567vWtp TC07y32sk/XUVsNqoSlARa3n8OHoePqvN6XiKYT8= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [10.150.123.71] ([80.187.113.71]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MUGe1-1lJ6yf2QT5-00RHH8; Fri, 12 Feb 2021 19:05:22 +0100 Date: Fri, 12 Feb 2021 09:23:04 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <161257199785.16601.5458969087152796022@ietfa.amsl.com> <20210210062551.GI21@kduck.mit.edu> <2fb9d724-7f8a-93cd-9045-eb3852345a9e@erg.abdn.ac.uk> <1416490d-6532-59ce-e09f-388db716af8f@si6networks.com> <1005a57d-d24b-a71e-e977-2be84ad63695@si6networks.com> <1dcb48f6-f621-11f8-9e9a-067b65c44818@si6networks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable To: tsvwg@ietf.org, Tom Herbert , Fernando Gont CC: Gorry Fairhurst , "tsvwg@ietf.org" , Benjamin Kaduk , "saag@ietf.org" , Fernando Gont From: Sebastian Moeller Message-ID: <0EA379CE-077D-4822-8991-62C1FD2D96DB@gmx.de> X-Provags-ID: V03:K1:BsOmdCGS2P3O7YhtvcIIUM0ctY5/3JB3+y4RY7voao2OwZN8I/R RNvhS8OZ6WVITQhKWFr3YgbSLmcQ2JmG/RD3otvvfDpx/qO7M9HhnAbLqisMGxy0RkOD7aa n/FJxBBXW4Ws2JYe+4Zlt5jIUmR5yRPI5bNd200i9llG9P+aFnyosp4Gord34HHdKCF58DJ uuYZfZS8z9rYYlfnND8Bw== X-UI-Out-Filterresults: notjunk:1;V03:K0:bWd/u47e9wo=:kcnnwofuzcGkItWmghUPlm oPUEXxhVqhvQaWTF3Q1j+43xeiMs8i5HCSV/YTpcfTbHok5bcEbRPb+kCbjOUw3SgAsdvZVeV bdwoNBE3KbBH6AR50NdpPsxnMCedof4YXeE7yj6e4xZ1I1JUxmJ0bLHPpYGlj8bsdQf4Li5pN QNgjrjId2MCEswObtr4rYVb30N1YgnMXDPMXdkcHBMaHNAY2U0UCYonFY//GzpFYTHksadBcD rcJ2wM30wf7fwdVqXijwR0nMAe2BGAkwlppR+RG9iyA1a3q0T3Rrh7HEe02rNF7r0MrNyQ7Xo aNE62+9qgF9S1zX9Zd7+ozspyS0gy4V7uSJFdmCOcUQ2j1q9y3I6SjXlFUwgTlh4w3Z8/lqGy pzJps3HJfF8xYOZQtpZrfytRU+tiMYZF1aIZgRPV5EjbdjkAoBw7PDE8JsJ35yNUz4Nb+D8d1 L8u6JOwwbuLJ/5uPcT5ARiXSe4jsy9X0810a+l+0jQTEbvMt3HrNsL9JjYloUdf0qTLI1tKME q6QODNR4RGPoNOomg34CqzYrx04H2cMz3Ia+TvDYA+IyGOvsD2EoP37Kf0583gTp+wf0tpE+D IM147R7uZjHtfLu0uae7wNvTOOTkUp5J0sQo72ZPNhxw05YHxCdDQGyLWYo3ClHp6ngYUd1c4 M4ZS07sZoJxDK4iHOEJjajINdsHga3G5MY2m9bARlDtgeXMlUOhl0z+aFGPAV3oEeEq89cCld 28nt2LKgmH58lrh/Yz6YTGptQlM61mmZZfbR/v9xd3qyGZWQ7W8ZYGbXYqpQDyzNlnHnFCkcG 2bbFVB8/NAEcA08sUlX3ZVqZp6rv6Qzu0Ktd2YTWeD+yu+eA4Rs2Hw1K8p4y+FsKR9BMViqrf 0W3cIGxXS/VNiI3udQ6Q== Archived-At: Subject: Re: [tsvwg] [saag] Fwd: Last Call: (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC X-BeenThere: tsvwg@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Transport Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Feb 2021 18:05:43 -0000 Hi Tom, More below inline, prefixed with [SM]=2E On 11 February 2021 20:43:19 CET, Tom Herbert wrot= e: >On Thu, Feb 11, 2021 at 12:28 PM Fernando Gont >wrote: >> >> On 11/2/21 16:11, Tom Herbert wrote: >> > On Thu, Feb 11, 2021 at 11:40 AM Fernando Gont > wrote: >> >> >> >> On 11/2/21 15:18, Tom Herbert wrote: >> >> [=2E=2E=2E] >> >>> >> >>> When the transport layer is encrypted, network devices would only >see >> >>> the plaintext EH and that is only what that is what they can act >on=2E >> >>> At the destination, we could try to rectify transport information >in >> >>> HBH with decrypted plaintext transport headers, but I suspect >that >> >>> wouldn't typically be done=2E The HBH information is only >operationally >> >>> useful to the network, not the transport endpoints that have >access to >> >>> the transport header=2E >> >> >> >> Then this is what an attacker would do: >> >> He/she would advertise on a HBH option something that looks >sensible to >> >> the guy enforcing a network-based security policy, and then at >transport >> >> would do what he/she needs to do=2E :-) >> >> >> >> >> >> e=2Eg=2E, HBH could advertise that my packets are directed to ports >80/443, >> >> while in transport they are actually directed to port, say, 22=2E >> >> >> > It's more likely that information in the HBH would be generic and >> > abstract, afterall the whole point of encrypting the transport >header >> > is to hide information from the network that it doesn't require, >not >> > to just blindly volunteer the same information somewhere else in >the >> > packet=2E Port numbers, for instance, are not required for delivery >and >> > in fact are prone to misinterpretation in the network (RFC7605)-- >IMO >> > it makes no sense to put those in a HBH option=2E >> > >> > Regardless of HBH though, if the preponderence of transport headers >> > are encrytped then network security policiy that relies on the >> > information will need to change=2E >> >> The folks running networks might as well argue that if you want your >> protocol to be successfully deployed (or at all deployed), your >protocol >> might need to change=2E >> >Perhaps, but in order to change the protocol to satisfy the >requirements of folks running networks, we'd need to know *what* the >requirements are=2E For instance, if someone were to say that networks >require more information than what is in the IP header to successfully >deliver packets, then I will immediately ask that they specify >*exactly* what information they need=2E [SM] While I only run my own home network, and hence only marginally quali= fy network operator at best, I do use per-flow queueing, currently based on= a 5-tupel, ot dst/src IP addresses, protocol, and dst/src port=2E That wor= ks amazingly well, so if possible I would like to be able to keep getting a= ccess to a stable representation of the port numbers, but I do not care whe= ther these stable representations are veridical or hashed, and I don't care= about an occasional hash collision=2E Since I am vaguely familiar with game theory, I would very much like to be= able to access the same field as used by the protocol itself (as anything = that can be gamed for an undeserved advantage, will be gamed)=2E That is so= mething like IPv6's flowlabel is less ideal than the real port numbers=2E Best Regards Sebadtian Until/unless that is answered we >are left guessing as to what may or may not be acceptable in various >networks and the tussle continues=2E > >> It's a tussle=2E ANd I see valid arguments on both sides=2E >> >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont@si6networks=2Ecom >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E