Re: Review of draft-mm-wg-effect-encrypt-09

[Mirja Kühlewind <[e-mail]>]

Hi Martin, hi Kathleen,

I would like to comment (for now) just on this one section, as my name was called out.

> Am 11.04.2017 um 05:54 schrieb Kathleen Moriarty <[e-mail]>:
> 
>>> Section 2.1
>>> 
>>> This is one of the few sections that talk about what it means to operate a
>>> service as opposed to operate a network.
>>> 
>>> Overall, this section doesn't work particularly well.  The distinction
>>> between
>>> integrated and standalone load balancing is an interesting division, but
>>> it
>>> doesn't leverage this distinction well.  What causes a standalone
>>> load-balancer
>>> to be necessary?  

My understanding is that the stand-alone load balancer was only brought up to better explain what an integrated load balancer is, assuming that the integrated (more complex) case is the common one. 

However, to answer your question, for a stand-alone laod balancer it is assumed that you only have a small number of servers at one single location and you only need one box that does the load-balancing on these different servers. So all this box needs to know is the IP address of these servers.

>>> Is this something a network operator uses?  I see text
>>> on NFV
>>> later, but it's far removed from the original text and it seems
>>> aspirational
>>> rather than concrete.  On the other hand, many of the concerns in this
>>> document
>>> simply don't apply to an integrated load balancer.

To my understanding all the concerns apply to integrated load balancers. Integrated only means that the load balancer shares some information with the server and based on this knowledge the load balancer can identify based on some information in the packets which server this packet should be forwarded to.

>>> 
>>> The amount of text on QUIC here is surprising.  Given how much of QUIC is
>>> changing right now, we shouldn't publish a document that attempts to make
>>> claims
>>> about what QUIC is or how it is operated.  This attempts to dive into the
>>> details of QUIC connection migration in a way that presumes much about the
>>> outcome of issues that the QUIC working group is still struggling with.
>>> 
>>> I would strongly recommend removing QUIC-specific language from this
>>> section and
>>> the document as a whole.  We have an operational document in the QUIC
>>> working
>>> group that would be a good venue to discuss some of these concerns.
> 
> While we read this as  more of a substantive remark, the text on
> load balancers and QUIC were added per Mirja's IESG review.  We would
> need to check with her about making any changes here.  They were
> specific additions that were requested.
> 
> Further, it is only IETF QUIC that is in active development.
> Google QUIC (referred to as GQUIC in IETF discussions) is a more
> stable experiment now.


I fully agree to remove the quic specific language. It’s definitely too early to say something in this document (and GQUIC is probably not documented well enough to rely on this). This text wasn’t provided by me but I recommended a contributor for this text who is also active in the quic wg and missed this when he send the text.

I recommend to simply remove the following sentences:

"QUIC is an example of such
   protocol in development by IETF QUIC WG right now.“

"New connection-migration-tolerant protocols, such as QUIC, are
   deliberately designed to allow such extra information available in
   plain text (QUIC's server-generated flow IDs).“


> 
>>> 
>>> Is this an oblique reference to (the much-loved) RFC 7974?

No, not at all. There are other ways middleboxes can add information. But in this case actually the server would add information because the load balancers and the server share some knowledge.

>>> 
>>>   Current protocols, such as TCP, allow the development of stateless
>>> integrated
>>>   load balancers by availing such load balancers of additional plain text
>>>   information in client-to-server packets.
>>> 
>>> Otherwise, I don't know what it means.

A server could select a certain sequence number (range), or TCP timestamp, I guess...

>>> 
>>> BTW, I like this parenthetical:
>>> 
>>>   (That said, care must be exercised to make sure that the information
>>> encoded
>>>   by the endpoints is not sufficient to identify unique flows and
>>> facilitate
>>>   Persistent Surveillance attack vector.)
>>> 
>>> I'm going to take this to the QUIC working group, because QUIC certainly
>>> doesn't
>>> meet that bar right now.  It fully facilitates Persistent Surveillance in
>>> its
>>> current form (proper noun?  I haven't really seen that term before, even
>>> though
>>> it draws a neat parallel with Pervasive Surveillance).
>>> 
> 
> OK, let us know what you hear back.  These changes were in response to
> the sponsoring AD's request of that work.

I think this sentence should be removed in this document and a reference to RFC 7258 should be added, instead of coming up with new terminology here that sets the bar higher that what was agreed in RFC 7258.

> 
>>> Editorial:
>>> * "pop" is a term of art that needs explanation.
>>> * "QUIC?s", "network?s" - avoid smart quotes, and - more generally - the
>>>  possessive form for the inanimate.
>>> * "QUIC's server-generated flow IDs" -> "QUIC's connection IDs".
> 
> Thanks for the nit corrections.

Thanks!

I will further comment later!

Mirja