Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32
"Gorry (erg)" <gorry@erg.abdn.ac.uk> Tue, 09 April 2024 10:48 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 E7967C14F61D; Tue, 9 Apr 2024 03:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 xJHG6QKZPRZ6; Tue, 9 Apr 2024 03:48:11 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8C463C14E515; Tue, 9 Apr 2024 03:48:08 -0700 (PDT)
Received: from smtpclient.apple (unknown [185.69.145.84]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 317701B001FC; Tue, 9 Apr 2024 11:48:02 +0100 (BST)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: "Gorry (erg)" <gorry@erg.abdn.ac.uk>
Mime-Version: 1.0 (1.0)
Date: Tue, 09 Apr 2024 11:47:50 +0100
Message-Id: <2BEB5CC3-BB54-4119-A20F-8497ED4B5AE2@erg.abdn.ac.uk>
References: <CAEh=tcd2FzQxgbSivuX2cEg2FpsnkoqdFw5gMhrx3pkT_JV88Q@mail.gmail.com>
Cc: Christian Huitema <huitema@huitema.net>, "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
In-Reply-To: <CAEh=tcd2FzQxgbSivuX2cEg2FpsnkoqdFw5gMhrx3pkT_JV88Q@mail.gmail.com>
To: Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com>
X-Mailer: iPhone Mail (20H330)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/bpgsSVcffNlMlMh3P8iCA7X1V6Y>
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 10:48:15 -0000
See below for my 2c. > On 9 Apr 2024, at 11:31, Zaheduzzaman Sarker <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. 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. The backwards compatibility with UDP was considered important in the development of this Spec. Gorry > >> On Fri, Apr 5, 2024 at 2:29 AM Christian Huitema <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