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

[Tom Herbert <[e-mail]>]

On Mon, Aug 26, 2019 at 11:52 AM Gorry Fairhurst <[e-mail]> 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
backup.”

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.

Tom

> 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:   [e-mail]
> Reply-To:       [e-mail]
> To:     <[e-mail]>
> CC:     [e-mail]
>
>
>
> 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:
> 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-08
> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-transport-encrypt-08
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-transport-encrypt-08
>
>
> 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/
>