Re: [tsvwg] Regarding DTLS and UDP options

[Tom Herbert <[e-mail]>]

On Mon, Apr 17, 2017 at 2:07 PM, Joe Touch <[e-mail]> wrote:
>
>
> On 4/17/2017 1:47 PM, Tom Herbert wrote:
>> ...
>>>
>>>> One thing that might be missing from the draft is middle box handling.
>>> This is already discussed extensively in the document, including in
>>> response to previous TSVWG discussion. That's why we now default to
>>> using the OCS and a length validation. Do you have specific concerns?
> ...
>
>>>
>>>> and so middleboxes must pass packets with UDP options,
>>>> should not attempt to parse the UDP options, and must not modify
>>>> options.
>>> We already addressed that in the doc.
>> I'm sorry, which section is this info in?
> The doc talks about legacy issues throughout.
>
> Sec 5.3 talks about the option checksum and Sec 9 talks about
> interactions with legacy devices in general.
>
> Section 7 explicitly indicates that these are for transport endpoint use
> only.
>
> 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.
Clarifying the exact requirements upfront is beneficial. In the
absence of such clarity, we need to assume that anything in clear text
is subject to inspection and possible modification 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).

Tom

> Joe
>
>
>
>
>
>