Re: [tsvwg] Remaining issues for draft-ietf-tsvwg-udp-options-22

[Erik Auerswald <[e-mail]>]

Hi,

On Mon, Jun 26, 2023 at 10:03:00AM +0100, Gorry Fairhurst wrote:
> The ID-Cutoff deadline of 2023-07-10, and I thought it might be
> helpful for us all to see where we are !
> 
> The current active issues that I saw are (please update as needed):

I have read draft-ietf-tsvwg-udp-options-22 and would like to add some
issues to the list.

> * Section 9.4: Agreed text for the (simplest) way to handle options
> in fragments of a datagram.

I have to admit that I am utterly confused by section 9.4.

I do not understand how both "[n]on-terminal fragments never have
options after the fragment" and "The RDOS field enables the FRAG option
to precede other options in every fragment" can be true at the same time.

Then "Frag. Start" seems to only be defined for the non-terminal FRAG
option format, but it is also part of the terminal FRAG option format.

The RDOS description uses an IMHO suprising order to describe checks
regarding its value:

  - Case 1: RDOS > Frag. Start of the first fragment (offset=8)

  - Case 2: RDOS == end of the original IP packet

  - Case 3: RDOS < Frag. Start of the first fragment

It seems to me as if case 2 is a subset of case 1, i.e., I'd say that it
might be easier to comprehend the logic if case 1 would be tightened to:

  Frag. Start of the first fragment (offset=8) < RDOS < end of the
  original IP packet

It might also be helpful to specify how to treat RDOS == Frag. Start of
the first fragment.

It might be helpful to provide pictures of IP packets comprising a
fragmented UDP Options packet, in the style of figure 19.

I would like to suggest considering a complete rewrite of the FRAG
description.

> * Section 9.8: Resolution of discussion on timestamp RTT processing.
> 
> * Section 9.9: Authentication: Query in WGLC about whether this is
> sufficiently mature for LC as PS, and suggestion that this is placed
> in a separate draft (resolution needed).
> 
> * Section 10.1: Encryption: WGLC noted this would be a down-ref and
> should not be a part of a PS (resolution needed - GF will propose on
> list).
> 
> * Section 13: A note in this section could be added indicating that
> use of UDP options is optional and that an Upper Layer (e.g. one
> providing security functions) could disable use of UDP options.
> 
> * Section 16: There was one question about where NAT traversal is
> discussed - One step might be to rename this section: " Interactions
> with Legacy Hosts and Legacy Devices on the Path"?
> 
> * Section 22: Request for the security considerations to mention
> potential for privacy exposure when using with an upper layer
> protocols that protect privacy.
> 
> * Other discussion, not in current draft: Is there a need
> for/implementation experience with one-way delay measurements or is
> this future work?
> 
> Are there other key issues?
> 
> -
> 
> NiTs, various, including:
> 
> UDP options in titles should be consistenly written as UDP Options
> (e.g. see section 15 title).

* Section "9.6 Maximum Reassembled Datagram Size (MRDS)" uses "Maximum
  Reassembled Segment Size" in the text, and uses "largest reassembled
  UDP segment that can be received".  I'd think that using "datagram"
  instead of "segment" would be more consistent with the other parts of
  the draft and with the option name and abbreviation.

* Section 9.7: It might be helpful to state that RES is supposed to echo
  the token from the REQ option it is answering.

* Section 9.10: The first sentence of the last paragraph reads a bit
  weird:

  "Assigned UDP experimental IDs (ExIDs) assigned from a single registry
  managed by IANA (see Section 23)."

  Could this be reworded, e.g., as follows?

  "UDP experimental IDs (ExIDs) are assigned from a single registry
  managed by IANA (see Section 23)."

* Section 10:  I do not understand the first sentence:

  "UNSAFE options are not safe to ignore and can be used unidirectionally
  or without soft-state confirmation of UDP option capability."

  Should there be a "not" added to the "can"?

  "UNSAFE options are not safe to ignore and cannot be used
  unidirectionally or without soft-state confirmation of UDP option
  capability."

  Otherwise, could the sentence be shortened to omit everything starting
  with "and"?  That would make it less confusing, I think.

  "UNSAFE options are not safe to ignore."

* Section 11: I'd suggest that the first two rules could use "SAFE
  options" instead of just "options" in order to indicate that the rules
  do allow new UNSAFE options.

* Section 12: The inner if clauses in the pseudo-code seem to be
  inconsistent:

  When (OCS == 0 and UDP CS != 0), both sub-clauses of the second outer
  if clause are true, and thus the options need to be both ignored
  (first sub-claused) and processed (second sub-clause).

* Section 17: The sentence comprising the second to last paragraph seems
  to be missing the word "to":

  OLD:

   UDP options that rely on soft-state exchange need allow for message
   reordering and loss, in the same way as UDP applications [RFC8085].

  NEW:

   UDP options that rely on soft-state exchange need to allow for message
   reordering and loss, in the same way as UDP applications [RFC8085].

* Section 20: The second to last sentence / paragraph seems to be missing
  a "with":

  OLD:

   This document is consistent the UDP profile for Robust Header
   Compression (ROHC)[RFC3095], noted here:

  NEW:

   This document is consistent with the UDP profile for Robust Header
   Compression (ROHC)[RFC3095], noted here:

* Section 22: The second paragraph seems intended to compare UDP options
  with TCP options, but it uses only "UDP", resulting in the tautology
  that the UDP security implications are not substantially different
  from security implications of UDP options:

  OLD:

   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;

  NEW:

   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 TCP options;

* Section 22: The second to last paragraph on page 35 states that
  "no options (including ECHO) ever initiate UDP responses in the
  absence of user transmission."  I think "ECHO" means "REQ", but
  draft-ietf-tsvwg-udp-options-dplpmtud-08 allows for REQ to create
  responses without use data, specifically when DPLPMTUD is implemented
  inside the "Packetization Layer of UDP Options".  This seems to be
  inconsistent.

* Section 22: There seems to be a stray "either" in the first paragraph
  of page 37:

  OLD:

   […]SHOULD detect excessive numbers of such occurrences and limit
   resources they use, either through silent packet drops.

  NEW:

   […]SHOULD detect excessive numbers of such occurrences and limit
   resources they use through silent packet drops.

* Section 22: The third paragraph on page 37 seems to intend to describe
  that UDP user data might be dropped because of option processing,
  if the receiver is configured to do so.  But to me this seems to be
  confusingly worded, and I'd like to suggest a rewording:

  OLD:

   […]All other options
   default to being silently ignored at the transport layer but may be
   dropped either if that default is overridden[…]

  NEW:

   […]All other options
   default to being silently ignored at the transport layer but may
   cause UDP data to be dropped either if that default is overridden[…]

* Section 23: The last paragraph of page 37 confuses me.  I would like
  to suggest an IMHO simpler rewording:

  OLD:

   Although option nicknames are not used in-band, new UNSAFE safe
   option names SHOULD commence with the capital letter "U" and avoid
   either uppercase or lowercase "U" as commencing safe options.

  NEW:

   Although option nicknames are not used in-band, new UNSAFE option
   names SHOULD commence with the capital letter "U".  New SAFE options
   SHOULD NOT commence with either uppercase or lowercase "U".

  (This paragraph might deserve a ">>" marker to indicate use of BCP 14
  key words.)

* Appendix A: The socket options table seems to be missing quite a few
  underscores ('_') in definition names.

* Appendix A: The contents of page 44 could be added to page 43.  I think
  the last two non-blank content lines of page 43 should be deleted,
  because they are also part of the beginning of page 44.

Best regards,
Erik