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

"Gorry (erg)" <gorry@erg.abdn.ac.uk> Sat, 29 February 2020 14:20 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A433A0B64 for <tsvwg@ietfa.amsl.com>; Sat, 29 Feb 2020 06:20:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e1MxbSd2SQa0 for <tsvwg@ietfa.amsl.com>; Sat, 29 Feb 2020 06:20:27 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7EB3A0B5E for <tsvwg@ietf.org>; Sat, 29 Feb 2020 06:20:27 -0800 (PST)
Received: from [192.168.0.13] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 7BA731B00247; Sat, 29 Feb 2020 14:20:21 +0000 (GMT)
Content-Type: multipart/alternative; boundary=Apple-Mail-9FA1E913-AC0D-4530-B993-74D5625A29F7
Content-Transfer-Encoding: 7bit
From: "Gorry (erg)" <gorry@erg.abdn.ac.uk>
Mime-Version: 1.0 (1.0)
Date: Sat, 29 Feb 2020 14:20:20 +0000
Message-Id: <E311E936-7781-4755-A98B-057A15378896@erg.abdn.ac.uk>
References: <C4386F14-4F73-4785-AE39-C5FF8A927ABE@strayalpha.com>
Cc: Erik Kline <ek.ietf@gmail.com>, tsvwg <tsvwg@ietf.org>
In-Reply-To: <C4386F14-4F73-4785-AE39-C5FF8A927ABE@strayalpha.com>
To: Joseph Touch <touch@strayalpha.com>
X-Mailer: iPhone Mail (17D50)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/ozoxgqQNnDo-p7ZRuRys7ByY6Ag>
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 29 Feb 2020 14:20:33 -0000

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 <touch@strayalpha.com> wrote:
> 
> 
> 
>> On Feb 28, 2020, at 7:27 PM, Erik Kline <ek.ietf@gmail.com> wrote:
>> 
>> 
>> 
>>> On Fri, Feb 28, 2020 at 6:06 PM C. M. Heard <heard@pobox.com> wrote:
>>>> On Fri, Feb 28, 2020 at 4:18 PM Tom Herbert <tom@herbertland.com> wrote:
>>> 
>>>>> On Fri, Feb 28, 2020, 4:10 PM Erik Kline <ek.ietf@gmail.com> 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
>