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

[Zaheduzzaman Sarker <[e-mail]>]

On Tue, Apr 9, 2024 at 8:26 PM C. M. Heard <[e-mail]> wrote:

> On Tue, Apr 9, 2024 at 6:09 AM Zaheduzzaman Sarker <
> [e-mail]> wrote:
>
>> On Tue, Apr 9, 2024 at 12:48 PM Gorry (erg) <[e-mail]> wrote:
>>
> [ ... ]
>
>> So.   I think given this, it is OK for the endpoints to send information
>>> in UDP options which can be read (only) by the transit nodes and they can
>>> indeed react to this. That has always been possible with tunnels, extension
>>> headers, and transports - at least those not using transport encryption.
>>> This comes with positive and negative impacts.
>>>
>>> In today’s world, a designer can choose to protect all of the transport
>>> eg using QUIC - and many designs will follow that path. Although, there is
>>> a large body of work in the IETF that still directly uses UDP. That to me
>>> is OK if that best fits the use.
>>>
>>
>> Yes, UDP should be considered as transport protocol. It would be good to
>> have a view on how many of those large body of work uses or envision to use
>> UDP options in clear. This would boost the motivation for this work and
>> back up the need of UDP options.
>>
>
>
> It was recognized early in the development of the UDP options that they
> would be useful for DPLPMTUD. This use case is documented
> in draft-ietf-tsvwg-udp-options-dplpmtud, which has actually been ready for
> publication for quite some time.
>
> Another potentially attractive use case was use of UDP options to allow
> UDP-based request/response protocols such as DNS to send large responses
> without relying on IP fragmentation (especially IPv6 fragmentation). Here's
> how this would work: client includes the MRDS option in the request;
> responder ignores said option unless it is option aware and has UDP options
> enabled, in which case it can use the option to determine how to send a
> large response using UDP fragmentation. This is incrementally deployable as
> long as legacy applications ignore the UDP surplus area. We don't have an
> I-D describing this use case. but one could be written if it would help to
> back up the need for UDP options.
>

I agree it would useful to record this usecase.


>
>
>
>> The backwards compatibility with UDP was considered important in the
>>> development of this Spec.
>>>
>>
>> This point is absent, AFAIK in Section 16 of the draft now.
>>
>
>
> Adding such a discussion is a reasonable request; IMO the best place would
> be Section 6 (Design Principles).
>

Please add it.


>
>
>  On Tue, Apr 9, 2024 at 10:16 AM Christian Huitema wrote:
>
>> On 4/9/2024 9:09 AM, Tom Herbert wrote:
>> > I believe that processing of the options is already opt-in. Accepting
>> > UDP surplus area (at least ignoring it and not dropping packet) and the
>> > checksum processing I described are currently mandatory.
>>
>> And that's probably what need to change before this draft is published.
>> Using the surplus area without the explicit consent of the application
>> is an attack. The proper way to stop such attacks is to drop the whole
>> packet, because only that inflicts a cost to the attacker.
>
>
>
> I disagree that use of the surplus area without the explicit consent of
> the receiver automatically constitutes an attack, as long as the surplus
> area is ignored by default.
>
> The attitude of dropping whatever you don't have a predetermined use for
> is exactly what has made IPv4 options and IPv6 extension headers
> essentially unusable in the open internet.
>
> Mike Heard
>