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

["[e-mail]" <[e-mail]>]

> 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 <[e-mail]> wrote: 

On Tue, Feb 19, 2019 at 9:40 AM Gorry Fairhurst <[e-mail]> 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<[e-mail]>  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/
> >>
>