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

[Tom Herbert <[e-mail]>]

Hi, here's a few comments on the latest draft.

>From the introduction:

"These benefits have been widely discussed [RFC7258], [RFC7624], and
them. There are also, however, some costs, in that the wide use of
this document strongly supports the increased use of encryption in
transport encryption requires changes to network operations, and
transport protocols."

I am not exactly sure what this means, but if this saying that the
document strongly supports increased use of transport header
encryption can transport header encryption be a RECOMMENDED
requirement.

>From the draft:

"To achieve stable Internet operations the IETF transport community
has to date relied heavily on measurement and insights of the network
operations community to understand the trade-offs, and to inform
selection of appropriate mechanisms, to ensure a safe, reliable, and
robust Internet (e.g., [RFC1273],[RFC2914])."

The two referenced RFCs are hardly recent (1991, 2000). Is there
something more recent that describes how the transport community is
"heavily" relying on transport layer measurements from the networking
community? I'd point out that we've made substantial changes to TCP
like ICWD=10, TFO, and BBR without needing input about the transport
layer from network operators. Host endpoints have the necessary
statistics and measurements to develop and validate such features. It
seems the only time we needed to specifically consider the network was
when packets for new transport layer features are blocked (like in the
case of TFO when SYN packets with data were being dropped).

>From the draft:

"transport designers have often ignored the implications of whether
the protocol designers have often ignored the implications of whether
the information in transport header fields can or will be used by in-
information in transport header fields can or will be used by in-
network devices"

Actually, I believe the the opposite is true. Host developers and
protocol designers are very much aware of the implications of
intermediate devices consuming transport layer information. This is
not because we're trying to help the network mechanisms, it's because
we need to work around protocol ossification caused by non-conformant
devices in order to maximize the chances of packet delivery.

Tom

On Sun, Nov 25, 2018 at 11:46 AM <[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-03.txt
>         Pages           : 41
>         Date            : 2018-11-25
>
> 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-03
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-03
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-03
>
>
> 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/
>