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

["[e-mail]" <[e-mail]>]

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 <[e-mail]> 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.