Return-Path: 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 4B2F33A0B2C for ; Fri, 28 Feb 2020 20:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 OIkuUQdTb094 for ; Fri, 28 Feb 2020 20:15:12 -0800 (PST) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CFA83A0B27 for ; Fri, 28 Feb 2020 20:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0NvpJA5qQa/hZGwpjjzab6ra6m881HP8ot8AAQsYnV8=; b=ktnSLvSpVBdNOu/Zj9T/ilEfC YJIUYVOtwo5813vqkXVdAHejpLNCK8em7ZEVKpzKbHb5Z+OFwKQbt7FNuvv4PHAJer8ZtC6V56RJ4 OVtZIJIHHKRLgfDPA3irJkAYBofnbugKr+H/gnQ1C/3MNpuNRXDnGPrx/awQtdTE6iEbYH4y+z1YG dR5rTxYOkqQML2b6yIZIUvWvWpofhSq02LVPnLGIz51T+ANk3Hl2SAU1UUj2Ur+o/AMAx6ZJKhpdC 93Mi34wTCFkwJUROLsjdxzT1VwujOTS36kdnLEfY/04RQZvDLowqvgV3h+lhwmuljv8qwYQMtqX2e dLn5MmzMQ==; Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59926 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1j7tWt-0036Fm-16; Fri, 28 Feb 2020 23:15:11 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_055FA85A-2086-43E6-BA13-83F276FBA876" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Joseph Touch In-Reply-To: Date: Fri, 28 Feb 2020 20:15:06 -0800 Cc: "C. M. Heard" , tsvwg Message-Id: References: To: Erik Kline X-Mailer: Apple Mail (2.3445.9.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 04:15:15 -0000 --Apple-Mail=_055FA85A-2086-43E6-BA13-83F276FBA876 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 28, 2020, at 7:27 PM, Erik Kline wrote: >=20 >=20 >=20 > On Fri, Feb 28, 2020 at 6:06 PM C. M. Heard > wrote: > On Fri, Feb 28, 2020 at 4:18 PM Tom Herbert > wrote: > On Fri, Feb 28, 2020, 4:10 PM Erik Kline > 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. >=20 > "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... >=20 > Also, UDP options as specified in the current WG draft are not = intended to be modifiable in flight: >=20 > >> 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. >=20 > 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=E2=80=99s actually how MSS is defined for TCP as well, FWIW; the = fact that it=E2=80=99s used for something else seems to be an error that = hasn=E2=80=99t been consistently noted). Joe --Apple-Mail=_055FA85A-2086-43E6-BA13-83F276FBA876 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

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=E2=80=99s = actually how MSS is defined for TCP as well, FWIW; the fact that it=E2=80=99= s used for something else seems to be an error that hasn=E2=80=99t been = consistently noted).

Joe
= --Apple-Mail=_055FA85A-2086-43E6-BA13-83F276FBA876--