Subject: Christian's review of draft-mm-wg-effect-encrypt-22

From: Christian Huitema <[email-masked]>
Date: Sat, 24 Feb 2018 19:29:59 -0800

Kathleen prompted me to review the latest revision of this draft,
promising me that I would "be a lot happier with version 21". I am
actually looking at version 22, and I certainly appreciate the amount of
work that went into improving this draft. We saw 9 revisions over the
last two months, so clearly the authors have been very busy. And the
result is indeed much improved. The old versions were sometimes
irritating, the new version is much easier to follow. I appreciate that
in many places, instead of just lamenting the loss of clear text
inspection capabilities, the draft lists the ongoing efforts in the IETF
to propose alternatives. Mostly, I like the general tone, carefully
asserting that documenting controversial practices is not an
endorsement. And I like the call for cooperation between application
providers and network managers, to develop suitable management and
debugging API.

By and large, I believe that this document is ready.

By that, I mean that we have probably reached an equilibrium, and that
further discussions might delay publication, but will not significantly
alter the content. Despite that general assertion of readiness, I think
that mention two sections that could still be improved.

The section on load balancers (2.2.1) fails to mention that end to end
solutions may very well solve the issue with CDN anycast, by simply
migrating the connections to a CDN unicast address. MTCP would allow
this today, and QUIC most probably will allow that tomorrow. Simple
improvements in the end-to-end transport might obviate the need for
complex deployment of load balancers in the network, resulting in an
overall simpler architecture.

I am very skeptical of the justification for performance enhancing
proxies in section 2.2.4. It develops the idea that having a form of
hop-by-hop transport would be more efficient than end-to-end transport,
because each hop controller would have a shorter RTT to manage and thus
could react more quickly. I understand that argument, and in fact I used
to believe it in the early 80's. Hop by hop control, as done by X.25 and
HDLC in 1980, was arguably more efficient than end-to-end control via
TCP, although of course less flexible. But then by 1988 Van Jacobson
demonstrated that with improved congestion control, TCP was in fact as
efficient or more than hop by hop alternatives. At that point, the
better flexibility of TCP and the simpler network architecture won the
day. I am pretty sure that someone in the CCRG will come up with
innovative congestion control that will similarly moot the debate. In
fact, they may already have. And I would appreciate a pointer to this
kind of history in the draft.

I could go on with more detailed feedback, but I want to keep this
review short, and maybe I am suffering a bit from review fatigue. My
final point is that there are quite a few typos in the draft. Please run
a spell checker and fix them.

-- Christian Huitema

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 25 Feb 2018 23:51:47 -0500

> proxies in section 2.2.4. It develops the idea that having a form of

These are primarily 'satellite games' proxies.. that early-ack and such to
make the long satellite portion of the transport seem short(er).
They only REALLY need to see TCP headers, so ipsec is problematic, but not
(probably) tls.

---

From: Joe Touch <[email-masked]>
Date: Sun, 25 Feb 2018 21:21:07 -0800

On Feb 25, 2018, at 8:51 PM, Christopher Morrow <[email-masked]> wrote:

> These are primarily 'satellite games' proxies.. that early-ack and such to make the long satellite portion of the transport seem short(er).
> They only REALLY need to see TCP headers, so ipsec is problematic, but not (probably) tls.

Enabling TCP Hijacking should never be justification for “needing” to avoid transport header privacy, IMO. 

Games or other apps that “need” such support ought to “need” to explicitly permit it by peering their security with those proxies directly.  

Joe

---

From: Christopher Morrow <[email-masked]>
Date: Mon, 26 Feb 2018 14:02:08 -0500

On Mon, Feb 26, 2018 at 12:21 AM, Joe Touch <[email-masked]> wrote:

> Games or other apps that “need” such support ought to “need” to explicitly
> permit it by peering their security with those proxies directly.
>

apologies: "games" in my reply could better be called: "shennanigans" ...
not games like farmville, but messy things the satellite ( in the past
anyway) providers would do to make tcp appear to perform better in their
environment.

Yes, people COULD ipsec around that problem.
Yes, people COULD md5-tcp around that problem. (tcp-ao, ha!)

generally none of that has happened though.