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

[Martin Duke <[e-mail]>]

Fair enough. I am willing to accept the judgment of the WG on this.

On Fri, Apr 10, 2020 at 8:08 AM Gorry Fairhurst <[e-mail]>
wrote:

>
> On 10/04/2020 16:03, Martin Duke wrote:
>
> 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
>
> Yes, and my own judgment (personal of course) is also that going too far
> down this particular direction could well end in tears.
>
> Gorry
>
> 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
>>
>