Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

Joseph Touch <> Tue, 07 April 2020 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C8603A0CB6 for <>; Tue, 7 Apr 2020 08:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i560WChujvfK for <>; Tue, 7 Apr 2020 08:43:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5DA23A0CB3 for <>; Tue, 7 Apr 2020 08:43:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; 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=fYqTRuZ0j2XzUJeMopEZVWGKMaWlc5nbzjle3fnHjX8=; b=WlnMCf1LC7Q1ghj3q5kiwy1uN T1gCog1MDCuE8tZllnFe0epHuqeHOVz3X6pl/oK9ecnC2f5LFfXa+Ao1cHqPnyOU2OidadeDy5y95 P5UovrIDhmZaig/1ZJeUmgrGB5DIXfI8Aqfe5AkGc+o1XVgmame1gzIateWDDs28HPUkKUZYYPY+l c/dbuVAMz09inP171c66jAXAp98M/JaRwbcfBx4XddxSn5cL/AL0EvXuCNBbWr0d9bvpX6KGI7Qnn wRiYdz/otGo0xfGTAggonBSIjYxUXyGIy/namMp3zwma8oCzTJ3rly6Scu1OaMEVFRCb0Az94kbI0 4TaCnr+QA==;
Received: from ([]:56475 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1jLqNQ-000IkD-HY; Tue, 07 Apr 2020 11:43:05 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_6B1A75D4-3489-49A5-96BF-D9A107BA84E9"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.5\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Tue, 7 Apr 2020 08:42:59 -0700
Cc: Gorry Fairhurst <>, tsvwg <>
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Tom Herbert <>
X-Mailer: Apple Mail (2.3445.9.5)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14
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: Tue, 07 Apr 2020 15:43:07 -0000

> On Apr 7, 2020, at 8:34 AM, Tom Herbert <> wrote:
> On Tue, Apr 7, 2020 at 8:12 AM Joseph Touch < <>> wrote:
>> Hi, Tom,
>>> On Apr 7, 2020, at 7:40 AM, Tom Herbert <> wrote:
>>> On Mon, Apr 6, 2020 at 6:42 PM Joseph Touch <> wrote:
>>>> Hi, Gorry,
>>>> I’d suggest as follows (just to follow through on the changes):
>>>> In some uses, an assigned transport port (e.g., 0..49151) can identify the protocol [RFC7605]. However, port information alone is not sufficient to guarantee identification. Applications can use arbitrary ports and do not need to use assigned port numbers. The use of an assigned port number is also not limited to the protocol for which the port is intended.
>>> Joe,
>>> RFC7605 acknowledges that port numbers are used to identify the
>>> application protocol, but clearly doesn't condone the practice. I
>>> suggest the text should just paraphrase RFC7605:’
>> I don’t quite understand the above, esp. the use of “condone”. Port numbers are assigned *exactly* for endpoints to identify application protocols *in the absence of any other more explicit coordination* (the draft doesn’t say it so directly, but that’s the summary).
> Joe,
> I meant by using port numbers at intermediate nodes for identifying
> application protocols.

Oh, sorry. I didn’t get that from the text, but agreed.

> For example, QUIC is assigned UDP port number
> 80 and the spinbit was created to be visible and processed by
> intermediate nodes. The only generic way intermediate nodes can
> identify QUIC is by matching the assigned UDP port number. RFC7605
> says that such matching may not be correct, so consideration needs to
> be taken what happens if things are misinterpreted (IIRC, processing
> of spinbit for a packet misinterpreted as being QUIC is considered
> innocuous).


> Also, a corollary should be the hard requirement: "Intermediate nodes
> MUST NOT ever modify transport payload”.

As a general principle, yes - agreed. There’s always the caveat that it’s always OK *with the consent of the endpoints*, e.g., if an enterprise wants to set up the network that way for their users. But in the arbitrary “middle” of the network, it *should* IMO always be MUST NOT.

> I don't believe this draft
> mentions the fact that some intermediate nodes modify unencrypted
> transport layer headers in flight, but this does happen. For instance,
> there are devices that will modify the TCP receive window to optimize
> traffic flow (I believe there are some routers for satellite links
> that do this).

Yes, and they then complain that mechanisms like IPsec “interfere” with that “feature”. Some of what they do might be relatively innocuous, but some - esp. forging ACKs to reduce endpoint-perceived RTT - runs a significant risk of undermining TCP semantics of reliable delivery.

> If this technique were applied to QUIC where the
> network modified some "exposed" fields in the QUIC header then this
> would risk systematic data corruption for UDP packets misinterpreted
> as QUIC (putting the transport layer in a modifiable HBH option would
> not have this problem).
> Tom
>> That said, I was OK with the resolved text I had suggested, with or without the text below - which is also fine.
>> Joe
>>> "Port numbers are sometimes used by intermediate devices on a network
>>> path to interpret transport protocol payload, however any
>>> interpretation of port numbers -- except at the endpoints -- may be
>>> incorrect, because port numbers are
>>> meaningful only at the endpoints [RFC7605]."
>>> Tom
>>>> Joe