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

From: "Ben Campbell" <[email-masked]>
Date: Wed, 18 May 2016 15:32:57 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-cdni-logging-25: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/

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

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

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

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

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

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 19 May 2016 00:38:04 +0100

Hi Ben,

I’ll let the authors respond to most of your comments but I wanted to respond to one of them, see below.

> On 18 May 2016, at 23:32, Ben Campbell <[email-masked]> wrote:

True, but…making detailed CDNI logging information known to the uCDN does not expose any more information to the uCDN than if the uCDN had chosen to perform the content delivery itself.

Typically when entity A contracts out work to entity B, entity A is entitled to see all records produced by entity B on entity A’s behalf.

Ben

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 May 2016 00:46:16 +0100

>> 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.
> 
> True, but…making detailed CDNI logging information known to the uCDN
> does not expose any more information to the uCDN than if the uCDN had
> chosen to perform the content delivery itself.
> 
> Typically when entity A contracts out work to entity B, entity A is
> entitled to see all records produced by entity B on entity A’s
> behalf.

I don't accept that that applies to all of the information that
could be at issue here. For example if A is in the US and B is in
the EU then things are not that simple.

S.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 19 May 2016 01:24:58 +0100

> On 19 May 2016, at 00:46, Stephen Farrell <[email-masked]> wrote:

You are correct that there are laws that may prevent the export of personal data from one country to another. AFAIK no IETF protocol that exchanges personal data or privacy impacting data has additional technical mechanisms to account for such laws (and I can not recall reading text in a technical specification RFC that discussed the impacts of such laws on the protocol being specified) so I don’t see how the presence of such laws is relevant to the technical specification of the CDNI logging interface.

Ben

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 May 2016 01:33:25 +0100

On 19/05/16 01:24, Ben Niven-Jenkins wrote:
> 
>> On 19 May 2016, at 00:46, Stephen Farrell
>> <[email-masked]> wrote: On 19/05/16 00:38, Ben
>> Niven-Jenkins wrote:
>>> Hi Ben,
>>> 
>>> I’ll let the authors respond to most of your comments but I
>>> wanted to respond to one of them, see below.
>>> 
>>>> 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)."
>>>> 
>>>> where the uCDN may have considerably less information. I think
>>>> some different guidance for that case may be needed.
>>> 
>>> True, but…making detailed CDNI logging information known to the
>>> uCDN does not expose any more information to the uCDN than if the
>>> uCDN had chosen to perform the content delivery itself.
>>> 
>>> Typically when entity A contracts out work to entity B, entity A
>>> is entitled to see all records produced by entity B on entity
>>> A’s behalf.
>> 
> You are correct that there are laws that may prevent the export of
> personal data from one country to another. AFAIK no IETF protocol
> that exchanges personal data or privacy impacting data has additional
> technical mechanisms to account for such laws (and I can not recall
> reading text in a technical specification RFC that discussed the
> impacts of such laws on the protocol being specified) so I don’t see
> how the presence of such laws is relevant to the technical
> specification of the CDNI logging interface.

The relevance is that it shows that your argument wasn't correct
as stated. There are other arguments, that are perhaps not yet well
accepted by those considering CDNI, for example that receiving all
of that logging data unaggregated is more toxic than valuable,
but I think we had that discussion before and concluded that the
best and correct thing for us to do now with CDNI is to ensure
that some privacy friendly mode of operation exists and is usable.
Ben's discuss seems to me to be checking whether we've done that
as well as we thought, and that's a good thing.

If instead you want to re-litigate that basic argument then we
can do that but I expect that'd be unproductive for us all and
would land us back where we are now anyway.

S.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 18 May 2016 19:51:38 -0500

On 18 May 2016, at 18:38, Ben Niven-Jenkins wrote:

>> privacy

That may be a reasonable argument (I will let the thread from Stephen's 
comment play out), but that's not the argument the draft makes. If there 
are arguments that apply to DNS redirection (such as the one you 
mention), I think they should be included.

Thanks,

Ben C.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 19 May 2016 02:11:58 +0100

> On 19 May 2016, at 01:33, Stephen Farrell <[email-masked]> wrote:
> as stated.

I’m not sure which part wasn’t correct unless we’re debating whether my use of “typically” is correct.

I stated a technical fact that

>>>> making detailed CDNI logging information known to the

I then stated a generalised version of that fact to try to illustrate that this situation is not unique to CDNI. I don’t have data to say how often the generalised version I stated occurs vs does not occur, so maybe it isn’t “typical” maybe its only “sometimes”. I didn’t consider that relevant and figured “typically” conveys the meaning quite often which I believe to be the case despite not having data to prove it.

Anyway, regardless of any of that, the technical fact regarding CDNI stands IMO and the generalised fact is not core to the point I was making (see below). 

> There are other arguments, that are perhaps not yet well

I agree.

> would land us back where we are now anyway.

I’m not trying to re-litigate anything. 

Maybe I should have been more expansive in my initial response. Ben raised the question of whether due to the assertion seeming to fall down for DNS redirection, the document should offer different guidance for DNS redirection to HTTP redirection. 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.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 19 May 2016 02:13:03 +0100

Ben C,

> On 19 May 2016, at 01:51, Ben Campbell <[email-masked]> wrote:
> 
> That may be a reasonable argument (I will let the thread from Stephen's comment play out), but that's not the argument the draft makes.

Agreed.

> If there are arguments that apply to DNS redirection (such as the one you mention), I think they should be included.

Agreed.

Ben

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 May 2016 02:41:23 +0100

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.

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.

S.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 19 May 2016 16:42:30 +0100

> On 19 May 2016, at 02:41, Stephen Farrell <[email-masked]> wrote:
> 

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.

> more subtle differences existed over populations of transactions and

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: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 20 May 2016 15:29:30 -0500

Dear Authors,

I've seen a robust exchange between Ben Niven-Jenkins, Ben Campbell, and
Stephen Farrell, but haven't seen a response from the authors. Could you
let me know if you need any help absorbing Ben's ballot position?

Thanks!

Spencer

On Thu, May 19, 2016 at 10:42 AM, Ben Niven-Jenkins <[email-masked]
> wrote:

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