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

[Martin Duke <[e-mail]>]

 Very well everyone,

I'm conscious of coming in at a very late stage in the consensus -- if
we've already defined header modification as out of scope, then very well
(although it would be good to state that the Introduction, assuming I
didn't miss it there). That certainly negates my comments PEPs and
injection attacks as subjects, although that seems like an important part
of this landscape.

To Gorry:
> That seems rather a simple view! Traffic conditioning and monitoring is
still something that can operate at the flow level and by address, even
on IPsec flows for instance - just with less accuracy, and likely
requiring more heuristics and with more and different "failure" modes
e.g. that impact sequences of packets rather than deterministically drop
packets with specific headers.

By "almost impossible" I was exactly suggesting this kind of approach,
which I am fairly convinced will lead to tears. But people are going to do
what they're going to do, I guess.

Martin

On Fri, Apr 10, 2020 at 7:51 AM Tom Herbert <[e-mail]> 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. 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
>