Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT)

Francois Le Faucheur <flefauch@gmail.com> Wed, 08 June 2016 15:38 UTC

Return-Path: <flefauch@gmail.com>
X-Original-To: cdni@ietfa.amsl.com
Delivered-To: cdni@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95E7A12D69C; Wed, 8 Jun 2016 08:38:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZp1juDcD_54; Wed, 8 Jun 2016 08:38:12 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E8312D69B; Wed, 8 Jun 2016 08:38:11 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id m124so22736554wme.1; Wed, 08 Jun 2016 08:38:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=cTm2d4TAXiesZn0DEhEOIaTR9o8Uwd70AhR2d0JbHLg=; b=c2mfA58D7x6Y9LCMO15SmjD/H+cwY0eI6vk5IMsrj+fS8k+Jyb6FqN2JjZO4/xZ45U 1TzMMavOcXHmxzRTRoad9YwITTyNHpnPHgit2npDOGsyrhEL0DwOlOHvzBgh7+kWz6YP hKkpZL+Rhyue5wIJXSSonN6G3xGo7BtxfY9zemm4Pv0Q1m8vdKsqarYeCQXERkfvGfTx EF5zLKTm62akLmGl+ll8w8f6gFendHYAUJaL1czV2eQRg/DvXwbKIAJ/txZyX3kQLdpf 8oq2VCBMGaJx0J23clhpx9Rp8NTgWEPxT8VzBgucG49d5tlK8NUWny+1IWsX8unBotj/ XU4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cTm2d4TAXiesZn0DEhEOIaTR9o8Uwd70AhR2d0JbHLg=; b=V/gXup1XXU3zQxvbiDLFXS82X+HzYplCLLMEn6cCPW+TcJM+vBYgvT0Xai7nOi2ozP i81klp1Bk7HwGVaYWjHOGWws8AVipuurQU1gIye483vIbtty719NVgtNIq77a93Zk5Nn fSyds06O047jTYUKgvz6Qa/yFy/cOmlQM5UmWGWLHsXBKyl2dbEiSbIV2/oKuR2fepvh oW9+/w8xd8q8pTdnvlBYnkjVJ3DhgzPZrxVNwuqHwk4LRWnPtyeJxlzw4A5zZs0zdjYi r5kdrDKMvGvkUDPLO3PNOH4rnNxuEb5VEK/1sAnB6ATOrqtG65hTGruliVA/GegPWd6A n7UA==
X-Gm-Message-State: ALyK8tISYNUT6cH44USmX6Bry5ct4qnYXNzr+WqldiMANL5NrOQ8YAXIT0KaZMfXBQV5rg==
X-Received: by 10.28.234.221 with SMTP id g90mr5676035wmi.30.1465400290199; Wed, 08 Jun 2016 08:38:10 -0700 (PDT)
Received: from [192.168.1.21] (125.216.113.78.rev.sfr.net. [78.113.216.125]) by smtp.gmail.com with ESMTPSA id p9sm2116682wjv.21.2016.06.08.08.38.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jun 2016 08:38:09 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_AC99D28D-77E0-4ACF-B26A-2158F68CD8CE"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Francois Le Faucheur <flefauch@gmail.com>
In-Reply-To: <3850695D-BA08-46E3-9D85-A098C3FB0369@nostrum.com>
Date: Wed, 08 Jun 2016 17:38:07 +0200
Message-Id: <FA532F87-789D-4836-9082-743B0D7B73F9@gmail.com>
References: <20160518223257.14733.37895.idtracker@ietfa.amsl.com> <3E2786B2-9204-447C-9A53-A3CB0213E0F5@niven-jenkins.co.uk> <573CFEC8.8010600@cs.tcd.ie> <5DED924E-C407-44E9-8FF1-477B26B69647@niven-jenkins.co.uk> <573D09D5.1020501@cs.tcd.ie> <C23FF36A-E663-4158-B6CE-4E129BFEE9C2@niven-jenkins.co.uk> <573D19C3.3050304@cs.tcd.ie> <A4F4089F-DAB0-4BE2-AE95-6B3BABB52D04@niven-jenkins.co.uk> <59AB96A8-B811-443A-8256-54D45141F96E@gmail.com> <CCFC316B-04CD-4EAB-87EC-618FE6166931@gmail.com> <3850695D-BA08-46E3-9D85-A098C3FB0369@nostrum.com>
To: Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/XLX_TccUQFndj0sY9VLI_Ui27iU>
Cc: cdni@ietf.org, cdni-chairs@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-cdni-logging@ietf.org, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [CDNi] Ben Campbell's Discuss on draft-ietf-cdni-logging-25: (with DISCUSS and COMMENT)
X-BeenThere: cdni@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This list is to discuss issues associated with the Interconnection of Content Delivery Networks \(CDNs\)" <cdni.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cdni>, <mailto:cdni-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cdni/>
List-Post: <mailto:cdni@ietf.org>
List-Help: <mailto:cdni-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cdni>, <mailto:cdni-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jun 2016 15:38:14 -0000

