Re: [tsvwg] Regarding DTLS and UDP options

[Joe Touch <[e-mail]>]

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?

Joe