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

["Ben Campbell" <[e-mail]>]

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