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

[Francois Le Faucheur <[e-mail]>]

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