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

[Tom Herbert <[e-mail]>]

On Tue, Apr 9, 2024, 11:29 AM Christian Huitema <[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]>
> 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]>> 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,
> >
> > 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.

Tom



> -- Christian Huitema
>