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

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

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.

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.

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