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

[Tom Herbert <[e-mail]>]

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

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

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
>
>>
>> We therefore were didn't see the need to call-out methods that
>> require changes to the transport header. There are other docs that take
>> a  look at a much broader swathe of mechanisms. If you want to read more
>> about those, see RFC 8404.
>
>
>