Re: [tsvwg] Fwd: I-D Action: draft-ietf-tsvwg-transport-encrypt-08.txt

Tom Herbert <> Mon, 26 August 2019 20:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FE12120F18 for <>; Mon, 26 Aug 2019 13:29:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rskC3pUGottk for <>; Mon, 26 Aug 2019 13:28:58 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E71DD120EE0 for <>; Mon, 26 Aug 2019 13:28:57 -0700 (PDT)
Received: by with SMTP id g24so899529edu.3 for <>; Mon, 26 Aug 2019 13:28:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=D+Rtn7xkjSX55ybtFn2xnT5NvLe0/n3a3aqbFTJJhAg=; b=JWFU7IE7SMQbSOoL22NvWwv7Ei0ecpWeSfhmGC0GVuoyrLfUUipKZnjWkYWdMHREgh Tdet9DwpPu8t5PdDSArIgynHjctOPyNGTDexKMo/eqYX0f2I9G0caaceySwD8CtemAHj 94yiDSDmutW3WGQMV4b6GJsM53X+onawBtwXJy+BrxiZNy+OmOiN7DjKkvyk1w76EeXu yXyZvU6rLcgPTlCtZgAz0PEDJcQKglnn03iRdWzofWXjNpyEG2eu5/dh1gaY+8U6qIVo wKozg4n43gAwOqleOJGbYFkKKoHg+ftOL6AY/uUGkYbmeySo5TmKBQA9n3BT+1FL0qN9 g97w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=D+Rtn7xkjSX55ybtFn2xnT5NvLe0/n3a3aqbFTJJhAg=; b=VSkICpqxvntuGN7Are5b9qBDalnqCbg+U02wHqk1GyCMTNLKVYECjYjHbLzP8Si/So cogt3ReOX5FrfrB5rH676x/qnw6rLspLct2t00u1p4Y+IfeGtOV6bTfd0wfPyisZu1Am 0AjaA/Xp/gXD4Xm7A7rbtCmYjXXPUaO8ssck80V0j1ravrZiC32mGUKvi7ao0UQGhtsJ bwfNG074MMG9qit7WplnpgzEJf6wG5VaB07jI0gsSbn223pN228ycgDbjNuu/5PSUpM7 KQXgvvmbRfLiXKCIcZFVZjy514TIu0Yg07AQtY59Cl/19TJZ1y62H5yomJ0WjkKJ9jDG miiw==
X-Gm-Message-State: APjAAAVVe10ljosI+7xuur696bE/3MsviD4pmC7T0sPrT0BuxoFlP/0g +kOOZzdYlFVzr/zp2yFt3ruByVFsPYfrFP28i7ngGB0s/A3F1Q==
X-Google-Smtp-Source: APXvYqzClhftIfu6SqqizORsGQvE+w52q3icSAIoZnxiZBgO4uQdeIf93tkcFpAidIJaiq25i8s6KcO0YEqjXGBmROs=
X-Received: by 2002:a17:906:12d3:: with SMTP id l19mr18459795ejb.149.1566851336166; Mon, 26 Aug 2019 13:28:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Tom Herbert <>
Date: Mon, 26 Aug 2019 13:28:44 -0700
Message-ID: <>
To: Gorry Fairhurst <>
Cc: tsvwg <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [tsvwg] Fwd: I-D Action: draft-ietf-tsvwg-transport-encrypt-08.txt
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: Mon, 26 Aug 2019 20:29:00 -0000

On Mon, Aug 26, 2019 at 11:52 AM Gorry Fairhurst <> wrote:
> In this revision we addressed feedback received and completed some
> editorial work, including
> updating the text referring to RFC7872, in preparation for a WGLC.
Hi Gorry,

Thanks for adding the refence. However, I still believe that extension
headers and the possibility of conveying transport layer information
in network layer in general are still not fairly represented. In the
same way that the rest of the document is trying to be balanced by
describing the pros and cons of transport layer encryption, I suggest
presented alternates should also get such consideration.

For instance, the draft does state: "This has the advantage that a
single header can support all transport protocol", but I think that
understates things. Consider:

- All transport protocols means *all* transport protocols, not just
the select few that the network deems important (which currently would
be TCP only). Intermeidate devices only need to implement support
once, not specifically for every possible transport protocol
- It's not just all transport protocols, but *all* use cases of those
transport protocols. Consider that a transport header might be buried
deep in some encapsulation which may or may not be parseable in the
network or may be in an encrypted tunnel-- this is not a problem if
the information is in the network layer
- This eliminates one rationale for doing deep packet inspection.

Similary, the disadvantages are overstated. Consider:

- From the draft: "Current measurement results suggest that it can be
undesirable to rely on methods requiring end to end support of network
options or extension headers across the Internet." That is highly
subjective and note that RFC7872 did not draw that conclusion it only
presented the data (we had the dicsussion in 6man WG in Motreal that
updated measurements are needed). This also falls into a class of
standards that are unrealiable because of non-confirmant  intermediate
devices. This general topic came up recently in 6man with regard to
fragmentation. Joe Touch suggested some text:

“The Internet is a best-effort system and lacks a formal validation or
conformance mechanism. Like any other protocol feature, IP
fragmentation is useful only when it actually works - both by
successfully traversing routers and other in-network devices and when
it is correctly supported by endpoints. As a consequence, like any
other protocol feature, IP fragmentation MAY be used by new protocols
that validate its successful traversal and provide an alternate as a

Substitute "IPv6 extension headers" for "IP fragmentation" and that is
guidance that could be applicable here.

- From the draft: "The incentive to reflect actual transport
information needs to be considered when proposing a method that
selectively exposes header information." That seems to assume that
just because something is in the transport layer header that it's more
trustworthy than the same information being conveyed elsewhere. I
don't think that is necessarily true, and probably based on the ad hoc
parsing of TCP in the network. But, looks can be decieving. For
instance Spin Bit in QUIC header needs to consider possibility that
end host manipulate it to gain an unfair advantage. Some TCP fields
could be manipulated in same way (we already know that some
intermediate devices rewrite receive windows so that it doesn't
reflect the actual receive window of the host).

Btw, to the last point, encrypting the transport header would also
impact network devices that update the transport header. The
aforementioned receive window modification in flight is an example
that I believe this is used in satellite networking. This is might be
worth mentioning in the draft.


> Best wishes,
> Gorry&  Colin
> -------- Original Message --------
> Subject:        [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-08.txt
> Date:   Mon, 26 Aug 2019 11:03:07 -0700
> From:
> Reply-To:
> To:     <>
> CC:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Transport Area Working Group WG of the IETF.
>          Title           : The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet
>          Authors         : Godred Fairhurst
>                            Colin Perkins
>         Filename        : draft-ietf-tsvwg-transport-encrypt-08.txt
>         Pages           : 45
>         Date            : 2019-08-26
> Abstract:
>     This document describes some implications of applying end-to-end
>     encryption at the transport layer.  It first identifies in-network
>     uses of transport layer header information.  Then, it reviews some
>     implications of developing end-to-end transport protocols that use
>     encryption to provide confidentiality of the transport protocol
>     headers, or that use authentication to protect the integrity of
>     transport header information.  Since measurement and analysis of the
>     impact of network characteristics on transport protocols has been
>     important to the design of current transports, it also considers the
>     impact of transport encryption on transport and application
>     evolution.
> The IETF datatracker status page for this draft is:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at: