Re: [tsvwg] https://notes.ietf.org/notes-ietf-117-tsvwg# UDP options discussion

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

On Wed, Jul 26, 2023 at 9:45 AM Tom Herbert wrote:
> It's not so much design principles, it's realities of deployment or
> lack of deployment that we have learned with experience from other
> protocols. We know that protocols with unlimited TLVs where unknown
> TLVs can be ignored is an invitation to DOS attack. We also know that
> any plain text in a packet will be read and consumed by some
> intermediate nodes in the network; this is an invitation to ossifying
> transport layers, or worse a security vulnerability when the plain
> text reveals information about encrypted data. As I said, there is a
> real risk that providers will filter packets with surplus area if
> there is ever a problem with UDP Options (even the perception that
> there might be a problem could be enough to drop packets).

Thank you for clarifying and expanding upon your mic comment.

> That being said, the more troublesome issue is about Christian
> comments that UDP Options should not be allowed with encrypted
> payloads.

I get the sense that the WG is generally in agreement with this; in
the case of QUIC in particular, it's been  established that the
currently specified UDP options do not offer any capabilities that
QUIC does not already have, while on the other hand there is a
temptation in some quarters to define new options that expose
information QUIC was explicitly designed to conceal (I'm thinking of
specifically of draft-reddy-tsvwg-explcit-signal). I do understand
Christian's antipathy to exposing anything about QUIC (or any other
encrypted protocol carried over UDP) as cleartext in the surplus area.
That certainly is not something that we should standardize. But given
that the whether insertion of such cleartext information is done is
under endpoint control, I fail to see how the very existence of UDP
options poses a threat to QUIC or other end-to-end encrypted protocols
that use UDP as a substrate. I'm expecting to be educated shortly :-)

> Given that the trend is towards encrypting as much of the
> packet as possible (if it was feasible, I think we'd regularly be
> encrypting TCP headers), if UDP Options were restricted to only work
> with unencrypted payloads I have to wonder if there are a sufficient
> number of use cases to justify the protocol. I don't know how this can
> be addressed; maybe since UDP Options are end-to-end, there should be
> a way to encrypt them along with the payload...

The potential lack of sufficient use cases is definitely an issue, and
the length of time that it is taking to get this spec done has not
helped at all. The greatest potential that I see in UDP options is to
improve matters for legacy applications such as DNS that rely heavily
on classical UDP but suffer from poor network handling of IP fragments.
A migration to UDP fragmentation can be done in a manner that is
backward compatible and incrementally deployable. If DNS has at best a
long and tortuous path to migrate all of its use of classical UDP to an
encrypted protocol such as QUIC, then maybe there still is a role for
UDP options.

Mike Heard