Hi Ben,


> On 8 Jun 2016, at 16:33, Ben Campbell <ben@nostrum.com> wrote:
> 
> That paragraph works for me in general, with one comment: Maybe I missed something in the conversation, but is there a reason to describe (2) as no legal reasons? Could you drop the word "legal"?
> 
I see. “legal” may be overly restrictive and not necessarily correct.
I am happy to drop the word “legal” (in its two occurrences). Can you confirm this updated wording works for you:

"
When HTTP redirection is used between the uCDN and the dCDN, making
detailed CDNI logging information known to the uCDN does not
represent a particular privacy concern because the uCDN is already
exposed at request redirection time to most of the information that
shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP
headers). When DNS redirection is used between the uCDN and the
dCDN, there are cases where there is no privacy concern in making
detailed CDNI logging information known to the uCDN; this may be the
case, for example, where (1) it is considered that because the uCDN
has the authority (with respect to the CSP) and control on how the
requests are delivered (including whether it is served by the uCDN
itself or by a dCDN), the uCDN is entitled to access all detailed
information related to the corresponding deliveries, and (2) there is
no reason to restrict access by the uCDN to all these detailed
information. Conversely, still when DNS redirection is used between
the uCDN and the dCDN, there are cases where there may be some
privacy concern in making detailed CDNI logging information known to
the uCDN; this may be the case, for example, because the uCDN is in a
different jurisdiction to the dCDN resulting is some reasons to
restrict access by the uCDN to all the detailed information related
to the deliveries. In this latter case, the privacy concern can be
taken into account when the uCDN and dCDN agree about which fields
are to be conveyed inside the CDNI Logging Files and which privacy
protection mechanism is to be used as discussed in the definition of
the c-groupid field specified in Section 3.4.1.
“

Thanks

François

