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

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 1 Jun 2016 17:50:20 +0200

Ben and all,

Thanks for the review and comments. Please see proposed resolution below:

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> While the security and privacy bits are much improved from earlier
> versions, I think I have found some holes. I assume these are not
> intentional, and it's entirely possible I have misread some things. But I
> would like to make sure they are considered prior to progressing.
> 
> - 3.4.1, c-groupid: The privacy-related guidance about c-groupids
> indentifying individual clients (in the several bullet list entries with
> "-" bullets) seems contingent on the MAY in the parent (with the "+"
> bullet.) The parent says that you MAY structure the field so that parts
> identify the aggregate and one part aggregates the individual, with the
> sub-bullets following an "In this case..." clause. I assume the guidance
> is intended to apply even when an implementation doesn't structure
> c-groupid that way (or at all.) 

Yes. I tweaked the text to make that clearer i.e.

s/In that case/In the case where the aggregate is chosen so that it contains a single client/

> 
> - 7.1: This section seems to effectively say that various protections are
> required when they are required. But it doesn't give advice on when they
> may be required. (For example, when c-groupid can be mapped to individual
> client addresses.)

I am tired of discussing the word smithing around use of TLS. So I aligned the text to cdni-control-triggers which effectively makes protection required all the time (i.e. MUST use TLS, unless some other protection is used). This has passed IESG approval in the context of cdni-control-triggers, so it should be equally acceptable to all for cdni-logging, and it will ensure consistency across CDNI I-Ds.
So it now reads:

“
TLS MUST be used by the server-side and the client-side of the CDNI
   Logging feed, as well as the server-side and the client-side of the
   CDNI Logging File pull mechanism, including authentication of the
   remote end, unless alternate methods are used for ensuring the
   security of the information exchanged over the LI interface (such as
   setting up an IPsec tunnel between the two CDNs or using a physically
   secured internal network between two CDNs that are owned by the same
   corporate entity).
"

> 
> - 7.3: "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 - at least when
>   HTTP redirection is used between uCDN and dCDN)."
> 
> I agree this is mostly true for HTTP redirection. But as you mention, the
> assertion seems to fall down for DNS redirection, where the uCDN may have
> considerably less information. I think some different guidance for that
> case may be needed.

I will come back to this one once I have digested the associated thread.

> 
> -- "Transporting
>   detailed CDNI logging information over the HTTP based CDNI Logging
>   Interface does not represent a particular privacy concern because it
>   is protected by usual IETF privacy-protection mechanism (e.g.,TLS)."
> 
> I don't find normative text that says privacy-sensitive information MUST
> be protected. Just that information that needs to be protected MUST be
> protected. The reader is left to infer that privacy-sensitive information
> is covered by that. (See previous comment about 7.1). Without something
> explicit there, I think it highly likely that some people will
> rationalize that their deployments don't need protection for one reason
> or another.

With the new text, the information MUST always be protected. So the question goes away.

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> - 3.3, 2nd to last paragraph: What does it mean to reject a logging file?
> Does it mean to simply ignore it, or does it imply some notice back the
> source of the file that there's a problem? (I tend to think of "reject"
> as implying the latter in a protocol, in contrast to words like "drop" or
> "ignore”.)

The CDNI Logging File Pull protocol is a simple HTTP transfer of the CDNI Logging File from dCDN to uCDN, so there is not backwards channel that can be used for the uCDN to notify the dCDN that a CDNI Logging File (that was successfully transmitted via HTTP) is actually not a valid CDNI Logging File. 
So, the text has been updated to say “ignore” instead of reject.

I also replaced “reject” by “Ignore” in 3.4:
"the implementation MUST ignore those HTTP Request Logging Records"

> 
> - 3.4.1, 3rd "-" bullet: "The algorithmic mapping and variation over time
> MAY allow
>               the uCDN ... to reconstruct the actual client IPv4 or IPv6
> address"
> 
> Is that intended to be a 2119 MAY or a statement of fact? If the former,
> it seems to directly contradict the NOT RECOMMENDED in the next "-"
> bullet..

It is a statement of fact (and an improper use of the 2119 “MAY”).
Text has been updated so it reads:
"The algorithmic mapping and variation over time can, in some cases, allow the uCDN ... to reconstruct the actual client IPv4 or IPv6 address”.

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 1 Jun 2016 18:47:01 +0200

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

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 8 Jun 2016 11:07:13 +0200

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 <[email-masked]> wrote:
> 
> Folks,
>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Jun 2016 09:33:50 -0500

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"?

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:
>
> "
>> 	* the current argument for why there is no privacy concern in 
>> communicating the CDNI Logging File to the uCDN holds for HTTP
>> 		- 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).
>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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
>>>
>>

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 8 Jun 2016 17:38:07 +0200

Hi Ben,

> On 8 Jun 2016, at 16:33, Ben Campbell <[email-masked]> 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:

"
no reason to restrict access by the uCDN to all these detailed
different jurisdiction to the dCDN resulting is some reasons to

Thanks

François

> On 1 Jun 2016, at 18:47, Francois Le Faucheur [email-masked] <mailto:[email-masked]> wrote:
> 
> Folks,
> 
> - 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.
> On 19 May 2016, at 17:42, Ben Niven-Jenkins [email-masked] <mailto:[email-masked]> wrote:
> 
> On 19 May 2016, at 02:41, Stephen Farrell [email-masked] <mailto:[email-masked]> wrote:
>