Re: [saag] [tsvwg] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

[Tom Herbert <[e-mail]>]

On Mon, Nov 4, 2019 at 9:47 AM Gorry Fairhurst <[e-mail]> wrote:
>
> Just focussing on the end...
>
> On 04/11/2019, 16:29, Christian Huitema wrote:
> >>
> >> [MK] That’s not the intention here. But we also need to consider ways
> >> to interact with the network where this brings benefit to both the
> >> network and the performance of the end-to-end traffic. There are
> >> situation where this is the case. And I don’t think one makes sense
> >> without the other.
> >>
> > You seem to be arguing for something like "performance enhancing
> > proxies". End-to-end encryption is indeed a way to opt out of such
> > proxying. Measurements so far indicate that opting out has very little
> > impact on actual performance, and that whatever impact there is could
> > be reduced by improvements in end-to-end algorithms. In fact, in many
> > cases, end to end performance is better without such proxies. But the
> > real reason for the opposition to the concept is ossification.
> > Enabling such proxies would quickly ossify the new transports, and a
> > such there is a strong consensus in the end-to-end transport designers
> > to use encryption and prevent interference by such devices.
> >
> On PEPs: The current case for many of the network segments I see is that
> QUIC is quite good, but it is considerably worse (currently) than a PEP
> using Split-TCP. That's not to say it can't improve - but that's not
> true yet. However: It's curious that people keep going back to PEPs,
> because network devices that change the transport header were
> specifically out-of-scope for this ID!
> >
> > This does not mean that network level deployment have no role in the
> > future. I could see for example tunnels deployed that use FEC or local
> > retransmission to mask the poor performance of a particular subnet. Or
> > I could see end-to-end devices opting into some kinds of application
> > level caching services in order to improve performance. But the draft
> > should be clear: transport protocols do not have to enable
> > interference with the transport bits.
> >
> There are also many operators - e.g., enterprise who rely on the methods
> currently mentioned in this draft. In this case, they also actually *do*
> care about the performance of the networks they operate. They also do
> care about the topics, which matters most depends on which organisation.
> >

Gorry,

"Many" is not "all". And even if all operators cared about this, they
will be all over the board about what information they need. If the
draft were to say that items X, Y, and Z are needed to be exposed in
the transport layer then that might be something we can work with and
this would be a different conversation. But, I don't believe you'll
ever get agreement on that. This is _exactly_ the same quandy we got
into we asked the operators what information they needed out of
transport payload when discussing encrypting transport payloads.

So basically what we're left with is plain text transport layer
information _may_ be important for some use case and _may_ have
legitimate reason to be read in the network, but we _can't_ describe
the exact circumstances when the information is required, we _don't_
know what a priori what transport protocols the network can even parse
so it can extract the information, the set of required information is
_undefined_, and we _don't_ have a good assessment of what the
security and privacy risks are. Given this, I still don't see much of
an argument that transport developers shouldn't encrypt as much a
possible-- to me it's clear the benefits outweigh the cost.

> > My take is that this draft should not be published as is. It should be
> > rewritten to actually reflect the consensus of the transport area,
> > which has to reflect in particular the work in the QUIC working group.
> >
> I suspect the information you wish to see about QUIC's design is
> actually available. I'm not sure documenting QUIC is helpful here, if
> the QUIC WG wants to so that, can't it be added to the manageability draft?
>
> I dispute the claim that the entire transport area has the same
> priorities as that voiced at the QUIC WG. I think this discussion needs
> to look outside the QUIC working group and examine other transports and
> WGs. As far as I know the RTP people are still doing specs in the IETF,
> as are various other transport working groups. Also, this draft has been
> presented at OPsec, and has contributors from other areas outside
> transport...
>
> My assertion is that *current* practice is using transport header
> information & header authentication/encryption is becoming common, let's
> set out what the current facts are. I'm also going to oppose documenting
> new ideas for how we can go forward - as Spencer insisted when this was
> chartered: Proposing new methods belong in a different draft - paraphrased.
>
Then I suggest to remove any discussion along those lines including
the references to alternatives include the discussion about and the
inherently negative comments about their potential use.

Tom

> Gorry
>