Subject: [tsvwg] Review of draft-fairhurst-tsvwg-transport-encrypt

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 8 May 2018 13:22:16 -0400

Hello Gorry & Colin,

Thanks for your work on this draft.  In my opinion, it is very
important to dig through the implications of encrypting transport
headers.  The document is well written and easy to read, thanks for
that as well.  Al and I had a hard time with that since ours was
contribution driven and controversial.

Here's some feedback from my review that I hope you find helpful:

General:
If you added section references to mm-wg-encrypt where it is
referenced, that may be helpful to the reader.

Specific feedback:
The apps side will object to this phrasing as they don't see the need
for any 'help'.  I agree with your point, just warning of the obstacle
in case you can reword it to prevent objections.
   Choosing to encrypt all information may reduce
   the ability for networks to "help" (e.g., in response to tracing
   issues, making appropriate QoS decisions).

Section 3 intro text

Encrypted traffic can also be profiled to identify threat actors.
This will continue to be important as threat actors may have advanced
capabilities and may modify the encrypted streams in identifiable ways
that can differentiate their traffic from others.

I was expecting to see some text toward the end of 3 on adoption of
these protocols.  We can put out protocols, but it's up to industry to
decide when and where to adopt protocols.  From a few recent talks,
what I saw from the audiences is that those aware of QUIC are outright
blocking it.  The business imperative is not there for the
applications using QUIC to justify it's use within the business
network, at least not yet.

Section 3.3
Do you want to make this specific to IPsec tunnel mode since that
hides the true end points as well?  Transport mode isn't well deployed
because of interoperability issues and not current use case driving
it's usage, but that does leave the true IP source and destination
addresses exposed, more than what you see with tunnel mode.

Section 5.3
This is starting to touch on NetNeutrality and if you are going to go
there, you should state it explicitly.  At the enterprise level (it
doesn't seem like you are covering that in this draft), I am hearing
QUIC is outright blocked by those that are aware of it on the network,
so it's not just NetNeutrality that will impact it's deployment.
Perhaps rephrasing may help?  Here's the text I'm talking about:
   A lack of data reduces the level of precision with which mechanisms
   are applied, and this needs to be considered when evaluating the
   impact of designs for transport encryption.  This could lead to
   increased use of rate limiting, circuit breaker techniques [RFC8084],
   or even blocking of uncharacterised traffic.  This would hinder
   deployment of new mechanisms and/or protocols.

Section 5.4
I think you have a typo here:
   Integrity checks can undetected modification of protocol fields by
   network devices,

-- 

Best regards,
Kathleen

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 17 May 2018 06:52:15 +0100

Thanks Kathleen,

it really helps to receive reviews, I'll try to respond to each in turn.

On 08/05/2018, 18:22, Kathleen Moriarty wrote:
> Hello Gorry&  Colin,
I have now tried to do this where I could.
>     issues, making appropriate QoS decisions).
We aded more clarity on the ability for networks to "help" users and 
subscribers.
> decide when and where to adopt protocols.
I'd be happy to improve this section, but at the moment I'm unsure what 
you have in mind.
>  From a few recent talks,
Indeed. I have seen similar talks and discussions that take this view. 
We are trying to the base the draft on what has been deployed and 
approaches that have been used - do you think we could/should say more?
> addresses exposed, more than what you see with tunnel mode.
Yes. I have done this.
>     deployment of new mechanisms and/or protocols.
I would love a suggestion?
>     Integrity checks can undetected modification of protocol fields by
Indeed, and now resolved.
Gorry

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 17 May 2018 08:05:49 -0500

Hi, Kathleen,
On Thu, May 17, 2018 at 12:53 AM Gorry Fairhurst <[email-masked]>
wrote:

> Thanks Kathleen,
>
> it really helps to receive reviews,

My thanks for your review as well. One point for Gorry, which might or
might not be helpful ...

> I'll try to respond to each in turn.
>

In discussions about
https://datatracker.ietf.org/doc/draft-dawkins-panrg-what-not-to-do/, I've
been reminded that the IAB RFC on "What Makes for a Successful Protocol?"
would be a good thing for me to include as a reference (
https://datatracker.ietf.org/doc/rfc5218/).

Perhaps that would be useful for this draft as well?

Spencer