Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-20

"touch@strayalpha.com" <touch@strayalpha.com> Fri, 09 June 2023 03:58 UTC

Return-Path: <touch@strayalpha.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 79A12C151717 for <tsvwg@ietfa.amsl.com>; Thu, 8 Jun 2023 20:58:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.316
X-Spam-Level:
X-Spam-Status: No, score=-1.316 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_NEUTRAL=0.779, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 L88bkUenMjWS for <tsvwg@ietfa.amsl.com>; Thu, 8 Jun 2023 20:58:23 -0700 (PDT)
Received: from server217-2.web-hosting.com (server217-2.web-hosting.com [198.54.115.98]) (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 7A24CC151711 for <tsvwg@ietf.org>; Thu, 8 Jun 2023 20:58:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=/tD62MKzDFedCH28C5OhuPXT0q1dvTsk1tOIH+Fn/JI=; b=lTzHglJ+yCRMHvcrlN5TqgtxzI VdozITQmVpiS8BftqKmHYZnCWzRLU6G1t6TOeON6ItqYG6MKCu9MDWYkwMYxK4N+X3f9H7DNcfkFm 2VmHNszyLpj2/xEDEuntQStLhJfQpR9ZO43qUOaRxZgoauVJgzvOf5zhu2MTXzcCyisVEplshaQyn G+gFiDtN2RYMQD2X1mY45afEZTDlDaNJALVcn5zKdF+4lROE+q4C3mXRB64tKCTeSWUzlBFc7ntec 8z5DkpxhqoffNmwExUS70EzfXn27tIE5OlrsfhbUmqAccyfjqocy9ItwODlw7JiukiAp2HQcB3eAi FbEJM2Cw==;
Received: from [172.58.209.100] (port=55803 helo=smtpclient.apple) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from <touch@strayalpha.com>) id 1q7TGS-00GJWj-1n; Thu, 08 Jun 2023 23:58:21 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_116915D5-28DD-483C-9D7E-44D778B23A82"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\))
From: "touch@strayalpha.com" <touch@strayalpha.com>
In-Reply-To: <3e867434-5fb2-cf67-6226-fdfb0d736439@erg.abdn.ac.uk>
Date: Thu, 08 Jun 2023 20:58:02 -0700
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>
Message-Id: <8181B1B9-710E-4718-9F2D-E7A59928ED8A@strayalpha.com>
References: <3e867434-5fb2-cf67-6226-fdfb0d736439@erg.abdn.ac.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3731.600.7)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/HTmHW1zSBCvhxyqMYwaYecDaeLo>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-udp-options-20
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: Fri, 09 Jun 2023 03:58:27 -0000

Hi, Gorry,

Thanks for the detailed comments. All are included, with notes/discussion as below.

An update should appear shortly.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On May 22, 2023, at 6:21 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> I have just read version 20, and I have some questions as a working group member. I hope this helps,
> 
> Gorry
> 
> P.S. I plan to also re-read and send comments specifically on the security mechanisms in a week or so.
> 
> ----
> 
> 1. The text in Figure 1, uses "ToS", this ought to be updated in line with the terminology in RFC2474, and refer to this as the DS field.
> 
> 2. In Figure 4 legend:
> "here using one zero for alignment"
> I think it would be clear to say this is a byte, rather than just the value:
> "here using one zero byte for alignment"
> 
> 3. "UNSAFE options are used only in with",
> - I think this should be more like:
> "UNSAFE options are used only with"
> 
> 3. "ignored but passing the UDP payload to the user when not supported"
> - Would it be easier for reading, if there was a comma before the "but'?
> 
> 4. "Except for NOP, EXP, and UEXP, each option SHOULD NOT occur more
>    than once in a single UDP datagram."
> - what happens if, in the future, other options or replacements are actually defined? It seems hard to know whether there will ever be an updates.
> Could this instead be written as more like:
> "Extensions SHOULD NOT occur more than once in a single UDP datagram,
> the only specified extensions are NOP, EXP, and UEXP."

The next sentence is key, though - options can occur more than once, but for all except these three, additionally copies are ignored. This is important because it prevents ambiguity; any option that really needs more than one ‘instance' should do so within a single option codepoint.

> 5. "Impossible lengths
>    should indicate a malformed surplus area and all options silently
>    discarded."
> - Why ought this not be "SHOULD", and can we also modify the word order?
> Could this be written as:
> "An impossible length SHOULD be treated as an indication of a malformed surplus area and all options ought to be silently discarded.

