draft-ietf-cdni-logging-15.txt   draft-ietf-cdni-logging-16.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: August 8, 2015 I. Oprescu, Ed. Expires: September 10, 2015 I. Oprescu, Ed.
Orange Orange
R. Peterkofsky R. Peterkofsky
Skytide, Inc. Skytide, Inc.
February 4, 2015 March 9, 2015
CDNI Logging Interface CDNI Logging Interface
draft-ietf-cdni-logging-15 draft-ietf-cdni-logging-16
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 August 8, 2015. This Internet-Draft will expire on September 10, 2015.
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 2, line 33 skipping to change at page 2, line 33
2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 12 2.2.5.1. Maintenance/Debugging . . . . . . . . . . . . . . 12
2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 12 2.2.5.2. Accounting . . . . . . . . . . . . . . . . . . . 12
2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 12 2.2.5.3. Analytics and Reporting . . . . . . . . . . . . . 12
2.2.5.4. Security . . . . . . . . . . . . . . . . . . . . 13 2.2.5.4. Security . . . . . . . . . . . . . . . . . . . . 13
2.2.5.5. Legal Logging Duties . . . . . . . . . . . . . . 13 2.2.5.5. Legal Logging Duties . . . . . . . . . . . . . . 13
2.2.5.6. Notions common to multiple Log Consuming 2.2.5.6. Notions common to multiple Log Consuming
Applications . . . . . . . . . . . . . . . . . . 13 Applications . . . . . . . . . . . . . . . . . . 13
3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 15 3. CDNI Logging File . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 16 3.2. CDNI Logging File Structure . . . . . . . . . . . . . . . 16
3.3. CDNI Logging File Directives . . . . . . . . . . . . . . 19 3.3. CDNI Logging Directives . . . . . . . . . . . . . . . . . 19
3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 23 3.4. CDNI Logging Records . . . . . . . . . . . . . . . . . . 23
3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 23 3.4.1. HTTP Request Logging Record . . . . . . . . . . . . . 24
3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 32 3.5. CDNI Logging File Example . . . . . . . . . . . . . . . . 33
3.6. Cascaded CDNI Logging Files Example . . . . . . . . . . . 34 3.6. Cascaded CDNI Logging Files Example . . . . . . . . . . . 34
4. Protocol for Exchange of CDNI Logging File After Full 4. Protocol for Exchange of CDNI Logging File After Full
Collection . . . . . . . . . . . . . . . . . . . . . . . . . 37 Collection . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 38 4.1. CDNI Logging Feed . . . . . . . . . . . . . . . . . . . . 38
4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 38 4.1.1. Atom Formatting . . . . . . . . . . . . . . . . . . . 38
4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 38 4.1.2. Updates to Log Files and the Feed . . . . . . . . . . 38
4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 39 4.1.3. Redundant Feeds . . . . . . . . . . . . . . . . . . . 39
4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 39 4.1.4. Example CDNI Logging Feed . . . . . . . . . . . . . . 39
4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 41 4.2. CDNI Logging File Pull . . . . . . . . . . . . . . . . . 41
5. Protocol for Exchange of CDNI Logging File During Collection 42 5. Protocol for Exchange of CDNI Logging File During Collection 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 43 6.1. CDNI Logging Directive Names Registry . . . . . . . . . . 43
6.2. CDNI Logging Record-Types Registry . . . . . . . . . . . 43 6.2. CDNI Logging File Version Registry . . . . . . . . . . . 43
6.3. CDNI Logging Field Names Registry . . . . . . . . . . . . 44 6.3. CDNI Logging Record-Types Registry . . . . . . . . . . . 44
6.4. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 46 6.4. CDNI Logging Field Names Registry . . . . . . . . . . . . 45
6.5. CDNI Logging MIME Media Type . . . . . . . . . . . . . . 46
7. Security Considerations . . . . . . . . . . . . . . . . . . . 46 7. Security Considerations . . . . . . . . . . . . . . . . . . . 46
7.1. Authentication, Confidentiality, Integrity Protection . . 46 7.1. Authentication, Authorization, Confidentiality, Integrity
7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 47 Protection . . . . . . . . . . . . . . . . . . . . . . . 47
7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 47 7.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 48
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 7.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 48
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
9.1. Normative References . . . . . . . . . . . . . . . . . . 48 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
9.2. Informative References . . . . . . . . . . . . . . . . . 49 9.1. Normative References . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 9.2. Informative References . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 52
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 6, line 33 skipping to change at page 6, line 33
o communication by the uCDN to the dCDN of the Logging information o communication by the uCDN to the dCDN of the Logging information
collected by the uCDN relevant to the dCDN. For example, the dCDN collected by the uCDN relevant to the dCDN. For example, the dCDN
might potentially benefit from this information for security might potentially benefit from this information for security
auditing or content acquisition troubleshooting. This is outside auditing or content acquisition troubleshooting. This is outside
the scope of this document and left for further study. the scope of this document and left for further study.
Figure 1 provides an example of CDNI Logging interactions (focusing Figure 1 provides an example of CDNI Logging interactions (focusing
only on the interactions that are in the scope of this document) in a only on the interactions that are in the scope of this document) in a
particular scenario where four CDNs are involved in the delivery of particular scenario where four CDNs are involved in the delivery of
content from a given CSP: the uCDN has a CDNI interconnection with content from a given CSP: the uCDN has a CDNI interconnection with
dCDN-1 and dCDN-2. In turn, dCDN2 has a CDNI interconnection with dCDN-1 and dCDN-2. In turn, dCDN-2 has a CDNI interconnection with
dCDN3. In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all dCDN-3, where dCDN-2 is acting as an upstream CDN relative to dCDN-3.
participate in the delivery of content for the CSP. In this example, In this example, uCDN, dCDN-1, dCDN-2 and dCDN-3 all participate in
the CDNI Logging interface enables the uCDN to obtain Logging the delivery of content for the CSP. In this example, the CDNI
information from all the dCDNs involved in the delivery. In the Logging interface enables the uCDN to obtain Logging information from
example, the uCDN uses the Logging information: all the dCDNs involved in the delivery. In the example, the uCDN
uses the Logging information:
o to analyze the performance of the delivery performed by the dCDNs o to analyze the performance of the delivery performed by the dCDNs
and to adjust its operations after the fact (e.g., request and to adjust its operations after the fact (e.g., request
routing) as appropriate, routing) as appropriate,
o to provide (non-real-time) reporting and monitoring information to o to provide (non-real-time) reporting and monitoring information to
the CSP. the CSP.
For instance, the uCDN merges Logging information, extracts relevant For instance, the uCDN merges Logging information, extracts relevant
KPIs, and presents a formatted report to the CSP, in addition to a KPIs, and presents a formatted report to the CSP, in addition to a
skipping to change at page 7, line 33 skipping to change at page 7, line 33
,' `-. ,' `-.
( dCDN-3 ) ( dCDN-3 )
`. ,-' `. ,-'
`--'--' `--'--'
===> CDNI Logging Interface ===> CDNI Logging Interface
***> outside the scope of CDNI ***> outside the scope of CDNI
Figure 1: Interactions in CDNI Logging Reference Model Figure 1: Interactions in CDNI Logging Reference Model
A dCDN (e.g., dCDN-2) integrates the relevant Logging information A downstream CDN relative to uCDN (e.g., dCDN-2) integrates the
obtained from its dCDNs (i.e., dCDN-3) in the Logging information relevant Logging information obtained from its own downstream CDNs
that it provides to the uCDN, so that the uCDN ultimately obtains all (i.e., dCDN-3) in the Logging information that it provides to the
Logging information relevant to a CSP for which it acts as the uCDN, so that the uCDN ultimately obtains all Logging information
authoritative CDN. Such aggregation is further discussed in relevant to a CSP for which it acts as the authoritative CDN. Such
Section 3.6. aggregation is further discussed in Section 3.6.
Note that the format of Logging information that a CDN provides over Note that the format of Logging information that a CDN provides over
the CDNI interface might be different from the one that the CDN uses the CDNI interface might be different from the one that the CDN uses
internally. In this case, the CDN needs to reformat the Logging internally. In this case, the CDN needs to reformat the Logging
information before it provides this information to the other CDN over information before it provides this information to the other CDN over
the CDNI Logging interface. Similarly, a CDN might reformat the the CDNI Logging interface. Similarly, a CDN might reformat the
Logging information that it receives over the CDNI Logging interface Logging information that it receives over the CDNI Logging interface
before injecting it into its log-consuming applications or before before injecting it into its log-consuming applications or before
providing some of this Logging information to the CSP. Such providing some of this Logging information to the CSP. Such
reformatting operations introduce latency in the logging distribution reformatting operations introduce latency in the logging distribution
skipping to change at page 19, line 5 skipping to change at page 19, line 5
| | | |
| #Directive P+Q | | #Directive P+Q |
+----------------------------------------------------------+ +----------------------------------------------------------+
Figure 3: Structure of Logging Files Figure 3: Structure of Logging Files
The CDNI Logging File format is inspired from the W3C Extended Log The CDNI Logging File format is inspired from the W3C Extended Log
File Format [ELF]. However, it is fully specified by the present File Format [ELF]. However, it is fully specified by the present
document. Where the present document differs from the W3C Extended document. Where the present document differs from the W3C Extended
Log File Format, an implementation of the CDNI Logging interface MUST Log File Format, an implementation of the CDNI Logging interface MUST
comply with the present document. comply with the present document. The W3C Extended Log File Format
was used as a starting point, reused where possible and expanded when
necessary.
Using a format that resembles the W3C Extended Log File Format is Using a format that resembles the W3C Extended Log File Format is
intended to keep CDNI logging format close to the intra-CDN Logging intended to keep CDNI logging format close to the intra-CDN Logging
information format commonly used in CDNs today, thereby minimizing information format commonly used in CDNs today, thereby minimizing
systematic translation at CDN/CDNI boundary. systematic translation at CDN/CDNI boundary.
A CDNI Logging File MUST contain a sequence of lines containing US- A CDNI Logging File MUST contain a sequence of lines containing US-
ASCII characters [CHAR_SET] terminated by CRLF. ASCII characters [CHAR_SET] terminated by CRLF.
Each line of a CDNI Logging File MUST contain either a directive or a Each line of a CDNI Logging File MUST contain either a directive or a
skipping to change at page 19, line 37 skipping to change at page 19, line 39
DIRLINE = "#" directive CRLF DIRLINE = "#" directive CRLF
DIRGROUP = 1*DIRLINE DIRGROUP = 1*DIRLINE
RECLINE = <CDNI Logging Record> CRLF RECLINE = <CDNI Logging Record> CRLF
RECGROUP = *RECLINE RECGROUP = *RECLINE
<CDNI Logging File> = 1*<DIRGROUP RECGROUP> <CDNI Logging File> = 1*<DIRGROUP RECGROUP>
3.3. CDNI Logging File Directives 3.3. CDNI Logging Directives
The CDNI Logging File directives are defined by the following rules: The CDNI Logging directives are defined by the following rules:
directive = DIRNAME ":" HTAB DIRVAL directive = DIRNAME ":" HTAB DIRVAL
DIRNAME = <any CDNI Logging Directive name registered in the CDNI DIRNAME = <any CDNI Logging Directive name registered in the CDNI
Logging Directive Names registry (Section 6.1)> Logging Directive Names registry (Section 6.1)>
DIRVAL = <directive value, as specified by the document identified DIRVAL = <directive value, as specified by the document identified
as Reference in the CDNI Logging Directive Names registry as Reference in the CDNI Logging Directive Names registry
(Section 6.1) for the corresponding DIRNAME> (Section 6.1) for the corresponding DIRNAME>
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: "CDNI" "/" 1*DIGIT "." 1*DIGIT * format: "CDNI" "/" 1*DIGIT "." 1*DIGIT
* directive value: indicates the version of the CDNI Logging File * directive value: indicates the version of the CDNI Logging File
format. The value MUST be "CDNI/1.0" for the version specified format. The entity transmitting a CDNI Logging File as per the
in the present document. present document MUST set the value to "CDNI/1.0". In the
future, other versions of CDNI Logging File might be specified;
those would use a value different to "CDNI/1.0" allowing the
entity receiving the CDNI Logging File to identify the
corresponding version.
* 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.
o UUID: o UUID:
* format: NHTABSTRING * format: NHTABSTRING
* directive value: this a Universally Unique IDentifier (UUID) * directive value: this a Universally Unique IDentifier (UUID)
skipping to change at page 21, line 23 skipping to change at page 21, line 29
of the CDNI Logging File pull mechanism (Section 4.2). of the CDNI Logging File pull mechanism (Section 4.2).
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.2). 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.
* 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.
o Fields: o Fields:
* format: FIENAME *<HTAB FIENAME> ; where FIENAME can take any * format: FIENAME *<HTAB FIENAME> ; where FIENAME can take any
CDNI Logging field name registered in the CDNI Logging Field CDNI Logging field name registered in the CDNI Logging Field
Names registry (Section 6.3). Names registry (Section 6.4).
* directive value: this lists the names of all the fields for * directive value: this lists the names of all the fields for
which a value is to appear in the CDNI Logging Records that which a value is to appear in the CDNI Logging Records that
follow the instance of this directive (until another instance follow the instance of this directive (until another instance
of this directive). The names of the fields, as well as their of this directive). The names of the fields, as well as their
occurrences, MUST comply with the corresponding rules specified occurrences, MUST comply with the corresponding rules specified
in the document referenced in the CDNI Logging Record-types in the document referenced in the CDNI Logging Record-types
registry (Section 6.2) for the corresponding CDNI Logging registry (Section 6.3) for the corresponding CDNI Logging
Record-Type. Record-Type.
* occurrence: there MUST be at least one instance of this * occurrence: there MUST be at least one instance of this
directive per Record-Type directive. The first instance of directive per Record-Type directive. The first instance of
this directive for a given Record-Type MUST appear before any this directive for a given Record-Type MUST appear before any
CDNI Logging Record for this Record-Type. One situation where CDNI Logging Record for this Record-Type. One situation where
more than one instance of the Fields directive can appear more than one instance of the Fields directive can appear
within a given CDNI Logging File, is when there is a change, in within a given CDNI Logging File, is when there is a change, in
the middle of a fairly large logging period, in the agreement the middle of a fairly large logging period, in the agreement
between the uCDN and the dCDN about the set of Fields that are between the uCDN and the dCDN about the set of Fields that are
skipping to change at page 23, line 5 skipping to change at page 23, line 10
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 Integrity-Hash field MUST be the last line of the CDNI the Integrity-Hash field MUST be the last line of the CDNI
Logging File. Logging File.
An uCDN-side implementation of the CDNI Logging interface MUST reject
a CDNI Logging File that does not comply with the occurences
specified above for each and every directive. For example, an uCDN-
side implementation of the CDNI Logging interface receiving a CDNI
Logging file with zero occurence of the Version directive, or with
two occurences of the Integrity-hash, MUST reject this CDNI Logging
File.
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
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
specification referenced in the CDNI Logging File Version registry
(see Section 6.1) if the implementation supports this specification
and MUST reject 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
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
skipping to change at page 24, line 4 skipping to change at page 24, line 27
contains the CDNI Logging field value corresponding to the CDNI contains the CDNI Logging field value corresponding to the CDNI
Logging field names (FIENAME) listed is the last Fields directive Logging field names (FIENAME) listed is the last Fields directive
preceding the present CDNI Logging Record. preceding the present CDNI Logging Record.
3.4.1. HTTP Request Logging Record 3.4.1. HTTP Request Logging Record
This section defines the CDNI Logging Record of Record-Type This section defines the CDNI Logging Record of Record-Type
"cdni_http_request_v1". It is applicable to content delivery "cdni_http_request_v1". It is applicable to content delivery
performed by the dCDN using HTTP/1.0([RFC1945]), performed by the dCDN using HTTP/1.0([RFC1945]),
HTTP/1.1([RFC7230],[RFC7231], [RFC7232], [RFC7233], [RFC7234], HTTP/1.1([RFC7230],[RFC7231], [RFC7232], [RFC7233], [RFC7234],
[RFC7235]) or HTTPS ([RFC2818], [RFC7230]). We observe that, in the [RFC7235]) or HTTPS ([RFC2818], [RFC7230]). We observe that, in the
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.0 [I-D.ietf-httpbis-http2] (which is still under applicable to HTTP/2 [I-D.ietf-httpbis-http2] (which is still under
development at the time of writing the present document) since a development at the time of writing the present document) since a
fundamental design tenet of HTTP/2.0 is to preserve the HTTP/1.1 fundamental design tenet of HTTP/2 is to preserve the HTTP/1.1
semantics. We observe that, in the case of HTTP/2.0 delivery, there semantics. We observe that, in the case of HTTP/2 delivery, there
may be value in logging additional information specific to the may be value in logging additional information specific to the
additional functionality of HTTP/2.0 (e.g. information related to additional functionality of HTTP/2 (e.g. information related to
connection identification, to stream identification, to stream connection identification, to stream identification, to stream
priority and to flow control). We note that such additional priority and to flow control). We note that such additional
information is outside the scope of the present document and may be information 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 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:
o date: o date:
skipping to change at page 28, line 40 skipping to change at page 29, line 12
prepended by a DQUOTE and appended by a DQUOTE. For example, prepended by a DQUOTE and appended by a DQUOTE. For example,
when the CDNI Logging field name (FIENAME) listed in the when the CDNI Logging field name (FIENAME) listed in the
preceding Fields directive is cs(User-Agent), this CDNI Logging preceding Fields directive is cs(User-Agent), this CDNI Logging
field value contains the value of the User-Agent HTTP header as field value contains the value of the User-Agent HTTP header as
received by the Surrogate in the request it processed, but received by the Surrogate in the request it processed, but
prepended by a DQUOTE and appended by a DQUOTE. If the HTTP prepended by a DQUOTE and appended by a DQUOTE. If the HTTP
header as it appeared in the request processed by the Surrogate header as it appeared in the request processed by the Surrogate
contains one or more DQUOTE, each DQUOTE MUST be escaped by an contains one or more DQUOTE, each DQUOTE MUST be escaped by an
additional DQUOTE. For example, if the HTTP header contains additional DQUOTE. For example, if the HTTP header contains
My_Header"value", then the field value of the cs(<HTTP-header- My_Header"value", then the field value of the cs(<HTTP-header-
name>) is "My_Header""value""". name>) is "My_Header""value""". The entity transmitting the
CDNI Logging File MUST ensure that the <HTTP-header-name> of
the cs(<HTTP-header-name) listed in the Fields directive comply
with HTTP specifications and, in particular, does not include
any HTAB, since this would prevent proper parsing of the Fields
directive by the entity receiving the CDNI Logging File.
* occurrence: there MAY be zero, one or any number of instance of * occurrence: there MAY be zero, one or any number of instance of
this field. this field.
o sc(<HTTP-header-name>): o sc(<HTTP-header-name>):
* format: QSTRING * format: QSTRING
* field value: the value of the HTTP header (identified by the * field value: the value of the HTTP header (identified by the
<HTTP-header-name> in the CDNI Logging field name) as it <HTTP-header-name> in the CDNI Logging field name) as it
appears in the response issued by the Surrogate to serve the appears in the response issued by the Surrogate to serve the
request, but prepended by a DQUOTE and appended by a DQUOTE. request, but prepended by a DQUOTE and appended by a DQUOTE.
If the HTTP header as it appeared in the request processed by If the HTTP header as it appeared in the request processed by
the Surrogate contains one or more DQUOTE, each DQUOTE MUST be the Surrogate contains one or more DQUOTE, each DQUOTE MUST be
escaped by an additional DQUOTE. For example, if the HTTP escaped by an additional DQUOTE. For example, if the HTTP
header contains My_Header"value", then the field value of the header contains My_Header"value", then the field value of the
cs(<HTTP-header-name>) is "My_Header""value""". cs(<HTTP-header-name>) is "My_Header""value""". The entity
transmitting the CDNI Logging File MUST ensure that the <HTTP-
header-name> of the cs(<HTTP-header-name) listed in the Fields
directive comply with HTTP specifications and, in particular,
does not include any HTAB, since this would prevent proper
parsing of the Fields directive by the entity receiving the
CDNI Logging File.
* occurrence: there MAY be zero, one or any number of instances * occurrence: there MAY be zero, one or any number of instances
of this field. For a given <HTTP-header-name>, there MUST be of this field. For a given <HTTP-header-name>, there MUST be
zero or exactly one instance of this field. zero or exactly one instance of this field.
o s-ccid: o s-ccid:
* format: QSTRING * format: QSTRING
* field value: this contains the value of the Content Collection * field value: this contains the value of the Content Collection
skipping to change at page 32, line 16 skipping to change at page 32, line 44
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
receives a CDNI Logging File with HTTP Request Logging Records that
do not contain field values for exactly the set of field names
actually listed in the preceding "Fields" directive, the
implementation MUST reject those HTTP Request Logging Records, and
MUST accept the other HTTP Request Logging Records .
3.5. CDNI Logging File Example 3.5. CDNI Logging File Example
Let us consider the upstream CDN and the downstream CDN labelled uCDN Let us consider the upstream CDN and the downstream CDN labelled uCDN
and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for and dCDN-1 in Figure 1. When dCDN-1 acts as a downstream CDN for
uCDN and performs content delivery on behalf of uCDN, dCDN-1 will uCDN and performs content delivery on behalf of uCDN, dCDN-1 will
include the CDNI Logging Records corresponding to the content include the CDNI Logging Records corresponding to the content
deliveries performed on behalf of uCDN in the CDNI Logging Files for deliveries performed on behalf of uCDN in the CDNI Logging Files for
uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is uCDN. An example CDNI Logging File communicated by dCDN-1 to uCDN is
shown below in Figure 4. shown below in Figure 4.
skipping to change at page 38, line 28 skipping to change at page 38, line 28
about older CDNI Logging files is moved into archive documents. Once about older CDNI Logging files is moved into archive documents. Once
created, archive documents are never modified. created, archive documents are never modified.
Each CDNI Logging File listed in an Atom feed MUST be described in an Each CDNI Logging File listed in an Atom feed MUST be described in an
atom:entry container element. atom:entry container element.
The atom:entry MUST contain an atom:content element whose "src" The atom:entry MUST contain an atom:content element whose "src"
attribute is a link to the CDNI Logging File and whose "type" attribute is a link to the CDNI Logging File and whose "type"
attribute is the MIME Media Type indicating that the entry is a CDNI attribute is the MIME Media Type indicating that the entry is a CDNI
Logging File. We define this MIME Media Type as "application/ Logging File. We define this MIME Media Type as "application/
cdni.LoggingFile" (See Section 6.4). cdni.LoggingFile" (See Section 6.5).
For compatibility with some Atom feed readers the atom:entry MAY also For compatibility with some Atom feed readers the atom:entry MAY also
contain an atom:link entry whose "href" attribute is a link to the contain an atom:link entry whose "href" attribute is a link to the
CDNI Logging File and whose "type" attribute is the MIME Media Type CDNI Logging File and whose "type" attribute is the MIME Media Type
indicating that the entry is a CDNI Logging File using the indicating that the entry is a CDNI Logging File using the
"application/cdni.LoggingFile" MIME Media Type (See Section 6.4). "application/cdni.LoggingFile" MIME Media Type (See Section 6.5).
The URI used in the atom:id of the atom:entry MUST contain the UUID The URI used in the atom:id of the atom:entry MUST contain the UUID
of the CDNI Logging File. of the CDNI Logging File.
The atom:updated in the atom:entry MUST indicate the time at which The atom:updated in the atom:entry MUST indicate the time at which
the CDNI Logging File was last updated. the CDNI Logging File was last updated.
4.1.2. Updates to Log Files and the Feed 4.1.2. Updates to Log Files and the Feed
CDNI Logging Files MUST NOT be modified by the dCDN once published in CDNI Logging Files MUST NOT be modified by the dCDN once published in
skipping to change at page 41, line 14 skipping to change at page 41, line 14
4.2. CDNI Logging File Pull 4.2. CDNI Logging File Pull
A client-side implementation of the CDNI Logging interface MAY pull, A client-side implementation of the CDNI Logging interface MAY pull,
at its convenience, a CDNI Logging File that is published by the at its convenience, a CDNI Logging File that is published by the
server-side in the CDNI Logging Feed (in the subscription document or server-side in the CDNI Logging Feed (in the subscription document or
an archive document). To do so, the client-side: an archive document). To do so, the client-side:
o MUST implement HTTP/1.1 ([RFC7230],[RFC7231], [RFC7232], o MUST implement HTTP/1.1 ([RFC7230],[RFC7231], [RFC7232],
[RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP [RFC7233], [RFC7234], [RFC7235]), MAY also support other HTTP
versions (e.g., HTTP/2.0 [I-D.ietf-httpbis-http2]) and MAY versions (e.g., HTTP/2 [I-D.ietf-httpbis-http2]) and MAY negotiate
negotiate which HTTP version is actually used. This allows which HTTP version is actually used. This allows operators and
operators and implementers to choose to use later versions of HTTP implementers to choose to use later versions of HTTP to take
to take advantage of new features, while still ensuring advantage of new features, while still ensuring interoperability
interoperability with systems that only support HTTP/1.1. with systems that only support HTTP/1.1.
o MUST use the URI that was associated to the CDNI Logging File o MUST use the URI that was associated to the CDNI Logging File
(within the "src" attribute of the corresponding atom:content (within the "src" attribute of the corresponding atom:content
element) in the CDNI Logging Feed; element) in the CDNI Logging Feed;
o MUST support exchange of CDNI Logging Files with no content o MUST support exchange of CDNI Logging Files with no content
encoding applied to the representation; encoding applied to the representation;
o MUST support exchange of CDNI Logging Files with "gzip" content o MUST support exchange of CDNI Logging Files with "gzip" content
encoding (as defined in [RFC7230]) applied to the representation. encoding (as defined in [RFC7230]) applied to the representation.
Note that a client-side implementation of the CDNI Logging interface Note that a client-side implementation of the CDNI Logging interface
MAY pull a CDNI Logging File that it has already pulled. MAY pull a CDNI Logging File that it has already pulled.
The server-side implementation MUST respond to valid pull request by The server-side implementation MUST respond to valid pull request by
a client-side implementation for a CDNI Logging File published by the a client-side implementation for a CDNI Logging File published by the
server-side in the CDNI Logging Feed (in the subscription document or server-side in the CDNI Logging Feed (in the subscription document or
an archive document). The server-side implementation: an archive document). The server-side implementation:
o MUST implement HTTP/1.1 to handle the client-side request and MAY o MUST implement HTTP/1.1 to handle the client-side request and MAY
also support other HTTP versions (e.g., HTTP/2.0); also support other HTTP versions (e.g., HTTP/2);
o MUST include the CDNI Logging File identified by the request URI o MUST include the CDNI Logging File identified by the request URI
inside the body of the HTTP response; inside the body of the HTTP response;
o MUST support exchange of CDNI Logging Files with no content o MUST support exchange of CDNI Logging Files with no content
encoding applied to the representation; encoding applied to the representation;
o MUST support exchange of CDNI Logging Files with "gzip" content o MUST support exchange of CDNI Logging Files with "gzip" content
encoding (as defined in [RFC7231]) applied to the representation. encoding (as defined in [RFC7231]) applied to the representation.
skipping to change at page 42, line 31 skipping to change at page 42, line 31
ready to serve, any CDNI Logging File within the agreed retention ready to serve, any CDNI Logging File within the agreed retention
limits. Outside these agreed limits, the server-side implementation limits. Outside these agreed limits, the server-side implementation
MAY indicate its inability to serve (e.g., with HTTP status code 404) MAY indicate its inability to serve (e.g., with HTTP status code 404)
a CDNI Logging File or MAY refuse to serve it (e.g., with HTTP status a CDNI Logging File or MAY refuse to serve it (e.g., with HTTP status
code 403 or 410). code 403 or 410).
5. Protocol for Exchange of CDNI Logging File During Collection 5. Protocol for Exchange of CDNI Logging File During Collection
We note that, in addition to the CDNI Logging File exchange protocol We note that, in addition to the CDNI Logging File exchange protocol
specified in Section 4, implementations of the CDNI Logging interface specified in Section 4, implementations of the CDNI Logging interface
MAY also support other mechanisms to exchange CDNI Logging Files. In may also support other mechanisms to exchange CDNI Logging Files. In
particular, such mechanisms might allow the exchange of the CDNI particular, such mechanisms might allow the exchange of the CDNI
Logging File to start before the file is fully collected. This can Logging File to start before the file is fully collected. This can
allow CDNI Logging Records to be communicated by the dCDN to the uCDN allow CDNI Logging Records to be communicated by the dCDN to the uCDN
as they are gathered by the dCDN without having to wait until all the as they are gathered by the dCDN without having to wait until all the
CDNI Logging Records of the same logging period are collected in the CDNI Logging Records of the same logging period are collected in the
corresponding CDNI Logging File. This approach is commonly referred corresponding CDNI Logging File. This approach is commonly referred
to as "tailing" of the file. to as "tailing" of the file.
Such an approach could be used, for example, to exchange logging Such an approach could be used, for example, to exchange logging
information with a significantly reduced time-lag (e.g., sub-minute information with a significantly reduced time-lag (e.g., sub-minute
skipping to change at page 43, line 12 skipping to change at page 43, line 12
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
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 registry, CDNI Logging
Directive Names. Directive Names.
The initial contents of the CDNI Logging File Directives registry The initial contents of the CDNI Logging Directives registry comprise
comprise the names of the directives specified in Section 3.3 of the the names of the directives specified in Section 3.3 of the present
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 |
| Claimed-Origin | RFC xxxx | | Claimed-Origin | RFC xxxx |
| Established-Origin | RFC xxxx | | Established-Origin | RFC xxxx |
| Record-Type | RFC xxxx | | Record-Type | RFC xxxx |
| Fields | RFC xxxx | | Fields | RFC xxxx |
skipping to change at page 43, line 43 skipping to change at page 43, line 43
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]. the "Specification Required" policy specified in [RFC5226].
Directive names are to be allocated by IANA with a format of Directive names are to be allocated by IANA with a format of
NAMEFORMAT (see Section 3.1). NAMEFORMAT (see Section 3.1).
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 Record-Types Registry 6.2. CDNI Logging File Version Registry
The IANA is requested to create a new registry, CDNI 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
the present document, and are as follows:
+-----------------+-----------+----------------------------------+
| Version | Reference | Description |
+-----------------+-----------+----------------------------------+
| CDNI/1.0 | RFC xxxx | CDNI Logging File version 1.0 |
| | | as specified in RFC xxxx |
+-----------------+-----------+----------------------------------+
Figure 9
[Instructions to IANA: Replace "RFC xxxx" above by the RFC number of
the present document]
Within the registry, Version values are to be allocated by IANA
according to the "Specification Required" policy specified in
[RFC5226]. Version values are to be allocated by IANA with a format
as specified for the Version directive in Section 3.3.
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 registry, CDNI Logging Record-
Types. Types.
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 |
+----------------------+-----------+----------------------------------+ +----------------------+-----------+----------------------------------+
Figure 9 Figure 10
[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, Record-Types are to be allocated by IANA Within the registry, Record-Types are to be allocated by IANA
according to the "Specification Required" policy specified in according to the "Specification Required" policy specified in
[RFC5226]. Record-Types are to be allocated by IANA with a format of [RFC5226]. Record-Types are to be allocated by IANA with a format of
NAMEFORMAT (see Section 3.1). Record-Types corresponding to NAMEFORMAT (see Section 3.1). Record-Types corresponding to
specifications produced by the IETF CDNI Working Group are to be specifications produced by the IETF CDNI Working Group are to be
allocated a name starting with "cdni_". All other Record-Types are allocated a name starting with "cdni_". All other Record-Types are
skipping to change at page 44, line 37 skipping to change at page 45, line 17
as provided in Section 3.4.1. This includes: as provided in Section 3.4.1. This includes:
o a list of all the CDNI Logging Fields that can appear in a CDNI o a list of all the CDNI Logging Fields that can appear in a CDNI
Logging Record of the new Record-Type Logging Record of the new Record-Type
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.3): a specification of the field name, format and field (Section 6.4): a specification of the field name, format and field
value. value.
6.3. 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 registry, CDNI Logging Field
Names. Names.
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
skipping to change at page 45, line 40 skipping to change at page 46, line 31
| sc-status | RFC xxxx | | sc-status | RFC xxxx |
| sc-total-bytes | RFC xxxx | | sc-total-bytes | RFC xxxx |
| sc-entity-bytes | RFC xxxx | | sc-entity-bytes | RFC xxxx |
| cs(<HTTP-header>) | RFC xxxx | | cs(<HTTP-header>) | RFC xxxx |
| sc(<HTTP-header>) | RFC xxxx | | sc(<HTTP-header>) | RFC xxxx |
| s-ccid | RFC xxxx | | s-ccid | RFC xxxx |
| s-sid | RFC xxxx | | s-sid | RFC xxxx |
| s-cached | RFC xxxx | | s-cached | RFC xxxx |
+------------------------------------------+-----------+ +------------------------------------------+-----------+
Figure 10 Figure 11
[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, 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.4. CDNI Logging MIME Media Type 6.5. CDNI Logging MIME Media Type
The IANA is requested to allocate the "application/cdni.LoggingFile" The IANA is requested to allocate the "application/cdni.LoggingFile"
MIME Media Type (whose use is specified in Section 4.1.1 of the MIME Media Type (whose use is specified in Section 4.1.1 of the
present document) in the MIME Media Types registry. present document) in the MIME Media Types registry.
7. Security Considerations 7. Security Considerations
7.1. Authentication, Authorization, Confidentiality, Integrity
7.1. Authentication, 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].
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 (to ensure they are o the dCDN and uCDN to authenticate each other
transmitting/receiving CDNI Logging File from an authenticated
and, once they have mutually authenticated each other, it allows::
o the dCDN and uCDN to authorize each other (to ensure they are
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, TLS SHOULD In an environment where any such protection is required, the use of a
be used (including authentication of the remote end) by the server- mutually authenticated encrypted transport MUST be used to ensure
side and the client-side of the CDNI Logging feed and the CDNI confidentiality of the logging information. TLS SHOULD be used
Logging File pull mechanism unless alternate methods are used for (including authentication of the remote end) by the server- side and
ensuring the confidentiality of the information in the logging files the client-side of the CDNI Logging feed, as well as the server- side
(such as setting up an IPsec tunnel between the two CDNs or using a and the client-side of the CDNI Logging File pull mechanism, unless
alternate methods are used. Alternate methods could include
establishing an IPsec tunnel between the two CDNs or using a
physically secured internal network between two CDNs that are owned physically secured internal network between two CDNs that are owned
by the same corporate entity). by the same corporate entity).
An implementation of the CDNI Logging interface MUST support the The general TLS usage guidance in [I-D.ietf-uta-tls-bcp] SHOULD be
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ( [RFC5288]). An followed.
implementation of the CDNI Logging interface SHOULD prefer cipher
suites which support perfect forward secrecy over cipher suites that
don't.
The Integrity-Hash directive inside the CDNI Logging File provides The Integrity-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 Integrity-Hash does not protect against tampering by a Note that the Integrity-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 Integrity-Hash after tampering. Protection against third updated the Integrity-Hash after tampering. Protection against third
party tampering can be achieved as discussed above through the use of party tampering can be achieved as discussed above through the use of
TLS. 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 can be the CDNI Logging feed and CDNI Logging pull endpoints are typically
protected against DoS attacks through the use of TLS transport and/or to be accessed only by a very small number of valid remote endpoints
via mechanisms outside the scope of the CDNI Logging interface such and therefore can be easily protected against DoS attacks through the
as firewalling or use of Virtual Private Networks (VPNs). usual conventional DOS protection mechanisms such as firewalling or
use of Virtual Private Networks (VPNs).
Protection of dCDN Surrogates against spoofed delivery requests is Protection of dCDN Surrogates against spoofed delivery requests is
outside the scope of the CDNI Logging interface. outside the scope of the CDNI Logging interface.
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. The provision of this information downloads performed by End Users. The provision of this information
to another CDN introduces potential End Users privacy protection to another CDN introduces potential End Users privacy protection
concerns. concerns.
The use of TLS for transport of the CDNI Logging feed and CDNI The use of mutually authenticated TLS to establish a secure session
Logging pull as discussed in Section 7.1 protects the confidentiality for the transport of the CDNI Logging feed and CDNI Logging pull as
of logged information by preventing any other party than the discussed in Section 7.1 access to the logging information. This
authorised uCDN to gain access to the logging information. provides confidentiality while the logging information is in transit
and prevents any other party than the authorised uCDN to gain access
to the logging information.
We observe that when CDNI interconnection is realised as per We observe that when CDNI interconnection is realised as per
[RFC7336], the uCDN handles the initial End User requests (before it [RFC7336], the uCDN handles the initial End User requests (before it
is redirected to the dCDN) so, regardless of which information is, or is redirected to the dCDN) so, regardless of which information is, or
is not, communicated to the uCDN through the CDNI Logging interface, is not, communicated to the uCDN through the CDNI Logging interface,
the uCDN has visibility on significant information such as the IP the uCDN has visibility on significant information such as the IP
address of the End User request and the URL of the request. address of the End User request and the URL of the request.
Nonetheless, if the dCDN and uCDN agree that anonymization is Nonetheless, if the dCDN and uCDN agree that anonymization is
required to avoid making some detailed information available to the required to avoid making some detailed information available to the
skipping to change at page 48, line 44 skipping to change at page 49, line 42
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
[I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-11 (work in progress), February 2015.
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005. 2005.
skipping to change at page 50, line 12 skipping to change at page 51, line 12
<http://www.iana.org/assignments/character-sets/ <http://www.iana.org/assignments/character-sets/
character-sets.xml>. character-sets.xml>.
[ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended [ELF] Phillip M. Hallam-Baker, and Brian Behlendorf, "Extended
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-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-08 (work in progress), October 2014. metadata-09 (work in progress), March 2015.
[I-D.ietf-httpbis-http2] [I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-16 (work in Protocol version 2", draft-ietf-httpbis-http2-17 (work in
progress), November 2014. progress), February 2015.
[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.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
 End of changes. 47 change blocks. 
91 lines changed or deleted 169 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/