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

[Christian Huitema <[e-mail]>]

On 4/9/2024 11:25 AM, C. M. Heard wrote:
> On Tue, Apr 9, 2024 at 6:09 AM Zaheduzzaman Sarker 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     On Tue, Apr 9, 2024 at 12:48 PM Gorry (erg) <[e-mail]
>     <mailto:[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.

Except that if the application includes its own transport, that 
transport is the normal place to include Path MTU discovery. In the case 
of encrypted transport like QUIC, there is a deliberate design decision 
to not use clear text data, because it can be manipulated by on path 
devices. Using UDP options for path MTU discovery would open a security 
issue.


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

Did you check that assumption with DNSOP? I don't see the DNS users 
clamoring for such a solution. Indeed, most DNS development seems to be 
focused on avoiding UDP fragmentation by either picking a small packet 
size, or using transports like TCP, DoT, DoH or DoQ that do include 
their own fragmentation mechanisms.


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

Anything that adds clear text to an already encrypted packet should be 
considered an attack. See Martin Duke's "attractive nuisance" 
discussion. If we want to avoid that, we should either make sure that 
UDP options are encrypted, or recommend dropping unexpected options.

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

I understand that you are concerned about deployment of UDP options, and 
that dropping packets with unexpected options would not ease that 
deployment. But we should not ease deployment at the cost of security or 
privacy.

-- Christian Huitema