Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-21 and -22
"C. M. Heard" <heard@pobox.com> Mon, 19 June 2023 16:49 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 C2C27C151556 for <tsvwg@ietfa.amsl.com>; Mon, 19 Jun 2023 09:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.096
X-Spam-Level:
X-Spam-Status: No, score=-7.096 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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 skPuDYuz0fwF for <tsvwg@ietfa.amsl.com>; Mon, 19 Jun 2023 09:49:11 -0700 (PDT)
Received: from pb-smtp21.pobox.com (pb-smtp21.pobox.com [173.228.157.53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887B1C14CE3B for <tsvwg@ietf.org>; Mon, 19 Jun 2023 09:49:10 -0700 (PDT)
Received: from pb-smtp21.pobox.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id C6D652364C for <tsvwg@ietf.org>; Mon, 19 Jun 2023 12:49:08 -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:content-type; s=sasl; bh=KCt9M6//LTo42VAppsxaIEZpaMJ0LZbWGeX vzq0QXlE=; b=Is+52y4FX5ONlPQoaI38rbAeZDeUVDrn2HSmqZo264d8M0EO+j6 Q8fqUmWq3yYtBRf2vYiLdpxZSBgJBwQn6vQIF4Q9Qci5nDL84WqUbox7dFMl3K9V DUX8pCPyBYiGHXcGHfdf9VhlB5inm5TxhgBVMG/vvl7oipl891t5JL5U=
Received: from pb-smtp21.sea.icgroup.com (unknown [127.0.0.1]) by pb-smtp21.pobox.com (Postfix) with ESMTP id BF7242364B for <tsvwg@ietf.org>; Mon, 19 Jun 2023 12:49:08 -0400 (EDT) (envelope-from heard@pobox.com)
Received: from mail-lj1-f174.google.com (unknown [209.85.208.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp21.pobox.com (Postfix) with ESMTPSA id C418C2364A for <tsvwg@ietf.org>; Mon, 19 Jun 2023 12:49:05 -0400 (EDT) (envelope-from heard@pobox.com)
Received: by mail-lj1-f174.google.com with SMTP id 38308e7fff4ca-2b46a06c553so32780311fa.1 for <tsvwg@ietf.org>; Mon, 19 Jun 2023 09:49:05 -0700 (PDT)
X-Gm-Message-State: AC+VfDzoLvCPAFYSRnnta9vOSGLNCROwsbI6Nc8oIB7h/YUndwnUXJqd Tu7RRhHfxmk5GWBoTMDS013btxqivE5Z8a6WKJk=
X-Google-Smtp-Source: ACHHUZ5heTrTvASvGoJaiTQqrril92MpcyRr3G9UD5xf+m7vrI5/G1RsGWwW1R49P3tW/0ST/P6IXkCM9hn0lTqh308=
X-Received: by 2002:a2e:914b:0:b0:2b4:7256:f9c3 with SMTP id q11-20020a2e914b000000b002b47256f9c3mr2742848ljg.13.1687193343600; Mon, 19 Jun 2023 09:49:03 -0700 (PDT)
MIME-Version: 1.0
References: <CACL_3VEQdQa5oRn1bfcy-tA0TGiHxkSC-iquMk3kJrgPpJmRLA@mail.gmail.com>
In-Reply-To: <CACL_3VEQdQa5oRn1bfcy-tA0TGiHxkSC-iquMk3kJrgPpJmRLA@mail.gmail.com>
From: "C. M. Heard" <heard@pobox.com>
Date: Mon, 19 Jun 2023 09:48:51 -0700
X-Gmail-Original-Message-ID: <CACL_3VFdBVW1cTK7L2zyTDyJq0ju6r5wK1NUep2C8XRbFc0+wQ@mail.gmail.com>
Message-ID: <CACL_3VFdBVW1cTK7L2zyTDyJq0ju6r5wK1NUep2C8XRbFc0+wQ@mail.gmail.com>
To: TSVWG <tsvwg@ietf.org>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Joe Touch <touch@strayalpha.com>
Content-Type: multipart/alternative; boundary="000000000000e9ae9d05fe7e4f2b"
X-Pobox-Relay-ID: 33F3DCD2-0EC1-11EE-9993-B31D44D1D7AA-06080547!pb-smtp21.pobox.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/_Hno_pV6DCWKZIV9L7tDRlzcyms>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-21 and -22
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: Mon, 19 Jun 2023 16:49:15 -0000
I missed this: in draft-ietf-tsvwg-udp-options-22 Section 9.6 we see The Maximum Reassembled Segment Size (MRDS, Kind=5) option is a 16- bit indicator of the largest reassembled UDP segment that can be received. MRDS is the UDP equivalent of IP's EMTU_R but the two are not related [RFC1122]. Using the FRAG option (Section 9.4), UDP packets can be transmitted as transport fragments, each in their own (presumably not fragmented) IP datagram and be reassembled at the UDP layer. Both occurrences of "segment" need to be replaced by "datagram". My apologies for not commenting on this when it first showed up in -16. ---------- Original Message --------- From: C. M. Heard <heard@pobox.com> Date: Sun, Jun 18, 2023 at 4:13 PM Subject: Comments on draft-ietf-tsvwg-udp-options-21 and -22 To: TSVWG <tsvwg@ietf.org>, Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Joe Touch <touch@strayalpha.com> On Mon, May 22, 2023 at 6:21 AM Gorry Fairhurst wrote: > I have just read version 20, and I have some questions as a working > group member. I hope this helps. [ ... ] > > 12. "Values should "increase" (allowing for rollover) according to a > typical 'tick' time" > - explain rollover in terms of the modulo the field size? and in draft-ietf-tsvwg-udp-options-22 Section 9.8 we now see: o Values should "increase" (allowing for rollover, i.e., modulo the field size) according to a typical 'tick' time where "modulo the field size" is new text. But later on (in text that has been around for several versions) we see: Rollover can be handled as a special case or more completely using sequence number extension [RFC9187], however zero values need to be avoided explicitly. >> TIME values MUST NOT use zeros as valid time values, because they are used as indicators of requests and responses. Since the value zero is not a value time value, it is incorrect to say that values should increment modulo the field size, i.e., modulo 2^32. At most they can increment modulo 2^32 - 1. In fact, though, if time values are incremented modulo 2^32 - 1, using output values in the range 1 through 2^31-1, what you have is nothing more than conventional ones complement arithmetic, and the difference between an echoed time stamp received in a response and the current time value when it that response is received can be reliably calculated through a rollover event by using ones complement arithmetic. I've commented on this point before, and I've received resistance on the grounds that such an interpretation is unnecessarily constraining. Well, I don't agree. I think being explicit on this point will enhance interoperability and predictability with insignificant constraints. If there is disagreement, I'd like to hear of an alternative scheme that accomplishes the same things within the constraints of a 32-bit field width and avoidance of the value zero. In any case, "modulo the field size" is not correct ======================================================================= In draft-ietf-tsvwg-udp-options-22 Section 9.1 we see >> Bytes after EOL in the surplus area MAY be checked as being zero on receipt, but MUST be treated as zero regardless of their content and are not passed to the user (e.g., as part of the surplus area). Do the words "MUST be treated as zero regardless of their content" mean that an implementation that does not verify that bytes after EOL are in fact equal to zero have to exclude them from the OCS validation? Doing so would not play well checksum offload (see https://mailarchive.ietf.org/arch/msg/tsvwg/9_1YWp-TApI9mcCuia8U6jfCwTA/). I therefore propose this replacement text: >> Bytes after EOL in the surplus area MAY be checked as being zero on receipt but MUST NOT otherwise be processed (except for OCS calculation) or passed to the user. This comment was made originally against -19 on 27-Jan-2023 but was not addressed. ======================================================================= In draft-ietf-tsvwg-udp-options-22 Section 9.4 we see: >> Similar to IPv6 reassembly [RFC8200], if any of the fragments being reassembled overlap with any other fragments being reassembled for the same UDP packet, reassembly of that UDP packet MUST be abandoned and all the fragments that have been received for that UDP packet must be discarded, and no ICMP error messages should be sent in this case (to avoid a potential DOS attack turning into an ICMP storm in the reverse direction). and >> UDP reassembly expiration MAY generate an ICMP error, but this MUST NOT use the existing IP reassembly timeout error type and code. [TBD: ?? Should we define a new code for this purpose?] In my opinion, any mention of sending ICMP errors for UDP reassembly failures is totally out of place, and all mention of this should be removed from Section 9.4. Sending ICMP messages is a function of the IP layer, not of the UDP layer (or any other transport layer). My apologies for not commenting on this when it first showed up in -14. ======================================================================= In draft-ietf-tsvwg-udp-options-22 Section 12 we see: if the UDP checksum passes or is zero then if ((OCS != 0 and fails or OCS == 0) and UDP CS != 0) or ((OCS != 0 and passes) and UDP CS == 0) then deliver the UDP user data but ignore other options (this is required to emulate legacy behavior) if OCS != 0 and passes or OCS == 0 when UDP CS != 0 then deliver the UDP user data after parsing and processing the rest of the options, regardless of whether each is supported or succeeds (again, this is required to emulate legacy behavior) Corrected: if the UDP checksum passes or is zero then if OCS != 0 and fails or OCS == 0 when UDP CS != 0 then deliver the UDP user data but ignore other options (this is required to emulate legacy behavior) if OCS != 0 and passes or OCS == 0 when UDP CS == 0 then deliver the UDP user data after parsing and processing the rest of the options, regardless of whether each is supported or succeeds (again, this is required to emulate legacy behavior) This comment was made originally against -19 on 27-Jan-2023 but was not addressed. ======================================================================= In draft-ietf-tsvwg-udp-options-22 Section 22, 2nd paragraph, we see: Note that any user application that considers UDP options to affect security need not enable them. However, their use does not impact security in a way substantially different than UDP options; both enable the use of a control channel that has the potential for abuse. Similar to TCP, there are many options that, if unprotected, could be used by an attacker to interfere with communication. The phrase "substantially different than UDP options" should be changed to "substantially different than TCP options." This comment was made originally against -19 on 27-Jan-2023 but was not addressed. ======================================================================= In draft-ietf-tsvwg-udp-options-22 Section 22, 3rd paragraph, we see: UDP options create new potential opportunities for DDOS attacks, notably through the use of fragmentation. Except when enabled, UDP options cause no additional work at the receiver. At most, the required options (if enabled) result in a responding option in the next transmitted packet, but no options (including ECHO) ever initiate UDP responses in the absence of user transmission. Corrected: UDP options create new potential opportunities for DDOS attacks, notably through the use of fragmentation. When enabled, UDP options may cause some additional work at the receiver; however, of the must-support options, only REQ (when used on a DLPMTUD probe [Fa22]) will initiate a UDP response in the absence of a user transmission. Note that [Fa22] needs to be updated to [Fa23]. This comment was made originally against -19 on 27-Jan-2023 but was not addressed. ======================================================================= The unaddressed comments mentioned above can be found in https://mailarchive.ietf.org/arch/msg/tsvwg/aGOHvmGfSTRs4ATgEEpqHrWAln4/. I also commented there on the need to replace turn [To18] (draft-touch-tcp-ao-encrypt) by a stable, normative reference, but I won't belabor that, since it's part of a larger ongoing discussion. Thanks and regards, Mike Heard
- [tsvwg] Comments on draft-ietf-tsvwg-udp-options-… C. M. Heard
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- [tsvwg] Comments on draft-ietf-tsvwg-udp-options-… C. M. Heard
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Sebastian Moeller
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Sebastian Moeller
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… touch@strayalpha.com
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Gorry Fairhurst
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Tom Herbert
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Sebastian Moeller
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Gorry Fairhurst
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Sebastian Moeller
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… C. M. Heard
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… Sebastian Moeller
- Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-opti… C. M. Heard
- [tsvwg] Remaining issues for draft-ietf-tsvwg-udp… Gorry Fairhurst
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Sebastian Moeller
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Gorry Fairhurst
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… C. M. Heard
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Tom Herbert
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Gorry Fairhurst
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… C. M. Heard
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Tom Herbert
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… C. M. Heard
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Tom Herbert
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Gorry Fairhurst
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Tom Herbert
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Gorry Fairhurst
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Tom Herbert
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Gorry Fairhurst
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Erik Auerswald
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Tom Herbert
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Gorry Fairhurst
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… C. M. Heard
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Erik Auerswald
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Erik Auerswald
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… C. M. Heard
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Gorry Fairhurst
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Erik Auerswald
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Sebastian Moeller
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Christian Huitema
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Gorry Fairhurst
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… C. M. Heard
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Erik Auerswald
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Erik Auerswald
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Tom Herbert
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… C. M. Heard
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… Tom Herbert
- Re: [tsvwg] Remaining issues for draft-ietf-tsvwg… C. M. Heard