draft-ietf-cdni-logging-26.txt   draft-ietf-cdni-logging-27.txt 
Internet Engineering Task Force F. Le Faucheur, Ed. Internet Engineering Task Force F. Le Faucheur, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track G. Bertrand, Ed. Intended status: Standards Track G. Bertrand, Ed.
Expires: November 26, 2016 Orange Expires: December 10, 2016
I. Oprescu, Ed. I. Oprescu, Ed.
R. Peterkofsky R. Peterkofsky
Google Inc. Google Inc.
May 25, 2016 June 8, 2016
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-26 draft-ietf-cdni-logging-27
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 40 skipping to change at page 1, line 40
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 November 26, 2016. This Internet-Draft will expire on December 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 50 skipping to change at page 2, line 50
Collection . . . . . . . . . . . . . . . . . . . . . . . . . 42 Collection . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 43 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 43
4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 43 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 43
4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 43 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 43
4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 44 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 44
4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 44 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 44
4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 46 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 46
5. Protocol for Exchange of CDNI Logging File During Collection 47 5. Protocol for Exchange of CDNI Logging File During Collection 47
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 48 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 48
6.2. CDNI Logging File version Registry . . . . . . . . . . . 49 6.2. CDNI Logging File version Registry . . . . . . . . . . . 48
6.3. CDNI Logging record-types Registry . . . . . . . . . . . 49 6.3. CDNI Logging record-types Registry . . . . . . . . . . . 49
6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 50 6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 50
6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 51 6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 51
7. Security Considerations . . . . . . . . . . . . . . . . . . . 52 7. Security Considerations . . . . . . . . . . . . . . . . . . . 52
7.1. Authentication, Authorization, Confidentiality, Integrity 7.1. Authentication, Authorization, Confidentiality, Integrity
Protection . . . . . . . . . . . . . . . . . . . . . . . 52 Protection . . . . . . . . . . . . . . . . . . . . . . . 52
7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 53 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 53
7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 53 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 53
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . 55 9.1. Normative References . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . 57 9.2. Informative References . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
1. Introduction 1. Introduction
This memo specifies the CDNI Logging interface between a downstream This memo specifies the CDNI Logging interface between a downstream
CDN (dCDN) and an upstream CDN (uCDN). First, it describes a CDN (dCDN) and an upstream CDN (uCDN). 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.
The reader should be familiar with the following documents: The reader should be familiar with the following documents:
skipping to change at page 20, line 8 skipping to change at page 20, line 8
DIRGROUP = 1*DIRLINE DIRGROUP = 1*DIRLINE
RECLINE = <any subset of record values that match what is expected RECLINE = <any subset of record values that match what is expected
according to the fields directive within the immediately preceding according to the fields directive within the immediately preceding
DIRGROUP> DIRGROUP>
RECGROUP = *RECLINE RECGROUP = *RECLINE
CDNILOGFILE = 1*(DIRGROUP RECGROUP) CDNILOGFILE = 1*(DIRGROUP RECGROUP)
All directive names and field names defined in the logging file are
case-insensitive as per the basic ABNF([RFC5234]).
3.3. CDNI Logging Directives 3.3. CDNI Logging Directives
A CDNI Logging directive line contains the directive name followed by A CDNI Logging directive line contains the directive name followed by
":" HTAB and the directive value. ":" HTAB and the directive value.
Directive names MUST be of the format NAMEFORMAT. All directive Directive names MUST be of the format NAMEFORMAT. All directive
names MUST be registered in the CDNI Logging Directives Names names MUST be registered in the CDNI Logging Directives Names
registry. Unknown directives MUST be ignored. Directive values can registry. Directive names are case-insensitive as per the basic
have various formats. All possible directive values for the record- ABNF([RFC5234]). Unknown directives MUST be ignored. Directive
type "cdni_http_request_v1" are further detailed in this section. values can have various formats. All possible directive values for
the record-type "cdni_http_request_v1" are further detailed in this
section.
The following example shows the structure of a directive and The following example shows the structure of a directive and
enumerates strictly the directive values presently defined in the enumerates strictly the directive values presently defined in the
version "CDNI/1.0" of the CDNI Logging File. version "cdni/1.0" of the CDNI Logging File.
directive = DIRNAME ":" HTAB DIRVAL directive = DIRNAME ":" HTAB DIRVAL
DIRNAME = NAMEFORMAT DIRNAME = NAMEFORMAT
DIRVAL = NHTABSTRING / QSTRING / host / USER-COMMENT / FIENAME * DIRVAL = NHTABSTRING / QSTRING / host / USER-COMMENT / FIENAME *
(HTAB FIENAME) / 64HEXDIG (HTAB FIENAME) / 64HEXDIG
An implementation of the CDNI Logging interface MUST support all of An implementation of the CDNI Logging interface MUST support all of
the following directives, listed below by their directive name: the following directives, listed below by their directive name:
o version: o version:
* format: NHTABSTRING * format: NHTABSTRING
* directive value: indicates the version of the CDNI Logging File * directive value: indicates the version of the CDNI Logging File
format. The entity transmitting a CDNI Logging File as per the format. The entity transmitting a CDNI Logging File as per the
present document MUST set the value to "CDNI/1.0". In the present document MUST set the value to "cdni/1.0". In the
future, other versions of CDNI Logging File might be specified; future, other versions of CDNI Logging File might be specified;
those would use a value different to "CDNI/1.0" allowing the those would use a value different to "cdni/1.0" allowing the
entity receiving the CDNI Logging File to identify the entity receiving the CDNI Logging File to identify the
corresponding version. corresponding version. CDNI Logging File versions are case-
insensitive as per the basic ABNF([RFC5234]).
* occurrence: there MUST be one and only one instance of this * occurrence: there MUST be one and only one instance of this
directive per CDNI Logging File. It MUST be the first line of directive per CDNI Logging File. It MUST be the first line of
the CDNI Logging File. the CDNI Logging File.
* example: "version: HTAB CDNI/1.0". * example: "version: HTAB cdni/1.0".
o UUID: o UUID:
* format: NHTABSTRING * format: NHTABSTRING
* directive value: this a Uniform Resource Name (URN) from the * directive value: this a Uniform Resource Name (URN) from the
Universally Unique IDentifier (UUID) URN namespace specified in Universally Unique IDentifier (UUID) URN namespace specified in
[RFC4122]). The UUID contained in the URN uniquely identifies [RFC4122]). The UUID contained in the URN uniquely identifies
the CDNI Logging File. the CDNI Logging File.
skipping to change at page 22, line 33 skipping to change at page 22, line 33
o record-type: o record-type:
* format: NAMEFORMAT * format: NAMEFORMAT
* directive value: indicates the type of the CDNI Logging Records * directive value: indicates the type of the CDNI Logging Records
that follow this directive, until another record-type directive that follow this directive, until another record-type directive
(or the end of the CDNI Logging File). This can be any CDNI (or the end of the CDNI Logging File). This can be any CDNI
Logging Record type registered in the CDNI Logging Record-types Logging Record type registered in the CDNI Logging Record-types
registry (Section 6.3). For example this may be registry (Section 6.3). For example this may be
"cdni_http_request_v1" as specified in Section 3.4.1. "cdni_http_request_v1" as specified in Section 3.4.1. CDNI
Logging record-types are case-insensitive as per the basic
ABNF([RFC5234]).
* occurrence: there MUST be at least one instance of this * occurrence: there MUST be at least one instance of this
directive per CDNI Logging File. The first instance of this directive per CDNI Logging File. The first instance of this
directive MUST precede a fields directive and MUST precede all directive MUST precede a fields directive and MUST precede all
CDNI Logging Records. CDNI Logging Records.
* example: "record-type: HTAB cdni_http_request_v1". * example: "record-type: HTAB cdni_http_request_v1".
o fields: o fields:
skipping to change at page 24, line 20 skipping to change at page 24, line 23
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 ignore
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-
side implementation of the CDNI Logging interface receiving a CDNI side implementation of the CDNI Logging interface receiving a CDNI
Logging file with zero occurrence of the version directive, or with Logging file with zero occurrence of the version directive, or with
two occurrences of the SHA256-hash, MUST reject this CDNI Logging two occurrences of the SHA256-hash, MUST ignore this CDNI Logging
File. File.
An entity receiving a CDNI Logging File with a value set to An entity receiving a CDNI Logging File with a value set to
"CDNI/1.0" MUST process the CDNI Logging File as per the present "cdni/1.0" MUST process the CDNI Logging File as per the present
document. An entity receiving a CDNI Logging File with a value set document. An entity receiving a CDNI Logging File with a value set
to a different value MUST process the CDNI Logging File as per the to a different value MUST process the CDNI Logging File as per the
specification referenced in the CDNI Logging File version registry specification referenced in the CDNI Logging File version registry
(see Section 6.1) if the implementation supports this specification (see Section 6.1) if the implementation supports this specification
and MUST reject the CDNI Logging File otherwise. and MUST ignore the CDNI Logging File otherwise.
3.4. CDNI Logging Records 3.4. CDNI Logging Records
A CDNI Logging Record consists of a sequence of CDNI Logging fields A CDNI Logging Record consists of a sequence of CDNI Logging fields
relating to that single CDNI Logging Record. relating to that single CDNI Logging Record.
CDNI Logging fields MUST be separated by the "horizontal tabulation CDNI Logging fields MUST be separated by the "horizontal tabulation
(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
skipping to change at page 27, line 21 skipping to change at page 27, line 23
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. than one client.
+ When the aggregate is chosen so that it contains a single + When the aggregate is chosen so that it contains a single
client (e.g., to allow more detailed analytics, or to allow client (e.g., to allow more detailed analytics, or 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) the c-groupid MAY situations of performance-based penalties) the c-groupid MAY
be structured where some elements identify aggregates and be structured where some elements identify aggregates and
one element identifies the client, e.g., US/TN/ one element identifies the client, e.g., US/TN/
MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2. In that MEM/38138/43a5bdd6-95c4-4d62-be65-7410df0021e2. In the case
case: where the aggregate is chosen so that it contains a single
client:
- the element identifying the client SHOULD be - the element identifying the client SHOULD be
algorithmically generated (from the client IPv4 or IPv6 algorithmically generated (from the client IPv4 or IPv6
address in the request received by the Surrogate and/or address in the request received by the Surrogate and/or
other network-level identifying information) in a way other network-level identifying information) in a way
that SHOULD NOT be linkable back to the global addressing that SHOULD NOT be linkable back to the global addressing
context and that SHOULD vary over time (to offer context and that SHOULD vary over time (to offer
protection against long term attacks). protection against long term attacks).
- It is RECOMMENDED that the mapping varies at least once - It is RECOMMENDED that the mapping varies at least once
every 24 hours. every 24 hours.
- The algorithmic mapping and variation over time MAY allow - The algorithmic mapping and variation over time can, in
the uCDN (with the knowledge of the algorithm and time some cases, allow the uCDN (with the knowledge of the
variation and associated attributes and keys) to algorithm and time variation and associated attributes
reconstruct the actual client IPv4 or IPv6 address and/or and keys) to reconstruct the actual client IPv4 or IPv6
other network-level identifying information when required address and/or other network-level identifying
(e.g., to allow a-posteriori analysis of individual information when required (e.g., to allow a-posteriori
delivery for example in situations of performance-based analysis of individual delivery for example in situations
penalties). However, these enduser addresses SHOULD only of performance-based penalties). However, these enduser
be reconstructed on-demand and the CDNI Logging File addresses SHOULD only be reconstructed on-demand and the
SHOULD only be stored with the anonymised c-groupid CDNI Logging File SHOULD only be stored with the
value. anonymised c-groupid value.
- Allowing reconstruction of client address information - Allowing reconstruction of client address information
carries with it grave risks to end-user privacy. Since carries with it grave risks to end-user privacy. Since
the c-groupid is in this case equivalent in the c-groupid is in this case equivalent in
identification power to a client IP address, its use may identification power to a client IP address, its use may
be restricted by regulation or law as personally be restricted by regulation or law as personally
identifiable information. For this reason, such use is identifiable information. For this reason, such use is
NOT RECOMMENDED. NOT RECOMMENDED.
- One method for mapping that MAY be be supported by - One method for mapping that MAY be be supported by
skipping to change at page 33, line 35 skipping to change at page 33, line 37
be used otherwise (including cases where the Surrogate served be used otherwise (including cases where the Surrogate served
the request using some, but not all, content already stored on the request using some, but not all, content already stored on
its local cache). Note that a "0" only means a cache miss in its local cache). Note that a "0" only means a cache miss in
the Surrogate and does not provide any information on whether the Surrogate and does not provide any information on whether
the content was already stored, or not, in another device of the content was already stored, or not, in another device of
the dCDN, i.e., whether this was a "dCDN hit" or "dCDN miss". the dCDN, i.e., whether this was a "dCDN hit" or "dCDN miss".
* occurrence: there MUST be zero or exactly one instance of this * occurrence: there MUST be zero or exactly one instance of this
field. field.
The "fields" directive corresponding to a HTTP Request Logging Record CDNI Logging field names are case-insensitive as per the basic
MUST contain all the fields names whose occurrence is specified above ABNF([RFC5234]). The "fields" directive corresponding to a HTTP
as "There MUST be one and only one instance of this field". The Request Logging Record MUST contain all the fields names whose
corresponding fields value MUST be present in every HTTP Request occurrence is specified above as "There MUST be one and only one
Logging Record. instance of this field". The corresponding fields value MUST be
present in every HTTP Request Logging Record.
The "fields" directive corresponding to a HTTP Request Logging Record The "fields" directive corresponding to a HTTP Request Logging Record
MAY list all the fields value whose occurrence is specified above as MAY list all the fields value whose occurrence is specified above as
"there MUST be zero or exactly one instance of this field" or "there "there MUST be zero or exactly one instance of this field" or "there
MAY be zero, one or any number of instances of this field". The set MAY be zero, one or any number of instances of this field". The set
of such field names actually listed in the "fields" directive is of such field names actually listed in the "fields" directive is
selected by the CDN generating the CDNI Logging File based on selected by the CDN generating the CDNI Logging File based on
agreements between the interconnected CDNs established through agreements between the interconnected CDNs established through
mechanisms outside the scope of this specification (e.g., contractual mechanisms outside the scope of this specification (e.g., contractual
agreements). When such a field name is not listed in the "fields" agreements). When such a field name is not listed in the "fields"
skipping to change at page 35, line 48 skipping to change at page 36, line 4
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 ignore 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.
3.5. CDNI Logging File Extension 3.5. CDNI Logging File Extension
The CDNI Logging File contains blocks of directives and blocks of The CDNI Logging File contains blocks of directives and blocks of
corresponding records. The supported set of directives is defined corresponding records. The supported set of directives is defined
relative to the CDNI Logging File Format version. The complete set relative to the CDNI Logging File Format version. The complete set
of directives for version "CDNI/1.0" are defined in Section 3.3. The of directives for version "cdni/1.0" are defined in Section 3.3. The
directive list is not expected to require much extension, but when it directive list is not expected to require much extension, but when it
does, the new directive MUST be defined and registered in the "CDNI does, the new directive MUST be defined and registered in the "CDNI
Logging Directive Names" registry, as described in Figure 9, and a Logging Directive Names" registry, as described in Figure 9, and a
new version MUST be defined and registered in the "CDNI Logging File new version MUST be defined and registered in the "CDNI Logging File
version" registry, as described in Section 6.2. For example, adding version" registry, as described in Section 6.2. For example, adding
a new CDNI Logging Directive, e.g., "foo", to the set of directives a new CDNI Logging Directive, e.g., "foo", to the set of directives
defined for "CDNI/1.0" in Section 3.3, would require registering both defined for "cdni/1.0" in Section 3.3, would require registering both
the new CDNI Logging Directive "foo" and a new CDNI Logging File the new CDNI Logging Directive "foo" and a new CDNI Logging File
version, e.g., "CDNI/2.0", which includes all of the existing CDNI version, e.g., "CDNI/2.0", which includes all of the existing CDNI
Logging Directives of "CDNI/1.0" plus "foo". Logging Directives of "cdni/1.0" plus "foo".
It is expected that as new logging requirements arise, the list of It is expected that as new logging requirements arise, the list of
fields to log will change and expand. When adding new fields, the fields to log will change and expand. When adding new fields, the
new fields MUST be defined and registered in the "CDNI Logging Field new fields MUST be defined and registered in the "CDNI Logging Field
Names" registry, as described in Section 6.4, and a new record-type Names" registry, as described in Section 6.4, and a new record-type
MUST be defined and registered in the "CDNI Logging record-types" MUST be defined and registered in the "CDNI Logging record-types"
registry, as described in Section 6.3. For example, adding a new registry, as described in Section 6.3. For example, adding a new
CDNI Logging Field, e.g., "c-bar", to the set of fields defined for CDNI Logging Field, e.g., "c-bar", to the set of fields defined for
"cdni_http_request_v1" in Section 3.4.1, would require registering "cdni_http_request_v1" in Section 3.4.1, would require registering
both the new CDNI Logging Field "c-bar" and a new CDNI record-type, both the new CDNI Logging Field "c-bar" and a new CDNI record-type,
skipping to change at page 40, line 8 skipping to change at page 40, line 8
Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3 Let us consider the cascaded CDN scenario of uCDN, dCDN-2 and dCDN-3
as depicted in Figure 1. After completion of a delivery by dCDN-3 on as depicted in Figure 1. After completion of a delivery by dCDN-3 on
behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record behalf of dCDN-2, dCDN-3 will include a corresponding Logging Record
in a CDNI Logging File that will be pulled by dCDN-2 and that is in a CDNI Logging File that will be pulled by dCDN-2 and that is
illustrated below in Figure 6. In practice, a CDNI Logging File is illustrated below in Figure 6. In practice, a CDNI Logging File is
likely to contain a very high number of CDNI Logging Records. likely to contain a very high number of CDNI Logging Records.
However, for readability, the example in Figure 6 contains a single However, for readability, the example in Figure 6 contains a single
CDNI Logging Record. CDNI Logging Record.
#version:<HTAB>CDNI/1.0<CRLF> #version:<HTAB>cdni/1.0<CRLF>
#UUID:<HTAB>urn:uuid:65718ef-0123-9876-adce4321bcde<CRLF> #UUID:<HTAB>urn:uuid:65718ef-0123-9876-adce4321bcde<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF> #claimed-origin:<HTAB>cdni-logging-entity.dcdn-3.example.com<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF> #record-type:<HTAB>cdni_http_request_v1<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB> #fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB> cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB> sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
skipping to change at page 41, line 9 skipping to change at page 41, line 9
behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and behalf of dCDN-2 had actually been redirected to dCDN-2 by uCDN, and
say that another content delivery has just been redirected by uCDN to say that another content delivery has just been redirected by uCDN to
dCDN-2 and that dCDN-2 elected to perform the corresponding delivery dCDN-2 and that dCDN-2 elected to perform the corresponding delivery
itself. Then after Filtering and Rectification (as illustrated in itself. Then after Filtering and Rectification (as illustrated in
Figure 2), dCDN-2 will include the two Logging Records corresponding Figure 2), dCDN-2 will include the two Logging Records corresponding
respectively to the delivery performed by dCDN-3 and the delivery respectively to the delivery performed by dCDN-3 and the delivery
performed by dCDN-2, in the next CDNI Logging File that will be performed by dCDN-2, in the next CDNI Logging File that will be
communicated to uCDN. An example of such CDNI Logging File is communicated to uCDN. An example of such CDNI Logging File is
illustrated below in Figure 7. illustrated below in Figure 7.
#version:<HTAB>CDNI/1.0<CRLF> #version:<HTAB>cdni/1.0<CRLF>
#UUID:<HTAB>urn:uuid:1234567-8fedc-abab-0987654321ff<CRLF> #UUID:<HTAB>urn:uuid:1234567-8fedc-abab-0987654321ff<CRLF>
#claimed-origin:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF> #claimed-origin:<HTAB>cdni-logging-entity.dcdn-2.example.com<CRLF>
#record-type:<HTAB>cdni_http_request_v1<CRLF> #record-type:<HTAB>cdni_http_request_v1<CRLF>
#fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB> #fields:<HTAB>date<HTAB>time<HTAB>time-taken<HTAB>c-groupid<HTAB>
cs-method<HTAB>u-uri<HTAB>protocol<HTAB> cs-method<HTAB>u-uri<HTAB>protocol<HTAB>
sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB> sc-status<HTAB>sc-total-bytes<HTAB>cs(User-Agent)<HTAB>
skipping to change at page 48, line 7 skipping to change at page 48, line 7
information with a significantly reduced time-lag (e.g., sub-minute information with a significantly reduced time-lag (e.g., sub-minute
or sub-second) between when the event occurred in the dCDN and when or sub-second) between when the event occurred in the dCDN and when
the corresponding CDNI Logging Record is made available to the uCDN. the corresponding CDNI Logging Record is made available to the uCDN.
This can satisfy log-consuming applications requiring extremely fresh This can satisfy log-consuming applications requiring extremely fresh
logging information such as near-real-time content delivery logging information such as near-real-time content delivery
monitoring. Such mechanisms are for further study and outside the monitoring. Such mechanisms are for further study and outside the
scope of this document. scope of this document.
6. IANA Considerations 6. IANA Considerations
When IANA allocates new extensions to CDNI Logging Directive Names
Registry, CDNI Logging File version Registry, CDNI Logging record-
type Registry or CDNI Logging fields Registry, IANA MUST take into
account that the directive names are case-insensitive as per the
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 "CDNI Logging Directive Names" The IANA is requested to create a new "CDNI Logging Directive Names"
subregistry under the "Content Delivery Networks Interconnection subregistry under the "Content Delivery Networks Interconnection
(CDNI) Parameters" registry. (CDNI) Parameters" registry.
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:
skipping to change at page 49, line 12 skipping to change at page 49, line 6
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 "CDNI Logging File version" The IANA is requested to create a new "CDNI Logging File version"
subregistry under the "Content Delivery Networks Interconnection subregistry under the "Content Delivery Networks Interconnection
(CDNI) Parameters" registry. (CDNI) Parameters" registry.
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 |
+-----------------+-----------+----------------------------------+ +-----------------+-----------+----------------------------------+
Figure 10 Figure 10
skipping to change at page 52, line 28 skipping to change at page 52, line 28
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].
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).
The use of TLS for transport of the CDNI Logging feed and CDNI The use of TLS for transport of the CDNI Logging feed and CDNI
Logging File pull allows: Logging File pull allows:
o the dCDN and uCDN to authenticate each other o the dCDN and uCDN to authenticate each other using TLS client auth
and TLS server auth.
and, once they have mutually authenticated each other, it allows: and, once they have mutually authenticated each other, it allows:
o the dCDN and uCDN to authorize each other (to ensure they are o the dCDN and uCDN to authorize each other (to ensure they are
transmitting/receiving CDNI Logging File to/from an authorized transmitting/receiving CDNI Logging File to/from an authorized
CDN) CDN)
o the CDNI Logging information to be transmitted with o the CDNI Logging information to be transmitted with
confidentiality confidentiality
o the integrity of the CDNI Logging information to be protected o the integrity of the CDNI Logging information to be protected
during the exchange. during the exchange.
In an environment where any such protection is required, mutually
authenticated encrypted transport MUST be used to ensure
confidentiality of the logging information, and to do so, TLS MUST be
used (including authentication of the remote end) 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.
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
followed. followed.
The SHA256-hash directive inside the CDNI Logging File provides The SHA256-hash directive inside the CDNI Logging File provides
additional integrity protection, this time targeting potential additional integrity protection, this time targeting potential
corruption of the CDNI logging information during the CDNI Logging corruption of the CDNI logging information during the CDNI Logging
File generation, storage or exchange. This mechanism does not itself File generation, storage or exchange. This mechanism does not itself
allow restoration of the corrupted CDNI Logging information, but it allow restoration of the corrupted CDNI Logging information, but it
allows detection of such corruption and therefore triggering of allows detection of such corruption and therefore triggering of
appropriate corrective actions (e.g., discard of corrupted appropriate corrective actions (e.g., discard of corrupted
information, attempt to re-obtain the CDNI Logging information). information, attempt to re-obtain the CDNI Logging information).
Note that the SHA256-hash does not protect against tampering by a Note that the SHA256-hash does not protect against tampering by a
third party, since such a third party could have recomputed and third party, since such a third party could have recomputed and
updated the SHA256-hash after tampering. Protection against third updated the SHA256-hash after tampering. Protection against third
party tampering when the CDNI Logging File is communicated over the party tampering, when the CDNI Logging File is communicated over the
CDN Logging Interface can be achieved as discussed above through the CDN Logging Interface, can be achieved as discussed above through the
use of TLS. use of TLS.
7.2. Denial of Service 7.2. Denial of Service
This document does not define specific mechanism to protect against This document does not define specific mechanism to protect against
Denial of Service (DoS) attacks on the Logging Interface. However, Denial of Service (DoS) attacks on the Logging Interface. However,
the CDNI Logging feed and CDNI Logging pull endpoints are typically the CDNI Logging feed and CDNI Logging pull endpoints are typically
to be accessed only by a very small number of valid remote endpoints to be accessed only by a very small number of valid remote endpoints
and therefore can be easily protected against DoS attacks through the and therefore can be easily protected against DoS attacks through the
usual conventional DOS protection mechanisms such as firewalling or usual conventional DOS protection mechanisms such as firewalling or
skipping to change at page 53, line 46 skipping to change at page 53, line 49
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 communicated to information into CDNI Logging Files, which are then communicated to
an uCDN. an 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 generated obviously fully aware of all information logged since it generated
the information in the first place. Making detailed CDNI logging the information in the first place.
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). 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).
However, one privacy concern arises from the fact that large volumes Transporting detailed CDNI logging information over the HTTP based
of detailed information about content delivery to users, potentially CDNI Logging Interface does not represent a particular privacy
concern because it is protected by usual IETF privacy-protection
mechanism (e.g.,TLS).
When HTTP redirection is used between the uCDN and the dCDN, 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). When DNS redirection is used between the uCDN and the
dCDN, there are cases where there is no privacy concern in making
detailed CDNI logging information known to the uCDN; this may be the
case, for example, where (1) it is considered that because the uCDN
has the authority (with respect to the CSP) and control on how the
requests are delivered (including whether it is served by the uCDN
itself or by a dCDN), the uCDN is entitled to access all detailed
information related to the corresponding deliveries, and (2) there is
no legal reasons to restrict access by the uCDN to all these detailed
information. Conversely, still when DNS redirection is used between
the uCDN and the dCDN, there are cases where there may be some
privacy concern in making detailed CDNI logging information known to
the uCDN; this may be the case, for example, because the uCDN is in a
different jurisdiction to the dCDN resulting is some legal reasons to
restrict access by the uCDN to all the detailed information related
to the deliveries. In this latter case, the privacy concern can be
taken into account when the uCDN and dCDN agree about which fields
are to be conveyed inside the CDNI Logging Files and which privacy
protection mechanism is to be used as discussed in the definition of
the c-groupid field specified in Section 3.4.1.
Another privacy concern arises from the fact that large volumes of
detailed information about content delivery to users, potentially
traceable back to indvidual users, may be collected in CDNI Logging traceable back to indvidual users, may be collected in CDNI Logging
files. These CDNI Logging files represent high-value targets, 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 mandate a particular level of Logging architecture does not mandate a particular level of
centralisation/distribution) and 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., beyond the scope of the CDNI Logging interface itself (e.g.,
corrupted employee, corrupted logging storage system,...). This corrupted employee, corrupted logging storage system,...). This
privacy concern calls for some protection. privacy concern calls for some protection.
skipping to change at page 58, line 47 skipping to change at page 59, line 28
DOI 10.17487/RFC7337, August 2014, DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>. <http://www.rfc-editor.org/info/rfc7337>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI)
Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
December 2015, <http://www.rfc-editor.org/info/rfc7736>. December 2015, <http://www.rfc-editor.org/info/rfc7736>.
Authors' Addresses Authors' Addresses
Francois Le Faucheur (editor) Francois Le Faucheur (editor)
FR
Phone: +33 6 19 98 50 90 Phone: +33 6 19 98 50 90
Email: flefauch@gmail.com Email: flefauch@gmail.com
Gilles Bertrand (editor) Gilles Bertrand (editor)
Orange
38-40 rue du General Leclerc
Issy les Moulineaux 92130
FR
Phone: +33 1 45 29 89 46 Phone: +41 76 675 91 44
Email: gilles.bertrand@orange.com Email: gilbertrand@gmail.com
Iuniana Oprescu (editor) Iuniana Oprescu (editor)
FR FR
Email: iuniana.oprescu@gmail.com Email: iuniana.oprescu@gmail.com
Roy Peterkofsky Roy Peterkofsky
Google Inc. Google Inc.
345 Spear St, 4th Floor 345 Spear St, 4th Floor
San Francisco CA 94105 San Francisco CA 94105
 End of changes. 40 change blocks. 
81 lines changed or deleted 103 lines changed or added

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