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

[Zaheduzzaman Sarker <[e-mail]>]

Hi all,

Putting my AD hat on, if we specify protocol features only for endpoints to
consume and not for endpoints to network, then we should make sure that is
case when we design and describe it. We cannot expect all the
intermediaries are well behaved or features are used as intended when
designed. From that point of view it is not good enough to send information
in clear and just say "UDP Options are for Transport, Not Transit". With
the current, well placed, scrutiny of privacy and security on all the
protocols that IETF is producing- It would require a huge exception to get
it published.

The questions I would like to get answer is  -

      Is it OK for the endpoints to send information in UDP options which
can be read (only) by the transit nodes and react to it? if NO,  then how
to prevent that to happen?

//Zahed

On Fri, Apr 5, 2024 at 2:29 AM Christian Huitema <[e-mail]>
wrote:

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