[Int-dir] Intdir telechat review of draft-ietf-tsvwg-udp-options-38

[Antoine Fressancourt via Datatracker <[e-mail]>]

Reviewer: Antoine Fressancourt
Review result: Ready with Nits

I am an assigned INT directorate reviewer for
draft-ietf-tsvwg-udp-options-38.txt. These comments were written primarily for
the benefit of the Internet Area Directors. Document editors and shepherd(s)
should treat these comments just like they would treat comments from any other
IETF contributors and resolve them along with any other Last Call comments that
have been received. For more details on the INT Directorate, see
https://datatracker.ietf.org/group/intdir/about/
<https://datatracker.ietf.org/group/intdir/about/>.

Based on my review, if I was on the IESG I would ballot this document as YES or
NO OBJECTION.

The following are comments that came to my mind while reading the document. I
would enjoy a clarification about those comments (with no obligation,
obviously):

In general, the document is well written and structured. I was not familiar
with the idea of UDP options before being asked to review this document, and I
have been intrigued about this design option. In the frame of this review, I
also carefully read [Zu20] as deployment aspects of this design seemed to me
key in the potential use of UDP options.

While reading the document, I was asking to myself for a rather long time why
the authors opted for placing the UDP option after the UDP data. I think the
surplus area gap between the IP length and the UDP length should be presented
earlier in the text, right after the 3rd paragraph of section 4.

In the same way, I was kept wondering for a rather long time whether
intermediate (middlebox) nodes may add or remove UDP options on the flight.
This is prohibited with a sentence appearing in section 13. I would state this
in section 6 about the design principles, and in any case before the FRAG
option is introduced to rule out the possibility for a middlebox to further
fragment a UDP fragment.

Talking about section 6, I find it odd that potential issues related to
fragmentation are presented in the last paragraph of the section before we got
more information about the fragmentation mechanism presented in section 11.4.

After reading about the surplus area idea, I wondered why such an inconsistency
was kept, and looking at some OS code (e.g. FreeBSD), it appears that some OS
check the various length fields' consistencies. It seems to me a rather sane
behavior given the possibility to use the surplus area as a side channel to
convey data related to an attack (rather than an ossification factor as
presented in [ZU20]). Given this context, we may consider that the UDP option
mechanism presented in this document is an opportunity to clarify the use of
the surplus area and close this inconsistency's gap. Then, I am wondering why
there is still a possibility for the presence of a surplus area behind the EOL
option. In my humble opinion, given that the document mentions that UDP options
can't be introduced by on-path nodes, the document should close the gap left
open by length fields inconsistencies.

Regarding authentication and encryption options introduced in section 10, after
possible authentication and encryption options were presented, I was wondering
what would such options add compared to QUIC or DTLS. Potential gap analysis
between those existing protocols and future authentication and encryption
schemes should be done in the future by UDP option designers addressing those
challenges.

In section 8, the reason for using zeros before the beginning of the OCS
checksum is not mentioned. It should be clearly stated in the document: does it
comply with an alignment constraint about UDP mentioned in another document? Is
it arbitrary?

In section 9, I would add another subfigure in Figure 4 presenting the case in
which the UDP data ends at the first byte of the 4 bytes representation to
clearly show that the intention is to align on 2 bytes boundaries:

 +--------+--------+--------+--------+
 |UDP data|    0   |       OCS       |
 +--------+--------+--------+--------+

 Besides, in the same section, I would clarify whether the 0 padding before the
 OCS should be considered part of the surplus area in the checksum computation.

Section 11.2 presents the NOP option as a padding solution to align options to
16-, 32- or 64-bits boundaries, yet, the need to align UDP options or not is
not mentioned in the design principles. It should be mentioned there clearly in
my view.

In section 11.4, the document mentions that "The Identification field SHOULD be
generated in a manner similar to that of the IPv6 Fragment ID [RFC8200].". I
think it would be beneficial to give a bit more details about this generation
method to add clarity. In the same section, the document mentions that "2.
Identify the desired fragment size, which we will call "S". This value is
calculated to take the path MTU into account (if known) and to allow space for
per-fragment options.". I would give a better idea about the size of said space
for per-fragment options.

In section 16, the document mentions "... many of the deployment scenarios of
interest...", yet, to the best of my understanding, those scenarios are not
mentioned in the text of the document. Could a reference or a description of
those scenarios be given?

I was a bit surprised by the results presented in section 18 of the document
because if one looks at some OS's code, the consistency between the length
advertised in the IP header and the length advertised in the UDP header is
checked (see FreeBSD: http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c)
In particular, I find the fact that the inconsistency is only noted by one
middlebox vendor astonishing. On the one end, it is good news for UDP options,
but it opens avenues for side channel communications, which I would consider
being a threat.

The following are minor issues (typos, misspelling, minor text improvements)
with the document:

* On page 16, "...and trying to defining meaning..." should be replaced by
"...and trying to define meaning..."