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

[Christian Huitema <[e-mail]>]

On 4/4/2024 2:22 PM, C. M. Heard wrote:
> On Tue, Apr 2, 2024 at 2:23 PM Martin Duke wrote:
> 
>     ...
> 
>     - 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.
> 
> 
> TSVWG went over this ground, to some extent at least, during the initial 
> discussions of the initial versions of draft-reddy-tsvwg-explcit-signal 
> (now expired) and draft-kaippallimalil-tsvwg-media-hdr-wireless (still 
> active). After several threads in which the merits of using UDP options 
> for host-to-network signaling was discussed (see, e.g., Challenges for 
> host to network signaling via UDP Options 
> <https://mailarchive.ietf.org/arch/msg/tsvwg/SpcVd6EB1Zi6FUhhyn2-o6nxuq4/> and other messages in that thread), I think most in the WG came around to the position of *_not_* wanting to see UDP options used for host-to-network signaling, The chairs are, or course, the folks who can make authoritative statements, but that was my impression, at least. The current version of draft-kaippallimalil-tsvwg-media-hdr-wireless does propose to use UDP options for signaling, but as part of a tunnel encapsulation arrangement, which does not conflict with the desired E2E nature of UDP options.

I think that the WG is well meaning, but as Martin says, this is 2024. 
Just saying that a protocol is mean to be end-to-end is no guarantee 
that it will not actually be used and abused by intermediaries. After 
all, the TCP headers are clearly end-to-end similar intermediaries have 
been abusing TCP headers for a long time. Intentions are nice, but in 
2024 if the protocol does not enforce its end to end nature then it is 
not end-to-end.

In the absence of features like end-to-end encryption or, at a minimum, 
end-to-end cryptographic checksums, this protocol is open to 
intermediaries, even if the intent was end-to-end.

-- Christian Huitema