[tsvwg] Mike Heard's WGLC for comments for draft-ietf-tsvwg-udp-options-32

["C. M. Heard" <[e-mail]>]

Greetings,

My WGLC comments on draft-ietf-tsvwg-udp-options-32 follow below.
References to github issues (some newly created) are included. As a
top-level summary, I have supported publication of this document as an RFC
for a long time, and I think it's almost ready to ship. Kudos to Joe Touch
for a job well done.


*Section 3. Terminology*

I concur with Tom Herbert's request to provide a crisp definition of SAFE
and UNSAFE (Issue #40
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/40>) in
Section 3 (Issue #35
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/35>).
Proposed text is provided in comments to the latter issue.


*Section 6. UDP Option Design Principles*

In  https://mailarchive.ietf.org/arch/msg/tsvwg/xC4M6R0nAmSLgjC-2yGgffk37YI/
 Zahed Sarker that text be added noting that backwards compatibility was
considered important in the development of the spe. I think that this is
adequately addressed in Section 6. See
https://mailarchive.ietf.org/arch/msg/tsvwg/BM7w7mTduw82p__PzK2ht5fnfT4/
 and Issue #43
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/43>.


*Section 9. The Option Checksum (OCS)*

I see that Med Boucadair (see
https://mailarchive.ietf.org/arch/msg/tsvwg/4F5sQrfPAJ4rn0PHdJMdioi0Um8/
 and Issue #32
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/32>) has
proposed to include a two-byte magic number in front of the OCS. Given the
complete lack of evidence for any existing non-standard uses of the surplus
area, I am not convinced that this is necessary, but I would not object if
it would once and for all put to that issue to bed (see Tom Herbert's
review
https://mailarchive.ietf.org/arch/msg/tsvwg/qbc3I4qHDHj43vBrJWJFKoI-Byk/ and
Issue #38 <https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/38>
).


*Section 10. UDP Options*

   >> UDP options MUST be interpreted in the order in which they occur
   in the surplus area.


Options can also appear in fragments, where they "are processed before the
fragment is included in the reassembled datagram."  Proposed fix:

   >> UDP options MUST be interpreted in the order in which they occur
   in the surplus area or in the options area of a UDP fragment (as
   defined in Section 11.4).


See Issue #46
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/46>.

   >> Each option SHOULD NOT occur more than once in a single UDP
   datagram, the only exceptions being NOP, EXP, and UEXP. If an option
   other than these occurs more than once, a receiver MUST interpret
   only the first instance of that option and MUST ignore all others.
   Section 24 <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options#section-24>
provides additional advice for DOS issues that involve
   large numbers of options, whether valid, unknown, or repeating.

   >> EXP and UEXP MAY occur more than once, but SHOULD NOT occur more
   than once using the same ExID (see Sections 11.10
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options#section-11.10>
and 12.3 <https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options#section-12.3>).


The "first instance only" rule is not respected in the existing
instructions on what to do with per-fragment instances of MDS, MRDS, REQ,
RES, and TIME (see sections 11.5 through 11.8). The instructions for MDS
and MRDS recommend reporting the minimum value received; the instructions
for REQ and RES recommend reporting the the most recent i.e., last) value
received; and the instructions for TIME recommend reporting the minimum and
maximum values without specifying what value should be reflected to the
remote end (if the values in question are TSVALs). And none of these
instructions are explicit about what to do if one of these options is
received both in a fragment and in the surplus area of the corresponding
reassembled UDP packet.

The main use that I see for allowing MDS, MRDS, REQ, RES, and TIME on UDP
fragments (including atomic ones) is "to provide limited support for UDP
options in systems that have access to only the initial  portion of the
data in incoming or outgoing packets," as noted near the end of Section
11.4. For that use case, it would IMO suffice to stipulate that the first
instance received is the one reported to the upper layer, thus sustaining
the text quoted above, and I recommend that the per-frag text in sections
11.5 through 11.8 be modified accordingly.

See Issue #47
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/47>

   >> "Must-support" options other than NOP and EOL MUST be placed by
   the transmitter before other UDP options and a receiver MUST drop
   all UDP options in such malformed packet (i.e., in which this
   ordering is not honored) and that event MAY be logged for
   diagnostics (logging SHOULD be rate limited).

   The requirement that must-support options come before others is
   intended to allow for endpoints to implement DOS protection, as
   discussed further in Section 24
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options#section-24>.