I changed the last part to SHOULD silently be discarded.

> 6. " >> When the UDP options do not consume the entire surplus area, the
>    last non-NOP option MUST be EOL."
> - What is the required receiver behaviour when this is observed?

It’s stated a few sentences later - the idea is that we prefer this:

	opt1 opt2 … optN EOL zero zero zero

To this:

	opt1 opt2 … optN NOP NOP NOP NOP

Or this:
	opt1 opt2 … optN NOP NOP NOP EOL

I.e., don’t use pads to end-fill; simply use an EOL as quickly as possible and zero fill after.

> 7. ">> NOPs SHOULD NOT be used as padding before the EOL option. As a
>    one byte option, it need not be otherwise aligned."
> - Does this really matter for interoperation at the receiver?

No; it’s a SHOULD so option processing can stop as quickly as possible

> - I can see the argument that NOPs ought not to be used, but does this really need a keyword for receiver interoperability, or is this just good advice?

Yes - “Ought” is why it’s a SHOULD, not a MUST.

> 8. "on receipt but MUST be"
> - Please add a comma before "but".
> 
> 9. " >> UDP packets SHOULD NOT use more than seven consecutive NOPs,
>    i.e., to support alignment up to 8-byte boundaries. UDP packets
>    SHOULD NOT use NOPs at the end of the options area as a substitute
>    for EOL followed by zero-fill. "
> - What is the required receiver behaviour if consecutive NOPs are observed?

This was added because of a perceived potential for DOS via lots of NOPs.

I added text that persistent use SHOULD be logged as a potential DOS indicator.

> 10. " MUST be receive the"
> - Please omit "be".
> 
> 11. "Start pointer can indicate the start of the
>       original surplus area anywhere in the reassembled data."
> - Insert "The" ?
> 
> 12. "Values should "increase" (allowing for rollover) according to a
>       typical 'tick' time"
> - explain rollover in terms of the modulo the field size?
> 
> 13. " or intend optionally for
>    modification of any UDP options, including their new areas, in
>    transit."
> - I was unaware of what was intended here, perhaps this could be clearer?

Yes, reworded.

> 14. " UDP options are transport options. Generally, transport headers,
>    options, and data re not intended"
> - Please add "a" to make this "are not intended.."
> 
> 15. "Although option nicknames are not used in-band, new UNSAFE safe
>    option values SHOULD commence with the letter "U" and avoid that
>    letter as commencing safe options."
> - Query: Please clarify: Is this intended as a capital "U", a small "u", or both cases?

Reworded; start with U, avoid both U and u in other names.

> 16. " Future options MUST NOT be defined as having a value
>    dependent on the contents of the surplus area."
> - This troubles me, because it seeks to limit evolution in the future,
> albeit for good reason. I'm not saying we should expect this type of change, but then I don't
> also know that somebody might propose something that is useful in future.
> - I wondered if it is wiser to say that we don't expect options
> to define this, and any case that does, then has to explain how it will
> co-exist with existing deployments, etc.

This becomes a problem because it would allow an option that isn’t an option. IMO, anyone wanting to use that space needs to have a codepoint assigned and use it to indicate the meaning of that field.

I don’t think that’s constraining; IMO, that’s just ensuring everyone plays by the same rules in that area of the packet.

I’ve added explanation to that effect.

> 17. "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."
> I this doesn't explain why this is required or recommended for the receiver,
> what happens when the assembly doesn't complete and the data is truncated.

That’s a timeout - as stated later. Partial reassembly MUST NOT be forwarded to the user - as stated even later.

> - why not require this with MUST?

Good point. This is just about when fragments overlap.

> - I also don't yet see why this ought not to be "ICMP error messages SHOULD NOT be sent", since I think that can have implications on end-to-end operation.

It’s only for fragment overlap. That should only happen due to DOS or incorrect implementation. We don’t want a DOS in one direction to cause an ICMP storm In the other. I’ll note that.

>> So should we define a new ICMP code for non-overlapping cases? It could be new code 2 for type 11 defined as UDP reassembly time exceeded, ir we could define a new type for this and other UDP errors.

> 18. ">> UDP options that rely on soft-state exchange MUST allow for
>    message reordering and loss."
> - This is a normative requirement currently, but I do not understand why this is a requirement, it is surely a reality that designs need to accommodate. For instance, RFC 8085 said "Therefore,
>    UDP-based applications need to be robust to reordering and delay.”

It’s better restated non-normatively.