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

[Tom Herbert <[e-mail]>]

On Wed, Jul 26, 2023, 11:32 AM C. M. Heard <[e-mail]> wrote:

> 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).
>

Mike,

Yes, there are valid use cases for hosts to signal the network, QoS
immediately comes to mind. The temptation here is to use UDP Options"
because the proper technique, HBH Options, "doesn't work". Even if I
believed the argument, I am doubtful there's a path to deployment or
standardization in IETF for using UDP Options for this purpose (layering
violation, UDP specific, relies on unproven protocol, yet to be shown it's
any more deployable than HBH, difficulties to process TLVs in trailers
efficiently, lack of deployment, etc.).

So, UDP Options should only be an E2E protocol. As I mentioned previously,
regardless of the requirements, some network nodes will decide to inspect
any plain text in a packet data. They may even decide to modify it. This is
true for UDP Options. I don't think this is necessarily a showstopper, but
it does need to be considered.

Tom


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
>