[Int-dir] Re: [Last-Call] Intdir telechat review of draft-ietf-tsvwg-udp-options-38

[Antoine FRESSANCOURT <[e-mail]>]

Hello,

First of all, sorry for my delayed answer.

Please see my remaining comments inline prefixed by [AFT2]. Overall, I am ok with the proposed comments, and agree with Eric on his positioning on version -43 of your document (even if my agreement is by no means necessary).

Best regards,

Antoine

From: C. M. Heard <[e-mail]>
Sent: vendredi 7 mars 2025 02:40
To: Joe Touch <[e-mail]>; Antoine FRESSANCOURT <[e-mail]>
Cc: C. M. Heard <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Last-Call] Intdir telechat review of draft-ietf-tsvwg-udp-options-38

Two additional points below ...

On Thu, Mar 6, 2025 at 4:29 PM [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>> wrote:
Hi, Antoine,

Notes below with [JT]… All the ones not commented will be in the next rev.

Looking forward to your reply on the commented ones.

Joe

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com<http://www.strayalpha.com>


On Mar 6, 2025, at 2:05 AM, Antoine FRESSANCOURT <antoine.fressancourt=[e-mail]<mailto:[e-mail]>> wrote:

Hello Mike and Joe,

Thanks a lot for taking the time to write this detailed answer to the points I mentioned in the review, I will add my comments to your answer in the text of the previous email, prefixed with [AFT].

Best regards,

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

The fourth paragraph of Section 4 explains this already. We would prefer to
leave the figures where they are.

[AFT] Noted

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.

Traditionally, the expectation has been that fields that are modified in transit
reside at the network layer, not the transport layer, so this does not (to us)
seem to be a design principle that is specific to UDP options. Section 16 does
address this issue generally. In the absence of a request from other reviewers,
we would prefer to leave the order of the presentation as it is.

[AFT] I have the same traditional opinion as you about the fact that anything at layer 4 and above should be left unmodified in transit, and should not be modified. Yet, NATs exist, and very recently there has been a quite heated discussion about the possibility for transit nodes to check values for transport layer checksums in another working group. Thus, I felt this clarification would be helpful in this document. Yet, I hear your point of view about it, and I let you determine whether it is appropriate or not to mention this in your document.

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.

Would a forward reference to Section 11.4 be helpful?

[AFT] I think so.

The following text is queued up for -43:

   Finally, UDP options do not attempt to match the number of zero-
   length UDP datagrams received by legacy and option-aware receivers
   from a source using UDP fragmentation (see Section 11.4).

[AFT2] This change is OK for me.

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.

We note that RFC 768 does not explicitly prohibit the presence of surplus
area, and all systems whose code we have inspected (including FreeBSD) simply
ignore it if it is present (more on this below). To us, concerns about
side-channel attacks on an unauthenticated transport protocol that can sit
inside an IP header with arbitrary options seems misplaced. Everything is a
possible side-channel attack unless it’s under control (e.g., encrypted).

That being said, we think that the UDP options specification may actually
improve the situation for transports for which this is a concern:

- The spec rules out any use of the area past EOL by requiring zero-fill
for the part of the surplus area after EOL (Section 11.0).

- The spec also levies a requirement on option-aware UDP implementations to
provide an API setting that allows an upper layers to request that the UDP
layer discard packets with a non-empty surplus area (Section 15), something
that is currently not generally available.

[AFT] I get that, but in my view, the document should be more directive about discarding UDP packets with non-zero content after the UDP options (and have an option NOT to discard it, for instance).

[JT] yes, this is useful. If the UDP options end (with an EOL), then the rest MUST be zero and a packet with nonzero is malformed and the entire surplus area MUST be discarded (same as other options), but the data is still passed up (to copy legacy endpoint behavior).

If that works, I’ll add that to the next rev.

To bring in some background: the relevant text from Section 11.1 (not 11.0 as stated above) is:

   >> All bytes after EOL in the surplus area or the options area of a
   UDP fragment MUST be set to zero on transmit.

   >> Bytes after EOL in the surplus area or the options area of a UDP
   fragment MAY be checked as being zero on receipt, but MUST NOT be
   otherwise processed (except for OCS calculation, which zeros would
   not affect) and MUST NOT be passed to the user.

The WG decision to allow, but not to require, a receiver to check that all bytes
after EOL are actually zero was a deliberate one, motivated in part to minimize
the expense of processing DPLPMTUD probe packets (these typically consist
of just a REQ option followed by EOL and zero-fill to a specific size; see
Section 23.2 of draft-ietf-tsvwg-udp-options-dplpmtud).

It is definitely worthwhile to clarify that if a receiver elects to check that all
bytes after EOL are zero, then the appropriate action is to discard the
options but accept the UDP user data. But we don't want to mandate
the checking (at least not without going back to the WG).

As always, if there is a strong concern about middleboxes altering the surplus
area, then the appropriate action is to encrypt the entire packet.

[AFT2] I get your point, my position on that was that it was worth it being more restrictive and forbid the presence of surplus after the EOL option, but I will follow Eric’s view mentioning that this concern should rather be addressed from a SEC perspective.


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.

We think that such a discussion would be out of place in this document. It
would be entirely appropriate subject matter for a future specification of UDP
authentication and/or encryption.

[AFT] I agree, I wanted to clearly state that such a gap analysis was necessary in my perspective.

[JT] it may be, but are you saying that belongs here or that it should be a suggestion for TSVWG for a future doc?

If the latter, I can queue it up for a future rev of the UDP AUTH draft.

[AFT2] I was of the latter opinion, (and we are 2 in this queue now).

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?

The following text will appear in -41:

These alignment bytes, coupled with OCS as computed over the
remainder of the surplus area, ensure that the ones-
complement sum of the surplus area is zero. OCS is half-word
(2-byte) aligned to avoid the need for byte-swapping in its
implementation.

Please let us know if this addresses your concern.

[AFT] This text answers my concern. Thanks.

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.

 We do not think that the proposed changes are improvements and would prefer
not include them. Further, it doesn’t matter if the 0 is included in the
surplus area checksum computation or not -- it’s a 0, which has no effect on
ones-complement arithmetic. What we do avoid is the need to write code to
deal with adding in individual bytes to a 16-bit quantity.

[AFT] Noted
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.

Allowance for alignment is not a design principle; it is an optimization for
implementation efficiency and has been common practice not needing explanation
since at least the 1980s -- see, e.g., RFC 791 (IP) and RFC 793 (TCP).

[AFT] Noted

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.

We think that pointing to RFC 8200 without prescribing specific algorithms
(as is done, e.g., in RFC 1948 and RFC 6528), is more than sufficient. That
being said, if you wish to propose specific text, we are all ears.

[AFT] I noted your answer to the first comment in this paragraph. Regarding the second part of the comment, by memory, RFC 3261 mentions that a packet containing a SIP header and body should not be larger than the MTU minus 200 bytes to give enough space for on path additions to the header. I was having similar recommendations in mind regarding the desired fragment size.

[JT] If I understand correctly, you want to “de-rate” the IP reported MTU to allow IP more space to add or increase the size of headers on the path. That has been discussed in INTAREA and the consensus I recall was that IPv6 options should never become larger (as a set), precisely because it interferes with path MTU mechanisms (both PMTUD and PLPMTUD). De-rating for IP tunnels and the like would already have been done at the IP layer.

I.e., UDP, like TCP, determines its max transport MTU based on what IP reports. I don’t understand why SIP has any different recommendation, FWIW.

[AFT2] My point here was that, if you are fragmenting the UDP header + payload in several fragments and that you allow per fragment UDP options, then you should make sure in your fragmentation strategy that you leave some space to add UDP options between the end of the UDP fragment and the IP packet’s MTU. My intention when citing SIP was to mention that SIP gives a limit to its size by retracting some bytes to the MTU. Translating to UDP fragmentation, it would mean that, when fragmenting UDP in fragments, the fragment should be less that the size allowed by the MTU to allow some UDP options to be added without exceeding the MTU. I didn’t mean to allow middle nodes to add options on the fly.


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?

This is covered by Section 5 and by the last paragraph of Section 16, where
[He24] is cited.

[AFT] Noted.

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.

We looked up the BSD code at that link and saw this:

  511<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L511>         /*

  512<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L512>          * Make mbuf data length reflect UDP length.  If not enough data to

  513<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L513>          * reflect UDP length, drop.

  514<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L514>          */

  515<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L515>         len<http://fxr.watson.org/fxr/ident?i=len> = ntohs<http://fxr.watson.org/fxr/ident?i=ntohs>((u_short)uh->uh_ulen);

  516<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L516>         ip_len = ntohs<http://fxr.watson.org/fxr/ident?i=ntohs>(ip<http://fxr.watson.org/fxr/ident?i=ip>->ip_len) - iphlen;

  517<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L517>         if (proto<http://fxr.watson.org/fxr/ident?i=proto> == IPPROTO_UDPLITE<http://fxr.watson.org/fxr/ident?i=IPPROTO_UDPLITE> && (len<http://fxr.watson.org/fxr/ident?i=len> == 0 || len<http://fxr.watson.org/fxr/ident?i=len> == ip_len)) {

  518<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L518>                 /* Zero means checksum over the complete packet. */

  519<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L519>                 if (len<http://fxr.watson.org/fxr/ident?i=len> == 0)

  520<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L520>                         len<http://fxr.watson.org/fxr/ident?i=len> = ip_len;

  521<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L521>                 cscov_partial = 0;

  522<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L522>         }

  523<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L523>         if (ip_len != len<http://fxr.watson.org/fxr/ident?i=len>) {

  524<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L524>                 if (len<http://fxr.watson.org/fxr/ident?i=len> > ip_len || len<http://fxr.watson.org/fxr/ident?i=len> < sizeof(struct udphdr<http://fxr.watson.org/fxr/ident?i=udphdr>)) {

  525<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L525>                         UDPSTAT_INC<http://fxr.watson.org/fxr/ident?i=UDPSTAT_INC>(udps_badlen);

  526<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L526>                         goto badunlocked;

  527<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L527>                 }

  528<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L528>                 if (proto<http://fxr.watson.org/fxr/ident?i=proto> == IPPROTO_UDP<http://fxr.watson.org/fxr/ident?i=IPPROTO_UDP>)

  529<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L529>                         m_adj<http://fxr.watson.org/fxr/ident?i=m_adj>(m<http://fxr.watson.org/fxr/ident?i=m>, len<http://fxr.watson.org/fxr/ident?i=len> - ip_len);

  530<http://fxr.watson.org/fxr/source/netinet/udp_usrreq.c#L530>         }

If our understanding is correct, the highlighted code simply discards the
surplus area. The only policing for consistency is to make sure that UDP Length
does not point past the end of the packet, as indicated by the IP payload
length. This is consistent with what we have seen in other legacy endpoint
implementations -- they simply silently discard the surplus, which is what
we want and expect them to do.

Legacy middleboxes need to keep the surplus intact, but they’re not likely to
look at it, since it is usually deep in the packet. They can and do filter on
transport ports or UDP content, but (with some exceptions) they don’t typically
check for consistency between UDP length and IP payload length.

[AFT] Noted

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

Good catch. It will be fixed in -41.

Mike and Joe

--
last-call mailing list -- [e-mail]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>