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

[Gorry Fairhurst <[e-mail]>]

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] 
> <mailto:[e-mail]>> wrote:
>
>     On Tue, Apr 7, 2020 at 3:54 PM Spencer Dawkins at IETF
>     <[e-mail]
>     <mailto:[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] <mailto:[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] <mailto:[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