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

[Christian Huitema <[e-mail]>]

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 Huitema