Re: [CDNi] I-D Action: draft-ietf-cdni-logging-20.txt

[Kevin Ma J <[e-mail]>]

Hi Francois,

  Comments and nits on the updated text below.

thanx.

--  Kevin J. Ma

general:

  - Theres an inconsistency in use of "e.g. " vs "e.g., ".  Should do a find-and-replace to use the latter?

  - Theres an inconsistency in use of ",..." vs ", etc.".  Should do a find-and-replace to use one or the other?

  - Theres an inconsistency in use of "a uCDN" vs "an uCDN".  Should do a find-and-replace to use one or the other?

section 2.2.5.1:

  - "This is allowed
     , in the definition of the c-groupid under Section 3.4.1), with very" ->
    "This is allowed in the definition of the c-groupid (under Section 3.4.1), with very"

  - "in the request in request fields" -> "in request fields"

  - "care SHOULD then be" -> "care SHOULD be"

  - "it allows a reliable identification of the client while IP address does not allow accurate identification of clients in many situations (e.g. behind NAT," ->
    "it allows a reliable identification of the client while IP address does not in many situations (e.g. when behind NAT,"

section 3.4.1:

  - "out of band" -> "out-of-band"

  - extra "*"?

  - "the element identifying the client is algorithmically generated" -> "the element identifying the client SHOULD be algorithmically generated"

  - "one example way to achieve this is to hash the address with a shared secret that is pre-synchronised and rotated at a predefined time interval"
    "The encryption algorithm must also be defined,"

    I found this to be a bit confusing.  I think of a hash as being a one-way function, but encryption as being reversible.  I believe we agreed that either a hash or encryption would work, but that encryption provided the ability to get back the IP address if necessary.  We might want to make that more clear.  Do we only want to suggest encryption?

    I found the subsequent text that lists hashing and encryption algorithms compounded my confusion since the hashing algorithms are only intended to be used for generating key material, as opposed to being used to generate the id.

    "they agree on the salt and input key material, as described in [RFC5869], Section 2.2, the hash mechanism to use (SHA-2 or SHA-3 SHOULD be used),"
    "The encryption algorithm must also be defined, and SHOULD be 128-bit AES-GCM or better."

    I think it would be helpful to separate key generation from generating the id.  The following feels a little clearer and more concise to me:

      "the element identifying the client is algorithmically
       generated (from the client IPv4 or IPv6 address in the
       request received by the Surrogate and/or other network-level
       identifying information) in a way that SHOULD NOT be
       linkable back to the global addressing context and that
       SHOULD vary over time (to offer protection against long term
       attacks); one way to achieve this is to either hash or encrypt the
       address with a shared secret that is pre-synchronised and
       rotated at a predefined time interval.  It is RECOMMENDED
       that the mapping varies at least once every 24 hours.  If
       the client IPv4 or IPv6 address or other network-level
       identifying information needs to be recoverable, encryption
       should be used rather than a one-way hashing algorithm.
       The mapping from IP address to the element identifying the
       client SHOULD be done using a symmetric key that is known only
       to both the uCDN and dCDN.  (One method of selecting a key is
       to use an analog of HKDF [RFC5869], as will be used in TLS 1.3
       [I-D.ietf-tls-rfc5246-bis]). 
       When the two CDNs set up a relationship, they agree
       out-of-band on a mapping between IPv4 and IPv6 addresses and
       aggregates and on the algorithmic mapping from IPv4/IPv6
       addresses and the element identifying the client.
       They agree on the salt and input key material, any
       algorithms used in key generation (e.g., SHA-256), and the key
       lifetime which SHOULD NOT exceed 25 hours (shorter lifetimes
       MAY be used).  At the expiration of the agreed-upon lifetime,
       a new key is used."

section 7.3:
  - "it generates it" -> "it generated the information"

  - "protected by usual IETF privacy-protection mechanism (TLS)" ->
    "protected by usual IETF privacy-protection mechanisms (e.g., TLS)"

  - "that very large volumes" -> "that large volumes"

  - ", which then represent a high-value target," ->
    ".  These files represent high-value targets"

  - "and thus is at risk" -> "and at risk"

  - "very large volumes of" -> "large volumes of"

  - "these concerned are" -> "these concerns are"

  - "section Section 3.4.1." -> "Section 3.4.1."

  - "any other party than" -> "any party other than"


> -----Original Message-----
> From: CDNi [mailto:[e-mail]] On Behalf Of Francois Le
> Faucheur (flefauch)
> Sent: Friday, October 16, 2015 12:22 PM
> To: [e-mail]
> Subject: Re: [CDNi] I-D Action: draft-ietf-cdni-logging-20.txt
> 
> Folks,
> 
> (as a co-author)
> 
> This new version addresses :
> 	* ABNF corrections
> 	* logging privacy :
> 		o privacy concerns and non-concerns in section 7.3
> 		o privacy protection mechanism in the form of the  “c-groupid”
> field in section 3.4.1 (replacing the c-ip, c-ip-anonymizing, c-port, c-
> port-anonymizing).
> 
> Thanks much to the Logging Privacy Design team, in particular to Brian
> Trammel and Rich Salz.
> 
> Please review the diffs from -19 and let us know if you have any concerns.
> 
> Obviously, the material related to privacy will also be presented in
> Yokohama.
> 
> Cheers
> 
> Francois
> 
> > On 16 Oct 2015, at 17:20, [e-mail] wrote:
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Content Delivery Networks
> Interconnection Working Group of the IETF.
> >
> >        Title           : CDNI Logging Interface
> >        Authors         : Francois Le Faucheur
> >                          Gilles Bertrand
> >                          Iuniana Oprescu
> >                          Roy Peterkofsky
> > 	Filename        : draft-ietf-cdni-logging-20.txt
> > 	Pages           : 57
> > 	Date            : 2015-10-16
> >
> > Abstract:
> >   This memo specifies the Logging interface between a downstream CDN
> >   (dCDN) and an upstream CDN (uCDN) that are interconnected as per the
> >   CDN Interconnection (CDNI) framework.  First, it describes a
> >   reference model for CDNI logging.  Then, it specifies the CDNI
> >   Logging File format and the actual protocol for exchange of CDNI
> >   Logging Files.
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-cdni-logging/
> >
> > There's also a htmlized version available at:
> > https://tools.ietf.org/html/draft-ietf-cdni-logging-20
> >
> > A diff from the previous version is available at:
> > https://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-logging-20
> >
> >
> > Please note that it may take a couple of minutes from the time of
> submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > CDNi mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/cdni
> 
> _______________________________________________
> CDNi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cdni