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 09:07 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 904DF12D86E; Wed, 8 Jun 2016 02:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_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 IYUU-H3UTvIg; Wed, 8 Jun 2016 02:07:18 -0700 (PDT)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 35FCA12D534; Wed, 8 Jun 2016 02:07:18 -0700 (PDT)
Received: by mail-wm0-x22c.google.com with SMTP id k184so15287759wme.1; Wed, 08 Jun 2016 02:07:18 -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 :content-transfer-encoding:message-id:references:to; bh=I04K1S6RcZR+ZiDM+FmZ7e1QCHylh1Zdwd2SriMieL4=; b=v5pIkZX6iLUmTv/d6m2zooH/0TWcmyeSPkLjwcskFCQC9Vx11QGEw8ACKBPqaKdzUc adFRf4yCbdsE07dHWGw3AX4DZSK1xH4CxyT5iJ91n0SzxN/GZjCuF213+DdmcWnGcGzz /ZiT2zdg1oshnU+4RnPH+rYfMHfKJfVkbjinZX020wfhAX+ArzYDxs1z4Rl8tBnmL6T5 X+/mjCE+2jHdymT1cMF9sL63XYqkd8q7i2oGm0OLSwgyNQ9tZVCuGiltUrVkWBRtaJ0A sF6LwDMKbxmBl0Ek3DDv6F8SRBK2byzNt0328bWBcw6UmBjUh6HXHE9hxEDpoJ/cD3L2 5Qww==
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 :content-transfer-encoding:message-id:references:to; bh=I04K1S6RcZR+ZiDM+FmZ7e1QCHylh1Zdwd2SriMieL4=; b=E1cBFCQLop+NE+01Nx3tpNLGUzsGIY0e7PDGodRJ+Zbi/477PEIG8XfVLbLCm7kG48 rLhZMmsHYdg6FmkWD96nCPorC4IjKvstoNr9CgKbZJG1jsnwHE8yD/PqWlcY1D89o/Av ecmPWYKkwCV8g0avlZRa4yJzxBCL2fO+LbDW56qdGwfOSxyWc/RBm+kah9SF691wZhj9 dU7WwHOEDWKmDV3xMhU9yrDi7kTpuaQgbYpHuB6cVqjsoSXJl9LLRDldL+vDyHXgW14N Z3ny6QYRLtTJzZMbfOOtVArpllA7zLGxPsEd1R3TJtiD/W7+tfg6X3FnoPCqbeOWpgGp zzwg==
X-Gm-Message-State: ALyK8tLNDZPC70F1MiV2idDFFa/Q5gacojs9b1gbxEulvkgRvk/bSi91+y71sUkmonnOoA==
X-Received: by 10.28.12.199 with SMTP id 190mr3607249wmm.15.1465376836574; Wed, 08 Jun 2016 02:07:16 -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 w16sm939436wmw.6.2016.06.08.02.07.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 08 Jun 2016 02:07:15 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Francois Le Faucheur <flefauch@gmail.com>
In-Reply-To: <59AB96A8-B811-443A-8256-54D45141F96E@gmail.com>
Date: Wed, 08 Jun 2016 11:07:13 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <CCFC316B-04CD-4EAB-87EC-618FE6166931@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>
To: Niven-Jenkins Ben <ben@niven-jenkins.co.uk>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, Ben Campbell <ben@nostrum.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cdni/sY9nZP9E8tyqblRzN5xoZAcYFCY>
Cc: draft-ietf-cdni-logging@ietf.org, The IESG <iesg@ietf.org>, "<cdni@ietf.org>" <cdni@ietf.org>, cdni-chairs@ietf.org
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 09:07:21 -0000

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> 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> wrote:
>> 
>> 
>>> On 19 May 2016, at 02:41, Stephen Farrell <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
>> 
>