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

[Kathleen Moriarty <[e-mail]>]

Hi Mirja and Martin,

Responding inline with adjustments that were made to address the
technical comments and responses in this section of the review.  This
will show up in version 11.

On Wed, Apr 12, 2017 at 2:42 PM, Kathleen Moriarty
<[e-mail]> wrote:
> Mirja,
>
> Sorry for the top post.
>
> Thank you for responding on the outstanding items that were more
> technical in nature (QUIC and load balancing).  We'll integrate your
> suggested edits in the next revision.
>
> Kathleen
>
> On Wed, Apr 12, 2017 at 2:28 PM, Mirja Kühlewind
> <[e-mail]> wrote:
>> 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).“
>>

These sentences have been removed.  Thanks for your guidance on these questions.

>>
>>>
>>>>>
>>>>> 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.

Thanks, Mirja.  Deborah suggested some new text for the abstract and
introduction that hits on this same point as well.  It should assist
with some of Martin's tone comments.  As for this specific suggestion,
we deleted the text as advised and added the following per your
suggestion:

       As noted in Section 2 of RFC7258, careful consideration
        in protocol design to mitigate PM is important, while ensuring
        manageability of the network.
>>
>>>
>>>>> 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
>>
>>
>
>
>
> --
>
> Best regards,
> Kathleen

Your assistance is much appreciated.

-- 

Best regards,
Kathleen