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

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

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