Re: [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-14

[Spencer Dawkins at IETF <[e-mail]>]

On Wed, Apr 8, 2020, 05:08 Gorry Fairhurst <[e-mail]> wrote:

>
> On 08/04/2020 02:57, Spencer Dawkins at IETF wrote:
>
> Hi, Tom,
>
> On Tue, Apr 7, 2020 at 6:29 PM Tom Herbert <[e-mail]> wrote:
>
>> On Tue, Apr 7, 2020 at 3:54 PM Spencer Dawkins at IETF
>> <[e-mail]> wrote:
>> >
>> > I'm happy to defer to Magnus on this, but ...
>>
> I also see more now - I'm happy to defer to MARTIN on this!

My apologies for missing the change in responsible ADs.

Best,

Spencer

> >
>> > On Tue, Apr 7, 2020 at 2:10 PM Gorry Fairhurst <[e-mail]>
>> wrote:
>> >>
>> >>
>> >> On 07/04/2020 19:11, Tom Herbert wrote:
>> >> > On Tue, Apr 7, 2020 at 9:20 AM Black, David <[e-mail]>
>> wrote:
>> >> >>>> Also, a corollary should be the hard requirement:
>> >> >>>> "Intermediate nodes MUST NOT ever modify transport payload”.
>> >> >>
>> >> >>
>> >> >>> As a general principle, yes - agreed. There’s always the caveat
>> that it’s always OK
>> >> >>> *with the consent of the endpoints*, e.g., if an enterprise wants
>> to set up the
>> >> >>> network that way for their users. But in the arbitrary “middle” of
>> the network, it
>> >> >>> *should* IMO always be MUST NOT.
>> >> >>
>> >> >>
>> >> >> As a general requirement, that’s fine, but it should be stated
>> somewhere other than in this draft, e.g., as this draft is intended to
>> become an Informational RFC.
>> >> >>
>> >> > David,
>> >> >
>> >> > Changing transport layer header, e.g. for traffic flow optimization
>> >> > such as those devices doing receive window modulation, might also be
>> >> > another use of transport header information that could be included in
>> >> > section 2.1. Currently, the draft only seems to consider uses based
>> on
>> >> > passive observation of transport headers.
>> >>
>> >> Yes, that was the intention to talk about using the information, not
>> >> changing the header.  WE don't discuss methods that modify the
>> transport
>> >> header, some ACK-modification methods, Window Modulation,
>> >> proxy-intercept, PEPs, etc, which can't work if you authenticate the
>> >> headers.
>> >
>> >
>> > That was my understanding when I was encouraging Gorry on this draft.
>> >
>> > In addition to the likelihood that the description of passive observers
>> would be considerably delayed by inclusion of description of active
>> middleboxen dorking with transport headers (we did not lack for controversy
>> on passive observers, in 2017), I wasn't confident that we could come up
>> with a taxonomy of what dorkers were doing, and why they were doing it.
>> >
>> > That's probably the result of me spending time in the SIP community,
>> when we tried to describe what Session Border Controllers were doing in
>> https://tools.ietf.org/html/rfc5853, while SBC vendors were adding
>> features as quickly as their engineers could type. You won't be shocked to
>> discover that vendors considered their dorking to be "secret sauce", that
>> differentiated their products from their competitors, and were not lining
>> up to tell us what they were doing.
>> >
>>
>> Spencer,
>>
>> That reminds me of the olden days when some dorker providers were
>> parsing HTTP and replacing ads with their own :-)
>>
>
> I'm guiltier than I look about dorking with TCP and HTTP in middleboxes,
> but let's just walk away from that  ...
>
>>
>> > So, unless someone can convince the working group that documenting the
>> dorkers can be completed in finite time and space, I'd discourage expanding
>> the scope of this draft, at this time.
>> >
>>
>> it might be good to clarify the draft that only uses cases of
>> transport information being observed are in scope.
>>
>
> That would indeed be a clarification - I'll let the shepherd and author Do
> The Right Thing, of course :-)
>
> Best,
>
> Spencer
>
>
>>
>> As I said, the potential tussle happens if the transport protocol
>> designer decides to make some transport header information visible and
>> doesn't consider that the network may then modify the information-- I
>> believe this is prevented in QUIC since the plaintext parts of the
>> QUIC header are authenticated, but that might not be the case for
>> other transport protocols.
>>
>> Tom
>>
>> > And that's not in any way intended to say that documenting the dorkers
>> would be a bad thing, if the working group thought it was possible.
>> >
>> > Best,
>> >
>> > Spencer
>>
> I see more now. Thanks Tom for raising this threda up, I will take a look
> at the document - I see that since we added examples in the first WGLC,
> there are some places where the language could mislead. I'll seek to repair
> those in the next rev.
>
> Gorry
>