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

From: [email-masked]
Date: Mon, 26 Aug 2019 11:03:07 -0700

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/

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 26 Aug 2019 19:52:34 +0100

In this revision we addressed feedback received and completed some 
editorial work, including
updating the text referring to RFC7872, in preparation for a WGLC.

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: 	[email-masked]
Reply-To: 	[email-masked]
To: 	<[email-masked]>
CC: 	[email-masked]

Abstract:

---

From: Tom Herbert <[email-masked]>
Date: Mon, 26 Aug 2019 13:28:44 -0700

> 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

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 27 Aug 2019 08:53:43 +0100

On 26/08/2019, 21:28, Tom Herbert wrote:
> On Mon, Aug 26, 2019 at 11:52 AM Gorry Fairhurst<[email-masked]>  wrote:
We've been through this discussion before: The current document editors 
see your proposal there is indeed a possibility that such additional 
information could be provided. It's even possible that the additional 
information could be widely supported and therefore widely accessible, 
at some time in the future. However, I think to get to the point where 
this provides a useful tool for analysis would require much more than a 
few sentences in this particular document. The focus of this document is 
not on the solutions.
> updated measurements are needed).
I would support sauch new measurements, and be interested in their 
outcome - as I stated in Montreal.
> This also falls into a class of
If the outcome of the 6man analysis shows that, it could be a conclusion 
for that study. That would, in my own opion, not be a bad thing for 6man 
to conclude.
> trustworthy than the same information being conveyed elsewhere.
The text intends to say that if you copy or summarise the transport 
protocol information used by the endpoints, to another layer - then 
there is a chance the information could be changed in that copy. I think 
it says that.
> I
> end host manipulate it to gain an unfair advantage.
I agree, if the QUIC packet number had been exposed that potential
gaming could have been less. This is however not the point.
> Some TCP fields
> that I believe this is used in satellite networking.
Many satellite links do much more than that with TCP, but do not do this 
with encrypted transports.
> This is might be worth mentioning in the draft.
When the work was chartered two thinks were stated:

- this document would not discuss the pros and cons of middleboxes that 
proactively modified transport headers. Other documents had been 
published that explored that topic.
- this document would not propose or advocate a specific new solution to 
the effects of encryptioon. We would include discussion of deployed 
methods that are impacted, but would not try in this document to seek 
alternate solutions to current methods.

> Tom
I don't see additional text that needs to be added to this document. If 
you're proposing adding text to a new draft, or one of your drafts then 
I think this nis a great place to start proposing new scalable 
approaches that can work with encryption.

Gorry
>> To:<[email-masked]>
>> CC:     [email-masked]
>>
>>
>>