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..." -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
