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

["C. M. Heard" <[e-mail]>]

On Tue, Apr 9, 2024 at 10:16 AM Christian Huitema wrote:
> On 4/9/2024 9:09 AM, Tom Herbert wrote:
> > On Tue, Apr 9, 2024 at 8:29 AM Christian Huitema wrote:
> > > On 4/9/2024 8:17 AM, Tom Herbert wrote:
> > > > On Tue, Apr 9, 2024 at 7:29 AM Christian Huitema wrote:
> > > > > 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[s], 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?
> > > >
> > > > 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.
> > >
> > > If the application did not opt-in, yes, because that's the best
> > > way to prevent "off standard" deployment of clear-text options.
> >
> > 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.

In case it was not clear, when Tom says "currently mandatory" in the
passage above, he is referring to current standards, i.e., RFC 768
as it now stands. He is not referring to the current contents of
the UDP Options spec. The change that you are proposing here would
thus be a change to current standard behaviour, which is explicitly
out of scope for the UDP Options spec.

What the UDP Options spec could do to improve the situation would be
to have an API option (or a configuration option that applies to
selected listening ports) to drop all packets that contain a
non-empty surplus area (i.e., that contain any UDP options at all).
This would not address all of the security problems that you raise,
but it result in an improvement over the current situation if the
UDP Options spec were to be published and adopted.

These considerations are summarized in a response to Issue #44
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/44>.

Respectfully,

Mike Heard