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

["Gorry (erg)" <[e-mail]>]

I’d expect the most likely method to work for detecting  path packet size for UDP would be an end to end proving method, such as: draft-ietf-tsvwg-datagram-plpmtud

See also:
1. Network layer style MSS-clamping:
- draft-hinden-6man-mtu-option

2. End to end UDP plpmtud probing using the UDP options space;
- draft-fairhurst-tsvwg-udp-options-dplpmtud

Gorry

> On 29 Feb 2020, at 04:15, Joseph Touch <[e-mail]> wrote:
> 
> 
> 
>> On Feb 28, 2020, at 7:27 PM, Erik Kline <[e-mail]> wrote:
>> 
>> 
>> 
>>> 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).
> 
> As discussed on the UDP options draft, the option is more relevant to signal end host reassembly limits, which are not affected by the effects of on-path tunnels.
> 
> (That’s actually how MSS is defined for TCP as well, FWIW; the fact that it’s used for something else seems to be an error that hasn’t been consistently noted).
> 
> Joe
>