ietf
[Top] [All Lists]

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

2017-04-12 13:28:50
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 
<kathleen(_dot_)moriarty(_dot_)ietf(_at_)gmail(_dot_)com>:

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