draft-ietf-cdni-logging-20.txt   draft-ietf-cdni-logging-21.txt 
Internet Engineering Task Force F. Le Faucheur, Ed. Internet Engineering Task Force F. Le Faucheur, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track G. Bertrand, Ed. Intended status: Standards Track G. Bertrand, Ed.
Expires: April 18, 2016 I. Oprescu, Ed. Expires: May 5, 2016 I. Oprescu, Ed.
Orange Orange
R. Peterkofsky R. Peterkofsky
Skytide, Inc. Skytide, Inc.
October 16, 2015 November 2, 2015
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-20 draft-ietf-cdni-logging-21
Abstract Abstract
This memo specifies the Logging interface between a downstream CDN This memo specifies the Logging interface between a downstream CDN
(dCDN) and an upstream CDN (uCDN) that are interconnected as per the (dCDN) and an upstream CDN (uCDN) that are interconnected as per the
CDN Interconnection (CDNI) framework. First, it describes a CDN Interconnection (CDNI) framework. First, it describes a
reference model for CDNI logging. Then, it specifies the CDNI reference model for CDNI logging. Then, it specifies the CDNI
Logging File format and the actual protocol for exchange of CDNI Logging File format and the actual protocol for exchange of CDNI
Logging Files. Logging Files.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 18, 2016. This Internet-Draft will expire on May 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 12, line 44 skipping to change at page 12, line 44
given period of time), which is particularly useful for CDN and given period of time), which is particularly useful for CDN and
network planning operations. network planning operations.
Some of these maintenance and debugging applications only require Some of these maintenance and debugging applications only require
aggregate logging information highly compatible with use of aggregate logging information highly compatible with use of
anonymization of IP addresses (as supported by the present document anonymization of IP addresses (as supported by the present document
and specified in the definition of the c-groupid field under and specified in the definition of the c-groupid field under
Section 3.4.1). However, in some situations, it may be useful, where Section 3.4.1). However, in some situations, it may be useful, where
compatible with privacy protection, to access some CDNI Logging compatible with privacy protection, to access some CDNI Logging
Records containing full non-anonymized IP addresses. This is allowed Records containing full non-anonymized IP addresses. This is allowed
, in the definition of the c-groupid under Section 3.4.1), with very in the definition of the c-groupid (under Section 3.4.1), with very
significant privacy protection limitations that are discussed in the significant privacy protection limitations that are discussed in the
definition of the c-groupid field. For example, this may be useful definition of the c-groupid field. For example, this may be useful
for detailed fault tracking of a particular end user content delivery for detailed fault tracking of a particular end user content delivery
issue. Where there is a hard requirement by uCDN or CSP to associate issue. Where there is a hard requirement by uCDN or CSP to associate
a given enduser to individual CDNI Logging Records (e.g. to allow a given enduser to individual CDNI Logging Records (e.g., to allow
a-posteriori analysis of individual delivery for example in a-posteriori analysis of individual delivery for example in
situations of performance-based penalties), instead of using situations of performance-based penalties), instead of using
aggregates containing a single client as discussed in the c-groupid aggregates containing a single client as discussed in the c-groupid
field definition, an alternate approach is to ensure that a client field definition, an alternate approach is to ensure that a client
identifier is embedded in the request in request fields that can be identifier is embedded in the request fields that can be logged in a
logged in a CDNI Logging Record (for example by including the client CDNI Logging Record (for example by including the client identifier
identifier in the URI query string or in a HTTP Header). That latter in the URI query string or in a HTTP Header). That latter approach
approach offers two strong benefits: first, the aggregate inside the offers two strong benefits: first, the aggregate inside the c-groupid
c-groupid can contain more than one client, thereby ensuring stronger can contain more than one client, thereby ensuring stronger privacy
privacy protection; second, it allows a reliable identification of protection; second, it allows a reliable identification of the client
the client while IP address does not allow accurate identification of while IP address does not in many situations (e.g., behind NAT, where
clients in many situations (e.g. behind NAT, where dynamic IP dynamic IP addresses are used and reused,...). However, care SHOULD
addresses are used and reused,...). However, care SHOULD then be be taken that the client identifiers exposed in other fields of the
taken that the client identifier exposed in other fields of the CDNI CDNI Records cannot themselves be linked back to actual users.
Records cannot themselves be linked back to actual users.
2.2.5.2. Accounting 2.2.5.2. Accounting
Logging information is essential for accounting, to permit inter-CDN Logging information is essential for accounting, to permit inter-CDN
billing and CSP billing by uCDNs. For instance, Logging information billing and CSP billing by uCDNs. For instance, Logging information
provided by dCDNs enables the uCDN to compute the total amount of provided by dCDNs enables the uCDN to compute the total amount of
traffic delivered by every dCDN for a particular Content Provider, as traffic delivered by every dCDN for a particular Content Provider, as
well as, the associated bandwidth usage (e.g., peak, 95th well as, the associated bandwidth usage (e.g., peak, 95th
percentile), and the maximum number of simultaneous sessions over a percentile), and the maximum number of simultaneous sessions over a
given period of time. given period of time.
skipping to change at page 24, line 12 skipping to change at page 24, line 12
receiving a non-corrupted CDNI Logging File adds an receiving a non-corrupted CDNI Logging File adds an
established-origin directive, it MUST then recompute and update established-origin directive, it MUST then recompute and update
the SHA256-hash directive so it also protects the added the SHA256-hash directive so it also protects the added
established-origin directive. established-origin directive.
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
directive. There SHOULD be exactly one instance of this directive. There SHOULD be exactly one instance of this
directive. One situation where that directive could be omitted directive. One situation where that directive could be omitted
is where integrity protection is already provided via another is where integrity protection is already provided via another
mechanism (for example if an integrity hash is associated to mechanism (for example if an integrity hash is associated to
the CDNI Logging File out of band through the CDNI Logging Feed the CDNI Logging File out-of-band through the CDNI Logging Feed
( Section 4.1) leveraging ATOM extensions such as those ( Section 4.1) leveraging ATOM extensions such as those
proposed in [I-D.snell-atompub-link-extensions]. When present, proposed in [I-D.snell-atompub-link-extensions]. When present,
the SHA256-hash field MUST be the last line of the CDNI Logging the SHA256-hash field MUST be the last line of the CDNI Logging
File. File.
* example: "SHA256-hash: HTAB 64HEXDIG". * example: "SHA256-hash: HTAB 64HEXDIG".
An uCDN-side implementation of the CDNI Logging interface MUST reject An uCDN-side implementation of the CDNI Logging interface MUST reject
a CDNI Logging File that does not comply with the occurrences a CDNI Logging File that does not comply with the occurrences
specified above for each and every directive. For example, an uCDN- specified above for each and every directive. For example, an uCDN-
skipping to change at page 25, line 5 skipping to change at page 25, line 5
(HTAB)" character. (HTAB)" character.
To facilitate readability, a prefix scheme is used for CDNI Logging To facilitate readability, a prefix scheme is used for CDNI Logging
field names in a similar way to the one used in W3C Extended Log File field names in a similar way to the one used in W3C Extended Log File
Format [ELF]. The semantics of the prefix in the present document Format [ELF]. The semantics of the prefix in the present document
is: is:
o "c-" refers to the User Agent that issues the request (corresponds o "c-" refers to the User Agent that issues the request (corresponds
to the "client" of W3C Extended Log Format) to the "client" of W3C Extended Log Format)
o "d-" refers to the dCDN (relative to a given CDN acting as a uCDN) o "d-" refers to the dCDN (relative to a given CDN acting as an
uCDN)
o "s-" refers to the dCDN Surrogate that serves the request o "s-" refers to the dCDN Surrogate that serves the request
(corresponds to the "server" of W3C Extended Log Format) (corresponds to the "server" of W3C Extended Log Format)
o "u-" refers to the uCDN (relative to a given CDN acting as a dCDN) o "u-" refers to the uCDN (relative to a given CDN acting as a dCDN)
o "cs-" refers to communication from the User Agent towards the dCDN o "cs-" refers to communication from the User Agent towards the dCDN
Surrogate Surrogate
o "sc-" refers to communication from the dCDN Surrogate towards the o "sc-" refers to communication from the dCDN Surrogate towards the
skipping to change at page 25, line 46 skipping to change at page 25, line 47
case of HTTPS delivery, there may be value in logging additional case of HTTPS delivery, there may be value in logging additional
information specific to the operation of HTTP over TLS and we note information specific to the operation of HTTP over TLS and we note
that this is outside the scope of the present document and may be that this is outside the scope of the present document and may be
addressed in a future document defining another CDNI Logging Record addressed in a future document defining another CDNI Logging Record
or another version of the HTTP Request Logging Record. or another version of the HTTP Request Logging Record.
The "cdni_http_request_v1" record-type is also expected to be The "cdni_http_request_v1" record-type is also expected to be
applicable to HTTP/2 [RFC7540] since a fundamental design tenet of applicable to HTTP/2 [RFC7540] since a fundamental design tenet of
HTTP/2 is to preserve the HTTP/1.1 semantics. We observe that, in HTTP/2 is to preserve the HTTP/1.1 semantics. We observe that, in
the case of HTTP/2 delivery, there may be value in logging additional the case of HTTP/2 delivery, there may be value in logging additional
information specific to the additional functionality of HTTP/2 (e.g. information specific to the additional functionality of HTTP/2 (e.g.,
information related to connection identification, to stream information related to connection identification, to stream
identification, to stream priority and to flow control). We note identification, to stream priority and to flow control). We note
that such additional information is outside the scope of the present that such additional information is outside the scope of the present
document and may be addressed in a future document defining another document and may be addressed in a future document defining another
CDNI Logging Record or another version of the HTTP Request Logging CDNI Logging Record or another version of the HTTP Request Logging
Record. Record.
The "cdni_http_request_v1" record-type contains the following CDNI The "cdni_http_request_v1" record-type contains the following CDNI
Logging fields, listed by their field name: Logging fields, listed by their field name:
skipping to change at page 26, line 52 skipping to change at page 27, line 6
* format: NHTABSTRING * format: NHTABSTRING
* field value: an opaque identifier for an aggregate set of * field value: an opaque identifier for an aggregate set of
clients, derived from the client IPv4 or IPv6 address in the clients, derived from the client IPv4 or IPv6 address in the
request received by the Surrogate and/or other network-level request received by the Surrogate and/or other network-level
identifying information. The c-groupid serves to group clients identifying information. The c-groupid serves to group clients
into aggregates. Example aggregates include civil geolocation into aggregates. Example aggregates include civil geolocation
information (the country, second-level administrative division, information (the country, second-level administrative division,
or postal code from which the client is presumed to make the or postal code from which the client is presumed to make the
request based on a geolocation database lookup) or network request based on a geolocation database lookup) or network
topological information (e.g. the BGP AS number announcing the topological information (e.g., the BGP AS number announcing the
prefix containing the address). The c-groupid MAY be prefix containing the address). The c-groupid MAY be
structured e.g. US/TN/MEM/38138. Agreement between the dCDN structured e.g., US/TN/MEM/38138. Agreement between the dCDN
and the uCDN on a mapping between IPv4 and IPv6 addresses and and the uCDN on a mapping between IPv4 and IPv6 addresses and
aggregates is presumed to occur out of band. The aggregation aggregates is presumed to occur out-of-band. The aggregation
mapping SHOULD be chosen such that each aggregate contains more mapping SHOULD be chosen such that each aggregate contains more
than one client. When the aggregate is chosen so that it than one client. When the aggregate is chosen so that it
contains a single client (e.g. to allow more detailed contains a single client (e.g., to allow more detailed
analytics, or to allow a-posteriori analysis of individual analytics, or to allow a-posteriori analysis of individual
delivery for example in situations of performance-based delivery for example in situations of performance-based
penalties): penalties):
* + the c-groupid MAY be structured (e.g., US/TN/
+ the c-groupid MAY be structured (e.g. US/TN/
MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2) where some MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2) where some
elements identify aggregates and one element identifies the elements identify aggregates and one element identifies the
client. client.
+ the element identifying the client is algorithmically + 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. The mapping from IP address to the element
identifying the client (effectively an encryption of the
address) SHOULD be done using a symmetric key that is known
only to both the uCDN and dCDN. One method of doing this is
to use an analog of how key derivation is via HKDF
([RFC5869]), as will be used in TLS 1.3
([I-D.ietf-tls-rfc5246-bis]). When the two CDNs set up the
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, as described in [RFC5869], Section 2.2, the hash
mechanism to use (SHA-2 or SHA-3 SHOULD be used), and the
key lifetime which SHOULD NOT exceed 25 hours. They also
agree on an initial "info" parameter, which can be something
such as the business names of the two organizations in UTF-
8, concatenated. The encryption algorithm also needs to be
defined, and SHOULD be 128-bit AES-GCM or better. The PRK
should be chosen by both parties contributing alternate
random bytes until sufficient length exists. After this
initial setup, client-information is encrypted using the key
generated by the "expand" step, Section 2.3 of [RFC5869],
and hex-encoded or base64-encoded. At the agreed-upon
lifetime, a new key is used, indicated by prefixing the key
with a special character such as exclamation point. In this
way, shorter lifetimes can be used as needed.
+ the element identifying the client SHOULD be algorithmically
generated (from the client IPv4 or IPv6 address in the generated (from the client IPv4 or IPv6 address in the
request received by the Surrogate and/or other network-level request received by the Surrogate and/or other network-level
identifying information) in a way that SHOULD NOT be identifying information) in a way that SHOULD NOT be
linkable back to the global addressing context and that linkable back to the global addressing context and that
SHOULD vary over time (to offer protection against long term SHOULD vary over time (to offer protection against long term
attacks); one example way to achieve this is to hash the attacks); one example way to achieve this is to hash.
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. The
mapping from IP address to the element identifying the
client (effectively an encryption of the address) SHOULD be
done using a symmetric key that is known only to both the
uCDN and dCDN. One method of doing this is to use an analog
of how key derivation is via HKDF ([RFC5869]), as will be
used in TLS 1.3 ([I-D.ietf-tls-rfc5246-bis]). When the two
CDNs set up the 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, as described in [RFC5869], Section 2.2,
the hash mechanism to use (SHA-2 or SHA-3 SHOULD be used),
and the key lifetime which SHOULD NOT exceed 25 hours. They
also agree on an initial "info" parameter, which can be
something such as the business names of the two
organizations in UTF-8, concatenated. The encryption
algorithm must also be defined, and SHOULD be 128-bit AES-
GCM or better. The PRK should be chosen by both parties
contributing alternate random bytes until sufficient length
exists. After this initial setup, client-information is
encrypted using the key generated by the "expand" step,
Section 2.3 of [RFC5869], and hex-encoded or base64-encoded.
At the agreed-upon lifetime, a new key is used, indicated by
prefixing the key with a special character such as
exclamation point. In this way, shorter lifetimes can be
used as needed.
+ The algorithmic mapping and variation over time MAY allow + The algorithmic mapping and variation over time MAY allow
the uCDN (with the knowledge of the algorithm and time the uCDN (with the knowledge of the algorithm and time
variation and associated attributes and keys) to reconstruct variation and associated attributes and keys) to reconstruct
the actual enduser IPv4/IPv6 addresses where that is the actual enduser IPv4/IPv6 addresses where that is
required (e.g. to allow a-posteriori analysis of individual required (e.g., to allow a-posteriori analysis of individual
delivery for example in situations of performance-based delivery for example in situations of performance-based
penalties). However, these enduser IPv4/IPv6 addresses penalties). However, these enduser IPv4/IPv6 addresses
SHOULD only be reconstructed on-demand and the CDNI Logging SHOULD only be reconstructed on-demand and the CDNI Logging
File SHOULD only be stored with the anonymised c-groupid File SHOULD only be stored with the anonymised c-groupid
value. value.
+ Using the c-groupid field in this way carries with it grave + Using the c-groupid field in this way carries with it grave
risks to end-user privacy. Since the c-groupid is in this risks to end-user privacy. Since the c-groupid is in this
case equivalent in identification power to a client IP case equivalent in identification power to a client IP
address, its use may be restricted by regulation or law as address, its use may be restricted by regulation or law as
skipping to change at page 35, line 16 skipping to change at page 35, line 16
If a dCDN-side implementation of the CDNI Logging interface supports If a dCDN-side implementation of the CDNI Logging interface supports
these fields, it MUST support the ability to include valid values for these fields, it MUST support the ability to include valid values for
them. them.
An uCDN-side implementation of the CDNI Logging interface MUST be An uCDN-side implementation of the CDNI Logging interface MUST be
able to accept CDNI Logging Files with CDNI Logging Records of able to accept CDNI Logging Files with CDNI Logging Records of
record-type "cdni_http_request_v1" containing any CDNI Logging Field record-type "cdni_http_request_v1" containing any CDNI Logging Field
defined in Section 3.4.1 as long as the CDNI Logging Record and the defined in Section 3.4.1 as long as the CDNI Logging Record and the
CDNI Logging File are compliant with the present document. CDNI Logging File are compliant with the present document.
In case, an uCDN-side implementation of the CDNI Logging interface In case an uCDN-side implementation of the CDNI Logging interface
receives a CDNI Logging File with HTTP Request Logging Records that receives a CDNI Logging File with HTTP Request Logging Records that
do not contain field values for exactly the set of field names do not contain field values for exactly the set of field names
actually listed in the preceding "fields" directive, the actually listed in the preceding "fields" directive, the
implementation MUST reject those HTTP Request Logging Records, and implementation MUST reject those HTTP Request Logging Records, and
MUST accept the other HTTP Request Logging Records. MUST accept the other HTTP Request Logging Records.
To ensure that the logging file is correct, the text MUST be To ensure that the logging file is correct, the text MUST be
sanitized before being logged. Null, bare CR, bare LF and HTAB have sanitized before being logged. Null, bare CR, bare LF and HTAB have
to be removed by escaping them through percent encoding to avoid to be removed by escaping them through percent encoding to avoid
confusion with the logging record separators. confusion with the logging record separators.
skipping to change at page 36, line 42 skipping to change at page 36, line 42
"host1.example.com"<HTAB>1<CRLF> "host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>US/TN/MEM/38138<HTAB> 2013-05-17<HTAB>00:42:53.437<HTAB>52.879<HTAB>US/TN/MEM/38138<HTAB>
GET<HTAB> GET<HTAB>
http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB> http://cdni-ucdn.dcdn-1.example.com/video/picture11.mp4<HTAB>
HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0 HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB> Gecko) Chrome/5.0.375.127 Safari/533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF> "host5.example.com"<HTAB>0<CRLF>
#SHA256-hash:<HTAB>...64-hexadecimal-digit hash value...<CRLF> #SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
Figure 4: CDNI Logging File Example Figure 4: CDNI Logging File Example
If uCDN establishes by some means (e.g. via TLS authentication when If uCDN establishes by some means (e.g., via TLS authentication when
pulling the CDNI Logging File) the identity of the entity from which pulling the CDNI Logging File) the identity of the entity from which
it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an
established-origin directive as illustrated below: established-origin directive as illustrated below:
#established-origin:<HTAB>cdni-logging-entity.dcdn- #established-origin:<HTAB>cdni-logging-entity.dcdn-
1.example.com<CRLF> 1.example.com<CRLF>
As illustrated in Figure 2, uCDN will then ingest the corresponding As illustrated in Figure 2, uCDN will then ingest the corresponding
CDNI Logging Records into its Collection process, alongside the CDNI Logging Records into its Collection process, alongside the
Logging Records generated locally by the uCDN itself. This allows Logging Records generated locally by the uCDN itself. This allows
uCDN to aggregate Logging Records for deliveries performed by itself uCDN to aggregate Logging Records for deliveries performed by itself
skipping to change at page 38, line 26 skipping to change at page 38, line 26
cs(Referer)<HTAB>s-cached<CRLF> cs(Referer)<HTAB>s-cached<CRLF>
2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>US/CA/SFO/94114<HTAB> 2013-05-17<HTAB>00:39:09.119<HTAB>14.07<HTAB>US/CA/SFO/94114<HTAB>
GET<HTAB> GET<HTAB>
http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4<HTAB> http://cdni-dcdn-2.dcdn-3.example.com/video/movie118.mp4<HTAB>
HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0 HTTP/1.1<HTAB>200<HTAB>15799210<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB> Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host1.example.com"<HTAB>1<CRLF> "host1.example.com"<HTAB>1<CRLF>
#SHA256-hash:<HTAB>...64-hexadecimal-digit hash value...<CRLF> #SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2) Figure 5: Cascaded CDNI Logging File Example (dCDN-3 to dCDN-2)
If dCDN-2 establishes by some means (e.g. via TLS authentication when If dCDN-2 establishes by some means (e.g., via TLS authentication
pulling the CDNI Logging File) the identity of the entity from which when pulling the CDNI Logging File) the identity of the entity from
it pulled the CDNI Logging File, dCDN-2 can add to the CDNI Logging which it pulled the CDNI Logging File, dCDN-2 can add to the CDNI
an established-origin directive as illustrated below: Logging an established-origin directive as illustrated below:
#established-origin:<HTAB>cdni-logging-entity.dcdn- #established-origin:<HTAB>cdni-logging-entity.dcdn-
3.example.com<CRLF> 3.example.com<CRLF>
dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3) dCDN-2 (behaving as an upstream CDN from the viewpoint of dCDN-3)
will then ingest the CDNI Logging Record for the considered dCDN-3 will then ingest the CDNI Logging Record for the considered dCDN-3
delivery into its Collection process (as illustrated in Figure 2). delivery into its Collection process (as illustrated in Figure 2).
This Logging Record may be aggregated with Logging Records generated This Logging Record may be aggregated with Logging Records generated
locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say, locally by dCDN-2 for deliveries performed by dCDN-2 itself. Say,
for illustration, that the content delivery performed by dCDN-3 on for illustration, that the content delivery performed by dCDN-3 on
skipping to change at page 39, line 34 skipping to change at page 39, line 34
"host1.example.com"<HTAB>1<CRLF> "host1.example.com"<HTAB>1<CRLF>
2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>FR/IDF/PAR/75001<HTAB> 2013-05-17<HTAB>01:42:53.437<HTAB>52.879<HTAB>FR/IDF/PAR/75001<HTAB>
GET<HTAB> GET<HTAB>
http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB> http://cdni-ucdn.dcdn-2.example.com/video/picture11.mp4<HTAB>
HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0 HTTP/1.0<HTAB>200<HTAB>97234724<HTAB>"Mozilla/5.0
(Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.4 (KHTML, like
Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB> Gecko) Chrome/5.0.375.127 Safari /533.4"<HTAB>
"host5.example.com"<HTAB>0<CRLF> "host5.example.com"<HTAB>0<CRLF>
#SHA256-hash:<HTAB>...64-hexadecimal-digit hash value...<CRLF> #SHA256-hash:<HTAB> 64-hexadecimal-digit hash value <CRLF>
Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN) Figure 6: Cascaded CDNI Logging File Example (dCDN-2 to uCDN)
If uCDN establishes by some means (e.g. via TLS authentication when If uCDN establishes by some means (e.g., via TLS authentication when
pulling the CDNI Logging File) the identity of the entity from which pulling the CDNI Logging File) the identity of the entity from which
it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an it pulled the CDNI Logging File, uCDN can add to the CDNI Logging an
established-origin directive as illustrated below: established-origin directive as illustrated below:
#established-origin:<HTAB>cdni-logging-entity.dcdn- #established-origin:<HTAB>cdni-logging-entity.dcdn-
2.example.com<CRLF> 2.example.com<CRLF>
In the example of Figure 6, we observe that: In the example of Figure 6, we observe that:
o the first Logging Record corresponds to the Logging Record o the first Logging Record corresponds to the Logging Record
skipping to change at page 46, line 15 skipping to change at page 46, line 15
6. IANA Considerations 6. IANA Considerations
When IANA allocates new extensions to CDNI Logging Directive Names When IANA allocates new extensions to CDNI Logging Directive Names
Registry, CDNI Logging File version Registry, CDNI Logging record- Registry, CDNI Logging File version Registry, CDNI Logging record-
type Registry or CDNI Logging fields Registry, IANA MUST take into type Registry or CDNI Logging fields Registry, IANA MUST take into
account that the directive names are case-insensitive as per the account that the directive names are case-insensitive as per the
basic ABNF([RFC5234]). basic ABNF([RFC5234]).
6.1. CDNI Logging Directive Names Registry 6.1. CDNI Logging Directive Names Registry
The IANA is requested to create a new registry, CDNI Logging The IANA is requested to create a new "CDNI Logging Directive Names"
Directive Names. registry under the "Content Delivery Networks Interconnection (CDNI)
Parameters" category.
The initial contents of the CDNI Logging Directives registry comprise The initial contents of the CDNI Logging Directives registry comprise
the names of the directives specified in Section 3.3 of the present the names of the directives specified in Section 3.3 of the present
document, and are as follows: document, and are as follows:
+------------------------------+-----------+ +------------------------------+-----------+
| Directive Name | Reference | | Directive Name | Reference |
+------------------------------+-----------+ +------------------------------+-----------+
| version | RFC xxxx | | version | RFC xxxx |
| UUID | RFC xxxx | | UUID | RFC xxxx |
skipping to change at page 47, line 7 skipping to change at page 47, line 7
defined in the logging file are case-insensitive as per the basic defined in the logging file are case-insensitive as per the basic
ABNF([RFC5234]). ABNF([RFC5234]).
Each specification that defines a new CDNI Logging directive needs to Each specification that defines a new CDNI Logging directive needs to
contain a description for the new directive with the same set of contain a description for the new directive with the same set of
information as provided in Section 3.3 (i.e., format, directive value information as provided in Section 3.3 (i.e., format, directive value
and occurrence). and occurrence).
6.2. CDNI Logging File version Registry 6.2. CDNI Logging File version Registry
The IANA is requested to create a new registry, CDNI Logging File The IANA is requested to create a new "CDNI Logging File version"
version. registry under the "Content Delivery Networks Interconnection (CDNI)
Parameters" category.
The initial contents of the CDNI Logging Logging File version The initial contents of the CDNI Logging Logging File version
registry comprise the value "CDNI/1.0" specified in Section 3.3 of registry comprise the value "CDNI/1.0" specified in Section 3.3 of
the present document, and are as follows: the present document, and are as follows:
+-----------------+-----------+----------------------------------+ +-----------------+-----------+----------------------------------+
| version | Reference | Description | | version | Reference | Description |
+-----------------+-----------+----------------------------------+ +-----------------+-----------+----------------------------------+
| cdni/1.0 | RFC xxxx | CDNI Logging File version 1.0 | | cdni/1.0 | RFC xxxx | CDNI Logging File version 1.0 |
| | | as specified in RFC xxxx | | | | as specified in RFC xxxx |
skipping to change at page 47, line 33 skipping to change at page 47, line 34
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of [Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document] the present document]
Within the registry, version values are to be allocated by IANA Within the registry, version values are to be allocated by IANA
according to the "Specification Required" policy specified in according to the "Specification Required" policy specified in
[RFC5226]. Version values are to be allocated by IANA with a format [RFC5226]. Version values are to be allocated by IANA with a format
of NAMEFORMAT (see Section 3.1). of NAMEFORMAT (see Section 3.1).
6.3. CDNI Logging record-types Registry 6.3. CDNI Logging record-types Registry
The IANA is requested to create a new registry, CDNI Logging record- The IANA is requested to create a new "CDNI Logging record-types"
types. under the "Content Delivery Networks Interconnection (CDNI)
Parameters" category.
The initial contents of the CDNI Logging record-types registry The initial contents of the CDNI Logging record-types registry
comprise the names of the CDNI Logging Record types specified in comprise the names of the CDNI Logging Record types specified in
Section 3.4 of the present document, and are as follows: Section 3.4 of the present document, and are as follows:
+----------------------+-----------+----------------------------------+ +----------------------+-----------+----------------------------------+
| record-types | Reference | Description | | record-types | Reference | Description |
+----------------------+-----------+----------------------------------+ +----------------------+-----------+----------------------------------+
| cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 | | cdni_http_request_v1 | RFC xxxx | CDNI Logging Record version 1 |
| | | for content delivery using HTTP | | | | for content delivery using HTTP |
skipping to change at page 48, line 26 skipping to change at page 48, line 26
o for all these fields: a specification of the occurrence for each o for all these fields: a specification of the occurrence for each
Field in the new record-type Field in the new record-type
o for every newly defined Field, i.e., for every Field that results o for every newly defined Field, i.e., for every Field that results
in a registration in the CDNI Logging Field Names Registry in a registration in the CDNI Logging Field Names Registry
(Section 6.4): a specification of the field name, format and field (Section 6.4): a specification of the field name, format and field
value. value.
6.4. CDNI Logging Field Names Registry 6.4. CDNI Logging Field Names Registry
The IANA is requested to create a new registry, CDNI Logging Field The IANA is requested to create a new "CDNI Logging Field Names"
Names. under the "Content Delivery Networks Interconnection (CDNI)
Parameters" category.
This registry is intended to be shared across the currently defined This registry is intended to be shared across the currently defined
record-type (i.e., cdni_http_request_v1) as well as potential other record-type (i.e., cdni_http_request_v1) as well as potential other
CDNI Logging record-types that may be defined in separate CDNI Logging record-types that may be defined in separate
specifications. When a Field from this registry is used by another specifications. When a Field from this registry is used by another
CDNI Logging record-type, it is to be used with the exact semantics CDNI Logging record-type, it is to be used with the exact semantics
and format specified in the document that registered this field and and format specified in the document that registered this field and
that is identified in the Reference column of the registry. If that is identified in the Reference column of the registry. If
another CDNI Logging record-type requires a Field with semantics that another CDNI Logging record-type requires a Field with semantics that
are not strictly identical, or a format that is not strictly are not strictly identical, or a format that is not strictly
skipping to change at page 49, line 42 skipping to change at page 49, line 42
the present document] the present document]
Within the registry, names are to be allocated by IANA according to Within the registry, names are to be allocated by IANA according to
the "Specification Required" policy specified in [RFC5226]. Field the "Specification Required" policy specified in [RFC5226]. Field
names are to be allocated by IANA with a format of NHTABSTRING (see names are to be allocated by IANA with a format of NHTABSTRING (see
Section 3.1). Section 3.1).
6.5. CDNI Logging MIME Media Type 6.5. CDNI Logging MIME Media Type
The IANA is requested to register the following new Payload Type in The IANA is requested to register the following new Payload Type in
the CDNI Payload Type Parameter registry for use with the the CDNI Payload Type registry for use with the application/cdni MIME
application/cdni MIME media type. media type.
[RFC Editor Note: Please replace the references to [RFCthis] below [RFC Editor Note: Please replace the references to [RFCthis] below
with this document's RFC number before publication. with this document's RFC number before publication.]
+----------------------+---------------+ +----------------------+---------------+
| Payload Type | Specification | | Payload Type | Specification |
+----------------------+---------------+ +----------------------+---------------+
| logging-file | [RFCthis] | | logging-file | [RFCthis] |
+----------------------+---------------+ +----------------------+---------------+
Figure 12: MIME Media Type payload Figure 12: MIME Media Type payload
The purpose of the logging-file payload type is to be able to The purpose of the logging-file payload type is to distinguish
distinguish logging messages from other types of messages. between CDNI Logging Files and other CDNI messages.
Interface: LI Interface: LI
Encoding: see Section 4.1.1 Encoding: see Section 3.2, Section 3.3 and Section 3.4
7. Security Considerations 7. Security Considerations
7.1. Authentication, Authorization, Confidentiality, Integrity 7.1. Authentication, Authorization, Confidentiality, Integrity
Protection Protection
An implementation of the CDNI Logging interface MUST support TLS An implementation of the CDNI Logging interface MUST support TLS
transport of the CDNI Logging feed (Section 4.1) and of the CDNI transport of the CDNI Logging feed (Section 4.1) and of the CDNI
Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230]. Logging File pull (Section 4.2) as per [RFC2818] and [RFC7230].
skipping to change at page 51, line 44 skipping to change at page 51, line 44
7.3. Privacy 7.3. Privacy
CDNs have the opportunity to collect detailed information about the CDNs have the opportunity to collect detailed information about the
downloads performed by End Users. A dCDN is expected to collect such downloads performed by End Users. A dCDN is expected to collect such
information into CDNI Logging Files, which are then communicatd to an information into CDNI Logging Files, which are then communicatd to an
uCDN. uCDN.
Having detailed CDNI logging information known by the dCDN in itself Having detailed CDNI logging information known by the dCDN in itself
does not represent a particular privacy concern since the dCDN is does not represent a particular privacy concern since the dCDN is
obviously fully aware of all information logged since it generates it obviously fully aware of all information logged since it generated
in the first place. Making detailed CDNI logging information known the information in the first place. Making detailed CDNI logging
to the uCDN does not represent a particular privacy concern because information known to the uCDN does not represent a particular privacy
the uCDN is already exposed at request redirection time to most of concern because the uCDN is already exposed at request redirection
the information that shows up as CDNI logging information (e.g. time to most of the information that shows up as CDNI logging
enduser IP@, URL, HTTP headers - at least when HTTP redirection is information (e.g., enduser IP@, URL, HTTP headers - at least when
used between uCDN and dCDN). Transporting detailed CDNI logging HTTP redirection is used between uCDN and dCDN). Transporting
information over the HTTP based CDNI Logging Interface does not detailed CDNI logging information over the HTTP based CDNI Logging
represent a particular privacy concern because it is protected by Interface does not represent a particular privacy concern because it
usual IETF privacy-protection mechanism (TLS). is protected by usual IETF privacy-protection mechanism (e.g.,TLS).
However, one privacy concern arises from the fact that very large However, one privacy concern arises from the fact that large volumes
volumes of detailed information about content delivery to users, of detailed information about content delivery to users, potentially
potentially traceable back to indvidual users, may be collected in traceable back to indvidual users, may be collected in CDNI Logging
CDNI Logging files, which then represent a high-value target, likely files. These CDNI Logging files represent high-value targets, likely
concentrated in a fairly centralised system (although the CDNI concentrated in a fairly centralised system (although the CDNI
Logging architecture does not manadate a particular level of Logging architecture does not manadate a particular level of
centralisation/distribution) and thus is at risk of potential data centralisation/distribution) and at risk of potential data
exfiltration. Note that the means of such data exfiltration are exfiltration. Note that the means of such data exfiltration are
beyond the scope of the CDNI Logging interface itself (e.g. corrupted beyond the scope of the CDNI Logging interface itself (e.g.,
employee, corrupted logging storage system,...). This privacy corrupted employee, corrupted logging storage system,...). This
concern calls for some protection. privacy concern calls for some protection.
The collection of very large volumes of such information into CDNI The collection of large volumes of such information into CDNI Logging
Logging Files introduces potential End Users privacy protection Files introduces potential End Users privacy protection concerns.
concerns. Mechanisms to address these concerned are discussed in the Mechanisms to address these concerns are discussed in the definition
definition of the c-groupid field specified in section Section 3.4.1. of the c-groupid field specified in Section 3.4.1.
The use of mutually authenticated TLS to establish a secure session The use of mutually authenticated TLS to establish a secure session
for the transport of the CDNI Logging feed and CDNI Logging pull as for the transport of the CDNI Logging feed and CDNI Logging pull as
discussed in Section 7.1 provides confidentiality while the logging discussed in Section 7.1 provides confidentiality while the logging
information is in transit and prevents any other party than the information is in transit and prevents any party other than the
authorised uCDN to gain access to the logging information. authorised uCDN to gain access to the logging information.
We also note that the query string portion of the URL that may be We also note that the query string portion of the URL that may be
conveyed inside the cs-uri and u-uri fields of CDNI Logging Files, or conveyed inside the cs-uri and u-uri fields of CDNI Logging Files, or
the HTTP cookies( [RFC6265]) that may be conveyed as part of the the HTTP cookies( [RFC6265]) that may be conveyed as part of the
cs(<HTTP-header-name>) field of CDNI Logging files, may contain cs(<HTTP-header-name>) field of CDNI Logging files, may contain
personnal information or information that can be exploited to derive personnal information or information that can be exploited to derive
personal information. Where this is a concern, the CDNI Logging personal information. Where this is a concern, the CDNI Logging
interface specification allows the dCDN to not include the cs-uri and interface specification allows the dCDN to not include the cs-uri and
to include a u-uri that removes (or hides) the sensitive part of the to include a u-uri that removes (or hides) the sensitive part of the
skipping to change at page 52, line 50 skipping to change at page 52, line 50
8. Acknowledgments 8. Acknowledgments
This document borrows from the W3C Extended Log Format [ELF]. This document borrows from the W3C Extended Log Format [ELF].
Rob Murray significantly contributed into the text of Section 4.1. Rob Murray significantly contributed into the text of Section 4.1.
The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and The authors thank Ben Niven-Jenkins, Kevin Ma, David Mandelberg and
Ray van Brandenburg for their ongoing input. Ray van Brandenburg for their ongoing input.
Brian Trammel and Rich Salz made significant contributions into
making this interface privacy-friendly.
Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian Finally, we also thank Sebastien Cubaud, Pawel Grochocki, Christian
Jacquenet, Yannick Le Louedec, Anne Marrec , Emile Stephan, Fabio Jacquenet, Yannick Le Louedec, Anne Marrec, Emile Stephan, Fabio
Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the Costa, Sara Oueslati, Yvan Massot, Renaud Edel, Joel Favier and the
contributors of the EU FP7 OCEAN project for their input in the early contributors of the EU FP7 OCEAN project for their input in the early
versions of this document. versions of this document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
skipping to change at page 55, line 16 skipping to change at page 55, line 16
Log File Format, W3C (work in progress), WD-logfile- Log File Format, W3C (work in progress), WD-logfile-
960323", <http://www.w3.org/TR/WD-logfile.html>. 960323", <http://www.w3.org/TR/WD-logfile.html>.
[I-D.ietf-cdni-media-type] [I-D.ietf-cdni-media-type]
Ma, K., "CDNI Media Type Registration", draft-ietf-cdni- Ma, K., "CDNI Media Type Registration", draft-ietf-cdni-
media-type-06 (work in progress), October 2015. media-type-06 (work in progress), October 2015.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni- "CDN Interconnection Metadata", draft-ietf-cdni-
metadata-11 (work in progress), July 2015. metadata-12 (work in progress), October 2015.
[I-D.ietf-tls-rfc5246-bis] [I-D.ietf-tls-rfc5246-bis]
Dierks, T. and E. Rescorla, "The Transport Layer Security Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.3", draft-ietf-tls-rfc5246-bis-00 (TLS) Protocol Version 1.3", draft-ietf-tls-rfc5246-bis-00
(work in progress), April 2014. (work in progress), April 2014.
[I-D.snell-atompub-link-extensions] [I-D.snell-atompub-link-extensions]
Snell, J., "Atom Link Extensions", draft-snell-atompub- Snell, J., "Atom Link Extensions", draft-snell-atompub-
link-extensions-09 (work in progress), June 2012. link-extensions-09 (work in progress), June 2012.
 End of changes. 42 change blocks. 
109 lines changed or deleted 114 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/