> Thanks!
> 
> Ben.
> 
> On 8 Jun 2016, at 4:07, Francois Le Faucheur wrote:
> 
> Folks,
> 
> Here is the rewritten paragraph about the potential privacy concerns related to communicating details information to the uCDN:
> 
> "
> When HTTP redirection is used between the uCDN and the dCDN, making
> detailed CDNI logging information known to the uCDN does not
> represent a particular privacy concern because the uCDN is already
> exposed at request redirection time to most of the information that
> shows up as CDNI logging information (e.g., enduser IP@, URL, HTTP
> headers). When DNS redirection is used between the uCDN and the
> dCDN, there are cases where there is no privacy concern in making
> detailed CDNI logging information known to the uCDN; this may be the
> case, for example, where (1) it is considered that because the uCDN
> has the authority (with respect to the CSP) and control on how the
> requests are delivered (including whether it is served by the uCDN
> itself or by a dCDN), the uCDN is entitled to access all detailed
> information related to the corresponding deliveries, and (2) there is
> no legal reasons to restrict access by the uCDN to all these detailed
> information. Conversely, still when DNS redirection is used between
> the uCDN and the dCDN, there are cases where there may be some
> privacy concern in making detailed CDNI logging information known to
> the uCDN; this may be the case, for example, because the uCDN is in a
> different jurisdiction to the dCDN resulting is some legal reasons to
> restrict access by the uCDN to all the detailed information related
> to the deliveries. In this latter case, the privacy concern can be
> taken into account when the uCDN and dCDN agree about which fields
> are to be conveyed inside the CDNI Logging Files and which privacy
> protection mechanism is to be used as discussed in the definition of
> the c-groupid field specified in Section 3.4.1.
> “
> 
> Cheers
> 
> Francois
> 
> On 1 Jun 2016, at 18:47, Francois Le Faucheur flefauch@gmail.com <mailto:flefauch@gmail.com> wrote:
> 
> Folks,
> 
> My conclusion from that thread is:
> * the current argument for why there is no privacy concern in communicating the CDNI Logging File to the uCDN holds for HTTP
> * for DNS, the current argument does not hold as currently written
> * for DNS, my proposal is to:
> - capture Ben NJ’s argument (but with a caveat): because the uCDN is the “authoritative” CDN (i.e. the CDN that has control about how the request is delivered and by itself of by another CDN) and has the responsibility of each and every delivery, it may not be a privacy concern to communicate detailed logging information to the uCDN.
> - in scenarios where there are some privacy concerns (e.g. because of different regulations applying to uCDN and dCDN), then this can be taken into account when uCDN and dCDN agree on which fields to convey inside the CDNI Logging Files and which privacy protection mechanisms are to be used (such as the c-groupid, and which mapping is used for the c-groupid).
> 
> Let me know if that is not acceptable, and can be improved.
> 
> Cheers
> 
> Francois
> 
> On 19 May 2016, at 17:42, Ben Niven-Jenkins ben@niven-jenkins.co.uk <mailto:ben@niven-jenkins.co.uk> wrote:
> 
> On 19 May 2016, at 02:41, Stephen Farrell stephen.farrell@cs.tcd.ie <mailto:stephen.farrell@cs.tcd.ie> wrote:
> 
> Cutting to (I think) the substantive bit...
> 
> On 19/05/16 02:11, Ben Niven-Jenkins wrote:
> 
> My intention was to express my opinion that because the uCDN could
> have chosen to perform the content delivery itself the dCDN is not
> exposing any more information to the uCDN than the uCDN could have
> chosen to gather itself if it so desired and therefore IMO there is
> no need to provide different guidance for DNS redirection than for
> HTTP redirection.
> 
> Yes, I've seen arguments of that form offered a number of times.
> I don't find it convincing myself, but recognise that other folks
> do. And in every case so far, neither side has convinced the other,
> and sometimes not even understood one another. But let's see if
> we (me really:-) get better with practice...
> 
> In this case I'd argue that the "could have chosen" isn't really
> true - presumably the uCDN deals with the dCDN because it's hard(er)
> for the uCDN to do the work directly, so it's not really true that
> the uCDN could have chosen to access the information, at least not
> at the same cost.
> 
> True, but there are lots of possibilities for why the uCDN would;t do it itself or why it might those to do the content delivery itself if it was so inclined, e.g. maybe if the uCDN is really interested in invading user’s privacy, what it gains from that outweighs the additional cost of performing the delivery itself. Who knows, I don’t think we can try and account for all that variation.
> 
> And there may be aspects of meta-data that are just different because
> the access was via the dCDN, e.g. perhaps some other client IP address
> gets used if somethings multihomed, or some ISP infrastructure differs,
> e.g. HTTP Forwarded might be present and visible to the dCDN but with
> no similar thing for DNS (or vice versa). I'd not be surprised if even
> more subtle differences existed over populations of transactions and
> users and CDNs.
> 
> I’m sure there are all sort of things like you suggest above. What is not at all clear to me is what specifically the logging draft is meant to do about it.
> 
> Ultimately it’s a tradeoff I think. I’m not sure we’ll ever agree.
> 
> I have nothing more to say that won’t end up just rehashing discussions we’ve already had so I don’t intend on participating in this thread any longer.
> 
> Ben
>