Re: [tsvwg] Regarding DTLS and UDP options

[Joe Touch <[e-mail]>]

On 4/17/2017 3:31 PM, Tom Herbert wrote:
>> Do you use TCP options?
>>
>> How and why should these be different?
>>
> TCP options are pretty much required for operation of the TCP
> protocol, 

You can run TCP with no options just fine - but not efficiently.

> this is why they will never be ossified and why it's one of
> the few methods of protocol extensibility that is viable on the
> Internet.
They are somewhat ossified in that there are offload devices and
middleboxes that work only with known subsets of options. In some cases,
those features have work-arounds when unknown or unsupported options are
seen - but not always.

>  IP options on the other hand were never required for IP to
> operate hence they were quickly ossified.
I'm not sure you're using the term 'ossified' the way others do.

For IPv4, options were not so much "turned to stone" as they were
deprecated because fast-path processing never supported them.

For IPv6, that's not as true because of the way the options are layered
rather than tacked-on.

>  In this context, UDP options
> are more like IP options since they are not required for use with UDP.
Just like TCP, option support is determined by which options are
activated and the semantics of the options and user (application)
preferences. Whether they're required or not depends on the endpoint's
decision of how they use the options. An endpoint could require
particular options and backoff to TCP where the options are not
supported, e.g., DNSSEC might require FRAG or backoff to TCP.

> So there is a possibility that some vendors (e.g. a firewall) may just
> decide that to start dropping packets or throwing packets that might
> have them into a slow path similar to IP options. If something like
> this is not consistently supported in the Internet, then applications
> are unlikely to use it. I wish this wasn't reality and that the end to
> end model was actually adhered to, but when writing Internet
> applications we have to stick with what is known to work... ie. plain
> TCP/IP or UDP/IP (where support for the latter is still a little shaky
> since some network operators refer to think of UDP as nothing more
> than a DOS vector).
Certainly, but so far all we have evidence of are over-eager firewalls
that incorrectly think that UDP packets whose transport portion are
smaller than the IP payload are an error. That's just as incorrect as
thinking that it's "safer" to drop all TCP packets that support MPTCP.

So yes, like any extension, it works only where the Internet lets it. It
can be useful where needed or preferred, but like any extension, there's
always the possibility that some ignorant party will try to block it in
the name of security.

Again, not new and just like TCP.

Joe