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

["C. M. Heard" <[e-mail]>]

On Thu, Apr 11, 2024 at 4:16 AM Zaheduzzaman Sarker <
[e-mail]> wrote:

>
>
> On Tue, Apr 9, 2024 at 5:01 PM [e-mail] <[e-mail]>
> wrote:
>
>> Hi, all,
>>
>> On Apr 9, 2024, at 3:31 AM, Zaheduzzaman Sarker <
>> [e-mail]> wrote:
>>
>> 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
>>
>>
>> We can prevent that if/when we proceed with the UDP encryption option or
>> using IPsec.
>>
>
> I wanted to make sure we have a consensus here that it is good enough to
> do so.
>
>
>>
>> But all this talk about transport protocols and their vulnerability to
>> on-path mods strikes me as hollow. We have had such protections for TCP for
>> a generation (over 25 yrs) with TCP-MD5 and its successor TCP-AO. Neither
>> one protects packets from on-path tampering with IP options, but we’ve had
>> that for just as long too.
>>
>> What we don’t have is a widely enough deployed key infrastructure. Until
>> that happens, it’s difficult to understand how raising these issues
>> obligates protocol designers.
>>
>
> (I am not sure why that is not widely deployed yet :-).)
>
> The obligation here is that we have thought about the possibilities,
> understand the pros and cons, made the right choice, and well describe them
> on what we published.  I am not AD reviewing the document now, but I would
> not like wait till my AD review to express what I would be looking for. Now
> you know and can just tell me yes we have done those thoughts and in
> section XXX we have described it well.
>

This is now Issue #45
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/45> in the
github tracker.

As was noted earlier in this thread, the issue was discussed previously on
the TSVWG mailing list:

On Fri, Apr 5, 2024 at 9:49 AM Martin Duke wrote:

> On Thu, Apr 4, 2024 at 2:22 PM C. M. Heard  wrote:
>
>> 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.
>>
>
> Thanks for the pointer. I'm glad that the WG has already done what I've
> asked.
>

I cited only one of the relevant threads. Would it be helpful if I were to
go back through the mailing list archives and add links to all of the
relevant threads in a comment? That will be a fair amount of work, but I am
willing to do it, *if* it will help the AD, the chairs, and the WG.

Please let me know.

Mike Heard