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

[Christian Huitema <[e-mail]>]

On 4/9/2024 6:09 AM, Zaheduzzaman Sarker wrote:
> 
> 
> On Tue, Apr 9, 2024 at 12:48 PM Gorry (erg) <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
>     See below for my 2c.
> 
>      > On 9 Apr 2024, at 11:31, Zaheduzzaman Sarker
>     <[e-mail] <mailto:[e-mail]>>
>     wrote:
>      >
>      > Hi all,
>      >
>      > Putting my AD hat on, if we specify protocol features only for
>     endpoints to
>      > consume and not for endpoints to network, then we should make
>     sure that is
>      > case when we design and describe it. We cannot expect all the
>      > intermediaries are well behaved or features are used as intended when
>      > designed. From that point of view it is not good enough to send
>     information
>      > in clear and just say "UDP Options are for Transport, Not
>     Transit". With
>      > the current, well placed, scrutiny of privacy and security on all the
>      > protocols that IETF is producing- It would require a huge
>     exception to get
>      > it published.
>      >
>      > 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
> 
>     this is a transport/encapsulation that can be used without the
>     benefits of encryption.To me, this was already clear when the
>     working group asked to start this work (it certainly was made clear
>     after the work was adopted), and this spec developed over many years.
> 
> 
> Right, many years have past and we should then recheck the consensus on 
> this. From the mentioned email discussions and views expressed here I am 
> not sure it is clear to me what consensus we have now. Could you also 
> please provide me any reference to the consensus?
> 
> 
> 
>     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.

Depending on the application stack, UDP is either a transport protocol 
or a transparent pass-through. Indeed, this is pretty much the intended 
design of UDP, as stated in RFC 768: "This protocol provides a procedure 
for application programs to send messages to other programs with a 
minimum of protocol mechanism."

If the application stack is including its own transport protocol, then 
we are in the "pass-through" case. This is absolutely the case if the 
application stack includes QUIC, SCTP or DTLS, but there are other examples.

In the pass-through examples, and especially when the application 
transport uses encryption, adding clear-text options does not add value. 
It destroys it, re-enabling surveillance despite encryption of the 
application.

I think there should be a very clear mechanism for application to 
"opt-in" the usage of clear-text application, and that for applications 
that did not opt in the reception of clear-text options should be 
treated as a protocol error.

-- Christian Huitema

> 
> 
>     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.
> 
> //Zahed
> 
> 
>     Gorry
> 
>      >
>      >> On Fri, Apr 5, 2024 at 2:29 AM Christian Huitema
>     <[e-mail] <mailto:[e-mail]>>
>      >> wrote:
>      >>
>      >>
>      >>
>      >>> On 4/4/2024 2:22 PM, C. M. Heard wrote:
>      >>>> On Tue, Apr 2, 2024 at 2:23 PM Martin Duke wrote:
>      >>>
>      >>>    ...
>      >>>
>      >>>    - I appreciate the work to make this an end-to-end signal,
>     and that
>      >>>    UDP has pre-existing limitations in this regard. I also
>     think the
>      >>>    use cases are probably valuable.
>      >>>
>      >>>    But in 2024, if we want to make rules about what the network
>     can and
>      >>>    can't do, we enforce it with encryption and authentication. I
>      >>>    recognize that these were originally in the draft, and were
>     removed
>      >>>    for very good reasons. But I'm also worried that, if successful:
>      >>>    - This will attract "helpful" middlebox functions like MSS
>     clamping
>