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

Kathleen Moriarty <> Wed, 12 April 2017 18:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B1561296C6 for <>; Wed, 12 Apr 2017 11:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DaG9jG7KG-rZ for <>; Wed, 12 Apr 2017 11:43:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 98F0A12955B for <>; Wed, 12 Apr 2017 11:43:37 -0700 (PDT)
Received: by with SMTP id 72so10379473pge.2 for <>; Wed, 12 Apr 2017 11:43:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=D8jZ7KgdtWHRuFOmrybIhr1R6PO0moxnCewZj4WeN3s=; b=sfTRcaat0upCeRBo52OXqn90xPv/012yzcL4g/1KqdbwxfMBosVNQHNoick3o+BlCk +fVAknZPQgPnCJJ90HMnEY63thYQr5ggWa5or2PXi+m/vHlsfVfO6MXiCsM7D6s9nBFA NdNcAGAGPXafM1+N954odkTtOAf2Uzs8phbHeXxACBOFByG/7IPyPSL1uY3AvS73es45 lozxqCVGAjPINP11Q+wogBc80E9649ZShpqIkcW50MIibVncTdTKavdHr8z/53SPJ2LQ a5RtKtIdo17v5Al8zwl9b7zF182pS4y2yyTTnqktMnl0J34MReMjJ0Xwz5pev7vl83vz DEcw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=D8jZ7KgdtWHRuFOmrybIhr1R6PO0moxnCewZj4WeN3s=; b=QJYsCeCXeyKdTmvk+CN2rYzFZYsMWHRT/gKj0X4IJrzXJMk1QQkvo3KAnSLB9Dv/6P bJ4Tt/Hb/AucBgnXWMNtx9mXeWRR0eWXFyiwAMFtzbDgPRFR15nVjs8WjdaIfSEBzXOi TZSdkLij0T0ngUDdaY/Uy+63T4NFKp04KbNvwSwBTBJ6hlGc0otbaVmSUGZjc2tbsa4Y Q14vMpuZ892lTChZ/X8dz0qm5Q2XIYaE3y9pTGtJOw9el23JzvEIrhrLHeNLGUGfQ4Nn EGfHBkvCgkoNysNuWtmeYGvyQzixeYeRRlfCuJ5dg2xFhT3GXF8uGkUxjQ/NYGb4+4DI 6diA==
X-Gm-Message-State: AN3rC/7D+12YxUHtn77T5++gnzh+YJXhTxEZfy9/6Dp0JNn/gIbDlmZ+q16IDqggLQmAfFr4p0Rnf2SfZDdvjg==
X-Received: by with SMTP id d83mr15338312pfd.68.1492022617157; Wed, 12 Apr 2017 11:43:37 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 12 Apr 2017 11:42:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Kathleen Moriarty <>
Date: Wed, 12 Apr 2017 14:42:56 -0400
Message-ID: <>
Subject: Re: Review of draft-mm-wg-effect-encrypt-09
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>
Cc: Martin Thomson <>, IETF <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Apr 2017 18:43:40 -0000


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.


On Wed, Apr 12, 2017 at 2:28 PM, Mirja Kühlewind
<> 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 <>om>:
>>>> 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


Best regards,