Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32
"C. M. Heard" <heard@pobox.com> Thu, 04 April 2024 21:22 UTC
Return-Path: <heard@pobox.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 85AECC1519A4; Thu, 4 Apr 2024 14:22:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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_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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com
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 n3BbdMJ8heXh; Thu, 4 Apr 2024 14:22:27 -0700 (PDT)
Received: from pb-smtp20.pobox.com (pb-smtp20.pobox.com [173.228.157.52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5691AC1840D1; Thu, 4 Apr 2024 14:22:21 -0700 (PDT)
Received: from pb-smtp20.pobox.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id D197C1DEB9; Thu, 4 Apr 2024 17:22:18 -0400 (EDT) (envelope-from heard@pobox.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h= mime-version:references:in-reply-to:from:date:message-id:subject :to:cc:content-type; s=sasl; bh=xZhiTJ9HtyoqGWsb9gDl+HmI96tZ8h09 FdmGYWPh03s=; b=lE0fqwN+3/ij6xBu2ybbmJHtQpXZ8vENf1CN6T2t67az8wEb IyLGOn/k6t5yQvv/CjhP+CLErMew5xjQARBNisL+qvtH+gHhu9QeYFKdy+jpUwHF SznO+I7sgkPaEoT1TlB51FwilywQ1dawnhX36AnFhQZ01FRcMcbG7CL8E30=
Received: from pb-smtp20.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp20.pobox.com (Postfix) with ESMTP id CA52E1DEB8; Thu, 4 Apr 2024 17:22:18 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-lf1-f47.google.com (unknown [209.85.167.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp20.pobox.com (Postfix) with ESMTPSA id 7AD501DEB7; Thu, 4 Apr 2024 17:22:15 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-lf1-f47.google.com with SMTP id 2adb3069b0e04-516d3a470d5so80930e87.3; Thu, 04 Apr 2024 14:22:15 -0700 (PDT)
X-Forwarded-Encrypted: i=1; AJvYcCUrNbW4gzMhzzMwjRXKmiQIHQiOOHud/vzZcdBxHbcuTcXP1uabPiOPp0z/tj+pCTYKGpDq0YV+d1Anefk/JdFRhCvW/UJFoe08pILD1TJjlFi1QxFUV623zA==
X-Gm-Message-State: AOJu0Yx8q2HIMiuepFkkN+CnleEwzShtRv/QT7zvbGnGxtDiw8Ha1y7I OZI14m/Mqi+22UdQZf3WNCKYUpbJbEhEfYafTw/16aSUB3r02kK1aRwfCMjqjy6QEe3KJbnlD0L cpjo/euBn3B+6jUu/NB8j1/SkTsk=
X-Google-Smtp-Source: AGHT+IF58CT3xylCuz5xMzUalKtGogdyMMqUpmIytFlYhqAsuqwfC+ICurZ2N9ycOA4BEALHyyoaQpfawcLgBW2bdX8=
X-Received: by 2002:a05:6512:49a:b0:516:be61:7688 with SMTP id v26-20020a056512049a00b00516be617688mr411726lfq.22.1712265733152; Thu, 04 Apr 2024 14:22:13 -0700 (PDT)
MIME-Version: 1.0
References: <CAM4esxSpwRF5E3Xc_hotgvCSdKVe4BY_zRUKAzHvW48JEtWqTA@mail.gmail.com>
In-Reply-To: <CAM4esxSpwRF5E3Xc_hotgvCSdKVe4BY_zRUKAzHvW48JEtWqTA@mail.gmail.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Thu, 04 Apr 2024 14:22:00 -0700
X-Gmail-Original-Message-ID: <CACL_3VGOLkJU1m7pqSXRRouCKwdQ6yrbmaPwoa22Jr-N3FZNzA@mail.gmail.com>
Message-ID: <CACL_3VGOLkJU1m7pqSXRRouCKwdQ6yrbmaPwoa22Jr-N3FZNzA@mail.gmail.com>
To: Martin Duke <martin.h.duke@gmail.com>
Cc: tsvwg <tsvwg@ietf.org>, draft-ietf-tsvwg-udp-options.all@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c933c206154beef4"
X-Pobox-Relay-ID: 68C55A98-F2C9-11EE-8E41-F515D2CDFF5E-06080547!pb-smtp20.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/nLIpfkI1X1GbxG5cqgIpcajWQK4>
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: Thu, 04 Apr 2024 21:22:31 -0000
On Tue, Apr 2, 2024 at 2:23 PM Martin Duke wrote: > Here is a somewhat late individual review of the udp-options draft, since > I purposely didn't read it when I thought I'd have to review it as an AD > evaluatoin. > Thank you, Martin, for these thoughtful comments. I have some responses in-line below, made from my perspective as a proponent. > Major comments: > - I'm impressed with the overall cleverness and elegance of this solution, > particularly the use of FRAG to contain unsafe options in a zero-length > datagram. > > - 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. > - This is an attractive nuisance for various path signaling schemes. They > are going to come here because other avenues (DSCP, IPv6 Extension Headers) > have been blocked. And that eventually UDP options will be blocked for the > same reason that those were blocked. I suppose that enough fortitude in > TSVWG can forestall this happening. Personally, I would strongly encourage > these efforts to use encapsulation, or any other mechanism, to avoid > compromise of the E2E channel you are building here. > - To the extent that new options are "opt-in" by the endpoint, I'm fine > with it. But if we reach a point where identifying signals are required by > the network to participate, that's not so great. I'm not sure that this > architecture has much in the way of safeguards to prevent that outcome. > > This isn't really actionable because I genuinely don't know what to do, > and luckily for me, I don't have to decide anymore. But I ask the > proponents and the working group to reflect on this a bit more. And we > should consciously decide, as a community, if path signaling over UDP is a > thing we support or not. > TSVWG went over this ground, to some extent at least, during the initial discussions of the initial versions of draft-reddy-tsvwg-explcit-signal (now expired) and draft-kaippallimalil-tsvwg-media-hdr-wireless (still active). After several threads in which the merits of using UDP options for host-to-network signaling was discussed (see, e.g., Challenges for host to network signaling via UDP Options <https://mailarchive.ietf.org/arch/msg/tsvwg/SpcVd6EB1Zi6FUhhyn2-o6nxuq4/> and other messages in that thread), I think most in the WG came around to the position of *not* wanting to see UDP options used for host-to-network signaling, The chairs are, or course, the folks who can make authoritative statements, but that was my impression, at least. The current version of draft-kaippallimalil-tsvwg-media-hdr-wireless does propose to use UDP options for signaling, but as part of a tunnel encapsulation arrangement, which does not conflict with the desired E2E nature of UDP options. > Some minor points: > (11.4) It might be worth clarifying at the start that fragmentation is > purely E2E, not something that routers can do. > Is that not made clear enough by 16 <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options#section-16>. UDP Options are for Transport, Not Transit? (11.4) What if Frag. Start is inconsistent with the location of EOL? > Do you mean when Frag. Start points past the end of the packet? It was clear enough to me that this would be considered malformed and discarded, but maybe that's just me being too familiar with the intent, and not actually scrutinizing the text. > (11.4) 2 fragments/3000 bytes as a minimum will work, of course, but it > seems like an odd number. This seems to be related to the canonical 1500B > MTU, but that would imply that 2 fragments would be 2926 for IPv4 and 2886 > in IPv6, if my math is correct. (To be clear, I can live with 3000) > I had a similar clarification request about what the value of MRDS size (11.6) means. My assumption is that parameter means the size of the Original UDP Datagram (or equivalently, the size of the reassembled datagram) as shown in Figure 12. If that is the case, we would be referring to the size of the reassembled datagram EXCLUDING the IPv4 or IPV6 headers but INCLUDING the UDP header and UDP options transmitted over the wire in the surplus area. The exact numbers are not that important, but a clear definition is. It may be appropriate to open a Github issue covering these points. > (11.4) "the OCS value of the original packet SHOULD be zero if each > fragment will have a non-zero OCS value" > > I don't understand the purpose of this. First, it complicates packet > processing because the full datagram has to use a different OCS > verification path if it's reassembled. Second, if the fragment OCSes are > sufficient, why not simply say that the original packet MUST NOT have an > OCS option? > Actually, the idea was that reassembly could be implemented as a "bump in the stack" and that the handling of reassembled datagrams would not vary much from how it's done for datagrams that are not received as fragments. IPv4 (and under certain circumstances IPv6) allow zero UDP checksum. The OCS is mandatory when UDP checksum is non-zero and recommended (but not required) when the UDP checksum is non-zero. So an implementation already has to deal with datagrams that have UDP CS == 0 but OCS != 0. Given that, it seems (to me at least) fair to keep this as a SHOULD, as it does not require any mechanisms that are not otherwise required. (11.5) "MDS does not indicate a known path MTU and thus MUST NOT be used to > limit transmissions." > > I am not sure what it means "to limit transmissions". Can you elaborate? > What is the purpose of this if not to provide a hint of datagram size? Just > to seed PMTUD? > > (11.6) "NOPs are not reported to the user, whether used per-datagram or > per-fragment (as defined in Section 11.4)." > > I think this is a cut-and-paste error. > Agreed. > (11.7) Is the token generated by the UDP implementation or the upper > layer? Is there any guidance on how to choose the token (should it be > random or monotonically increasing? Is any method OK as long as they don't > repeat? Given that UDP is connectionless, what would it even mean that it > doesn't repeat?) > It was my understanding -- and maybe I am simply too close to the spec -- that the upper layer, or a library acting on its behalf, chooses the token value in a REQ option. I see text that says "Both the REQ and RES are under the control of these upper layers." Is this not sufficiently clear, especially after reading the normative reference [Fa24]? In closing I have a question for the document shepherd: are we going to go to WG last call on this version, and of so, should Github issues be opened to cover WGLC comments? Thanks Mike Heard
- 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