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

["Francois Le Faucheur (flefauch)" <[e-mail]>]

Hi Kevin,

Thanks for these comments. 

I have included all the editorial corrections in the working copy.

I will discuss separately the non-editorial comment regarding choice of mapping algorithm.

Thanks

Francois


> On 17 Oct 2015, at 05:54, Kevin Ma J <[e-mail]> wrote:
> 
> 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