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

[Zaheduzzaman Sarker <[e-mail]>]

On Mon, Apr 29, 2024 at 11:24 PM C. M. Heard <[e-mail]> wrote:

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

For me, I have the same understanding from the email discussions as you
described above, so you can save some energy for other great things. I
however, not aware of any consensus declared in the WG, may be the chairs
want to do that to close the loop.

//Zahed


>
> Mike Heard
>