This rule does not work for certain proposed options such as UCMP (and
probably UENC), which must appear before other currently-defined options.
So the proper requirement to levy on the transmitter is that it SHOULD
place the "must-support" options before other UDP options. And even if this
were not the case, it would IMO be overly prescriptive to require that the
receiver drop the entire options area if this dictum is not respected. It
is out of line with the less prescriptive advice in Section 24 (and the
advice in Section 11.2 regarding repeated NOPs), which IMO is quite
sufficient.  Proposed replacement text:

   >> "Must-support" options other than NOP and EOL SHOULD be placed by
   the transmitter before other UDP options.

   The requirement that must-support options should come before others
   is intended to allow for endpoints to implement DOS protection, as
   discussed further in Section 24
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options#section-24>.


See Issue #48
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/48>.


*Section 11.1. End of Options List (EOL)*

Martin Duke pointed out that the description of EOL does not stipulate that
it terminates the per-fragment options area (see
https://mailarchive.ietf.org/arch/msg/tsvwg/8JBqbYF_fZp6MBhNVzuNMSGr4as/)
This is easily fixed with the following change throughout Section 11.1:

s/surplus area/surplus area or the options area in a UDP fragment/

See Issue #49
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/49>.


*Section 11.4. Fragmentation (FRAG)*

This section requires that if an instance of FRAG with a valid length (10
or 12, or possibly 12 or 14, if the extended length format is used) occurs
when UDP Length > 8, then the entire option area is considered malformed
and is discarded. I wanted to note that these instructions, combined with
those in Section 10, have the following implications for some other corner
cases:

   - A FRAG option with a length other than 10 or 12 (or 12 or 14, for
   extended length format) is treated as an unknown option and is ignored on
   receipt (i.e., skipped over), as long as the length is not impossible (less
   than 2 for a normal length or 4 for an extended length, or pointing past
   the end of the option area). This applies whether or not UDP Length == 8.
   - If there are multiple occurrences of otherwise valid FRAG options when
   UDP Length == 8, only the first one is processed; the remaining ones are
   ignored and skipped over.

IMO the behavior described above, if it is indeed a correct interpretation
of the spec, is fine. I just wanted to get confirmation that this is indeed
the intent of the spec (or if it isn't, to get clarification on what the
intent is).

See Issue #51
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/51>.


In https://mailarchive.ietf.org/arch/msg/tsvwg/dxL8px2Gri30qw2xTBes5UQohM4/,
Martin Duke wrote:

(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 also get 2926 for IPv4 and 2886 for IPv6, if we include the reconstituted
UDP header in the total. Not a big deal, of course, but for internal
consistency I suggest s/3000/2926/.

See Issue #52
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/52>.

   FRAG is not reported to the user, whether used per-datagram or per-
   fragment (as defined in Section 11.4
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options#section-11.4>).


Given that FRAG by definition can only be used per-fragment (as described
earlier in the section), it should be possible to simplify this text to:

   FRAG is not reported to the user.


See Issue #53
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/53>.


*Sec. 11.5 thru 11.8 - per-frag instances of MDS, MRDS, REQ, RES, & TIME*

As noted above on the remarks for Section 10, the main use that I see for
allowing MDS, MRDS, REQ, RES, and TIME on UDP fragments (including atomic
ones) is "to provide limited support for UDP options in systems that have
access to only the initial  portion of the data in incoming or outgoing
packets," as noted near the end of Section 11.4. For that use case, it
would IMO suffice to stipulate that the first instance received is the one
reported to the upper layer, thus sustaining the text quoted above, and I
recommend that the per-frag text in sections 11.5 through 11.8 be modified
accordingly. Note that the current instructions are not in all cases
consistent with Section 10.

As noted above, this is covered in Issue #47
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/47>.


*11.6. Maximum Reassembled Datagram Size (MRDS)*

I propose that the following text

   The Maximum Reassembled Datagram Size (MRDS, Kind=5) option is a 16-
   bit indicator of the largest reassembled UDP datagram that can be
   received.


be replaced with

   The Maximum Reassembled Datagram Size (MRDS, Kind=5) option is a 16-
   bit indicator of the largest reassembled UDP datagram that can be
   received, including the UDP header and any UDP options.


This is intended to clarify that the MRDS size is intended to be that of
the original UDP datagram shown in Figure 12, including all UDP options.

See Issue #54
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/54>.

In https://mailarchive.ietf.org/arch/msg/tsvwg/dxL8px2Gri30qw2xTBes5UQohM4/,
Martin Duke wrote:

> (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.
>

I agree. That text is already in Section 11.2. No Operation (NOP), which is
where it belongs. It is out-of-place here, especially if it implies that
NOPs (or other optiouns not reported to the user) are to be excluded from
the value of MRDS size  (they should not be, see above).

See Issue #55
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/55>.

I have also sent some typos to the author under separate cover.

Best regards,

Mike Heard