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

"lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk> Wed, 20 February 2019 05:16 UTC

Return-Path: <lloyd.wood@yahoo.co.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 A58E812D4E6 for <tsvwg@ietfa.amsl.com>; Tue, 19 Feb 2019 21:16:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.co.uk
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 lPFwG_kdrUXm for <tsvwg@ietfa.amsl.com>; Tue, 19 Feb 2019 21:16:37 -0800 (PST)
Received: from sonic302-19.consmr.mail.ir2.yahoo.com (sonic302-19.consmr.mail.ir2.yahoo.com [87.248.110.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C51612008F for <tsvwg@ietf.org>; Tue, 19 Feb 2019 21:16:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s2048; t=1550639795; bh=KaEUq2ZMs3K4VgHbMbqEFug49BMWdEFdAefwxQjvF+M=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From:Subject; b=bYhGGWGRhB8s09lVQ4p+XDI+Pyp1K48x/PU3ZI8xk5Og8MnZJzS3/UKJbpDzTJsGPAzewQVQ7AaMj9+fATGhr6DT8FBQaU8ocnSktITBRlgluk+DsdtNHTIxvHKwGxH5SdNQVY1yNjXOAUt7FceNKIhzzUzjBN9aNFqN3Z8ms3LiHtZRgXVH3bXKBNw3bjDCOzgWTc9qrj3i096OFuIKL4AgpE1SwNxgUtDSHmxOspemHE6si7W7XeYswZxmFu0WgWzzmmteKx2OOfQ/T8s1WajRLWG6ivc8mLmQngXWgTX9NxbEu0YwtDQzczkjfe4OUZSFzqap/SaBMpFQxF2Hiw==
X-YMail-OSG: NEbo1vEVM1mBAkPRTU4huS4aFNkMPqwV4Nj9a2gp9ZC8XEs_W13fSIqWvpbwg1E Rr9cIKMJMuK75RQrvpJS8lZ_WFLF2HtgPaHM.lj0ZUVHmny0cVRkxp4iQG7y0M9Ve7guZFdaWHfB 2TzOBbubdVhSFjqIppEJ8Ot0nx.NFQgG7Noihd0EH0cSbok0pWLg_ckAQiOlvEaiECR4cWFvgL0y E4uA7y34119yw0kMVegUHRIqaHWOPZBgRRQpryzkjDLY1i1vhl8.5qY94vTF_8ZHmEj5GSGeNxLQ uUtuIi.h1kjOJds9aAHWKOEf0.6s_TTEHgaX5_ixrSRWnmaBXDPD6AodYeqlx1eTZG5FtV_0Adyn 7SfGaMgDuksMapMGEWyMyLAbySo6Ew5KvrIzD6PRzqjvds_mW6oCA6uBGhnHSciH8Jy7HvAO6ap5 CrRQLpt46mRQVD25aNndVE_AwCEElCrczfMlpeWJrskM92ahHWBPu5uuUU5zjFArZEtsOdmoJSkm YPkURwi7e0238ssAkhhbcuavQcNqyXB7.VtoJnUHo83VS4Q7BF81fkHZQ0p4ezugmcGq2AlzN6SA cqt0rav2AqfqfjkjZhxJm3zEJGzr9_HXv6jA3ZABg7whqn835VuZOBkG1IibuX8_0fCnQP8mMcg5 5za1lIAI5R0DOlubRS9h2UVYT5Wor901KoVO53G1IV41hE1BPiwNn4V0fYVRRXuWh3RGM8Jt8xZT N8SVLFh98QVWEC0mb6H42qMuP8DM65BVsvXMEzAqmWy9TANUi5G4ZfcTt50CQE5DV9UiAwosB7qt mKgn3UT4T_lxYbK3f1tttP8aLJQSWqZklzC1.z_wLJpabTgFA.U56uz22LSBHnCaQIVRfMYq15zQ 8eGNxA7rhAl5th1WUCqwNmXA05haPKNBHLZyxA9qoof49aIK9H8p2UJ3L.aS62lxWVc7EmvoOqjt WGa3kmVBdp3Sfz_SzfYJh4_dwgi1jOeLO4NzIPuzrPx33SqrUExUlYACPzeE1vLlrzpq48tPqVHb doPXjEvyZfjdn5Gvdav2LJCOvLJ6_Nc1KjZF6vJMDEferrbYq2tkWkt_DgMYeKdc4rw--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ir2.yahoo.com with HTTP; Wed, 20 Feb 2019 05:16:35 +0000
Date: Wed, 20 Feb 2019 05:16:33 +0000 (UTC)
From: "lloyd.wood@yahoo.co.uk" <lloyd.wood@yahoo.co.uk>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, Tom Herbert <tom@herbertland.com>
Cc: tsvwg <tsvwg@ietf.org>
Message-ID: <259096320.3298750.1550639793692@mail.yahoo.com>
In-Reply-To: <CALx6S35WuRra0njfY=HOCaF8v9ampkTG612nbjKwid=CHQNumQ@mail.gmail.com>
References: <155052226474.25978.1700439564007128149@ietfa.amsl.com> <CALx6S34o08DY-v-1S59VAerwpnf3wD6puNGe-Jq90aswYdK8Xw@mail.gmail.com> <5C6C3F9C.1070601@erg.abdn.ac.uk> <CALx6S35WuRra0njfY=HOCaF8v9ampkTG612nbjKwid=CHQNumQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: WebService/1.1.13123 YMailNorrin Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/UMi-QH4nCTXlX1NnG2DztlnL1ZY>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt
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: Wed, 20 Feb 2019 05:16:41 -0000

> Conversely, the draft floats the idea of purposely not encrypting
> certain fields of a transport header for the purposes that
> intermediate devices can parse them. What is the deployment experience
> of that? What transport protocols been retrofitted that do that?

Examples include:

TLS encryption over unencrypted TCP - the outer TCP wrapper can
be tweaked by intermediate PEPs to advertise larger windows and
increase buffering for faster traversal of satellite links, and
IP address substitution can be done for proxying purposes.
This provides increased performance over e.g. QUIC, where this
transport control/payload content separation cannot be done.
Deployment experience of this is widespread. Really widespread.

The bundle protocol, where completely encrypting the bundle
means that custodial transfer and discarding of damaged
or truncated bundles could not be done well. This is discussed
in detail in A Bundle of Problems, IEEE Aerospace 2009 - see the
worked example in Fig. 1, which is basically analogous to
checking a bridged Ethernet CRC at each hop before forwarding.

The end-to-end principle says that checking reliability at the
endpoints is necessary, but that for increased performance
it may not be sufficient. Those are two examples of that.

Other examples would be unencrypted tunnel headers carrying
encrypted traffic, or the entire TCP/UDP pseudoheader or
SCTP checksum, where intermediate devices protecting a
constrained link will want to have some integrity check
on the entire contents before forwarding, but the Ethernet
frame may only be goo for the local link.

Lloyd Wood
http://lloydwood.users.sf.net/l/dtn


On Wednesday, 20 February 2019, 05:10:36 GMT+11, Tom Herbert <tom@herbertland.com>; wrote: 

On Tue, Feb 19, 2019 at 9:40 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk>; wrote:
>
> On 19/02/2019, 17:13, Tom Herbert wrote:
> > Hello,
> >
> > I am still having a hard time believing that need for operators to
> > inspect and process transport layer information in ad hoc ways
> > remotely outweighs the need for users' security and privacy and to
> > impede protocol ossification.
> Whatever you c
> > Regardless of the arguments in the
> > draft, I believe that the trend will be more use of encryption even in
> > the transport layer.
> That certainly is the way it looks, to summarise the draft says:
> "
>
>    As seen, different transports use encryption to protect their header
>    information to varying degrees.  There is, however, a trend towards
>    increased protection with newer transport protocols.
>
> "
> > Consequently, it would be nice if the draft had
> > more discussion about alternative means for network devices to get the
> > information about the transport layer that they need.
> Our guidance on scoping means that we can include deployed methods, are
> there examples that you can tell us about?

Extension headers are one. I know in some proprietary datacenter
networks (like Google) there are whole systems that collect per flow
statistics and state from host endpoints. Getting transport
information from an endpoint is FAR more robust and accurate than
trying to infer the same information from an extremely limited
viewpoint somewhere within the network.

> > In particular, I
> > still think possibility of using extension headers is far too easily
> > dismissed by the draft (please see my previous comments about that).
> I also think there may be potential here in future, and would love to
> see this area explored - it is a topic in which I have research, and I
> believe you also. I can't however point yet to deployment examples in
> this area. Do you know more?

draft-hinden-6man-mtu-option, draft-ietf-ippm-ioam-data, draft-herbert-fast

More generally to the need for extension headers to work on the
Internet is demonstrated by segment routing.

Conversely, the draft floats the idea of purposely not encrypting
certain fields of a transport header for the purposes that
intermediate devices can parse them. What is the deployment experience
of that? What transport protocols been retrofitted that do that?

Thanks,

Tom

>
> Gorry
> > Tom
> >
> > On Mon, Feb 18, 2019 at 12:38 PM<internet-drafts@ietf.org>  wrote:
> >>
> >> 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-04.txt
> >>          Pages          : 43
> >>          Date            : 2019-02-18
> >>
> >> Abstract:
> >>    This document describes implications of applying end-to-end
> >>    encryption at the transport layer.  It identifies in-network uses of
> >>    transport layer header information.  It then reviews the implications
> >>    of developing end-to-end transport protocols that use authentication
> >>    to protect the integrity of transport information or encryption to
> >>    provide confidentiality of the transport protocol header and expected
> >>    implications of transport protocol design and network operation.
> >>    Since transport measurement and analysis of the impact of network
> >>    characteristics have been important to the design of current
> >>    transport protocols, it also considers the impact on transport and
> >>    application evolution.
> >>
> >>
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
> >>
> >> There are also htmlized versions available at:
> >> https://tools.ietf.org/html/draft-ietf-tsvwg-transport-encrypt-04
> >> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-04
> >>
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-04
> >>
> >>
> >> Please note that it may take a couple of minutes from the time of submission
> >> until the htmlized version and diff are available at tools.ietf.org.
> >>
> >> Internet-Drafts are also available by anonymous FTP at:
> >> ftp://ftp.ietf.org/internet-drafts/
> >>
>