Re: [tsvwg] transport-encrypt-14 review, pt 1

[Tom Herbert <[e-mail]>]

On Fri, Apr 10, 2020 at 12:45 AM Gorry Fairhurst <[e-mail]> wrote:
>
>
> On 09/04/2020 21:20, Joseph Touch wrote:
>
>
>
> On Apr 9, 2020, at 12:44 PM, Martin Duke <[e-mail]> wrote:
>
> - Conversely, middlebox interference with headers does enable performance enhancing proxies for extraordinary link types like satellite.
>
>
> Those are only “extraordinary” only in the “been around for 50 years in the Arpanet/Internet”. That understanding goes back as far as RFC 346 and IEN 8.
>
> Additionally, ground nets often experience similar BW delay products, which can be the dominant driver.
>
> There are known ways to help TCP over such links that don’t involve these sort of steps, documented as far back as RFC 2488, some of which are now being incorporated (faster window growth and recovery, ala Hybla).
>
> I.e., just because a mechanism CAN rely on these headers doesn’t mean that’s the only - or even safe - way to do so.
>
> Joe
>
> I'm with Joe there are MANY ways that devices sitting in the network *do* presently change TCP headers. This is not at all restricted to specific technologies such as Satellite. TCP ACK filtering/decimation/etc is commonly used on a variety of paths to reduce return link traffic in WiFi, Docsis, LTE, etc. PEPs have split TCP in many ways where delay and/or loss is important, devices that track or change rwnd are out there, as are other devices that have modified other things for better or worese. However we already have RFC3135, RFC3449, a variety of header compression specs, and more recently RFC8404. All of which delve into these topics.
>
> In an earlier thread, I motivated restoring the focus on methods that observe headers and do not "manipulate" these. It's true that when the WG decided to add the "ossification" examples at the start iof the document, that these were nearly all related to changing headers, but still I think the focus of the remainder should be on methods that do not change headers - That also is the set of methods that could be compatible with end-to-end authentication.
>

Gorry,

I think the draft is trying to walk a fine line. The draft provides
several examples of presumably benevolent instances of passive
observation, however doesn't acknowledge there are deployed use cases
of modification. There are people that would probably agree that maybe
observation is okay but modification is detrimental. There are also
those that might say any use of transport information by intermediate
nodes is bad and leads to ossification, so both observation and
modification should be prevented. A third camp might say we've been
modifying TCP fields and our users are seeing great benefits so it's
okay. I don't think there is consensus on which of these viewpoints is
correct, however I believe that the goal of the draft is trying to
establish a balanced position without judgement, so not mentioning a
known use case that would definitely be affected by transport layer
encryption seems like an omission.

I'd also point out that if a transport protocol developer makes a
conscious decision to not encrypt some data in the transport layer for
the benefit of observation at intermediate nodes, it's just as easy
for them to also purposely not authenticate data so that intermediate
nodes could modify it (again this is independent of any judgement as
to whether intermediate nodes observing or modifying end-to-end data
is a good thing).

Tom

> Gorry