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

[Christian Huitema <[e-mail]>]

On 4/9/2024 9:09 AM, Tom Herbert wrote:
> 
> 
> On Tue, Apr 9, 2024, 11:29 AM Christian Huitema <[e-mail] 
> <mailto:[e-mail]>> wrote:
> 
> 
> 
>     On 4/9/2024 8:17 AM, Tom Herbert wrote:
>      > On Tue, Apr 9, 2024 at 7:29 AM Christian Huitema
>     <[e-mail] <mailto:[e-mail]>> wrote:
>      >>
>      >>
>      >>
>      >> 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]>
>      >>> <mailto:[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]>
>     <mailto:[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,
>      >
>      > In current host stack implementation, when a UDP packet is received
>      > with surplus area we truncate the packet down to UDP Length and
>      > otherwise ignore the surplus area bits. Are you suggesting that the
>      > default behavior should be to drop packets with a UDP surplus area?
> 
>     If the application did not opt-in, yes, because that's the best way to
>     prevent "off standard" deployment of clear-text options.
> 
>      >
>      > IMO, this might be worth considering. I agree that this would tighten
>      > security. Also, I would point out that even truncating the surplus
>      > area like we do today is not without cost. If we are doing protocol
>      > agnostic checksum offload, the preferred method, then we need to
>      > compute the checksum over the surplus area when truncating and so we
>      > do this in the CPU. For a large surplus area this can burn a lot of
>      > cycles to process data that is useless to the receiver; conceivably,
>      > this could be a basis for a DoS attack on CPU resources.
> 
>     Yes, there is also a security aspect. Adding option processing does
>     increase the attack surface, and even simple options like Ping have
>     caused issues like Heartbleed. Add the extra CPU requirements that you
>     mention, and I can see why security conscious application would want to
>     not use any clear-text addition to UDP packets.
> 
> 
> Christian,
> 
> 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.

-- Christian Huitema