[tsvwg] Review of draft-ietf-tsvwg-udp-options-32

[Martin Duke <[e-mail]>]

Here is a somewhat late individual review of the udp-options draft, since I
purposely didn't read it when I thought I'd have to review it as an AD
evaluatoin.

Major comments:
- I'm impressed with the overall cleverness and elegance of this solution,
particularly the use of FRAG to contain unsafe options in a zero-length
datagram.

- I appreciate the work to make this an end-to-end signal, and that UDP has
pre-existing limitations in this regard. I also think the use cases are
probably valuable.

But in 2024, if we want to make rules about what the network can and can't
do, we enforce it with encryption and authentication. I recognize that
these were originally in the draft, and were removed for very good reasons.
But I'm also worried that, if successful:
- This will attract "helpful" middlebox functions like MSS clamping.
- This is an attractive nuisance for various path signaling schemes. They
are going to come here because other avenues (DSCP, IPv6 Extension Headers)
have been blocked. And that eventually UDP options will be blocked for the
same reason that those were blocked. I suppose that enough fortitude in
TSVWG can forestall this happening. Personally, I would strongly encourage
these efforts to use encapsulation, or any other mechanism, to avoid
compromise of the E2E channel you are building here.
- To the extent that new options are "opt-in" by the endpoint, I'm fine
with it. But if we reach a point where identifying signals are required by
the network to participate, that's not so great. I'm not sure that this
architecture has much in the way of safeguards to prevent that outcome.

This isn't really actionable because I genuinely don't know what to do, and
luckily for me, I don't have to decide anymore. But I ask the proponents
and the working group to reflect on this a bit more. And we should
consciously decide, as a community, if path signaling over UDP is a thing
we support or not.

Some minor points:
(11.4) It might be worth clarifying at the start that fragmentation is
purely E2E, not something that routers can do.

(11.4) What if Frag. Start is inconsistent with the location of EOL?

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

(11.4) "the OCS value of the original packet SHOULD be zero if each
fragment will have a non-zero OCS value"

I don't understand the purpose of this. First, it complicates packet
processing because the full datagram has to use a different OCS
verification path if it's reassembled. Second, if the fragment OCSes are
sufficient, why not simply say that the original packet MUST NOT have an
OCS option?

(11.5) "MDS does not indicate a known path MTU and thus MUST NOT be used to
limit transmissions."

I am not sure what it means "to limit transmissions". Can you elaborate?
What is the purpose of this if not to provide a hint of datagram size? Just
to seed PMTUD?

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

(11.7) Is the token generated by the UDP implementation or the upper layer?
Is there any guidance on how to choose the token (should it be random or
monotonically increasing? Is any method OK as long as they don't repeat?
Given that UDP is connectionless, what would it even mean that it doesn't
repeat?)

Martin