Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt

[Erik Kline <[e-mail]>]

On Fri, Feb 28, 2020 at 6:06 PM C. M. Heard <[e-mail]> wrote:

> On Fri, Feb 28, 2020 at 4:18 PM Tom Herbert <[e-mail]> wrote:
>
>> On Fri, Feb 28, 2020, 4:10 PM Erik Kline <[e-mail]> wrote:
>>
>>> It also seems possible that some UDP options (
>>> https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options) might come
>>> along that could help things like QUIC effectively have a path-modifiable
>>> portion that (a) isn't a HbH extension header and (b) isn't covered by
>>> something cryptographic that would break if it were modified in-flight.
>>>
>>
>> "things like QUIC" would mean protocols encapsulated in UDP. The point of
>> HBH is that it works transparently for _all_ transport protocols whether
>> they are encrypted. Besides, UDP options hasn't yet been proven deployable,
>> so good chance it would just be trading one set of problems for another...
>>
>
> Also, UDP options as specified in the current WG draft are not intended to
> be modifiable in flight:
>
>    >> Options MUST NOT be modified in transit. This includes those
>    already defined as well as new options. New options MUST NOT require
>    or intend optionally for modification of any UDP options, including
>    their new areas, in transit.
>
>
I find that a little sad, actually.  I would expect UDP MSS clamping to be
a thing (in the absence of an AH it should be fine).

I understand the architectural impurity of it, but I also feel like TCP MSS
clamping is the only path MTU mechanism that has a great success rate of
working in the Internet -- for better or worse.  Forbidding UDP MSS
clamping seems to me to be ignoring this state of affairs.