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

[Tom Herbert <[e-mail]>]

On Fri, Apr 10, 2020 at 8:24 AM Gorry Fairhurst <[e-mail]> wrote:
>
>
> 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?
>

Gorry,

Here is the pertinent sentence from the draft:

"It is important to understand how transport header information is
used by networks, to allow future protocol designs to make an informed
choice on what, if any, transport layer information to expose to the
network."

If this draft isn't going to dive into the uses of transport header
information being modified by the network then I suggest this sentence
should followed by a statement like:

"This document highlights uses of passive observation of transport
headers by network. Use cases where network nodes may modify transport
layer information are out of scope and described in [RFC...]."

Also, I'm not sure the term "expose" is well defined. Does this mean
to only make visible for observation, or to make it both visible and
modifiable? It might not matter here since there are no normative
requirements, but if the term were used elsewhere in a normative
context we may end up regretting any ambiguity.

Tom

>
> Gorry
>
> Gorry