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

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

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.



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


 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