Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32
Christian Huitema <huitema@huitema.net> Tue, 09 April 2024 14:29 UTC
Return-Path: <huitema@huitema.net>
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 BC917C14F605; Tue, 9 Apr 2024 07:29:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5WW8BOMtbly; Tue, 9 Apr 2024 07:28:58 -0700 (PDT)
Received: from se04.mfg.siteprotect.com (se04.mfg.siteprotect.com [64.26.60.167]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9942CC14F619; Tue, 9 Apr 2024 07:28:58 -0700 (PDT)
Received: from smtpauth02.mfg.siteprotect.com ([64.26.60.151]) by se04.mfg.siteprotect.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1ruCSz-00A49z-QZ; Tue, 09 Apr 2024 10:28:55 -0400
Received: from [192.168.1.102] (unknown [172.56.169.185]) (Authenticated sender: huitema@huitema.net) by smtpauth02.mfg.siteprotect.com (Postfix) with ESMTPSA id 4VDSxp3DPFz2YRNHP; Tue, 9 Apr 2024 10:28:46 -0400 (EDT)
Message-ID: <b7f7b836-c625-445d-bd38-f5ed8f4ba757@huitema.net>
Date: Tue, 09 Apr 2024 07:28:45 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>, "Gorry (erg)" <gorry@erg.abdn.ac.uk>
Cc: "C. M. Heard" <heard@pobox.com>, Martin Duke <martin.h.duke@gmail.com>, tsvwg <tsvwg@ietf.org>, draft-ietf-tsvwg-udp-options.all@ietf.org
References: <CAEh=tcd2FzQxgbSivuX2cEg2FpsnkoqdFw5gMhrx3pkT_JV88Q@mail.gmail.com> <2BEB5CC3-BB54-4119-A20F-8497ED4B5AE2@erg.abdn.ac.uk> <CAEh=tccKg7YHYkwKZ978uaXmTkBu3zyA+WBAW=eBMKAh2PSVDw@mail.gmail.com>
Content-Language: en-US
From: Christian Huitema <huitema@huitema.net>
Autocrypt: addr=huitema@huitema.net; keydata= xjMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1RmvN J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsKWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAzjgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB8J+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
In-Reply-To: <CAEh=tccKg7YHYkwKZ978uaXmTkBu3zyA+WBAW=eBMKAh2PSVDw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=huitema@huitema.net
X-Originating-IP: 64.26.60.151
X-SpamExperts-Domain: mfg.outbound
X-SpamExperts-Username: 64.26.60.150/31
Authentication-Results: mfg.siteprotect.com; auth=pass smtp.auth=64.26.60.150/31@mfg.outbound
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.06)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9lTHS2jGyundoMqJZJm7JRPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5z5W83tr/6vNQtj+4/xevXo2Zybh0C7q2u3ACfXjTyoXiyb 5GIeP46iSHCD/hbqgmu1tKRQLPmP9InHnx1Brj2eX/LhG7FXTm6Tybw4nzs9RzpvjJMlRqtLYdVR m5o1UatFouhV/hTlnP3gizNJ4cCTbODl0npQ7QiJwO4ZFU5qPmw3eNeOhkLncll6ybXS3v37YzVM +DNLaG9EqC8HPWpqIecagTeih6ZIlZsKCgIlyj9V70oPWOV5e2jS1ELFlksEybI1sOftHmSKUCHC vcq0YTPNT555B5Mf73FCdrCIg3BXvrLBlKCVRjjdPbjQ4HnU/Pi2QiSAHmtoEaz2bwGM/SySBKPE LGmZ8koc19ew0uGF6ePhLVNfQ99xpFdqMeOtUvCxPaIM4Ou74wbpe1B+tPQt8ktwubmkyIGt5wqx bNYmyTxrQyWytnV+j2TEcDbyPOsQNm1yLTjGbseEpgCNV4nXdhmqZFgXvtwoyf4nBPqexC/FKmrB VQq3b2CTOB3jT+mbShou6hktCloTvTOZCr3KS+nSmfB/Le8WyggcZGNMyMGzGQ/sIq/J9wLEXmWK 2sg7fhU6xWMp7cHXwP7QnNBzJuL8Gr1cSOdPD+8kUhsGUBCdud6r3d8EwqZuwQA8bzhbGbYrpodL rvAd0KCRSdsy/sW8HAfzzH+4WszBuBOaHC5n55mAcO/V9SpUSv/jlorFXW3bhC79ikuI4jpG++Du IQUs/5JJj4C/n4CILpQjvpxZ7UPYmlSOVPdsu4mPA8mbzdTvSqWoD0J+HqTLBg2q5JoNYB0RxfVT 8C7NdH7HgAd3NkOV15aRTCT2yxkQ4sKVqNBqZI8EvH6iEaQNA0ktIwG6OzbKAMPdy8PF1PdjzQ6Y C7Heg3Xf7O1TOd5MkcPNRcApvSCyyqhSIIwVGOC+7ukCf411wDyLaL5NOLyFj7ORksGGTcv5Mk/R OpqvDd1+tpyI/Ju98coKLrIyoFerMg1nuEvMLfJEsg9sub8sFZYmujn9w1cwNWBS7bKnctmz90bX lncpPK4/0BcLB/aO4y6heshmOzypSUjkQYqPuKEgMyfBW022v5adAIlR7gKuJOz6hvTOYnc+46Ee YZuk+LRvHwhK/P1D2xoYX1AWGtsACu2JT7qExpH5i1stXXqfBUgOanr8kY4bkjzQpxo6McVVb7Dx QuoZigjAq/Q+PE9CfPRaI6O+XszhTgw=
X-Report-Abuse-To: spam@se02.mfg.siteprotect.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Z8vfZsgvJbDhSCdj6LBrFoGn-Eo>
Subject: Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.39
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, 09 Apr 2024 14:29:02 -0000
On 4/9/2024 6:09 AM, Zaheduzzaman Sarker wrote: > > > On Tue, Apr 9, 2024 at 12:48 PM Gorry (erg) <gorry@erg.abdn.ac.uk > <mailto:gorry@erg.abdn.ac.uk>> wrote: > > See below for my 2c. > > > On 9 Apr 2024, at 11:31, Zaheduzzaman Sarker > <zahed.sarker.ietf@gmail.com <mailto:zahed.sarker.ietf@gmail.com>> > wrote: > > > > Hi all, > > > > Putting my AD hat on, if we specify protocol features only for > endpoints to > > consume and not for endpoints to network, then we should make > sure that is > > case when we design and describe it. We cannot expect all the > > intermediaries are well behaved or features are used as intended when > > designed. From that point of view it is not good enough to send > information > > in clear and just say "UDP Options are for Transport, Not > Transit". With > > the current, well placed, scrutiny of privacy and security on all the > > protocols that IETF is producing- It would require a huge > exception to get > > it published. > > > > The questions I would like to get answer is - > > > > Is it OK for the endpoints to send information in UDP > options which > > can be read (only) by the transit nodes and react to it? if NO, > then how > > to prevent that to happen? > > > > //Zahed > > this is a transport/encapsulation that can be used without the > benefits of encryption.To me, this was already clear when the > working group asked to start this work (it certainly was made clear > after the work was adopted), and this spec developed over many years. > > > Right, many years have past and we should then recheck the consensus on > this. From the mentioned email discussions and views expressed here I am > not sure it is clear to me what consensus we have now. Could you also > please provide me any reference to the consensus? > > > > So. I think given this, it is OK for the endpoints to send > information in UDP options which can be read (only) by the transit > nodes and they can indeed react to this. That has always been > possible with tunnels, extension headers, and transports - at least > those not using transport encryption. This comes with positive and > negative impacts. > > In today’s world, a designer can choose to protect all of the > transport eg using QUIC - and many designs will follow that path. > Although, there is a large body of work in the IETF that still > directly uses UDP. That to me is OK if that best fits the use. > > > Yes, UDP should be considered as transport protocol. It would be good to > have a view on how many of those large body of work uses or envision to > use UDP options in clear. This would boost the motivation for this work > and back up the need of UDP options. Depending on the application stack, UDP is either a transport protocol or a transparent pass-through. Indeed, this is pretty much the intended design of UDP, as stated in RFC 768: "This protocol provides a procedure for application programs to send messages to other programs with a minimum of protocol mechanism." If the application stack is including its own transport protocol, then we are in the "pass-through" case. This is absolutely the case if the application stack includes QUIC, SCTP or DTLS, but there are other examples. In the pass-through examples, and especially when the application transport uses encryption, adding clear-text options does not add value. It destroys it, re-enabling surveillance despite encryption of the application. I think there should be a very clear mechanism for application to "opt-in" the usage of clear-text application, and that for applications that did not opt in the reception of clear-text options should be treated as a protocol error. -- Christian Huitema > > > The backwards compatibility with UDP was considered important in the > development of this Spec. > > > This point is absent, AFAIK in Section 16 of the draft now. > > //Zahed > > > Gorry > > > > >> On Fri, Apr 5, 2024 at 2:29 AM Christian Huitema > <huitema@huitema.net <mailto:huitema@huitema.net>> > >> wrote: > >> > >> > >> > >>> On 4/4/2024 2:22 PM, C. M. Heard wrote: > >>>> On Tue, Apr 2, 2024 at 2:23 PM Martin Duke wrote: > >>> > >>> ... > >>> > >>> - I appreciate the work to make this an end-to-end signal, > and that > >>> UDP has pre-existing limitations in this regard. I also > think the > >>> use cases are probably valuable. > >>> > >>> But in 2024, if we want to make rules about what the network > can and > >>> can't do, we enforce it with encryption and authentication. I > >>> recognize that these were originally in the draft, and were > removed > >>> for very good reasons. But I'm also worried that, if successful: > >>> - This will attract "helpful" middlebox functions like MSS > clamping >
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… C. M. Heard
- [tsvwg] Review of draft-ietf-tsvwg-udp-options-32 Martin Duke
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… C. M. Heard
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… touch@strayalpha.com
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Christian Huitema
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Martin Duke
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Martin Duke
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Zaheduzzaman Sarker
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Gorry (erg)
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Zaheduzzaman Sarker
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Christian Huitema
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Tom Herbert
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Christian Huitema
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Tom Herbert
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Christian Huitema
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Joe Touch
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… touch@strayalpha.com
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Sebastian Moeller
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… touch@strayalpha.com
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Zaheduzzaman Sarker
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Zaheduzzaman Sarker
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… C. M. Heard
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… C. M. Heard
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… touch@strayalpha.com
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Martin Duke
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… C. M. Heard
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… C. M. Heard
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Christian Huitema
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Christian Huitema
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… C. M. Heard
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Erik Auerswald
- [tsvwg] Discarding the UDP surplus area when prot… C. M. Heard
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… C. M. Heard
- Re: [tsvwg] Discarding the UDP surplus area when … Tom Herbert
- [tsvwg] github issue long term archiving[ wa… Sebastian Moeller
- Re: [tsvwg] Discarding the UDP surplus area when … Gorry Fairhurst
- Re: [tsvwg] Review of draft-ietf-tsvwg-udp-option… Zaheduzzaman Sarker
- [tsvwg] Resolving UDP Options Issue #52 C. M. Heard
- [tsvwg] Re: Resolving UDP Options Issue #52 C. M. Heard
- [tsvwg] Re: Resolving UDP Options Issue #52 C. M. Heard