Re: [tsvwg] Regarding DTLS and UDP options

[Tom Herbert <[e-mail]>]

On Tue, Apr 18, 2017 at 12:30 AM, Gorry Fairhurst <[e-mail]> wrote:
> On 17/04/2017, 23:31, Tom Herbert wrote:
>
> Joe: How and why should these be different?
>>
>>
> Tom:
>
>> TCP options are pretty much required for operation of the TCP
>> protocol, 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. IP options on the other hand were never required for IP to
>> operate hence they were quickly ossified. In this context, UDP options
>> are more like IP options since they are not required for use with UDP.
>> 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).
>>
>> Tom
>>
> I have opinions on this para, in that I think options in TCP can be selected
> by the TCP stack, they do not explicitly need to be turned on or off by
> applications. A simple example: Timestamp or MSS. If we had similar options
> for UDP, this could also be automated by the stack (e.g., MSS to know the
> maximum receive datagram size). I have ideas of a number of such things that
> could be automatable, and plan to try these as soon as we have a stack that
> supports this.
>
Gorry,

UDP is a connectionless and unreliable protocol, so if the stack were
to on its own accord add an MSS to a packet how and no response was
seen how would it know the difference between a one way communication
and the packet was dropped because some intermediate device enforces
IP len == UDP len?

My concern with retrofitting UDP is that I don't think it can be done
so that all ambiguities are eliminated and hence it will never be
completely robust. For instance, in TCP any part of the TCP header
after the first twenty bytes must be TCP options-- there is no other
possible interpretation of these bits allowed by the protocol. But,
correct interpretation of UDP options in the surplus space is
inherently probabilistic. Even if we put in checksums and magic
numbers and get the probability of misinterpretation very low it will
not be zero. If some existing device happens to be adding random bits
beyond the UDP header (as the draft points out it was never a
requirement that lengths need to match) and this is subsequently
misinterpreted as UDP options causing insidious effects, even if this
happens just once, it is a problem with the protocol not the
implementation.

I think ambiguity is manageable if it is only the communicating hosts
that process the options and the use of options is expressly enabled
for both transmit and receive. If some intermediate device wereto
start parsing and possibly modifying options on its own accord this
would be exceedingly dangerous in my opinion. Such a problem would
potentially be a nightmare to debug in real networks since we don't
even have tools that can would analyze trailers. Fortunately, trailers
are unlikely to be considered by intermediate devices so this problem
is unlikely today. Nevertheless, I think the draft should say up from
that intermediate devices MUST NOT process, examine, or modify UDP
options.

A related concern I have is around security and whether ambiguity can
be exploited. For instance, someone could easily forge a UDP fragment
using the UDP option. If a device supports UDP options they will
interpret this as fragment, if they don't they will see this as plain
UDP packet. This are very different interpretations of the same bits
however both devices could claim protocol conformance-- that's a
potential problem. This becomes a real problem if the ambiguity can be
somehow exploited to bypass security.

The draft should probably include some more consideration for use with
NAT. For instance:

"A host SHOULD indicate FRAG support by transmitting an unfragmented
datagram using the Fragmentation option"

If the host lives behind a NAT this would effectively indicate support
for FRAG for all the hosts sitting behind the NAT. I doubt that's the
intent! FRAG should probably be based on UDP 4-tuple, but even packets
on that flow might not always be going to the same host (an IP anycast
destination for example).

Also, the draft should mention multicast and whether or not UDP
options are allowed with that.

Thanks,
Tom

> Sure, options may not be supported by specific paths - although I suspect
> that enough paths already do support to make it worth trying in many cases.
> The UDP (plus options) transport stack can then include mechanisms to decide
> how to handle loss of options, just as TCP stacks do this today.
> Applications do not need to be involved - perhaps other than to "enable" the
> sender stack to do the correct thing.
>

> Gorry
>
>
>
>