Re: [tsvwg] Regarding DTLS and UDP options

[Tom Herbert <[e-mail]>]

On Mon, Apr 17, 2017 at 3:09 PM, Joe Touch <[e-mail]> wrote:
> Hi, Tom,
>
>
> On 4/17/2017 3:00 PM, Tom Herbert wrote:
>> On Mon, Apr 17, 2017 at 2:07 PM, Joe Touch <[e-mail]> wrote:
>>> ...
>>> I don't think we should be writing rules to indicate who should NOT be
>>> changing them, if we already have rules indicating the only parties that
>>> can. (granted, the requirement in 7 needs to be revised in 2119-speak).
>>>
>> Joe,
>>
>> You may want to look at IPv6 EH description for guidance. Even with
>> all the words about how extension headers can't be examined or
>> processed with the exception of HBH options, there still has been
>> considerable discussion on what intermediate devices can or can't do.
> The situation is completely different.
>
> IP is intended for inspection - and HBH headers for modification - by
> network devices other than the endpoints.
>
> Transport headers have no such role. Any device that tampers with
> transport headers already needs to be (effectively) an endpoint or
> acting on the behalf of an endpoint.
>
>> Clarifying the exact requirements upfront is beneficial.
> Yes, which has already been done. These are declared as owned by and for
> the use of the endpoints, just like the transport header.
>
> We don't have documents that declare that TCP headers or options MUST
> NOT be modified by middleboxes, even though that's always been
> effectively the case. The only way a middlebox gets around that rule is
> by assuming the behavior of an endpoint, essentially.
>
>> In the
>> absence of such clarity, we need to assume that anything in clear text
>> is subject to inspection and possible modification
>
> We already have docs describing (true) transport and network layer
> security. If you don't want data inspected or modified, that's the only
> solution.
>
> I see no reason to declare anything special about middleboxes here.
> Frankly, they can modify these options just like they modify the UDP
> header - at their own risk.
>
>> so that the end
>> result is often ossification of what might have otherwise been a
>> useful feature (although even with clear requirements abuse and
>> ossification is still a possibility). Neither can we expect
>> middleboxes to always know what they're doing. Fundamentally, if I, as
>> an application developer, can't trust the network not do mess with my
>> UDP options, it's likely I simply wouldn't use them (hence
>> ossification even before deployment).
> Do you use TCP options?
>
> How and why should these be different?
>
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

> Joe