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

[Gorry Fairhurst <[e-mail]>]

On 26/08/2019, 21:28, Tom Herbert wrote:
> 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.
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.
> 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).
I would support sauch new measurements, and be interested in their 
outcome - as I stated in Montreal.
> 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.
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.
>
> - 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.
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
> 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.
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
> 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.
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
>> 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/
>>