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

[Gorry Fairhurst <[e-mail]>]

On 10/04/2020 15:51, Tom Herbert wrote:
> 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.
Yes. That's a very useful observation. I'm hoping if I disect this 
reply, I'll be able to see exactly the part(s) you are talking to.
> The draft provides
> several examples of presumably benevolent instances of passive
> observation,

I do *NOT* think the draft claims passive observation is benevolent, it 
may be, it may not be, that even might depend on usage.

The draft explicitly says in section 2:

    "This analysis does not judge
    whether specific practises are necessary, or endorse the use of any
    specific approach."

> however doesn't acknowledge there are deployed use cases
> of modification.

It was *NOT* intended to ignore that, only to note that any modification 
can be detected by authentication, and to set the context section 2.1 
did provide examples of this. There are other RFCs that talk more about 
that.

> 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

It should *NOT* be making that call.

*EXCEPT* it should assert privacy concerns were appropriate.

> and leads to ossification,
It *SHOULD* state that.
> so both observation and modification should be prevented.
That's a judgement call this did *NOT* plan to make.
> A third camp might say we've been modifying TCP fields
This modification is a (sometimes sad, sometime not sad) reality.
> and our users are seeing great benefits so it's
> okay.
The intent is explicitly *NOT* to decide whether the spectrum of 
modifications are good or bad.
> I don't think there is consensus on which of these viewpoints is
> correct,
So, I think we may agree?
> however I believe that the goal of the draft is trying to
> establish a balanced position without judgement,
I agree.
> so not mentioning a
> known use case that would definitely be affected by transport layer
> encryption seems like an omission.

---

If we happen to agree on scope, then I think your present comment 
relates to section 2.1 and I assume this is somewhere around the text 
that starts:

    In-network measurement of transport flow characteristics can be used
    to enhance performance, control cost and improve service reliability.
    To support network operations and enhance performance, some operators
    have deployed functionality that utilises on-path observations of the
    transport headers of packets passing through their network.

... examples ...

    When network devices rely on the presence of a header field or the
    semantics of specific header information, this can lead to
    ossification where an endpoint has to supply a specific header to
    receive the network service that it desires.

    In all these cases, middleboxes with a hard-coded, but incomplete,
    understanding of transport behaviour, interacted poorly with
    transport protocols after the transport behaviour was changed.

    In contrast, transport header encryption prevents an on-path device
    from observing the transport headers, and therefore stops mechanisms
    being built that directly rely on or infer semantics of the transport
    header information.

Which sentences should be improved?

> 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).

Agree (with the NiT that modification isn't necessarilly prevented by 
authentication: it's detected - that allows it to be prevented).

Is that somehow made unclear by a sentence somewhere that should be fixed?

> Tom
>
>> Gorry
Gorry